Subject: U-Boot Digest, Vol 9, Issue 33
From: [email-masked]
To: [email-masked]
Date: Wed, 04 Feb 2009 17:59:09 +0100
List-Id: U-Boot discussion <u-boot.lists.denx.de>

Send U-Boot mailing list submissions to
	[email-masked]

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.denx.de/mailman/listinfo/u-boot
or, via email, send a message with subject or body 'help' to
	[email-masked]

You can reach the person managing the list at
	[email-masked]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of U-Boot digest..."

Today's Topics:

   1. Re: [PATCH 1/2] Allow board specific overwriting of	library
      code (Wolfgang Denk)
   2. Re: [PATCH 1/2] Allow board specific overwriting of library
      code (Michael Roth)
   3. Re: [PATCH 1/2] Allow board specific overwriting of	library
      code (Mike Frysinger)
   4. [PATCH v2] MPC8349ITX: several config issues fixed
      (Valeriy Glushkov)
   5. [PATCH v3] MPC8349ITX: several config issues fixed
      (Valeriy Glushkov)
   6. Re: [PATCH] ARM: synchronize mach-types.h	with	linux
      2.6.29-rc3 (Dirk Behme)
   7. [PATCH 0/9] ARM: Support for splashimage om i.MX31-based
      phycore "eet" variant (Guennadi Liakhovetski)
   8. [PATCH 1/9] i.MX31: fix SPI driver for shorter than 32 bit
      transfers (Guennadi Liakhovetski)

----------------------------------------------------------------------

Message: 1
Date: Wed, 04 Feb 2009 17:08:56 +0100
From: Wolfgang Denk <[email-masked]>
Subject: Re: [U-Boot] [PATCH 1/2] Allow board specific overwriting of
	library code
To: Michael Roth <[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Dear Michael Roth,

In message <[email-masked]> you wrote:
> 
> > Why would that be needed?
> 
> Because the whole weak-linking looks like it is somewhat broken or at
> least very difficult to get it correctly.

Then you should at least document this purpose in the commit message.

> Yes, there are several possible solutions to address this issue. Until
> now, there were discussed: CONFIG_XYZ and ifdef/endif and pre-build
> objects (patch from Jean-Christophe) and my proposal.
> 
> Using a board specific linker script is another way.
> 
> However, because the problem regarding weak-linking is a global one,
> maybe the circumvention should be global too.

In the long term, following the Linux style is probably the way to go.
In the man time, I suggest to use what has least impact.

> But I don't know. I could also use a board specific linker script.

OK, fine.

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: [email-masked]
This restaurant was advertising breakfast  any  time.  So  I  ordered
french toast in the renaissance.            - Steven Wright, comedian

------------------------------

Message: 2
Date: Wed, 04 Feb 2009 17:18:16 +0100
From: Michael Roth <[email-masked]>
Subject: Re: [U-Boot] [PATCH 1/2] Allow board specific overwriting of
	library code
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1

Michael Roth schrieb:

> Because the whole weak-linking looks like it is somewhat broken or at
> least very difficult to get it correctly.

Small example:

In board/atmel/at91sam9261ek there is:

led.c:
	void red_LED_on(void)
	...
	void red_LED_off(void)
	...

Makefile:

	COBJS-y += led.o
	...
	OBJS    := $(addprefix $(obj),$(COBJS-y))
	...
	$(LIB): $(obj).depend $(OBJS) $(SOBJS)

And in lib_arm/board.c we have:

	void inline __red_LED_on (void) {}
	void inline red_LED_on (void) __attribute__((weak, alias("__red_LED_on")));
	void inline __red_LED_off(void) {}
	void inline red_LED_off(void)        __attribute__((weak, alias("__red_LED_off")));

But as you can see from u-boot.map, the result is not as expected:

	0x23f00340      0x35c lib_arm/libarm.a(board.o)
	0x23f00390                __red_LED_off
	...
	0x23f00390                red_LED_off
	...
	0x23f0038c                red_LED_on
	0x23f0038c                __red_LED_on

No single weak symbol from lib_arm/board.c get overridden from the
board specific led.c. Very annoying.

Michael Roth

------------------------------

Message: 3
Date: Wed, 4 Feb 2009 11:23:08 -0500
From: Mike Frysinger <[email-masked]>
Subject: Re: [U-Boot] [PATCH 1/2] Allow board specific overwriting of
	library code
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="iso-8859-1"

On Wednesday 04 February 2009 11:18:16 Michael Roth wrote:
> Michael Roth schrieb:
> > Because the whole weak-linking looks like it is somewhat broken or at
> > least very difficult to get it correctly.
>
> Small example:
>
> In board/atmel/at91sam9261ek there is:
>
> led.c:
> 	void red_LED_on(void)
> 	...
> 	void red_LED_off(void)
> 	...
>
> Makefile:
>
> 	COBJS-y += led.o
> 	...
> 	OBJS    := $(addprefix $(obj),$(COBJS-y))
> 	...
> 	$(LIB): $(obj).depend $(OBJS) $(SOBJS)
>
>
> And in lib_arm/board.c we have:
>
> 	void inline __red_LED_on (void) {}
> 	void inline red_LED_on (void) __attribute__((weak,
> alias("__red_LED_on"))); void inline __red_LED_off(void) {}
> 	void inline red_LED_off(void)        __attribute__((weak,
> alias("__red_LED_off")));
>
>
> But as you can see from u-boot.map, the result is not as expected:
>
> 	0x23f00340      0x35c lib_arm/libarm.a(board.o)
> 	0x23f00390                __red_LED_off
> 	...
> 	0x23f00390                red_LED_off
> 	...
> 	0x23f0038c                red_LED_on
> 	0x23f0038c                __red_LED_on
>
>
> No single weak symbol from lib_arm/board.c get overridden from the
> board specific led.c. Very annoying.

that's because your led.o was not pulled in for any other reason.  give it a 
reason to be pulled in and the weak overrides will work fine.  in other words, 
what you show is not the linker being broken, but your expectations being 
broken ;).
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: This is a digitally signed message part.
Url : http://lists.denx.de/pipermail/u-boot/attachments/20090204/e259fc99/attachment-0001.pgp 

------------------------------

Message: 4
Date: Wed,  4 Feb 2009 18:24:35 +0200
From: Valeriy Glushkov <[email-masked]>
Subject: [U-Boot] [PATCH v2] MPC8349ITX: several config issues fixed
To: [email-masked]
Message-ID: <[email-masked]>

The previous version rebooted forever with DDR bigger than 256MB.
Access the DS1339 RTC chip is on I2C1 bus.
Allow DHCP.

Signed-off-by: Valeriy Glushkov <[email-masked]>
---
 include/configs/MPC8349ITX.h |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h
index 14cbc45..3f87f0f 100644
--- a/include/configs/MPC8349ITX.h
+++ b/include/configs/MPC8349ITX.h
@@ -158,6 +158,9 @@
 #define CONFIG_SYS_DDR_SDRAM_CLK_CNTL	(DDR_SDRAM_CLK_CNTL_SS_EN | \
 				DDR_SDRAM_CLK_CNTL_CLK_ADJUST_075)
 
+#define CONFIG_VERY_BIG_RAM
+#define CONFIG_MAX_MEM_MAPPED   ((phys_size_t)256 << 20)
+
 #ifdef CONFIG_HARD_I2C
 #define CONFIG_SPD_EEPROM		/* use SPD EEPROM for DDR setup*/
 #endif
-- 
1.5.2.5

------------------------------

Message: 5
Date: Wed,  4 Feb 2009 18:27:49 +0200
From: Valeriy Glushkov <[email-masked]>
Subject: [U-Boot] [PATCH v3] MPC8349ITX: several config issues fixed
To: [email-masked]
Message-ID: <[email-masked]>

The previous version rebooted forever with DDR bigger than 256MB.
Access the DS1339 RTC chip is on I2C1 bus.
Allow DHCP.

Signed-off-by: Valeriy Glushkov <[email-masked]>
---
 include/configs/MPC8349ITX.h |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/include/configs/MPC8349ITX.h b/include/configs/MPC8349ITX.h
index 14cbc45..f1b5566 100644
--- a/include/configs/MPC8349ITX.h
+++ b/include/configs/MPC8349ITX.h
@@ -98,6 +98,7 @@
 #define CONFIG_SYS_I2C_OFFSET		0x3000
 #define CONFIG_SYS_I2C2_OFFSET		0x3100
 #define CONFIG_SYS_SPD_BUS_NUM		1	/* The I2C bus for SPD */
+#define CONFIG_SYS_RTC_BUS_NUM		1	/* The I2C bus for RTC */
 
 #define CONFIG_SYS_I2C_8574_ADDR1	0x20	/* I2C1, PCF8574 */
 #define CONFIG_SYS_I2C_8574_ADDR2	0x21	/* I2C1, PCF8574 */
@@ -158,6 +159,9 @@
 #define CONFIG_SYS_DDR_SDRAM_CLK_CNTL	(DDR_SDRAM_CLK_CNTL_SS_EN | \
 				DDR_SDRAM_CLK_CNTL_CLK_ADJUST_075)
 
+#define CONFIG_VERY_BIG_RAM
+#define CONFIG_MAX_MEM_MAPPED   ((phys_size_t)256 << 20)
+
 #ifdef CONFIG_HARD_I2C
 #define CONFIG_SPD_EEPROM		/* use SPD EEPROM for DDR setup*/
 #endif
@@ -447,6 +451,7 @@ boards, we say we have two, but don't display a message if we find only one. */
 #define CONFIG_CMD_IRQ
 #define CONFIG_CMD_NET
 #define CONFIG_CMD_PING
+#define CONFIG_CMD_DHCP
 #define CONFIG_CMD_SDRAM
 
 #ifdef CONFIG_COMPACT_FLASH
-- 
1.5.2.5

------------------------------

Message: 6
Date: Wed, 04 Feb 2009 17:50:32 +0100
From: Dirk Behme <[email-masked]>
Subject: Re: [U-Boot] [PATCH] ARM: synchronize mach-types.h	with	linux
	2.6.29-rc3
To: Jean-Christophe PLAGNIOL-VILLARD <[email-masked]>, 	Tom
	<[email-masked]>
Cc: [email-masked]
Message-ID: <[email-masked]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 19:19 Tue 03 Feb     , Tom wrote:
>> This change is to support Zoom2.
>>
>> #define MACH_TYPE_OMAP_ZOOM2           1967
>>
>> The file was generated from building the default arm config of
>>
>> git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
>> 18e352e4a73465349711a9324767e1b2453383e2
>> or tag
>> Linux 2.6.29-rc3
>>
>> It was tested with
>> MAKEALL arm
>>
>> Tom
>>
> NACK
> 
> As announce on the ML please send a sync request

Just fyi, Jean-Christophe wanted to point you to

http://lists.denx.de/pipermail/u-boot/2008-September/040553.html

Some background/history info (please correct me if I'm wrong):

In contrast to statement in above cited procedure, I'm not sure if 
"The mach-types.h will be sync with the kernel on each kernel's 
release" is/was ever done:

http://git.denx.de/?p=u-boot.git;a=history;f=include/asm-arm/mach-types.h;h=ce6d25f9e12b7b614a2d3ff7a3aa249b127fc987;hb=HEAD

The first sync request we got ~mid November 2008 then

http://lists.denx.de/pipermail/u-boot/2008-November/043433.html

which was never answered at list nor handled.

Then there was an attempt to update mach-types ~end of january 2009

http://lists.denx.de/pipermail/u-boot/2009-January/045856.html

which unfortunately failed due to mix with other changes.

I really hope we will get a mach-types update this merge window and 
then regularly.

> with a description of which machine you need

Sounds like we are talking about OMAP_ZOOM2 ;)

Best regards

Dirk

------------------------------

Message: 7
Date: Wed, 4 Feb 2009 17:59:08 +0100 (CET)
From: Guennadi Liakhovetski <[email-masked]>
Subject: [U-Boot] [PATCH 0/9] ARM: Support for splashimage om
	i.MX31-based phycore "eet" variant
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Hi,

this series of patches adds support for the graphics engine on i.MX31 SoC. 
Specifically it allows to display 8-bit BMPs on an OLED display, 
controlled by an SPI s6e63d6 controller from Samsung. A (fixed formatting) 
version of the

From: Mark Jackson <[email-masked]>
Subject: [PATCH] Add 16bpp BMP support

patch is included for completeness. The cumulative diffstat is

 Makefile                              |    6
 board/imx31_phycore/imx31_phycore.c   |   51 ++
 common/lcd.c                          |  106 ++--
 drivers/gpio/Makefile                 |    3
 drivers/gpio/mx31_gpio.c              |   71 ++
 drivers/spi/mxc_spi.c                 |   99 +++
 drivers/video/Makefile                |    2
 drivers/video/mx3fb.c                 |  866 +++++++++++++++++++++++++++++++++-
 drivers/video/s6e63d6.c               |   68 ++
 include/asm-arm/arch-mx31/mx31-regs.h |   16
 include/asm-arm/arch-mx31/mx31.h      |   10
 include/configs/imx31_phycore.h       |   24
 include/lcd.h                         |   22
 include/s6e63d6.h                     |   37 +
 lib_arm/board.c                       |    7
 15 files changed, 1314 insertions(+), 74 deletions(-)

i.e., most changes go under drivers/video and to common/lcd.c, so, I would 
suggest to collect respective Acks and pull it through the video tree. 
Hence Anatolij is cc'ed on all patches:-) Also many need an Ack from the 
ARM maintainer, so, he is on cc on respective patches and on this one.

Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.

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: [email-masked]

------------------------------

Message: 8
Date: Wed, 4 Feb 2009 17:59:17 +0100 (CET)
From: Guennadi Liakhovetski <[email-masked]>
Subject: [U-Boot] [PATCH 1/9] i.MX31: fix SPI driver for shorter than
	32 bit	transfers
To: [email-masked]
Message-ID: <[email-masked]>
Content-Type: TEXT/PLAIN; charset=US-ASCII

Fix 8 and 16-bit transfers in mxc_spi driver and a wrong pointer in the 
free routine.

Signed-off-by: Guennadi Liakhovetski <[email-masked]>
---

No SPI custodian, so, Jean-Christophe will have to Ack it?

 drivers/spi/mxc_spi.c |   62 +++++++++++++++++++++++++++++++++++++++---------
 1 files changed, 50 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/mxc_spi.c b/drivers/spi/mxc_spi.c
index 5957ada..9267341 100644
--- a/drivers/spi/mxc_spi.c
+++ b/drivers/spi/mxc_spi.c
@@ -85,17 +85,12 @@ static inline void reg_write(unsigned long addr, u32 val)
 	*(volatile unsigned long*)addr = val;
 }
 
-static u32 spi_xchg_single(struct spi_slave *slave, u32 data, int bitlen)
+static u32 spi_xchg_single(struct spi_slave *slave, u32 data,
+			   unsigned long flags)
 {
 	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
 	unsigned int cfg_reg = reg_read(mxcs->base + MXC_CSPICTRL);
 
-	if (MXC_CSPICTRL_BITCOUNT(bitlen - 1) != (cfg_reg & MXC_CSPICTRL_BITCOUNT(31))) {
-		cfg_reg = (cfg_reg & ~MXC_CSPICTRL_BITCOUNT(31)) |
-			MXC_CSPICTRL_BITCOUNT(bitlen - 1);
-		reg_write(mxcs->base + MXC_CSPICTRL, cfg_reg);
-	}
-
 	reg_write(mxcs->base + MXC_CSPITXDATA, data);
 
 	cfg_reg |= MXC_CSPICTRL_XCH;
@@ -108,13 +103,46 @@ static u32 spi_xchg_single(struct spi_slave *slave, u32 data, int bitlen)
 	return reg_read(mxcs->base + MXC_CSPIRXDATA);
 }
 
+/*
+ * bitlen is the total number of bits to be sent. Therefore, if you have to send
+ * using < 32-bit words, you have to send each single word individually. If
+ * bitlen > 32 we assume you meant to send 32-bit words...
+ */
 int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
-		void *din, unsigned long flags)
+	     void *din, unsigned long flags)
 {
-	int n_blks = (bitlen + 31) / 32;
+	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
+	int n_blks = bitlen / 32;
 	u32 *out_l, *in_l;
 	int i;
 
+	mxcs->ctrl_reg = (mxcs->ctrl_reg & ~MXC_CSPICTRL_BITCOUNT(31)) |
+		MXC_CSPICTRL_BITCOUNT(bitlen - 1);
+
+	reg_write(mxcs->base + MXC_CSPICTRL, mxcs->ctrl_reg);
+
+	if (bitlen <= 8) {
+		u32 iword, oword = *(const u8 *)dout;
+
+		iword = spi_xchg_single(slave, oword, flags);
+		*(u8 *)din = iword;
+		return 0;
+	}
+
+	if (bitlen <= 16) {
+		u32 iword, oword = *(const u16 *)dout;
+
+		if ((int)dout & 1 || (int)din & 1) {
+			printf("Error: unaligned buffers in: %p, out: %p\n",
+			       din, dout);
+			return 1;
+		}
+
+		iword = spi_xchg_single(slave, oword, flags);
+		*(u16 *)din = iword;
+		return 0;
+	}
+
 	if ((int)dout & 3 || (int)din & 3) {
 		printf("Error: unaligned buffers in: %p, out: %p\n", din, dout);
 		return 1;
@@ -122,8 +150,17 @@ int spi_xfer(struct spi_slave *slave, unsigned int bitlen, const void *dout,
 
 	for (i = 0, in_l = (u32 *)din, out_l = (u32 *)dout;
 	     i < n_blks;
-	     i++, in_l++, out_l++, bitlen -= 32)
-		*in_l = spi_xchg_single(slave, *out_l, bitlen);
+	     i++, in_l++, out_l++)
+		*in_l = spi_xchg_single(slave, *out_l, flags);
+
+	if (bitlen & 31) {
+		/* Exchange the residue, treat data as 32 bits */
+		mxcs->ctrl_reg = (mxcs->ctrl_reg & ~MXC_CSPICTRL_BITCOUNT(31)) |
+			MXC_CSPICTRL_BITCOUNT((bitlen & 31) - 1);
+		reg_write(mxcs->base + MXC_CSPICTRL, mxcs->ctrl_reg);
+
+		*in_l = spi_xchg_single(slave, *out_l, flags);
+	}
 
 	return 0;
 }
@@ -169,7 +206,8 @@ struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
 
 void spi_free_slave(struct spi_slave *slave)
 {
-	free(slave);
+	struct mxc_spi_slave *mxcs = to_mxc_spi_slave(slave);
+	free(mxcs);
 }
 
 int spi_claim_bus(struct spi_slave *slave)
-- 
1.5.4

------------------------------

_______________________________________________
U-Boot mailing list
[email-masked]
http://lists.denx.de/mailman/listinfo/u-boot

End of U-Boot Digest, Vol 9, Issue 33
*************************************