Re: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command

2008-08-03 Thread Jerry Van Baren 
David Gibson wrote:
> On Sat, Aug 02, 2008 at 08:51:54PM -0400, Jerry Van Baren wrote:

[snip]

>> I've CC:ed David Gibson in case he has some advice - the concept is to  
>> indicate a dereference of /aliases nodes so that us lazy engineers don't  
>> have to cut'n'paste the whole long path from the alias.  Kumar  
>> originally proposed to do it automagically and I countered proposing  
>> using "*" to indicate the next path name should be looked up in /aliases  
>> and the result used instead (i.e. dereferenced).  Discussion thread:
>> 
> 
> No, I really don't think using this "dereference" character is a good
> idea.  If you're going to expand aliases, you should do it as real OF
> does - see section 4.3 of IEEE1275.  Essentially it's the *lack* of a
> leading '/' character that triggers alias expansion.  So you could use
> e.g.
>   /[EMAIL PROTECTED]/[EMAIL PROTECTED]
> or
>   soc/[EMAIL PROTECTED]
> or
>   ethernet0

Ahh, I didn't read far enough.  The algorithm in section 4.3 is much 
better thought out than either of our proposals.

[snip]

> If you're interepreting them in one place, you should probably
> interpret them everywhwere and have a single "resolve pathname"
> function.

Yes.

> In fact, I should quite possibly put such a function into libfdt.

That would be very useful.  :-)

Thanks,
gvb


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] [PATCH] fdt: Add simple alias support to fdt print command

2008-08-03 Thread David Gibson 
On Sat, Aug 02, 2008 at 08:51:54PM -0400, Jerry Van Baren wrote:
> Kumar Gala wrote:
>>
>> On Jul 9, 2008, at 12:02 PM, Jerry Van Baren wrote:
>>
>>>
>>> Thinking out loud... we could define the syntax that a leading "*"  
>>> indicates the first part of the path is a dereference of /aliases.
>>>
>>> Assuming
>>>  /aliases/soc = /[EMAIL PROTECTED]
>>>  /aliases/ethernet0 = /[EMAIL PROTECTED]/.../enet0
>>> then
>>>  print *soc/enet0
>>> and
>>>  print *ethernet0
>>> would both work and print the right thing.  You *would* have to know  
>>> that the first element of the path is an /aliases dereference.  Your  
>>> original patch did not require that piece of knowledge (but silently  
>>> and automagically, which makes me nervous).
>>
>> did we come to resolution on this?  I'd like to see this in 1.3.5.
>>
>> - k
>
> Hi Kumar,
>
> I think we have basic resolution - I would like to see it in 1.3.5 too.  
> I haven't pushed on this, waiting for 1.3.5 window to open (or some free 
> time, whichever comes last).
>
> I've CC:ed David Gibson in case he has some advice - the concept is to  
> indicate a dereference of /aliases nodes so that us lazy engineers don't  
> have to cut'n'paste the whole long path from the alias.  Kumar  
> originally proposed to do it automagically and I countered proposing  
> using "*" to indicate the next path name should be looked up in /aliases  
> and the result used instead (i.e. dereferenced).  Discussion thread:
> 

No, I really don't think using this "dereference" character is a good
idea.  If you're going to expand aliases, you should do it as real OF
does - see section 4.3 of IEEE1275.  Essentially it's the *lack* of a
leading '/' character that triggers alias expansion.  So you could use
e.g.
/[EMAIL PROTECTED]/[EMAIL PROTECTED]
or
soc/[EMAIL PROTECTED]
or
ethernet0

> Looking at the ieee1275 doc
> 
> it looks like "*" will work for a dereference delimiter as it is not  
> listed as one of the permitted punctuation characters in a node name.  
> Quoting 3.2.1.1 Node names:
> --
> The driver name field is a sequence of between one and 31 letters,  
> digits, and punctuation characters from the set ", . _ + - ". Uppercase  
> and lowercase characters are distinct.
> --
>
> We do have a problem with property names, where "*" _is_ a legal name  
> component.  Quoting 3.2.2.1.1 Property names:
> --
> The property name is a human-readable text string consisting of one to  
> thirty-one printable characters. Property names shall not contain  
> uppercase characters or the characters "/", "\", ":", "[", "]" and "@".
> --
> Note that "*" is not proscribed, making it a legal character in a  
> property name.

I've observed a '*' in the device tree in the wild - some Apple tree,
unfortunately I can't find it right at the moment.  So I can't check
if the '*' was in a node node, making it IEEE1275 illegal, or in a
property name.  I remember thinking it was illegal at the time, but I
thought '*' was invalid in property names too, which seems to have
been a misinterpretation.

> Having noted that, I'm willing to take the risk and use "*" for the  
> "alias dereference" separator.
>
> Looking back at the original patch, Kumar's original patch only did the  
> /aliases dereference for the "fdt print" command.  I'm thinking more  
> general purpose: being able to dereference /aliases in all "fdt"  
> commands.  This seems helpful for the "fdt set" command, for instance.  
> Whether this is reasonable to implement remains to be seen...

If you're interepreting them in one place, you should probably
interpret them everywhwere and have a single "resolve pathname"
function.  In fact, I should quite possibly put such a function into
libfdt.

-- 
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au  | minimalist, thank you.  NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH] (Resubmit) ADD ARM AMBA PL031 RTC Support

2008-08-03 Thread Gururaja Hebbar K R 
- Add ARM AMBA PL031 RTC Support

Signed-off-by: Gururaja Hebbar <[EMAIL PROTECTED]>
---
 drivers/rtc/Makefile|1 +
 drivers/rtc/rtc_pl031.c |  123 +++
 2 files changed, 124 insertions(+), 0 deletions(-)
 create mode 100755 drivers/rtc/rtc_pl031.c

diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 2e0c118..f888a31 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -56,6 +56,7 @@ COBJS-y += rs5c372.o
 COBJS-y += rx8025.o
 COBJS-y += s3c24x0_rtc.o
 COBJS-y += x1205.o
+COBJS-y += rtc_pl031.o
 
 COBJS  := $(COBJS-y)
 SRCS   := $(COBJS:.o=.c)
diff --git a/drivers/rtc/rtc_pl031.c b/drivers/rtc/rtc_pl031.c
new file mode 100755
index 000..0ad5e9c
--- /dev/null
+++ b/drivers/rtc/rtc_pl031.c
@@ -0,0 +1,123 @@
+/*
+ * (C) Copyright 2008
+ * Gururaja Hebbar [EMAIL PROTECTED]
+ *
+ * reference linux-2.6.20.6/drivers/rtc/rtc-pl031.c
+ *
+ * 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 
+
+#if defined(CONFIG_RTC_PL031) && defined(CONFIG_CMD_DATE)
+
+#ifndef CFG_RTC_PL031_BASE
+#error CFG_RTC_PL031_BASE is not defined!
+#endif
+
+/*
+ * Register definitions
+ */
+#defineRTC_DR  0x00/* Data read register */
+#defineRTC_MR  0x04/* Match register */
+#defineRTC_LR  0x08/* Data load register */
+#defineRTC_CR  0x0c/* Control register */
+#defineRTC_IMSC0x10/* Interrupt mask and set register */
+#defineRTC_RIS 0x14/* Raw interrupt status register */
+#defineRTC_MIS 0x18/* Masked interrupt status register */
+#defineRTC_ICR 0x1c/* Interrupt clear register */
+
+#define RTC_CR_START   (1 << 0)
+
+#defineRTC_WRITE_REG(addr, val) \
+   (*(volatile unsigned int *)(CFG_RTC_PL031_BASE + 
(addr)) = (val))
+#defineRTC_READ_REG(addr)  \
+   (*(volatile unsigned int *)(CFG_RTC_PL031_BASE + 
(addr)))
+
+static int pl031_initted = 0;
+
+/* Enable RTC Start in Control register*/
+void rtc_init(void)
+{
+   RTC_WRITE_REG(RTC_CR, RTC_CR_START);
+
+   pl031_initted = 1;
+}
+
+/*
+ * Reset the RTC. We set the date back to 1970-01-01.
+ */
+void rtc_reset(void)
+{
+   RTC_WRITE_REG(RTC_LR, 0x00);
+   if(!pl031_initted)
+   rtc_init();
+}
+
+/*
+ * Set the RTC
+*/
+void rtc_set(struct rtc_time *tmp)
+{
+   unsigned long tim;
+
+   if(!pl031_initted)
+   rtc_init();
+
+   if (tmp == NULL) {
+   puts("Error setting the date/time\n");
+   return;
+   }
+
+   /* Calculate number of seconds this incoming time represents */
+   tim = mktime(tmp->tm_year, tmp->tm_mon, tmp->tm_mday,
+   tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
+
+   RTC_WRITE_REG(RTC_LR, tim);
+}
+
+/*
+ * Get the current time from the RTC
+ */
+int rtc_get(struct rtc_time *tmp)
+{
+   ulong tim;
+
+   if(!pl031_initted)
+   rtc_init();
+
+   if (tmp == NULL) {
+   puts("Error getting the date/time\n");
+   return -1;
+   }
+
+   tim = RTC_READ_REG(RTC_DR);
+
+   to_tm (tim, tmp);
+
+   debug ( "Get DATE: %4d-%02d-%02d (wday=%d)  TIME: %2d:%02d:%02d\n",
+   tmp->tm_year, tmp->tm_mon, tmp->tm_mday, tmp->tm_wday,
+   tmp->tm_hour, tmp->tm_min, tmp->tm_sec);
+
+   return 0;
+}
+
+#endif
-- 
1.5.6.4

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] Resubmit : [PATCH] Correct ARM Versatile Timer Initialization

2008-08-03 Thread Gururaja Hebbar K R 
- According to ARM Dual-Timer Module (SP804) TRM (ARM DDI0271), 
 -- Timer Value Register @ TIMER Base + 4 is Read-only. 
 -- Prescale Value (Bits 3-2 of TIMER Control register) 
can only be one of 00,01,10. 11 is undefined.

Signed-off-by: Gururaja Hebbar <[EMAIL PROTECTED]>
---
 cpu/arm926ejs/versatile/timer.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/cpu/arm926ejs/versatile/timer.c b/cpu/arm926ejs/versatile/timer.c
index 32872d2..9659b67 100644
--- a/cpu/arm926ejs/versatile/timer.c
+++ b/cpu/arm926ejs/versatile/timer.c
@@ -50,8 +50,7 @@ static ulong lastdec;
 int timer_init (void)
 {
*(volatile ulong *)(CFG_TIMERBASE + 0) = CFG_TIMER_RELOAD;  /* 
TimerLoad */
-   *(volatile ulong *)(CFG_TIMERBASE + 4) = CFG_TIMER_RELOAD;  /* 
TimerValue */
-   *(volatile ulong *)(CFG_TIMERBASE + 8) = 0x8C;
+   *(volatile ulong *)(CFG_TIMERBASE + 8) = 0x80;
 
/* init the timestamp and lastdec value */
reset_timer_masked();
-- 
1.5.6.4

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Please Help me to Setup & Send Patch using M$ Office

2008-08-03 Thread Hebbar 

Hi all,

Hurray I found the solution to linewrap issue in M$ office.
http://support.microsoft.com/?id=823921

Thanks for all the feedback and support. 

Regards
Gururaja


-- 
View this message in context: 
http://www.nabble.com/Please-Help-me-to-Setup---Send-Patch-using-M%24-Office-tp18770065p18803954.html
Sent from the Uboot - Users mailing list archive at Nabble.com.


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

2008-08-03 Thread Andrew Dyer 
On Sun, Aug 3, 2008 at 7:57 AM, Jon Smirl <[EMAIL PROTECTED]> wrote:
> A DTB is only about 8K. I was thinking that a user supplied one would
> override the one contained inside uboot.

How big is the code that parses the FDT right now?  I mostly deal with
MIPS and ARM, and haven't used this stuff before.


-- 
Hardware, n.:
 The parts of a computer system that can be kicked.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

2008-08-03 Thread Timur Tabi 
On Sun, Aug 3, 2008 at 2:06 PM, Grant Likely <[EMAIL PROTECTED]> wrote:

> Better to just not depend on the DTB at all for basic operation.  ie.
> don't brick the board if the DTB is unavailable.

Is it even possible to have a "recovery mode U-Boot" that is not tied
to the specific board it's built for?  Either U-Boot is reliable, or
it's generic (i.e. uses the DTB for configuration).  I just don't see
how it can be both.

-- 
Timur Tabi
Linux kernel developer at Freescale

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] U-Boot v1.3.4-rc2 released

2008-08-03 Thread Magnus Lilja 
Hi,

Wolfgang Denk skrev:
> Hello everybody,
> 
> I have released U-Boot v1.3.4-rc2, and it is available both from the
> git repository and the FTP server.
> 
> Please help testing.
> 
> Please also check if all your patches that you want to have  included
> in  v1.3.4  have really been added - I don't have anything pending on
> my list, but I might have missed something.

I just posted an updated set of patches related to "4000  06/18 Magnus Lilja
   [U-Boot-Users] i.MX31: mx31_gpio_mux() problem", would be nice to have that 
in v1.3.4 as well.

The subjects are:
[PATCH v2 1/2] i.MX31: Fix IOMUX related typos
[PATCH v2 2/2] i.MX31: Fix mx31_gpio_mux() function and MUX_-macros.

(actually only the second patch has been updated, the first version of these 
patches were sent in June)


Regards, Magnus


-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

2008-08-03 Thread Wolfgang Denk 
In message <[EMAIL PROTECTED]> you wrote:
> 
> > If the  DTB  can  be  at  any
> > flash location, you can for example have a fall-back version which is
> > used  to bring up U-Boot in a minimal configuration for recovery mode
> > if the new DTB fails to work.
> 
> I think that a "recovery DTB" would have to be part of U-Boot itself

Why? One address is as good as any other.

> to be effective.  If the normal DTB is not available, then it's likely
> the backup one would also be unavailable.

Then this makes no differnce if it's embedded in the U=Boot image  or
prepended or appended or at any other location in memory.

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 PROTECTED]
A supercomputer is a machine that runs an endless loop in 2 seconds.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] [PATCH v2 2/2] i.MX31: Fix mx31_gpio_mux() function and MUX_-macros.

2008-08-03 Thread Magnus Lilja 
Correct the mx31_gpio_mux() function to allow changing all i.MX31 IOMUX
contacts instead of only the first 256 ones as is the case prior to
this patch.

Add missing MUX_* macros and update board files to use the new macros.

Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
Changes from first version:
Renamed helper macro in mx31-regs.h to IOMUX_MODE since that's the
name used in imx31 code in Linux 2.6.26.
Split one macro into two lines in order to fit within 80 columns.

 board/imx31_litekit/imx31_litekit.c   |   14 +++---
 board/mx31ads/mx31ads.c   |   14 +++---
 cpu/arm1136/mx31/generic.c|4 ++--
 include/asm-arm/arch-mx31/mx31-regs.h |   33 -
 4 files changed, 40 insertions(+), 25 deletions(-)

diff --git a/board/imx31_litekit/imx31_litekit.c 
b/board/imx31_litekit/imx31_litekit.c
index 8cbc26e..cb3e174 100644
--- a/board/imx31_litekit/imx31_litekit.c
+++ b/board/imx31_litekit/imx31_litekit.c
@@ -53,13 +53,13 @@ int board_init (void)
mx31_gpio_mux(MUX_CTS1__UART1_CTS_B);
 
/* SPI2 */
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS2);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SCLK);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SPI_RDY);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_MOSI);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_MISO);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS0);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS1);
+   mx31_gpio_mux(MUX_CSPI2_SS2__CSPI2_SS2_B);
+   mx31_gpio_mux(MUX_CSPI2_SCLK__CSPI2_CLK);
+   mx31_gpio_mux(MUX_CSPI2_SPI_RDY__CSPI2_DATAREADY_B);
+   mx31_gpio_mux(MUX_CSPI2_MOSI__CSPI2_MOSI);
+   mx31_gpio_mux(MUX_CSPI2_MISO__CSPI2_MISO);
+   mx31_gpio_mux(MUX_CSPI2_SS0__CSPI2_SS0_B);
+   mx31_gpio_mux(MUX_CSPI2_SS1__CSPI2_SS1_B);
 
/* start SPI2 clock */
__REG(CCM_CGR2) = __REG(CCM_CGR2) | (3 << 4);
diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c
index b6928fc..c24c47c 100644
--- a/board/mx31ads/mx31ads.c
+++ b/board/mx31ads/mx31ads.c
@@ -58,13 +58,13 @@ int board_init (void)
mx31_gpio_mux(MUX_CTS1__UART1_CTS_B);
 
/* SPI2 */
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS2);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SCLK);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SPI_RDY);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_MOSI);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_MISO);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS0);
-   mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS1);
+   mx31_gpio_mux(MUX_CSPI2_SS2__CSPI2_SS2_B);
+   mx31_gpio_mux(MUX_CSPI2_SCLK__CSPI2_CLK);
+   mx31_gpio_mux(MUX_CSPI2_SPI_RDY__CSPI2_DATAREADY_B);
+   mx31_gpio_mux(MUX_CSPI2_MOSI__CSPI2_MOSI);
+   mx31_gpio_mux(MUX_CSPI2_MISO__CSPI2_MISO);
+   mx31_gpio_mux(MUX_CSPI2_SS0__CSPI2_SS0_B);
+   mx31_gpio_mux(MUX_CSPI2_SS1__CSPI2_SS1_B);
 
/* start SPI2 clock */
__REG(CCM_CGR2) = __REG(CCM_CGR2) | (3 << 4);
diff --git a/cpu/arm1136/mx31/generic.c b/cpu/arm1136/mx31/generic.c
index 29c08c1..dc031c9 100644
--- a/cpu/arm1136/mx31/generic.c
+++ b/cpu/arm1136/mx31/generic.c
@@ -81,12 +81,12 @@ void mx31_gpio_mux(unsigned long mode)
 {
unsigned long reg, shift, tmp;
 
-   reg = IOMUXC_BASE + (mode & 0xfc);
+   reg = IOMUXC_BASE + (mode & 0x1fc);
shift = (~mode & 0x3) * 8;
 
tmp = __REG(reg);
tmp &= ~(0xff << shift);
-   tmp |= ((mode >> 8) & 0xff) << shift;
+   tmp |= ((mode >> IOMUX_MODE_POS) & 0xff) << shift;
__REG(reg) = tmp;
 }
 
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h 
b/include/asm-arm/arch-mx31/mx31-regs.h
index abe61f0..b04a718 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -126,17 +126,32 @@
 #define MUX_CTL_CSPI2_SS2  0x87
 #define MUX_CTL_CSPI2_MOSI 0x8b
 
-/* The modes a specific pin can be in
- * these macros can be used in mx31_gpio_mux() and have the form
- * MUX_[contact name]__[pin function]
+/*
+ * Helper macros for the MUX_[contact name]__[pin function] macros
  */
-#define MUX_RXD1__UART1_RXD_MUX((MUX_CTL_FUNC << 8) | MUX_CTL_RXD1)
-#define MUX_TXD1__UART1_TXD_MUX((MUX_CTL_FUNC << 8) | MUX_CTL_TXD1)
-#define MUX_RTS1__UART1_RTS_B  ((MUX_CTL_FUNC << 8) | MUX_CTL_RTS1)
-#define MUX_CTS1__UART1_CTS_B  ((MUX_CTL_FUNC << 8) | MUX_CTL_CTS1)
+#define IOMUX_MODE_POS 9
+#define IOMUX_MODE(contact, mode) (((mode) << IOMUX_MODE_POS) | (contact))
 
-#define MUX_CSPI2_MOSI__I2C2_SCL ((MUX_CTL_ALT1 << 8) | MUX_CTL_CSPI2_MOSI)
-#define MUX_CSPI2_MISO__I2C2_SDA ((MUX_CTL_ALT1 << 8) | MUX_CTL_CSPI2_MISO)
+/*
+ * These macros can be used in mx31_gpio_mux() and have the form
+ * MUX_[contact name]__[pin function]
+ */
+#define MUX_RXD1__UART1_RXD_MUXIOMU

[U-Boot-Users] [PATCH v2 1/2] i.MX31: Fix IOMUX related typos

2008-08-03 Thread Magnus Lilja 
Correct the names of some IOMUX macros.

Signed-off-by: Magnus Lilja <[EMAIL PROTECTED]>
---
No changes from first version.

 board/imx31_litekit/imx31_litekit.c   |2 +-
 board/imx31_phycore/imx31_phycore.c   |4 ++--
 board/mx31ads/mx31ads.c   |2 +-
 include/asm-arm/arch-mx31/mx31-regs.h |4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/board/imx31_litekit/imx31_litekit.c 
b/board/imx31_litekit/imx31_litekit.c
index 263dd9f..8cbc26e 100644
--- a/board/imx31_litekit/imx31_litekit.c
+++ b/board/imx31_litekit/imx31_litekit.c
@@ -50,7 +50,7 @@ int board_init (void)
mx31_gpio_mux(MUX_RXD1__UART1_RXD_MUX);
mx31_gpio_mux(MUX_TXD1__UART1_TXD_MUX);
mx31_gpio_mux(MUX_RTS1__UART1_RTS_B);
-   mx31_gpio_mux(MUX_RTS1__UART1_CTS_B);
+   mx31_gpio_mux(MUX_CTS1__UART1_CTS_B);
 
/* SPI2 */
mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS2);
diff --git a/board/imx31_phycore/imx31_phycore.c 
b/board/imx31_phycore/imx31_phycore.c
index 42ecb1e..ae93444 100644
--- a/board/imx31_phycore/imx31_phycore.c
+++ b/board/imx31_phycore/imx31_phycore.c
@@ -54,11 +54,11 @@ int board_init (void)
mx31_gpio_mux(MUX_RXD1__UART1_RXD_MUX);
mx31_gpio_mux(MUX_TXD1__UART1_TXD_MUX);
mx31_gpio_mux(MUX_RTS1__UART1_RTS_B);
-   mx31_gpio_mux(MUX_RTS1__UART1_CTS_B);
+   mx31_gpio_mux(MUX_CTS1__UART1_CTS_B);
 
/* setup pins for I2C2 (for EEPROM, RTC) */
mx31_gpio_mux(MUX_CSPI2_MOSI__I2C2_SCL);
-   mx31_gpio_mux(MUX_CSPI2_MISO__I2C2_SCL);
+   mx31_gpio_mux(MUX_CSPI2_MISO__I2C2_SDA);
 
gd->bd->bi_arch_number = 447;   /* board id for linux */
gd->bd->bi_boot_params = (0x8100);  /* adress of boot parameters */
diff --git a/board/mx31ads/mx31ads.c b/board/mx31ads/mx31ads.c
index dd0e150..b6928fc 100644
--- a/board/mx31ads/mx31ads.c
+++ b/board/mx31ads/mx31ads.c
@@ -55,7 +55,7 @@ int board_init (void)
mx31_gpio_mux(MUX_RXD1__UART1_RXD_MUX);
mx31_gpio_mux(MUX_TXD1__UART1_TXD_MUX);
mx31_gpio_mux(MUX_RTS1__UART1_RTS_B);
-   mx31_gpio_mux(MUX_RTS1__UART1_CTS_B);
+   mx31_gpio_mux(MUX_CTS1__UART1_CTS_B);
 
/* SPI2 */
mx31_gpio_mux((MUX_CTL_FUNC << 8) | MUX_CTL_CSPI2_SS2);
diff --git a/include/asm-arm/arch-mx31/mx31-regs.h 
b/include/asm-arm/arch-mx31/mx31-regs.h
index 02b7dcb..abe61f0 100644
--- a/include/asm-arm/arch-mx31/mx31-regs.h
+++ b/include/asm-arm/arch-mx31/mx31-regs.h
@@ -133,10 +133,10 @@
 #define MUX_RXD1__UART1_RXD_MUX((MUX_CTL_FUNC << 8) | MUX_CTL_RXD1)
 #define MUX_TXD1__UART1_TXD_MUX((MUX_CTL_FUNC << 8) | MUX_CTL_TXD1)
 #define MUX_RTS1__UART1_RTS_B  ((MUX_CTL_FUNC << 8) | MUX_CTL_RTS1)
-#define MUX_RTS1__UART1_CTS_B  ((MUX_CTL_FUNC << 8) | MUX_CTL_CTS1)
+#define MUX_CTS1__UART1_CTS_B  ((MUX_CTL_FUNC << 8) | MUX_CTL_CTS1)
 
 #define MUX_CSPI2_MOSI__I2C2_SCL ((MUX_CTL_ALT1 << 8) | MUX_CTL_CSPI2_MOSI)
-#define MUX_CSPI2_MISO__I2C2_SCL ((MUX_CTL_ALT1 << 8) | MUX_CTL_CSPI2_MISO)
+#define MUX_CSPI2_MISO__I2C2_SDA ((MUX_CTL_ALT1 << 8) | MUX_CTL_CSPI2_MISO)
 
 /*
  * Memory regions and CS

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

[U-Boot-Users] El segundo trabajo.

2008-08-03 Thread ben 
Me llamo Valeriy Volik. Me director adjunto de la empresa de System Storage 
Software. 
Nuestra empresa seocupa en el desarrollo aplicado de la empresa, las sistemas
integracionistas, las cadenas corporativas y otras soluciones de software
para el negocio, las haciendas y otros tipos de problemas.
Nuestra empresa esta situada en Ucrania. Gozamos de buena fama y somos los
socios seguros y dignos de confianza. Trabajamos con exito con muchas
empresas de la Europa Occidental y America del Norte haciendo el software
seguro para ellos. Casi un ano trabajamos con los clientes de los paises
extranjeros y no teniamos los problemas con ellos a excepcion de los
terminos del pago. Transferencias financieras en sumas de 3000-20 000 EUROS
van al Ucrania cerca de 3-5 dias + lo mismo termino para la comprobacion por
el Banco. En total, junto con los dias de descanso, este termino puede ser
desde 10 dias hasta 2-3 semanas. Ahora estamos trabajando con los proyectos
grandes, que tienen necesidad de los inversiones grandes de dinero y no
tenemos las posibilidades para esperar el pago tan largo tiempo.
Por eso, en este momento estamos buscando los socios en su pais, quien nos
ayudara aceptar el pago mas rapido. Si Vds. quieren ganar el dinero
complementario, Vds. pueden ser los representantes de nuestra empresa en su
pias. Vds. podran recibir 8% de cada transaccion, que realizamos con la
participacion de su cuenta. Su trabajo consistira en la aceptacion del
capital en la forma de los giros postales a su cuenta y la salida del dinero
a nosotros. Esto es un metodo muy comodo y rapido de recibir los ingresos
adicionales. Ademas, estudiamos la posibilidad de la apertura de la oficina
en su pais en el futuro proximo y entonces Vds. podran tener los privilegios
de recibir el trabajo de plena ocupacion. Si Vds. tienen interes trabajar
con nosotros, entonces, estamos en sus ordenes.

Pueden contactar con nosotros con ayuda de E-Mail:  [EMAIL PROTECTED]

y envien a nosotros la informacion siguiente:

1. Su nombre y apellido
2. Educacion
3. Direccion
4. Numero de telefono/fax
5. Conocimiento de la lengua Inglesa
6. Su edad

Por favor, respondan a nuestra carta y nosotros daremos los datos
adicionales sobre la cooperacion. Este colaboracion no vale nada para Vds. ,
pero esto la posibilidad de recibir los ingresos adicionales muy comodo y
rapido. Si Vds. tienen algunas preguntas, no tienen escrupulos en
contactarse con nosotros.

Con respeto.
Valeriy Volik
System Storage Software-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

2008-08-03 Thread Grant Likely 
On Sun, Aug 3, 2008 at 11:49 AM, Timur Tabi <[EMAIL PROTECTED]> wrote:
> On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
>
>> If the  DTB  can  be  at  any
>> flash location, you can for example have a fall-back version which is
>> used  to bring up U-Boot in a minimal configuration for recovery mode
>> if the new DTB fails to work.
>
> I think that a "recovery DTB" would have to be part of U-Boot itself
> to be effective.  If the normal DTB is not available, then it's likely
> the backup one would also be unavailable.

Better to just not depend on the DTB at all for basic operation.  ie.
don't brick the board if the DTB is unavailable.

g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

2008-08-03 Thread Timur Tabi 
On Sun, Aug 3, 2008 at 10:47 AM, Wolfgang Denk <[EMAIL PROTECTED]> wrote:

> If the  DTB  can  be  at  any
> flash location, you can for example have a fall-back version which is
> used  to bring up U-Boot in a minimal configuration for recovery mode
> if the new DTB fails to work.

I think that a "recovery DTB" would have to be part of U-Boot itself
to be effective.  If the normal DTB is not available, then it's likely
the backup one would also be unavailable.

-- 
Timur Tabi
Linux kernel developer at Freescale

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

2008-08-03 Thread Wolfgang Denk 
In message <[EMAIL PROTECTED]> you wrote:
>
> > No, no, no. The DTB *must not* be included with the U-Boot image.  It
> >  shall  always  be  kept  separate  so we canupdate it independently -
> >  otherwise you lose a lot of advantages.
> 
> A DTB is only about 8K. I was thinking that a user supplied one would
> override the one contained inside uboot.

Then you have to take special care  that  the  DTB  is  flash  sector
aligned  and sufficiently padded - this extra effort and introduces a
new, avoidable single point of failure. If the  DTB  can  be  at  any
flash location, you can for example have a fall-back version which is
used  to bring up U-Boot in a minimal configuration for recovery mode
if the new DTB fails to work.

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 PROTECTED]
Space is big. You just won't believe how vastly, hugely, mind-
bogglingly big it is. I mean, you may think it's a long way down the
road to the drug store, but that's just peanuts to space.
  -- The Hitchhiker's Guide to the Galaxy

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

2008-08-03 Thread Jon Smirl 
On 8/3/08, Wolfgang Denk <[EMAIL PROTECTED]> wrote:
> In message <[EMAIL PROTECTED]> you wrote:
>  >
>  > > What about creating a tool that parses a device tree and creates (or
>  > >  updates) the board header file?  This will retain compatibility with
>  > >  other platforms, clean up the existing header files (they won't need
>  > >  to contain as much information), and reduce the amount of changes to
>  > >  U-Boot itself.
>  >
>  > That's a good idea. I have used variation on this concept in the past
>  > and they have worked out well.
>
>
> A much more powerful concept is to have U-Boot read and interpret the
>  DT dynamically - only then can you use the same U-Boot  binary  image
>  on  different board configurations, which is an important feature for
>  many board vendors.

I don't disagree with this but it is a lot more work.

>
>  > A perfect tool would take a fully populated DTS file and use it to
>  > dynamically generate all of the needed header files to build uboot.
>  > More info would need to be added to the DTS file like DRAM timings,
>  > etc. But a DTS file is good place to track all of that info. The
>  > generated uboot image could contain a copy of the DTB and feed it to
>  > Linux. Allow the user to override the embedded DTB if necessary.
>
>
> No, no, no. The DTB *must not* be included with the U-Boot image.  It
>  shall  always  be  kept  separate  so we canupdate it independently -
>  otherwise you lose a lot of advantages.

A DTB is only about 8K. I was thinking that a user supplied one would
override the one contained inside uboot.

>
>  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 PROTECTED]
>  Unsichtbar macht sich die Dummheit, indem sie immer  größere  Ausmaße
>  annimmt. -- Bertold Brecht: Der Tui-Roman
>


-- 
Jon Smirl
[EMAIL PROTECTED]

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] Marvell db64460 / mpc7447 migration from U-boot 1.1.2 to U-boot 1.3.3

2008-08-03 Thread Jerry Van Baren 
Stephen Horton wrote:
> Hello folks,
> 
> In a current work project, I have inherited a compactPCI board that has 
> an mpc7447/7448 powerpc processor as well as a Marvell system 
> controller, model mv64462 (stripped down mv64460). The board has a 
> somewhat working U-boot 1.1.2 loader (using db64460 platform) and a 
> Gentoo Linux port (kernel version 2.6.9 built using arch/ppc) running on 
> it from long ago and a company far far away. It looks like the company 
> contracted with Timesys to pull together the initial software. To 
> prepare for an upcoming deployment, I would like to bring the OS 
> up-to-date on this board with a newer kernel (targeting 2.6.24r3), as 
> well as migrate U-boot to 1.3.3 and fix some bugs along the way.
> 
> My Linux kernel work is going very well, but with U-boot I’m stuck. I 
> have what I believe ‘may’ be the working U-boot 1.1.2 source code, and I 
> have migrated all of the board’s customizations from various files into 
> the 1.3.3 stream; however, I can get –no- console output on the serial 
> port. I don’t have access to a remote debugger, so I’m working in the 
> dark and have no idea how far, if at all, the initialization is 
> progressing. Does anyone know of any tips to help me along?  Any changes 
> in mpsc device initialization from 1.1.2 to 1.3.3 that could help me? 
> Any clues?
> 
> Regards,
> 
> Stephen

Suggestion: first make sure your 1.1.2 source is working (fix as 
necessary) before trying to pull it forward.

How are you reloading flash when you brick the board?  What capabilities 
does your hardware have for debugging - can it halt the processor and 
show the registers?

Are there any LEDs you can blink when you get to a certain place in the 
code, and then move the blinkin' successfully further in the init 
sequence?  Can you hook a logic analyzer or scope to a bus and do a bus 
write to indicate progress?

Is is a memory size / organization issue?  Despite Wolfgang's best 
efforts, u-boot keeps growing.  :-/  If you are lucky, the problem is 
simply that a memory section outgrew its allocation.

Good luck,
gvb

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users

Re: [U-Boot-Users] using a flat device tree to drive u-boot config

2008-08-03 Thread Wolfgang Denk 
In message <[EMAIL PROTECTED]> you wrote:
>
> > What about creating a tool that parses a device tree and creates (or
> >  updates) the board header file?  This will retain compatibility with
> >  other platforms, clean up the existing header files (they won't need
> >  to contain as much information), and reduce the amount of changes to
> >  U-Boot itself.
> 
> That's a good idea. I have used variation on this concept in the past
> and they have worked out well.

A much more powerful concept is to have U-Boot read and interpret the
DT dynamically - only then can you use the same U-Boot  binary  image
on  different board configurations, which is an important feature for
many board vendors.

> A perfect tool would take a fully populated DTS file and use it to
> dynamically generate all of the needed header files to build uboot.
> More info would need to be added to the DTS file like DRAM timings,
> etc. But a DTS file is good place to track all of that info. The
> generated uboot image could contain a copy of the DTB and feed it to
> Linux. Allow the user to override the embedded DTB if necessary.

No, no, no. The DTB *must not* be included with the U-Boot image.  It
shall  always  be  kept  separate  so we canupdate it independently -
otherwise you lose a lot of advantages.

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 PROTECTED]
Unsichtbar macht sich die Dummheit, indem sie immer  größere  Ausmaße
annimmt. -- Bertold Brecht: Der Tui-Roman

-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users