[U-Boot] Run hello world with Uboot !

[thaoth]

Hi,

I'm working on SH7727　T-Engine Board (MS7727CP02)(sh3) and I'm trying to
load Hello World example in U-boot (use Serial, ymodem and hello_world.bin), 
...
=> loady 0x8e00
## Ready for binary (ymodem) download to 0x8E00 at 115200 bps...
CCCxyzModem - CRC mode, 2(SOH)/69(STX)/0(CAN) packets, 5 retries
## Total Size  = 0x000112ec = 70380 Bytes
=> go 0x8e00
## Starting application at 0x8E00 ...
...
but my board reset when I run Hello world. I also try with hello_world.srec
(serial, Kermit mode) and an uboot image:
"mkimage -A sh -O u-boot -T standalone -C none -a 0x8c00 -e 0x8c00
-n 'Hello Image' -d examples/hello_world hello.img"
...
=> loady
## Ready for binary (ymodem) download to 0x8E00 at 115200 bps...
CCxyzModem - CRC mode, 2(SOH)/69(STX)/0(CAN) packets, 4 retries
## Total Size  = 0x0001132c = 70444 Bytes
=> bootm 0x8e00
*  kernel: cmdline image address = 0x8e00
## Booting kernel from Legacy Image at 8e00 ...
   Image Name:   Hello Image
   Image Type:   SuperH U-Boot Standalone Program (uncompressed)
   Data Size:70380 Bytes = 68.7 kB
   Load Address: 8c00
   Entry Point:  8c00
   Verifying Checksum ... OK
Wrong Image Type for bootm command
ERROR: can't get kernel image!
...
Could you give me an advice?
I think i have wrong image format? But how can I get correct format ?

Best regards.
-- 
View this message in context: 
http://www.nabble.com/Run-hello-world-with-Uboot-%21-tp19851315p19851315.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

[U-Boot] [PATCH] Align end of bss by 4 bytes,

[Selvamuthukumar]

bss initialization loop increments 4 bytes at a time.
And the loop end is checked for an 'equal' condition.
Make the bss end address aligned by 4, so that the loop
will end as expected.

Adding below lines creates bss of size not aligned to 4 bytes.

typedef struct bss_test__ {
unsigned char a1;
unsigned char ip1[4];
unsigned char ip2[4];
} bss_test_t;

bss_test_t bss; /* Global variable */


$ ppc_83xx-gcc --version
ppc_83xx-gcc (GCC) 4.2.0 (MontaVista 4.2.0-4.0.7.0703741 2007-08-09)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$

$ ppc_83xx-readelf -S u-boot | grep bss
  [ 9] .bss  NOBITS  fe034000 0335dc 006c9d 00  WA  0   0  8
$

Size of bss is 6c9d bytes.

Signed-off-by: Selvamuthukumar <[EMAIL PROTECTED]>
---
 cpu/mpc83xx/u-boot.lds |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/cpu/mpc83xx/u-boot.lds b/cpu/mpc83xx/u-boot.lds
index 99ad675..0d26937 100644
--- a/cpu/mpc83xx/u-boot.lds
+++ b/cpu/mpc83xx/u-boot.lds
@@ -117,6 +117,7 @@ SECTIONS
   *(.bss)
   *(COMMON)
  }
+  . = ALIGN(4);
  _end = . ;
  PROVIDE (end = .);
 }
--
1.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] how can i change u-boot load address?

[Roman Mashak]

Hello

2008/10/6 Roman Mashak <[EMAIL PROTECTED]>:

[skip]
> On many MCUs built on arm7tdmi core (for example, SAM7 family from
> Atmel) the process of starting up involves remapping, i.e. 0x0 address
> points on ROM at reset and on RAM after remap. U-Boot usually resides
> in ROM storage at startup, after reset relocates itself to RAM --
> should not it involve remapping as well?
>
> I didn't find how it's done in U-Boot (if it's done at all). Would
> appreciate a lot for clarification.

I seem to understand that remapping, being a CPU specific and
depending on a way U-Boot starts (either from ROM or RAM), is taken
away in 'lowlevel_init' function, defined either in in
$(uboot)/cpu/arm/$(soc)/lowlevel_init.S (for example,
$(uboot)/cpu/arm920t/ks8695/) or in
$(uboot)/board/board_name/lowlevel_init.S, but what confuses me is
that I couldn't find remap functions on every ARM platform, running
from ROM at reset.

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

Re: [U-Boot] JFFS2-Summary support for u-boot

[Detlev Zundel]

Hi Michael,

> Joakim Tjernlund  transmode.se> writes:
>
>> Can't remember, possibly it was a hack.
>> 
> Seems so. I tried to put it in my 1.3.3, but 'ls' never returns :-(
>
> So I will wait for Detlev Zundel.

Actually someone doing the development for DENX will post the code, but
it will not be me ;)

The code should hit the mailing list any day now.  The speed
improvements are pretty drastic, although dependant on the actual file
system.  Improvements by factors of 4 have been measured however...

Cheers
  Detlev

-- 
"The number you have dialed is imaginary. Please rotate your phone 90
degrees and try again."
--
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: [EMAIL PROTECTED]
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot Saveenv question --> final tested solution

[Suresh Bhaskaran]

-Original Message-
From: Jerry Van Baren [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 06, 2008 10:07 AM
To: Suresh Bhaskaran
Cc: Andrejs Cainikovs; u-boot@lists.denx.de
Subject: Re: [U-Boot] U-boot Saveenv question

Suresh Bhaskaran wrote:
> 1.  I verified flash contents using the md.w command in u-boot
> 2.  I've already verified correct flash r/w operation using the cp.w
> command
> 3.  Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile
> 4.  Flinfo shows the correct flash configuration (sectors, etc) of the
> flash
> 
> I can see the new env variable (e.g. set serverip 10.0.0.1) at the end
> of the saveenv area in flash (after I do a saveenv).  (the original
> entry is removed from the list in flash, and the new updated entry is
> added to the end of the list in flash).
> 
> Still, when I reboot u-boot, I don't get the new environment variable
> updated from flash.
> 
> What am I missing?
> 
> Thanks.
> Suresh

Please don't top post.

Are you using DHCP (BOOTP)?  If you are, serverip is probably being sent

by your DHCP server and overriding the value you have set in your env.

I'm assuming you are *not* getting env CRC failure warnings on boot.

If neither of the above guesses solve the problem, please copy what is 
printed to the console on start up.  Without more information, we're 
just guessing.

Best regards,
gvb

-

Thanks for help:

I've got it working:

Final answer:

1.  If *only* CONFIG_ENV_OVERWRITE is turned on in board file, then crc
is not written to flash [don't know if it's bug, or if I am setting
incorrect flags]

2.  But if CFG_ENV_ADDR_REDUND is also set, then it sets CRC to flash,
and it works correctly.

In any case, setup 2. works for me.

Thanks for all the help.

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

[U-Boot] ext2ls - size limit

[mRon]

Hello,

Could you tell me what is the maximum size limit for partition to be 
able to be listed via ext2ls command?

I have uBoot 1.1.1

Pozdrawiam,
mRon

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

Re: [U-Boot] [PATCH 1/3 v2] ppc4xx: Add AMCC Arches boardsupport(dual 460GT)

[Victor Gallardo]

Dear Wolfgang,

> > diff --git a/include/configs/canyonlands.h 
> > b/include/configs/canyonlands.h index 2f162e1..acad9b3 100644
> > --- a/include/configs/canyonlands.h
> > +++ b/include/configs/canyonlands.h
> ...
> > +#define CONFIG_PREBOOT \
> > +   "setenv ethact ppc_4xx_eth1;" \
> 
> This should not be done in the preboot command, but as part of the 
> default config instead.

I reviewed this again. It cannot be part of default config. We need
to do it at PREBOOT because eth_register() updates this variable
each time at boot. It assigns ethact to the first ethernet port it
discovers. In Arches, we need the second Ethernet port set as ethact.
Updating it at preboot allows us to update after eth_register has
set it.

Best Regards,

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

Re: [U-Boot] how can i change u-boot load address?

[Roman Mashak]

Hello Andrew,

2008/10/6 Andrew Dyer <[EMAIL PROTECTED]>:
> If you want to build a version of u-boot that is linked to a start
> address that is in RAM for loading via a jtag debugger, then change
> the definition of TEXT_BASE in board//config.mk.

Can the value of TEXT_BASE be arbitrary chosen for test purposes?

> If you want to make sure u-boot is still linked in ROM, but gets put
> at the top of memory during relocation, then you have to make sure the
> initdram() function in your code returns the correct ram size.

As I understand it's valid for MIPS or PPC based architectures, right?
On many MCUs built on arm7tdmi core (for example, SAM7 family from
Atmel) the process of starting up involves remapping, i.e. 0x0 address
points on ROM at reset and on RAM after remap. U-Boot usually resides
in ROM storage at startup, after reset relocates itself to RAM --
should not it involve remapping as well?

I didn't find how it's done in U-Boot (if it's done at all). Would
appreciate a lot for clarification.

I'm trying to understand how it's done on ARM --

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

Re: [U-Boot] [PATCH] Align end of bss by 4 bytes,

[Kim Phillips]

On Mon, 6 Oct 2008 21:12:58 +0530
Selvamuthukumar <[EMAIL PROTECTED]> wrote:

> bss initialization loop increments 4 bytes at a time.
> And the loop end is checked for an 'equal' condition.
> Make the bss end address aligned by 4, so that the loop
> will end as expected.
> ---

I need a signed-off-by to apply this.

also, providing more details in the commit message as to how this
condition is being triggered, what happens with which toolchain
when it does would be appreciated.

Kim

>  cpu/mpc83xx/u-boot.lds |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> diff --git a/cpu/mpc83xx/u-boot.lds b/cpu/mpc83xx/u-boot.lds
> index 99ad675..0d26937 100644
> --- a/cpu/mpc83xx/u-boot.lds
> +++ b/cpu/mpc83xx/u-boot.lds
> @@ -117,6 +117,7 @@ SECTIONS
>*(.bss)
>*(COMMON)
>   }
> +  . = ALIGN(4);
>   _end = . ;
>   PROVIDE (end = .);
>  }
> --
> 1.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Olimex SAM9-L9260 board support

[Wolfgang Denk]

Dear Cristian Birsan,

In message <[EMAIL PROTECTED]> you wrote:
> 
>  > Carelessly leaving ports or devices in an initialized stated has been
>  > the source for problems too many times before.
>  >
>  > Don't do that.
> 
> The above code section is used also in other ATMEL boards like
> at91sam9260ek ( /board/atmel/at91sam9260ek/at91sam9260ek.c ),
> at91sam9261ek, at91sam9263ek, at91sam9rlek. This is my
> first patch sent to U-Boot and I used that code as reference.

So this problem escaped the review when that old code was added.

So we can only ask the baord maintainer and the AT91 custodian to take
care of the existing code and clean ipt up ASAP.

But we should not add more copies of that bad example.

> The board that i have (SAM9-L9260 from Olimex ) is close to
> AT91SAM9260EK from ATMEL.
> 
> How do you think i can do this the right way?

Well, the Right Thing (TM) would be to use a device tree to pass such
information to Linux, but that's a long way to go still.

In the mean time, other methods  should  be  used  to  pass  the  MAC
address information to the Linux network driver (I understand this is
all  what  needs  to  be  done, right?). In the simplest case, use an
"ethaddr=..." boot argument. [Make sure to read the ML archive before
you try to bring up this topic on the linux-arm  ML;  this  has  been
discussed in *length* before.]


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Due to lack of disk space, this fortune database has been discontinued.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Olimex SAM9-L9260 board support

[Cristian Birsan]

Dear Wolfgang Denk,

Thank you for your quick response.

 >> +#ifdef CONFIG_RESET_PHY_R
 >> +void reset_phy(void)
 >> +{
 >> +#ifdef CONFIG_MACB
 >> +/*
 >> + * Initialize ethernet HW addr prior to starting Linux,
 >> + * needed for nfsroot
 >> + */
 >> +eth_init(gd->bd);
 >> +#endif
 >
 > Please do NOT  do  this.  It's  a  violation  of  the  U-Boot  design
 > principles,  which  clearly  say that only such periphereals that are
 > actually being used by U-Boot shall be initialized, and even if  they
 > are being used, these shall be deactivated after use.
 >
 > Carelessly leaving ports or devices in an initialized stated has been
 > the source for problems too many times before.
 >
 > Don't do that.
 >

The above code section is used also in other ATMEL boards like
at91sam9260ek ( /board/atmel/at91sam9260ek/at91sam9260ek.c ),
at91sam9261ek, at91sam9263ek, at91sam9rlek. This is my
first patch sent to U-Boot and I used that code as reference.

The board that i have (SAM9-L9260 from Olimex ) is close to
AT91SAM9260EK from ATMEL.

How do you think i can do this the right way?

 >> +#define ROUND(A, B)(((A) + (B)) & ~((B) - 1))
 >
 > First I think that this is wrong (maybe you need "B-1" instead of "B"
 > in the first part?), second we already have DIV_ROUND_UP  defined  in
 > common.h so please use this.

Thanks, good catch. I will fix this and submit a new patch.

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

[U-Boot] [PATCH] CONFIG_EFI_PARTITION: Added support for EFI partition in cmd_ext2fs.c

[richardretanubun]

Added support for CONFIG_EFI_PARTITION to ext2 commands.
Signed-off-by: Richard Retanubun <[EMAIL PROTECTED]>
---
Hi Wolfgang,

This patch should be applied on top of the patch that adds EFI partition 
support.

A workaround without this patch is to #define CONFIG_DOS_PARTITION 
and #define CONFIG_EFI_PARTITION when using #define CONFIG_CMD_EXT2 
in the include/config/

Regards,

Richard

 common/cmd_ext2.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/common/cmd_ext2.c b/common/cmd_ext2.c
index f569406..cfd4f64 100644
--- a/common/cmd_ext2.c
+++ b/common/cmd_ext2.c
@@ -44,8 +44,8 @@
 #include 
 #endif
 
-#ifndef CONFIG_DOS_PARTITION
-#error DOS partition support must be selected
+#if !defined(CONFIG_DOS_PARTITION) && !defined(CONFIG_EFI_PARTITION)
+#error DOS or EFI partition support must be selected
 #endif
 
 /* #define EXT2_DEBUG */
-- 
1.5.5.GIT









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

Re: [U-Boot] [U-boot] [PATCHv2 1/2] NET: QE: UEC: Make uec_miiphy_read() and uec_miiphy_write() use the devname arg.

[richardretanubun]

richardretanubun wrote:

> The current uec_miiphy_read and uec_miiphy_write hardcode access devlist[0]
> This patch makes these function use the devname argument that is passed in to
> allow access to the phy registers of other devices in devlist[].
>
> Signed-of-by: Richard Retanubun <[EMAIL PROTECTED]>
> ---
> Hi Ben,
>
> I'm hoping the 7th try will do it. I forgot to add the commit message before.
[snip]


Hi Ben, 

Apologies for nagging, just checking if you get a chance to re-re-re-apply my 
7th attempt? :)

Gratefully-Embarrassed,

- Richard


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

Re: [U-Boot] [PATCH v3] [83xx] Adds two more ethernet interface to 83xx

[richardretanubun]

Fixed compiler warning "declared but unused" eth5_uec_info and eth6_uec_info.
Signed-off-by: Richard Retanubun <[EMAIL PROTECTED]>
---
Hi Ben,

Thanks for applying the patch. 
I got a compiler warning when using it, here is a patch to fix that.

Thanks for all the help

Richard

 drivers/qe/uec.c |8 
 1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/drivers/qe/uec.c b/drivers/qe/uec.c
index e1dec5e..582a1c0 100644
--- a/drivers/qe/uec.c
+++ b/drivers/qe/uec.c
@@ -1414,6 +1414,14 @@ int uec_initialize(int index)
 #ifdef CONFIG_UEC_ETH4
uec_info = ð4_uec_info;
 #endif
+   } else if (index == 4) {
+#ifdef CONFIG_UEC_ETH5
+   uec_info = ð5_uec_info;
+#endif
+   } else if (index == 5) {
+#ifdef CONFIG_UEC_ETH6
+   uec_info = ð6_uec_info;
+#endif
} else {
printf("%s: index is illegal.\n", __FUNCTION__);
return -EINVAL;
-- 
1.5.5.GIT


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

Re: [U-Boot] [PATCH 1/3 v2] ppc4xx: Add AMCC Arches board support(dual 460GT)

[Victor Gallardo]

Dear Wolfgang,

Thanks for the feedback.

> ...
> > +int misc_init_r(void)
> > +{
> ...
> > +   /* reset all SGMII interfaces */
> > +   mfsdr(SDR0_SRST1,   reg);
> > +   reg |= (SDR0_SRST1_SGMII0 | SDR0_SRST1_SGMII1 | SDR0_SRST1_SGMII2);
> > +   mtsdr(SDR0_SRST1, reg);
> > +   mtsdr(SDR0_ETH_STS, 0x);
> > +   mtsdr(SDR0_SRST1,   0x);
> > +
> > +   for (timeout = 60; timeout > 0; timeout--) {
> > +   udelay(1000);
> > +   mfsdr(SDR0_ETH_PLL, eth_pll);
> > +   if ((eth_pll & SDR0_ETH_PLL_PLLLOCK) != 0)
> > +   break;
> > +   }
>
> Where is the 60 ms timeout coming from?
>

This is a very high mark number we came up with when running some test
while waiting for SDR0_ETH_PLL_POCK. Actually a timeout is really
not needed PLL LOCK is always achieved. No initialization of the
SDR0_ETH_PLL required. The SDR0_ETH_PLL is configured by default after
reset. The code should look more like this.

do {
mfsdr(SDR0_ETH_PLL, eth_pll);
} while (!(eth_pll & SDR0_ETH_PLL_PLLLOCK));

> > --- a/include/configs/amcc-common.h
> > +++ b/include/configs/amcc-common.h
> > @@ -55,6 +55,13 @@
> >  #endif
> >  
> >  /*
> > + * Only very few boards have default netdev not set to eth0 (like Arches)
> > + */
> > +#if !defined(CONFIG_NETDEV)
> > +#define CONFIG_NETDEV  eth0
> > +#endif
> 
> Please don't add this to common code; please handle it locally in the
> arches configuration.

We do handle this locally in arches config section (canyonlands.h). The
above is the default. We need this because eth0 in Arches is used for
CPU-to-CPU Communcation via ethernet. Eth1 is used for normal RJ45
connection.


> > @@ -147,9 +154,11 @@
> >  /*
> >   * Booting and default environment
> >   */
> > +#if !defined(CONFIG_PREBOOT)
> >  #define CONFIG_PREBOOT "echo;" \
> > "echo Type \"run flash_nfs\" to mount root filesystem over NFS;" \
> > "echo"
> > +#endif
>
> Ditto. [Also: what's the reason for this change? ]
>

Once again. This is the default, we overwrite this in our arches
Config section (canyonlands.h). We modify CONFIG_PREBOOT to
Set the default ethact to ppc_4xx_eth1. See below

> > +   "net_self_load=tftp ${kernel_addr_r} ${bootfile};"  \
> > +   "tftp ${fdt_addr_r} ${fdt_file};"   \
> > +   "tftp ${ramdisk_addr_r} ${ramdisk_file};\0" \
> 
> What is this needed for?

net_self_load is used by net_self to load linux, fdt blob, ramdisk
via tftp. this is very similar to net_nfs, flash_nfs and flash_self

> > diff --git a/include/configs/canyonlands.h b/include/configs/canyonlands.h
> > index 2f162e1..acad9b3 100644
> > --- a/include/configs/canyonlands.h
> > +++ b/include/configs/canyonlands.h
> ...
> > +#define CONFIG_PREBOOT \
> > +   "setenv ethact ppc_4xx_eth1;" \
> 
> This should not be done in the preboot command, but as part of the
> default config instead.

Yes, you are correct. I will fix this.

> > -#define CFG_AHB_BASE   0xE200  /* internal AHB 
> > peripherals */
> > +#define CFG_AHB_BASE   0xE200  /* internal AHB 
> > peripherals */
> 
> Is this change an improvement?

No

> > @@ -223,6 +268,7 @@
> >   * DDR SDRAM
> >   
> > **/
> >  #if !defined(CONFIG_NAND_U_BOOT)
> > +#if !defined(CONFIG_ARCHES)
> >  /*
> >   * NAND booting U-Boot version uses a fixed initialization, since the whole
> >   * I2C SPD DIMM autodetection/calibration doesn't fit into the 4k of boot
> 
> Are you sure this is correct?

I will investigate.

> > +#if !defined(CONFIG_ARCHES)
> >  /* Only Canyonlands (460EX) has USB */
> >  #ifdef CONFIG_460EX
> 
> I think it would make more sense to move the "!defined(CONFIG_ARCHES)"
> _after_ the "#ifdef CONFIG_460EX".

Will double check

> > +#else  /* defined(CONFIG_ARCHES) */
> > +
> > +/* Arches board does not have USB connectivity */
> > +
> > +/*
> > + * Default environment variables
> > + */
> > +#defineCONFIG_EXTRA_ENV_SETTINGS   
> > \
> 
> Ah... but these definitely do not belong into the "USB connectivity"
> block...

OK. Will fix.

> >   */
> > +#if !defined(CONFIG_ARCHES)
> >  #define CONFIG_CMD_DATE
> > -#define CONFIG_CMD_DTT
> >  #define CONFIG_CMD_NAND
> > +#define CONFIG_CMD_SNTP
> > +#endif
> > +#define CONFIG_CMD_DTT
> >  #define CONFIG_CMD_PCI
> >  #define CONFIG_CMD_SDRAM
> > -#define CONFIG_CMD_SNTP
> >  #ifdef CONFIG_460EX
> >  #define CONFIG_CMD_EXT2
> >  #define CONFIG_CMD_FAT
>
> I think we should separate these tlistrs of commands, so we can keep
> the lists sorted.

OK.

> > +/*
> > + * Arches has 32MBytes of NOR FLASH (Spansion 29GL256) so remap FLASH to
> > + * EBC address which accepts bigger regions:
> > + *   0xfe00. -> 4.ce00.
> > + */
> 
> Cannot we do this automatically, dependent on the actual size of flash
> as determined by the code?
> 

Will investigate.

Best Rega

Re: [U-Boot] [PATCH] Olimex SAM9-L9260 board support

[Wolfgang Denk]

Dear Cristian Birsan,

> +#ifdef CONFIG_RESET_PHY_R
> +void reset_phy(void)
> +{
> +#ifdef CONFIG_MACB
> + /*
> +  * Initialize ethernet HW addr prior to starting Linux,
> +  * needed for nfsroot
> +  */
> + eth_init(gd->bd);
> +#endif

Please do NOT  do  this.  It's  a  violation  of  the  U-Boot  design
principles,  which  clearly  say that only such periphereals that are
actually being used by U-Boot shall be initialized, and even if  they
are being used, these shall be deactivated after use.

Carelessly leaving ports or devices in an initialized stated has been
the source for problems too many times before.

Don't do that.

> +#define ROUND(A, B)  (((A) + (B)) & ~((B) - 1))

First I think that this is wrong (maybe you need "B-1" instead of "B"
in the first part?), second we already have DIV_ROUND_UP  defined  in
common.h so please use this.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
A well-written program is its own heaven; a poorly-written program is
its own hell. -- Geoffrey James, "The Tao of Programming"
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] U-boot Saveenv question

[Suresh Bhaskaran]

-Original Message-
From: Jerry Van Baren [mailto:[EMAIL PROTECTED] 
Sent: Monday, October 06, 2008 10:07 AM
To: Suresh Bhaskaran
Cc: Andrejs Cainikovs; u-boot@lists.denx.de
Subject: Re: [U-Boot] U-boot Saveenv question

Suresh Bhaskaran wrote:
> 1.  I verified flash contents using the md.w command in u-boot
> 2.  I've already verified correct flash r/w operation using the cp.w
> command
> 3.  Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile
> 4.  Flinfo shows the correct flash configuration (sectors, etc) of the
> flash
> 
> I can see the new env variable (e.g. set serverip 10.0.0.1) at the end
> of the saveenv area in flash (after I do a saveenv).  (the original
> entry is removed from the list in flash, and the new updated entry is
> added to the end of the list in flash).
> 
> Still, when I reboot u-boot, I don't get the new environment variable
> updated from flash.
> 
> What am I missing?
> 
> Thanks.
> Suresh

Please don't top post.

Are you using DHCP (BOOTP)?  If you are, serverip is probably being sent

by your DHCP server and overriding the value you have set in your env.

I'm assuming you are *not* getting env CRC failure warnings on boot.

If neither of the above guesses solve the problem, please copy what is 
printed to the console on start up.  Without more information, we're 
just guessing.

Best regards,
gvb

--

Thanks, Jerry.

Sorry for the previous top post.

Your guess is right!  

Upon looking more carefully at my log, I see 

  "bad CRC, using default environment"

In my boot-up log.

I am looking thru the code to see why I might have a bad crc.

Meanwhile, any guesses as to why I have bad crc?

Could I have ported code from u1.1.3 to u1.3.4 incorrectly?

Or could I have accidentally ignored some "change" from u1.1.3 to
u1.3.4?

Thanks.

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

[U-Boot] [PATCH] Olimex SAM9-L9260 board support

[Cristian Birsan]

Added support for the Olimex SAM9-L9260 development board.
This patch is based on u-boot v1.3.4.

Tested with data flash only (not with NAND).

Signed-off-by: Cristian Birsan <[EMAIL PROTECTED]>
---
  MAKEALL|1 +
  Makefile   |   21 ++--
  board/olimex/sam9l9260/Makefile|   59 
  board/olimex/sam9l9260/config.mk   |1 +
  board/olimex/sam9l9260/led.c   |   64 +
  board/olimex/sam9l9260/nand.c  |   78 +++
  board/olimex/sam9l9260/partition.c |   39 ++
  board/olimex/sam9l9260/sam9l9260.c |  264 
  drivers/mtd/nand/nand_ids.c|2 +
  include/configs/sam9l9260.h|  212 +
  10 files changed, 732 insertions(+), 9 deletions(-)
  create mode 100644 board/olimex/sam9l9260/Makefile
  create mode 100644 board/olimex/sam9l9260/config.mk
  create mode 100644 board/olimex/sam9l9260/led.c
  create mode 100644 board/olimex/sam9l9260/nand.c
  create mode 100644 board/olimex/sam9l9260/partition.c
  create mode 100644 board/olimex/sam9l9260/sam9l9260.c
  create mode 100644 include/configs/sam9l9260.h

diff --git a/MAKEALL b/MAKEALL
index 9ccb9ac..0e2cb36 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -542,6 +542,7 @@ LIST_at91=" \
kb9202  \
mp2usb  \
m501sk  \
+   sam9l9260   \
  "

  #
diff --git a/Makefile b/Makefile
index 7c13ce8..5b0acae 100644
--- a/Makefile
+++ b/Makefile
@@ -2487,15 +2487,6 @@ shannon_config   :   unconfig
  at91rm9200dk_config   :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t at91rm9200dk atmel at91rm9200

-at91sam9261ek_config   :   unconfig
-   @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9261ek atmel at91
-
-at91sam9263ek_config   :   unconfig
-   @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9263ek atmel at91
-
-at91sam9rlek_config:   unconfig
-   @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9rlek atmel at91
-
  cmc_pu2_config:   unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t cmc_pu2 NULL at91rm9200

@@ -2521,6 +2512,18 @@ at91cap9adk_config   :   unconfig
  at91sam9260ek_config  :   unconfig
@$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9260ek atmel at91

+at91sam9261ek_config   :   unconfig
+   @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9261ek atmel at91
+
+at91sam9263ek_config   :   unconfig
+   @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9263ek atmel at91
+
+at91sam9rlek_config:   unconfig
+   @$(MKCONFIG) $(@:_config=) arm arm926ejs at91sam9rlek atmel at91
+
+sam9l9260_config   :   unconfig
+   @$(MKCONFIG) $(@:_config=) arm arm926ejs sam9l9260 olimex at91
+
  
  ## ARM Integrator boards - see doc/README-integrator for more info.
  integratorap_config   \
diff --git a/board/olimex/sam9l9260/Makefile b/board/olimex/sam9l9260/Makefile
new file mode 100644
index 000..8853b7c
--- /dev/null
+++ b/board/olimex/sam9l9260/Makefile
@@ -0,0 +1,59 @@
+#
+# (C) Copyright 2003-2008
+# Wolfgang Denk, DENX Software Engineering, [EMAIL PROTECTED]
+#
+# (C) Copyright 2008
+#
+# Cristian Birsan <[EMAIL PROTECTED]> based on the work of
+# Stelian Pop <[EMAIL PROTECTED]>
+# Lead Tech Design 
+#
+# See file CREDITS for list of people who contributed to this
+# project.
+#
+# This program is free software; you can redistribute it and/or
+# modify it under the terms of the GNU General Public License as
+# published by the Free Software Foundation; either version 2 of
+# the License, or (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+# MA 02111-1307 USA
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS-y+= sam9l9260.o
+COBJS-y+= led.o
+COBJS-y+= partition.o
+COBJS-$(CONFIG_CMD_NAND) += nand.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS-y))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak $(obj).depend
+
+#
+
+# defines $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#

[U-Boot] [PATCH 1/1 v2] ppc4xx: Reset and relock memory DLL after SDRAM_CLKTR change

[Adam Graham]

After changing SDRAM_CLKTR phase value rerun the memory preload
initialization sequence (INITPLR) to reset and relock the memory
DLL. Changing the SDRAM_CLKTR memory clock phase coarse timing
adjustment effects the phase relationship of the internal, to the
PPC chip, and external, to the PPC chip, versions of MEMCLK_OUT.

Signed-off-by: Adam Graham <[EMAIL PROTECTED]>
Signed-off-by: Victor Gallardo <[EMAIL PROTECTED]>
---
 v2:
 - fix commit text. line to long.

 cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c |   21 +
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c 
b/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
index 83b9883..47ab39b 100644
--- a/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
+++ b/cpu/ppc4xx/4xx_ibm_ddr2_autocalib.c
@@ -174,6 +174,23 @@ static inline void ecc_clear_status_reg(void)
 #endif
 }
 
+/*
+ * Reset and relock memory DLL after SDRAM_CLKTR change
+ */
+static inline void relock_memory_DLL(void)
+{
+   u32 reg;
+
+   mtsdram(SDRAM_MCOPT2, SDRAM_MCOPT2_IPTR_EXECUTE);
+
+   do {
+   mfsdram(SDRAM_MCSTAT, reg);
+   } while (!(reg & SDRAM_MCSTAT_MIC_COMP));
+
+   mfsdram(SDRAM_MCOPT2, reg);
+   mtsdram(SDRAM_MCOPT2, reg | SDRAM_MCOPT2_DCEN_ENABLE);
+}
+
 static int ecc_check_status_reg(void)
 {
u32 ecc_status;
@@ -981,6 +998,8 @@ u32 DQS_autocalibration(void)
 
mtsdram(SDRAM_CLKTR, clkp << 30);
 
+   relock_memory_DLL();
+
putc('\b');
putc(slash[loopi++ % 8]);
 
@@ -1170,6 +1189,8 @@ u32 DQS_autocalibration(void)
 
mtsdram(SDRAM_CLKTR, tcal.clocks.clktr << 30);
 
+   relock_memory_DLL();
+
mfsdram(SDRAM_RQDC, rqdc_reg);
rqdc_reg &= ~(SDRAM_RQDC_RQFD_MASK);
mtsdram(SDRAM_RQDC, rqdc_reg |
-- 
1.5.5

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

Re: [U-Boot] U-boot Saveenv question

[Jerry Van Baren]

Suresh Bhaskaran wrote:
> 1.  I verified flash contents using the md.w command in u-boot
> 2.  I've already verified correct flash r/w operation using the cp.w
> command
> 3.  Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile
> 4.  Flinfo shows the correct flash configuration (sectors, etc) of the
> flash
> 
> I can see the new env variable (e.g. set serverip 10.0.0.1) at the end
> of the saveenv area in flash (after I do a saveenv).  (the original
> entry is removed from the list in flash, and the new updated entry is
> added to the end of the list in flash).
> 
> Still, when I reboot u-boot, I don't get the new environment variable
> updated from flash.
> 
> What am I missing?
> 
> Thanks.
> Suresh

Please don't top post.

Are you using DHCP (BOOTP)?  If you are, serverip is probably being sent 
by your DHCP server and overriding the value you have set in your env.

I'm assuming you are *not* getting env CRC failure warnings on boot.

If neither of the above guesses solve the problem, please copy what is 
printed to the console on start up.  Without more information, we're 
just guessing.

Best regards,
gvb


> -Original Message-
> From: Andrejs Cainikovs [mailto:[EMAIL PROTECTED] 
> Sent: Sunday, October 05, 2008 8:55 AM
> To: Suresh Bhaskaran
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] U-boot Saveenv question
> 
> How did you verified that your environment get saved?
> What is the result of running the 'flinfo'?
> Is CONFIG_ENV_OVERWRITE defined in your board file?
> 
> Kind regards,
> Andrejs Cainikovs.
> 
> Suresh Bhaskaran wrote:
>> Hello,
>>
>> I have a question relating to doing saveenv from the u-boot command
> line
>> (after hitting key to stop autoboot), and having u-boot come up during
>> the next reboot with the saved environment.
>>
>> First of all, I apologize in advance if this question is out of place
> in
>> this mailing list.  
>>
>> This mailing list seems to be for u-boot patch upgrades, rather than
> for
>> general questions?
>>
>> Anyway, it's the best list on u-boot I was able to find:
>>
>> 1.  I upgraded from u-boot 1.1.3 (2005) to u-boot 1.3.4 (2008)
>> 2.  I've put in the board/target-specific files incorporated, and have
>> it working.
>>
>> 3.  However, when I do a saveenv (e.g. after "set serverip 10.0.0.1"),
>> and I do a reboot, the new environment variable doesn't show up.  
>>  a.  (I've verified that it actually gets written to flash...)
>>
>> 4.  Is there something I else I need to do to "turn on" re-booting
> from
>> saved environment?
>>
>> Thanks in advance.
>>
>> Suresh Bhaskaran
>> ___
>> 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

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

Re: [U-Boot] U-boot Saveenv question

[Suresh Bhaskaran]

1.  I verified flash contents using the md.w command in u-boot
2.  I've already verified correct flash r/w operation using the cp.w
command
3.  Yes, the CONFIG_ENV_OVERWRITE flag is defined in my boardfile
4.  Flinfo shows the correct flash configuration (sectors, etc) of the
flash

I can see the new env variable (e.g. set serverip 10.0.0.1) at the end
of the saveenv area in flash (after I do a saveenv).  (the original
entry is removed from the list in flash, and the new updated entry is
added to the end of the list in flash).

Still, when I reboot u-boot, I don't get the new environment variable
updated from flash.

What am I missing?

Thanks.

Suresh

-Original Message-
From: Andrejs Cainikovs [mailto:[EMAIL PROTECTED] 
Sent: Sunday, October 05, 2008 8:55 AM
To: Suresh Bhaskaran
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] U-boot Saveenv question

How did you verified that your environment get saved?
What is the result of running the 'flinfo'?
Is CONFIG_ENV_OVERWRITE defined in your board file?

Kind regards,
Andrejs Cainikovs.

Suresh Bhaskaran wrote:
> Hello,
>
> I have a question relating to doing saveenv from the u-boot command
line
> (after hitting key to stop autoboot), and having u-boot come up during
> the next reboot with the saved environment.
>
> First of all, I apologize in advance if this question is out of place
in
> this mailing list.  
>
> This mailing list seems to be for u-boot patch upgrades, rather than
for
> general questions?
>
> Anyway, it's the best list on u-boot I was able to find:
>
> 1.  I upgraded from u-boot 1.1.3 (2005) to u-boot 1.3.4 (2008)
> 2.  I've put in the board/target-specific files incorporated, and have
> it working.
>
> 3.  However, when I do a saveenv (e.g. after "set serverip 10.0.0.1"),
> and I do a reboot, the new environment variable doesn't show up.  
>   a.  (I've verified that it actually gets written to flash...)
>
> 4.  Is there something I else I need to do to "turn on" re-booting
from
> saved environment?
>
> Thanks in advance.
>
> Suresh Bhaskaran
> ___
> 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

[U-Boot] [PATCH] Align end of bss by 4 bytes,

[Selvamuthukumar]

bss initialization loop increments 4 bytes at a time.
And the loop end is checked for an 'equal' condition.
Make the bss end address aligned by 4, so that the loop
will end as expected.
---
 cpu/mpc83xx/u-boot.lds |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

diff --git a/cpu/mpc83xx/u-boot.lds b/cpu/mpc83xx/u-boot.lds
index 99ad675..0d26937 100644
--- a/cpu/mpc83xx/u-boot.lds
+++ b/cpu/mpc83xx/u-boot.lds
@@ -117,6 +117,7 @@ SECTIONS
   *(.bss)
   *(COMMON)
  }
+  . = ALIGN(4);
  _end = . ;
  PROVIDE (end = .);
 }
--
1.5.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] how can i change u-boot load address?

[Andrew Dyer]

On Mon, Oct 6, 2008 at 7:13 AM, sahar mustafa <[EMAIL PROTECTED]> wrote:
> can you tell me how to change the load address without crippling the u-boot?

It's not 100% clear what you are trying to do, and you didn't mention
your target other than it's MIPS...

If you want to build a version of u-boot that is linked to a start
address that is in RAM for loading via a jtag debugger, then change
the definition of TEXT_BASE in board//config.mk.
 You have to make sure that u-boot doesn't try to re-initialize the
ram or caches, and doesn't write over parts of itself when it
relocates or allocates memory for the stack and heap.

If you want to make sure u-boot is still linked in ROM, but gets put
at the top of memory during relocation, then you have to make sure the
initdram() function in your code returns the correct ram size.  If you
look in lib_mips/board.c board_init_f(), ram starts being allocated
top down, starting at CFG_SDRAM_BASE + gd->ram_size.  gd->ram_size is
initialized by the return value of a call to initdram() which is
usually somewhere in the board specific code.

-- 
Hardware, n.:
The parts of a computer system that can be kicked.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] MPC86xx unapplied patches

[Kumar Gala]

On Sep 24, 2008, at 2:32 PM, Jon Loeliger wrote:

> On Sun, 2008-09-07 at 01:39 +0200, Wolfgang Denk wrote:
>> Dear Jon,
>>
>> I have a couple of unapplied patches in my list which seem to fall
>> into your area of responsibility. Can you please have a look at
>> these:
>>
>> 6185  08/19 Kumar Gala [U-Boot] [PATCH] 86xx: remove  
>> redudant code with lib_ppc/interrupts.c
>> 6767  08/28 Nick Spence[U-Boot] [PATCH] mpc86xx: use r4  
>> instead of r2 in lock_ram_in_cache a
>
>
> Hi Wolfgang,
>
> Sorry, got buried here.  If these are still outstanding,
> please directly apply them.

Wolfgang,

Will you be applying these for v2008.10-rc2+?

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

[U-Boot] [PATCH] ARM DaVinci: Add maintainer informations for SFFSDR board.

[Hugo Villeneuve]

ARM DaVinci: Add maintainer informations for SFFSDR board.

Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>
---
 MAINTAINERS |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 750e374..9c0d6bf 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -594,6 +594,10 @@ Greg Ungerer <[EMAIL PROTECTED]>
cm4116  ks8695p
cm4148  ks8695p
 
+Hugo Villeneuve <[EMAIL PROTECTED]>
+
+   SFFSDR  ARM926EJS
+
 Richard Woodruff <[EMAIL PROTECTED]>
 
omap2420h4  ARM1136EJS
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM DaVinci: Add maintainer informations for SFFSDR board.

[Hugo Villeneuve]

Wolfgang Denk wrote:
> Dear Hugo Villeneuve,
> 
> In message
> <[EMAIL PROTECTED]> you
> wrote:  
>> ARM DaVinci: Add maintainer informations for SFFSDR board.
>> 
>> Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>
> 
> Please keep the list of names alphabetically sorted.
> 
>> +Hugo Villeneuve <[EMAIL PROTECTED]>
>> +
>> +SFFSDR  ARM926EJS
>> +
>>  Prakash Kumar <[EMAIL PROTECTED]>
> 
> 'V' obviously goes after 'K' (i. e. add your entry after Richard
> Woodruff's one.

I don´t know in german, but in french V obviously goes before W :)

Hugo V.

Hugo Villeneuve
Hardware developer | Concepteur matériel
Lyrtech
Phone/Tél. : (1) (418) 877-4644 #2395
Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395
Fax/Téléc. : (1) (418) 877-7710
www.lyrtech.com
Infinite possibilities...TM
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM DaVinci: Add maintainer informations for SFFSDR board.

[Hugo Villeneuve]

Wolfgang Denk wrote:
> Dear Hugo Villeneuve,
> 
> In message
> <[EMAIL PROTECTED]> you
> wrote:  
>> ARM DaVinci: Add maintainer informations for SFFSDR board.
>> 
>> Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>
> 
> Please keep the list of names alphabetically sorted.

Ok.

>> +Hugo Villeneuve <[EMAIL PROTECTED]>
>> +
>> +SFFSDR  ARM926EJS
>> +
>>  Prakash Kumar <[EMAIL PROTECTED]>
> 
> 'V' obviously goes after 'K' (i. e. add your entry after Richard
> Woodruff's one.

Redundant comment based on your first comment :)

I will resubmit my patch in a few minutes.

Hugo V.

Hugo Villeneuve
Hardware developer | Concepteur matériel
Lyrtech
Phone/Tél. : (1) (418) 877-4644 #2395
Toll-free/Sans frais - Canada & USA : (1) (888) 922-4644 #2395
Fax/Téléc. : (1) (418) 877-7710
www.lyrtech.com
Infinite possibilities...TM
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM DaVinci: Add maintainer informations for SFFSDR board.

[Wolfgang Denk]

Dear Hugo Villeneuve,

In message <[EMAIL PROTECTED]> you wrote:
> ARM DaVinci: Add maintainer informations for SFFSDR board.
> 
> Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>

Please keep the list of names alphabetically sorted.

> +Hugo Villeneuve <[EMAIL PROTECTED]>
> +
> + SFFSDR  ARM926EJS
> +
>  Prakash Kumar <[EMAIL PROTECTED]>

'V' obviously goes after 'K' (i. e. add your entry after Richard
Woodruff's one.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
A failure will not appear until a unit has passed final inspection.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] ARM DaVinci: Add maintainer informations for SFFSDR board.

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:06 Mon 06 Oct , Hugo Villeneuve wrote:
> ARM DaVinci: Add maintainer informations for SFFSDR board.
> 
> Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>
> ---
>  MAINTAINERS |4 
>  1 files changed, 4 insertions(+), 0 deletions(-)

Wolfgang please appy directly

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

[U-Boot] [PATCH] ARM DaVinci: Add maintainer informations for SFFSDR board.

[Hugo Villeneuve]

ARM DaVinci: Add maintainer informations for SFFSDR board.

Signed-off-by: Hugo Villeneuve <[EMAIL PROTECTED]>
---
 MAINTAINERS |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 750e374..fc55a0b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -526,6 +526,10 @@ Sergey Kubushyn <[EMAIL PROTECTED]>
SONATA  ARM926EJS
SCHMOOGIE   ARM926EJS
 
+Hugo Villeneuve <[EMAIL PROTECTED]>
+
+   SFFSDR  ARM926EJS
+
 Prakash Kumar <[EMAIL PROTECTED]>
 
cerf250 xscale
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] /chosen node not overwritten by bootm

[Jerry Van Baren]

Jerry Van Baren wrote:
> Stefan Roese wrote:
>> Hi Jerry,
>>
>> Again I (and Wolfgang) stumbled about the problem, that the /chosen node is 
>> not overwritten by the bootm command when it already exists. This is really 
>> annoying, since we either:
>>
>> a) Have to remove the chosen node from the dts files (which is not so easy
>>if we try to stay in sync with the kernel.org version)
>>
>> or
>>
>> b) Have to manually use the U-Boot "fdt" commands to overwrite the chosen 
>> node
>>
>> I can't remember why this current behavior is implemented this way. Jerry, 
>> can't we just overwrite this node even if it already exists? What would we 
>> loose by doing this?
>>
>> Thanks.
>>
>> Best regards,
>> Stefan
> 
> Hi Stefan,
> 
> The behavior was to mimic the behavior of the non-LIBFDT original 
> implementation (and because we thought it was a good idea at the time). 
>   We originally assumed that the .dts file writer had more/better 
> knowledge of the system than we did (which was true at the time).  This 
> was aggravated by the conundrum that the original FDT support didn't do 
> a good job of generating the /chosen properties (some were, some 
> weren't), so the .dts writers /had to/ pre-init some /chosen values. 
> The /aliases node also helped - configuration choices that use to be 
> implicit in the .dts /chosen node are now in /aliases (major improvement!).
> 
> I thought we turned on the "force" flag so that the /chosen properties 
> would be overwritten, apparently I'm mistaken.
> 
> I'm fine with overwriting the /chosen node and properties.  Generate a 
> patch and I'll be happy to ack it.
> 
> (Note to self: maybe it is time to retire the "force" flag - it always 
> made me uncomfortable and is confusing.  Is there anything left that we 
> *don't* want to force?)
> 
> Best regards,
> gvb

Hi Stefan, Wolfgang, Kumar,

I was messing with Kumar's bootm split-up changeset and it reminded me 
of a major reason that I did not do a "force" on creating the /chosen 
node: it was so that a FDT blob user could use "fdt chosen" to create 
the /chosen node, post-modify it (which is what Kumar needs to do as I 
understand it), and then run bootm.  In this situation, bootm *won't* 
touch /chosen and thus won't undo the extra modifications that the user 
(boot script) did.

Question for Kumar: Am I understanding your problem correctly?  Would 
keeping the /chosen node generation unchanged (no "force") work for you 
short term?

Long term I believe we want to eliminate the "force" parameter entirely 
(disclaimer: I need to look at the impact) and want to break bootm up 
into subcommand a'la Kumar's changeset.

Note to Stefan: I don't know how your boot script is set up, but if you 
prefix it with "fdt rm /chosen", I think it will do what you want it to 
do - remove legacy .dts generated /chosen nodes so it doesn't prevent 
bootm/libfdt from generating the /chosen node.  If the "/chosen" node 
doesn't exist, it will print an error (I believe) but otherwise be OK.

Best regards,
gvb

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

[U-Boot] Arm Pull request

[Jean-Christophe PLAGNIOL-VILLARD]

Hi Wolfgang,
Please pull The following changes since commit 
8fd4166c467a46773f80208bda1ec3b4757747bc:
  Stefan Roese (1):
ppc4xx: Canyonlands: Remove unnecessary FDT warning upon DTB fixup

are available in the git repository at:

  git://git.denx.de/u-boot-arm.git Master

Guennadi Liakhovetski (1):
  i.MX31: switch to CFG_HZ=1000

Jean-Christophe PLAGNIOL-VILLARD (4):
  Revert "ARM: set GD_FLG_RELOC for boards skipping relocation to RAM"
  ARM: set GD_FLG_RELOC at board init
  move README.imx31 to doc/ and merge with README.mx31
  update uImage FIT multi documentation

 README.imx31|   13 --
 cpu/arm1136/mx31/interrupts.c   |   79 --
 doc/README.imx31|   29 ++
 doc/README.mx31 |   17 
 doc/uImage.FIT/multi.its|2 +
 include/configs/imx31_litekit.h |4 +-
 include/configs/imx31_phycore.h |2 +-
 include/configs/mx31ads.h   |4 +-
 lib_arm/board.c |   19 +
 9 files changed, 86 insertions(+), 83 deletions(-)
 delete mode 100644 README.imx31
 create mode 100644 doc/README.imx31
 delete mode 100644 doc/README.mx31

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

Re: [U-Boot] [U-Boot-Users] DNS support in U-Boot

[Jerry Van Baren]

Ben Warren wrote:
> On Fri, Oct 3, 2008 at 7:53 AM, Pieter Voorthuijsen
> <[EMAIL PROTECTED]> wrote:
>> Hi,
>>
>> I recently made a simple DNS implementation in U-Boot. The attached
>> file is a patch to U-Boot 1.2.0.
>>
>> DNS can be enabled by setting CFG_CMD_DNS. After performing a
>> query, the serverip environment var is updated.
>>
>> Probably there are some cosmetic issues with the patch.
>> Unfortunatly I do not have the time to correct these. So if anybody
>> else likes DNS support in U-Boot and has the time, feel free to
>> patch it in the main tree.
> 
> Thanks Pieter - this looks useful.
> 
> Wolfgang,
> is the licensing of this code compatible with U-boot?  If so, I'll
> clean it up and include.
> 
> regards,
> Ben

Disclaimer: IANAL

The "beer-ware license" looks to me like the MIT license after the 
author consumed a few beers.
   
On the FSF site
  
the MIT license is listed as the "expat" license and is approved as 
compatible with the GPL
  

It actually looks quite similar to the "Fair" license[1]:
   

In my unprofessional opinion, I would say it is compatible.

Best regards,
gvb

[1] The "Fair" license is listed as a "redundant" license in
   
It doesn't say what it is redundant with, I would assume the MIT license.

Quote from 

Licenses that are redundant with more popular licenses

 Several licenses in this group are excellent licenses and have 
their own followings. The committee struggled with this group, but 
ultimately decided that if we were to attack the license proliferation 
problem, we had to prune licenses. Thus, licenses that were perceived as 
completely or partially redundant with existing licenses were placed in 
this group.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] how can i change u-boot load address?

[sahar mustafa]

hi every one..

currently, u-boot load it self in SDRAM address : 0x8010
i want the u-boot to be loaded to address: 0x80FE.
i have try the following:

1#repeating the last steps preform by the build script:
1-./tools/mkimage -A mips -T firmware -C bzip2 -a 0x8010  -e 0x8010 
-n 'u-boot image' -d u-boot.bz2 u-boot.zimg
2-./mk_ubootimg.sh head.bin u-boot.zimg 12400 u-boot.img
3-mipsel-linux-objcopy -I binary -O binary --pad-to 0x1  u-boot.img
u-boot.img
that of course after changing to the new address, but when downloading it to
the board, it hangs

2#in the mkimage.c file, i have change the code a little:

case 'a':
if (--argc <= 0)
usage ();
addr = strtoul ("0x80FE", (char **)&ptr, 
16);
*++argv;
if (*ptr) {
fprintf (stderr,
"%s: invalid load address %s\n",
cmdname, *argv);
exit (EXIT_FAILURE);

their was no compilation error, but also the board hangs
3# i thought a bout the entry point, and make it to match the load address,
but still the same result.

can you tell me how to change the load address without crippling the u-boot?

with respect
sahar mustafa.

-- 
View this message in context: 
http://www.nabble.com/how-can-i-change-u-boot-load-address--tp19836732p19836732.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] Red Black Tree support

[Amit Kumar Sharma]

Hi Kyungmin

What is the purpose of adding RB in UBI .

Rgs
Amit
- Original Message - 
From: "Wolfgang Denk" <[EMAIL PROTECTED]>
To: "Kyungmin Park" <[EMAIL PROTECTED]>
Cc: 
Sent: Monday, October 06, 2008 12:56 PM
Subject: Re: [U-Boot] [PATCH] Red Black Tree support


> Dear Kyungmin Park,
>
> In message <[EMAIL PROTECTED]> you wrote:
>> RB-tree support on U-Boot
>> Now it's used at UBI module. Of course other modules can 
>> use it.
> ...
>
> I understand the code is a verbatim copy from the LInux 
> kernel?
> Otherwise the coding style violations would not be 
> acceptable.
>
>> diff --git a/lib_generic/Makefile b/lib_generic/Makefile
>> index 7df5a2c..83b41ca 100644
>> --- a/lib_generic/Makefile
>> +++ b/lib_generic/Makefile
>> @@ -45,6 +45,7 @@ COBJS-y += string.o
>>  COBJS-y += strmhz.o
>>  COBJS-y += vsprintf.o
>>  COBJS-y += zlib.o
>> +COBJS-y += rbtree.o
>
> I expect that only few systems will actually use this, so 
> it must be
> configurable. It makes no sense to build this for ALL 
> systems. Please
> add a config option.
>
>
> Best regards,
>
> Wolfgang Denk
>
> -- 
> DENX Software Engineering GmbH, MD: Wolfgang Denk & 
> Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 
> Groebenzell, Germany
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: 
> [EMAIL PROTECTED]
> Reader, suppose you were an idiot. And suppose you were a 
> member  of
> Congress. But I repeat myself.   - 
> Mark Twain
> ___
> 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] Custodian update

[Wolfgang Denk]

Dear Jens Gehrlein,

In message <[EMAIL PROTECTED]> you wrote:
>
> What's about the ARM custodian entry in U-Boot's Gitweb? Peter or 
> Jean-Christophe?

Fixed, thanks for pointing out (it's j24, of course).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Few people do business well who do nothing else.
   -- Philip Earl of Chesterfield
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] u-boot randomly lost params.

[Wolfgang Denk]

Dear gather bzbz,

In message <[EMAIL PROTECTED]> you wrote:
> I am using 1.3.2, and discovered that the params randomly got lost. This does 
> not happen every time, but does happen from time to time. I can not repliably 
> reproduce it. Any hints? I am using a TI6446 EVM. Someone over at the TI 
> mailing list suggests that the size of params is bigger than the param sector 
> size. How to check that? T.I.A

Your line length is *way* too long. Please make sure to use lines of
70 characters max.

Where is your environment stored? In an EEPROM?

If the environment becomes bigger than the reserved space, you will
get error messages, and the last added entry will be ignored.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
I can type faster than I can move a  mouse,  so  I  find  menu-driven
drawing packages time consuming and frustrating.  - W. R. Stevens
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Use correct kzalloc

[Wolfgang Denk]

Dear Kyungmin Park,

In message <[EMAIL PROTECTED]> you wrote:
> I'm not sure calloc returns all zero values.

Why aren't you sure? Check the code...

> Actually the calloc uses the __libc_alloc.

Ooops?  What exactly are you talking about?

It makes no sense to reinvent the wheel here.

If calloc() should have a problem (which I don't believe) it needs to
be fixed.

NAK for this patch.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
The human mind  ordinarily  operates  at  only  ten  percent  of  its
capacity. The rest is overhead for the operating system.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] Red Black Tree support

[Wolfgang Denk]

Dear Kyungmin Park,

In message <[EMAIL PROTECTED]> you wrote:
> RB-tree support on U-Boot 
> Now it's used at UBI module. Of course other modules can use it.
...

I understand the code is a verbatim copy from the LInux kernel?
Otherwise the coding style violations would not be acceptable.

> diff --git a/lib_generic/Makefile b/lib_generic/Makefile
> index 7df5a2c..83b41ca 100644
> --- a/lib_generic/Makefile
> +++ b/lib_generic/Makefile
> @@ -45,6 +45,7 @@ COBJS-y += string.o
>  COBJS-y  += strmhz.o
>  COBJS-y += vsprintf.o
>  COBJS-y += zlib.o
> +COBJS-y += rbtree.o

I expect that only few systems will actually use this, so it must be
configurable. It makes no sense to build this for ALL systems. Please
add a config option.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: [EMAIL PROTECTED]
Reader, suppose you were an idiot. And suppose you were a  member  of
Congress. But I repeat myself.   - Mark Twain
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot