Re: [U-Boot] [PATCH] Marvell GuruPlug Board Support

2010-03-18 Thread Siddarth Gore
On Mon, 2010-03-15 at 09:08 -0700, Wolfgang Denk wrote:
> ...
> > --- /dev/null
> > +++ b/board/Marvell/guruplug/guruplug.h
> > @@ -0,0 +1,39 @@
> 
> > +#define GURUPLUG_OE_LOW  (~(0))
> > +#define GURUPLUG_OE_HIGH (~(0))
> 
> Is this correct? Both LOW and HIGH use the same value??
> 
Sorry. forget to respond to this one.

Yes this is correct. LOW and HIGH does not represent logic levels here.
The registers which control GPIO pins 0 though 31 are suffixed LOW and
those which control the rest are suffixed HIGH.

-siddarth

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


[U-Boot] [PATCH v2] Marvell GuruPlug Board Support

2010-03-18 Thread Siddarth Gore
GuruPlug Standard: 1 Gb Ethernet, 2 USB 2.0
GuruPlug Plus: 2 Gb Ethernet, 2 USB 2.0, 1 eSATA, 1 uSD slot

References:
http://www.globalscaletechnologies.com/t-guruplugdetails.aspx
http://plugcomputer.org

This patch is for GuruPlug Plus, but it supports Standard version
as well.

Signed-off-by: Siddarth Gore 
---
Changes compared to the previous version (messaage-id:
1268660568-23022-1-git-send-email-go...@marvell.com)
- maintainers entry sorted according to last name
- removed trailing comment from board/Marvell/guruplug/config.mk
- removed CONFIG_CMD_AUTOSCRIPT from include/configs/guruplug.h
- removed word 'minimal' from comment in include/configs/guruplug.h

 MAINTAINERS |4 +
 MAKEALL |1 +
 Makefile|3 +
 board/Marvell/guruplug/Makefile |   51 +
 board/Marvell/guruplug/config.mk|   27 +
 board/Marvell/guruplug/guruplug.c   |  167 +
 board/Marvell/guruplug/guruplug.h   |   39 +++
 board/Marvell/guruplug/kwbimage.cfg |  162 
 include/configs/guruplug.h  |  198 +++
 9 files changed, 652 insertions(+), 0 deletions(-)
 create mode 100644 board/Marvell/guruplug/Makefile
 create mode 100644 board/Marvell/guruplug/config.mk
 create mode 100644 board/Marvell/guruplug/guruplug.c
 create mode 100644 board/Marvell/guruplug/guruplug.h
 create mode 100644 board/Marvell/guruplug/kwbimage.cfg
 create mode 100644 include/configs/guruplug.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 80057ce..ed0731d 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -195,6 +195,10 @@ Niklaus Giger 
MCU25   PPC405GPr
HCU5PPC440EPx
 
+Siddarth Gore 
+
+   guruplugARM926EJS (Kirkwood SoC)
+
 Frank Gottschling 
 
MHPCMPC8xx
diff --git a/MAKEALL b/MAKEALL
index beacb5f..b15c2d1 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -562,6 +562,7 @@ LIST_ARM9=" \
edb9312 \
edb9315 \
edb9315a\
+   guruplug\
imx27lite   \
lpd7a400\
mv88f6281gtw_ge \
diff --git a/Makefile b/Makefile
index d801e25..30d5968 100644
--- a/Makefile
+++ b/Makefile
@@ -2952,6 +2952,9 @@ davinci_dm365evm_config : unconfig
 davinci_dm6467evm_config : unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs dm6467evm davinci davinci
 
+guruplug_config: unconfig
+   @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) Marvell kirkwood
+
 imx27lite_config:  unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs imx27lite logicpd mx27
 
diff --git a/board/Marvell/guruplug/Makefile b/board/Marvell/guruplug/Makefile
new file mode 100644
index 000..99748a7
--- /dev/null
+++ b/board/Marvell/guruplug/Makefile
@@ -0,0 +1,51 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Siddarth Gore 
+#
+# 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., 51 Franklin Street, Fifth Floor, Boston,
+# MA 02110-1301 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS  := guruplug.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 .depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/Marvell/guruplug/config.mk b/board/Marvell/guruplug/config.mk
new file mode 100644
index 000..caa26b6
--- /dev/null
+++ b/board/Marvell/guruplug/config.mk
@@ -0,0 +1,27 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Siddarth Gore 
+#
+# 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 Sof

Re: [U-Boot] Hi guys, maybe this is not the best list but I ask about my problem

2010-03-18 Thread Wolfgang Denk
Dear Fabio Giovagnini,

you are indeed completely off topic here on the U-Boot list.

In message <201003180657.27345.fabio.giovagn...@aurion-tech.com> you wrote:
>
> Im able to mount the nfsroot filesystem but I get this message:
...
> Warning: unable to open an initial console.
^

> In rootpath I should read someting?

You should read the error messages and contemplate their meaning.

> Could the problem be my PC is little endian and I' exporting to a big endian 
> CPU?

No.

"unable to open an initial console" usually means that there is no
"/dev/console" entry in your root file system, so check your root file
system if it is complete.

[If you were using the ELDK, my bet was that you have forgotten to run
the ELDK_MAKEDEV (plus eventually the ELDK_FIXOWNER) script(s), but
you don't include such vital information as where this root file
system is coming from and why you think it should be a working one.]

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
Quantum particles: The dreams that stuff is made of.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATH] at91: add hwecc method for nand

2010-03-18 Thread Nikolay Petukhov
Hi, all.

This is a patch to use the hardware ECC controller of
the AT91SAM9260 for the AT91 nand. Taken from the kernel 2.6.33.

To use this it is necessary to add two definitions in config:
CONFIG_ATMEL_NAND_HWECC
CONFIG_SYS_NAND_ECC_BASE (AT91_ECC for the AT91SAM9260 and AT91_ECC0
for the AT91SAM9263 boards)

It has been tested only on AT91SAM9260-EK.
u-boot version : 2009.11
kernel version : 2.6.27(32)

Results of read bandwidth:
u-boot with SWECC: 1MB/s
u-boot with HWECC: 3MB/s
linux with HWECC: 6MB/s

Signed-off-by: Nikolay Petukhov 

diff -uprN u-boot-2009.11/drivers/mtd/nand/atmel_nand.c
u-boot-2009.11-at91-nand-hwecc/drivers/mtd/nand/atmel_nand.c
--- u-boot-2009.11/drivers/mtd/nand/atmel_nand.c2009-12-16
03:20:54.0 +0500
+++ u-boot-2009.11-at91-nand-hwecc/drivers/mtd/nand/atmel_nand.c
2010-03-18
11:15:01.0 +0500
@@ -31,6 +31,210 @@

 #include 

+#ifdef CONFIG_ATMEL_NAND_HWECC
+
+/* Register access macros */
+#define ecc_readl(add, reg)\
+   readl(AT91_BASE_SYS + add + ATMEL_ECC_##reg)
+#define ecc_writel(add, reg, value)\
+   writel((value), AT91_BASE_SYS + add + ATMEL_ECC_##reg)
+
+#include "atmel_nand_ecc.h"/* Hardware ECC registers */
+
+/* oob layout for large page size
+ * bad block info is on bytes 0 and 1
+ * the bytes have to be consecutives to avoid
+ * several NAND_CMD_RNDOUT during read
+ */
+static struct nand_ecclayout atmel_oobinfo_large = {
+   .eccbytes = 4,
+   .eccpos = {60, 61, 62, 63},
+   .oobfree = {
+   {2, 58}
+   },
+};
+
+/* oob layout for small page size
+ * bad block info is on bytes 4 and 5
+ * the bytes have to be consecutives to avoid
+ * several NAND_CMD_RNDOUT during read
+ */
+static struct nand_ecclayout atmel_oobinfo_small = {
+   .eccbytes = 4,
+   .eccpos = {0, 1, 2, 3},
+   .oobfree = {
+   {6, 10}
+   },
+};
+
+/*
+ * Calculate HW ECC
+ *
+ * function called after a write
+ *
+ * mtd:MTD block structure
+ * dat:raw data (unused)
+ * ecc_code:   buffer for ECC
+ */
+static int atmel_nand_calculate(struct mtd_info *mtd,
+   const u_char *dat, unsigned char *ecc_code)
+{
+   struct nand_chip *nand_chip = mtd->priv;
+   unsigned int ecc_value;
+
+   /* get the first 2 ECC bytes */
+   ecc_value = ecc_readl(CONFIG_SYS_NAND_ECC_BASE, PR);
+
+   ecc_code[0] = ecc_value & 0xFF;
+   ecc_code[1] = (ecc_value >> 8) & 0xFF;
+
+   /* get the last 2 ECC bytes */
+   ecc_value = ecc_readl(CONFIG_SYS_NAND_ECC_BASE, NPR) & 
ATMEL_ECC_NPARITY;
+
+   ecc_code[2] = ecc_value & 0xFF;
+   ecc_code[3] = (ecc_value >> 8) & 0xFF;
+
+   return 0;
+}
+
+/*
+ * HW ECC read page function
+ *
+ * mtd:mtd info structure
+ * chip:   nand chip info structure
+ * buf:buffer to store read data
+ */
+static int atmel_nand_read_page(struct mtd_info *mtd,
+   struct nand_chip *chip, uint8_t *buf, int page)
+{
+   int eccsize = chip->ecc.size;
+   int eccbytes = chip->ecc.bytes;
+   uint32_t *eccpos = chip->ecc.layout->eccpos;
+   uint8_t *p = buf;
+   uint8_t *oob = chip->oob_poi;
+   uint8_t *ecc_pos;
+   int stat;
+
+   /* read the page */
+   chip->read_buf(mtd, p, eccsize);
+
+   /* move to ECC position if needed */
+   if (eccpos[0] != 0) {
+   /* This only works on large pages
+* because the ECC controller waits for
+* NAND_CMD_RNDOUTSTART after the
+* NAND_CMD_RNDOUT.
+* anyway, for small pages, the eccpos[0] == 0
+*/
+   chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
+   mtd->writesize + eccpos[0], -1);
+   }
+
+   /* the ECC controller needs to read the ECC just after the data */
+   ecc_pos = oob + eccpos[0];
+   chip->read_buf(mtd, ecc_pos, eccbytes);
+
+   /* check if there's an error */
+   stat = chip->ecc.correct(mtd, p, oob, NULL);
+
+   if (stat < 0)
+   mtd->ecc_stats.failed++;
+   else
+   mtd->ecc_stats.corrected += stat;
+
+   /* get back to oob start (end of page) */
+   chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);
+
+   /* read the oob */
+   chip->read_buf(mtd, oob, mtd->oobsize);
+
+   return 0;
+}
+
+/*
+ * HW ECC Correction
+ *
+ * function called after a read
+ *
+ * mtd:MTD block structure
+ * dat:raw data read from the chip
+ * read_ecc:   ECC from the chip (unused)
+ * isnull: unused
+ *
+ * Detect and correct a 1 bit error for a page
+ */
+static int atmel_nand_correct(struct mtd_info *mtd, u_char *dat,
+   u_char *read_ecc, u_char *isnull)
+{
+   struct nand_chip *nand_chip = mtd->priv;
+   //struct atmel_nand_host *host = nand_chip->priv;
+   unsigned int ecc_status, ecc_parity, ecc_mode;
+   unsigned int ecc_word, ecc_

Re: [U-Boot] [PATCH] Marvell GuruPlug Board Support

2010-03-18 Thread Prafulla Wadaskar
 

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Siddarth Gore
> Sent: Thursday, March 18, 2010 10:59 AM
> To: Wolfgang Denk
> Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATCH] Marvell GuruPlug Board Support
...snip...
> > 
> > We have pretty much identical code already in mv_phy_88e1116_init()
> > [in "board/Marvell/rd6281a/rd6281a.c"], in reset_phy() [in
> > "board/Marvell/openrd_base/openrd_base.c"], in reset_phy(0 [in
> > "board/Marvell/sheevaplug/sheevaplug.c"] and I don't know 
> where else.
> > 
> > I object against adding more and more copies of the same 
> code. Please
> > factor out the common part into a single implementation, 
> and call this
> > everwhere where such code is used.  Thanks.
> > 
> i can create a new file ethphy.c in board/Marvell/common and put this
> code there. but if we are going to move to a phy driver (as Prafulla
> suggested) then that wont be necessary. Please advise.
> 
> Also i think we should maintain different init functions for 1116 and
> 1121 as they represent different phy families, even though the code is
> pretty much the same right now.

Hi Siddarth

I think you keep this part as it is as of now,
Once Ben suggest something, I will post the cleanup patch

Regards..
Prafulla ..

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


Re: [U-Boot] [PATCH v2] Marvell GuruPlug Board Support

2010-03-18 Thread Prafulla Wadaskar
> -Original Message-
> From: Siddarth Gore [mailto:go...@marvell.com] 
> Sent: Thursday, March 18, 2010 1:12 PM
> To: u-boot@lists.denx.de
> Cc: Prafulla Wadaskar; Prabhanjan Sarnaik; Ashish Karkare; 
> Siddarth Gore
> Subject: [PATCH v2] Marvell GuruPlug Board Support
> 
> GuruPlug Standard: 1 Gb Ethernet, 2 USB 2.0
> GuruPlug Plus: 2 Gb Ethernet, 2 USB 2.0, 1 eSATA, 1 uSD slot
> 
> References:
> http://www.globalscaletechnologies.com/t-guruplugdetails.aspx
> http://plugcomputer.org
> 
> This patch is for GuruPlug Plus, but it supports Standard version
> as well.
> 
> Signed-off-by: Siddarth Gore 
> ---
> Changes compared to the previous version (messaage-id:
> 1268660568-23022-1-git-send-email-go...@marvell.com)
> - maintainers entry sorted according to last name
> - removed trailing comment from board/Marvell/guruplug/config.mk
> - removed CONFIG_CMD_AUTOSCRIPT from include/configs/guruplug.h
> - removed word 'minimal' from comment in include/configs/guruplug.h
> 
>  MAINTAINERS |4 +
>  MAKEALL |1 +
>  Makefile|3 +
>  board/Marvell/guruplug/Makefile |   51 +
>  board/Marvell/guruplug/config.mk|   27 +
>  board/Marvell/guruplug/guruplug.c   |  167 
> +
>  board/Marvell/guruplug/guruplug.h   |   39 +++
>  board/Marvell/guruplug/kwbimage.cfg |  162 
> 
>  include/configs/guruplug.h  |  198 
> +++
>  9 files changed, 652 insertions(+), 0 deletions(-)
>  create mode 100644 board/Marvell/guruplug/Makefile
>  create mode 100644 board/Marvell/guruplug/config.mk
>  create mode 100644 board/Marvell/guruplug/guruplug.c
>  create mode 100644 board/Marvell/guruplug/guruplug.h
>  create mode 100644 board/Marvell/guruplug/kwbimage.cfg
>  create mode 100644 include/configs/guruplug.h
> 

Looks okay to me

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


Re: [U-Boot] [PATCH] Marvell GuruPlug Board Support

2010-03-18 Thread Wolfgang Denk
Dear Siddarth Gore,

In message <1268890125.23313.27.ca...@pe-dt434> you wrote:
>
...
> > We have pretty much identical code already in mv_phy_88e1116_init()
> > [in "board/Marvell/rd6281a/rd6281a.c"], in reset_phy() [in
> > "board/Marvell/openrd_base/openrd_base.c"], in reset_phy(0 [in
> > "board/Marvell/sheevaplug/sheevaplug.c"] and I don't know where else.
> > 
> > I object against adding more and more copies of the same code. Please
> > factor out the common part into a single implementation, and call this
> > everwhere where such code is used.  Thanks.
> > 
> i can create a new file ethphy.c in board/Marvell/common and put this
> code there. but if we are going to move to a phy driver (as Prafulla
> suggested) then that wont be necessary. Please advise.

Is there any actual development for a generic PHY support layer going
on anywhere? I must have missed this, then.  If there is such a thing,
it should be used, obviously.

> Also i think we should maintain different init functions for 1116 and
> 1121 as they represent different phy families, even though the code is
> pretty much the same right now.

If the code is the same, then duplication makes no sense to me.

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
Space is big. You just won't believe how vastly, hugely, mind-
bogglingly big it is. I mean, you may think it's a long way down the
road to the drug store, but that's just peanuts to space.
  -- The Hitchhiker's Guide to the Galaxy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] u-boot stack overwrites end ramdisk

2010-03-18 Thread Norbert van Bolhuis

I was not totally correct.
gunzip/inflate has nothing to do with this problem.

the problem is this:

- do_bootm->bootm_start->arch_lmb_reserve
   reserves "unused" memory as in cur_sp-1k upto end-of-mem
   in my case this is 0x0fb0cb28 - 0x1000

- do_bootm->do_bootm_linux->boot_body_linux->boot_ramdisk_high
   places ramdisk as close to (and below) the "unused" memory
   reservation (0x1000 aligned)
   in my case ramdisk is copied to 0x0f8c - 0x0fb0ca24

- the end of the ramdisk is overwritten while printing
   "Loading Device Tree to 00ffa000, end 00fff593 ... OK"
   this happens from:
   do_bootm->do_bootm_linux->boot_relocate_fdt->printf->vsprintf->number

bootm_start and arch_lmb_reserve together use 40 + 32 = 72 bytes stack.
The assumption that u-boots' stack usage will not exceed
arch_lmb_reserve stack pointer - 1k is simply incorrect.
The "do_bootm_linux->boot_relocate_fdt->printf->vsprintf->number"
call chain (called from that same do_bootm) uses
56 + 40 + 1112 + 56 + 104 = 1368 bytes

This problem will only occur with CONFIG_OF_LIBFDT #defined
and it depends on how the 0x1000 alignment of the ramdisk image
turns out.

Btw. It looks like latest u-boot also has this problem.

I'll send a patch later making it 4k.

I do wonder why it was set so tight in the first place.

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


Re: [U-Boot] soft_spi.c crash while saveenv

2010-03-18 Thread Detlev Zundel
Hello Horst,

> I used the soft_spi - driver for saving the u-boot-environment.
>
> When I started "saveenv" u-boot hang - no output.
> I located the problem in soft_spi.c in function "spi_xfer()".
> This function writes every byte received from the spi-device to the
> pointer "dout".
> In case of writing to the spi-device the returned bytes are also
> written to the dout-pointer.
>
> The function "spi_flash_cmd()" in "drivers/mtd/spi/spi_flash.c" calls
> now this function with
> a NULL-pointer.

Ok, I see that the mtd does a call with NULL pointers, so your fix
actually works for your combination.

On the other hand, this check of parameters is not consistent in the
other drivers.  drivers/spi/mpc8xxx_spi.c does no checks, while
drivers/spi/bfin_spi.c does - I did not bother to check others.

As I'm a friend of passive programming, I would go down your route but
eventually fix all other drivers too.

So can you please cook up a proper patch with a signed-off-by line as
stated in the docs[1]?

Thanks
  Detlev

[1] http://www.denx.de/wiki/U-Boot/Patches

-- 
Die eine Haelfte der Welt lacht ueber die andere, und Narren sind alle.
--- Baltasar Gracian
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] uboot on microblaze, compilation error

2010-03-18 Thread Michal Simek
Mike Frysinger wrote:
> On Wednesday 17 March 2010 14:36:38 Horst Gall wrote:
>> Hi,
>>
>> I try to compile an actual version of u-boot for xilinx microblaze.
>> The linker ends with the error-message:
>>
>> ... mb-ld.real:u-boot.lds:1: parse error
>>
>> In u-boot main-directory I found the file 'u-boot.lds':
>>
>> OUTPUT_ARCH(1)
>> ENTRY(_start)
>> ...
>> cpu/1/start.o (.text)
>> ...
>>
>> When I change the "1" to "microblaze" it works:
>>
>> OUTPUT_ARCH(microblaze)
>> ENTRY(_start)
>> ...
>> cpu/microblaze/start.o (.text)
>> ...
>>
>>
>> After "make ...config" my modification is overwritten.
>> How can I fix this problem?
> 
> add "#undef microblaze" to the top of board/xilinx/microblaze-generic/u-
> boot.lds

Mike is right. I expect you are using toolchain from EDK where the 
problem is. Linux toolchain are ok.

Michal

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


-- 
Michal Simek, Ing. (M.Eng)
w: www.monstr.eu p: +42-0-721842854
Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/
Microblaze U-BOOT custodian
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Environmentvar. "ipaddr" - microblaze

2010-03-18 Thread Detlev Zundel
Hi Horst,

> in "lib_microblaze/board.c  board_init()" the function "env_relocate()" 
> should be called before "getenv_IPaddr()"
> otherwise there is no chance to save an ip-address in the environment (like 
> in lib_ppc/board.c).

You should check this issues with the microblaze custodian listed on the
web page[1].  Actually I put Michal on CC on this mail already.

Thanks
  Detlev

[1] http://www.denx.de/wiki/U-Boot/Custodians

-- 
"One of my most productive days was throwing away 1000 lines of code."
  - Ken Thompson.
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] serial init

2010-03-18 Thread Valentin Ecker
Hi!

I have some problems with understanding the serial initialization.  
Maybe someone can help me out here...

In my case I want to use a second serial console on a DM365 davinci  
dvevm which is provided on an external chip through EMIF. The use case  
would be then to switch from the internal SoC serial (ns16550) to the  
second external console and back during runtime.

So here is my question:

While board initialization, serial_init() gets called, which calls the  
driver specific (hardware, etc...) init stuff. The default is that the  
default serial (in my case the SoC ns16550 ) will be initialized. So  
my extra serial port stays uninitialized because it's not default.

When i switch stdout/stdin/stderr to the second serial port during  
runtime, serial_assign() gets called, but without calling serial_init 
() of the second serial port first.

This confuses me, or am I misunderstanding the architecture / how  
serial interfaces work in uboot?


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


[U-Boot] [PATCH v2] [ARM] at91: Add support for taskit AT91SAM9G20 boards

2010-03-18 Thread Achim Ehrlich
This adds support for the AT91SAM9G20 boards by taskit GmbH.
Both boards, Stamp9G20 and PortuxG20, are integrated in one file.
PortuxG20 is basically a SBC built around Stamp9G20.

Signed-off-by: Achim Ehrlich 
---
 MAINTAINERS|5 +
 MAKEALL|1 +
 Makefile   |4 +
 board/taskit/stamp9G20/Makefile|   50 +
 board/taskit/stamp9G20/config.mk   |1 +
 board/taskit/stamp9G20/stamp9G20.c |  203 
 include/configs/stamp9G20.h|  180 
 7 files changed, 444 insertions(+), 0 deletions(-)
 create mode 100644 board/taskit/stamp9G20/Makefile
 create mode 100644 board/taskit/stamp9G20/config.mk
 create mode 100644 board/taskit/stamp9G20/stamp9G20.c
 create mode 100644 include/configs/stamp9G20.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 7f40ebd..c4259a0 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -138,6 +138,11 @@ Jon Diekema 
 
sbc8260 MPC8260
 
+Achim Ehrlich 
+
+   Stamp9G20   AT91SAM9G20
+   PortuxG20   AT91SAM9G20
+
 Dirk Eibach 
 
devconcenterPPC460EX
diff --git a/MAKEALL b/MAKEALL
index 1949985..516 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -675,6 +675,7 @@ LIST_at91=" \
pm9261  \
pm9263  \
SBC35_A9G20 \
+   stamp9G20   \
TNY_A9260   \
TNY_A9G20   \
 "
diff --git a/Makefile b/Makefile
index ce77e10..ed9ae00 100644
--- a/Makefile
+++ b/Makefile
@@ -2903,6 +2903,10 @@ TNY_A9260_config :   unconfig
@echo "#define CONFIG_$(@:_config=) 1" >$(obj)include/config.h
@$(MKCONFIG) -a tny_a9260 arm arm926ejs tny_a9260 calao at91
 
+portuxG20_config \
+stamp9G20_config   :   unconfig
+   @$(MKCONFIG) -t $(@:_config=) stamp9G20 arm arm926ejs stamp9G20 taskit 
at91
+
 
 ## ARM Integrator boards - see doc/README-integrator for more info.
 integratorap_config\
diff --git a/board/taskit/stamp9G20/Makefile b/board/taskit/stamp9G20/Makefile
new file mode 100644
index 000..191fb8e
--- /dev/null
+++ b/board/taskit/stamp9G20/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2010
+# Achim Ehrlich, taskit GmbH, aehrl...@taskit.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y+= stamp9G20.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+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
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/taskit/stamp9G20/config.mk b/board/taskit/stamp9G20/config.mk
new file mode 100644
index 000..ff2cfd1
--- /dev/null
+++ b/board/taskit/stamp9G20/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x23f0
diff --git a/board/taskit/stamp9G20/stamp9G20.c 
b/board/taskit/stamp9G20/stamp9G20.c
new file mode 100644
index 000..b543b0a
--- /dev/null
+++ b/board/taskit/stamp9G20/stamp9G20.c
@@ -0,0 +1,203 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop 
+ * Lead Tech Design 
+ *
+ * (C) Copyright 2010
+ * Achim Ehrlich 
+ * taskit GmbH 
+ *
+ * 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 Licens

Re: [U-Boot] serial init

2010-03-18 Thread Michael Zaidman
On Thu, Mar 18, 2010 at 12:33 PM, Valentin Ecker
 wrote:
...
> While board initialization, serial_init() gets called, which calls the
> driver specific (hardware, etc...) init stuff. The default is that the
> default serial (in my case the SoC ns16550 ) will be initialized. So
> my extra serial port stays uninitialized because it's not default.
Did you add the CONFIG_SYS_NS16550_COM2 in your board
configuration file?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH] correct a syntax typo in at91_matrix.h

2010-03-18 Thread Asen Dimov

Signed-off-by: Asen Dimov 
---
 include/asm-arm/arch-at91/at91_matrix.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/asm-arm/arch-at91/at91_matrix.h 
b/include/asm-arm/arch-at91/at91_matrix.h
index 9b3c110..981ec20 100644
--- a/include/asm-arm/arch-at91/at91_matrix.h
+++ b/include/asm-arm/arch-at91/at91_matrix.h
@@ -80,7 +80,7 @@ typedef struct at91_matrix {
u32 mrcr;   /* 0x100 Master Remap Control */
u32 reserve4[3];
 #ifdefined(CONFIG_AT91SAM9G45)
-   u32 ccr[52] /* 0x110 - 0x1E0 Chip Configuration */
+   u32 ccr[52];/* 0x110 - 0x1E0 Chip Configuration */
u32 womr;   /* 0x1E4 Write Protect Mode  */
u32 wpsr;   /* 0x1E8 Write Protect Status */
u32 resg45_1[10];
-- 
1.5.5.6

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


[U-Boot] [PATCH] using AT91_PMC_MCKR_MDIV_ instead of LEGACY one in at91/clock.c

2010-03-18 Thread Asen Dimov

Signed-off-by: Asen Dimov 
---
 cpu/arm926ejs/at91/clock.c |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/cpu/arm926ejs/at91/clock.c b/cpu/arm926ejs/at91/clock.c
index b06d760..ecf91f5 100644
--- a/cpu/arm926ejs/at91/clock.c
+++ b/cpu/arm926ejs/at91/clock.c
@@ -203,7 +203,8 @@ int at91_clock_init(unsigned long main_clock)
if (mckr & AT91_PMC_MCKR_MDIV_MASK)
freq /= 2;  /* processor clock division */
 #elif defined(CONFIG_AT91SAM9G45) || defined(CONFIG_AT91SAM9M10G45)
-   mck_rate_hz = (mckr & AT91_PMC_MCKR_MDIV_MASK) == AT91SAM9_PMC_MDIV_3
+   mck_rate_hz = (mckr & AT91_PMC_MCKR_MDIV_MASK) ==
+   (AT91_PMC_MCKR_MDIV_2 | AT91_PMC_MCKR_MDIV_4)
? freq / 3
: freq / (1 << ((mckr & AT91_PMC_MCKR_MDIV_MASK) >> 8));
 #else
-- 
1.5.5.6

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


Re: [U-Boot] serial init

2010-03-18 Thread Valentin Ecker
well, i don't want to use the second com port of the ns16550. Im using  
an external serial chip over EMIF.
so -> no, i don't, wouldn't make any sense to me...

thx for the help


On 18.03.2010, at 12:31, Michael Zaidman wrote:

> On Thu, Mar 18, 2010 at 12:33 PM, Valentin Ecker
>  wrote:
> ...
>> While board initialization, serial_init() gets called, which calls  
>> the
>> driver specific (hardware, etc...) init stuff. The default is that  
>> the
>> default serial (in my case the SoC ns16550 ) will be initialized. So
>> my extra serial port stays uninitialized because it's not default.
> Did you add the CONFIG_SYS_NS16550_COM2 in your board
> configuration file?

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


Re: [U-Boot] serial init

2010-03-18 Thread Michael Zaidman
On Thu, Mar 18, 2010 at 2:21 PM, Valentin Ecker
 wrote:
> well, i don't want to use the second com port of the ns16550. Im using an
> external serial chip over EMIF.

I am not familiar with Davinci architecture and probably my case is
completely different from yours but on our board we have dual uart on
mpc8349 chip + external quad uart ns16554 chip connected via local
bus. The current u-boot code supports up to 4  ns16550 devices, i.e.
from COM1 to COM4. So I extended the serial_ports array to 6 entries
and in this way got ability to communicate via COM5 and COM6.

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


[U-Boot] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?

2010-03-18 Thread Brian Hutchinson
(puts on flame retardant underwear) Can environment variables be
pulled from Flash and EEPROM?

Why would I want to do this?  I need to provide fail safe upgrade path
and need to do something similar to the bootcount feature in PPC (I'm
using ARM though).

I have a internal SRAM that I can use for the bootcount feature (no
registers survive reset so SRAM is next best option) but I want to be
able to select Kernel B or Kernel A.  Let me explain more.  Right now
the bootcount feature boots a primary kernel and if it fails it tries
a secondary kernel.  So in my case the bootcount feature would
translate to Kernel A always tried first, then B and we want to be
able to say boot B first, then A on failure (make the choice
configurable based on upgrades etc).

The goal is to not brick a device during a upgrade.  Whatever bank you
are running out of, you upgrade by flashing the bank not being used.
Once a bank has been upgraded, if I want to select that bank to boot
... I would need to modify a environment variable but if it is stored
in flash then while that sector (a 256k sector in my case) is being
updated ... if power is lost I just hosed myself.  If the environment
variable I update was stored in EEPROM, then it would be closer to an
atomic action that couldn't be interrupted with say a power failure.

So what I'm asking about is a Hybrid environment were some variables
are in flash and some are in EEPROM.  The env is read from both
locations and saveenv writes some vars in flash and some in EEPROM.
With the current u-boot code I have (1.1.6) the environment choices
are mutually exclusive (flash, eeprom, nvram etc.)

Is this a sane approach or am I heading for heart ache?  This has to
be something that others have dealt with but I didn't see any similar
discussions in the archives.

Regards,

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


Re: [U-Boot] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?

2010-03-18 Thread Brian Hutchinson
... oops, one glaring thing I didn't think about in the approach I
presented was the I2C transaction.  If power is lost during that
transaction I have a similar problem to a loss of power during a
saveenv and the flash sector being erased and re written.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] Hi guys, maybe this is not the best list but I ask about my problem

2010-03-18 Thread Fabio Giovagnini
Thanks alot.
The very first problem was a permission problem, as you suggestied to ckech.
But now I think a Have a problem of irq losing form eth.

Thanks again


In data giovedì 18 marzo 2010 09:04:22, Wolfgang Denk ha scritto:
: > Dear Fabio Giovagnini,
> 
> you are indeed completely off topic here on the U-Boot list.
> 
> In message <201003180657.27345.fabio.giovagn...@aurion-tech.com> you wrote:
> > Im able to mount the nfsroot filesystem but I get this message:
> 
> ...
> 
> > Warning: unable to open an initial console.
> 
> ^
> 
> > In rootpath I should read someting?
> 
> You should read the error messages and contemplate their meaning.
> 
> > Could the problem be my PC is little endian and I' exporting to a big
> > endian CPU?
> 
> No.
> 
> "unable to open an initial console" usually means that there is no
> "/dev/console" entry in your root file system, so check your root file
> system if it is complete.
> 
> [If you were using the ELDK, my bet was that you have forgotten to run
> the ELDK_MAKEDEV (plus eventually the ELDK_FIXOWNER) script(s), but
> you don't include such vital information as where this root file
> system is coming from and why you think it should be a working one.]
> 
> Best regards,
> 
> Wolfgang Denk
> 

-- 
Fabio Giovagnini

Aurion s.r.l.
P.I e C.F.
00885711200
Tel. +39.051.594.78.24
Cell. +39.335.83.50.919
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] serial init

2010-03-18 Thread Valentin Ecker
I see...I think we have a very similar setup, and I see how you init  
your ports. Although I'm not sure if this is suitable for me, since  
editing the ns16550-files to support/init an external COM-chip is not  
a really clean/nice implementation.

I'm not sure if there is any way to implement this in a nice way. But  
I will let you know if we find something ;)

thx for your help!
Valentin

On 18.03.2010, at 15:37, Michael Zaidman wrote:

> On Thu, Mar 18, 2010 at 2:21 PM, Valentin Ecker
>  wrote:
>> well, i don't want to use the second com port of the ns16550. Im  
>> using an
>> external serial chip over EMIF.
>
> I am not familiar with Davinci architecture and probably my case is
> completely different from yours but on our board we have dual uart on
> mpc8349 chip + external quad uart ns16554 chip connected via local
> bus. The current u-boot code supports up to 4  ns16550 devices, i.e.
> from COM1 to COM4. So I extended the serial_ports array to 6 entries
> and in this way got ability to communicate via COM5 and COM6.
>
> Michael.

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


Re: [U-Boot] serial init

2010-03-18 Thread Michael Zaidman
On Thu, Mar 18, 2010 at 4:58 PM, Valentin Ecker
 wrote:
> I see...I think we have a very similar setup, and I see how you init your
> ports. Although I'm not sure if this is suitable for me, since editing the
> ns16550-files to support/init an external COM-chip is not a really
> clean/nice implementation.
>
> I'm not sure if there is any way to implement this in a nice way. But I will
> let you know if we find something ;)
>
I implemented it first in board specific code. It added small code
overhead due to necessity to duplicate the serial_ports array and add
uart_init for ports higher then 4. Afterwards, I implemented the same
in common code. Extending the original serial_ports array makes the
code more generic. I also added serial loopback tests availible via
CLI and POST. I am going to post this patch on u-boot-list promptly.

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


[U-Boot] [Nios] Pull Request

2010-03-18 Thread Scott McNutt
Wolfgang,

The following changes since commit f1fdc42e5efb9e3b6d0dd3b605d0848d3ca8a039:
   Wolfgang Denk (1):
 Merge branch 'master' of git://git.denx.de/u-boot-video

are available in the git repository at:

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

Renato Andreola (1):
   nios2: Added support to YANU UART

Thomas Chou (1):
   nios2: use generic unaligned.h

  cpu/nios2/serial.c|  168 
-
  include/asm-nios2/unaligned.h |6 ++
  include/nios2-yanu.h  |  115 
  3 files changed, 288 insertions(+), 1 deletions(-)
  create mode 100644 include/asm-nios2/unaligned.h
  create mode 100644 include/nios2-yanu.h


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


Re: [U-Boot] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?

2010-03-18 Thread Wolfgang Denk
Dear Brian Hutchinson,

In message <3d1967ab1003180758p2006f562pc56cee3438eb2...@mail.gmail.com> you 
wrote:
> (puts on flame retardant underwear) Can environment variables be
> pulled from Flash and EEPROM?

Not directly.

> Why would I want to do this?  I need to provide fail safe upgrade path
> and need to do something similar to the bootcount feature in PPC (I'm
> using ARM though).

Hm... And redundant environment is not safe enough for you?

> The goal is to not brick a device during a upgrade.  Whatever bank you
> are running out of, you upgrade by flashing the bank not being used.
> Once a bank has been upgraded, if I want to select that bank to boot
> ... I would need to modify a environment variable but if it is stored
> in flash then while that sector (a 256k sector in my case) is being
> updated ... if power is lost I just hosed myself.  If the environment
> variable I update was stored in EEPROM, then it would be closer to an
> atomic action that couldn't be interrupted with say a power failure.

EEPROM is not a bit more reliable than NOR, on contrary (read for
example doc/I2C_Edge_Conditions - unless you write-protect your EEPROm
in hardware it is actually way less reliable).

And redundant environment should cover your use case just fine.

> So what I'm asking about is a Hybrid environment were some variables
> are in flash and some are in EEPROM.  The env is read from both
> locations and saveenv writes some vars in flash and some in EEPROM.
> With the current u-boot code I have (1.1.6) the environment choices
> are mutually exclusive (flash, eeprom, nvram etc.)

This makes little sense to me.

If you really fell like it, you can of course store some script image
in EEPROM which you can then read and run (using "eeprom read" plus
"source" commands).

> Is this a sane approach or am I heading for heart ache?  This has to
> be something that others have dealt with but I didn't see any similar
> discussions in the archives.

Maybe because redundant environment is good enough for all practical
purposes?

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
Objects in mirror are closer than they appear.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


[U-Boot] [PATCH v2] add new board pm9g45

2010-03-18 Thread Asen Dimov
Add the new board PM9G45 from Ronetix GmbH.
* AT91SAM9G45 MCU at 400Mhz.
* 128MB DDR2 SDRAM
* 256MB NAND
* 4MB DataFlash (optional)
* 10/100 MBits Ethernet DP83848
* Serial number chip DS2401

The board is made as SODIMM200 module.
For more info www.ronatix.at or i...@ronetix.at.

Signed-off-by: Asen Dimov 
---
 MAINTAINERS|1 +
 MAKEALL|1 +
 Makefile   |4 +
 board/ronetix/pm9g45/Makefile  |   54 
 .../at91sam9m10g45ek => ronetix/pm9g45}/config.mk  |0 
 board/ronetix/pm9g45/pm9g45.c  |  317 
 include/configs/pm9g45.h   |  218 ++
 7 files changed, 595 insertions(+), 0 deletions(-)
 create mode 100644 board/ronetix/pm9g45/Makefile
 copy board/{atmel/at91sam9m10g45ek => ronetix/pm9g45}/config.mk (100%)
 create mode 100644 board/ronetix/pm9g45/pm9g45.c
 create mode 100644 include/configs/pm9g45.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 80057ce..3659947 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -225,6 +225,7 @@ Ilko Iliev 
 
PM9261  AT91SAM9261
PM9263  AT91SAM9263
+   PM9G45  ARM926EJS (AT91SAM9G45 SoC)
 
 Gary Jennejohn 
 
diff --git a/MAKEALL b/MAKEALL
index beacb5f..ad591d5 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -673,6 +673,7 @@ LIST_at91=" \
otc570  \
pm9261  \
pm9263  \
+   pm9g45  \
SBC35_A9G20 \
TNY_A9260   \
TNY_A9G20   \
diff --git a/Makefile b/Makefile
index d801e25..438580a 100644
--- a/Makefile
+++ b/Makefile
@@ -2882,6 +2882,10 @@ otc570_config:   unconfig
 pm9263_config  :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91
 
+pm9g45_config  :   unconfig
+   @mkdir -p $(obj)include
+   @$(MKCONFIG) -a pm9g45 arm arm926ejs pm9g45 ronetix at91
+
 SBC35_A9G20_NANDFLASH_config \
 SBC35_A9G20_EEPROM_config \
 SBC35_A9G20_config :   unconfig
diff --git a/board/ronetix/pm9g45/Makefile b/board/ronetix/pm9g45/Makefile
new file mode 100644
index 000..dd5b02e
--- /dev/null
+++ b/board/ronetix/pm9g45/Makefile
@@ -0,0 +1,54 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop 
+# Lead Tech Design 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y += pm9g45.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+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
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff --git a/board/atmel/at91sam9m10g45ek/config.mk 
b/board/ronetix/pm9g45/config.mk
similarity index 100%
copy from board/atmel/at91sam9m10g45ek/config.mk
copy to board/ronetix/pm9g45/config.mk
diff --git a/board/ronetix/pm9g45/pm9g45.c b/board/ronetix/pm9g45/pm9g45.c
new file mode 100644
index 000..28221ec
--- /dev/null
+++ b/board/ronetix/pm9g45/pm9g45.c
@@ -0,0 +1,317 @@
+/*
+ * (C) Copyright 2010
+ * Ilko Iliev 
+ * Asen Dimov 
+ * Ronetix GmbH 
+ *
+ * (C) Copyright 2007-2008
+ * Stelian Pop 
+ * Lead Tech Design 
+ *
+ * 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

Re: [U-Boot] [PATCH V5 10/11] fsl_esdhc: add support for mx51 processor

2010-03-18 Thread Kumar Gala

On Mar 4, 2010, at 1:23 PM, Stefano Babic wrote:

> The esdhc controller in the mx51 processor is quite
> the same as the one in some powerpc processors
> (MPC83xx, MPC85xx). This patches adapts the driver
> to support the arm mx51.
> 
> Signed-off-by: Stefano Babic 
> ---

Do you have any time to possible test a few patches to fsl_esdhc on mx51?

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


Re: [U-Boot] [PATCH V5 10/11] fsl_esdhc: add support for mx51 processor

2010-03-18 Thread Detlev Zundel
Hi Kumar,

> On Mar 4, 2010, at 1:23 PM, Stefano Babic wrote:
>
>> The esdhc controller in the mx51 processor is quite
>> the same as the one in some powerpc processors
>> (MPC83xx, MPC85xx). This patches adapts the driver
>> to support the arm mx51.
>> 
>> Signed-off-by: Stefano Babic 
>> ---
>
> Do you have any time to possible test a few patches to fsl_esdhc on mx51?

At the moment Stefano is somewhat under water currently - I hope he will
resurface beginning next week.  What exactly do you want him to test?

Cheers
  Detlev

-- 
... that every year or so they're going to give you a new release full
of 50 000  additional lines of code all  written  by monkeys.  Because
they generally follow  the  ``million monkeys typing,   and eventually
they'll come up with something useful'' school of system development.
-- Richard M. Stallman
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot


Re: [U-Boot] U-Boot Env Vars in Flash and EEPROM at the same time (hybrid env)?

2010-03-18 Thread Brian Hutchinson
>
> Hm... And redundant environment is not safe enough for you?

I don't know much about redundant env but now that you mention it ...
I do remember seeing something about that in the code.  I'll look into
it.  Thanks!

>
>> The goal is to not brick a device during a upgrade.  Whatever bank you
>> are running out of, you upgrade by flashing the bank not being used.
>> Once a bank has been upgraded, if I want to select that bank to boot
>> ... I would need to modify a environment variable but if it is stored
>> in flash then while that sector (a 256k sector in my case) is being
>> updated ... if power is lost I just hosed myself.  If the environment
>> variable I update was stored in EEPROM, then it would be closer to an
>> atomic action that couldn't be interrupted with say a power failure.
>
> EEPROM is not a bit more reliable than NOR, on contrary (read for
> example doc/I2C_Edge_Conditions - unless you write-protect your EEPROm
> in hardware it is actually way less reliable).

I've seen that document and have raised the issues (and discussions I
found about it in the archives) to those that "really" want to use the
EEPROM.

I guess when I first thought about this I had sector erase time of
flash vs hitting a single byte of the EEPROM but I wasn't thinking of
the I2C transaction.  That realization hit me right after I hit send
and realized what I posted was heading in the weeds.

>
> And redundant environment should cover your use case just fine.

Cool!  I will surely read all I can on it.

>
>> So what I'm asking about is a Hybrid environment were some variables
>> are in flash and some are in EEPROM.  The env is read from both
>> locations and saveenv writes some vars in flash and some in EEPROM.
>> With the current u-boot code I have (1.1.6) the environment choices
>> are mutually exclusive (flash, eeprom, nvram etc.)
>
> This makes little sense to me.

Thanks for being gentle.  I had temporary insanity.

Regards,

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


Re: [U-Boot] [PATCH V5 10/11] fsl_esdhc: add support for mx51 processor

2010-03-18 Thread stefano babic
Kumar Gala wrote:
> 
> Do you have any time to possible test a few patches to fsl_esdhc on mx51?

Hi Kumar,

I could test your patches next week, I have no possibility to access to
the imx51evk board before. Should be ok for you ?

Stefano


-- 
=
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 V5 10/11] fsl_esdhc: add support for mx51 processor

2010-03-18 Thread Kumar Gala

On Mar 18, 2010, at 11:15 AM, Detlev Zundel wrote:

> Hi Kumar,
> 
>> On Mar 4, 2010, at 1:23 PM, Stefano Babic wrote:
>> 
>>> The esdhc controller in the mx51 processor is quite
>>> the same as the one in some powerpc processors
>>> (MPC83xx, MPC85xx). This patches adapts the driver
>>> to support the arm mx51.
>>> 
>>> Signed-off-by: Stefano Babic 
>>> ---
>> 
>> Do you have any time to possible test a few patches to fsl_esdhc on mx51?
> 
> At the moment Stefano is somewhat under water currently - I hope he will
> resurface beginning next week.  What exactly do you want him to test?

I've got a few patches from our internal team for PQ3/eSHDC support and want to 
make sure they didn't break mx51 support.

I'll post the patches once I clean them up (not 100% sure on the rationale for 
all of them at this point).

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


Re: [U-Boot] [PATH] at91: add hwecc method for nand

2010-03-18 Thread Scott Wood
On Thu, Mar 18, 2010 at 11:55:29AM +0500, Nikolay Petukhov wrote:
> + /* move to ECC position if needed */
> + if (eccpos[0] != 0) {
> + /* This only works on large pages
> +  * because the ECC controller waits for
> +  * NAND_CMD_RNDOUTSTART after the
> +  * NAND_CMD_RNDOUT.
> +  * anyway, for small pages, the eccpos[0] == 0
> +  */
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT,
> + mtd->writesize + eccpos[0], -1);
> + }
[snip]
> + /* get back to oob start (end of page) */
> + chip->cmdfunc(mtd, NAND_CMD_RNDOUT, mtd->writesize, -1);

Is the second RNDOUT OK on small page NAND?

> + //struct atmel_nand_host *host = nand_chip->priv;

Just remove the line.

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


Re: [U-Boot] [PATCH v3] TI: Davinci: NAND Driver Cleanup

2010-03-18 Thread Scott Wood
On Wed, Mar 17, 2010 at 10:03:10AM -0400, Cyril Chemparathy wrote:
> Modified to use IO accessor routines consistently.  Eliminated volatile usage
> to keep checkpatch.pl happy.
> 
> Signed-off-by: Cyril Chemparathy 
> ---
> Minor formatting

Applied to u-boot-nand-flash/next

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


Re: [U-Boot] uboot on microblaze, compilation error

2010-03-18 Thread Mike Frysinger
On Thursday 18 March 2010 05:29:19 Michal Simek wrote:
> Mike Frysinger wrote:
> > On Wednesday 17 March 2010 14:36:38 Horst Gall wrote:
> >> I try to compile an actual version of u-boot for xilinx microblaze.
> >> 
> >> The linker ends with the error-message:
> >> ... mb-ld.real:u-boot.lds:1: parse error
> >> 
> >> In u-boot main-directory I found the file 'u-boot.lds':
> >> OUTPUT_ARCH(1)
> >> ENTRY(_start)
> >> ...
> >> cpu/1/start.o (.text)
> >> ...
> >> 
> >> When I change the "1" to "microblaze" it works:
> >> OUTPUT_ARCH(microblaze)
> >> ENTRY(_start)
> >> ...
> >> cpu/microblaze/start.o (.text)
> >> ...
> >> 
> >> After "make ...config" my modification is overwritten.
> >> How can I fix this problem?
> > 
> > add "#undef microblaze" to the top of board/xilinx/microblaze-generic/u-
> > boot.lds
> 
> Mike is right. I expect you are using toolchain from EDK where the
> problem is. Linux toolchain are ok.

i dont think the toolchain is broken.  this is standard gcc behavior for all 
arches.  i would check the microblaze gcc port, but it doesnt seem to be 
mainlined at gcc.gnu.org, so ive lost interest.
-mike


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


[U-Boot] Attn

2010-03-18 Thread ½²±R¬w
Prize Won! (Five hundred and fifty two Thousand pounds sterling), kindly
confirm receipt of this email, by forwarding Your Details as stated below to
our events manager on Email: rennyharli...@live.com Name/Address/Tel
number/Age/Occupation/Country of Origin.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot