Re: [U-Boot] [PATCH 5/8]: Use do_div from div64.h for vsprintf

[Dirk Behme]

Stefan Roese wrote:
> On Tuesday 07 July 2009 15:59:27 Simon Kagstrom wrote:
>> Signed-off-by: Simon Kagstrom 
> 
> Acked-by: Stefan Roese 

Could we have this patch asap (for merge window close?) in mainline? 
Seems that everybody agrees on it.

Many thanks

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

[U-Boot] env_onenand compiler warning

[Dirk Behme]

Testing recent mainline git head for omap3_evm_config I get compiler 
warning

env_onenand.c: In function 'saveenv':
env_onenand.c:104: warning: format '%08lx' expects type 'long unsigned 
int', but argument 2 has type 'loff_t'

Is there already a fix available?

Thanks

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

Re: [U-Boot] [PATCH 1/1] OMAP3 Fix compiler warning for v7_flush_dcache_all

[Dirk Behme]

Dear Wolfgang,

Wolfgang Denk wrote:
> Dear Tom Rix,
> 
> In message <1246392253-8431-2-git-send-email-tom@windriver.com> you wrote:
>> On build of omap3 targets in MAKEALL, the *.ERR files have
>>
>> cpu.c: In function 'cleanup_before_linux':
>> cpu.c:64: warning: implicit declaration of function 'v7_flush_dcache_all'
>> cpu.c:64: warning: implicit declaration of function 'get_device_type
>>
>> The functions v7_flush_dcache_all and get_device_type are declared
>> in include/asm-arm/arch-omap3/sys_proto.h, so use this file to
>> declare the functions.
>>
>> Signed-off-by: Tom Rix 
>> ---
>>  cpu/arm_cortexa8/cpu.c |3 +++
>>  1 files changed, 3 insertions(+), 0 deletions(-)
> 
> Applied, thanks.

Many thanks!

I'm not sure, Tom will have the details, but there might be a newer 
version of this patch?

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

Best regards

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

Re: [U-Boot] [RFC] CONFIG naming convetion

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> In message <200907181115.26404.rg...@blackfin.uclinux.org> you wrote:
>> It would be nice to come up with some list of namespaces, and what they
>> they should be used for...
> 
> Agreed.
> 
>> For example, should it be:
>> CONFIG_DRIVER_OMAP24XX_I2C
>> or
>> CONFIG_SYS_I2C_DRIVER_OMAP24XX
>> or
>> CONFIG_DRIVER_I2C_OMAP24XX
> 
> Well, the difference between CONFIG_ and CONFIG_SYS_ is well-defined.
> 
> And the "DRIVER_" part makes not much sense to me in any of the
> examples above. 

Agreed.

> My personal way of thinking about such options is usually  CPU/archi-
> tecture  first,  so I would probably chose CONFIG_OMAP24XX_I2C to en-
> able/disable the I2C driver on a OMAP24XX based board, but  I  under-
> stand  that there are reasons to prefer CONFIG_I2C_OMAP24XX as well -
> let's see if there is a clear majority of opiniions...

I vote for CONFIG_I2C_xxx because we collect all i2c drivers in
drivers/i2c without considering the plattform, so I think CONFIG_I2C_
represents better the code structure.

>> Again - which is only used in one place:
>> drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
>> include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C
>>
>> Which is fine - since it is a driver, which I'm sure that people out of tree 
>> use.
> 
> Well, if only out-of-tree ports use it, it probably should never have
> been added in the first place.
> 
>> I would think should be CONFIG_DRIVERS_PATA_BFIN
> 
> I dosagree, the "DRIVERS" part is just added line noise.

Yep.

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

Re: [U-Boot] arm, i2c: added support for the TWSI I2C Interface

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4a61cc6b.3090...@denx.de> you wrote:
>>> Jean-Christophe, I recommend you accept Heiko's patch as is (as it was
>>> submitted before your patch), and then just regenerate your patch
>>> (which is trivial for you to do as you have the script ready).
>> Hmm.. I have to fix some comments, which Prafulla suggested, also
>> to integrate the speed settings ...
>>
>> So I don;t know, if this patch should go in mainline as it is ...
>> I think it is easier, if we integrate Jean-Christophes renaming
>> patch (the reposted version with correct subject ;-)
>> and then I can easy adapt "my" patch ...
> 
> Jean-Christophes renaming patch is at the very end of a prtty long
> queue. I would not wait that long.

Ok. So I try to add the comments from Prafulla and Jean-Christophe
and post a new version.

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

Re: [U-Boot] [PATCH 1/3] tools: mkimage: hdr_size used to facilitate customized support

[Prafulla Wadaskar]

 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Sunday, July 19, 2009 3:04 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; 
> Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH 1/3] tools: mkimage: hdr_size 
> used to facilitate customized support
> 
> Dear Prafulla Wadaskar,
> 
> In message 
> <1247967958-4446-1-git-send-email-prafu...@marvell.com> you wrote:
> > hdr_size variable is initialized
> > at the start of image creation algorithm instead of reading 
> it each time.
> > This facilitate to use the common code for other image type 
> > implementations for ex. kwbimage
> 
> Hm... I have no idea what you are trying to do, or why. You 
> are aware that image_get_header_size()  is  a  static  
> inline,  returning  just "sizeof (image_header_t)"?
Dear Wolfgang

This is what done in image_get_header_size().
I do not want to disturb current mkimage implementation.
whereas for mkbimage creation the image_header size will come form kwbimag.h 
and not generic one which is used further in image creation part.

In brief, header size will be decided by which kind of image you are creating.

This is a generic change required for kwbimage support.
I have kept this change in separate patch to get some better readability of 
generic changes for kwbimage support.

> 
> As far as the context of mkimage goes, you could as well 
> consider it a constant.
This will be decided runtime hence can not be considered as constant.
Well I can update the relevant line kwbimage patch to read sizeof() instead of 
api kwbimage_get_header_size()
 
> 
> > Signed-off-by: Prafulla Wadaskar 
> > ---
> >  tools/mkimage.c |   18 --
> >  1 files changed, 8 insertions(+), 10 deletions(-)
> > 
> > diff --git a/tools/mkimage.c b/tools/mkimage.c index 
> 967fe9a..c5b593c 
> > 100644
> > --- a/tools/mkimage.c
> > +++ b/tools/mkimage.c
> > @@ -250,9 +250,10 @@ NXTARG:;
> >  *
> >  * write dummy header, to be fixed later
> >  */
> > -   memset (hdr, 0, image_get_header_size ());
> > -
> > -   if (write(ifd, hdr, image_get_header_size ()) != 
> image_get_header_size ()) {
> > +   int hdr_size;
> 
> We don't allow variable declarations in the middle of the code.
Okay I will more this up

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

[U-Boot] [PATCH] atmel_df_pow2: standalone to convert dataflashes to pow2

[Mike Frysinger]

Atmel DataFlashes by default operate with pages with 1056 byte pages.  They
also have a "power of 2" mode where the pages are 1024 bytes in size.  The
latter mode is required in order to boot with a Blackfin processor, so many
people wish to convert their DataFlashes on their development systems to
this mode.  This standalone application does just that.

Signed-off-by: Mike Frysinger 
---
 examples/.gitignore  |1 +
 examples/Makefile|4 +
 examples/atmel_df_pow2.c |  206 ++
 3 files changed, 211 insertions(+), 0 deletions(-)
 create mode 100644 examples/atmel_df_pow2.c

diff --git a/examples/.gitignore b/examples/.gitignore
index 0d1864c..7b783fc 100644
--- a/examples/.gitignore
+++ b/examples/.gitignore
@@ -1,4 +1,5 @@
 /82559_eeprom
+/atmel_df_pow2
 /hello_world
 /interrupt
 /mem_to_mem_idma2intr
diff --git a/examples/Makefile b/examples/Makefile
index dbcfa92..9f67afd 100644
--- a/examples/Makefile
+++ b/examples/Makefile
@@ -86,6 +86,10 @@ ELF  = hello_world
 SREC   = hello_world.srec
 BIN= hello_world.bin
 
+ELF+= atmel_df_pow2
+SREC   += atmel_df_pow2.srec
+BIN+= atmel_df_pow2.bin
+
 ifeq ($(CPU),mpc8xx)
 ELF+= test_burst
 SREC   += test_burst.srec
diff --git a/examples/atmel_df_pow2.c b/examples/atmel_df_pow2.c
new file mode 100644
index 000..e6d02b1
--- /dev/null
+++ b/examples/atmel_df_pow2.c
@@ -0,0 +1,206 @@
+/*
+ * atmel_df_pow2.c - convert Atmel Dataflashes to Power of 2 mode
+ *
+ * Copyright 2009 Analog Devices Inc.
+ *
+ * Licensed under the 2-clause BSD.
+ */
+
+#include 
+#include 
+
+#define CMD_ID0x9f
+#define CMD_STAT  0xd7
+#define CMD_CFG   0x3d
+
+static int flash_cmd(struct spi_slave *slave, uchar cmd, uchar *buf, int len)
+{
+   buf[0] = cmd;
+   return spi_xfer(slave, 8 * len, buf, buf, SPI_XFER_BEGIN | 
SPI_XFER_END);
+}
+
+static int flash_status(struct spi_slave *slave)
+{
+   uchar buf[2];
+   if (flash_cmd(slave, CMD_STAT, buf, sizeof(buf)))
+   return -1;
+   return buf[1];
+}
+
+static int flash_set_pow2(struct spi_slave *slave)
+{
+   int ret;
+   uchar buf[4];
+
+   buf[1] = 0x2a;
+   buf[2] = 0x80;
+   buf[3] = 0xa6;
+
+   ret = flash_cmd(slave, CMD_CFG, buf, sizeof(buf));
+   if (ret)
+   return ret;
+
+   /* wait Tp, or 6 msec */
+   udelay(6000x);
+
+   ret = flash_status(slave);
+   if (ret == -1)
+   return 1;
+
+   return ret & 0x1 ? 0 : 1;
+}
+
+static int flash_check(struct spi_slave *slave)
+{
+   int ret;
+   uchar buf[4];
+
+   ret = flash_cmd(slave, CMD_ID, buf, sizeof(buf));
+   if (ret)
+   return ret;
+
+   if (buf[1] != 0x1F) {
+   printf("atmel flash not found (id[0] = %#x)\n", buf[1]);
+   return 1;
+   }
+
+   if ((buf[2] >> 5) != 0x1) {
+   printf("AT45 flash not found (id[0] = %#x)\n", buf[2]);
+   return 2;
+   }
+
+   return 0;
+}
+
+static char *getline(void)
+{
+   static char buffer[100];
+   char c;
+   size_t i;
+
+   i = 0;
+   while (1) {
+   buffer[i] = '\0';
+
+   c = getc();
+
+   switch (c) {
+   case '\r':  /* Enter/Return key */
+   case '\n':
+   puts("\n");
+   return buffer;
+
+   case 0x03:  /* ^C - break */
+   return NULL;
+
+   case 0x5F:
+   case 0x08:  /* ^H  - backspace */
+   case 0x7F:  /* DEL - backspace */
+   if (i) {
+   puts("\b \b");
+   i--;
+   }
+   break;
+
+   default:
+   /* Ignore control characters */
+   if (c < 0x20)
+   break;
+   /* Queue up all other characters */
+   buffer[i++] = c;
+   printf("%c", c);
+   break;
+   }
+   }
+}
+
+int atmel_df_pow2(int argc, char *argv[])
+{
+   /* Print the ABI version */
+   app_startup(argv);
+   if (XF_VERSION != get_version()) {
+   printf("Expects ABI version %d\n", XF_VERSION);
+   printf("Actual U-Boot ABI version %lu\n", get_version());
+   printf("Can't run\n\n");
+   return 1;
+   }
+
+   spi_init();
+
+   while (1) {
+   struct spi_slave *slave;
+   char *line, *p;
+   int bus, cs, status;
+
+   puts("\nenter the [BUS:]CS of the SPI flash: ");
+   line = getline();
+
+   /* CTRL+C */
+   if (!line)
+   return 0;
+   if (line[0] == '\0')
+   continue;
+
+   bus = cs = simpl

Re: [U-Boot] [PATCH 2/3] tools: mkimage (type=kwbimage) kirkwood boot image support

[Prafulla Wadaskar]

Dear Wolfgang
Thanks for your quick feedback 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Sunday, July 19, 2009 3:33 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; 
> Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH 2/3] tools: mkimage 
> (type=kwbimage) kirkwood boot image support
> 
> Dear Prafulla Wadaskar,
> 
> In message 
> <1247967958-4446-2-git-send-email-prafu...@marvell.com> you wrote:
> > For more details refer docs/README.kwbimage
> 
> ...
> > diff --git a/doc/README.kwbimage b/doc/README.kwbimage new 
> file mode 
> > 100644 index 000..b00a053
> > --- /dev/null
> > +++ b/doc/README.kwbimage
> > @@ -0,0 +1,77 @@
> > +-
> > +Kirkwood Boot Image generation using mkimage
> > +-
> > +
> > +This document describes the U-Boot feature as it is 
> implemented for 
> > +the Kirkwood family of SoCs.
> > +
> > +The Kirkwood SoC's can boot directly from NAND FLASH, SPI 
> FLASH, SATA 
> > +etc. using its internal bootRom support.
> > +
> > +for more details refer section 24.2 of Kirkwood functional 
> specifications.
> > +ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
> > +
> > +Commad syntax:
> > +./tools/mkimage -n  \
> > +-T kwbimage -a  -e 
>  
> > +-d  
> > +
> > +for ex.
> > +./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
> > +-T kwbimage -a 0x0060 -e 0x0060 -d 
> u-boot.bin 
> > +u-boot.kwb
> > +
> > +kwimage support available with mkimage utility will 
> generate kirkwood 
> > +boot image that can be flashed on the board nand/spi flash
> 
> 
> Maximum line length exceeded. Please fix globally.
Okay I will correct them

> 
> 
> ...
> > +Author: Prafulla Wadaskar 
> > +--
> > +
> 
> Please do not add trailing empty lines.
Okay

> 
> > diff --git a/include/image.h b/include/image.h index 
> f183757..ed94dda 
> > 100644
> > --- a/include/image.h
> > +++ b/include/image.h
> > @@ -158,6 +158,7 @@
> >  #define IH_TYPE_SCRIPT 6   /* Script file  
>   */
> >  #define IH_TYPE_FILESYSTEM 7   /* Filesystem Image 
> (any type)*/
> >  #define IH_TYPE_FLATDT 8   /* Binary Flat 
> Device Tree Blob  */
> > +#define IH_TYPE_KWBIMAGE   9   /* Boot Rom 
> Image */
> 
> Please s/Boot Rom Image/Kirkwood Boot Rom Image/ or similar.
Okay

> 
> > diff --git a/tools/kwbimage.c b/tools/kwbimage.c new file 
> mode 100644 
> > index 000..06f256e
> > --- /dev/null
> > +++ b/tools/kwbimage.c
> > ...
> > +/*
> > + * Generates 32 bit checksum
> > + */
> > +u32 kwbimage_checksum32(void *start, u32 len, u32 csum) {
> > +   register u32 sum = csum;
> > +   volatile u32 *startp = (volatile u32 *)start;
> > +
> > +   do {
> > +   sum += *startp;
> > +   startp++;
> > +   len -= sizeof(u32);
> > +   } while (len > 0);
> > +   return (sum);
> > +}
> 
> This will fail if start is not 32bit aligned; if you can 
> guarantee that it is always aligned, then please pass a u32 pointer.
Yes the pointer is char *, I will add check for 32bit alligned ptr and use of 
temp buffer to correct this

> 
> > +void kwdimage_set_ext_header(struct kwb_header *kwbhdr, 
> char* fname) {
> > +   bhr_t *mhdr = &kwbhdr->kwb_hdr;
> > +   extbhr_t *exthdr = &kwbhdr->kwb_exthdr;
> > +   int fd = -1;
> > +   int lineno, i;
> > +   char *line = NULL;
> > +   char cmdstr[MAX_KWBCMD_LEN], datastr[MAX_KWBDATA_LEN];
> > +   size_t len = 0;
> > +
> > +   exthdr->dramregsoffs = (u32)&exthdr->rcfg - (u32)mhdr;
> > +
> > +   if ((fd = fopen(fname, "r")) == 0) {
> > +   fprintf (stderr, "Err: Can't open %s: %s\n",
> > +   fname, strerror(errno));
> > +   exit (EXIT_FAILURE);
> > +   }
> > +
> > +   i = lineno = 0;
> > +   while ((getline(&line, &len, fd)) != -1) {
> > +   /* skip empty lines and lines staring with # */
> 
> s/staring/starting/
Okay

> 
> > +   lineno++;
> > +   if (!(line[0] != '#' && strlen(line) != 1))
> > +   continue;
> 
> This is a bit simple-minded. This will for example fail on 
> DOS-formatted files, and for lines that contain only white 
> space (which still look "empty" to most users and are thus 
> hard to spot). 
To take care of Dos formatted file I should use "strlen(line) <= 1" right
As explained in doc.README.kwimage,
any other line apart from above will be considered as valid configuration line.
This is bare minimal parsing provided here which is sufficient

> 
> > +   if (strlen(line) > (MAX_KWBCMD_LEN + MAX_KWBDATA_LEN)) {
> > +   printf("Err.. %s(line no %d) too long\n",
> 
> "Error: %s[%d] Line too long\n" ?
Good one.. I will update this

> 
> > diff --git a/tools/kwbimage.h b/tools/kwbimage.h new file 
> mod

Re: [U-Boot] [PATCH v1] usb: bugfix driver/usb/host/ehci-hcd.c function ehci_submit_root

[Prafulla Wadaskar]

 

> -Original Message-
> From: l.ping...@gmail.com [mailto:l.ping...@gmail.com] On 
> Behalf Of Remy Bohmer
> Sent: Saturday, July 18, 2009 2:29 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATCH v1] usb: bugfix 
> driver/usb/host/ehci-hcd.c function ehci_submit_root
> 
> Hello Prafulla,
> 
> 2009/7/17 Prafulla Wadaskar :
> > This change is cheked in Linux source and fix found to be in sync.
> > This patch is tested for USB host interface on Kirkwood based 
> > Sheevaplug platform (ARM little endian board)
> >
> > Risk: the impact of this patch is not validated on big endian board.
> > This need to be checked...
> >
> > Signed-off-by: Prafulla Wadaskar 
> > ---
> > Change log:
> > v1: le16_to_cpu macro removed for typeReq
> 
> As discussed previously: Applied to u-boot-usb.
> Thanks!
Many thanks Remy :-)

Regards..
Prafulla . .

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

Re: [U-Boot] [PATCH v7 2/6] Marvell Sheevaplug Board support

[Prafulla Wadaskar]

 

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] 
> Sent: Saturday, July 18, 2009 11:11 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; 
> Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH v7 2/6] Marvell Sheevaplug Board support
> 
> On 20:58 Thu 16 Jul , Prafulla Wadaskar wrote:
> > Reference:
> > http://plugcomputer.org/
> > http://openplug.org/plugwiki/index.php/Das_U-boot_plug_support
> > 
> > This patch is tested for-
> > 1. Boot from DRAM/NAND flash
> > 2. File transfer using tftp
> > 3. NAND flash read/write/erase
> > 4. Linux kernel and RFS Boot from NAND 5. Enabled USB PHY init for 
> > kernel need 6. Boot from USB supported
> > 
> > Note: to boot Kirkwood kernel with USB support,
> > you should add "usb start" in the boot sequence
> > 
> > Signed-off-by: Prafulla Wadaskar 
> Applied to u-boot-arm
Thank you Jean..
Regards..
Prafulla . .

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

Re: [U-Boot] [PATCH v13 3/6] Marvell MV88F6281GTW_GE Board support

[Prafulla Wadaskar]

 

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] 
> Sent: Sunday, July 19, 2009 12:11 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; 
> Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH v13 3/6] Marvell MV88F6281GTW_GE 
> Board support
> 
> On 20:58 Thu 16 Jul , Prafulla Wadaskar wrote:
> > This is Marvell's 88F6281_A0 based custom board developed 
> for wireless 
> > access point product
> > 
> > This patch is tested for-
> > 1. Boot from DRAM/SPI flash/NFS
> > 2. File transfer using tftp and loadb
> > 3. SPI flash read/write/erase
> > 4. Booting Linux kernel and RFS from SPI flash 5. Boot from USB 
> > supported
> > 
> > Reviewed-by: Ronen Shitrit 
> > Signed-off-by: Prafulla Wadaskar 
> > ---
> applied to u-boot-arm
Thanks Jean..
Regards..
Prafulla . .

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

Re: [U-Boot] [PATCH 5/6] net: Kirkwood_egiga: forced interface speed config support

[Prafulla Wadaskar]

 

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] 
> Sent: Sunday, July 19, 2009 12:14 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; 
> Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH 5/6] net: Kirkwood_egiga: forced 
> interface speed config support
> 
> On 20:58 Thu 16 Jul , Prafulla Wadaskar wrote:
> > By default Auto Negotiation is enabled for interface speed 
> but on some 
> > platforms like RD6281A it does not work.
> > If you want to forced program it to desired speed, this patch helps-
> > 
> > Through this patch Auto negotiation can be disabled and desired 
> > interface speed can be configured
> > 
> > This patch is tested on RD6281A Kirkwood board
> > 
> > Signed-off-by: Prafulla Wadaskar 
> > ---
> >  drivers/net/kirkwood_egiga.c |   24 
> >  1 files changed, 24 insertions(+), 0 deletions(-)
> > 
> > diff --git a/drivers/net/kirkwood_egiga.c 
> > b/drivers/net/kirkwood_egiga.c index 3c5db19..1dfd567 100644
> > --- a/drivers/net/kirkwood_egiga.c
> > +++ b/drivers/net/kirkwood_egiga.c
> > @@ -415,7 +415,31 @@ static int kwgbe_init(struct eth_device *dev)
> > /* Assign port configuration and command. */
> > KWGBEREG_WR(regs->pxc, PRT_CFG_VAL);
> > KWGBEREG_WR(regs->pxcx, PORT_CFG_EXTEND_VALUE);
> > +   /*
> > +* Forced 10/100/1000BASE-T interface speed configuration
> > +* By default Auto Negotiation of interface speed is enabled
> > +* This can be forced disabled and desired speed can be 
> configured
> > +*/
> > +#ifdef CONFIG_DIS_AUTO_NEG_SPEED_GMII #if (!defined 
> > +(CONFIG_PHY_SPEED) || (CONFIG_PHY_SPEED == _1000BASET))
> Could you find a better config taht _1000BASET & co
Hi Jean,
I have reused it from include/miiphy.h which is relevant too.

Regards..
Prafulla . .

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

Re: [U-Boot] [PATCH 6/6] Marvell RD6281A Board support

[Prafulla Wadaskar]

 

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] 
> Sent: Sunday, July 19, 2009 12:18 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; 
> Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH 6/6] Marvell RD6281A Board support
> 
> > diff --git a/include/configs/rd6281a.h 
> b/include/configs/rd6281a.h new 
> > file mode 100644 index 000..065e4aa
> > --- /dev/null
> > +++ b/include/configs/rd6281a.h
> > @@ -0,0 +1,209 @@
> > +/*
> > + * (C) Copyright 2009
> > + * Marvell Semiconductor 
> > + * Written-by: Prafulla Wadaskar 
> > + *
> > + * 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
> > + */
> > +
> > +#ifndef _CONFIG_RD6281A_H
> > +#define _CONFIG_RD6281A_H
> > +
> > +/*
> > + * Version number information
> > + */
> > +#define CONFIG_IDENT_STRING"\nMarvell-Sheevaplug"
> ???
> Sheevaplug?
Sorry.. I observed this after git-send :-) , patch already reposted
Reference: http://lists.denx.de/pipermail/u-boot/2009-July/056438.html

Regards..
Prafulla . .


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

Re: [U-Boot] [PATCH 3/3] Kirkwood: Sheevaplug: kwimage configuration

[Prafulla Wadaskar]

 

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] 
> Sent: Sunday, July 19, 2009 2:56 AM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Manas Saksena; Ronen Shitrit; 
> Nicolas Pitre; Ashish Karkare; Prabhanjan Sarnaik; Lennert Buijtenhek
> Subject: Re: [U-Boot] [PATCH 3/3] Kirkwood: Sheevaplug: 
> kwimage configuration
> 
> > +
> > +# Boot Media configurations
> > +BOOT_FROM  nand
> > +NAND_ECC_MODE  default
> > +NAND_PAGE_SIZE 0x0800
> > +
> > +# SOC registers configuration for initial values using 
> bootrom header 
> > +extension # Maximum KWBIMAGE_MAX_CONFIG configurations allowed
> > +
> > +# Configure RGMII-0 interface pad voltage to 1.8V 0xFFD100e0 
> > +0x1b1b1b9b # DRAM Configuration 0xFFD01400 0x43000c30
> could you give more details about the configs
Dear Jean
I will add details for each configuration

Regards..
Prafulla . .

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

[U-Boot] [PATCH] export SPI functions to standalone apps

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
 common/exports.c   |8 
 include/_exports.h |8 
 include/exports.h  |3 ++-
 3 files changed, 18 insertions(+), 1 deletions(-)

diff --git a/common/exports.c b/common/exports.c
index ec4656b..b3b6e1f 100644
--- a/common/exports.c
+++ b/common/exports.c
@@ -38,4 +38,12 @@ void jumptable_init (void)
gd->jt[XF_i2c_write] = (void *) i2c_write;
gd->jt[XF_i2c_read] = (void *) i2c_read;
 #endif
+#ifdef CONFIG_CMD_SPI
+   gd->jt[XF_spi_init] = (void *) spi_init;
+   gd->jt[XF_spi_setup_slave] = (void *) spi_setup_slave;
+   gd->jt[XF_spi_free_slave] = (void *) spi_free_slave;
+   gd->jt[XF_spi_claim_bus] = (void *) spi_claim_bus;
+   gd->jt[XF_spi_release_bus] = (void *) spi_release_bus;
+   gd->jt[XF_spi_xfer] = (void *) spi_xfer;
+#endif
 }
diff --git a/include/_exports.h b/include/_exports.h
index af43885..2ff95cf 100644
--- a/include/_exports.h
+++ b/include/_exports.h
@@ -24,3 +24,11 @@ EXPORT_FUNC(strcmp)
 EXPORT_FUNC(i2c_write)
 EXPORT_FUNC(i2c_read)
 #endif
+#ifdef CONFIG_CMD_SPI
+EXPORT_FUNC(spi_init)
+EXPORT_FUNC(spi_setup_slave)
+EXPORT_FUNC(spi_free_slave)
+EXPORT_FUNC(spi_claim_bus)
+EXPORT_FUNC(spi_release_bus)
+EXPORT_FUNC(spi_xfer)
+#endif
diff --git a/include/exports.h b/include/exports.h
index 0620e9e..16ea03a 100644
--- a/include/exports.h
+++ b/include/exports.h
@@ -33,6 +33,7 @@ void forceenv (char *varname, char *varvalue);
 int i2c_write (uchar, uint, int , uchar* , int);
 int i2c_read (uchar, uint, int , uchar* , int);
 #endif
+#include 
 
 void app_startup(char **);
 
@@ -46,7 +47,7 @@ enum {
XF_MAX
 };
 
-#define XF_VERSION 4
+#define XF_VERSION 5
 
 #if defined(CONFIG_I386)
 extern gd_t *global_data;
-- 
1.6.3.3

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

[U-Boot] Pull request u-boot-blackfin.git

[Mike Frysinger]

The following changes since commit d39041fcadb1231430201d298c31f6be03d654f7:
  Wolfgang Denk (1):
PATI board: fix compiler warnings

are available in the git repository at:

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

Mike Frysinger (4):
  Blackfin: add os log functions
  Blackfin: split cpu COBJS into multilines
  Blackfin: bf533-stamp: back down SCLK a bit
  Blackfin: bf537-{minotaur,srv1}: do not hardcode CONFIG_ETHADDR

 cpu/blackfin/Makefile |8 +++-
 cpu/blackfin/os_log.c |   30 ++
 include/asm-blackfin/blackfin_local.h |3 +++
 include/configs/bf533-stamp.h |2 +-
 include/configs/bf537-minotaur.h  |5 ++---
 include/configs/bf537-srv1.h  |5 ++---
 lib_blackfin/board.c  |6 ++
 7 files changed, 51 insertions(+), 8 deletions(-)
 create mode 100644 cpu/blackfin/os_log.c
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] - add dns

[Mike Frysinger]

On Saturday 18 July 2009 20:27:00 Robin Getz wrote:
> On Sat 18 Jul 2009 18:11, Mike Frysinger pondered:
> > keep the modulus something with only 1 bit set so gcc will optimize into
> > a simple and operation.  probably add a comment about it too:
> > /* make src port a little random, but use something trivial to compute
> > */
>
> OK - So, this would give three different variations:
>
> net/sntp.c: SntpOurPort = 1 + (get_timer(0) % 4096);
> net/tftp.c: TftpOurPort = 1024 + (get_timer(0) % 3072);
> net/nfs.c:  NfsOurPort = 4096 + (get_ticks() % 3072);
>
> Does it make sense to have 4 different ones? (not to me)...
>
> Or something new & common in ./net.c:random_port()

i would make a new patch that adds a new random_port() function and converts 
existing consumers to that, and then have the dns code rely on that.

and you should adopt my implementation because the generated code is much much 
nicer than the others ;)

a quick google shows:
 - sntp - any non-zero source port is OK
 - tftp - "between 0 and 65535"
 - nfs - couldnt find anything, but i'm pretty sure there isnt one

get_ticks() and get_timer(0) are pretty much equivalent
-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] Please pull u-boot-mpc83xx.git

[Kim Phillips]

Hello Wolfgang D.,

I realize this is very last-minute, but converting 83xx PCI has been
overdue for a while now, and I'm expecting enough time to test before
the next release.  So, if there are no quarrels, please pull 83xx:

The following changes since commit d39041fcadb1231430201d298c31f6be03d654f7:
  Wolfgang Denk (1):
PATI board: fix compiler warnings

are available in the git repository at:

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

Kim Phillips (1):
  mpc83xx: convert all remaining boards over to 83XX_GENERIC_PCI

 board/freescale/mpc832xemds/Makefile |4 +-
 board/freescale/mpc832xemds/pci.c|  285 +++---
 board/freescale/mpc8349emds/Makefile |4 +-
 board/freescale/mpc8349emds/pci.c|6 +-
 board/freescale/mpc8349itx/Makefile  |4 +-
 board/freescale/mpc8349itx/pci.c |  361 +
 board/freescale/mpc8360emds/Makefile |4 +-
 board/freescale/mpc8360emds/pci.c|  287 +++
 board/freescale/mpc837xemds/Makefile |4 +-
 board/freescale/mpc837xemds/pci.c|4 +-
 board/freescale/mpc837xerdb/Makefile |4 +-
 board/freescale/mpc837xerdb/pci.c|4 +-
 board/sbc8349/Makefile   |4 +-
 board/sbc8349/pci.c  |  340 +++-
 board/tqc/tqm834x/Makefile   |4 +-
 board/tqc/tqm834x/pci.c  |  213 +++-
 include/configs/MPC832XEMDS.h|   32 ++--
 include/configs/MPC8349ITX.h |1 +
 include/configs/MPC8360EMDS.h|   28 ++--
 include/configs/TQM834x.h|   14 +-
 include/configs/sbc8349.h|1 +
 21 files changed, 342 insertions(+), 1266 deletions(-)

Thank you,

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

[U-Boot] [PATCH 2/2] document network driver framework

[Mike Frysinger]

Signed-off-by: Mike Frysinger 
---
Ben: some things to note:
- i adopted Jean's proposed naming scheme in the CONFIG section
- i deprecated calling the driver-specific entry point
  "xxx_initialization()" in favor of "xxx_register()" because the
  former is way too confusing with everyone also having "xxx_init()"

 doc/README.drivers.eth |  199 
 1 files changed, 199 insertions(+), 0 deletions(-)
 create mode 100644 doc/README.drivers.eth

diff --git a/doc/README.drivers.eth b/doc/README.drivers.eth
new file mode 100644
index 000..00b4eb1
--- /dev/null
+++ b/doc/README.drivers.eth
@@ -0,0 +1,199 @@
+---
+ Ethernet Driver Guide
+---
+
+The networking stack in Das U-Boot is designed for multiple network devices
+to be easily added and controlled at runtime.  This guide is meant for people
+who wish to review the net driver stack with an eye towards implementing your
+own ethernet device driver.  Here we will describe a new pseudo 'APE' driver.
+
+
+ CONFIG Options
+
+
+The common config defines your device should respect (if applicable):
+   CONFIG_MII  - configure in MII mode
+   CONFIG_RMII - configure in RMII mode
+
+   CONFIG_CMD_MII - support the MII command
+
+If you want to add config options specific to your driver, you should use the
+naming convention:
+   CONFIG_NET__
+For example, if the APE driver could operate in either 16bit or 32bit mode,
+there would probably be the option:
+   CONFIG_NET_APE_32BIT - operate in 32bit mode rather than 16bit default
+
+And to control whether your driver is even enabled, you should use:
+   CONFIG_SYS_NET_
+So the APE driver would look like:
+   CONFIG_SYS_NET_APE
+
+--
+ Driver Functions
+--
+
+All functions you will be implementing in this document have the return value
+meaning of 0 for success and non-zero for failure.
+
+ --
+  Register
+ --
+
+When U-Boot initializes, it will call the common function eth_initialize().
+This will in turn call the board-specific board_eth_init() (or if that fails,
+the cpu-specific cpu_eth_init()).  These board-specific functions can do random
+system handling, but ultimately they will call the driver-specific register
+function which in turn takes care of initializing that particular instance.
+
+Keep in mind that you should code the driver to avoid storing state in global
+data as someone might want to hook up two of the same devices to one board.  If
+the state is maintained as global data, it makes using both of those devices
+impossible.
+
+So the call graph at this stage would look something like:
+board_init()
+   eth_initialize()
+   board_eth_init() / cpu_eth_init()
+   driver_register()
+   initialize eth_device
+   eth_register()
+
+At this point in time, the only thing you need to worry about is the driver's
+register function.  The pseudo code would look something like:
+int ape_register(bd_t *bis, int iobase)
+{
+   struct ape_priv *priv;
+   struct eth_device *dev;
+
+   priv = malloc(sizeof(*priv));
+   if (priv == NULL)
+   return 1;
+
+   dev = malloc(sizeof(*dev));
+   if (dev == NULL) {
+   free(priv);
+   return 1;
+   }
+
+   /* setup whatever private state you need */
+
+   memset(dev, 0, sizeof(*dev));
+   sprintf(dev->name, "APE");
+
+   /* if your device has dedicated hardware storage for the
+* MAC, read it and initialize dev->enetaddr with it
+*/
+   ape_mac_read(dev->enetaddr);
+
+   dev->iobase = iobase;
+   dev->priv = priv;
+   dev->init = ape_init;
+   dev->halt = ape_halt;
+   dev->send = ape_send;
+   dev->recv = ape_recv;
+
+   eth_register(dev);
+
+#ifdef CONFIG_CMD_MII)
+   miiphy_register(dev->name, ape_mii_read, ape_mii_write);
+#endif
+
+   return 0;
+}
+
+The exact arguments needed to initialize your device are up to you.  If you
+need to pass more/less arguments, that's fine.  You should also add the
+prototype for your new register function to include/netdev.h.  You might notice
+that many drivers seem to use xxx_initialize() rather than xxx_register().
+This is the old naming convention and should be avoided as it causes confusion
+with the driver-specific init function.
+
+Other than locating the MAC address in dedicated hardware storage, you should
+not touch the hardware in anyway.  That step is handled in the driver-specific
+init function.  Remember that we are only registering the device here, we are
+not checking its state or doing random probing.
+
+ ---
+  Callbacks
+ ---
+
+Now that we've registered with the ethernet layer, we can start getting some
+real work done.  You will need four functions:
+ 

[U-Boot] [PATCH 1/2] net: rename NetRxPkt to NetRxPacket

[Mike Frysinger]

The net code is mostly consistent in using 'Packet' rather than 'Pkt', so
rename the minor detractor to follow suite.

Signed-off-by: Mike Frysinger 
---
 include/net.h |4 ++--
 net/bootp.c   |2 +-
 net/net.c |8 
 3 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/include/net.h b/include/net.h
index 5a1d36e..88a9513 100644
--- a/include/net.h
+++ b/include/net.h
@@ -331,8 +331,8 @@ extern IPaddr_t NetOurIP;   /* Our  
  IP addr (0 = unknown) */
 extern IPaddr_tNetServerIP;/* Server IP addr (0 = 
unknown) */
 extern volatile uchar * NetTxPacket;   /* THE transmit packet  
*/
 extern volatile uchar * NetRxPackets[PKTBUFSRX];/* Receive packets 
*/
-extern volatile uchar * NetRxPkt;  /* Current receive packet   
*/
-extern int NetRxPktLen;/* Current rx packet length 
*/
+extern volatile uchar * NetRxPacket;   /* Current receive packet   
*/
+extern int NetRxPacketLen; /* Current rx packet length 
*/
 extern unsignedNetIPID;/* IP ID (counting) 
*/
 extern uchar   NetBcastAddr[6];/* Ethernet boardcast address   
*/
 extern uchar   NetEtherNullAddr[6];
diff --git a/net/bootp.c b/net/bootp.c
index 77057c6..d5f9c4b 100644
--- a/net/bootp.c
+++ b/net/bootp.c
@@ -124,7 +124,7 @@ static void BootpCopyNetParams(Bootp_t *bp)
NetCopyIP(&tmp_ip, &bp->bp_siaddr);
if (tmp_ip != 0)
NetCopyIP(&NetServerIP, &bp->bp_siaddr);
-   memcpy (NetServerEther, ((Ethernet_t *)NetRxPkt)->et_src, 6);
+   memcpy (NetServerEther, ((Ethernet_t *)NetRxPacket)->et_src, 6);
 #endif
if (strlen(bp->bp_file) > 0)
copy_filename (BootFile, bp->bp_file, sizeof(BootFile));
diff --git a/net/net.c b/net/net.c
index 5637cf5..e215fd8 100644
--- a/net/net.c
+++ b/net/net.c
@@ -139,8 +139,8 @@ uchar   NetServerEther[6] = /* Boot server 
enet address */
{ 0, 0, 0, 0, 0, 0 };
 IPaddr_t   NetOurIP;   /* Our IP addr (0 = unknown)
*/
 IPaddr_t   NetServerIP;/* Server IP addr (0 = unknown) 
*/
-volatile uchar *NetRxPkt;  /* Current receive packet   
*/
-intNetRxPktLen;/* Current rx packet length 
*/
+volatile uchar *NetRxPacket;   /* Current receive packet   
*/
+intNetRxPacketLen; /* Current rx packet length 
*/
 unsigned   NetIPID;/* IP packet ID 
*/
 uchar  NetBcastAddr[6] =   /* Ethernet bcast address   
*/
{ 0xff, 0xff, 0xff, 0xff, 0xff, 0xff };
@@ -1122,8 +1122,8 @@ NetReceive(volatile uchar * inpkt, int len)
printf("packet received\n");
 #endif
 
-   NetRxPkt = inpkt;
-   NetRxPktLen = len;
+   NetRxPacket = inpkt;
+   NetRxPacketLen = len;
et = (Ethernet_t *)inpkt;
 
/* too small packet? */
-- 
1.6.3.3

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

Re: [U-Boot] [PATCH] - add dns

[Robin Getz]

On Sat 18 Jul 2009 18:11, Mike Frysinger pondered:
> On Saturday 18 July 2009 01:14:25 Robin Getz wrote:
> > +   DnsOurPort = 1 + (get_timer(0) % 4096);
> 
> 4096 port range seems kind of small.  i dont think the requests really need 
> to 
> be greater than 1.  not sure if services would get pissed about being 
> below the 1024 limit though, so this is probably better:
> 1024 + (get_timer() % 0x8000);

Sure.

> keep the modulus something with only 1 bit set so gcc will optimize into a 
> simple and operation.  probably add a comment about it too:
>   /* make src port a little random, but use something trivial to compute 
> */

OK - So, this would give three different variations:

net/sntp.c: SntpOurPort = 1 + (get_timer(0) % 4096);
net/tftp.c: TftpOurPort = 1024 + (get_timer(0) % 3072);
net/nfs.c:  NfsOurPort = 4096 + (get_ticks() % 3072);

Does it make sense to have 4 different ones? (not to me)...

Or something new & common in ./net.c:random_port()

Ben?

> > +void
> > +DnsStart(void)
> > +{
> > +   NetSetTimeout(DNS_TIMEOUT, DnsTimeout);
> > +   NetSetHandler(DnsHandler);
> > +   memset(NetServerEther, 0, 6);
> 
> is clearing the ether address really necessary ?  if so, why should the dns 
> code care about it ?

Nope - I can remove that...

> > +/* http://en.wikipedia.org/wiki/List_of_DNS_record_types */
> > +enum dns_query_type {
> > +   DNS_A_RECORD = 0x01,
> > +   DNS_CNAME_RECORD = 0x05,
> > +   DNS_MX_RECORD = 0x0f };
> 
> that last }; should be on a line by itself, and the last entry should still 
> have a comma at the end

Hmm - didn't notice that one from the orginal. Thanks 
(I'm surprised that checkpatch didn't complain).

Since there aren't any functionality differences - I'll send out a new version 
on 
Monday for Ben - since he is away anyway (unless someone else comments 
tomorrow).

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

Re: [U-Boot] [PATCH 3/3 v5] mpl: printing current stdio devices cleanup

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1242468896-5007-3-git-send-email-plagn...@jcrosoft.com> you wrote:
> curently the mpl's boards duplicate the printing current devices
> from common/console.c
> 
> use stdio_print_current_devices() instead
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> ---
>  board/mpl/common/common_util.c |   30 --
>  board/mpl/common/common_util.h |1 -
>  board/mpl/mip405/mip405.c  |3 ++-
>  board/mpl/pip405/pip405.c  |3 ++-
>  board/mpl/vcma9/vcma9.c|3 ++-
>  5 files changed, 6 insertions(+), 34 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
A dog always bit deepest on the veterinary hand.
- Terry Pratchett, _Wyrd Sisters_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] PATI board: fix compiler warnings

[Wolfgang Denk]

Fix these:
pati.c: In function 'checkboard':
pati.c:358: warning: pointer targets in passing argument 2 of 'getenv_r' differ 
in signedness
../common/flash.c: In function 'write_word':
../common/flash.c:824: warning: dereferencing type-punned pointer will break 
strict-aliasing rules
cmd_pati.c: In function 'do_pati':
cmd_pati.c:279: warning: 'value' may be used uninitialized in this function

Signed-off-by: Wolfgang Denk 
---
 board/mpl/common/flash.c  |   10 +++---
 board/mpl/pati/cmd_pati.c |2 +-
 board/mpl/pati/pati.c |4 ++--
 3 files changed, 10 insertions(+), 6 deletions(-)

diff --git a/board/mpl/common/flash.c b/board/mpl/common/flash.c
index 302d7a3..355608c 100644
--- a/board/mpl/common/flash.c
+++ b/board/mpl/common/flash.c
@@ -819,13 +819,17 @@ static FLASH_WORD_SIZE *read_val = (FLASH_WORD_SIZE 
*)0x20;
 
 static int write_word (flash_info_t *info, ulong dest, ulong data)
 {
-   volatile FLASH_WORD_SIZE *addr2 = (FLASH_WORD_SIZE *)(info->start[0]);
-   volatile FLASH_WORD_SIZE *dest2 = (FLASH_WORD_SIZE *)dest;
-   volatile FLASH_WORD_SIZE *data2 = (FLASH_WORD_SIZE *)&data;
+   volatile FLASH_WORD_SIZE *addr2 = (volatile FLASH_WORD_SIZE 
*)(info->start[0]);
+   volatile FLASH_WORD_SIZE *dest2 = (volatile FLASH_WORD_SIZE *)dest;
+   volatile FLASH_WORD_SIZE *data2;
ulong start;
+   ulong *data_p;
int flag;
int i;
 
+   data_p = &data;
+   data2 = (volatile FLASH_WORD_SIZE *)data_p;
+
/* Check if Flash is (sufficiently) erased */
if ((*((volatile FLASH_WORD_SIZE *)dest) &
(FLASH_WORD_SIZE)data) != (FLASH_WORD_SIZE)data) {
diff --git a/board/mpl/pati/cmd_pati.c b/board/mpl/pati/cmd_pati.c
index 0682323..740881e 100644
--- a/board/mpl/pati/cmd_pati.c
+++ b/board/mpl/pati/cmd_pati.c
@@ -276,7 +276,7 @@ static int pati_pci_eeprom_write(unsigned short offset, 
unsigned long addr, unsi
 static int pati_pci_eeprom_read(unsigned short offset, unsigned long addr, 
unsigned short size)
 {
int i;
-   unsigned short value;
+   unsigned short value = 0;
unsigned short *buffer =(unsigned short *)addr;
if((offset + size) > PATI_EEPROM_LAST_OFFSET) {
size = PATI_EEPROM_LAST_OFFSET - offset;
diff --git a/board/mpl/pati/pati.c b/board/mpl/pati/pati.c
index 8f23d2d..1b3b698 100644
--- a/board/mpl/pati/pati.c
+++ b/board/mpl/pati/pati.c
@@ -347,8 +347,8 @@ int last_stage_init (void)
 
 int checkboard (void)
 {
-   unsigned char s[50];
-   unsigned long reg;
+   char s[50];
+   ulong reg;
char rev;
int i;
 
-- 
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] Add inverted clock polarity support for Atmel LCD driver

[Anatolij Gustschin]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 18:56 Wed 15 Jul , Dimitar Dimitrov wrote:
...
>> --- a/drivers/video/atmel_lcdfb.c
>> +++ b/drivers/video/atmel_lcdfb.c
>> @@ -112,6 +112,9 @@ void lcd_ctrl_init(void *lcdbase)
>>  
>>  value |= panel_info.vl_sync;
>>  value |= (panel_info.vl_bpix << 5);
>> +#if defined(CONFIG_LCD_INVERTED_CLOCK)
>> +value |= ATMEL_LCDC_INVCLK_INVERTED;
>> +#endif
> NACK
>   do this throught the struct via vl_sync as in linux

actually the "vl_sync" is supposed to contain HSYNC and VSYNC
polarity flags and not the dot clock polarity. The Linux driver in
mainline uses var.sync for this purpose too, and doesn't set
inverted dot clock polarity at all.
This definition in struct vidinfo for Atmel LCD
/* LCD configuration register */
u_long vl_sync; /* Horizontal / vertical sync */
u_long vl_bpix; /* Bits per pixel, 0 = 1, 1 = 2, 2 = 4, 3 = 8,
 4 = 16 */
u_long vl_tft;  /* 0 = passive, 1 = TFT */

is confusing. If these fields are supposed to contain flags
for LCD configuration register LCDCON2 then we should define
only one "u_long lcdcon2" field containing all the flags/fields
for sync polarity, bpp, clock polarity, scan mode, display type,
interface width, LCDD, LCDDEN polarities, LCDDOTCLK mode and memory
ordering format. We are wasting tree u_longs here and are not even
able to use half of the possible settings for LCDCON2 register.
I would rather fix the struct vidinfo for Atmel LCD so that
people could set needed flags in the board code, e.g.:

vidinfo_t panel_info = {
...
lcdcon2:ATMEL_LCDC_INVLINE_INVERTED |
ATMEL_LCDC_INVFRAME_INVERTED |
ATMEL_LCDC_INVCLK_INVERTED;
...
}

I don't have the Atmel hardware to test/fix this change however.

Best regards,
Anatolij

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

Re: [U-Boot] [PATCH] NAND boot: fix nand_load overlap issue

[Wolfgang Denk]

Dear Scott,

In message <1244170414-4840-1-git-send-email-mingkai...@freescale.com> Mingkai 
Hu wrote:
> The code copy data from NAND flash block by block, so when
> the data length isn't a whole-number multiple of the block
> size, it will overlap the rest space.
> 
> Signed-off-by: Mingkai Hu 
> ---
>  nand_spl/nand_boot_fsl_elbc.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)


Can you please check the state of this patch? Thanks in advance.

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 X11 source code style is ATROCIOUS and should not be used  as  a
model."   - Doug Gwyn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Assigned a static SMI address to all UECs TBIPA address.

[Wolfgang Denk]

Dear Ben,

In message <1243958368-28613-1-git-send-email-richardretanu...@ruggedcom.com> 
Richard Retanubun wrote:
> It is set to 0x1F by default and can be overwritten on the board
> header file by defining CONFIG_UTBIPAR_INIT_TBIPA. This allows
> the CPU to simply "reserve" one SMI address instead of using
> a different one for each UEC.
> ---
>  drivers/qe/uec.c |   17 +
>  1 files changed, 9 insertions(+), 8 deletions(-)

Can you please check the state of this patch? Thanks in advance.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
There's a way out of any cage.
-- Captain Christopher Pike, "The Menagerie" ("The Cage"),
   stardate unknown.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] update nand.h to support address more than 0x80000000

[Wolfgang Denk]

Dear Scott Wood,

In message <20090602201923.ga4...@b07421-ec1.am.freescale.net> you wrote:
> On Tue, Jun 02, 2009 at 07:27:01PM +0800, adrian wen wrote:
> > Hi all,
> > 
> > I found a bug in nand.h which prevent UBOOT to supprt large NAND chip.
> > 
> > The bug description as below:
> > In the original implementation, we use a wrapper function in
> > nand.h to facilitate nand_base function usage in other files,
> > like cmd_nand.c, nand_util.c etc.
> > 
> > However, the wrapper in nand.h is using off_t which is long type.
> > If we pass a address like 0x8000, which is allowed by nand_base.c,
> > the wrapper would recognize it as a negative num. So we would get a
> > huge num when this parameter get into nand_base.c
> > 
> > Fix it by replacing off_t to loff_t type.
> > 
> > Signed-off-by: Lei Wen 
> 
> A substantially similar patch was posted here:
> http://lists.denx.de/pipermail/u-boot/2009-May/052847.html
> 
> I'm fine with this change, but it should also handle large erases.

What happened out of this? I see a question asked by Adrian, but I
cannot find a reply from you?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"May the forces of evil become confused on the way to your house."
- George Carlin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Using Uboot to communicate a PCI device.

[dwh]

Hi Darshan,

> 1. Since Octeon's u-boot has the capabilities of initialize
> Octeon's PCI (Assign bus address ranges used to configure
> devices found on the PCI bus)

Right. The host CPU can configure the PCI interface on the NP.

> Having said this, what all (info) i need to have from the
> PCI device (Winpath NP) so that i am able to bring it up.
> I mean do i need to have some device driver of NP so that
> i am able to read/write into its Config space/Memory space?

The host CPU must be able to issue configuration space
read/writes, since that is what it uses to setup devices.
The host CPU will generally also support memory and I/O
read/writes. The user manual will tell you how to generate
the configuration space read/write, whereas the memory map
configuration will generally determine whether a memory
or I/O transaction is generated. These questions are totally
independent of U-Boot and require that you read the user
manual - the trick is knowing what to look for - which you
now do.

> I am really sorry if my questions are too silly. I am
> new to u-boot and PCI hence such questions.

They're not silly, just inexperienced.

> Now let me answer the questions, you have asked me.
> *The host's U-Boot can initialize the PCI interfaces on the NPs, and then
> later your U-Boot 'NP boot' command (U-boot application) can use the PCI
> interface registers to move the window around while copying application
> code
> into the NP memory space. You would need to have access via PCI to NP
> control registers too, so that you can release the NP core from reset and
> allow it to boot from the application code your host just copied into its
> address space. Based on your current understanding of the processors, does
> any of this sound possible?
> *I am not able to apprehend the very first sentence you have quoted. The
> host's U-boot can initialize its own end of the PCI interface. How can it
> initialize the PCI interface of the NP? Please, can you give me more
> clarity on this?

Initialization of a PCI interface will require actions from both
the slave side (NP) of the bridge and on the host side. The
activity on the host side is standardized by the PCI spec, i.e.,
there is a standard sequence used to initialize PCI devices.
However, the configuration of the slave side of the NP PCI
interface needs to be performed to describe how many
base-address-registers (BARs) and what they point to.
For that, you need to read the user manual for the NP,
and look at the PCI initialization (its possible that its
hardcoded, but you'll have to find that out).

> You mention, "You would need to have access via PCI to NP
> control registers too, so that you can release the NP core
> from reset and allow it to boot from the application code
> your host just copied into its address space*.*"
> In order to execute such task, do i need a program code
> (NP device driver) present at my end (inside my U-boot's
> driver folder) so that i will be able to write an u-boot
> application('NP Boot')?

At some point you will have to write some code. But first,
you should be able to manually perform most of the operations
needed to boot an NP processor.

Once you figure that out, you can post an RFC
(request for comments) on how you plan to proceed so
others can provide feedback. Its quite possible that
once you know what you want to do, that something
already exists, or something similar that can
be generalized exists.

> *Do you have access to the source code for the NP bootloader
> so that you can implement both ends of the communication path?*
> Can i conclude after reading the above sentence written from
> you that i need to write some code (which involves modification
> in the NP bootloader) to complete the 'NP boot'  initiated
> from the other end?

Sure, its not magic. If you write a custom communications
protocol at one end, then you need to write the code at
the other end.

The board hardware engineer should have figured out how the
two devices were planning on communicating. Perhaps you are
lucky and that in addition to the PCI interfaces being
routed together, the serial ports on the cores are connected
(if the processors have such things). In that case, the
host might be able to control the slaves via serial commands.

You have not provided sufficient information to say much more.

> Also, can i conclude that in order to achieve my objective of Booting an
> NP(PCI device) from Octeon (PCI host) involves work at both the ends?

Maybe. Again, insufficient information.

> *Is there any documentation on the boards you are working on that is
> available online? At a minimum links to the Cavium and NP data sheets
> would be useful.*
> I am afraid such datasheets wont be available speaking details like PIN
> configuration etc.Check this link a primitive one ;-) (
> http://www.caviumnetworks.com/OCTEON-Plus_CN58XX.html)

- This isn't a user manual, its a block diagram and
  product request interface.
- What about the processors connected via

Re: [U-Boot] [PATCH 2/3 v5] console: unify printing current devices

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1242468896-5007-2-git-send-email-plagn...@jcrosoft.com> you wrote:
> create stdio_print_current_devices() for this purpose
> 
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> ---
>  common/console.c|   75 +++---
>  include/stdio_dev.h |1 +
>  2 files changed, 30 insertions(+), 46 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Hegel was right when he said that we learn from history that man  can
never learn anything from history.  - George Bernard Shaw
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Pull request: nand flash

[Wolfgang Denk]

Dear Scott Wood,

In message <20090718174036.ga30...@b07421-ec1.am.freescale.net> you wrote:
> The following changes since commit 462b1038738dd86f8dd70595f250ce792e90d244:
>   Wolfgang Denk (1):
> Merge branch 'master' of /home/wd/git/u-boot/custodians
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-nand-flash.git ..BRANCH.NOT.VERIFIED..
> 
> David Brownell (1):
>   Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646.
> 
> Kyungmin Park (1):
>   MTD: OneNAND: Increase the environment size to 4KiB
> 
> Scott Wood (2):
>   Remove legacy NAND and disk on chip code.
>   Remove legacy NAND and disk on chip references from boards.
> 
> Stefan Roese (3):
>   nand/ppc4xx: Move PPC4xx NAND driver to common NAND driver directory
>   nand: ndfc: Remove unnecessary #ifdef's
>   nand: Change NAND_MAX_OOBSIZE to 218 as needed for some 4k page devices
> 
> Valeriy Glushkov (1):
>   nand: fixed failed reads on corrected ECC errors in nand_util.c
> 
>  Makefile |2 -
>  README   |1 -
>  board/atc/atc.c  |7 -
>  board/bmw/bmw.c  |8 -
>  board/cpu86/cpu86.c  |7 -
>  board/cpu87/cpu87.c  |7 -
>  board/delta/nand.c   |4 -
>  board/esd/common/auto_update.c   |   50 -
>  board/g2000/g2000.c  |   15 -
>  board/gen860t/gen860t.c  |   12 -
>  board/mcc200/mcc200.c|7 -
>  board/mpl/common/common_util.c   |9 -
>  board/netphone/netphone.c|   16 -
>  board/netta/netta.c  |   15 -
>  board/netta2/netta2.c|   16 -
>  board/netvia/netvia.c|   15 -
>  board/omap2420h4/omap2420h4.c|   23 -
>  board/pcippc2/pcippc2.c  |5 -
>  board/pm520/pm520.c  |7 -
>  board/pm826/pm826.c  |7 -
>  board/pm828/pm828.c  |7 -
>  board/rbc823/rbc823.c|   12 -
>  board/samsung/smdk6400/smdk6400.c|   11 -
>  board/sixnet/sixnet.c|5 -
>  board/stxxtc/stxxtc.c|   16 -
>  board/svm_sc8xx/svm_sc8xx.c  |7 -
>  board/zylonite/nand.c|4 -
>  common/Makefile  |2 -
>  common/cmd_doc.c | 1644 
> --
>  common/cmd_jffs2.c   |   15 -
>  common/cmd_mtdparts.c|   10 -
>  common/cmd_nand.c|  412 
>  common/docecc.c  |  513 --
>  common/env_nand.c|4 -
>  common/env_onenand.c |   35 +-
>  cpu/ppc4xx/Makefile  |1 -
>  doc/README.nand  |3 +-
>  doc/feature-removal-schedule.txt |8 -
>  drivers/mtd/nand/Makefile|3 +-
>  drivers/mtd/nand/davinci_nand.c  |2 +-
>  drivers/mtd/nand/diskonchip.c|3 -
>  drivers/mtd/nand/nand_util.c |   10 +-
>  {cpu/ppc4xx => drivers/mtd/nand}/ndfc.c  |6 -
>  drivers/mtd/nand_legacy/Makefile |   48 -
>  drivers/mtd/nand_legacy/nand_legacy.c| 1610 -
>  fs/jffs2/jffs2_1pass.c   |   20 -
>  fs/jffs2/jffs2_nand_1pass.c  |4 -
>  include/common.h |3 -
>  include/configs/BMW.h|4 -
>  include/configs/CATcenter.h  |8 -
>  include/configs/CPU86.h  |   10 -
>  include/configs/CPU87.h  |4 -
>  include/configs/G2000.h  |   20 -
>  include/configs/GEN860T.h|   17 -
>  include/configs/MIP405.h |   10 -
>  include/configs/NETPHONE.h   |   87 --
>  include/configs/NETTA.h  |  100 --
>  include/configs/NETTA2.h |   87 --
>  include/configs/NETVIA.h |   79 --
>  include/configs/PCIPPC2.h|   12 -
>  include/configs/PCIPPC6.h|   12 -
>  include/configs/PIP405.h |4 -
>  include/configs/PM520.h  |   19 -
>  include/configs/PM826.h  |   14 -
>  include/configs/PM828.h  |   13 -
>  include/configs/PPChameleonEVB.h |   26 -
>  include/configs/RBC823.h |9 -
>  include/configs/SXNI855T.h   |   67 --
>  include/configs/TQM85xx.h|2 -
>  include/configs/VCMA9.h  |   38 -
>  include/configs/at91rm9200dk.h   |   30 -
>  include/configs/csb637.h |   32 -
>  include/configs/delta.h  |9 -
>  include/configs/m501sk.

Re: [U-Boot] Pull request: u-boot-video

[Anatolij Gustschin]

Wolfgang Denk wrote:
> In message <4a62378d.4040...@denx.de> you wrote:
>> Dear Wolfgang,
>>  
>> The following changes since commit 462b1038738dd86f8dd70595f250ce792e90d244:
>>   Wolfgang Denk (1):
>> Merge branch 'master' of /home/wd/git/u-boot/custodians
>>
>> are available in the git repository at:
>>
>>   git://git.denx.de/u-boot-video.git master
>>
>> Dimitar Dimitrov (1):
>>   Add inverted clock polarity support for Atmel LCD driver
>>
>>  README  |6 ++
>>  drivers/video/atmel_lcdfb.c |3 +++
>>  2 files changed, 9 insertions(+), 0 deletions(-)
> 
> Hm... Jean-Christophe just NAKed the patch.
> 
> Of course this falls into your bailiwick, so you have the last word,
> but I'd rather make sure you read Jean-Christophe's argument.

Yes, I have seen it too.

> Do you really want me to pull?

Not yet. I think I should discuss this whit him first how to solve
this, then I am going to send either another pull request or the
acknowledge to pull this patch.

Thanks,
Anatolij

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

Re: [U-Boot] Pull request: u-boot-i2c

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4a61882f.2000...@denx.de> you wrote:
> Hello Wolfgang,
> 
> The following changes since commit bfadb17f69c256196620c32164775f063a59c34f:
>   Anton Vorontsov (1):
> mpc83xx: MPC837xEMDS: Use hwconfig instead of pci_external_arbiter 
> variable
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> Alessandro Rubini (1):
>   cmd_i2c: bugfix: add missing brace
> 
>  common/cmd_i2c.c |6 +++---
>  1 files changed, 3 insertions(+), 3 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I had the rare misfortune of being one of the first people to try and
implement a PL/1 compiler. -- T. Cheatham
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

Dear Robin Getz,

In message <200907181713.25601.rg...@blackfin.uclinux.org> you wrote:
>
> It's a namespace - controls if a driver is compile in or not. 
> Should only be used in .config files, and Makefiles.

What's the difference between adding a driver and any other feature?

> Some (very few) already use it..

These can easily be fixed :-)

> > My personal way of thinking about such options is usually  CPU/archi-
> > tecture  first,  so I would probably chose CONFIG_OMAP24XX_I2C to en-
> > able/disable the I2C driver on a OMAP24XX based board, but  I  under-
> > stand  that there are reasons to prefer CONFIG_I2C_OMAP24XX as well -
> > let's see if there is a clear majority of opiniions...
> 
> If we are thinking of a "tree" type structure - it might make sense to
> start at the top? I guess the question is -- is it an I2C driver for 
> the OMAP24xx or a OMAP24xx driver for I2C?
> 
> Since the API is a I2C API - my thought it is an I2C driver, which happens
> to run on a specific SoC. The actual SoC doesn't really matter (and
> should be last) - so it is similar to the directory structure we have today.

That's why I said that I understand that there are reasons for such a
name.

> Then I can start sending patches for unused CONFIG_ from random config files,
> and no one will start complaining?

Probably.

> From what I can quickly tell - there seems to be about 472 different CONFIG_ 
> options in ./include/config that are not actually used anywhere in the master
> tree.

I guess lots of these is indeed garbage that can be removed without
anybody noticing it.

> > > I would think should be CONFIG_DRIVERS_PATA_BFIN
> > 
> > I dosagree, the "DRIVERS" part is just added line noise.
> 
> It's a name space - making sure it is differentiated from an option.

Yeah, and we end up with variable names that cannot be used any more
because they exceed the maximum line length.

> I think there needs to be more words - do you mean:
>   - hardware, CPU level? or
>   - hardware, SoC level? or 
>   - hardware, board level?

Hm... I don't see any real need for adding additional  characters  to
the  CONFIG_(SYS_)*  names  -  I  am  not  aware that we ever had any
problems because of name collisions.

> Personally - I don't think board level things should be CONFIG_SYS_, as
> these need to be switched around by board porters.
> 
> I guess we could back up a step and look at the users, and defined things
> as things that should be changed by:
>  - arch maintainers (Core/CPU specific)
>  - SoC maintainer (SoC specific)
>  - Board maintainer (PCB specific)
>  - End user of the above (changes options, but nothing from the above list?)

Frankly, this makes no sense to me. I have yet to see any such clear
split of roles and functions. When you bring up a new board, you
usually have to check everything.

The only split that made, and still makes, kind of sense to me is the
split into normal users (CONFIG_) versus "root" (CONFIG_SYS_) groups.

> I'm happy to write a patch - but I have a feeling what I think isn't what
> everyone else's opinion is...

It seems there are at least two sets, one containing you,  the  other
one  containing  me.  I  have no information about the cardinality of
each, though ;-)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.   - Bill Gates
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] - add dns

[Mike Frysinger]

On Saturday 18 July 2009 01:14:25 Robin Getz wrote:
> + DnsOurPort = 1 + (get_timer(0) % 4096);

4096 port range seems kind of small.  i dont think the requests really need to 
be greater than 1.  not sure if services would get pissed about being 
below the 1024 limit though, so this is probably better:
1024 + (get_timer() % 0x8000);

keep the modulus something with only 1 bit set so gcc will optimize into a 
simple and operation.  probably add a comment about it too:
/* make src port a little random, but use something trivial to compute 
*/

> +void
> +DnsStart(void)
> +{
> + NetSetTimeout(DNS_TIMEOUT, DnsTimeout);
> + NetSetHandler(DnsHandler);
> + memset(NetServerEther, 0, 6);

is clearing the ether address really necessary ?  if so, why should the dns 
code care about it ?

> +/* http://en.wikipedia.org/wiki/List_of_DNS_record_types */
> +enum dns_query_type {
> + DNS_A_RECORD = 0x01,
> + DNS_CNAME_RECORD = 0x05,
> + DNS_MX_RECORD = 0x0f };

that last }; should be on a line by itself, and the last entry should still 
have a comma at the end
-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] Pull request: u-boot-video

[Wolfgang Denk]

Dear Anatolij,

In message <4a62378d.4040...@denx.de> you wrote:
> Dear Wolfgang,
>  
> The following changes since commit 462b1038738dd86f8dd70595f250ce792e90d244:
>   Wolfgang Denk (1):
> Merge branch 'master' of /home/wd/git/u-boot/custodians
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-video.git master
> 
> Dimitar Dimitrov (1):
>   Add inverted clock polarity support for Atmel LCD driver
> 
>  README  |6 ++
>  drivers/video/atmel_lcdfb.c |3 +++
>  2 files changed, 9 insertions(+), 0 deletions(-)

Hm... Jean-Christophe just NAKed the patch.

Of course this falls into your bailiwick, so you have the last word,
but I'd rather make sure you read Jean-Christophe's argument.

Do you really want me to pull?

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're usually so busy thinking about what  happens  next  that  the
only  time they ever find out what is happening now is when they come
to look back on it. - Terry Pratchett, _Wyrd Sisters_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] Add support for Eukrea CPUAT91 SBC

[Eric Benard]

CPUAT91 is built around Atmel's AT91RM9200 and has up to 16MB of NOR
flash, up to 128MB of SDRAM, and includes a Micrel KS8721 PHY in RMII
mode.

v3 : fix coding style issues

Signed-off-by: Eric Benard 
---
 MAINTAINERS |4 +
 MAKEALL |3 +-
 Makefile|   12 ++
 board/eukrea/cpuat91/Makefile   |   50 
 board/eukrea/cpuat91/config.mk  |1 +
 board/eukrea/cpuat91/cpuat91.c  |   86 ++
 cpu/arm920t/at91rm9200/Makefile |5 +-
 cpu/arm920t/at91rm9200/ks8721.c |  242 +++
 include/configs/cpuat91.h   |  231 +
 include/ks8721.h|   78 +
 10 files changed, 709 insertions(+), 3 deletions(-)
 create mode 100644 board/eukrea/cpuat91/Makefile
 create mode 100644 board/eukrea/cpuat91/config.mk
 create mode 100644 board/eukrea/cpuat91/cpuat91.c
 create mode 100644 cpu/arm920t/at91rm9200/ks8721.c
 create mode 100644 include/configs/cpuat91.h
 create mode 100644 include/ks8721.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 575a7ec..ed73b25 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -515,6 +515,10 @@ Dirk Behme 
 
omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
 
+Eric Benard 
+
+   cpuat91 ARM920T
+
 Rishi Bhattacharya 
 
omap5912osk ARM926EJS
diff --git a/MAKEALL b/MAKEALL
index 020ff73..0e0b657 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -587,11 +587,12 @@ LIST_at91="   \
at91sam9260ek   \
at91sam9261ek   \
at91sam9263ek   \
-   at91sam9g10ek   \
+   at91sam9g10ek   \
at91sam9g20ek   \
at91sam9m10g45ek\
at91sam9rlek\
cmc_pu2 \
+   cpuat91 \
csb637  \
kb9202  \
meesc   \
diff --git a/Makefile b/Makefile
index 090e645..3b348d9 100644
--- a/Makefile
+++ b/Makefile
@@ -2683,6 +2683,18 @@ at91rm9200ek_config  :   unconfig
 cmc_pu2_config :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t cmc_pu2 NULL at91rm9200
 
+cpuat91_ram_config \
+cpuat91_config :   unconfig
+   @mkdir -p $(obj)include
+   @if [ "$(findstring _ram_,$@)" ] ; then \
+   echo "#define CONFIG_CPUAT91_RAM 1" >>$(obj)include/config.h ; \
+   $(XECHO) "... CPUAT91 configured for RAM" ; \
+   else \
+   echo "#define CONFIG_BOOTDELAY 1" >>$(obj)include/config.h ;\
+   $(XECHO) "... CPUAT91 configured for Flash" ;\
+   fi;
+   @$(MKCONFIG) -a cpuat91 arm arm920t cpuat91 eukrea at91rm9200
+
 csb637_config  :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t csb637 NULL at91rm9200
 
diff --git a/board/eukrea/cpuat91/Makefile b/board/eukrea/cpuat91/Makefile
new file mode 100644
index 000..08a90dc
--- /dev/null
+++ b/board/eukrea/cpuat91/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2003-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS  := cpuat91.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/eukrea/cpuat91/config.mk b/board/eukrea/cpuat91/config.mk
new file mode 100644
index 000..ef8dda0
--- /dev/null
+++ b/board/eukrea/cpuat91/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x21F0
diff --git a/board/eukrea/cpuat91/cpuat91.c b/board/eukrea/cpuat91/cpuat91.c
new file mode 100644
index 000..adb3a56
--- /dev/null
+++ b/board/eukrea/cpuat91/cpuat91.c
@@ -0,0 +1,86 @@
+/*
+ * (C) Copyright 2006

Re: [U-Boot] [PATCH 2/3] tools: mkimage (type=kwbimage) kirkwood boot image support

[Wolfgang Denk]

Dear Prafulla Wadaskar,

In message <1247967958-4446-2-git-send-email-prafu...@marvell.com> you wrote:
> For more details refer docs/README.kwbimage

...
> diff --git a/doc/README.kwbimage b/doc/README.kwbimage
> new file mode 100644
> index 000..b00a053
> --- /dev/null
> +++ b/doc/README.kwbimage
> @@ -0,0 +1,77 @@
> +-
> +Kirkwood Boot Image generation using mkimage
> +-
> +
> +This document describes the U-Boot feature as it
> +is implemented for the Kirkwood family of SoCs.
> +
> +The Kirkwood SoC's can boot directly from NAND FLASH,
> +SPI FLASH, SATA etc. using its internal bootRom support.
> +
> +for more details refer section 24.2 of Kirkwood functional specifications.
> +ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
> +
> +Commad syntax:
> +./tools/mkimage -n  \
> +-T kwbimage -a  -e  -d 
>  
> +
> +for ex.
> +./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
> +-T kwbimage -a 0x0060 -e 0x0060 -d u-boot.bin 
> u-boot.kwb
> +
> +kwimage support available with mkimage utility will generate kirkwood boot 
> image that can be flashed on the board nand/spi flash


Maximum line length exceeded. Please fix globally.


...
> +Author: Prafulla Wadaskar 
> +--
> +

Please do not add trailing empty lines.

> diff --git a/include/image.h b/include/image.h
> index f183757..ed94dda 100644
> --- a/include/image.h
> +++ b/include/image.h
> @@ -158,6 +158,7 @@
>  #define IH_TYPE_SCRIPT   6   /* Script file  
> */
>  #define IH_TYPE_FILESYSTEM   7   /* Filesystem Image (any type)  */
>  #define IH_TYPE_FLATDT   8   /* Binary Flat Device Tree Blob 
> */
> +#define IH_TYPE_KWBIMAGE 9   /* Boot Rom Image   
> */

Please s/Boot Rom Image/Kirkwood Boot Rom Image/ or similar.

> diff --git a/tools/kwbimage.c b/tools/kwbimage.c
> new file mode 100644
> index 000..06f256e
> --- /dev/null
> +++ b/tools/kwbimage.c
> ...
> +/*
> + * Generates 32 bit checksum
> + */
> +u32 kwbimage_checksum32(void *start, u32 len, u32 csum)
> +{
> + register u32 sum = csum;
> + volatile u32 *startp = (volatile u32 *)start;
> +
> + do {
> + sum += *startp;
> + startp++;
> + len -= sizeof(u32);
> + } while (len > 0);
> + return (sum);
> +}

This will fail if start is not 32bit aligned; if you can guarantee
that it is always aligned, then please pass a u32 pointer.

> +void kwdimage_set_ext_header(struct kwb_header *kwbhdr, char* fname) {
> + bhr_t *mhdr = &kwbhdr->kwb_hdr;
> + extbhr_t *exthdr = &kwbhdr->kwb_exthdr;
> + int fd = -1;
> + int lineno, i;
> + char *line = NULL;
> + char cmdstr[MAX_KWBCMD_LEN], datastr[MAX_KWBDATA_LEN];
> + size_t len = 0;
> +
> + exthdr->dramregsoffs = (u32)&exthdr->rcfg - (u32)mhdr;
> +
> + if ((fd = fopen(fname, "r")) == 0) {
> + fprintf (stderr, "Err: Can't open %s: %s\n",
> + fname, strerror(errno));
> + exit (EXIT_FAILURE);
> + }
> +
> + i = lineno = 0;
> + while ((getline(&line, &len, fd)) != -1) {
> + /* skip empty lines and lines staring with # */

s/staring/starting/

> + lineno++;
> + if (!(line[0] != '#' && strlen(line) != 1))
> + continue;

This is a bit simple-minded. This will for example fail on
DOS-formatted files, and for lines that contain only white space
(which still look "empty" to most users and are thus hard to spot). 

> + if (strlen(line) > (MAX_KWBCMD_LEN + MAX_KWBDATA_LEN)) {
> + printf("Err.. %s(line no %d) too long\n",

"Error: %s[%d] Line too long\n" ?

> diff --git a/tools/kwbimage.h b/tools/kwbimage.h
> new file mode 100644
> index 000..c54b701
> --- /dev/null
> +++ b/tools/kwbimage.h
> ...
> +/* typedefs */
> +typedef char s8;
> +typedef unsigned char u8;
> +
> +typedef int s32;
> +typedef unsigned int u32;
> +
> +typedef short s16;
> +typedef unsigned short u16;
> +
> +typedef long s64;
> +typedef unsigned long u64;

Please get rid of these.

> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index c5b593c..9a11071 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -24,6 +24,7 @@
>  
>  #include "mkimage.h"
>  #include 
> +#include "kwbimage.h"
>  
>  extern int errno;
>  
> @@ -251,7 +252,13 @@ NXTARG:  ;
>* write dummy header, to be fixed later
>*/
>   int hdr_size;
> - hdr_size = image_get_header_size ();
> +
> + if (opt_type == IH_TYPE_KWBIMAGE) {
> + hdr = kwbimage_get_header_ptr();
> + hdr_size = kwbimage_get_header_size ();
> + } else
> + hdr_size = image_get_header_size ();
> +
>   memset (hdr, 0, hdr_size);
>   if (write(ifd, hdr, hdr_size) != hdr_size) {
> 

[U-Boot] [PATCH v4 2/2] Add AT91SAM9260 to at91's lowlevel_init.S

[Eric Benard]

Needed for AT91SAM9260 NOR Boot on Eukrea's CPU9260.

Signed-off-by: Eric Benard 
---
 cpu/arm926ejs/at91/lowlevel_init.S |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cpu/arm926ejs/at91/lowlevel_init.S 
b/cpu/arm926ejs/at91/lowlevel_init.S
index 5ed518c..9962ae9 100644
--- a/cpu/arm926ejs/at91/lowlevel_init.S
+++ b/cpu/arm926ejs/at91/lowlevel_init.S
@@ -194,7 +194,7 @@ SMRDATA:
.word CONFIG_SYS_PIOD_PPUDR_VAL
.word (AT91_BASE_SYS + AT91_PIOD + PIO_ASR)
.word CONFIG_SYS_PIOD_PPUDR_VAL
-#elif defined(CONFIG_AT91SAM9261)
+#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261)
.word (AT91_BASE_SYS + AT91_PIOC + PIO_PDR)
.word CONFIG_SYS_PIOC_PDR_VAL1
.word (AT91_BASE_SYS + AT91_PIOC + PIO_PUDR)
-- 
1.6.0.4

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

[U-Boot] [PATCH v4 1/2] Add support for Eukrea CPU9260 SBC

[Eric Benard]

CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR
flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100
Ethernet PHY in RMII mode.

v4 : do the commit before generating/sending the patch ;-)
v3 : fix Makefile (run mkconfig after config.h configuration)

Signed-off-by: Eric Benard 
---
 MAINTAINERS|4 +
 MAKEALL|1 +
 Makefile   |   13 ++
 board/eukrea/cpu9260/Makefile  |   59 +++
 board/eukrea/cpu9260/config.mk |1 +
 board/eukrea/cpu9260/cpu9260.c |  211 +++
 board/eukrea/cpu9260/cpu9260_led.c |   46 +
 include/configs/cpu9260.h  |  335 
 8 files changed, 670 insertions(+), 0 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/cpu9260_led.c
 create mode 100644 include/configs/cpu9260.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 575a7ec..b8d701a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -515,6 +515,10 @@ Dirk Behme 
 
omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
 
+Eric Benard 
+
+   cpu9260 ARM926EJS (AT91SAM9260 SoC)
+
 Rishi Bhattacharya 
 
omap5912osk ARM926EJS
diff --git a/MAKEALL b/MAKEALL
index 020ff73..bdc80fa 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -592,6 +592,7 @@ LIST_at91=" \
at91sam9m10g45ek\
at91sam9rlek\
cmc_pu2 \
+   cpu9260 \
csb637  \
kb9202  \
meesc   \
diff --git a/Makefile b/Makefile
index 090e645..8c4178f 100644
--- a/Makefile
+++ b/Makefile
@@ -2813,6 +2813,19 @@ at91sam9rlek_config  :   unconfig
fi;
@$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91
 
+cpu9260_64m_config \
+cpu9260_config :   unconfig
+   @if [ "$(findstring _64m,$@)" ] ; then \
+   echo "#define CONFIG_SYS_SDRC_CR_VAL 
CONFIG_SYS_SDRC_CR_VAL_64MB" \
+   >>$(obj)include/config.h ; \
+   $(XECHO) "... CPU9260 with 64MB SDRAM" ; \
+   else \
+   echo "#define CONFIG_SYS_SDRC_CR_VAL 
CONFIG_SYS_SDRC_CR_VAL_128MB" \
+   >>$(obj)include/config.h ; \
+   $(XECHO) "... CPU9260 with 128MB SDRAM" ; \
+   fi;
+   @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91
+
 meesc_config   :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91
 
diff --git a/board/eukrea/cpu9260/Makefile b/board/eukrea/cpu9260/Makefile
new file mode 100644
index 000..5b1acdc
--- /dev/null
+++ b/board/eukrea/cpu9260/Makefile
@@ -0,0 +1,59 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop 
+# Lead Tech Design 
+# Ilko Iliev 
+#
+# (C) Copyright 2009
+# Eric Benard 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y += $(BOARD).o
+COBJS-y += $(BOARD)_led.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+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/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk
new file mode 100644
index 000..9ce161e
--- /dev/null
+++ b/board/eukrea/cpu9260/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x21f0
diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c
new file mode 100644
index 000..84707b6
--- /dev/null
+++ b/board/eukrea/cpu9260/cpu9260.c
@@ -0,0 +1,211 @@
+/*
+ * (C) Copyright 2007-2008

[U-Boot] [PATCH v3 1/2] Add support for Eukrea CPU9260 SBC

[Eric Benard]

CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR
flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100
Ethernet PHY in RMII mode.

v3 : fix Makefile (run mkconfig after config.h configuration)

Signed-off-by: Eric Benard 
---
 MAINTAINERS|4 +
 MAKEALL|1 +
 Makefile   |   13 ++
 board/eukrea/cpu9260/Makefile  |   59 +++
 board/eukrea/cpu9260/config.mk |1 +
 board/eukrea/cpu9260/cpu9260.c |  211 +++
 board/eukrea/cpu9260/cpu9260_led.c |   46 +
 include/configs/cpu9260.h  |  335 
 8 files changed, 670 insertions(+), 0 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/cpu9260_led.c
 create mode 100644 include/configs/cpu9260.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 575a7ec..b8d701a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -515,6 +515,10 @@ Dirk Behme 
 
omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
 
+Eric Benard 
+
+   cpu9260 ARM926EJS (AT91SAM9260 SoC)
+
 Rishi Bhattacharya 
 
omap5912osk ARM926EJS
diff --git a/MAKEALL b/MAKEALL
index 020ff73..bdc80fa 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -592,6 +592,7 @@ LIST_at91=" \
at91sam9m10g45ek\
at91sam9rlek\
cmc_pu2 \
+   cpu9260 \
csb637  \
kb9202  \
meesc   \
diff --git a/Makefile b/Makefile
index 090e645..7ae2bfe 100644
--- a/Makefile
+++ b/Makefile
@@ -2813,6 +2813,19 @@ at91sam9rlek_config  :   unconfig
fi;
@$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91
 
+cpu9260_64m_config \
+cpu9260_config :   unconfig
+   @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91
+   @if [ "$(findstring _64m,$@)" ] ; then \
+   echo "#define CONFIG_SYS_SDRC_CR_VAL 
CONFIG_SYS_SDRC_CR_VAL_64MB" \
+   >>$(obj)include/config.h ; \
+   $(XECHO) "... with 64MB SDRAM" ; \
+   else \
+   echo "#define CONFIG_SYS_SDRC_CR_VAL 
CONFIG_SYS_SDRC_CR_VAL_128MB" \
+   >>$(obj)include/config.h ; \
+   $(XECHO) "... with 128MB SDRAM" ; \
+   fi;
+
 meesc_config   :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91
 
diff --git a/board/eukrea/cpu9260/Makefile b/board/eukrea/cpu9260/Makefile
new file mode 100644
index 000..5b1acdc
--- /dev/null
+++ b/board/eukrea/cpu9260/Makefile
@@ -0,0 +1,59 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop 
+# Lead Tech Design 
+# Ilko Iliev 
+#
+# (C) Copyright 2009
+# Eric Benard 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y += $(BOARD).o
+COBJS-y += $(BOARD)_led.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+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/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk
new file mode 100644
index 000..9ce161e
--- /dev/null
+++ b/board/eukrea/cpu9260/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x21f0
diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c
new file mode 100644
index 000..84707b6
--- /dev/null
+++ b/board/eukrea/cpu9260/cpu9260.c
@@ -0,0 +1,211 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop 
+ * Lead Tech Design 
+ * Ilko Iliev 
+ *
+ * (C) Copyrigh

[U-Boot] [PATCH v3 2/2] Add AT91SAM9260 to at91's lowlevel_init.S

[Eric Benard]

Needed for AT91SAM9260 NOR Boot on Eukrea's CPU9260.

Signed-off-by: Eric Benard 
---
 cpu/arm926ejs/at91/lowlevel_init.S |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cpu/arm926ejs/at91/lowlevel_init.S 
b/cpu/arm926ejs/at91/lowlevel_init.S
index 5ed518c..9962ae9 100644
--- a/cpu/arm926ejs/at91/lowlevel_init.S
+++ b/cpu/arm926ejs/at91/lowlevel_init.S
@@ -194,7 +194,7 @@ SMRDATA:
.word CONFIG_SYS_PIOD_PPUDR_VAL
.word (AT91_BASE_SYS + AT91_PIOD + PIO_ASR)
.word CONFIG_SYS_PIOD_PPUDR_VAL
-#elif defined(CONFIG_AT91SAM9261)
+#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261)
.word (AT91_BASE_SYS + AT91_PIOC + PIO_PDR)
.word CONFIG_SYS_PIOC_PDR_VAL1
.word (AT91_BASE_SYS + AT91_PIOC + PIO_PUDR)
-- 
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 1/3] tools: mkimage: hdr_size used to facilitate customized support

[Wolfgang Denk]

Dear Prafulla Wadaskar,

In message <1247967958-4446-1-git-send-email-prafu...@marvell.com> you wrote:
> hdr_size variable is initialized
> at the start of image creation algorithm instead of reading it each time.
> This facilitate to use the common code for other image type implementations
> for ex. kwbimage

Hm... I have no idea what you are trying to do, or why. You are aware
that image_get_header_size()  is  a  static  inline,  returning  just
"sizeof (image_header_t)"?

As far as the context of mkimage goes, you could as well consider it a
constant.

> Signed-off-by: Prafulla Wadaskar 
> ---
>  tools/mkimage.c |   18 --
>  1 files changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/tools/mkimage.c b/tools/mkimage.c
> index 967fe9a..c5b593c 100644
> --- a/tools/mkimage.c
> +++ b/tools/mkimage.c
> @@ -250,9 +250,10 @@ NXTARG:  ;
>*
>* write dummy header, to be fixed later
>*/
> - memset (hdr, 0, image_get_header_size ());
> -
> - if (write(ifd, hdr, image_get_header_size ()) != image_get_header_size 
> ()) {
> + int hdr_size;

We don't allow variable declarations in the middle of the code.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
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

Re: [U-Boot] [PATCH 3/3] Kirkwood: Sheevaplug: kwimage configuration

[Jean-Christophe PLAGNIOL-VILLARD]

> +
> +# Boot Media configurations
> +BOOT_FROMnand
> +NAND_ECC_MODEdefault
> +NAND_PAGE_SIZE   0x0800
> +
> +# SOC registers configuration for initial values using bootrom header 
> extension
> +# Maximum KWBIMAGE_MAX_CONFIG configurations allowed
> +
> +# Configure RGMII-0 interface pad voltage to 1.8V
> +0xFFD100e0 0x1b1b1b9b
> +# DRAM Configuration
> +0xFFD01400 0x43000c30
could you give more details about the configs

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

Re: [U-Boot] [PATCH 2/3] tools: mkimage (type=kwbimage) kirkwood boot image support

[Jean-Christophe PLAGNIOL-VILLARD]

On 07:15 Sun 19 Jul , Prafulla Wadaskar wrote:
> For more details refer docs/README.kwbimage
> 
> Signed-off-by: Prafulla Wadaskar 
> ---
>  Makefile|5 ++
>  common/image.c  |1 +
>  doc/README.kwbimage |   77 ++
>  include/image.h |1 +
>  tools/Makefile  |1 +
>  tools/kwbimage.c|  181 
> +++
>  tools/kwbimage.h|  105 +
>  tools/mkimage.c |   23 ++-
>  8 files changed, 393 insertions(+), 1 deletions(-)
>  create mode 100644 doc/README.kwbimage
>  create mode 100644 tools/kwbimage.c
>  create mode 100644 tools/kwbimage.h
> 
> diff --git a/Makefile b/Makefile
> index 55fc2a3..b9e45ed 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -339,6 +339,10 @@ $(obj)u-boot.img:$(obj)u-boot.bin
>   sed -e 's/"[ ]*$$/ for $(BOARD) board"/') \
>   -d $< $@
>  
> +$(obj)u-boot.kwb:$(obj)u-boot.bin
> + ./tools/mkimage -n ./board/$(BOARDDIR)/kwbimage.cfg \
> + -T kwbimage -a $(TEXT_BASE) -e $(TEXT_BASE) -d $< $@
It will be better to make it a few more generic (and btw fix the out of tree
support) as this
MKIMAGE = $(OBJTREE)/tools/mkimage

$(obj)u-boot.kwb:   $(obj)u-boot.bin
$(MKIMAGE) -n $(KWD_CONFIG) -T kwbimage -a $(TEXT_BASE) \
-e $(TEXT_BASE) -d $< $@

and in the board config.mk or soc anyother config.mk
KWD_CONFIG = $(SRCTREE)/board/$(BOARDDIR)/kwbimage.cfg

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

Re: [U-Boot] [RFC] CONFIG naming convetion

[Robin Getz]

On Sat 18 Jul 2009 11:52, Jean-Christophe PLAGNIOL-VILLARD pondered:
> On 11:15 Sat 18 Jul , Robin Getz wrote:
> > It doesn't appear very "system" oriented to me...
> it's as we had reorganise the drivers file place as example or
> the common Makefile and continue to do it eveyday (take a look on Peter e-mail
> about arch dir)
> > 
> > It would be nice to come up with some list of namespaces, and what they
> > they should be used for...
> > 
> > For example, should it be:
> > CONFIG_DRIVER_OMAP24XX_I2C
> > or
> > CONFIG_SYS_I2C_DRIVER_OMAP24XX
> > or
> > CONFIG_DRIVER_I2C_OMAP24XX
>
> DRIVER is really un-nessary IMHO

It doesn't cost extra $ to keep 6 letters - and makes it alot more clear
about what it does.

I understand the point about having really _long_ names, and personally
think things like "ThisVariableIsATemporaryCounter" are brain dead, but
I don't think we have hit that yet with CONFIG_ yet.

We already have lots (419) that are over 30 chars, and some over 40!

40 CONFIG_SYS_TFTP_BLINK_STATUS_ON_DATA_IN
41 CONFIG_SYS_MONAHANS_TURBO_RUN_MODE_RATIO
41 CONFIG_SYS_MPC8220_SYSPLL_VCO_MULTIPLIER
42 CONFIG_SYS_PCI_SUBSYS_DEVICEID_NONMONARCH

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

[U-Boot] [PATCH] cmd_flash.c: fix warning: unused variable 'addr_first'/'addr_last'

[Wolfgang Denk]

Signed-off-by: Wolfgang Denk 
---
 common/cmd_flash.c |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/common/cmd_flash.c b/common/cmd_flash.c
index 9f27ab0..bc651fa 100644
--- a/common/cmd_flash.c
+++ b/common/cmd_flash.c
@@ -467,18 +467,18 @@ int do_protect (cmd_tbl_t *cmdtp, int flag, int argc, 
char *argv[])
flash_info_t *info;
ulong bank;
int i, n, sect_first, sect_last;
-#endif /* CONFIG_SYS_NO_FLASH */
ulong addr_first, addr_last;
-   int p;
+#endif /* CONFIG_SYS_NO_FLASH */
 #if defined(CONFIG_CMD_JFFS2) && defined(CONFIG_CMD_MTDPARTS)
struct mtd_device *dev;
struct part_info *part;
u8 dev_type, dev_num, pnum;
 #endif
-   int rcode = 0;
 #ifdef CONFIG_HAS_DATAFLASH
int status;
 #endif
+   int p;
+   int rcode = 0;
 
if (argc < 3) {
cmd_usage(cmdtp);
-- 
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 03/03 v3] Add support for Olimex SAM9-L9260 SBC

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:00 Wed 15 Jul , Dimitar Dimitrov wrote:
> The SAM9-L9260 board support is based on code for AT91SAM9260EK. Networking
> is missing and will be added after the MACB support for AT91 boards is
> fixed to comply with U-Boot guide-lines.
> 
> Signed-off-by: Dimitar Dimitrov 
> ---
same as 9261
could you regenerate it with
git format-patch -M -B -C 
>  MAINTAINERS  |1 +
>  MAKEALL  |1 +
>  Makefile |   17 +++
>  board/olimex/sam9_l9260/Makefile |   56 +
>  board/olimex/sam9_l9260/config.mk|1 +
>  board/olimex/sam9_l9260/led.c|   41 +++
>  board/olimex/sam9_l9260/partition.c  |   40 +++
>  board/olimex/sam9_l9260/sam9_l9260.c |  111 ++
>  include/configs/sam9_l9260.h |  214 
> ++

> +
> +#define CONFIG_ARM926EJS 1   /* This is an ARM926EJS Core*/
> +
> +#define AT91_CPU_NAME"AT91SAM9260"
no-need please remove
> +#define CONFIG_AT91SAM9260   1   /* It's an Atmel AT91SAM9260 SoC*/
> +#define CONFIG_SAM9_L92601   /* on an SAM9_L9260 Board   */
> +
> +#define CONFIG_ARCH_CPU_INIT
> +#undef CONFIG_USE_IRQ/* we don't need IRQ/FIQ stuff  
> */
> +
> +#define CONFIG_CMDLINE_TAG   1   /* enable passing of ATAGs  */
> +#define CONFIG_SETUP_MEMORY_TAGS 1
> +#define CONFIG_INITRD_TAG1
> +
> +#define CONFIG_SKIP_LOWLEVEL_INIT
> +#define CONFIG_SKIP_RELOCATE_UBOOT
> +
> +/*
> + * Hardware drivers
> + */
> +#define CONFIG_ATMEL_USART   1
> +#undef CONFIG_USART0
> +#undef CONFIG_USART1
> +#undef CONFIG_USART2
> +#define CONFIG_USART31   /* USART 3 is DBGU */
> +
> +/* LED */
> +#define CONFIG_AT91_LED
> +#define  CONFIG_RED_LED  AT91_PIN_PA9/* this is the power 
> led */
> +#define  CONFIG_GREEN_LEDAT91_PIN_PA6/* this is the user led 
> */
please fix the indent
> +
> +#define CONFIG_BOOTDELAY 3
> +
> +/*
> + * BOOTP options
> + */
> +#define CONFIG_BOOTP_BOOTFILESIZE1
> +#define CONFIG_BOOTP_BOOTPATH1
> +#define CONFIG_BOOTP_GATEWAY 1
> +#define CONFIG_BOOTP_HOSTNAME1

> +
> +#define CONFIG_BAUDRATE  115200
> +#define CONFIG_SYS_BAUDRATE_TABLE{115200 , 19200, 38400, 57600, 9600 }
> +
> +#define CONFIG_SYS_PROMPT"U-Boot> "
> +#define CONFIG_SYS_CBSIZE256
> +#define CONFIG_SYS_MAXARGS   16
> +#define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + 
> sizeof(CONFIG_SYS_PROMPT) + 16)
> +#define CONFIG_SYS_LONGHELP  1
> +#define CONFIG_CMDLINE_EDITING   1
> +
> +#define ROUND(A, B)  (((A) + (B)) & ~((B) - 1))
no-need please remove
> +/*
> + * Size of malloc() pool
> + */
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 02/03 v3] Add support for Olimex SAM9-L9261 SBC

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:58 Wed 15 Jul , Dimitar Dimitrov wrote:
> The SAM9-L9261 board support is based on code for AT91SAM9261EK. Networking
> is missing and will be added after the DM9000 support for AT91 boards is
> fixed to comply with U-Boot guide-lines.
> ---
this patch look at 80% similar as the at91sam9261ek

could you regenerate it with
git format-patch -M -B -C
>  MAINTAINERS  |3 +
>  MAKEALL  |1 +
>  Makefile |   17 +++
>  board/olimex/sam9_l9261/Makefile |   56 
>  board/olimex/sam9_l9261/config.mk|1 +
>  board/olimex/sam9_l9261/led.c|   43 +++
>  board/olimex/sam9_l9261/partition.c  |   40 ++
>  board/olimex/sam9_l9261/sam9_l9261.c |  214 +++
>  include/configs/sam9_l9261.h |  230 
> ++
>  tools/Makefile   |3 +
>  tools/logos/olimex.bmp   |  Bin 0 -> 27510 bytes
>  11 files changed, 608 insertions(+), 0 deletions(-)
>  create mode 100644 board/olimex/sam9_l9261/Makefile
>  create mode 100644 board/olimex/sam9_l9261/config.mk
>  create mode 100644 board/olimex/sam9_l9261/led.c
>  create mode 100644 board/olimex/sam9_l9261/partition.c
>  create mode 100644 board/olimex/sam9_l9261/sam9_l9261.c
>  create mode 100644 include/configs/sam9_l9261.h
>  create mode 100644 tools/logos/olimex.bmp
> 

> +
> +/* - 
> */
> +/*
> + * Miscelaneous platform dependent initialisations
> + */
> +
why don't you configure the dm9000 SMC?

> +
> +/* ARM asynchronous clock */
> +#define AT91_CPU_NAME"AT91SAM9261"
no-need please remove
> +#define AT91_MAIN_CLOCK  18432000/* 18.432 MHz crystal */
> +#define CONFIG_SYS_HZ1000
> +
> +#define CONFIG_ARM926EJS 1   /* This is an ARM926EJS Core*/
> +#define CONFIG_AT91SAM9261   1   /* It's an Atmel AT91SAM9261 SoC*/
> +#define CONFIG_SAM9_L92611   /* on an SAM9_L9261 Board   */
> +#define CONFIG_ARCH_CPU_INIT
> +#undef CONFIG_USE_IRQ/* we don't need IRQ/FIQ stuff  
> */
> +
> +#define CONFIG_CMDLINE_TAG   1   /* enable passing of ATAGs  */
> +#define CONFIG_SETUP_MEMORY_TAGS 1
> +#define CONFIG_INITRD_TAG1
> +
> +#define CONFIG_SKIP_LOWLEVEL_INIT
> +#define CONFIG_SKIP_RELOCATE_UBOOT
> +
> +/*
> + * Hardware drivers
> + */
> +#define CONFIG_ATMEL_USART   1
> +#undef CONFIG_USART0
> +#undef CONFIG_USART1
> +#undef CONFIG_USART2
> +#define CONFIG_USART31   /* USART 3 is DBGU */
> +
> +/* LCD */
> +#define CONFIG_LCD   1
> +#define LCD_BPP  LCD_COLOR8
> +#define CONFIG_LCD_LOGO  1
> +#undef LCD_TEST_PATTERN
> +#define CONFIG_LCD_INFO  1
> +#define CONFIG_LCD_INFO_BELOW_LOGO   1
> +#define CONFIG_LCD_INVERTED_CLOCK1
> +#define CONFIG_SYS_WHITE_ON_BLACK1
> +#define CONFIG_ATMEL_LCD 1
> +#define CONFIG_ATMEL_LCD_BGR555  1
> +#define CONFIG_SYS_CONSOLE_IS_IN_ENV 1
> +
> +/* LED */
> +#define CONFIG_AT91_LED
> +#define  CONFIG_RED_LED  AT91_PIN_PA23   /* this is the power 
> led */
> +#define  CONFIG_GREEN_LEDAT91_PIN_PA13   /* this is the user1 
> led */
> +#define  CONFIG_YELLOW_LED   AT91_PIN_PA14   /* this is the user2 
> led */
please fix the indent
> +
> +#define CONFIG_BOOTDELAY 3
> +
> +/*
> + * BOOTP options
> + */
> +#define CONFIG_BOOTP_BOOTFILESIZE1
> +#define CONFIG_BOOTP_BOOTPATH1
> +#define CONFIG_BOOTP_GATEWAY 1
> +#define CONFIG_BOOTP_HOSTNAME1
> +

> +
> +#define CONFIG_BAUDRATE  115200
> +#define CONFIG_SYS_BAUDRATE_TABLE{115200 , 19200, 38400, 57600, 9600 }
> +
> +#define CONFIG_SYS_PROMPT"U-Boot> "
> +#define CONFIG_SYS_CBSIZE256
> +#define CONFIG_SYS_MAXARGS   16
> +#define CONFIG_SYS_PBSIZE(CONFIG_SYS_CBSIZE + 
> sizeof(CONFIG_SYS_PROMPT) + 16)
> +#define CONFIG_SYS_LONGHELP  1
> +#define CONFIG_CMDLINE_EDITING   1
> +
> +#define ROUND(A, B)  (((A) + (B)) & ~((B) - 1))
no-need please remove
> +/*
> + * Size of malloc() pool
> + */
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Alessandro Rubini]

>> So, with the current code base, you can't autodetect ram size on the
>> atmel 926x.
> 
> Argh. So this should be fixed.

Yes.

> Other architectures (like PPC) do all  this  in  C.  This  should  be
> possible  on  ARM,  too.

Everything is possible. I fear it's not trivial to make a generic ARM
implementation, since each platform has its own way to bring up stuff.

> Who is going to attack this - you, Alessandro?

I'm going to do it for 9263 next week, for a project I'm following.
Then I'll be glad to study the general situation and see if I can
suggest anything useful.

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

Re: [U-Boot] [RFC] CONFIG naming convetion

[Robin Getz]

On Sat 18 Jul 2009 13:50, Wolfgang Denk pondered:
> Dear Robin Getz,
> 
> In message <200907181115.26404.rg...@blackfin.uclinux.org> you wrote:
> >
> > It would be nice to come up with some list of namespaces, and what they
> > they should be used for...
> 
> Agreed.

Excellent - a common goal :)

> > For example, should it be:
> > CONFIG_DRIVER_OMAP24XX_I2C
> > or
> > CONFIG_SYS_I2C_DRIVER_OMAP24XX
> > or
> > CONFIG_DRIVER_I2C_OMAP24XX
> 
> Well, the difference between CONFIG_ and CONFIG_SYS_ is well-defined.
> 
> And the "DRIVER_" part makes not much sense to me in any of the
> examples above. 

It's a namespace - controls if a driver is compile in or not. 
Should only be used in .config files, and Makefiles.

Some (very few) already use it..

./drivers/serial/Makefile:COBJS-$(CONFIG_DRIVER_S3C4510_UART) += s3c4510b_uart.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_3C589) += 3c589.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_AX88180) += ax88180.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_CS8900) += cs8900.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_DM9000) += dm9000x.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_KS8695ETH) += ks8695eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_LAN91C96) += lan91c96.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NE2000) += ne2000.o ne2000_base.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_AX88796L) += ax88796.o 
ne2000_base.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NETARMETH) += netarm_eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NS7520_ETHERNET) += ns7520_eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_NS9750_ETHERNET) += ns9750_eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_RTL8019) += rtl8019.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_S3C4510_ETH) += s3c4510b_eth.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_SMC9) += smc9.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_SMC911X) += smc911x.o
./drivers/net/Makefile:COBJS-$(CONFIG_DRIVER_TI_EMAC) += davinci_emac.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP34XX_I2C) += omap24xx_i2c.o
./drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_S3C24X0_I2C) += s3c24x0_i2c.o
./drivers/mtd/Makefile:COBJS-$(CONFIG_FLASH_CFI_DRIVER) += cfi_flash.o
./drivers/mtd/nand/Makefile:COBJS-$(CONFIG_DRIVER_NAND_BFIN) += bfin_nand.o
./board/micronas/vct/Makefile:COBJS-$(CONFIG_DRIVER_SMC911X) += ebi_smc911x.o 
smc_eeprom.o
./cpu/arm926ejs/davinci/Makefile:COBJS-$(CONFIG_DRIVER_TI_EMAC) += lxt972.o 
dp83848.o

> My personal way of thinking about such options is usually  CPU/archi-
> tecture  first,  so I would probably chose CONFIG_OMAP24XX_I2C to en-
> able/disable the I2C driver on a OMAP24XX based board, but  I  under-
> stand  that there are reasons to prefer CONFIG_I2C_OMAP24XX as well -
> let's see if there is a clear majority of opiniions...

If we are thinking of a "tree" type structure - it might make sense to
start at the top? I guess the question is -- is it an I2C driver for 
the OMAP24xx or a OMAP24xx driver for I2C?

Since the API is a I2C API - my thought it is an I2C driver, which happens
to run on a specific SoC. The actual SoC doesn't really matter (and
should be last) - so it is similar to the directory structure we have today.

> > Again - which is only used in one place:
> > drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
> > include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C
> > 
> > Which is fine - since it is a driver, which I'm sure that people out of 
> > tree use.
> 
> Well, if only out-of-tree ports use it, it probably should never have
> been added in the first place.

Then I can start sending patches for unused CONFIG_ from random config files,
and no one will start complaining?

>From what I can quickly tell - there seems to be about 472 different CONFIG_ 
options in ./include/config that are not actually used anywhere in the master
tree.

> > I would think should be CONFIG_DRIVERS_PATA_BFIN
> 
> I dosagree, the "DRIVERS" part is just added line noise.

It's a name space - making sure it is differentiated from an option.

As you pointed out - this is what exists in the README today. (which
I have read, but gained no clarity from it)...

===
* Configuration _OPTIONS_:
  These are selectable by the user and have names beginning with
  "CONFIG_".

* Configuration _SETTINGS_:
  These depend on the hardware etc. and should not be meddled with if
  you don't know what you're doing; they have names beginning with
  "CONFIG_SYS_".
===

I think there needs to be more words - do you mean:
  - hardware, CPU level? or
  - hardware, SoC level? or 
  - hardware, board level?

Personally - I don't think board level things should be CONFIG_SYS_, as
these need to be switched around by 

Re: [U-Boot] [PATCH] Add inverted clock polarity support for Atmel LCD driver

[Jean-Christophe PLAGNIOL-VILLARD]

On 18:56 Wed 15 Jul , Dimitar Dimitrov wrote:
> This is my third try for Olimex SAM9-L9260/61 board support patches. 
> 
> Here follows the first patch.
> ---
> 
> Boards utilizing the Atmel LCD driver can now specify that the LCD clock must
> be inverted by defining the macro CONFIG_LCD_INVERTED_CLOCK.
> ---
>  README  |5 +
>  drivers/video/atmel_lcdfb.c |3 +++
>  2 files changed, 8 insertions(+), 0 deletions(-)
> 
> diff --git a/README b/README
> index de700bd..d7c0afe 100644
> --- a/README
> +++ b/README
> @@ -1063,6 +1063,11 @@ The following options need to be configured:
>   Normally display is black on white background; define
>   CONFIG_SYS_WHITE_ON_BLACK to get it inverted.
>  
> + CONFIG_LCD_INVERTED_CLOCK
> + Define this if your LCD needs inverted clock polarity. Note
> + that this feature will work only if the selected LCD driver 
> + and hardware controller support it.
> +
>  - Splash Screen Support: CONFIG_SPLASH_SCREEN
>  
>   If this option is set, the environment is checked for
> diff --git a/drivers/video/atmel_lcdfb.c b/drivers/video/atmel_lcdfb.c
> index db86763..d3e988e 100644
> --- a/drivers/video/atmel_lcdfb.c
> +++ b/drivers/video/atmel_lcdfb.c
> @@ -112,6 +112,9 @@ void lcd_ctrl_init(void *lcdbase)
>  
>   value |= panel_info.vl_sync;
>   value |= (panel_info.vl_bpix << 5);
> +#if defined(CONFIG_LCD_INVERTED_CLOCK)
> + value |= ATMEL_LCDC_INVCLK_INVERTED;
> +#endif
NACK
do this throught the struct via vl_sync as in linux

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

[U-Boot] Pull request: u-boot-video

[Anatolij Gustschin]

Dear Wolfgang,
 
The following changes since commit 462b1038738dd86f8dd70595f250ce792e90d244:
  Wolfgang Denk (1):
Merge branch 'master' of /home/wd/git/u-boot/custodians

are available in the git repository at:

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

Dimitar Dimitrov (1):
  Add inverted clock polarity support for Atmel LCD driver

 README  |6 ++
 drivers/video/atmel_lcdfb.c |3 +++
 2 files changed, 9 insertions(+), 0 deletions(-)

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

[U-Boot] [PATCH 2/3] tools: mkimage (type=kwbimage) kirkwood boot image support

[Prafulla Wadaskar]

For more details refer docs/README.kwbimage

Signed-off-by: Prafulla Wadaskar 
---
 Makefile|5 ++
 common/image.c  |1 +
 doc/README.kwbimage |   77 ++
 include/image.h |1 +
 tools/Makefile  |1 +
 tools/kwbimage.c|  181 +++
 tools/kwbimage.h|  105 +
 tools/mkimage.c |   23 ++-
 8 files changed, 393 insertions(+), 1 deletions(-)
 create mode 100644 doc/README.kwbimage
 create mode 100644 tools/kwbimage.c
 create mode 100644 tools/kwbimage.h

diff --git a/Makefile b/Makefile
index 55fc2a3..b9e45ed 100644
--- a/Makefile
+++ b/Makefile
@@ -339,6 +339,10 @@ $(obj)u-boot.img:  $(obj)u-boot.bin
sed -e 's/"[ ]*$$/ for $(BOARD) board"/') \
-d $< $@
 
+$(obj)u-boot.kwb:  $(obj)u-boot.bin
+   ./tools/mkimage -n ./board/$(BOARDDIR)/kwbimage.cfg \
+   -T kwbimage -a $(TEXT_BASE) -e $(TEXT_BASE) -d $< $@
+
 $(obj)u-boot.sha1: $(obj)u-boot.bin
$(obj)tools/ubsha1 $(obj)u-boot.bin
 
@@ -3638,6 +3642,7 @@ clobber:  clean
@rm -f $(OBJS) $(obj)*.bak $(obj)ctags $(obj)etags $(obj)TAGS \
$(obj)cscope.* $(obj)*.*~
@rm -f $(obj)u-boot $(obj)u-boot.map $(obj)u-boot.hex $(ALL)
+   @rm -f $(obj)u-boot.kwb
@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
@rm -f $(obj)cpu/mpc824x/bedbug_603e.c
@rm -f $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
diff --git a/common/image.c b/common/image.c
index e22c974..845006f 100644
--- a/common/image.c
+++ b/common/image.c
@@ -145,6 +145,7 @@ static table_entry_t uimage_type[] = {
{   IH_TYPE_SCRIPT, "script", "Script", },
{   IH_TYPE_STANDALONE, "standalone", "Standalone Program", },
{   IH_TYPE_FLATDT, "flat_dt","Flat Device Tree",   },
+   {   IH_TYPE_KWBIMAGE,   "kwbimage",   "Kirkwood Boot Image",},
{   -1, "",   "",   },
 };
 
diff --git a/doc/README.kwbimage b/doc/README.kwbimage
new file mode 100644
index 000..b00a053
--- /dev/null
+++ b/doc/README.kwbimage
@@ -0,0 +1,77 @@
+-
+Kirkwood Boot Image generation using mkimage
+-
+
+This document describes the U-Boot feature as it
+is implemented for the Kirkwood family of SoCs.
+
+The Kirkwood SoC's can boot directly from NAND FLASH,
+SPI FLASH, SATA etc. using its internal bootRom support.
+
+for more details refer section 24.2 of Kirkwood functional specifications.
+ref: www.marvell.com/products/embedded.../kirkwood/index.jsp
+
+Commad syntax:
+./tools/mkimage -n  \
+-T kwbimage -a  -e  -d 
 
+
+for ex.
+./tools/mkimage -n ./board/Marvell/openrd_base/kwbimage.cfg \
+-T kwbimage -a 0x0060 -e 0x0060 -d u-boot.bin 
u-boot.kwb
+
+kwimage support available with mkimage utility will generate kirkwood boot 
image that can be flashed on the board nand/spi flash
+
+Board specific configuration file specifications:-
+1. This file must present in the $(BOARDDIR) and the name should be 
kwbimage.cfg (since this is used in Makefile)
+2. This file can have empty lines and lines starting with "#" as first 
character to put comments
+3. This file can have configuration command lines as mentioned below, any 
other information in this file is treated as invalid.
+
+Configuration command line syntax:
+1. Each command line is must have two strings, first one command or address 
and second one data string
+2. Following are the valid command strings and data strings associated 
combinations
+   Command string  data string
+   BOOT_FROM   nand/spi/sata
+   NAND_ECC_MODE   default/rs/hamming/disabled
+   NAND_PAGE_SIZE  any u16 hex value
+   SATA_PIO_MODE   any u32 hex value
+   DDR_INIT_DELAY  any u32 hex value
+ , you can have maximum 55 
such commands
+3. all commands are optional to program
+
+Typical example of kwimage.cfg file:-
+
+# Boot Media configurations
+BOOT_FROM  nand
+NAND_ECC_MODE  default
+NAND_PAGE_SIZE 0x0800
+
+# Configure RGMII-0 interface pad voltage to 1.8V
+0xFFD100e0 0x1b1b1b9b
+# DRAM Configuration
+0xFFD01400 0x43000c30
+0xFFD01404 0x37543000
+0xFFD01408 0x22125451
+0xFFD0140C 0x0a33
+0xFFD01410 0x00cc
+0xFFD01414 0x
+0xFFD01418 0x
+0xFFD0141C 0x0C52
+0xFFD01420 0x0040
+0xFFD01424 0xF17F
+0xFFD01428 0x00085520
+0xFFD0147C 0x8552
+0xFFD01504 0x0FF1
+0xFFD01508 0x1000
+0xFFD0150C 0x0FF5
+0xFFD01514 0x
+0xFFD0151C 0x
+0xFFD01494 0x0003
+0xFFD01498 0x
+0xFFD0149C 0xE803
+0xFFD01480 0x0001
+# End of Header extension
+0x0 0x0
+
+Author: Prafulla Wadaskar 
+--

[U-Boot] [PATCH 3/3] Kirkwood: Sheevaplug: kwimage configuration

[Prafulla Wadaskar]

Signed-off-by: Prafulla Wadaskar 
---
 board/Marvell/sheevaplug/kwbimage.cfg |   61 +
 1 files changed, 61 insertions(+), 0 deletions(-)
 create mode 100644 board/Marvell/sheevaplug/kwbimage.cfg

diff --git a/board/Marvell/sheevaplug/kwbimage.cfg 
b/board/Marvell/sheevaplug/kwbimage.cfg
new file mode 100644
index 000..874dcd2
--- /dev/null
+++ b/board/Marvell/sheevaplug/kwbimage.cfg
@@ -0,0 +1,61 @@
+#
+# (C) Copyright 2009
+# Marvell Semiconductor 
+# Written-by: Prafulla Wadaskar 
+#
+# 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
+#
+# Refer docs/README.kwimage for more details about how-to configure
+# and create kirkwood boot image
+#
+
+# Boot Media configurations
+BOOT_FROM  nand
+NAND_ECC_MODE  default
+NAND_PAGE_SIZE 0x0800
+
+# SOC registers configuration for initial values using bootrom header extension
+# Maximum KWBIMAGE_MAX_CONFIG configurations allowed
+
+# Configure RGMII-0 interface pad voltage to 1.8V
+0xFFD100e0 0x1b1b1b9b
+# DRAM Configuration
+0xFFD01400 0x43000c30
+0xFFD01404 0x37543000
+0xFFD01408 0x22125451
+0xFFD0140C 0x0a33
+0xFFD01410 0x00cc
+0xFFD01414 0x
+0xFFD01418 0x
+0xFFD0141C 0x0C52
+0xFFD01420 0x0040
+0xFFD01424 0xF17F
+0xFFD01428 0x00085520
+0xFFD0147C 0x8552
+0xFFD01504 0x0FF1
+0xFFD01508 0x1000
+0xFFD0150C 0x0FF5
+0xFFD01514 0x
+0xFFD0151C 0x
+0xFFD01494 0x0003
+0xFFD01498 0x
+0xFFD0149C 0xE803
+0xFFD01480 0x0001
+# End of Header extension
+0x0 0x0
-- 
1.5.3.4

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

[U-Boot] [PATCH 1/3] tools: mkimage: hdr_size used to facilitate customized support

[Prafulla Wadaskar]

hdr_size variable is initialized
at the start of image creation algorithm instead of reading it each time.
This facilitate to use the common code for other image type implementations
for ex. kwbimage

Signed-off-by: Prafulla Wadaskar 
---
 tools/mkimage.c |   18 --
 1 files changed, 8 insertions(+), 10 deletions(-)

diff --git a/tools/mkimage.c b/tools/mkimage.c
index 967fe9a..c5b593c 100644
--- a/tools/mkimage.c
+++ b/tools/mkimage.c
@@ -250,9 +250,10 @@ NXTARG:;
 *
 * write dummy header, to be fixed later
 */
-   memset (hdr, 0, image_get_header_size ());
-
-   if (write(ifd, hdr, image_get_header_size ()) != image_get_header_size 
()) {
+   int hdr_size;
+   hdr_size = image_get_header_size ();
+   memset (hdr, 0, hdr_size);
+   if (write(ifd, hdr, hdr_size) != hdr_size) {
fprintf (stderr, "%s: Write error on %s: %s\n",
cmdname, imagefile, strerror(errno));
exit (EXIT_FAILURE);
@@ -339,14 +340,12 @@ NXTARG:   ;
hdr = (image_header_t *)ptr;
 
checksum = crc32 (0,
- (const char *)(ptr + image_get_header_size ()),
- sbuf.st_size - image_get_header_size ()
-);
-
+   (const char *)(ptr + hdr_size),
+   sbuf.st_size - hdr_size);
/* Build new header */
image_set_magic (hdr, IH_MAGIC);
image_set_time (hdr, sbuf.st_mtime);
-   image_set_size (hdr, sbuf.st_size - image_get_header_size ());
+   image_set_size (hdr, sbuf.st_size - hdr_size);
image_set_load (hdr, addr);
image_set_ep (hdr, ep);
image_set_dcrc (hdr, checksum);
@@ -354,10 +353,9 @@ NXTARG:;
image_set_arch (hdr, opt_arch);
image_set_type (hdr, opt_type);
image_set_comp (hdr, opt_comp);
-
image_set_name (hdr, name);
 
-   checksum = crc32 (0, (const char *)hdr, image_get_header_size ());
+   checksum = crc32 (0, (const char *)hdr, hdr_size);
 
image_set_hcrc (hdr, checksum);
 
-- 
1.5.3.4

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

Re: [U-Boot] [PATCH 1/1] OMAP3 Fix compiler warning for v7_flush_dcache_all

[Wolfgang Denk]

Dear Tom Rix,

In message <1246392253-8431-2-git-send-email-tom@windriver.com> you wrote:
> On build of omap3 targets in MAKEALL, the *.ERR files have
> 
> cpu.c: In function 'cleanup_before_linux':
> cpu.c:64: warning: implicit declaration of function 'v7_flush_dcache_all'
> cpu.c:64: warning: implicit declaration of function 'get_device_type
> 
> The functions v7_flush_dcache_all and get_device_type are declared
> in include/asm-arm/arch-omap3/sys_proto.h, so use this file to
> declare the functions.
> 
> Signed-off-by: Tom Rix 
> ---
>  cpu/arm_cortexa8/cpu.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Software suppliers are trying to make their  software  packages  more
``user-friendly''.  .  .  .  Their best approach, so far, has been to
take all the old brochures, and stamp the words, ``user-friendly'' on
the cover.   - Bill Gates
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Eric Benard,

In message <1247948834-30856-1-git-send-email-e...@eukrea.com> you wrote:
> CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR
> flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100
> Ethernet PHY in RMII mode.
> 
...
> --- a/Makefile
> +++ b/Makefile
> @@ -2813,6 +2813,19 @@ at91sam9rlek_config:   unconfig
>   fi;
>   @$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91
>  
> +cpu9260_64m_config \
> +cpu9260_config   :   unconfig
> + @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91
> + @if [ "$(findstring _64m,$@)" ] ; then \
> + echo "#define CONFIG_SYS_SDRC_CR_VAL 
> CONFIG_SYS_SDRC_CR_VAL_64MB" \
> + >>$(obj)include/config.h ; \
> + $(XECHO) "... with 64MB SDRAM" ; \
> + else \
> + echo "#define CONFIG_SYS_SDRC_CR_VAL 
> CONFIG_SYS_SDRC_CR_VAL_128MB" \
> + >>$(obj)include/config.h ; \
> + $(XECHO) "... with 128MB SDRAM" ; \
> + fi;

This makes no sense to me. "mkconfig  -a"  (i.  e.  in  append  mode)
should  be  used AFTER manually initializing the config files. Either
omit the "-a", or move the line down.

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
Drawing on my fine command of language, I said nothing.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC

[Wolfgang Denk]

Dear Eric Benard,

In message <1247947830-22602-1-git-send-email-e...@eukrea.com> you wrote:
> CPUAT91 is built around Atmel's AT91RM9200 and has up to 16MB of NOR
> flash, up to 128MB of SDRAM, and includes a Micrel KS8721 PHY in RMII
> mode.
> 
> Signed-off-by: Eric Benard 
> ---

Your subject line reads:

[PATCH 1/1] Add support for Eukrea CPUAT91 SBC

Note that the "1/1" part is bogus as you submit just a single patch -
please omit it.

Second, it seems that this is a resubmit of an earlier patch. You are
suppposed to mark it as such, for example by using something like
"[PATCH v2]" in the subject, and you are also supposed to include at
least a short summary what has been changed compared to your previous
version (add this here, i. e. below the "---" line).


> diff --git a/MAINTAINERS b/MAINTAINERS
> index 575a7ec..da64571 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1,4 +1,4 @@
> -#
> +9#
^

Here you inserted garbage. Please fix.

> --- /dev/null
> +++ b/board/eukrea/cpuat91/cpuat91.c
> +int board_init(void)
> +{
> + /* Enable Ctrlc */
> + console_init_f();
> +
> + /* memory and cpu-speed are setup before relocation */
> + /* so we do _nothing_ here */

Incorrect multi-line comment style.

> + /* arch number of CPUAT91-Board */
> + gd->bd->bi_arch_number = MACH_TYPE_CPUAT91;
> + /* adress of boot parameters */
> + gd->bd->bi_boot_params = PHYS_SDRAM + 0x100;
> +
> + return 0;
> +}
> +
> +int dram_init(void)
> +{
> + gd->bd->bi_dram[0].start = PHYS_SDRAM;
> + gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
> + return 0;
> +}
> +
> +#if defined(CONFIG_DRIVER_ETHER)
> +#if defined(CONFIG_CMD_NET)
> +
> +/*
> + * Name:
> + *   at91rm9200_GetPhyInterface
> + * Description:
> + *   Initialise the interface functions to the PHY
> + * Arguments:
> + *   None
> + * Return value:
> + *   None
> + */
> +void at91rm9200_GetPhyInterface(AT91PS_PhyOps p_phyops)
> +{
> + p_phyops->Init = ks8721_InitPhy;
> + p_phyops->IsPhyConnected = ks8721_IsPhyConnected;
> + p_phyops->GetLinkSpeed = ks8721_GetLinkSpeed;
> + p_phyops->AutoNegotiate = ks8721_AutoNegotiate;
> +}
> +
> +#endif   /* CONFIG_CMD_NET */
> +#endif   /* CONFIG_DRIVER_ETHER */
> diff --git a/cpu/arm920t/at91rm9200/Makefile b/cpu/arm920t/at91rm9200/Makefile
> index 73aeeac..114d8ad 100644
> --- a/cpu/arm920t/at91rm9200/Makefile
> +++ b/cpu/arm920t/at91rm9200/Makefile
> @@ -31,14 +31,15 @@ COBJS += bcm5221.o
>  COBJS+= dm9161.o
>  COBJS+= ether.o
>  COBJS+= i2c.o
> +COBJS-$(CONFIG_KS8721_PHY)   += ks8721.o
>  COBJS+= lxt972.o
>  COBJS+= reset.o
>  COBJS+= spi.o
>  COBJS+= timer.o
>  COBJS+= usb.o
>  
> -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
> +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS) $(COBJS-y))
>  
>  all: $(obj).depend $(LIB)
>  
> diff --git a/cpu/arm920t/at91rm9200/ks8721.c b/cpu/arm920t/at91rm9200/ks8721.c
> new file mode 100644
> index 000..703e58c
> --- /dev/null
> +++ b/cpu/arm920t/at91rm9200/ks8721.c
...
> + * Return value:
> + *   TRUE - if id read successfully
> + *   FALSE- if error
> + */

Please use 0 and 1 (or -1) as return values. We don't use TRUE and
FALSE here.

...
> + if (stat1 & KS8721_10BASE_T_HD) {
> + /*set MII for 10BaseT and Half Duplex  */
> + printf("10BT HD\n");
> + p_mac->EMAC_CFG &= ~(AT91C_EMAC_SPD | AT91C_EMAC_FD);
> + return TRUE;
> + }
> + return FALSE;
> +}
> +
> +

Please use only a single blank line here (and in similar places).

> +/*
> + * Name:
> + *   ks8721_InitPhy
> + * Description:
> + *   MAC starts checking its link by using parallel detection and
> + *   Autonegotiation and the same is set in the MAC configuration registers
> + * Arguments:
> + *   p_mac - pointer to struct AT91S_EMAC
> + * Return value:
> + *   TRUE - if link status set succesfully
> + *   FALSE - if link status not set
> + */
> +UCHAR ks8721_InitPhy(AT91PS_EMAC p_mac)
> +{
> + UCHAR ret = TRUE;

Please get rid of UCHAR an the like.

> + unsigned short IntValue;
> +
> + at91rm9200_EmacEnableMDIO(p_mac);

Please do not use CamelCase identifiers.


Best regards,

Wolfgang Denk

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

[U-Boot] [PATCH 1/2] Add support for Eukrea CPU9260 SBC

[Eric Benard]

CPUAT91 is built around Atmel's AT91SAM9260 and has up to 64MB of NOR
flash, up to 128MB of SDRAM, up to 2GB of NAND and includes a 10/100
Ethernet PHY in RMII mode.

Signed-off-by: Eric Benard 
---
 MAINTAINERS|4 +
 MAKEALL|1 +
 Makefile   |   13 ++
 board/eukrea/cpu9260/Makefile  |   59 +++
 board/eukrea/cpu9260/config.mk |1 +
 board/eukrea/cpu9260/cpu9260.c |  211 +++
 board/eukrea/cpu9260/cpu9260_led.c |   46 +
 include/configs/cpu9260.h  |  335 
 8 files changed, 670 insertions(+), 0 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/cpu9260_led.c
 create mode 100644 include/configs/cpu9260.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 575a7ec..b8d701a 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -515,6 +515,10 @@ Dirk Behme 
 
omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
 
+Eric Benard 
+
+   cpu9260 ARM926EJS (AT91SAM9260 SoC)
+
 Rishi Bhattacharya 
 
omap5912osk ARM926EJS
diff --git a/MAKEALL b/MAKEALL
index 020ff73..bdc80fa 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -592,6 +592,7 @@ LIST_at91=" \
at91sam9m10g45ek\
at91sam9rlek\
cmc_pu2 \
+   cpu9260 \
csb637  \
kb9202  \
meesc   \
diff --git a/Makefile b/Makefile
index 090e645..7ae2bfe 100644
--- a/Makefile
+++ b/Makefile
@@ -2813,6 +2813,19 @@ at91sam9rlek_config  :   unconfig
fi;
@$(MKCONFIG) -a at91sam9rlek arm arm926ejs at91sam9rlek atmel at91
 
+cpu9260_64m_config \
+cpu9260_config :   unconfig
+   @$(MKCONFIG) -a cpu9260 arm arm926ejs cpu9260 eukrea at91
+   @if [ "$(findstring _64m,$@)" ] ; then \
+   echo "#define CONFIG_SYS_SDRC_CR_VAL 
CONFIG_SYS_SDRC_CR_VAL_64MB" \
+   >>$(obj)include/config.h ; \
+   $(XECHO) "... with 64MB SDRAM" ; \
+   else \
+   echo "#define CONFIG_SYS_SDRC_CR_VAL 
CONFIG_SYS_SDRC_CR_VAL_128MB" \
+   >>$(obj)include/config.h ; \
+   $(XECHO) "... with 128MB SDRAM" ; \
+   fi;
+
 meesc_config   :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs meesc esd at91
 
diff --git a/board/eukrea/cpu9260/Makefile b/board/eukrea/cpu9260/Makefile
new file mode 100644
index 000..5b1acdc
--- /dev/null
+++ b/board/eukrea/cpu9260/Makefile
@@ -0,0 +1,59 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Stelian Pop 
+# Lead Tech Design 
+# Ilko Iliev 
+#
+# (C) Copyright 2009
+# Eric Benard 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y += $(BOARD).o
+COBJS-y += $(BOARD)_led.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y) $(SOBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS)
+
+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/eukrea/cpu9260/config.mk b/board/eukrea/cpu9260/config.mk
new file mode 100644
index 000..9ce161e
--- /dev/null
+++ b/board/eukrea/cpu9260/config.mk
@@ -0,0 +1 @@
+TEXT_BASE = 0x21f0
diff --git a/board/eukrea/cpu9260/cpu9260.c b/board/eukrea/cpu9260/cpu9260.c
new file mode 100644
index 000..84707b6
--- /dev/null
+++ b/board/eukrea/cpu9260/cpu9260.c
@@ -0,0 +1,211 @@
+/*
+ * (C) Copyright 2007-2008
+ * Stelian Pop 
+ * Lead Tech Design 
+ * Ilko Iliev 
+ *
+ * (C) Copyright 2009
+ * Eric Benard 
+ *
+ * See file CREDITS for list of pe

[U-Boot] [PATCH 2/2] Add AT91SAM9260 to at91's lowlevel_init.S

[Eric Benard]

Needed for AT91SAM9260 NOR Boot on Eukrea's CPU9260.

Signed-off-by: Eric Benard 
---
 cpu/arm926ejs/at91/lowlevel_init.S |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/cpu/arm926ejs/at91/lowlevel_init.S 
b/cpu/arm926ejs/at91/lowlevel_init.S
index 5ed518c..9962ae9 100644
--- a/cpu/arm926ejs/at91/lowlevel_init.S
+++ b/cpu/arm926ejs/at91/lowlevel_init.S
@@ -194,7 +194,7 @@ SMRDATA:
.word CONFIG_SYS_PIOD_PPUDR_VAL
.word (AT91_BASE_SYS + AT91_PIOD + PIO_ASR)
.word CONFIG_SYS_PIOD_PPUDR_VAL
-#elif defined(CONFIG_AT91SAM9261)
+#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261)
.word (AT91_BASE_SYS + AT91_PIOC + PIO_PDR)
.word CONFIG_SYS_PIOC_PDR_VAL1
.word (AT91_BASE_SYS + AT91_PIOC + PIO_PUDR)
-- 
1.6.0.4

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

Re: [U-Boot] bootelf and command line arguments

[Wolfgang Denk]

Dear Thomas Dörfler,

In message <4a622bd6.2070...@embedded-brains.de> you wrote:
>
> - Is there any useful reason why the bootelf command is limited to
> maxargs?

No. git blame shows that this entry has never been changed, so I guess
it just went unnoticed so far.

> - Would anybody mind if I commit a patch to change maxargs to
> CONFIG_SYS_MAXARGS?

No, on contrary - I consider this a bug fix.

I recommend to submit a (separate) patch for this ASAP so it can go in
into the upcoming release.

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
"Anyone attempting to generate random numbers by deterministic  means
is, of course, living in a state of sin."  - John Von Neumann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] ARM: make split_by_variant.sh output more useful

[Wolfgang Denk]

The board/armltd/integrator/split_by_variant.sh script used to print
"Configuring for integrator*p board..." no matter which board name
was being compiled. This made it difficult to match MAKEALL output to
board names. This patch fixes this.

Signed-off-by: Wolfgang Denk 
---
 board/armltd/integrator/split_by_variant.sh |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/board/armltd/integrator/split_by_variant.sh 
b/board/armltd/integrator/split_by_variant.sh
index d67bdc2..702b436 100755
--- a/board/armltd/integrator/split_by_variant.sh
+++ b/board/armltd/integrator/split_by_variant.sh
@@ -231,5 +231,5 @@ fi # ap
 # -
 # Complete the configuration
 # -
-$MKCONFIG -a integrator$1 arm $cpu integrator armltd;
-echo "Variant:: $variant with core $cpu"
+$MKCONFIG -a -n "${2%%_config}" integrator$1 arm $cpu integrator armltd
+echo "Variant: $variant with core $cpu"
-- 
1.6.0.6

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

[U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC

[Eric Benard]

CPUAT91 is built around Atmel's AT91RM9200 and has up to 16MB of NOR
flash, up to 128MB of SDRAM, and includes a Micrel KS8721 PHY in RMII
mode.

Signed-off-by: Eric Benard 
---
 MAINTAINERS |6 +-
 MAKEALL |3 +-
 Makefile|   12 ++
 board/eukrea/cpuat91/Makefile   |   50 
 board/eukrea/cpuat91/config.mk  |1 +
 board/eukrea/cpuat91/cpuat91.c  |   85 ++
 cpu/arm920t/at91rm9200/Makefile |5 +-
 cpu/arm920t/at91rm9200/ks8721.c |  244 +++
 include/configs/cpuat91.h   |  231 
 include/ks8721.h|   78 +
 10 files changed, 711 insertions(+), 4 deletions(-)
 create mode 100644 board/eukrea/cpuat91/Makefile
 create mode 100644 board/eukrea/cpuat91/config.mk
 create mode 100644 board/eukrea/cpuat91/cpuat91.c
 create mode 100644 cpu/arm920t/at91rm9200/ks8721.c
 create mode 100644 include/configs/cpuat91.h
 create mode 100644 include/ks8721.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 575a7ec..da64571 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1,4 +1,4 @@
-#
+9#
 #  #
 # Regular Maintainers for U-Boot board support:
#
 #  #
@@ -515,6 +515,10 @@ Dirk Behme 
 
omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
 
+Eric Benard 
+
+   cpcuat91ARM920T
+
 Rishi Bhattacharya 
 
omap5912osk ARM926EJS
diff --git a/MAKEALL b/MAKEALL
index 020ff73..0e0b657 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -587,11 +587,12 @@ LIST_at91="   \
at91sam9260ek   \
at91sam9261ek   \
at91sam9263ek   \
-   at91sam9g10ek   \
+   at91sam9g10ek   \
at91sam9g20ek   \
at91sam9m10g45ek\
at91sam9rlek\
cmc_pu2 \
+   cpuat91 \
csb637  \
kb9202  \
meesc   \
diff --git a/Makefile b/Makefile
index 090e645..3b348d9 100644
--- a/Makefile
+++ b/Makefile
@@ -2683,6 +2683,18 @@ at91rm9200ek_config  :   unconfig
 cmc_pu2_config :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t cmc_pu2 NULL at91rm9200
 
+cpuat91_ram_config \
+cpuat91_config :   unconfig
+   @mkdir -p $(obj)include
+   @if [ "$(findstring _ram_,$@)" ] ; then \
+   echo "#define CONFIG_CPUAT91_RAM 1" >>$(obj)include/config.h ; \
+   $(XECHO) "... CPUAT91 configured for RAM" ; \
+   else \
+   echo "#define CONFIG_BOOTDELAY 1" >>$(obj)include/config.h ;\
+   $(XECHO) "... CPUAT91 configured for Flash" ;\
+   fi;
+   @$(MKCONFIG) -a cpuat91 arm arm920t cpuat91 eukrea at91rm9200
+
 csb637_config  :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t csb637 NULL at91rm9200
 
diff --git a/board/eukrea/cpuat91/Makefile b/board/eukrea/cpuat91/Makefile
new file mode 100644
index 000..08a90dc
--- /dev/null
+++ b/board/eukrea/cpuat91/Makefile
@@ -0,0 +1,50 @@
+#
+# (C) Copyright 2003-2006
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS  := cpuat91.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/eukrea/cpuat91/config.mk b/board/eukre

[U-Boot] bootelf and command line arguments

[Thomas Dörfler]

Hello,

up to now I have worked in private with U-Boot and adapted it to a
user-specific MPC5121e based board. We have worked out how we want to
use U-Boot and soon would like to commit the board specific (and not so
specific) source code changes and additions.

Now we have hit a strange point. the "bootelf" command obviously is
prepared to pass argc/argv to the called program. But in its command
list entry, the number of maximum arguments is limited to 2, which
allows only the command itself and the address of the elf image in
memory to be specified.

I have modified the maxargs field to be CONFIG_SYS_MAXARGS, which works
fine. So my questions are:

- Is there any useful reason why the bootelf command is limited to
maxargs=2?

- Would anybody mind if I commit a patch to change maxargs to
CONFIG_SYS_MAXARGS?

wkr,
Thomas Doerfler.

-- 


Embedded Brains GmbH
Thomas DoerflerObere Lagerstrasse 30
D-82178 Puchheim   Germany
email: thomas.doerf...@embedded-brains.de
Phone: +49-89-18908079-2
Fax:   +49-89-18908079-9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] jffs2: some fixes to summary support

[Mike Frysinger]

On Friday 17 July 2009 07:02:42 Ilya Yanok wrote:
> +#ifdef CONFIG_JFFS2_SUMMARY
> +static u32 sum_get_unaligned32(u32 *ptr)
> +{
> + u32 val;
> + u8 *p = (u8 *)ptr;
> +
> + val = *p | (*(p + 1) << 8) | (*(p + 2) << 16) | (*(p + 3) << 24);
> +
> + return __le32_to_cpu(val);
> +}
> +
> +static u16 sum_get_unaligned16(u16 *ptr)
> +{
> + u16 val;
> + u8 *p = (u8 *)ptr;
> +
> + val = *p | (*(p + 1) << 8);
> +
> + return __le16_to_cpu(val);
> +}

do get_unaligned_le16 and such not work ?
-mike


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

Re: [U-Boot] [PATCH] Add inverted clock polarity support for Atmel LCD driver

[Anatolij Gustschin]

Dimitar Dimitrov wrote:
> This is my third try for Olimex SAM9-L9260/61 board support patches. 
> 
> Here follows the first patch.
> ---
> 
> Boards utilizing the Atmel LCD driver can now specify that the LCD clock must
> be inverted by defining the macro CONFIG_LCD_INVERTED_CLOCK.
> ---
>  README  |5 +
>  drivers/video/atmel_lcdfb.c |3 +++
>  2 files changed, 8 insertions(+), 0 deletions(-)

Applied to u-boot-video after fixing commit message and adding
your Signed-off-by line. Also please check for trailing white
spaces next time. Thanks!

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

Re: [U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

Dear Mike Frysinger,

In message <200907181456.20670.vap...@gentoo.org> you wrote:
>
> are there really any guidelines on what "CONFIG_SYS_" is for ?  i havent 
> really figured out what "_SYS_" is supposed to indicate, so the new proposed 
> naming is just as confusing imo.

Actually there ARE guidelines; they are not perfect, but better than
nothing.

It helps to read the README.

If you think this is insufficint and yoiu have better ideas, please
post a patch.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The price of curiosity is a terminal experience.
 - Terry Pratchett, _The Dark Side of the Sun_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] CONFIG naming convetion

[Mike Frysinger]

On Saturday 18 July 2009 07:03:38 Jean-Christophe PLAGNIOL-VILLARD wrote:
> Hi all,
>
>   Currently we have a mess in the drivers CONFIG naming convention
>   as example on I2C we have
>   CONFIG_I2C_X
>   CONFIG_DRIVER_XXX_I2C
>   CONFIG__I2C
>   CONFIG_SYS_I2C_
>
>   I think it will good to have common and clean naming convention
>   so I'll propose we use this one
>   CONFIG_namespace_X
>   and
>   CONFIG_SYS_namespace_X
>
>   so it will resutly for I2C to this
>
>   CONFIG_I2C_X
>   CONFIG_SYS_I2C_
>
>   and the Makefile and KConfig it will be easier to sort and read

are there really any guidelines on what "CONFIG_SYS_" is for ?  i havent 
really figured out what "_SYS_" is supposed to indicate, so the new proposed 
naming is just as confusing imo.
-mike


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

Re: [U-Boot] [PATCH 6/6] Marvell RD6281A Board support

[Jean-Christophe PLAGNIOL-VILLARD]

> diff --git a/include/configs/rd6281a.h b/include/configs/rd6281a.h
> new file mode 100644
> index 000..065e4aa
> --- /dev/null
> +++ b/include/configs/rd6281a.h
> @@ -0,0 +1,209 @@
> +/*
> + * (C) Copyright 2009
> + * Marvell Semiconductor 
> + * Written-by: Prafulla Wadaskar 
> + *
> + * 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
> + */
> +
> +#ifndef _CONFIG_RD6281A_H
> +#define _CONFIG_RD6281A_H
> +
> +/*
> + * Version number information
> + */
> +#define CONFIG_IDENT_STRING  "\nMarvell-Sheevaplug"
???
Sheevaplug?

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

[U-Boot] [PATCH] at91cap9adk: fix #ifdef/#endif pairing

[Wolfgang Denk]

The #ifdef/#endif pairing in this file was obviously messed up.

Signed-off-by: Wolfgang Denk 
---
 include/configs/at91cap9adk.h |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/include/configs/at91cap9adk.h b/include/configs/at91cap9adk.h
index 526cd60..219eea3 100644
--- a/include/configs/at91cap9adk.h
+++ b/include/configs/at91cap9adk.h
@@ -123,7 +123,6 @@
 /* our CLE is AD22 */
 #define CONFIG_SYS_NAND_MASK_CLE   (1 << 22)
 #define CONFIG_SYS_NAND_ENABLE_PIN AT91_PIN_PD15
-#endif
 
 /* NAND flash */
 #ifdef CONFIG_CMD_NAND
@@ -131,6 +130,7 @@
 #define CONFIG_SYS_MAX_NAND_DEVICE 1
 #define CONFIG_SYS_NAND_BASE   0x4000
 #define CONFIG_SYS_NAND_DBW_8  1
+#endif
 
 /* Ethernet */
 #define CONFIG_MACB1
-- 
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 5/6] net: Kirkwood_egiga: forced interface speed config support

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:58 Thu 16 Jul , Prafulla Wadaskar wrote:
> By default Auto Negotiation is enabled for interface speed
> but on some platforms like RD6281A it does not work.
> If you want to forced program it to desired speed,
> this patch helps-
> 
> Through this patch Auto negotiation can be disabled and
> desired interface speed can be configured
> 
> This patch is tested on RD6281A Kirkwood board
> 
> Signed-off-by: Prafulla Wadaskar 
> ---
>  drivers/net/kirkwood_egiga.c |   24 
>  1 files changed, 24 insertions(+), 0 deletions(-)
> 
> diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
> index 3c5db19..1dfd567 100644
> --- a/drivers/net/kirkwood_egiga.c
> +++ b/drivers/net/kirkwood_egiga.c
> @@ -415,7 +415,31 @@ static int kwgbe_init(struct eth_device *dev)
>   /* Assign port configuration and command. */
>   KWGBEREG_WR(regs->pxc, PRT_CFG_VAL);
>   KWGBEREG_WR(regs->pxcx, PORT_CFG_EXTEND_VALUE);
> + /*
> +  * Forced 10/100/1000BASE-T interface speed configuration
> +  * By default Auto Negotiation of interface speed is enabled
> +  * This can be forced disabled and desired speed can be configured
> +  */
> +#ifdef CONFIG_DIS_AUTO_NEG_SPEED_GMII
> +#if (!defined (CONFIG_PHY_SPEED) || (CONFIG_PHY_SPEED == _1000BASET))
Could you find a better config taht _1000BASET & co

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

Re: [U-Boot] [PATCH v13 3/6] Marvell MV88F6281GTW_GE Board support

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:58 Thu 16 Jul , Prafulla Wadaskar wrote:
> This is Marvell's 88F6281_A0 based custom board developed
> for wireless access point product
> 
> This patch is tested for-
> 1. Boot from DRAM/SPI flash/NFS
> 2. File transfer using tftp and loadb
> 3. SPI flash read/write/erase
> 4. Booting Linux kernel and RFS from SPI flash
> 5. Boot from USB supported
> 
> Reviewed-by: Ronen Shitrit 
> Signed-off-by: Prafulla Wadaskar 
> ---
applied to u-boot-arm

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

Re: [U-Boot] Using Uboot to communicate a PCI device.

[Darshan Vasisht]

Hi Dave,
 I am really happy for your co-operation in making me understand things
which i completely don't have an idea for.
I am getting some clarity into this requirement after looking at your
answers and explanations.
Let me tell you what i am able to understand from these explanations at this
juncture.
1. Since Octeon's u-boot has the capabilities of initialize Octeon's PCI
(Assign bus address ranges used to configure devices found on the PCI bus),
we can talk to a PCI device on the other end provided we have info about
their memory addressing etc.
*Having said this, what all (info) i need to have from the PCI device
(Winpath NP) so that i am able to bring it up. I mean do i need to have some
device driver of NP so that i am able to read/write into its Config
space/Memory space?* I am really sorry if my questions are too silly. I am
new to u-boot and PCI hence such questions.

Now let me answer the questions, you have asked me.
*The host's U-Boot can initialize the PCI interfaces on the NPs, and then
later your U-Boot 'NP boot' command (U-boot application) can use the PCI
interface registers to move the window around while copying application code
into the NP memory space. You would need to have access via PCI to NP
control registers too, so that you can release the NP core from reset and
allow it to boot from the application code your host just copied into its
address space. Based on your current understanding of the processors, does
any of this sound possible?
*I am not able to apprehend the very first sentence you have quoted. The
host's U-boot can initialize its own end of the PCI interface. How can it
initialize the PCI interface of the NP? Please, can you give me more clarity
on this?
You mention, "You would need to have access via PCI to NP control registers
too, so that you can release the NP core from reset and allow it to boot
from the application code your host just copied into its address space*.*"
In order to execute such task, do i need a program code (NP device driver)
present at my end (inside my U-boot's driver folder) so that i will be able
to write an u-boot application('NP Boot')?

*Do you have access to the source code for the NP bootloader so that you can
implement both ends of the communication path?*
Can i conclude after reading the above sentence written from you that i need
to write some code (which involves modification in the NP bootloader) to
complete the 'NP boot'  initiated from the other end?
Also, can i conclude that in order to achieve my objective of Booting an
NP(PCI device) from Octeon (PCI host) involves work at both the ends?

*Is there any documentation on the boards you are working on that is
available online? At a minimum links to the Cavium and NP data sheets would
be useful.*
I am afraid such datasheets wont be available speaking details like PIN
configuration etc.Check this link a primitive one ;-) (
http://www.caviumnetworks.com/OCTEON-Plus_CN58XX.html)


2009/7/18 

> Hi Darshan,
>
> > Cavium's U-boot version included has been modified to support
> > multicore OCTEON processors. The 'bootoct' command has been
> > added, which supports the booting of an Octeon simple
> > executive application.
>
> Ok. Since the processor is already supported in U-Boot,
> your life is much easier.
>
> > In my case I dont have any OS on the board
>
> Ok.
>
> > U-boot is responsible for loading applications into
> > the Octeon Memory space.
>
> Ok.
>
> > But i have heard that Uboot(inside Octeon) can be modified
> > to communicate to a device.
>
> If the other processors are in the address space of the
> Octeon processor, or if an Octeon PCI window can be moved
> to overlay each of the NPs, then host read/write accesses
> can be used to initialize the slave NPs. There is no
> additional 'communication' code needed.
>
> > Since No OS such as Linux exists, Cavium's U-Boot will initialize the
> > processor itself (As a Simple Executive) along with its PCI interface
> > initialization is also done. Now, how should i go ahead in talking to the
> > Winpath NP for doing a task. For eg, Copying the Winpath Boot Image onto
> > the NP via the PCI interface?
>
> Once the NP PCI interface is configured and enabled, you
> should be able to use read/write accesses on your host that
> hit the PCI addresses corresponding to the NP.
>
> As an analogy, we have a single x86 host processor in a cPCI
> interface with 15 PowerPC boards plugged into the backplane.
> The host BIOS initializes the PCI interfaces on the PowerPC boards
> and enables them. On the PowerPCs, if U-Boot has not been
> installed, a default PCI window is setup, and if U-Boot is
> installed a custom setting is used (the local-side PCI
> initialization completes before the x86 BIOS enables the
> interfaces). As far as the x86 host is concerned, each
> PowerPC appears as at least two windows in the PCI space;
> one window is a set of PowerPC control registers, and
> another window points to an arbitrary address in the
> PowerPC me

Re: [U-Boot] [PATCH] 8xxx: fix warning: implicit declaration of function 'uec_standard_init'

[Wolfgang Denk]

Dear Peter Tyser,

In message <1247940820.13289.2.ca...@ptyser-laptop> you wrote:
> On Sat, 2009-07-18 at 16:15 +0200, Wolfgang Denk wrote:
> > Commit 8e55258f created function uec_standard_init() to initialize
> > all UEC interfaces for 83xx and 85xx but failed to provide a
> > prototype for it.
> 
> Kumar sent a similar patch to fix this previously and was picked up by
> Ben FWIW:
> http://www.mail-archive.com/u-boot@lists.denx.de/msg15797.html

Indeed - yet it didn't make into mainline yet, so I went ahead and
fixed it.

Hope this is ok.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I believe you find life such a problem because you  think  there  are
the  good  people  and the bad people. You're wrong, of course. There
are, always and only, the bad people, but some of them are  on  oppo-
site sides.  - Terry Pratchett, _Guards! Guards!_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] 8xxx: fix warning: implicit declaration of function 'uec_standard_init'

[Peter Tyser]

On Sat, 2009-07-18 at 16:15 +0200, Wolfgang Denk wrote:
> Commit 8e55258f created function uec_standard_init() to initialize
> all UEC interfaces for 83xx and 85xx but failed to provide a
> prototype for it.

Kumar sent a similar patch to fix this previously and was picked up by
Ben FWIW:
http://www.mail-archive.com/u-boot@lists.denx.de/msg15797.html

Best,
Peter

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

Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure

[Wolfgang Denk]

Dear Peter Tyser,

In message <1247935976.9174.31.ca...@ptyser-laptop> you wrote:
> 
> I see your point.  Its a bit confusing as U-Boot documentation
> seems to refer to "Standalone applications" alot, and in general that
> documentation is specifically referring jumptable applications.  eg
> "doc/README.standalone" and "Standalone HOWTO" in README.  If you dig
> you can find the API applications mentioned in api/README - I don't see
> it referenced much in either the standard location of /doc/* or /README.
> I guess my only point is that it would be great if the application
> documentation was consistent between the jumptable and API method, then
> it would be a a no brainer as far as naming /examples directory layout.
> As is, documentation implies "standalone application" means jumptable
> application.

Agreed. So far it seems that the *BSD boot loader folks are the only
users of and the only developers interested in the API code.

> eg: /examples/apps/[api|jumptable].  I'm also fine with leaving it the
> way I had it initially as all documentation currently implies standalone
> == jumptable, api = API method.

Agreed - that should besufficiently clear - at least for now.

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
After a time, you may find that "having" is not so pleasing a thing,
after all, as "wanting."  It is not logical, but it is often true.
-- Spock, "Amok Time", stardate 3372.7
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure

[Wolfgang Denk]

Dear Peter Tyser,

In message <1247935062.9174.14.ca...@ptyser-laptop> you wrote:
> 
> I'd still vote for changing the directory structure in this release,

NAK. Such heavily restructuring changes should be prepared and
submitted at (or even before) the begin of the merge window, not at
it's very end.

For this release it's too late for such a change.

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
"Deliver yesterday, code today, think tomorrow."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ppc: Fix compile error for boards with CONFIG_DDR_ECC

[Wolfgang Denk]

Dear Stefan Roese,

In message <200907180731.42703...@denx.de> you wrote:
> 
> > > Wolfgang, I suggest that you pull this patch directly so that the
> > > breakage is fixed.
> >
> > Done.
> 
> This patch is still not available in mainline.

Should be visible now. I forgot to push my changes out to the public
server (you should have been able to see it on pollux, though).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
History is only a confused heap of facts.
   -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mpc83xx: fix duplicate MONITOR_LEN definition caused by merge foo

[Wolfgang Denk]

Dear Kim Phillips,

In message <20090717124744.2e420b4b.kim.phill...@freescale.com> you wrote:
> commits 4a9932a4364b548773bc131bf85e24a2ec15f2b0 and
> c9646ed758804fa1fa6c1425369a4eee5d618b1d merged and generated this build
> error:
> 
> Configuring for MPC837XERDB board...
> In file included from /home/r1aaha/git/u-boot/include/config.h:3,
>  from include/common.h:35:
> /home/r1aaha/git/u-boot/include/configs/MPC837XERDB.h:233:1: warning: 
> "CONFIG_SYS_MONITOR_LEN" redefined
> /home/r1aaha/git/u-boot/include/configs/MPC837XERDB.h:232:1: warning: this is 
> the location of the previous definition
> 
> take the larger value of the two, to allow for -mmultiple-broken compilers,
> such as gcc 4.4.
> 
> Signed-off-by: Kim Phillips 

Sorry, I ran over this and fixed it before running over your patch.

Hope this is OK with you.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
God may be subtle, but He isn't plain mean. - Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Using Uboot to communicate a PCI device.

[Wolfgang Denk]

Dear Darshan Vasisht,

In message <49797f780907172331s4e6e9121w122812e2ccc3c...@mail.gmail.com> you 
wrote:
> 
> Cavium's U-boot version included has been modified to support multicore
> OCTEON processors. The 'bootoct' command has been added, which supports the
> booting of an Octeon simple executive application.

It would have been really nice if such development had not been done
behind closed doors, and if design decisions had been discussed here
on the mailinglist.

I guess this could have saved you a lot of effort whenever you try to
push this code upstream.

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
Far back in the mists of ancient time, in the great and glorious days
of the former Galactic Empire, life was wild, rich  and  largely  tax
free. - Douglas Adams, _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] [RFC] CONFIG naming convetion

[Wolfgang Denk]

Dear Robin Getz,

In message <200907181115.26404.rg...@blackfin.uclinux.org> you wrote:
>
> It would be nice to come up with some list of namespaces, and what they
> they should be used for...

Agreed.

> For example, should it be:
> CONFIG_DRIVER_OMAP24XX_I2C
> or
> CONFIG_SYS_I2C_DRIVER_OMAP24XX
> or
> CONFIG_DRIVER_I2C_OMAP24XX

Well, the difference between CONFIG_ and CONFIG_SYS_ is well-defined.

And the "DRIVER_" part makes not much sense to me in any of the
examples above. 

My personal way of thinking about such options is usually  CPU/archi-
tecture  first,  so I would probably chose CONFIG_OMAP24XX_I2C to en-
able/disable the I2C driver on a OMAP24XX based board, but  I  under-
stand  that there are reasons to prefer CONFIG_I2C_OMAP24XX as well -
let's see if there is a clear majority of opiniions...

> Again - which is only used in one place:
> drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
> include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C
> 
> Which is fine - since it is a driver, which I'm sure that people out of tree 
> use.

Well, if only out-of-tree ports use it, it probably should never have
been added in the first place.

> I would think should be CONFIG_DRIVERS_PATA_BFIN

I dosagree, the "DRIVERS" part is just added line noise.

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
Politician:  An  eel  in  the  fundamental   mud   upon   which   the
superstructure  of  organized  society is reared. When he wriggles he
mistakes the agitation of his tail for the trembling of the  edifice.
As  compared with the statesman, he suffers the disadvantage of being
alive.   - Ambrose Bierce
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC

[Jean-Christophe PLAGNIOL-VILLARD]

On 19:14 Sat 18 Jul , Eric Bénard wrote:
> Jean-Christophe PLAGNIOL-VILLARD wrote :
> >> +
> >> +cpuat91_ram_config \
> >> +cpuat91_config:unconfig
> >> +@if [ "$(findstring _ram_,$@)" ] ; then \
> >> +echo "#define CONFIG_CPUAT91_RAM 1" >> ./include/config.h ; \
> > what is this ram config?
> the ram config allows to generate a u-boot without low level init
> and relocation without having to modify the .h config file.
> 
> > what is its goal?
> to generate a u-boot.bin which can be used to bootstrap the
> AT91RM9200 through it's serial port (using Atmel's loader).
so no need to add a new config
just add
#define CONFIG_SKIP_LOWLEVEL_INIT
#define CONFIG_SKIP_RELOCATE_UBOOT
via the Makefile

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

Re: [U-Boot] [PATCH v7 2/6] Marvell Sheevaplug Board support

[Jean-Christophe PLAGNIOL-VILLARD]

On 20:58 Thu 16 Jul , Prafulla Wadaskar wrote:
> Reference:
> http://plugcomputer.org/
> http://openplug.org/plugwiki/index.php/Das_U-boot_plug_support
> 
> This patch is tested for-
> 1. Boot from DRAM/NAND flash
> 2. File transfer using tftp
> 3. NAND flash read/write/erase
> 4. Linux kernel and RFS Boot from NAND
> 5. Enabled USB PHY init for kernel need
> 6. Boot from USB supported
> 
> Note: to boot Kirkwood kernel with USB support,
>   you should add "usb start" in the boot sequence
> 
> Signed-off-by: Prafulla Wadaskar 
Applied to u-boot-arm

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

Re: [U-Boot] [PATCH V2] ppc4xx: Add 405EP based PMC405DE board

[Wolfgang Denk]

Dear Matthias Fuchs,

In message <4a61e62e.3030...@esd.eu> you wrote:
> 
> Do you want to see something like this (see below)?

Basicly yes, but see comments below.

> I ran into the problem that include/ppc405.h defines a macro "tcr".
> This conflicts with tcr in my gpio_controller struct.

Indeed - this is one of the resons we sreally should clean this up.

> I hope you do make adding PMC405DE board support dependant from
> fixing all casts with io accessor macros :-(

If you really like and kindly ask for it, we can certainly do that :-)
[Or did was a "not" missing somewhere in this sentence? :-) ]

> index 9c1a119..789e326 100644
> --- a/board/esd/pmc405de/pmc405de.c
> +++ b/board/esd/pmc405de/pmc405de.c
> @@ -26,10 +26,20 @@
>   #include 
>   #include 
>   #include 
> +#include 
>   #include 
>   #include 
>   #include 

Patch is white space corrupted.

> +struct pmc405de_cpld {
> + u8 version;
> + u8 reserved0[3];
> + u8 status;
> + u8 reserved1[3];
> + u8 control;
> + u8 reserved2[3];
> +};

Are you sure these are 8 bit registers?

And some comments would be nice, too.

> - out_be32((void*)GPIO0_OR,
> -  in_be32((void*)GPIO0_OR) | CONFIG_SYS_GPIO_EREADY);
> - out_be32((void*)GPIO0_TCR,
> -  in_be32((void*)GPIO0_TCR) | CONFIG_SYS_GPIO_EREADY);
> + out_be32(&gpio0->or,
> +  in_be32(&gpio0->or) | CONFIG_SYS_GPIO_EREADY);
> + out_be32(&gpio0->_tcr,
> +  in_be32(&gpio0->_tcr) | CONFIG_SYS_GPIO_EREADY);

Something is wrong here- either it's 8 bit registers, nd you should
use 8 bit accessor functions, or it's 32 bit in both cases.

And instead of
out_be32(&gpio0->or,
 in_be32(&gpio0->or) | CONFIG_SYS_GPIO_EREADY);
you better use
setbits_be32(&gpio0->or, CONFIG_SYS_GPIO_EREADY);

[See also clrbits_*() and clrsetbits_*()]

> +/* GPIO controller */
> +struct ppc4xx_gpio_controller {
> + u32 or;
> + u32 _tcr;
> + u32 osl;
> + u32 osh;
> + u32 tsl;
> + u32 tsh;
> + u32 odr;
> + u32 ir;
> + u32 rr1;
> + u32 rr2;
> + u32 rr3;
> + u32 reserved;
> + u32 is1l;
> + u32 is1h;
> + u32 is2l;
> + u32 is2h;
> + u32 is3l;
> + u32 is3h;
> +};

Some comments might be helpful here, 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
Perfection is reached, not when there is no longer anything  to  add,
but when there is no longer anything to take away.
   - Antoine de Saint-Exupery
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Pull request: nand flash

[Scott Wood]

The following changes since commit 462b1038738dd86f8dd70595f250ce792e90d244:
  Wolfgang Denk (1):
Merge branch 'master' of /home/wd/git/u-boot/custodians

are available in the git repository at:

  git://git.denx.de/u-boot-nand-flash.git ..BRANCH.NOT.VERIFIED..

David Brownell (1):
  Typo fix: use CONFIG_SOC_DM644X, not CONFIG_SOC_DM646.

Kyungmin Park (1):
  MTD: OneNAND: Increase the environment size to 4KiB

Scott Wood (2):
  Remove legacy NAND and disk on chip code.
  Remove legacy NAND and disk on chip references from boards.

Stefan Roese (3):
  nand/ppc4xx: Move PPC4xx NAND driver to common NAND driver directory
  nand: ndfc: Remove unnecessary #ifdef's
  nand: Change NAND_MAX_OOBSIZE to 218 as needed for some 4k page devices

Valeriy Glushkov (1):
  nand: fixed failed reads on corrected ECC errors in nand_util.c

 Makefile |2 -
 README   |1 -
 board/atc/atc.c  |7 -
 board/bmw/bmw.c  |8 -
 board/cpu86/cpu86.c  |7 -
 board/cpu87/cpu87.c  |7 -
 board/delta/nand.c   |4 -
 board/esd/common/auto_update.c   |   50 -
 board/g2000/g2000.c  |   15 -
 board/gen860t/gen860t.c  |   12 -
 board/mcc200/mcc200.c|7 -
 board/mpl/common/common_util.c   |9 -
 board/netphone/netphone.c|   16 -
 board/netta/netta.c  |   15 -
 board/netta2/netta2.c|   16 -
 board/netvia/netvia.c|   15 -
 board/omap2420h4/omap2420h4.c|   23 -
 board/pcippc2/pcippc2.c  |5 -
 board/pm520/pm520.c  |7 -
 board/pm826/pm826.c  |7 -
 board/pm828/pm828.c  |7 -
 board/rbc823/rbc823.c|   12 -
 board/samsung/smdk6400/smdk6400.c|   11 -
 board/sixnet/sixnet.c|5 -
 board/stxxtc/stxxtc.c|   16 -
 board/svm_sc8xx/svm_sc8xx.c  |7 -
 board/zylonite/nand.c|4 -
 common/Makefile  |2 -
 common/cmd_doc.c | 1644 --
 common/cmd_jffs2.c   |   15 -
 common/cmd_mtdparts.c|   10 -
 common/cmd_nand.c|  412 
 common/docecc.c  |  513 --
 common/env_nand.c|4 -
 common/env_onenand.c |   35 +-
 cpu/ppc4xx/Makefile  |1 -
 doc/README.nand  |3 +-
 doc/feature-removal-schedule.txt |8 -
 drivers/mtd/nand/Makefile|3 +-
 drivers/mtd/nand/davinci_nand.c  |2 +-
 drivers/mtd/nand/diskonchip.c|3 -
 drivers/mtd/nand/nand_util.c |   10 +-
 {cpu/ppc4xx => drivers/mtd/nand}/ndfc.c  |6 -
 drivers/mtd/nand_legacy/Makefile |   48 -
 drivers/mtd/nand_legacy/nand_legacy.c| 1610 -
 fs/jffs2/jffs2_1pass.c   |   20 -
 fs/jffs2/jffs2_nand_1pass.c  |4 -
 include/common.h |3 -
 include/configs/BMW.h|4 -
 include/configs/CATcenter.h  |8 -
 include/configs/CPU86.h  |   10 -
 include/configs/CPU87.h  |4 -
 include/configs/G2000.h  |   20 -
 include/configs/GEN860T.h|   17 -
 include/configs/MIP405.h |   10 -
 include/configs/NETPHONE.h   |   87 --
 include/configs/NETTA.h  |  100 --
 include/configs/NETTA2.h |   87 --
 include/configs/NETVIA.h |   79 --
 include/configs/PCIPPC2.h|   12 -
 include/configs/PCIPPC6.h|   12 -
 include/configs/PIP405.h |4 -
 include/configs/PM520.h  |   19 -
 include/configs/PM826.h  |   14 -
 include/configs/PM828.h  |   13 -
 include/configs/PPChameleonEVB.h |   26 -
 include/configs/RBC823.h |9 -
 include/configs/SXNI855T.h   |   67 --
 include/configs/TQM85xx.h|2 -
 include/configs/VCMA9.h  |   38 -
 include/configs/at91rm9200dk.h   |   30 -
 include/configs/csb637.h |   32 -
 include/configs/delta.h  |9 -
 include/configs/m501sk.h |5 -
 include/configs/omap2420h4.h |   36 -
 include/configs/sbc2410x.h   |   23 -
 include/configs/stxxtc.h |   82 --
 include/configs/svm_sc8xx.h  |4 -
 include/configs/zylonite.h   |8 -
 include/linu

Re: [U-Boot] [PATCH] EUKREA CPUIMX27 : update boot script

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090718150811.gd30...@game.jcrosoft.org> you wrote:
>
> > (imx_nand renamed to mxc_nand)
> > 
> > Signed-off-by: Eric Benard 
> > ---
> >  board/eukrea_cpuimx27/env/bin/boot |2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> could you specify that it's for u-boot-v2 in the subject?
> as [U-BOOT-V2]

I find this mix of unrelated patches pretty much confusing, too.

How about creating a separate list for "u-boot-v2" related patches?
It's trivial to me to set up, but I'd like to hear other opinions
first.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I'm frequently appalled by the low regard you Earthmen have for life.
-- Spock, "The Galileo Seven", stardate 2822.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [RFC] CONFIG naming convetion

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090718144826.gc30...@game.jcrosoft.org> you wrote:
>
> > Funny. You first post a patch, then only then bother to discuss the
> > topic. 
> the patch was send after :)

Well, hard facts tell a different story:

Patch:
...
Received: from ns32433.ovh.net (HELO localhost)
(plagnioj%jcrosoft@213.251.161.87)
by ns0.ovh.net with SMTP; 18 Jul 2009 10:58:33 -
Message-id: <1247914560-30501-1-git-send-email-plagn...@jcrosoft.com>

   Note that "1247914560" = Sat Jul 18 12:56:00 2009

...
Subject: [U-Boot] [PATCH] i2c: use for CONFIGs a common naming
 convention CONFIG_I2C
From: Jean-Christophe PLAGNIOL-VILLARD 
Date: Sat, 18 Jul 2009 12:56:00 +0200
To: u-boot@lists.denx.de

Proposal:
...
Received: from ns32433.ovh.net (HELO localhost)
(plagnioj%jcrosoft@213.251.161.87)
  by ns0.ovh.net with SMTP; 18 Jul 2009 11:06:09 -
Message-id: <20090718110338.ga30...@game.jcrosoft.org>
...
Subject: [RFC] CONFI# G naming convetion
From: Jean-Christophe PLAGNIOL-VILLARD 
Date: Sat, 18 Jul 2009 13:03:38 +0200
To: U-Boot 

The Date: header and internal  timestamps  (Messag-ID)  clearly  show
that the patch was sent 5 minutes before the proposal.

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
"Look! There! Evil!.. pure and simple, total  evil  from  the  Eighth
Dimension!" - Buckaroo Banzai
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC

[Eric Bénard]

Jean-Christophe PLAGNIOL-VILLARD wrote :
 >> +
 >> +cpuat91_ram_config \
 >> +cpuat91_config:unconfig
 >> +@if [ "$(findstring _ram_,$@)" ] ; then \
 >> +echo "#define CONFIG_CPUAT91_RAM 1" >> ./include/config.h ; \
 > what is this ram config?
the ram config allows to generate a u-boot without low level init and 
relocation without having to modify the .h config file.

 > what is its goal?
to generate a u-boot.bin which can be used to bootstrap the AT91RM9200 
through it's serial port (using Atmel's loader).

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

Re: [U-Boot] [PATCH 1/2] new video driver for bus vcxk framebuffers

[Anatolij Gustschin]

Jens Scharsig wrote:
> This patch adds a new video driver
> 
> * adds common bus_vcxk framebuffer driver 
> 
> Signed-off-by: Jens Scharsig 
> ---

Sorry it took so long to review/comment. We need to resolve some
issues before this patch can be applied, then it can go in
for coming release.

> diff --git a/doc/README.bus_vcxk b/doc/README.bus_vcxk
> new file mode 100644
> index 000..44e1238
> --- /dev/null
> +++ b/doc/README.bus_vcxk
> @@ -0,0 +1,95 @@
> +/*
> + * (C) Copyright 2008-2009
> + * BuS Elektronik GmbH & Co. KG 
> + * Jens Scharsig 
> + *
> + * Configuation settings for the EB+CPUx9K2 board.

Typo in Configuration, please fix.

> + *
> + * 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
> + */
> +
> +U-Boot vcxk video controller driver
> +==
> +
> +The driver can use with VC2K, VC4K and VC8K devices on following boards:

> +
> +board| ARCH  | Vendor
> +---
> +EB+CPU5282-T1| MCF5282   | BuS Elektronik GmbH & Co. KG
> +EB+MCF-EVB123| MCF5282   | BuS Elektronik GmbH & Co. KG
> +EB+CPUx9K2   | AT91RM9200| BuS Elektronik GmbH & Co. KG
> +ZLSA | AT91RM9200| Ruf Telematik AG

Please fix indentation/alignment in lines above, so it will look
like initially intended.

> +
> +by define CONFIG_VIDEO_VCXK

I suggest to move this to the beginning of the sentence, e.g.:
"By defining CONFIG_VIDEO_VCXK this driver can be used with VC2K, VC4K ..."

> +
> +Driver configuration
> +
> +
> +The driver needs some defines to descrip the target hardware:

s/descrip/describe

> +
> +CONFIG_SYS_VCXK_BASE
> +
> +base address of VCxK hardware memory
> +
> +CONFIG_SYS_VCXK_DEFAULT_LINEALIGN
> +
> +defines the physical alignment of a pixel row
> +
> +CONFIG_SYS_VCXK_DOUBLEBUFFERED
> +
> +some boards that use vcxk prevent read from framebuffer memory.
> +define this option to enable double buffering (needs 16KiB RAM)

It is more readable if you indent the lines describing the CONFIG_SYS_
option by tab, please fix, also in appropriate lines below, e.g.:

CONFIG_SYS_VCXK_BASE

base address of VCxK hardware memory

CONFIG_SYS_VCXK_DEFAULT_LINEALIGN

defines the physical alignment of a pixel row

and so on.

> +
> +CONFIG_SYS_VCXK_ACKNOWLEDGE_INIT
> +
> +initialize the acknowledge line from vcxk hardware
> +
> +#define CONFIG_SYS_VCXK_ACKNOWLEDGE

please remove "#define" before CONFIG_SYS_VCXK_ACKNOWLEDGE

> +
> +should return true (1), if vcxk hardware acknowledges a viewing reqest

please fix a typo, s/reqest/request

> +
> +CONFIG_SYS_VCXK_ENABLE_INIT
> +
> +initialize the enable line to vcxk hardware
> +
> +CONFIG_SYS_VCXK_DISABLE
> +
> +set  vcxk enable line to disable level / display off
> +
> +CONFIG_SYS_VCXK_ENABLE
> +
> +set  vcxk enable line enable level / display on
> +
> +CONFIG_SYS_VCXK_REQUEST_INIT
> +
> +initialize the request line to vcxk hardware
> +
> +CONFIG_SYS_VCXK_REQUEST
> +
> +should be send an request impulse to vcxk hardware
> +
> +CONFIG_SYS_VCXK_INVERT_INIT
> +
> +should initialize the invert line to vcxk hardware and set it to
> +non invers mode
> +
> +CONFIG_SYS_VCXK_RESET_INIT
> +
> +initialize the reset line to vcxk hardware and release it from reset

Looking on the changes to board configuration file
"include/configs/EB+MCF-EV123.h" in the second patch of this series
I now realize that most of these CONFIG_SYS_ macros above expand to
C code, so these are not configuration options any more.
I tend to reject all this. CONFIG_SYS_ options are supposed to be options
and not board specific code. VCxK.c driver you removed by this patch
series did it in more correct way, I think.
What about moving this code to functions which use board specific macros?
These functions should be placed in this new video driver then.

> +
> diff --git a/drivers/video/Makefile b/drivers/video/Makefile
> index bc00852..bb6b5a0 100644
> --- a/drivers/video/Makefile
> +++ b/drivers/video/Makefile
> @@ -36,6 +36,7 @@ COBJS-$(CONFIG_VIDEO_SED13806) += sed13806.o
>  COBJS-$(CONFIG_SED156X) += sed156x.o
>  

Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure

[Peter Tyser]

Hi Rafal,

> > I like the Linux and u-boot-v2 directory layout too the more I think
> > about it too.  How about if I resend this series but with the final
> > directory structure looking like:
> >
> > /arch/$(ARCH)/lib/ >
> > /lib/
> > /
> > /libfdt/
> > /lzma/
> > /lzo/
> >
> > /examples/
> > /api/
> > /standalone/
> 
> Not directly answering your question, but rather a minor naming nit:  
> strictly speaking the 'api' subdir contents are also standalone  
> applications... so the above naming scheme is not clear cut, although  
> I don't have much better suggestions :-) The 'standalone' above use  
> the legacy jumptable calls method, so maybe 'jumptable' dirname would  
> work? Other thoughts?

I see your point.  Its a bit confusing as U-Boot documentation
seems to refer to "Standalone applications" alot, and in general that
documentation is specifically referring jumptable applications.  eg
"doc/README.standalone" and "Standalone HOWTO" in README.  If you dig
you can find the API applications mentioned in api/README - I don't see
it referenced much in either the standard location of /doc/* or /README.
I guess my only point is that it would be great if the application
documentation was consistent between the jumptable and API method, then
it would be a a no brainer as far as naming /examples directory layout.
As is, documentation implies "standalone application" means jumptable
application.

In any case, I'm OK with a different directory layout.  /examples/[api|
jumptable] is fine, or we could even add an apps subdir,
eg: /examples/apps/[api|jumptable].  I'm also fine with leaving it the
way I had it initially as all documentation currently implies standalone
== jumptable, api = API method.

Let me know if you or others have arguments for 1 convention over
another.

Thanks,
Peter



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

Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:37 Sat 18 Jul , Peter Tyser wrote:
> 
> > > I'd vote to get the directory structure changed as desired (in this
> > > release), then integrate the Kconfig-based build system in the next
> > > release once the directory layout is stable.  Jean-Christophe is the
> > > most familiar with the Kbuild system and might have a better idea what
> > > its state is, how hard it would be to adapt to a new directory layout,
> > > etc.  Do you have any input Jean-Christophe?
> > more we will be close to the linux organisation more easier it will be to
> > integrate it and update it
> 
> Your sentence above implies you'd like the directory structure to match
> Linux's BEFORE adding Kconfig support...
> 
> > the only really important think is to merge to KConfig first.
> 
> But this sentence states you'd prefer to change the directory structure
> AFTER adding Kconfig support?
I do not care that much for the Kconfig
but we need to have it before the Kbuild support which is different
> 
> I'd still vote for changing the directory structure in this release,
> then apply the Kconfig changes in the next one.  The same Kconfig files
> you've already made could still be used regardless of directory layout,
> correct?  ie all you'd have to do is change the "source oldpath" to
> "source newpath" in some Kconfig files and maybe update a Makefile or 2?
> 
> In any case, one of us would have to fix up the Kconfig support to work
> with a new directory layout.  In my opinion, if its not hard to update
> the Kconfigs to work with a new directory layout it would make more
> sense for you to do it at the same time as adding Kconfig support
> instead of me making both directory layout and Kconfig changes at the
> same time.
that's fine for me

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

Re: [U-Boot] [PATCH v2 0/6] Clean up top-level directory structure

[Peter Tyser]

> > I'd vote to get the directory structure changed as desired (in this
> > release), then integrate the Kconfig-based build system in the next
> > release once the directory layout is stable.  Jean-Christophe is the
> > most familiar with the Kbuild system and might have a better idea what
> > its state is, how hard it would be to adapt to a new directory layout,
> > etc.  Do you have any input Jean-Christophe?
> more we will be close to the linux organisation more easier it will be to
> integrate it and update it

Your sentence above implies you'd like the directory structure to match
Linux's BEFORE adding Kconfig support...

> the only really important think is to merge to KConfig first.

But this sentence states you'd prefer to change the directory structure
AFTER adding Kconfig support?

I'd still vote for changing the directory structure in this release,
then apply the Kconfig changes in the next one.  The same Kconfig files
you've already made could still be used regardless of directory layout,
correct?  ie all you'd have to do is change the "source oldpath" to
"source newpath" in some Kconfig files and maybe update a Makefile or 2?

In any case, one of us would have to fix up the Kconfig support to work
with a new directory layout.  In my opinion, if its not hard to update
the Kconfigs to work with a new directory layout it would make more
sense for you to do it at the same time as adding Kconfig support
instead of me making both directory layout and Kconfig changes at the
same time.

Anyway, that's my $.02

Peter

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

Re: [U-Boot] [PATCH 2/2] LPC2468 example board

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:54 Tue 28 Apr , Remco Poelstra wrote:
> Added example board for LPC2468 processor
> 
> Signed-off-by: Remco Poelstra  ---
>  From ab9ef1e9c2bd8f04612429461baa5c24dbc52266 Mon Sep 17 00:00:00 2001
> From: Remco Poelstra 
> Date: Tue, 28 Apr 2009 15:04:33 +0200
> Subject: [PATCH] Added example board for LPC2468 processor
> 
> ---
>   board/LPC2468/LPC2468.c  |   65 +
>   board/LPC2468/Makefile   |   55 +
>   board/LPC2468/config.mk  |   29 +++
>   board/LPC2468/flash.c|  255 +++
>   board/LPC2468/lowlevel_init.c|  445 
> ++
>   board/LPC2468/nand.c |   63 +
please add it in an other patch
and please store it in drivers/mtd/nand/
>   board/LPC2468/u-boot.lds |   55 +
>   include/asm-arm/arch-lpc24xx/immap.h |  142 ++-
>   include/configs/LPC2468.h|  220 +
>   9 files changed, 1319 insertions(+), 10 deletions(-)
>   create mode 100644 board/LPC2468/LPC2468.c
>   create mode 100755 board/LPC2468/Makefile
>   create mode 100755 board/LPC2468/config.mk
>   create mode 100644 board/LPC2468/flash.c
>   create mode 100644 board/LPC2468/lowlevel_init.c
>   create mode 100755 board/LPC2468/nand.c
>   create mode 100755 board/LPC2468/u-boot.lds
>   create mode 100644 include/configs/LPC2468.h
> 
> diff --git a/board/LPC2468/LPC2468.c b/board/LPC2468/LPC2468.c
> new file mode 100644
> index 000..498885f
> --- /dev/null
> +++ b/board/LPC2468/LPC2468.c
> @@ -0,0 +1,65 @@
> +/*
> + * (C) Copyright 2002
> + * Sysgo Real-Time Solutions, GmbH 
> + * Marius Groeger 
> + *
> + * (C) Copyright 2005 Rowel Atienza 
> + * Armadillo board HT1070
> + *
> + * 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 
> +#include 
> +
> +/* - 
> */
> +
> +/*
> + * Miscelaneous platform dependent initialisations
> + */
> +
> +int board_init (void)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
> +
> + /* arch number MACH_TYPE_ARMADILLO - not official */
> + gd->bd->bi_arch_number = 1339;
please use proper CONFIG
> +
> + /* location of boot parameters */
> + gd->bd->bi_boot_params = 0xA100;
please use this style
CONFIG_RAM_BASE + 0x100
> +
> + return 0;
> +}
> +
> +int print_cpuinfo (void)
> +{
> + printf ("CPU:   LPC2468 (ARM7tdmi-s from NXP)\n"
> + "   running at 57.6 MHz (12 MHz crystal)\n");
is it possible to detect it?
> + return 0;
> +}
> +
> +int dram_init (void)
> +{
> + DECLARE_GLOBAL_DATA_PTR;
> +
> + gd->bd->bi_dram[0].start = PHYS_SDRAM_1;
> + gd->bd->bi_dram[0].size = PHYS_SDRAM_1_SIZE;
> +
> + return (0);
> +}
> diff --git a/board/LPC2468/Makefile b/board/LPC2468/Makefile
> new file mode 100755
> index 000..19a2cd7
> --- /dev/null

> +TEXT_BASE =  0xA1f8
> diff --git a/board/LPC2468/flash.c b/board/LPC2468/flash.c
> new file mode 100644
> index 000..9d61b43
> --- /dev/null
> +++ b/board/LPC2468/flash.c
Is your flash cfi compatible?
Stefan what do you think?
> @@ -0,0 +1,255 @@
> +/*
> + * (C) Copyright 2006 Embedded Artists AB 
> + *
> + * (C) Copyright 2009 Duran Audio B.V. 
> + *
> + * 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
> + *
> + * 18-03-2009 Updated for U-boot 2009.3
> + * by Remco Poelstra 
> + */
> +

> diff --git a/board/LPC2468/lowlevel_init.c b/board/LPC2468/lowlevel_init.c
> new file mode 1006

[U-Boot] [PATCH] pcm030: fix out-of-tree building

[Wolfgang Denk]

Commit c9969947, which added support for the pcm030 board
(aka phyCORE-MPC5200B-tiny), broke out-of-tree building.

Signed-off-by: Wolfgang Denk 
---
 Makefile |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/Makefile b/Makefile
index 9e6346f..9ff846e 100644
--- a/Makefile
+++ b/Makefile
@@ -698,7 +698,7 @@ o2dnt_config:   unconfig
 
 pcm030_config \
 pcm030_LOWBOOT_config: unconfig
-   @ >include/config.h
+   @ >$(obj)include/config.h
@[ -z "$(findstring LOWBOOT_,$@)" ] || \
{ echo "TEXT_BASE = 0xFF00" 
>$(obj)board/phytec/pcm030/config.tmp ; \
  echo "... with LOWBOOT configuration" ; \
-- 
1.6.0.6

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

Re: [U-Boot] [RFC] CONFIG naming convetion

[Jean-Christophe PLAGNIOL-VILLARD]

On 11:15 Sat 18 Jul , Robin Getz wrote:
> On Sat 18 Jul 2009 07:03, Jean-Christophe PLAGNIOL-VILLARD pondered:
> > Hi all,
> > 
> > Currently we have a mess in the drivers CONFIG naming convention
> > as example on I2C we have
> > CONFIG_I2C_X
> > CONFIG_DRIVER_XXX_I2C
> > CONFIG__I2C
> > CONFIG_SYS_I2C_
> > 
> > I think it will good to have common and clean naming convention
> > so I'll propose we use this one
> > CONFIG_namespace_X
> > and
> > CONFIG_SYS_namespace_X
> > 
> > so it will resutly for I2C to this
> > 
> > CONFIG_I2C_X
> > CONFIG_SYS_I2C_
> > 
> > and the Makefile and KConfig it will be easier to sort and read
> 
> I think this goes way beyond I2C
> 
> There are ~4866 unique options in ./include/configs/*
> 
> Most of which have no name spaces at all, some are not even
> used in any source files (that are in mainline anyway).
> 
> We have 2815, which already start with CONFIG_SYS_xxx, like
> CONFIG_SYS_16M_MBMR  Which is used in a single board:
> 
CONFIG_SYS_
is already well defined
README extract
* Configuration _SETTINGS_:
These depend on the hardware etc. and should not be meddled with if
you don't know what you're doing; they have names beginning with
"CONFIG_SYS_".

so we do not need to touch non subsystem thinks on contrary of i2c, pci, nand 
etc...

> It doesn't appear very "system" oriented to me...
it's as we had reorganise the drivers file place as example or
the common Makefile and continue to do it eveyday (take a look on Peter e-mail
about arch dir)
> 
> It would be nice to come up with some list of namespaces, and what they
> they should be used for...
> 
> For example, should it be:
> CONFIG_DRIVER_OMAP24XX_I2C
> or
> CONFIG_SYS_I2C_DRIVER_OMAP24XX
> or
> CONFIG_DRIVER_I2C_OMAP24XX
DRIVER is really un-nessary IMHO
> 
> Again - which is only used in one place:
> drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
> include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C
> 
> Which is fine - since it is a driver, which I'm sure that people out of tree 
> use.
brake out of tree thinks is really not a problem
I'll never consider out of tree thinks to be an obstacle to move on
> 
> we assumed that it was:
> CONFIG_DRIVER_NAND_BFIN
> 
> but it depends on who added it...
> CONFIG_PATA_BFIN
when you'll write Kconfig
you will have something like this

config  PATA_BFIN
bool "Blackfing Pata driver"
depend on BLACKFIN

> 
> drivers/block/Makefile:COBJS-$(CONFIG_PATA_BFIN) += pata_bfin.o
> include/configs/bf548-ezkit.h:#define CONFIG_PATA_BFIN
> 
> I would think should be CONFIG_DRIVERS_PATA_BFIN
too long at the end

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

Re: [U-Boot] [PATCH 1/1] Add support for Eukrea CPUAT91 SBC

[Jean-Christophe PLAGNIOL-VILLARD]

On 15:24 Thu 16 Jul , Eric Benard wrote:
> CPUAT91 is built around Atmel's AT91RM9200 and has up to 16MB of NOR
> flash, up to 128MB of SDRAM, and includes a Micrel KS8721 PHY in RMII
> mode.
> 
> Signed-off-by: Eric Benard 
> ---
>  MAINTAINERS |6 +-
>  MAKEALL |3 +-
>  Makefile|   16 +++
>  board/eukrea/cpuat91/Makefile   |   50 
>  board/eukrea/cpuat91/config.mk  |1 +
>  board/eukrea/cpuat91/cpuat91.c  |   85 ++
>  cpu/arm920t/at91rm9200/Makefile |5 +-
>  cpu/arm920t/at91rm9200/ks8721.c |  244 
> +++
>  include/configs/cpuat91.h   |  231 
>  include/ks8721.h|   78 +
>  10 files changed, 715 insertions(+), 4 deletions(-)
>  create mode 100644 board/eukrea/cpuat91/Makefile
>  create mode 100644 board/eukrea/cpuat91/config.mk
>  create mode 100644 board/eukrea/cpuat91/cpuat91.c
>  create mode 100644 cpu/arm920t/at91rm9200/ks8721.c
>  create mode 100644 include/configs/cpuat91.h
>  create mode 100644 include/ks8721.h
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 575a7ec..da64571 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1,4 +1,4 @@
> -#
> +9#
>  ##
>  # Regular Maintainers for U-Boot board support:  
> #
>  ##
> @@ -515,6 +515,10 @@ Dirk Behme 
>  
>   omap3_beagleARM CORTEX-A8 (OMAP3530 SoC)
>  
> +Eric Benard 
> +
> + cpcuat91ARM920T
> +
>  Rishi Bhattacharya 
>  
>   omap5912osk ARM926EJS
> diff --git a/MAKEALL b/MAKEALL
> index 020ff73..0e0b657 100755
> --- a/MAKEALL
> +++ b/MAKEALL
> @@ -587,11 +587,12 @@ LIST_at91=" \
>   at91sam9260ek   \
>   at91sam9261ek   \
>   at91sam9263ek   \
> - at91sam9g10ek   \
> + at91sam9g10ek   \
>   at91sam9g20ek   \
>   at91sam9m10g45ek\
>   at91sam9rlek\
>   cmc_pu2 \
> + cpuat91 \
>   csb637  \
>   kb9202  \
>   meesc   \
> diff --git a/Makefile b/Makefile
> index 090e645..02efe1b 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -2683,6 +2683,22 @@ at91rm9200ek_config:   unconfig
>  cmc_pu2_config   :   unconfig
>   @$(MKCONFIG) $(@:_config=) arm arm920t cmc_pu2 NULL at91rm9200
>  
> +xtract_cpuat91 = $(subst _ram,, $(subst _config,,$1))
no need please remove
> +
> +cpuat91_ram_config \
> +cpuat91_config   :   unconfig
> + @if [ "$(findstring _ram_,$@)" ] ; then \
> + echo "#define CONFIG_CPUAT91_RAM 1" >> ./include/config.h ; \
what is this ram config?
what is its goal?
> + fi;
> + @$(MKCONFIG) -a $(call xtract_cpuat91,$@) arm arm920t cpuat91 eukrea 
> at91rm9200
cpuat91 will be enough as you do not use other option
> + @if [ "$(findstring _ram_,$@)" ] ; then \
> + echo "#define CONFIG_CPUAT91_RAM 1" >> ./include/config.h ; \
> + echo "... CPUAT91 configured for RAM !" ; \
> + else \
> + echo "#define CONFIG_BOOTDELAY 1" >> ./include/config.h ;\
> + echo "... CPUAT91 configure for Flash !" ;\
> + fi;
> +
>  csb637_config:   unconfig
>   @$(MKCONFIG) $(@:_config=) arm arm920t csb637 NULL at91rm9200
>  

> diff --git a/cpu/arm920t/at91rm9200/Makefile b/cpu/arm920t/at91rm9200/Makefile
> index 73aeeac..114d8ad 100644
> --- a/cpu/arm920t/at91rm9200/Makefile
> +++ b/cpu/arm920t/at91rm9200/Makefile
> @@ -31,14 +31,15 @@ COBJS += bcm5221.o
>  COBJS+= dm9161.o
>  COBJS+= ether.o
>  COBJS+= i2c.o
> +COBJS-$(CONFIG_KS8721_PHY)   += ks8721.o
>  COBJS+= lxt972.o
>  COBJS+= reset.o
>  COBJS+= spi.o
>  COBJS+= timer.o
>  COBJS+= usb.o
>  
> -SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
> -OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS))
> +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) $(COBJS-y:.o=.c)
> +OBJS := $(addprefix $(obj),$(SOBJS) $(COBJS) $(COBJS-y))
>  
>  all: $(obj).depend $(LIB)
>  
> diff --git a/cpu/arm920t/at91rm9200/ks8721.c b/cpu/arm920t/at91rm9200/ks8721.c
> new file mode 100644
> index 000..703e58c
> --- /dev/null
> +++ b/cpu/arm920t/at91rm9200/ks8721.c
> @@ -0,0 +1,244 @@
> +/*
> + * (C) Copyright 2006
> + * Author : Eric Benard (Eukrea Electromatique)
> + * based on dm9161.c which is :
> + * (C) Copyright 2003
> + * Author : Hamid Ikdoumi (Atmel)
I'm not a fan of this implementation at all

but as I've not yet finish the rm9200 cleanup
I'll ack this ben what do you think?
ben please note that the rm9200 cleanup will intro

Re: [U-Boot] Using Uboot to communicate a PCI device.

[dwh]

Hi Darshan,

> Cavium's U-boot version included has been modified to support
> multicore OCTEON processors. The 'bootoct' command has been
> added, which supports the booting of an Octeon simple
> executive application.

Ok. Since the processor is already supported in U-Boot,
your life is much easier.

> In my case I dont have any OS on the board

Ok.

> U-boot is responsible for loading applications into
> the Octeon Memory space.

Ok.

> But i have heard that Uboot(inside Octeon) can be modified
> to communicate to a device.

If the other processors are in the address space of the
Octeon processor, or if an Octeon PCI window can be moved
to overlay each of the NPs, then host read/write accesses
can be used to initialize the slave NPs. There is no
additional 'communication' code needed.

> Since No OS such as Linux exists, Cavium's U-Boot will initialize the
> processor itself (As a Simple Executive) along with its PCI interface
> initialization is also done. Now, how should i go ahead in talking to the
> Winpath NP for doing a task. For eg, Copying the Winpath Boot Image onto
> the NP via the PCI interface?

Once the NP PCI interface is configured and enabled, you
should be able to use read/write accesses on your host that
hit the PCI addresses corresponding to the NP.

As an analogy, we have a single x86 host processor in a cPCI
interface with 15 PowerPC boards plugged into the backplane.
The host BIOS initializes the PCI interfaces on the PowerPC boards
and enables them. On the PowerPCs, if U-Boot has not been
installed, a default PCI window is setup, and if U-Boot is
installed a custom setting is used (the local-side PCI
initialization completes before the x86 BIOS enables the
interfaces). As far as the x86 host is concerned, each
PowerPC appears as at least two windows in the PCI space;
one window is a set of PowerPC control registers, and
another window points to an arbitrary address in the
PowerPC memory map. Manipulation of a control register
changes the base address, so the window can be moved around.

Your NPs should have something similar. The host's U-Boot can
initialize the PCI interfaces on the NPs, and then later your
U-Boot 'NP boot' command (U-boot application) can use the PCI
interface registers to move the window around while copying
application code into the NP memory space. You would need
to have access via PCI to NP control registers too, so that
you can release the NP core from reset and allow it to boot
from the application code your host just copied into its
address space.

Based on your current understanding of the processors,
does any of this sound possible?

> The Winpath has a similar U-boot*-like* bootloader to boot
> up the processor... since it doesn't have tftp or flash
> interface for copying the bootloader image... Cavium has
> to do this task via its PCI interface.
> Cavium's task is to load Wintegra NP's Bootloader into the
> memory space of Wintegra so that WinPath boots itself and
> further all the applications that Winpath has to run shall
> be "loaded" to Winpath into its memory addresses. The
> bottomline is Winapth NP does not have direct access to
> TFTP/Flash for loading the applications or even the
> bootloader, it has to do it via the Cavium on the PCI interface.

Ok. This is should be no problem.

These devices are 'network processors'. Do they have a direct
network connection, or do they get all their network data
via the host processor?

The host can copy all data into the NP memory space, however,
once the NP is booted, you will want some form of commincations;
which is what you are asking. However, there are more questions:

- Cavium host boots U-Boot
- NP boots Winpath NP bootloader

Do you have access to the source code for the NP bootloader
so that you can implement both ends of the communication path?

Depending on the complexity needed, the communications can
be as simple as an interlock to indicate to the NP that a
new application is needed, or it can be as complex as
an emulated serial-port-over-PCI and network-over-PCI as
demonstrated in Ira's drivers.

> Since Cavium's Octeon and Wintegra's Winpath are 'sitting' on the same
> board as two chips they cant communicate over the network.

Why not? It doesn't matter where they are sitting if they
both have a network interface. However, I assume you mean
they do not have an external connection via the network.

> I hope i am much clearer this time.

We're getting there :)

Is there any documentation on the boards you are working on
that is available online? At a minimum links to the Cavium
and NP data sheets would be useful.

Cheers,
Dave


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

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

[Jean-Christophe PLAGNIOL-VILLARD]

> +
> +#ifdef CONFIG_DISPLAY_BOARDINFO
> +int checkboard(void)
> +{
> + char buf[32];
> +
> + printf("Board : Eukrea Electromatique CPU9260\n");
> + printf("Crystal frequency: %8s MHz\n",
> + strmhz(buf, get_main_clk_rate()));
> + printf("CPU clock: %8s MHz\n",
> + strmhz(buf, get_cpu_clk_rate()));
> + printf("Master clock : %8s MHz\n",
> + strmhz(buf, get_mck_clk_rate()));
please use CONFIG_DISPLAY_CPUINFO
> + printf("\n");
> + return 0;
> +}
> +#endif

> diff --git a/cpu/arm926ejs/at91/lowlevel_init.S 
> b/cpu/arm926ejs/at91/lowlevel_init.S
> index 5ed518c..9962ae9 100644
> --- a/cpu/arm926ejs/at91/lowlevel_init.S
> +++ b/cpu/arm926ejs/at91/lowlevel_init.S
> @@ -194,7 +194,7 @@ SMRDATA:
>   .word CONFIG_SYS_PIOD_PPUDR_VAL
>   .word (AT91_BASE_SYS + AT91_PIOD + PIO_ASR)
>   .word CONFIG_SYS_PIOD_PPUDR_VAL
> -#elif defined(CONFIG_AT91SAM9261)
> +#elif defined(CONFIG_AT91SAM9260) || defined(CONFIG_AT91SAM9261)
please do this in a separate patch
>   .word (AT91_BASE_SYS + AT91_PIOC + PIO_PDR)
>   .word CONFIG_SYS_PIOC_PDR_VAL1
>   .word (AT91_BASE_SYS + AT91_PIOC + PIO_PUDR)

> +
> +/* NAND flash */
> +#define CONFIG_NAND_ATMEL1
> +#define NAND_MAX_CHIPS   1
> +#define CONFIG_SYS_MAX_NAND_DEVICE   1
> +#define CONFIG_SYS_NAND_BASE 0x4000
> +#define CONFIG_SYS_NAND_DBW_81
> +#undef  CONFIG_SYS_NAND_DBW_16
please remove if no-need
> +#define CONFIG_SYS_NAND_READY_PINAT91_PIN_PC13
> +#define CONFIG_SYS_NAND_ENABLE_PIN   AT91_PIN_PC14
> +#define CONFIG_SYS_NAND_MASK_ALE (1 << 21)
> +#define CONFIG_SYS_NAND_MASK_CLE (1 << 22)
> +
> +/* NOR flash */
> +#define CONFIG_SYS_FLASH_CFI 1
> +#define CONFIG_FLASH_CFI_DRIVER  1
> +#define PHYS_FLASH_1 0x1000
> +#define PHYS_FLASH_2 0x1200
> +#define CONFIG_SYS_FLASH_BANKS_LIST  \
> + { PHYS_FLASH_1, PHYS_FLASH_2 }
> +#define CONFIG_SYS_FLASH_BASEPHYS_FLASH_1
> +#define CONFIG_SYS_MAX_FLASH_SECT(255+4)
> +#define CONFIG_SYS_MAX_FLASH_BANKS   2
> +#define CONFIG_SYS_FLASH_CFI_WIDTH   FLASH_CFI_16BIT
> +#define CONFIG_SYS_FLASH_EMPTY_INFO  1
> +#define CONFIG_SYS_FLASH_USE_BUFFER_WRITE1
> +#define CONFIG_SYS_FLASH_PROTECTION  1
> +#define CONFIG_SYS_MONITOR_BASE  PHYS_FLASH_1
> +

> +#undef CONFIG_SYS_USE_NANDFLASH
> +#define CONFIG_SYS_USE_FLASH 1
> +
> +#if defined(CONFIG_SYS_USE_FLASH)
> +#define CONFIG_ENV_IS_IN_FLASH   1
> +#define CONFIG_ENV_OFFSET0x4
> +#define CONFIG_ENV_SECT_SIZE 0x2
> +#define  CONFIG_ENV_SIZE 0x2
> +#define CONFIG_ENV_OVERWRITE 1
> +
> +#define CONFIG_BOOTCOMMAND   "run flashboot"
> +
> +#define MTDIDS_DEFAULT   
> "nor0=physmap-flash.0,nand0=nand"
> +#define MTDPARTS_DEFAULT \
> + "mtdparts=physmap-flash.0:" \
> + "256k(u-boot)ro,"   \
> + "128k(u-boot-env)ro,"   \
> + "1792k(kernel),"\
> + "-(rootfs);"\
> + "nand:-(nand)"
> +
> +#define CONFIG_BOOTARGS "root=/dev/mtdblock3 rootfstype=jffs2 "
> +
> +#define CONFIG_EXTRA_ENV_SETTINGS\
> + "mtdids=" MTDIDS_DEFAULT "\0"   \
> + "mtdparts=" MTDPARTS_DEFAULT "\0"   \
> + "partition=nand0,0\0"   \
> + "ramargs=setenv bootargs $(bootargs) $(mtdparts)\0" \
> + "ramboot=tftpboot 0x2200 cpu9260/uImage;"   \
> + "run ramargs;bootm 2200\0"  \
> + "flashboot=run ramargs;bootm 0x1006\0"  \
> + "updtub=tftp 0x2400 cpu9260/u-boot.bin;protect off" \
> + " 0x1000 0x1003;erase 0x1000 "  \
> + "0x1003;cp.b 0x2400 0x1000 "\
> + "$(filesize)\0" \
> + "updtui=tftp 0x2400 cpu9260/uImage;protect off" \
> + " 0x1006 0x1021;erase 0x1006 "  \
> + "0x1021;cp.b 0x2400 0x1006 "\
> + "$(filesize)\0" \
> + "updtrfs=tftp 0x2400 cpu9260/rootfs.jffs2;protect " \
> + "off 0x1022 0x13ff;erase 0x1022 "   \
> + "0x13ff;cp.b 0x2400 0x1022 "\
> + "$(filesize)\0" \
> + ""
> +#else
> +#error "Undefined memory device"
why?
> +#endif
> +
> +#define CONFIG_BAUDRATE  115200
> +#define CONFIG_SYS_BAUDRATE_TABLE{115200 , 19200, 38400, 57600, 9600 }
> +
> +#define CONFIG_SYS_PR

Re: [U-Boot] [RFC] CONFIG naming convetion

[Robin Getz]

On Sat 18 Jul 2009 07:03, Jean-Christophe PLAGNIOL-VILLARD pondered:
> Hi all,
> 
>   Currently we have a mess in the drivers CONFIG naming convention
>   as example on I2C we have
>   CONFIG_I2C_X
>   CONFIG_DRIVER_XXX_I2C
>   CONFIG__I2C
>   CONFIG_SYS_I2C_
> 
>   I think it will good to have common and clean naming convention
>   so I'll propose we use this one
>   CONFIG_namespace_X
>   and
>   CONFIG_SYS_namespace_X
> 
>   so it will resutly for I2C to this
> 
>   CONFIG_I2C_X
>   CONFIG_SYS_I2C_
> 
>   and the Makefile and KConfig it will be easier to sort and read

I think this goes way beyond I2C

There are ~4866 unique options in ./include/configs/*

Most of which have no name spaces at all, some are not even
used in any source files (that are in mainline anyway).

We have 2815, which already start with CONFIG_SYS_xxx, like
CONFIG_SYS_16M_MBMR  Which is used in a single board:

board/snmc/qs860t/qs860t.c: memctl->memc_mbmr = CONFIG_SYS_16M_MBMR;
board/snmc/qs860t/qs860t.c: size = dram_size (CONFIG_SYS_16M_MBMR, (long 
*)SDRAM_BASE, SDRAM_16M_MAX_SIZE);
include/configs/QS860T.h:#define CONFIG_SYS_16M_MBMR0x18802114  
/* Mem Periodic Timer Prescaler */

It doesn't appear very "system" oriented to me...

It would be nice to come up with some list of namespaces, and what they
they should be used for...

For example, should it be:
CONFIG_DRIVER_OMAP24XX_I2C
or
CONFIG_SYS_I2C_DRIVER_OMAP24XX
or
CONFIG_DRIVER_I2C_OMAP24XX

Again - which is only used in one place:
drivers/i2c/Makefile:COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
include/configs/omap2420h4.h:#define CONFIG_DRIVER_OMAP24XX_I2C

Which is fine - since it is a driver, which I'm sure that people out of tree 
use.

we assumed that it was:
CONFIG_DRIVER_NAND_BFIN

but it depends on who added it...
CONFIG_PATA_BFIN

drivers/block/Makefile:COBJS-$(CONFIG_PATA_BFIN) += pata_bfin.o
include/configs/bf548-ezkit.h:#define CONFIG_PATA_BFIN

I would think should be CONFIG_DRIVERS_PATA_BFIN

?


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

Re: [U-Boot] [PATCH V2] ppc4xx: Add 405EP based PMC405DE board

[Matthias Fuchs]

Hi Wolfgang and Stefan,

Wolfgang Denk schrieb:
> Of course you can. The cure is simple:
> 
> Fix "include/ppc405.h" so we get rid of this silly  "base  address  +
> offset" notation and use proper C structures instead.
> 
> 
> Oh, and while we are at it - "include/ppc440.h" has more of this stuff
> that is waiting for cleanup. But that is another story, not related to
> your patch - maybe Stefan picks up this ball :-)
> 
> 
>> We could put the cast into the GPIO_IR (and friends) definitions.
> 
> No cast is needed. Just use proper C structs.
> 
>> Do you want me to remove the cast and life with a compiler warning until
>> this has been globally fixed?
> 
> No, of course not.
> 
>> Because this is not a particular problem with this patch it should be
>> addressed in a separate discussion. But you are rigth - this cast is
>> a little bit nerving :-)
> 
> I agree - the cleanup patch should be submitted first.
Do you want to see something like this (see below)?

I ran into the problem that include/ppc405.h defines a macro "tcr".
This conflicts with tcr in my gpio_controller struct.

When this kind of structure and it's usage is ok,
I will provide a clean patch that adds the struct
and a revised path for adding the PMC405DE board support.

I hope you do make adding PMC405DE board support dependant from
fixing all casts with io accessor macros :-(

Matthias

---
  board/esd/pmc405de/pmc405de.c |   30 +-
  include/asm-ppc/gpio.h|   24 
  2 files changed, 45 insertions(+), 9 deletions(-)

diff --git a/board/esd/pmc405de/pmc405de.c b/board/esd/pmc405de/pmc405de.c
index 9c1a119..789e326 100644
--- a/board/esd/pmc405de/pmc405de.c
+++ b/board/esd/pmc405de/pmc405de.c
@@ -26,10 +26,20 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  #include 
  #include 

+struct pmc405de_cpld {
+   u8 version;
+   u8 reserved0[3];
+   u8 status;
+   u8 reserved1[3];
+   u8 control;
+   u8 reserved2[3];
+};
+
  #define CPLD_VERSION  (CONFIG_SYS_CPLD_BASE + 0)
  #define CPLD_VERSION_MASK 0x0f
  #define CPLD_STATUS   (CONFIG_SYS_CPLD_BASE + 4)
@@ -120,22 +130,24 @@ static void upd_plb_pci_div(u32 pllmr0, u32 
pllmr1, u32 div)
  int misc_init_r(void)
  {
int i;
+   struct ppc4xx_gpio_controller *gpio0 = (struct ppc4xx_gpio_controller 
*)GPIO_BASE;
+   struct pmc405de_cpld *cpld = (struct pmc405de_cpld 
*)CONFIG_SYS_CPLD_BASE;

if (!is_monarch()) {
/* PCI configuration done: release EREADY */
-   out_be32((void*)GPIO0_OR,
-in_be32((void*)GPIO0_OR) | CONFIG_SYS_GPIO_EREADY);
-   out_be32((void*)GPIO0_TCR,
-in_be32((void*)GPIO0_TCR) | CONFIG_SYS_GPIO_EREADY);
+   out_be32(&gpio0->or,
+in_be32(&gpio0->or) | CONFIG_SYS_GPIO_EREADY);
+   out_be32(&gpio0->_tcr,
+in_be32(&gpio0->_tcr) | CONFIG_SYS_GPIO_EREADY);
}

/* turn off POST LED */
-   out_8((void*)CPLD_CONTROL,
+   out_8(&cpld->control,
  CPLD_CONTROL_POSTLED_N | CPLD_CONTROL_POSTLED_GATE);

/* turn on LEDs: RUN, A, B */
-   out_be32((void*)GPIO0_OR,
-in_be32((void*)GPIO0_OR) &
+   out_be32(&gpio0->or,
+in_be32(&gpio0->or) &
 ~(CONFIG_SYS_GPIO_LEDRUN_N |
   CONFIG_SYS_GPIO_LEDA_N |
   CONFIG_SYS_GPIO_LEDB_N));
@@ -144,8 +156,8 @@ int misc_init_r(void)
udelay(1000);

/* turn off LEDs: A, B */
-   out_be32((void*)GPIO0_OR,
-in_be32((void*)GPIO0_OR) |
+   out_be32(&gpio0->or,
+in_be32(&gpio0->or) |
 (CONFIG_SYS_GPIO_LEDA_N |
  CONFIG_SYS_GPIO_LEDB_N));

diff --git a/include/asm-ppc/gpio.h b/include/asm-ppc/gpio.h
index fc05dc0..2dfbad7 100644
--- a/include/asm-ppc/gpio.h
+++ b/include/asm-ppc/gpio.h
@@ -24,6 +24,8 @@
  #ifndef __ASM_PPC_GPIO_H
  #define __ASM_PPC_GPIO_H

+#include 
+
  /* 4xx PPC's have 2 GPIO controllers */
  #if defined(CONFIG_405EZ) ||  \
defined(CONFIG_440EP) || defined(CONFIG_440GR) ||   \
@@ -34,6 +36,28 @@
  #define GPIO_GROUP_MAX1
  #endif

+/* GPIO controller */
+struct ppc4xx_gpio_controller {
+   u32 or;
+   u32 _tcr;
+   u32 osl;
+   u32 osh;
+   u32 tsl;
+   u32 tsh;
+   u32 odr;
+   u32 ir;
+   u32 rr1;
+   u32 rr2;
+   u32 rr3;
+   u32 reserved;
+   u32 is1l;
+   u32 is1h;
+   u32 is2l;
+   u32 is2h;
+   u32 is3l;
+   u32 is3h;
+};
+
  /* Offsets */
  #define GPIOx_OR  0x00/* GPIO Output Register */
  #define GPIOx_TCR 0x04/* GPIO Three-State Control Register */
-- 
1.6.1


___
U-Boot mailing list
U-Boot@lists.denx.de
ht