[U-Boot] [PATCH] vxworks: Add CONFIG_VXWORKS_PREBOOT

2009-09-22 Thread Niklaus Giger
The option CONFIG_VXWORKS_PREBOOT allows a board specific
vxworks_preboot to be run just before jumping into the
vxWorks images. This can be used to alter a register
which is used differently by U-boot and vxWorks.

Signed-off-by: Niklaus Giger 
---
 common/cmd_elf.c  |4 
 include/vxworks.h |4 
 2 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index bf7dd63..4e36680 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -213,6 +213,10 @@ int do_bootvx (cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
(char *) bootaddr);
printf ("## Starting vxWorks at 0x%08lx ...\n", addr);
 
+#ifdef CONFIG_VXWORKS_PREBOOT
+vxworks_preboot();
+#endif
+
((void (*)(void)) addr) ();
 
puts ("## vxWorks terminated\n");
diff --git a/include/vxworks.h b/include/vxworks.h
index 1633904..df2b580 100644
--- a/include/vxworks.h
+++ b/include/vxworks.h
@@ -50,4 +50,8 @@ int do_bootvx(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[]);
 #define CONFIG_SYS_VXWORKS_SERVERNAME  "srv"
 #endif
 
+#ifdef CONFIG_VXWORKS_PREBOOT
+void vxworks_preboot(void);
+#endif
+
 #endif
-- 
1.6.3.3

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


[U-Boot] [PATCH] vxworks: Make loading vxworks less verbose

2009-09-22 Thread Niklaus Giger
Newer vxWorks 6.x images have over 20 different C++ segments.
This fills up the output with rarely used information.

Signed-off-by: Niklaus Giger 
---
 common/cmd_elf.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/common/cmd_elf.c b/common/cmd_elf.c
index 63f6fe7..bf7dd63 100644
--- a/common/cmd_elf.c
+++ b/common/cmd_elf.c
@@ -286,6 +286,7 @@ unsigned long load_elf_image (unsigned long addr)
continue;
}
 
+#ifdef DEBUG
if (strtab) {
debug("%sing %s @ 0x%08lx (%ld bytes)\n",
(shdr->sh_type == SHT_NOBITS) ?
@@ -294,6 +295,7 @@ unsigned long load_elf_image (unsigned long addr)
(unsigned long) shdr->sh_addr,
(long) shdr->sh_size);
}
+#endif
 
if (shdr->sh_type == SHT_NOBITS) {
memset ((void *)shdr->sh_addr, 0, shdr->sh_size);
-- 
1.6.3.3

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


[U-Boot] [PATCH] Cleanup: use constant

2009-09-22 Thread Niklaus Giger
Signed-off-by: Niklaus Giger 
---
 common/miiphyutil.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/common/miiphyutil.c b/common/miiphyutil.c
index 66fd9ca..196ef4a 100644
--- a/common/miiphyutil.c
+++ b/common/miiphyutil.c
@@ -299,7 +299,7 @@ int miiphy_reset (char *devname, unsigned char addr)
debug ("PHY status read failed\n");
return (-1);
}
-   if (miiphy_write (devname, addr, PHY_BMCR, reg | 0x8000) != 0) {
+   if (miiphy_write (devname, addr, PHY_BMCR, reg | PHY_BMCR_RESET) != 0) {
debug ("PHY reset failed\n");
return (-1);
}
-- 
1.6.3.3

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


Re: [U-Boot] [U-boot] Marvell Pull Request

2009-09-22 Thread Prafulla Wadaskar
 

> -Original Message-
> From: Tom [mailto:tom@windriver.com] 
> Sent: Tuesday, September 22, 2009 6:50 PM
> To: Prafulla Wadaskar
> Cc: U-Boot; Paulraj, Sandeep; Minkyu Kang; Wolfgang Denk
> Subject: Re: [U-Boot] [U-boot] Marvell Pull Request
> 
> Prafulla Wadaskar wrote:
> >  
> > 
> >> -Original Message-
> >> From: Tom [mailto:tom@windriver.com] 
> >> Sent: Tuesday, September 22, 2009 12:46 AM
> >> To: Prafulla Wadaskar
> >> Cc: U-Boot
> >> Subject: Re: [U-Boot] [U-boot] Marvell Pull Request
> >>
> >> Prafulla Wadaskar wrote:
> >>> Hi Wolfgang
> >>>
> >>> Please pull
> >> Shouldn't this rather get pulled to u-boot-arm?
> >> Tom
> > 
> > Hi Tom,
> > Yes :-) you are right.
> > I was bit biased since u-boot-marvell.git was cloned from u-boot.git
> > Shall I generate new email pull request? Or
> > Can you please kindly pull it to u-boot-arm?
> 
> I would like to set up a process where I just cherry picked 
> your changes
> directly from marvell/master.
> 
> Comparing marvell/master to arm/next
> 
> git cherry t-next
> + ceb2d57c2205db5bbd868577f756c74a2568160c
> + 95a4a593b577b6e2f1da2d4b0f5ec86975c33413
> + 84a45d33c2cc261dbd5411f7c2ad45f6003025b6
> + e67af44d0167d8237dd2c2ddf8e301d19ca12914
> + 0413cfecea35eab5e591a0965c3e3ee0ff00
> + 3b6a9267f0de7b85d387fa4123d0b58379363447
> + ffed6c85ce591cd93e28190153fec421c3b2499c <- pick me
> + c928c19b2563e4977adc0570d06c900ac1e7788c <- pick me
> + 9ef0569a3c8b0d2458bdbce21a5370807e13e20a <- pick me
> 
> The others look like they came from u-boot/master
> 
> It would be helpful but not required if you merged against 
> arm/master or 
> arm/next instead of u-boot/master.

I think this makes more sense to merge it from arm/master, I will do that, I am 
thinking of creating a branch "arm" instead of disturbing master, what do you 
think?

> 
> If I can assume what is good in marvell/master, we do not need
> for you go through the asking for a pulls, they will just happen
> when I have time, likely over the weekend.

If I have clean changes in lined with arm/master, then why not to pull?

> 
> These changes will accumulate in arm/next.

If this is clear from you that Changes will be accumulated in arm/next then I 
must rebase a branch on u-boot-marvell.git with arm/next.

> Less frequently I will merge these to arm/master.
> This will happen once you and the other arm maintainers have
> given then the ok.  I was thinking that this could happen monthly
> but I am open for other suggestions.

I think monthly will be too long, may be wolfgang can comment better on this :-)

Regards..
Prafulla . .

> 
> Tom
> 
> > 
> > Regards..
> > Prafulla . .
> > 
> >>
> >>> The following changes since commit 
> >> 3b6a9267f0de7b85d387fa4123d0b58379363447:
> >>>   Wolfgang Denk (1):
> >>> board/flagadm/flash.c: fix compile warning
> >>>
> >>> are available in the git repository at:
> >>>
> >>>   git://git.denx.de/u-boot-marvell.git master
> >>>
> >>> Prafulla Wadaskar (2):
> >>>   Kirkwood: rd6281a: Add kwbimage build support
> >>>   Kirkwood: mv88f6281gtw_ge: Add kwbimage build support
> >>>
> >>> Simon Kagstrom (1):
> >>>   Support for the OpenRD base board
> >>>
> >>>  MAINTAINERS|4 +
> >>>  MAKEALL|1 +
> >>>  Makefile   |3 +
> >>>  board/Marvell/mv88f6281gtw_ge/config.mk|3 +
> >>>  board/Marvell/mv88f6281gtw_ge/kwbimage.cfg |  165 
> >> +
> >>>  board/Marvell/openrd_base/Makefile |   56 +++
> >>>  board/Marvell/openrd_base/config.mk|   33 
> >>>  board/Marvell/openrd_base/kwbimage.cfg |  168 
> >> +
> >>>  board/Marvell/openrd_base/openrd_base.c|  160 
> >> 
> >>>  board/Marvell/openrd_base/openrd_base.h|   46 ++
> >>>  board/Marvell/rd6281a/config.mk|3 +
> >>>  board/Marvell/rd6281a/kwbimage.cfg |  167 
> >> +
> >>>  include/configs/openrd_base.h  |  220 
> >> 
> >>>  13 files changed, 1029 insertions(+), 0 deletions(-)
> >>>  create mode 100644 board/Marvell/mv88f6281gtw_ge/kwbimage.cfg
> >>>  create mode 100644 board/Marvell/openrd_base/Makefile
> >>>  create mode 100644 board/Marvell/openrd_base/config.mk
> >>>  create mode 100644 board/Marvell/openrd_base/kwbimage.cfg
> >>>  create mode 100644 board/Marvell/openrd_base/openrd_base.c
> >>>  create mode 100644 board/Marvell/openrd_base/openrd_base.h
> >>>  create mode 100644 board/Marvell/rd6281a/kwbimage.cfg
> >>>  create mode 100644 include/configs/openrd_base.h
> >>>
> >>> Regards..
> >>> Prafulla . . .
> >>> ___
> >>> 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/

[U-Boot] [PATCHv6 2/2] mucmc52, uc101: delete a...@3a00 node, if no CF card is detected

2009-09-22 Thread Heiko Schocher
U-Boot can detect if an IDE device is present or not.
If not, and this new config option is activated, U-Boot
removes the ATA node from the DTS before booting Linux,
so the Linux IDE driver does not probe the device and
crash. This is needed for buggy hardware (uc101) where
no pull down resistor is connected to the signal IDE5V_DD7.

Signed-off-by: Heiko Schocher 
---

changes since v1:
- added comment from Wolfgang Denk, to move this to a more
  common place, so others can also use it, and made it
  therefore per CONFIG_OF_IDE_FIXUP selectable.

changes since v2:
- add CONFIG_OF_IDE_FIXUP to mpc5200-common.h

changes since v3:
- correct spelling in README and commit message, as
  Detlev Zundel suggested

changes since v4:
- added comments from Stefan Roese
  Coding Style corrections
  do not longer include the global variable, instead
  call ide_device_present()
- added comment from Jerry Van Baren
  correct README entry

changes since v5:
  delete ata node if !ide_device_present() instead
  of ide_device_present()

 README |9 +
 common/cmd_ide.c   |8 
 cpu/mpc5xxx/cpu.c  |   20 
 include/configs/manroland/mpc5200-common.h |1 +
 include/ide.h  |3 +++
 5 files changed, 41 insertions(+), 0 deletions(-)

diff --git a/README b/README
index ff4ed8b..8d0cbc9 100644
--- a/README
+++ b/README
@@ -386,6 +386,15 @@ The following options need to be configured:
This define fills in the correct boot CPU in the boot
param header, the default value is zero if undefined.

+   CONFIG_OF_IDE_FIXUP
+
+   U-Boot can detect if an IDE device is present or not.
+   If not, and this new config option is activated, U-Boot
+   removes the ATA node from the DTS before booting Linux,
+   so the Linux IDE driver does not probe the device and
+   crash. This is needed for buggy hardware (uc101) where
+   no pull down resistor is connected to the signal IDE5V_DD7.
+
 - vxWorks boot parameters:

bootvx constructs a valid bootline using the following
diff --git a/common/cmd_ide.c b/common/cmd_ide.c
index 4d7a0ac..ec9a1df 100644
--- a/common/cmd_ide.c
+++ b/common/cmd_ide.c
@@ -1624,6 +1624,14 @@ static void ide_led (uchar led, uchar status)

 #endif /* CONFIG_IDE_LED */

+#if defined(CONFIG_OF_IDE_FIXUP)
+int ide_device_present(int dev)
+{
+   if (dev >= CONFIG_SYS_IDE_MAXBUS)
+   return 0;
+   return (ide_dev_desc[dev].type == DEV_TYPE_UNKNOWN ? 0 : 1);
+}
+#endif
 /* - */

 #ifdef CONFIG_ATAPI
diff --git a/cpu/mpc5xxx/cpu.c b/cpu/mpc5xxx/cpu.c
index f6258c7..efa64c7 100644
--- a/cpu/mpc5xxx/cpu.c
+++ b/cpu/mpc5xxx/cpu.c
@@ -40,6 +40,10 @@
 #include 
 #endif

+#if defined(CONFIG_OF_IDE_FIXUP)
+#include 
+#endif
+
 DECLARE_GLOBAL_DATA_PTR;

 int checkcpu (void)
@@ -137,6 +141,22 @@ void ft_cpu_setup(void *blob, bd_t *bd)
do_fixup_by_path(blob, eth_path, "mac-address", enetaddr, 6, 0);
do_fixup_by_path(blob, eth_path, "local-mac-address", enetaddr, 6, 0);
 #endif
+#if defined(CONFIG_OF_IDE_FIXUP)
+   if (!ide_device_present(0)) {
+   /* NO CF card detected -> delete ata node in DTS */
+   int nodeoffset = 0;
+   char nodename[] = "/soc5...@f000/a...@3a00";
+
+   nodeoffset = fdt_path_offset(blob, nodename);
+   if (nodeoffset >= 0) {
+   fdt_del_node(blob, nodeoffset);
+   } else {
+   printf("%s: cannot find %s node err:%s\n",
+   __func__, nodename, fdt_strerror(nodeoffset));
+   }
+   }
+
+#endif
 }
 #endif

diff --git a/include/configs/manroland/mpc5200-common.h 
b/include/configs/manroland/mpc5200-common.h
index 2f092b1..b29ef9b 100644
--- a/include/configs/manroland/mpc5200-common.h
+++ b/include/configs/manroland/mpc5200-common.h
@@ -225,5 +225,6 @@
 #define OF_SOC "soc5...@f000"
 #define OF_TBCLK   (bd->bi_busfreq / 4)
 #define OF_STDOUT_PATH "/soc5...@f000/ser...@2000"
+#define CONFIG_OF_IDE_FIXUP

 #endif /* __MANROLAND_MPC52XX__COMMON_H */
diff --git a/include/ide.h b/include/ide.h
index ddb9579..6a1b7ae 100644
--- a/include/ide.h
+++ b/include/ide.h
@@ -54,4 +54,7 @@ void ide_init(void);
 ulong ide_read(int device, lbaint_t blknr, ulong blkcnt, void *buffer);
 ulong ide_write(int device, lbaint_t blknr, ulong blkcnt, void *buffer);

+#if defined(CONFIG_OF_IDE_FIXUP)
+int ide_device_present(int dev);
+#endif
 #endif /* _IDE_H */
-- 
1.6.0.6

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
_

[U-Boot] [PATCHv4 1/2] mpc5200, mucmc52, uc101: config cleanup

2009-09-22 Thread Heiko Schocher
- as this boards are similiar, collect common config option
  in manroland/common.h and manroland/mpc52xx-common.h
  for mpc5200 specific common options for this manufacturer.
- add OF support
- update default environment

Signed-off-by: Heiko Schocher 
---

- changes since v1:
  added suggestion from Detlev Zundel, to collect mpc52xx specific
  config options in manroland-mpc52xx-common.h

- changes since v2:
  as discussed with Wolfgang and Detlev, moved the manroland common
  headers in include/configs/manroland

- changes since v3:
  add possibility to set loglevel in default environment

 board/mucmc52/mucmc52.c|7 +
 board/uc101/uc101.c|7 +
 include/configs/manroland/common.h |  141 +++
 include/configs/manroland/mpc5200-common.h |  229 
 include/configs/mucmc52.h  |  257 +--
 include/configs/uc101.h|  267 ++--
 6 files changed, 404 insertions(+), 504 deletions(-)
 create mode 100644 include/configs/manroland/common.h
 create mode 100644 include/configs/manroland/mpc5200-common.h

diff --git a/board/mucmc52/mucmc52.c b/board/mucmc52/mucmc52.c
index 7181bd8..bac49be 100644
--- a/board/mucmc52/mucmc52.c
+++ b/board/mucmc52/mucmc52.c
@@ -398,3 +398,10 @@ void pci_init_board (void)
pci_mpc5xxx_init (&hose);
 }
 #endif
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+   ft_cpu_setup(blob, bd);
+}
+#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/board/uc101/uc101.c b/board/uc101/uc101.c
index 7df349f..4030b9d 100644
--- a/board/uc101/uc101.c
+++ b/board/uc101/uc101.c
@@ -371,3 +371,10 @@ void hw_watchdog_reset(void)
*(vu_long *)MPC5XXX_GPT0_ENABLE = GPT_OUT_0;
 }
 #endif
+
+#if defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+   ft_cpu_setup(blob, bd);
+}
+#endif /* defined(CONFIG_OF_LIBFDT) && defined(CONFIG_OF_BOARD_SETUP) */
diff --git a/include/configs/manroland/common.h 
b/include/configs/manroland/common.h
new file mode 100644
index 000..c0122b7
--- /dev/null
+++ b/include/configs/manroland/common.h
@@ -0,0 +1,141 @@
+/*
+ * (C) Copyright 2009
+ * Heiko Schocher, DENX Software Engineering, h...@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
+ */
+
+#ifndef __MANROLAND_COMMON_H
+#define __MANROLAND_COMMON_H
+
+/*
+ * High Level Configuration Options
+ * (easy to change)
+ */
+
+#define BOOTFLAG_COLD  0x01/* Normal Power-On: Boot from FLASH 
*/
+#define BOOTFLAG_WARM  0x02/* Software reboot  
*/
+
+#define CONFIG_BOARD_EARLY_INIT_R
+
+/* Partitions */
+#define CONFIG_DOS_PARTITION
+
+/*
+ * Command line configuration.
+ */
+#include 
+
+#define CONFIG_CMD_DATE
+#define CONFIG_CMD_DISPLAY
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_EEPROM
+#define CONFIG_CMD_I2C
+#define CONFIG_CMD_DTT
+#define CONFIG_CMD_IDE
+#define CONFIG_CMD_FAT
+#define CONFIG_CMD_NFS
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_SNTP
+
+#defineCONFIG_TIMESTAMP1   /* Print image info with 
timestamp */
+
+/*
+ * Autobooting
+ */
+#define CONFIG_BOOTDELAY   5   /* autoboot after 5 seconds */
+
+#define CONFIG_PREBOOT "echo;" \
+   "echo Type \\\"run flash_nfs\\\" to mount root filesystem over NFS;" \
+   "echo"
+
+#undef CONFIG_BOOTARGS
+
+#define xstr(s)str(s)
+#define str(s) #s
+
+#define CONFIG_EXTRA_ENV_SETTINGS  \
+   "netdev=eth0\0" \
+   "nfsargs=setenv bootargs root=/dev/nfs rw " \
+   "nfsroot=${serverip}:${rootpath}\0" \
+   "ramargs=setenv bootargs root=/dev/ram rw\0"\
+   "addwdt=setenv bootargs ${bootargs} wdt=off\0"  \
+   "logval=4\0"\
+   "addlog=setenv bootargs ${bootargs} loglevel=${logval}\0"   \
+   "addip=setenv bootarg

[U-Boot] [PATCH 0/2] mpc52xx, mucmc52, uc101: config cleanup

2009-09-22 Thread Heiko Schocher
Changes:
- As this boards are similiar, collect common config option
  in manroland/common.h and manroland/mpc5200-common.h
- Also add OF support to boot 2.6.x kernels
- update default environment for booting 2.6.x kernels
- If no CF card is detected delete the ata node in the DTS
  before booting Linux

Heiko Schocher (2):
  mpc5200, mucmc52, uc101: config cleanup
  mucmc52, uc101: delete a...@3a00 node, if no CF card is detected

 README |9 +
 board/mucmc52/mucmc52.c|7 +
 board/uc101/uc101.c|7 +
 common/cmd_ide.c   |8 +
 cpu/mpc5xxx/cpu.c  |   20 ++
 include/configs/manroland/common.h |  141 +++
 include/configs/manroland/mpc5200-common.h |  230 
 include/configs/mucmc52.h  |  257 +--
 include/configs/uc101.h|  267 ++--
 include/ide.h  |3 +
 10 files changed, 445 insertions(+), 504 deletions(-)
 create mode 100644 include/configs/manroland/common.h
 create mode 100644 include/configs/manroland/mpc5200-common.h

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCHv5 2/2] mucmc52, uc101: delete a...@3a00 node, if no CF card is detected

2009-09-22 Thread Heiko Schocher
Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4aaf1fe4.9050...@denx.de> you wrote:
>> U-Boot can detect if an IDE device is present or not.
>> If not, and this new config option is activated, U-Boot
>> removes the ATA node from the DTS before booting Linux,
>> so the Linux IDE driver does not probe the device and
>> crash. This is needed for buggy hardware (uc101) where
>> no pull down resistor is connected to the signal IDE5V_DD7.
>>
>> Signed-off-by: Heiko Schocher 
> 
> Seems this patch depends on other patches, that add support for the
> manroland boards, which have not been accepted yet. I think I'm
> waiting for a resubmit from you?

OK, I am reposting it.

bye
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 2/3] Add support for save environment variable to MMC/SD card

2009-09-22 Thread Hu Mingkai-B21284
 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Wednesday, September 23, 2009 2:54 AM
> To: Hu Mingkai-B21284
> Cc: u-boot@lists.denx.de; Wood Scott-B07421; Gala Kumar-B11780
> Subject: Re: [U-Boot] [PATCH v1 2/3] Add support for save 
> environment variable to MMC/SD card
> 
> Dear Mingkai Hu,
> 
> In message 
> <1252640445-7890-3-git-send-email-mingkai...@freescale.com> you wrote:
> > Whether booting from MMC/SD card or not, the environment 
> variables can 
> > be saved on it, this patch add the operation support.
> > 
> > Signed-off-by: Mingkai Hu 
> ...
> > --- a/common/Makefile
> > +++ b/common/Makefile
> > @@ -61,6 +61,7 @@ COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
> >  COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
> >  COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
> >  COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
> > +COBJS-$(CONFIG_ENV_IS_IN_SDCARD) += env_sdcard.o
> >  COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o
> 
> Please keep the list sorted.
> 
OK.

> >  # command
> > diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c index 
> > 2186205..83969ef 100644
> > --- a/common/cmd_nvedit.c
> > +++ b/common/cmd_nvedit.c
> > @@ -60,9 +60,10 @@ DECLARE_GLOBAL_DATA_PTR;
> >  !defined(CONFIG_ENV_IS_IN_NVRAM)   && \
> >  !defined(CONFIG_ENV_IS_IN_ONENAND) && \
> >  !defined(CONFIG_ENV_IS_IN_SPI_FLASH)   && \
> > +!defined(CONFIG_ENV_IS_IN_SDCARD)  && \
> 
> Ditto.
> 
OK.

> >  # error Define one of 
> > CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
> > -SPI_FLASH|MG_DISK|NVRAM|NOWHERE}
> > +SPI_FLASH|MG_DISK|NVRAM|SDCARD|NOWHERE}
> 
> Please take the opportunity to sort this list, too. Thanks.
> 
OK.

> ...
> > +int env_init(void)
> > +{
> > +   /* eSDHC isn't usable before relocation */
> > +   gd->env_addr  = (ulong)&default_environment[0];
> > +   gd->env_valid = 1;
> 
> Argh... Does that mean that your environment suddenly changes 
> while running? That you start running from the default 
> environment (which cannot be changed) and then switch to a 
> the real, changable environment?
> 
Yes. I refered to env_sf.c file, maybe it has the same issue.

> This is going to cause a hell of confusion to users who for 
> example want to define a different console baud rate or such...
> 
It's a problem.

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


Re: [U-Boot] [PATCH v1 1/3] Make mmc init come before env_relocate

2009-09-22 Thread Hu Mingkai-B21284
 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Wednesday, September 23, 2009 2:58 AM
> To: Hu Mingkai-B21284
> Cc: u-boot@lists.denx.de; Wood Scott-B07421; Gala Kumar-B11780
> Subject: Re: [U-Boot] [PATCH v1 1/3] Make mmc init come 
> before env_relocate
> 
> This has not been done so far, because it suffers from the 
> fundamental problem your code is suffering from, too: you 
> cannot access the environment early enough, so for example 
> your board boots with a hard-wird, unchangable console baud 
> rate, despite that you suggest to the user he could change it.
>
Got it.
 
> I don't like that, and therefore tend to NAK the whole approach.
>
No problem, after all this patchset is not matured enough.

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


Re: [U-Boot] [PATCH v1 3/3] mpc8536: Get the address of env on the SDCard

2009-09-22 Thread Hu Mingkai-B21284

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Wednesday, September 23, 2009 3:00 AM
> To: Hu Mingkai-B21284
> Cc: u-boot@lists.denx.de; Wood Scott-B07421; Gala Kumar-B11780
> Subject: Re: [U-Boot] [PATCH v1 3/3] mpc8536: Get the address 
> of env on the SDCard
> 
> This seems to be broken by design. If your U-Boot image 
> grows, it would overwrite the environment? Or am I missing something?
> 

Yes, if the U-Boot image grows, it would overwrite the env saved last
time.
Maybe we should put it the to haed of the U-Boot image.

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


Re: [U-Boot] [PATCH v3 3/5] NAND boot: MPC8536DS support

2009-09-22 Thread Hu Mingkai-B21284
 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Wednesday, September 23, 2009 3:16 AM
> To: Hu Mingkai-B21284
> Cc: u-boot@lists.denx.de; Wood Scott-B07421; Gala Kumar-B11780
> Subject: Re: [U-Boot] [PATCH v3 3/5] NAND boot: MPC8536DS support
> 
> > +   /* set up CCSR if we want it moved */ #if 
> > +(CONFIG_SYS_CCSRBAR_DEFAULT != CONFIG_SYS_CCSRBAR_PHYS)
> > +   {
> > +   volatile u32 *ccsr_virt =
> > +   (volatile u32 *)(CONFIG_SYS_CCSRBAR + 0x1000);
> 
> Please do not declare vaiables righjt in the middle of the code.
> Consider moving this code into a separate function instead.
>
OK.
 
> > diff --git a/cpu/mpc85xx/u-boot-nand.lds 
> b/cpu/mpc85xx/u-boot-nand.lds 
> > index c14e946..a0fc8f1 100644
> > --- a/cpu/mpc85xx/u-boot-nand.lds
> > +++ b/cpu/mpc85xx/u-boot-nand.lds
> > @@ -65,10 +65,8 @@ SECTIONS
> >  PROVIDE (etext = .);
> >  .rodata:
> > {
> > -*(.rodata)
> > -*(.rodata1)
> > -*(.rodata.str1.4)
> >  *(.eh_frame)
> > +*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))
> 
> Please rebase your patch against current code.
> 
OK.

> ...
> >  /*
> > + * Config the L2 Cache as L2 SRAM
> > + */
> > +#define CONFIG_SYS_INIT_L2_ADDR0xf8f8
> > +#ifdef CONFIG_PHYS_64BIT
> > +#define CONFIG_SYS_INIT_L2_ADDR_PHYS   0xff8f8ull
> > +#else
> > +#define CONFIG_SYS_INIT_L2_ADDR_PHYS   CONFIG_SYS_INIT_L2_ADDR
> > +#endif
> > +#define CONFIG_SYS_L2_SIZE (512 << 10)
> > +#define CONFIG_SYS_INIT_L2_END 
> (CONFIG_SYS_INIT_L2_ADDR + CONFIG_SYS_L2_SIZE)
> 
> Line too long, please fix globally.
OK.

> 
> > diff --git a/nand_spl/board/freescale/mpc8536ds/Makefile 
> > b/nand_spl/board/freescale/mpc8536ds/Makefile
> > new file mode 100644
> > index 000..c9104d3
> > --- /dev/null
> > +++ b/nand_spl/board/freescale/mpc8536ds/Makefile
> ...
> > +$(obj)tlb.c:
> > +   @rm -f $(obj)tlb.c
> > +   ln -sf $(SRCTREE)/cpu/mpc85xx/tlb.c $(obj)tlb.c
> > +
> > +$(obj)tlb_table.c:
> > +   @rm -f $(obj)tlb_table.c
> > +   ln -sf $(SRCTREE)/board/$(BOARDDIR)/tlb.c $(obj)tlb_table.c
> 
> Consider using the same file name here; it will simplify the 
> Makefile rules.
> 
> > +
> > +$(obj)law.c:
> > +   @rm -f $(obj)law.c
> > +   ln -sf $(SRCTREE)/drivers/misc/fsl_law.c $(obj)law.c
> 
> Ditto.
> 
> > +
> > +$(obj)law_table.c:
> > +   @rm -f $(obj)law_table.c
> > +   ln -sf $(SRCTREE)/board/$(BOARDDIR)/law.c $(obj)law_table.c
> 
> Ditto.
> 
> Please sort list.
> 
> And why do you need a separate rule everywhere? They look all 
> the same to me  (except for the inconsistent file names) ?
> 

Ok, I'll change it. But for some files, the name is same for different
files in the different
directory, for example,  cpu/mpc85xx/tlb.c and
board/freescale/mpc8536/tlb.c, so
I changed the linked name.

> > 
> > +   /* initialize selected port with appropriate baud rate */
> > +   sysclk_ratio = *((volatile unsigned char *)(PIXIS_BASE + 
> > +PIXIS_SPD));
> 
> Please use I/O accessors.
> 
Thanks, I've modified this, and prepared a new version patch.

> ...
> > +   NS16550_init((NS16550_t)(CONFIG_SYS_CCSRBAR + 0x4500),
> > +   bus_clk / 16 / CONFIG_BAUDRATE);
> 
> Smells like I/O accessors should be used here (and further 
> down below), too?
> 
Ditto.

Thanks,
Mingkai

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


Re: [U-Boot] [PATCH v3 1/3] NAND boot: MPC8536DS support

2009-09-22 Thread Hu Mingkai-B21284
 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Wednesday, September 23, 2009 5:11 AM
> To: Hu Mingkai-B21284
> Cc: u-boot@lists.denx.de; Wood Scott-B07421; ga...@kernel.crashing.org
> Subject: Re: [U-Boot] [PATCH v3 1/3] NAND boot: MPC8536DS support
> 
> > 
> > Change over v2:
> >  - Intergrated Kumar's comments.
> >  - Aligned to the leatest git tree
> 
> I am a bit surprised about your way to number patch versions ;-)
> 
> We had a "[PATCH v3 1/3] NAND boot: MPC8536DS support" on Sep 
> 18 already, and now again.
>

Actually this patch you replied is the patch sent on Sep 18 :-)
 
> But OK, the things I complained about for the old version are 
> still present, too.
>

The version you complained about is v2, it should be v3, and this
version v3 should be v4,
but I sent this version as v3, wanted to make it continuous with v2 and
didn't leave a sudden v4.

> Please fix - but then update the version, too, please.
> 
Ok, the next version should be v4, is that OK? :-)

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


Re: [U-Boot] [PATCH] OMAP3: Clean up whitespace in mux configs

2009-09-22 Thread Tom
Olof Johansson wrote:
> Switch from space-based indentation to tab-based in mux configs, as pointed
> out by WD at:
> 
> http://lists.denx.de/pipermail/u-boot/2009-September/061241.html
> 
> Nothing but whitespace changes in this patch (diff -w gives no output).
> 
> Signed-off-by: Olof Johansson 
> 
> ---
>  board/logicpd/zoom1/zoom1.h |  164 +-
>  board/logicpd/zoom2/zoom2.h |  188 +-
>  board/overo/overo.h |  644 +-
>  board/pandora/pandora.h |  662 +-
>  board/ti/beagle/beagle.h|  640 +-
>  board/ti/evm/evm.h  |  662 +-
>  board/timll/devkit8000/devkit8000.h |  628 +-
>  7 files changed, 1794 insertions(+), 1794 deletions(-)
> 

I have visually inspected zoom2.
It looks fine.

The other board maintainers should have a chance to review before it 
goes up the chain.

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


Re: [U-Boot] tftp packet failure counter reset

2009-09-22 Thread Ben Warren
Jeffery Palmer wrote:
> I do large transfers via tftp, and since the timeout counter never resets, 
> they often fail since the failures are counted throughout the entire 
> transfer. By resetting the counter to 0 on a successful packet, this issue is 
> fixed
>
>
>
> tftp.c:
> } else {
> if (((TftpBlock - 1) % 10) == 0) {
> putc ('#');
> } else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0) 
> {
> puts ("\n\t ");
> }
> +   //Reset timeout count since we received a good packet
> +   TftpTimeoutCount = 0;
> }
>
> if (TftpState == STATE_RRQ)
>   
Please send a proper patch in plaintext with all the right bits and pieces.

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


[U-Boot] tftp packet failure counter reset

2009-09-22 Thread Jeffery Palmer

I do large transfers via tftp, and since the timeout counter never resets, they 
often fail since the failures are counted throughout the entire transfer. By 
resetting the counter to 0 on a successful packet, this issue is fixed



tftp.c:
} else {
if (((TftpBlock - 1) % 10) == 0) {
putc ('#');
} else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0) {
puts ("\n\t ");
}
+   //Reset timeout count since we received a good packet
+   TftpTimeoutCount = 0;
}

if (TftpState == STATE_RRQ)
_
Hotmail: Free, trusted and rich email service.
http://clk.atdmt.com/GBL/go/171222984/direct/01/___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] ZOOM2 mux setup

2009-09-22 Thread Tom
Olof Johansson wrote:
> Hi,
> 
> I stumbled across this when fixing the whitespace in the mux setup tables
> for various omap platforms.
> 
> I don't find it to be a very sustainable way of adding random delays into
> the gpio setups. Having it open-coded in a C file is much preferred.
> 
> from boards/logicpd/zoom2/zoom2.h:
> 
> /* Toggle Reset pin of TL16CP754C device */\
> MUX_VAL(CP(MCBSP4_CLKX),(IEN  | PTU | EN  | M4)) /* GPIO_152 
> */\
>  udelay(10);\
> MUX_VAL(CP(MCBSP4_CLKX),(IEN  | PTD | EN  | M4)) /* GPIO_152 
> */\
> 
> Also, it seems like alot of the tables are really pretty common between
> boards. Maybe those should be extracted out to a separate base table,
> with additional per-board tables to be applied on top?
> 

GPIO toggling should really be done with gpio interface and not the mux
interface.

I will see about cleaning this up when I have time.

Tom

> 
> -Olof

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


[U-Boot] ZOOM2 mux setup

2009-09-22 Thread Olof Johansson
Hi,

I stumbled across this when fixing the whitespace in the mux setup tables
for various omap platforms.

I don't find it to be a very sustainable way of adding random delays into
the gpio setups. Having it open-coded in a C file is much preferred.

from boards/logicpd/zoom2/zoom2.h:

/* Toggle Reset pin of TL16CP754C device */\
MUX_VAL(CP(MCBSP4_CLKX),(IEN  | PTU | EN  | M4)) /* GPIO_152 */\
 udelay(10);\
MUX_VAL(CP(MCBSP4_CLKX),(IEN  | PTD | EN  | M4)) /* GPIO_152 */\

Also, it seems like alot of the tables are really pretty common between
boards. Maybe those should be extracted out to a separate base table,
with additional per-board tables to be applied on top?


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


Re: [U-Boot] [PATCH 6/7] ppc/p4080: Handle timebase enabling and frequency reporting

2009-09-22 Thread Wolfgang Denk
Dear Kumar Gala,

In message <1253307595-28655-7-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> On CoreNet style platforms the timebase frequency is the bus frequency
> defined by 16 (on PQ3 it is divide by 8).  Also on the CoreNet platforms
> the core not longer controls the enabling of the timebase.  We now need
> to enable the boot core's timebase via CCSR register writes.
> 
> Signed-off-by: Kumar Gala 
> ---
>  cpu/mpc85xx/cpu.c  |4 
>  cpu/mpc85xx/cpu_init.c |   12 
>  cpu/mpc85xx/fdt.c  |7 ++-
>  3 files changed, 22 insertions(+), 1 deletions(-)
> 
> diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
> index bdd9ee4..25c0416 100644
> --- a/cpu/mpc85xx/cpu.c
> +++ b/cpu/mpc85xx/cpu.c
> @@ -184,7 +184,11 @@ int do_reset (cmd_tbl_t *cmdtp, bd_t *bd, int flag, int 
> argc, char *argv[])
>   */
>  unsigned long get_tbclk (void)
>  {
> +#ifdef CONFIG_FSL_CORENET
> + return (gd->bus_clk + 8) / 16;
> +#else
>   return (gd->bus_clk + 4UL)/8UL;
> +#endif
>  }
>  
>  
> diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
> index a6d1e99..428b461 100644
> --- a/cpu/mpc85xx/cpu_init.c
> +++ b/cpu/mpc85xx/cpu_init.c
> @@ -229,6 +229,18 @@ void cpu_init_f (void)
>  #if defined(CONFIG_FSL_DMA)
>   dma_init();
>  #endif
> +#ifdef CONFIG_FSL_CORENET
> + {
> + volatile ccsr_rcpm_t *rcpm =
> + (void *)(CONFIG_SYS_FSL_CORENET_RCPM_ADDR);
> + volatile ccsr_pic_t *pic =
> + (void *)(CONFIG_SYS_MPC85xx_PIC_ADDR);
> + u32 whoami = in_be32(&pic->whoami);
> +
> + /* Enable the timebase register for this core */
> + out_be32(&rcpm->ctbenrl, (1 << whoami));
> + }
> +#endif
>  }

Please do not declare variables right in the middle of the code.
Consider moving this into a separate function if 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
In the future, you're going to get computers as prizes  in  breakfast
cereals.  You'll  throw  them out because your house will be littered
with them. - Robert Lucky
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 4/7] ppc/p4080: CoreNet platfrom style secondary core release

2009-09-22 Thread Wolfgang Denk
Dear Kumar Gala,

In message <1253307595-28655-5-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> The CoreNet platform style of bringing secondary cores out of reset is
> a bit different that the PQ3 style.  Mostly the registers that we use
> to setup boot translation, enable time bases, and boot release the cores
> have moved around.
> 
> Signed-off-by: Kumar Gala 
> ---
>  cpu/mpc85xx/mp.c |   68 
> +-
>  1 files changed, 67 insertions(+), 1 deletions(-)
> 
> diff --git a/cpu/mpc85xx/mp.c b/cpu/mpc85xx/mp.c
> index fa65bed..b474218 100644
> --- a/cpu/mpc85xx/mp.c
> +++ b/cpu/mpc85xx/mp.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "mp.h"
>  
>  DECLARE_GLOBAL_DATA_PTR;
> @@ -135,6 +136,66 @@ ulong get_spin_addr(void)
>   return addr;
>  }
>  
> +#ifdef CONFIG_FSL_CORENET
> +static void corenet_mp_up(unsigned long bootpg)
> +{
> + u32 up, cpu_up_mask, whoami;
> + u32 *table = (u32 *)get_spin_addr();
> + volatile ccsr_gur_t *gur;
> + volatile ccsr_local_t *ccm;
> + volatile ccsr_rcpm_t *rcpm;
> + volatile ccsr_pic_t *pic;
> + int timeout = 10;
> + u32 nr_cpus;
> + struct law_entry e;
> +
> + gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
> + ccm = (void *)(CONFIG_SYS_FSL_CORENET_CCM_ADDR);
> + rcpm = (void *)(CONFIG_SYS_FSL_CORENET_RCPM_ADDR);
> + pic = (void *)(CONFIG_SYS_MPC85xx_PIC_ADDR);
> +
> + nr_cpus = ((in_be32(&pic->frr) >> 8) & 0xff) + 1;
> +
> + whoami = in_be32(&pic->whoami);
> + cpu_up_mask = 1 << whoami;
> + out_be32(&ccm->bstrl, bootpg);
> +
> + e = find_law(bootpg);
> + out_be32(&ccm->bstrar, LAWAR_EN | e.trgt_id << 20 | LAWAR_SIZE_4K);
> +
> + /* disable time base at the platform */
> + out_be32(&rcpm->ctbenrl, cpu_up_mask);
> +
> + /* release the hounds */
> + up = ((1 << nr_cpus) - 1);
> + out_be32(&gur->brrl, up);
> +
> + /* wait for everyone */
> + while (timeout) {
> + int i;
> + for (i = 0; i < nr_cpus; i++) {
> + if (table[i * NUM_BOOT_ENTRY + BOOT_ENTRY_ADDR_LOWER])
> + cpu_up_mask |= (1 << i);
> + };
> +
> + if ((cpu_up_mask & up) == up)
> + break;
> +
> + udelay(100);
> + timeout--;
> + }
> +
> + if (timeout == 0)
> + printf("CPU up timeout. CPU up mask is %x should be %x\n",
> + cpu_up_mask, up);
> +
> + /* enable time base at the platform */
> + out_be32(&rcpm->ctbenrl, 0);
> + mtspr(SPRN_TBWU, 0);
> + mtspr(SPRN_TBWL, 0);
> + out_be32(&rcpm->ctbenrl, (1 << nr_cpus) - 1);
> +}
> +#else
>  static void pq3_mp_up(unsigned long bootpg)
>  {
>   u32 up, cpu_up_mask, whoami;
> @@ -196,6 +257,7 @@ static void pq3_mp_up(unsigned long bootpg)
>   devdisr &= ~(MPC85xx_DEVDISR_TB0 | MPC85xx_DEVDISR_TB1);
>   out_be32(&gur->devdisr, devdisr);
>  }
> +#endif

This is becoming a terrible mess of #ifdef's.  Would it not make sense
to move the new code into separate files?

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
"Pull the wool over your own eyes!"- J.R. "Bob" Dobbs
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/7] ppc/p4080: Add support for CoreNet style platform LAWs

2009-09-22 Thread Wolfgang Denk
Dear Kumar Gala,

In message <1253307595-28655-3-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> On CoreNet based platforms the LAW address is split between an high &
> low register and we no longer shift the address.  Also, the target IDs
> on CoreNet platforms have been completely re-assigned.
> 
> Additionally, added a new find_law() API to which LAW an address hits in.
> This is need for the CoreNet style boot release code since it will need
> to determine what the target ID should be set to for boot window
> translation.
> 
> Signed-off-by: Kumar Gala 
> ---
>  drivers/misc/fsl_law.c|   99 
> -
>  include/asm-ppc/fsl_law.h |   29 +
>  2 files changed, 127 insertions(+), 1 deletions(-)
> 
> diff --git a/drivers/misc/fsl_law.c b/drivers/misc/fsl_law.c
> index aa877c6..fba16ed 100644
> --- a/drivers/misc/fsl_law.c
> +++ b/drivers/misc/fsl_law.c
> @@ -1,5 +1,5 @@
>  /*
> - * Copyright 2008 Freescale Semiconductor, Inc.
> + * Copyright 2008-2009 Freescale Semiconductor, Inc.
>   *
>   * (C) Copyright 2000
>   * Wolfgang Denk, DENX Software Engineering, w...@denx.de.
> @@ -48,6 +48,24 @@ DECLARE_GLOBAL_DATA_PTR;
>  
>  void set_law(u8 idx, phys_addr_t addr, enum law_size sz, enum law_trgt_if id)
>  {
> +#ifdef CONFIG_FSL_CORENET
> + volatile ccsr_local_t *ccm;
> + volatile u32 *base, *lawbarh, *lawbarl, *lawar;
> +
> + ccm = (void *)(CONFIG_SYS_FSL_CORENET_CCM_ADDR);
> +
> + base = &(ccm->lawbarh0);
> + lawbarh = base + idx * 4;
> + lawbarl = lawbarh + 1;
> + lawar = lawbarl + 1;
> +
> + gd->used_laws |= (1 << idx);
> +
> + out_be32(lawar, 0);
> + out_be32(lawbarh, ((u64)addr >> 32));
> + out_be32(lawbarl, addr & 0x);
> + out_be32(lawar, LAWAR_EN | ((u32)id << 20) | (u32)sz);
> +#else
>   volatile u32 *base = (volatile u32 *)(CONFIG_SYS_IMMR + 0xc08);
>   volatile u32 *lawbar = base + 8 * idx;
>   volatile u32 *lawar = base + 8 * idx + 2;

This is ugly. Now we have code and variable declarations intermixed.
Please don't. Especially not when it's the same variables.

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
There comes to all races an ultimate crisis which  you  have  yet  to
face    One  day  our  minds became so powerful we dared think of
ourselves as gods.
-- Sargon, "Return to Tomorrow", stardate 4768.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Jean-Christian de Rivaz
Wolfgang Denk a écrit :
> Dear Olof Johansson,
> 
> In message <3c828e04-9cb1-4ccf-ad61-904f8956f...@gmail.com> you wrote:
>>> Linus does not S-o-b all patches that go into the Linux kernel, or
>>> does he?
>> He does.
> 
> No, he does not.

Maybe not so off-tropic, Linus have talked precisely about that today:

http://www.tuxradar.com/content/linuxcon-rountable-torvalds-quotes

On documentation:
“In the kernel we have this sign-off process, where patches as they flow 
through people are supposed to be signed off. And we had legal reasons 
for doing it initially, and the legal reasons have kind of gone away 
because nobody worries about SCO very much anymore. But it turns out 
it’s a really nice flow process, where people actually see how code came 
in, so it’s nice, and I’m seeing that in a number of non-kernel projects 
too. So I think there may not be a lot of documentation about how the 
kernel does it, but I think a lot of open source people do see the 
kernel model and it actually ends up being, the same way there’s this 
Unix mindset of how things are supposed to work, I think the kernel 
model has actually become this mindset of how open source projects are 
supposed to work, at least for a subset of projects out there.”


Best regards,

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


Re: [U-Boot] [PATCH 1/1] SPARC: fixes exported function stub for standalone applications.

2009-09-22 Thread Wolfgang Denk
Dear Daniel Hellstrom,

In message <1253270387-15741-1-git-send-email-dan...@gaisler.com> you wrote:
> Hello Wolfgang,
> 
> Please pull the u-boot-sparc.git master branch.
> 
> This patch fixes the SPARC support for standalone u-boot applications. 
> The problem was that I neve finished the implementation in the first
> place.
> 
> jmp ensures we get back to the location we came from, size(void *) make
> sure we get the function addresses correctly from the table (entry*4 
> instead of entry*1).

Um...
...
> 
> Signed-off-by: Daniel Hellstrom 
> ---
>  examples/standalone/stubs.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/examples/standalone/stubs.c b/examples/standalone/stubs.c
> index 339bbf9..ce3371d 100644
> --- a/examples/standalone/stubs.c
> +++ b/examples/standalone/stubs.c
> @@ -181,9 +181,9 @@ gd_t *global_data;
>  "or %%g1, %%g7, %%g1\n"  \
>  "ld [%%g1], %%g1\n"  \
>  "ld [%%g1 + %1], %%g1\n" \
> -"call %%g1\n"\
> +"jmp %%g1\n" \
>  "nop\n"  \
> - : : "i"(offsetof(gd_t, jt)), "i"(XF_ ## x) : "g1" );
> + : : "i"(offsetof(gd_t, jt)), "i"(XF_ ## x * sizeof(void *)) : "g1" );

This looks 100% like the patch submitted by Sergey Mironov on 16 Sep,
yet I see no Signed-off-by: line from him, nor any credit or
reference.

This can't be right?

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
"He was so narrow minded he could see through  a  keyhole  with  both
eyes ..."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning

2009-09-22 Thread Wolfgang Denk
Dear Guennadi Liakhovetski,

In message  you wrote:
> On Tue, 22 Sep 2009, Wolfgang Denk wrote:
> 
> > Dear Guennadi Liakhovetski,
> > 
> > In message  you wrote:
> > > 
> > > I have the hardware, yes, and I even have something, that should be a 
> > > Jtag 
> > > cable for it... But I don't have near 100% certainty, that if I brick it 
> > > I 
> > > will be able in reasonable time to recover it... But, hey, that's what I 
> > > have that hardware for... So, yes, I would be able to test, just not 
> > > immediately.
> > 
> > Do you think you can submit this patch before the end of the current
> > merge window? Otherwise I'd check in my previous clean up patch now,
> > and then wait for your rework in the next (?) version.
> 
> don't think so, very unlikely I'll have time for this in the next month.

OK, so please submit an incremental patch whenever you find time.

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
"An open mind has but one disadvantage: it collects dirt."
- a saying at RPI
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning

2009-09-22 Thread Wolfgang Denk

In message <1252967162-15935-1-git-send-email...@denx.de> you wrote:
> Fix warning: ide.c:60: warning: dereferencing type-punned pointer will
> break strict-aliasing rules
> 
> Signed-off-by: Wolfgang Denk 
> Cc: Guennadi Liakhovetski 
> 
> ---
> v2: Better implementation as suggested by Scott Wood in
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67840/focus=67891
> 
>  board/linkstation/ide.c |6 --
>  1 files changed, 4 insertions(+), 2 deletions(-)

Applied.

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
...computer hardware progress is so fast. No other  technology  since
civilization  began  has seen six orders of magnitude in performance-
price gain in 30 years. - Fred Brooks, Jr.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Olof Johansson

On Sep 22, 2009, at 4:49 PM, Wolfgang Denk wrote:

> Dear Olof Johansson,
>
> In message  you wrote:
>>
>>> No, please submit a new version which also incorporates the cleanup
>>> patches by Dirk.
>>
>> I didn't see those, since I wasn't cc:d.
>
> See the ML archive, then.

Yep, no problem.

>>> I will not pull the current version.
>>
>> So much for delegating maintainership. :)
>
> Heh. We just introduced these new custodians, _and_ I didn't find time
> for reviewing soon enough. That's just an unlucky coincidence.
>
> [Hm... not to mention that sometimes I do enjoy being able to have the
> last word.]
>
> [[Please don't tell my wife, though. :-) ]]

:-)   No worries.



-Olof


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


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Olof Johansson,

In message  you wrote:
> 
> > No, please submit a new version which also incorporates the cleanup
> > patches by Dirk.
> 
> I didn't see those, since I wasn't cc:d.

See the ML archive, then.

> > I will not pull the current version.
> 
> So much for delegating maintainership. :)

Heh. We just introduced these new custodians, _and_ I didn't find time
for reviewing soon enough. That's just an unlucky coincidence.

[Hm... not to mention that sometimes I do enjoy being able to have the
last word.]

[[Please don't tell my wife, though. :-) ]]

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 all is said and done, more is said than done.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Tom
Wolfgang Denk wrote:
> Dear Olof Johansson,
> 
> In message  you wrote:
>> Random question on u-boot development process: I see you didn't add  
>> your signed-off on the commit. People don't do that when they check in  
>> patches to the u-boot trees?
> 
> No, we don't do this if we check in an unchanged patch.
> 
> Linus does not S-o-b all patches that go into the Linux kernel, or
> does he?
> 

This cracks me up.
When is being a SOB ever good? :P

Tom


> 
> 
> Best regards,
> 
> Wolfgang Denk
> 

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


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Olof Johansson,

In message <00aa7a76-7fe3-440e-acbb-0d7fdcd4c...@gmail.com> you wrote:
> 
> On Sep 22, 2009, at 4:32 PM, Wolfgang Denk wrote:
> 
> > 56327c2a58b76291616f15c9c84a180cf7049645
> 
> committer Jaswinder Singh Rajput 
> Sun, 20 Sep 2009 10:32:20 + (15:32 +0530)
> 
> He didn't commit it.

So?

What is the difference between a "cd here ; git pull there" and a
"git format-patch" there followed by a "git am" here?

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 computer programmer is a creator of universes for which he alone
is responsible. Universes of virtually unlimited  complexity  can  be
created  in  the  form  of  computer  programs." - Joseph Weizenbaum,
_Computer Power and Human Reason_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Olof Johansson,

In message  you wrote:
> 
> I guess you don't see what the difference between applying a patch and  
> pulling a tree is.

Indeed I don't. Isn't pulling a tree the same as applying a number of
patches using soem highly efficient command?

> Anyway, it really doesn't matter much to me, it just confused me. It's  
> your project and you can do with it as you please, there's no use in  
> arguing over it. It just happens to be opposite to the principle of  
> another large project using similar signed-off methods.

Well, I'm willing to learn, but I'm an old man and a pighead at that.
I need good reason to change my mind, and so far I really see none.
If you could help this will be appreciated.


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
Leave bigotry in your quarters; there's no room for it on the bridge.
-- Kirk, "Balance of Terror", stardate 1709.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] ppc/85xx: Fix enabling of L2 cache

2009-09-22 Thread Kumar Gala
We need to flash invalidate the locks in addition to the cache
before we enable.

Signed-off-by: Kumar Gala 
---
 cpu/mpc85xx/cpu_init.c |4 ++--
 cpu/mpc85xx/release.S  |3 ++-
 2 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
index 428b461..726182f 100644
--- a/cpu/mpc85xx/cpu_init.c
+++ b/cpu/mpc85xx/cpu_init.c
@@ -348,8 +348,8 @@ int cpu_init_r(void)
u32 l2cfg0 = mfspr(SPRN_L2CFG0);
 
/* invalidate the L2 cache */
-   mtspr(SPRN_L2CSR0, L2CSR0_L2FI);
-   while (mfspr(SPRN_L2CSR0) & L2CSR0_L2FI)
+   mtspr(SPRN_L2CSR0, (L2CSR0_L2FI|L2CSR0_L2LFC));
+   while (mfspr(SPRN_L2CSR0) & (L2CSR0_L2FI|L2CSR0_L2LFC))
;
 
/* enable the cache */
diff --git a/cpu/mpc85xx/release.S b/cpu/mpc85xx/release.S
index 074b056..ecbd0d5 100644
--- a/cpu/mpc85xx/release.S
+++ b/cpu/mpc85xx/release.S
@@ -102,7 +102,8 @@ __secondary_start_page:
 #ifdef CONFIG_BACKSIDE_L2_CACHE
/* Enable/invalidate the L2 cache */
msync
-   lis r3,l2csr0_l...@h
+   lis r3,(L2CSR0_L2FI|L2CSR0_L2LFC)@h
+   ori r3,r3,(L2CSR0_L2FI|L2CSR0_L2LFC)@l
mtspr   SPRN_L2CSR0,r3
 1:
mfspr   r3,SPRN_L2CSR0
-- 
1.6.0.6

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


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Olof Johansson

On Sep 22, 2009, at 4:34 PM, Wolfgang Denk wrote:

> Dear Olof Johansson,
>
> In message <20090922203431.ga14...@lixom.net> you wrote:
>>
 + MUX_VAL(CP(GPMC_CLK),(IDIS | PTU | EN  | M0)) /*GPMC_CLK*/\
 + MUX_VAL(CP(GPMC_WAIT2),  (IEN  | PTU | EN  | M4)) /*GPIO_64*/\
 +   /* - SMSC911X_NRES*/\
 + MUX_VAL(CP(MCSPI1_CS2),  (IEN  | PTU | DIS | M4)) /*GPIO_176 */\
 +   /* - LAN_INTR */\
>>>
>>> Please use either no indentatioin at all, or indent by a multiple of
>>> TAB characters.
>>
>> So no aligning with spaces at the end of a run of tabs to make them  
>> line
>> up? Ok, if you prefer so.
>
> I was referring to the initial blank at the very beginning of the
> line.

Ah, crap. Thanks.

>
>>> Please do not use an C++ comments, and do not add dead code.
>>
>> What is the preferred way to show that the option is available but  
>> not enabled
>> by default?
>
> Use a C comment, if you must.
>
>> This patch has been applied and pulled though. I'll submit an  
>> incremental patch to address the above.
>
> No, please submit a new version which also incorporates the cleanup
> patches by Dirk.

I didn't see those, since I wasn't cc:d.

> I will not pull the current version.

So much for delegating maintainership. :)


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


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Olof Johansson,

In message <20090922203431.ga14...@lixom.net> you wrote:
> 
> > > + MUX_VAL(CP(GPMC_CLK),   (IDIS | PTU | EN  | M0)) /*GPMC_CLK*/\
> > > + MUX_VAL(CP(GPMC_WAIT2), (IEN  | PTU | EN  | M4)) /*GPIO_64*/\
> > > +  /* - SMSC911X_NRES*/\
> > > + MUX_VAL(CP(MCSPI1_CS2), (IEN  | PTU | DIS | M4)) /*GPIO_176 */\
> > > +  /* - LAN_INTR */\
> > 
> > Please use either no indentatioin at all, or indent by a multiple of
> > TAB characters.
> 
> So no aligning with spaces at the end of a run of tabs to make them line
> up? Ok, if you prefer so.

I was referring to the initial blank at the very beginning of the
line.

> > Please do not use an C++ comments, and do not add dead code.
> 
> What is the preferred way to show that the option is available but not enabled
> by default?

Use a C comment, if you must.

> This patch has been applied and pulled though. I'll submit an incremental 
> patch to address the above.

No, please submit a new version which also incorporates the cleanup
patches by Dirk.

I will not pull the current version.

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
That's their goal, remember, a goal that's really contrary to that of
the programmer or administrator. We just want to get our  jobs  done.
$Bill  just  wants  to  become  $$Bill. These aren't even marginallly
congruent.
 -- Tom Christiansen in <6jhtqk$ql...@csnews.cs.colorado.edu>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Olof Johansson

On Sep 22, 2009, at 4:32 PM, Wolfgang Denk wrote:

> 56327c2a58b76291616f15c9c84a180cf7049645

committer   Jaswinder Singh Rajput 
Sun, 20 Sep 2009 10:32:20 + (15:32 +0530)

He didn't commit it.


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


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Olof Johansson

On Sep 22, 2009, at 4:28 PM, Wolfgang Denk wrote:

> Dear Olof Johansson,
>
> In message  you wrote:
>>
>>> Please feel free to do that, but I consider this just adding
>>> line-noise, unless you _really_ express special approval.
>>>
>>> Which sense would it make if I added a s-o-b to each and every  
>>> commit
>>> I'm pulling in from anywhere?
>>
>> You're not pulling it, you are applying it. And the s-o-b is used to
>> show the paper trail of who has touched it. So all you should need to
>> backtrack the source of the code change is the list of the s-o-bs.
>
> What is the difference between a "git pull" from some remote repo
> and the "git am" of a patch posted on the mailing list? In both cases
> I do _not_ touch the patch, and the result looks the same, too.
>
>> S-o-b is not an approval of the technical merits of the change.  
>> It's a
>> pure bookkeeping measure to tell where a piece of code came from and
>> who handled it on the way.
>
> If the "handling" is just a technical operation which does not modify
> a single bit of the content I see no reason to add lines of s-o-b.
> Hey, I use several stages of repositories, and a number or branches
> here and there. Should I every time I pull from here or cherry-pick
> from there or format-patch + am somewhere else add a s-o-b? This makes
> zero sense to me.

I guess you don't see what the difference between applying a patch and  
pulling a tree is.

Anyway, it really doesn't matter much to me, it just confused me. It's  
your project and you can do with it as you please, there's no use in  
arguing over it. It just happens to be opposite to the principle of  
another large project using similar signed-off methods.

>> BUT in addition to this it's really useful for a newbie like me to  
>> see
>> who to send a patch to, since it shows the list of maintainership (up
>> to the first person that submits his work through git pulls, but that
>> seems nonexistent for non-maintainers in u-boot anyway :)
>
> Did you try looking at the list of custodians?
> http://www.denx.de/wiki/U-Boot/Custodians

I'm not saying there aren't other ways to do it, just that it's the  
one that made sense for me: Look at other files near where you are  
changing, and see the merge path.


-Olof

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


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Olof Johansson,

In message <3c828e04-9cb1-4ccf-ad61-904f8956f...@gmail.com> you wrote:
> 
> > Linus does not S-o-b all patches that go into the Linux kernel, or
> > does he?
> 
> He does.

No, he does not.

> For example, see 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e258b80e691f1f3ae83a60aa80eaf7322bd55ec4

See for example
5ac7687860dbfd3dd90e09d2c10dd31de91f20c2
a0f320f48799f67329fcb1b26ff0451c304e1dde
83ba7c34d2b82dc608647f629616df393ab883f9
97572751d78133cf9a5f7165b252bf975f9dd17d
067006a5f5b956fbdd183f9b799e7b8059b53f6c
b21495a03e20514eacd788a6b5d160667177cd94
56327c2a58b76291616f15c9c84a180cf7049645
6d6c971778c5257fc815e1ebe01779fefda6293c
98840f2ce5339d46e1830b0455360ad03a840d9d
39558c8f8e4c48805e702340e1610961d922268a
fcf989216138858003f0c354698260f29e6e10b0
144374dcc3ad0436f0a1bb3095836cf0ec32eebe
edf382bc6d4429d796fc3b26f7a33eaeca9db8ec
4765d681a4dccdc6ded7dd20329f5498aa53b0d0
5d3f33318a6c1f79f89e3dd2c7ddc11e0da14895
b0999cc55bd49e315ec82d2fb770a0d9ef7cbed8
7bd032dc2793afcbaf4a350056768da84cdbd89b
320348c8d5c9b591282633ddb8959b42f7fc7a1c
ff8324df1187b7280e507c976777df76c73a1ef1
74556123e034c8337b69a3ebac2f3a5fc0a97032
...

Let me know if you need more :-)

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 price of curiosity is a terminal experience.
 - Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Olof Johansson,

In message  you wrote:
> 
> > Please feel free to do that, but I consider this just adding
> > line-noise, unless you _really_ express special approval.
> >
> > Which sense would it make if I added a s-o-b to each and every commit
> > I'm pulling in from anywhere?
> 
> You're not pulling it, you are applying it. And the s-o-b is used to  
> show the paper trail of who has touched it. So all you should need to  
> backtrack the source of the code change is the list of the s-o-bs.

What is the difference between a "git pull" from some remote repo
and the "git am" of a patch posted on the mailing list? In both cases
I do _not_ touch the patch, and the result looks the same, too.

> S-o-b is not an approval of the technical merits of the change. It's a  
> pure bookkeeping measure to tell where a piece of code came from and  
> who handled it on the way.

If the "handling" is just a technical operation which does not modify
a single bit of the content I see no reason to add lines of s-o-b.
Hey, I use several stages of repositories, and a number or branches
here and there. Should I every time I pull from here or cherry-pick
from there or format-patch + am somewhere else add a s-o-b? This makes
zero sense to me.

> BUT in addition to this it's really useful for a newbie like me to see  
> who to send a patch to, since it shows the list of maintainership (up  
> to the first person that submits his work through git pulls, but that  
> seems nonexistent for non-maintainers in u-boot anyway :)

Did you try looking at the list of custodians? 
http://www.denx.de/wiki/U-Boot/Custodians

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It usually takes more than three weeks to prepare  a  good  impromptu
speech.  - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] mtd: SPI Flash: Winbond W25X16/WX2532/WX2564 support

2009-09-22 Thread Mike Frysinger
On Thursday 02 April 2009 06:54:59 Mike Frysinger wrote:
> On Thursday 11 December 2008 16:16:29 Mike Frysinger wrote:
> > On Wednesday 09 July 2008 18:37:06 Wolfgang Denk wrote:
> > > In message Jason McMullan wrote:
> > > > Add support for the Winbond W25X16/32/64 series of
> > > > SPI Flash devices.
> > >
> > > Signed-off-by line is missing.
> > >
> > > > --- /dev/null
> > > > +++ b/drivers/mtd/spi/winbond.c
> > > > @@ -0,0 +1,331 @@
> > > > +/*
> > > > + * Copyright 2008, Network Appliance Inc.
> > > > + * Author: Jason McMullan 
> > > > + *
> > > > + */
> > >
> > > GPL header is missing.
> > >
> > >
> > > Please fix and resubmit.
> >
> > Jason: could you fix these two minor issues so we can get this in ? :)
> 
> pretty pretty please ?  ive merged and been maintaining this in the
>  Blackfin git repo because we have some winbond parts, but it'd be nice to
>  get this into mainline.  i cant push it without your sign off :(.

not sure if doing a routine 6-month ping is getting us anywhere.  does anybody 
know people at netapp.com who can get this moving ?
-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] smc91111_eeprom: get working with net multi conversion

2009-09-22 Thread Mike Frysinger
On Tuesday 22 September 2009 16:49:06 Ben Warren wrote:
> Wolfgang Denk wrote:
> > Mike Frysinger wrote:
> >> This should be squashed into the pending:
> >>Convert SMC9 Ethernet driver to CONFIG_NET_MULTI API
> >>
> >> The changes to the eeprom were incomplete, and the new version needs
> >> slightly different handling on the BF533 boards that share flash.
> >>
> >> Signed-off-by: Mike Frysinger 
> >
> > Then better send a v2 patch which includes this stuff.
> 
> I think he was commenting that my SMC9 patch was incomplete and this
> fixes it, but may be wrong (it happens from time to time :).

yes, the original patch is Ben's and in Ben's tree, not mine
-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] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Olof Johansson

On Sep 22, 2009, at 2:50 PM, Wolfgang Denk wrote:

> Dear Ben Warren,
>
> In message  > you wrote:
>>
>>> I always use 'git am -s', which adds the SOB.   My understanding  
>>> is that
>> maintainers should do this as an indication of approval and help in
>> traceability.
>
> Please feel free to do that, but I consider this just adding
> line-noise, unless you _really_ express special approval.
>
> Which sense would it make if I added a s-o-b to each and every commit
> I'm pulling in from anywhere?

You're not pulling it, you are applying it. And the s-o-b is used to  
show the paper trail of who has touched it. So all you should need to  
backtrack the source of the code change is the list of the s-o-bs.

S-o-b is not an approval of the technical merits of the change. It's a  
pure bookkeeping measure to tell where a piece of code came from and  
who handled it on the way.

BUT in addition to this it's really useful for a newbie like me to see  
who to send a patch to, since it shows the list of maintainership (up  
to the first person that submits his work through git pulls, but that  
seems nonexistent for non-maintainers in u-boot anyway :)


-Olof

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


Re: [U-Boot] [PATCH v3 1/3] NAND boot: MPC8536DS support

2009-09-22 Thread Wolfgang Denk
Dear Mingkai Hu,

In message <1253244935-1555-1-git-send-email-mingkai...@freescale.com> you 
wrote:
> MPC8536E can support booting from NAND flash which uses the
> image u-boot-nand.bin. This image contains two parts: a 4K
> NAND loader and a main U-Boot image. The former is appended
> to the latter to produce u-boot-nand.bin. The 4K NAND loader
> includes the corresponding nand_spl directory, along with the
> code twisted by CONFIG_NAND_SPL. The main U-Boot image just
> like a general U-Boot image except the parts that included by
> CONFIG_SYS_RAMBOOT.
> 
> When power on, eLBC will automatically load from bank 0 the
> 4K NAND loader into the FCM buffer RAM where CPU can execute
> the boot code directly. In the first stage, the NAND loader
> copies itself to RAM or L2SRAM to free up the FCM buffer RAM,
> then loads the main image from NAND flash to RAM or L2SRAM
> and boot from it.
> 
> This patch implements the NAND loader to load the main image
> into L2SRAM, so the main image can configure the RAM by using
> SPD EEPROM. In the first stage, the NAND loader copies itself
> to the second to last 4K address space, and uses the last 4K
> address space as the initial RAM for stack.
> 
> Obviously, the size of L2SRAM shouldn't be less than the size
> of the image used. If so, the workaround is to generate another
> image that includes the code to configure the RAM by SPD and
> load it to L2SRAM first, then relocate the main image to RAM
> to boot up.
> 
> Signed-off-by: Mingkai Hu 
> ---
> 
> Change over v2:
>  - Intergrated Kumar's comments.
>  - Aligned to the leatest git tree

I am a bit surprised about your way to number patch versions ;-)

We had a "[PATCH v3 1/3] NAND boot: MPC8536DS support" on Sep 18
already, and now again.

But OK, the things I complained about for the old version are still
present, too.

Please fix - but then update the version, too, please.

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
Without freedom of choice there is no creativity.
-- Kirk, "The return of the Archons", stardate 3157.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2] ppc: Clean up calling of phy_reset() during init

2009-09-22 Thread Wolfgang Denk
Dear Peter Tyser,

In message <1253156588-8686-2-git-send-email-pty...@xes-inc.com> you wrote:
> Remove board-specific #ifdefs for calling phy_reset() during
> initializtion
> 
> Signed-off-by: Peter Tyser 
> ---
>  include/configs/CCM.h|1 +
>  include/configs/ELPT860.h|1 +
>  include/configs/IP860.h  |1 +
>  include/configs/IVML24.h |2 ++
>  include/configs/IVMS8.h  |2 ++
>  include/configs/MPC8260ADS.h |1 +
>  include/configs/MPC8266ADS.h |1 +
>  include/configs/MPC8560ADS.h |1 +
>  include/configs/RPXsuper.h   |1 +
>  include/configs/SBC8540.h|1 +
>  include/configs/SPD823TS.h   |2 ++
>  include/configs/pcu_e.h  |1 +
>  include/configs/sbc8560.h|1 +
>  include/configs/stxgp3.h |1 +
>  lib_ppc/board.c  |   17 +
>  15 files changed, 18 insertions(+), 16 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
"It takes all sorts of in & out-door schooling to get adapted  to  my
kind of fooling"   - R. Frost
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/2] ppc: Clean up calling of misc_init_r() during init

2009-09-22 Thread Wolfgang Denk
Dear Peter Tyser,

In message <1253156588-8686-1-git-send-email-pty...@xes-inc.com> you wrote:
> Remove board-specific #ifdefs for calling misc_init_r() during
> initializtion
> 
> Signed-off-by: Peter Tyser 
> ---
>  include/configs/CCM.h|1 +
>  include/configs/CPCI405.h|1 +
>  include/configs/CPCI4052.h   |1 +
>  include/configs/CPCI405AB.h  |1 +
>  include/configs/CPCI405DT.h  |1 +
>  include/configs/W7OLMC.h |1 +
>  include/configs/W7OLMG.h |1 +
>  include/configs/cogent_mpc8260.h |1 +
>  include/configs/cogent_mpc8xx.h  |1 +
>  include/configs/lwmon.h  |5 +++--
>  include/configs/pcu_e.h  |2 ++
>  include/configs/sc3.h|1 +
>  lib_ppc/board.c  |   12 +---
>  13 files changed, 16 insertions(+), 13 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
THIS IS A 100% MATTER  PRODUCT:  In  the  Unlikely  Event  That  This
Merchandise  Should  Contact  Antimatter  in Any Form, a Catastrophic
Explosion Will Result.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] Remove deprecated 'autoscr' command/variables

2009-09-22 Thread Wolfgang Denk
Dear Peter Tyser,

In message <1253155091-6576-1-git-send-email-pty...@xes-inc.com> you wrote:
> The more standard 'source' command provides identical functionality to
> the autoscr command.
> 
> Environment variable names/values on the MVBC_P, MVBML7, kmeter1,
> mgcoge, and km8xx boards are updated to no longer refernce 'autoscr'.
> 
> The 'autoscript' and 'autoscript_uname' environment variables are
> also removed.
> 
> Signed-off-by: Peter Tyser 
> ---
> Changes since v1:
> - Removed all references to autoscript and autoscript_uname, previously
>   just the autoscr command was removed.
> 
>  README   |8 
>  board/LEOX/elpt860/README.LEOX   |2 +-
>  board/matrix_vision/mvbc_p/mvbc_p_autoscript |4 ++--
>  board/matrix_vision/mvblm7/mvblm7_autoscript |4 ++--
>  board/musenki/README |2 +-
>  board/pn62/cmd_pn62.c|   18 --
>  common/cmd_load.c|   18 --
>  common/cmd_net.c |   15 ---
>  common/cmd_source.c  |   18 --
>  doc/README.IPHASE4539|2 +-
>  doc/README.m52277evb |2 +-
>  doc/README.m5373evb  |2 +-
>  doc/README.m54455evb |2 +-
>  doc/README.m5475evb  |2 +-
>  doc/feature-removal-schedule.txt |   19 ---
>  include/configs/MVBC_P.h |   14 +++---
>  include/configs/MVBLM7.h |   14 +++---
>  include/configs/keymile-common.h |6 +++---
>  18 files changed, 28 insertions(+), 124 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
Hi there! This is just a note from me, to you, to tell you, the  per-
son  reading this note, that I can't think up any more famous quotes,
jokes, nor bizarre stories, so you may as well go home.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 1/3] fsl_i2c: Wait for STOP condition to propagate

2009-09-22 Thread Wolfgang Denk
Dear Joakim Tjernlund,

In message <1253178437-32398-1-git-send-email-joakim.tjernl...@transmode.se> 
you wrote:
> After issuing a STOP one must wait until the STOP has completed
> on the bus before doing something new to the controller.
> 
> Also add an extra read of SR as the manual mentions doing that
> is a good idea.
> 
> Remove surplus write of CR just before a write, isn't required and
> could potentially disturb the I2C bus.
> 
> Signed-off-by: Joakim Tjernlund 
> ---
>  drivers/i2c/fsl_i2c.c |   12 
>  1 files changed, 8 insertions(+), 4 deletions(-)

Could you _please_ start adding some version information to your
patches, and a list of changes between the versions?

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
Crash programs fail because they are based on the theory  that,  with
nine women pregnant, you can get a baby a month.  - Wernher von Braun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] smc91111_eeprom: get working with net multi conversion

2009-09-22 Thread Ben Warren
Wolfgang Denk wrote:
> Dear Mike Frysinger,
>
> In message <1253068647-29134-1-git-send-email-vap...@gentoo.org> you wrote:
>   
>> This should be squashed into the pending:
>>  Convert SMC9 Ethernet driver to CONFIG_NET_MULTI API
>>
>> The changes to the eeprom were incomplete, and the new version needs
>> slightly different handling on the BF533 boards that share flash.
>>
>> Signed-off-by: Mike Frysinger 
>> 
>
> Then better send a v2 patch which includes this stuff.
>
>   
I think he was commenting that my SMC9 patch was incomplete and this 
fixes it, but may be wrong (it happens from time to time :).

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


Re: [U-Boot] [PATCH] SPARC standalone app fix

2009-09-22 Thread Wolfgang Denk
Dear Daniel Hellstrom,

In message <4ab35893.4000...@gaisler.com> you wrote:
> 
> Thank you for your work. I have updated the sparc repository with your
> patch. And, yes, you are probably the first one to use the standalone
> app feature :)

Um... Please put this patch on hold. 

We need Sergey's Signed-off-by: line first!

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
panic: kernel trap (ignored)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] mpc512x. Micron nand flash needs a reset before a read command is issued

2009-09-22 Thread Wolfgang Denk
Dear Paul Gibson,

In message <26b052040909152126q55945d47yad3bcf90334ac...@mail.gmail.com> you 
wrote:
> Micron nand flash needs a reset before a read command is issued.
> The current mpc5121_nfc driver ignores the reset command.
> 
> Signed-off-by: Paul Gibson 
> 
> ---
>  drivers/mtd/nand/mpc5121_nfc.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Why did you resend this? I don't notice any changes, there is not "v2"
indication or comments aboyt changes either. So what am I supposed to
do with that?

And the patch is line-wrapped like the first posting. Please *fix*
that.

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
America has been discovered before, but it has always been hushed up.
- Oscar Wilde
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning

2009-09-22 Thread Guennadi Liakhovetski
On Tue, 22 Sep 2009, Wolfgang Denk wrote:

> Dear Guennadi Liakhovetski,
> 
> In message  you wrote:
> > 
> > I have the hardware, yes, and I even have something, that should be a Jtag 
> > cable for it... But I don't have near 100% certainty, that if I brick it I 
> > will be able in reasonable time to recover it... But, hey, that's what I 
> > have that hardware for... So, yes, I would be able to test, just not 
> > immediately.
> 
> Do you think you can submit this patch before the end of the current
> merge window? Otherwise I'd check in my previous clean up patch now,
> and then wait for your rework in the next (?) version.

don't think so, very unlikely I'll have time for this in the next month.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] smc91111_eeprom: get working with net multi conversion

2009-09-22 Thread Wolfgang Denk
Dear Mike Frysinger,

In message <1253068647-29134-1-git-send-email-vap...@gentoo.org> you wrote:
> This should be squashed into the pending:
>   Convert SMC9 Ethernet driver to CONFIG_NET_MULTI API
> 
> The changes to the eeprom were incomplete, and the new version needs
> slightly different handling on the BF533 boards that share flash.
> 
> Signed-off-by: Mike Frysinger 

Then better send a v2 patch which includes this stuff.

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
You can love it, change it, or leave it.There is NO other option.
But do not complain - it is your own choice...  -- wd
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] mpc512x. Micron nand flash needs a reset before a read command is issued.

2009-09-22 Thread Wolfgang Denk
Dear Paul Gibson,

In message <26b052040909151705r35cdb874gbbe5a184d20e4...@mail.gmail.com> you 
wrote:
> Micron nand flash needs a reset before a read command is issued.
> The current mpc5121_nfc driver ignores the reset command.
> 
> ---
>  drivers/mtd/nand/mpc5121_nfc.c |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)

Applied, after fixing the line wrapping added by your mailer.

Please use "git send-email" to submit patches, which avoid this (and
other) problem(s).

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
Hegel was right when he said that we learn from history that man  can
never learn anything from history.  - George Bernard Shaw
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] env: only build env_embedded and envcrc when needed

2009-09-22 Thread Wolfgang Denk
Dear Mike Frysinger,

In message <200909151739.11704.vap...@gentoo.org> you wrote:
>
> > > i saw it as "custom embedding of the environment".  the only thing it
> > > does is enable the envcrc binary.  i thought of using "CONFIG_ENVCRC",
> > > but it seemed a little too short.
> > 
> > CONFIG_ENABLE_ENVCRC ?   CONFIG_BUILD_ENVCRC ?
>
> the name doesnt really matter to me.  if you're fine with 
> CONFIG_BUILD_ENVCRC, 
> i'll use that in common code and keep the CONFIG_ENV_IS_EMBEDDED_CUSTOM in 
> the 
> Blackfin specific code.

CONFIG_BUILD_ENVCRC is fine with me (and I'd rather see if you got rid
of this unwieldy CONFIG_ENV_IS_EMBEDDED_CUSTOM thingy).

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
Leave bigotry in your quarters; there's no room for it on the bridge.
-- Kirk, "Balance of Terror", stardate 1709.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 2/2 v2] Blackfin: tweak embedded env config option

2009-09-22 Thread Wolfgang Denk
Dear Mike Frysinger,

In message <200909151736.52720.vap...@gentoo.org> you wrote:
>
> > ...
> > >  $(obj)u-boot.ldr:$(obj)u-boot
> > > - $(obj)tools/envcrc --binary > $(obj)env-ldr.o
> > > + $(CREATE_LDR_ENV)
> > >   $(LDR) -T $(CONFIG_BFIN_CPU) -c $@ $< $(LDR_FLAGS)
> > 
> > This is all BF specific stuff, right? Maybe we should move this into
> > some BF Makefile, then, instead of adding more and more references to
> > magic variables that have no meaning anywhere except for BF.
>
> if you're talking about the %.ldr target, then yes, it is only for Blackfin 
> systems.  it isnt the only target-specific top level which is why it's there 
> now, but that doesnt mean it has to stay there (as well as the other cruft).  
> ive already looked at moving this to the Blackfin specific config.mk, but it 
> would require adding dummy "all" targets early on in the top level Makefile 
> and one or two subdir Makefiles.  i didnt feel like dealing with people 
> complaining about this.  although if we created a new lib_$(ARCH)/targets.mk, 
> we could push all arch-specific crap there (like all the boards config 
> targets), and only the top level Makefile would include it.

I'm not asking for a general Makefile rework. But maybe we can move
this code to some BF Makefile?

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 child is a person who can't understand why someone would give away
a perfectly good kitten."   - Doug Larson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCHv5 2/2] mucmc52, uc101: delete a...@3a00 node, if no CF card is detected

2009-09-22 Thread Wolfgang Denk
Dear Heiko Schocher,

In message <4aaf1fe4.9050...@denx.de> you wrote:
> U-Boot can detect if an IDE device is present or not.
> If not, and this new config option is activated, U-Boot
> removes the ATA node from the DTS before booting Linux,
> so the Linux IDE driver does not probe the device and
> crash. This is needed for buggy hardware (uc101) where
> no pull down resistor is connected to the signal IDE5V_DD7.
> 
> Signed-off-by: Heiko Schocher 

Seems this patch depends on other patches, that add support for the
manroland boards, which have not been accepted yet. I think I'm
waiting for a resubmit from you?

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
ATTENTION: Despite Any Other Listing of Product Contents Found  Here-
on, the Consumer is Advised That, in Actuality, This Product Consists
Of 99.99% Empty Space.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx51:Add support basic boot code of freescale imx51 bbg board

2009-09-22 Thread Fred Fan
HI Magnus Lilja:
 Best Regards
Fred

2009/9/23, Magnus Lilja :
>
>
> Hmm, for some reason "Reply" in gmail cut part of the qouted message so
> here's the rest of the followup.
>
> Fred Fan skrev:
> > Hi Magnus Liljia:
> > Thanks for your comments.
> >  Best Regards
> > Fred
> >
> > 2009/9/22, Magnus Lilja :
> >
> >> Hi
> >>
> >>
> >> I've scanned the patch briefly and have some comments below.
> >>
> >> gareat...@gmail.com wrote:
> >> I don't think everything in this file is needed by U-Boot, e.g. the
> >> interrupt definitions.
> >> Yes. But interrupt maybe use when interrupt is supportted. Do I need
> remove
> >> the definitions which are not used?
>
> Don't know.
> We have plan to support interrupt in furture.

>>> diff --git a/include/configs/imx51.h b/include/configs/imx51.h
> >>> new file mode 100644
> >>> index 000..f0def4e
> >>> --- /dev/null
> >>> +++ b/include/configs/imx51.h
> >>> @@ -0,0 +1,177 @@
> >>> +/*
> >>> + * Copyright (C) 2007, Guennadi Liakhovetski 
> >>> + *
> >>> + * (C) Copyright 2009 Freescale Semiconductor, Inc.
> >>> + *
> >>> + * Configuration settings for the MX51-3Stack Freescale board.
> >>> + *
> >>> + * 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
> >>> + */
> >>> +
> >>> +#ifndef __CONFIG_H
> >>> +#define __CONFIG_H
> >>> +
> >>> +#include 
> >>> +
> >>> + /* High Level Configuration Options */
> >>> +#define CONFIG_ARMV7 1   /* This is armv7 Cortex-A8 CPU
> core
> >> */
> >>> +#define CONFIG_L2_OFF
> >>> +
> >>> +#define CONFIG_MXC   1
> >>> +#define CONFIG_MX51_BBG  1   /* in a mx51 */
> >> Can't see that this is used anywhere.
> >> OK. I will remove them;
>
> Only remove MX51_BBG, I didn't check if CONFIG_MXC is used anywhere.
> OK.
>
> Regards, Magnus
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx51:Add support basic boot code of freescale imx51 bbg board

2009-09-22 Thread Fred Fan
HI Magnus Lilja:
Best Regards
Fred


2009/9/23, Magnus Lilja :
>
> Hi
>
> 2009/9/22 Fred Fan :
> > Hi Magnus Liljia:
> > Thanks for your comments.
> >  Best Regards
> > Fred
> >
> > 2009/9/22, Magnus Lilja :
> >>
> >> Hi
> >>
> >>
> >> I've scanned the patch briefly and have some comments below.
> >>
> >> gareat...@gmail.com wrote:
> >> > diff --git a/MAKEALL b/MAKEALL
> >> > index edebaea..ed8c437 100755
> >> > --- a/MAKEALL
> >> > +++ b/MAKEALL
> >> 
> >
> >
> > Does means use new board name?
>
> Heh, no.  just means that I've removed parts of your patch
> (those parts which I don't have any comments on). Sorry for the
> confusion.
> OK
> >> > +++ b/board/freescale/imx51/Makefile
> >> 
> >> Does means use new board name?
>
> The board name should be used instead of the imx51 name.

OK

>> > + mxc_request_iomux(MX51_PIN_UART1_RXD, IOMUX_CONFIG_ALT0);
> >> > + mxc_iomux_set_pad(MX51_PIN_UART1_RXD, pad | PAD_CTL_SRE_FAST);
> >> > + mxc_request_iomux(MX51_PIN_UART1_TXD, IOMUX_CONFIG_ALT0);
> >> > + mxc_iomux_set_pad(MX51_PIN_UART1_TXD, pad | PAD_CTL_SRE_FAST);
> >> > + mxc_request_iomux(MX51_PIN_UART1_RTS, IOMUX_CONFIG_ALT0);
> >> > + mxc_iomux_set_pad(MX51_PIN_UART1_RTS, pad);
> >> > + mxc_request_iomux(MX51_PIN_UART1_CTS, IOMUX_CONFIG_ALT0);
> >> > + mxc_iomux_set_pad(MX51_PIN_UART1_CTS, pad);
> >> > +}
> >> > +
> >> > +void setup_nfc(void)
> >> > +{
> >> > + /* Enable NFC IOMUX */
> >> > + mxc_request_iomux(MX51_PIN_NANDF_CS0, IOMUX_CONFIG_ALT0);
> >> > + mxc_request_iomux(MX51_PIN_NANDF_CS1, IOMUX_CONFIG_ALT0);
> >> > + mxc_request_iomux(MX51_PIN_NANDF_CS2, IOMUX_CONFIG_ALT0);
> >> > + mxc_request_iomux(MX51_PIN_NANDF_CS3, IOMUX_CONFIG_ALT0);
> >> > + mxc_request_iomux(MX51_PIN_NANDF_CS4, IOMUX_CONFIG_ALT0);
> >> > + mxc_request_iomux(MX51_PIN_NANDF_CS5, IOMUX_CONFIG_ALT0);
> >> > + mxc_request_iomux(MX51_PIN_NANDF_CS6, IOMUX_CONFIG_ALT0);
> >> > + mxc_request_iomux(MX51_PIN_NANDF_CS7, IOMUX_CONFIG_ALT0);
> >> > +}
> >>
> >> Since it's very likely that setup_nfc() and setup_uart() will be used in
> >> other i.MX51 boards as well it's a good idea to
> >> place these functions in cpu/arm_cortexa8/mx51/devices.c (or something
> >> similar).
> >> I think it should be board level. Some board based on i.MX51 maybe has
> >> differenent choice.
>
> That can  be handed with #ifdef's just like in the i.MX31 case.



> If we do like i.MX31, the code in soc level has the details of board level.

   we should reduce the block of #ifdef.

> <...>
> >> > +#define MXC_SRPGC_EMI_SRPGCR (MXC_SRPGC_EMI_BASE + 0x0)
> >> > +#define MXC_SRPGC_EMI_PUPSCR (MXC_SRPGC_EMI_BASE + 0x4)
> >> > +#define MXC_SRPGC_EMI_PDNSCR (MXC_SRPGC_EMI_BASE + 0x8)
> >> > +
> >>
> >> Are all of the above #defines needed/expected to be needed by U-boot?
> >
> >   No. It just copy from linux kernel code. Does need remove them?
>
> Don't no what the policy is.


we prefer to keep the sync with the file in kernel source code.

>> > diff --git a/cpu/arm_cortexa8/mx51/interrupts.c
> >> > b/cpu/arm_cortexa8/mx51/interrupts.c
> >> > new file mode 100644
> >> > index 000..c0d70ac
> >> > --- /dev/null
> >> > +++ b/cpu/arm_cortexa8/mx51/interrupts.c
> >> 
> >> What's means?
>
> Ignore the  comments.
>
> >> > diff --git a/cpu/arm_cortexa8/mx51/serial.c
> >> > b/cpu/arm_cortexa8/mx51/serial.c
> >> > new file mode 100644
> >> > index 000..580ac13
> >> > --- /dev/null
> >> > +++ b/cpu/arm_cortexa8/mx51/serial.c
> >>
> >> I haven't looked in the details of the serial driver, but would it be
> >> possible to use drivers/serial/serial_mxc.c
> >> instead? It looks very similar.
> >> I don't like the implement of this driver. It contains the chip details
> in
> >> driver code.
> >>
> >> But I will do what as your said. And restructure this driver in another
> >> patch.
>
> That sounds like a good idea if you want to improve the serial driver.
> Create a separate standalone patch so people can review and test that.
>
> Regards, Magnus
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] board/linkstation/ide.c: Fix compile warning

2009-09-22 Thread Wolfgang Denk
Dear Guennadi Liakhovetski,

In message  you wrote:
> 
> I have the hardware, yes, and I even have something, that should be a Jtag 
> cable for it... But I don't have near 100% certainty, that if I brick it I 
> will be able in reasonable time to recover it... But, hey, that's what I 
> have that hardware for... So, yes, I would be able to test, just not 
> immediately.

Do you think you can submit this patch before the end of the current
merge window? Otherwise I'd check in my previous clean up patch now,
and then wait for your rework in the next (?) version.

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 modem is a baudy house.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: DaVinci DM365: Enabling net support on DM365

2009-09-22 Thread Wolfgang Denk
Dear "Paulraj, Sandeep",

In message <0554bef07d437848af01b9c9b5f0bc5d929e5...@dlee01.ent.ti.com> you 
wrote:
> 
> 
> > From: Sandeep Paulraj 
> > 
> > This patch enables EMAC on the DM365 EVM.
> > 
> > Signed-off-by: Sandeep Paulraj 
> > ---
> >  board/davinci/dm365evm/dm365evm.c |   38
> > +
> >  1 files changed, 38 insertions(+), 0 deletions(-)
> > 
> 
> Pushed to u-boot-ti

Please undo. We want to enable the compiler for strict type checkings
for all accesses to hardware registers, which is impossible with the
use of plain address constants in this code.

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
Whom the gods would destroy, they first teach BASIC.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: DaVinci DM365: Enabling net support on DM365

2009-09-22 Thread Wolfgang Denk
Dear s-paul...@ti.com,

In message <1252955798-31840-1-git-send-email-s-paul...@ti.com> you wrote:
> From: Sandeep Paulraj 
> 
> This patch enables EMAC on the DM365 EVM.
> 
> Signed-off-by: Sandeep Paulraj 
> ---
>  board/davinci/dm365evm/dm365evm.c |   38 
> +
>  1 files changed, 38 insertions(+), 0 deletions(-)
...
> + /* Configure PINMUX 3 to enable EMAC pins */
> + writel((readl(PINMUX3) | 0x1a), PINMUX3);
> +
> + /* Configure GPIO20 as output */
> + writel((readl(GIO_DIR01) & 0xffef), GIO_DIR01);

Please use C structs to dsescribe the register layout. Do not use
typeless addresses.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
To know how another being, another creature feels -  that  is  impos-
sible.  - Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Olof Johansson
On Tue, Sep 22, 2009 at 09:41:42PM +0200, Wolfgang Denk wrote:

> Please use "git format-patch" / "git send-email" to create and submit
> patches. For example, it is always nice to see a file statistics in
> the patch.

k.

> > + MUX_VAL(CP(GPMC_CLK), (IDIS | PTU | EN  | M0)) /*GPMC_CLK*/\
> > + MUX_VAL(CP(GPMC_WAIT2),   (IEN  | PTU | EN  | M4)) /*GPIO_64*/\
> > +/* - SMSC911X_NRES*/\
> > + MUX_VAL(CP(MCSPI1_CS2),   (IEN  | PTU | DIS | M4)) /*GPIO_176 */\
> > +/* - LAN_INTR */\
> 
> Please use either no indentatioin at all, or indent by a multiple of
> TAB characters.

So no aligning with spaces at the end of a run of tabs to make them line
up? Ok, if you prefer so.

> > diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
> > index 07a031b..6616b55 100644
> > --- a/include/configs/omap3_overo.h
> > +++ b/include/configs/omap3_overo.h
> > @@ -28,7 +28,8 @@
> >  #define CONFIG_OMAP1   /* in a TI OMAP core */
> >  #define CONFIG_OMAP34XX1   /* which is a 34XX */
> >  #define CONFIG_OMAP34301   /* which is in a 3430 */
> > -#define CONFIG_OMAP3_OVERO 1   /* working with overo */
> > +#define CONFIG_OMAP3_OVERO 1   /* working with overo */
> > +//#define CONFIG_OMAP3_OVERO_TOBI  1   /* overo mounted on tobi */
> 
> Please do not use an C++ comments, and do not add dead code.

What is the preferred way to show that the option is available but not enabled
by default?

> > +#if !defined(CONFIG_OMAP3_OVERO_TOBI)
> > +#undef CONFIG_CMD_NET  /* bootp, tftpboot, rarpboot*/
> > +#endif
> > +
> > +
> 
> Only one blank line, please.
> 
> > +#endif /* (CONFIG_CMD_NET) */
> > +
> > +
> 
> Ditto.

Sure (on both).

This patch has been applied and pulled though. I'll submit an incremental patch 
to address the above.


-Olof

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


Re: [U-Boot] [PATCH v2] ppc/85xx: PIO Support for FSL eSDHC Controller Driver

2009-09-22 Thread Wolfgang Denk
Dear Dipen Dudhat,

In message <1252904203-9129-1-git-send-email-dipen.dud...@freescale.com> you 
wrote:
> On some Freescale SoC Internal DMA of eSDHC controller has bug.
> 
> So PIO Mode has introduced to do data transfer using CPU.
> In PIO mode data transfer performance will be degraded by a large extent.
> 
> Note: 
> In PIO mode multiple block read/write requires delay to complete the transfer.
> 
> Signed-off-by: Dipen Dudhat 

My comments to v1 of the patch still apply.

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 do not colonize. We conquer. We rule. There is no  other  way  for
us.
-- Rojan, "By Any Other Name", stardate 4657.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [help] is there anything wrong with my previously sent A320 patches?

2009-09-22 Thread Wolfgang Denk
Dear Po-Yu Chuang,

In message  you 
wrote:
> 
> I sent the following patches two weeks ago and got no reply.
> Maybe you did not receive the mails?
> I wonder if there was something wrong with my mail server or if I
> messed up something.
> 
> [U-Boot] [PATCH v6 1/2 resend] arm: A320: driver for FTRTC010 real time clock
> http://lists.denx.de/pipermail/u-boot/2009-September/059753.html
> 
> [U-Boot] [PATCH v6 2/2 resend] arm: A320: Add support for Faraday A320
> evaluation board
> http://lists.denx.de/pipermail/u-boot/2009-September/059755.html
> 
> Please let me know if there is anything wrong.

I cannot find these patches in my archive (even though I see the
archive entries).

Please (rebase and) resend. Sorry for the inconvenience.

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
Anything that is worth doing at all is worth doing well.
   -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Olof Johansson

On Sep 22, 2009, at 2:48 PM, Wolfgang Denk wrote:

> Dear Olof Johansson,
>
> In message  you wrote:
>>
>> Random question on u-boot development process: I see you didn't add
>> your signed-off on the commit. People don't do that when they check  
>> in
>> patches to the u-boot trees?
>
> No, we don't do this if we check in an unchanged patch.
>
> Linus does not S-o-b all patches that go into the Linux kernel, or
> does he?

He does.

For example, see 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=e258b80e691f1f3ae83a60aa80eaf7322bd55ec4



-Olof

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


Re: [U-Boot] [PATCH] OMAP3 Overo: Fix ethernet related warnings

2009-09-22 Thread Wolfgang Denk
Dear "Paulraj, Sandeep",

In message <0554bef07d437848af01b9c9b5f0bc5d927da...@dlee01.ent.ti.com> you 
wrote:
> 
> 
> > 
> > Fix warning
> > 
> > 'setup_net_chip' declared 'static' but never defined
> > 
> > with CONFIG_OMAP3_OVERO_TOBI disabled and
> > 
> > implicit declaration of function 'smc911x_initialize'
> > 
> > with CONFIG_OMAP3_OVERO_TOBI enabled.
> > 
> > Signed-off-by: Dirk Behme 
> > 
> 
> Pushed to u-boot-ti

I think all these cleanup patches by Dirk should be merged into a
cleaned up version of the Overo patch which is needed anyway due to
my other comments.

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
COBOL is for morons. -- E.W. Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: DaVinci: Adding GIO addresses to header file

2009-09-22 Thread Wolfgang Denk
Dear "Paulraj, Sandeep",

In message <0554bef07d437848af01b9c9b5f0bc5d92854...@dlee01.ent.ti.com> you 
wrote:
> 
> > 
> > From: Sandeep Paulraj 
> > 
> > This patch adds GIO definitions to the hardware.h
> > header file
> > 
> > Signed-off-by: Sandeep Paulraj 
> > ---
> >  include/asm-arm/arch-davinci/hardware.h |   23 +++
> >  1 files changed, 23 insertions(+), 0 deletions(-)
> > 
> Pushed to u-boot-ti

Sorry, I just NAKed that 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
It is a good thing for an uneducated man to read books of quotations.
- Sir Winston Churchill _My Early Life_ ch. 9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: DaVinci: Adding GIO addresses to header file

2009-09-22 Thread Wolfgang Denk
Dear s-paul...@ti.com,

In message <1252783655-13545-1-git-send-email-s-paul...@ti.com> you wrote:
> From: Sandeep Paulraj 
> 
> This patch adds GIO definitions to the hardware.h
> header file
> 
> Signed-off-by: Sandeep Paulraj 

NAK. Please do not add such address lists. Please use C structures to
describe the hardware mapping.


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
Never call a man a fool.  Borrow from him.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: DaVinci: DM355 Leopard board support

2009-09-22 Thread Wolfgang Denk
Dear "Paulraj, Sandeep",

In message <0554bef07d437848af01b9c9b5f0bc5d929e5...@dlee01.ent.ti.com> you 
wrote:
> 
> > From: Sandeep Paulraj 
> > 
> > This patch adds support for the leopard board which is
> > based on the DM355 SOC.
> > 
> > Signed-off-by: Sandeep Paulraj 
> > ---
> >  Makefile  |3 +
> >  board/davinci/dm355leopard/Makefile   |   52 +
> >  board/davinci/dm355leopard/config.mk  |6 +
> >  board/davinci/dm355leopard/dm355leopard.c |   84 +++
> >  include/configs/davinci_dm355leopard.h|  162
> > +
> >  5 files changed, 307 insertions(+), 0 deletions(-)
> >  create mode 100644 board/davinci/dm355leopard/Makefile
> >  create mode 100644 board/davinci/dm355leopard/config.mk
> >  create mode 100644 board/davinci/dm355leopard/dm355leopard.c
> >  create mode 100644 include/configs/davinci_dm355leopard.h
> 
> Pushed to u-boot-ti

Sorry for the late review - I just requested some changes to this
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
Every program has at least one bug and can be shortened by  at  least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx51:Add support basic boot code of freescale imx51 bbg board

2009-09-22 Thread Magnus Lilja

Hmm, for some reason "Reply" in gmail cut part of the qouted message so 
here's the rest of the followup.

Fred Fan skrev:
> Hi Magnus Liljia:
> Thanks for your comments.
>  Best Regards
> Fred
> 
> 2009/9/22, Magnus Lilja :
> 
>> Hi
>>
>>
>> I've scanned the patch briefly and have some comments below.
>>
>> gareat...@gmail.com wrote:
>> I don't think everything in this file is needed by U-Boot, e.g. the
>> interrupt definitions.
>> Yes. But interrupt maybe use when interrupt is supportted. Do I need remove
>> the definitions which are not used?

Don't know.

>>> diff --git a/include/configs/imx51.h b/include/configs/imx51.h
>>> new file mode 100644
>>> index 000..f0def4e
>>> --- /dev/null
>>> +++ b/include/configs/imx51.h
>>> @@ -0,0 +1,177 @@
>>> +/*
>>> + * Copyright (C) 2007, Guennadi Liakhovetski 
>>> + *
>>> + * (C) Copyright 2009 Freescale Semiconductor, Inc.
>>> + *
>>> + * Configuration settings for the MX51-3Stack Freescale board.
>>> + *
>>> + * 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
>>> + */
>>> +
>>> +#ifndef __CONFIG_H
>>> +#define __CONFIG_H
>>> +
>>> +#include 
>>> +
>>> + /* High Level Configuration Options */
>>> +#define CONFIG_ARMV7 1   /* This is armv7 Cortex-A8 CPU core
>> */
>>> +#define CONFIG_L2_OFF
>>> +
>>> +#define CONFIG_MXC   1
>>> +#define CONFIG_MX51_BBG  1   /* in a mx51 */
>> Can't see that this is used anywhere.
>> OK. I will remove them;

Only remove MX51_BBG, I didn't check if CONFIG_MXC is used anywhere.


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


Re: [U-Boot] [PATCH] TI: DaVinci: DM355 Leopard board support

2009-09-22 Thread Wolfgang Denk
Dear s-paul...@ti.com,

In message <1252783335-13371-1-git-send-email-s-paul...@ti.com> you wrote:
> From: Sandeep Paulraj 
> 
> This patch adds support for the leopard board which is
> based on the DM355 SOC.
> 
> Signed-off-by: Sandeep Paulraj 
> ---
>  Makefile  |3 +
>  board/davinci/dm355leopard/Makefile   |   52 +
>  board/davinci/dm355leopard/config.mk  |6 +
>  board/davinci/dm355leopard/dm355leopard.c |   84 +++
>  include/configs/davinci_dm355leopard.h|  162 
> +
>  5 files changed, 307 insertions(+), 0 deletions(-)
>  create mode 100644 board/davinci/dm355leopard/Makefile
>  create mode 100644 board/davinci/dm355leopard/config.mk
>  create mode 100644 board/davinci/dm355leopard/dm355leopard.c
>  create mode 100644 include/configs/davinci_dm355leopard.h

Entries to MAINTAINERS and MAKEALL missing.

> diff --git a/Makefile b/Makefile
> index 0449a5b..5a4a109 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2958,6 +2958,9 @@ davinci_dm355evm_config :   unconfig
>  davinci_dm365evm_config :unconfig
>   @$(MKCONFIG) $(@:_config=) arm arm926ejs dm365evm davinci davinci
>  
> +davinci_dm355leopard_config :unconfig
> + @$(MKCONFIG) $(@:_config=) arm arm926ejs dm355leopard davinci davinci
> +

Please keep list sorted.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Our business is run on trust.  We trust you will pay in advance.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] imx51:Add support basic boot code of freescale imx51 bbg board

2009-09-22 Thread Magnus Lilja
Hi

2009/9/22 Fred Fan :
> Hi Magnus Liljia:
>     Thanks for your comments.
>  Best Regards
> Fred
>
> 2009/9/22, Magnus Lilja :
>>
>> Hi
>>
>>
>> I've scanned the patch briefly and have some comments below.
>>
>> gareat...@gmail.com wrote:
>> > diff --git a/MAKEALL b/MAKEALL
>> > index edebaea..ed8c437 100755
>> > --- a/MAKEALL
>> > +++ b/MAKEALL
>> 
>
>
> Does means use new board name?

Heh, no.  just means that I've removed parts of your patch
(those parts which I don't have any comments on). Sorry for the
confusion.

>> > +++ b/board/freescale/imx51/Makefile
>> 
>> Does means use new board name?

The board name should be used instead of the imx51 name.
>> > + mxc_request_iomux(MX51_PIN_UART1_RXD, IOMUX_CONFIG_ALT0);
>> > + mxc_iomux_set_pad(MX51_PIN_UART1_RXD, pad | PAD_CTL_SRE_FAST);
>> > + mxc_request_iomux(MX51_PIN_UART1_TXD, IOMUX_CONFIG_ALT0);
>> > + mxc_iomux_set_pad(MX51_PIN_UART1_TXD, pad | PAD_CTL_SRE_FAST);
>> > + mxc_request_iomux(MX51_PIN_UART1_RTS, IOMUX_CONFIG_ALT0);
>> > + mxc_iomux_set_pad(MX51_PIN_UART1_RTS, pad);
>> > + mxc_request_iomux(MX51_PIN_UART1_CTS, IOMUX_CONFIG_ALT0);
>> > + mxc_iomux_set_pad(MX51_PIN_UART1_CTS, pad);
>> > +}
>> > +
>> > +void setup_nfc(void)
>> > +{
>> > + /* Enable NFC IOMUX */
>> > + mxc_request_iomux(MX51_PIN_NANDF_CS0, IOMUX_CONFIG_ALT0);
>> > + mxc_request_iomux(MX51_PIN_NANDF_CS1, IOMUX_CONFIG_ALT0);
>> > + mxc_request_iomux(MX51_PIN_NANDF_CS2, IOMUX_CONFIG_ALT0);
>> > + mxc_request_iomux(MX51_PIN_NANDF_CS3, IOMUX_CONFIG_ALT0);
>> > + mxc_request_iomux(MX51_PIN_NANDF_CS4, IOMUX_CONFIG_ALT0);
>> > + mxc_request_iomux(MX51_PIN_NANDF_CS5, IOMUX_CONFIG_ALT0);
>> > + mxc_request_iomux(MX51_PIN_NANDF_CS6, IOMUX_CONFIG_ALT0);
>> > + mxc_request_iomux(MX51_PIN_NANDF_CS7, IOMUX_CONFIG_ALT0);
>> > +}
>>
>> Since it's very likely that setup_nfc() and setup_uart() will be used in
>> other i.MX51 boards as well it's a good idea to
>> place these functions in cpu/arm_cortexa8/mx51/devices.c (or something
>> similar).
>> I think it should be board level. Some board based on i.MX51 maybe has
>> differenent choice.

That can  be handed with #ifdef's just like in the i.MX31 case.

<...>
>> > +#define MXC_SRPGC_EMI_SRPGCR (MXC_SRPGC_EMI_BASE + 0x0)
>> > +#define MXC_SRPGC_EMI_PUPSCR (MXC_SRPGC_EMI_BASE + 0x4)
>> > +#define MXC_SRPGC_EMI_PDNSCR (MXC_SRPGC_EMI_BASE + 0x8)
>> > +
>>
>> Are all of the above #defines needed/expected to be needed by U-boot?
>
>   No. It just copy from linux kernel code. Does need remove them?

Don't no what the policy is.
>> > diff --git a/cpu/arm_cortexa8/mx51/interrupts.c
>> > b/cpu/arm_cortexa8/mx51/interrupts.c
>> > new file mode 100644
>> > index 000..c0d70ac
>> > --- /dev/null
>> > +++ b/cpu/arm_cortexa8/mx51/interrupts.c
>> 
>> What's means?

Ignore the  comments.

>> > diff --git a/cpu/arm_cortexa8/mx51/serial.c
>> > b/cpu/arm_cortexa8/mx51/serial.c
>> > new file mode 100644
>> > index 000..580ac13
>> > --- /dev/null
>> > +++ b/cpu/arm_cortexa8/mx51/serial.c
>>
>> I haven't looked in the details of the serial driver, but would it be
>> possible to use drivers/serial/serial_mxc.c
>> instead? It looks very similar.
>> I don't like the implement of this driver. It contains the chip details in
>> driver code.
>>
>> But I will do what as your said. And restructure this driver in another
>> patch.

That sounds like a good idea if you want to improve the serial driver.
Create a separate standalone patch so people can review and test that.

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


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear "Paulraj, Sandeep",

In message <0554bef07d437848af01b9c9b5f0bc5d91e07...@dlee01.ent.ti.com> you 
wrote:
> 
> > I always use 'git am -s', which adds the SOB.   My understanding is that 
> > maintainers should do this as an indication of approval and help in 
> > traceability.
> 
> OK Thanks. Shall do so henceforth.

Hm. I have to amit that I don't consider this a change to the better.

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
No man knows what true happiness is until he gets married.  By  then,
of course, its too late.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Ben Warren,

In message  you 
wrote:
>
> > I always use 'git am -s', which adds the SOB.   My understanding is that
> maintainers should do this as an indication of approval and help in
> traceability.

Please feel free to do that, but I consider this just adding
line-noise, unless you _really_ express special approval.

Which sense would it make if I added a s-o-b to each and every commit
I'm pulling in from anywhere? 

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
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
  - Wernher von Braun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Olof Johansson,

In message  you wrote:
> 
> Random question on u-boot development process: I see you didn't add  
> your signed-off on the commit. People don't do that when they check in  
> patches to the u-boot trees?

No, we don't do this if we check in an unchanged patch.

Linus does not S-o-b all patches that go into the Linux kernel, or
does he?



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
"What the scientists have in their briefcases is terrifying."
- Nikita Khrushchev
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear "Paulraj, Sandeep",

In message <0554bef07d437848af01b9c9b5f0bc5d92708...@dlee01.ent.ti.com> you 
wrote:
> 
> > Olof Johansson wrote:
> > > Add setup for ethernet on Tobi, allowing kernel/ramdisk to be loaded
> > > over tftp.
> > >
> > > Based on the omap3 evm code. I added a new highlevel define for Tobi
> > > to avoid having it dependent on CMD_NET (which would seem backward in
> > > this case).
> > >
> > > Signed-off-by: Olof Johansson 
> > 
> > Acked-by: Dirk Behme 
> 
> Pushed to u-boot-ti

Sorry, please see my previous review comments. I apologize for the
late review.

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
Diplomacy is the art of saying "nice doggy" until you can find a rock.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH-ARM 4/4] Clean-up of s3c24x0 nand driver

2009-09-22 Thread Wolfgang Denk
Dear Scott Wood,

In message <20090911222349.ga26...@b07421-ec1.am.freescale.net> you wrote:
> On Mon, Sep 07, 2009 at 12:15:22AM +0100, 
> kevin.morf...@fearnside-systems.co.uk wrote:
> > This patch re-formats the arm920t s3c24x0 nand driver in preparation for 
> > changes
> > to add support for the Embest SBC2440-II Board.
> > 
> > The changes are as follows:
> > - re-indent the code using Lindent
> > - make sure register layouts are defined using a C struct
> > - replace the upper-case typedef'ed C struct names with lower case
> > non-typedef'ed ones
> > - make sure registers are accessed using the proper accessor functions
> > - run checkpatch.pl and fix any error reports
> > 
> > It assumes the following patch has been applied first:
> > - [U-Boot][PATCH-ARM] CONFIG_SYS_HZ fix for ARM902T S3C24X0 Boards, 
> > 05/09/2009
> >  - patches 1/4, 2/4 and 3/4 of this series
> 
> Acked-by: Scott Wood 

What does that ACK mean? Who is supposed to apply this patch - the ARM
custodian?

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 moral of the story is: "Don't stop to  tighten  your  shoe  laces
during the Olympics 100m finals".
 - Kevin Jones in 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI: OMAP3: Overo Tobi ethernet support

2009-09-22 Thread Wolfgang Denk
Dear Olof Johansson,

In message <20090911204750.ga22...@lixom.net> you wrote:
> Add setup for ethernet on Tobi, allowing kernel/ramdisk to be loaded
> over tftp.
> 
> Based on the omap3 evm code. I added a new highlevel define for Tobi
> to avoid having it dependent on CMD_NET (which would seem backward in
> this case).
> 
> 
> Signed-off-by: Olof Johansson 
> 
> diff --git a/board/overo/overo.c b/board/overo/overo.c
> index dd6d286..4a67360 100644

Please use "git format-patch" / "git send-email" to create and submit
patches. For example, it is always nice to see a file statistics in
the patch.

> --- a/board/overo/overo.h
> +++ b/board/overo/overo.h
> @@ -33,6 +33,8 @@ const omap3_sysinfo sysinfo = {
>  #endif
>  };
>  
> +static void setup_net_chip(void);
> +
>  /*
>   * IEN  - Input Enable
>   * IDIS - Input Disable
> @@ -378,4 +380,42 @@ const omap3_sysinfo sysinfo = {
>   MUX_VAL(CP(SDRC_CKE0),  (IDIS | PTU | EN  | M0)) /*sdrc_cke0*/\
>   MUX_VAL(CP(SDRC_CKE1),  (IDIS | PTU | EN  | M0)) /*sdrc_cke1*/
>  
> +#if defined(CONFIG_OMAP3_OVERO_TOBI)
> +#define MUX_OVERO_TOBI() \
> + MUX_VAL(CP(GPMC_A1),(IDIS | PTU | EN  | M0)) /*GPMC_A1*/\
> + MUX_VAL(CP(GPMC_A2),(IDIS | PTU | EN  | M0)) /*GPMC_A2*/\
> + MUX_VAL(CP(GPMC_A3),(IDIS | PTU | EN  | M0)) /*GPMC_A3*/\
> + MUX_VAL(CP(GPMC_A4),(IDIS | PTU | EN  | M0)) /*GPMC_A4*/\
> + MUX_VAL(CP(GPMC_A5),(IDIS | PTU | EN  | M0)) /*GPMC_A5*/\
> + MUX_VAL(CP(GPMC_A6),(IDIS | PTU | EN  | M0)) /*GPMC_A6*/\
> + MUX_VAL(CP(GPMC_A7),(IDIS | PTU | EN  | M0)) /*GPMC_A7*/\
> + MUX_VAL(CP(GPMC_A8),(IDIS | PTU | EN  | M0)) /*GPMC_A8*/\
> + MUX_VAL(CP(GPMC_A9),(IDIS | PTU | EN  | M0)) /*GPMC_A9*/\
> + MUX_VAL(CP(GPMC_A10),   (IDIS | PTU | EN  | M0)) /*GPMC_A10*/\
> + MUX_VAL(CP(GPMC_D0),(IEN  | PTU | EN  | M0)) /*GPMC_D0*/\
> + MUX_VAL(CP(GPMC_D1),(IEN  | PTU | EN  | M0)) /*GPMC_D1*/\
> + MUX_VAL(CP(GPMC_D2),(IEN  | PTU | EN  | M0)) /*GPMC_D2*/\
> + MUX_VAL(CP(GPMC_D3),(IEN  | PTU | EN  | M0)) /*GPMC_D3*/\
> + MUX_VAL(CP(GPMC_D4),(IEN  | PTU | EN  | M0)) /*GPMC_D4*/\
> + MUX_VAL(CP(GPMC_D5),(IEN  | PTU | EN  | M0)) /*GPMC_D5*/\
> + MUX_VAL(CP(GPMC_D6),(IEN  | PTU | EN  | M0)) /*GPMC_D6*/\
> + MUX_VAL(CP(GPMC_D7),(IEN  | PTU | EN  | M0)) /*GPMC_D7*/\
> + MUX_VAL(CP(GPMC_D8),(IEN  | PTU | EN  | M0)) /*GPMC_D8*/\
> + MUX_VAL(CP(GPMC_D9),(IEN  | PTU | EN  | M0)) /*GPMC_D9*/\
> + MUX_VAL(CP(GPMC_D10),   (IEN  | PTU | EN  | M0)) /*GPMC_D10*/\
> + MUX_VAL(CP(GPMC_D11),   (IEN  | PTU | EN  | M0)) /*GPMC_D11*/\
> + MUX_VAL(CP(GPMC_D12),   (IEN  | PTU | EN  | M0)) /*GPMC_D12*/\
> + MUX_VAL(CP(GPMC_D13),   (IEN  | PTU | EN  | M0)) /*GPMC_D13*/\
> + MUX_VAL(CP(GPMC_D14),   (IEN  | PTU | EN  | M0)) /*GPMC_D14*/\
> + MUX_VAL(CP(GPMC_D15),   (IEN  | PTU | EN  | M0)) /*GPMC_D15*/\
> + MUX_VAL(CP(GPMC_NCS5),  (IDIS | PTU | EN  | M0)) /*GPMC_nCS5*/\
> + MUX_VAL(CP(GPMC_CLK),   (IDIS | PTU | EN  | M0)) /*GPMC_CLK*/\
> + MUX_VAL(CP(GPMC_WAIT2), (IEN  | PTU | EN  | M4)) /*GPIO_64*/\
> +  /* - SMSC911X_NRES*/\
> + MUX_VAL(CP(MCSPI1_CS2), (IEN  | PTU | DIS | M4)) /*GPIO_176 */\
> +  /* - LAN_INTR */\

Please use either no indentatioin at all, or indent by a multiple of
TAB characters.

> diff --git a/include/configs/omap3_overo.h b/include/configs/omap3_overo.h
> index 07a031b..6616b55 100644
> --- a/include/configs/omap3_overo.h
> +++ b/include/configs/omap3_overo.h
> @@ -28,7 +28,8 @@
>  #define CONFIG_OMAP  1   /* in a TI OMAP core */
>  #define CONFIG_OMAP34XX  1   /* which is a 34XX */
>  #define CONFIG_OMAP3430  1   /* which is in a 3430 */
> -#define CONFIG_OMAP3_OVERO   1   /* working with overo */
> +#define CONFIG_OMAP3_OVERO   1   /* working with overo */
> +//#define CONFIG_OMAP3_OVERO_TOBI1   /* overo mounted on tobi */

Please do not use an C++ comments, and do not add dead code.

> +#if !defined(CONFIG_OMAP3_OVERO_TOBI)
> +#undef CONFIG_CMD_NET/* bootp, tftpboot, rarpboot*/
> +#endif
> +
> +

Only one blank line, please.

> +#endif /* (CONFIG_CMD_NET) */
> +
> +

Ditto.

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 some people discover the truth, they just can't  understand  why
everybody isn't eager to hear it.
___

Re: [U-Boot] [PATCH] Add support for the Calao QIL-A9G20 board

2009-09-22 Thread Wolfgang Denk
Dear Albin Tonnerre,

In message 
<1252688802-29403-1-git-send-email-albin.tonne...@free-electrons.com> you wrote:
> The Calao SBC35-A9G20 board is manufactured and sold by Calao Systems
> . It is built around an AT91SAM9G20 ARM SoC
> running at 400MHz. It features an Ethernet port, an SPI RTC backed by an 
> onboard
> battery , an SD/MMC slot, a CompactFlash slot, 64Mo of SDRAM, 256Mo of NAND
> flash, two USB host ports, and an USB device port. More informations can be
> found at 
> 
> Signed-off-by: Albin Tonnerre 
> ---
>  MAINTAINERS   |2 +
>  MAKEALL   |2 +
>  Makefile  |   10 ++
>  board/calao/qil_a9g20/Makefile|   55 ++
>  board/calao/qil_a9g20/config.mk   |1 +
>  board/calao/qil_a9g20/qil_a9g20.c |  201 
> +
>  board/calao/qil_a9g20/spi.c   |   57 +++
>  include/configs/qil_a9g20.h   |  200 
>  8 files changed, 528 insertions(+), 0 deletions(-)
>  create mode 100644 board/calao/qil_a9g20/Makefile
>  create mode 100644 board/calao/qil_a9g20/config.mk
>  create mode 100644 board/calao/qil_a9g20/qil_a9g20.c
>  create mode 100644 board/calao/qil_a9g20/spi.c
>  create mode 100644 include/configs/qil_a9g20.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e9db278..b1e82f4 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -696,6 +696,8 @@ Andrea Scian 
>  
>  Albin Tonnerre 
>  
> + qil_a9260   ARM926EJS (AT91SAM9260 SoC)
> + qil_a9g20   ARM926EJS (AT91SAM9G20 SoC)
>   sbc35_a9g20 ARM926EJS (AT91SAM9G20 SoC)
>   tny_a9260   ARM926EJS (AT91SAM9260 SoC)
>   tny_a9g20   ARM926EJS (AT91SAM9G20 SoC)

This is a mess.

The Subject mentions adding the QIL-A9G20 board; the commit message
says you were adding the SBC35-A9G20 board (which already exists),
but actually you seem to be adding the QIL-A9G20 and QIL-A9260
boards?

Please make comments and code match.


> diff --git a/MAKEALL b/MAKEALL
> index f0ed8ea..531a667 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -614,6 +614,8 @@ LIST_at91="   \
>   m501sk  \
>   pm9261  \
>   pm9263  \
> + QIL_A9260   \
> + QIL_A9G20   \
>   SBC35_A9G20 \
>   TNY_A9260   \
>   TNY_A9G20   \

Ditto.

> diff --git a/Makefile b/Makefile
> index 0449a5b..eb542a4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2897,6 +2897,16 @@ at91sam9g45ekes_config :   unconfig
>  pm9263_config:   unconfig
>   @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91
>  
> +QIL_A9G20_NANDFLASH_config \
> +QIL_A9G20_EEPROM_config \
> +QIL_A9G20_config \
> +QIL_A9260_NANDFLASH_config \
> +QIL_A9260_EEPROM_config \
> +QIL_A9260_config :   unconfig
> + @mkdir -p $(obj)include
> + @echo "#define CONFIG_$(@:_config=) 1" >$(obj)include/config.h
> + @$(MKCONFIG) -a qil_a9g20 arm arm926ejs qil_a9g20 calao at91

Ditto.

...
> diff --git a/board/calao/qil_a9g20/qil_a9g20.c 
> b/board/calao/qil_a9g20/qil_a9g20.c
> new file mode 100644
> index 000..38f4cce
> --- /dev/null
> +++ b/board/calao/qil_a9g20/qil_a9g20.c
...
> +int board_init(void)
> +{
> + /* Enable Ctrlc */
> + console_init_f();
> +
> +#ifdef CONFIG_QIL_A9G20
> + gd->bd->bi_arch_number = MACH_TYPE_QIL_A9G20;
> +#else
> + gd->bd->bi_arch_number = MACH_TYPE_QIL_A9260;
> +#endif

Please avoid the #ifdef here; use for example a #define in the board
config file instead.

...
> +#ifdef CONFIG_RESET_PHY_R
> +void reset_phy(void)
> +{
> +#ifdef CONFIG_MACB
> + /*
> +  * Initialize ethernet HW addr prior to starting Linux,
> +  * needed for nfsroot
> +  */
> + eth_init(gd->bd);
> +#endif
> +}
> +#endif

You must not initialize the Ethernet interface unless U-Boot is
running a network coimmand. And you should then disable it again
before booting Linux. Please read the FAQ and fix the Linux driver
issues in Linux.

...
> +/*
> + * Command line configuration.
> + */
> +#include 
> +#undef CONFIG_CMD_BDI
> +#undef CONFIG_CMD_FPGA
> +#undef CONFIG_CMD_IMI
> +#undef CONFIG_CMD_IMLS
> +#undef CONFIG_CMD_LOADS
> +#undef CONFIG_CMD_SOURCE

You are undefining some pretty useful commands here (like bdinfo,
iminfo, source, etc.) Is ther eany special reason for doing this?


...
> +/* USB */
> +#define CONFIG_USB_ATMEL
> +#define CONFIG_USB_OHCI_NEW  1
> +#define CONFIG_DOS_PARTITION 1
> +#define CONFIG_SYS_USB_OHCI_CPU_INIT 1
> +#define CONFIG_SYS_USB_OHCI_REGS_BASE0x0050  /* 
> AT91SAM9260_UHP_BASE */

Line too long. Please fix globally.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groe

Re: [U-Boot] [PATCH] Support for Calao USB A9263 board based on AT91SAM9263 CPU

2009-09-22 Thread Wolfgang Denk
Dear Thomas Petazzoni,

In message 
<1252668335-17986-1-git-send-email-thomas.petazz...@free-electrons.com> you 
wrote:
> The Calao USB A9263 board is a board manufactured and sold by Calao
> Systems . Its components are very
> similar to the AT91SAM9263EK board, so its configuration is based
> on the configuration of this board. There are however some
> differences: different clocks, no LCD, etc.
> 
> Signed-off-by: Thomas Petazzoni 
> Signed-off-by: Albin Tonnerre 
...
> +#ifdef CONFIG_RESET_PHY_R
> +void reset_phy(void)
> +{
> +#ifdef CONFIG_MACB
> + /*
> +  * Initialize ethernet HW addr prior to starting Linux,
> +  * needed for nfsroot
> +  */
> + eth_init(gd->bd);
> +#endif
> +}
> +#endif

You must not initialize the Ethernet interface unless U-Boot is
running a network coimmand. And you should then disable it again
before booting Linux. Please read the FAQ and fix the Linux driver
issues in Linux.


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 weak mind is like a microscope, which magnifies trifling things,
but cannot receive great ones.  -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v3 3/5] NAND boot: MPC8536DS support

2009-09-22 Thread Wolfgang Denk
Dear Mingkai Hu,

In message <1252649951-28543-2-git-send-email-mingkai...@freescale.com> you 
wrote:
> MPC8536E can support booting from NAND flash which uses the
> image u-boot-nand.bin. This image contains two parts: a 4K
> NAND loader and a main U-Boot image. The former is appended
> to the latter to produce u-boot-nand.bin. The 4K NAND loader
> includes the corresponding nand_spl directory, along with the
> code twisted by CONFIG_NAND_SPL. The main U-Boot image just
> like a general U-Boot image except the parts that included by
> CONFIG_SYS_RAMBOOT.
...
> diff --git a/cpu/mpc85xx/nand_init.c b/cpu/mpc85xx/nand_init.c
> new file mode 100644
> index 000..c29b22d
...
> +void cpu_init_early_f(void)
> +{
> + int i;
> +
> + /* Pointer is writable since we allocated a register for it */
> + gd = (gd_t *) (CONFIG_SYS_INIT_RAM_ADDR + CONFIG_SYS_GBL_DATA_OFFSET);
> +
> + /* Clear initial global data */
> + for (i = 0; i < sizeof(gd_t); i++)
> + ((char *)gd)[i] = 0;
> +
> + set_tlb(0, CONFIG_SYS_CCSRBAR, CONFIG_SYS_CCSRBAR_PHYS,
> + MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
> + 1, 0, BOOKE_PAGESZ_4K, 0);
> +
> + /* set up CCSR if we want it moved */
> +#if (CONFIG_SYS_CCSRBAR_DEFAULT != CONFIG_SYS_CCSRBAR_PHYS)
> + {
> + volatile u32 *ccsr_virt =
> + (volatile u32 *)(CONFIG_SYS_CCSRBAR + 0x1000);

Please do not declare vaiables righjt in the middle of the code.
Consider moving this code into a separate function instead.

> diff --git a/cpu/mpc85xx/u-boot-nand.lds b/cpu/mpc85xx/u-boot-nand.lds
> index c14e946..a0fc8f1 100644
> --- a/cpu/mpc85xx/u-boot-nand.lds
> +++ b/cpu/mpc85xx/u-boot-nand.lds
> @@ -65,10 +65,8 @@ SECTIONS
>  PROVIDE (etext = .);
>  .rodata:
> {
> -*(.rodata)
> -*(.rodata1)
> -*(.rodata.str1.4)
>  *(.eh_frame)
> +*(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*)))

Please rebase your patch against current code.

...
>  /*
> + * Config the L2 Cache as L2 SRAM
> + */
> +#define CONFIG_SYS_INIT_L2_ADDR  0xf8f8
> +#ifdef CONFIG_PHYS_64BIT
> +#define CONFIG_SYS_INIT_L2_ADDR_PHYS 0xff8f8ull
> +#else
> +#define CONFIG_SYS_INIT_L2_ADDR_PHYS CONFIG_SYS_INIT_L2_ADDR
> +#endif
> +#define CONFIG_SYS_L2_SIZE   (512 << 10)
> +#define CONFIG_SYS_INIT_L2_END   (CONFIG_SYS_INIT_L2_ADDR + 
> CONFIG_SYS_L2_SIZE)

Line too long, please fix globally.

> diff --git a/nand_spl/board/freescale/mpc8536ds/Makefile 
> b/nand_spl/board/freescale/mpc8536ds/Makefile
> new file mode 100644
> index 000..c9104d3
> --- /dev/null
> +++ b/nand_spl/board/freescale/mpc8536ds/Makefile
...
> +$(obj)start.S:
> + @rm -f $(obj)start.S
> + ln -sf $(SRCTREE)/cpu/mpc85xx/start.S $(obj)start.S
> +
> +$(obj)resetvec.S:
> + @rm -f $(obj)resetvec.S
> + ln -s $(SRCTREE)/cpu/$(CPU)/resetvec.S $(obj)resetvec.S
> +
> +$(obj)nand_boot_fsl_elbc.c:
> + @rm -f $(obj)nand_boot_fsl_elbc.c
> + ln -sf $(SRCTREE)/nand_spl/nand_boot_fsl_elbc.c \
> +$(obj)nand_boot_fsl_elbc.c
> +
> +$(obj)ns16550.c:
> + @rm -f $(obj)ns16550.c
> + ln -sf $(SRCTREE)/drivers/serial/ns16550.c $(obj)ns16550.c
> +
> +$(obj)nand_init.c:
> + @rm -f $(obj)nand_init.c
> + ln -sf $(SRCTREE)/cpu/mpc85xx/nand_init.c $(obj)nand_init.c
> +
> +$(obj)cache.c:
> + @rm -f $(obj)cache.c
> + ln -sf $(SRCTREE)/lib_ppc/cache.c $(obj)cache.c
> +
> +$(obj)tlb.c:
> + @rm -f $(obj)tlb.c
> + ln -sf $(SRCTREE)/cpu/mpc85xx/tlb.c $(obj)tlb.c
> +
> +$(obj)tlb_table.c:
> + @rm -f $(obj)tlb_table.c
> + ln -sf $(SRCTREE)/board/$(BOARDDIR)/tlb.c $(obj)tlb_table.c

Consider using the same file name here; it will simplify the Makefile
rules.

> +
> +$(obj)law.c:
> + @rm -f $(obj)law.c
> + ln -sf $(SRCTREE)/drivers/misc/fsl_law.c $(obj)law.c

Ditto.

> +
> +$(obj)law_table.c:
> + @rm -f $(obj)law_table.c
> + ln -sf $(SRCTREE)/board/$(BOARDDIR)/law.c $(obj)law_table.c

Ditto.

Please sort list.

And why do you need a separate rule everywhere? They look all the
same to me  (except for the inconsistent file names) ?

> +#
> +
> +$(obj)%.o:   $(obj)%.S
> + $(CC) $(AFLAGS) -c -o $@ $<
> +
> +$(obj)%.o:   $(obj)%.c
> + $(CC) $(CFLAGS) -c -o $@ $<
> +
> +# defines $(obj).depend target
> +include $(SRCTREE)/rules.mk
> +
> +sinclude $(obj).depend
> +
> +#
> diff --git a/nand_spl/board/freescale/mpc8536ds/nand_boot.c 
> b/nand_spl/board/freescale/mpc8536ds/nand_boot.c
> new file mode 100644
> index 000..77973d1
> --- /dev/null
> +++ b/nand_spl/board/freescale/mpc8536ds/nand_boot.c
...
> +void board_init_f(ulong bootflag)
> +{
> + u8 sysclk_ratio;
> + uint plat_ratio, bus_clk, sys_clk;
> + volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
> +
> + /* initialize selected port w

Re: [U-Boot] [PATCH][Net] Convert SMC91111 Ethernet driver to CONFIG_NET_MULTI API

2009-09-22 Thread Wolfgang Denk
Dear Mike Frysinger,

In message <200909110606.42732.vap...@gentoo.org> you wrote:
> --===0077506097==
> Content-Type: multipart/signed;
>   boundary="nextPart2279044.usXPOpWbKs";
>   protocol="application/pgp-signature";
>   micalg=pgp-sha1
> Content-Transfer-Encoding: 7bit
> 
> --nextPart2279044.usXPOpWbKs
> Content-Type: multipart/mixed;
>   boundary="Boundary-01=_rEiqKxzcR2Mk9j/"
> Content-Transfer-Encoding: 7bit
> 
> 
> --Boundary-01=_rEiqKxzcR2Mk9j/
> Content-Type: Text/Plain;
>   charset="utf-8"
> Content-Transfer-Encoding: quoted-printable
> Content-Disposition: inline

Please do not do that. Patches are supposed to be submitten inline.

Except for that:

Acked-by: Wolfgang Denk 

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 don't care.  We don't have to.  We're the Phone Company."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 3/3] mpc8536: Get the address of env on the SDCard

2009-09-22 Thread Wolfgang Denk
Dear Mingkai Hu,

In message <1252640445-7890-4-git-send-email-mingkai...@freescale.com> you 
wrote:
> Both the save env and load env operation will call this function
> to get the address of env on the SDCard, so the user can control
> where to put the env freely.
> 
> Also enable the functionlity of saving env variable to SDCard on
> mpc8536
> 
> Signed-off-by: Mingkai Hu 
...
> +#if defined(CONFIG_MMC)
> +/*
> + * The environment variables are written to just after the u-boot image
> + * on SDCard, so we must read the MBR to get the start address and code
> + * length of the u-boot image, then calculate the address of the env.

This seems to be broken by design. If your U-Boot image grows, it
would overwrite the environment? Or am I missing something?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
If A equals success, then the formula is A = X + Y + Z. X is work.  Y
is play. Z is keep your mouth shut. - Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 1/3] Make mmc init come before env_relocate

2009-09-22 Thread Wolfgang Denk
Dear Mingkai Hu,

In message <1252640445-7890-2-git-send-email-mingkai...@freescale.com> you 
wrote:
> If the environment variables are saved on the MMC/SD card,
> env_relocat can't relocate env from MMC/SD card without mmc init.
> 
> Signed-off-by: Mingkai Hu 

I'm biased. I understand that you do this because you need it for the
next patch, which reads the environment from MMC card. But then MMC is
just one out of many storage devices, and with the same right we would
have to move the SCSI or DoC or S-ATA initialization up, because we
could implement storing the environment on such devices, too.

This has not been done so far, because it suffers from the fundamental
problem your code is suffering from, too: you cannot access the
environment early enough, so for example your board boots with a
hard-wird, unchangable console baud rate, despite that you suggest to
the user he could change it.

I don't like that, and therefore tend to NAK the whole approach.

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
Don't hit a man when he's down - kick him; it's easier.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v1 2/3] Add support for save environment variable to MMC/SD card

2009-09-22 Thread Wolfgang Denk
Dear Mingkai Hu,

In message <1252640445-7890-3-git-send-email-mingkai...@freescale.com> you 
wrote:
> Whether booting from MMC/SD card or not, the environment variables
> can be saved on it, this patch add the operation support.
> 
> Signed-off-by: Mingkai Hu 
...
> --- a/common/Makefile
> +++ b/common/Makefile
> @@ -61,6 +61,7 @@ COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
>  COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
>  COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
>  COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
> +COBJS-$(CONFIG_ENV_IS_IN_SDCARD) += env_sdcard.o
>  COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o

Please keep the list sorted.

>  # command
> diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
> index 2186205..83969ef 100644
> --- a/common/cmd_nvedit.c
> +++ b/common/cmd_nvedit.c
> @@ -60,9 +60,10 @@ DECLARE_GLOBAL_DATA_PTR;
>  !defined(CONFIG_ENV_IS_IN_NVRAM) && \
>  !defined(CONFIG_ENV_IS_IN_ONENAND)   && \
>  !defined(CONFIG_ENV_IS_IN_SPI_FLASH) && \
> +!defined(CONFIG_ENV_IS_IN_SDCARD)&& \

Ditto.

>  # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
> -SPI_FLASH|MG_DISK|NVRAM|NOWHERE}
> +SPI_FLASH|MG_DISK|NVRAM|SDCARD|NOWHERE}

Please take the opportunity to sort this list, too. Thanks.

...
> +int env_init(void)
> +{
> + /* eSDHC isn't usable before relocation */
> + gd->env_addr  = (ulong)&default_environment[0];
> + gd->env_valid = 1;

Argh... Does that mean that your environment suddenly changes while
running? That you start running from the default environment (which
cannot be changed) and then switch to a the real, changable
environment?

This is going to cause a hell of confusion to users who for example
want to define a different console baud rate or such...

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
It is surely a great calamity for  a  human  being  to  have  no  ob-
sessions.- Robert Bly
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] MPC83xx and uec

2009-09-22 Thread Joakim Tjernlund
Ben Warren  wrote on 22/09/2009 18:55:22:
>
> Anton Vorontsov wrote:
> > On Tue, Sep 22, 2009 at 04:03:16PM +0200, Joakim Tjernlund wrote:
> > [...]
> >
> > Also
> >  drivers/qe/uec.h:int uec_initialize(bd_t *bis, uec_info_t *uec_info);
> >  include/netdev.h:int uec_initialize(int index);
> > different prototypes for the same function.
> >
>  BTW, I am looking for a way to swap the order of ethernet interfaces:
>  static uec_info_t uec_info[] = {
>  #ifdef CONFIG_UEC_ETH1
> STD_UEC_INFO(1),   /* UEC1 */
>  #endif
>  #ifdef CONFIG_UEC_ETH2
> STD_UEC_INFO(2),   /* UEC2 */
>  #endif
>  #ifdef CONFIG_UEC_ETH3
> STD_UEC_INFO(3),   /* UEC3 */
>  #endif
>  };
> 
> >>> Works for me:
> >>>
> >>> http://lists.denx.de/pipermail/u-boot/2009-September/060821.html
> >>>
> >> Right, but I don't consider a include as this:
> >>   +#include "../../../drivers/qe/uec.h"
> >> as the correct way of getting of required data types and macros.
> >> Consider that uec_initialize() is exported by netdev.h (although with the
> >> wrong prototype ATM). As far as I can tell, I should only have to include
> >> netdev.h to get the required types and macros.
> >>
> >
> > Not sure if having all-in-one netdev header is a good idea.
> > It might be a good idea to move uec.h to "include/" though.
> >
> >
> This needs to be cleaned up.  THE prototype for the global initialize()
> function needs to be in netdev.h and nowhere else.
>
> BTW - can't you effectively swap the order of the Ethernet interfaces at
> runtime using the 'ethprime' environment variable?

I did this quite some time ago so memory isn't fresh, but at time
I looked high and low(including ethprime) and nothing worked all the way so I
ended up swapping by patching generic code instead. Now I can do the
same in board code, but current u-boot is a bit fuzzy in this area.

  Jocke

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


Re: [U-Boot] [PATCH v3] at91: Update MEESC board support

2009-09-22 Thread Wolfgang Denk
Dear Daniel Gorsulowski,

In message <12525916852655-git-send-email-daniel.gorsulow...@esd.eu> you wrote:
> This patch implements several updates:
> -disable CONFIG_ENV_OVERWRITE
> -add new hardware style variants and set the arch numbers appropriate 
> (autodet.)

LIne too long.

> -pass the serial# and hardware revision to the kernel
> -removed unused macros from include/configs/meesc.h
> 
> Signed-off-by: Daniel Gorsulowski 
...
> --- a/board/esd/meesc/meesc.c
> +++ b/board/esd/meesc/meesc.c
> @@ -156,8 +156,35 @@ int board_eth_init(bd_t *bis)
>  int checkboard(void)
>  {
>   char str[32];
> -
> - puts("Board: esd CAN-EtherCAT Gateway");
> + u_char hw_type; /* hardware type */
> +
> + /* read the "Type" register of the ET1100 controller */
> + hw_type = readb(CONFIG_ET1100_BASE);
> +
> + switch (hw_type) {
> + case 0x11:
> + case 0x3F:

Incorrect indentation - the "case" must have the same indent as the
"switch". Please fix globally.

> + /* ET1100 present,
> +arch number of MEESC-Board */

Incorrect multiline comment style. 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
Lots of people drink from the wrong bottle sometimes.
-- Edith Keeler, "The City on the Edge of Forever",
   stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] ppc/85xx: PIO Support for FSL eSDHC Controller Driver

2009-09-22 Thread Wolfgang Denk
Dear Dipen Dudhat,

In message <1252589856-4970-1-git-send-email-dipen.dud...@freescale.com> you 
wrote:
> On some Freescale SoC Internal DMA of eSDHC controller has bug.
> 
> So PIO Mode has introduced to do data transfer using CPU.
> In PIO mode data transfer performance will be degraded by a large extent.
> 
> Note: 
> In PIO mode multiple block read/write requires delay to complete the transfer.

Does that mean you just delay, i. e. you do not check for some ready
state?

...
> --- a/include/fsl_esdhc.h
> +++ b/include/fsl_esdhc.h
> @@ -86,6 +86,7 @@
>  #define PRSSTAT_CDPL (0x0004)
>  #define PRSSTAT_CINS (0x0001)
>  #define PRSSTAT_BREN (0x0800)
> +#define PRSSTAT_BWEN (0x0400)
>  #define PRSSTAT_DLA  (0x0004)
>  #define PRSSTAT_CICHB(0x0002)
>  #define PRSSTAT_CIDHB(0x0001)
> @@ -117,6 +118,7 @@
>  #define XFERTYP_DMAEN0x0001
>  
>  #define CINS_TIMEOUT 1000
> +#define MAX_TIMEOUT  10

MAX_TIMEOUT is a very generic name, please chose a more specific one
so interactions with other code are prevented. (Also, TIMEOUT itself
already means a maximum time, so MAX_TIMEOUT is a tautology.)

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
Very ugly or very beautiful women should be flattered on their
understanding, and mediocre ones on their beauty.
   -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH][v2] FDT: remove obsolete OF_CPU and OF_SOC macros.

2009-09-22 Thread Wolfgang Denk
Dear Marcel Ziswiler,

In message <1252523921.3643.8.ca...@com-21> you wrote:
> Signed-off-by: Marcel Ziswiler 
> ---
> Changes since v1:
> - CC all respective board maintainers
> 
>  README|6 --
>  include/configs/IDS8247.h |2 --
>  include/configs/MPC8260ADS.h  |1 -
>  include/configs/linkstation.h |2 --
>  include/configs/mgcoge.h  |2 --
>  include/configs/mpc7448hpc2.h |1 -
>  include/configs/muas3001.h|2 --
>  include/configs/stxxtc.h  |1 -
>  8 files changed, 4 insertions(+), 13 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
Oh, that sound of male ego.  You travel halfway across the galaxy and
it's still the same song.
-- Eve McHuron, "Mudd's Women", stardate 1330.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] document network driver framework

2009-09-22 Thread Wolfgang Denk
Dear Mike Frysinger,

In message <1252521682-5067-1-git-send-email-vap...@gentoo.org> you wrote:
> Signed-off-by: Mike Frysinger 
> ---
> v2
>   - drop CONFIG naming section
>   - fix MII documentation
> 
>  doc/README.drivers.eth |  177 
> 
>  1 files changed, 177 insertions(+), 0 deletions(-)
>  create mode 100644 doc/README.drivers.eth

Acked-by: Wolfgang Denk 

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
Virtue is a relative term.
-- Spock, "Friday's Child", stardate 3499.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH MAKEALL coldfire] : Fix start.S:Error: Conversionof PC relative displacement to absolute

2009-09-22 Thread Liew Tsi Chung-R5AAHP
Philippe,

The error that you encountered only happen when using linux cross
compiler; however, if choosing uclinux cross compiler this will not be
an issue.

Anyway, is an acked for me so that both compiler can be used without
causing the problem.

Best Regards,
TsiChung


-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
On Behalf Of Philippe De Muyter
Sent: Monday, September 21, 2009 2:49 PM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH MAKEALL coldfire] : Fix start.S:Error:
Conversionof PC relative displacement to absolute

Hi all,

This fixes the following errors when running MAKEALL for coldfire :
start.S: Assembler messages:
start.S:320: Error: Conversion of PC relative displacement to
absolute

Signed-off-by: Philippe De Muyter 

diff -ru a/cpu/mcf523x/start.S b/cpu/mcf523x/start.S
--- a/cpu/mcf523x/start.S   2009-09-17 23:28:31.0 +0200
+++ b/cpu/mcf523x/start.S   2009-09-21 19:58:34.0 +0200
@@ -246,7 +246,7 @@
 /* exception code */
.globl _fault
 _fault:
-   jmp _fault
+   bra _fault
.globl  _exc_handler
 
 _exc_handler:
diff -ru a/cpu/mcf52x2/start.S b/cpu/mcf52x2/start.S
--- a/cpu/mcf52x2/start.S   2009-09-17 23:28:31.0 +0200
+++ b/cpu/mcf52x2/start.S   2009-09-21 19:47:40.0 +0200
@@ -317,7 +317,7 @@
 /* exception code */
.globl _fault
 _fault:
-   jmp _fault
+   bra _fault
 
.globl  _exc_handler
 _exc_handler:
diff -ru a/cpu/mcf532x/start.S b/cpu/mcf532x/start.S
--- a/cpu/mcf532x/start.S   2009-09-17 23:28:31.0 +0200
+++ b/cpu/mcf532x/start.S   2009-09-21 19:50:36.0 +0200
@@ -256,7 +256,7 @@
 /* exception code */
.globl _fault
 _fault:
-   jmp _fault
+   bra _fault
.globl  _exc_handler
 
 _exc_handler:
___
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] Subject: [PATCH v3] mx27ads: add support for iMX27ADS board from Freescale

2009-09-22 Thread Wolfgang Denk
Dear Alan Carvalho de Assis,

In message <37367b3a0909151429h317066ax2efa504d83dbf...@mail.gmail.com> you 
wrote:
> This patch adds support to iMX27ADS development board. This board has
> 128MB RAM, 32MB NOR Flash and 128MB NAND Flash. Currently only
> booting from NOR is supported.
> 
> Signed-off-by: Alan Carvalho de Assis 

I will try and mention only the issues not yet covered.

...
> --- a/Makefile
> +++ b/Makefile
> @@ -2965,6 +2965,9 @@ davinci_dm365evm_config :   unconfig
>  imx27lite_config:unconfig
>   @$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27
> 
> +mx27ads_config : unconfig
> + @$(MKCONFIG) $(@:_config=) arm arm926ejs mx27ads freescale mx27
> +
>  lpd7a400_config \
>  lpd7a404_config: unconfig

Please keep list sorted.

> diff --git a/board/freescale/mx27ads/Makefile 
> b/board/freescale/mx27ads/Makefile
> new file mode 100644
> index 000..d142a9e
> --- /dev/null
> +++ b/board/freescale/mx27ads/Makefile
...
> +#
> +

Please don;t add trailing empty lines.

> diff --git a/board/freescale/mx27ads/config.mk
> b/board/freescale/mx27ads/config.mk
> new file mode 100644
> index 000..a2e7768
> --- /dev/null
> +++ b/board/freescale/mx27ads/config.mk
...
> +/*
> + * For clock initialization, see chapter 3 of the "MCIMX27 Multimedia
> + * Applications Processor Reference Manual, Rev. 0.2".
> + *
> + */

Please don't add random empty comment lines.

...
> + write32 0xAF00, 0x
> + write32 0xD8001000, 0xb210
> + ldr r0, =0xA033
> + mov r1, #0xda
> + strbr1, [r0]
> + ldr r0, =0xA100
> + mov r1, #0xff
> + strbr1, [r0]
> + write32 0xD8001000, 0x82226080
...
> + mov r10, lr
...
> + ldr r0, =CSCR
> + ldr r1, [r0]
> + bic r1, r1, #0x03
> + str r1, [r0]

Please use a consistent style for indentation. I suggest you use the
insn name followed by a single TAB character followed by args.


> +++ b/board/freescale/mx27ads/mx27ads.c
> @@ -0,0 +1,93 @@
...
...
> +# define __REG(x)  (*((volatile u32 *)(x)))
> +
> +#define IMX_CS4_BASE   0xD400
> +#define CS4U __REG(IMX_WEIM_BASE + 0x40) /* Chip Select 4 Upper Register
> */
> +#define CS4L __REG(IMX_WEIM_BASE + 0x44) /* Chip Select 4 Lower Register
> */
> +#define CS4A __REG(IMX_WEIM_BASE + 0x48) /* Chip Select 4 Addition Register 
> */

Please use proper I/O accessors. Direct register accesses like here
are forbidden. Also, you probably want to define a C structure
describing the register map.

...
> + /* Configure CPLD on CS4 */
> + CS4U = 0xDCF6;
> + CS4L = 0x444A4541;
> + CS4A = 0x3302;

Please never use suchmagic numbers in the code. Provide some #defines
for these, together with sufficient comments to explain what the
numbers mean.

> + /* Select FEC data through data path */
> + writew(0x0020, IMX_CS4_BASE + 0x10);
> +
> + /* Enable CPLD FEC data path */
> + writew(0x0010, IMX_CS4_BASE + 0x14);

Please use C structs for the register mapping; do not use base address
plus offsets.

> +int dram_init(void)
> +{
> +

No empty line here.

> +#if CONFIG_NR_DRAM_BANKS > 0
> + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> + gd->bd->bi_dram[0].size = get_ram_size((volatile void *)PHYS_SDRAM_1,
> + PHYS_SDRAM_1_SIZE);
> +#endif

Um... is CONFIG_NR_DRAM_BANKS <= 0 any configuration that is supposed
to work? 

> +#if CONFIG_NR_DRAM_BANKS > 1
> + gd->bd->bi_dram[1].start = PHYS_SDRAM_2;
> + gd->bd->bi_dram[1].size = get_ram_size((volatile void *)PHYS_SDRAM_2,
> + PHYS_SDRAM_2_SIZE);
> +#endif
> +
> + return 0;

You unconditionally return OK< even in case of memory errors? This
seems wrong to me.

> diff --git a/board/freescale/mx27ads/u-boot.lds
> b/board/freescale/mx27ads/u-boot.lds
> new file mode 100644
> index 000..f66f20e
> --- /dev/null
> +++ b/board/freescale/mx27ads/u-boot.lds

Does this board need a private linke rscript? Why cannot you use the
common script in cpu/arm926ejs/u-boot.lds ?

> diff --git a/include/configs/mx27ads.h b/include/configs/mx27ads.h
> new file mode 100644
> index 000..3360d76
> --- /dev/null
> +++ b/include/configs/mx27ads.h
...
> +/* memtest start address */
> +#define CONFIG_SYS_MEMTEST_START 0xA000
> +#define CONFIG_SYS_MEMTEST_END   0xA100  /* 16MB RAM 
> test */

Did you ever test this? Overwriting low memory where exception vectors
and such is located is probably a bad idea.

...
> +/* Use hardware sector protection */
> +#define CONFIG_SYS_FLASH_PROTECTION  1
> +#define CONFIG_SYS_MAX_FLASH_BANKS   1   /* max number of flash banks */
> +#define CONFIG_SYS_FLASH_SECT_SZ 0x2000  /* 8KB sect size Intel Flash */
> +/* end of flash */
> +#define CONFIG_ENV_OFFSET(PHYS_FLASH_SIZE - 0x2)
> +/* 

Re: [U-Boot] I am maintainer of Freescale i.MX

2009-09-22 Thread Wolfgang Denk
Dear Fred,

In message <2f495dc80909170830j7acdd1b0j4e4d27e60af06...@mail.gmail.com> you 
wrote:
>
>  I am u-boot maintainer of Freescale i.MX team.
>  I have two mail accounts:

Thanks for volunteering to become the custodian for the i.MX support
in U-Boot. 

Please send me your SSH private key, and I will set up a repository
for you.

> fanyef...@gmail.com and r01...@freescale.com.
>  I will use both of them.

That's fine. Your identification for the git repository is through
your SSH key. Which address do you prefer when sending mail to the
i.MX custodian?


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
Perl itself is  usually  pretty  good  about  telling  you  what  you
shouldn't do. :-) - Larry Wall in <11...@jpl-devvax.jpl.nasa.gov>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] Add support for Eukrea CPU9260/CPU9G20 SBC

2009-09-22 Thread Wolfgang Denk
Dear Eric Benard,

In message <1252167339-21415-1-git-send-email-e...@eukrea.com> you wrote:
> these boards are built around Atmel's AT91SAM9260/9G20 and have
> up to 64MB of NOR flash, up to 128MB of SDRAM, up to 2GB of NAND
> and include a 10/100 Ethernet PHY in RMII mode.
> 
> Signed-off-by: Eric Benard 
> ---
>  MAINTAINERS|5 +
>  MAKEALL|2 +
>  Makefile   |8 +
>  board/eukrea/cpu9260/Makefile  |   59 +
>  board/eukrea/cpu9260/config.mk |1 +
>  board/eukrea/cpu9260/cpu9260.c |  218 +
>  board/eukrea/cpu9260/led.c |  153 
>  cpu/arm926ejs/at91/lowlevel_init.S |3 +-
>  include/configs/cpu9260.h  |  453 
> 
>  9 files changed, 901 insertions(+), 1 deletions(-)
>  create mode 100644 board/eukrea/cpu9260/Makefile
>  create mode 100644 board/eukrea/cpu9260/config.mk
>  create mode 100644 board/eukrea/cpu9260/cpu9260.c
>  create mode 100644 board/eukrea/cpu9260/led.c
>  create mode 100644 include/configs/cpu9260.h
...
> index dd01b66..1d1ded4 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2863,6 +2863,14 @@ at91sam9rlek_config:   unconfig
>   fi;
>   @$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91
>  
> +CPU9G20_128M_config \
> +CPU9G20_config \
> +CPU9260_128M_config \
> +CPU9260_config   :   unconfig
> + @mkdir -p $(obj)include
> + @echo "#define CONFIG_$(@:_config=) 1" >$(obj)include/config.h
> + @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91
> +
>  meesc_config :   unconfig
>   @$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91

Please use the new "-t" option to mkconfig to simplify the Makefile
entry.

> +#ifdef CONFIG_CMD_NAND
> +static void cpu9260_nand_hw_init(void)
> +{
> + unsigned long csa;
> +
> + /* Enable CS3 */
> + csa = at91_sys_read(AT91_MATRIX_EBICSA);
> + at91_sys_write(AT91_MATRIX_EBICSA,
> +csa | AT91_MATRIX_CS3A_SMC_SMARTMEDIA);
> +
> + /* Configure SMC CS3 for NAND/SmartMedia */
> +#if defined(CONFIG_CPU9G20)
> + at91_sys_write(AT91_SMC_SETUP(3),
> +AT91_SMC_NWESETUP_(2) | AT91_SMC_NCS_WRSETUP_(0) |
> +AT91_SMC_NRDSETUP_(2) | AT91_SMC_NCS_RDSETUP_(0));
> + at91_sys_write(AT91_SMC_PULSE(3),
> +AT91_SMC_NWEPULSE_(4) | AT91_SMC_NCS_WRPULSE_(4) |
> +AT91_SMC_NRDPULSE_(4) | AT91_SMC_NCS_RDPULSE_(4));
> + at91_sys_write(AT91_SMC_CYCLE(3),
> +AT91_SMC_NWECYCLE_(7) | AT91_SMC_NRDCYCLE_(7));
> + at91_sys_write(AT91_SMC_MODE(3),
> +AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
> +AT91_SMC_EXNWMODE_DISABLE |
> +AT91_SMC_DBW_8 |
> +AT91_SMC_TDF_(3));
> +#elif defined(CONFIG_CPU9260)
> + at91_sys_write(AT91_SMC_SETUP(3),
> +AT91_SMC_NWESETUP_(1) | AT91_SMC_NCS_WRSETUP_(0) |
> +AT91_SMC_NRDSETUP_(1) | AT91_SMC_NCS_RDSETUP_(0));
> + at91_sys_write(AT91_SMC_PULSE(3),
> +AT91_SMC_NWEPULSE_(3) | AT91_SMC_NCS_WRPULSE_(3) |
> +AT91_SMC_NRDPULSE_(3) | AT91_SMC_NCS_RDPULSE_(3));
> + at91_sys_write(AT91_SMC_CYCLE(3),
> +AT91_SMC_NWECYCLE_(5) | AT91_SMC_NRDCYCLE_(5));
> + at91_sys_write(AT91_SMC_MODE(3),
> +AT91_SMC_READMODE | AT91_SMC_WRITEMODE |
> +AT91_SMC_EXNWMODE_DISABLE |
> +AT91_SMC_DBW_8 |
> +AT91_SMC_TDF_(2));
> +#endif

The code here looks the same to me, there are just minor differences
in the data. Please #define appropriate variables in the respective
board config files and get rid of the #if in this common file.

...
> +int board_init(void)
> +{
> + /* Enable Ctrlc */
> + console_init_f();
> +
> + /* arch number of the board */
> +#if defined(CONFIG_CPU9G20)
> + gd->bd->bi_arch_number = MACH_TYPE_CPUAT9260;
> +#elif defined(CONFIG_CPU9260)
> + gd->bd->bi_arch_number = MACH_TYPE_CPUAT9260;
> +#endif

Ditto here.

> +#ifdef CONFIG_RESET_PHY_R
> +void reset_phy(void)
> +{
> +#ifdef CONFIG_MACB
> + /*
> +  * Initialize ethernet HW addr prior to starting Linux,
> +  * needed for nfsroot
> +  */
> + eth_init(gd->bd);
> +#endif
> +}
> +#endif

Ethernet must not be unconditionally initilaized. Only when U-Boot
runs a network command it may do that, and then it should disable the
interface again before booting Linux. Please see the FAQ, and fix the
Linux driver issue in Linux.


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
No more blah, blah, blah!
-- Kirk, "Miri", stardate 27

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

2009-09-22 Thread Kumar Gala
The following changes since commit 3b6a9267f0de7b85d387fa4123d0b58379363447:
  Wolfgang Denk (1):
board/flagadm/flash.c: fix compile warning

are available in the git repository at:

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

Kumar Gala (15):
  ppc/85xx: Fix LCRR_CLKDIV defines
  ppc/85xx: Simplify the top makefile for 36-bit config for MPC8572DS
  ppc/85xx: Simplify the top makefile for 36-bit config for P2020DS
  ppc/85xx: Simplify the top makefile for P1_P2_RDB boards
  ppc/85xx: Clean up p1_p2_rdb PCI setup
  ppc/85xx: Clean up p2020ds PCI setup code
  ppc/85xx: Clean up mpc8572DS PCI setup code
  ppc/85xx: Clean up use of LAWAR defines
  ppc/p4080: Add p4080 platform immap definitions
  ppc/p4080: Add support for CoreNet style platform LAWs
  ppc/p4080: CoreNet platfrom style CCSRBAR setting
  ppc/p4080: CoreNet platfrom style secondary core release
  ppc/p4080: Add various p4080 related defines (and p4040)
  ppc/p4080: Handle timebase enabling and frequency reporting
  ppc/p4080: Determine various chip frequencies on CoreNet platforms

Mingkai Hu (4):
  ppc/85xx: simplify the top makefile for 36-bit config for mpc8536ds
  ppc/85xx: add ld script file for boot from NAND
  immap_85xx: add porpllsr's plat ratio definition
  ppc/85xx: add cpu init config file for boot from NAND

Paul Gortmaker (12):
  sbc8548: replace README with completely new document
  sbc8548: enable use of PCI network cards
  sbc8548: delete unused MPC8548CDS info carried over from port
  sbc8548: get_clock_freq is not valid for this board
  sbc8548: enable access to second bank of flash
  sbc8548: remove eTSEC3/4 voltage hack
  sbc8548: use I/O accessors
  sbc8548: correct local bus SDRAM size from 64M to 128M
  fsl_pci: create a SET_STD_PCI_INFO() helper wrapper
  sbc8548: update PCI/PCI-e support code
  sbc8548: allow enabling PCI via a make config option
  sbc85x0: tidy up Makefile to use new configuration script.

Peter Tyser (1):
  mpc8610hpcd: Use common 86xx fdt fixup code

Poonam Aggrwal (1):
  ppc/85xx: 32bit DDR changes for P1020/P1011

Vivek Mahajan (1):
  85xx-fdt: Fixed l2-ctlr's compatible prop for QorIQ

 MAKEALL   |4 +
 Makefile  |   66 ++-
 board/atum8548/law.c  |2 +-
 board/freescale/mpc8536ds/law.c   |6 +-
 board/freescale/mpc8540ads/law.c  |2 +-
 board/freescale/mpc8544ds/law.c   |6 +-
 board/freescale/mpc8560ads/law.c  |2 +-
 board/freescale/mpc8572ds/law.c   |6 +-
 board/freescale/mpc8572ds/mpc8572ds.c |  230 +++---
 board/freescale/mpc8610hpcd/mpc8610hpcd.c |   14 +--
 board/freescale/p1_p2_rdb/ddr.c   |   29 +++-
 board/freescale/p1_p2_rdb/law.c   |4 +-
 board/freescale/p1_p2_rdb/pci.c   |   42 ++--
 board/freescale/p2020ds/law.c |6 +-
 board/freescale/p2020ds/p2020ds.c |  150 +++---
 board/pm854/law.c |2 +-
 board/pm856/law.c |2 +-
 board/sbc8548/Makefile|4 +-
 board/sbc8548/law.c   |   12 +-
 board/sbc8548/sbc8548.c   |  305 ++---
 board/sbc8548/tlb.c   |   64 --
 board/socrates/law.c  |4 +-
 board/stx/stxgp3/law.c|2 +-
 board/stx/stxssa/law.c|2 +-
 board/xes/xpedite5200/law.c   |2 +-
 cpu/mpc85xx/Makefile  |1 +
 cpu/mpc85xx/cpu.c |   33 +++
 cpu/mpc85xx/cpu_init.c|   12 ++
 cpu/mpc85xx/cpu_init_early.c  |   29 +++
 cpu/mpc85xx/cpu_init_nand.c   |   63 ++
 cpu/mpc85xx/fdt.c |   15 +-
 cpu/mpc85xx/mp.c  |   68 +++-
 cpu/mpc85xx/speed.c   |   85 
 cpu/mpc85xx/u-boot-nand_spl.lds   |   67 +++
 cpu/mpc8xxx/cpu.c |4 +
 doc/README.sbc8548|  189 --
 drivers/misc/fsl_law.c|   98 +-
 drivers/pci/fsl_pci_init.c|2 +-
 include/asm-ppc/config.h  |6 +-
 include/asm-ppc/fsl_law.h |   31 +++
 include/asm-ppc/fsl_lbc.h |   12 ++
 include/asm-ppc/fsl_pci.h |   12 ++
 include/asm-ppc/immap_85xx.h  |  289 +--
 include/asm-ppc/mmu.h |9 +-
 include/asm-ppc/processor.h   |4 +
 include/configs/MPC8536DS.h   |2 +-
 include/configs/MPC8572DS.h   |4 +
 include/configs/P1_P2_RDB.h   |   13 ++
 include/configs/P2020DS.h 

Re: [U-Boot] [PATCH 0/3 v2] New MIIPHYBB implementation with multi-bus support

2009-09-22 Thread Ben Warren
Hi Luigi,

I like what you're doing here.  Thanks for working towards making the BB 
driver more universal.

Luigi 'Comio' Mantellini wrote:
> From: Luigi 'Comio' Mantellini 
>
> This patch rewrites the miiphybb ( Bit-banged MII bus driver ) in order to
> support an arbitrary number of buses. This feature is useful when your board
> uses different mii buses for different phys and all (or a part) of these buses
> are implemented via bit-banging mode.
>
> The driver requires that the following macros should be defined into the board
> configuration file:
>
> CONFIG_BITBANGMII   - Enable the miiphybb driver
> CONFIG_BITBANGMII_MULTI - Enable the multi bus support
>
> If the CONFIG_BITBANGMII_MULTI is not defined, the board's config file needs 
> to define
> the following macros:
>
>   
My preference would be to only support the 'multi' mode.  That way we 
can keep it smaller (source-wise, not binary-wise) and not use macros.
I'll give a more thorough review shortly, but just thought I'd put this 
idea out there...

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


Re: [U-Boot] [PATCH 4/4 v3] s5pc1xx: add support SMDKC100 board

2009-09-22 Thread Peter Tyser
> >>>
> >> Please include a brief readme doc/README.s5pc1xx similar to README.omap
> > 
> > Hi Tom,
> > Others may disagree, but I'm personally opposed to creating
> 
> Slugfest over documentation!

Nothing gets me more worked up than a documentation discussion:)

> I can see you point.  If you have the board you likely have the user manual.
> In no way do I want a user manual.
> 
> Mostly what I am looking for brief product description and a list of the
> configs.  Maybe some hints if the setup is tricky.  README.omap3 contains
> writeups on 6 boards, each get about 10 lines.

The README.omap3 looks decent, but even that I would personally have a
few issues with the following:
1. The list of omap3 boards is going to get out of date quickly when
people don't update README.omap3.  Eg devkit8000 already isn't in the
list:)

2. I still think the details of how to configure U-Boot for a board, use
the ecc commands, and gpio interfaces would still be better placed in a
User's Manual.  New users will use the User's Manual and experienced
users will know how to dig through the code - eg I'm not sure who will
reference README.omap3:).  Those command names and config names will
probably change at some point in the future, and there's a decent chance
README.omap3 won't be similarly updated.

> The vendor readme is also good if you want to convey board family u-boot
> interfaces to other developers.  See my writeup of omap gpio in omap3.

I see your point.  If it were me, I'd throw that documentation in the
omap3 gpio driver itself.  Its much more likely to be kept in sync when
code changes, and if someone is writing low-level U-Boot code, I'd hope
they'd be smart enough to track down the gpio driver they need to use.

> > board/vendor-specific doc/README. files in most cases.  My logic
> > is that the people that are compiling and using U-Boot on my company's
> > boards will have bought the boards from us, and we should be the ones
> > providing them documentation.  eg I would guess the vast majority of
> > board vendors don't say "for board information consult
> > doc/README. in the U-Boot source code", they provide a PDF, text
> > document, datasheet, etc about the board and how it can be used.  Thus
> > the doc/README. doesn't really provide any useful info.
> 
> This is doc/README.

OK, I missed that point.  SOC documentation does seem more fitting.  I
personally think low-level details shouldn't be in the SOC doc however.
For example, take a look at README.blackfin.  There's nothing I could
ever change about U-Boot which would require this file to be updated,
which is perfect!



> > I only care because I hate having to pick through 10 board-specific
> > README files every time I make a change the renames a command, adds a
> > new command, changes a CONFIG_XYZ name, etc:)
> > 
> 
> This should be the task of the board/soc maintainer.

I think this is debatable.  I'd guess most board maintainers don't
follow the list closely or care enough to monitor every change and
determine if they need to update their board's README file.  So if the
person making a large change doesn't update relevant READMEs, no one
will.  Eg, no one added devkit8000 to README.omap3.

> > I think README files are good in general, but board-specific details
> > should be documented elsewhere such as a product manual. 
> > 
> > Anyway, that's my $.02.
> 
> Taking it outside over documentation,

Best,
Peter

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


Re: [U-Boot] MPC83xx and uec

2009-09-22 Thread Ben Warren
Anton Vorontsov wrote:
> On Tue, Sep 22, 2009 at 04:03:16PM +0200, Joakim Tjernlund wrote:
> [...]
>   
> Also
>  drivers/qe/uec.h:int uec_initialize(bd_t *bis, uec_info_t *uec_info);
>  include/netdev.h:int uec_initialize(int index);
> different prototypes for the same function.
>   
 BTW, I am looking for a way to swap the order of ethernet interfaces:
 static uec_info_t uec_info[] = {
 #ifdef CONFIG_UEC_ETH1
STD_UEC_INFO(1),   /* UEC1 */
 #endif
 #ifdef CONFIG_UEC_ETH2
STD_UEC_INFO(2),   /* UEC2 */
 #endif
 #ifdef CONFIG_UEC_ETH3
STD_UEC_INFO(3),   /* UEC3 */
 #endif
 };
 
>>> Works for me:
>>>
>>> http://lists.denx.de/pipermail/u-boot/2009-September/060821.html
>>>   
>> Right, but I don't consider a include as this:
>>   +#include "../../../drivers/qe/uec.h"
>> as the correct way of getting of required data types and macros.
>> Consider that uec_initialize() is exported by netdev.h (although with the
>> wrong prototype ATM). As far as I can tell, I should only have to include
>> netdev.h to get the required types and macros.
>> 
>
> Not sure if having all-in-one netdev header is a good idea.
> It might be a good idea to move uec.h to "include/" though.
>
>   
This needs to be cleaned up.  THE prototype for the global initialize() 
function needs to be in netdev.h and nowhere else.

BTW - can't you effectively swap the order of the Ethernet interfaces at 
runtime using the 'ethprime' environment variable?

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


Re: [U-Boot] [PATCH] ppc/85xx: add cpu init config file for boot from NAND

2009-09-22 Thread Kumar Gala

On Sep 21, 2009, at 11:53 PM, Mingkai Hu wrote:

> When boot from NAND, the NAND flash must be connected to br/or0.
> Also init RAM(L2 SRAM or DDR SDRAM) for load the second image to
> it.
>
> Signed-off-by: Mingkai Hu 
> ---
>
> ChangeLog:
> - move the board specific config for br/or to board init file, i.e.
>   nand_spl/board/freescale/mpc8536ds/nand_boot.c, which make it common
>   for 85xx platform.
>
> cpu/mpc85xx/cpu_init_nand.c |   63 ++ 
> +
> 1 files changed, 63 insertions(+), 0 deletions(-)
> create mode 100644 cpu/mpc85xx/cpu_init_nand.c

applied to 85xx

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


Re: [U-Boot] [PATCH] immap_85xx: add porpllsr's plat ratio definition

2009-09-22 Thread Kumar Gala

On Sep 21, 2009, at 11:53 PM, Mingkai Hu wrote:

> Signed-off-by: Mingkai Hu 
> ---
> include/asm-ppc/immap_85xx.h |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)

applied to 85xx

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


Re: [U-Boot] [PATCH] ppc/85xx: add ld script file for boot from NAND

2009-09-22 Thread Kumar Gala

On Sep 21, 2009, at 11:53 PM, Mingkai Hu wrote:

> The first stage 4K image uses a seperate ld script file to
> generate 4K image. This patch moves it to the cpu/mpc85xx/*
> to make it avaliable for 85xx platform.
>
> Signed-off-by: Mingkai Hu 
> ---
>
> ChangeLog:
> - move from board specific directory to cpu/mpc85xx/*,
>   make it avalible for 85xx platform.
>
> cpu/mpc85xx/u-boot-nand_spl.lds |   67 ++ 
> +
> 1 files changed, 67 insertions(+), 0 deletions(-)
> create mode 100644 cpu/mpc85xx/u-boot-nand_spl.lds

applied to 85xx

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


Re: [U-Boot] [PATCH] mpc8610hpcd: Use common 86xx fdt fixup code

2009-09-22 Thread Kumar Gala

On Sep 21, 2009, at 9:09 PM, Peter Tyser wrote:

> Using the common 86xx fdt fixups removes some board-specific code and
> should make the mpc8610hpcd easier to maintain in the long run.
>
> Signed-off-by: Peter Tyser 
> ---
> board/freescale/mpc8610hpcd/mpc8610hpcd.c |   14 +-
> 2 files changed, 1 insertions(+), 14 deletions(-)

applied to 85xx

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


  1   2   >