[U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support

[Prafulla Wadaskar]

I am sorry for previous post v2, pls ignore it, this is the right patch for the 
same

This feature can be used to trigger special command "sysrstcmd" using
reset key long press event and environment variable "sysrstdelay" is set
(useful for reset to factory or manufacturing mode execution)

Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
The counter value is stored in the SYSRSTn Length Counter Register
The counter is based on the 25-MHz reference clock (40ns)
It is a 29-bit counter, yielding a maximum counting duration of
2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
it remains at this value until counter reset is triggered by setting
bit 31 of KW_REG_SYSRST_CNT

Implementation:
Upon long reset assertion (> ${sysrstdleay} in secs) sysrstcmd will be
executed if pre-defined in environment variables.
This feature will be disabled if "sysrstdelay" variable is unset.

for-ex.
setenv sysrst_cmd "echo starting factory reset;
   nand erase 0xa 0x2;
   echo finish ed sysrst command;"
will erase particular nand sector if triggered by this event

Signed-off-by: Prafulla Wadaskar 
---
Change log:
v2: updated as per review feedback for v1
bug fix in the previous post (V2) fixed

 cpu/arm926ejs/kirkwood/cpu.c|   75 +++
 include/asm-arm/arch-kirkwood/cpu.h |2 +
 2 files changed, 77 insertions(+), 0 deletions(-)

diff --git a/cpu/arm926ejs/kirkwood/cpu.c b/cpu/arm926ejs/kirkwood/cpu.c
index 795a739..97318ff 100644
--- a/cpu/arm926ejs/kirkwood/cpu.c
+++ b/cpu/arm926ejs/kirkwood/cpu.c
@@ -195,6 +195,78 @@ int kw_config_mpp(u32 mpp0_7, u32 mpp8_15, u32 mpp16_23, 
u32 mpp24_31,
return 0;
 }
 
+/*
+ * SYSRSTn Duration Counter Support
+ *
+ * Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
+ * When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
+ * The SYSRSTn duration counter is useful for implementing a manufacturer
+ * or factory reset. Upon a long reset assertion that is greater than a
+ * pre-configured environment variable value for sysrstdelay,
+ * The counter value is stored in the SYSRSTn Length Counter Register
+ * The counter is based on the 25-MHz reference clock (40ns)
+ * It is a 29-bit counter, yielding a maximum counting duration of
+ * 2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
+ * it remains at this value until counter reset is triggered by setting
+ * bit 31 of KW_REG_SYSRST_CNT
+ */
+static void kw_sysrst_action(void)
+{
+   int ret;
+   char *s = getenv("sysrstcmd");
+
+   if (!s) {
+   printf("Error.. %s failed, check sysrstcmd\n",
+   __FUNCTION__);
+   return;
+   }
+
+   printf("Starting %s process...\n", __FUNCTION__);
+#if !defined(CONFIG_SYS_HUSH_PARSER)
+   ret = run_command (s, 0);
+#else
+   ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
+ | FLAG_EXIT_FROM_LOOP);
+#endif
+   if (ret < 0)
+   printf("Error.. %s failed\n", __FUNCTION__);
+   else
+   printf("%s process finished\n", __FUNCTION__);
+}
+
+static void kw_sysrst_check(void)
+{
+   u32 sysrst_cnt, sysrst_dly;
+   char *s;
+
+   /*
+* no action if sysrstdelay environment variable is not defined
+*/
+   s = getenv("sysrstdelay");
+   if (s == NULL)
+   return;
+
+   /* read sysrstdelay value */
+   sysrst_dly = (u32) simple_strtoul(s, NULL, 10);
+
+   /* read SysRst Length counter register (bits 28:0) */
+   sysrst_cnt = (0x1fff & readl(KW_REG_SYSRST_CNT));
+   printf("H/w Rst hold time: %d.%d secs\n",
+   sysrst_cnt / SYSRST_CNT_1SEC_VAL,
+   sysrst_cnt % SYSRST_CNT_1SEC_VAL);
+
+   /* clear the counter for next valid read*/
+   writel(1 << 31, KW_REG_SYSRST_CNT);
+
+   /*
+* sysrst_action:
+* if H/w Reset key is pressed and hold for time
+* more than sysrst_dly in seconds
+*/
+   if (sysrst_cnt >= SYSRST_CNT_1SEC_VAL * sysrst_dly)
+   kw_sysrst_action();
+}
+
 #if defined(CONFIG_DISPLAY_CPUINFO)
 int print_cpuinfo(void)
 {
@@ -298,6 +370,9 @@ int arch_misc_init(void)
temp = get_cr();
set_cr(temp & ~CR_V);
 
+   /* checks and execute resset to factory event */
+   kw_sysrst_check();
+
return 0;
 }
 #endif /* CONFIG_ARCH_MISC_INIT */
diff --git a/include/asm-arm/arch-kirkwood/cpu.h 
b/include/asm-arm/arch-kirkwood/cpu.h
index d1440af..b3022a3 100644
--- a/include/asm-arm/arch-kirkwood/cpu.h
+++ b/include/asm-arm/arch-kirkwood/cpu.h
@@ -36,6 +36,8 @@
((_x ? KW_EGIGA0_BASE : KW_EGIGA1_BASE) + 0x44c)
 
 #define KW_REG_DEVICE_ID   (KW_MPP_BASE + 0x34)
+#define KW_REG_SYSRST_CNT  (KW_MPP_BASE + 0x50)
+#define SYSRST_CNT_1S

Re: [U-Boot] DDR initialization

[Magnus Lilja]

Hi

2009/8/19 alfred steele :
> Hi all,
> How do i go about the SDRAM/DDR initialization on my board. IS the
> function partitoned  or is it just done in  a single place.
> I would think that  board specifc dram_init is just a generic
> function. There has to be a specific place where the SDRAM controller
> is told about the DRR/SDRAM.
> Is the porting documented somewhere or are there any good example to
> follow to stick to U-boot conventions.

It's often done in lowlevel_init.S, whether that's true for all
platforms and all boards I do not know.

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

[U-Boot] [PATCH v2] arm: Kirkwood: add SYSRSTn Duration Counter Support

[Prafulla Wadaskar]

This feature can be used to trigger special command "sysrstcmd" using
reset key long press event and environment variable "sysrstdelay" is set
(useful for reset to factory or manufacturing mode execution)

Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
The counter value is stored in the SYSRSTn Length Counter Register
The counter is based on the 25-MHz reference clock (40ns)
It is a 29-bit counter, yielding a maximum counting duration of
2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
it remains at this value until counter reset is triggered by setting
bit 31 of KW_REG_SYSRST_CNT

Implementation:
Upon long reset assertion (> ${sysrstdleay} in secs) sysrstcmd will be
executed if pre-defined in environment variables.
This feature will be disabled if "sysrstdelay" variable is unset.

for-ex.
setenv sysrst_cmd "echo starting factory reset;
   nand erase 0xa 0x2;
   echo finish ed sysrst command;"
will erase particular nand sector if triggered by this event

Signed-off-by: Prafulla Wadaskar 
---
Change log:
v2: updated as per review feedback for v1
build time error detection added for CONFIG_CMD_RUN

 cpu/arm926ejs/kirkwood/cpu.c|   79 +++
 include/asm-arm/arch-kirkwood/cpu.h |2 +
 2 files changed, 81 insertions(+), 0 deletions(-)

diff --git a/cpu/arm926ejs/kirkwood/cpu.c b/cpu/arm926ejs/kirkwood/cpu.c
index 795a739..1d3af4a 100644
--- a/cpu/arm926ejs/kirkwood/cpu.c
+++ b/cpu/arm926ejs/kirkwood/cpu.c
@@ -195,6 +195,82 @@ int kw_config_mpp(u32 mpp0_7, u32 mpp8_15, u32 mpp16_23, 
u32 mpp24_31,
return 0;
 }
 
+/*
+ * SYSRSTn Duration Counter Support
+ *
+ * Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
+ * When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
+ * The SYSRSTn duration counter is useful for implementing a manufacturer
+ * or factory reset. Upon a long reset assertion that is greater than a
+ * pre-configured environment variable value for sysrstdelay,
+ * The counter value is stored in the SYSRSTn Length Counter Register
+ * The counter is based on the 25-MHz reference clock (40ns)
+ * It is a 29-bit counter, yielding a maximum counting duration of
+ * 2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
+ * it remains at this value until counter reset is triggered by setting
+ * bit 31 of KW_REG_SYSRST_CNT
+ */
+static void kw_sysrst_action(void)
+{
+   int ret;
+   char *s = getenv("sysrstcmd");
+
+   if (!s) {
+   printf("Error.. %s failed, check sysrstcmd\n",
+   __FUNCTION__);
+   return;
+   }
+
+   printf("Starting %s process...\n", __FUNCTION__);
+#if !defined(CONFIG_SYS_HUSH_PARSER)
+   ret = run_command (s, 0);
+#else
+   ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
+ | FLAG_EXIT_FROM_LOOP);
+#endif
+   if (ret < 0)
+   printf("Error.. %s failed\n", __FUNCTION__);
+   else
+   printf("%s process finished\n", __FUNCTION__);
+
+#else  /* CONFIG_CMD_RUN */
+#error "Error.. CONFIG_CMD_RUN not defined (needed for sysrstcmd support)"
+#endif /* CONFIG_CMD_RUN */
+}
+
+static void kw_sysrst_check(void)
+{
+   u32 sysrst_cnt, sysrst_dly;
+   char *s;
+
+   /*
+* no action if sysrstdelay environment variable is not defined
+*/
+   s = getenv("sysrstdelay");
+   if (s == NULL)
+   return;
+
+   /* read sysrstdelay value */
+   sysrst_dly = (u32) simple_strtoul(s, NULL, 10);
+
+   /* read SysRst Length counter register (bits 28:0) */
+   sysrst_cnt = (0x1fff & readl(KW_REG_SYSRST_CNT));
+   printf("H/w Rst hold time: %d.%d secs\n",
+   sysrst_cnt / SYSRST_CNT_1SEC_VAL,
+   sysrst_cnt % SYSRST_CNT_1SEC_VAL);
+
+   /* clear the counter for next valid read*/
+   writel(1 << 31, KW_REG_SYSRST_CNT);
+
+   /*
+* sysrst_action:
+* if H/w Reset key is pressed and hold for time
+* more than sysrst_dly in seconds
+*/
+   if (sysrst_cnt >= SYSRST_CNT_1SEC_VAL * sysrst_dly)
+   kw_sysrst_action();
+}
+
 #if defined(CONFIG_DISPLAY_CPUINFO)
 int print_cpuinfo(void)
 {
@@ -298,6 +374,9 @@ int arch_misc_init(void)
temp = get_cr();
set_cr(temp & ~CR_V);
 
+   /* checks and execute resset to factory event */
+   kw_sysrst_check();
+
return 0;
 }
 #endif /* CONFIG_ARCH_MISC_INIT */
diff --git a/include/asm-arm/arch-kirkwood/cpu.h 
b/include/asm-arm/arch-kirkwood/cpu.h
index d1440af..b3022a3 100644
--- a/include/asm-arm/arch-kirkwood/cpu.h
+++ b/include/asm-arm/arch-kirkwood/cpu.h
@@ -36,6 +36,8 @@
((_x ? KW_EGIGA0_BASE : KW_EGIGA1_BASE) + 0x44c)
 
 #define KW_REG_DEVICE_ID   (KW_MPP_BASE + 0x34)
+#define KW_REG_SYSRST

[U-Boot] DDR initialization

[alfred steele]

Hi all,
How do i go about the SDRAM/DDR initialization on my board. IS the
function partitoned  or is it just done in  a single place.
I would think that  board specifc dram_init is just a generic
function. There has to be a specific place where the SDRAM controller
is told about the DRR/SDRAM.
Is the porting documented somewhere or are there any good example to
follow to stick to U-boot conventions.

Please enlighten me.

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

Re: [U-Boot] Regarding 8641D u-boot

[Becky Bruce]

On Aug 18, 2009, at 9:14 AM, Kumar Gala wrote:

>
> On Aug 18, 2009, at 5:12 AM, Thirumalai wrote:
>
>> Hi kumar,
>>  The CONFIG_PHYS_64BIT was not defined on the header file
>> of HPCN but extended address translation was enabled on the start.S
>> irrespective of the  MPC8641D_hpcn compilation option why?.
>>
>> Regards,
>> T.
>
> Are you running into an issue with this?  It could be to allow an OS
> to have 36-bit addressing w/o u-boot having to deal with it.

That's always been there (since the original board port), and it  
shouldn't cause a problem (or any performance issues), AFAIK.

Cheers,
Becky

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

[U-Boot] [PATCH] fsl: simplify the "mac id" command, improve boot-time informational message

[Timur Tabi]

The "mac id" command took a 4-character parameter as the identifier string.
However, for any given board, only one kind of identifier is acceptable, so it
makes no sense to ask the user to type it in.  Instead, if the user enters
"mac id", the identifier (and also the version, if it's NXID) will
automatically be set to the correct value.

Improve the message that is displayed when EEPROM is read during boot.  It now
displays "EEPROM:" and then either an error message or the EEPROM identifier
if successful.

If the identifier in EEPROM is valid, then always reject a bad CRC, even if the
CRC field has not been initialized.

Don't force the MAC address count to MAX_NUM_PORTS or less.  Forcing the value
to be changed resulting in an in-memory copy that does not match what's in
hardware, even though the user did not request that change.

Finally, always update the CRC value in the in-memory copy after any field
is changed, so that the CRC is always correct.

Signed-off-by: Timur Tabi 
---
 board/freescale/common/sys_eeprom.c |   79 +--
 lib_ppc/board.c |1 +
 2 files changed, 48 insertions(+), 32 deletions(-)

diff --git a/board/freescale/common/sys_eeprom.c 
b/board/freescale/common/sys_eeprom.c
index 3e1e332..f11b249 100644
--- a/board/freescale/common/sys_eeprom.c
+++ b/board/freescale/common/sys_eeprom.c
@@ -186,12 +186,25 @@ static int read_eeprom(void)
 }
 
 /**
+ *  update_crc - update the CRC
+ *
+ *  This function should be called after each update to the EEPROM structure,
+ *  to make sure the CRC is always correct.
+ */
+static void update_crc(void)
+{
+   u32 crc;
+
+   crc = crc32(0, (void *)&e, sizeof(e) - 4);
+   e.crc = cpu_to_be32(crc);
+}
+
+/**
  * prog_eeprom - write the EEPROM from memory
  */
 static int prog_eeprom(void)
 {
-   int ret, i, length;
-   unsigned int crc;
+   int ret, i;
void *p;
 #ifdef CONFIG_SYS_EEPROM_BUS_NUM
unsigned int bus;
@@ -204,19 +217,16 @@ static int prog_eeprom(void)
 #else
memset(e.res_0, 0xFF, sizeof(e.res_0));
 #endif
-
-   length = sizeof(e);
-   crc = crc32(0, (void *)&e, length - 4);
-   e.crc = cpu_to_be32(crc);
+   update_crc();
 
 #ifdef CONFIG_SYS_EEPROM_BUS_NUM
bus = i2c_get_bus_num();
i2c_set_bus_num(CONFIG_SYS_EEPROM_BUS_NUM);
 #endif
 
-   for (i = 0, p = &e; i < length; i += 8, p += 8) {
+   for (i = 0, p = &e; i < sizeof(e); i += 8, p += 8) {
ret = i2c_write(CONFIG_SYS_I2C_EEPROM_ADDR, i, 
CONFIG_SYS_I2C_EEPROM_ADDR_LEN,
-   p, min((length - i), 8));
+   p, min((sizeof(e) - i), 8));
if (ret)
break;
udelay(5000);   /* 5ms write cycle timing */
@@ -273,6 +283,8 @@ static void set_date(const char *string)
 
for (i = 0; i < 6; i++)
e.date[i] = h2i(string[2 * i]) << 4 | h2i(string[2 * i + 1]);
+
+   update_crc();
 }
 
 /**
@@ -297,11 +309,12 @@ static void set_mac_address(unsigned int index, const 
char *string)
if (*p == ':')
p++;
}
+
+   update_crc();
 }
 
 int do_mac(cmd_tbl_t *cmdtp, int flag, int argc, char *argv[])
 {
-   int i;
char cmd;
 
if (argc == 1) {
@@ -316,9 +329,13 @@ int do_mac(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
return 0;
}
 
-   if ((cmd == 'i') && (argc > 2)) {
-   for (i = 0; i < 4; i++)
-   e.id[i] = argv[2][i];
+   if (cmd == 'i') {
+#ifdef CONFIG_SYS_I2C_EEPROM_NXID
+   memcpy(e.id, "NXID", sizeof(e.id));
+   e.version = 0;
+#else
+   memcpy(e.id, "CCID", sizeof(e.id));
+#endif
return 0;
}
 
@@ -346,6 +363,7 @@ int do_mac(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
case 'n':   /* serial number */
memset(e.sn, 0, sizeof(e.sn));
strncpy((char *)e.sn, argv[2], sizeof(e.sn) - 1);
+   update_crc();
break;
case 'e':   /* errata */
 #ifdef CONFIG_SYS_I2C_EEPROM_NXID
@@ -355,12 +373,14 @@ int do_mac(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
e.errata[0] = argv[2][0];
e.errata[1] = argv[2][1];
 #endif
+   update_crc();
break;
case 'd':   /* date BCD format YYMMDDhhmmss */
set_date(argv[2]);
break;
case 'p':   /* MAC table size */
e.mac_count = simple_strtoul(argv[2], NULL, 16);
+   update_crc();
break;
case '0' ... '7':   /* "mac 0" through "mac 7" */
set_mac_address(cmd - '0', argv[2]);
@@ -388,6 +408,7 @@ int do_mac(cmd_tbl_t *cmdtp, int flag, int argc, char 
*argv[])
 int mac_read_from_eeprom(void)
 {
unsigned int i;
+   u32 crc;
 
if (read_

Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

Dear Tom,

In message <4a8af7d9.7070...@windriver.com> you wrote:
>
> MAKEALL arm with CodeSourcery's
> arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu
> arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu
> 
> and this patch differ from
> 
> USE_PRIVATE_LIBGCC=yes ./MAKEALL arm
> 
> only in these targets
> 
> actux1 actux2 actux3 actux4 ixdp425 ixdpg425 pdnb3 scpu trab
> 
> As already mentioned already by
> 
> http://lists.denx.de/pipermail/u-boot/2009-August/058838.html
> 
> Tested-by : Tom Rix 

Thanks a lot, Tom.

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
Wenn das dann in die Hose geht, nehme ich es auf meine Kappe.
 -- Rudi Völler, 15. Nov 2003
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

Dear Magnus Lilja,

In message <59b21cf20908181008t75a981d8g512c10687c0b8...@mail.gmail.com> you 
wrote:
> 
> Tested-by: Magnus Lilja 
> 
> 
> Run-time tested on i.MX31 PDK board using the above toolchains.

Thanks a lot!

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
About the use of language: it is impossible to sharpen a pencil  with
a  blunt  ax.  It is equally vain to try to do it with ten blunt axes
instead.   -- Edsger Dijkstra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] NAND: DaVinci:Adding 4 BIT ECC support

[Wolfgang Denk]

Dear s-paul...@ti.com,

In message <1250613233-3362-1-git-send-email-s-paul...@ti.com> you wrote:
> From: Sandeep Paulraj 
> 
> This patch adds 4 BIT ECC support in the DaVinci NAND
> driver. Tested on both the DM355 and DM365.
> 
> V3 version of the patch resolves compilation warnings pointed to by
> Scott Wood. These compilation warnings occur when 4 BIT ECC support
> is not enabled

Such commetns must go _below_ the "---" line.

> Signed-off-by: Sandeep Paulraj 
> ---
^^^ This is where commetns belong.

> For feature completeness this patch should be used along with
> [PATCH v2] ARM: DaVinci DM355: Updating the DM355 EVM config
> that i just sent to the mailing list
>  drivers/mtd/nand/davinci_nand.c  |  283 
> +-
>  include/asm-arm/arch-davinci/emif_defs.h |   10 +
>  2 files changed, 291 insertions(+), 2 deletions(-)
...
> +static u32 nand_davinci_4bit_readecc(struct mtd_info *mtd, unsigned int 
> ecc[4])
> +{
> + ecc[0] = emif_regs->NAND4BITECC1 & NAND_4BITECC_MASK;
> + ecc[1] = emif_regs->NAND4BITECC2 & NAND_4BITECC_MASK;
> + ecc[2] = emif_regs->NAND4BITECC3 & NAND_4BITECC_MASK;
> + ecc[3] = emif_regs->NAND4BITECC4 & NAND_4BITECC_MASK;

Please use I/O accessors.

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
Celestial navigation is based on the premise that the  Earth  is  the
center  of  the  universe.  The  premise is wrong, but the navigation
works. An incorrect model can be a useful tool.   - Kelvin Throop III
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: DaVinci: DaVinci DM365 SOC specific code

[Wolfgang Denk]

Dear "Paulraj, Sandeep",

In message <0554bef07d437848af01b9c9b5f0bc5d7e996...@dlee01.ent.ti.com> you 
wrote:
>
> Yesterday night after J-C mentioned that he applied 2 of my patches to u-bo
> ot-arm next I tried to checkout that branch
>  to add some more stuff on top of my Dm365 patches.
> 
> I could not see it either. But I have used that branch in the recent past.
> I don't know what is wrong.

Unfortunately the U-Boot ARM repository is in a really poor state.
Commits and branches come and go more or less at ramdom.

I apologize for the inconveninces caused by that.

Jean-Christophe, we really need more consistency here.


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 nice thing about  standards  is that there are  so many to choose
from.   - Andrew S. Tanenbaum
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support

[Paulraj, Sandeep]

> Jean-Christophe has acked this one - see
> http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/65792/focus=6614
He said he'll ACK if this patch is ACK'ed. He has not acked yet.
> 
> But I'm concerned about direct register accesses. We really should
> insist on using proper accessor calls.
I'll rework my driver based on your comments. 
> 
> Best regards,
> 
> Wolfgang Denk

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

Re: [U-Boot] [PATCH] Add support for USB on PSC3 for the mpc5200

[Wolfgang Denk]

Dear "Eric Millbrandt",

In message <20090813131409.m57...@coldhaus.com> you wrote:
> Support USB on PSC3 on the mpc5200.  Before this patch, enabling USB support
> would reconfigure PSC4 and PSC5 to USB.  The mpc5200 does not support USB
> enabled on both the standard USB port and PSC3.  This patch masks the
> appropriate bits when enabling USB.
> 
> Signed-off-by: Eric Millbrandt 
> ---
>  README |4 
>  cpu/mpc5xxx/usb.c  |6 +-
>  cpu/mpc5xxx/usb_ohci.c |6 +-
>  3 files changed, 14 insertions(+), 2 deletions(-)

Applied to "next", 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
After a heated argument on some trivial matter Nancy [Astor]  .  .  .
shouted,  ``If  I were your wife I would put poison in your coffee!''
Whereupon Winston Churchill with equal heat and  sincerity  answered,
``And if I were your husband I would drink it.''
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Add support for USB on PSC3 for the mpc5200

[Wolfgang Denk]

Dear Remy Bohmer,

In message <3efb10970908180032w57826ddexeae344ae52a8b...@mail.gmail.com> you 
wrote:
> 
> Except from the fact that IMHO this driver belongs in the drivers/usb
> section (and being merged into the existing ohci-driver):

Agreed...

> Acked-by: Remy Bohmer 

Thanks.

> Wolfgang, do you take it in your mpc5xxx tree?

I take it directly to "next".

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
Niklaus Wirth has lamented that, whereas Europeans pronounce his name
correctly  (Ni-klows  Virt),  Americans  invariably  mangle  it  into
(Nick-les  Worth).  Which  is to say that Europeans call him by name,
but Americans call him by value.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] Add driver for the ST M41T94 SPI RTC

[Wolfgang Denk]

Dear Albin Tonnerre,

In message <1250183564-6140-1-git-send-email-albin.tonne...@free-electrons.com> 
you wrote:
> This RTC is used in some Calao boards. The driver code is taken from the
> linux rtc-m41t94 driver
> 
> Signed-off-by: Albin Tonnerre 
> ---
> Changelog since V1:
>  - Use the common bin2bcd/bcd2bin functions. This patch depends on:
>1250170272-25909-2-git-send-email-albin.tonne...@free-electrons.com
> 
>  drivers/rtc/Makefile |1 +
>  drivers/rtc/m41t94.c |  124 
> ++
>  2 files changed, 125 insertions(+), 0 deletions(-)
>  create mode 100644 drivers/rtc/m41t94.c

Aplied to "next", 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
There are three things I always forget. Names, faces -  the  third  I
can't remember. - Italo Svevo
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] Switch from per-driver to common definition of bin2bcd and bcd2bin

[Wolfgang Denk]

Dear Albin Tonnerre,

In message 
<1250170272-25909-2-git-send-email-albin.tonne...@free-electrons.com> you wrote:
> 
> Signed-off-by: Albin Tonnerre 
> ---
>  drivers/rtc/ds12887.c |   12 
>  drivers/rtc/ds1306.c  |   18 --
>  drivers/rtc/ds1307.c  |   13 -
>  drivers/rtc/ds1337.c  |   13 -
>  drivers/rtc/ds1556.c  |   12 
>  drivers/rtc/ds164x.c  |   12 
>  drivers/rtc/ds174x.c  |   12 
>  drivers/rtc/ds3231.c  |   12 
>  drivers/rtc/isl1208.c |   12 
>  drivers/rtc/m41t11.c  |   11 ---
>  drivers/rtc/m41t60.c  |   10 --
>  drivers/rtc/m41t62.c  |1 -
>  drivers/rtc/m48t35ax.c|   12 
>  drivers/rtc/max6900.c |   10 --
>  drivers/rtc/mc146818.c|   12 
>  drivers/rtc/mk48t59.c |   10 --
>  drivers/rtc/pcf8563.c |   12 
>  drivers/rtc/rs5c372.c |   14 --
>  drivers/rtc/rtc4543.c |1 -
>  drivers/rtc/rx8025.c  |   12 
>  drivers/rtc/s3c24x0_rtc.c |   10 --
>  drivers/rtc/s3c44b0_rtc.c |1 -
>  drivers/rtc/x1205.c   |1 -
>  include/rtc.h |5 +
>  24 files changed, 5 insertions(+), 233 deletions(-)

Applied to "next", 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
What is tolerance? -- it is the consequence of humanity. We  are  all
formed  of frailty and error; let us pardon reciprocally each other's
folly -- that is the first law of nature.  - Voltaire
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2] Replace BCD2BIN and BIN2BCD macros with inline functions

[Wolfgang Denk]

Dear Albin Tonnerre,

In message 
<1250170272-25909-1-git-send-email-albin.tonne...@free-electrons.com> you wrote:
> In the process, also remove backward-compatiblity macros BIN_TO_BCD and
> BCD_TO_BIN and update the sole board using them to use the new bin2bcd
> and bcd2bin instead
> 
> Signed-off-by: Albin Tonnerre 
> ---
>  board/rsdproto/rsdproto.c   |   17 -
>  drivers/rtc/m41t62.c|   24 
>  drivers/rtc/rtc4543.c   |   28 ++--
>  drivers/rtc/s3c44b0_rtc.c   |   42 +-
>  drivers/rtc/x1205.c |   28 ++--
>  include/bcd.h   |   19 ---
>  include/linux/mc146818rtc.h |   12 
>  7 files changed, 81 insertions(+), 89 deletions(-)

Applied to "next", 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
Any sufficiently advanced technology is indistinguishable from magic.
Clarke's Third Law   - _Profiles of the Future_ (1962; rev. 1973)
  ``Hazards of Prophecy: The Failure of Imagination''
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] jffs2: clean the cache in case of malloc fails in build_lists

[Wolfgang Denk]

Dear Ilya Yanok,

In message <1250080968-10923-1-git-send-email-ya...@emcraft.com> you wrote:
> We should call jffs2_clean_cache() if we return from jffs2_build_lists()
> with an error to prevent usage of incomplete lists. Also we should
> free() a local buffer to prevent memory leaks.
> 
> Signed-off-by: Ilya Yanok 
> ---
>  fs/jffs2/jffs2_1pass.c |   17 ++---
>  1 files changed, 14 insertions(+), 3 deletions(-)

Applied, thanks.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"The trouble with doing something right the first time is that nobody
appreciates how difficult it was."- Walt West
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ppc: trigger WDT before starting Linux

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4a827a7f.30...@denx.de> you wrote:
> Signed-off-by: Heiko Schocher 
> ---
>  lib_ppc/bootm.c |2 ++
>  1 files changed, 2 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
Inside every old person is a young person wondering what happened.
  - Terry Pratchett, _Moving Pictures_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support

[Wolfgang Denk]

Dear Scott Wood,

In message <4a8acbd0.6060...@freescale.com> you wrote:
> Paulraj, Sandeep wrote:
> > And please correct me if I am wrong, but J-C can't actually pull these 
> > patches into his next branch correct?
> 
> Right, not yet.
> 
> > That is because it will require 2 of the NAND patches that I sent a week 
> > ago.
> > 
> > Thus you might have to accept the DM355 EVM config update patch as well 
> > which actually enables the NAND support.
> 
> I could do that with an ACK from JC if it does not depend on anything in 
> his tree -- or I could send Wolfgang a -next pull request and then JC 
> could sync with that.

Jean-Christophe has acked this one - see
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/65792/focus=66144

But I'm concerned about direct register accesses. We really should
insist on using proper accessor calls.

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
Always leave room to add an explanation if it doesn't work out.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support

[Wolfgang Denk]

Dear "Paulraj, Sandeep",

In message <0554bef07d437848af01b9c9b5f0bc5d7e996...@dlee01.ent.ti.com> you 
wrote:
> 
> > What I mean is using accessors such as readl/writel -- though we're still
> > in a pretty sorry state with respect to what accessors we provide cross
> > architectures (you have to pick between native endian with no barriers,
> > or little endian with barriers).
> 
> Scott, I am quite certain that I have received comments for other patches 
> that I have submitted earlier where I have been specifically been asked to do 
> things the way I am doing at the moment and not use readl/writel(because of 
> the reason you mentioned 
> above). 

Can you please use shorter lines? Something like a maximum lin leght
of 70 characters or so?  Thanks.

Well, this being a DaVinci driver, cross architectur poretability does
not really matter: this is ARM, and little-endian.

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 bad reputation UNIX has gotten is totally undeserved, laid on by
people who don't understand, who have not gotten in there  and  tried
anything."  -- Jim Joyce, owner of Jim Joyce's UNIX Bookstore
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support

[Wolfgang Denk]

Dear Scott Wood,

In message <20090818151213.gb26...@b07421-ec1.am.freescale.net> you wrote:
> On Tue, Aug 18, 2009 at 08:56:03AM -0500, Paulraj, Sandeep wrote:
> > > > +   case NAND_ECC_READSYN:
> > > > +   val = emif_regs->NAND4BITECC1;
> > > 
> > > Use I/O accessors.
> > I could not understand this one. It is done similarly 
> > nand_davinci_enable_hwecc which is used for 1 BIT ECC.
> > NANDFCR is a control register and we have to write the appropriate valvue 
> > to it.
> > We similarly write to other register that are part of the IP in other 
> > sections of this driver.
> 
> Well, the comment applies to the rest of the driver too.  I won't NACK
> because of it, but it's something to consider in the future.

Well, I will NAK it, then.

We should really write clean code these days.


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
Some people march to the beat of a different drummer. And some people
tango!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-ppc4xx/master

[Wolfgang Denk]

Dear Stefan Roese,

In message <200908181906.03021...@denx.de> you wrote:
> 
> > Umm... what about this patch:
> >
> > 07/30 Dirk Eibach  ppc4xx: Support PPC460EX rev B on gdsys CompactCenter
> 
> Not needed any more. It's been superseded by this patch which is already in 
> mainline:
> 
> ppc4xx: Remove check for PPC460EX from CompactCenter

thanks, one less patch to care about :-)

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
2000 pounds of chinese soup   = 1 Won Ton
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Tom]

Wolfgang Denk wrote:
> For some time there have been repeated reports about build problems
> with some ARM (cross) tool chains.  Especially issues about
> (in)compatibility with the tool chain provided runtime support
> library libgcc.a caused to add and support a private implementation
> of such runtime support code in U-Boot.  A closer look at the code
> indicated that some of these issues are actually home-made.  This
> patch attempts to clean up some of the most obvious problems and make
> building of U-Boot with different tool chains easier:
>
> - Even though all ARM systems basicy used the same compiler options
>   to select a specific ABI from the tool chain, the code for this was
>   distributed over all cpu/*/config.mk files.  We move this one level
>   up into lib_arm/config.mk instead.
>
> - So far, we only checked if "-mapcs-32" was supported by the tool
>   chain; if yes, this was used, if not, "-mabi=apcs-gnu" was
>   selected, no matter if the tool chain actually understood this
>   option.  There was no support for EABI conformant tool chains.
>   This patch implements the following logic:
>
>   1) If the tool chain supports
>   "-mabi=aapcs-linux -mno-thumb-interwork"
>  we use these options (EABI conformant tool chain).
>   2) Otherwise, we check first if
>   "-mapcs-32"
>  is supported, and then check for
>   "-mabi=apcs-gnu"
>  If one test succeeds, we use the first found option.
>   3) In case 2), we also test if "-mno-thumb-interwork", and use
>  this if the test succeeds. [For "-mabi=aapcs-linux" we set
>  "-mno-thumb-interwork" mandatorily.]
>
>   This way we use a similar logic for the compile options as the
>   Linux kenrel does.
>
> - Some EABI conformant tool chains cause external references to
>   utility functions like raise(); such functions are provided in the
>   new file lib_arm/eabi_compat.c
>
>   Note that lib_arm/config.mk gets parsed several times, so we must
>   make sure to add eabi_compat.o only once to the linker list.
>
> Signed-off-by: Wolfgang Denk 
> Cc: Jean-Christophe PLAGNIOL-VILLARD 
> Cc: Dirk Behme 
> Cc: Magnus Lilja 
> Cc: Tom Rix 
> Cc: Prafulla Wadaskar 
>
>   
MAKEALL arm with CodeSourcery's
arm-2008q3-72-arm-none-linux-gnueabi-i686-pc-linux-gnu
arm-2009q1-203-arm-none-linux-gnueabi-i686-pc-linux-gnu

and this patch differ from

USE_PRIVATE_LIBGCC=yes ./MAKEALL arm

only in these targets

actux1 actux2 actux3 actux4 ixdp425 ixdpg425 pdnb3 scpu trab

As already mentioned already by

http://lists.denx.de/pipermail/u-boot/2009-August/058838.html

Tested-by : Tom Rix 


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

Re: [U-Boot] [PATCH v2 1/2] tools: mkimage: Fixed build warnings

[Prafulla Wadaskar]

 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Tuesday, August 18, 2009 6:23 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATCH v2 1/2] tools: mkimage: Fixed 
> build warnings
> 
> Dear Prafulla,
> 
> In message <2009081813.73095833d...@gemini.denx.de> I wrote:
> > 
> > In message 
> <1250380700-15636-1-git-send-email-prafu...@marvell.com> you wrote:
> > > uninitialized retval variable warning fixed
> > > crc32 APIs moved to crc.h (newly added) and build warnings fixed
> > > some indentation tabs fixed
> > > 
> > > Signed-off-by: Prafulla Wadaskar 
> > > ---
> > > Change log:
> > > v2: updated as per review feedback for v1
> > > 
> > >  include/common.h |4 +---
> > >  include/u-boot/crc.h |   33 +
> > >  tools/mkimage.c  |   20 +++-
> > >  3 files changed, 45 insertions(+), 12 deletions(-)
> > >  create mode 100644 include/u-boot/crc.h
> > 
> > Applied to "mkimage" branch.
> > 
> > I decided to omit the tab cleanup, and used "uchar" instead of
> > "unsigned char" so no reformatting due to growing line length was
> > needed.  This way the changes are (IMHO) better visible.
> 
> ...what a stupid idea. I didn't consider that "uchar" might not be
> defined in standard compile environments. Undone.
> 
> I applied your original patch now, just with minimal indentation
> changes.
:-D Thanks
Regards..
Prafulla . .

> 
> Sorry for the confusion.
> 
> 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 usually tell my classes "if you are using @ and [] together in this
> class, you will almost certainly NOT get what you want. That's  going
> down  the wrong tunnel. There's no cheese at the end of that tunnel."
>  -- Randal L. Schwartz in <8czptuomey@gadget.cscaper.com>
> 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2] tools: mkimage: split code into core, default and FIT image specific

[Prafulla Wadaskar]

 

> -Original Message-
> From: Wolfgang Denk [mailto:w...@denx.de] 
> Sent: Tuesday, August 18, 2009 8:16 PM
> To: Prafulla Wadaskar
> Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATCH 2/2] tools: mkimage: split code 
> into core, default and FIT image specific
> 
> Dear Prafulla Wadaskar,
> 
> In message 
> <1250380700-15636-2-git-send-email-prafu...@marvell.com> you wrote:
> > This is first step towards cleaning mkimage code for kwbimage
> > support in clean way. Current mkimage code is very specific to
> > uimg generation whereas the same framework can be used to
> > generate other image types like Kirkwood boot image (kwbimage-TBD).
> > For this, the architecture of mkimage code need to modified.
> > 
> > Here is the brief plan for the same:-
> > a) Split mkimage code into core and image specific support
> > b) Implement callback function for image specific functions
> > c) Move image type specific code to respective c files
> >Currently there are two types of file generation/list
> >supported (i.e uimg, FIT), the code is abstracted from
> >mkimage.c/h and put in default_image.c and fit_image.c
> >all code in these file is static except init function call
> > d) mkimage_register API is added to add new image type support
> > All above is addressed in this patch
> > e) Add kwbimage type support to this new framework (TBD)
> > 
> > Signed-off-by: Prafulla Wadaskar 
> > ---
> >  tools/Makefile|9 +-
> >  tools/default_image.c |  149 ++
> >  tools/fit_image.c |  212 +++
> >  tools/mkimage.c   |  539 
> +++--
> >  tools/mkimage.h   |  101 +-
> >  5 files changed, 720 insertions(+), 290 deletions(-)
> >  create mode 100644 tools/default_image.c
> >  create mode 100644 tools/fit_image.c
> 
> I have only but a few minor comments (which I probably would clean up
> myself), but the problem is: the patch doesn't apply to the current
> "mkimage" branch:
Oh... I will repost it for mkimage branch
Thanks
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Magnus Lilja]

Wolfgang,

2009/8/17 Wolfgang Denk :
> Dear Magnus Lilja,
>
> In message <59b21cf20908171317s10d7fdb5t631c37f06707e...@mail.gmail.com> you 
> wrote:
>>
>> >   This way we use a similar logic for the compile options as the
>> >   Linux kenrel does.
>>
>> "kenrel" => "kernel" :-)
>
> Thanks, will try to remember to edit the commit message.
>
>> I've done compile time testing for the ARM11 boards using a gcc 4.1.2
>> toolchain that I often use and also Codesourcery's 2009-q1 (gcc 4.3.3)
>> (both with and without USE_PRIVATE_LIBGCC=yes), everything compiles
>> fine.
>>
>> I hope to be able to do some run-time testing of some i.MX31 U-boot
>> binaries later this week, so far I haven't tried them at all.
>
> Excellent., Thanks a lot. Can you please send an ACK or Tested-by,
> then?

Tested-by: Magnus Lilja 


Run-time tested on i.MX31 PDK board using the above toolchains.

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

Re: [U-Boot] Please pull u-boot-ppc4xx/master

[Stefan Roese]

Hi Wolfgang,

On Tuesday 18 August 2009 13:58:54 Wolfgang Denk wrote:
> > The following changes since commit
> > 7dedefdf749ff02c1086f7ddb8cb83a77b00d030: John Schmoller (1):
> > flash: Fix CFI buffer size bug
> >
> > are available in the git repository at:
> >
> >   git://www.denx.de/git/u-boot-ppc4xx.git master
> >
> > Stefan Roese (1):
> >   ppc4xx: Fix "chip_config" command for AMCC Arches
> >
> >  board/amcc/canyonlands/chip_config.c |   34
> > ++ include/configs/canyonlands.h|
> >4 
> >  2 files changed, 22 insertions(+), 16 deletions(-)
>
> Done, thanks.

Thanks.

> Umm... what about this patch:
>
> 07/30 Dirk Eibach  ppc4xx: Support PPC460EX rev B on gdsys CompactCenter

Not needed any more. It's been superseded by this patch which is already in 
mainline:

ppc4xx: Remove check for PPC460EX from CompactCenter

Cheers,
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] [PATCH v3] NAND: DaVinci:Adding 4 BIT ECC support

[s-paulraj]

From: Sandeep Paulraj 

This patch adds 4 BIT ECC support in the DaVinci NAND
driver. Tested on both the DM355 and DM365.

V3 version of the patch resolves compilation warnings pointed to by
Scott Wood. These compilation warnings occur when 4 BIT ECC support
is not enabled

Signed-off-by: Sandeep Paulraj 
---
For feature completeness this patch should be used along with
[PATCH v2] ARM: DaVinci DM355: Updating the DM355 EVM config
that i just sent to the mailing list
 drivers/mtd/nand/davinci_nand.c  |  283 +-
 include/asm-arm/arch-davinci/emif_defs.h |   10 +
 2 files changed, 291 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 7837a8e..eabaf3e 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -47,6 +47,16 @@
 #include 
 #include 
 
+/* Definitions for 4-bit hardware ECC */
+#define NAND_TIMEOUT   10240
+#define NAND_ECC_BUSY  0xC
+#define NAND_4BITECC_MASK  0x03FF03FF
+#define EMIF_NANDFSR_ECC_STATE_MASK0x0F00
+#define ECC_STATE_NO_ERR   0x0
+#define ECC_STATE_TOO_MANY_ERRS0x1
+#define ECC_STATE_ERR_CORR_COMP_P  0x2
+#define ECC_STATE_ERR_CORR_COMP_N  0x3
+
 static emif_registers *const emif_regs = (void *) 
DAVINCI_ASYNC_EMIF_CNTRL_BASE;
 
 static void nand_davinci_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int 
ctrl)
@@ -170,6 +180,267 @@ static int nand_davinci_correct_data(struct mtd_info 
*mtd, u_char *dat, u_char *
 }
 #endif /* CONFIG_SYS_NAND_HW_ECC */
 
+#ifdef CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+static struct nand_ecclayout nand_davinci_4bit_layout_oobfirst = {
+/*
+ * TI uses a different layout for 4K page deviecs. Since the
+ * eccpos filed can hold only a limited number of entries, adding
+ * support for 4K page will result in compilation warnings
+ * 4K Support will be added later
+ */
+#ifdef CONFIG_SYS_NAND_PAGE_2K
+   .eccbytes = 40,
+   .eccpos = {
+   24, 25, 26, 27, 28,
+   29, 30, 31, 32, 33, 34, 35, 36, 37, 38,
+   39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
+   49, 50, 51, 52, 53, 54, 55, 56, 57, 58,
+   59, 60, 61, 62, 63,
+   },
+   .oobfree = {
+   {.offset = 2, .length = 22, },
+   },
+#endif
+};
+
+static void nand_davinci_4bit_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+   u32 val;
+
+   switch (mode) {
+   case NAND_ECC_WRITE:
+   case NAND_ECC_READ:
+   /*
+* Start a new ECC calculation for reading or writing 512 bytes
+* of data.
+*/
+   val = (emif_regs->NANDFCR & ~(3 << 4)) | (1 << 12);
+   emif_regs->NANDFCR = val;
+   break;
+   case NAND_ECC_READSYN:
+   val = emif_regs->NAND4BITECC1;
+   break;
+   default:
+   break;
+   }
+}
+
+static u32 nand_davinci_4bit_readecc(struct mtd_info *mtd, unsigned int ecc[4])
+{
+   ecc[0] = emif_regs->NAND4BITECC1 & NAND_4BITECC_MASK;
+   ecc[1] = emif_regs->NAND4BITECC2 & NAND_4BITECC_MASK;
+   ecc[2] = emif_regs->NAND4BITECC3 & NAND_4BITECC_MASK;
+   ecc[3] = emif_regs->NAND4BITECC4 & NAND_4BITECC_MASK;
+
+   return 0;
+}
+
+static int nand_davinci_4bit_calculate_ecc(struct mtd_info *mtd,
+  const uint8_t *dat,
+  uint8_t *ecc_code)
+{
+   unsigned int hw_4ecc[4] = { 0, 0, 0, 0 };
+   unsigned int const1 = 0, const2 = 0;
+   unsigned char count1 = 0;
+
+   nand_davinci_4bit_readecc(mtd, hw_4ecc);
+
+   /*Convert 10 bit ecc value to 8 bit */
+   for (count1 = 0; count1 < 2; count1++) {
+   const2 = count1 * 5;
+   const1 = count1 * 2;
+
+   /* Take first 8 bits from val1 (count1=0) or val5 (count1=1) */
+   ecc_code[const2] = hw_4ecc[const1] & 0xFF;
+
+   /*
+* Take 2 bits as LSB bits from val1 (count1=0) or val5
+* (count1=1) and 6 bits from val2 (count1=0) or
+* val5 (count1=1)
+*/
+   ecc_code[const2 + 1] =
+   ((hw_4ecc[const1] >> 8) & 0x3) | ((hw_4ecc[const1] >> 14) &
+ 0xFC);
+
+   /*
+* Take 4 bits from val2 (count1=0) or val5 (count1=1) and
+* 4 bits from val3 (count1=0) or val6 (count1=1)
+*/
+   ecc_code[const2 + 2] =
+   ((hw_4ecc[const1] >> 22) & 0xF) |
+   ((hw_4ecc[const1 + 1] << 4) & 0xF0);
+
+   /*
+* Take 6 bits from val3(count1=0) or val6 (count1=1) and
+* 2 bits from val4 (count1=0) or  val7 (count1=1)
+*/
+   ecc_code[const2 + 3] =

[U-Boot] [PATCH v2] ARM: DaVinci DM355: Updating the DM355 EVM config

[s-paulraj]

From: Sandeep Paulraj 

This patch enables NAND support on the DM355 EVM.
Changes in this patch mostly relate to adding the NAND support.
This patch also defines a boot delay.

Signed-off-by: Sandeep Paulraj 
---
 include/configs/davinci_dm355evm.h |   22 +-
 1 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/include/configs/davinci_dm355evm.h 
b/include/configs/davinci_dm355evm.h
index c35f5c9..d8fd9b7 100644
--- a/include/configs/davinci_dm355evm.h
+++ b/include/configs/davinci_dm355evm.h
@@ -66,9 +66,10 @@
 #define CONFIG_SYS_I2C_SLAVE   0x10/* SMBus host address */
 
 /* NAND: socketed, two chipselects, normally 2 GBytes */
-/* NYET -- #define CONFIG_NAND_DAVINCI */
-#define CONFIG_SYS_NAND_HW_ECC
+#define CONFIG_NAND_DAVINCI
 #define CONFIG_SYS_NAND_USE_FLASH_BBT
+#define CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+#define CONFIG_SYS_NAND_PAGE_2K
 
 #define CONFIG_SYS_NAND_LARGEPAGE
 #define CONFIG_SYS_NAND_BASE_LIST  { 0x0200, }
@@ -92,19 +93,17 @@
 #define CONFIG_CMD_I2C
 #define CONFIG_CMD_PING
 #define CONFIG_CMD_SAVES
+#define CONFIG_CMD_SAVEENV
 
 #ifdef CONFIG_NAND_DAVINCI
 #define CONFIG_CMD_MTDPARTS
 #define CONFIG_MTD_PARTITIONS
+#define CONFIG_MTD_DEVICE
 #define CONFIG_CMD_NAND
 #define CONFIG_CMD_UBI
 #define CONFIG_RBTREE
 #endif
 
-/* TEMPORARY -- no safe place to save env, yet */
-#define CONFIG_ENV_IS_NOWHERE
-#undef CONFIG_CMD_SAVEENV
-
 #ifdef CONFIG_USB_DAVINCI
 #define CONFIG_MUSB_HCD
 #define CONFIG_CMD_USB
@@ -130,9 +129,14 @@
 #define CONFIG_SYS_PROMPT_HUSH_PS2 "> "
 #define CONFIG_SYS_LONGHELP
 
-#define CONFIG_ENV_SIZESZ_16K
+#ifdef CONFIG_NAND_DAVINCI
+#define CONFIG_ENV_SIZESZ_256K
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_OFFSET  0x3C
+#undef CONFIG_ENV_IS_IN_FLASH
+#endif
 
-/* NYET -- #define CONFIG_BOOTDELAY5 */
+#define CONFIG_BOOTDELAY   3
 #define CONFIG_BOOTCOMMAND \
"dhcp;bootm"
 #define CONFIG_BOOTARGS \
@@ -147,7 +151,7 @@
 
 /* U-Boot memory configuration */
 #define CONFIG_STACKSIZE   SZ_256K /* regular stack */
-#define CONFIG_SYS_MALLOC_LEN  SZ_512K /* malloc() arena */
+#define CONFIG_SYS_MALLOC_LEN  SZ_1M   /* malloc() arena */
 #define CONFIG_SYS_GBL_DATA_SIZE   128 /* for initial data */
 #define CONFIG_SYS_MEMTEST_START   0x8700  /* physical address */
 #define CONFIG_SYS_MEMTEST_END 0x8800  /* test 16MB RAM */
-- 
1.6.0.4

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

Re: [U-Boot] Where can I find some material about Xenomai/SOLO's usage and limit?

[Gao Ya'nan]

Sorry, I forgot it. And thanks for your tips.

2009/8/18 Wolfgang Denk :
> Dear "Gao Ya'nan",
>
> In message  you 
> wrote:
>>  And is there any successful stories about Xenomai/SOLO?
>
> This is the U-Bootmailing list - you are off topic here.
>
> Please ask on the xenomai-h...@gna.org list, instead.
>
> Also you may consider coming to the Xenomai User Meeting in September,
> see http://www.denx.de/en/News/XenomaiUserMeeting2009
>
> 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
> Nothing is easier than to denounce  the  evildoer;  nothing  is  more
> difficult than to understand him.                 - Fyodor Dostoevski
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] NAND: DaVinci: V2 Adding 4 BIT ECC support

[Scott Wood]

On Tue, Aug 18, 2009 at 10:10:42AM -0400, s-paul...@ti.com wrote:
> From: Sandeep Paulraj 
> 
> This patch adds 4 BIT ECC support in the DaVinci NAND
> driver. Tested on both the DM355 and DM365.
> 
> 
> Signed-off-by: Sandeep Paulraj 

When I build with this patch, but without 4 bit enabled, I get this:

davinci_nand.c: In function ‘nand_davinci_4bit_correct_data’:
davinci_nand.c:292: warning: unused variable ‘this’
davinci_nand.c: At top level:
davinci_nand.c:208: warning: ‘nand_davinci_4bit_enable_hwecc’ defined but
not used
davinci_nand.c:242: warning: ‘nand_davinci_4bit_calculate_ecc’ defined
but not used
davinci_nand.c:291: warning: ‘nand_davinci_4bit_correct_data’ defined but
not used

We should only build the 4bit code when the board config has asked for
it.

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

Re: [U-Boot] [PATCH 2/2] MTD:NAND: ADD new ECC mode NAND_ECC_HW_OOB_FIRST

[Scott Wood]

On Mon, Aug 10, 2009 at 01:27:56PM -0400, s-paul...@dal.design.ti.com wrote:
> From: Sandeep Paulraj 
> 
> This patch adds the new mode NAND_ECC_HW_OOB_FIRST in the nand code to
> support 4-bit ECC on TI DaVinci devices with large page (up to 2K) NAND
> chips.  This ECC mode is similar to NAND_ECC_HW, with the exception of
> read_page API that first reads the OOB area, reads the data in chunks,
> feeds the ECC from OOB area to the ECC hw engine and perform any
> correction on the data as per the ECC status reported by the engine.
> 
> This patch has been accepted by Andrew Morton and can be found at
> 
> http://userweb.kernel.org/~akpm/mmotm/broken-out/mtd-nand-add-new-ecc-mode-ecc_hw_oob_first.patch
> 
> Signed-off-by: Sandeep Paulraj 
> Signed-off-by: Sneha Narnakaje 

Applied to u-boot-nand-flash/next.

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

[U-Boot] Pull request: nand flash

[Scott Wood]

The following fixes since commit 2bcbd429f44e32ead38a33f372e4c027e66710f9:
  Wolfgang Denk (1):
Merge branch 'master' of git://git.denx.de/u-boot-mpc85xx

are available in the git repository at:

  git://git.denx.de/u-boot-nand-flash.git master

Giulio Benetti (1):
  add WATCHDOG_RESET() on nand write and read

Mingkai Hu (1):
  NAND boot: fix nand_load overlap issue

 drivers/mtd/nand/nand_util.c  |4 
 nand_spl/nand_boot_fsl_elbc.c |2 +-
 2 files changed, 5 insertions(+), 1 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support

[Scott Wood]

Paulraj, Sandeep wrote:
> And please correct me if I am wrong, but J-C can't actually pull these 
> patches into his next branch correct?

Right, not yet.

> That is because it will require 2 of the NAND patches that I sent a week ago.
> 
> Thus you might have to accept the DM355 EVM config update patch as well which 
> actually enables the NAND support.

I could do that with an ACK from JC if it does not depend on anything in 
his tree -- or I could send Wolfgang a -next pull request and then JC 
could sync with that.

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

Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support

[Scott Wood]

Paulraj, Sandeep wrote:
>> What I mean is using accessors such as readl/writel -- though we're still
>> in a pretty sorry state with respect to what accessors we provide cross
>> architectures (you have to pick between native endian with no barriers,
>> or little endian with barriers).
> 
> Scott, I am quite certain that I have received comments for other
> patches that I have submitted earlier where I have been specifically
> been asked to do things the way I am doing at the moment and not use
> readl/writel(because of the reason you mentioned above).

OK, I didn't see those comments.

> So should I assume that my updated patch has your ACK as you mentioned above 
> that you want NACK it

It looks OK.

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

Re: [U-Boot] [PATCH] ARM: DaVinci: DaVinci DM365 SOC specific code

[Paulraj, Sandeep]

John,

Yesterday night after J-C mentioned that he applied 2 of my patches to 
u-boot-arm next I tried to checkout that branch
 to add some more stuff on top of my Dm365 patches.

I could not see it either. But I have used that branch in the recent past. I 
don't know what is wrong.

Thanks,
Sandeep


From: John Rigby [mailto:jcri...@gmail.com]
Sent: Tuesday, August 18, 2009 11:21 AM
To: Jean-Christophe PLAGNIOL-VILLARD
Cc: Paulraj, Sandeep; u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH] ARM: DaVinci: DaVinci DM365 SOC specific code

I don't see a next branch in u-boot-arm.  Am I missing something?

Thanks
John
On Mon, Aug 17, 2009 at 4:01 PM, Jean-Christophe PLAGNIOL-VILLARD 
mailto:plagn...@jcrosoft.com>> wrote:
On 11:20 Sat 15 Aug , s-paul...@ti.com wrote:
> From: Sandeep Paulraj mailto:s-paul...@ti.com>>
>
> This patch adds support for DaVinci DM365 SOC.
>
> Signed-off-by: Sandeep Paulraj mailto:s-paul...@ti.com>>
> ---
>  cpu/arm926ejs/davinci/Makefile |1 +
>  cpu/arm926ejs/davinci/dm365.c  |   35 +++
>  2 files changed, 36 insertions(+), 0 deletions(-)
>  create mode 100644 cpu/arm926ejs/davinci/dm365.c
apply to u-boot-arm next

Best Regards,
J.
___
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] NAND: DaVinci: Adding 4 BIT ECC support

[Paulraj, Sandeep]

> -Original Message-
> From: Scott Wood [mailto:scottw...@freescale.com]
> Sent: Tuesday, August 18, 2009 11:12 AM
> To: Paulraj, Sandeep
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support
> 
> On Tue, Aug 18, 2009 at 08:56:03AM -0500, Paulraj, Sandeep wrote:
> > > > +   case NAND_ECC_READSYN:
> > > > +   val = emif_regs->NAND4BITECC1;
> > >
> > > Use I/O accessors.
> > I could not understand this one. It is done similarly
> nand_davinci_enable_hwecc which is used for 1 BIT ECC.
> > NANDFCR is a control register and we have to write the appropriate
> valvue to it.
> > We similarly write to other register that are part of the IP in other
> sections of this driver.
> 
> Well, the comment applies to the rest of the driver too.  I won't NACK
> because of it, but it's something to consider in the future.
> 
> > I'll send in a patch with your comments addressed except the first one.
> I can resend the patch( again if required) once I know what you mean by
> your comment #1.
> 
> What I mean is using accessors such as readl/writel -- though we're still
> in a pretty sorry state with respect to what accessors we provide cross
> architectures (you have to pick between native endian with no barriers,
> or little endian with barriers).

Scott, I am quite certain that I have received comments for other patches that 
I have submitted earlier where I have been specifically been asked to do things 
the way I am doing at the moment and not use readl/writel(because of the reason 
you mentioned above). 
> 
> -Scott

So should I assume that my updated patch has your ACK as you mentioned above 
that you want NACK it

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

Re: [U-Boot] [PATCH] ARM: DaVinci: DaVinci DM365 SOC specific code

[John Rigby]

I don't see a next branch in u-boot-arm.  Am I missing something?

Thanks
John

On Mon, Aug 17, 2009 at 4:01 PM, Jean-Christophe PLAGNIOL-VILLARD <
plagn...@jcrosoft.com> wrote:

> On 11:20 Sat 15 Aug , s-paul...@ti.com wrote:
> > From: Sandeep Paulraj 
> >
> > This patch adds support for DaVinci DM365 SOC.
> >
> > Signed-off-by: Sandeep Paulraj 
> > ---
> >  cpu/arm926ejs/davinci/Makefile |1 +
> >  cpu/arm926ejs/davinci/dm365.c  |   35
> +++
> >  2 files changed, 36 insertions(+), 0 deletions(-)
> >  create mode 100644 cpu/arm926ejs/davinci/dm365.c
> apply to u-boot-arm next
>
> Best Regards,
> J.
> ___
> 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] NAND: DaVinci: Adding 4 BIT ECC support

[Scott Wood]

On Tue, Aug 18, 2009 at 08:56:03AM -0500, Paulraj, Sandeep wrote:
> > > + case NAND_ECC_READSYN:
> > > + val = emif_regs->NAND4BITECC1;
> > 
> > Use I/O accessors.
> I could not understand this one. It is done similarly 
> nand_davinci_enable_hwecc which is used for 1 BIT ECC.
> NANDFCR is a control register and we have to write the appropriate valvue to 
> it.
> We similarly write to other register that are part of the IP in other 
> sections of this driver.

Well, the comment applies to the rest of the driver too.  I won't NACK
because of it, but it's something to consider in the future.

> I'll send in a patch with your comments addressed except the first one. I can 
> resend the patch( again if required) once I know what you mean by your 
> comment #1.

What I mean is using accessors such as readl/writel -- though we're still
in a pretty sorry state with respect to what accessors we provide cross
architectures (you have to pick between native endian with no barriers,
or little endian with barriers).

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

Re: [U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets

[Kumar Gala]

On Aug 18, 2009, at 2:37 AM, Mingkai Hu wrote:

> To simplify the top level makefile it useful to be able to paree
> the top level makefile target to multiple individual target, then
> put them to the config.h and config.mk, leave the board config file
> and board makefile to handle the different targets.
> ---
> mkconfig |   11 +++
> 1 files changed, 11 insertions(+), 0 deletions(-)

I know you are swamped w/ARM.. but if we can make some progress on  
this one change it would be useful for 'next'.

thanks

- k

>
> diff --git a/mkconfig b/mkconfig
> index b0bbbd1..d9e216d 100755
> --- a/mkconfig
> +++ b/mkconfig
> @@ -10,12 +10,14 @@
>
> APPEND=no # Default: Create new config file
> BOARD_NAME="" # Name to print in make output
> +TARGETS=""
>
> while [ $# -gt 0 ] ; do
>   case "$1" in
>   --) shift ; break ;;
>   -a) shift ; APPEND=yes ;;
>   -n) shift ; BOARD_NAME="${1%%_config}" ; shift ;;
> + -t) shift ; TARGETS="`echo $1 | sed 's:_: :g'` ${TARGETS}" ;  
> shift ;;
>   *)  break ;;
>   esac
> done
> @@ -72,6 +74,10 @@ echo "BOARD  = $4" >> config.mk
>
> [ "$6" ] && [ "$6" != "NULL" ] && echo "SOC= $6" >> config.mk
>
> +for i in ${TARGETS} ; do
> + echo "CONFIG_OPT_${i} = y" >> config.mk ;
> +done
> +
> #
> # Create board specific header file
> #
> @@ -82,6 +88,11 @@ else
>   > config.h  # Create new config file
> fi
> echo "/* Automatically generated - do not edit */" >>config.h
> +
> +for i in ${TARGETS} ; do
> + echo "#define CONFIG_OPT_${i} 1" >>config.h ;
> +done
> +
> echo "#include " >>config.h
> echo "#include " >>config.h
>
> -- 
> 1.5.4

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

Re: [U-Boot] [PATCH 2/2] tools: mkimage: split code into core, default and FIT image specific

[Wolfgang Denk]

Dear Prafulla Wadaskar,

In message <1250380700-15636-2-git-send-email-prafu...@marvell.com> you wrote:
> This is first step towards cleaning mkimage code for kwbimage
> support in clean way. Current mkimage code is very specific to
> uimg generation whereas the same framework can be used to
> generate other image types like Kirkwood boot image (kwbimage-TBD).
> For this, the architecture of mkimage code need to modified.
> 
> Here is the brief plan for the same:-
> a) Split mkimage code into core and image specific support
> b) Implement callback function for image specific functions
> c) Move image type specific code to respective c files
>Currently there are two types of file generation/list
>supported (i.e uimg, FIT), the code is abstracted from
>mkimage.c/h and put in default_image.c and fit_image.c
>all code in these file is static except init function call
> d) mkimage_register API is added to add new image type support
> All above is addressed in this patch
> e) Add kwbimage type support to this new framework (TBD)
> 
> Signed-off-by: Prafulla Wadaskar 
> ---
>  tools/Makefile|9 +-
>  tools/default_image.c |  149 ++
>  tools/fit_image.c |  212 +++
>  tools/mkimage.c   |  539 
> +++--
>  tools/mkimage.h   |  101 +-
>  5 files changed, 720 insertions(+), 290 deletions(-)
>  create mode 100644 tools/default_image.c
>  create mode 100644 tools/fit_image.c

I have only but a few minor comments (which I probably would clean up
myself), but the problem is: the patch doesn't apply to the current
"mkimage" branch:

Applying: tools: mkimage: split code into core, default and FIT image
specific
error: patch failed: tools/mkimage.c:152
error: tools/mkimage.c: patch does not apply
fatal: sha1 information is lacking or useless (tools/Makefile).
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0002.


Could you please reebase and resubmit? Thanks in advance (I like how
you implemented this now!)

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Der Horizont vieler Menschen ist ein Kreis mit Radius Null --
und das nennen sie ihren Standpunkt.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Regarding 8641D u-boot

[Kumar Gala]

On Aug 18, 2009, at 5:12 AM, Thirumalai wrote:

> Hi kumar,
>   The CONFIG_PHYS_64BIT was not defined on the header file  
> of HPCN but extended address translation was enabled on the start.S  
> irrespective of the  MPC8641D_hpcn compilation option why?.
>
> Regards,
> T.

Are you running into an issue with this?  It could be to allow an OS  
to have 36-bit addressing w/o u-boot having to deal with it.


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

[U-Boot] [PATCH v2] NAND: DaVinci: V2 Adding 4 BIT ECC support

[s-paulraj]

From: Sandeep Paulraj 

This patch adds 4 BIT ECC support in the DaVinci NAND
driver. Tested on both the DM355 and DM365.


Signed-off-by: Sandeep Paulraj 
---
I had earlier sent another patch along with this patch to add 4 BIT ECC support
[PATCH] ARM: DaVinci DM355: Updating the DM355 EVM config
The above patch has not changed
 drivers/mtd/nand/davinci_nand.c  |  284 +-
 include/asm-arm/arch-davinci/emif_defs.h |   10 +
 2 files changed, 292 insertions(+), 2 deletions(-)

diff --git a/drivers/mtd/nand/davinci_nand.c b/drivers/mtd/nand/davinci_nand.c
index 7837a8e..37d8b73 100644
--- a/drivers/mtd/nand/davinci_nand.c
+++ b/drivers/mtd/nand/davinci_nand.c
@@ -47,6 +47,16 @@
 #include 
 #include 
 
+/* Definitions for 4-bit hardware ECC */
+#define NAND_TIMEOUT   10240
+#define NAND_ECC_BUSY  0xC
+#define NAND_4BITECC_MASK  0x03FF03FF
+#define EMIF_NANDFSR_ECC_STATE_MASK0x0F00
+#define ECC_STATE_NO_ERR   0x0
+#define ECC_STATE_TOO_MANY_ERRS0x1
+#define ECC_STATE_ERR_CORR_COMP_P  0x2
+#define ECC_STATE_ERR_CORR_COMP_N  0x3
+
 static emif_registers *const emif_regs = (void *) 
DAVINCI_ASYNC_EMIF_CNTRL_BASE;
 
 static void nand_davinci_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int 
ctrl)
@@ -170,6 +180,268 @@ static int nand_davinci_correct_data(struct mtd_info 
*mtd, u_char *dat, u_char *
 }
 #endif /* CONFIG_SYS_NAND_HW_ECC */
 
+#ifdef CONFIG_SYS_NAND_4BIT_HW_ECC_OOBFIRST
+static struct nand_ecclayout nand_davinci_4bit_layout_oobfirst = {
+/*
+ * TI uses a different layout for 4K page deviecs. Since the
+ * eccpos filed can hold only a limited number of entries, adding
+ * support for 4K page will result in compilation warnings
+ * 4K Support will be added later
+ */
+#ifdef CONFIG_SYS_NAND_PAGE_2K
+   .eccbytes = 40,
+   .eccpos = {
+   24, 25, 26, 27, 28,
+   29, 30, 31, 32, 33, 34, 35, 36, 37, 38,
+   39, 40, 41, 42, 43, 44, 45, 46, 47, 48,
+   49, 50, 51, 52, 53, 54, 55, 56, 57, 58,
+   59, 60, 61, 62, 63,
+   },
+   .oobfree = {
+   {.offset = 2, .length = 22, },
+   },
+#endif
+};
+#endif
+
+static void nand_davinci_4bit_enable_hwecc(struct mtd_info *mtd, int mode)
+{
+   u32 val;
+
+   switch (mode) {
+   case NAND_ECC_WRITE:
+   case NAND_ECC_READ:
+   /*
+* Start a new ECC calculation for reading or writing 512 bytes
+* of data.
+*/
+   val = (emif_regs->NANDFCR & ~(3 << 4)) | (1 << 12);
+   emif_regs->NANDFCR = val;
+   break;
+   case NAND_ECC_READSYN:
+   val = emif_regs->NAND4BITECC1;
+   break;
+   default:
+   break;
+   }
+}
+
+static u32 nand_davinci_4bit_readecc(struct mtd_info *mtd, unsigned int ecc[4])
+{
+   ecc[0] = emif_regs->NAND4BITECC1 & NAND_4BITECC_MASK;
+   ecc[1] = emif_regs->NAND4BITECC2 & NAND_4BITECC_MASK;
+   ecc[2] = emif_regs->NAND4BITECC3 & NAND_4BITECC_MASK;
+   ecc[3] = emif_regs->NAND4BITECC4 & NAND_4BITECC_MASK;
+
+   return 0;
+}
+
+static int nand_davinci_4bit_calculate_ecc(struct mtd_info *mtd,
+  const uint8_t *dat,
+  uint8_t *ecc_code)
+{
+   unsigned int hw_4ecc[4] = { 0, 0, 0, 0 };
+   unsigned int const1 = 0, const2 = 0;
+   unsigned char count1 = 0;
+
+   nand_davinci_4bit_readecc(mtd, hw_4ecc);
+
+   /*Convert 10 bit ecc value to 8 bit */
+   for (count1 = 0; count1 < 2; count1++) {
+   const2 = count1 * 5;
+   const1 = count1 * 2;
+
+   /* Take first 8 bits from val1 (count1=0) or val5 (count1=1) */
+   ecc_code[const2] = hw_4ecc[const1] & 0xFF;
+
+   /*
+* Take 2 bits as LSB bits from val1 (count1=0) or val5
+* (count1=1) and 6 bits from val2 (count1=0) or
+* val5 (count1=1)
+*/
+   ecc_code[const2 + 1] =
+   ((hw_4ecc[const1] >> 8) & 0x3) | ((hw_4ecc[const1] >> 14) &
+ 0xFC);
+
+   /*
+* Take 4 bits from val2 (count1=0) or val5 (count1=1) and
+* 4 bits from val3 (count1=0) or val6 (count1=1)
+*/
+   ecc_code[const2 + 2] =
+   ((hw_4ecc[const1] >> 22) & 0xF) |
+   ((hw_4ecc[const1 + 1] << 4) & 0xF0);
+
+   /*
+* Take 6 bits from val3(count1=0) or val6 (count1=1) and
+* 2 bits from val4 (count1=0) or  val7 (count1=1)
+*/
+   ecc_code[const2 + 3] =
+   ((hw_4ecc[const1 + 1] >> 4) & 0x3F) |
+   ((hw_4ecc[const1 + 1] >> 10) & 0xC0);
+
+ 

Re: [U-Boot] [PATCH] NAND: DaVinci: Adding 4 BIT ECC support

[Paulraj, Sandeep]

> > +static void nand_davinci_4bit_enable_hwecc(struct mtd_info *mtd, int
> mode)
> > +{
> > +   u32 val;
> > +
> > +   switch (mode) {
> > +   case NAND_ECC_WRITE:
> > +   case NAND_ECC_READ:
> > +   /*
> > +* Start a new ECC calculation for reading or writing 512
> bytes
> > +* of data.
> > +*/
> > +   val = (emif_regs->NANDFCR & ~(3 << 4)) | (1 << 12);
> > +   emif_regs->NANDFCR = val;
> > +   break;
> > +   case NAND_ECC_READSYN:
> > +   val = emif_regs->NAND4BITECC1;
> 
> Use I/O accessors.
I could not understand this one. It is done similarly nand_davinci_enable_hwecc 
which is used for 1 BIT ECC.
NANDFCR is a control register and we have to write the appropriate valvue to it.
We similarly write to other register that are part of the IP in other sections 
of this driver.

> 
> > +   for (i = 0; i < 100; i++)
> > +   udelay(this->chip_delay);
> 
> No explanation for the delay?  Is there any status register you can poll?
> 
> Is it truly 100 times the chip delay (even if that changes), or is it a
> fixed delay that just happens to work out to that?
remnant of an old version of the driver which had bugs. I have got rid of this
> 
> > +static int nand_davinci_4bit_correct_data(struct mtd_info *mtd, uint8_t
> *dat,
> > + uint8_t *read_ecc, uint8_t *calc_ecc)
> > +{
> > +   return nand_davinci_4bit_compare_ecc(mtd, read_ecc, dat);
> > +}
> 
> Why have a wrapper?  This seems to be the only place where compare_ecc is
> used.
Yes its of no use, I'll remove it.
> 
> -Scott
I'll send in a patch with your comments addressed except the first one. I can 
resend the patch( again if required) once I know what you mean by your comment 
#1.

Thanks,
Sandeep

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

[U-Boot] Porting to Broadcom BCM7038 (Hermes board)

[Peter Belm]

I posted a message before about this, but I didn't really give it the most
descriptive subject (I went off to find the chip model and then forgot to
add it to the subject, doh!)

Basically I'm trying to port uboot to the Broadcom BCM7038 chip, the current
bootloader I have is specific to the board (Hermes), and loads the kernel
from flash. I'd rather use uboot to start the SATA HDD and load the Linux
kernel from there. I have the source code for the bootloader and all the
Linux drivers, as well as documentation on the processor, but I'm not very
good at low level code.

As far as I can see I need to create a cpu/bcm7038 directory, add the
start.S from the original bootloader, and modify it to work with uboot (this
is the part I'm really not sure on!). Then add a board/hermes directory with
the rest of the original bootloader init code, and modify that to include
the SATA drivers, bring up the SATA interface, then load the kernel. But
theory is far from practice, and I'm already having trouble.

Would someone be able to assist me in porting to this cpu/board?

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

[U-Boot] 83xx and LCRR setting

[Heiko Schocher]

Hello Kim,

I actually work on an u-boot mpc8321 port (mostly identical with the kmeter1
port already in mainline), and I have to set the LCRR (Clock Ratio Register
Reference Manual 10.3.1.14). As I see in

cpu/mpc83xx/cpu_init.c cpu_init_f()

this is done while running from flash. Hmm... the Reference manual
says in chapter 10.3.1.14 page 474:

NOTE
For proper operation of the system, this register setting must not be altered
while local bus memories or devices are being accessed. Special care needs
to be taken when running instructions from an local bus controller memory.

Hmm...

On my board (and for example on the MPC832XEMDS) the flash is connected
to the localbus ... and this register setting is done, while
running from flash ... Hmm.. is this safe?

I only can set the LCRR register succesfully on my board port, if
I set the LCRR_DBYP bit in the CONFIG_SYS_LCRR define, without it
I couldn;t run u-boot (with it, it works fine)

Unfortunately this LCRR_DBYP bit (0x8000) is not documented in
the MPC8323ERM ... there, it is just marked as reserved (and set
to 1 on reset)

So, it is ok, just to set this LCRR_DBYP bit? Or should the LCRR
register only changed, if u-boot runs from ram? Or ...?

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 v2 1/2] tools: mkimage: Fixed build warnings

[Wolfgang Denk]

Dear Prafulla,

In message <2009081813.73095833d...@gemini.denx.de> I wrote:
> 
> In message <1250380700-15636-1-git-send-email-prafu...@marvell.com> you wrote:
> > uninitialized retval variable warning fixed
> > crc32 APIs moved to crc.h (newly added) and build warnings fixed
> > some indentation tabs fixed
> > 
> > Signed-off-by: Prafulla Wadaskar 
> > ---
> > Change log:
> > v2: updated as per review feedback for v1
> > 
> >  include/common.h |4 +---
> >  include/u-boot/crc.h |   33 +
> >  tools/mkimage.c  |   20 +++-
> >  3 files changed, 45 insertions(+), 12 deletions(-)
> >  create mode 100644 include/u-boot/crc.h
> 
> Applied to "mkimage" branch.
> 
> I decided to omit the tab cleanup, and used "uchar" instead of
> "unsigned char" so no reformatting due to growing line length was
> needed.  This way the changes are (IMHO) better visible.

...what a stupid idea. I didn't consider that "uchar" might not be
defined in standard compile environments. Undone.

I applied your original patch now, just with minimal indentation
changes.

Sorry for the confusion.

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 usually tell my classes "if you are using @ and [] together in this
class, you will almost certainly NOT get what you want. That's  going
down  the wrong tunnel. There's no cheese at the end of that tunnel."
 -- Randal L. Schwartz in <8czptuomey@gadget.cscaper.com>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/2] tools: mkimage: Fixed build warnings

[Wolfgang Denk]

Dear Prafulla Wadaskar,

In message <1250380700-15636-1-git-send-email-prafu...@marvell.com> you wrote:
> uninitialized retval variable warning fixed
> crc32 APIs moved to crc.h (newly added) and build warnings fixed
> some indentation tabs fixed
> 
> Signed-off-by: Prafulla Wadaskar 
> ---
> Change log:
> v2: updated as per review feedback for v1
> 
>  include/common.h |4 +---
>  include/u-boot/crc.h |   33 +
>  tools/mkimage.c  |   20 +++-
>  3 files changed, 45 insertions(+), 12 deletions(-)
>  create mode 100644 include/u-boot/crc.h

Applied to "mkimage" branch.

I decided to omit the tab cleanup, and used "uchar" instead of
"unsigned char" so no reformatting due to growing line length was
needed.  This way the changes are (IMHO) better visible.

Hope this is OK with you.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Build a system that even a fool can use and only a fool will want  to
use it.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Please pull u-boot-ppc4xx/master

[Wolfgang Denk]

Dear Stefan Roese,

In message <200908180923.10022...@denx.de> you wrote:
> Hi Wolfgang,
> 
> please pull the following bug fix:
> 
> Thanks,
> Stefan
> 
> 
> The following changes since commit 7dedefdf749ff02c1086f7ddb8cb83a77b00d030:
>   John Schmoller (1):
> flash: Fix CFI buffer size bug
> 
> are available in the git repository at:
> 
>   git://www.denx.de/git/u-boot-ppc4xx.git master
> 
> Stefan Roese (1):
>   ppc4xx: Fix "chip_config" command for AMCC Arches
> 
>  board/amcc/canyonlands/chip_config.c |   34 
> ++
>  include/configs/canyonlands.h|4 
>  2 files changed, 22 insertions(+), 16 deletions(-)

Done, thanks.


Umm... what about this patch:

07/30 Dirk Eibach  ppc4xx: Support PPC460EX rev B on gdsys CompactCenter

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
It would seem that evil retreats when forcibly confronted
-- Yarnek of Excalbia, "The Savage Curtain", stardate 5906.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Wolfgang Denk]

Dear Kumar Gala,

In message  you wrote:
> This fixes an issue that cropped in v2009.08-rc testing.
> 
> The following changes since commit 7dedefdf749ff02c1086f7ddb8cb83a77b00d030:
>   John Schmoller (1):
> flash: Fix CFI buffer size bug
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-mpc85xx.git master
> 
> Kumar Gala (1):
>   85xx: Fix addrmap to include memory
> 
>  cpu/mpc85xx/tlb.c |   28 ++--
>  1 files changed, 22 insertions(+), 6 deletions(-)

Done, 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
"Out of register space (ugh)"
- vi
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] ARM Pull Request

[Wolfgang Denk]

Dear Jean-Christophe PLAGNIOL-VILLARD,

In message <20090817234931.ge4...@game.jcrosoft.org> you wrote:
> Hi,
> 
> please pull
> The following changes since commit 7dedefdf749ff02c1086f7ddb8cb83a77b00d030:
>   John Schmoller (1):
> flash: Fix CFI buffer size bug
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arm.git master
> 
> Albin Tonnerre (1):
>   Update the mtd driver name in bootargs for at91-based boards
> 
> Ben Goska (1):
>   omap3: Fixed a problem with hwecc

There was an "Acked-by: Dirk Behme "
Why did you not include this?

> Wolfgang Denk (1):
>   Monahans: avoid floating point calculations

Thanks.

What about the other ARM related patches?

We are very close to the scheduled release date, and it would
definitely be a good thing to allow for a few days of testing.

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
Question: How does one get fresh air into a Russian church?
Answer:   One clicks on an icon, and a window opens!
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Gaye Abdoulaye Walsimou]

Wolfgang Denk wrote:
> For some time there have been repeated reports about build problems
> with some ARM (cross) tool chains.  Especially issues about
> (in)compatibility with the tool chain provided runtime support
> library libgcc.a caused to add and support a private implementation
> of such runtime support code in U-Boot.  A closer look at the code
> indicated that some of these issues are actually home-made.  This
> patch attempts to clean up some of the most obvious problems and make
> building of U-Boot with different tool chains easier:
>
> - Even though all ARM systems basicy used the same compiler options
>   to select a specific ABI from the tool chain, the code for this was
>   distributed over all cpu/*/config.mk files.  We move this one level
>   up into lib_arm/config.mk instead.
>
> - So far, we only checked if "-mapcs-32" was supported by the tool
>   chain; if yes, this was used, if not, "-mabi=apcs-gnu" was
>   selected, no matter if the tool chain actually understood this
>   option.  There was no support for EABI conformant tool chains.
>   This patch implements the following logic:
>
>   1) If the tool chain supports
>   "-mabi=aapcs-linux -mno-thumb-interwork"
>  we use these options (EABI conformant tool chain).
>   2) Otherwise, we check first if
>   "-mapcs-32"
>  is supported, and then check for
>   "-mabi=apcs-gnu"
>  If one test succeeds, we use the first found option.
>   3) In case 2), we also test if "-mno-thumb-interwork", and use
>  this if the test succeeds. [For "-mabi=aapcs-linux" we set
>  "-mno-thumb-interwork" mandatorily.]
>
>   This way we use a similar logic for the compile options as the
>   Linux kenrel does.
>
> - Some EABI conformant tool chains cause external references to
>   utility functions like raise(); such functions are provided in the
>   new file lib_arm/eabi_compat.c
>
>   Note that lib_arm/config.mk gets parsed several times, so we must
>   make sure to add eabi_compat.o only once to the linker list.
>
> Signed-off-by: Wolfgang Denk 
> Cc: Jean-Christophe PLAGNIOL-VILLARD 
> Cc: Dirk Behme 
> Cc: Magnus Lilja 
> Cc: Tom Rix 
> Cc: Prafulla Wadaskar 
> ---
>
> I have run a full "MAKEALL arm" for ELDK releases 3.1 (gcc 3.3.3),
> 3.1.1 (gcc 3.3.3), 4.1 (gcc 4.0.0) and 4.2 (gcc 4.2.2, both as "arm"
> [softfloat] and "armVFP" [VFP hardfloat]), and all of these both with
> USE_PRIVATE_LIBGCC=yes (i. e. using U-Boot internal libgcc
> replacement code) and without (i. e. using the tool chain provided
> standard libgcc instead).
>
> The ELDK fails to build the big-endian IXP boards, but this is a
> restriction of the ELDK, not a new issue introcued by this patch.
> Except of this, all build were succesful.
>
> Note 1: Please note that older tool chains (based on binutils versions
> older than 2.16) will have problems with the SORT_BY_ALIGNMENT()
> and SORT_BY_NAME() functions introduced to the linker scripts with
> commit f62fb99941c6. I'll soon submit a patch to fix this issue. Final
> tests are running right now.
>
> Note 2: Even though this is a bigger change, I consider it a bug fix
> and therefor tend to have it included into the upcoming release. Of
> course this requires sufficient test coverage and feedback. Please
> help!!
>
> Note 3: Most ARM systems also define this:
> PLATFORM_RELFLAGS +=$(call cc-option,-mshort-load-bytes,$(call 
> cc-option,-malignment-traps,))
> I guess this can be unified and moved to lib_arm/config.mk, too, but I
> would like to handle this in a separate, later patch. This makes
> testing (and bisecting) easier, and it is a non-critical problem.
>
>  
Tested-by: Gaye Abdoulaye Walsimou 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support

[Wolfgang Denk]

Dear Gaye Abdoulaye Walsimou,

In message <4a8a8b27.7080...@walsimou.com> you wrote:
> 
> I tested your patch against 7dedefdf749ff02c1086f7ddb8cb83a77b00d030

Thanks for testing!

> Results:
> I was unable to compile without the patch in this thread
> http://lists.denx.de/pipermail/u-boot/2009-August/058193.html (which is
> normal because of gcc-4.4.1).

Yes, this is to be expected.

> With 'MAKEALL arm' I have no compile errors except for:
> * actux1, actux2, actux3, actux4, ixdp425, ixdpg425, pdnb3, which seem
> to be big endian (my toolchain only generates binaries for little endian).

correct, to be expected, too.

> * and "trab board" with this error: armel-unknown-linux-gnueabi-ld:
> ../../lib_arm/div0.o: No such file: No such file or directory

I posted a patch to fix this issue. This is a problem in the trab
board code.

Would you please be so kind and post a formal "Tested-by:" or
"Acked-by": message? 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
I think there's a world market for about five computers.
 -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] Network based logging with U-Boot

[Wolfgang Denk]

Dear Matthew Lear,

In message <4a8a7fa3.2090...@bubblegen.co.uk> you wrote:
>
> Firstly, perhaps the problems I have with netcat and U-Boot netconsole
> are partly to do with the 'listener' software itself (ie netcat),
> running on .  AFAIK the 'mapping' of netcat to target ip
> address in order to utilise U-Boot's netconsole is one-to-one, ie netcat
> is unable to listen on an ip address range because it performs a lookup
> on the address and this obviously fails for an ip address range. I may
> be wrong here but from what I can tell, listening on an ip range with
> netcat is not possible. If it was, then this would solve part of my problem.
> 
> Of course, there may be other listeners which may be able to do this..?

You got the source code. Feel free to implement a lsitener with all
the features you need.

> Secondly, if there is a centralised logging machine (), then
> ideally, the messages received from U-Boot's netconsole would be
> prefixed with an identifier in order to differentiate one device running
> U-Boot from another. The prefix could be a U-Boot env hostname, ip
> address, MAC address or some other identifier/variable. If this was
> possible then each platform could be differentiated easily at the server
> end.

Again, this can be easily implemented on the listener side, as you
know exactly where each packet is coming from.

> I suppose my end goal is to have something akin or analogous to multiple
> platforms running Linux and logging over syslog to a server machine
> running syslogd.
> 
> Does that help?

Yes, as it defines your requirements.  As  it  turns  out,  you  need
support  for  additional features on the listener side. From what you
wrote I cannot see any changes needed for the U-Boot side.

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
Speed of a tortoise breaking the sound barrier = 1 Machturtle
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] License Problems for standalone application at u-boot

[Wolfgang Denk]

Dear Peter Chen,

In message <1250589013.6208.40.ca...@nchen-desktop> you wrote:
> 
> The functions which in my function list are written by our own.
> and do not call any other functions at original u-boot code. In that
> case, 

Then just link them against your standalone application, and keep the
code outside the U-Boot image.

> can we add our functions to "include/_exports.h" in order to free from
> GPL for our standalone application?

No.

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 was so narrow minded he could see through  a  keyhole  with  both
eyes ..."
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] init exits with signal 11

[Wolfgang Denk]

Dear Sridhar M,

In message <25021185.p...@talk.nabble.com> you wrote:
> 
> Thanks a lot. I tried the same but it still gives me the same error. These
> are the one that gets displayed.

YOU ARE OFF TOPIC HERE.

YOU ARE OFF TOPIC HERE.

YOU ARE OFF TOPIC HERE.


Do you get it?

> [0.00] Linux version 2.6.21 (r...@cheuxeri002) (gcc version 4.1.2
> (Wind River Linux Sourcery G++ 4.1-91)) #21 PREEMPT Tue Aug 18 12:9

Please contact Wind River support if you have issues with their
obsolete code and tools.

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] ARM: compiler options cleanup - improve tool chain support

[Gaye Abdoulaye Walsimou]

Dear Wolfgang Denk,
I tested your patch against 7dedefdf749ff02c1086f7ddb8cb83a77b00d030
(latest revision at the moment of writing of u-boot.git).
My toolchain is a home-made toolchain and contains gcc-4.4.1,
binutils-2.19.1, eglibc-2.10.1, kernel headers 2.6.30.4, configured to
generate binaries for arm little endian, eabi, and multilib disable.

Results:
I was unable to compile without the patch in this thread
http://lists.denx.de/pipermail/u-boot/2009-August/058193.html (which is
normal because of gcc-4.4.1).
With 'MAKEALL arm' I have no compile errors except for:
* actux1, actux2, actux3, actux4, ixdp425, ixdpg425, pdnb3, which seem
to be big endian (my toolchain only generates binaries for little endian).
* and "trab board" with this error: armel-unknown-linux-gnueabi-ld:
../../lib_arm/div0.o: No such file: No such file or directory

Regards




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

Re: [U-Boot] BMP display.

[Wolfgang Denk]

Dear Tuma,

In message <200908181300.25197.chernigovs...@spb.gs.ru> you wrote:
>
> Oo, thank you! I forgot about CROSS_COMPILE=. In my old U-Boot this parameter 
> was set in Makefile. In 2009 CROSS_COMPILE= in Makefile was ignored.

This statement is plain wrong. CROSS_COMPILE= has never been ignored
in the Makefile, at leats as far as the mainline code is concerned. [I
don't know which crippeled version you might be using, and I don;t
actually care.]

> U-boot 2009 is built now, and runs on OMAP3 evm.
> 
> So I have to put i2c driver files (as .h as .c) to drivers/i2c and LCD driver 
> file s (as .h as .c) to drivers/video?

I don't know the code, so what can I say? Maybe?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Quantum particles: The dreams that stuff is made of.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

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

[Simon Kagstrom]

Thanks for the review Prafulla!

On Tue, 18 Aug 2009 03:12:07 -0700
Prafulla Wadaskar  wrote:

> > v2: Malloc send buffer (comment from Stefan Roese)
> Malloc will always be an overhead.

It's only allocated once (the first time a non-aligned buffer is
passed), so the overhead is minimal.

> I strongly recommend- we should pass aligned buffers from upper layers
> to avoid such rework in all low level drivers, (few are already
> aligned).

We could put the same fix in eth_send instead. Then the issue is really
just how we know what alignment requirement to go for. I guess one
could add a field to the eth_device structure to store this and then
fixup all drivers to supply this.

If the rest of you thinks this is a good idea, I can cook up a patch.
Opinions?

> > v3: No need to use jumbo frames, use 1518 bytes buffer instead
> Better to use PKTSIZE_ALIGN here, avoid magic numbers

OK, I'll fix that.

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

Re: [U-Boot] init exits with signal 11

[Detlev Zundel]

Hi Sridhar,

> [4.106288] init has generated signal 11 but has no handler for it
> [4.112525] Kernel panic - not syncing: Attempted to kill init!
> [4.118461] Rebooting in 3 seconds..
>
> My /etc doesnt have this ld.so.cache.

Your init/busybox obviously has problems.  Did you try to boot the
system with a known working root filesystem? (ELDK 4.2 comes to mind...)
Then switch bit by bit to the files that you have cross-compiled.  This
can be done elegantly with a subsequent mount of your "problematic"
rootfs and chroot(8).

Cheers
  Detlev

-- 
Men are born ignorant, not stupid; they are made stupid by education.
  --Bertrand Russell
--
DENX Software Engineering GmbH,  MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2] arm: Kirkwood: add SYSRSTn Duration Counter Support

[Prafulla Wadaskar]

 

> -Original Message-
> From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] 
> Sent: Tuesday, August 18, 2009 4:24 AM
> To: Wolfgang Denk
> Cc: Prafulla Wadaskar; u-boot@lists.denx.de; Ashish Karkare; 
> Prabhanjan Sarnaik
> Subject: Re: [U-Boot] [PATCH v2] arm: Kirkwood: add SYSRSTn 
> Duration Counter Support
> 
> On 00:36 Tue 18 Aug , Wolfgang Denk wrote:
> > Dear Jean-Christophe PLAGNIOL-VILLARD,
> > 
> > In message <20090817221152.gm23...@game.jcrosoft.org> you wrote:
> > >
> > > > +   printf("Starting %s process...\n", __FUNCTION__);
> > > > +   sprintf(cmd, "run ");
> > > > +   sprintf(img, "sysrstcmd");
> > > > +   argv[0] = cmd;
> > > > +   argv[1] = img;
> > > > +   if ((do_run(NULL, 0, 2, argv)) != 0x0) {
> > > > +   printf("Error.. %s failed\n", __FUNCTION__);
> > > > +   } else {
> > > > +   printf("%s process finished\n", __FUNCTION__);
> > > > +   }
> > > 
> > > > +#else  /* CONFIG_CMD_RUN */
I think better approach will be report it at build time
i.e. #error "Error.. CONFIG_CMD_RUN needed for sysrstcmd support"

> > > > +   printf("Error.. %s needs run command 
> support\n", __FUNCTION__);
> > > > +#endif /* CONFIG_CMD_RUN */
> > > why not replace this by
> > > 
> > >   char *s = getenv("sysrstcmd");
> > > 
> > >   if (!s) {
> > >   printf("Error.. %s failed, check sysrstcmd\n",
> > >   __FUNCTION__);
> > >   return;
> > >   }
> > > 
> > >   printf("Starting %s process...\n", __FUNCTION__);
> > > #if !defined(CONFIG_SYS_HUSH_PARSER)
> > >   ret = run_command (s, 0);
> > > #else
> > >   ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
> > > | FLAG_EXIT_FROM_LOOP);
I had checked this before,
this is already done in the context of do_run
to avoid code duplication I have used do_run.


> > > #endif
> > 
> > Maybe because the original code does not need an #ifdef ?
> but the size is bigger on the current implementation
> and as we have this is other part of U-Boot we can add a 
> inline to have the
> ifdef at only one place
As suggested above, we can report it at build time and reduce some on binary 
size too.

Regards..
Prafulla . .

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

[U-Boot] Regarding 8641D u-boot

[Thirumalai]

Hi kumar,
The CONFIG_PHYS_64BIT was not defined on the header file of HPCN 
but extended address translation was enabled on the start.S irrespective of 
the  MPC8641D_hpcn compilation option why?.

Regards,
T.


 CAUTION - Disclaimer *This email may contain 
confidential and privileged material for the
sole use of the intended recipient(s). Any review, use, retention, distribution 
or disclosure by others is strictly prohibited. If you are not the intended 
recipient (or authorized to receive for the recipient), please contact the 
sender by reply email and delete all copies of this message. Also, email is 
susceptible to data corruption, interception, tampering, unauthorized amendment 
and viruses. We only send and receive emails on the basis that we are not 
liable for any such corruption, interception, tampering, amendment or viruses 
or any consequence thereof. 
*** End of Disclaimer ***DataPatterns ITS Group**

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

Re: [U-Boot] Network based logging with U-Boot

[Matthew Lear]

Hi Wolfgang,
Wolfgang Denk wrote:
> Dear Matthew Lear,
> 
> In message <4a896ed5.3010...@bubblegen.co.uk> you wrote:

[snip]

>> I've got netconsole running via netcat on a host pc but this is console
>> only and is not ideal for a multi-platform deployment model. Although,
> 
> "not ideal"? What exactly are you missing?
> 
>> saying that, I suppose that doing 'set ncip ' and 'set stdout
>> nc' and running netcat on a host pc would provide some level of diagnostics.
>>
>> Is anybody able to offer any advice or strategy here for similar
>> requirements?
> 
> Try to explain what your exact problems with netconsole are.

Firstly, perhaps the problems I have with netcat and U-Boot netconsole
are partly to do with the 'listener' software itself (ie netcat),
running on .  AFAIK the 'mapping' of netcat to target ip
address in order to utilise U-Boot's netconsole is one-to-one, ie netcat
is unable to listen on an ip address range because it performs a lookup
on the address and this obviously fails for an ip address range. I may
be wrong here but from what I can tell, listening on an ip range with
netcat is not possible. If it was, then this would solve part of my problem.

Of course, there may be other listeners which may be able to do this..?

Secondly, if there is a centralised logging machine (), then
ideally, the messages received from U-Boot's netconsole would be
prefixed with an identifier in order to differentiate one device running
U-Boot from another. The prefix could be a U-Boot env hostname, ip
address, MAC address or some other identifier/variable. If this was
possible then each platform could be differentiated easily at the server
end.

I suppose my end goal is to have something akin or analogous to multiple
platforms running Linux and logging over syslog to a server machine
running syslogd.

Does that help?

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

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

[Prafulla Wadaskar]

 

> -Original Message-
> From: u-boot-boun...@lists.denx.de 
> [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Kagstrom
> Sent: Tuesday, August 18, 2009 3:02 PM
> To: U-Boot ML
> Subject: [U-Boot] [PATCH] arm:kirkwood See to it that sent 
> data is 8-byte aligned
> 
> See to it that sent data is 8-byte aligned
> 
> 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 malloced temporary buffer if it is
> non-aligned.
> 
> v2: Malloc send buffer (comment from Stefan Roese)
Malloc will always be an overhead.
I strongly recommend- we should pass aligned buffers from upper layers to avoid 
such rework in all low level drivers, (few are already aligned).

> v3: No need to use jumbo frames, use 1518 bytes buffer instead
Better to use PKTSIZE_ALIGN here, avoid magic numbers

> (comment from Ben Warren)
> 
> Signed-off-by: Simon Kagstrom 
> ---
>  drivers/net/kirkwood_egiga.c |   26 ++
>  1 files changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/net/kirkwood_egiga.c 
> b/drivers/net/kirkwood_egiga.c
> index f31fefc..6627412 100644
> --- a/drivers/net/kirkwood_egiga.c
> +++ b/drivers/net/kirkwood_egiga.c
> @@ -481,24 +481,42 @@ static int kwgbe_halt(struct eth_device *dev)
>   return 0;
>  }
>  
> +#define KWGBE_SEND_BUF_SIZE 1518
Better to use PKTSIZE_ALIGN here, avoid magic numbers
Regards..
Prafulla . .
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] License Problems for standalone application at u-boot

[Peter Chen]

Dear Wolfgang Denk,


On Tue, 2009-08-18 at 10:35 +0200, Wolfgang Denk wrote:

> Dear Peter Chen,
> 
> In message <1250571462.6548.21.ca...@nchen-desktop> you wrote:
> > 
> > > > > The "jump table provided by U-Boot exactly for this purpose" is the
> > > > > list of functions exported through the "include/_exports.h" header
> > > > > file.
> ...
> > > If you set up your own list of function pointers (in addition or
> > > instead of the jump table provided by the "include/_exports.h"
> > > header), then this is a form of linking against the U-Boot code, and
> > > your application must be released under GPL.
> > 
> > I am sorry, I can't understand your meaning. For example, at
> 
> I'm close to give up. I try to as explicit as possible, and I see no
> room for interpretation left, yet you still try to argument.
> 
> > "include/_exports.h"
> > there is an EXPORT_FUNC(printf), do the standalone application must
> > under GPL if
> > it uses printf?
> 
> No. As explained several times before, the "jump table [is]  provided
> by  U-Boot  exactly  for  this purpose", with "this purpose" being to
> allow for closed source, proprietary code.
> 
> printf() gets exported through the jump table interface, so this is OK
> to use in proprietary code.
> 
> > Then, what does "include/_exports.h" use?
> 
> It uses a list of functions (resp. function pointers) we consider  OK
> to be used in closed source applications.
> 
> > In your COPYING, it writes:
> >   NOTE! This copyright does *not* cover the so-called "standalone"
> > applications that use U-Boot services by means of the jump table
> > provided by U-Boot exactly for this purpose - this is merely
> > considered normal use of U-Boot, and does *not* fall under the 
> > heading of "derived work".
> 
> Indeed. And I explained this several times before.
> 
> > > > Is it free to license at below situation:
> > > > The function list which is defined at u-boot/board/myboard/myboard.c,
> > > > and all functions in this list
> > > > only uses functions at include/_exports.h and some of user-defined
> > > > functions.
> > > 
> > > Your description is really vague; it would be easier if you could
> > > give specific code examples or such. If "some of user-defined
> > > functions" refers to code that is covered by the GPL, then your
> > > application must be released under GPL, too.
> > > 
> > 
> > My code like belows:
> > 
> > typedef void (*pfn_t) (void);
> > pfn_t sc_gps_pfn[] = {
> > LoadToMemory,
> > SaveData,
> > RFPowerCtrl,
> > MiscConfig,
> > RegisterDspInterruptHandler,
> > GetPowerStatus,
> > IsUserResume,
> > DebugOutput,
> > ReturnToBootLoader
> > };
> 
> OK, so you are setting up a table of your  own  functions.  You  need
> this  table only if you link the code containing these functions with
> the U-Boot binary - and you do so  most  probably  because  the  code
> calls into other U-Boot provided functions.
> 
> > We want to open this code, but want to close the code which use this
> > function list in binary pattern.
> 
> You probably have no choice here. If your code that provides the list
> of functions above is linked with U-Boot, you *must* release it under
> GPL. No matter if you want or not - if you release your code at all,
> it is GPLed.
> 
> And your list of functions above thus accesses GPLed  code  which  is
> NOT  part  of include/_exports.h. So the GPL exception does NOT apply
> to any code that references functions from  this  list,  i.  e.  your
> standalone application must be released under GPL, too.
> 

The functions which in my function list are written by our own.
and do not call any other functions at original u-boot code. In that
case, 
can we add our functions to "include/_exports.h" in order to free from
GPL for our standalone application?

I checked the functions which exported in "include/_exports.h", and
their definitions are also under GPL. then why 
they can be called for closed code? If we want to add, how to do?


> > > What you implement is some form of static linking.
> ...
> > The standalone application is compiled by armcc, and this bin file is
> > shared by WinCE and Linux bootloader.
> > The standalone application uses bootloader functions by address not by
> > name.
> 
> That does not matter. Accessing a function by address still means you
> are linking against the code (in a stupid way, btw). Your standalone
> application has to be released under GPL.
> 
> 
> 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 quarrel is quickly settled when deserted by one party; there is  no
> battle unless there be two.  - Seneca


Best Regards,
Peter Chen
___
U-Boot mailing list

[U-Boot] [PATCH] arm:kirkwood See to it that sent data is 8-byte aligned

[Simon Kagstrom]

See to it that sent data is 8-byte aligned

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 malloced temporary buffer if it is
non-aligned.

v2: Malloc send buffer (comment from Stefan Roese)
v3: No need to use jumbo frames, use 1518 bytes buffer instead
(comment from Ben Warren)

Signed-off-by: Simon Kagstrom 
---
 drivers/net/kirkwood_egiga.c |   26 ++
 1 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index f31fefc..6627412 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -481,24 +481,42 @@ static int kwgbe_halt(struct eth_device *dev)
return 0;
 }
 
+#define KWGBE_SEND_BUF_SIZE 1518
 static int kwgbe_send(struct eth_device *dev, volatile void *dataptr,
  int datasize)
 {
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe->regs;
struct kwgbe_txdesc *p_txdesc = dkwgbe->p_txdesc;
+   void *p = (void *)dataptr;
u32 cmd_sts;
 
+   /* Copy buffer if it's misaligned */
if ((u32) dataptr & 0x07) {
-   printf("Err..(%s) xmit dataptr not 64bit aligned\n",
-   __FUNCTION__);
-   return -1;
+   static void *aligned_buf;
+
+   if (!aligned_buf)
+   aligned_buf = memalign(sizeof(u32),
+   KWGBE_SEND_BUF_SIZE);
+   if (!aligned_buf) {
+   printf("Err...(%s): Cannot allocate aligned buffer\n",
+   __FUNCTION__);
+   return -1;
+   }
+   if (datasize > KWGBE_SEND_BUF_SIZE) {
+   printf("Err..(%s) Non-aligned data too large (%d)\n",
+   __FUNCTION__, datasize);
+   return -1;
+   }
+   memcpy(aligned_buf, p, datasize);
+   p = aligned_buf;
}
+
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;
p_txdesc->cmd_sts |= KWGBE_TX_EN_INTERRUPT;
-   p_txdesc->buf_ptr = (u8 *) dataptr;
+   p_txdesc->buf_ptr = (u8 *) p;
p_txdesc->byte_cnt = datasize;
 
/* Apply send command using zeroth RXUQ */
-- 
1.6.0.4

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

Re: [U-Boot] init exits with signal 11

[Sridhar M]

Hi,
Thanks a lot. I tried the same but it still gives me the same error. These
are the one that gets displayed.

## Booting image at 0020 ...
   Image Name:   Linux-2.6.21
   Image Type:   PowerPC Linux Kernel Image (gzip compressed)
   Data Size:1311814 Bytes =  1.3 MB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Uncompressing Kernel Image ... OK
## Loading RAMDisk Image at 0100 ...
   Image Name:   Rootfs Test
   Image Type:   PowerPC Linux RAMDisk Image (gzip compressed)
   Data Size:5046516 Bytes =  4.8 MB
   Load Address: 
   Entry Point:  
   Verifying Checksum ... OK
   Loading Ramdisk to 0522f000, end 056ff0f4 ... OK
[0.00] Linux version 2.6.21 (r...@cheuxeri002) (gcc version 4.1.2
(Wind River Linux Sourcery G++ 4.1-91)) #21 PREEMPT Tue Aug 18 12:9
[0.00] AMCC PowerPC 440EP Yosemite Platform
[0.00] Zone PFN ranges:
[0.00]   DMA 0 ->32768
[0.00]   Normal  32768 ->32768
[0.00]   HighMem 32768 ->32768
[0.00] early_node_map[1] active PFN ranges
[0.00] 0:0 ->32768
[0.00] Built 1 zonelists.  Total pages: 32512
[0.00] Kernel command line: mem=128M console=ttyS0,115200
root=/dev/ram rw init=/sbin/linuxrc panic=3 loglevel=7
[0.00] PID hash table entries: 512 (order: 9, 2048 bytes)
[0.76] Console: colour dummy device 80x25
[0.068076] Dentry cache hash table entries: 16384 (order: 4, 65536
bytes)
[0.075516] Inode-cache hash table entries: 8192 (order: 3, 32768 bytes)
[0.094408] Memory: 121756k available (1936k kernel code, 1044k data,
108k init, 0k highmem)
[0.192156] Mount-cache hash table entries: 512
[0.198250] NET: Registered protocol family 16
[0.208218] PCI: Probing PCI hardware
[0.222329] NET: Registered protocol family 2
[0.252127] IP route cache hash table entries: 1024 (order: 0, 4096
bytes)
[0.259225] TCP established hash table entries: 4096 (order: 3, 32768
bytes)
[0.266431] TCP bind hash table entries: 4096 (order: 2, 16384 bytes)
[0.272964] TCP: Hash tables configured (established 4096 bind 4096)
[0.279324] TCP reno registered
[0.292438] checking if image is initramfs...it isn't (no cpio magic);
looks like an initrd
[1.770630] Freeing initrd memory: 4928k freed
[1.777422] io scheduler noop registered
[1.781425] io scheduler cfq registered (default)
[2.071072] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ
sharing disabled
[2.079365] serial8250: ttyS0 at MMIO 0x0 (irq = 0) is a 16550A
[2.086089] serial8250: ttyS1 at MMIO 0x0 (irq = 1) is a 16550A
[2.092844] serial8250: ttyS2 at MMIO 0x0 (irq = 3) is a 16550A
[2.099560] serial8250: ttyS3 at MMIO 0x0 (irq = 4) is a 16550A
[2.112918] RAMDISK driver initialized: 16 RAM disks of 6K size 1024
blocksize
[2.123495] loop: loaded (max 8 devices)
[2.127779] nbd: registered device at major 43
[2.139752] Intel(R) PRO/1000 Network Driver - version 7.3.20-k2
[2.145851] Copyright (c) 1999-2006 Intel Corporation.
[2.151342] e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
[2.157475] e100: Copyright(c) 1999-2006 Intel Corporation
[2.165232] forcedeth.c: Reverse Engineered nForce ethernet driver.
Version 0.60.
[2.173761] tun: Universal TUN/TAP device driver, 1.6
[2.178855] tun: (C) 1999-2004 Max Krasnyansky 
[2.186097] netconsole: not configured, aborting
[2.191571] i8042.c: No controller found.
[2.195900] mice: PS/2 mouse device common for all mice
[2.201261] TCP cubic registered
[2.204537] NET: Registered protocol family 1
[2.208917] NET: Registered protocol family 17
[2.213856] RAMDISK: Compressed image found at block 0
[4.018906] DEBUG:Going to mount file system
[4.023591] EXT2-fs warning: mounting unchecked fs, running e2fsck is
recommended
[4.031412] VFS: Mounted root (ext2 filesystem).
[4.036073] DEBUG:printing the filesystem name
[4.040534] DEBUG:Mount root returned
[4.044299] DEBUG:sys_mount returned
[4.047887] DEBUG:sys_chroot returned
[4.051557] DEBUG:security_sb_post_mountroot returned
[4.056619] DEBUG:FILE SYSTEM mounted
[4.060290] Freeing unused kernel memory: 108k init
[4.065242] DEBUG:free_initmem
[4.068302] DEBUG:unlock_kernel
[4.071449] DEBUG:mark_rodata_ro
[4.074692] DEBUG:numa_default_policy
[4.078661] DEBUG:console opened successfully
[4.083059] DEBUG:sys_dup executed twice
[4.086991] DEBUG:value of ramdisk_execute_command 
[4.092401] DEBUG:run_init_process
[4.095808] DEBUG:Value of execute_command /sbin/linuxrc
[4.101133] DEBUG:run_init_process start
[4.106288] init has generated signal 11 but has no handler for it
[4.112525] Kernel panic - not syncing: Attempted to kill init!
[4.118461] Rebooting in 3 seconds..

My /etc doesnt have this ld.so.cache.

Thanks and Regards
Sri

[U-Boot] [PATCH 4/4]: Define test_and_set_bit and test_and_clear bit for ARM

[Simon Kagstrom]

Define test_and_set_bit and test_and_clear bit for ARM

Needed for (e.g.) ubifs support to work.

Signed-off-by: Simon Kagstrom 
---
 include/asm-arm/bitops.h |   27 ---
 1 files changed, 24 insertions(+), 3 deletions(-)

diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index e98dd56..7ae7aab 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -18,6 +18,7 @@
 #ifdef __KERNEL__
 
 #include 
+#include 
 
 #define smp_mb__before_clear_bit() do { } while (0)
 #define smp_mb__after_clear_bit()  do { } while (0)
@@ -46,8 +47,6 @@ static inline void __change_bit(int nr, volatile void *addr)
((unsigned char *) addr)[nr >> 3] ^= (1U << (nr & 7));
 }
 
-extern int test_and_set_bit(int nr, volatile void * addr);
-
 static inline int __test_and_set_bit(int nr, volatile void *addr)
 {
unsigned int mask = 1 << (nr & 7);
@@ -58,7 +57,17 @@ static inline int __test_and_set_bit(int nr, volatile void 
*addr)
return oldval & mask;
 }
 
-extern int test_and_clear_bit(int nr, volatile void * addr);
+static inline int test_and_set_bit(int nr, volatile void * addr)
+{
+   unsigned long flags;
+   int out;
+
+   local_irq_save(flags);
+   out = __test_and_set_bit(nr, addr);
+   local_irq_restore(flags);
+
+   return out;
+}
 
 static inline int __test_and_clear_bit(int nr, volatile void *addr)
 {
@@ -70,6 +79,18 @@ static inline int __test_and_clear_bit(int nr, volatile void 
*addr)
return oldval & mask;
 }
 
+static inline int test_and_clear_bit(int nr, volatile void * addr)
+{
+   unsigned long flags;
+   int out;
+
+   local_irq_save(flags);
+   out = __test_and_clear_bit(nr, addr);
+   local_irq_restore(flags);
+
+   return out;
+}
+
 extern int test_and_change_bit(int nr, volatile void * addr);
 
 static inline int __test_and_change_bit(int nr, volatile void *addr)
-- 
1.6.0.4

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

[U-Boot] [PATCH 3/4]: Remove duplicate set_cr

[Simon Kagstrom]

Remove duplicate set_cr

set_cr is defined in both asm-arm/proc-armv/system.h and
include/asm-arm/system.h. This patch removes it (and some duplicate
defines) from the former.

Signed-off-by: Simon Kagstrom 
---
 include/asm-arm/proc-armv/system.h |   30 --
 1 files changed, 0 insertions(+), 30 deletions(-)

diff --git a/include/asm-arm/proc-armv/system.h 
b/include/asm-arm/proc-armv/system.h
index e7b0fe6..b4cfa68 100644
--- a/include/asm-arm/proc-armv/system.h
+++ b/include/asm-arm/proc-armv/system.h
@@ -12,36 +12,6 @@
 
 #include 
 
-#define set_cr(x)  \
-   __asm__ __volatile__(   \
-   "mcrp15, 0, %0, c1, c0  @ set CR"   \
-   : : "r" (x))
-
-#define CR_M   (1 << 0)/* MMU enable   */
-#define CR_A   (1 << 1)/* Alignment abort enable   */
-#define CR_C   (1 << 2)/* Dcache enable*/
-#define CR_W   (1 << 3)/* Write buffer enable  */
-#define CR_P   (1 << 4)/* 32-bit exception handler */
-#define CR_D   (1 << 5)/* 32-bit data address range*/
-#define CR_L   (1 << 6)/* Implementation defined   */
-#define CD_B   (1 << 7)/* Big endian   */
-#define CR_S   (1 << 8)/* System MMU protection*/
-#define CD_R   (1 << 9)/* ROM MMU protection   */
-#define CR_F   (1 << 10)   /* Implementation defined   */
-#define CR_Z   (1 << 11)   /* Implementation defined   */
-#define CR_I   (1 << 12)   /* Icache enable*/
-#define CR_V   (1 << 13)   /* Vectors relocated to 0x  */
-#define CR_RR  (1 << 14)   /* Round Robin cache replacement*/
-
-extern unsigned long cr_no_alignment;  /* defined in entry-armv.S */
-extern unsigned long cr_alignment; /* defined in entry-armv.S */
-
-#if __LINUX_ARM_ARCH__ >= 4
-#define vectors_base() ((cr_alignment & CR_V) ? 0x : 0)
-#else
-#define vectors_base() (0)
-#endif
-
 /*
  * Save the current interrupt enable state & disable IRQs
  */
-- 
1.6.0.4

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

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

[Simon Kagstrom]

Define ffs/fls for all architectures

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.

v2: Unify code style (empty line between ffs/fls)

Signed-off-by: Simon Kagstrom 
---
 include/asm-arm/bitops.h|4 
 include/asm-avr32/bitops.h  |4 
 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   |5 -
 include/asm-nios2/bitops.h  |5 -
 include/asm-sh/bitops.h |2 ++
 include/asm-sparc/bitops.h  |4 
 include/linux/bitops.h  |   37 +
 11 files changed, 67 insertions(+), 2 deletions(-)

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)
+
 /*
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
diff --git a/include/asm-avr32/bitops.h b/include/asm-avr32/bitops.h
index b1cf2fb..5fa20e2 100644
--- a/include/asm-avr32/bitops.h
+++ b/include/asm-avr32/bitops.h
@@ -26,4 +26,8 @@
 
 #define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
 
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
+
 #endif /* __ASM_AVR32_BITOPS_H */
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
index b768e20..71c2256 100644
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -350,6 +350,8 @@ static __inline__ int ffs(int x)
return r+1;
 }
 
+#define fls(x) generic_fls(x)
+
 /**
  * hweightN - returns the hamming weight of a N-bit word
  * @x: the word to weigh
diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
index fb472e6..a38a62a 100644
--- a/include/asm-m68k/bitops.h
+++ b/include/asm-m68k/bitops.h
@@ -56,6 +56,8 @@ extern __inline__ int ffs(int x)
 }
 #define __ffs(x) (ffs(x) - 1)
 
+#define fls(x) generic_fls(x)
+
 #endif /* __KERNEL__ */
 
 #endif /* _M68K_BITOPS_H */
diff --git a/include/asm-microblaze/bitops.h b/include/asm-microblaze/bitops.h
index 04ea020..e277ab8 100644
--- a/include/asm-microblaze/bitops.h
+++ b/include/asm-microblaze/bitops.h
@@ -266,6 +266,8 @@ found_middle:
 
 #define ffs(x) generic_ffs(x)
 
+#define fls(x) generic_fls(x)
+
 /*
  * hweightN: returns the hamming weight (i.e. the number
  * of bits set) of a N-bit word
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 659ac9d..76b9baa 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -716,6 +716,8 @@ static __inline__ unsigned long ffz(unsigned long word)
 
 #define ffs(x) generic_ffs(x)
 
+#define fls(x) generic_fls(x)
+
 /*
  * hweightN - returns the hamming weight of a N-bit word
  * @x: the word to weigh
diff --git a/include/asm-nios/bitops.h b/include/asm-nios/bitops.h
index 76c52c2..33714c4 100644
--- a/include/asm-nios/bitops.h
+++ b/include/asm-nios/bitops.h
@@ -32,7 +32,10 @@ extern void change_bit(unsigned long nr, volatile void 
*addr);
 extern int test_and_set_bit(int nr, volatile void * a);
 extern int test_and_change_bit(int nr, volatile void * addr);
 extern int test_bit(int nr, volatile void * a);
-extern int ffs(int i);
+
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
 
 #define __set_bit(nr, addr) generic_set_bit(nr, addr)
 
diff --git a/include/asm-nios2/bitops.h b/include/asm-nios2/bitops.h
index da04b40..1fac52c 100644
--- a/include/asm-nios2/bitops.h
+++ b/include/asm-nios2/bitops.h
@@ -32,7 +32,10 @@ extern void change_bit(unsigned long nr, volatile void 
*addr);
 extern int test_and_set_bit(int nr, volatile void * a);
 extern int test_and_change_bit(int nr, volatile void * addr);
 extern int test_bit(int nr, volatile void * a);
-extern int ffs(int i);
+
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
 
 #define __set_bit(nr, addr) generic_set_bit(nr, addr)
 
diff --git a/include/asm-sh/bitops.h b/include/asm-sh/bitops.h
index f102e7e..8021455 100644
--- a/include/asm-sh/bitops.h
+++ b/include/asm-sh/bitops.h
@@ -147,6 +147,8 @@ static inline int ffs (int x)
return r;
 }
 
+#define fls(x) generic_fls(x)
+
 #define __set_bit(nr, addr) generic_set_bit(nr, addr)
 
 #define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
diff --git a/include/asm-sparc/bitops.h b/include/asm-sparc/bitops.h
index b1bcb53..942029f 100644
--- a/include/asm-sparc/bitops.h
+++ b/include/asm-sparc/bitops.h
@@ -30,4 +30,8 @@
 
 #define __clear_bit(nr,

Re: [U-Boot] init exits with signal 11

[Heiko Schocher]

Hello Sridhar,

Sridhar M wrote:
> I am trying to bring up a AMCC 440EP yosemite eval board using wind river
> linux 2.0/I cross compiled busy box 1.4.1 and the kernel . I tried to bring
> up the board using TFTP. 
> 
> It loads the kernel and the file system.I get an error message when init is
> spawned.

This is the U-Bootmailing list - you are off topic here.

> EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
> [4.851771] 
> VFS: Mounted root (ext2 filesystem).
> 
> [4.856547] Freeing unused kernel memory: 120k init
> [
> 4.863038] init has generated signal 11 but has no handler for it
> 
> [4.869283] Kernel panic - not syncing: Attempted to kill init!
> [4.875221] Rebooting in 3 seconds.
> 
> 
> Please help me. Am struck with this for almost 3 days.

Maybe this helps:

http://www.denx.de/wiki/DULG/LinuxKernelPanicsBecauseInitProessDies

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 1/4]: Move __set/clear_bit from ubifs.h to bitops.h

[Simon Kagstrom]

Move __set/clear_bit from ubifs.h to bitops.h

__set_bit and __clear_bit are defined in ubifs.h as well as in
asm/include/bitops.h for some architectures. This patch moves
the generic implementation to include/linux/bitops.h and uses
that unless it's defined by the architecture.

v2: Unify code style (newline between __set_bit and __clear_bit)

Signed-off-by: Simon Kagstrom 
---
 fs/ubifs/ubifs.h   |   32 
 include/asm-avr32/bitops.h |4 
 include/asm-m68k/bitops.h  |4 
 include/asm-nios/bitops.h  |4 
 include/asm-nios2/bitops.h |4 
 include/asm-ppc/bitops.h   |4 
 include/asm-sh/bitops.h|5 +
 include/asm-sparc/bitops.h |4 
 include/linux/bitops.h |   30 ++
 9 files changed, 59 insertions(+), 32 deletions(-)

diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 43865aa..06772af 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -449,38 +449,6 @@ static inline ino_t parent_ino(struct dentry *dentry)
return res;
 }
 
-/* linux/include/linux/bitops.h */
-
-#define BIT_MASK(nr)   (1UL << ((nr) % BITS_PER_LONG))
-#define BIT_WORD(nr)   ((nr) / BITS_PER_LONG)
-
-/* linux/include/asm-generic/bitops/non-atomic.h */
-
-/**
- * __set_bit - Set a bit in memory
- * @nr: the bit to set
- * @addr: the address to start counting from
- *
- * Unlike set_bit(), this function is non-atomic and may be reordered.
- * If it's called on the same region of memory simultaneously, the effect
- * may be that only one operation succeeds.
- */
-static inline void __set_bit(int nr, volatile unsigned long *addr)
-{
-   unsigned long mask = BIT_MASK(nr);
-   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
-
-   *p  |= mask;
-}
-
-static inline void __clear_bit(int nr, volatile unsigned long *addr)
-{
-   unsigned long mask = BIT_MASK(nr);
-   unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
-
-   *p &= ~mask;
-}
-
 /* debug.c */
 
 #define DEFINE_SPINLOCK(...)
diff --git a/include/asm-avr32/bitops.h b/include/asm-avr32/bitops.h
index f15fd46..b1cf2fb 100644
--- a/include/asm-avr32/bitops.h
+++ b/include/asm-avr32/bitops.h
@@ -22,4 +22,8 @@
 #ifndef __ASM_AVR32_BITOPS_H
 #define __ASM_AVR32_BITOPS_H
 
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
 #endif /* __ASM_AVR32_BITOPS_H */
diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
index 0f9e8ab..fb472e6 100644
--- a/include/asm-m68k/bitops.h
+++ b/include/asm-m68k/bitops.h
@@ -15,6 +15,10 @@ extern int test_and_set_bit(int nr, volatile void *addr);
 extern int test_and_clear_bit(int nr, volatile void *addr);
 extern int test_and_change_bit(int nr, volatile void *addr);
 
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
 #ifdef __KERNEL__
 
 /*
diff --git a/include/asm-nios/bitops.h b/include/asm-nios/bitops.h
index 7744212..76c52c2 100644
--- a/include/asm-nios/bitops.h
+++ b/include/asm-nios/bitops.h
@@ -34,4 +34,8 @@ extern int test_and_change_bit(int nr, volatile void * addr);
 extern int test_bit(int nr, volatile void * a);
 extern int ffs(int i);
 
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
 #endif /* _ASM_NIOS_BITOPS_H */
diff --git a/include/asm-nios2/bitops.h b/include/asm-nios2/bitops.h
index e6c1a85..da04b40 100644
--- a/include/asm-nios2/bitops.h
+++ b/include/asm-nios2/bitops.h
@@ -34,4 +34,8 @@ extern int test_and_change_bit(int nr, volatile void * addr);
 extern int test_bit(int nr, volatile void * a);
 extern int ffs(int i);
 
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
 #endif /* __ASM_NIOS2_BITOPS_H */
diff --git a/include/asm-ppc/bitops.h b/include/asm-ppc/bitops.h
index daa66cf..fd7f599 100644
--- a/include/asm-ppc/bitops.h
+++ b/include/asm-ppc/bitops.h
@@ -144,6 +144,10 @@ extern __inline__ int test_and_change_bit(int nr, volatile 
void *addr)
 }
 #endif /* __INLINE_BITOPS */
 
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
 extern __inline__ int test_bit(int nr, __const__ volatile void *addr)
 {
__const__ unsigned int *p = (__const__ unsigned int *) addr;
diff --git a/include/asm-sh/bitops.h b/include/asm-sh/bitops.h
index 410fba4..f102e7e 100644
--- a/include/asm-sh/bitops.h
+++ b/include/asm-sh/bitops.h
@@ -146,6 +146,11 @@ static inline int ffs (int x)
}
return r;
 }
+
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
 #endif /* __KERNEL__ */
 
 #endif /* __ASM_SH_BITOPS_H */
diff --git a/include/asm-sparc/bitops.h b/include/asm-sparc/bitops.h
index ceb39f2..b1bcb53 100644
--- a/include/asm-sparc/bito

[U-Boot] [PATCH 0/4]: bitops cleanup and fixes

[Simon Kagstrom]

Hi again!

This patch series is an update to "[PATCH 0/8]: Fixes for ubifs build
on ARM" sent in july:

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

and contains the patches which were not accepted. The patches are:

  0001-Move-__set-clear_bit-from-ubifs.h-to-bitops.h.patch
- Code style updates. I chose to not create
  asm-generic/include/bitops/ (Jean-Christophes comment) since I
  feel that should go together with a larger restructuring.

  0002-Define-ffs-fls-for-all-architectures.patch
- Code style updates (Wolfgangs comment).

  0003-Remove-duplicate-set_cr.patch
- New patch, removes a duplicate definition (also unused) that
  prevents compilation of the next patch

  0004-Define-test_and_set_bit-and-test_and_clear-bit-for-A.patch
- Defines test_and_set_bit etc for ARM. Uses the non-atomic
  __test_and_set_bit. The endianness issue in __test_and_set_bit
  (Jean-Christophes comment) is a separate issue and should be
  handled in a separate patch I think.

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

Re: [U-Boot] BMP display.

[Tuma]

On Monday 17 August 2009 19:37:53 you wrote:
> > -Original Message-
> > From: u-boot-boun...@lists.denx.de
> > [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Tuma
> > Sent: Monday, August 17, 2009 7:26 PM
> > To: Wolfgang Denk; U-Boot Mailing List
> > Subject: Re: [U-Boot] BMP display.
> >
> > On Monday 17 August 2009 16:38:31 you wrote:
> > > Dear Tuma,
> > >
> > > again: please keep the mailing list on Cc: !!!
> > >
> > > In message <200908171631.17975.chernigovs...@spb.gs.ru> you wrote:
> > > > Okay. Is new version configurable for OMAP3evm out of the box?
> > >
> > > Yes.
> > >
> > > > And is the v2009.08-rc2 stable enought?
> > >
> > > Yes.
> >
> > Thank you. I've downloaded new U-Boot 2009.08.rc2.
> > I have some error while making it.
> > I do:
> > make distclean  (Okay)
> > make omap3_evm_config  (Okay)
> > make
> >
> > And get:
> >
> > make[1]: arm-linux-gcc: Command not found
> >
> > My old U-Boot used "arm-none-linux-gnueabi-gcc" which make
> > system could easyly
> > find on my system.
> > Should I install some new software to build new U-Boot?
> > Or configure existing Makefile?
>
> Can you try:
> make CROSS_COMPILE=arm-none-linux-gnueabi-


Oo, thank you! I forgot about CROSS_COMPILE=. In my old U-Boot this parameter 
was set in Makefile. In 2009 CROSS_COMPILE= in Makefile was ignored.

U-boot 2009 is built now, and runs on OMAP3 evm.

So I have to put i2c driver files (as .h as .c) to drivers/i2c and LCD driver 
file s (as .h as .c) to drivers/video?


> > > Best regards,
> > >
> > > Wolfgang Denk
> >
> > --
> > Software Developer
> > General Satellite Corp.
> > ___
> > U-Boot mailing list
> > U-Boot@lists.denx.de
> > http://lists.denx.de/mailman/listinfo/u-boot



-- 
Software Developer
General Satellite Corp.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] init exits with signal 11

[Sridhar M]

Hi,
I am trying to bring up a AMCC 440EP yosemite eval board using wind river
linux 2.0/I cross compiled busy box 1.4.1 and the kernel . I tried to bring
up the board using TFTP. 

It loads the kernel and the file system.I get an error message when init is
spawned.

EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
[4.851771] 
VFS: Mounted root (ext2 filesystem).

[4.856547] Freeing unused kernel memory: 120k init
[
4.863038] init has generated signal 11 but has no handler for it

[4.869283] Kernel panic - not syncing: Attempted to kill init!
[4.875221] Rebooting in 3 seconds.


Please help me. Am struck with this for almost 3 days.
-- 
View this message in context: 
http://www.nabble.com/init-exits-with-signal-11-tp25020951p25020951.html
Sent from the Uboot - Users mailing list archive at Nabble.com.

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

Re: [U-Boot] [PATCH] AT91: Add support for blue_LED_* and add coloured_LED_init to at91/led.c

[Albin Tonnerre]

On Tue, Aug 18, 2009 at 12:51:48AM +0200, Jean-Christophe PLAGNIOL-VILLARD 
wrote :
> no please take a look on the other LED thread

Would you please provide a pointer to this thread ? THe only one remotely
related I can find is
http://lists.denx.de/pipermail/u-boot/2009-May/052160.html, and you did not
participate in this one ...

> I want to hape coloured-LED api and numbered led handle by the same api
> with the less size impact

When you have this same API, you'll still need code to turn LEDs on and off, and
you'll still have to beat the LED code out of cards-specific code because it
really ought to be in a common file. My patch does exactly that, does *not*
impact size, and is an actual step towards whatever you plan next. I'd prefer if
you were rejecting this on actual, justified grounds.

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com


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

Re: [U-Boot] Where can I find some material about Xenomai/SOLO's usage and limit?

[Wolfgang Denk]

Dear "Gao Ya'nan",

In message  you 
wrote:
>  And is there any successful stories about Xenomai/SOLO?

This is the U-Bootmailing list - you are off topic here.

Please ask on the xenomai-h...@gna.org list, instead.

Also you may consider coming to the Xenomai User Meeting in September,
see http://www.denx.de/en/News/XenomaiUserMeeting2009

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
Nothing is easier than to denounce  the  evildoer;  nothing  is  more
difficult than to understand him. - Fyodor Dostoevski
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] License Problems for standalone application at u-boot

[Wolfgang Denk]

Dear Peter Chen,

In message <1250571462.6548.21.ca...@nchen-desktop> you wrote:
> 
> > > > The "jump table provided by U-Boot exactly for this purpose" is the
> > > > list of functions exported through the "include/_exports.h" header
> > > > file.
...
> > If you set up your own list of function pointers (in addition or
> > instead of the jump table provided by the "include/_exports.h"
> > header), then this is a form of linking against the U-Boot code, and
> > your application must be released under GPL.
> 
> I am sorry, I can't understand your meaning. For example, at

I'm close to give up. I try to as explicit as possible, and I see no
room for interpretation left, yet you still try to argument.

> "include/_exports.h"
> there is an EXPORT_FUNC(printf), do the standalone application must
> under GPL if
> it uses printf?

No. As explained several times before, the "jump table [is]  provided
by  U-Boot  exactly  for  this purpose", with "this purpose" being to
allow for closed source, proprietary code.

printf() gets exported through the jump table interface, so this is OK
to use in proprietary code.

> Then, what does "include/_exports.h" use?

It uses a list of functions (resp. function pointers) we consider  OK
to be used in closed source applications.

> In your COPYING, it writes:
>   NOTE! This copyright does *not* cover the so-called "standalone"
> applications that use U-Boot services by means of the jump table
> provided by U-Boot exactly for this purpose - this is merely
> considered normal use of U-Boot, and does *not* fall under the 
> heading of "derived work".

Indeed. And I explained this several times before.

> > > Is it free to license at below situation:
> > > The function list which is defined at u-boot/board/myboard/myboard.c,
> > > and all functions in this list
> > > only uses functions at include/_exports.h and some of user-defined
> > > functions.
> > 
> > Your description is really vague; it would be easier if you could
> > give specific code examples or such. If "some of user-defined
> > functions" refers to code that is covered by the GPL, then your
> > application must be released under GPL, too.
> > 
> 
> My code like belows:
> 
> typedef void (*pfn_t) (void);
> pfn_t sc_gps_pfn[] = {
> LoadToMemory,
> SaveData,
> RFPowerCtrl,
> MiscConfig,
> RegisterDspInterruptHandler,
> GetPowerStatus,
> IsUserResume,
> DebugOutput,
> ReturnToBootLoader
> };

OK, so you are setting up a table of your  own  functions.  You  need
this  table only if you link the code containing these functions with
the U-Boot binary - and you do so  most  probably  because  the  code
calls into other U-Boot provided functions.

> We want to open this code, but want to close the code which use this
> function list in binary pattern.

You probably have no choice here. If your code that provides the list
of functions above is linked with U-Boot, you *must* release it under
GPL. No matter if you want or not - if you release your code at all,
it is GPLed.

And your list of functions above thus accesses GPLed  code  which  is
NOT  part  of include/_exports.h. So the GPL exception does NOT apply
to any code that references functions from  this  list,  i.  e.  your
standalone application must be released under GPL, too.

> > What you implement is some form of static linking.
...
> The standalone application is compiled by armcc, and this bin file is
> shared by WinCE and Linux bootloader.
> The standalone application uses bootloader functions by address not by
> name.

That does not matter. Accessing a function by address still means you
are linking against the code (in a stupid way, btw). Your standalone
application has to be released under GPL.


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 quarrel is quickly settled when deserted by one party; there is  no
battle unless there be two.  - Seneca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260/TNY-A9G20 boards

[Albin Tonnerre]

On Tue, Aug 18, 2009 at 12:48:02AM +0200, Jean-Christophe PLAGNIOL-VILLARD 
wrote :
> On 00:13 Tue 18 Aug , Albin Tonnerre wrote:
> > On Mon, Aug 17, 2009 at 11:41:06PM +0200, Jean-Christophe PLAGNIOL-VILLARD 
> > wrote :
> > > > +
> > > > +#ifndef __CONFIG_H
> > > > +#define __CONFIG_H
> > > > +
> > > > +#if defined(CONFIG_tny_a9260) || defined(CONFIG_tny_a9260_nandflash) 
> > > > || defined(CONFIG_tny_a9260_eeprom)
> > > too long
> > > and define must be upper case
> > 
> > Those defines are generated directly from the target names in the Makfile, 
> > and
> > are used for "internal" purposes only. Moving them to uppercase would mean
> > changing the target names from tny_a9g20_nandflash to TNY_A9G20_NANDFLASH, 
> > while
> > the existing Calao-provided BSP uses lowercase. I'd rather not change that.
> you make them uppercase before put them in the config.h

Any hint about how to do that in a Makefile without using things like tr ?

Regards,
-- 
Albin Tonnerre, Free Electrons
Kernel, drivers and embedded Linux development,
consulting, training and support.
http://free-electrons.com


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

[U-Boot] R: R: R: USB EHCI driver

[Rendine Francesco]

Hi Mike,

my patch for USB2.0 on MPC5121e is for u-boot-2009.03. I released for that 
version, so it's reasonable that doesn't fit well on 2009.06.
Regard to your problem and log, as soon as I have time, I see your problem.

Regards,
Francesco.


-Messaggio originale-
Da: Mike Timmons [mailto:michael.joseph.timm...@gmail.com]
Inviato: lun 8/17/2009 4:04
A: Rendine Francesco; u-boot@lists.denx.de
Cc: Detlev Zundel; Mike Timmons
Oggetto: Re: [U-Boot] R: R: USB EHCI driver
 
All,
I'm having trouble resetting my USB (virtual) root port hub following
high speed handshake on the 5121e using USB0+UTMI on the mpc5121e. If
anyone has any idea why root port hub reset typically fails, please
advise. Thanks!

Francesco,

Thank you for your efforts on usb for the 5121e! I took your patch
last week and applied it to u-boot-2009.06 the patch wasn't a perfect
fit for some reason, but it was easy enough for me to extract the code
from your patch file. What version did you intend the patch for, if
not u-boot-2009.06?

Regardless, I'm using a custom board based off the the ADS512101
board. I complete your initialization step and it appears I get the
5121e registers mapped correctly. "USB start" looks for devices, and I
do see debug output to the console when I have a USB memory stick
plugged in.

I also have a USB analyzer, so I can see some action on the bus. However...

It appears I am failing to reset the root port hub after the
high-speed handshake between host and device (memory stick).

My degree of USB ignorance is a painful limitation at this point. I'm
tripping-through specs, the register set, and getting somewhat
familiar with the sequencing, but I'm grinding my gears at this point.

I attach a console log dump. A snippet of the log appears below,
showing where/why the reset fails. I also attach a screen snap of my
USB analyzer showing that some action is occurring on the wire between
the host and the device (memory stick).

This root port hub reset issue appears to be killing any subsequent
device discovery efforts. I DID try the hack of ignoring the reset
failure to see what happens. In this case I do see "2 devices"
detected in the console log (root hub plus my stick I presume), but I
see no additional bus traffic on the analyzer so I figure the reset
failure is my smoking gun.


Any ideas?

console log snippet (see attached full console log dump)

hub_port_reset: resetting port 0...
usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x1 length 0x0
req=3 (0x3), type=35 (0x23), value=4, index=1
Len is 0
usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4
req=0 (0x0), type=163 (0xa3), value=0, index=1
portstatus 101, change 13, 12 Mb/s
STAT_C_CONNECTION = 1 STAT_CONNECTION = 1  USB_PORT_STAT_ENABLE 0
cannot reset port 1!?
port 1 reset change
usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x1 length 0x
0
req=1 (0x1), type=35 (0x23), value=20, index=1
Len is 0
1 USB Device(s) found
   scanning bus for storage devices... i=0
i=1
0 Storage Device(s) found
=>





> On Wed, Jun 24, 2009 at 4:08 AM, Rendine Francesco 
>  wrote:
>>
>> Hi,
>>
>> thanks for your compliments, but I think that there is some work to do about 
>> this driver to support OTG mode and gadget mode.
>> For now I enabled support to host mode, and from my test does it work.
>>
>> I'm preparing the patch, and this will carry away some days because usb 
>> u-boot source code is been re-organized..
>> I developed my patch on u-boot 2009.03, so I have to port my job on last 
>> u-boot version.
>>
>> Regards,
>> Francesco
>>
>> -Messaggio originale-
>> Da: Detlev Zundel [mailto:d...@denx.de]
>> Inviato: mer 6/24/2009 10:51
>> A: Rendine Francesco
>> Cc: Michael Trimarchi; Gupta Maneesh-B18878; u-boot@lists.denx.de
>> Oggetto: Re: [U-Boot] R:  USB EHCI driver
>>
>> Hi Francesco,
>>
>> > I'm successful in provide a preliminary support to EHCI USB Freescale
>> > controller integrated on ADS5121 platform.  I'm preparing a patch to
>> > submit to u-boot mailing list.
>>
>> Congratulations - I'm also looking forward to see and test the patch on
>> our ads5121.
>>
>> Cheers
>>  Detlev
>>
>> --
>> More than any other time in history, mankind faces a crossroads.  One
>> path leads  to despair  and utter  hopelessness.   The other to total
>> extinction.  Let us pray, we have the wisdom to choose correctly.
>>                                        -- Woody Allen
>> --
>> DENX Software Engineering GmbH,      MD: Wolfgang Denk & Detlev Zundel
>> HRB 165235 Munich,  Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>> Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de
>>
>>
>> ___
>> U-Boot mailing list
>> U-Boot@lists.denx.de
>> http://lists.denx.de/mailman/listinfo/u-boot
>>
>

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

Re: [U-Boot] [PATCH] Add support for USB on PSC3 for the mpc5200

[Remy Bohmer]

Hello,

2009/8/13 Eric Millbrandt :
> Support USB on PSC3 on the mpc5200.  Before this patch, enabling USB support
> would reconfigure PSC4 and PSC5 to USB.  The mpc5200 does not support USB
> enabled on both the standard USB port and PSC3.  This patch masks the
> appropriate bits when enabling USB.
>
> Signed-off-by: Eric Millbrandt 
> ---
>  README                 |    4 
>  cpu/mpc5xxx/usb.c      |    6 +-
>  cpu/mpc5xxx/usb_ohci.c |    6 +-
>  3 files changed, 14 insertions(+), 2 deletions(-)

Except from the fact that IMHO this driver belongs in the drivers/usb
section (and being merged into the existing ohci-driver):
Acked-by: Remy Bohmer 

Wolfgang, do you take it in your mpc5xxx tree?

Kind Regards,

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

[U-Boot] [PATCH 10/10] Get the address of env on the SDCard

[Mingkai Hu]

Both the save env and load env operation will call this function
to get the address of env on the SDCard, so the user can control
where to put the env freely.

Signed-off-by: Mingkai Hu 
---
 board/freescale/mpc8536ds/mpc8536ds.c |   43 +
 1 files changed, 43 insertions(+), 0 deletions(-)

diff --git a/board/freescale/mpc8536ds/mpc8536ds.c 
b/board/freescale/mpc8536ds/mpc8536ds.c
index 8c5984b..b32b84b 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -38,6 +38,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "../common/pixis.h"
 #include "../common/sgmii_riser.h"
@@ -705,3 +707,44 @@ void ft_board_setup(void *blob, bd_t *bd)
 #endif
 }
 #endif
+
+#if defined(CONFIG_MMC)
+/*
+ * The environment variables are written to just after the u-boot image
+ * on SDCard, so we must read the MBR to get the start address and code
+ * length of the u-boot image, then calculate the address of the env.
+ */
+int mmc_get_env_addr(int dev, u32 *env_addr)
+{
+   uint blklen;
+   int ret, code_offset, code_len;
+   uchar *tmp_buf;
+   struct mmc *mmc = find_mmc_device(dev);
+
+   mmc_init(mmc);
+
+   blklen = mmc->read_bl_len;
+   tmp_buf = (uchar *)malloc(blklen);
+   if (!tmp_buf)
+   return 1;
+
+   /* read out the first block, get the config data information */
+   ret = mmc_read(mmc, 0, tmp_buf, blklen);
+   if (ret) {
+   free(tmp_buf);
+   return 1;
+   }
+
+   /* Get the Source Address, from offset 0x50 */
+   code_offset = *(unsigned long *)(tmp_buf + 0x50);
+
+   /* Get the code size from offset 0x48 */
+   code_len = *(unsigned long *)(tmp_buf + 0x48);
+
+   *env_addr = code_offset + code_len;
+
+   free(tmp_buf);
+
+   return 0;
+}
+#endif
-- 
1.5.4

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

[U-Boot] [PATCH 09/10] Add support for save environment variable to MMC/SD card

[Mingkai Hu]

Whether booting from MMC/SD card or not, the environment variables
can be saved on it, this patch add the operation support.

Signed-off-by: Mingkai Hu 
---
 common/Makefile |1 +
 common/cmd_nvedit.c |3 +-
 common/env_sdcard.c |  135 +++
 3 files changed, 138 insertions(+), 1 deletions(-)
 create mode 100644 common/env_sdcard.c

diff --git a/common/Makefile b/common/Makefile
index 3781738..ce6a7da 100644
--- a/common/Makefile
+++ b/common/Makefile
@@ -61,6 +61,7 @@ COBJS-$(CONFIG_ENV_IS_IN_NAND) += env_nand.o
 COBJS-$(CONFIG_ENV_IS_IN_NVRAM) += env_nvram.o
 COBJS-$(CONFIG_ENV_IS_IN_ONENAND) += env_onenand.o
 COBJS-$(CONFIG_ENV_IS_IN_SPI_FLASH) += env_sf.o
+COBJS-$(CONFIG_ENV_IS_IN_SDCARD) += env_sdcard.o
 COBJS-$(CONFIG_ENV_IS_NOWHERE) += env_nowhere.o
 
 # command
diff --git a/common/cmd_nvedit.c b/common/cmd_nvedit.c
index 2186205..83969ef 100644
--- a/common/cmd_nvedit.c
+++ b/common/cmd_nvedit.c
@@ -60,9 +60,10 @@ DECLARE_GLOBAL_DATA_PTR;
 !defined(CONFIG_ENV_IS_IN_NVRAM)   && \
 !defined(CONFIG_ENV_IS_IN_ONENAND) && \
 !defined(CONFIG_ENV_IS_IN_SPI_FLASH)   && \
+!defined(CONFIG_ENV_IS_IN_SDCARD)  && \
 !defined(CONFIG_ENV_IS_NOWHERE)
 # error Define one of CONFIG_ENV_IS_IN_{EEPROM|FLASH|DATAFLASH|ONENAND|\
-SPI_FLASH|MG_DISK|NVRAM|NOWHERE}
+SPI_FLASH|MG_DISK|NVRAM|SDCARD|NOWHERE}
 #endif
 
 #define XMK_STR(x) #x
diff --git a/common/env_sdcard.c b/common/env_sdcard.c
new file mode 100644
index 000..ce73358
--- /dev/null
+++ b/common/env_sdcard.c
@@ -0,0 +1,135 @@
+/*
+ * Copyright (C) 2009 Freescale Semiconductor, Inc.
+ *
+ * Changelog:
+ * July 2008, Intial version.
+ * June 2009, align to the MMC framework.
+ *
+ * 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 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* references to names in env_common.c */
+extern uchar default_environment[];
+extern int mmc_get_env_addr(int dev, u32 *env_addr);
+
+char *env_name_spec = "SD CARD";
+env_t *env_ptr;
+
+uchar env_get_char_spec(int index)
+{
+   return *((uchar *)(gd->env_addr + index));
+}
+
+static int readenv(int dev, size_t offset, u_char *buf)
+{
+   int ret;
+   struct mmc *mmc = find_mmc_device(dev);
+
+   mmc_init(mmc);
+
+   ret = mmc_read(mmc, offset, buf, CONFIG_ENV_SIZE);
+   if (ret)
+   return 1;
+
+   return 0;
+}
+
+static int writeenv(int dev, size_t offset, u_char *buf)
+{
+   int env_blknr, env_blkcnt, n;
+   uint blklen;
+   struct mmc *mmc = find_mmc_device(dev);
+
+   mmc_init(mmc);
+
+   blklen = mmc->write_bl_len;
+   env_blknr = offset / blklen;
+   env_blkcnt = CONFIG_ENV_SIZE / blklen;
+
+   n = mmc->block_dev.block_write(dev, env_blknr, env_blkcnt, buf);
+   if (n != env_blkcnt)
+   return 1;
+
+   return 0;
+}
+
+int saveenv(void)
+{
+   int ret;
+   int dev = 0;
+   u32 env_addr;
+
+   ret = mmc_get_env_addr(dev, &env_addr);
+   if (ret) {
+   puts("FAILED!\n");
+   return 1;
+   }
+
+   ret = writeenv(dev, env_addr, (u_char *) env_ptr);
+   if (ret)
+   return 1;
+
+   puts("done\n");
+   gd->env_valid = 1;
+
+   return ret;
+}
+
+void env_relocate_spec(void)
+{
+   int ret;
+   int dev = 0;
+   u32 env_addr;
+
+   ret = mmc_get_env_addr(dev, &env_addr);
+   if (ret)
+   goto err_read;
+
+   ret = readenv(dev, env_addr, (u_char *) env_ptr);
+   if (ret)
+   goto err_read;
+
+   if (crc32(0, env_ptr->data, ENV_SIZE) != env_ptr->crc)
+   goto err_crc;
+
+   gd->env_valid = 1;
+
+   return;
+
+err_read:
+err_crc:
+   puts("*** Warning - bad CRC, using default environment\n\n");
+
+   set_default_env();
+}
+
+int env_init(void)
+{
+   /* eSDHC isn't usable before relocation */
+   gd->env_addr  = (ulong)&default_environment[0];
+   gd->env_valid = 1;
+
+   return 0;
+}
-- 
1.5.4

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

[U-Boot] [PATCH 08/10] Make mmc init come before env_relocate

[Mingkai Hu]

If the environment variables are saved on the MMC/SD card,
env_relocat can't relocate env from MMC/SD card without mmc init.

Signed-off-by: Mingkai Hu 
---
 lib_ppc/board.c |   12 ++--
 1 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/lib_ppc/board.c b/lib_ppc/board.c
index 6dd4d56..b788580 100644
--- a/lib_ppc/board.c
+++ b/lib_ppc/board.c
@@ -849,6 +849,12 @@ void board_init_r (gd_t *id, ulong dest_addr)
nand_init();/* go init the NAND */
 #endif
 
+#ifdef CONFIG_GENERIC_MMC
+   WATCHDOG_RESET ();
+   puts ("MMC:  ");
+   mmc_initialize (bd);
+#endif
+
/* relocate environment function pointers etc. */
env_relocate ();
 
@@ -1015,12 +1021,6 @@ void board_init_r (gd_t *id, ulong dest_addr)
scsi_init ();
 #endif
 
-#ifdef CONFIG_GENERIC_MMC
-   WATCHDOG_RESET ();
-   puts ("MMC:  ");
-   mmc_initialize (bd);
-#endif
-
 #if defined(CONFIG_CMD_DOC)
WATCHDOG_RESET ();
puts ("DOC:   ");
-- 
1.5.4

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

[U-Boot] [PATCH 05/10] NAND boot: MPC8536DS support

[Mingkai Hu]

MPC8536E can support booting from NAND flash which uses the
image u-boot-nand.bin. This image contains two parts: a 4K
NAND loader and a main U-Boot image. The former is appended
to the latter to produce u-boot-nand.bin. The 4K NAND loader
includes the corresponding nand_spl directory, along with the
code twisted by CONFIG_NAND_SPL. The main U-Boot image just
like a general U-Boot image except the parts that included by
CONFIG_SYS_RAMBOOT.

When power on, eLBC will automatically load from bank 0 the
4K NAND loader into the FCM buffer RAM where CPU can execute
the boot code directly. In the first stage, the NAND loader
copies itself to RAM or L2SRAM to free up the FCM buffer RAM,
then loads the main image from NAND flash to RAM or L2SRAM
and boot from it.

This patch implements the NAND loader to load the main image
into L2SRAM, so the main image can configure the RAM by using
SPD EEPROM. In the first stage, the NAND loader copies itself
to the second to last 4K address space, and uses the last 4K
address space as the initial RAM for stack.

Obviously, the size of L2SRAM shouldn't be less than the size
of the image used. If so, the workaround is to generate another
image that includes the code to configure the RAM by SPD and
load it to L2SRAM first, then relocate the main image to RAM
to boot up.

Signed-off-by: Mingkai Hu 
---
 Makefile   |5 +-
 board/freescale/mpc8536ds/config.mk|6 +
 board/freescale/mpc8536ds/tlb.c|   11 ++
 board/freescale/mpc8536ds/u-boot-nand.lds  |  140 
 cpu/mpc85xx/nand_init.c|  109 ++
 include/configs/MPC8536DS.h|   85 +++
 nand_spl/board/freescale/mpc8536ds/Makefile|  119 
 nand_spl/board/freescale/mpc8536ds/nand_boot.c |   99 +
 nand_spl/board/freescale/mpc8536ds/u-boot.lds  |   67 +++
 9 files changed, 619 insertions(+), 22 deletions(-)
 create mode 100644 board/freescale/mpc8536ds/u-boot-nand.lds
 create mode 100644 cpu/mpc85xx/nand_init.c
 create mode 100644 nand_spl/board/freescale/mpc8536ds/Makefile
 create mode 100644 nand_spl/board/freescale/mpc8536ds/nand_boot.c
 create mode 100644 nand_spl/board/freescale/mpc8536ds/u-boot.lds

diff --git a/Makefile b/Makefile
index 329e0f5..db69ef3 100644
--- a/Makefile
+++ b/Makefile
@@ -2406,8 +2406,9 @@ vme8349_config:   unconfig
 ATUM8548_config:   unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx atum8548
 
-MPC8536DS_config:   unconfig
-   @$(MKCONFIG) $(@:_config=) ppc mpc85xx mpc8536ds freescale
+MPC8536DS_config \
+MPC8536DS_NAND_config: unconfig
+   @$(MKCONFIG) -t $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale
 
 MPC8540ADS_config: unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx mpc8540ads freescale
diff --git a/board/freescale/mpc8536ds/config.mk 
b/board/freescale/mpc8536ds/config.mk
index 9775ff4..f747fe8 100644
--- a/board/freescale/mpc8536ds/config.mk
+++ b/board/freescale/mpc8536ds/config.mk
@@ -23,6 +23,12 @@
 #
 # mpc8536ds board
 #
+ifndef NAND_SPL
+ifeq ($(CONFIG_OPT_NAND),y)
+TEXT_BASE = 0xf8f82000
+endif
+endif
+
 ifndef TEXT_BASE
 TEXT_BASE = 0xeff8
 endif
diff --git a/board/freescale/mpc8536ds/tlb.c b/board/freescale/mpc8536ds/tlb.c
index 35a13d4..dc52d7f 100644
--- a/board/freescale/mpc8536ds/tlb.c
+++ b/board/freescale/mpc8536ds/tlb.c
@@ -71,6 +71,17 @@ struct fsl_e_tlb_entry tlb_table[] = {
SET_TLB_ENTRY(1, CONFIG_SYS_NAND_BASE, CONFIG_SYS_NAND_BASE_PHYS,
  MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
  0, 4, BOOKE_PAGESZ_1M, 1),
+
+#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L2_ADDR)
+   /* *I*G - L2SRAM */
+   SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L2_ADDR, CONFIG_SYS_INIT_L2_ADDR_PHYS,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 5, BOOKE_PAGESZ_256K, 1),
+   SET_TLB_ENTRY(1, CONFIG_SYS_INIT_L2_ADDR + 0x4,
+ CONFIG_SYS_INIT_L2_ADDR_PHYS + 0x4,
+ MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G,
+ 0, 6, BOOKE_PAGESZ_256K, 1),
+#endif
 };
 
 int num_tlb_entries = ARRAY_SIZE(tlb_table);
diff --git a/board/freescale/mpc8536ds/u-boot-nand.lds 
b/board/freescale/mpc8536ds/u-boot-nand.lds
new file mode 100644
index 000..c14e946
--- /dev/null
+++ b/board/freescale/mpc8536ds/u-boot-nand.lds
@@ -0,0 +1,140 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * 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

[U-Boot] [PATCH 07/10] Add README.mpc8536ds

[Mingkai Hu]

Add boot from NAND/eSDHC/eSPI description

Signed-off-by: Mingkai Hu 
---
 doc/README.mpc8536ds |  127 ++
 1 files changed, 127 insertions(+), 0 deletions(-)
 create mode 100644 doc/README.mpc8536ds

diff --git a/doc/README.mpc8536ds b/doc/README.mpc8536ds
new file mode 100644
index 000..4d0bee0
--- /dev/null
+++ b/doc/README.mpc8536ds
@@ -0,0 +1,127 @@
+Overview:
+=
+
+The MPC8536E integrates a PowerPC processor core with system logic
+required for imaging, networking, and communications applications.
+
+Boot from NAND:
+===
+
+The MPC8536E is capable of booting from NAND flash which uses the image
+u-boot-nand.bin. This image contains two parts: a first stage image(also
+call 4K NAND loader and a second stage image. The former is appended to
+the latter to produce u-boot-nand.bin.
+
+The bootup process can be divided into two stages: the first stage will
+configure the L2SRAM, then copy the second stage image to L2SRAM and jump
+to it. The second stage image is to configure all the hardware and boot up
+to U-Boot command line.
+
+The 4K NAND loader's code comes from the corresponding nand_spl directory,
+along with the code twisted by CONFIG_NAND_SPL. The macro CONFIG_NAND_SPL
+is mainly used to shrink the code size to the 4K size limitation.
+
+The macro CONFIG_SYS_RAMBOOT is used to control the code to produce the
+second stage image. It's set in the board config file when boot from NAND
+is selected.
+
+Build and boot steps
+
+
+1. Building image
+   make MPC8536DS_NAND_config
+   make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
+
+2. Change dip-switch
+   SW2[5-8] = 1011
+   SW9[1-3] = 101
+   Note: 1 stands for 'on', 0 stands for 'off'
+
+3. Flash image
+   tftp 100 u-boot-nand.bin
+   nand erase 0 a
+   nand write 100 0 a
+
+Boot from On-chip ROM:
+==
+
+The MPC8536E is capable of booting from the on-chip ROM - boot from eSDHC
+and boot from eSPI. When power on, the porcessor excutes the ROM code to
+initialize the eSPI/eSDHC controller, and loads the mian U-Boot image from
+the memory device that interfaced to the controller, such as the SDCard or
+SPI EEPROM, to the target memory, e.g. SDRAM or L2SRAM, then boot from it.
+
+The memory device should contain a specific data structure with control word
+and config word at the fixed address. The config word direct the process how
+to config the memory device, and the control word direct the processor where
+to find the image on the memory device, or where copy the main image to. The
+user can use any method to store the data structure to the memory device, only
+if store it on the assigned address.
+
+Build and boot steps
+
+
+For boot from eSDHC:
+1. Build image
+   make MPC8536DS_SDCARD_config
+   make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
+
+2. Change dip-switch
+   SW2[5-8] = 0111
+   SW3[1]   = 0
+   SW8[7]   = 0 - The on-board SD/MMC slot is active
+   SW8[7]   = 1 - The externel SD/MMC slot is active
+
+3. Put image to SDCard
+   Put the follwing info at the assigned address on the SDCard:
+
+  Offset   |   Data | Description
+   
+   | 0x40-0x43 | 0x424F4F54 | BOOT signature  |
+   
+   | 0x48-0x4B | 0x0008 | u-boot.bin's size   |
+   
+   | 0x50-0x53 | 0x | u-boot.bin's Addr on SDCard |
+   
+   | 0x58-0x5B | 0xF8F8 | Target Address  |
+   ---
+   | 0x60-0x63 | 0xF8FFF000 | Execution Starting Address  |
+   
+   | 0x68-0x6B | 0x6| Number of Config Addr/Data  |
+   
+   | 0x80-0x83 | 0xFF720100 | Config Addr 1   |
+   | 0x84-0x87 | 0xF8F8 | Config Data 1   |
+   
+   | 0x88-0x8b | 0xFF720e44 | Config Addr 2   |
+   | 0x8c-0x8f | 0x000C | Config Data 2   |
+   
+   | 0x90-0x93 | 0xFF72 | Config Addr 3   |
+   | 0x94-0x97 | 0x8001 | Config Data 3   |
+   
+   | 0x98-0x9b | 0xFF72e40e | Config Addr 4   |
+   | 0x9c-0x9f | 0x0040 | Config Data 4   |
+   
+   | 0xa0-0xa3 | 0x4001 | Config Addr 5   |
+   | 0xa4-0xa7 | 0x0100 | Con

[U-Boot] [PATCH 06/10] On-chip ROM boot: MPC8536DS support

[Mingkai Hu]

The MPC8536E is capable of booting from the on-chip ROM - boot from
eSDHC and boot from eSPI. When power on, the porcessor excutes the
ROM code to initialize the eSPI/eSDHC controller, and loads the mian
U-Boot image from the memory device that interfaced to the controller,
such as the SDCard or SPI EEPROM, to the target memory, e.g. SDRAM or
L2SRAM, then boot from it.

The memory device should contain a specific data structure with control
word and config word at the fixed address. The config word direct the
process how to config the memory device, and the control word direct
the processor where to find the image on the memory device, or where
copy the main image to. The user can use any method to store the data
structure to the memory device, only if store it on the assigned address.

The on-chip ROM code will map the whole 4GB address space by setting
entry0 in the TLB1, so the main image need to switch to Address space 1
to disable this mapping and map the address space again.

This patch implements loading the mian U-Boot image into L2SRAM, so
the image can configure the system memory by using SPD EEPROM.

Signed-off-by: Mingkai Hu 
---
 Makefile|4 +++-
 board/freescale/mpc8536ds/config.mk |8 
 include/configs/MPC8536DS.h |   10 +-
 3 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index db69ef3..c4d4906 100644
--- a/Makefile
+++ b/Makefile
@@ -2407,7 +2407,9 @@ ATUM8548_config:  unconfig
@$(MKCONFIG) $(@:_config=) ppc mpc85xx atum8548
 
 MPC8536DS_config \
-MPC8536DS_NAND_config: unconfig
+MPC8536DS_NAND_config \
+MPC8536DS_SDCARD_config \
+MPC8536DS_SPIFLASH_config: unconfig
@$(MKCONFIG) -t $(@:_config=) MPC8536DS ppc mpc85xx mpc8536ds freescale
 
 MPC8540ADS_config: unconfig
diff --git a/board/freescale/mpc8536ds/config.mk 
b/board/freescale/mpc8536ds/config.mk
index f747fe8..d6b721b 100644
--- a/board/freescale/mpc8536ds/config.mk
+++ b/board/freescale/mpc8536ds/config.mk
@@ -29,6 +29,14 @@ TEXT_BASE = 0xf8f82000
 endif
 endif
 
+ifeq ($(CONFIG_OPT_SDCARD),y)
+TEXT_BASE = 0xf8f8
+endif
+
+ifeq ($(CONFIG_OPT_SPIFLASH),y)
+TEXT_BASE = 0xf8f8
+endif
+
 ifndef TEXT_BASE
 TEXT_BASE = 0xeff8
 endif
diff --git a/include/configs/MPC8536DS.h b/include/configs/MPC8536DS.h
index 3204bdc..63b86f6 100644
--- a/include/configs/MPC8536DS.h
+++ b/include/configs/MPC8536DS.h
@@ -207,7 +207,8 @@ extern unsigned long get_board_ddr_clk(unsigned long dummy);
 
 #define CONFIG_SYS_MONITOR_BASETEXT_BASE   /* start of monitor */
 
-#if defined(CONFIG_SYS_SPL) || defined(CONFIG_NAND_U_BOOT)
+#if defined(CONFIG_SYS_SPL) || defined(CONFIG_NAND_U_BOOT) \
+   || defined(CONFIG_OPT_SDCARD) || defined(CONFIG_OPT_SPIFLASH)
 #define CONFIG_SYS_RAMBOOT
 #else
 #undef CONFIG_SYS_RAMBOOT
@@ -549,6 +550,13 @@ extern unsigned long get_board_ddr_clk(unsigned long 
dummy);
#define CONFIG_ENV_IS_IN_NAND   1
#define CONFIG_ENV_SIZE CONFIG_SYS_NAND_BLOCK_SIZE
#define CONFIG_ENV_OFFSET   ((512 * 1024) + 
CONFIG_SYS_NAND_BLOCK_SIZE)
+#elif defined(CONFIG_OPT_SDCARD)
+#define CONFIG_ENV_IS_IN_SDCARD 1
+#define CONFIG_ENV_SIZE 0x2000
+#elif defined(CONFIG_OPT_SPIFLASH)
+   #define CONFIG_ENV_IS_NOWHERE   1   /* Store ENV in memory only */
+   #define CONFIG_ENV_ADDR (CONFIG_SYS_MONITOR_BASE - 0x1000)
+   #define CONFIG_ENV_SIZE 0x2000
 #endif
 #else
#define CONFIG_ENV_IS_IN_FLASH  1
-- 
1.5.4

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

[U-Boot] [PATCH 03/10] Add L2SRAM Register's macro definition

[Mingkai Hu]

Signed-off-by: Mingkai Hu 
---
 cpu/mpc85xx/cpu_init.c   |5 +++--
 include/asm-ppc/immap_85xx.h |5 +
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
index 41de694..c4d1a9d 100644
--- a/cpu/mpc85xx/cpu_init.c
+++ b/cpu/mpc85xx/cpu_init.c
@@ -330,11 +330,12 @@ int cpu_init_r(void)
break;
}
 
-   if (l2cache->l2ctl & 0x8000) {
+   if (l2cache->l2ctl & MPC85xx_L2CTL_L2E) {
puts("already enabled");
l2srbar = l2cache->l2srbar0;
 #ifdef CONFIG_SYS_INIT_L2_ADDR
-   if (l2cache->l2ctl & 0x0001 && l2srbar >= 
CONFIG_SYS_FLASH_BASE) {
+   if (l2cache->l2ctl & MPC85xx_L2CTL_L2SRAM_ENTIRE
+   && l2srbar >= CONFIG_SYS_FLASH_BASE) {
l2srbar = CONFIG_SYS_INIT_L2_ADDR;
l2cache->l2srbar0 = l2srbar;
printf("moving to 0x%08x", CONFIG_SYS_INIT_L2_ADDR);
diff --git a/include/asm-ppc/immap_85xx.h b/include/asm-ppc/immap_85xx.h
index 0efef05..375d804 100644
--- a/include/asm-ppc/immap_85xx.h
+++ b/include/asm-ppc/immap_85xx.h
@@ -411,6 +411,11 @@ typedef struct ccsr_l2cache {
charres15[420];
 } ccsr_l2cache_t;
 
+#define MPC85xx_L2CTL_L2E  0x8000
+#define MPC85xx_L2CTL_L2SRAM_ENTIRE0x0001
+#define MPC85xx_L2ERRDIS_MBECC 0x0008
+#define MPC85xx_L2ERRDIS_SBECC 0x0004
+
 /*
  * DMA Registers(0x2_1000-0x2_2000)
  */
-- 
1.5.4

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

[U-Boot] [PATCH 02/10] NAND boot: change NAND loader's relocate SP to CONFIG param

[Mingkai Hu]

So that we can set the NAND loader's relocate stack pointer
to the value other than the relocate address + 0x1.

Signed-off-by: Mingkai Hu 
---
 board/freescale/mpc8313erdb/mpc8313erdb.c |2 +-
 board/sheldon/simpc8313/simpc8313.c   |2 +-
 include/configs/MPC8313ERDB.h |1 +
 include/configs/SIMPC8313.h   |1 +
 4 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/board/freescale/mpc8313erdb/mpc8313erdb.c 
b/board/freescale/mpc8313erdb/mpc8313erdb.c
index 9ffd4bf..e5f62ae 100644
--- a/board/freescale/mpc8313erdb/mpc8313erdb.c
+++ b/board/freescale/mpc8313erdb/mpc8313erdb.c
@@ -140,7 +140,7 @@ void board_init_f(ulong bootflag)
puts("NAND boot... ");
init_timebase();
initdram(0);
-   relocate_code(CONFIG_SYS_NAND_U_BOOT_RELOC + 0x1, (gd_t *)gd,
+   relocate_code(CONFIG_SYS_NAND_U_BOOT_RELOC_SP, (gd_t *)gd,
  CONFIG_SYS_NAND_U_BOOT_RELOC);
 }
 
diff --git a/board/sheldon/simpc8313/simpc8313.c 
b/board/sheldon/simpc8313/simpc8313.c
index 25e5c24..1044de2 100644
--- a/board/sheldon/simpc8313/simpc8313.c
+++ b/board/sheldon/simpc8313/simpc8313.c
@@ -112,7 +112,7 @@ void board_init_f(ulong bootflag)
puts("NAND boot... ");
init_timebase();
initdram(0);
-   relocate_code(CONFIG_SYS_NAND_U_BOOT_RELOC + 0x1, (gd_t *)gd,
+   relocate_code(CONFIG_SYS_NAND_U_BOOT_RELOC_SP, (gd_t *)gd,
  CONFIG_SYS_NAND_U_BOOT_RELOC);
 }
 
diff --git a/include/configs/MPC8313ERDB.h b/include/configs/MPC8313ERDB.h
index d9aa60b..4645d3b 100644
--- a/include/configs/MPC8313ERDB.h
+++ b/include/configs/MPC8313ERDB.h
@@ -242,6 +242,7 @@
 #define CONFIG_SYS_NAND_U_BOOT_START 0x00100100
 #define CONFIG_SYS_NAND_U_BOOT_OFFS  16384
 #define CONFIG_SYS_NAND_U_BOOT_RELOC 0x0001
+#define CONFIG_SYS_NAND_U_BOOT_RELOC_SP (CONFIG_SYS_NAND_U_BOOT_RELOC + 
0x1)
 
 #define CONFIG_SYS_NAND_BR_PRELIM  ( CONFIG_SYS_NAND_BASE \
| (2

[U-Boot] [PATCH 04/10] 85xx: add boot from NAND/eSDHC/eSPI support

[Mingkai Hu]

The MPC8536E is capable of booting form NAND/eSDHC/eSPI, this patch
implements these three bootup methods in a unified way - all of these
use the general cpu/mpc85xx/start.S, and load the main image to L2SRAM
which lets us use the SPD to initialize the SDRAM.

For all three bootup methods, the bootup process can be divided into two
stages: the first stage will initialize the corresponding controller,
configure the L2SRAM, then copy the second stage image to L2SRAM and
jump to it. The second stage image is just like the general U-Boot image
to configure all the hardware and boot up to U-Boot command line.

When boot from NAND, the eLBC controller will first load the first stage
image to internal 4K RAM buffer because it's also stored on the NAND
flash. The first stage image, also call 4K NADN loader, will initialize
the L2SRAM, load the second stage image to L2SRAM and jump to it. The 4K
NAND loader's code comes from the corresponding nand_spl directory, along
with the code twisted by CONFIG_NAND_SPL.

When boot from eSDHC/eSPI, there's no such a first stage image because
the CPU ROM code does the same work. It will initialize the L2SRAM
according to the config addr/word pairs on the fixed address and
initialize the eSDHC/eSPI controller, then load the second stage image
to L2SRAM and jump to it.

The macro CONFIG_SYS_RAMBOOT is used to control the code to produce the
second stage image for all different bootup methods. It's set in the
board config file when one of the bootup methods above is selected.

Signed-off-by: Mingkai Hu 
---
 cpu/mpc85xx/cpu_init.c |   19 +++
 cpu/mpc85xx/start.S|   23 ++-
 cpu/mpc85xx/tlb.c  |4 
 drivers/misc/fsl_law.c |2 ++
 4 files changed, 47 insertions(+), 1 deletions(-)

diff --git a/cpu/mpc85xx/cpu_init.c b/cpu/mpc85xx/cpu_init.c
index c4d1a9d..c931d4a 100644
--- a/cpu/mpc85xx/cpu_init.c
+++ b/cpu/mpc85xx/cpu_init.c
@@ -291,6 +291,25 @@ int cpu_init_r(void)
 
asm("msync;isync");
cache_ctl = l2cache->l2ctl;
+
+#if defined(CONFIG_SYS_RAMBOOT) && defined(CONFIG_SYS_INIT_L2_ADDR)
+   if (cache_ctl & MPC85xx_L2CTL_L2E) {
+   /* Clear L2 SRAM memory-mapped base address */
+   out_be32(&l2cache->l2srbar0, 0x0);
+   out_be32(&l2cache->l2srbar1, 0x0);
+
+   /* set MBECCDIS=0, SBECCDIS=0 */
+   clrbits_be32(&l2cache->l2errdis,
+   (MPC85xx_L2ERRDIS_MBECC |
+MPC85xx_L2ERRDIS_SBECC));
+
+   /* set L2E=0, L2SRAM=0 */
+   clrbits_be32(&l2cache->l2ctl,
+   (MPC85xx_L2CTL_L2E |
+MPC85xx_L2CTL_L2SRAM_ENTIRE));
+   }
+#endif
+
l2siz_field = (cache_ctl >> 28) & 0x3;
 
switch (l2siz_field) {
diff --git a/cpu/mpc85xx/start.S b/cpu/mpc85xx/start.S
index 4f7236f..de13c25 100644
--- a/cpu/mpc85xx/start.S
+++ b/cpu/mpc85xx/start.S
@@ -57,10 +57,12 @@
GOT_ENTRY(_GOT2_TABLE_)
GOT_ENTRY(_FIXUP_TABLE_)
 
+#ifndef CONFIG_NAND_SPL
GOT_ENTRY(_start)
GOT_ENTRY(_start_of_vectors)
GOT_ENTRY(_end_of_vectors)
GOT_ENTRY(transfer_to_handler)
+#endif
 
GOT_ENTRY(__init_end)
GOT_ENTRY(_end)
@@ -235,10 +237,11 @@ _start_e500:
 
 #endif /* CONFIG_MPC8569 */
 
-   /* create a temp mapping in AS=1 to the 4M boot window */
lis r6,FSL_BOOKE_MAS0(1, 15, 0)@h
ori r6,r6,FSL_BOOKE_MAS0(1, 15, 0)@l
 
+#ifndef CONFIG_SYS_RAMBOOT
+   /* create a temp mapping in AS=1 to the 4M boot window */
lis r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@h
ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_4M)@l
 
@@ -248,6 +251,20 @@ _start_e500:
/* The 85xx has the default boot window 0xff80 - 0x */
lis r9,FSL_BOOKE_MAS3(0xffc0, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h
ori r9,r9,FSL_BOOKE_MAS3(0xffc0, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
+#else
+   /*
+* create a temp mapping in AS=1 to the 1M TEXT_BASE space, the main
+* image has been relocated to TEXT_BASE on the second stage.
+*/
+   lis r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_1M)@h
+   ori r7,r7,FSL_BOOKE_MAS1(1, 1, 0, 1, BOOKE_PAGESZ_1M)@l
+
+   lis r8,FSL_BOOKE_MAS2(TEXT_BASE, (MAS2_I|MAS2_G))@h
+   ori r8,r8,FSL_BOOKE_MAS2(TEXT_BASE, (MAS2_I|MAS2_G))@l
+
+   lis r9,FSL_BOOKE_MAS3(TEXT_BASE, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@h
+   ori r9,r9,FSL_BOOKE_MAS3(TEXT_BASE, 0, (MAS3_SX|MAS3_SW|MAS3_SR))@l
+#endif
 
mtspr   MAS0,r6
mtspr   MAS1,r7
@@ -359,6 +376,7 @@ _start_cont:
bl  board_init_f
isync
 
+#ifndef CONFIG_NAND_SPL
. = EXC_OFF_SYS_RESET
.globl  _start_of_vectors
 _start_of_vectors:
@@ -813,6 +831,7 @@ in32:
 in32r:
lwbrx   r3,r0,r3
blr
+#endif  /* !CONFIG_NAND_SPL */
 
 
/*

[U-Boot] [PATCH 01/10] mkconfig: parse top level makefile target to multiple config targets

[Mingkai Hu]

To simplify the top level makefile it useful to be able to paree
the top level makefile target to multiple individual target, then
put them to the config.h and config.mk, leave the board config file
and board makefile to handle the different targets.
---
 mkconfig |   11 +++
 1 files changed, 11 insertions(+), 0 deletions(-)

diff --git a/mkconfig b/mkconfig
index b0bbbd1..d9e216d 100755
--- a/mkconfig
+++ b/mkconfig
@@ -10,12 +10,14 @@
 
 APPEND=no  # Default: Create new config file
 BOARD_NAME=""  # Name to print in make output
+TARGETS=""
 
 while [ $# -gt 0 ] ; do
case "$1" in
--) shift ; break ;;
-a) shift ; APPEND=yes ;;
-n) shift ; BOARD_NAME="${1%%_config}" ; shift ;;
+   -t) shift ; TARGETS="`echo $1 | sed 's:_: :g'` ${TARGETS}" ; shift ;;
*)  break ;;
esac
 done
@@ -72,6 +74,10 @@ echo "BOARD  = $4" >> config.mk
 
 [ "$6" ] && [ "$6" != "NULL" ] && echo "SOC= $6" >> config.mk
 
+for i in ${TARGETS} ; do
+   echo "CONFIG_OPT_${i} = y" >> config.mk ;
+done
+
 #
 # Create board specific header file
 #
@@ -82,6 +88,11 @@ else
> config.h  # Create new config file
 fi
 echo "/* Automatically generated - do not edit */" >>config.h
+
+for i in ${TARGETS} ; do
+   echo "#define CONFIG_OPT_${i} 1" >>config.h ;
+done
+
 echo "#include " >>config.h
 echo "#include " >>config.h
 
-- 
1.5.4

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

[U-Boot] [PATCH 00/10] add boot from NAND/eSDHC/eSPI support

[Mingkai Hu]

The MPC8536E is capable of booting form NAND/eSDHC/eSPI, this patchset
implements these three bootup methods in a unified way - all of these
use the general cpu/mpc85xx/start.S, and load the second stage image
to L2SRAM which lets us use the SPD to initialize the SDRAM.

[PATCH 01/10] mkconfig: parse top level makefile target to multiple config 
targets
[PATCH 02/10] NAND boot: change NAND loader's relocate SP to CONFIG param
[PATCH 03/10] Add L2SRAM Register's macro definition

[PATCH 04/10] 85xx: add boot from NAND/eSDHC/eSPI support
[PATCH 05/10] NAND boot: MPC8536DS support
[PATCH 06/10] On-chip ROM boot: MPC8536DS support

Add description for the different boot method:
[PATCH 07/10] Add README.mpc8536ds

The follow three patches implement save env to SDCard:
[PATCH 08/10] Make mmc init come before env_relocate
[PATCH 09/10] Add support for save environment variable to MMC/SD card
[PATCH 10/10] Get the address of env on the SDCard


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

[U-Boot] Please pull u-boot-ppc4xx/master

[Stefan Roese]

Hi Wolfgang,

please pull the following bug fix:

Thanks,
Stefan


The following changes since commit 7dedefdf749ff02c1086f7ddb8cb83a77b00d030:
  John Schmoller (1):
flash: Fix CFI buffer size bug

are available in the git repository at:

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

Stefan Roese (1):
  ppc4xx: Fix "chip_config" command for AMCC Arches

 board/amcc/canyonlands/chip_config.c |   34 ++
 include/configs/canyonlands.h|4 
 2 files changed, 22 insertions(+), 16 deletions(-)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ppc4xx: Fix "chip_config" command for AMCC Arches

[Stefan Roese]

On Monday 17 August 2009 17:14:28 Stefan Roese wrote:
> This patch fixes the "chip_config" command for I2C bootstrap EEPROM
> configuration. First it changes the I2C bootstrap EEPROM address to
> 0x54 as this is used on Arches (instead of 0x52 on Canyonlands/
> Glacier). Additionally, the NAND bootstrap settings are removed
> for Arches since Arches doesn't support NAND-booting.
>
> Signed-off-by: Stefan Roese 

Applied to u-boot-ppc4xx. Thanks.

Cheers,
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