Re: [U-Boot] U-boot environment on Sheevaplug

2009-09-08 Thread Prafulla Wadaskar
 

 -Original Message-
 From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] 
 Sent: Tuesday, August 25, 2009 1:00 PM
 To: U-Boot ML
 Cc: Prafulla Wadaskar; Nicolas Pitre
 Subject: Re: [U-Boot] U-boot environment on Sheevaplug
 
 Hi again!
 
 I just wanted to check if there has been any progress on the issue
 below (4-bit ECC support to read for the kernel / U-boot) during the
 summer.
 
 On Wed, 8 Jul 2009 15:59:27 +0200
 Simon Kagstrom simon.kagst...@netinsight.net wrote:
 
  Hi Prafulla (and the list)!
  
  I'm wondering a bit how Sheevaplug handles the U-boot 
 environment area.
  On OpenRD base it's stored on the NAND flash, and is protected by a
  4-bit ECC as required when read by the boot prom - it just goes
  together with the rest of the u-boot image.
  
  The Marvell-supplied 1.1.4 version has code to handle this 
 (basically
  switches to Reed-Solomon when reading/saving the 
 environment), but it
  doesn't work with upstream U-boot. If I disable ECC altogether (in
  kirkwood_nand.c) I can read the environment, but since 
 U-boot doesn't
  use Reed-Solomon, the soft ECC option doesn't cut it.
Hi Simon
As of now u-boot as well as Linux kernel supports only 1-bit ECC for Kirkwood.
There are efforts going on to make 4-bit ECC support available for Kirkwood on 
Linux.
Once this available, I will make it available on u-boot.

Meanwhile you can replace oob_softecc_kw with oob_softecc in openocd board 
config file to make it in sync with u-boot and kernel. This will ensure openocd 
to write NAND with 1-bit ECC.

Regards..
Prafulla . .

  
  
  Is the situation the same with sheevaplug? I see there are 
 patches for
  OpenOCD to handle the same thing there,
  

 http://lists.berlios.de/pipermail/openocd-development/2009-May
 /006413.html
  
  so perhaps something similar is bound for U-boot as well?
 
 // Simon
 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 2/2] mpc8536: simplify the top makefile for 36-bit config

2009-09-08 Thread Mingkai Hu
Signed-off-by: Mingkai Hu mingkai...@freescale.com
---
 Makefile|4 +---
 include/configs/MPC8536DS.h |2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index 0449a5b..901a336 100644
--- a/Makefile
+++ b/Makefile
@@ -2444,9 +2444,7 @@ ATUM8548_config:  unconfig
 
 MPC8536DS_36BIT_config \
 MPC8536DS_config:   unconfig
-   @mkdir -p $(obj)include
-   @echo #define CONFIG_$(@:_config=) 1  $(obj)include/config.h
-   @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale
+   @$(MKCONFIG) -n $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale
 
 MPC8540ADS_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx mpc8540ads freescale
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 4746e2e..6018858 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -27,7 +27,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#ifdef CONFIG_MPC8536DS_36BIT
+#ifdef CONFIG_MK_MPC8536DS_36BIT
 #define CONFIG_PHYS_64BIT  1
 #endif
 
-- 
1.6.4

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


Re: [U-Boot] [PATCH v2] ppc4xx: Rename compactcenter to intip

2009-09-08 Thread Stefan Roese
Hi Dirk,

On Wednesday 26 August 2009 09:08:26 Stefan Roese wrote:
  Signed-off-by: Dirk Eibach eib...@gdsys.de
  ---
  Changes since v1:
  - also changed config name
 
   Makefile|   16 
   include/configs/compactcenter.h |6 +++---
   2 files changed, 11 insertions(+), 11 deletions(-)
 
 I just noticed that when changing the config name, you also need to change
 this in MAKEALL and MAINTAINERS. And thinking further about it, you are now
 removing the target name compactcenter, but you keep the files
 compactcenter.h and the board directory board/gdsys/compactcenter. This
 seems inconsistent to me.

Any news on this?
 
Cheers,
Stefan

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


[U-Boot] Antw: Re: Interrupts in uboot with ARM AT91SAM9 (V2)

2009-09-08 Thread Manuel Sahm
Hello,

I´ve already inserted the following code:

In at91sam9g20ek.c:

void thread_test(void)
{
printf(RESET via INT\n);
}

in function :static void at91sam9g20ek_macb_hw_init (void)
{
...

at91_sys_write(AT91_RSTC_MR, AT91_RSTC_KEY | AT91_RSTC_URSTIEN);
// Reset Bit AT91_RSTC_URSTS
at91_sys_read(AT91_RSTC_SR);

at91_sys_write(AT91_PMC_PCER, 1  AT91_ID_SYS);
at91_sys_write(AT91_AIC_IDCR, 0x01  AT91_ID_SYS);
at91_sys_write(AT91_AIC_SVR(AT91_ID_SYS), (unsigned int)thread_test);
at91_sys_write(AT91_AIC_SMR(AT91_ID_SYS), 5 | AT91_AIC_SRCTYPE_LOW);
at91_sys_write(AT91_AIC_ICCR, 0x01  AT91_ID_SYS);
at91_sys_write(AT91_AIC_IECR, 0x01  AT91_ID_SYS);

.
}


 if I trigger my interrupt - the system hangsnothing is printed on
screen and I cańt enter anything in the prompt ?

Anything else that I have to add ???

Thanks very much...
Manuel


 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com 05.09.2009
02:49 
On 10:31 Thu 03 Sep , Manuel Sahm wrote:
 Hello,
  
 I have to use interrupts in UBoot 1.3.4 - how could I enable them ?
  
 I have an AT91SAM9G20 - in ist header file I enable CONFIG_USE_IRQ
und
 uncomment the lines#ifdefc CONFIG_USE_IRQ #error  #endif.
 I inserted the lines:
 #define CONFIG_STACKSIZE_IRQ (4*1024)
 #define CONFIG_STACKSIZE_FIQ (4*1024)
  
 
 In the file (/lib_amr/interrupts.c) I have to insert a function
called
 do_irq().
 I inserted:
  
 void do_irq(struct pt_regs* pt_regs)
 {
  printf(interrupt request\n);
  show_regs(pt_regs);
  bad_mode();
 }
  
 When UBOOT starts all seems to be OK, but if I trigger my interrupt
-
 the system hangsnothing is printed on screen anmd I cańt enter
 anything in the prompt ?
  
 Could you please help me ?
you need to clear the interrupt and add the at91 interrupt controller
to use it

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


Re: [U-Boot] [PATCH] amcc-common.h: Use filenames from environment variables for update procedure.

2009-09-08 Thread Stefan Roese
On Wednesday 02 September 2009 17:24:57 Detlev Zundel wrote:
 Using a separate u-boot environment variable allows to easily
 specify different filenames for the update procedure.  This is also in
 line with many other board configurations defining an update script.

Applied to ppc4xx. Thanks.

Cheers,
Stefan

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


Re: [U-Boot] [PATCH] ppc4xx: Fix PMC405DE support

2009-09-08 Thread Stefan Roese
On Friday 04 September 2009 10:37:04 Matthias Fuchs wrote:
 This patch fixes PMC405DE support. Patch 85d6bf0b fixed out-of-tree
 building for this board but the loadpci object did not get linked
 after that.

Applied to ppc4xx. Thanks.

Cheers,
Stefan

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


Re: [U-Boot] [PATCH 1/2] ppc4xx: Allow overwriting pci target registers for all 4xx boards

2009-09-08 Thread Stefan Roese
On Monday 07 September 2009 17:00:40 Matthias Fuchs wrote:
 This patch adds the CONFIG_PCI_4xx_PTM_OVERWRITE option and replaces
 the ugly 'if defined(BOARD1) || ... || defined(BOARDn)' construct
 in 4xx pci code.
 
 When CONFIG_PCI_4xx_PTM_OVERWRITE is defined the default ptm register
 setup can be overwritten through environment variables ptm1la, ptm1ms,
 ptm2la and ptm2ms to do application specific pci target BAR configuration.

Applied to ppc4xx. Thanks.

Cheers,
Stefan

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


Re: [U-Boot] [PATCH 2/2] ppc4xx: Add CONFIG_PCI_4xx_PTM_OVERWRITE to some esd 4xx boards

2009-09-08 Thread Stefan Roese
On Monday 07 September 2009 17:00:41 Matthias Fuchs wrote:
 Signed-off-by: Matthias Fuchs matthias.fu...@esd.eu

Applied to ppc4xx. Thanks.

Cheers,
Stefan

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



Re: [U-Boot] [PATCH] ppc4xx: Fix compilation warning in 4xx miiphy.c

2009-09-08 Thread Stefan Roese
On Monday 07 September 2009 13:08:35 Stefan Roese wrote:
 This patch fixes the following compilation warning:
 
 miiphy.c: In function 'emac4xx_miiphy_read':
 miiphy.c:353: warning: dereferencing type-punned pointer will break
 strict-aliasing rules

Applied to ppc4xx. Thanks.

Cheers,
Stefan

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


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

2009-09-08 Thread Stefan Roese
The following changes since commit 0052a051f60a043f1730b3a46f23b3c7b0eb7820:
  Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-i2c

are available in the git repository at:

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

Detlev Zundel (1):
  amcc-common.h: Use filenames from environment variables for update 
procedure.

Matthias Fuchs (3):
  ppc4xx: Fix PMC405DE support
  ppc4xx: Allow overwriting pci target registers for all 4xx boards
  ppc4xx: Add CONFIG_PCI_4xx_PTM_OVERWRITE to some esd 4xx boards

Stefan Roese (1):
  ppc4xx: Fix compilation warning in 4xx miiphy.c

 board/esd/pmc405de/Makefile   |5 -
 cpu/ppc4xx/4xx_pci.c  |4 ++--
 cpu/ppc4xx/miiphy.c   |2 +-
 include/configs/CPCI405.h |2 ++
 include/configs/CPCI4052.h|2 ++
 include/configs/CPCI405AB.h   |2 ++
 include/configs/CPCI405DT.h   |2 ++
 include/configs/PMC405.h  |2 ++
 include/configs/PMC405DE.h|2 ++
 include/configs/amcc-common.h |8 +---
 10 files changed, 24 insertions(+), 7 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] PPC440GX: DDR ECC init time.

2009-09-08 Thread Stefan Roese
Hi Felix,

On Tuesday 08 September 2009 11:19:41 Felix Radensky wrote:
 Not exactly related to the subject under discussion, but I thought I'd
 mention it.
 
 I had problems with ecc_init() on a custom 460EX board with soldered DDR2.
 Right after ecc_init() u-boot was crashing on PLB access. I've modified
 the code
 to use program_ecc_addr() instead of ecc_init(), and problem was solved.
 I was
 wandering why use two different ECC initialization routines for SPD and
 soldered
 cases, when program_ecc_addr() can do the job in both cases, while
 ecc_init()
 apparently has issues ?

Most likely historic reasons. I added Grant Erickson to Cc, IIRC he 
added/tested this ecc_init() code. Maybe he can shed some more light into 
this.

But from looking at it, it seems to me that we should get rid of one of those 
routines. program_ecc_addr() seems more generic to me. Patches welcome. ;)

Thanks.

Cheers,
Stefan

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


[U-Boot] u-boot-1.3.4 porting problem

2009-09-08 Thread 王培养
hi all,
u-boot-1.3.4,which was ported to my board S3C44B0.
now what I got from serial:

U-boot-1.3.4
DRAM:8M
FLASH:2M

after tracing functions by using printf command,I found the problem was 
devlist=NULL.
then I went deep,found the function NewHandle ,whitch is related to Create 
empty List.
It returned NULL ,and the problem is command calloc.
 
any help is appreciated.
 
regards,
Juan


  ___ 
  好玩贺卡等你发,邮箱贺卡全新上线! 
http://card.mail.cn.yahoo.com/___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] PPC440GX: DDR ECC init time.

2009-09-08 Thread Stefan Roese
Felix,

On Tuesday 08 September 2009 12:05:30 Felix Radensky wrote:
  Most likely historic reasons. I added Grant Erickson to Cc, IIRC he
  added/tested this ecc_init() code. Maybe he can shed some more light into
  this.
 
  But from looking at it, it seems to me that we should get rid of one of
  those routines. program_ecc_addr() seems more generic to me. Patches
  welcome. ;)
 
 OK, unless Grant objects I'll try to cook up a patch, most probably next
 week.
 I have 405EX and 460EX boards with ECC enabled soldered DDR2, so
 I'll be able to test these cases. It would be great if someone could
 test SPD case,
 to see that I didn't break anything.

Great. I'll test it on Katmai (440SPe DDR2 with ECC enabled).

Thanks. 

Cheers,
Stefan

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


Re: [U-Boot] u-boot-1.3.4 porting problem

2009-09-08 Thread Wolfgang Denk
Dear =?utf-8?B?546L5Z+55YW7ICA=?=,

In message 131396.27983...@web92206.mail.cnh.yahoo.com you wrote:

 u-boot-1.3.4,which was ported to my board S3C44B0.

U-Boot 1.3.4 is more than a year old - we had 5 official releases
since. Please consider U-Boot 1.3.4 unsupporeted and upodate to recent
code (U-Boot v2009.08).

 now what I got from serial:
 
 U-boot-1.3.4
 DRAM:8M
 FLASH:2M
 
 after tracing functions by using printf command,I found the problem was 
 devlist=NULL.
 then I went deep,found the function NewHandle ,whitch is related to Create 
 empty List.
 It returned NULL ,and the problem is command calloc.

You misunderstand. calloc is not the problem, but just the victim.

 any help is appreciated.

Most probably your RAM initalization is broken, and U-Boot crashes
when staring to run from RAM.

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
Q:  How many DEC repairman does it take to fix a flat ?
A:  Five; four to hold the car up and one to swap tires.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] Merging u-boot-s3c24xx with u-boot-samsung

2009-09-08 Thread Wolfgang Denk
Dear Harald,

in the context of splitting the ARM architecure into vendor-related
sub-repositories an new u-boot-samsung.git repository has been
created; it seems to make sense to merge the older u-boot-s3c24xx
repository into this one.

As you're the custodian for the u-boot-s3c24xx repository I would like
to hear your opinion about this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A person with one watch knows what time it  is;  a  person  with  two
watches is never sure.   Proverb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] TI DaVinci: DM355: Config Cleanup

2009-09-08 Thread s-paulraj
From: Sandeep Paulraj s-paul...@ti.com

This patch does the following
1) The config no longer uses the asm/sizes.h header file
2) Replaces references of SZ_xx with the equivalent values
3) Enables Bootdelay
4) We now have a safe place to save the environment variables

Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
The sizes.h still has the All rights reserved phrase so it might
not be part of the repository in the near future and Wolfgang also does
not like the SZ_xx references. So just getting rid of this dependency.
 include/configs/davinci_dm355evm.h |   25 ++---
 1 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/include/configs/davinci_dm355evm.h 
b/include/configs/davinci_dm355evm.h
index c35f5c9..baa2704 100644
--- a/include/configs/davinci_dm355evm.h
+++ b/include/configs/davinci_dm355evm.h
@@ -19,7 +19,6 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
-#include asm/sizes.h
 
 /* Spectrum Digital TMS320DM355 EVM board */
 #define DAVINCI_DM355EVM
@@ -40,7 +39,7 @@
 /* Memory Info */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0x8000
-#define PHYS_SDRAM_1_SIZE  SZ_128M
+#define PHYS_SDRAM_1_SIZE  0x0800
 
 /* Serial Driver info: UART0 for console  */
 #define CONFIG_SYS_NS16550
@@ -66,9 +65,11 @@
 #define CONFIG_SYS_I2C_SLAVE   0x10/* SMBus host address */
 
 /* NAND: socketed, two chipselects, normally 2 GBytes */
-/* NYET -- #define CONFIG_NAND_DAVINCI */
+#define CONFIG_NAND_DAVINCI
 #define CONFIG_SYS_NAND_HW_ECC
 #define CONFIG_SYS_NAND_USE_FLASH_BBT
+#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+#define CONFIG_SYS_NAND_PAGE_2K
 
 #define CONFIG_SYS_NAND_LARGEPAGE
 #define CONFIG_SYS_NAND_BASE_LIST  { 0x0200, }
@@ -96,15 +97,12 @@
 #ifdef CONFIG_NAND_DAVINCI
 #define CONFIG_CMD_MTDPARTS
 #define CONFIG_MTD_PARTITIONS
+#define CONFIG_MTD_DEVICE
 #define CONFIG_CMD_NAND
 #define CONFIG_CMD_UBI
 #define CONFIG_RBTREE
 #endif
 
-/* TEMPORARY -- no safe place to save env, yet */
-#define CONFIG_ENV_IS_NOWHERE
-#undef CONFIG_CMD_SAVEENV
-
 #ifdef CONFIG_USB_DAVINCI
 #define CONFIG_MUSB_HCD
 #define CONFIG_CMD_USB
@@ -130,9 +128,14 @@
 #define CONFIG_SYS_PROMPT_HUSH_PS2  
 #define CONFIG_SYS_LONGHELP
 
-#define CONFIG_ENV_SIZESZ_16K
+#ifdef CONFIG_NAND_DAVINCI
+#define CONFIG_ENV_SIZE0x0004
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_OFFSET  0x3C
+#undef CONFIG_ENV_IS_IN_FLASH
+#endif
 
-/* NYET -- #define CONFIG_BOOTDELAY5 */
+#define CONFIG_BOOTDELAY   5
 #define CONFIG_BOOTCOMMAND \
dhcp;bootm
 #define CONFIG_BOOTARGS \
@@ -146,8 +149,8 @@
 #define CONFIG_NET_RETRY_COUNT 10
 
 /* U-Boot memory configuration */
-#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
-#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc() arena */
+#define CONFIG_STACKSIZE   0x0004  /* regular stack */
+#define CONFIG_SYS_MALLOC_LEN  0x0008  /* malloc() arena */
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* for initial data */
 #define CONFIG_SYS_MEMTEST_START   0x8700  /* physical address */
 #define CONFIG_SYS_MEMTEST_END 0x8800  /* test 16MB RAM */
-- 
1.6.0.4

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


[U-Boot] [PATCH] TI DaVinci: DM365: Minor Updates to DM365 EVM

2009-09-08 Thread s-paulraj
From: Sandeep Paulraj s-paul...@ti.com

The patch does the following
1) Gets rid of dependency on asm/sizes.h and replaces references
to SZ_xx with their equivalent values
2) Disables EMAC as the EMAC is broken due to recent changes that have been
added to the net driver. Board does not compile with this enabled
Patch to add EMAC will be sent to u-boot-net soon.


Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
 board/davinci/dm365evm/dm365evm.c  |2 +-
 include/configs/davinci_dm365evm.h |   12 +---
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/board/davinci/dm365evm/dm365evm.c 
b/board/davinci/dm365evm/dm365evm.c
index e30184b..1c88b30 100644
--- a/board/davinci/dm365evm/dm365evm.c
+++ b/board/davinci/dm365evm/dm365evm.c
@@ -17,7 +17,7 @@
 
 #include common.h
 #include nand.h
-#include linux/io.h
+#include asm/io.h
 #include asm/arch/hardware.h
 #include asm/arch/emif_defs.h
 #include asm/arch/nand_defs.h
diff --git a/include/configs/davinci_dm365evm.h 
b/include/configs/davinci_dm365evm.h
index 47cb554..e74f27a 100644
--- a/include/configs/davinci_dm365evm.h
+++ b/include/configs/davinci_dm365evm.h
@@ -18,7 +18,6 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
-#include asm/sizes.h
 
 /* Spectrum Digital TMS320DM365 EVM board */
 #define DAVINCI_DM365EVM
@@ -38,7 +37,7 @@
 /* Memory Info */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0x8000
-#define PHYS_SDRAM_1_SIZE  SZ_128M
+#define PHYS_SDRAM_1_SIZE  0x0800
 
 /* Serial Driver info: UART0 for console  */
 #define CONFIG_SYS_NS16550
@@ -57,7 +56,7 @@
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS  20
 
 /* Network Configuration */
-#define CONFIG_DRIVER_TI_EMAC
+/* NYET: #define CONFIG_DRIVER_TI_EMAC */
 #define CONFIG_MII
 #define CONFIG_BOOTP_DEFAULT
 #define CONFIG_BOOTP_DNS
@@ -74,7 +73,6 @@
 
 /* NAND: socketed, two chipselects, normally 2 GBytes */
 #define CONFIG_NAND_DAVINCI
-#define CONFIG_SYS_NAND_HW_ECC
 #define CONFIG_SYS_NAND_USE_FLASH_BBT
 #define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
 #define CONFIG_SYS_NAND_PAGE_2K
@@ -125,7 +123,7 @@
 #define CONFIG_SYS_LONGHELP
 
 #ifdef CONFIG_NAND_DAVINCI
-#define CONFIG_ENV_SIZESZ_256K
+#define CONFIG_ENV_SIZE0x0004
 #define CONFIG_ENV_IS_IN_NAND
 #define CONFIG_ENV_OFFSET  0x3C
 #undef CONFIG_ENV_IS_IN_FLASH
@@ -143,8 +141,8 @@
 #define CONFIG_TIMESTAMP
 
 /* U-Boot memory configuration */
-#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
-#define CONFIG_SYS_MALLOC_LEN  SZ_1M   /* malloc() arena */
+#define CONFIG_STACKSIZE   0x0004  /* regular stack */
+#define CONFIG_SYS_MALLOC_LEN  0x0008  /* malloc() arena */
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* for initial data */
 #define CONFIG_SYS_MEMTEST_START   0x8700  /* physical address */
 #define CONFIG_SYS_MEMTEST_END 0x8800  /* test 16MB RAM */
-- 
1.6.0.4

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


Re: [U-Boot] All rights reserved in drivers/mtd/nand/nand_util.c

2009-09-08 Thread Paulraj, Sandeep
I don't think we received a patch.

How are we moving forward as this is required for the NAND driver to work.

Thanks,
Sandeep


 Hi Guido,
 
 A while back you added nand_util.c to U-Boot, with a copyright statement
   of Copyright (C) 2006 by Weiss-Electronic GmbH.  All rights reserved.
 
 At best the All rights reserved clause is meaningless, and at worst it
 is in conflict with the statement that the code is licensed under the
 GPL.  Wolfgang Denk has taken the latter interpretation, and is
 threatening to remove code from the repository that contains this phrase.
 
 Are you authorized to remove the All rights reserved clause on behalf
 of Weiss-Electronic GmbH?  If so, please submit a patch doing so.  If
 not, and you can't find someone who can, it looks like we'll have to
 replace the code.
 
 Thanks,
 Scott

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


Re: [U-Boot] [PATCH] TQM85xx: enable partition support, sort commands

2009-09-08 Thread Kumar Gala

On Sep 2, 2009, at 3:20 AM, Wolfgang Denk wrote:

 Signed-off-by: Wolfgang Denk w...@denx.de
 ---
 include/configs/TQM85xx.h |   18 +++---
 1 files changed, 11 insertions(+), 7 deletions(-)

This breaks building of TQM85xx boards for me.

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


[U-Boot] [PATCH][v1] r7780mp: fix typo in Ethernet chip model number comment.

2009-09-08 Thread Marcel Ziswiler
---
 include/configs/r7780mp.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/r7780mp.h b/include/configs/r7780mp.h
index 7738a17..71c570e 100644
--- a/include/configs/r7780mp.h
+++ b/include/configs/r7780mp.h
@@ -154,7 +154,7 @@
 #define CONFIG_NET_MULTI
 #define CONFIG_RTL8169
 */
-/* AX88696L Support(NE2000 base chip) */
+/* AX88796L Support(NE2000 base chip) */
 #define CONFIG_DRIVER_NE2000
 #define CONFIG_DRIVER_AX88796L
 #define CONFIG_DRIVER_NE2000_BASE  0xA410
-- 
1.6.0.4



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


[U-Boot] [PATCH][v1] muas3001: remove BRG clock node fixup to use common mpc8260 code.

2009-09-08 Thread Marcel Ziswiler
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
 board/muas3001/muas3001.c |   16 
 1 files changed, 0 insertions(+), 16 deletions(-)

diff --git a/board/muas3001/muas3001.c b/board/muas3001/muas3001.c
index 8f83dd9..bf4ccb6 100644
--- a/board/muas3001/muas3001.c
+++ b/board/muas3001/muas3001.c
@@ -310,7 +310,6 @@ void ft_blob_update (void *blob, bd_t *bd)
int ret, nodeoffset = 0;
ulong memory_data[2] = {0};
ulong flash_data[4] = {0};
-   ulong freq = 0;
ulong   speed = 0;
 
memory_data[0] = cpu_to_be32 (bd-bi_memstart);
@@ -359,21 +358,6 @@ void ft_blob_update (void *blob, bd_t *bd)
err:%s\n, fdt_strerror (nodeoffset));
}
 
-   /* brg clock */
-   nodeoffset = fdt_path_offset (blob, /soc/cpm/brg);
-   if (nodeoffset = 0) {
-   freq = cpu_to_be32 (bd-bi_brgfreq);
-   ret = fdt_setprop (blob, nodeoffset, clock-frequency, freq,
-   sizeof (unsigned long));
-   if (ret  0)
-   printf (ft_blob_update): cannot set 
/soc/cpm/brg/clock-frequency 
-   property err:%s\n, fdt_strerror (ret));
-   } else {
-   /* memory node is required in dts */
-   printf (ft_blob_update(): cannot find 
/soc/cpm/brg/clock-frequency node 
-   err:%s\n, fdt_strerror (nodeoffset));
-   }
-
/* baudrate */
nodeoffset = fdt_path_offset (blob, /soc/cpm/serial);
if (nodeoffset = 0) {
-- 
1.6.0.4



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


[U-Boot] [PATCH][v1] r7780mp: fix typo in Ethernet chip model number comment.

2009-09-08 Thread Marcel Ziswiler
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
 include/configs/r7780mp.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/r7780mp.h b/include/configs/r7780mp.h
index 7738a17..71c570e 100644
--- a/include/configs/r7780mp.h
+++ b/include/configs/r7780mp.h
@@ -154,7 +154,7 @@
 #define CONFIG_NET_MULTI
 #define CONFIG_RTL8169
 */
-/* AX88696L Support(NE2000 base chip) */
+/* AX88796L Support(NE2000 base chip) */
 #define CONFIG_DRIVER_NE2000
 #define CONFIG_DRIVER_AX88796L
 #define CONFIG_DRIVER_NE2000_BASE  0xA410
-- 
1.6.0.4



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


[U-Boot] [PATCH][v1] mpc8260: remove Ethernet node fixup to use generic FDT code.

2009-09-08 Thread Marcel Ziswiler
Remove Ethernet node fixup from mgcoge and muas3001 boards and modify its
configs for the common mpc8260 code to use generic Ethernet fixup.

Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
 board/keymile/mgcoge/mgcoge.c |5 -
 board/muas3001/muas3001.c |   15 ---
 include/configs/mgcoge.h  |1 +
 include/configs/muas3001.h|1 +
 4 files changed, 2 insertions(+), 20 deletions(-)

diff --git a/board/keymile/mgcoge/mgcoge.c b/board/keymile/mgcoge/mgcoge.c
index d24a4b5..b16a01c 100644
--- a/board/keymile/mgcoge/mgcoge.c
+++ b/board/keymile/mgcoge/mgcoge.c
@@ -25,7 +25,6 @@
 #include mpc8260.h
 #include ioports.h
 #include malloc.h
-#include net.h
 #include asm/io.h
 
 #if defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_OF_LIBFDT)
@@ -373,10 +372,6 @@ void ft_blob_update (void *blob, bd_t *bd)
flash_reg[5] = cpu_to_be32 (info-size);
fdt_set_node_and_value (blob, /localbus/fl...@5,0, reg, flash_reg,
sizeof (flash_reg));
-
-   /* MAC addr */
-   fdt_set_node_and_value (blob, /soc/cpm/ethernet, mac-address,
-   bd-bi_enetaddr, sizeof (u8) * 6);
 }
 
 void ft_board_setup (void *blob, bd_t *bd)
diff --git a/board/muas3001/muas3001.c b/board/muas3001/muas3001.c
index bf4ccb6..36caed8 100644
--- a/board/muas3001/muas3001.c
+++ b/board/muas3001/muas3001.c
@@ -342,21 +342,6 @@ void ft_blob_update (void *blob, bd_t *bd)
printf (ft_blob_update(): cannot find /localbus node 
err:%s\n, fdt_strerror (nodeoffset));
}
-   /* MAC Adresse */
-   nodeoffset = fdt_path_offset (blob, /soc/cpm/ethernet);
-   if (nodeoffset = 0) {
-   uchar ethaddr[6];
-   eth_getenv_enetaddr(ethaddr, ethaddr);
-   ret = fdt_setprop (blob, nodeoffset, mac-address, ethaddr,
-   sizeof (uchar) * 6);
-   if (ret  0)
-   printf (ft_blob_update): cannot set 
/soc/cpm/ethernet/mac-address 
-   property err:%s\n, fdt_strerror (ret));
-   } else {
-   /* memory node is required in dts */
-   printf (ft_blob_update(): cannot find /soc/cpm/ethernet node 
-   err:%s\n, fdt_strerror (nodeoffset));
-   }
 
/* baudrate */
nodeoffset = fdt_path_offset (blob, /soc/cpm/serial);
diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h
index 99ac8c1..55d1fc9 100644
--- a/include/configs/mgcoge.h
+++ b/include/configs/mgcoge.h
@@ -70,6 +70,7 @@
 #define CONFIG_NET_MULTI   1
 
 #define CONFIG_ETHER_INDEX 4
+#define CONFIG_HAS_ETH0
 #define CONFIG_SYS_SCC_TOUT_LOOP   1000
 
 # define CONFIG_SYS_CMXSCR_VALUE   (CMXSCR_RS4CS_CLK7 | CMXSCR_TS4CS_CLK8)
diff --git a/include/configs/muas3001.h b/include/configs/muas3001.h
index f2d117c..c94daa3 100644
--- a/include/configs/muas3001.h
+++ b/include/configs/muas3001.h
@@ -74,6 +74,7 @@
 
 #define CONFIG_ETHER_INDEX 1
 #define CONFIG_ETHER_ON_FCC1
+#define CONFIG_HAS_ETH0
 #define FCC_ENET
 
 /*
-- 
1.6.0.4



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


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

2009-09-08 Thread Marcel Ziswiler
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
 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(-)

diff --git a/README b/README
index ff4ed8b..3cb7786 100644
--- a/README
+++ b/README
@@ -368,8 +368,10 @@ The following options need to be configured:
 * Adds the fdt command
 * The bootm command automatically updates the fdt
 
-   OF_CPU - The proper name of the cpus node.
-   OF_SOC - The proper name of the soc node.
+   OF_CPU - The proper name of the cpus node (only required for
+   MPC512X and MPC5xxx based boards).
+   OF_SOC - The proper name of the soc node (only required for
+   MPC512X and MPC5xxx based boards).
OF_TBCLK - The timebase frequency.
OF_STDOUT_PATH - The path to the console device
 
diff --git a/include/configs/IDS8247.h b/include/configs/IDS8247.h
index 4c4af05..147a8b2 100644
--- a/include/configs/IDS8247.h
+++ b/include/configs/IDS8247.h
@@ -125,8 +125,6 @@
 #define CONFIG_OF_LIBFDT   1
 #define CONFIG_OF_BOARD_SETUP  1
 
-#define OF_CPU PowerPC,8...@0
-#define OF_SOC s...@f000
 #define OF_TBCLK   (bd-bi_busfreq / 4)
 #define OF_STDOUT_PATH /s...@f000/serial8...@e0008000
 
diff --git a/include/configs/MPC8260ADS.h b/include/configs/MPC8260ADS.h
index 942a4cc..677a143 100644
--- a/include/configs/MPC8260ADS.h
+++ b/include/configs/MPC8260ADS.h
@@ -209,7 +209,6 @@
 #define CONFIG_OF_LIBFDT   1
 #define CONFIG_OF_BOARD_SETUP  1
 #if defined(CONFIG_OF_LIBFDT)
-#define OF_CPU c...@0
 #define OF_TBCLK   (bd-bi_busfreq / 4)
 #endif
 
diff --git a/include/configs/linkstation.h
b/include/configs/linkstation.h
index 2feb3ae..16b464c 100644
--- a/include/configs/linkstation.h
+++ b/include/configs/linkstation.h
@@ -96,8 +96,6 @@
 
 #define CONFIG_OF_LIBFDT   1
 
-#define OF_CPU PowerPC,603e
-#define OF_SOC soc...@8000
 #define OF_STDOUT_PATH /soc10x/ser...@80004600
 
 /* this must be included AFTER the definition of CONFIG_COMMANDS (if
any) */
diff --git a/include/configs/mgcoge.h b/include/configs/mgcoge.h
index ea14948..99ac8c1 100644
--- a/include/configs/mgcoge.h
+++ b/include/configs/mgcoge.h
@@ -346,8 +346,6 @@
 #define CONFIG_OF_LIBFDT   1
 #define CONFIG_OF_BOARD_SETUP  1
 
-#define OF_CPU PowerPC,8...@0
-#define OF_SOC s...@f000
 #define OF_TBCLK   (bd-bi_busfreq / 4)
 #define OF_STDOUT_PATH /soc/cpm/ser...@11a90
 
diff --git a/include/configs/mpc7448hpc2.h
b/include/configs/mpc7448hpc2.h
index 4f98ba4..be12186 100644
--- a/include/configs/mpc7448hpc2.h
+++ b/include/configs/mpc7448hpc2.h
@@ -79,7 +79,6 @@
 #define CONFIG_OF_LIBFDT   1
 #define CONFIG_OF_BOARD_SETUP  1
 
-#define OF_CPU PowerPC,7...@0
 #define OF_TSI tsi...@c000
 #define OF_TBCLK   (bd-bi_busfreq / 8)
 #define OF_STDOUT_PATH /tsi...@c000/ser...@7808
diff --git a/include/configs/muas3001.h b/include/configs/muas3001.h
index f031a17..f2d117c 100644
--- a/include/configs/muas3001.h
+++ b/include/configs/muas3001.h
@@ -404,8 +404,6 @@
 #define CONFIG_OF_LIBFDT   1
 #define CONFIG_OF_BOARD_SETUP  1
 
-#define OF_CPU PowerPC,8...@0
-#define OF_SOC s...@f000
 #define OF_TBCLK   (bd-bi_busfreq / 4)
 #if defined(CONFIG_MUAS_DEV_BOARD)
 #define OF_STDOUT_PATH /soc/cpm/ser...@11a90
diff --git a/include/configs/stxxtc.h b/include/configs/stxxtc.h
index d16262b..5854366 100644
--- a/include/configs/stxxtc.h
+++ b/include/configs/stxxtc.h
@@ -509,7 +509,6 @@ typedef unsigned int led_id_t;
 /* pass open firmware flattened device tree */
 #define CONFIG_OF_LIBFDT   1
 
-#define OF_CPU PowerPC,mpc...@0
 #define OF_TBCLK   (MPC8XX_HZ / 16)
 
 #endif /* __CONFIG_H */
-- 
1.6.0.4



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


Re: [U-Boot] [PATCH v1 1/2] mkconfig: pass the board name to board config file

2009-09-08 Thread Kumar Gala

On Sep 8, 2009, at 2:07 AM, Mingkai Hu wrote:

 then we can handle the different config target in the board file,
 which simplify the top makefile for board that have multiple config
 targets.

 Signed-off-by: Mingkai Hu mingkai...@freescale.com
 ---
 mkconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

Wolfgang,

I'll pick up the second patch once you apply this one.

- k


 diff --git a/mkconfig b/mkconfig
 index b0bbbd1..9efd2fa 100755
 --- a/mkconfig
 +++ b/mkconfig
 @@ -82,6 +82,7 @@ else
config.h  # Create new config file
 fi
 echo /* Automatically generated - do not edit */ config.h
 +echo #define CONFIG_MK_${BOARD_NAME} 1 config.h
 echo #include configs/$1.h config.h
 echo #include asm/config.h config.h

 -- 
 1.6.4

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

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


[U-Boot] [PATCH][v2] mpc8260: move FDT memory node fixup into common CPU code.

2009-09-08 Thread Marcel Ziswiler
Move the memory node fixup of the MPC8260ADS, ids8247, mgcoge and muas3001
boards into common mpc8260 CPU code.

Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
 board/freescale/mpc8260ads/mpc8260ads.c |   13 -
 board/ids8247/ids8247.c |   16 
 board/keymile/mgcoge/mgcoge.c   |8 +---
 board/muas3001/muas3001.c   |   16 
 cpu/mpc8260/cpu.c   |1 +
 5 files changed, 2 insertions(+), 52 deletions(-)

diff --git a/board/freescale/mpc8260ads/mpc8260ads.c 
b/board/freescale/mpc8260ads/mpc8260ads.c
index 49a88bb..be55626 100644
--- a/board/freescale/mpc8260ads/mpc8260ads.c
+++ b/board/freescale/mpc8260ads/mpc8260ads.c
@@ -550,24 +550,11 @@ void pci_init_board(void)
 #endif
 
 #if defined(CONFIG_OF_LIBFDT)  defined(CONFIG_OF_BOARD_SETUP)
-void ft_blob_update(void *blob, bd_t *bd)
-{
-   int ret;
-
-   ret = fdt_fixup_memory(blob, (u64)bd-bi_memstart, (u64)bd-bi_memsize);
-
-   if (ret  0) {
-   printf(ft_blob_update(): cannot set /memory/reg 
-   property err:%s\n, fdt_strerror(ret));
-   }
-}
-
 void ft_board_setup(void *blob, bd_t *bd)
 {
ft_cpu_setup(blob, bd);
 #ifdef CONFIG_PCI
ft_pci_setup(blob, bd);
 #endif
-   ft_blob_update(blob, bd);
 }
 #endif
diff --git a/board/ids8247/ids8247.c b/board/ids8247/ids8247.c
index 79fe9da..d621833 100644
--- a/board/ids8247/ids8247.c
+++ b/board/ids8247/ids8247.c
@@ -400,24 +400,8 @@ int board_nand_init(struct nand_chip *nand)
 #endif /* CONFIG_CMD_NAND */
 
 #if defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_OF_LIBFDT)
-/*
- * update memory property in the blob
- */
-void ft_blob_update(void *blob, bd_t *bd)
-{
-   int ret;
-
-   ret = fdt_fixup_memory(blob, (u64)bd-bi_memstart, (u64)bd-bi_memsize);
-
-   if (ret  0) {
-   printf(ft_blob_update(): cannot set /memory/reg 
-   property err:%s\n, fdt_strerror(ret));
-   }
-}
-
 void ft_board_setup(void *blob, bd_t *bd)
 {
ft_cpu_setup( blob, bd);
-   ft_blob_update(blob, bd);
 }
 #endif /* defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_OF_LIBFDT) */
diff --git a/board/keymile/mgcoge/mgcoge.c b/board/keymile/mgcoge/mgcoge.c
index b16a01c..932a805 100644
--- a/board/keymile/mgcoge/mgcoge.c
+++ b/board/keymile/mgcoge/mgcoge.c
@@ -312,11 +312,10 @@ int hush_init_var (void)
 
 #if defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_OF_LIBFDT)
 /*
- * update memory property in the blob
+ * update flash property in the blob
  */
 void ft_blob_update (void *blob, bd_t *bd)
 {
-   ulong memory_data[2] = {0};
ulong *flash_data = NULL;
ulong   flash_reg[6] = {0};
flash_info_t*info;
@@ -324,11 +323,6 @@ void ft_blob_update (void *blob, bd_t *bd)
int size;
int i = 0;
 
-   memory_data[0] = cpu_to_be32 (bd-bi_memstart);
-   memory_data[1] = cpu_to_be32 (bd-bi_memsize);
-   fdt_set_node_and_value (blob, /memory, reg, memory_data,
-   sizeof (memory_data));
-
len = fdt_get_node_and_value (blob, /localbus, ranges,
(void *)flash_data);
 
diff --git a/board/muas3001/muas3001.c b/board/muas3001/muas3001.c
index 36caed8..e0a7f32 100644
--- a/board/muas3001/muas3001.c
+++ b/board/muas3001/muas3001.c
@@ -308,25 +308,9 @@ int board_early_init_r (void)
 void ft_blob_update (void *blob, bd_t *bd)
 {
int ret, nodeoffset = 0;
-   ulong memory_data[2] = {0};
ulong flash_data[4] = {0};
ulong   speed = 0;
 
-   memory_data[0] = cpu_to_be32 (bd-bi_memstart);
-   memory_data[1] = cpu_to_be32 (bd-bi_memsize);
-
-   nodeoffset = fdt_path_offset (blob, /memory);
-   if (nodeoffset = 0) {
-   ret = fdt_setprop (blob, nodeoffset, reg, memory_data,
-   sizeof(memory_data));
-   if (ret  0)
-   printf (ft_blob_update): cannot set /memory/reg 
-   property err:%s\n, fdt_strerror (ret));
-   } else {
-   /* memory node is required in dts */
-   printf (ft_blob_update(): cannot find /memory node 
-   err:%s\n, fdt_strerror(nodeoffset));
-   }
/* update Flash addr, size */
flash_data[2] = cpu_to_be32 (CONFIG_SYS_FLASH_BASE);
flash_data[3] = cpu_to_be32 (CONFIG_SYS_FLASH_SIZE);
diff --git a/cpu/mpc8260/cpu.c b/cpu/mpc8260/cpu.c
index 17e6248..aedbf29 100644
--- a/cpu/mpc8260/cpu.c
+++ b/cpu/mpc8260/cpu.c
@@ -318,6 +318,7 @@ void ft_cpu_setup (void *blob, bd_t *bd)
timebase-frequency, OF_TBCLK, 1);
do_fixup_by_prop_u32(blob, device_type, cpu, 4,
clock-frequency, bd-bi_intfreq, 1);
+   fdt_fixup_memory(blob, (u64)bd-bi_memstart, (u64)bd-bi_memsize);
 }
 #endif /* CONFIG_OF_LIBFDT */
 
-- 
1.6.0.4




[U-Boot] [PATCH][v3] ep8248: add support for device tree and secondary Ethernet interface.

2009-09-08 Thread Marcel Ziswiler
Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
---
 board/ep8248/ep8248.c|   16 -
 include/configs/ep8248.h |   53 --
 2 files changed, 37 insertions(+), 32 deletions(-)

diff --git a/board/ep8248/ep8248.c b/board/ep8248/ep8248.c
index bc20ba7..eb11418 100644
--- a/board/ep8248/ep8248.c
+++ b/board/ep8248/ep8248.c
@@ -5,6 +5,10 @@
  * Support for Embedded Planet EP8248 boards.
  * Tested on EP8248E.
  *
+ * Copyright (C) 2009 Noser Engineering AG
+ * Marcel Ziswiler marcel.ziswi...@noser.com
+ * Added support for device tree and secondary Ethernet interface
+ *
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -35,8 +39,8 @@
  * according to the five values podr/pdir/ppar/psor/pdat for that entry
  */
 
-#define CONFIG_SYS_FCC1 (CONFIG_ETHER_INDEX == 1)
-#define CONFIG_SYS_FCC2 (CONFIG_ETHER_INDEX == 2)
+#define CONFIG_SYS_FCC1 (CONFIG_ETHER_ON_FCC1 == 1)
+#define CONFIG_SYS_FCC2 (CONFIG_ETHER_ON_FCC2 == 1)
 
 const iop_conf_t iop_conf_tab[4][32] = {
 
@@ -261,3 +265,11 @@ int checkboard(void)
 
return 0;
 }
+
+#if defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_OF_LIBFDT)
+void ft_board_setup(void *blob, bd_t *bd)
+{
+   ft_cpu_setup( blob, bd);
+}
+#endif /* defined(CONFIG_OF_BOARD_SETUP)  defined(CONFIG_OF_LIBFDT) */
+
diff --git a/include/configs/ep8248.h b/include/configs/ep8248.h
index f7b3fde..b1dbe7d 100644
--- a/include/configs/ep8248.h
+++ b/include/configs/ep8248.h
@@ -4,6 +4,10 @@
  *
  * U-Boot configuration for Embedded Planet EP8248 boards.
  *
+ * Copyright (C) 2009 Noser Engineering AG
+ * Marcel Ziswiler marcel.ziswi...@noser.com
+ * Added support for device tree and secondary Ethernet interface
+ *
  * See file CREDITS for list of people who contributed to this
  * project.
  *
@@ -50,50 +54,41 @@
 
 #define CONFIG_SYS_BCSR0xFA00
 
-/*
- * Select ethernet configuration
- *
- * If either CONFIG_ETHER_ON_SCC or CONFIG_ETHER_ON_FCC is selected,
- * then CONFIG_ETHER_INDEX must be set to the channel number (1-4 for
- * SCC, 1-3 for FCC)
- *
- * If CONFIG_ETHER_NONE is defined, then either the ethernet routines
- * must be defined elsewhere (as for the console), or CONFIG_CMD_NET
- * must be unset.
- */
+/* Pass open firmware flat device tree */
+#define CONFIG_OF_LIBFDT   1
+#define CONFIG_OF_BOARD_SETUP  1
+
+#define OF_TBCLK(bd-bi_busfreq / 4)
+#define OF_STDOUT_PATH  /soc/cpm/ser...@11a80
+
+/* Select ethernet configuration */
 #undef CONFIG_ETHER_ON_SCC /* Ethernet is not on SCC */
 #define CONFIG_ETHER_ON_FCC/* Ethernet is on FCC */
 #undef CONFIG_ETHER_NONE   /* No external Ethernet   */
 
-#ifdef CONFIG_ETHER_ON_FCC
-
-#define CONFIG_ETHER_INDEX 1   /* FCC1 is used for Ethernet */
-
-#if   (CONFIG_ETHER_INDEX == 1)
+#define CONFIG_NET_MULTI
+#define CONFIG_SYS_CPMFCR_RAMTYPE  0
+#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
 
+#define CONFIG_HAS_ETH0
+#define CONFIG_ETHER_ON_FCC1   1
 /* - Rx clock is CLK10
  * - Tx clock is CLK11
  * - BDs/buffers on 60x bus
  * - Full duplex
  */
-#define CONFIG_SYS_CMXFCR_MASK (CMXFCR_FC1 | CMXFCR_RF1CS_MSK | 
CMXFCR_TF1CS_MSK)
-#define CONFIG_SYS_CMXFCR_VALUE(CMXFCR_RF1CS_CLK10 | 
CMXFCR_TF1CS_CLK11)
-#define CONFIG_SYS_CPMFCR_RAMTYPE  0
-#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
-
-#elif (CONFIG_ETHER_INDEX == 2)
+#define CONFIG_SYS_CMXFCR_MASK1(CMXFCR_FC1 | CMXFCR_RF1CS_MSK | 
CMXFCR_TF1CS_MSK)
+#define CONFIG_SYS_CMXFCR_VALUE1   (CMXFCR_RF1CS_CLK10 | 
CMXFCR_TF1CS_CLK11)
 
+#define CONFIG_HAS_ETH1
+#define CONFIG_ETHER_ON_FCC2   1
 /* - Rx clock is CLK13
  * - Tx clock is CLK14
  * - BDs/buffers on 60x bus
  * - Full duplex
  */
-#define CONFIG_SYS_CMXFCR_MASK (CMXFCR_FC2 | CMXFCR_RF2CS_MSK | 
CMXFCR_TF2CS_MSK)
-#define CONFIG_SYS_CMXFCR_VALUE(CMXFCR_RF2CS_CLK13 | 
CMXFCR_TF2CS_CLK14)
-#define CONFIG_SYS_CPMFCR_RAMTYPE  0
-#define CONFIG_SYS_FCC_PSMR(FCC_PSMR_FDE | FCC_PSMR_LPB)
-
-#endif /* CONFIG_ETHER_INDEX */
+#define CONFIG_SYS_CMXFCR_MASK2(CMXFCR_FC2 | CMXFCR_RF2CS_MSK | 
CMXFCR_TF2CS_MSK)
+#define CONFIG_SYS_CMXFCR_VALUE2   (CMXFCR_RF2CS_CLK13 | 
CMXFCR_TF2CS_CLK14)
 
 #define CONFIG_MII /* MII PHY management*/
 #define CONFIG_BITBANGMII  /* Bit-banged MDIO interface */
@@ -113,8 +108,6 @@
 
 #define MIIDELAY   udelay(1)
 
-#endif /* CONFIG_ETHER_ON_FCC */
-
 #ifndef CONFIG_8260_CLKIN
 #define CONFIG_8260_CLKIN  6600/* in Hz */
 #endif
-- 
1.6.0.4



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


Re: [U-Boot] PowerPC -mrelocatable

2009-09-08 Thread Peter Tyser
On Thu, 2009-08-27 at 12:49 -0500, Scott Wood wrote:
 Peter Tyser wrote:
  On Thu, 2009-08-27 at 10:38 -0500, Scott Wood wrote:
  Someone tried to get proper relocation working a while ago, but ran into
  toolchain bugs.  Maybe current toolchains are better...
  
  X-ES's board's in U-Boot fully relocate to SDRAM with the
  CONFIG_RELOC_FIXUP_WORKS define and -mrelocatable compiler flag.  This
  feature has worked with gcc-4.3.1/binutils-2.18.90 and
  gcc-4.2.2/binutils-2.17.50.
  
  Does anyone have a specific example of a toolchain that doesn't work?
  It'd be great to get the issue figured out and get rid of all those
  gd-reloc_off references that currently litter the code...
 
 According to these e-mails:
 http://lists.denx.de/pipermail/u-boot/2007-October/025937.html
 http://lists.denx.de/pipermail/u-boot/2007-October/025941.html
 
 it worked in (at least some) 4.0, but not (at least some) 3.x or 4.1.

Going over the emails and my own testing, it looks the following
versions worked:
gcc 4.0.0
gcc 4.0.2
gcc 4.1.1, binutils 2.16 (I've verified this)
gcc 4.2.2, binutils 2.17 (I've verified this)
gcc 4.3.1, binutils 2.17 (I've verified this)

And the following didn't:
gcc 3.4.3, glibc 2.3.4, binutils 2.15.94
gcc 4.1.2, glibc 2.5, binutils 2.17 ***
gcc 4.1.78 ***

 If we're now at the point where current GCC works, and has for several 
 releases, we should probably consider revisiting those patches.

I did some debug on gcc 3.4.3/binutils2.3.4/glibc2.15 which was a known
non-working setup on an MPC8548-based board.  I'm 98% sure the the
reason it fails because it doesn't properly generate .fixup sections.
No .fixup sections are present in any of the compiled objects or u-boot.
This results in the link script variable '__fixup_entries' equalling 0,
so no relocation fixups are performed on bootup (eg see line 943 in
cpu/mpc85xx/start.S).

It looks like this was a gcc bug that has been fixed:
http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00057.html


gcc 4.1.2 and 4.1.78 have the gcc relocation fix in it, so that isn't
the issue for them.  I tried gcc 4.1.2/binutils 2.17 from one of
Freescale's BSPs (looks to be very similar to the one described here:
http://www.freescale.com/files/soft_dev_tools/doc/support_info/BSPMPC5121EADSRN.txt?fsrch=1)
and it actually worked!

I'm guessing that the broken versions of gcc 4.1.2 and 4.1.78 are
actually the same Freescale-provided compiler.  The toolchain Freescale
provided is really version 4.1.2, but the path of the compiler contains
gcc-4.1.78-eglibc-2.5.78-dp-1.  gcc 4.1.78 doesn't exist, so I'm
guessing someone in the threads above was using Freescale's gcc 4.1.2,
but made the mistake of calling it 4.1.78 based on its misleading
install path.

So in summary, there appears to be a bug in gcc for version 3.4.3 which
prevents relocation from working, and I was unable to find any issues
with 4.1.2.  The fact that all 4.0.0, 4.1.1, 4.2.2, 4.3.1 worked also
would lead me to believe 4.1.2 should also work.


Does anyone out there by chance have a failure case for gcc  4.0.0,
because I can't seem to reproduce the issues others had in the past.

My vote would be to find out which version of gcc contains the
relocation bug and spit out an error if gcc  than that version is used.
We could also try and get fancy and dynamically turn on/off relocation
support at compile time based on gcc's version if other's wanted to
maintain support for older compilers.  These changes would only be for
ppc at this point btw.

Let me know if others have any input.

Best,
Peter

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


Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets

2009-09-08 Thread Scott Wood
On Mon, Sep 07, 2009 at 02:38:22PM +0200, Wolfgang Denk wrote:
  then in the include/configs/*.h:
  #ifdef MPC8536DS_NAND
  blablabla
  #endif
 
  #ifdef MPC8536DS_NAND_36BIT
  blablabla
  #endif
 
  #ifdef MPC8536DS_36BIT
  blablabla
  #endif
 
 That would be CONFIG_MPC8536DS_NAND etc., but except of that that's
 whaty I mean.

NAND and 36BIT are orthogonal options -- what is wrong with the previous
suggestion of splitting them in mkconfig?

With more than two orthogonal options, things will get rather silly
trying to list every combination -- and it would be nice if it didn't
matter which order the user specifies the options in.

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


[U-Boot] [PATCH] TI DaVinci: DM646x: Initial Support for DM646x SOC

2009-09-08 Thread s-paulraj
From: Sandeep Paulraj s-paul...@ti.com

DM646x is an SOC from TI which has both an ARM and a DSP.
There are multiple variants of the SOC mainly dealing with different
core speeds.
This patch adds the initial framework for the DM646x SOC.

Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
 cpu/arm926ejs/davinci/Makefile  |1 +
 cpu/arm926ejs/davinci/dm646x.c  |   41 +++
 include/asm-arm/arch-davinci/hardware.h |   11 
 3 files changed, 53 insertions(+), 0 deletions(-)
 create mode 100644 cpu/arm926ejs/davinci/dm646x.c

diff --git a/cpu/arm926ejs/davinci/Makefile b/cpu/arm926ejs/davinci/Makefile
index 7501a85..d7e9e2c 100644
--- a/cpu/arm926ejs/davinci/Makefile
+++ b/cpu/arm926ejs/davinci/Makefile
@@ -31,6 +31,7 @@ COBJS-y   += cpu.o timer.o psc.o
 COBJS-$(CONFIG_SOC_DM355)  += dm355.o
 COBJS-$(CONFIG_SOC_DM365)  += dm365.o
 COBJS-$(CONFIG_SOC_DM644X) += dm644x.o
+COBJS-$(CONFIG_SOC_DM646X) += dm646x.o
 COBJS-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o dp83848.o
 
 SOBJS  = reset.o
diff --git a/cpu/arm926ejs/davinci/dm646x.c b/cpu/arm926ejs/davinci/dm646x.c
new file mode 100644
index 000..329825f
--- /dev/null
+++ b/cpu/arm926ejs/davinci/dm646x.c
@@ -0,0 +1,41 @@
+/*
+ * SoC-specific code for TMS320DM646x chips
+ *
+ * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include asm/arch/hardware.h
+
+void davinci_enable_uart0(void)
+{
+   lpsc_on(DAVINCI_DM646X_LPSC_UART0);
+}
+
+#ifdef CONFIG_DRIVER_TI_EMAC
+void davinci_enable_emac(void)
+{
+   lpsc_on(DAVINCI_DM646X_LPSC_EMAC);
+}
+#endif
+
+#ifdef CONFIG_DRIVER_DAVINCI_I2C
+void davinci_enable_i2c(void)
+{
+   lpsc_on(DAVINCI_DM646X_LPSC_I2C);
+}
+#endif
diff --git a/include/asm-arm/arch-davinci/hardware.h 
b/include/asm-arm/arch-davinci/hardware.h
index 313b3f3..ac32510 100644
--- a/include/asm-arm/arch-davinci/hardware.h
+++ b/include/asm-arm/arch-davinci/hardware.h
@@ -105,6 +105,13 @@ typedef volatile unsigned int *dv_reg_p;
 #define DAVINCI_ASYNC_EMIF_CNTRL_BASE  0x01d1
 #define DAVINCI_MMC_SD0_BASE   0x01d11000
 
+#elif defined(CONFIG_SOC_DM646X)
+#define DAVINCI_ASYNC_EMIF_CNTRL_BASE  0x20008000
+#define DAVINCI_ASYNC_EMIF_DATA_CE0_BASE   0x4200
+#define DAVINCI_ASYNC_EMIF_DATA_CE1_BASE   0x4400
+#define DAVINCI_ASYNC_EMIF_DATA_CE2_BASE   0x4600
+#define DAVINCI_ASYNC_EMIF_DATA_CE3_BASE   0x4800
+
 #endif
 
 /* Power and Sleep Controller (PSC) Domains */
@@ -153,6 +160,10 @@ typedef volatile unsigned int *dv_reg_p;
 #define DAVINCI_LPSC_GEM   39
 #define DAVINCI_LPSC_IMCOP 40
 
+#define DAVINCI_DM646X_LPSC_EMAC   14
+#define DAVINCI_DM646X_LPSC_UART0  26
+#define DAVINCI_DM646X_LPSC_I2C31
+
 void lpsc_on(unsigned int id);
 void dsp_on(void);
 
-- 
1.6.0.4

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


Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets

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

In message 20090908153825.ga18...@b07421-ec1.am.freescale.net you wrote:

   #ifdef MPC8536DS_36BIT
   blablabla
   #endif
  
  That would be CONFIG_MPC8536DS_NAND etc., but except of that that's
  whaty I mean.
 
 NAND and 36BIT are orthogonal options -- what is wrong with the previous
 suggestion of splitting them in mkconfig?

I don't like this idea as it will pollute the namespace by a number of
uncontrolled auto-generated #defines, which may be a nightmare to
debug because you quickly forget where such definitions might be
coming from - after you realize that they are actually set because you
cannot find them in any board-related config or source file.

There are a number of board names that have an underscore embedded
which may or may not indicate such options. Also, such auto-generated
symbols may be wrong. For example omap1610inn_cs_autoboot_config
would auto-generate

CONFIG_OMAP1610INN
CONFIG_CS
CONFIG_AUTOBOOT

instead of the expected CONFIG_CS_AUTOBOOT

 With more than two orthogonal options, things will get rather silly
 trying to list every combination -- and it would be nice if it didn't
 matter which order the user specifies the options in.

Agreed. Unfortunately I don't have a clever idea how to implement
this either.

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
Always borrow money from a pessimist; they don't expect  to  be  paid
back.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Microblaze repo update - patches

2009-09-08 Thread Ben Warren
Michal Simek wrote:
 Wolfgang Denk wrote:
   
 Dear Michal Simek,

 In message 4aa4c096.7060...@monstr.eu you wrote:
 
 Hi Wolfgang,

 I added all Microblaze changes to my repo.

 Ben: Can you finally check LL-Temac driver? I haven't got any your reaction.
 I know you have just a lot of work.

 Wolfgang: There are two patches for you. First remove xilinx_emac.c driver
 and second cleanup license in xilinx_emaclite.c file.

 There are some microblaze related changes too.

 If is Ben ok with pulling ll-temac driver directly, Wolfgang please pull to 
 your tree.
 If not, I'll remove that last LL_Temac patch.
   
 I guess it would be easiest if Ben sends an ACK, and I will pull then.
 

 good idea.

 Best regards,
 Michal

   
 Ben?

 Best regards,

 Wolfgang Denk

 

   
Sorry, I've been off the grid for the last week or so but am back now.  
I'm working through the big pile of e-mails and will get to this soon.

regards,
Ben

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


Re: [U-Boot] PowerPC -mrelocatable

2009-09-08 Thread Mike Frysinger
On Tuesday 08 September 2009 12:16:13 Peter Tyser wrote:
 I did some debug on gcc 3.4.3/binutils2.3.4/glibc2.15 which was a known
 non-working setup on an MPC8548-based board.  I'm 98% sure the the
 reason it fails because it doesn't properly generate .fixup sections.
 No .fixup sections are present in any of the compiled objects or u-boot.
 This results in the link script variable '__fixup_entries' equalling 0,
 so no relocation fixups are performed on bootup (eg see line 943 in
 cpu/mpc85xx/start.S).
 
 It looks like this was a gcc bug that has been fixed:
 http://gcc.gnu.org/ml/gcc-cvs/2004-12/msg00057.html
 
 ...
 
 My vote would be to find out which version of gcc contains the
 relocation bug and spit out an error if gcc  than that version is used.
 We could also try and get fancy and dynamically turn on/off relocation
 support at compile time based on gcc's version if other's wanted to
 maintain support for older compilers.  These changes would only be for
 ppc at this point btw.

or run readelf on the objects that are known to not generate fixup stuff and 
error out if they're missing in the objects ?
-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] PowerPC -mrelocatable

2009-09-08 Thread Wolfgang Denk
Dear Peter,

In message 1252426573.6005.253.ca...@localhost.localdomain you wrote:

 Going over the emails and my own testing, it looks the following
 versions worked:
...

Thanks for the detailed analysis.

I remember that gcc-3.4.x has always been marked as suspicious in
our tests, so for example we avoided basing an ELDK release on it.

 Does anyone out there by chance have a failure case for gcc  4.0.0,
 because I can't seem to reproduce the issues others had in the past.

Do you have an up-to-date patch that can be used for such testing?

 My vote would be to find out which version of gcc contains the
 relocation bug and spit out an error if gcc  than that version is used.

Agreed.

 We could also try and get fancy and dynamically turn on/off relocation
 support at compile time based on gcc's version if other's wanted to
 maintain support for older compilers.  These changes would only be for
 ppc at this point btw.

I think there would be not  much  lost  if  we  dropped  support  for
versions before gcc-4.x

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A Perl script is correct if it's halfway readable and  gets  the  job
done before your boss fires you.
   - L. Wall  R. L. Schwartz, _Programming Perl_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI DaVinci: DM365: Minor Updates to DM365 EVM

2009-09-08 Thread Wolfgang Denk
Dear Sandeep,

In message 1252422547-27960-1-git-send-email-s-paul...@ti.com you wrote:
 From: Sandeep Paulraj s-paul...@ti.com
 
 The patch does the following
 1) Gets rid of dependency on asm/sizes.h and replaces references
 to SZ_xx with their equivalent values

This is actually a good idea, I think. Yet I have some comments...


 diff --git a/board/davinci/dm365evm/dm365evm.c 
 b/board/davinci/dm365evm/dm365evm.c
 index e30184b..1c88b30 100644
 --- a/board/davinci/dm365evm/dm365evm.c
 +++ b/board/davinci/dm365evm/dm365evm.c
 @@ -17,7 +17,7 @@
  
  #include common.h
  #include nand.h
 -#include linux/io.h
 +#include asm/io.h

This is an unrelated fix, it seems. It should be split into a separate
commit.

 --- a/include/configs/davinci_dm365evm.h
 +++ b/include/configs/davinci_dm365evm.h
...
 @@ -38,7 +37,7 @@
  /* Memory Info */
  #define CONFIG_NR_DRAM_BANKS 1
  #define PHYS_SDRAM_1 0x8000
 -#define PHYS_SDRAM_1_SIZESZ_128M
 +#define PHYS_SDRAM_1_SIZE0x0800

I recommend to use a way to write such constants that can quickly read
(without much thinking) by a huan, for example here:

#define PHYS_SDRAM_1_SIZE   (128  20) /* 128 MiB */

Please consider adding a comment as I did to make it even easier to
understand.

 @@ -74,7 +73,6 @@
  
  /* NAND: socketed, two chipselects, normally 2 GBytes */
  #define CONFIG_NAND_DAVINCI
 -#define CONFIG_SYS_NAND_HW_ECC

This is also an unrelated change that should be split into a separate
commit.

 @@ -125,7 +123,7 @@
  #define CONFIG_SYS_LONGHELP
  
  #ifdef CONFIG_NAND_DAVINCI
 -#define CONFIG_ENV_SIZE  SZ_256K
 +#define CONFIG_ENV_SIZE  0x0004

How about:

#define CONFIG_ENV_SIZE (256  10) /* 256 KiB */

 @@ -143,8 +141,8 @@
  #define CONFIG_TIMESTAMP
  
  /* U-Boot memory configuration */
 -#define CONFIG_STACKSIZE SZ_256K /* regular stack */
 -#define CONFIG_SYS_MALLOC_LENSZ_1M   /* malloc() arena */
 +#define CONFIG_STACKSIZE 0x0004  /* regular stack */
 +#define CONFIG_SYS_MALLOC_LEN0x0008  /* malloc() 
 arena */

#define CONFIG_STACKSIZE(256  10) /* 256 KiB regular 
stack */
#define CONFIG_SYS_MALLOC_LEN   (1  20)   /* 1 MiB malloc() arena 
*/

Thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The optimum committee has no members.
   - Norman Augustine
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread s-paulraj
From: Sandeep Paulraj s-paul...@ti.com

This patch removes the asm/sizes.h header file from being
included in the DaVinci SOC configs.
References to SZ_xx have been replaced by appropriate
bit shifted values.

Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
The asm/sizes.h header file has the phrase All rights reserved
and i don't see a patch to rectify this. Also i gather from e-mails
on the list that Wolfgang does not like these references to SZ_xx.
It appears to me that this file has a good chance of being removed from the
repository. Thus this patch removes a dependency on this file.
 include/configs/davinci_dm355evm.h  |9 -
 include/configs/davinci_dm365evm.h  |9 -
 include/configs/davinci_dvevm.h |5 ++---
 include/configs/davinci_schmoogie.h |3 +--
 include/configs/davinci_sffsdr.h|3 +--
 include/configs/davinci_sonata.h|3 +--
 6 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/include/configs/davinci_dm355evm.h 
b/include/configs/davinci_dm355evm.h
index c35f5c9..4e3415f 100644
--- a/include/configs/davinci_dm355evm.h
+++ b/include/configs/davinci_dm355evm.h
@@ -19,7 +19,6 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
-#include asm/sizes.h
 
 /* Spectrum Digital TMS320DM355 EVM board */
 #define DAVINCI_DM355EVM
@@ -40,7 +39,7 @@
 /* Memory Info */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0x8000
-#define PHYS_SDRAM_1_SIZE  SZ_128M
+#define PHYS_SDRAM_1_SIZE  (128  20) /* 128 MiB */
 
 /* Serial Driver info: UART0 for console  */
 #define CONFIG_SYS_NS16550
@@ -130,7 +129,7 @@
 #define CONFIG_SYS_PROMPT_HUSH_PS2  
 #define CONFIG_SYS_LONGHELP
 
-#define CONFIG_ENV_SIZESZ_16K
+#define CONFIG_ENV_SIZE(16  10)  /* 16 KiB */
 
 /* NYET -- #define CONFIG_BOOTDELAY5 */
 #define CONFIG_BOOTCOMMAND \
@@ -146,8 +145,8 @@
 #define CONFIG_NET_RETRY_COUNT 10
 
 /* U-Boot memory configuration */
-#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
-#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc() arena */
+#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
+#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB*/
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* for initial data */
 #define CONFIG_SYS_MEMTEST_START   0x8700  /* physical address */
 #define CONFIG_SYS_MEMTEST_END 0x8800  /* test 16MB RAM */
diff --git a/include/configs/davinci_dm365evm.h 
b/include/configs/davinci_dm365evm.h
index 47cb554..72eccb9 100644
--- a/include/configs/davinci_dm365evm.h
+++ b/include/configs/davinci_dm365evm.h
@@ -18,7 +18,6 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
-#include asm/sizes.h
 
 /* Spectrum Digital TMS320DM365 EVM board */
 #define DAVINCI_DM365EVM
@@ -38,7 +37,7 @@
 /* Memory Info */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0x8000
-#define PHYS_SDRAM_1_SIZE  SZ_128M
+#define PHYS_SDRAM_1_SIZE  (128  20) /* 128 MiB */
 
 /* Serial Driver info: UART0 for console  */
 #define CONFIG_SYS_NS16550
@@ -125,7 +124,7 @@
 #define CONFIG_SYS_LONGHELP
 
 #ifdef CONFIG_NAND_DAVINCI
-#define CONFIG_ENV_SIZESZ_256K
+#define CONFIG_ENV_SIZE(256  10) /* 256 KiB */
 #define CONFIG_ENV_IS_IN_NAND
 #define CONFIG_ENV_OFFSET  0x3C
 #undef CONFIG_ENV_IS_IN_FLASH
@@ -143,8 +142,8 @@
 #define CONFIG_TIMESTAMP
 
 /* U-Boot memory configuration */
-#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
-#define CONFIG_SYS_MALLOC_LEN  SZ_1M   /* malloc() arena */
+#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
+#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB */
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* for initial data */
 #define CONFIG_SYS_MEMTEST_START   0x8700  /* physical address */
 #define CONFIG_SYS_MEMTEST_END 0x8800  /* test 16MB RAM */
diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h
index 96b6afc..af669bc 100644
--- a/include/configs/davinci_dvevm.h
+++ b/include/configs/davinci_dvevm.h
@@ -19,7 +19,6 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
-#include asm/sizes.h
 
 /*
  * Define this to make U-Boot skip low level initialization when loaded
@@ -120,7 +119,7 @@
 #define CONFIG_ENV_IS_IN_NAND  /* U-Boot env in NAND Flash  */
 #ifdef CONFIG_SYS_NAND_SMALLPAGE
 #define CONFIG_ENV_SECT_SIZE   512 /* Env sector Size */
-#define CONFIG_ENV_SIZESZ_16K
+#define CONFIG_ENV_SIZE(16  10)  /* 16 KiB */
 #define CONFIG_MTD_PARTITIONS
 #define CONFIG_CMD_MTDPARTS
 #define MTDIDS_DEFAULT \
@@ -129,7 +128,7 @@
mtdparts=davinci_nand.0:384k(bootloader)ro,4m(kernel),-(filesystem)
 #else
 #define CONFIG_ENV_SECT_SIZE   2048/* Env sector 

Re: [U-Boot] [PATCH][v2] mpc8260: move FDT memory node fixup into common CPU code.

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

In message 1252423922.5386.17.ca...@com-21 you wrote:
 Move the memory node fixup of the MPC8260ADS, ids8247, mgcoge and muas3001
 boards into common mpc8260 CPU code.

In which way is this patch version 2? I have not seen any v1 of such a
patch?

 Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
 ---
  board/freescale/mpc8260ads/mpc8260ads.c |   13 -
  board/ids8247/ids8247.c |   16 
  board/keymile/mgcoge/mgcoge.c   |8 +---
  board/muas3001/muas3001.c   |   16 
  cpu/mpc8260/cpu.c   |1 +

You want to put the respective board maintainers on Cc:

Also, what is the impact for the other MPC826x board, that are not
listed 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
No one can guarantee the actions of another.
-- Spock, Day of the Dove, stardate unknown
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH][v1] mpc8260: remove Ethernet node fixup to use generic FDT code.

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

In message 1252423835.5386.15.ca...@com-21 you wrote:
 Remove Ethernet node fixup from mgcoge and muas3001 boards and modify its
 configs for the common mpc8260 code to use generic Ethernet fixup.
 
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
 ---
  board/keymile/mgcoge/mgcoge.c |5 -
  board/muas3001/muas3001.c |   15 ---
  include/configs/mgcoge.h  |1 +
  include/configs/muas3001.h|1 +
  4 files changed, 2 insertions(+), 20 deletions(-)

Should / could a similar change be added to
board/keymile/km8xx/km8xx.c, too?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A secure program has to be robust: it  must  be  able  to  deal  with
conditions  that can't happen, whether user input, program error or
library/etc. This is basic damage  control.  Buffer  overflow  errors
have nothing to do with security, but everything with stupidity.
 -- Wietse Venema in 5cnqm3$...@spike.porcupine.org
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH][v1] r7780mp: fix typo in Ethernet chip model number comment.

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

In message 1252423492.5386.7.ca...@com-21 you wrote:
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
 ---
  include/configs/r7780mp.h |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

Your patch numbering is really, really confusing. There is a patch
posted for the first time numbered as v2, another one as v3, and this
here is the second version of a patch which is still numbered v1.

I completely lost you here.

I don;t understand if these patches are supposed to be part of a
series, or if they are independet of each other, or what else these
random vN additions might mean.  Please eluciadate.

Also please note that new versions of a patch should contain a
comment (below the --- line) that describes what has been changed
compared to the old version, i. e. here something like: v2: added
missing SoB line or so.


Given this confusion, I will ignore the whole batch of 7 patches you
just sent. Please work on the other review comments, and then decide
how you want to post them - as series or independent patches. Assume
version numbering restarts from zero, as I really ignore this current
patch series.

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][v1] FDT: remove obsolete OF_CPU and OF_SOC macros.

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

In message 1252423607.5386.10.ca...@com-21 you wrote:
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
 ---
  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(-)

Please put the affected board maintainers on Cc:

How much testing has this patch seen?

 diff --git a/README b/README
 index ff4ed8b..3cb7786 100644
 --- a/README
 +++ b/README
 @@ -368,8 +368,10 @@ The following options need to be configured:
* Adds the fdt command
* The bootm command automatically updates the fdt
  
 - OF_CPU - The proper name of the cpus node.
 - OF_SOC - The proper name of the soc node.
 + OF_CPU - The proper name of the cpus node (only required for
 + MPC512X and MPC5xxx based boards).
 + OF_SOC - The proper name of the soc node (only required for
 + MPC512X and MPC5xxx based boards).
   OF_TBCLK - The timebase frequency.
   OF_STDOUT_PATH - The path to the console device

What about the other boards then? Say MPC8260ADS or mpc7448hpc2?

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 dear, I think you'll find reality's on the blink again.
- Marvin The Paranoid Android
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH][v3] ep8248: add support for device tree and secondary Ethernet interface.

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

In message 1252424017.5386.19.ca...@com-21 you wrote:
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
 ---
  board/ep8248/ep8248.c|   16 -
  include/configs/ep8248.h |   53 
 --
  2 files changed, 37 insertions(+), 32 deletions(-)

Please put the board maintainer on Cc:

 diff --git a/board/ep8248/ep8248.c b/board/ep8248/ep8248.c
 index bc20ba7..eb11418 100644
 --- a/board/ep8248/ep8248.c
 +++ b/board/ep8248/ep8248.c
 @@ -5,6 +5,10 @@
   * Support for Embedded Planet EP8248 boards.
   * Tested on EP8248E.
   *
 + * Copyright (C) 2009 Noser Engineering AG
 + * Marcel Ziswiler marcel.ziswi...@noser.com
 + * Added support for device tree and secondary Ethernet interface

We don't add copyright entries for so few lines of code.  And we don;t
add a change log either. We have git to track the history of changes
for us.

 diff --git a/include/configs/ep8248.h b/include/configs/ep8248.h
 index f7b3fde..b1dbe7d 100644
 --- a/include/configs/ep8248.h
 +++ b/include/configs/ep8248.h
 @@ -4,6 +4,10 @@
   *
   * U-Boot configuration for Embedded Planet EP8248 boards.
   *
 + * Copyright (C) 2009 Noser Engineering AG
 + * Marcel Ziswiler marcel.ziswi...@noser.com
 + * Added support for device tree and secondary Ethernet interface
 + *

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
A woman should have compassion.
-- Kirk, Catspaw, stardate 3018.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] ppc/85xx: Clean up do_reset

2009-09-08 Thread Kumar Gala
There is no reason to do a run time check for e500 v1 based cores to
determine if we have the GUTs RSTCR facility.  Only the first generation
of PQ3 parts (MPC8540/41/55/60) do not have it.  So checking to see if
we are e500 v2 would miss future parts (like e500mc).

Just change this to be ifdef'd based on CONFIG_MPC85{40,41,55,60}.

Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
 cpu/mpc85xx/cpu.c |   25 +
 1 files changed, 9 insertions(+), 16 deletions(-)

diff --git a/cpu/mpc85xx/cpu.c b/cpu/mpc85xx/cpu.c
index 8b3810f..bdd9ee4 100644
--- a/cpu/mpc85xx/cpu.c
+++ b/cpu/mpc85xx/cpu.c
@@ -153,27 +153,15 @@ int checkcpu (void)
 
 int do_reset (cmd_tbl_t *cmdtp, bd_t *bd, int flag, int argc, char *argv[])
 {
-   uint pvr;
-   uint ver;
+/* Everything after the first generation of PQ3 parts has RSTCR */
+#if defined(CONFIG_MPC8540) || defined(CONFIG_MPC8541) || \
+defined(CONFIG_MPC8555) || defined(CONFIG_MPC8560)
unsigned long val, msr;
 
-   pvr = get_pvr();
-   ver = PVR_VER(pvr);
-
-   if (ver  1){
-   /* e500 v2 core has reset control register */
-   volatile unsigned int * rstcr;
-   rstcr = (volatile unsigned int *)(CONFIG_SYS_IMMR + 0xE00B0);
-   *rstcr = 0x2;   /* HRESET_REQ */
-   udelay(100);
-   }
-
/*
-* Fallthrough if the code above failed
 * Initiate hard reset in debug control register DBCR0
-* Make sure MSR[DE] = 1
+* Make sure MSR[DE] = 1.  This only resets the core.
 */
-
msr = mfmsr ();
msr |= MSR_DE;
mtmsr (msr);
@@ -181,6 +169,11 @@ int do_reset (cmd_tbl_t *cmdtp, bd_t *bd, int flag, int 
argc, char *argv[])
val = mfspr(DBCR0);
val |= 0x7000;
mtspr(DBCR0,val);
+#else
+   volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+   out_be32(gur-rstcr, 0x2); /* HRESET_REQ */
+   udelay(100);
+#endif
 
return 1;
 }
-- 
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 DaVinci: Remove references to SZ_xx

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

In message 1252434246-19517-1-git-send-email-s-paul...@ti.com you wrote:
 From: Sandeep Paulraj s-paul...@ti.com
 
 This patch removes the asm/sizes.h header file from being
 included in the DaVinci SOC configs.
 References to SZ_xx have been replaced by appropriate
 bit shifted values.
 
 Signed-off-by: Sandeep Paulraj s-paul...@ti.com

Note that this patch actually changes the configuration:

 --- a/include/configs/davinci_dm355evm.h
 +++ b/include/configs/davinci_dm355evm.h
...
  /* U-Boot memory configuration */
 -#define CONFIG_STACKSIZE SZ_256K /* regular stack */
 -#define CONFIG_SYS_MALLOC_LENSZ_512K /* malloc() 
 arena */
 +#define CONFIG_STACKSIZE (256  10) /* 256 KiB */
 +#define CONFIG_SYS_MALLOC_LEN(1  20)   /* 1 MiB*/

as it increases the malloc() arena size form 512 to 1024 KiB.

Assuming this was done intentionally:

Acked-by: Wolfgang Denk w...@denx.de

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
Work 8 hours, sleep 8 hours; but not the same 8 hours.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc

2009-09-08 Thread Dirk Behme
Tom wrote:
 Minkyu Kang wrote:
 Dear Dirk,


 snip
 
 I have lost track of this thread.

Yes, and I'm currently trying to get the track back ;)

 When last I worked this, it seemed like the cache routines were going to
 be split.
 
 1. generic cache routines
 2. legacy soc cache routines.
 
 Are the generic cache routines in place and can you use them?
 Else can you handle your soc specific cache routines as part of a
 legacy cache routine ?
 
 The omap cache routines are dependent on omap rom code and fitting
 new routines in using the omap specifics may not be the best way to
 go.

I'm sure this is not the perfect way, but it seems to me that 
splitting all this stuff into several small steps would be the easier 
for all. E.g.

1) From the previous discussion I think we should apply

http://lists.denx.de/pipermail/u-boot/2009-August/058492.html

Independent of any discussion if this code is needed at all, if it is 
generic or not etc. the main advantage I understood is that it frees 
the way for Samsung.

2a) Then, what I understood from Minkyu, we need an additional patch 
(discussion?) how to switch CONFIG_L2_OFF from compile time to run 
time selection (for Samsung's multi board support)

2b) Then, what I understood from Minkyu, we should discuss about 
removal of get_device_type() function

3) In parallel, we should discuss how to further improve the OMAP3 
cache stuff. What might be generic, what not, what isn't necessary etc.

4) Regarding (cache) code duplication, I vote for doing this 
duplication first. That is, have working Samsung and OMAP3 code 
applied in parallel. While Jean-Christophe might cry code 
duplication, I learned from OMAP3 boards that is was easier to unify 
common code _after_ code duplication was done and therefore can be 
easily identified. Discussing about possible code duplication without 
being able to see (and test) the code is sometimes a little tricky ;)

As mentioned, doing this in several, small steps I feel more 
comfortable with. If we would have done step (1) already, it's my 
feeling that we would have reached step 2 or 3 already. But now, we 
are still discussing about the 'one big perfect patch'.

Best regards

Dirk



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


Re: [U-Boot] Please pull u-boot-ppc4xx

2009-09-08 Thread Wolfgang Denk
Dear Stefan Roese,

In message 200909081109.54942...@denx.de you wrote:
 The following changes since commit 0052a051f60a043f1730b3a46f23b3c7b0eb7820:
   Wolfgang Denk (1):
 Merge branch 'master' of git://git.denx.de/u-boot-i2c
 
 are available in the git repository at:
 
   git://www.denx.de/git/u-boot-ppc4xx.git master
 
 Detlev Zundel (1):
   amcc-common.h: Use filenames from environment variables for update 
 procedure.


Um... I see this in the commit log in your repo:

Signed-off-by: Detlev Zundel d...@denx.de
Signed-off-by: Wolfgang Denk w...@denx.de
Signed-off-by: Stefan Roese s...@denx.de

But this is not correct. I sent an Acked-by:, but never a SoB.

Please fix.

 Matthias Fuchs (3):
   ppc4xx: Fix PMC405DE support
   ppc4xx: Allow overwriting pci target registers for all 4xx boards
   ppc4xx: Add CONFIG_PCI_4xx_PTM_OVERWRITE to some esd 4xx boards
 
 Stefan Roese (1):
   ppc4xx: Fix compilation warning in 4xx miiphy.c
 
  board/esd/pmc405de/Makefile   |5 -
  cpu/ppc4xx/4xx_pci.c  |4 ++--
  cpu/ppc4xx/miiphy.c   |2 +-
  include/configs/CPCI405.h |2 ++
  include/configs/CPCI4052.h|2 ++
  include/configs/CPCI405AB.h   |2 ++
  include/configs/CPCI405DT.h   |2 ++
  include/configs/PMC405.h  |2 ++
  include/configs/PMC405DE.h|2 ++
  include/configs/amcc-common.h |8 +---
  10 files changed, 24 insertions(+), 7 deletions(-)

Not pulled due to incorrect commit logs.

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Paulraj, Sandeep


 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.de]
 Sent: Tuesday, September 08, 2009 2:51 PM
 To: Paulraj, Sandeep
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
 
 Dear s-paul...@ti.com,
 
 In message 1252434246-19517-1-git-send-email-s-paul...@ti.com you wrote:
  From: Sandeep Paulraj s-paul...@ti.com
 
  This patch removes the asm/sizes.h header file from being
  included in the DaVinci SOC configs.
  References to SZ_xx have been replaced by appropriate
  bit shifted values.
 
  Signed-off-by: Sandeep Paulraj s-paul...@ti.com
 
 Note that this patch actually changes the configuration:
 
  --- a/include/configs/davinci_dm355evm.h
  +++ b/include/configs/davinci_dm355evm.h
 ...
   /* U-Boot memory configuration */
  -#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
  -#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc()
 arena */
  +#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
  +#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB*/
 
 as it increases the malloc() arena size form 512 to 1024 KiB.
 
 Assuming this was done intentionally:
[Sandeep] Yes this was intentional because for NANDs with large block sizes(256 
KiB), if this is not increased we will get out of memory errors.
 
 Acked-by: Wolfgang Denk w...@denx.de
 
 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
 Work 8 hours, sleep 8 hours; but not the same 8 hours.

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Paulraj, Sandeep
Wolfgang,

Now how do I handle this?
Should I make a next branch and push this patch to the next branch or push it 
directly to the master.
 
  Assuming this was done intentionally:
 [Sandeep] Yes this was intentional because for NANDs with large block
 sizes(256 KiB), if this is not increased we will get out of memory
 errors.
 
  Acked-by: Wolfgang Denk w...@denx.de
 
Thanks,
Sandeep

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Tom
Paulraj, Sandeep wrote:
 
 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.de]
 Sent: Tuesday, September 08, 2009 2:51 PM
 To: Paulraj, Sandeep
 Cc: u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

 Dear s-paul...@ti.com,

 In message 1252434246-19517-1-git-send-email-s-paul...@ti.com you wrote:
 From: Sandeep Paulraj s-paul...@ti.com

 This patch removes the asm/sizes.h header file from being
 included in the DaVinci SOC configs.
 References to SZ_xx have been replaced by appropriate
 bit shifted values.

 Signed-off-by: Sandeep Paulraj s-paul...@ti.com
 Note that this patch actually changes the configuration:

 --- a/include/configs/davinci_dm355evm.h
 +++ b/include/configs/davinci_dm355evm.h
 ...
  /* U-Boot memory configuration */
 -#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
 -#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc()
 arena */
 +#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
 +#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB*/
 as it increases the malloc() arena size form 512 to 1024 KiB.

 Assuming this was done intentionally:
 [Sandeep] Yes this was intentional because for NANDs with large block 
 sizes(256 KiB), if this is not increased we will get out of memory errors.
 Acked-by: Wolfgang Denk w...@denx.de


Then this change needs to be a separate patch.

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread J.C. Wren
Why is this change being made at all?  Seems a lot more awkward to define (1
 20) than SZ_1MB.  SZ_1MB reads a lot easier.

--jc

On Tue, Sep 8, 2009 at 3:09 PM, Tom tom@windriver.com wrote:

 Paulraj, Sandeep wrote:
 
  -Original Message-
  From: Wolfgang Denk [mailto:w...@denx.de]
  Sent: Tuesday, September 08, 2009 2:51 PM
  To: Paulraj, Sandeep
  Cc: u-boot@lists.denx.de
  Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
 
  Dear s-paul...@ti.com,
 
  In message 1252434246-19517-1-git-send-email-s-paul...@ti.com you
 wrote:
  From: Sandeep Paulraj s-paul...@ti.com
 
  This patch removes the asm/sizes.h header file from being
  included in the DaVinci SOC configs.
  References to SZ_xx have been replaced by appropriate
  bit shifted values.
 
  Signed-off-by: Sandeep Paulraj s-paul...@ti.com
  Note that this patch actually changes the configuration:
 
  --- a/include/configs/davinci_dm355evm.h
  +++ b/include/configs/davinci_dm355evm.h
  ...
   /* U-Boot memory configuration */
  -#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
  -#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc()
  arena */
  +#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
  +#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB*/
  as it increases the malloc() arena size form 512 to 1024 KiB.
 
  Assuming this was done intentionally:
  [Sandeep] Yes this was intentional because for NANDs with large block
 sizes(256 KiB), if this is not increased we will get out of memory errors.
  Acked-by: Wolfgang Denk w...@denx.de
 

 Then this change needs to be a separate patch.

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

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Paulraj, Sandeep
Jc,

Did you read what I wrote below the --- line in the patch itself?

Wolfgang wants to get rid of these references. He expressed this some time back.
If he decides to get rid of this file altogether this will lead to compilation 
failures.

Thanks,
Sandeep


From: jcw...@gmail.com [mailto:jcw...@gmail.com] On Behalf Of J.C. Wren
Sent: Tuesday, September 08, 2009 3:15 PM
To: Tom
Cc: Paulraj, Sandeep; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

Why is this change being made at all?  Seems a lot more awkward to define (1  
20) than SZ_1MB.  SZ_1MB reads a lot easier.

--jc
On Tue, Sep 8, 2009 at 3:09 PM, Tom 
tom@windriver.commailto:tom@windriver.com wrote:
Paulraj, Sandeep wrote:

 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.demailto:w...@denx.de]
 Sent: Tuesday, September 08, 2009 2:51 PM
 To: Paulraj, Sandeep
 Cc: u-boot@lists.denx.demailto:u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

 Dear s-paul...@ti.commailto:s-paul...@ti.com,

 In message 
 1252434246-19517-1-git-send-email-s-paul...@ti.commailto:1252434246-19517-1-git-send-email-s-paul...@ti.com
  you wrote:
 From: Sandeep Paulraj s-paul...@ti.commailto:s-paul...@ti.com

 This patch removes the asm/sizes.h header file from being
 included in the DaVinci SOC configs.
 References to SZ_xx have been replaced by appropriate
 bit shifted values.

 Signed-off-by: Sandeep Paulraj s-paul...@ti.commailto:s-paul...@ti.com
 Note that this patch actually changes the configuration:

 --- a/include/configs/davinci_dm355evm.h
 +++ b/include/configs/davinci_dm355evm.h
 ...
  /* U-Boot memory configuration */
 -#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
 -#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc()
 arena */
 +#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
 +#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB*/
 as it increases the malloc() arena size form 512 to 1024 KiB.

 Assuming this was done intentionally:
 [Sandeep] Yes this was intentional because for NANDs with large block 
 sizes(256 KiB), if this is not increased we will get out of memory errors.
 Acked-by: Wolfgang Denk w...@denx.demailto:w...@denx.de

Then this change needs to be a separate patch.

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

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


[U-Boot] [PATCH] mx27ads: add support for iMX27ADS board from Freescale

2009-09-08 Thread Alan Carvalho de Assis
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.
---
 MAINTAINERS |3 +
 MAKEALL |1 +
 Makefile|3 +
 board/freescale/mx27ads/Makefile|   51 
 board/freescale/mx27ads/config.mk   |1 +
 board/freescale/mx27ads/lowlevel_init.S |  130 +++
 board/freescale/mx27ads/mx27ads.c   |   93 ++
 board/freescale/mx27ads/u-boot.lds  |   56 +
 include/configs/mx27ads.h   |  205 +++
 9 files changed, 543 insertions(+), 0 deletions(-)
 create mode 100644 board/freescale/mx27ads/Makefile
 create mode 100644 board/freescale/mx27ads/config.mk
 create mode 100644 board/freescale/mx27ads/lowlevel_init.S
 create mode 100644 board/freescale/mx27ads/mx27ads.c
 create mode 100644 board/freescale/mx27ads/u-boot.lds
 create mode 100644 include/configs/mx27ads.h

diff --git a/MAINTAINERS b/MAINTAINERS
index e9db278..5b25188 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -550,6 +550,9 @@ Thomas Elste i...@elste.org

modnet50ARM720T (NET+50)

+Alan Carvalho de Assis acas...@gmail.com
+   mx27ads i.MX27
+
 Fabio Estevam fabio.este...@freescale.com

mx31pdk i.MX31
diff --git a/MAKEALL b/MAKEALL
index f0ed8ea..8411eef 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -520,6 +520,7 @@ LIST_ARM9= \
cp926ejs\
cp946es \
cp966   \
+   mx27ads \
imx27lite   \
lpd7a400\
mv88f6281gtw_ge \
diff --git a/Makefile b/Makefile
index 0449a5b..6fa4b28 100644
--- a/Makefile
+++ b/Makefile
@@ -2961,6 +2961,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
@$(MKCONFIG) $(@:_config=) arm lh7a40x lpd7a40x
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
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2000-2004
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS  := mx27ads.o
+SOBJS  := lowlevel_init.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
+
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
@@ -0,0 +1 @@
+TEXT_BASE = 0xA7F0
diff --git a/board/freescale/mx27ads/lowlevel_init.S
b/board/freescale/mx27ads/lowlevel_init.S
new file mode 100644
index 000..9560802
--- /dev/null
+++ b/board/freescale/mx27ads/lowlevel_init.S
@@ -0,0 +1,130 @@
+/*
+ * Copyright (C) 2008, Guennadi Liakhovetski l...@denx.de
+ *
+ * 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 

Re: [U-Boot] [PATCH] TQM85xx: enable partition support, sort commands

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

In message 971ea703-e556-477a-ae04-147ca724b...@kernel.crashing.org you wrote:
 
 On Sep 2, 2009, at 3:20 AM, Wolfgang Denk wrote:
 
  Signed-off-by: Wolfgang Denk w...@denx.de
  ---
  include/configs/TQM85xx.h |   18 +++---
  1 files changed, 11 insertions(+), 7 deletions(-)
 
 This breaks building of TQM85xx boards for me.

Confirmed, will post a new patch 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
They say a little knowledge is a dangerous thing,  but it is not  one
half so bad as a lot of ignorance.   - Terry Pratchett, _Equal Rites_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] TQM85xx: enable partition support, sort commands

2009-09-08 Thread Wolfgang Denk
Signed-off-by: Wolfgang Denk w...@denx.de

---
v2: Fix building for TQM8548_BE

On TQM8548_BE, building failed like that:
Configuring for TQM85xx board...
common/libcommon.a(cmd_mtdparts.o): In function 
`part_validate_eraseblock':
/home/wd/git/u-boot/work/common/cmd_mtdparts.c:316: undefined reference 
to `get_mtd_device_nm'
common/libcommon.a(cmd_mtdparts.o): In function `mtd_device_validate':
/home/wd/git/u-boot/work/common/cmd_mtdparts.c:706: undefined reference 
to `get_mtd_device_nm'
make: *** [u-boot] Error 1

This was because CONFIG_CMD_MTDPARTS was defined after it was
used. Move the part that uses it after the #define.

 include/configs/TQM85xx.h |   48 
 1 files changed, 26 insertions(+), 22 deletions(-)

diff --git a/include/configs/TQM85xx.h b/include/configs/TQM85xx.h
index 1fbf4bf..9548950 100644
--- a/include/configs/TQM85xx.h
+++ b/include/configs/TQM85xx.h
@@ -557,12 +557,34 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
+/*
+ * Command line configuration.
+ */
+#include config_cmd_default.h
+
+#ifndef CONFIG_TQM8548_AG
+#define CONFIG_CMD_DATE
+#endif
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_DTT
+#define CONFIG_CMD_EEPROM
+#define CONFIG_CMD_I2C
+#define CONFIG_CMD_JFFS2
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_CMD_NFS
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_SNTP
+
+#if defined(CONFIG_PCI)
+#define CONFIG_CMD_PCI
+#endif
+
 #ifdef CONFIG_NAND
 /*
  * Use NAND-FLash as JFFS2 device
  */
 #define CONFIG_CMD_NAND
-#define CONFIG_CMD_JFFS2
 
 #defineCONFIG_JFFS2_NAND   1
 
@@ -579,29 +601,11 @@
 
 #endif /* CONFIG_NAND */
 
-/*
- * Command line configuration.
- */
-#include config_cmd_default.h
-
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_I2C
-#define CONFIG_CMD_DHCP
-#define CONFIG_CMD_NFS
-#define CONFIG_CMD_SNTP
-#ifndef CONFIG_TQM8548_AG
-#define CONFIG_CMD_DATE
-#endif
-#define CONFIG_CMD_EEPROM
-#define CONFIG_CMD_DTT
-#define CONFIG_CMD_MII
-
-#if defined(CONFIG_PCI)
-#define CONFIG_CMD_PCI
-#endif
-
 #undef CONFIG_WATCHDOG /* watchdog disabled*/
 
+#define CONFIG_MAC_PARTITION
+#define CONFIG_DOS_PARTITION
+
 /*
  * Miscellaneous configurable options
  */
-- 
1.6.0.6

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


Re: [U-Boot] Please pull u-boot-mpc85xx - master branch

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

In message pine.lnx.4.64.0909080919540.2...@localhost.localdomain you wrote:
 The following changes since commit 0052a051f60a043f1730b3a46f23b3c7b0eb7820:
   Wolfgang Denk (1):
 Merge branch 'master' of git://git.denx.de/u-boot-i2c
 
 are available in the git repository at:
 
   git://git.denx.de/u-boot-mpc85xx.git master
 
 Anton Vorontsov (1):
   fsl: sys_eeprom: Fix 'may be used uninitialized' warning
 
 Dipen Dudhat (2):
   ppc/85xx: Use CONFIG_FSL_ESDHC to enable sdhc clk
   ppc/85xx: Fix up eSDHC controller clock frequency in the device tree
 
 Kumar Gala (7):
   ppc/8xxx: relocate cpu pointer in global data
   ppc/8xxx: Remove ddr_pd_cntl register since it doesn't exist
   85xx: Add support for setting IVORs to fixed offset defaults
   ppc/85xx: Add a simple function to search the TLB
   ppc/85xx: Fix bug in setup_mp code
   ppc/85xx: Cleanup makefile and related optional files
   ppc/8xxx: Refactor code to determine if PCI is enabled  agent/host
 
 Poonam Aggrwal (3):
   ppc/85xx,86xx: Handling Unknown SOC version
   ppc/85xx/86xx: Device tree fixup for number of cores
   ppc/85xx/86xx: Bug fix: call to puts in probecpu() moved to checkcpu().
 
 Timur Tabi (1):
   fsl: add register read-back to set_law()
 
  board/atum8548/atum8548.c |6 +-
  board/freescale/common/sys_eeprom.c   |3 +-
  board/freescale/mpc8536ds/mpc8536ds.c |   15 +-
  board/freescale/mpc8544ds/mpc8544ds.c |   14 +-
  board/freescale/mpc8548cds/mpc8548cds.c   |6 +-
  board/freescale/mpc8568mds/mpc8568mds.c   |4 +-
  board/freescale/mpc8569mds/mpc8569mds.c   |4 +-
  board/freescale/mpc8572ds/mpc8572ds.c |   17 +--
  board/freescale/mpc8610hpcd/mpc8610hpcd.c |   12 +-
  board/freescale/mpc8641hpcn/mpc8641hpcn.c |5 +-
  board/freescale/p1_p2_rdb/ddr.c   |5 -
  board/freescale/p1_p2_rdb/pci.c   |   10 +-
  board/freescale/p2020ds/p2020ds.c |   14 +-
  board/sbc8548/sbc8548.c   |6 +-
  board/tqc/tqm85xx/tqm85xx.c   |8 +-
  cpu/mpc85xx/Makefile  |   23 +++-
  cpu/mpc85xx/commproc.c|3 -
  cpu/mpc85xx/cpu.c |   14 +-
  cpu/mpc85xx/cpu_init.c|7 +
  cpu/mpc85xx/ddr-gen3.c|1 -
  cpu/mpc85xx/ether_fcc.c   |4 -
  cpu/mpc85xx/fdt.c |9 ++
  cpu/mpc85xx/fixed_ivor.S  |   79 ++
  cpu/mpc85xx/mp.c  |   32 -
  cpu/mpc85xx/pci.c |4 +-
  cpu/mpc85xx/release.S |3 +
  cpu/mpc85xx/serial_scc.c  |3 -
  cpu/mpc85xx/speed.c   |2 +-
  cpu/mpc85xx/start.S   |6 +
  cpu/mpc85xx/tlb.c |   27 
  cpu/mpc86xx/cpu.c |   11 +-
  cpu/mpc86xx/fdt.c |3 +
  cpu/mpc8xxx/Makefile  |2 +
  cpu/mpc8xxx/cpu.c |   11 +-
  cpu/mpc8xxx/ddr/ctrl_regs.c   |   23 ---
  cpu/mpc8xxx/fdt.c |   55 +++
  cpu/mpc8xxx/pci_cfg.c |  225 
 +
  drivers/misc/fsl_law.c|3 +-
  include/asm-ppc/fsl_ddr_sdram.h   |1 -
  include/asm-ppc/fsl_pci.h |5 +
  include/asm-ppc/immap_85xx.h  |2 +-
  include/asm-ppc/mmu.h |7 +-
  include/asm-ppc/processor.h   |   14 ++
  lib_ppc/board.c   |4 +
  44 files changed, 568 insertions(+), 144 deletions(-)
  create mode 100644 cpu/mpc85xx/fixed_ivor.S
  create mode 100644 cpu/mpc8xxx/fdt.c
  create mode 100644 cpu/mpc8xxx/pci_cfg.c

Done, 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
G's Third Law: In spite of all evidence  to  the  contra-
ry,  the  entire  universe  is composed of only two basic substances:
magic and bullshit.
H's Dictum:There is no magic ...
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v3] AT91: Add SD/MMC controller support

2009-09-08 Thread Albin Tonnerre
This patch allows to use the atmel_mci SD/MMC driver on the at91 architecture.
It contains:
 - initialization code for the MCI controller for all the supported AT91. It
   allows the use of only one controller even if a SoC has two controllers
   (anyway there's no support for it in atmel_mci as of now)
 - the necessary get_mci_clk_rate function
 - definition of MMCI_BASE for use in atmel_mci
 - the cpu_mmc_init function. As of now this is not used, but will be required
   when atmel_mci is ported to the new generic mmc API.

Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com
Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com
---
Changes since v1
 - Fix the MCI controller ID in the init code for CAP9, SAM9263 and SAM9G45
 - Move AT91_BASE_MCI* define to soc header
 - define AT91_BASE_MCI{0,1} instead of AT91_BASE_MCI for boards which have 2
   controllers
 - rework the way MMCI_BASE is defined accordingly

Changes since v2
 - allow using 8-bit bus width on CPUs that support it
 - change the arguments of atmel_mciX_hw_init to (slot, bus) so that it's more
   meaningful than (bitmask)

 cpu/arm926ejs/at91/at91cap9_devices.c   |   40 +++
 cpu/arm926ejs/at91/at91sam9260_devices.c|   37 ++
 cpu/arm926ejs/at91/at91sam9261_devices.c|   21 
 cpu/arm926ejs/at91/at91sam9263_devices.c|   72 +++
 cpu/arm926ejs/at91/at91sam9m10g45_devices.c |   56 +
 cpu/arm926ejs/at91/at91sam9rl_devices.c |   25 +
 include/asm-arm/arch-at91/at91_common.h |2 +
 include/asm-arm/arch-at91/at91cap9.h|2 +
 include/asm-arm/arch-at91/at91sam9260.h |1 +
 include/asm-arm/arch-at91/at91sam9261.h |1 +
 include/asm-arm/arch-at91/at91sam9263.h |2 +
 include/asm-arm/arch-at91/at91sam9g45.h |2 +
 include/asm-arm/arch-at91/at91sam9rl.h  |1 +
 include/asm-arm/arch-at91/clk.h |5 ++
 include/asm-arm/arch-at91/memory-map.h  |6 ++
 15 files changed, 273 insertions(+), 0 deletions(-)

diff --git a/cpu/arm926ejs/at91/at91cap9_devices.c 
b/cpu/arm926ejs/at91/at91cap9_devices.c
index 39e405f..de7048b 100644
--- a/cpu/arm926ejs/at91/at91cap9_devices.c
+++ b/cpu/arm926ejs/at91/at91cap9_devices.c
@@ -79,6 +79,46 @@ void at91_serial_hw_init(void)
 #endif
 }
 
+#ifdef CONFIG_ATMEL_MCI
+void at91_mci0_hw_init(int slot, int bus_width)
+{
+   at91_sys_write(AT91_PMC_PCER, 1  AT91CAP9_ID_MCI0);
+
+   /* CLK */
+   at91_set_A_periph(AT91_PIN_PA2, 0);
+
+   /* CMD */
+   at91_set_A_periph(AT91_PIN_PA1, 1);
+
+   /* DAT0, maybe DAT1..DAT3 */
+   at91_set_A_periph(AT91_PIN_PA0, 1);
+   if (bus_width == 4) {
+   at91_set_A_periph(AT91_PIN_PA3, 1);
+   at91_set_A_periph(AT91_PIN_PA4, 1);
+   at91_set_A_periph(AT91_PIN_PA5, 1);
+   }
+}
+
+void at91_mci1_hw_init(int slot, int bus_width)
+{
+   at91_sys_write(AT91_PMC_PCER, 1  AT91CAP9_ID_MCI0);
+
+   /* CLK */
+   at91_set_A_periph(AT91_PIN_PA16, 0);
+
+   /* CMD */
+   at91_set_A_periph(AT91_PIN_PA17, 1);
+
+   /* DAT0, maybe DAT1..DAT3 */
+   at91_set_A_periph(AT91_PIN_PA18, 1);
+   if (bus_width == 4) {
+   at91_set_A_periph(AT91_PIN_PA19, 1);
+   at91_set_A_periph(AT91_PIN_PA20, 1);
+   at91_set_A_periph(AT91_PIN_PA21, 1);
+   }
+}
+#endif
+
 #ifdef CONFIG_HAS_DATAFLASH
 void at91_spi0_hw_init(unsigned long cs_mask)
 {
diff --git a/cpu/arm926ejs/at91/at91sam9260_devices.c 
b/cpu/arm926ejs/at91/at91sam9260_devices.c
index f86cb99..f724f58 100644
--- a/cpu/arm926ejs/at91/at91sam9260_devices.c
+++ b/cpu/arm926ejs/at91/at91sam9260_devices.c
@@ -75,6 +75,43 @@ void at91_serial_hw_init(void)
 #endif
 }
 
+#ifdef CONFIG_ATMEL_MCI
+void at91_mci0_hw_init(int slot, int bus_width)
+{
+   at91_sys_write(AT91_PMC_PCER, 1  AT91SAM9260_ID_MCI);
+
+   /* CLK */
+   at91_set_A_periph(AT91_PIN_PA8, 0);
+
+   switch (slot) {
+   case 0:
+   /* CMD */
+   at91_set_A_periph(AT91_PIN_PA7, 1);
+
+   /* DAT0, maybe DAT1..DAT3 */
+   at91_set_A_periph(AT91_PIN_PA6, 1);
+   if (bus_width == 4) {
+   at91_set_A_periph(AT91_PIN_PA9, 1);
+   at91_set_A_periph(AT91_PIN_PA10, 1);
+   at91_set_A_periph(AT91_PIN_PA11, 1);
+   }
+   break;
+   case 1:
+   /* CMD */
+   at91_set_B_periph(AT91_PIN_PA1, 1);
+
+   /* DAT0, maybe DAT1..DAT3 */
+   at91_set_B_periph(AT91_PIN_PA0, 1);
+   if (bus_width == 4) {
+   at91_set_B_periph(AT91_PIN_PA3, 1);
+   at91_set_B_periph(AT91_PIN_PA4, 1);
+ 

Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

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

In message 17434f2e0909081312r3fe4523ej66ed4fc0275fa...@mail.gmail.com you 
wrote:

 Excellent explanation.  Thank you.

Indeed. Thanks to gvb.

I'd just like to add that you also never know if SZ_1M is 1024*1024 or 
1000*1000.

 I do like this (from the email link): (31 * 1024 * 1024).  And it appears
 not to give Wolfgang indigestion :)

It is probably the preferred form in many cases, line length
permitting :-) 31  20 is a bit shorter, but it's just a personal
preference, not something I consider better in any way.

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'll learn something  about  men  and  women  --  the  way  they're
supposed  to  be. Caring for each other, being happy with each other,
being good to each other. That's what we call love. You'll like  that
a lot.
-- Kirk, The Apple, stardate 3715.6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH][v1] r7780mp: fix typo in Ethernet chip model number comment.

2009-09-08 Thread Marcel Ziswiler
On Tue, 2009-09-08 at 20:37 +0200, Wolfgang Denk wrote:
 Your patch numbering is really, really confusing. There is a patch
 posted for the first time numbered as v2, another one as v3, and this
 here is the second version of a patch which is still numbered v1.

Sorry if I confused you, that was not my intention at all, but I truly 
carefully numbered my patches. Every patch having a v  1 was already posted 
here once before:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/67275
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67197
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67197

 I completely lost you here.
 
 I don;t understand if these patches are supposed to be part of a
 series, or if they are independet of each other, or what else these
 random vN additions might mean.  Please eluciadate.

If it would be a series, one would add something like [3/6] or such. So it is 
no series, just a few very simple patches.

 Also please note that new versions of a patch should contain a
 comment (below the --- line) that describes what has been changed
 compared to the old version, i. e. here something like: v2: added
 missing SoB line or so.

OK, this one is new for me, sorry. Unfortunately the one I looked at did not 
include any such history neither:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67181

 Given this confusion, I will ignore the whole batch of 7 patches you
 just sent. Please work on the other review comments, and then decide
 how you want to post them - as series or independent patches. Assume
 version numbering restarts from zero, as I really ignore this current
 patch series.

That's really sad.

Cheers

Marcel Ziswiler

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


Re: [U-Boot] [PATCH][v2] mpc8260: move FDT memory node fixup into common CPU code.

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

In message 1252440603.5386.40.ca...@com-21 you wrote:
 
 On Tue, 2009-09-08 at 20:25 +0200, Wolfgang Denk wrote:
  In which way is this patch version 2? I have not seen any v1 of such a
  patch?
 
 What about http://article.gmane.org/gmane.comp.boot-loaders.u-boot/67275? A 
 pair of glasses might help (;-p).

Heh. If that was sufficient. I'm alrady wearing glasses _and_ contact
lenses, and it didn't help.

Um... but why didn't you set the In-Reply-To: and References:
headers, then?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
2000 pounds of chinese soup   = 1 Won Ton
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets

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

In message 20090908202143.ga26...@b07421-ec1.am.freescale.net you wrote:
 On Tue, Sep 08, 2009 at 07:46:29PM +0200, Wolfgang Denk wrote:
   NAND and 36BIT are orthogonal options -- what is wrong with the previous
   suggestion of splitting them in mkconfig?
  
  I don't like this idea as it will pollute the namespace by a number of
  uncontrolled auto-generated #defines, which may be a nightmare to
  debug because you quickly forget where such definitions might be
  coming from - after you realize that they are actually set because you
  cannot find them in any board-related config or source file.
 
 Would this still be a big problem if the auto-generated defines were put
 in their own namespace (such as the CONFIG_MK_* that you suggested)?

Probably not a big problem, and maybe not even a practical problem.
But it is still ugly, and nothing I really like.

But as it seems that nobody else cares about this, and I don;t have
any better ideas either, I guess I should not block this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk  Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Once they go up, who cares where  they  come  down?  That's  not  my
department.   - Werner von Braun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH v2] TI DaVinci: Remove references to SZ_xx

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

In message 1252442075-21038-1-git-send-email-s-paul...@ti.com you wrote:
 From: Sandeep Paulraj s-paul...@ti.com
 
 This patch removes the asm/sizes.h header file from being
 included in the DaVinci SOC configs.
 References to SZ_xx have been replaced by appropriate
 bit shifted values.
 
 Signed-off-by: Sandeep Paulraj s-paul...@ti.com
 ---
 v2 version of the patch does not change the DM355 configuration as suggested
 by Tom. This will be addressed in another patch.
  include/configs/davinci_dm355evm.h  |9 -
  include/configs/davinci_dm365evm.h  |9 -
  include/configs/davinci_dvevm.h |5 ++---
  include/configs/davinci_schmoogie.h |3 +--
  include/configs/davinci_sffsdr.h|3 +--
  include/configs/davinci_sonata.h|3 +--
  6 files changed, 13 insertions(+), 19 deletions(-)

Acked-by: Wolfgang Denk w...@denx.de

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's the sound a name makes when it's dropped?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2009-09-08 Thread Marcel Ziswiler
Hi Wolfgang Denk

On Tue, 2009-09-08 at 20:41 +0200, Wolfgang Denk wrote:
 Please put the affected board maintainers on Cc:

OK, sorry. Added them now.

 How much testing has this patch seen?

Tested on ep8248. Unfortunately I don't have access to any of the other boards.

 What about the other boards then? Say MPC8260ADS or mpc7448hpc2?

As OF_CPU and OF_SOC is only ever used in cpu/mpc512x/cpu.c and 
cpu/mpc5xxx/cpu.c there is no impact whatever on any of the other boards.

Cheers

Marcel Ziswiler

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


Re: [U-Boot] [PATCH][v1] r7780mp: fix typo in Ethernet chip model number comment.

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

In message 1252442498.5386.67.ca...@com-21 you wrote:
 On Tue, 2009-09-08 at 20:37 +0200, Wolfgang Denk wrote:
  Your patch numbering is really, really confusing. There is a patch
  posted for the first time numbered as v2, another one as v3, and this
  here is the second version of a patch which is still numbered v1.
 
 Sorry if I confused you, that was not my intention at all, but I truly 
 carefully numbered my patches. Every patch having a v  1 was already posted 
 here once before:
 http://article.gmane.org/gmane.comp.boot-loaders.u-boot/67275
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67197
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67197

Could you please make sure not to break threading, then?

  Given this confusion, I will ignore the whole batch of 7 patches you
  just sent. Please work on the other review comments, and then decide
  how you want to post them - as series or independent patches. Assume
  version numbering restarts from zero, as I really ignore this current
  patch series.
 
 That's really sad.

Not really; I think most patches need minor changes anyway.

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 dangerous to be right on a subject  on  which  the  established
authorities are wrong.-- Voltaire
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets

2009-09-08 Thread Scott Wood
Wolfgang Denk wrote:
 Would this still be a big problem if the auto-generated defines were put
 in their own namespace (such as the CONFIG_MK_* that you suggested)?
 
 Probably not a big problem, and maybe not even a practical problem.
 But it is still ugly, and nothing I really like.

Well, yes -- the long term, less-ugly solution is kconfig.

 But as it seems that nobody else cares about this, and I don;t have
 any better ideas either, I guess I should not block this.

Thanks.

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


[U-Boot] [PATCH v2] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread s-paulraj
From: Sandeep Paulraj s-paul...@ti.com

This patch removes the asm/sizes.h header file from being
included in the DaVinci SOC configs.
References to SZ_xx have been replaced by appropriate
bit shifted values.

Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
v2 version of the patch does not change the DM355 configuration as suggested
by Tom. This will be addressed in another patch.
 include/configs/davinci_dm355evm.h  |9 -
 include/configs/davinci_dm365evm.h  |9 -
 include/configs/davinci_dvevm.h |5 ++---
 include/configs/davinci_schmoogie.h |3 +--
 include/configs/davinci_sffsdr.h|3 +--
 include/configs/davinci_sonata.h|3 +--
 6 files changed, 13 insertions(+), 19 deletions(-)

diff --git a/include/configs/davinci_dm355evm.h 
b/include/configs/davinci_dm355evm.h
index c35f5c9..4546f64 100644
--- a/include/configs/davinci_dm355evm.h
+++ b/include/configs/davinci_dm355evm.h
@@ -19,7 +19,6 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
-#include asm/sizes.h
 
 /* Spectrum Digital TMS320DM355 EVM board */
 #define DAVINCI_DM355EVM
@@ -40,7 +39,7 @@
 /* Memory Info */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0x8000
-#define PHYS_SDRAM_1_SIZE  SZ_128M
+#define PHYS_SDRAM_1_SIZE  (128  20) /* 128 MiB */
 
 /* Serial Driver info: UART0 for console  */
 #define CONFIG_SYS_NS16550
@@ -130,7 +129,7 @@
 #define CONFIG_SYS_PROMPT_HUSH_PS2  
 #define CONFIG_SYS_LONGHELP
 
-#define CONFIG_ENV_SIZESZ_16K
+#define CONFIG_ENV_SIZE(16  10)  /* 16 KiB */
 
 /* NYET -- #define CONFIG_BOOTDELAY5 */
 #define CONFIG_BOOTCOMMAND \
@@ -146,8 +145,8 @@
 #define CONFIG_NET_RETRY_COUNT 10
 
 /* U-Boot memory configuration */
-#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
-#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc() arena */
+#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
+#define CONFIG_SYS_MALLOC_LEN  (512  10) /* 512 KiB */
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* for initial data */
 #define CONFIG_SYS_MEMTEST_START   0x8700  /* physical address */
 #define CONFIG_SYS_MEMTEST_END 0x8800  /* test 16MB RAM */
diff --git a/include/configs/davinci_dm365evm.h 
b/include/configs/davinci_dm365evm.h
index 47cb554..72eccb9 100644
--- a/include/configs/davinci_dm365evm.h
+++ b/include/configs/davinci_dm365evm.h
@@ -18,7 +18,6 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
-#include asm/sizes.h
 
 /* Spectrum Digital TMS320DM365 EVM board */
 #define DAVINCI_DM365EVM
@@ -38,7 +37,7 @@
 /* Memory Info */
 #define CONFIG_NR_DRAM_BANKS   1
 #define PHYS_SDRAM_1   0x8000
-#define PHYS_SDRAM_1_SIZE  SZ_128M
+#define PHYS_SDRAM_1_SIZE  (128  20) /* 128 MiB */
 
 /* Serial Driver info: UART0 for console  */
 #define CONFIG_SYS_NS16550
@@ -125,7 +124,7 @@
 #define CONFIG_SYS_LONGHELP
 
 #ifdef CONFIG_NAND_DAVINCI
-#define CONFIG_ENV_SIZESZ_256K
+#define CONFIG_ENV_SIZE(256  10) /* 256 KiB */
 #define CONFIG_ENV_IS_IN_NAND
 #define CONFIG_ENV_OFFSET  0x3C
 #undef CONFIG_ENV_IS_IN_FLASH
@@ -143,8 +142,8 @@
 #define CONFIG_TIMESTAMP
 
 /* U-Boot memory configuration */
-#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
-#define CONFIG_SYS_MALLOC_LEN  SZ_1M   /* malloc() arena */
+#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
+#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB */
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* for initial data */
 #define CONFIG_SYS_MEMTEST_START   0x8700  /* physical address */
 #define CONFIG_SYS_MEMTEST_END 0x8800  /* test 16MB RAM */
diff --git a/include/configs/davinci_dvevm.h b/include/configs/davinci_dvevm.h
index 96b6afc..af669bc 100644
--- a/include/configs/davinci_dvevm.h
+++ b/include/configs/davinci_dvevm.h
@@ -19,7 +19,6 @@
 
 #ifndef __CONFIG_H
 #define __CONFIG_H
-#include asm/sizes.h
 
 /*
  * Define this to make U-Boot skip low level initialization when loaded
@@ -120,7 +119,7 @@
 #define CONFIG_ENV_IS_IN_NAND  /* U-Boot env in NAND Flash  */
 #ifdef CONFIG_SYS_NAND_SMALLPAGE
 #define CONFIG_ENV_SECT_SIZE   512 /* Env sector Size */
-#define CONFIG_ENV_SIZESZ_16K
+#define CONFIG_ENV_SIZE(16  10)  /* 16 KiB */
 #define CONFIG_MTD_PARTITIONS
 #define CONFIG_CMD_MTDPARTS
 #define MTDIDS_DEFAULT \
@@ -129,7 +128,7 @@
mtdparts=davinci_nand.0:384k(bootloader)ro,4m(kernel),-(filesystem)
 #else
 #define CONFIG_ENV_SECT_SIZE   2048/* Env sector Size */
-#define CONFIG_ENV_SIZESZ_128K
+#define CONFIG_ENV_SIZE(128  10) /* 128 KiB */
 #endif
 #define CONFIG_SKIP_LOWLEVEL_INIT  /* U-Boot is loaded by a bootloader */
 

Re: [U-Boot] [PATCH][v2] mpc8260: move FDT memory node fixup into common CPU code.

2009-09-08 Thread Marcel Ziswiler
Dear Wolfgang Denk

On Tue, 2009-09-08 at 22:44 +0200, Wolfgang Denk wrote:
 Heh. If that was sufficient. I'm alrady wearing glasses _and_ contact
 lenses, and it didn't help.

I do know that as I saw you at the EW in Nürnberg this spring.

 Um... but why didn't you set the In-Reply-To: and References:
 headers, then?

Sorry about that, my understanding was to post new versions of a patch as a new 
thread. Is that not so?

What exactly is that references header you are talking about?

Cheers

Marcel Ziswiler

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


Re: [U-Boot] [PATCH][v3] ep8248: add support for device tree and secondary Ethernet interface.

2009-09-08 Thread Marcel Ziswiler
Dear Wolfgang Denk

On Tue, 2009-09-08 at 20:46 +0200, Wolfgang Denk wrote:
 Please put the board maintainer on Cc:

OK, did so now.

 We don't add copyright entries for so few lines of code.  And we don;t
 add a change log either. We have git to track the history of changes
 for us.

OK, sorry. Will change that.

Cheers

Marcel Ziswiler

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


[U-Boot] [PATCH v3] TQM85xx: enable partition support, sort commands

2009-09-08 Thread Wolfgang Denk
Signed-off-by: Wolfgang Denk w...@denx.de

---
v2: Fix building for TQM8548_BE

On TQM8548_BE, building failed like that:
Configuring for TQM85xx board...
common/libcommon.a(cmd_mtdparts.o): In function 
`part_validate_eraseblock':
/home/wd/git/u-boot/work/common/cmd_mtdparts.c:316: undefined reference 
to `get_mtd_device_nm'
common/libcommon.a(cmd_mtdparts.o): In function `mtd_device_validate':
/home/wd/git/u-boot/work/common/cmd_mtdparts.c:706: undefined reference 
to `get_mtd_device_nm'
make: *** [u-boot] Error 1

This was because CONFIG_CMD_MTDPARTS was defined after it was
used. Move the part that uses it after the #define.
v3: Fix undefined reference to `get_mtd_device_nm' errors for
non-8548 boards; build-tested with ELDK 4.2 on TQM8540, TQM8541,
TQM8548, TQM8548_AG, TQM8548_BE, TQM8555 and TQM8560

 include/configs/TQM85xx.h |   51 
 1 files changed, 28 insertions(+), 23 deletions(-)

diff --git a/include/configs/TQM85xx.h b/include/configs/TQM85xx.h
index 1fbf4bf..8f7fe0e 100644
--- a/include/configs/TQM85xx.h
+++ b/include/configs/TQM85xx.h
@@ -557,17 +557,40 @@
 #define CONFIG_BOOTP_GATEWAY
 #define CONFIG_BOOTP_HOSTNAME
 
+/*
+ * Command line configuration.
+ */
+#include config_cmd_default.h
+
+#ifndef CONFIG_TQM8548_AG
+#define CONFIG_CMD_DATE
+#endif
+#define CONFIG_CMD_DHCP
+#define CONFIG_CMD_DTT
+#define CONFIG_CMD_EEPROM
+#define CONFIG_CMD_I2C
+#define CONFIG_CMD_JFFS2
+#define CONFIG_CMD_MII
+#define CONFIG_CMD_MTDPARTS
+#define CONFIG_CMD_NFS
+#define CONFIG_CMD_PING
+#define CONFIG_CMD_SNTP
+
+#if defined(CONFIG_PCI)
+#define CONFIG_CMD_PCI
+#endif
+
+#define CONFIG_MTD_DEVICE  /* needed for mtdparts commands */
+
 #ifdef CONFIG_NAND
 /*
  * Use NAND-FLash as JFFS2 device
  */
 #define CONFIG_CMD_NAND
-#define CONFIG_CMD_JFFS2
 
 #defineCONFIG_JFFS2_NAND   1
 
 #ifdef CONFIG_CMD_MTDPARTS
-#define CONFIG_MTD_DEVICE  /* needed for mtdparts commands */
 #define CONFIG_FLASH_CFI_MTD
 #define MTDIDS_DEFAULT nand0=TQM85xx-nand
 #define MTDPARTS_DEFAULT   mtdparts=TQM85xx-nand:-
@@ -579,29 +602,11 @@
 
 #endif /* CONFIG_NAND */
 
-/*
- * Command line configuration.
- */
-#include config_cmd_default.h
-
-#define CONFIG_CMD_PING
-#define CONFIG_CMD_I2C
-#define CONFIG_CMD_DHCP
-#define CONFIG_CMD_NFS
-#define CONFIG_CMD_SNTP
-#ifndef CONFIG_TQM8548_AG
-#define CONFIG_CMD_DATE
-#endif
-#define CONFIG_CMD_EEPROM
-#define CONFIG_CMD_DTT
-#define CONFIG_CMD_MII
-
-#if defined(CONFIG_PCI)
-#define CONFIG_CMD_PCI
-#endif
-
 #undef CONFIG_WATCHDOG /* watchdog disabled*/
 
+#define CONFIG_MAC_PARTITION
+#define CONFIG_DOS_PARTITION
+
 /*
  * Miscellaneous configurable options
  */
-- 
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][v1] FDT: remove obsolete OF_CPU and OF_SOC macros.

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

In message 1252444556.5386.91.ca...@com-21 you wrote:
 
 On Tue, 2009-09-08 at 23:11 +0200, Wolfgang Denk wrote:
  The patch should remove the macros then from the respective config
  files.
 
 Isn't that exactly what my patch does?

It doesn't do it for all affected boards. That's why I asked about for
example MPC8260ADS or mpc7448hpc2:

- grep OF_CPU include/configs/{MPC8260ADS,mpc7448hpc2}.h
include/configs/MPC8260ADS.h:#define OF_CPU c...@0
include/configs/mpc7448hpc2.h:#define OF_CPUPowerPC,7...@0



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 average woman would rather have beauty than brains,  because  the
average man can see better than he can think.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2009-09-08 Thread Marcel Ziswiler
On Tue, 2009-09-08 at 23:23 +0200, Wolfgang Denk wrote:
 It doesn't do it for all affected boards. That's why I asked about for
 example MPC8260ADS or mpc7448hpc2:
 - grep OF_CPU include/configs/{MPC8260ADS,mpc7448hpc2}.h
 include/configs/MPC8260ADS.h:#define OF_CPU c...@0
 include/configs/mpc7448hpc2.h:#define OF_CPU
 PowerPC,7...@0

Yes it does. What are you talking about?

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Jerry Van Baren
Wolfgang Denk wrote:
 Dear J.C. Wren,
 
 In message 17434f2e0909081312r3fe4523ej66ed4fc0275fa...@mail.gmail.com you 
 wrote:
 Excellent explanation.  Thank you.
 
 Indeed. Thanks to gvb.
 
 I'd just like to add that you also never know if SZ_1M is 1024*1024 or 
 1000*1000.
 
 I do like this (from the email link): (31 * 1024 * 1024).  And it appears
 not to give Wolfgang indigestion :)
 
 It is probably the preferred form in many cases, line length
 permitting :-) 31  20 is a bit shorter, but it's just a personal

s/3// ;-)

 preference, not something I consider better in any way.
 
 Best regards,
 
 Wolfgang Denk

Another objection: Company A makes their favorite SZ_* defines but 
Company B defines them as SIZE_* but Company C defines them as...

...and we end up with the same mess as INT32 vs. WORD vs. int32_t 
defines (C99 tackled that, finally, but not all the mess has been 
cleaned up yet, 10 years later).

Best regards,
gvb

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Wolfgang Denk
Dear Jerry Van Baren,

In message 4aa6c913.7000...@ge.com you wrote:

  I'd just like to add that you also never know if SZ_1M is 1024*1024 or 
  1000*1000.
  
  I do like this (from the email link): (31 * 1024 * 1024).  And it appears
  not to give Wolfgang indigestion :)
  
  It is probably the preferred form in many cases, line length
  permitting :-) 31  20 is a bit shorter, but it's just a personal
 
 s/3// ;-)

No. I intended to state that 31  20 is a bit shorter than
(31 * 1024 * 1024).

With your substitution, it would also be much less :-)

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
Conceptual integrity in turn dictates that the  design  must  proceed
from  one  mind,  or  from  a  very small number of agreeing resonant
minds.   - Frederick Brooks Jr., The Mythical Man Month
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


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

2009-09-08 Thread Marcel Ziswiler
Dear Wolfang Denk

On Tue, 2009-09-08 at 23:11 +0200, Wolfgang Denk wrote:
 The patch should remove the macros then from the respective config
 files.

Isn't that exactly what my patch does?

Cheers

Marcel Ziswiler

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Paulraj, Sandeep
Jc,

Wolfgang is the best person to answer your question.

Also read this
http://lists.denx.de/pipermail/u-boot/2009-September/059794.html

The way I look at things, any new patches or files with such references are 
going to get comments from him.

I will be submitting patches based on his suggestion above so just removing 
such references to make things consistent across all DaVinci SOCs.

As I said before if the concerned header files are removed at least DaVinci 
SOCs will not be affected.

Thanks,
Sandeep



From: jcw...@gmail.com [mailto:jcw...@gmail.com] On Behalf Of J.C. Wren
Sent: Tuesday, September 08, 2009 3:28 PM
To: Paulraj, Sandeep
Cc: Tom; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

I saw this comment: Also i gather from e-mails on the list that Wolfgang does 
not like these references to SZ_xx.  Maybe that discussion took place before 
I joined the list.

If he wants it that way, fine.  But that doesn't explain the why.  What's so 
offensive about the SZ_* defines?

--jc
On Tue, Sep 8, 2009 at 3:20 PM, Paulraj, Sandeep 
s-paul...@ti.commailto:s-paul...@ti.com wrote:

Jc,



Did you read what I wrote below the --- line in the patch itself?



Wolfgang wants to get rid of these references. He expressed this some time back.

If he decides to get rid of this file altogether this will lead to compilation 
failures.



Thanks,

Sandeep





From: jcw...@gmail.commailto:jcw...@gmail.com 
[mailto:jcw...@gmail.commailto:jcw...@gmail.com] On Behalf Of J.C. Wren
Sent: Tuesday, September 08, 2009 3:15 PM
To: Tom
Cc: Paulraj, Sandeep; u-boot@lists.denx.demailto:u-boot@lists.denx.de

Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx



Why is this change being made at all?  Seems a lot more awkward to define (1  
20) than SZ_1MB.  SZ_1MB reads a lot easier.

--jc

On Tue, Sep 8, 2009 at 3:09 PM, Tom 
tom@windriver.commailto:tom@windriver.com wrote:

Paulraj, Sandeep wrote:

 -Original Message-
 From: Wolfgang Denk [mailto:w...@denx.demailto:w...@denx.de]
 Sent: Tuesday, September 08, 2009 2:51 PM
 To: Paulraj, Sandeep
 Cc: u-boot@lists.denx.demailto:u-boot@lists.denx.de
 Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

 Dear s-paul...@ti.commailto:s-paul...@ti.com,

 In message 
 1252434246-19517-1-git-send-email-s-paul...@ti.commailto:1252434246-19517-1-git-send-email-s-paul...@ti.com
  you wrote:
 From: Sandeep Paulraj s-paul...@ti.commailto:s-paul...@ti.com

 This patch removes the asm/sizes.h header file from being
 included in the DaVinci SOC configs.
 References to SZ_xx have been replaced by appropriate
 bit shifted values.

 Signed-off-by: Sandeep Paulraj s-paul...@ti.commailto:s-paul...@ti.com
 Note that this patch actually changes the configuration:

 --- a/include/configs/davinci_dm355evm.h
 +++ b/include/configs/davinci_dm355evm.h
 ...
  /* U-Boot memory configuration */
 -#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
 -#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc()
 arena */
 +#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
 +#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB*/
 as it increases the malloc() arena size form 512 to 1024 KiB.

 Assuming this was done intentionally:
 [Sandeep] Yes this was intentional because for NANDs with large block 
 sizes(256 KiB), if this is not increased we will get out of memory errors.
 Acked-by: Wolfgang Denk w...@denx.demailto:w...@denx.de


Then this change needs to be a separate patch.

Nak Tom

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



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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread J.C. Wren
On Tue, Sep 8, 2009 at 4:07 PM, Jerry Van Baren gerald.vanba...@ge.comwrote:

 J.C. Wren wrote:

 I saw this comment: Also i gather from e-mails on the list that Wolfgang
 does not like these references to SZ_xx.  Maybe that discussion took
 place
 before I joined the list.

 If he wants it that way, fine.  But that doesn't explain the why.
  What's
 so offensive about the SZ_* defines?

 --jc


 Hi J.C.,

 The SZ_* defines turns a simple math problem into a two finger problem...
 every time you see them, you need to put your finger in the code and look
 them up, only to find (1  n), have to stick a second finger in the code,
 and have to do the math anyway.

 One REALLY BAD problem is that idiots have been known to mis-define them
 rather than fix the code that uses them (seriously!).  By using (1  20)
 directly, it removes that temptation.

 A lesser problem is that they don't do anything, you still have to figure
 out that 1  20 is 1MiB.  All they do is defer the pain.

 You will also find other silliness, e.g. generating SZ_31M:
 http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/27048/focus=27139
 This silliness is the road to insanity: SZ_30M and SZ_29M and SZ_28.125M.
 (OK, I exaggerated on that last one.  It would actually be SZ_28_125M.)

 HTH,
 gvb

 [snip]


Excellent explanation.  Thank you.

I do like this (from the email link): (31 * 1024 * 1024).  And it appears
not to give Wolfgang indigestion :)

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


Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets

2009-09-08 Thread Scott Wood
On Tue, Sep 08, 2009 at 07:46:29PM +0200, Wolfgang Denk wrote:
  NAND and 36BIT are orthogonal options -- what is wrong with the previous
  suggestion of splitting them in mkconfig?
 
 I don't like this idea as it will pollute the namespace by a number of
 uncontrolled auto-generated #defines, which may be a nightmare to
 debug because you quickly forget where such definitions might be
 coming from - after you realize that they are actually set because you
 cannot find them in any board-related config or source file.

Would this still be a big problem if the auto-generated defines were put
in their own namespace (such as the CONFIG_MK_* that you suggested)?

-Scott
___
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-08 Thread Eric Bénard
Hi Jean-Christophe,

Jean-Christophe PLAGNIOL-VILLARD a écrit :
 On 18:15 Sat 05 Sep , Eric Benard 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 e...@eukrea.com
 ---
  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

 it's looks fine
 
do you plan to merge it or should I fix anything ?

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


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

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

In message 1252443024.5386.76.ca...@com-21 you wrote:
 
  What about the other boards then? Say MPC8260ADS or mpc7448hpc2?
 
 As OF_CPU and OF_SOC is only ever used in cpu/mpc512x/cpu.c and
 cpu/mpc5xxx/cpu.c there is no impact whatever on any of the other
 boards.

The patch should remove the macros then from the respective config
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
I don't mind criticism. You know me. I've  never  been  one  to  take
offence  at  criticism. No one could say I'm the sort to take offence
at criticism -- Not twice, anyway. Not without blowing bubbles.
  - Terry Pratchett, _Witches Abroad_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Wolfgang Denk
Dear Sandeep,

In message 0554bef07d437848af01b9c9b5f0bc5d92568...@dlee01.ent.ti.com you 
wrote:
 
 Now how do I handle this?
 Should I make a next branch and push this patch to the next branch or push
 it directly to the master.

The merge window is open, so you can push this to master (and when
you think enough patches have been stacked and/or time has come you
send a pull request to Tom).

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 have to protect the environment -- the Second Coming is  at
hand.   - James Watt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH][v1] mpc8260: remove Ethernet node fixup to use generic FDT code.

2009-09-08 Thread Marcel Ziswiler
Hi Wolfgang Denk

On Tue, 2009-09-08 at 20:31 +0200, Wolfgang Denk wrote:
 Should / could a similar change be added to
 board/keymile/km8xx/km8xx.c, too?

You mean the kmsupx4 and mgsuvd boards. I guess as Ethernet node fixup is 
already done in generic mpc8xx CPU code. I am afraid there might be lots more 
boards with similar obsolete fixups in board specific code.

Heiko?

Cheers

Marcel Ziswiler

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


Re: [U-Boot] [PATCH][v2] mpc8260: move FDT memory node fixup into common CPU code.

2009-09-08 Thread Marcel Ziswiler
On Tue, 2009-09-08 at 23:19 +0200, Wolfgang Denk wrote:
 No, on contrary. New versions of a patch should always make sure to
 thread correctly to the old version(s). It seems that preferences here
 are a matter of taste - my personal preference is to link to the
 preceeding version of the patch, but most others seem to prefer to
 link to the first version always.

That's kind of what I thought at first as well, but then I saw many
others posting patches not adhering to that and still getting your ack
no problem:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67581
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67462
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/67394
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/67187

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Jerry Van Baren
J.C. Wren wrote:
 I saw this comment: Also i gather from e-mails on the list that Wolfgang
 does not like these references to SZ_xx.  Maybe that discussion took place
 before I joined the list.
 
 If he wants it that way, fine.  But that doesn't explain the why.  What's
 so offensive about the SZ_* defines?
 
 --jc

Hi J.C.,

The SZ_* defines turns a simple math problem into a two finger 
problem... every time you see them, you need to put your finger in the 
code and look them up, only to find (1  n), have to stick a second 
finger in the code, and have to do the math anyway.

One REALLY BAD problem is that idiots have been known to mis-define them 
rather than fix the code that uses them (seriously!).  By using (1  
20) directly, it removes that temptation.

A lesser problem is that they don't do anything, you still have to 
figure out that 1  20 is 1MiB.  All they do is defer the pain.

You will also find other silliness, e.g. generating SZ_31M:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/27048/focus=27139
This silliness is the road to insanity: SZ_30M and SZ_29M and 
SZ_28.125M. (OK, I exaggerated on that last one.  It would actually be 
SZ_28_125M.)

HTH,
gvb

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


Re: [U-Boot] [PATCH v2] 85xx: Move to a common linker script

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

In message 1249997451-21265-1-git-send-email-ga...@kernel.crashing.org you 
wrote:
 There are really no differences between all the 85xx linker scripts so
 we can just move to a single common one.  Board code is still able to
 override the common one if need be.
 
 Signed-off-by: Kumar Gala ga...@kernel.crashing.org
 ---

This commit breaks building TQM85xx boards.


Before this commit:

- git-describe
v2009.08-rc3-56-g87c7661
- ./MAKEALL TQM8555
... TQM8555 (MPC8555)
Configuring for TQM85xx board...
   textdata bss dec hex filename
 220096   16140   34552  270788   421c4 ./u-boot


After this commit:

- git-describe
v2009.08-rc3-57-gec79d33
- ./MAKEALL TQM8555
... TQM8555 (MPC8555)
Configuring for TQM85xx board...
ppc_6xx-ld: u-boot: section .text lma 0xfffc overlaps previous 
sections
ppc_6xx-ld: u-boot: section .rodata lma 0xfffebe3c overlaps previous 
sections
ppc_6xx-ld: u-boot: section .reloc lma 0x5a00 overlaps previous 
sections
ppc_6xx-ld: u-boot: section .data lma 0x6fe8 overlaps previous 
sections
ppc_6xx-ld: u-boot: section .data.rel.ro.local lma 0x7cbc overlaps 
previous sections
ppc_6xx-ld: u-boot: section .data.rel lma 0x7d1c overlaps previous 
sections
ppc_6xx-ld: u-boot: section .data.rel.local lma 0x86b8 overlaps 
previous sections
ppc_6xx-ld: u-boot: section .u_boot_cmd lma 0x93e8 overlaps 
previous sections
   textdata bss dec hex filename
 220096   16140   34552  270788   421c4 ./u-boot


Please help.

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 beginning, I was made. I didn't ask to be made. No one consul-
ted with me or considered my feelings  in  this  matter.  But  if  it
brought  some  passing fancy to some lowly humans as they haphazardly
pranced their way through life's mournful jungle, then so be it.
- Marvin the Paranoid Android
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread J.C. Wren
I saw this comment: Also i gather from e-mails on the list that Wolfgang
does not like these references to SZ_xx.  Maybe that discussion took place
before I joined the list.

If he wants it that way, fine.  But that doesn't explain the why.  What's
so offensive about the SZ_* defines?

--jc

On Tue, Sep 8, 2009 at 3:20 PM, Paulraj, Sandeep s-paul...@ti.com wrote:

  Jc,



 Did you read what I wrote below the --- line in the patch itself?



 Wolfgang wants to get rid of these references. He expressed this some time
 back.

 If he decides to get rid of this file altogether this will lead to
 compilation failures.



 Thanks,

 Sandeep


   --

 *From:* jcw...@gmail.com [mailto:jcw...@gmail.com] *On Behalf Of *J.C.
 Wren
 *Sent:* Tuesday, September 08, 2009 3:15 PM
 *To:* Tom
 *Cc:* Paulraj, Sandeep; u-boot@lists.denx.de

 *Subject:* Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx



 Why is this change being made at all?  Seems a lot more awkward to define
 (1  20) than SZ_1MB.  SZ_1MB reads a lot easier.

 --jc

 On Tue, Sep 8, 2009 at 3:09 PM, Tom tom@windriver.com wrote:

 Paulraj, Sandeep wrote:
 
  -Original Message-
  From: Wolfgang Denk [mailto:w...@denx.de]
  Sent: Tuesday, September 08, 2009 2:51 PM
  To: Paulraj, Sandeep
  Cc: u-boot@lists.denx.de
  Subject: Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx
 
  Dear s-paul...@ti.com,
 
  In message 1252434246-19517-1-git-send-email-s-paul...@ti.com you
 wrote:
  From: Sandeep Paulraj s-paul...@ti.com
 
  This patch removes the asm/sizes.h header file from being
  included in the DaVinci SOC configs.
  References to SZ_xx have been replaced by appropriate
  bit shifted values.
 
  Signed-off-by: Sandeep Paulraj s-paul...@ti.com
  Note that this patch actually changes the configuration:
 
  --- a/include/configs/davinci_dm355evm.h
  +++ b/include/configs/davinci_dm355evm.h
  ...
   /* U-Boot memory configuration */
  -#define CONFIG_STACKSIZE   SZ_256K /* regular stack */
  -#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc()
  arena */
  +#define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
  +#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB*/
  as it increases the malloc() arena size form 512 to 1024 KiB.
 
  Assuming this was done intentionally:
  [Sandeep] Yes this was intentional because for NANDs with large block
 sizes(256 KiB), if this is not increased we will get out of memory errors.
  Acked-by: Wolfgang Denk w...@denx.de
 

 Then this change needs to be a separate patch.

 Nak Tom

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



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


[U-Boot] [PATCH v2] TI DaVinci: DM355: Config Cleanup and Update

2009-09-08 Thread s-paulraj
From: Sandeep Paulraj s-paul...@ti.com

This patch does the following
1) Enables the NAND driver which is now available.
2) Enables the 'CONFIG_MTD_DEVICE' as without this the
compilation will fail
3) We now have a safe place to store environment and defines
an offset where this can be stored. This offset value is such that it is after
the location where U-Boot is flashed using TI flash utilities.
4) Enables Bootdelay
5) Increases malloc() arena size. Manufacturers are coming out with
NAND with large blocks sizes of upto 1 MiB. It has been noticed that
as the block size of the NAND used is increased, if this particular
value is not increased, the NAND driver will output out of memory
errors.

Signed-off-by: Sandeep Paulraj s-paul...@ti.com
---
Changes since the initial version mainly invloved submitting a separate
patch to get rid of references to SZ_xx
 include/configs/davinci_dm355evm.h |   21 -
 1 files changed, 12 insertions(+), 9 deletions(-)

diff --git a/include/configs/davinci_dm355evm.h 
b/include/configs/davinci_dm355evm.h
index 4546f64..d092fb8 100644
--- a/include/configs/davinci_dm355evm.h
+++ b/include/configs/davinci_dm355evm.h
@@ -65,9 +65,10 @@
 #define CONFIG_SYS_I2C_SLAVE   0x10/* SMBus host address */
 
 /* NAND: socketed, two chipselects, normally 2 GBytes */
-/* NYET -- #define CONFIG_NAND_DAVINCI */
-#define CONFIG_SYS_NAND_HW_ECC
+#define CONFIG_NAND_DAVINCI
 #define CONFIG_SYS_NAND_USE_FLASH_BBT
+#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+#define CONFIG_SYS_NAND_PAGE_2K
 
 #define CONFIG_SYS_NAND_LARGEPAGE
 #define CONFIG_SYS_NAND_BASE_LIST  { 0x0200, }
@@ -95,15 +96,12 @@
 #ifdef CONFIG_NAND_DAVINCI
 #define CONFIG_CMD_MTDPARTS
 #define CONFIG_MTD_PARTITIONS
+#define CONFIG_MTD_DEVICE
 #define CONFIG_CMD_NAND
 #define CONFIG_CMD_UBI
 #define CONFIG_RBTREE
 #endif
 
-/* TEMPORARY -- no safe place to save env, yet */
-#define CONFIG_ENV_IS_NOWHERE
-#undef CONFIG_CMD_SAVEENV
-
 #ifdef CONFIG_USB_DAVINCI
 #define CONFIG_MUSB_HCD
 #define CONFIG_CMD_USB
@@ -129,9 +127,14 @@
 #define CONFIG_SYS_PROMPT_HUSH_PS2  
 #define CONFIG_SYS_LONGHELP
 
-#define CONFIG_ENV_SIZE(16  10)  /* 16 KiB */
+#ifdef CONFIG_NAND_DAVINCI
+#define CONFIG_ENV_SIZE(256  10) /* 256 KiB */
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_OFFSET  0x3C
+#undef CONFIG_ENV_IS_IN_FLASH
+#endif
 
-/* NYET -- #define CONFIG_BOOTDELAY5 */
+#define CONFIG_BOOTDELAY   5
 #define CONFIG_BOOTCOMMAND \
dhcp;bootm
 #define CONFIG_BOOTARGS \
@@ -146,7 +149,7 @@
 
 /* U-Boot memory configuration */
 #define CONFIG_STACKSIZE   (256  10) /* 256 KiB */
-#define CONFIG_SYS_MALLOC_LEN  (512  10) /* 512 KiB */
+#define CONFIG_SYS_MALLOC_LEN  (1  20)   /* 1 MiB */
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* for initial data */
 #define CONFIG_SYS_MEMTEST_START   0x8700  /* physical address */
 #define CONFIG_SYS_MEMTEST_END 0x8800  /* test 16MB RAM */
-- 
1.6.0.4

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


Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc

2009-09-08 Thread Tom
Dirk Behme wrote:
 Tom wrote:
 Minkyu Kang wrote:
 Dear Dirk,


 snip

 I have lost track of this thread.
 
 Yes, and I'm currently trying to get the track back ;)
 
 When last I worked this, it seemed like the cache routines were going to
 be split.

 1. generic cache routines
 2. legacy soc cache routines.

 Are the generic cache routines in place and can you use them?
 Else can you handle your soc specific cache routines as part of a
 legacy cache routine ?

 The omap cache routines are dependent on omap rom code and fitting
 new routines in using the omap specifics may not be the best way to
 go.
 
 I'm sure this is not the perfect way, but it seems to me that splitting 
 all this stuff into several small steps would be the easier for all. E.g.
 
 1) From the previous discussion I think we should apply
 
 http://lists.denx.de/pipermail/u-boot/2009-August/058492.html
 
 Independent of any discussion if this code is needed at all, if it is 
 generic or not etc. the main advantage I understood is that it frees the 
 way for Samsung.
 
 2a) Then, what I understood from Minkyu, we need an additional patch 
 (discussion?) how to switch CONFIG_L2_OFF from compile time to run time 
 selection (for Samsung's multi board support)
 
 2b) Then, what I understood from Minkyu, we should discuss about removal 
 of get_device_type() function
 
 3) In parallel, we should discuss how to further improve the OMAP3 cache 
 stuff. What might be generic, what not, what isn't necessary etc.
 
 4) Regarding (cache) code duplication, I vote for doing this duplication 
 first. That is, have working Samsung and OMAP3 code applied in parallel. 
 While Jean-Christophe might cry code duplication, I learned from OMAP3 
 boards that is was easier to unify common code _after_ code duplication 
 was done and therefore can be easily identified. Discussing about 
 possible code duplication without being able to see (and test) the code 
 is sometimes a little tricky ;)
 
 As mentioned, doing this in several, small steps I feel more comfortable 
 with. If we would have done step (1) already, it's my feeling that we 
 would have reached step 2 or 3 already. But now, we are still discussing 
 about the 'one big perfect patch'.
 
 Best regards
 
 Dirk
 
 

I am making this workflow up as I go.. but it seems like the
way to resolve this is to work through the new sub-arm repo's

#1 should go to u-boot-ti first and then I will will merge it to u-boot-arm
Then u-boot-samsung can sync to it and we will all be at a good
starting point for #2.
Can #1 go now to u-boot-ti ?
If there is a merge problem, kick it back to the developer ;)

This patch moves the cache support out of A8 and into omap3 which is
the correct place for it.

I assume the samsung changes are going to go first to u-boot-samsung
Correct ?

For 2a) runtime cache enabling / disabling
New feature I don't think omap needs so it should be at some board or
soc level that does not impact omap.

For 2b) get_device_type.  This is an omap-ism that goes away with #1

The means though that samsung needs its own cache routines.
If they are going to do 2a) they will need them anyway.

For 3) I don't think omap needs improving at this point.

For 4) Lets see how much the samsung cache routines look like the
omap once they are done.  If it is a lot of cut-n-paste this is
not worth arguing about a common routine will be easier to manage.
If the cache code looks really different then it can live at the
board or soc layer.  As long as no one claims the cpu layer at the
very least everyone's board will work.


Tom


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


Re: [U-Boot] [PATCH v2] TI DaVinci: DM355: Config Cleanup and Update

2009-09-08 Thread John Rigby
Hi Sandeep,

On Tue, Sep 8, 2009 at 4:14 PM, s-paul...@ti.com wrote:
 From: Sandeep Paulraj s-paul...@ti.com

 This patch does the following
 1) Enables the NAND driver which is now available.

On Sep 1 you said:
I'll send an updated NAND Davinci driver patch soon which adds to what is 
already there. I have made a mistake and testing did not show it.

Did I miss the updated driver?  I have not seen anything on the list.

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


Re: [U-Boot] [PATCH v2] TI DaVinci: DM355: Config Cleanup and Update

2009-09-08 Thread Paulraj, Sandeep
I will send it.
And besides that will be against the u-boot-nand-flash GIT

Thanks,
Sandeep

From: John Rigby [jcri...@gmail.com]
Sent: Tuesday, September 08, 2009 8:07 PM
To: Paulraj, Sandeep
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH v2] TI DaVinci: DM355: Config Cleanup and Update

Hi Sandeep,

On Tue, Sep 8, 2009 at 4:14 PM, s-paul...@ti.com wrote:
 From: Sandeep Paulraj s-paul...@ti.com

 This patch does the following
 1) Enables the NAND driver which is now available.

On Sep 1 you said:
I'll send an updated NAND Davinci driver patch soon which adds to what is 
already there. I have made a mistake and testing did not show it.

Did I miss the updated driver?  I have not seen anything on the list.

Best regards,
John

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


Re: [U-Boot] [PATCH] TI DaVinci: Remove references to SZ_xx

2009-09-08 Thread Jerry Van Baren
Wolfgang Denk wrote:
 Dear Jerry Van Baren,
 
 In message 4aa6c913.7000...@ge.com you wrote:
 I'd just like to add that you also never know if SZ_1M is 1024*1024 or 
 1000*1000.

 I do like this (from the email link): (31 * 1024 * 1024).  And it appears
 not to give Wolfgang indigestion :)
 It is probably the preferred form in many cases, line length
 permitting :-) 31  20 is a bit shorter, but it's just a personal
 s/3// ;-)
 
 No. I intended to state that 31  20 is a bit shorter than
 (31 * 1024 * 1024).
 
 With your substitution, it would also be much less :-)

D'OH!  Indeed.  My thinko, not your typo. :-D  I already have the 
glasses, maybe I need contacts too.  ;-)

 Best regards,
 
 Wolfgang Denk

gvb

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


[U-Boot] Why Cache flush required in some ARM Cortex boards to enable D cache?

2009-09-08 Thread akshay ts
Hi,
I ran into problems when i enabled D cache. But later i found out that cache 
flush was required before enabling D Cache. What i dont understand is why is it 
required?. Since earlier D cache is never enabled and so nothing should be 
present in the cache. 
Flushing is only required during context switch/may be interrupts?. 
I tried with omap3 board with Arm cortex A8 on it, it worked without a cache 
flush. I tried with C110 with Arm cortex A8 on it, i had to do a cache flush to 
make D cache work. 
Also if possible please tell me what is a GP device, OMAP3 (CONTROL_STATUS 
register) seems to be a GP device and hence they are skipping cache flush. I 
dont know what is this.


Warm Regards,
Akshay


  Love Cricket? Check out live scores, photos, video highlights and more. 
Click here http://cricket.yahoo.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2 1/2] mkconfig: split the board make target to multiple config targets

2009-09-08 Thread Mingkai Hu
To simplify the top level makefile it useful to be able to parse
the top level makefile target to multiple individual target, then
put them to the config.h, leave the board config file to handle
the different targets.

Note that this method uses the '_'(underline) as the delimiter when
splits the board make target.

Signed-off-by: Mingkai Hu mingkai...@freescale.com
---

According to the comments from Wolfgang and Scott, I modified
the patch and made some modification over v1:

 - remove the sectence thats puts the splited variables to the
   config.mk, we can use the CONFIG_MK_* in the board config file
   to override the variable in the board config file.

 - change CONFIG_OPT_* to CONFIG_MK_*

 mkconfig |7 +++
 1 files changed, 7 insertions(+), 0 deletions(-)

diff --git a/mkconfig b/mkconfig
index b0bbbd1..4c5675b 100755
--- a/mkconfig
+++ b/mkconfig
@@ -10,12 +10,14 @@
 
 APPEND=no  # Default: Create new config file
 BOARD_NAME=  # Name to print in make output
+TARGETS=
 
 while [ $# -gt 0 ] ; do
case $1 in
--) shift ; break ;;
-a) shift ; APPEND=yes ;;
-n) shift ; BOARD_NAME=${1%%_config} ; shift ;;
+   -t) shift ; TARGETS=`echo $1 | sed 's:_: :g'` ${TARGETS} ; shift ;;
*)  break ;;
esac
 done
@@ -82,6 +84,11 @@ else
 config.h  # Create new config file
 fi
 echo /* Automatically generated - do not edit */ config.h
+
+for i in ${TARGETS} ; do
+   echo #define CONFIG_MK_${i} 1 config.h ;
+done
+
 echo #include configs/$1.h config.h
 echo #include asm/config.h config.h
 
-- 
1.6.4

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


[U-Boot] [PATCH 2/2] mpc8536: simplify the top makefile for 36-bit config

2009-09-08 Thread Mingkai Hu
Signed-off-by: Mingkai Hu mingkai...@freescale.com
---
 Makefile|4 +---
 include/configs/MPC8536DS.h |2 +-
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/Makefile b/Makefile
index dd01b66..9624beb 100644
--- a/Makefile
+++ b/Makefile
@@ -2444,9 +2444,7 @@ ATUM8548_config:  unconfig
 
 MPC8536DS_36BIT_config \
 MPC8536DS_config:   unconfig
-   @mkdir -p $(obj)include
-   @echo #define CONFIG_$(@:_config=) 1  $(obj)include/config.h
-   @$(MKCONFIG) -a MPC8536DS ppc mpc85xx mpc8536ds freescale
+   @$(MKCONFIG) -t $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale
 
 MPC8540ADS_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx mpc8540ads freescale
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 4746e2e..faca805 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -27,7 +27,7 @@
 #ifndef __CONFIG_H
 #define __CONFIG_H
 
-#ifdef CONFIG_MPC8536DS_36BIT
+#ifdef CONFIG_MK_36BIT
 #define CONFIG_PHYS_64BIT  1
 #endif
 
-- 
1.6.4

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


Re: [U-Boot] [PATCH] arm_cortexa8: support cache flush to other soc

2009-09-08 Thread Minkyu Kang
Tom wrote:
 Dirk Behme wrote:
 Tom wrote:
 Minkyu Kang wrote:
 Dear Dirk,


 snip

 I have lost track of this thread.

 Yes, and I'm currently trying to get the track back ;)

 When last I worked this, it seemed like the cache routines were going to
 be split.

 1. generic cache routines
 2. legacy soc cache routines.

 Are the generic cache routines in place and can you use them?
 Else can you handle your soc specific cache routines as part of a
 legacy cache routine ?

 The omap cache routines are dependent on omap rom code and fitting
 new routines in using the omap specifics may not be the best way to
 go.

 I'm sure this is not the perfect way, but it seems to me that
 splitting all this stuff into several small steps would be the easier
 for all. E.g.

 1) From the previous discussion I think we should apply

 http://lists.denx.de/pipermail/u-boot/2009-August/058492.html

 Independent of any discussion if this code is needed at all, if it is
 generic or not etc. the main advantage I understood is that it frees
 the way for Samsung.

 2a) Then, what I understood from Minkyu, we need an additional patch
 (discussion?) how to switch CONFIG_L2_OFF from compile time to run
 time selection (for Samsung's multi board support)

 2b) Then, what I understood from Minkyu, we should discuss about
 removal of get_device_type() function

 3) In parallel, we should discuss how to further improve the OMAP3
 cache stuff. What might be generic, what not, what isn't necessary etc.

 4) Regarding (cache) code duplication, I vote for doing this
 duplication first. That is, have working Samsung and OMAP3 code
 applied in parallel. While Jean-Christophe might cry code
 duplication, I learned from OMAP3 boards that is was easier to unify
 common code _after_ code duplication was done and therefore can be
 easily identified. Discussing about possible code duplication without
 being able to see (and test) the code is sometimes a little tricky ;)

 As mentioned, doing this in several, small steps I feel more
 comfortable with. If we would have done step (1) already, it's my
 feeling that we would have reached step 2 or 3 already. But now, we
 are still discussing about the 'one big perfect patch'.

 Best regards

 Dirk


 
 I am making this workflow up as I go.. but it seems like the
 way to resolve this is to work through the new sub-arm repo's
 
 #1 should go to u-boot-ti first and then I will will merge it to u-boot-arm
 Then u-boot-samsung can sync to it and we will all be at a good
 starting point for #2.
 Can #1 go now to u-boot-ti ?
 If there is a merge problem, kick it back to the developer ;)
 
 This patch moves the cache support out of A8 and into omap3 which is
 the correct place for it.
 
 I assume the samsung changes are going to go first to u-boot-samsung
 Correct ?
 
 For 2a) runtime cache enabling / disabling
 New feature I don't think omap needs so it should be at some board or
 soc level that does not impact omap.
 
 For 2b) get_device_type.  This is an omap-ism that goes away with #1
 
 The means though that samsung needs its own cache routines.
 If they are going to do 2a) they will need them anyway.
 
 For 3) I don't think omap needs improving at this point.
 
 For 4) Lets see how much the samsung cache routines look like the
 omap once they are done.  If it is a lot of cut-n-paste this is
 not worth arguing about a common routine will be easier to manage.
 If the cache code looks really different then it can live at the
 board or soc layer.  As long as no one claims the cpu layer at the
 very least everyone's board will work.
 
 
 Tom
 

Although I did not understand all of the cache routine..
the s5pc100 soc doesn't need v7_flush_dcache_all function
and other cache routines.
But the s5pc110 soc needs this function,
and it works fine without modification. (please see my patch)

I think.. v7_flush_decache_all function can share together.

If this function is not moved to soc layer,
need to remove omap specific codes (checking device type)

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


[U-Boot] [PATCH] net: kirkwood_egiga.c: fixed build warning

2009-09-08 Thread Prafulla Wadaskar
if link up detection code is disabled through config option, it gives build 
warning.
This patch fixes the same

Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
 cpu/arm926ejs/config.mk  |2 +-
 drivers/net/kirkwood_egiga.c |4 +++-
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/cpu/arm926ejs/config.mk b/cpu/arm926ejs/config.mk
index f8ef90f..c154efe 100644
--- a/cpu/arm926ejs/config.mk
+++ b/cpu/arm926ejs/config.mk
@@ -23,7 +23,7 @@
 
 PLATFORM_RELFLAGS += -fno-common -ffixed-r8 -msoft-float
 
-PLATFORM_CPPFLAGS += -march=armv5te
+PLATFORM_CPPFLAGS += -march=armv5t
 # =
 #
 # Supply options according to compiler version
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 479035d..07a86cd 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -400,8 +400,10 @@ static int kwgbe_init(struct eth_device *dev)
 {
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe-regs;
+#if (defined (CONFIG_MII) || defined (CONFIG_CMD_MII)) \
+ defined (CONFIG_SYS_FAULT_ECHO_LINK_DOWN)
int i;
-
+#endif
/* setup RX rings */
kwgbe_init_rx_desc_ring(dkwgbe);
 
-- 
1.5.3.3

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


[U-Boot] [PATCH v2] net: kirkwood_egiga.c: fixed build warning

2009-09-08 Thread Prafulla Wadaskar
if link up detection code is disabled through config option, it gives build 
warning.
This patch fixes the same

Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Changelog:
v2: unwanted commit in v1 patch removed

 drivers/net/kirkwood_egiga.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 479035d..07a86cd 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -400,8 +400,10 @@ static int kwgbe_init(struct eth_device *dev)
 {
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe-regs;
+#if (defined (CONFIG_MII) || defined (CONFIG_CMD_MII)) \
+ defined (CONFIG_SYS_FAULT_ECHO_LINK_DOWN)
int i;
-
+#endif
/* setup RX rings */
kwgbe_init_rx_desc_ring(dkwgbe);
 
-- 
1.5.3.3

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


Re: [U-Boot] [PATCH][v1] muas3001: remove BRG clock node fixup to use common mpc8260 code.

2009-09-08 Thread Heiko Schocher
Hello Marcel,

Marcel Ziswiler wrote:
 Signed-off-by: Marcel Ziswiler marcel.ziswi...@noser.com
 ---
  board/muas3001/muas3001.c |   16 
  1 files changed, 0 insertions(+), 16 deletions(-)

Unfortunately, I don;t have anymore access to this board, but your
patch looks good to me, so:

Acked-by: Heiko Schocher h...@denx.de

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