Re: [U-Boot] [PATCH] ubi: help message correction

[Stefan Roese]

On Friday 17 July 2009 22:26:54 Andrzej Wolski wrote:
> Fix incorrect information about size units and correct typo.
>
> Signed-off-by: Andrzej Wolski 

Patch didn't apply clean. I fixed this manually. So, applied to u-boot-ubi.

Thanks.

Best regards,
Stefan

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

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

[Stefan Roese]

The following changes since commit b86b85e2611d57d834795a92453431a1a340c3c9:
  Ilya Yanok (1):
mmc: set bus width to 1 and clock to minimum early during initialization

are available in the git repository at:

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

Andrzej Wolski (1):
  ubi: help message correction

 common/cmd_ubi.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Heiko Schocher]

Hello Alessandro,

Alessandro Rubini wrote:
> This adds gpio and i2c support for the Nomadik evaluation kit. They
> are needed to turn on the LCD backlight in order to later add LCD
> support.
> 
> I have one doubt and some questions on gpio:
> 
> To use soft_i2c I need to define some macros in the config file.
> Instead of writing hard numbers there I called the gpio functions, but
> the config file is inluded from asm sources as well.  I don't think my
> approach is beautiful at all (both #ifndef __ASSEMBLY__ and #include
> "../board/"), but I didn't find a better solution.

Yes, thats a problem ... if we had a GPIO Framework it would be solved
by including gpio.h ...

Or, maybe, we can make a soft_i2c.h which which gets only included
if saying CONFIG_I2C_SOFT_INCLUDE is defined. soft_i2c.h defines for
example:

#define I2C_SDA(x)  i2c_soft_sda(bit)

void i2c_soft_sda(int pin);

and you can define this function i2c_soft_sda(int pin) in your board
specific code ... maybe a cleaner option?

to speak in c, I tried the following patch on the suen3 plattform,
where I have actually a similiar problem, and this worked fine :-)

[PATCH] i2c, soft: added soft_i2c.h

In case you must define functions for the I2C_XXX
defines, it is necessary to have a soft_i2c.h, which
defines functions for this macros. This functions can
then be programmed in board specific code. To activate
this it must be CONFIG_I2C_SOFT_INCLUDE defined in the
board config file.

Signed-off-by: Heiko Schocher 
---
 drivers/i2c/soft_i2c.c |3 +++
 include/soft_i2c.h |   16 
 2 files changed, 19 insertions(+), 0 deletions(-)
 create mode 100644 include/soft_i2c.h

diff --git a/drivers/i2c/soft_i2c.c b/drivers/i2c/soft_i2c.c
index 59883a5..30e24f3 100644
--- a/drivers/i2c/soft_i2c.c
+++ b/drivers/i2c/soft_i2c.c
@@ -43,6 +43,9 @@
 #if defined(CONFIG_MPC852T) || defined(CONFIG_MPC866)
 #include 
 #endif
+#if defined(CONFIG_SOFT_I2C_INCLUDE)
+#include 
+#endif
 #include 

 /* #define DEBUG_I2C   */
diff --git a/include/soft_i2c.h b/include/soft_i2c.h
new file mode 100644
index 000..39f9a35
--- /dev/null
+++ b/include/soft_i2c.h
@@ -0,0 +1,16 @@
+#ifndef _CONFIG_SOFT_I2C
+#define _CONFIG_SOFT_I2C
+#define I2C_ACTIVE i2c_soft_active();
+#define I2C_TRISTATE   i2c_soft_tristate();
+#define I2C_READ   i2c_soft_read();
+#define I2C_SDA(bit)   i2c_soft_sda(bit);
+#define I2C_SCL(bit)   i2c_soft_scl(bit);
+#defineI2C_DELAY   i2c_soft_delay();
+
+void   i2c_soft_active(void);
+void   i2c_soft_tristate(void);
+inti2c_soft_read(void);
+void   i2c_soft_sda(int value);
+void   i2c_soft_scl(int value);
+void   i2c_soft_delay(void);
+#endif
-- 
1.6.0.GIT

Maybe you can try it too?

> I would like to add a gpio command, and I've found no generic gpio
> stuff.  Only one board (cm-bf527) has a gpio commands, but quite a few
> have similar commands to set leds or other bits.  Is time ripe for a
> generic gpio driver with board-specific limits and operations? Would
> that be interesting for u-boot-next?  Should I process with a board-specific
> gpio command by now?

I vote for making a gpio framework, but that will take a while I think ...
Hmm.. maybe we use my proposal for such a soft_i2c.h, so I think, it is
okay for such a board specific gpio (unless we have a gpio framework).

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] U-Boot doesn't compile for M54455EVB_intel_config

[Matthew Lear]

Thanks TsiChung. That did the trick.
--  Matt

TC Liew wrote:
> Matt,
> 
> In asm-m68k/io.h, please add
> 
> #ifndef _IO_BASE
> #define _IO_BASE 0
> #endif
> 
> Regards,
> TsiChung
> 
> On Wed, Jul 15, 2009 at 9:43 AM, Matthew Lear wrote:
>> Hi TsiChung / Wolfgang,
>>
>> I just pulled u-boot.git to re-sync and tried to configure and build it
>> for M54455EVB_intel_config but the compilation failed. I tried a fresh
>> clone just to be sure and it was the same.
>>
>> [snip]
>>
>> m68k-linux-gnu-gcc  -g  -Os   -ffixed-d7 -msep-data -D__KERNEL__
>> -DTEXT_BASE=0x -I/home/matt/nht/git-uboot-master/u-boot/include
>> -fno-builtin -ffreestanding -nostdinc -isystem
>> /opt/freescale/usr/local/gcc-4.2.35-eglibc-2.5.35/m68k-linux/lib/gcc/m68k-linux-gnu/4.2.0/include
>> -pipe  -DCONFIG_M68K -D__M68K__ -mcpu=54455 -fPIC -DTEXT_BASE=0x
>> -Wall -Wstrict-prototypes -fno-stack-protector   -o cmd_ide.o cmd_ide.c -c
>> cmd_ide.c: In function '__ide_outb':
>> cmd_ide.c:529: error: '_IO_BASE' undeclared (first use in this function)
>> cmd_ide.c:529: error: (Each undeclared identifier is reported only once
>> cmd_ide.c:529: error: for each function it appears in.)
>> cmd_ide.c: In function '__ide_inb':
>> cmd_ide.c:538: error: '_IO_BASE' undeclared (first use in this function)
>> cmd_ide.c: In function 'output_data':
>> cmd_ide.c:942: error: '_IO_BASE' undeclared (first use in this function)
>> cmd_ide.c: In function 'input_data':
>> cmd_ide.c:1000: error: '_IO_BASE' undeclared (first use in this function)
>> cmd_ide.c: In function 'output_data_shorts':
>> cmd_ide.c:1705: error: '_IO_BASE' undeclared (first use in this function)
>> cmd_ide.c: In function 'input_data_shorts':
>> cmd_ide.c:1711: error: '_IO_BASE' undeclared (first use in this function)
>> make[1]: *** [cmd_ide.o] Error 1
>> make[1]: Leaving directory `/home/matt/nht/git-uboot-master/u-boot/common'
>> make: *** [common/libcommon.a] Error 2
>>
>>
>> Is this expected at the current time?
>>
>> Rgds,
>> --  Matt
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>

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

Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Alessandro Rubini,
> 
> In message  you wrote:
>> To use soft_i2c I need to define some macros in the config file.
>> Instead of writing hard numbers there I called the gpio functions, but
>> the config file is inluded from asm sources as well.  I don't think my
>> approach is beautiful at all (both #ifndef __ASSEMBLY__ and #include
>> "../board/"), but I didn't find a better solution.
> 
> Agreed. It's a bit intricate to get this done, but I don't see a
> better way either.

Hmm.. maybe my previous patch is a better solution?

>> I would like to add a gpio command, and I've found no generic gpio
>> stuff.  Only one board (cm-bf527) has a gpio commands, but quite a few
>> have similar commands to set leds or other bits.  Is time ripe for a
>> generic gpio driver with board-specific limits and operations? Would
>> that be interesting for u-boot-next?  Should I process with a board-specific
>> gpio command by now?
> 
> Well, my opinion on that is a clear "yes, but..." :-)
> 
> Yes, some generic gpio framework would be nice - for example,  if  it
> would allow us to get rid of the 14 largely similar "led.c" files, to
> name just one.
> 
> On the other hand, the design of such a framework should be lean  and
> not  necessarily  try  to  cover 100% of all possible use cases - I'd
> rather have a small and beautiful solution that  covers  90%  of  the
> cases  and use board-specific exceptions where really needed, instead
> of a fat thing that solves each and every problem but costs 50 kB.

Agreed. So we need an gpio_core.c / .h which defines the following
functions (just a proposal):

typedef struct gpio_adapter {
int (*init_pin)(int pin);
int (*set)(int pin, value);
int (*get)(int pin);
int (*dir)(int pin, int direction); 
int (*level)(int pin, int level);
}

int gpio_init(gpio_adapter *adap);
int gpio_init_pin(pin);
? maybe with setting a marker, that this pin is initialized,
  so this can be checked in the above functions ... ?
int gpio_set(pin, value);
int gpio_get(pin);
int gpio_dir(pin, dir);
int gpio_level(pin, dir);

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

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

[Heiko Schocher]

Signed-off-by: Heiko Schocher 
---
- changes since v1:
  added comments from Prafulla Wadaskar
- changes since v2
  added comments from Jean-Christophe
  - added speed setting

 drivers/i2c/Makefile   |1 +
 drivers/i2c/kirkwood_i2c.c |  484 
 2 files changed, 485 insertions(+), 0 deletions(-)
 create mode 100644 drivers/i2c/kirkwood_i2c.c

diff --git a/drivers/i2c/Makefile b/drivers/i2c/Makefile
index ef32f13..4a12976 100644
--- a/drivers/i2c/Makefile
+++ b/drivers/i2c/Makefile
@@ -28,6 +28,7 @@ LIB   := $(obj)libi2c.a
 COBJS-$(CONFIG_BFIN_TWI_I2C) += bfin-twi_i2c.o
 COBJS-$(CONFIG_DRIVER_DAVINCI_I2C) += davinci_i2c.o
 COBJS-$(CONFIG_FSL_I2C) += fsl_i2c.o
+COBJS-$(CONFIG_I2C_KIRKWOOD) += kirkwood_i2c.o
 COBJS-$(CONFIG_I2C_MXC) += mxc_i2c.o
 COBJS-$(CONFIG_DRIVER_OMAP1510_I2C) += omap1510_i2c.o
 COBJS-$(CONFIG_DRIVER_OMAP24XX_I2C) += omap24xx_i2c.o
diff --git a/drivers/i2c/kirkwood_i2c.c b/drivers/i2c/kirkwood_i2c.c
new file mode 100644
index 000..dd30499
--- /dev/null
+++ b/drivers/i2c/kirkwood_i2c.c
@@ -0,0 +1,484 @@
+/*
+ * Driver for the i2c controller on the Marvell line of host bridges
+ * (e.g, gt642[46]0, mv643[46]0, mv644[46]0, Orion SoC family),
+ * and Kirkwood family.
+ *
+ * Based on:
+ * Author: Mark A. Greer 
+ *
+ * 2005 (c) MontaVista, Software, Inc.  This file is licensed under
+ * the terms of the GNU General Public License version 2.  This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ *
+ * ported from Linux to u-boot
+ * (C) Copyright 2009
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de.
+ *
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+static unsigned int i2c_bus_num __attribute__ ((section (".data"))) = 0;
+#if defined(CONFIG_I2C_MUX)
+static unsigned int i2c_bus_num_mux __attribute__ ((section ("data"))) = 0;
+#endif
+
+/* Register defines */
+#defineKW_I2C_REG_SLAVE_ADDR   0x00
+#defineKW_I2C_REG_DATA 0x04
+#defineKW_I2C_REG_CONTROL  0x08
+#defineKW_I2C_REG_STATUS   0x0c
+#defineKW_I2C_REG_BAUD 0x0c
+#defineKW_I2C_REG_EXT_SLAVE_ADDR   0x10
+#defineKW_I2C_REG_SOFT_RESET   0x1c
+
+#defineKW_I2C_REG_CONTROL_ACK  0x0004
+#defineKW_I2C_REG_CONTROL_IFLG 0x0008
+#defineKW_I2C_REG_CONTROL_STOP 0x0010
+#defineKW_I2C_REG_CONTROL_START0x0020
+#defineKW_I2C_REG_CONTROL_TWSIEN   0x0040
+#defineKW_I2C_REG_CONTROL_INTEN0x0080
+
+/* Ctlr status values */
+#defineKW_I2C_STATUS_BUS_ERR   0x00
+#defineKW_I2C_STATUS_MAST_START0x08
+#defineKW_I2C_STATUS_MAST_REPEAT_START 0x10
+#defineKW_I2C_STATUS_MAST_WR_ADDR_ACK  0x18
+#defineKW_I2C_STATUS_MAST_WR_ADDR_NO_ACK   0x20
+#defineKW_I2C_STATUS_MAST_WR_ACK   0x28
+#defineKW_I2C_STATUS_MAST_WR_NO_ACK0x30
+#defineKW_I2C_STATUS_MAST_LOST_ARB 0x38
+#defineKW_I2C_STATUS_MAST_RD_ADDR_ACK  0x40
+#defineKW_I2C_STATUS_MAST_RD_ADDR_NO_ACK   0x48
+#defineKW_I2C_STATUS_MAST_RD_DATA_ACK  0x50
+#defineKW_I2C_STATUS_MAST_RD_DATA_NO_ACK   0x58
+#defineKW_I2C_STATUS_MAST_WR_ADDR_2_ACK0xd0
+#defineKW_I2C_STATUS_MAST_WR_ADDR_2_NO_ACK 0xd8
+#defineKW_I2C_STATUS_MAST_RD_ADDR_2_ACK0xe0
+#defineKW_I2C_STATUS_MAST_RD_ADDR_2_NO_ACK 0xe8
+#defineKW_I2C_STATUS_NO_STATUS 0xf8
+
+/* Driver states */
+enum {
+   KW_I2C_STATE_INVALID,
+   KW_I2C_STATE_IDLE,
+   KW_I2C_STATE_WAITING_FOR_START_COND,
+   KW_I2C_STATE_WAITING_FOR_ADDR_1_ACK,
+   KW_I2C_STATE_WAITING_FOR_ADDR_2_ACK,
+   KW_I2C_STATE_WAITING_FOR_SLAVE_ACK,
+   KW_I2C_STATE_WAITING_FOR_SLAVE_DATA,
+};
+
+/* Driver actions */
+enum {
+   KW_I2C_ACTION_INVALID,
+   KW_I2C_ACTION_CONTINUE,
+   KW_I2C_ACTION_SEND_START,
+   KW_I2C_ACTION_SEND_ADDR_1,
+   KW_I2C_ACTION_SEND_ADDR_2,
+   KW_I2C_ACTION_SEND_DATA,
+   KW_I2C_ACTION_RCV_DATA,
+   KW_I2C_ACTION_RCV_DATA_STOP,
+   KW_I2C_ACTION_SEND_STOP,
+};
+
+/* defines to get compatible with Linux driver */
+#define IRQ_NONE   0x0
+#define IRQ_HANDLED0x01
+
+#define I2C_M_TEN  0x01
+#define I2C_M_RD   0x02
+#defineI2C_M_REV_DIR_ADDR  0x04;
+
+struct i2c_msg {
+   u32 addr;
+   u32 flags;
+   u8  *buf;
+   u32 len;
+};
+
+struct kirkwood_i2c_data {
+   int irq;
+   u32 state;
+   u32 action;
+   u32 

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

[Alessandro Rubini]

>> > > 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.

What about "DRV" or even "D" if you insist?   CONFIG_D_I2C_SOFT ?

I personally find the config files pretty unreadable. Options that
enable a driver should be different from those that select a
behaviour, in my opinion.

While people responsible for their board know all the stuff they
wrote, but when someone undergoes a more general code change several or
all config files must be checked. A driver namespace would help, in my
opionion.

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

Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Alessandro Rubini]

> Agreed. So we need an gpio_core.c / .h which defines the following
> functions (just a proposal):

Yes.

> typedef struct gpio_adapter {
>   int (*init_pin)(int pin);
>   int (*set)(int pin, value);
>   int (*get)(int pin);
>   int (*dir)(int pin, int direction); 
>   int (*level)(int pin, int level);
> }

I don't understand the init_pin function, nor what "level" is.
Actually, even "dir" can be dropped: a get configures as input, a set
configures as output, the extra instruction is very little overhead.

But an alternate function configuration is definitely needed: everybody
has alternate functions associated to the pins. Just say "0" is gpio
and 1...n is SoC-specific.

So, are you going to write it? Or should someone else do that?

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

[U-Boot] Problem booting Linux from Flash

[Rahanesh]

Hi all,

I am trying to boot  Linux from flash on MIPS Board.
When uBoot tries to boot Linux it fails saying "Verifying Checksum 
Failed bad data crc".
The bootcmd is fsload 0x8080 /boot/uImage; bootm 0x8080.

But When i do a tftp of the same image(uImage) to same 
address(0x8080) it works fine.
What might be the problem when it is loading uImage from flash?

Log is as shown below:

Bootrom Version [RTEMS]:  Rel_30
Chip: Atlanta A80
Board: REF MTA

U-Boot 1.1.2 (Jul 17 2009 - 10:32:57)
Board: MIPS CPU Speed 200 MHz
DRAM:  32 MB
sflash.c:266:DF_F_DataflashProbe: Entered
sflash.c:269:DF_F_DataflashProbe: flash type is 0x1
sflash.c:270:DF_F_DataflashProbe: num pages 32768
DataFlash:Nb pages:  32768
Page Size:256
Size= 8388608 bytes
Logical address: 0xAD00
Nb Erase Blocks:128
Erase Block Size:  65536
Area 0: AD00 to AD003FFF
Area 1: AD004000 to AD03
Area 2: AD04 to AD30BFFF
Area 3: AD30C000 to AD7F
crc matched
In:serial
Out:   serial
Err:   serial
Net:   Eth.

Type "run flash_nfs" to mount root filesystem over NFS

Hit any key to stop autoboot:  0
### JFFS2 loading '/boot/uImage' to 0x8080
Scanning JFFS2 FS: . done.
### JFFS2 load complete: 1853548 bytes loaded to 0x8080
## Booting image at 8080 ...
   Image Name:   Linux Kernel Image with ramdisk.
   Created:  2009-07-17  11:01:27 UTC
   Image Type:   MIPS Linux Kernel Image (gzip compressed)
   Data Size:1853484 Bytes =  1.8 MB
   Load Address: 8010
   Entry Point:  80423000
   Verifying Checksum ... Bad Data CRC
uboot>#

Please Help

Thanks
Rahanesh






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

Re: [U-Boot] [PATCH] ppc4xx: Fixed compilation warning in 4xx_enet.c

[Stefan Roese]

Hi Ben,

On Saturday 11 July 2009 20:56:06 Alessio Centazzo wrote:
> This patch fixes a compilation warning for some Ethernet PHY-less
> PPC4xx platforms (440SPE based ones) and a potential compilation
> error for 440SP platforms (use of undefined 'ethgroup' variable).
> In the original code and in case of 440SPE platforms, 'ethgroup'
> is initialized to -1 and never modified.  Later in the function,
> within an #ifdef statement, an 'if statement' executes code only
> if 'ethgroup' is set to 4, therefore it is harmless to avoid
> executing the 'if statement' by removing the CONFIG_440SPE from
> the affected #ifdefs.  In case of 440SP platforms  with on-board
> Ethernet PHY, 'ethgroup' is undefined but used (there are not such
> platforms in the repository yet). All other architectures are not
> affected by this change.
>
> Signed-off-by: Alessio Centazzo acpa...@yahoo.com

This patch falls into your responsibility now. I have no objections, so:

Acked-by: Stefan Roese 

Thanks.

Best regards,
Stefan

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

Re: [U-Boot] [PATCH] ppc4xx: Fix missing freqOPB for 405EP

[Stefan Roese]

On Friday 10 July 2009 14:47:32 Dirk Eibach wrote:
> In cpu/ppc4xx/speed.c initialization of sysInfo->freqOPB for 405EP was
> left out for no obvious reason.
>
> Signed-off-by: Dirk Eibach 

Applied to ppc4xx. Thanks.

Best regards,
Stefan

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

Re: [U-Boot] [PATCH v2] ppc4xx: Add GDsys CompactCenter board support.

[Stefan Roese]

Felix,

On Wednesday 15 July 2009 11:24:07 Felix Radensky wrote:
> I think my first patch that open-coded part of ft_board_setup() related
> to EBC ranges
> was correct and tested on real hardware. I admit that I didn't test the
> second version
> of the patch, as I didn't have the hardware at hand.
>
> I'll submit a fix soon, but I still don't have hardware for testing, so
> I'd appreciate your
> help with that.

Any news on this issue? Would be great if you could find the time to submit a 
patch for this. Dirk (?) and I will do the testing.

Thanks.

Best regards,
Stefan

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

Re: [U-Boot] [PATCH v4] ppc4xx: Add DL-Vision 405EP board support

[Stefan Roese]

On Friday 17 July 2009 14:16:40 Dirk Eibach wrote:
> Board support for the Guntermann & Drunck DL-Vision.
>
> Signed-off-by: Dirk Eibach 

Applied to ppc4xx. Thanks.

Best regards,
Stefan

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

Re: [U-Boot] [PATCH] ppc4xx: Cleanup PLU405 board code

[Stefan Roese]

On Thursday 16 July 2009 22:13:57 Matthias Fuchs wrote:
> Some Coding style cleanup (braces, whitespaces, long lines)
>
> Signed-off-by: Matthias Fuchs 

Applied to ppc4xx. Thanks.

Best regards,
Stefan

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

Re: [U-Boot] [PATCH 00/14] XPedite1K updates

[Stefan Roese]

On Saturday 18 July 2009 02:01:02 Peter Tyser wrote:
> The XPedite1000 is a 440gx-based PMC made by X-ES.  Support was added
> for XPedite100 to U-Boot > 5 years ago by Travis Sawyer
> (travis.saw...@sandburst.com) independent of X-ES.  Sandburst was
> bought out by Broadcom some time ago.  I attempted to contact
> Travis at both his old Sandburst and Broadcom email addresses
> but neither account still exist.
>
> We never sold any XPedite1000's to Sandburst, so I'm not quite sure
> how Travis initially got his hands on one (ebay?).  In any case,
> now that other X-ES products are supported by U-Boot I thought
> it would make sense to sync up the XPedite1000 with other X-ES
> boards.  In my opinion, these changes add some functionality and
> are generally an improvement.  No one is currently using U-Boot
> on the XPedite1000 that I'm aware of so I hope the changes don't
> affect others in a negative way.
>
> In any case, I was hoping to take over maintainership for the board,
> but was never able to get the OK from Travis.  I hope this is OK...

It's ok with me.

> Peter Tyser (14):
>   xpedite1k: Use standard CFI flash driver
>   xpedite1k: Remove CONFIG_SYS_DRAM_TEST support
>   xpedite1k: Remove support for fixed SDRAM configuration
>   xpedite1k: Remove support for reading MACs from EEPROM
>   xpedite1k: Cleanup coding style
>   xpedite1k: Add support for optional flashes
>   xpedite1k: Add support for additional GPIO pins
>   xpedite1k: Store environment in flash
>   xpedite1k: Disable unused ethernet port 1
>   xpedite1k: Sync up commands and environment with other X-ES boards
>   xpedite1k: Sync organization of board config with other X-ES boards
>   xpedite1k: Sync up board config options with other X-ES boards
>   xpedite1k: Sync checkboard() with other X-ES boards
>   xpedite1k: Move to X-ES vendor directory

All 14 patches applied to ppc4xx. Thanks.

Best regards,
Stefan

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

Re: [U-Boot] [PATCH 2/4] I2C Add initial support for TWL4030

[Heiko Schocher]

Hello Tom,

Tom wrote:
> Omap2 is still pending.
> I was hoping to help Richard out with this last week but he was on travel.
> 
> There is not much more I think I can do wrt omap2.
> All my targets are omap3.
> The nearest I can find online is the nokia n8xx which uses a another 
> bootloader.
> 
> The options as I see them are.
> 
> 1. Get a pass on omap2 testing
> 2. Rewrite i2c init to have a omap3 specific init
> 3. Hack n8xx and try to convience you the results are reasonable
> 4. Wait for omap2 testing.
> 
> I vote for #1.

Hmm.. because I think this patches go through Jean-Christophe he has
to decide if this is acceptable.

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 0/2] arm nomadik: gpio and i2c

[Heiko Schocher]

Hello Alessandro,

Alessandro Rubini wrote:
>> Agreed. So we need an gpio_core.c / .h which defines the following
>> functions (just a proposal):
> 
> Yes.
> 
>> typedef struct gpio_adapter {
>>  int (*init_pin)(int pin);
>>  int (*set)(int pin, value);
>>  int (*get)(int pin);
>>  int (*dir)(int pin, int direction); 
>>  int (*level)(int pin, int level);
>> }
> 
> I don't understand the init_pin function, nor what "level" is.

init_pin:
  you call this function, if you want to use this pin as an gpio.
  (BTW: init pin should look like this,
changing init_pin(pin, dir, value);
  with value only used if setting it as an output)
  functionality:
- Setup the GPIO registers for using this pin as GPIO
- Maybe setting a marker in the gpio_core, that this pin is usable
  now for gpio. This marker can be checked in the other functions,
  which use this pin ...

level:
  we can set the output level with this function directly ... ok,
  not really needed ... but maybe nice to have ... if thinking for
  the i2c bitbang driver, we save on all set() calls the output
  settings ... maybe more then one register changes, if switching
  between input/output ...

> Actually, even "dir" can be dropped: a get configures as input, a set
> configures as output, the extra instruction is very little overhead.

See my comment above. I just like the idea, that a user can control this
separately.

> But an alternate function configuration is definitely needed: everybody
> has alternate functions associated to the pins. Just say "0" is gpio
> and 1...n is SoC-specific.

what with deinit_pin(pin, function)? That would be in shape with init_pin()?

(There, we could also unset the marker, that this pin is no longer used
for gpio ...)

> So, are you going to write it? Or should someone else do that?

Hmm... if nobody else volunteers, maybe I find time for it ... but I
think, there should be more ratings, if this is a way to go ... also,
if we make a gpio_core, would we have some commands for it (show
status of gpios, directly access the gpios per commandshell, ...)?

Also, a board can have more then one gpio adapter, how we address
such a case?

Just a fast thought about that:
- adding to typedef struct gpio_adapter also a "name" field
- allow to register more than one gpio adapter
- addressing the different adapters through an int ... called gpio_device?

So the core functions look something like that:

int gpio_init(gpio_adap *adap); (returns a int gpio_device)

int gpio_init_pin(gpio_device, pin, dir, value);
int gpio_set(gpio_device, pin, value)
int gpio_get(gpio_device, pin)
int gpio_dir(gpio_device, pin, dir)
int gpio_level(gpio_device, pin, level)

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 0/2] arm nomadik: gpio and i2c

[Alessandro Rubini]

> what with deinit_pin(pin, function)? That would be in shape with init_pin()?

No, it's not clear what it is. I'd rename "init" to "setup", adding an AF
argument. So I can setup it as AF2, or as GPIO-OUT, or whatever.

> (There, we could also unset the marker, that this pin is no longer used
> for gpio ...)

No, I wouldn't like the marker. It's a boot loader, it shouldn't
overdo sanity checks.  Most of the times it runs the same "bootcmd"
over and over. In the rare but important case it's a debugging tool, it
shouldn't force policy, in my opinion (I already have problems with the
kernel gpiolib, that doesn't let me fix mishaps at will).

> Also, a board can have more then one gpio adapter, how we address
> such a case?

As Wolfgang suggested, we don't.  If atmel calls it PORTC-12 I have no
problem calling it gpio-76 by concatentating the ports as 0..31,
32..64, ...  It's still better to have a gpio command than doing "mw
 " over and over.

In my old-fashioned way, it should be as simple as possible, but no simpler.

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

Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Heiko Schocher]

Hello Alessandro,

Alessandro Rubini wrote:
>> what with deinit_pin(pin, function)? That would be in shape with init_pin()?
> 
> No, it's not clear what it is. I'd rename "init" to "setup", adding an AF

ok.

> argument. So I can setup it as AF2, or as GPIO-OUT, or whatever.

No I don;t understand you ;-) What means AF? Ah, while typing this, my
brain parsed AF to Alternate Function, right?

So, I am fine with that.

>> (There, we could also unset the marker, that this pin is no longer used
>> for gpio ...)
> 
> No, I wouldn't like the marker. It's a boot loader, it shouldn't
> overdo sanity checks.  Most of the times it runs the same "bootcmd"
> over and over. In the rare but important case it's a debugging tool, it
> shouldn't force policy, in my opinion (I already have problems with the
> kernel gpiolib, that doesn't let me fix mishaps at will).

Ok, it was just a thought. If others agree I am fine with it.

>> Also, a board can have more then one gpio adapter, how we address
>> such a case?
> 
> As Wolfgang suggested, we don't.  If atmel calls it PORTC-12 I have no
> problem calling it gpio-76 by concatentating the ports as 0..31,
> 32..64, ...  It's still better to have a gpio command than doing "mw
>  " over and over.

Huh, missed I an Email? Didn;t see a response from Wolfgang ...

Ah, yes, this is also an option, so we need to configure when
adding a gpio_adapter, with which GPIO number the GPIOs in this adapter
starts and how many GPIOs are accessible through it... OK, I am also
fine with such an option.

> In my old-fashioned way, it should be as simple as possible, but no simpler.

;-)

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

[U-Boot] [PATCH 2/2] ppc4xx: Add struct for 4xx GPIO controller registers

[matthias . fuchs]

From: Matthias Fuchs 

Signed-off-by: Matthias Fuchs 
---
 include/asm-ppc/gpio.h |   24 
 1 files changed, 24 insertions(+), 0 deletions(-)

diff --git a/include/asm-ppc/gpio.h b/include/asm-ppc/gpio.h
index fc05dc0..23e29b1 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_MAX 1
 #endif
 
+/* GPIO controller */
+struct ppc4xx_gpio {
+   u32 or; /* Output Control */
+   u32 tcr;/* Tri-State Control */
+   u32 osl;/* Output Select 16..31 */
+   u32 osh;/* Output Select 0..15 */
+   u32 tsl;/* Tri-State Select 16..31 */
+   u32 tsh;/* Tri-State Select 0..15 */
+   u32 odr;/* Open Drain */
+   u32 ir; /* Input */
+   u32 rr1;/* Receive Register 1 */
+   u32 rr2;/* Receive Register 2 */
+   u32 rr3;/* Receive Register 3 */
+   u32 reserved;
+   u32 is1l;   /* Input Select 1 16..31 */
+   u32 is1h;   /* Input Select 1 0..15 */
+   u32 is2l;   /* Input Select 2 16..31 */
+   u32 is2h;   /* Input Select 2 0..15 */
+   u32 is3l;   /* Input Select 3 16..31 */
+   u32 is3h;   /* Input Select 3 0..15 */
+};
+
 /* 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
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH 1/2] ppc4xx: use TCR macro instead of tcr

[matthias . fuchs]

From: Matthias Fuchs 

This patch migrates 4xx code from using the lowercase tcr macro
to the uppercase TCR macro. Both macros have been defined in the past.
So one is to much and uppercase macros are much more common.

The lowercase macro conflicts with the upcoming
introduction of the ppc4xx_gpio struct and it's tcr field.

Doing more such migration and getting rid of many defines from
include/ppc405.h and include/ppc440.h should be put on
our TODO list.

Signed-off-by: Matthias Fuchs 
---
 cpu/ppc4xx/cpu_init.c   |4 ++--
 cpu/ppc4xx/interrupts.c |8 
 cpu/ppc4xx/start.S  |2 +-
 include/ppc405.h|1 -
 include/ppc440.h|1 -
 5 files changed, 7 insertions(+), 9 deletions(-)

diff --git a/cpu/ppc4xx/cpu_init.c b/cpu/ppc4xx/cpu_init.c
index bbd795d..111f635 100644
--- a/cpu/ppc4xx/cpu_init.c
+++ b/cpu/ppc4xx/cpu_init.c
@@ -248,7 +248,7 @@ cpu_init_f (void)
 #endif
 
 #if defined(CONFIG_WATCHDOG)
-   val = mfspr(tcr);
+   val = mfspr(TCR);
 #if defined(CONFIG_440EP) || defined(CONFIG_440GR)
val |= 0xb800;  /* generate system reset after 1.34 seconds */
 #elif defined(CONFIG_440EPX)
@@ -260,7 +260,7 @@ cpu_init_f (void)
val &= ~0x3000; /* clear WRC bits */
val |= CONFIG_SYS_4xx_RESET_TYPE << 28; /* set board specific WRC type 
*/
 #endif
-   mtspr(tcr, val);
+   mtspr(TCR, val);
 
val = mfspr(tsr);
val |= 0x8000;  /* enable watchdog timer */
diff --git a/cpu/ppc4xx/interrupts.c b/cpu/ppc4xx/interrupts.c
index 494bd8c..47c12a2 100644
--- a/cpu/ppc4xx/interrupts.c
+++ b/cpu/ppc4xx/interrupts.c
@@ -102,9 +102,9 @@ int interrupt_init_cpu (unsigned *decrementer_count)
 * Init PIT
 */
 #if defined(CONFIG_440)
-   val = mfspr( tcr );
+   val = mfspr( TCR );
val &= (~0x0440);   /* clear DIS & ARE */
-   mtspr( tcr, val );
+   mtspr( TCR, val );
mtspr( dec, 0 );/* Prevent exception after TSR clear*/
mtspr( decar, 0 );  /* clear reload */
mtspr( tsr, 0x0800 );   /* clear DEC status */
@@ -126,9 +126,9 @@ int interrupt_init_cpu (unsigned *decrementer_count)
/*
 * Enable PIT
 */
-   val = mfspr(tcr);
+   val = mfspr(TCR);
val |= 0x0440;
-   mtspr(tcr, val);
+   mtspr(TCR, val);
 
/*
 * Set EVPR to 0
diff --git a/cpu/ppc4xx/start.S b/cpu/ppc4xx/start.S
index 582c781..22bc409 100644
--- a/cpu/ppc4xx/start.S
+++ b/cpu/ppc4xx/start.S
@@ -626,7 +626,7 @@ _start:
mtspr   tbl,r0  /* prevent fit & wdt exceptions */
mtspr   tbu,r0
mtspr   tsr,r1  /* clear all timer exception status */
-   mtspr   tcr,r0  /* disable all */
+   mtspr   TCR,r0  /* disable all */
mtspr   esr,r0  /* clear exception syndrome register */
mtxer   r0  /* clear integer exception register */
 
diff --git a/include/ppc405.h b/include/ppc405.h
index 917afec..50fc7be 100644
--- a/include/ppc405.h
+++ b/include/ppc405.h
@@ -61,7 +61,6 @@
#define  dear  0x3d5  /* data exeption address register */
#define  evpr  0x3d6  /* exeption vector prefix register */
#define  tsr   0x3d8  /* timer status register */
-   #define  tcr   0x3da  /* timer control register */
#define  pit   0x3db  /* programmable interval timer */
#define  sgr   0x3b9  /* storage guarded reg  */
#define  dcwr  0x3ba  /* data cache write-thru reg*/
diff --git a/include/ppc440.h b/include/ppc440.h
index 01f6eaf..df78eea 100644
--- a/include/ppc440.h
+++ b/include/ppc440.h
@@ -90,7 +90,6 @@
 #define dvc1   0x13e   /* data value compare 1 */
 #define dvc2   0x13f   /* data value compare 2 */
 #define tsr0x150   /* timer status register */
-#define tcr0x154   /* timer control register */
 #define ivor0  0x190   /* interrupt vector offset register 0 */
 #define ivor1  0x191   /* interrupt vector offset register 1 */
 #define ivor2  0x192   /* interrupt vector offset register 2 */
-- 
1.6.1

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

[U-Boot] U-Boot environment update in linux embedded ARM architecture

[Jan Misfatto]

Dear Madam/Sir,
our company, Microhard s.r.l, produces data acquisition terminals and in 
our new design, which is under development, we use an ARM 9 plattform 
based on the AT91SAM9263 microcontroller. Right now our system uses a 
NAND Flash chip from Micron MT29F2G08AACWP and out Memory is mapped as 
follows

0x0 AT91Booststrap
0x2 *U-Boot (2009.06)*
0x6 *U-Boot Env.*
0x A Linux Kernel
0x40 Rooot FS (jffs2)

We are trying to update the U-booot environment from U-boot with the 
/"savenev"/ command. We encounter the following problem. When updating 
the u-boot environment part of the u-boot code is overwritten with the 
environment parameters. This happens only when our NAND flash has bad 
blocks in the u-boot zone. (Block 1 and 2), We receive the information 
about the  bad blocks from Sam-ba.  If we use a NAND  with no bad blocks 
everything works fine.
Could you kindly give any advise about this topic?
We looking foreword for your answer thank you for your time,
best regards

Jan Misfatto
-- 

*/Jan Misfatto/*

*/Microhard/**/ S.r.l./*
*Tel: +39.0331.514420*
*Fax: +39.0331.514707*
*e-mail:* **

---
 


/Questo messaggio ed i suoi allegati viene spedito solo alle persone 
indicate come destinatarie. Esso contiene informazioni confidenziali 
legalmente privilegiate. Se il lettore non e' indicato come 
destinatario, la lettura, diffusione o copia di questo messaggio o l'uso 
delle informazioni che contiene o degli allegati e' proibita. Se avete 
ricevuto questo messaggio per errore Vi preghiamo di avvisare 
immediatamente il mittente e cancellare il messaggio e gli allegati. Per 
qualunque domanda in proposito Vi preghiamo di contattarci inviando un 
messaggio a /_i...@microhard.biz _/./

/This message and its attachments is addressed only to the intended 
recipient. This message contains confidential information legally 
privileged. If the reader is not a representative of the intended 
recipient, any review, dissemination or copying of this message or use 
of the information it contains or its attachments is prohibited. If you 
have received this message in error please notify immediately the sender 
and delete this message and attachments. Should you have any questions, 
please contact us by replying to /_i...@microhard.biz__ 
_/./

 

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

Re: [U-Boot] [PATCH 2/3] xpedite5370: Fix I2C GPIO initialization typo

[Heiko Schocher]

Hello Peter,

pty...@xes-inc.com wrote:
> From: Peter Tyser 
> 
> Signed-off-by: Peter Tyser 
> ---
>  board/xes/xpedite5370/xpedite5370.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/board/xes/xpedite5370/xpedite5370.c 
> b/board/xes/xpedite5370/xpedite5370.c
> index 22cf294..d54c699 100644
> --- a/board/xes/xpedite5370/xpedite5370.c
> +++ b/board/xes/xpedite5370/xpedite5370.c
> @@ -84,8 +84,8 @@ int board_early_init_r(void)
>   /* Initialize PCA9557 devices */
>   pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR0, 0xff, 0);
>   pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR1, 0xff, 0);
> - pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR0, 0xff, 0);
> - pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR0, 0xff, 0);
> + pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR2, 0xff, 0);
> + pca953x_set_pol(CONFIG_SYS_I2C_PCA953X_ADDR3, 0xff, 0);
>  
>   /*
>* Remap NOR flash region to caching-inhibited

This go through the mpc85xx maintainer, so you get my

Acked-by: Heiko Schocher

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

Re: [U-Boot] [PATCH v5] Add "chip_config" command for PPC4xx bootstrap configuration

[Matthias Fuchs]

Works fine! Thanks.

Acked-by: Matthias Fuchs 

On Monday 20 July 2009 08:26, Stefan Roese wrote:
> This patch adds a generic command for programming I2C bootstrap
> eeproms on PPC4xx. An implementation for Canyonlands board is
> included.
> 
> The command name is intentionally chosen not to be PPC4xx specific.
> This way other CPU's/SoC's can implement a similar command under
> the same name, perhaps with a different syntax.
> 
> Usage on Canyonlands:
> 
> => chip_config
> Available configurations (I2C address 0x52):
> 600-nor  - NOR  CPU: 600 PLB: 200 OPB: 100 EBC: 100
> 600-nand - NAND CPU: 600 PLB: 200 OPB: 100 EBC: 100
> 800-nor  - NOR  CPU: 800 PLB: 200 OPB: 100 EBC: 100
> 800-nand - NAND CPU: 800 PLB: 200 OPB: 100 EBC: 100
> 1000-nor - NOR  CPU:1000 PLB: 200 OPB: 100 EBC: 100
> 1000-nand- NAND CPU:1000 PLB: 200 OPB: 100 EBC: 100
> 1066-nor - NOR  CPU:1066 PLB: 266 OPB:  88 EBC:  88 ***
> 1066-nand- NAND CPU:1066 PLB: 266 OPB:  88 EBC:  88
> => chip_config 600-nor
> Using configuration:
> 600-nor  - NOR  CPU: 600 PLB: 200 OPB: 100 EBC: 100
> done (dump via 'i2c md 52 0.1 10')
> Reset the board for the changes to take effect
> 
> Other 4xx boards will be migrated to use this command soon
> as well.
> 
> Signed-off-by: Stefan Roese 
> Signed-off-by: Dirk Eibach 
> Cc: Matthias Fuchs 
> ---
> v5:
> - Removed bogus lines from commit text
> 
> v4:
> - Command name changed from cpu_config to chip_config
> - Used eeprom_read/eeprom_write if available
> - Added CONFIG_4xx_CONFIG_I2C_EEPROM_OFFSET
> 
> v3:
> - Line length of one printf reduced
> 
> v2:
> - Patch authorship changes to Stefan
> - s-o-b from Dirk added
> - Added current configuration detection
> - Minor coding style cleanup
> 
>  board/amcc/canyonlands/Makefile  |5 +-
>  board/amcc/canyonlands/bootstrap.c   |  195 
> --
>  board/amcc/canyonlands/chip_config.c |   55 ++
>  cpu/ppc4xx/Makefile  |3 +
>  cpu/ppc4xx/cmd_chip_config.c |  142 
>  include/asm-ppc/ppc4xx_config.h  |   42 +++
>  include/configs/canyonlands.h|6 +
>  7 files changed, 251 insertions(+), 197 deletions(-)
>  delete mode 100644 board/amcc/canyonlands/bootstrap.c
>  create mode 100644 board/amcc/canyonlands/chip_config.c
>  create mode 100644 cpu/ppc4xx/cmd_chip_config.c
>  create mode 100644 include/asm-ppc/ppc4xx_config.h
> 
> diff --git a/board/amcc/canyonlands/Makefile b/board/amcc/canyonlands/Makefile
> index 2aeead6..12f8a64 100644
> --- a/board/amcc/canyonlands/Makefile
> +++ b/board/amcc/canyonlands/Makefile
> @@ -25,10 +25,11 @@ include $(TOPDIR)/config.mk
>  
>  LIB  = $(obj)lib$(BOARD).a
>  
> -COBJS:= $(BOARD).o
> -COBJS+= bootstrap.o
> +COBJS-y  := $(BOARD).o
> +COBJS-$(CONFIG_CMD_CHIP_CONFIG) += chip_config.o
>  SOBJS:= init.o
>  
> +COBJS   := $(COBJS-y)
>  SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
>  OBJS := $(addprefix $(obj),$(COBJS))
>  SOBJS:= $(addprefix $(obj),$(SOBJS))
> diff --git a/board/amcc/canyonlands/bootstrap.c 
> b/board/amcc/canyonlands/bootstrap.c
> deleted file mode 100644
> index 6dc2cca..000
> --- a/board/amcc/canyonlands/bootstrap.c
> +++ /dev/null
> @@ -1,195 +0,0 @@
> -/*
> - * (C) Copyright 2008
> - * Stefan Roese, DENX Software Engineering, s...@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 
> -#include 
> -#include 
> -#include 
> -
> -/*
> - * NOR and NAND boot options change bytes 5, 6, 8, 9, 11. The
> - * values are independent of the rest of the clock settings.
> - */
> -
> -#define NAND_COMPATIBLE  0x01
> -#define NOR_COMPATIBLE  0x02
> -
> -#define I2C_EEPROM_ADDR 0x52
> -
> -static char *config_labels[] = {
> - "CPU: 600 PLB: 200 OPB: 100 EBC: 100",
> - "CPU: 800 PLB: 200 OPB: 100 EBC: 100",
> - "CPU:1000 PLB: 200 OPB: 100 EBC: 100",
> - "CPU:1066 PLB: 266 OPB:  88 EBC:  88",
> - NULL
> -};
> -
> -static u8 boot_configs[][17] = {
> - {
> - (NAND_COMPATIBLE | NOR_COMPATIBLE),
> - 0x86, 0x80, 0xce, 0x1f, 0x79, 0x80, 0x00, 0xa0, 0x40,

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

[matthias . fuchs]

From: Matthias Fuchs 

Signed-off-by: Matthias Fuchs 
---
 MAINTAINERS  |1 +
 MAKEALL  |1 +
 Makefile |3 +
 board/esd/pmc405de/Makefile  |   53 
 board/esd/pmc405de/chip_config.c |   47 
 board/esd/pmc405de/config.mk |   23 ++
 board/esd/pmc405de/pmc405de.c|  521 ++
 board/esd/pmc405de/u-boot.lds|  133 ++
 include/configs/PMC405DE.h   |  378 +++
 9 files changed, 1160 insertions(+), 0 deletions(-)
 create mode 100644 board/esd/pmc405de/Makefile
 create mode 100644 board/esd/pmc405de/chip_config.c
 create mode 100644 board/esd/pmc405de/config.mk
 create mode 100644 board/esd/pmc405de/pmc405de.c
 create mode 100644 board/esd/pmc405de/u-boot.lds
 create mode 100644 include/configs/PMC405DE.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 575a7ec..484040c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -171,6 +171,7 @@ Matthias Fuchs 
PCI405  PPC405GP
PLU405  PPC405EP
PMC405  PPC405GP
+   PMC405DEPPC405EP
PMC440  PPC440EPx
VOH405  PPC405EP
VOM405  PPC405EP
diff --git a/MAKEALL b/MAKEALL
index 020ff73..f36a5fd 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -237,6 +237,7 @@ LIST_4xx="  \
PIP405  \
PLU405  \
PMC405  \
+   PMC405DE\
PMC440  \
PPChameleonEVB  \
quad100hd   \
diff --git a/Makefile b/Makefile
index 090e645..a5d397b 100644
--- a/Makefile
+++ b/Makefile
@@ -1492,6 +1492,9 @@ PLU405_config:unconfig
 PMC405_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc405 esd
 
+PMC405DE_config:   unconfig
+   @$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc405de esd
+
 PMC440_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc ppc4xx pmc440 esd
 
diff --git a/board/esd/pmc405de/Makefile b/board/esd/pmc405de/Makefile
new file mode 100644
index 000..a080649
--- /dev/null
+++ b/board/esd/pmc405de/Makefile
@@ -0,0 +1,53 @@
+#
+# (C) Copyright 2000-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-y= $(BOARD).o
+COBJS-y+= ../common/cmd_loadpci.o
+COBJS-$(CONFIG_CMD_CHIP_CONFIG) += chip_config.o
+
+COBJS  := $(COBJS-y)
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(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/esd/pmc405de/chip_config.c b/board/esd/pmc405de/chip_config.c
new file mode 100644
index 000..f1cafc1
--- /dev/null
+++ b/board/esd/pmc405de/chip_config.c
@@ -0,0 +1,47 @@
+/*
+ * (C) Copyright 2008-2009
+ * Stefan Roese, DENX Software Engineering, s...@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 
+#include 
+
+struct ppc4xx_config ppc4xx_config_val[] = {
+
+   { "133", "CPU: 133 P

Re: [U-Boot] [PATCH 3/3] Remove last remanants of unused CONFIG_I2C_CMD_TREE

[Heiko Schocher]

Hello Peter,

pty...@xes-inc.com wrote:
> From: Peter Tyser 
> 
> Signed-off-by: Peter Tyser 
> ---
>  include/configs/P2020DS.h |1 -
>  include/configs/XPEDITE5170.h |1 -
>  include/configs/aria.h|1 -
>  include/configs/mecp5123.h|1 -
>  4 files changed, 0 insertions(+), 4 deletions(-)

added to u-boot-i2c.git
Thanks!

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

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

[Heiko Schocher]

Hello Wolfgang,

The following changes since commit b86b85e2611d57d834795a92453431a1a340c3c9:
  Ilya Yanok (1):
mmc: set bus width to 1 and clock to minimum early during initialization

are available in the git repository at:

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

Peter Tyser (1):
  Remove last remanants of unused CONFIG_I2C_CMD_TREE

 include/configs/P2020DS.h |1 -
 include/configs/XPEDITE5170.h |1 -
 include/configs/aria.h|1 -
 include/configs/mecp5123.h|1 -
 4 files changed, 0 insertions(+), 4 deletions(-)

-- 
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 2/6] S5PC100: SMDKC100 Board support

[Minkyu Kang]

Dear Wolfgang,

2009/7/18 Wolfgang Denk :
> Dear Minkyu Kang,
>
> In message <1f3430fb0907170142l51139f76jed37a47f7760f...@mail.gmail.com> you 
> wrote:
>>
>> >> +void raise(void)
>> >> +{
>> >> +}
>> >
>> > Why would that be needed?
>>
>> Actually this function is workaround.
>> because of undefined reference error
>>
>> /opt/toolchains/arm-2008q3/bin/../lib/gcc/arm-none-linux-gnueabi/4.3.2/libgcc.a(_dvmd_lnx.o):
>> In function `__aeabi_ldiv0':
>> (.text+0x8): undefined reference to `raise'
>>
>> I want to solve it but can't find the reason yet.
>> How i can fix this problem?
>
> Find out which part of your code triggers the use of the  _dvmd_lnx.o
> code  and  avoid  this;  from  the  error message it seems to be some
> (long) division.

yes, we tried it.
but, can't find about it...

Omap3 also has raise function at cpu/arm_cortexa8/omap3/board.c(303 line)
I think this is a matter of coretexA8, and want to use this workaround function
until fix the problem.
how you think?

Thanks.
Minkyu Kang

-- 
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-Boot environment update in linux embedded ARM architecture

[Alessandro Rubini]

> 0x2 *U-Boot (2009.06)*
> 0x6 *U-Boot Env.*

So two blocks. for u-boot, which is bigger than one block.

> the u-boot environment part of the u-boot code is overwritten with the 
> environment parameters. This happens only when our NAND flash has bad 
> blocks in the u-boot zone. (Block 1 and 2),

In this case u-boot is stored in two blocks, but skipping the bad
block.  Your env area will contain the trailing part of u-boot binary.
I'm sure your consultant already told you.

> /Questo messaggio ed i suoi allegati viene spedito solo alle persone 
> indicate come destinatarie. Esso contiene informazioni confidenziali 

Please avoid this meaningless stuff when posting to public lists (even
in private mail it sounds insulting, but that's just personal taste).

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

[U-Boot] oob bytes in NAND

[Muralitharan.Perumal]

Hi,

 

Can I modify the oob bytes in NAND using U-boot commands like this:

 

"nand write.oob 0x800 0x0 64" [This should modify the oob bytes of
page 0].

 

Is this Correct? Please can you suggest on this?

 

I tried this but no success.

 

Best Regards

Murali

 

 



This E-mail and any attachments hereto are strictly confidential and intended 
solely for the addressee. If you are not the intended addressee please notify 
the sender by return and delete the message. You must not disclose, forward or 
copy this E-mail or attachments to any third party without the prior consent of 
the sender. Pace plc is registered in England and Wales (Company no. 1672847) 
and our Registered Office is at Victoria Road, Saltaire, West Yorkshire, BD18 
3LF, UK. Tel +44 (0) 1274 532000 Fax +44 (0) 1274 532010. 
Save where otherwise agreed in writing between you and Pace (i) all orders for 
goods and/or services placed by you are made pursuant to Pace's standard terms 
and conditions of sale which may have been provided to you, or in any event are 
available at http://www.pace.com/uktcsale.pdf (ii) all orders for goods and/or 
services placed by Pace are subject to Pace's standard terms and conditions of 
purchase which may have been provided to you, or in any event are available at 
http://www.pace.com/uktcpurch.pdf. All other inconsistent terms in any other 
documentation including without limitation any purchase order, reschedule 
instruction, order acknowledgement, delivery note or invoice are hereby 
excluded.



This message has been scanned for viruses by BlackSpider MailControl - 
www.blackspider.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/6] S5PC100: SMDKC100 Board support

[Wolfgang Denk]

Dear Minkyu Kang,

In message <1f3430fb0907200415n1482bc40s33a44cf3ca439...@mail.gmail.com> you 
wrote:
> 
> > Find out which part of your code triggers the use of the  _dvmd_lnx.o
> > code  and  avoid  this;  from  the  error message it seems to be some
> > (long) division.
>
> yes, we tried it.
> but, can't find about it...

Why not? Using "nm" it should be trivial to find out from which source file
such a reference is coming from, and either using "gcc -S" or "objdump
-SD" or "gdb" should be suifficient to locate the C code that is to
blame for it.

> Omap3 also has raise function at cpu/arm_cortexa8/omap3/board.c(303 line)

Ah... thanks for pointing out.

Dirk Behme should be able to tell us about it.

Dirk, can we please get rid of this raise() and abort()  stuff?  Even
if  in  the  end  we  should  agree  that  we  should  keep these, it
definitely makes no sense to add this in a CPU specific file.


> I think this is a matter of coretexA8, and want to use this workaround 
> function
> until fix the problem.

I am pretty much sure that this has nothing to do with CortexA8 per
se.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
To the systems programmer,  users  and  applications  serve  only  to
provide a test load.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Problem booting Linux from Flash

[Wolfgang Denk]

Dear Rahanesh,

In message <4a642891.2090...@tataelxsi.co.in> you wrote:
> 
> I am trying to boot  Linux from flash on MIPS Board.
> When uBoot tries to boot Linux it fails saying "Verifying Checksum 
> Failed bad data crc".

CRC is one type of checksum.

> What might be the problem when it is loading uImage from flash?

Obviously the loaded data are corrupt. Based on the  information  you
gave  us  it is impossible to tell if the data are already corrupt in
your JFFS2 file system, of if they get  corrupted  when  loading  the
file, or when booting it.

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
Humans do claim a great deal for that particular emotion (love).
-- Spock, "The Lights of Zetar", stardate 5725.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

[Wolfgang Denk]

Dear Alessandro Rubini,

In message <20090720080226.ga2...@mail.gnudd.com> you wrote:
>
> What about "DRV" or even "D" if you insist?   CONFIG_D_I2C_SOFT ?

That's longer than needed, and nobody will understand what the "D_"
stands for.

> I personally find the config files pretty unreadable. Options that
> enable a driver should be different from those that select a
> behaviour, in my opinion.

So what do you think when you read "CONFIG_I2C_SOFT" ?

So many people here seem to take Linux as reference - why not here?

Does Linux use "CONFIG_DRIVER_E1000", "CONFIG_DRIVER_I2C",
"CONFIG_DRIVER_IDE", "CONFIG_DRIVER_SCSI" or "CONFIG_DRIVER_SPI"?

No! Linux uses "CONFIG_E1000", "CONFIG_I2C", "CONFIG_IDE",
"CONFIG_SCSI" and "CONFIG_SPI".

> While people responsible for their board know all the stuff they
> wrote, but when someone undergoes a more general code change several or
> all config files must be checked. A driver namespace would help, in my
> opionion.

Linux has an order of magnitude more drivers than U-Boot, and they do
well without this.  We don't need this either.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The more complex the mind, the greater the need for the simplicity of
play.
-- Kirk, "Shore Leave", stardate 3025.8
___
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

[Wolfgang Denk]

Dear Prafulla Wadaskar,

In message <73173d32e9439e4abb5151606c3e19e202ddf27...@sc-vexch1.marvell.com> 
you wrote:
>
> > > + 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

Hm...

Normally the use of lex (and eventually yacc) is recommended if you
need a parser - writing parsers in C is a typical "programming" task
(see definition in signature below :-)

If you have an extremely simple syntax, you might for example proceed
like this:

1) drop all lines starting with '#' as comment lines.
2) use strtok_r() to split your lines of input into white-space
   separated tokens.
3) drop all lines with zero tokens (= empty lines)
4) process the rest

[See example in the strtok()/strtok_r() man page).

> As explained in doc.README.kwimage,
> any other line apart from above will be considered as valid configuration l> 
> ine.
> This is bare minimal parsing provided here which is sufficient
...

> > Hmm... it seems you add only image creation code. But "mkimage -l"
> > should work on such an image, too. And "imls" in U-Boot 
> > should be working, too.
> Well I will disable other generic mkimage options including -l for kwbimage 
> ;-)

This makes little sense to me. When we have one command to  build  an
image,  I  definitely want to have a command to check and display the
contents of an image, too, and/or to verify it's integrity.

> Can we add this in second part which is not required too?
> For me great thing is that we can support kwimage generation through mkimage.

I understand your position. I guess you  agree  that  _full_  support
(i.e.  including the ability to check and list and image, both on the
host and on the target) would be even better, and more in  line  with
existing U-Boot 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
PROGRAM - n.  A magic spell cast over a computer  allowing it to turn
one's input into error messages.
v. tr. - To engage in a pastime similar to banging one's head against
a wall, but with fewer opportunities for reward.
___
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

[Wolfgang Denk]

Dear Prafulla Wadaskar,

In message <73173d32e9439e4abb5151606c3e19e202de09c...@sc-vexch1.marvell.com> 
you wrote:
> 
> > > 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.
> 
> Hi Wolfgang
> Any suggestions for this?
> I could used  or  but these typedefs are ifdefe=
> d
> under __KERNEL_STRICT_NAMES and __KERNEL__.
> I don't wish to redefine or disturb them for kwbimage support

This is code running on the host, so please use ISO C99 standard types:
#include  and use int8_t, int16_t, int32_t, int64_t resp.
uint8_t, uint16_t, uint32_t, uint64_t.



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
Ordnung ist die Lust der Vernunft,
aber Unordnung die Wonne der Phantasie - Paul Claudel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4a6422fc.6030...@invitel.hu> you wrote:
> 
> typedef struct gpio_adapter {
>   int (*init_pin)(int pin);
>   int (*set)(int pin, value);
>   int (*get)(int pin);
>   int (*dir)(int pin, int direction); 
>   int (*level)(int pin, int level);
> }
> 
> int gpio_init(gpio_adapter *adap);
> int gpio_init_pin(pin);
>   ? maybe with setting a marker, that this pin is initialized,
> so this can be checked in the above functions ... ?
> int gpio_set(pin, value);
> int gpio_get(pin);
> int gpio_dir(pin, dir);
> int gpio_level(pin, dir);

What does "level" mean in this context?

gpio_init_pin() and gpio_dir() seem to be redundant  -  or  does  pin
initialization not include the setting of the direction (and, in case
of an output pin, it's initial state) ?

gpio_get() returns the current state of the pin?

gpio_set() returns the previous state of the pin? Or the  new  state?
If  it  returns  the  new  state,  we could use value=1 to set a pin,
value=0 to unset a pin, and value=-1 to just read it's value  without
changing it; then we could "#define gpio_get(pin) gpio_set(pin,-1)".

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 speed of time is one second per second.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4a6437a7.40...@denx.de> you wrote:
> 
> Also, a board can have more then one gpio adapter, how we address
> such a case?

How far do you want to take that? What about an I/O expander at the
I2C bus?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
When it is incorrect, it is, at least *authoritatively* incorrect.
- Hitchiker'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] [PATCH 2/4] I2C Add initial support for TWL4030

[Dirk Behme]

Tom wrote:
> Omap2 is still pending.
> I was hoping to help Richard out with this last week but he was on travel.
> 
> There is not much more I think I can do wrt omap2.
> All my targets are omap3.
> The nearest I can find online is the nokia n8xx which uses a another 
> bootloader.
> 
> The options as I see them are.
> 
> 1. Get a pass on omap2 testing
> 2. Rewrite i2c init to have a omap3 specific init
> 3. Hack n8xx and try to convience you the results are reasonable
> 4. Wait for omap2 testing.
> 
> I vote for #1.

Me too.

Dirk

> Heiko Schocher wrote:
>> Hello Wolfgang,
>>
>> Wolfgang Denk wrote:
>>   
>>> In message <1244638432-30893-3-git-send-email-tom@windriver.com> Tom 
>>> Rix wrote:
>>> 
 The TWL4030 supplies many peripheral for OMAP3 boards. These include
 power management, usb and, keyboard.

 The product description is found here:

 http://focus.ti.com/docs/prod/folders/print/tps65950.html

 Product reference document, tps65950.pdf, is found here:

 http://www.ti.com/lit/gpn/tps65950

 Signed-off-by: Tom Rix 
 ---
  drivers/i2c/Makefile  |1 +
  drivers/i2c/twl4030_i2c.c |   37 
  include/twl4030.h |  221 
 +
  3 files changed, 259 insertions(+), 0 deletions(-)
  create mode 100644 drivers/i2c/twl4030_i2c.c
  create mode 100644 include/twl4030.h
   
>>> I think this is supposed to go through the i2c repo, but I haven't
>>> seen any comments yet. 
>>> 
>>
>> Hmm.. there are responses, see for example:
>>
>> http://lists.denx.de/pipermail/u-boot/2009-June/054086.html
>>
>>   
>>> Can you please check the state of this patch? Thanks in advance.
>>> 
>> Hmm.. it is a little long to follow this ... it ended
>> first here:
>>
>> http://lists.denx.de/pipermail/u-boot/2009-June/054654.html
>>
>> waiting for an Ack that it works on omap2 ...
>>
>> (I Acked the resulting 3 patches, see:
>>  http://lists.denx.de/pipermail/u-boot/2009-June/054585.html
>> )
>>
>> Ah, found one more answer from Tom:
>>
>> http://lists.denx.de/pipermail/u-boot/2009-June/054801.html
>>
>> ended in:
>>
>> http://lists.denx.de/pipermail/u-boot/2009-June/055071.html
>>
>> with a new patchset of 6 patches, starting with:
>> http://lists.denx.de/pipermail/u-boot/2009-June/055072.html
>>
>> but state of omap2 is still pending ... see:
>>
>> http://lists.denx.de/pipermail/u-boot/2009-June/055087.html
>>
>> then Tom wrote, he has setup a git repo, see:
>> http://lists.denx.de/pipermail/u-boot/2009-July/055328.html
>>
>> but I think, the state of the omap2 is pending ... so
>> I (and I think Jean-Christophe also) wait for, that this
>> pending state is going away ...
>>
>> Tom, do you have an update?
>>
>> (added Jean-Christophe to cc:)
>> bye
>> Heiko
>>   
> 
> ___
> U-Boot mailing list
> U-Boot@lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
> 

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

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

[Thomas Petazzoni]

Le Thu, 16 Jul 2009 09:52:43 -0500,
Peter Tyser  a écrit :

> I don't have the final say here, I'm just giving my opinion.  If it
> was possible to clean up, the best way in my would be to fix your
> board (ie this patch), then send a separate follow-up patch fixing
> other boards. I don't think its too big of a deal either way.

Including  in a include/configs/ configuration file doesn't
seem to work, unfortunately.

> > +#
> > diff --git a/board/calao/usb-a9263/config.mk
> > b/board/calao/usb-a9263/config.mk new file mode 100644
> > index 000..ff2cfd1
> > --- /dev/null
> > +++ b/board/calao/usb-a9263/config.mk
> > @@ -0,0 +1 @@
> > +TEXT_BASE = 0x23f0
> 
> You should add a copyright header of some sort to config.mk.

In a one-line file, which just contains a factual definition ?

Thanks!

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Thomas Petazzoni]

Le Fri, 17 Jul 2009 21:41:43 +0200,
Wolfgang Denk  a écrit :

> Entries to maintainers is missing.

Yes, it was missing in the initial version of my patch, but further
versions got it added, thanks to other people review.

> > +int dram_init(void)
> > +{
> > +   gd->bd->bi_dram[0].start = PHYS_SDRAM;
> > +   gd->bd->bi_dram[0].size = PHYS_SDRAM_SIZE;
> > +   return 0;
> > +}
> 
> Any specific reason for not using autosizing and testing via
> get_ram_size() ?

The initial reason is that the code for this board is taken from the
Atmel boards code, which doesn't use get_ram_size(). However, my board
has a fixed RAM size, so in that case, is it still useful to use
get_ram_size() ?

> Line too long. Please fix globally.

Thanks, will do.

Thomas
-- 
Thomas Petazzoni, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM Cortex A8: Move OMAP3 specific reset handler

[Dirk Behme]

Minkyu Kang wrote:
> Because of the reset_cpu is soc specific, should be move to soc

Thanks, looks fine for me.

For the archives, this makes

http://lists.denx.de/pipermail/u-boot/2009-May/053490.html

obsolete.

Dirk

> Cc: Dirk Behme 
> Signed-off-by: Minkyu Kang 
> ---
>  cpu/arm_cortexa8/omap3/Makefile |1 +
>  cpu/arm_cortexa8/omap3/reset.S  |   36 
>  cpu/arm_cortexa8/start.S|   14 --
>  3 files changed, 37 insertions(+), 14 deletions(-)
>  create mode 100644 cpu/arm_cortexa8/omap3/reset.S
> 
> diff --git a/cpu/arm_cortexa8/omap3/Makefile b/cpu/arm_cortexa8/omap3/Makefile
> index 1fbd0dc..eef165c 100644
> --- a/cpu/arm_cortexa8/omap3/Makefile
> +++ b/cpu/arm_cortexa8/omap3/Makefile
> @@ -26,6 +26,7 @@ include $(TOPDIR)/config.mk
>  LIB  =  $(obj)lib$(SOC).a
>  
>  SOBJS:= lowlevel_init.o
> +SOBJS+= reset.o
>  
>  COBJS+= board.o
>  COBJS+= cache.o
> diff --git a/cpu/arm_cortexa8/omap3/reset.S b/cpu/arm_cortexa8/omap3/reset.S
> new file mode 100644
> index 000..a53c408
> --- /dev/null
> +++ b/cpu/arm_cortexa8/omap3/reset.S
> @@ -0,0 +1,36 @@
> +/*
> + * Copyright (c) 2009 Samsung Electronics.
> + * Minkyu Kang 
> + *
> + * 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 
> +
> +.global reset_cpu
> +reset_cpu:
> + ldr r1, rstctl  @ get addr for global reset
> + @ reg
> + mov r3, #0x2@ full reset pll + mpu
> + str r3, [r1]@ force reset
> + mov r0, r0
> +_loop_forever:
> + b   _loop_forever
> +rstctl:
> + .word   PRM_RSTCTRL
> diff --git a/cpu/arm_cortexa8/start.S b/cpu/arm_cortexa8/start.S
> index 66b4820..6bd6552 100644
> --- a/cpu/arm_cortexa8/start.S
> +++ b/cpu/arm_cortexa8/start.S
> @@ -500,17 +500,3 @@ finished_inval:
>   @ but we compile with armv5
>  
>   ldmfd   r13!, {r0 - r5, r7, r9 - r12, pc}
> -
> -
> - .align  5
> -.global reset_cpu
> -reset_cpu:
> - ldr r1, rstctl  @ get addr for global reset
> - @ reg
> - mov r3, #0x2@ full reset pll + mpu
> - str r3, [r1]@ force reset
> - mov r0, r0
> -_loop_forever:
> - b   _loop_forever
> -rstctl:
> - .word   PRM_RSTCTRL

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

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

[Peter Tyser]

On Mon, 2009-07-20 at 17:40 +0200, Thomas Petazzoni wrote:
> Le Thu, 16 Jul 2009 09:52:43 -0500,
> Peter Tyser  a écrit :
> 
> > I don't have the final say here, I'm just giving my opinion.  If it
> > was possible to clean up, the best way in my would be to fix your
> > board (ie this patch), then send a separate follow-up patch fixing
> > other boards. I don't think its too big of a deal either way.
> 
> Including  in a include/configs/ configuration file doesn't
> seem to work, unfortunately.

There might be other ways, eg it looks like Wolfgang addressed the issue
in this patch:
http://www.mail-archive.com/u-boot@lists.denx.de/msg17937.html

Does that patch work for you?  I'm assuming it will go in the next
U-Boot release.

> 
> > > +#
> > > diff --git a/board/calao/usb-a9263/config.mk
> > > b/board/calao/usb-a9263/config.mk new file mode 100644
> > > index 000..ff2cfd1
> > > --- /dev/null
> > > +++ b/board/calao/usb-a9263/config.mk
> > > @@ -0,0 +1 @@
> > > +TEXT_BASE = 0x23f0
> > 
> > You should add a copyright header of some sort to config.mk.
> 
> In a one-line file, which just contains a factual definition ?

In my opinion yes.  A copyright will explicitly say how the file may be
used, trivial as it may be.  Check out doc/feature-removal-schedule.txt:

What:   GPL cleanup
When:   August 2009
Why:Over time, a couple of files have sneaked in into the U-Boot
source code that are either missing a valid GPL license
header or that carry a license that is incompatible with the
GPL.
Such files shall be removed from the U-Boot source tree.
See
http://www.denx.de/wiki/pub/U-Boot/TaskGplCleanup/u-boot-1.1.2-files
for an old and probably incomplete list of such files.

You're free to use whatever license you'd like, as long as its GPL
compatible.  There's no harm in adding a license header, right?

Best,
Peter

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

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

[Robin Getz]

On 04 Oct 2008 Pieter posted a dns implementation for U-Boot.

http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg10216.html
> 
> DNS can be enabled by setting CFG_CMD_DNS. After performing a query,
> the serverip environment var is updated.
> 
> Probably there are some cosmetic issues with the patch. Unfortunatly I
> do not have the time to correct these. So if anybody else likes DNS
> support in U-Boot and has the time, feel free to patch it in the main tree.

Here it is again - slightly modified & smaller:
  - update to 2009-06 (Pieter's patch was for U-Boot 1.2.0)
  - README.dns is added
  - syntax is changed (now takes a third option, the env var to store
the result in)
  - add a random port() function in net.c
  - sort Makefile in ./net/Makefile
  - dns just returns unless a env var is given
  - run through checkpatch, and clean up style issues
  - remove packet from stack
  - cleaned up some comments
  - failure returns much faster (if server responds, don't wait for
timeout)
  - use built in functions (memcpy) rather than byte copy.
 

Signed-off-by: Robin Getz 
Signed-off-by: Pieter Voorthuijsen 

 common/cmd_net.c |   49 ++
 doc/README.dns   |   64 +
 include/net.h|5 +
 net/Makefile |7 -
 net/dns.c|  211 +
 net/dns.h|   39 
 net/net.c|   29 ++
 7 files changed, 401 insertions(+), 3 deletions(-)

---

diff --git a/common/cmd_net.c b/common/cmd_net.c
index 68183c4..ac706ae 100644
--- a/common/cmd_net.c
+++ b/common/cmd_net.c
@@ -353,3 +353,52 @@ U_BOOT_CMD(
"[NTP server IP]\n"
 );
 #endif
+
+#if defined(CONFIG_CMD_DNS)
+int do_dns(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
+{
+   if (argc == 1) {
+   cmd_usage(cmdtp);
+   return -1;
+   }
+
+   /*
+* We should check for a valid hostname:
+* - Each label must be between 1 and 63 characters long
+* - the entire hostname has a maximum of 255 characters
+* - only the ASCII letters 'a' through 'z' (case-insensitive),
+*   the digits '0' through '9', and the hyphen
+* - cannot begin or end with a hyphen
+* - no other symbols, punctuation characters, or blank spaces are
+*   permitted
+* but hey - this is a minimalist implmentation, so only check length
+* and let the name server deal with things.
+*/
+   if (strlen(argv[1]) >= 255) {
+   printf("dns error: hostname too long\n");
+   return 1;
+   }
+
+   NetDNSResolve = argv[1];
+
+   if (argc == 3)
+   NetDNSenvvar = argv[2];
+   else
+   NetDNSenvvar = NULL;
+
+   if (NetLoop(DNS) < 0) {
+   printf("dns lookup of %s failed, check setup\n", argv[1]);
+   return 1;
+   }
+
+   return 0;
+}
+
+U_BOOT_CMD(
+   dns,3,  1,  do_dns,
+   "lookup the IP of a hostname",
+   "hostname [envvar]"
+);
+
+#endif /* CONFIG_CMD_DNS */
+
diff --git a/doc/README.dns b/doc/README.dns
new file mode 100644
index 000..deeccd7
--- /dev/null
+++ b/doc/README.dns
@@ -0,0 +1,64 @@
+Domain Name System
+---
+
+The Domain Name System (DNS) is a hierarchical naming system for computers,
+services, or any resource participating in the Internet. It associates various
+information with domain names assigned to each of the participants. Most
+importantly, it translates domain names meaningful to humans into the numerical
+(binary) identifiers associated with networking equipment for the purpose of
+locating and addressing these devices world-wide. An often used analogy to
+explain the Domain Name System is that it serves as the "phone book" for the
+Internet by translating human-friendly computer hostnames into IP addresses.
+For example, www.example.com translates to 208.77.188.166.
+
+For more information on DNS - http://en.wikipedia.org/wiki/Domain_Name_System
+
+
+
+U-Boot and DNS
+--
+
+CONFIG_CMD_DNS - controls if the 'dns' command is compiled in. If it is, it
+ will send name lookups to the dns server (env var 'dnsip')
+ Turning this option on will about abou 1k to U-Boot's size.
+
+ Example:
+
+bfin> print dnsip
+dnsip=192.168.0.1
+
+bfin> dns www.google.com
+66.102.1.104
+
+ By default, dns does nothing except print the IP number on
+ the default console - which by itself, would be pretty
+ useless. Adding a third argument to the dns command will
+ use that as the environment variable to be set.
+
+ Example:
+
+bfin> print googleip
+## Error: "googleip" not defined
+bfin> dns www.google.com googleip
+64.233.161.104
+bfin> print googleip
+googleip=64.233.161.104
+bfin> ping ${googleip}
+Using Blackfin EMAC device
+host 6

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

[Rafal Jaworowski]

On 2009-07-19, at 04:22, Mike Frysinger wrote:

> 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
> }

Such conditional entries in the jumptable make this interface  
unstable, as the calls table is made dependent on configuration of a  
particular image built, while it should only depend on the interface  
version. The application in such case is entagled with the knowledge  
of how the underlying firmware was configured at build time. I know  
there are other calls already #ifdef'ed, but they should be all fixed.

Rafal

___
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 <200907192355.41601.rg...@blackfin.uclinux.org> you wrote:
>
> People responsible for the archicture/CPU core may set things up, and
> not want anyone to change things - on any SoC or Board. 
> 
> People responsible for SoC developments should be able to take what
> the arch provider delivers, write a few device drivers, make some
> specific choices that anyone who implements that SoC is going to have
> to live with.
> 
> People responsible for Board porting, should be able to take what
> the SoC provider delivers, customise things for their platform,
> and move on.
> 
> Then there are end users - which must live with the choices that all three
> have made, until they get their own hardware back, or in the case where
> the hardware is a module - just change some non-hardware related options.
> 
> So maybe it is core, chip, PCB, and user.
> 
> In some cases - all 4 categories are the same person - in many cases they
> are not.

You seem to live on a different planet than me. 

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Any sufficiently advanced bug is indistinguishable from a feature.
  - Rich Kulawiec
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] How to reduce size of U-Boot image (i.MX31, NAND-Flash)

[Wolfgang Denk]

Dear "Ulrich Gerster",

In message <4a64285f024d00014...@hochblauen.ba-loerrach.de> you wrote:
> 
> I'm trying to optimize the u-boot image I get after compiling. It's size is 
> 13XkB depending on the features I define. I'm using a i.MX31 processor and 
> only NAND-Flash. I think it should be possible to get a smaller Image.

We will not send you any new information, no matter how often you are
going to repost the very same question.


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
Comparing information  and  knowledge  is  like  asking  whether  the
fatness  of  a  pig  is more or less green than the designated hitter
rule."   - David Guaspari
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] ppc4xx: use TCR macro instead of tcr

[Wolfgang Denk]

Dear matthias.fu...@esd.eu,

In message <12480849383077-git-send-email-matthias.fu...@esd.eu> you wrote:
> 
> This patch migrates 4xx code from using the lowercase tcr macro
> to the uppercase TCR macro. Both macros have been defined in the past.
> So one is to much and uppercase macros are much more common.

I think this should not be TCR either. This should be SPRN_TCR as
defined in .

> diff --git a/cpu/ppc4xx/start.S b/cpu/ppc4xx/start.S
> index 582c781..22bc409 100644
> --- a/cpu/ppc4xx/start.S
> +++ b/cpu/ppc4xx/start.S
> @@ -626,7 +626,7 @@ _start:
>   mtspr   tbl,r0  /* prevent fit & wdt exceptions */
>   mtspr   tbu,r0
>   mtspr   tsr,r1  /* clear all timer exception status */
> - mtspr   tcr,r0  /* disable all */
> + mtspr   TCR,r0  /* disable all */
>   mtspr   esr,r0  /* clear exception syndrome register */
>   mtxer   r0  /* clear integer exception register */

Now this mix of lower case and upper case names is really ugly, isn't
it?

> diff --git a/include/ppc405.h b/include/ppc405.h
> index 917afec..50fc7be 100644
> --- a/include/ppc405.h
> +++ b/include/ppc405.h
> @@ -61,7 +61,6 @@
>   #define  dear  0x3d5  /* data exeption address register */
>   #define  evpr  0x3d6  /* exeption vector prefix register */
>   #define  tsr   0x3d8  /* timer status register */
> - #define  tcr   0x3da  /* timer control register */
>   #define  pit   0x3db  /* programmable interval timer */
>   #define  sgr   0x3b9  /* storage guarded reg  */
>   #define  dcwr  0x3ba  /* data cache write-thru reg*/
> diff --git a/include/ppc440.h b/include/ppc440.h
> index 01f6eaf..df78eea 100644
> --- a/include/ppc440.h
> +++ b/include/ppc440.h
> @@ -90,7 +90,6 @@
>  #define   dvc1   0x13e   /* data value compare 1 */
>  #define   dvc2   0x13f   /* data value compare 2 */
>  #define   tsr0x150   /* timer status register */
> -#define   tcr0x154   /* timer control register */
>  #define   ivor0  0x190   /* interrupt vector offset register 0 */
>  #define   ivor1  0x191   /* interrupt vector offset register 1 */
>  #define   ivor2  0x192   /* interrupt vector offset register 2 */

I think all these can be dumped - they should be taken from
 instead. 

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 high cost of living hasn't affected its popularity.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear matthias.fu...@esd.eu,

In message <12480877043650-git-send-email-matthias.fu...@esd.eu> you wrote:
> From: Matthias Fuchs 
> 
> Signed-off-by: Matthias Fuchs 

It would really be nice if you marked new versions of older
submissions as such, and added some information about what exactly you
changed.


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 complex system that works is invariably found to have evolved from
a simple system that worked." - John Gall, _Systemantics_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Kim Phillips,

In message <20090718200944.7c9d3eec.kim.phill...@freescale.com> you wrote:
> 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(-)

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
You may call me by my name, Wirth, or by my value, Worth.
- Nicklaus Wirth
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Mike Frysinger,

In message <1247966220-23627-1-git-send-email-vap...@gentoo.org> you wrote:
> 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

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
Madness takes its toll. Please have exact change.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Stefan Roese,

In message <200907200927.39207...@denx.de> you wrote:
> The following changes since commit b86b85e2611d57d834795a92453431a1a340c3c9:
>   Ilya Yanok (1):
> mmc: set bus width to 1 and clock to minimum early during 
> initialization
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ubi.git master
> 
> Andrzej Wolski (1):
>   ubi: help message correction
> 
>  common/cmd_ubi.c |4 ++--
>  1 files changed, 2 insertions(+), 2 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
He is truly wise who gains wisdom from another's mishap.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4a64516d.4020...@denx.de> you wrote:
> Hello Wolfgang,
> 
> The following changes since commit b86b85e2611d57d834795a92453431a1a340c3c9:
>   Ilya Yanok (1):
> mmc: set bus width to 1 and clock to minimum early during 
> initialization
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-i2c.git master
> 
> Peter Tyser (1):
>   Remove last remanants of unused CONFIG_I2C_CMD_TREE
> 
>  include/configs/P2020DS.h |1 -
>  include/configs/XPEDITE5170.h |1 -
>  include/configs/aria.h|1 -
>  include/configs/mecp5123.h|1 -
>  4 files changed, 0 insertions(+), 4 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
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Thomas Petazzoni,

In message <20090720174220.1800d...@surf> you wrote:
>
> > Any specific reason for not using autosizing and testing via
> > get_ram_size() ?
> 
> The initial reason is that the code for this board is taken from the
> Atmel boards code, which doesn't use get_ram_size(). However, my board
> has a fixed RAM size, so in that case, is it still useful to use
> get_ram_size() ?

Yes, it is still useful, as it will for example  detect  most  memory
errors and as such broken (or dying) hardware.

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
Often it is fatal to live too long.  - Racine
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Andrzej Wolski]

> 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.

Page size is not always 1056/1024 bytes, it is depended on total memory 
size.

> + if (flash_set_pow2(slave)) {
> + puts("setting pow2 mode failed\n");
> + goto done;
> + }
> +
> + puts("OK!\n");
> +
> + done:
> + spi_release_bus(slave);
> + spi_free_slave(slave);
> + }
> +}

DafaFlash documentation says that "The device must be power cycled after 
the completion of the program cycle to set the power of 2 page size", so 
it would be good to print that information at the end of programming.

Regards,
Andrzej Wolski



--
Daj odpoczac plecom - zmien auto na rower 
Sprawdz >>>http://link.interia.pl/f2255

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

Re: [U-Boot] [PATCH 6/6] S5PC100: Add onenand_ipl for SMDKC100 support

[Wolfgang Denk]

Dear Kyungmin Park,

In message <9c9fda240907192016i32c7312dh490629f2f2bb3...@mail.gmail.com> you 
wrote:
> 
> >>  /* read a page with ECC */
> >>  static inline int onenand_read_page(ulong block, ulong page,
> >>   u_char * buf> , int pagesize)
> >>  {
> >> +#ifdef CONFIG_S5PC1XX
> >> + unsigned int *p = (unsigned int *) buf;
> >> + int mem_addr, i;
> >> +
> >> + mem_addr = MEM_ADDR(block, page, 0);
> >> +
> >> + pagesize >>= 2;
> >> +
> >> + for (i = 0; i < pagesize; i++)
> >> + *p++ = *(volatile unsigned int *)(CMD_MAP_01> (mem_addr));
> >> +#else/* CONFIG_S5PC1XX */
> >> +
> >>   unsigned long *base;
> >
> > I don't like to see such board specific code in global files.
>
> I think it's not board specific code. S3C64XX and S5PC1XX series have
> own OneNAND controller and to access the OneNAND, it should use the
> this controller.

OK, so it is SoC specific code in a common file - that's just
marginally better.

> If you don't like the ifdef. we can separate the function but I'm not
> sure it's really required.

It would be great if we can get rid of the #ifdef.

> > Also, please use I/O accessor functions instead of register accesses.
>
> readl(...)? If yes, I agree it.

Yes.

> >> @@ -114,6 +129,9 @@ int onenand_read_block(unsigned char *buf)
> >>
> >>   erasesize = ONENAND_PAGES_PER_BLOCK * pagesize;
> >>   nblocks = (CONFIG_SYS_MONITOR_LEN + erasesize - 1) >> eras> e_shift;
> >> +#ifdef CONFIG_S5PC1XX
> >> + nblocks = 1;
> >> +#endif
> >
> > Again: why do we need such board specific code here?
>
> It should be fixed.

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
Just about every computer on the market today runs Unix,  except  the
Mac (and nobody cares about it).   - Bill Joy 6/21/85
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3

[Wolfgang Denk]

Dear Giuseppe CONDORELLI,

In message <1246273458-19028-1-git-send-email-giuseppe.condore...@st.com> you 
wrote:
> This patch updates zlib to the latest stable version.
> Only relevant zlib parts were ported to u-boot tree, as already did for the
> current zlib (0.95). New zlib guarantees a faster inflate performances
> other then others improvements as explained at www.zlib.net
> 
> Signed-off-by: Giuseppe Condorelli 
> ---
>  include/u-boot/zlib.h |  718 ++---
>  lib_generic/zlib.c| 3930 
> +
>  2 files changed, 2463 insertions(+), 2185 deletions(-)

Applied, thanks.

But please be more careful about CodingStyle:

...
Applying: zlib: updated to v.1.2.3
/home/wd/git/u-boot/work/.git/rebase-apply/patch:30: trailing whitespace.
  */ 
/home/wd/git/u-boot/work/.git/rebase-apply/patch:493: trailing whitespace.
int data_type;  /* best guess about the data type: 
warning: 2 lines applied after fixing whitespace errors.


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 committee is a life form with six or more legs and no brain.
  -- Lazarus Long, "Time Enough For Love"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/8]: Define ffs/fls for all architectures

[Wolfgang Denk]

Dear Simon Kagstrom,

In message <20090707155734.4b757...@marrow.netinsight.se> you wrote:
> UBIFS requires fls(), which is not defined for arm (and some other
> architectures) and this patch adds it. The implementation is taken from
> Linux and is generic. ffs() is also defined for those that miss it.
> 
> Signed-off-by: Simon Kagstrom 
> ---
>  include/asm-arm/bitops.h|4 
>  include/asm-avr32/bitops.h  |3 +++
>  include/asm-i386/bitops.h   |2 ++
>  include/asm-m68k/bitops.h   |2 ++
>  include/asm-microblaze/bitops.h |2 ++
>  include/asm-mips/bitops.h   |2 ++
>  include/asm-nios/bitops.h   |4 +++-
>  include/asm-nios2/bitops.h  |4 +++-
>  include/asm-sh/bitops.h |2 ++
>  include/asm-sparc/bitops.h  |3 +++
>  include/linux/bitops.h  |   37 +
>  11 files changed, 63 insertions(+), 2 deletions(-)

This patch does not apply at all:

Applying: Define ffs/fls for all architectures
error: patch failed: include/asm-avr32/bitops.h:25
error: include/asm-avr32/bitops.h: patch does not apply
error: patch failed: include/asm-nios/bitops.h:32
error: include/asm-nios/bitops.h: patch does not apply
error: patch failed: include/asm-nios2/bitops.h:32
error: include/asm-nios2/bitops.h: patch does not apply
error: patch failed: include/asm-sh/bitops.h:147
error: include/asm-sh/bitops.h: patch does not apply
error: patch failed: include/asm-sparc/bitops.h:29
error: include/asm-sparc/bitops.h: patch does not apply
fatal: sha1 information is lacking or useless (include/asm-avr32/bitops.h).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.


> diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
> index 4b8bab2..e98dd56 100644
> --- a/include/asm-arm/bitops.h
> +++ b/include/asm-arm/bitops.h
> @@ -17,6 +17,8 @@
>  
>  #ifdef __KERNEL__
>  
> +#include 
> +
>  #define smp_mb__before_clear_bit()   do { } while (0)
>  #define smp_mb__after_clear_bit()do { } while (0)
>  
> @@ -117,6 +119,8 @@ static inline unsigned long ffz(unsigned long word)
>  
>  #define ffs(x) generic_ffs(x)
>  
> +#define fls(x) generic_fls(x)

Please use a consistent style: here you have an empty line between
the two #define's.

> diff --git a/include/asm-avr32/bitops.h b/include/asm-avr32/bitops.h
> index bb272d8..75ba1c2 100644
> --- a/include/asm-avr32/bitops.h
> +++ b/include/asm-avr32/bitops.h
> @@ -25,4 +25,7 @@
>  #define __set_bit(nr, addr) generic_set_bit(nr, addr)
>  #define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
>  
> +#define ffs(x) generic_ffs(x)
> +#define fls(x) generic_fls(x)

Here you don't ... and do on.


Please clean up and resubmit.

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 is a multi-legged creature crawling on your shoulder.
-- Spock, "A Taste of Armageddon", stardate 3193.9
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 4/8]: Add unaligned.h for arm

[Wolfgang Denk]

Dear Simon Kagstrom,

In message <20090707155851.7dced...@marrow.netinsight.se> you wrote:
> This patch adds unaligned.h for ARM (needed to build with LZO
> compression). The file is taken from the linux kernel, but includes
> u-boot headers instead.
> 
> Signed-off-by: Simon Kagstrom 
> ---
>  include/asm-arm/unaligned.h |   18 ++
>  1 files changed, 18 insertions(+), 0 deletions(-)
>  create mode 100644 include/asm-arm/unaligned.h

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
Be careful what you wish for. You never know who will be listening.
  - Terry Pratchett, _Soul Music_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Simon Kagstrom,

In message <20090707155927.78e75...@marrow.netinsight.se> you wrote:
> Signed-off-by: Simon Kagstrom 
> ---
>  lib_generic/vsprintf.c |7 +--
>  1 files changed, 1 insertions(+), 6 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
Hindsight is an exact science.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] fsl_sata: Fix compiler warnings shown by gcc-4.4

[Wolfgang Denk]

Dear Kumar Gala,

In message <124701-22858-1-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> From: galak 
> 
> Update fsl_sata to use common structures instead of casting
> back and forth between the fsl specific ones and the common ones
> (which are identical).
> 
> fsl_sata.c: In function 'scan_sata':
> fsl_sata.c:550: warning: dereferencing pointer 'cfis' does break 
> strict-aliasing rules
> fsl_sata.c:549: warning: dereferencing pointer 'cfis' does break 
> strict-aliasing rules
> fsl_sata.c:548: warning: dereferencing pointer 'cfis' does break 
> strict-aliasing rules
> fsl_sata.c:545: note: initialized from here
> fsl_sata.c:592: warning: dereferencing pointer 'cfis' does break 
> strict-aliasing rules
> fsl_sata.c:590: warning: dereferencing pointer 'cfis' does break 
> strict-aliasing rules
> fsl_sata.c:588: warning: dereferencing pointer 'cfis' does break 
> strict-aliasing rules
> fsl_sata.c:586: warning: dereferencing pointer 'cfis' does break 
> strict-aliasing rules
> fsl_sata.c:579: warning: dereferencing pointer 'cfis' does break 
> strict-aliasing rules
> ...
> 
> Signed-off-by: Kumar Gala 
> ---
>  drivers/block/fsl_sata.c |   54 -
>  drivers/block/fsl_sata.h |   46 ---
>  2 files changed, 19 insertions(+), 81 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
Violence in reality is quite different from theory.
-- Spock, "The Cloud Minders", stardate 5818.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Refresh LZMA-lib to 4.65

[Wolfgang Denk]

Dear Luigi 'Comio' Mantellini,

In message <1246985548-24183-1-git-send-email-luigi.mantellini...@gmail.com> 
you wrote:
> --===1785671948==
> 
> From: Luigi 'Comio' Mantellini 
> 
> ---
>  common/cmd_bootm.c |5 +-
>  include/lzma/LzmaDec.h |   31 +
>  include/lzma/LzmaDecode.h  |   31 -
>  include/lzma/LzmaTools.h   |2 +-
>  include/lzma/LzmaTypes.h   |   15 +-
>  lib_generic/lzma/LGPL.txt  |  502 --
>  lib_generic/lzma/LzmaDec.c | 1007 +
>  lib_generic/lzma/LzmaDec.h |  223 +++
>  lib_generic/lzma/LzmaDecode.c  |  584 -
>  lib_generic/lzma/LzmaDecode.h  |  113 
>  lib_generic/lzma/LzmaTools.c   |  164 +++---
>  lib_generic/lzma/LzmaTools.h   |4 +-
>  lib_generic/lzma/LzmaTypes.h   |   45 --
>  lib_generic/lzma/Makefile  |4 +-
>  lib_generic/lzma/README.txt|8 +-
>  lib_generic/lzma/Types.h   |  208 ++
>  lib_generic/lzma/history.txt   |  434 +++--
>  lib_generic/lzma/import_lzmasdk.sh |8 +-
>  lib_generic/lzma/lzma.txt  | 1257 
> +---
>  19 files changed, 2398 insertions(+), 2247 deletions(-)
>  create mode 100644 include/lzma/LzmaDec.h
>  delete mode 100644 include/lzma/LzmaDecode.h
>  delete mode 100644 lib_generic/lzma/LGPL.txt
>  create mode 100644 lib_generic/lzma/LzmaDec.c
>  create mode 100644 lib_generic/lzma/LzmaDec.h
>  delete mode 100644 lib_generic/lzma/LzmaDecode.c
>  delete mode 100644 lib_generic/lzma/LzmaDecode.h
>  delete mode 100644 lib_generic/lzma/LzmaTypes.h
>  create mode 100644 lib_generic/lzma/Types.h

Are you going to resend an updated version of this patch any time
soon so it can go into this upcoming release?

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
Humanity has the  stars  in  its  future,  and  that  future  is  too
important  to be lost under the burden of juvenile folly and ignorant
superstition.  - Isaac Asimov
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3

[Wolfgang Denk]

Dear Giuseppe CONDORELLI,

In message <20090720213352.186e3832e...@gemini.denx.de> I wrote:
> Dear Giuseppe CONDORELLI,
> 
> In message <1246273458-19028-1-git-send-email-giuseppe.condore...@st.com> you 
> wrote:
> > This patch updates zlib to the latest stable version.
> > Only relevant zlib parts were ported to u-boot tree, as already did for the
> > current zlib (0.95). New zlib guarantees a faster inflate performances
> > other then others improvements as explained at www.zlib.net
> > 
> > Signed-off-by: Giuseppe Condorelli 
> > ---
> >  include/u-boot/zlib.h |  718 ++---
> >  lib_generic/zlib.c| 3930 
> > +
> >  2 files changed, 2463 insertions(+), 2185 deletions(-)
> 
> Applied, thanks.

Stope. I backed out your patch as it is causing compile problems. It
seems you did not do basic testing like running MAKEALL:

...
Configuring for netstar board...
/home/wd/git/u-boot/work/lib_generic/crc32.c:157: error: conflicting types for 
'crc32'
/home/wd/git/u-boot/work/include/u-boot/zlib.h:667: error: previous declaration 
of 'crc32' was here
make[1]: *** [crc32.o] Error 1


Please fix and resubmit.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Man is the best computer we can put aboard a spacecraft ...  and  the
only one that can be mass produced with unskilled labor.
 -- Wernher von Braun
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Simon Kagstrom,

In message <20090720214252.b0b6e832e...@gemini.denx.de> I wrote:
> Dear Simon Kagstrom,
> 
> In message <20090707155927.78e75...@marrow.netinsight.se> you wrote:
> > Signed-off-by: Simon Kagstrom 
> > ---
> >  lib_generic/vsprintf.c |7 +--
> >  1 files changed, 1 insertions(+), 6 deletions(-)
> 
> Applied, thanks.

Sorry, I had to back out your patch. as it is causing compile problems:

-> ./MAKEALL voiceblue
Configuring for voiceblue board...
vsprintf.c: In function 'put_dec':
vsprintf.c:237: warning: comparison of distinct pointer types lacks a cast
vsprintf.c:237: warning: right shift count >= width of type
vsprintf.c:237: warning: passing argument 1 of '__div64_32' from incompatible 
pointer type
   textdata bss dec hex filename
 1420995196   23304  170599   29a67 ./u-boot

Please fix and resubmit.

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 think animal testing is a terrible idea; they get all  nervous  and
give the wrong answers.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] netstar/voiceblue: remove no-need libgcc link for eeprom standalone

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <1247085496-21754-2-git-send-email-plagn...@jcrosoft.com> you wrote:
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD 
> ---
>  board/netstar/Makefile   |3 +--
>  board/voiceblue/Makefile |3 +--
>  2 files changed, 2 insertions(+), 4 deletions(-)

Sorry, patch does not apply:

Applying: netstar/voiceblue: netstar/voiceblue: remove no-need libgcc link for 
eeprom standalone
error: patch failed: board/netstar/Makefile:52
error: board/netstar/Makefile: patch does not apply
error: patch failed: board/voiceblue/Makefile:46
error: board/voiceblue/Makefile: patch does not apply
fatal: sha1 information is lacking or useless (board/netstar/Makefile).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.


Please clean up (and when doing so, please change the subject into
"don't link unneeded libgcc for eeprom standalone") and resubmit.
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
"Text processing has made it possible to right-justify any idea, even
one which cannot be justified on any other grounds."
 -- J. Finnegan, USC.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/3] powerpc: updates for the keymile boards

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4a55c0a2.2010...@denx.de> you wrote:
> - CONFIG_SYS_MAX_I2C_BUS changed to 1
>   We use only one I2C hardwarecontroller on this boards, so
>   change the CONFIG_SYS_MAX_I2C_BUS to 1.
> - common: dont print errormsg if second IVM Block lacks.
> - 82xx, mgcoge: fix double mtdpart entry in environment
> - 82xx, mgcoge: activate on second Flash the second bank.
> - common: CONFIG_ENV_SIZE 0x4000 for all keymile boards
> - common: Change malloc size to 1MByte for all Keymile boards
> We need a bigger malloc area for the environment support (128k)
> on some Keymile boards (kmeter1) and the upcoming UBI support.
> Change it to 1MB for all Keymile boards to be on the save side.
> Also define CONFIG_SYS_64BIT_VSPRINTF which is needed for
> UBI/UBIFS support.
> - Add UBI support to all Keymile boards
> - change manner of writing "/localbus/ranges" node
> instead of writting the complete "/localbus/ranges" node
> before booting Linux, only update the ranges entries
> which gets dynamical detected (size of flashes).
> This is needed, because keymile adds in the DTS
> "/localbus/ranges" node entries, which u-boot must
> not overwrite/delete.
> - kmeter, mgcoge: define 2 seperate regions needed for the Intel P30 chips
> The Intel P30 chip has 2 non-identical chips on
> one die, so we need to define 2 seperate regions
> that are scanned by physmap_of independantly.
> - kmeter1: Add MTD concat support to Keymile boards
> - 82xx, mgcoge: add "unlock=yes" to default environment
> - added CONFIG_MTD_DEVICE to get in sync with mainline code
> 
> Signed-off-by: Heiko Schocher 
> Signed-off-by: Stefan Roese 
> ---
>  board/keymile/common/common.c|   35 ++--
>  board/keymile/common/common.h|   10 ++
>  board/keymile/km8xx/km8xx.c  |   42 
>  board/keymile/kmeter1/kmeter1.c  |   51 +
>  board/keymile/mgcoge/mgcoge.c|   67 
> +++---
>  include/configs/keymile-common.h |   17 +-
>  include/configs/km8xx.h  |2 -
>  include/configs/kmeter1.h|7 +---
>  include/configs/mgcoge.h |   24 +++--
>  include/i2c.h|2 +
>  10 files changed, 202 insertions(+), 55 deletions(-)

Applied - after fixing a merge confligt in include/configs/kmeter1.h

Please check that everything 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
Faith may be defined briefly as an illogical belief in the  occurence
of the improbable.- H. L. Mencken
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ignore tags

[Wolfgang Denk]

Dear ratbert.chu...@gmail.com,

In message <1247221534-26150-1-git-send-email-ratbert.chu...@gmail.com> you 
wrote:
> From: Po-Yu Chuang 
> 
> Signed-off-by: Po-Yu Chuang 
> ---
>  .gitignore |1 +
>  1 files changed, 1 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
Never underestimate the bandwidth of a station wagon full of tapes.
-- Dr. Warren Jackson, Director, UTCS
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/6] Move architecture specific config.mk files into subdirs

[Wolfgang Denk]

Dear Peter Tyser,

In message <1247241800-29059-2-git-send-email-pty...@xes-inc.com> you wrote:
> This cleans up U-Boot's toplevel directory a bit and makes the
> architecture 'config.mk' file naming and location similar to board and
> cpu 'config.mk' files
> 
> Signed-off-by: Peter Tyser 
> ---
>  config.mk|2 +-
>  arm_config.mk => lib_arm/config.mk   |0
>  avr32_config.mk => lib_avr32/config.mk   |0
>  blackfin_config.mk => lib_blackfin/config.mk |0
>  i386_config.mk => lib_i386/config.mk |0
>  m68k_config.mk => lib_m68k/config.mk |0
>  microblaze_config.mk => lib_microblaze/config.mk |0
>  mips_config.mk => lib_mips/config.mk |0
>  nios_config.mk => lib_nios/config.mk |0
>  nios2_config.mk => lib_nios2/config.mk   |0
>  ppc_config.mk => lib_ppc/config.mk   |0
>  sh_config.mk => lib_sh/config.mk |0
>  sparc_config.mk => lib_sparc/config.mk   |0
>  13 files changed, 1 insertions(+), 1 deletions(-)
>  rename arm_config.mk => lib_arm/config.mk (100%)
>  rename avr32_config.mk => lib_avr32/config.mk (100%)
>  rename blackfin_config.mk => lib_blackfin/config.mk (100%)
>  rename i386_config.mk => lib_i386/config.mk (100%)
>  rename m68k_config.mk => lib_m68k/config.mk (100%)
>  rename microblaze_config.mk => lib_microblaze/config.mk (100%)
>  rename mips_config.mk => lib_mips/config.mk (100%)
>  rename nios_config.mk => lib_nios/config.mk (100%)
>  rename nios2_config.mk => lib_nios2/config.mk (100%)
>  rename ppc_config.mk => lib_ppc/config.mk (100%)
>  rename sh_config.mk => lib_sh/config.mk (100%)
>  rename sparc_config.mk => lib_sparc/config.mk (100%)

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
"Do we define evil as the absence of goodness? It seems only  logical
that shit happens--we discover this by the process of elimination."
-- Larry Wall
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 5/6] Move examples/ to examples/standalone

[Wolfgang Denk]

Dear Peter Tyser,

In message <1247241800-29059-6-git-send-email-pty...@xes-inc.com> you wrote:
> The current files in examples are all standalone application examples,
> so put them in their own subdirectory for organizational purposes
> 
> Signed-off-by: Peter Tyser 
> ---
>  Makefile |   16 ++--
>  examples/{ => standalone}/.gitignore |0
>  examples/{ => standalone}/82559_eeprom.c |0
>  examples/{ => standalone}/Makefile   |0
>  examples/{ => standalone}/README.smc9_eeprom |0
>  examples/{ => standalone}/eepro100_eeprom.c  |0
>  examples/{ => standalone}/hello_world.c  |0
>  examples/{ => standalone}/interrupt.c|0
>  examples/{ => standalone}/mem_to_mem_idma2intr.c |0
>  examples/{ => standalone}/mips.lds   |0
>  examples/{ => standalone}/nios.lds   |0
>  examples/{ => standalone}/nios2.lds  |0
>  examples/{ => standalone}/ppc_longjmp.S  |0
>  examples/{ => standalone}/ppc_setjmp.S   |0
>  examples/{ => standalone}/sched.c|0
>  examples/{ => standalone}/smc9_eeprom.c  |0
>  examples/{ => standalone}/smc911x_eeprom.c   |0
>  examples/{ => standalone}/sparc.lds  |0
>  examples/{ => standalone}/stubs.c|0
>  examples/{ => standalone}/test_burst.c   |0
>  examples/{ => standalone}/test_burst.h   |0
>  examples/{ => standalone}/test_burst_lib.S   |0
>  examples/{ => standalone}/timer.c|0
>  examples/{ => standalone}/x86-testapp.c  |0
>  24 files changed, 10 insertions(+), 6 deletions(-)
>  rename examples/{ => standalone}/.gitignore (100%)
>  rename examples/{ => standalone}/82559_eeprom.c (100%)
>  rename examples/{ => standalone}/Makefile (100%)
>  rename examples/{ => standalone}/README.smc9_eeprom (100%)
>  rename examples/{ => standalone}/eepro100_eeprom.c (100%)
>  rename examples/{ => standalone}/hello_world.c (100%)
>  rename examples/{ => standalone}/interrupt.c (100%)
>  rename examples/{ => standalone}/mem_to_mem_idma2intr.c (100%)
>  rename examples/{ => standalone}/mips.lds (100%)
>  rename examples/{ => standalone}/nios.lds (100%)
>  rename examples/{ => standalone}/nios2.lds (100%)
>  rename examples/{ => standalone}/ppc_longjmp.S (100%)
>  rename examples/{ => standalone}/ppc_setjmp.S (100%)
>  rename examples/{ => standalone}/sched.c (100%)
>  rename examples/{ => standalone}/smc9_eeprom.c (100%)
>  rename examples/{ => standalone}/smc911x_eeprom.c (100%)
>  rename examples/{ => standalone}/sparc.lds (100%)
>  rename examples/{ => standalone}/stubs.c (100%)
>  rename examples/{ => standalone}/test_burst.c (100%)
>  rename examples/{ => standalone}/test_burst.h (100%)
>  rename examples/{ => standalone}/test_burst_lib.S (100%)
>  rename examples/{ => standalone}/timer.c (100%)
>  rename examples/{ => standalone}/x86-testapp.c (100%)

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 right is not what someone gives you; it's what no one can take from
you.   - Ramsey Clark
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 6/6] Move api_examples to examples/api

[Wolfgang Denk]

Dear Peter Tyser,

In message <1247241800-29059-7-git-send-email-pty...@xes-inc.com> you wrote:
> Signed-off-by: Peter Tyser 
> ---
>  Makefile|4 ++--
>  {api_examples => examples/api}/.gitignore   |0
>  {api_examples => examples/api}/Makefile |8 
>  {api_examples => examples/api}/crt0.S   |0
>  {api_examples => examples/api}/demo.c   |0
>  {api_examples => examples/api}/glue.c   |0
>  {api_examples => examples/api}/glue.h   |0
>  {api_examples => examples/api}/libgenwrap.c |0
>  8 files changed, 6 insertions(+), 6 deletions(-)
>  rename {api_examples => examples/api}/.gitignore (100%)
>  rename {api_examples => examples/api}/Makefile (91%)
>  rename {api_examples => examples/api}/crt0.S (100%)
>  rename {api_examples => examples/api}/demo.c (100%)
>  rename {api_examples => examples/api}/glue.c (100%)
>  rename {api_examples => examples/api}/glue.h (100%)
>  rename {api_examples => examples/api}/libgenwrap.c (100%)

This patch doesn't apply (at least not to the current code base):

Applying: Move api_examples to examples/api
error: patch failed: api_examples/Makefile:41
error: api_examples/Makefile: patch does not apply
fatal: sha1 information is lacking or useless (Makefile).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001.

Please resubmit (eventually in new context).

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 heart is not a logical organ.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
___
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 <1248033674.15400.9.ca...@ptyser-laptop> you wrote:
> On Sat, 2009-07-18 at 20:07 +0200, Wolfgang Denk wrote:
> > 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.
> 
> Any interest in picking up the following patches from this series for
> the upcoming release:
> 1/6 Move architecture specific config.mk files into subdirs
> 5/6 Move examples/ to examples/standalone
> 6/6 Move api_examples to examples/api
> 
> They're pretty straightforward and are 3 less changes to carry around.

OK, tried that. It worked for 1/6 and 5/6, but 6/6 failed,probably due
to missing/not matching context.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Conceptual integrity in turn dictates that the  design  must  proceed
from  one  mind,  or  from  a  very small number of agreeing resonant
minds.   - Frederick Brooks Jr., "The Mythical Man Month"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Wolfgang Denk]

Dear "Liu Dave-R63238",

In message 
 you wrote:
> > Previously, non-e500 architectures only unlocked their data 
> > cache which
> > was used as early RAM when booting to Linux using the "bootm" command.
> > This change causes all PPC boards with 
> > CONFIG_SYS_INIT_RAM_LOCK defined
> > to unlock their data cache during U-Boot's initialization.  This
> > improves U-Boot performance and provides a common cache state when
> > booting to different OSes.
> > 
> > Signed-off-by: Peter Tyser 
> > ---
> > I've tested this on 86xx boards, it'd be great if someone 
> > could test on
> > 83xx and 74xx/7xx.  85xx boards should not be affected by this change.
> > 
> > This change assumes 
> > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
> > has already been applied, or the lib/ppc patches in the diffs 
> > below can
> > be changed to lib_ppc.
> 
> I'm afraid some 83xx boards will not work after the patch is applied.
> It is some was assuming the data cache locked. (that is cache-inhibited)

Are you just concerned, or did you actually test the patch, with
negative results?

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

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

[Peter Tyser]

On Tue, 2009-07-21 at 00:15 +0200, Wolfgang Denk wrote:
> Dear Peter Tyser,
> 
> In message <1248033674.15400.9.ca...@ptyser-laptop> you wrote:
> > On Sat, 2009-07-18 at 20:07 +0200, Wolfgang Denk wrote:
> > > 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.
> > 
> > Any interest in picking up the following patches from this series for
> > the upcoming release:
> > 1/6 Move architecture specific config.mk files into subdirs
> > 5/6 Move examples/ to examples/standalone
> > 6/6 Move api_examples to examples/api
> > 
> > They're pretty straightforward and are 3 less changes to carry around.
> 
> OK, tried that. It worked for 1/6 and 5/6, but 6/6 failed,probably due
> to missing/not matching context.

Thanks for applying them.  I'll send 6/6 in a few minutes.

Peter

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

Re: [U-Boot] [PATCH] ppc: Unlock cache-as-ram in a consistent manner

[Liu Dave-R63238]

> > > I've tested this on 86xx boards, it'd be great if someone 
> > > could test on
> > > 83xx and 74xx/7xx.  85xx boards should not be affected by 
> this change.
> > > 
> > > This change assumes 
> > > http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63423
> > > has already been applied, or the lib/ppc patches in the diffs 
> > > below can
> > > be changed to lib_ppc.
> > 
> > I'm afraid some 83xx boards will not work after the patch 
> is applied.
> > It is some was assuming the data cache locked. (that is 
> cache-inhibited)
> 
> Are you just concerned, or did you actually test the patch, with
> negative results?

I'm just concerned. I didn't test the patch.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v3] Move api_examples to examples/api

[Peter Tyser]

Also add a rule to remove demo.bin which was previously leftover after a
"make clean"

Signed-off-by: Peter Tyser 
---
Changes since v2:
- Clean up demo.bin
- rebased

 Makefile|5 +++--
 {api_examples => examples/api}/.gitignore   |0
 {api_examples => examples/api}/Makefile |8 
 {api_examples => examples/api}/crt0.S   |0
 {api_examples => examples/api}/demo.c   |0
 {api_examples => examples/api}/glue.c   |0
 {api_examples => examples/api}/glue.h   |0
 {api_examples => examples/api}/libgenwrap.c |0
 8 files changed, 7 insertions(+), 6 deletions(-)
 rename {api_examples => examples/api}/.gitignore (100%)
 rename {api_examples => examples/api}/Makefile (91%)
 rename {api_examples => examples/api}/crt0.S (100%)
 rename {api_examples => examples/api}/demo.c (100%)
 rename {api_examples => examples/api}/glue.c (100%)
 rename {api_examples => examples/api}/glue.h (100%)
 rename {api_examples => examples/api}/libgenwrap.c (100%)

diff --git a/Makefile b/Makefile
index 9ffba2e..25a6254 100644
--- a/Makefile
+++ b/Makefile
@@ -141,7 +141,7 @@ endif
 # Don't include stuff already done in $(LIBS)
 SUBDIRS= tools \
  examples/standalone \
- api_examples
+ examples/api
 
 .PHONY : $(SUBDIRS)
 
@@ -3601,6 +3601,7 @@ clean:
   $(obj)examples/standalone/smc9_eeprom  \
   $(obj)examples/standalone/test_burst   \
   $(obj)examples/standalone/timer
+   @rm -f $(obj)examples/api/demo{,.bin}
@rm -f $(obj)tools/bmp_logo$(obj)tools/easylogo/easylogo  \
   $(obj)tools/env/{fw_printenv,fw_setenv}\
   $(obj)tools/envcrc \
@@ -3617,7 +3618,7 @@ clean:
@rm -f $(obj)include/bmp_logo.h
@rm -f $(obj)nand_spl/{u-boot-spl,u-boot-spl.map,System.map}
@rm -f 
$(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl-2k.bin,ipl-4k.bin,ipl.map}
-   @rm -f $(obj)api_examples/demo $(TIMESTAMP_FILE) $(VERSION_FILE)
+   @rm -f $(TIMESTAMP_FILE) $(VERSION_FILE)
@find $(OBJTREE) -type f \
\( -name 'core' -o -name '*.bak' -o -name '*~' \
-o -name '*.o'  -o -name '*.a' -o -name '*.exe' \) -print \
diff --git a/api_examples/.gitignore b/examples/api/.gitignore
similarity index 100%
rename from api_examples/.gitignore
rename to examples/api/.gitignore
diff --git a/api_examples/Makefile b/examples/api/Makefile
similarity index 91%
rename from api_examples/Makefile
rename to examples/api/Makefile
index 2a30bef..2d05a01 100644
--- a/api_examples/Makefile
+++ b/examples/api/Makefile
@@ -33,13 +33,13 @@ include $(TOPDIR)/config.mk
 OUTPUT-$(CONFIG_API) = $(obj)demo
 OUTPUT = $(OUTPUT-y)
 
-# Source files located in the api_examples directory
+# Source files located in the examples/api directory
 SOBJ_FILES-$(CONFIG_API) += crt0.o
 COBJ_FILES-$(CONFIG_API) += demo.o
 COBJ_FILES-$(CONFIG_API) += glue.o
 COBJ_FILES-$(CONFIG_API) += libgenwrap.o
 
-# Source files which exist outside the api_examples directory
+# Source files which exist outside the examples/api directory
 EXT_COBJ_FILES-$(CONFIG_API) += lib_generic/crc32.o
 EXT_COBJ_FILES-$(CONFIG_API) += lib_generic/ctype.o
 EXT_COBJ_FILES-$(CONFIG_API) += lib_generic/string.o
@@ -51,8 +51,8 @@ endif
 # Create a list of source files so their dependencies can be auto-generated
 SRCS   += $(addprefix $(SRCTREE)/,$(EXT_COBJ_FILES-y:.o=.c))
 SRCS   += $(addprefix $(SRCTREE)/,$(EXT_SOBJ_FILES-y:.o=.S))
-SRCS   += $(addprefix $(SRCTREE)/api_examples/,$(COBJ_FILES-y:.o=.c))
-SRCS   += $(addprefix $(SRCTREE)/api_examples/,$(SOBJ_FILES-y:.o=.S))
+SRCS   += $(addprefix $(SRCTREE)/examples/api/,$(COBJ_FILES-y:.o=.c))
+SRCS   += $(addprefix $(SRCTREE)/examples/api/,$(SOBJ_FILES-y:.o=.S))
 
 # Create a list of object files to be compiled
 OBJS   += $(addprefix $(obj),$(SOBJ_FILES-y))
diff --git a/api_examples/crt0.S b/examples/api/crt0.S
similarity index 100%
rename from api_examples/crt0.S
rename to examples/api/crt0.S
diff --git a/api_examples/demo.c b/examples/api/demo.c
similarity index 100%
rename from api_examples/demo.c
rename to examples/api/demo.c
diff --git a/api_examples/glue.c b/examples/api/glue.c
similarity index 100%
rename from api_examples/glue.c
rename to examples/api/glue.c
diff --git a/api_examples/glue.h b/examples/api/glue.h
similarity index 100%
rename from api_examples/glue.h
rename to examples/api/glue.h
diff --git a/api_examples/libgenwrap.c b/examples/api/libgenwrap.c
similarity index 100%
rename from api_examples/libgenwrap.c
rename to examples/api/libgenwrap.c
-- 
1.6.2.1

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

[U-Boot] [PATCH] OneNAND: S5PC100 OneNAND IPL support

[Kyungmin Park]

S5PC100 has own OneNAND controller and has different interface.
OneNAND IPL use it to S5PC100 board.

Signed-off-by: Kyungmin Park 
---
diff --git a/onenand_ipl/onenand_ipl.h b/onenand_ipl/onenand_ipl.h
index 412572a..b43ddfb 100644
--- a/onenand_ipl/onenand_ipl.h
+++ b/onenand_ipl/onenand_ipl.h
@@ -31,5 +31,14 @@
 #define READ_INTERRUPT()\
onenand_readw(THIS_ONENAND(ONENAND_REG_INTERRUPT))
 
+#ifdef CONFIG_S5PC1XX
+#define AHB_ADDR   0xB000
+#define MEM_ADDR(fba, fpa, fsa)((fba) << 13 | (fpa) << 7 | 
(fsa) << 5)
+#define CMD_MAP_01(mem_addr)   (AHB_ADDR | (1 << 26) | (mem_addr))
+#define CMD_MAP_11(addr)   (AHB_ADDR | (3 << 26) | ((addr) << 2))
+#undef onenand_readw
+#define onenand_readw(a)   (readl(CMD_MAP_11((a) >> 1)) & 0x)
+#endif
+
 extern int onenand_read_block(unsigned char *buf);
 #endif
diff --git a/onenand_ipl/onenand_read.c b/onenand_ipl/onenand_read.c
index d1a842d..7ffc9a9 100644
--- a/onenand_ipl/onenand_read.c
+++ b/onenand_ipl/onenand_read.c
@@ -37,6 +37,23 @@
 extern void *memcpy32(void *dest, void *src, int size);
 #endif
 
+#ifdef CONFIG_S5PC1XX
+static inline int onenand_read_page(ulong block, ulong page,
+   u_char * buf, int pagesize)
+{
+   unsigned int *p = (unsigned int *) buf;
+   int mem_addr, i;
+
+   mem_addr = MEM_ADDR(block, page, 0);
+
+   pagesize >>= 2;
+
+   for (i = 0; i < pagesize; i++)
+   *p++ = readl(CMD_MAP_01(mem_addr));
+
+   return 0;
+}
+#else
 /* read a page with ECC */
 static inline int onenand_read_page(ulong block, ulong page,
u_char * buf, int pagesize)
@@ -88,6 +105,7 @@ static inline int onenand_read_page(ulong block, ulong page,
 
return 0;
 }
+#endif
 
 #define ONENAND_START_PAGE 1
 #define ONENAND_PAGES_PER_BLOCK64
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 6/6] S5PC100: Add onenand_ipl for SMDKC100 support

[Kyungmin Park]

On Tue, Jul 21, 2009 at 6:18 AM, Wolfgang Denk wrote:
> Dear Kyungmin Park,
>
> In message <9c9fda240907192016i32c7312dh490629f2f2bb3...@mail.gmail.com> you 
> wrote:
>>
>> >>  /* read a page with ECC */
>> >>  static inline int onenand_read_page(ulong block, ulong page,
>> >>                               u_char * buf> , int pagesize)
>> >>  {
>> >> +#ifdef CONFIG_S5PC1XX
>> >> +     unsigned int *p = (unsigned int *) buf;
>> >> +     int mem_addr, i;
>> >> +
>> >> +     mem_addr = MEM_ADDR(block, page, 0);
>> >> +
>> >> +     pagesize >>= 2;
>> >> +
>> >> +     for (i = 0; i < pagesize; i++)
>> >> +             *p++ = *(volatile unsigned int *)(CMD_MAP_01> (mem_addr));
>> >> +#else        /* CONFIG_S5PC1XX */
>> >> +
>> >>       unsigned long *base;
>> >
>> > I don't like to see such board specific code in global files.
>>
>> I think it's not board specific code. S3C64XX and S5PC1XX series have
>> own OneNAND controller and to access the OneNAND, it should use the
>> this controller.
>
> OK, so it is SoC specific code in a common file - that's just
> marginally better.
>
>> If you don't like the ifdef. we can separate the function but I'm not
>> sure it's really required.
>
> It would be great if we can get rid of the #ifdef.

As you know, OneNAND IPL has size limitation, 1KiB. So it's difficult
to co-exist two different function.

Thank you,
Kyungmin Park
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] cmd_tsi148: General cleanup

[ptyser]

From: Peter Tyser 

- Fix command help message
- Disable DEBUG by default
- Fix whitespace issues
- Fix lines > 80 characters

Signed-off-by: Peter Tyser 
---
 common/cmd_tsi148.c |   85 ++
 1 files changed, 44 insertions(+), 41 deletions(-)

diff --git a/common/cmd_tsi148.c b/common/cmd_tsi148.c
index 222938c..f2097fd 100644
--- a/common/cmd_tsi148.c
+++ b/common/cmd_tsi148.c
@@ -24,8 +24,6 @@
  * MA 02111-1307 USA
  */
 
-#define DEBUG
-
 #include 
 #include 
 #include 
@@ -40,10 +38,10 @@
 typedef struct _TSI148_DEV TSI148_DEV;
 
 struct _TSI148_DEV {
-   intbus;
-   pci_dev_t  busdevfn;
-   TSI148*uregs;
-   unsigned int   pci_bs;
+   int   bus;
+   pci_dev_t busdevfn;
+   TSI148   *uregs;
+   unsigned int  pci_bs;
 };
 
 static TSI148_DEV *dev;
@@ -84,11 +82,12 @@ int tsi148_init(void)
 
debug("Tsi148: Base: %p\n", dev->uregs);
 
-   /* check mapping  */
-   debug("Tsi148: Read via mapping, PCI_ID = %08X\n", 
readl(&dev->uregs->pci_id));
-   if (((PCI_DEVICE << 16) | PCI_VENDOR) !=  readl(&dev->uregs->pci_id)) {
+   /* check mapping */
+   debug("Tsi148: Read via mapping, PCI_ID = %08X\n",
+ readl(&dev->uregs->pci_id));
+   if (((PCI_DEVICE << 16) | PCI_VENDOR) != readl(&dev->uregs->pci_id)) {
printf("Tsi148: Cannot read PCI-ID via Mapping: %08x\n",
-   readl(&dev->uregs->pci_id));
+  readl(&dev->uregs->pci_id));
result = -1;
goto break_30;
}
@@ -106,10 +105,12 @@ int tsi148_init(void)
/* Tsi148 VME timeout etc */
__raw_writel(htonl(0x0084), &dev->uregs->vctrl);
 
+#ifdef DEBUG
if ((__raw_readl(&dev->uregs->vstat) & 0x0100) != 0)
-   debug("Tsi148: System Controller!\n");
+   printf("Tsi148: System Controller!\n");
else
-   debug("Tsi148: Not System Controller!\n");
+   printf("Tsi148: Not System Controller!\n");
+#endif
 
/*
 * Lets turn off interrupts
@@ -126,7 +127,7 @@ int tsi148_init(void)
__raw_writel(htonl(0x), &dev->uregs->intm2);
eieio();
 
-   val  = __raw_readl(&dev->uregs->vstat);
+   val = __raw_readl(&dev->uregs->vstat);
val &= ~(0x4000);
__raw_writel(val, &dev->uregs->vstat);
eieio();
@@ -147,7 +148,8 @@ int tsi148_init(void)
 /*
  * Create pci slave window (access: pci -> vme)
  */
-int tsi148_pci_slave_window(unsigned int pciAddr, unsigned int vmeAddr, int 
size, int vam, int vdw)
+int tsi148_pci_slave_window(unsigned int pciAddr, unsigned int vmeAddr,
+   int size, int vam, int vdw)
 {
int result, i;
unsigned int ctl = 0;
@@ -172,13 +174,12 @@ int tsi148_pci_slave_window(unsigned int pciAddr, 
unsigned int vmeAddr, int size
 
printf("Tsi148: Pci addr %08x\n", pciAddr);
 
-
-   __raw_writel(htonl(pciAddr) , &dev->uregs->outbound[i].otsal);
-   __raw_writel(0x , &dev->uregs->outbound[i].otsau);
+   __raw_writel(htonl(pciAddr), &dev->uregs->outbound[i].otsal);
+   __raw_writel(0x, &dev->uregs->outbound[i].otsau);
__raw_writel(htonl(pciAddr + size), &dev->uregs->outbound[i].oteal);
-   __raw_writel(0x , &dev->uregs->outbound[i].oteau);
+   __raw_writel(0x, &dev->uregs->outbound[i].oteau);
__raw_writel(htonl(vmeAddr - pciAddr), &dev->uregs->outbound[i].otofl);
-   __raw_writel(0x , &dev->uregs->outbound[i].otofu);
+   __raw_writel(0x, &dev->uregs->outbound[i].otofu);
 
switch (vam & VME_AM_Axx) {
case VME_AM_A16:
@@ -213,7 +214,7 @@ int tsi148_pci_slave_window(unsigned int pciAddr, unsigned 
int vmeAddr, int size
break;
}
 
-   ctl |= 0x8004;/* enable, no prefetch */
+   ctl |= 0x8004;  /* enable, no prefetch */
 
__raw_writel(htonl(ctl), &dev->uregs->outbound[i].otat);
 
@@ -272,7 +273,8 @@ unsigned int tsi148_eval_vam(int vam)
 /*
  * Create vme slave window (access: vme -> pci)
  */
-int tsi148_vme_slave_window(unsigned int vmeAddr, unsigned int pciAddr, int 
size, int vam)
+int tsi148_vme_slave_window(unsigned int vmeAddr, unsigned int pciAddr,
+   int size, int vam)
 {
int result, i;
unsigned int ctl = 0;
@@ -306,13 +308,13 @@ int tsi148_vme_slave_window(unsigned int vmeAddr, 
unsigned int pciAddr, int size
__raw_writel(0x, &dev->uregs->inbound[i].itofu);
 
ctl = tsi148_eval_vam(vam);
-   ctl |= 0x8000;/* enable */
+   ctl |= 0x8000;  /* enable */
__raw_writel(htonl(ctl), &dev->uregs->inbound[i].itat);
 
debug("Tsi148: window-addr=%p\n",
  &dev->uregs->inbound[i].itsau);
debug("Tsi148: vme slave window[%d] 

[U-Boot] [PATCH] OneNAND: Remove unused read_spareram

[Kyungmin Park]

Remove unused read_spareram and add unlock_all as kernel does

Signed-off-by: Kyungmin Park 
---
diff --git a/drivers/mtd/onenand/onenand_base.c 
b/drivers/mtd/onenand/onenand_base.c
index d482437..368fa6e 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1010,7 +1010,7 @@ int onenand_bbt_read_oob(struct mtd_info *mtd, loff_t 
from,
if (ret)
break;
 
-   this->read_spareram(mtd, 0, ONENAND_SPARERAM, buf, column, 
thislen);
+   this->read_bufferram(mtd, 0, ONENAND_SPARERAM, buf, column, 
thislen);
read += thislen;
if (read == len)
break;
@@ -2104,8 +2104,6 @@ int onenand_scan(struct mtd_info *mtd, int maxchips)
 
if (!this->read_bufferram)
this->read_bufferram = onenand_read_bufferram;
-   if (!this->read_spareram)
-   this->read_spareram = onenand_read_bufferram;
if (!this->write_bufferram)
this->write_bufferram = onenand_write_bufferram;
 
diff --git a/include/linux/mtd/onenand.h b/include/linux/mtd/onenand.h
index 2597e34..06f7baf 100644
--- a/include/linux/mtd/onenand.h
+++ b/include/linux/mtd/onenand.h
@@ -83,10 +83,9 @@ struct onenand_chip {
size_t len);
int (*wait) (struct mtd_info *mtd, int state);
int (*bbt_wait) (struct mtd_info *mtd, int state);
+   void (*unlock_all)(struct mtd_info *mtd);
int (*read_bufferram) (struct mtd_info *mtd, loff_t addr, int area,
   unsigned char *buffer, int offset, size_t count);
-   int (*read_spareram) (struct mtd_info *mtd, loff_t addr, int area,
-  unsigned char *buffer, int offset, size_t count);
int (*write_bufferram) (struct mtd_info *mtd, loff_t addr, int area,
const unsigned char *buffer, int offset,
size_t count);
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] cmd_tsi148: General cleanup

[Stefan Roese]

On Tuesday 21 July 2009 04:51:38 pty...@xes-inc.com wrote:
> From: Peter Tyser 
>
> - Fix command help message
> - Disable DEBUG by default
> - Fix whitespace issues
> - Fix lines > 80 characters

Thanks Peter.

> Signed-off-by: Peter Tyser 

Acked-by: Stefan Roese 

Best regards,
Stefan

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

Re: [U-Boot] [PATCH 1/3] powerpc: updates for the keymile boards

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4a55c0a2.2010...@denx.de> you wrote:
>> - CONFIG_SYS_MAX_I2C_BUS changed to 1
>>   We use only one I2C hardwarecontroller on this boards, so
>>   change the CONFIG_SYS_MAX_I2C_BUS to 1.
>> - common: dont print errormsg if second IVM Block lacks.
>> - 82xx, mgcoge: fix double mtdpart entry in environment
>> - 82xx, mgcoge: activate on second Flash the second bank.
>> - common: CONFIG_ENV_SIZE 0x4000 for all keymile boards
>> - common: Change malloc size to 1MByte for all Keymile boards
>> We need a bigger malloc area for the environment support (128k)
>> on some Keymile boards (kmeter1) and the upcoming UBI support.
>> Change it to 1MB for all Keymile boards to be on the save side.
>> Also define CONFIG_SYS_64BIT_VSPRINTF which is needed for
>> UBI/UBIFS support.
>> - Add UBI support to all Keymile boards
>> - change manner of writing "/localbus/ranges" node
>> instead of writting the complete "/localbus/ranges" node
>> before booting Linux, only update the ranges entries
>> which gets dynamical detected (size of flashes).
>> This is needed, because keymile adds in the DTS
>> "/localbus/ranges" node entries, which u-boot must
>> not overwrite/delete.
>> - kmeter, mgcoge: define 2 seperate regions needed for the Intel P30 chips
>> The Intel P30 chip has 2 non-identical chips on
>> one die, so we need to define 2 seperate regions
>> that are scanned by physmap_of independantly.
>> - kmeter1: Add MTD concat support to Keymile boards
>> - 82xx, mgcoge: add "unlock=yes" to default environment
>> - added CONFIG_MTD_DEVICE to get in sync with mainline code
>>
>> Signed-off-by: Heiko Schocher 
>> Signed-off-by: Stefan Roese 
>> ---
>>  board/keymile/common/common.c|   35 ++--
>>  board/keymile/common/common.h|   10 ++
>>  board/keymile/km8xx/km8xx.c  |   42 
>>  board/keymile/kmeter1/kmeter1.c  |   51 +
>>  board/keymile/mgcoge/mgcoge.c|   67 
>> +++---
>>  include/configs/keymile-common.h |   17 +-
>>  include/configs/km8xx.h  |2 -
>>  include/configs/kmeter1.h|7 +---
>>  include/configs/mgcoge.h |   24 +++--
>>  include/i2c.h|2 +
>>  10 files changed, 202 insertions(+), 55 deletions(-)
> 
> Applied - after fixing a merge confligt in include/configs/kmeter1.h
> 
> Please check that everything is OK.

Hmm.. this chunk is missing:

diff --git a/include/configs/kmeter1.h b/include/configs/kmeter1.h
index 19da133..1735683 100644
--- a/include/configs/kmeter1.h
+++ b/include/configs/kmeter1.h
@@ -158,7 +158,6 @@
 #endif

 #define CONFIG_SYS_MONITOR_LEN (384 * 1024) /* Reserve 256 kB for Mon 
*/
-#define CONFIG_SYS_MALLOC_LEN  (128 * 1024) /* Reserved for malloc */

 /*
  * Initial RAM Base Address Setup


so, if actual compiling the kmeter1, I get a compile error, following patch
solves it:

[PATCH] 83xx, kmeter: fix compile error

CONFIG_SYS_MALLOC_LEN is defined in the board config, and
the keymile-common.h, which collects common options used
by all keymile-boards. This results in a compile error
when compiling the kmeter1 board. So remove this define
in the board config file.

Signed-off-by: Heiko Schocher 
---
 include/configs/kmeter1.h |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/include/configs/kmeter1.h b/include/configs/kmeter1.h
index 347b47c..7e16c56 100644
--- a/include/configs/kmeter1.h
+++ b/include/configs/kmeter1.h
@@ -158,7 +158,6 @@
 #endif

 #define CONFIG_SYS_MONITOR_LEN (384 * 1024) /* Reserve 384 kB for Mon 
*/
-#define CONFIG_SYS_MALLOC_LEN  (128 * 1024) /* Reserved for malloc */

 /*
  * Initial RAM Base Address Setup
-- 
1.6.0.6

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] v3 - add dns

[Ben Warren]

Hi Robin,

Robin Getz wrote:
> On 04 Oct 2008 Pieter posted a dns implementation for U-Boot.
>
> http://www.mail-archive.com/u-boot-us...@lists.sourceforge.net/msg10216.html
>   
>> DNS can be enabled by setting CFG_CMD_DNS. After performing a query,
>> the serverip environment var is updated.
>>
>> Probably there are some cosmetic issues with the patch. Unfortunatly I
>> do not have the time to correct these. So if anybody else likes DNS
>> support in U-Boot and has the time, feel free to patch it in the main tree.
>> 
>
> Here it is again - slightly modified & smaller:
>   - update to 2009-06 (Pieter's patch was for U-Boot 1.2.0)
>   - README.dns is added
>   - syntax is changed (now takes a third option, the env var to store
> the result in)
>   - add a random port() function in net.c
>   - sort Makefile in ./net/Makefile
>   - dns just returns unless a env var is given
>   - run through checkpatch, and clean up style issues
>   - remove packet from stack
>   - cleaned up some comments
>   - failure returns much faster (if server responds, don't wait for
> timeout)
>   - use built in functions (memcpy) rather than byte copy.
>  
>
> Signed-off-by: Robin Getz 
> Signed-off-by: Pieter Voorthuijsen 
>   
Looks like I missed a pretty interesting discussion here.  Anyway, patch 
V3 is applied to the net repo with some cosmetic changes to the 
changelog (no changes to the patch).

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

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

[Ben Warren]

Mike,

Mike Frysinger wrote:
> 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(-)
>   
Applied to net repo.

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

Re: [U-Boot] [PATCH v2] net: tsec - fix dereferencing type-punned pointer will break strict-aliasing rules warning

[Ben Warren]

Kim,

Kim Phillips wrote:
> fix this gcc 4.4 warning:
>
> tsec.c: In function 'tsec_init':
> tsec.c:200: warning: dereferencing type-punned pointer will break 
> strict-aliasing rules
>
> Signed-off-by: Kim Phillips 
> ---
> this is the endian-correct version
>
>  drivers/net/tsec.c |5 -
>  1 files changed, 4 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
> index 63fc02e..5dc05e5 100644
> --- a/drivers/net/tsec.c
> +++ b/drivers/net/tsec.c
> @@ -197,7 +197,10 @@ int tsec_init(struct eth_device *dev, bd_t * bd)
>   for (i = 0; i < MAC_ADDR_LEN; i++) {
>   tmpbuf[MAC_ADDR_LEN - 1 - i] = dev->enetaddr[i];
>   }
> - regs->macstnaddr1 = *((uint *) (tmpbuf));
> + tempval = (tmpbuf[0] << 24) | (tmpbuf[1] << 16) | (tmpbuf[2] << 8) |
> +   tmpbuf[3];
> +
> + regs->macstnaddr1 = tempval;
>  
>   tempval = *((uint *) (tmpbuf + 4));
>  
>   
Applied to net repo.

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

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

[Ben Warren]

Mike Frysinger wrote:
> Signed-off-by: Mike Frysinger 
> ---
> Ben: some things to note:
>   - i adopted Jean's proposed naming scheme in the CONFIG section
>   
Is this a generally-accepted naming convention?  I personally think it's 
crap, and since there isn't a single driver that uses it yet, you might 
say this is a bit ahead of the curve.
>   - 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()"
>   
That may be so, but since there isn't a single driver that uses this 
naming convention, you're wishing something that ain't so.

Other than that, nice writeup.  thanks!

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

Re: [U-Boot] [PATCH] MIIPHYBB: Return 0xFFFF if the PHY is not asserting TA.

[Ben Warren]

Richard,

Richard Retanubun wrote:
> From d4c7dd98ac9a3f6fc4949079b84d7d811376cf3d Mon Sep 17 00:00:00 2001
> From: Richard Retanubun 
> Date: Thu, 2 Jul 2009 13:12:03 -0400
> Subject: [PATCH] MIIPHYBB: Return 0x if the PHY is not asserting TA.
>
> This patch sets the returned value to 0x if the PHY does not exist
> and does not assert Transfer Acknowledge. A NULL check for the value
> pointer is also added for buffer overflow protection.
>
> Without this patch 'mii info' will  show 'phantom' devices because the
> value will be not be initialized and return with some random value.
> ---
>  drivers/net/phy/miiphybb.c |7 +++
>  1 files changed, 7 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/phy/miiphybb.c b/drivers/net/phy/miiphybb.c
> index e3c163a..b77c917 100644
> --- a/drivers/net/phy/miiphybb.c
> +++ b/drivers/net/phy/miiphybb.c
> @@ -127,6 +127,11 @@ int bb_miiphy_read (char *devname, unsigned char 
> addr,
>  volatile ioport_t *iop = ioport_addr ((immap_t *) 
> CONFIG_SYS_IMMR, MDIO_PORT);
>  #endif
>
> +if (value == NULL) {
> +puts("NULL value pointer\n");
> +return (-1);
> +}
> +
>  miiphy_pre (1, addr, reg);
>
>  /* tri-state our MDIO I/O pin so we can read */
> @@ -145,6 +150,8 @@ int bb_miiphy_read (char *devname, unsigned char 
> addr,
>  MDC (1);
>  MIIDELAY;
>  }
> +/* There is no PHY, set value to 0x and return */
> +*value = 0x;
>  return (-1);
>  }
>
Applied to net repo.  Please add SOB next time and send e-mail as plain 
text.

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

Re: [U-Boot] [PATCH 2/4]: arm: Kirkwood: Fix compiler optimization bug for kwgbe_send

[Ben Warren]

Simon Kagstrom wrote:
> kwgbe_send/recv both have loops waiting for the hardware to set  a bit.
> GCC 4.3.3 cleverly optimizes the send case to ... a while(1); loop. This
> patch uses readl to force a read from device memory. Other volatile
> accesses have also been replaced with readl/writel where appropriate
> (as per suggestions on the U-boot mailing list).
>
> Signed-off-by: Simon Kagstrom 
> ---
Applied to net repo.

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

Re: [U-Boot] [PATCH 3/4]: arm: Kirkwood: Check the error summary bit for error detection

[Ben Warren]

Simon Kagstrom wrote:
> The Marvell documentation for the 88f6281 states that the error coding
> is only valid if the error summary and last frame bits in the transmit
> descriptor status field are set. This patch adds checks for these for
> transmit (I would get transmit errors on bootp with the current check,
> which I believe are spurious).
>
> Signed-off-by: Simon Kagstrom 
> ---
Applied to net repo.

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

Re: [U-Boot] [PATCH 4/4]: arm: Kirkwood: See to it that sent data is 8-byte aligned

[Ben Warren]

Simon,

Simon Kagstrom wrote:
> U-boot might use non-8-byte-aligned addresses for sending data, which
> the kwgbe_send doesn't accept (bootp does this for me). This patch
> copies the data to be sent to a temporary buffer if it is non-aligned.
>
> Signed-off-by: Simon Kagstrom 
> ---
>  drivers/net/kirkwood_egiga.c |   26 --
>  1 files changed, 20 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
> index 537343f..24269c1 100644
> --- a/drivers/net/kirkwood_egiga.c
> +++ b/drivers/net/kirkwood_egiga.c
> @@ -481,7 +481,7 @@ static int kwgbe_halt(struct eth_device *dev)
>   return 0;
>  }
>  
> -static int kwgbe_send(struct eth_device *dev, volatile void *dataptr,
> +static int kwgbe_send_aligned(struct eth_device *dev, volatile void *dataptr,
> int datasize)
>  {
>   struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
> @@ -489,11 +489,6 @@ static int kwgbe_send(struct eth_device *dev, volatile 
> void *dataptr,
>   struct kwgbe_txdesc *p_txdesc = dkwgbe->p_txdesc;
>   u32 cmd_sts;
>  
> - if ((u32) dataptr & 0x07) {
> - printf("Err..(%s) xmit dataptr not 64bit aligned\n",
> - __FUNCTION__);
> - return -1;
> - }
>   p_txdesc->cmd_sts = KWGBE_ZERO_PADDING | KWGBE_GEN_CRC;
>   p_txdesc->cmd_sts |= KWGBE_TX_FIRST_DESC | KWGBE_TX_LAST_DESC;
>   p_txdesc->cmd_sts |= KWGBE_BUFFER_OWNED_BY_DMA;
> @@ -522,6 +517,25 @@ static int kwgbe_send(struct eth_device *dev, volatile 
> void *dataptr,
>   return 0;
>  }
>  
> +static int kwgbe_send(struct eth_device *dev, volatile void *dataptr,
> +   int datasize)
> +{
> + static u8 __attribute__((aligned(8))) aligned_buf[9000];
>   
Why do you need to send a jumbo frame?  U-boot is hard-coded in some 
ways to only handle frames with an MTU of 1518 bytes on Rx.

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

Re: [U-Boot] [PATCH] ppc4xx: Fixed compilation warning in 4xx_enet.c

[Ben Warren]

Stefan,

Can I get an ACK from you on this? Sorry if you already did and I missed it.

regards,
Ben

Alessio Centazzo wrote:
> This patch fixes a compilation warning for some Ethernet PHY-less
> PPC4xx platforms (440SPE based ones) and a potential compilation
> error for 440SP platforms (use of undefined 'ethgroup' variable).
> In the original code and in case of 440SPE platforms, 'ethgroup'
> is initialized to -1 and never modified.  Later in the function,
> within an #ifdef statement, an 'if statement' executes code only
> if 'ethgroup' is set to 4, therefore it is harmless to avoid
> executing the 'if statement' by removing the CONFIG_440SPE from
> the affected #ifdefs.  In case of 440SP platforms  with on-board
> Ethernet PHY, 'ethgroup' is undefined but used (there are not such
> platforms in the repository yet). All other architectures are not
> affected by this change.
>
> Signed-off-by: Alessio Centazzo acpa...@yahoo.com
> ---
>  drivers/net/4xx_enet.c |3 +--
>  1 files changed, 1 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/4xx_enet.c b/drivers/net/4xx_enet.c
> index 587605d..c020048 100644
> --- a/drivers/net/4xx_enet.c
> +++ b/drivers/net/4xx_enet.c
> @@ -870,7 +870,7 @@ static int ppc_4xx_eth_init (struct eth_device
> *dev, bd_t * bis)
>  defined(CONFIG_405EX)
>   u32 opbfreq;
>   sys_info_t sysinfo;
> -#if defined(CONFIG_440GX) || defined(CONFIG_440SPE) || \
> +#if defined(CONFIG_440GX) || \
>  defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
>  defined(CONFIG_460EX) || defined(CONFIG_460GT) || \
>  defined(CONFIG_405EX)
> @@ -1119,7 +1119,6 @@ static int ppc_4xx_eth_init (struct eth_device
> *dev, bd_t * bis)
>
>  #if defined(CONFIG_440GX) || \
>  defined(CONFIG_440EPX) || defined(CONFIG_440GRX) || \
> -defined(CONFIG_440SP) || defined(CONFIG_440SPE) || \
>  defined(CONFIG_460EX) || defined(CONFIG_460GT) || \
>  defined(CONFIG_405EX)
>
>   

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

Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4a6422fc.6030...@invitel.hu> you wrote:
>> typedef struct gpio_adapter {
>>  int (*init_pin)(int pin);
>>  int (*set)(int pin, value);
>>  int (*get)(int pin);
>>  int (*dir)(int pin, int direction); 
>>  int (*level)(int pin, int level);
>> }
>>
>> int gpio_init(gpio_adapter *adap);
>> int gpio_init_pin(pin);
>>  ? maybe with setting a marker, that this pin is initialized,
>>so this can be checked in the above functions ... ?
>> int gpio_set(pin, value);
>> int gpio_get(pin);
>> int gpio_dir(pin, dir);
>> int gpio_level(pin, dir);
> 
> What does "level" mean in this context?

Yesterday, when I emailed with Alessandro, it looked like, if we
call gpio_set(), we also set the direction to output, so I thought,
it would be nice to have a function which really just sets the value.

Now, I think, we should set the direction only with gpio_dir()
(if output also set the value).

And with gpio_set() we only set the output value, without switching
the direction ...

Or should we do allways a set direction, when calling gpio_set() ...?

> gpio_init_pin() and gpio_dir() seem to be redundant  -  or  does  pin
> initialization not include the setting of the direction (and, in case
> of an output pin, it's initial state) ?

Yes, you are right, also redundant.

> gpio_get() returns the current state of the pin?

Yep.

> gpio_set() returns the previous state of the pin? Or the  new  state?
> If  it  returns  the  new  state,  we could use value=1 to set a pin,
> value=0 to unset a pin, and value=-1 to just read it's value  without
> changing it; then we could "#define gpio_get(pin) gpio_set(pin,-1)".

Yes, thats a good point.

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/2] Add ntel PCIE PRO/1000 Network Driver support

[Ben Warren]

Hi Roy,
Roy Zang wrote:
> From: Roy Zang 
>
>   Based on Intel PRO/1000 Network Driver 7.3.20-k2
>   Add Intel E1000 PCIE card support. The following cards are added:
>   INTEL_82571EB_COPPER
>   INTEL_82571EB_FIBER,
>   INTEL_82571EB_SERDES
>   INTEL_82571EB_QUAD_COPPER
>   INTEL_82571PT_QUAD_COPPER
>   INTEL_82571EB_QUAD_FIBER
>   INTEL_82571EB_QUAD_COPPER_LOWPROFILE
>   INTEL_82571EB_SERDES_DUAL
>   INTEL_82571EB_SERDES_QUAD
>   INTEL_82572EI_COPPER
>   INTEL_82572EI_FIBER
>   INTEL_82572EI_SERDES
>   INTEL_82572EI
>   INTEL_82573E
>   INTEL_82573E_IAMT
>   INTEL_82573L
>   INTEL_82546GB_QUAD_COPPER_KSP3
>   INTEL_80003ES2LAN_COPPER_DPT
>   INTEL_80003ES2LAN_SERDES_DPT
>   INTEL_80003ES2LAN_COPPER_SPT
>   INTEL_80003ES2LAN_SERDES_SPT
>
>  82571EB_COPPER dual ports,
>  82572EI single port,
>  82572EI_COPPER single port PCIE cards
>  and
>  82545EM_COPPER,
>  82541GI_LF
>  pci cards are tested on P2020 board, MPC8536DS
>  and MPC8544DS boards.
>
>  Signed-off-by: Roy Zang 
>   
I have no objections to any of the content.  A few themes, though:

1. Please ensure that the multi-line comments are formatted correctly.  
Lines 2+ should have a space in the first character.
2. If you insist on including dead code (i.e. #if 0), please provide a 
comment on why it's there
3. I have a hard time believing that most of this is necessary.  Sure 
it's a complicated chip and you're pulling it from Intel's driver, but 
3000+ lines is too much.  Please try to remove stuff that's not needed.

regards,
Ben
___
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

[Ben Warren]

Jean-Christophe PLAGNIOL-VILLARD wrote:
> 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
>
>   
Global configs for this type of thing are a bad idea (what if you want 
one interface @ 1000 and one @ 100?  I guess this will have to do for 
now, but let's ensure that it's temporary.

> Best Regards,
> J.

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

Re: [U-Boot] [PATCH 0/2] arm nomadik: gpio and i2c

[Heiko Schocher]

Hello Wolfgang,

Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4a6437a7.40...@denx.de> you wrote:
>> Also, a board can have more then one gpio adapter, how we address
>> such a case?
> 
> How far do you want to take that? What about an I/O expander at the
> I2C bus?

Hmmm.. good question ;-)

But I don;t think it is not so exotic to have more than one gpio adapter
on one board. On the suen3 plattform where I actually work, there are
the CPU GPIO pins and GPIO pins over an I/O Expander used ... so it
should be possible to have more than one gpio adapter I think. And to
make such an I/O Expander gpio adapter should not so difficult ... and
if we now really make such a gpio lib, it should support more than one
adapter ...

I like Alessandros suggestion for concatening such multiple
adapters, see:
http://lists.denx.de/pipermail/u-boot/2009-July/056949.html

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 2/2] document network driver framework

[Mike Frysinger]

On Tuesday 21 July 2009 01:09:11 Ben Warren wrote:
> Mike Frysinger wrote:
> > Signed-off-by: Mike Frysinger 
> > ---
> > Ben: some things to note:
> > - i adopted Jean's proposed naming scheme in the CONFIG section
>
> Is this a generally-accepted naming convention?  I personally think it's
> crap, and since there isn't a single driver that uses it yet, you might
> say this is a bit ahead of the curve.

some style needed to be suggested, and what Jean proposed is better than what 
we have today (which is nothing)

> > - 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()"
>
> That may be so, but since there isn't a single driver that uses this
> naming convention, you're wishing something that ain't so.

that's why i said "should", deprecated current naming, and noted existing 
practice.  if you agree with the proposal, it's easy enough to run sed on a 
few files to fix one function name.  you agree with my comment that today's 
behavior is confusing even if you stare and bang on the code day in and day 
out ?  it's even worse for the occasional observer ...
-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] - save the server's mac address...

[Ben Warren]

Hi Robin,
Robin Getz wrote:
> From: Robin Getz 
>
> Linux's netconsole works much better when you can pass it the MAC address of
> the server. (otherwise it just uses broadcast, which everyone else on my
> network complains about :)
>  
> This sets the env var "serveraddr" (to match ethaddr), so that you can pass
> it to linux with whatever bootargs you want to
>  
> addnetconsole=set bootargs $(bootargs) 
> netconso...@$(ipaddr)/eth0,@$(serverip)/$(serveraddr)
>
> Signed-of-by: Robin Getz 
>
>
> ---
>
> Index: net/net.c
> ===
> --- net/net.c (revision 1968)
> +++ net/net.c (working copy)
Can you please re-submit using git tools?

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

Re: [U-Boot] [PATCH] DHCP regression on 2009-06

[Ben Warren]

Michael,

Michael Zaidman wrote:
> Fixed the DHCP/BOOTP/RARP regression introduced in u-boot-2009.06
> by initializing our IP addr to 0 in order to accept any IP addr
> assigned to us by the DHCP/BOOTP/RARP server.
>
> Ack-by: Robin Getz 
> Signed-off-by: Michael Zaidman 
> ---
>  net/net.c |3 +++
>  1 files changed, 3 insertions(+), 0 deletions(-)
>
> diff --git a/net/net.c b/net/net.c
> index 5637cf5..9bd3208 100644
> --- a/net/net.c
> +++ b/net/net.c
> @@ -388,17 +388,20 @@ restart:
>  #if defined(CONFIG_CMD_DHCP)
>   case DHCP:
>   BootpTry = 0;
> + NetOurIP = 0;
>   DhcpRequest();  /* Basically same as BOOTP */
>   break;
>  #endif
>  
>   case BOOTP:
>   BootpTry = 0;
> + NetOurIP = 0;
>   BootpRequest ();
>   break;
>  
>   case RARP:
>   RarpTry = 0;
> + NetOurIP = 0;
>   RarpRequest ();
>   break;
>  #if defined(CONFIG_CMD_PING)
>   
Applied to net repo.

thanks,
Ben
___
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

[Ben Warren]

Prafulla,

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 
> ---
Applied to net repo.

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

Re: [U-Boot] [PATCH 4/6] net: phy: bugfixes: mv88E61xx multichip addressing support

[Ben Warren]

Prafulla,

Prafulla Wadaskar wrote:
> With these fixes, this driver works properly for multi chip
> addressging mode
>
> Bugfixes:
> 1. Build error fixed for function mv88e61xx_busychk_multic-fixed
> 2. PHY dev address error detection- fixed
> 3. wrong busy bit was refered in function mv88e61xx_busychk -fixed
> 4. invalid data read ptr was refered for RD_PHY in case of
>   multichip addressing mode -fixed
>
> The Multichip Address mode is tested with RD6281A board having
> MV88E6165 switch on it
>
> Signed-off-by: Prafulla Wadaskar 
> ---
Applied to net repo.

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

Re: [U-Boot] [PATCH] ppc4xx: Fixed compilation warning in 4xx_enet.c

[Stefan Roese]

Ben,

On Tuesday 21 July 2009 07:55:30 Ben Warren wrote:
> Can I get an ACK from you on this? Sorry if you already did and I missed
> it.

I thought that I already ack'ed it. But hey, I have more than one ;)

Acked-by: Stefan Roese 

Best regards,
Stefan

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

Re: [U-Boot] [PATCH] Bugfix: mpc512x_fec MII accesses fail after ethernet transfers

[Ben Warren]

Thomas,

Thomas Dörfler wrote:
> The mpc512x FEC network driver resets the FEC before transferring
> packets. With this reset, the FEC clears the previous setting of MII
> transfer speed. This patch ensures, that it is set again to a reasonable
> value after a FEC reset.
>
> Signed-off-by: Thomas Doerfler 
> --
> diff --git a/drivers/net/mpc512x_fec.c b/drivers/net/mpc512x_fec.c
> index fb2c19a..f3d76ba 100644
> --- a/drivers/net/mpc512x_fec.c
> +++ b/drivers/net/mpc512x_fec.c
> @@ -446,6 +446,19 @@ static void mpc512x_fec_halt (struct eth_device *dev)
>  * wait at least 16 clock cycles
>  */
> udelay (10);
> +   /*
> +* NOTE: reset will also clear the MII speed register
> +* we should reinitialize it ASAP
> +*/
> +   if (fec->xcv_type != SEVENWIRE) {
> +   /*
> +* Set MII_SPEED = (1/(mii_speed * 2)) * System Clock
> +* and do not drop the Preamble.
> +*/
> +   fec->eth->mii_speed = gd->ips_clk / 100) / 5)
> +   + 1)
> +  << 1);
> +   }
>  #if (DEBUG & 0x3)
> printf ("Ethernet task stopped\n");
>  #endif
>   
Applied to net repo (after some tweaking)

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