Re: [U-Boot] still an issue ?? - Can't get strong symbol to override weak one

[Wolfgang Denk]

Dear Joachim Rahn,

In message <4ce4d64f.4090...@helmholtz-berlin.de> you wrote:
> 
> O.k. so I will use my small local workaround until your proposed
> patch is accepted and included in the official source tree.

That was pulled into mainline last night.

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's no honorable way to kill, no gentle way to destroy.  There is
nothing good in war.  Except its ending.
-- Abraham Lincoln, "The Savage Curtain", stardate 5906.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Please pull u-boot-sparc.git net branch

[Daniel Hellstrom]

Dear Wolfgang,

Please pull the net branch of the Sparc repository. The patches include 
some bug fixes and debug printout cleanups of the GRETH network driver.

Thanks,
Daniel Hellstrom


The following changes since commit 6163f5b4c8873848ed023054bc401727301ea537:
  Kumar Gala (1):
malloc: Fix issue with calloc memory possibly being non-zero

are available in the git repository at:

  git://www.denx.de/git/u-boot-sparc.git net

Daniel Hellstrom (6):
  GRETH: removed unneccesary register write and one clean up.
  GRETH: made debug printouts use common debug() macro.
  GRETH: Added autodetection of PHY address, or let BSP hardcode it.
  GRETH: Added extra RESET, this is needed if GRETH was stopped 
during an ethernet frame reception.
  GRETH: fixed 2 decriptor table typos
  GRETH: removed space in network driver device name.

 drivers/net/greth.c |  164 
+--
 1 files changed, 94 insertions(+), 70 deletions(-)

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

[U-Boot] [PATCH] Devkit8000: Fix build after introduction of GENERATED_GBL_DATA_SIZE

[Thomas Weber]

This patch fixes the issue by defining and using
CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR.

This patch adopts the
commit 31bfcf1c5776df3d90286aa15104c45096d53dc6
from Steve Sakoman and Sandeep Paulraj on Devkit8000.

Signed-off-by: Thomas Weber 
---
 include/configs/devkit8000.h |6 +-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/include/configs/devkit8000.h b/include/configs/devkit8000.h
index fa7a6c7..d898b77 100644
--- a/include/configs/devkit8000.h
+++ b/include/configs/devkit8000.h
@@ -308,6 +308,10 @@ extern unsigned int boot_flash_type;
 #endif
 
 #define CONFIG_SYS_SDRAM_BASE  PHYS_SDRAM_1
-#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK - 
CONFIG_SYS_GBL_DATA_SIZE)
+#define CONFIG_SYS_INIT_RAM_ADDR0x4020f800
+#define CONFIG_SYS_INIT_RAM_SIZE0x800
+#define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_INIT_RAM_ADDR + \
+
CONFIG_SYS_INIT_RAM_SIZE - \
+
GENERATED_GBL_DATA_SIZE)
 
 #endif /* __CONFIG_H */
-- 
1.7.3.2

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

Re: [U-Boot] still an issue ?? - Can't get strong symbol to override weak one

[Joachim Rahn]

Dear Sebastian,

thanks for the fast response!

O.k. so I will use my small local workaround until your proposed
patch is accepted and included in the official source tree.

Best regards,
Joachim

On 17.11.2010 13:41, Sebastien Carlier wrote:
> Dear Joachim,
> 
> On 2010-11-17 11:38:54, Joachim Rahn wrote:
>>
>> Hi all,
>>
>> I've ported u-boot to our ARM board based on at91sam9263.
>>
>> When I try to use the LED functions I have problems getting
>> strong symbols overriden by weak ones.
>>
>> I'm just stumbling upon the archive entries
>>  http://lists.denx.de/pipermail/u-boot/2008-June/035540.html
>> and
>>  http://lists.denx.de/pipermail/u-boot/2008-July/037619.html
>>
>> Seems I have exact that problem.
>> Has this been solved?
> 
> This issue is solved by this patch:
> 
> 
> http://www.denx.de/wiki/pub/U-Boot/TooBigPatches/0001-Switch-from-archive-libraries-to-partial-linking-v4.patch
> 
> Here is the relevant thread from the mailing list:
> 
> http://www.mail-archive.com/u-boot@lists.denx.de/msg41959.html
> 
> Note that the patch has not yet made it into U-Boot and may change again
> before it is accepted.
> 
> Regards,

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

Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps fullduplex in SGMII mode"

[Li Yang-R58472]

>Subject: RE: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps
>fullduplex in SGMII mode"
>
>On Wed, 2010-11-17 at 21:13 -0700, Li Yang-R58472 wrote:
>> >Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps
>> >full duplex in SGMII mode"
>> >
>> >Hi Zhao,
>> >
>> >> In message <1289986984-2314-1-git-send-email-b26...@freescale.com>
>> >> you
>> >wrote:
>> >> > On P2020DS and MPC8572DS, the link to SGMII card which use
>> >> > Vitesse
>> >> > VSC8234 PHY can't come up. Current TBI PHY
>> >> > settings(TBICR_SETTINGS) for SGMII mode cause link problems.
>> >> >
>> >> > Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it.
>> >
>> >Based on my company's discussions with Freescale and Freescale's
>> >appnotes I believe that the current implementation is correct.  I
>> >make reference to some of this in the original patch:
>> >http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbp
>> >s- full-duplex-in-SGMII-mode-td26188785.html
>> >
>> >We use Broadcom PHYs on our boards, which likely has something to do
>> >with the discrepancies between the P2020DS/MPC8572DS vs the
>> >XPedite5370/XPedite5500.  Unless you have additional information that
>> >shows that in-band SGMII auto-negotiation does work per the spec I'd
>> >prefer to keep the current tsec.c code and add
>> >CONFIG_TSEC_TBICR_SETTINGS workarounds to the P2020DS (already done
>> >in commit
>> >90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS.
>>
>>
>> Hi Peter,
>>
>> From the App Note you mentioned, I didn't find that the auto-negotiation
>can't be used.
>
>My understanding is that the SGMII link is always at 1000Mbps speed - see
>figure 1 from the app note.  Additionally look at figure 3.  My understand
>from it, and the app note's text is that SGMII auto-negotiation doesn't
>really occur - its just passing the PHY-side auto-negotiation results to
>the Freescale MAC, which software then configures.  I'm not sure what the
>purpose of the "SGMII auto-negotiation" is - its not really auto-
>negotiating and the same information can be read from the PHY via its MDIO
>interface, which is what is happening on X-ES boards currently.

I guess the point is to save MDIO signals to the external PHY and read the
negotiated result from the internal TBI PHY.

>
>We were told by a Freescale FAE that SGMII auto-negotiation wasn't
>supported, although 1000 BASE-X auto-negotation was (which mirrored our
>test results).  I can dig up the old emails tomorrow at the office with
>the details.
>
>> Actually we need the auto-negotiation enabled for almost all Freescale
>reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards.  If we
>disable the auto-negotiation on these boards, the SGMII link won't
>work.  So I guess it might be more common to use auto-negotiation, and a
>fixed 1000M link is more like a special case.  I'm not sure what's the
>recommended way for SGMII PHY interconnect though.
>
>And auto-negotation doesn't work on X-ES hardware which all use Broadcom
>PHYs - which is why I made the original change after consulting a
>Freescale FAE.  Its not a huge deal to me either way as long as the
>XPedite5370 and XPedite5500 continue to not use SGMII auto-negotiation.
>Can someone at Freescale provide a definitive answer about what the proper
>SGMII auto-negotiation scheme is?  And has anyone used it successfully or
>unsuccessfully with a non-Vitesse PHY?
>
>Best,
>Peter



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

Re: [U-Boot] [PATCH v4 1/1] imx: Get fec mac address from fuse

[Jason Liu]

2010/11/18 Wolfgang Denk :
> Dear Jason Liu,
>
> In message <1290059063-20899-1-git-send-email-r64...@freescale.com> you wrote:
>> The patch is to support getting FEC MAC address from fuse bank.
>>
>> Signed-off-by: Jason Liu 
> ...
>> +struct fuse_bank1_regs {
>> +     u32     fuse0_8[9];
>> +     u32     mac_addr[6];
>> +     u32     fuse5_31[0x11];
>
> This looks wrong to me. It's 0...8, 9...14, 15...31 o the last field's
> name should be fuse15_31 ?

Sorry, typo error, it should be fuse15_31[0x11];
Thanks for your good review.

>
> 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
> Nearly everyone is in favor of going  to  heaven  but  too  many  are
> hoping  they'll  live  long  enough  to see an easing of the entrance
> requirements. Never appeal to a man's "better nature." he  might  not
> have one.
> ___
> 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 V5 1/2] ARM: fix linker file for newer ld support

[Albert ARIBAUD]

Le 17/11/2010 20:45, Wolfgang Denk a écrit :

>> older ld emitted all ELF relocations in input sections named
>> .rel.dyn, whereas newer ld uses names of the form .rel*. The
>> linker script only collected .rel.dyn input sections. Rewrite
>> to collect all .rel* input sections.
>>
>> Signed-off-by: Albert Aribaud

> Applied to u-boot-arm, thanks.

Thanks.

> Best regards,
>
> Wolfgang Denk

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

Re: [U-Boot] [PATCH v4 1/1] imx: Get fec mac address from fuse

[Wolfgang Denk]

Dear Jason Liu,

In message <1290059063-20899-1-git-send-email-r64...@freescale.com> you wrote:
> The patch is to support getting FEC MAC address from fuse bank.
> 
> Signed-off-by: Jason Liu 
...
> +struct fuse_bank1_regs {
> + u32 fuse0_8[9];
> + u32 mac_addr[6];
> + u32 fuse5_31[0x11];

This looks wrong to me. It's 0...8, 9...14, 15...31 o the last field's
name should be fuse15_31 ?

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
Nearly everyone is in favor of going  to  heaven  but  too  many  are
hoping  they'll  live  long  enough  to see an easing of the entrance
requirements. Never appeal to a man's "better nature." he  might  not
have one.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH v4 1/1] imx: Get fec mac address from fuse

[Jason Liu]

The patch is to support getting FEC MAC address from fuse bank.

Signed-off-by: Jason Liu 

---
Changes for v2:
 - correct the mac address byte order according to review comments
 - add memset(edev, 0. sizeof(*edev)) when do fec_probe,
 - fix some code comments
Changes for v3:
 - rebase
 - address the comments of Stefano, make the imx_get_mac_from_fuse(),
   declared independently inside each imx-regs.h to make it specific
   for each processor, because it accesses to different structures.
 - address the comments of Wolfgang and Stefano, use struct to access
   mac_addr fuse.
Changes for v4:
 - Address the comments of Wolfgang, use fuse_regs instead of bank addres
   and change from fuse1_6 to fuse0_5 naming convention and use fuse_bank0_regs
   instead of fuse_bank0 to kill misleading.
---
 arch/arm/cpu/arm926ejs/mx25/generic.c |   12 ++
 arch/arm/cpu/arm926ejs/mx27/generic.c |   12 ++
 arch/arm/cpu/armv7/mx5/soc.c  |   14 
 arch/arm/include/asm/arch-mx25/imx-regs.h |   19 +--
 arch/arm/include/asm/arch-mx27/imx-regs.h |   18 ++-
 arch/arm/include/asm/arch-mx5/imx-regs.h  |   34 +
 drivers/net/fec_mxc.c |   15 +
 7 files changed, 96 insertions(+), 28 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index b80a389..4ac7bbb 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -260,4 +260,16 @@ void mx25_fec_init_pins (void)
writel (outpadctl, &padctl->pad_fec_tdata1);
 
 }
+
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = &iim->bank[0];
+   struct fuse_bank0_regs *fuse =
+   (struct fuse_bank0_regs *)bank->fuse_regs;
+
+   for (i = 0; i < 6; i++)
+   mac[i] = readl(&fuse->mac_addr[i]);
+}
 #endif /* CONFIG_FEC_MXC */
diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c 
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index ae2ce58..ceaac48 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -313,6 +313,18 @@ void mx27_fec_init_pins(void)
for (i = 0; i < ARRAY_SIZE(mode); i++)
imx_gpio_mode(mode[i]);
 }
+
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = &iim->bank[0];
+   struct fuse_bank0_regs *fuse =
+   (struct fuse_bank0_regs *)bank->fuse_regs;
+
+   for (i = 0; i < 6; i++)
+   mac[6-1-i] = readl(&fuse->mac_addr[i]);
+}
 #endif /* CONFIG_FEC_MXC */
 
 #ifdef CONFIG_MXC_MMC
diff --git a/arch/arm/cpu/armv7/mx5/soc.c b/arch/arm/cpu/armv7/mx5/soc.c
index 7c7a565..c22d6dc 100644
--- a/arch/arm/cpu/armv7/mx5/soc.c
+++ b/arch/arm/cpu/armv7/mx5/soc.c
@@ -100,6 +100,20 @@ int cpu_eth_init(bd_t *bis)
return rc;
 }
 
+#if defined(CONFIG_FEC_MXC)
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank *bank = &iim->bank[1];
+   struct fuse_bank1_regs *fuse =
+   (struct fuse_bank1_regs *)bank->fuse_regs;
+
+   for (i = 0; i < 6; i++)
+   mac[i] = readl(&fuse->mac_addr[i]);
+}
+#endif
+
 /*
  * Initializes on-chip MMC controllers.
  * to override, implement board_mmc_init()
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index f5a2929..55ad115 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -36,6 +36,7 @@
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_FEC_MXC
 extern void mx25_fec_init_pins(void);
+extern void imx_get_mac_from_fuse(unsigned char *mac);
 #endif
 
 /* Clock Control Module (CCM) registers */
@@ -129,12 +130,17 @@ struct iim_regs {
u32 iim_srev;
u32 iim_prog_p;
u32 res1[0x1f5];
-   u32 iim_bank_area0[0x20];
-   u32 res2[0xe0];
-   u32 iim_bank_area1[0x20];
-   u32 res3[0xe0];
-   u32 iim_bank_area2[0x20];
+   struct fuse_bank {
+   u32 fuse_regs[0x20];
+   u32 fuse_rsvd[0xe0];
+   } bank[3];
 };
+
+struct fuse_bank0_regs {
+   u32 fuse0_25[0x1a];
+   u32 mac_addr[6];
+};
+
 #endif
 
 /* AIPS 1 */
@@ -312,7 +318,4 @@ struct iim_regs {
 #define WSR_UNLOCK10x
 #define WSR_UNLOCK20x
 
-/* FUSE bank offsets */
-#define IIM0_MAC   0x1a
-
 #endif /* _IMX_REGS_H */
diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h 
b/arch/arm/include/asm/arch-mx27/imx-regs.h
index 6ecddaa..3095839 100644
--- a/arch/arm/include/asm/arch-mx27/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx27/imx-regs.h
@@ -34,6 +34,7 @@ extern void mx27_u

Re: [U-Boot] ELDK support MPC8641D

[Wolfgang Denk]

Dear Brent Bartson,

In message <83a42a417fd59e48917448f8390945b70cb...@exchange1.qvm.local> you 
wrote:
>
> Does ELDK support MPC8641D ?

Yes, it does.  See
http://www.denx.de/wiki/view/DULG/ELDKSupportedTargetArchitectures

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 technology distinguishable from magic is insufficiently advanced.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/2][NEXT] Davinci 8xx: Move common functions to share code

[Sughosh Ganu]

hi Ben,

On Wed Nov 17, 2010 at 11:26:47AM -0500, Ben Gardiner wrote:
> Hi Stefano,
> 
> On Wed, Nov 17, 2010 at 5:09 AM, Stefano Babic  wrote:
> > [...]
> > diff --git a/arch/arm/include/asm/arch-davinci/da8xx_common.h 
> > b/arch/arm/include/asm/arch-davinci/da8xx_common.h
> > deleted file mode 100644
> > index 8b564f7..000
> > --- a/arch/arm/include/asm/arch-davinci/da8xx_common.h
> > +++ /dev/null
> > @@ -1,33 +0,0 @@
> > -void irq_init(void);
> > -int da8xx_configure_lpsc_items(const struct lpsc_resource *item,
> > -                                   int n_items);
> > -#if defined(CONFIG_DRIVER_TI_EMAC) && 
> > defined(CONFIG_MACH_DAVINCI_DA850_EVM)
> > -void da850_emac_mii_mode_sel(int mode_sel);
> > -#endif
> 
> I don't know what is the best way to proceed... I like the current
> state of this patch series. I was unable to apply the three patch
> series (Sugosh's, Yours and mine) in any order without conflicts.

  I think you would need to rebase your patch 'da850: Add RMII
  support for EMAC', on top of my patches. I had made changes in the
  include/asm/arch-davinci/hardware.h and moved the
  board/davinci/da8xxevm/common.h, both of which you are making
  changes to. Stefano's patch series should then apply on top of your
  rebased patch. Missed out your patch, else would have flagged you in
  advance. Sorry about that.

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

Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode"

[Peter Tyser]

On Wed, 2010-11-17 at 21:13 -0700, Li Yang-R58472 wrote:
> >Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full
> >duplex in SGMII mode"
> >
> >Hi Zhao,
> >
> >> In message <1289986984-2314-1-git-send-email-b26...@freescale.com> you
> >wrote:
> >> > On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse
> >> > VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS)
> >> > for SGMII mode cause link problems.
> >> >
> >> > Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it.
> >
> >Based on my company's discussions with Freescale and Freescale's appnotes
> >I believe that the current implementation is correct.  I make reference to
> >some of this in the original patch:
> >http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps-
> >full-duplex-in-SGMII-mode-td26188785.html
> >
> >We use Broadcom PHYs on our boards, which likely has something to do with
> >the discrepancies between the P2020DS/MPC8572DS vs the
> >XPedite5370/XPedite5500.  Unless you have additional information that
> >shows that in-band SGMII auto-negotiation does work per the spec I'd
> >prefer to keep the current tsec.c code and add CONFIG_TSEC_TBICR_SETTINGS
> >workarounds to the P2020DS (already done in commit
> >90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS.
> 
> 
> Hi Peter,
> 
> From the App Note you mentioned, I didn't find that the auto-negotiation 
> can't be used.

My understanding is that the SGMII link is always at 1000Mbps speed -
see figure 1 from the app note.  Additionally look at figure 3.  My
understand from it, and the app note's text is that SGMII
auto-negotiation doesn't really occur - its just passing the PHY-side
auto-negotiation results to the Freescale MAC, which software then
configures.  I'm not sure what the purpose of the "SGMII
auto-negotiation" is - its not really auto-negotiating and the same
information can be read from the PHY via its MDIO interface, which is
what is happening on X-ES boards currently.

We were told by a Freescale FAE that SGMII auto-negotiation wasn't
supported, although 1000 BASE-X auto-negotation was (which mirrored our
test results).  I can dig up the old emails tomorrow at the office with
the details.

> Actually we need the auto-negotiation enabled for almost all Freescale 
> reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards.  If we 
> disable the auto-negotiation on these boards, the SGMII link won't work.  So 
> I guess it might be more common to use auto-negotiation, and a fixed 1000M 
> link is more like a special case.  I'm not sure what's the recommended way 
> for SGMII PHY interconnect though.

And auto-negotation doesn't work on X-ES hardware which all use Broadcom
PHYs - which is why I made the original change after consulting a
Freescale FAE.  Its not a huge deal to me either way as long as the
XPedite5370 and XPedite5500 continue to not use SGMII auto-negotiation.
Can someone at Freescale provide a definitive answer about what the
proper SGMII auto-negotiation scheme is?  And has anyone used it
successfully or unsuccessfully with a non-Vitesse PHY?

Best,
Peter

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

Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode"

[Li Yang-R58472]

>Subject: Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full
>duplex in SGMII mode"
>
>Hi Zhao,
>
>> In message <1289986984-2314-1-git-send-email-b26...@freescale.com> you
>wrote:
>> > On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse
>> > VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS)
>> > for SGMII mode cause link problems.
>> >
>> > Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it.
>
>Based on my company's discussions with Freescale and Freescale's appnotes
>I believe that the current implementation is correct.  I make reference to
>some of this in the original patch:
>http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps-
>full-duplex-in-SGMII-mode-td26188785.html
>
>We use Broadcom PHYs on our boards, which likely has something to do with
>the discrepancies between the P2020DS/MPC8572DS vs the
>XPedite5370/XPedite5500.  Unless you have additional information that
>shows that in-band SGMII auto-negotiation does work per the spec I'd
>prefer to keep the current tsec.c code and add CONFIG_TSEC_TBICR_SETTINGS
>workarounds to the P2020DS (already done in commit
>90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS.


Hi Peter,

>From the App Note you mentioned, I didn't find that the auto-negotiation can't 
>be used.

Actually we need the auto-negotiation enabled for almost all Freescale 
reference boards such as P2020DS, MPC8572DS and P1/P2 RDB boards.  If we 
disable the auto-negotiation on these boards, the SGMII link won't work.  So I 
guess it might be more common to use auto-negotiation, and a fixed 1000M link 
is more like a special case.  I'm not sure what's the recommended way for SGMII 
PHY interconnect though.

- Leo


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

Re: [U-Boot] [PATCH v1] add mv_sdio driver for sheevaplug

[Prafulla Wadaskar]

Hi Gerald
Sorry for late feedback, please find my comments inlined.

> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Gérald Kerma
> Sent: Sunday, August 29, 2010 4:07 AM
> To: u-boot@lists.denx.de
> Subject: [U-Boot] [PATCH v1] add mv_sdio driver for sheevaplug
> 
> Add mvsdio driver to Kirkwood SoC
> Add SDIO support to SHEEVAPLUG
> Fix environments for SHEEVAPLUG

You should break this patch into small pieces as per functionalities like-
1. Kirkwood: add more timer functions
2. Kirkwood: pre-requisite for SDIO driver support
3. mmc : Add SDIO driver for Marvell SoCs (Kirkwood)
4. Sheevaplug: Add MMC/SDIO support
5. Sheevaplug: Fix environments for 
6. Guruplug: Add MMC/SDIO support (as Clint suggested- Optional)

> 
> Signed-off-by: Gérald Kerma 
> ---
> Changes in v1:
>  * Fix errors from SD/SDHC detect
>  * Minor fixes in boot env
> 
>  arch/arm/cpu/arm926ejs/kirkwood/timer.c   |   23 +
>  arch/arm/include/asm/arch-kirkwood/kirkwood.h |1 +
>  drivers/mmc/Makefile  |1 +
>  drivers/mmc/mv_sdio.c |  747
> +
>  drivers/mmc/mv_sdio.h |  296 ++
>  include/configs/sheevaplug.h  |   65 ++-
>  6 files changed, 1124 insertions(+), 9 deletions(-)
> 
> diff --git a/arch/arm/cpu/arm926ejs/kirkwood/timer.c
> b/arch/arm/cpu/arm926ejs/kirkwood/timer.c
> index 2ec6a93..c8f932b 100644
> --- a/arch/arm/cpu/arm926ejs/kirkwood/timer.c
> +++ b/arch/arm/cpu/arm926ejs/kirkwood/timer.c
> @@ -166,3 +166,26 @@ int timer_init(void)
> 
>   return 0;
>  }
> +
> +
> +/*
> + * This function is derived from PowerPC code (read timebase as long
> long).
> + * On ARM it just returns the timer value.
> + */
> +unsigned long long get_ticks(void)
> +{
> + return get_timer(0);
> +}

This is not needed, you can directly use get_timer(0) wherever needed

> +
> +/*
> + * This function is derived from PowerPC code (timebase clock frequency).
> + * On ARM it returns the number of timer ticks per second.
> + */
> +ulong get_tbclk (void)
> +{
> + ulong tbclk;
> +
> + tbclk = CONFIG_SYS_HZ;
> + return tbclk;
> +}

Ditto, 

> +
> diff --git a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
> b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
> index 0104418..4f9fe7e 100644
> --- a/arch/arm/include/asm/arch-kirkwood/kirkwood.h
> +++ b/arch/arm/include/asm/arch-kirkwood/kirkwood.h
> @@ -60,6 +60,7 @@
>  #define KW_EGIGA0_BASE   (KW_REGISTER(0x72000))
>  #define KW_EGIGA1_BASE   (KW_REGISTER(0x76000))
>  #define KW_SATA_BASE (KW_REGISTER(0x8))
> +#define KW_SDIO_BASE (KW_REGISTER(0x9))
> 
>  /* Kirkwood Sata controller has two ports */
>  #define KW_SATA_PORT0_OFFSET 0x2000
> diff --git a/drivers/mmc/Makefile b/drivers/mmc/Makefile
> index 8dfd8a3..f1e7db6 100644
> --- a/drivers/mmc/Makefile
> +++ b/drivers/mmc/Makefile
> @@ -31,6 +31,7 @@ COBJS-$(CONFIG_BFIN_SDH) += bfin_sdh.o
>  COBJS-$(CONFIG_OMAP3_MMC) += omap3_mmc.o
>  COBJS-$(CONFIG_FSL_ESDHC) += fsl_esdhc.o
>  COBJS-$(CONFIG_MXC_MMC) += mxcmmc.o
> +COBJS-$(CONFIG_MV_SDIO) += mv_sdio.o

Please maintain order here

>  COBJS-$(CONFIG_PXA_MMC) += pxa_mmc.o
>  COBJS-$(CONFIG_S5P_MMC) += s5p_mmc.o
> 
> diff --git a/drivers/mmc/mv_sdio.c b/drivers/mmc/mv_sdio.c
> new file mode 100644
> index 000..aa8df10
> --- /dev/null
> +++ b/drivers/mmc/mv_sdio.c
> @@ -0,0 +1,747 @@
> +/*
> + * (C) Copyright 2003
> + * Kyle Harris, Nexus Technologies, Inc. khar...@nexus-tech.net
> + * Copyright (C) 2010 Gérald Kerma 
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "mv_sdio.h"
> +#include 
> +#include 
> +#include 

Please use #ifdef CONFIG_KIRKWOOD here since driver name is generic and not 
Kirkwood specific

> +#include 

> +
> +#ifdef CONFIG_MMC
> +
> +#define DRIVER_NAME "mv-sdio"
> +
> +//#define DEBUG
> +
> +//static int maxfreq = MVSD_CLOCKRATE_MAX;
> +//static int nodma;

Remove dead code, please post clean code

> +
> +static int is_s

Re: [U-Boot] [PATCH v1] add mv_sdio driver for sheevaplug

[Prafulla Wadaskar]

First of all Thanks for pinging on this. 
Yes, we can, but this needs some more modifications.
I will provide review comments for this patch ASAP

Regards..
Prafulla . .

> -Original Message-
> From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
> On Behalf Of Clint Adams
> Sent: Thursday, November 18, 2010 6:31 AM
> To: Gérald Kerma
> Cc: u-boot@lists.denx.de
> Subject: Re: [U-Boot] [PATCH v1] add mv_sdio driver for sheevaplug
> 
> On Sun, Aug 29, 2010 at 12:37:16AM +0200, Gérald Kerma wrote:
> > Add mvsdio driver to Kirkwood SoC
> > Add SDIO support to SHEEVAPLUG
> 
> Gérald, can this be adapted for GuruPlug?
> ___
> 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] Ax88782 ethernet driver support in u-boot 3.0.2.7

[sethu madhav]

Hi,



My environment is OMAP3 – board with u-boot 3.0.2.7 . The Ethernet chip
which  is present on my hardware is AX88782



I have checked in the u-boot . There is support for Ax88796. I would like to
know is there any u-boot driver for Ax88782 ?

If Anyone can provide the driver for the Ax88782 in the u-boot 3.0.2.7, It
would be much helpful.

Or If any similar device driver present in the u-boot is also helpful to me.



Your help in this regards is very much appreciated.



Thanks,

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

Re: [U-Boot] [PATCH v1] add mv_sdio driver for sheevaplug

[Clint Adams]

On Sun, Aug 29, 2010 at 12:37:16AM +0200, Gérald Kerma wrote:
> Add mvsdio driver to Kirkwood SoC
> Add SDIO support to SHEEVAPLUG

Gérald, can this be adapted for GuruPlug?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] ELDK support MPC8641D

[Brent Bartson]

Hello,

Does ELDK support MPC8641D ?

Regards,
bbart...@xembedded.com

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

Re: [U-Boot] fw_setenv broken?

[Wolfgang Denk]

Dear Steve Sakoman,

In message <1290034139.2927.1192.ca...@quadra> you wrote:
>
> I patched readenv to use the same nand_read_skip_bad function used in
> the command line "nand read" tool.  I no longer get the -EUCLEAN errors
> when reading the environment after using fw_setenv to write from linux.
> Now I get:
> 
> *** Warning - bad CRC, using default environment
> 
> Checking the data with the "nand read" command line shows that the
> changes I made in linux are indeed there, so I suspect that there is
> also some mismatch in the CRC computation between the fw tools and the
> u-boot code (i.e. I'm pretty sure this error does *not* refer to the
> nand CRC)

Try and use the "crc32" command in U-Boot tocheck if the checksum is
correct. Check if the environment size in your board config file and
in the fw_env.conf file match.  Check if both match wether or not
redundant env is used.

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 amount of time between slipping on the peel and  landing  on  the
pavement is precisely 1 bananosecond.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Steve Sakoman]

On Wed, 2010-11-17 at 16:08 -0600, Scott Wood wrote:
> On Wed, 17 Nov 2010 22:40:49 +0100
> Wolfgang Denk  wrote:
> 
> > Dear Steve Sakoman,
> > 
> > In message  
> > you wrote:
> > >
> > > readenv: offset = 24
> > > readenv: nand_read failure = -117
> > > *** Warning - readenv() failed, using default environment
> > > 
> > > I then immediately tried to use the nand read command to read the same
> > > block, and it was successful!
> > 
> > Hm... any chance that - for example - your timers are not working
> > correctly before relocation (maybe because they try to write to the
> > not yet available data segment) ? This could cause timeouts or delays
> > to be too short, so the NAND driver is misbehaving?
> 
> The NAND driver only works after relocation.
> 
> It looks like the problem is that -EUCLEAN is a non-fatal error
> (indicates a correctable ECC error).  The code invoked by the "nand
> read" command succeeds if nand_read() returns either 0 or -EUCLEAN, but
> readenv() is missing this check.

OK, we seem to be peeling back the layers of the onion now.

I patched readenv to use the same nand_read_skip_bad function used in
the command line "nand read" tool.  I no longer get the -EUCLEAN errors
when reading the environment after using fw_setenv to write from linux.
Now I get:

*** Warning - bad CRC, using default environment

Checking the data with the "nand read" command line shows that the
changes I made in linux are indeed there, so I suspect that there is
also some mismatch in the CRC computation between the fw tools and the
u-boot code (i.e. I'm pretty sure this error does *not* refer to the
nand CRC)

Steve


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

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Mike Frysinger]

On Wednesday, November 17, 2010 14:53:33 Sebastien Carlier wrote:
> On 2010-11-17 13:06:49, Mike Frysinger wrote:
> > On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
> > > The size increase you noted seems to completely go away when adding
> > > --gc-sections to LDFLAGS, but this option apparently brings its own
> > > 
> > > issues when the linker discards important unreferenced bits:
> > > http://www.mail-archive.com/u-boot@lists.denx.de/msg41762.html
> > > http://www.mail-archive.com/u-boot@lists.denx.de/msg42063.html
> > > 
> > > These problems can be fixed within linker scripts, but I think it might
> > > be safer to use --gc-sections for diagnostic purposes only...
> > 
> > it's really not that hard to fix things to work with --gc-sections (ive
> > been using it on Blackfin for literally years at this point).  people
> > really should be driving to have that supported everywhere.
> 
> Maybe I was being overly conservative.  With --gc-sections, I assume the
> linker only needs to be told to keep any section that has no external
> references to it, which would only include startup code and reset
> vectors.  Is that accurate?

yes

> Is there any other case that may need special handling?

the u-boot command handling is a bit funky and needs handling, but that was 
implemented years ago in common code, so ports need not worry about it

> I suppose -ffunction-sections and -fdata-sections increase compile time;
> are they worth it in practice?

in practice, the difference is irrelevant.  for the bf548-ezkit build (a 
fairly large image -- in the 512KiB range), i run on a dual core system:
git clean -x -d -q
time make -s -j2 bf548-ezkit

with the section flags, i get ~5.7 seconds.  without, i get ~5.1 seconds.

> The few cases I have seen involved whole
> objects being unused, so just --gc-sections would deal with them.

it also takes care of unused common code and library functions.  for Blackfin 
systems, i provide the full common GPIO API in one file, but any local funcs 
that no one uses all get discarded.

it also keeps down horrible ifdef messes where the only point point would be 
to move gcc's DCE step to CPP.

again, to refer to the bf548-ezkit, i get ~10KB of .text removed by this alone
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Scott Wood]

On Wed, 17 Nov 2010 22:40:49 +0100
Wolfgang Denk  wrote:

> Dear Steve Sakoman,
> 
> In message  you 
> wrote:
> >
> > readenv: offset = 24
> > readenv: nand_read failure = -117
> > *** Warning - readenv() failed, using default environment
> > 
> > I then immediately tried to use the nand read command to read the same
> > block, and it was successful!
> 
> Hm... any chance that - for example - your timers are not working
> correctly before relocation (maybe because they try to write to the
> not yet available data segment) ? This could cause timeouts or delays
> to be too short, so the NAND driver is misbehaving?

The NAND driver only works after relocation.

It looks like the problem is that -EUCLEAN is a non-fatal error
(indicates a correctable ECC error).  The code invoked by the "nand
read" command succeeds if nand_read() returns either 0 or -EUCLEAN, but
readenv() is missing this check.

-Scott

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

[U-Boot] Freie Stelle. Vertrag. Heimarbeit/Nebenverdienst.

[amnatcharoen]

Guten Tag.

Die Firma sucht Handelsmanager in Deutschland.. Wir bieten die interessante 
Arbeit in der Gesellschaft mit der soliden Autoritat. 
Die Moglichkeit, entfernt am Wohnsitz zu arbeiten. Der flexible  Arbeitsplan, 
er lasst Ihnen, diese Arbeit mit Ihrer Tatigkeit zu vereinen. 
Keine besondere Erfahrung ist fur diese Position erforderlich. Teilzeit / 
Vollzeit. Vertrag. 


Wenn Sie diese Stelle in unserem Unternehmen bekommen moechten, senden Sie 
bitte E-Mail an unseren HR-Abteilung: ragty...@gmail.com


Antworten Sie auf diese Mitteilung nicht, weil es nicht bekommen sein wird, 
senden Sie bitte E-Mail an unseren HR-Abteilung.

Vielen Dank fur das Lesen dieses E-Mail.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Steve Sakoman]

On Wed, Nov 17, 2010 at 1:40 PM, Wolfgang Denk  wrote:
> Dear Steve Sakoman,
>
> In message  you 
> wrote:
>>
>> readenv: offset = 24
>> readenv: nand_read failure = -117
>> *** Warning - readenv() failed, using default environment
>>
>> I then immediately tried to use the nand read command to read the same
>> block, and it was successful!
>
> Hm... any chance that - for example - your timers are not working
> correctly before relocation (maybe because they try to write to the
> not yet available data segment) ? This could cause timeouts or delays
> to be too short, so the NAND driver is misbehaving?

Hmm . . . I suppose that is possible, but it doesn't seem to explain
why environment data written by u-boot will always be read
successfully, but reads of linux written data fails.

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

Re: [U-Boot] Pull request: u-boot-arm

[Wolfgang Denk]

Dear =?iso-8859-1?Q?Lo=EFc?= Minier,

In message <20101117213409.ga16...@bee.dooz.org> you wrote:
> Hey
> 
> On Wed, Nov 17, 2010, Wolfgang Denk wrote:
> > Sanjeev Premi (3):
> >   omap3evm: Support relocation
> >   omap3evm: Wrap function under CONFIG_USB_OMAP3
> >   omap3evm: Fix mechanism to identify board revision
> 
>  I was expecting this would fix the build of omap3_evm, but it still
>  fails for me:
>  http://hudson.dooz.org/job/u-boot_master/BOARD=3Domap3_evm/39/console
> make[1]: Entering directory `/srv/hudson.dooz.org/home/jobs/u-boot_master/w=
> orkspace/BOARD/omap3_evm/arch/arm/cpu/armv7'
> arm-linux-gnueabi-gcc   -D__ASSEMBLY__ -g  -Os   -fno-common -ffixed-r8 -ms=
> oft-float   -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=3D0x80008000 -I/srv/hudson.=
> dooz.org/home/jobs/u-boot_master/workspace/BOARD/omap3_evm/include -fno-bui=
> ltin -ffreestanding -nostdinc -isystem /usr/lib/gcc/arm-linux-gnueabi/4.4.5=
> /include -pipe  -DCONFIG_ARM -D__ARM__ -marm  -mabi=3Daapcs-linux -mno-thum=
> b-interwork -march=3Darmv5   \
> -o start.o start.S -c
> start.S: Assembler messages:
> start.S:144: Error: constant expression expected -- `ldr sp,=3D((0x4020FFFC=
> -CONFIG_SYS_GBL_DATA_SIZE))'
> make[1]: *** [start.o] Error 1
> make[1]: Leaving directory `/srv/hudson.dooz.org/home/jobs/u-boot_master/wo=
> rkspace/BOARD/omap3_evm/arch/arm/cpu/armv7'

CONFIG_SYS_GBL_DATA_SIZE does not exist any more; it now gets
auto-generated.  Seems there are a few boards out there that escaped
the change:

-> find * -type f | xargs egrep -l CONFIG_SYS_GBL_DATA_SIZE
include/configs/io.h
include/configs/devkit8000.h
include/configs/omap3_evm.h
include/configs/iocon.h

Patches welcome.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
"To take a significant step forward, you must make a series of finite
improvements." - Donald J. Atwood, General Motors
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Wolfgang Denk]

Dear Scott Wood,

In message <20101117152851.767ec...@udp111988uds.am.freescale.net> you wrote:
>
> > > So, I keep the same setting. If I change it, some guys main complain
> > > why it change, it will make it
> > > incompatible with the original env setting and make the customer env lost.

I missed that part.  Agreed, this is a problem, but a small one.
In a well-maintained product, sucha configuration change should be
properly maintained.  Most probably users will receive a release note,
which may (read: should) contain a description of the update
procedure.

In this specific case, users can use "env import" to restore (before
overwriting) their old environmnt settings.

> I think he was talking about CRCs failing after U-Boot is upgraded --
> whether the environment content is large or small, changing the size
> will change the CRC.  The environment header doesn't say what the size
> is, or else compatibility could be maintained that way.

You are right. I missed that point.

> Specifying the size in the environment header would also allow you to
> just CRC the part that has actual data, while allowing the environment
> to grow up to the entire sector if needed.

Eventually such a change is not even difficult to implement. The
length field could be prepended, shifting the remaining data by 4
bytes.  As before, "env import" could be used to recover old
environment settings.

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 algorithm to do that is extremely nasty. You might want  to  mug
someone with it."   - M. Devine, Computer Science 340
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] Mapping of DDR parameters to manufacturers SPD data for specific DDR

[Brent Bartson]

Hello,

I'm trying to configure an MPC8641D design to utilize 'memory down' (i.e. with 
no SPD) so the SPD params need to be hard-coded. It looks like this is possible 
through undef of CFG_SPD_EEPROM. However, I'm having a difficult time 
correlating the u-boot params such as CFG_DDR_CS0_BNDS, etc to the SPD params 
on the memory manufacturers SPD data sheet. Is there some cheater document 
available for this?

Thanks,
Brent


__ Information from ESET NOD32 Antivirus, version of virus signature 
database 5627 (20101117) __

The message was checked by ESET NOD32 Antivirus.

http://www.eset.com

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

Re: [U-Boot] [PATCH] powerpc/85xx: Relocate env_addr if we CONFIG_SYS_RAMBOOT

[Scott Wood]

On Wed, 17 Nov 2010 21:58:31 +0100
Wolfgang Denk  wrote:

> Dear Kumar Gala,
> 
> In message <1290008461-21171-1-git-send-email-ga...@kernel.crashing.org> you 
> wrote:
> > We use CONFIG_SYS_RAMBOOT for when boot out of NAND, SPI, SDHC/MMC
> > and utilize a L2 or L3 cache in SRAM mode.  In this case we will
> > end up changing the cache from SRAM mode back to cache before we
> > relocate the environment properly in env_relocate().
> > 
> > So we need to manual relocate the env pointer out of SRAM into DDR.
> > 
> > Signed-off-by: Kumar Gala 
> > ---
> >  arch/powerpc/lib/board.c |   12 
> >  1 files changed, 12 insertions(+), 0 deletions(-)
> > 
> > diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
> > index 2e0749d..5ce9caa 100644
> > --- a/arch/powerpc/lib/board.c
> > +++ b/arch/powerpc/lib/board.c
> > @@ -645,6 +645,18 @@ void board_init_r (gd_t *id, ulong dest_addr)
> > gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;
> >  #endif
> >  
> > +#if defined(CONFIG_MPC85xx) && defined(CONFIG_SYS_RAMBOOT)
> > +   /*
> > +* We use CONFIG_SYS_RAMBOOT for when boot out of NAND, SPI, SDHC/MMC
> 
> I think this is a bad misuse of the CONFIG_SYS_RAMBOOT variable here.
> Assume I have a 85xx system where U-Boot gets loaded by some means
> into DDR.  Of course I will have CONFIG_MPC85xx and CONFIG_SYS_RAMBOOT
> set, but I do not want in any way that this special mechanism kicks
> in.

Instead of trying to guess whether this is a boot scenario that needs
this, how about checking env_addr to see if it falls within the bounds
of the old image?  If so, relocate it.

-Scott

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

Re: [U-Boot] fw_setenv broken?

[Wolfgang Denk]

Dear Steve Sakoman,

In message  you 
wrote:
>
> readenv: offset = 24
> readenv: nand_read failure = -117
> *** Warning - readenv() failed, using default environment
> 
> I then immediately tried to use the nand read command to read the same
> block, and it was successful!

Hm... any chance that - for example - your timers are not working
correctly before relocation (maybe because they try to write to the
not yet available data segment) ? This could cause timeouts or delays
to be too short, so the NAND driver is misbehaving?

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
Q:  Do you know what the death rate around here is?
A:  One per person.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Steve Sakoman]

On Wed, Nov 17, 2010 at 12:47 PM, Wolfgang Denk  wrote:
> Dear Steve Sakoman,
>
> In message  you 
> wrote:
>>
>> After writing the environment with fw_setenv in linux, u-boot's read
>> of the environment on the subsequent boot always fails with either
>> EBADMSG or EUCLEAN.
>
> Can you read - in U-Boot - any other data written in Linux?
> Ecventually there is some discrepance for example in the use of sw
> versus hw ECC or such?

I just did that experiment!

As I mentioned, after writing with fw_setenv, I get an error in u-boot
(I added a couple of printf's to indicate the offset being read from
as well as any error codes returned):

U-Boot 2010.12-rc1 (Nov 17 2010 - 11:20:23)

OMAP3630/3730-GP ES1.0, CPU-OPP2, L3-165MHz, Max CPU Clock 1 Ghz
Gumstix Overo board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
readenv: offset = 24
readenv: nand_read failure = -117
*** Warning - readenv() failed, using default environment

I then immediately tried to use the nand read command to read the same
block, and it was successful!

Overo # nand read 8200 24 2

NAND read: device 0 offset 0x24, size 0x2
 131072 bytes read: OK

Not only that, the data read looks correct!

Overo # md 8200 140
8200: bd8c0c16 64756162 65746172 3531313dbaudrate=115
8210: 00303032 746f6f62 3d646d63 6d206669200.bootcmd=if m
8220: 7220636d 61637365 7b24206e 64636d6dmc rescan ${mmcd
8230: 3b7d7665 65687420 6669206e 6e757220ev}; then if run
8240: 616f6c20 6f6f6264 72637374 3b747069 loadbootscript;
8250: 65687420 7572206e 6f62206e 6373746f then run bootsc
8260: 74706972 6c6d203b 69206573 75722066ript; mlse if ru
8270: 6f6c206e 69756461 6567616d 6874203bn loaduimage; th
8280: 72206e65 6d206e75 6f62636d 203b746fen run mmcboot;
8290: 65736c65 6e757220 6e616e20 6f6f6264else run nandboo
82a0: 66203b74 66203b69 65203b69 2065736ct; fi; fi; else
82b0: 206e7572 646e616e 746f6f62 6966203brun nandboot; fi
82c0: 6f6f6200 6c656474 353d7961 6f6f6200.bootdelay=5.boo
82d0: 72637374 3d747069 6f686365 6e755220tscript=echo Run
82e0: 676e696e 6f6f6220 72637374 20747069ning bootscript
82f0: 6d6f7266 636d6d20 2e2e2e20 6f73203bfrom mmc ...; so
82000100: 65637275 6c7b2420 6164616f 7d726464urce ${loadaddr}
82000110: 6e6f6300 656c6f73 7974743d 312c3253.console=ttyS2,1
82000120: 30323531 00386e30 61666564 64746c7515200n8.defaultd
82000130: 6c707369 643d7961 64006976 64696569isplay=dvi.dieid
82000140: 32363d23 30306535 62313030 30303066#=625e1bf000
82000150: 31303030 39333735 37306165 3066323000015739ea0702f0
82000160: 64006530 6f6d6976 313d6564 783432300e.dvimode=1024x
82000170: 4d383637 36312d52 00303640 61687465768mr...@60.etha
82000180: 733d7463 3139636d 302d7831 616f6c00ct=smc911x-0.loa
82000190: 64646164 78303d72 30303238 30303030daddr=0x8200
820001a0: 616f6c00 6f6f6264 72637374 3d747069.loadbootscript=
820001b0: 6c746166 2064616f 20636d6d 6d6d7b24fatload mmc ${mm
820001c0: 76656463 7b24207d 64616f6c 72646461cdev} ${loadaddr
820001d0: 6f62207d 732e746f 6c007263 7564616f} boot.scr.loadu
820001e0: 67616d69 61663d65 616f6c74 6d6d2064image=fatload mm
820001f0: 7b242063 64636d6d 207d7665 6f6c7b24c ${mmcdev} ${lo
82000200: 64616461 207d7264 616d4975 6d006567adaddr} uImage.m
82000210: 7261636d 733d7367 6e657465 6f622076mcargs=setenv bo
82000220: 7261746f 63207367 6f736e6f 243d656cotargs console=$
82000230: 6e6f637b 656c6f73 706d207d 74617275{console} mpurat
82000240: 7b243d65 7275706d 7d657461 61727620e=${mpurate} vra
82000250: 7b243d6d 6d617276 6d6f207d 62667061m=${vram} omapfb
82000260: 646f6d2e 76643d65 7b243a69 6d697664.mode=dvi:${dvim
82000270: 7d65646f 616d6f20 2e626670 75626564ode} omapfb.debu
82000280: 20793d67 70616d6f 2e737364 5f666564g=y omapdss.def_
82000290: 70736964 647b243d 75616665 6964746cdisp=${defaultdi
820002a0: 616c7073 72207d79 3d746f6f 6d6d7b24splay} root=${mm
820002b0: 6f6f7263 72207d74 66746f6f 70797473croot} rootfstyp
820002c0: 7b243d65 72636d6d 66746f6f 70797473e=${mmcrootfstyp
820002d0: 6d007d65 6f62636d 653d746f 206f6863e}.mmcboot=echo
820002e0: 746f6f42 20676e69 6d6f7266 636d6d20Booting from mmc
820002f0: 2e2e2e20 7572203b 6d6d206e 67726163 ...; run mmcarg
82000300: 62203b73 6d746f6f 6c7b2420 6164616fs; bootm ${loada
82000310: 7d726464 636d6d00 3d766564 6d6d0030ddr}.mmcdev=0.mm
82000320: 6f6f7263 642f3d74 6d2f7665 6c62636dcroot=/dev/mmcbl
82000330: 3270306b 00777220 72636d6d 66746f6fk0p2 rw.mmcrootf
82000340: 70797473 78653d65 72203374 77746f6fstype=ext3 rootw
82000350: 00746961 646e616e 73677261 7465733dait.nandargs=set
82000360: 20766e65 746f6f62 73677261 6e6f6320env bootargs con
82000370: 656c6f73 637b243d 6f736e6f 207d656csole=${console}
82000380: 7275706d 3d657461 706d7b24 74617275mpur

Re: [U-Boot] [PATCH 0/2] ARMV7: Fixing Vexpress build errors and warnings

[Loïc Minier]

Hey Wolfgang!

 Would you mind considering these patches from earlier this month for
 u-boot-arm?  These fixes the build of ca9x4_ct_vxp which currently
 fails for me:
 http://hudson.dooz.org/job/u-boot_master/BOARD=ca9x4_ct_vxp/39/console
arm-linux-gnueabi-gcc  -g  -Os   -fno-common -ffixed-r8 -msoft-float   
-D__KERNEL__ 
-I/srv/hudson.dooz.org/home/jobs/u-boot_master/workspace/BOARD/ca9x4_ct_vxp/include
 -fno-builtin -ffreestanding -nostdinc -isystem 
/usr/lib/gcc/arm-linux-gnueabi/4.4.5/include -pipe  -DCONFIG_ARM -D__ARM__ 
-marm  -mabi=aapcs-linux -mno-thumb-interwork -march=armv5 -Wall 
-Wstrict-prototypes -DBUILD_TAG='"hudson-BOARD=ca9x4_ct_vxp-39"' 
-fno-stack-protector   \
-o syslib.o syslib.c -c
syslib.c:26: fatal error: asm/arch/sys_proto.h: No such file or directory
compilation terminated.

Thanks!

On Tue, Nov 02, 2010, Matt Waddel wrote:
> From: Matt Waddel 
> 
> These patches fix several build errors and warnings. A successful build for 
> this platform depends on Steve Sakoman's "ARMV7: Fix build for non-OMAP3 
> boards" patch.
> 
> Matt Waddel (2):
>   ARMV7: Vexpress build errors
>   ARMV7: Vexpress compile warnings
> 
>  arch/arm/include/asm/arch-armv7/sys_proto.h |   29 
>  board/armltd/vexpress/ca9x4_ct_vxp.c|9 +++-
>  board/armltd/vexpress/config.mk |3 +-
>  board/armltd/vexpress/u-boot.lds|   65 
> ---
>  4 files changed, 36 insertions(+), 70 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-armv7/sys_proto.h
>  delete mode 100644 board/armltd/vexpress/u-boot.lds

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

Re: [U-Boot] Pull request: u-boot-arm

[Loïc Minier]

Hey

On Wed, Nov 17, 2010, Wolfgang Denk wrote:
> Sanjeev Premi (3):
>   omap3evm: Support relocation
>   omap3evm: Wrap function under CONFIG_USB_OMAP3
>   omap3evm: Fix mechanism to identify board revision

 I was expecting this would fix the build of omap3_evm, but it still
 fails for me:
 http://hudson.dooz.org/job/u-boot_master/BOARD=omap3_evm/39/console
make[1]: Entering directory 
`/srv/hudson.dooz.org/home/jobs/u-boot_master/workspace/BOARD/omap3_evm/arch/arm/cpu/armv7'
arm-linux-gnueabi-gcc   -D__ASSEMBLY__ -g  -Os   -fno-common -ffixed-r8 
-msoft-float   -D__KERNEL__ -DCONFIG_SYS_TEXT_BASE=0x80008000 
-I/srv/hudson.dooz.org/home/jobs/u-boot_master/workspace/BOARD/omap3_evm/include
 -fno-builtin -ffreestanding -nostdinc -isystem 
/usr/lib/gcc/arm-linux-gnueabi/4.4.5/include -pipe  -DCONFIG_ARM -D__ARM__ 
-marm  -mabi=aapcs-linux -mno-thumb-interwork -march=armv5   \
-o start.o start.S -c
start.S: Assembler messages:
start.S:144: Error: constant expression expected -- `ldr 
sp,=((0x4020FFFC-CONFIG_SYS_GBL_DATA_SIZE))'
make[1]: *** [start.o] Error 1
make[1]: Leaving directory 
`/srv/hudson.dooz.org/home/jobs/u-boot_master/workspace/BOARD/omap3_evm/arch/arm/cpu/armv7'

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

Re: [U-Boot] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Scott Wood]

On Wed, 17 Nov 2010 08:42:16 +0100
Wolfgang Denk  wrote:

> Dear Jason Liu,
> 
> In message  you 
> wrote:
> > So, I keep the same setting. If I change it, some guys main complain
> > why it change, it will make it
> > incompatible with the original env setting and make the customer env lost.
> 
> I doubt that. I think I have seen a fair share of different
> environment settings. There are many, many in the 1...2 KiB range.
> Very, very few exceed 4 KiB. You have to search really hard to find
> one that gets close to 8KiB.

I think he was talking about CRCs failing after U-Boot is upgraded --
whether the environment content is large or small, changing the size
will change the CRC.  The environment header doesn't say what the size
is, or else compatibility could be maintained that way.

Specifying the size in the environment header would also allow you to
just CRC the part that has actual data, while allowing the environment
to grow up to the entire sector if needed.

-Scott

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

[U-Boot] [RFC PATCH] ARM: S3C64XX: add support for mini6410

[Darius Augulis]

Add support for mini6410 from FriendlyARM

Signed-off-by: Darius Augulis 
---
 MAKEALL |1 
 Makefile|4 
 arch/arm/cpu/arm1176/s3c64xx/Makefile   |6 -
 board/friendly_arm/mini6410/Makefile|   59 +
 board/friendly_arm/mini6410/config.mk   |5 
 board/friendly_arm/mini6410/lowlevel_init.S |  256 +++
 board/friendly_arm/mini6410/mini6410.c  |   99 +
 boards.cfg  |1 
 include/configs/mini6410.h  |  137 
 nand_spl/board/friendly_arm/mini6410/Makefile   |  107 ++
 nand_spl/board/friendly_arm/mini6410/config.mk  |7 +
 nand_spl/board/friendly_arm/mini6410/u-boot.lds |   85 
 nand_spl/nand_boot_s3c.c|  131 
 13 files changed, 896 insertions(+), 2 deletions(-)
 create mode 100644 board/friendly_arm/mini6410/Makefile
 create mode 100644 board/friendly_arm/mini6410/config.mk
 create mode 100644 board/friendly_arm/mini6410/lowlevel_init.S
 create mode 100644 board/friendly_arm/mini6410/mini6410.c
 create mode 100644 include/configs/mini6410.h
 create mode 100644 nand_spl/board/friendly_arm/mini6410/Makefile
 create mode 100644 nand_spl/board/friendly_arm/mini6410/config.mk
 create mode 100644 nand_spl/board/friendly_arm/mini6410/u-boot.lds
 create mode 100644 nand_spl/nand_boot_s3c.c

diff --git a/MAKEALL b/MAKEALL
index 767d561..556aa82 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -404,6 +404,7 @@ LIST_ARM11="\
imx31_litekit   \
imx31_phycore   \
imx31_phycore_eet   \
+   mini6410\
mx31ads \
mx31pdk \
mx31pdk_nand\
diff --git a/Makefile b/Makefile
index f0c2703..4dab98d 100644
--- a/Makefile
+++ b/Makefile
@@ -1087,6 +1087,10 @@ smdk6400_config  :   unconfig
@$(MKCONFIG) smdk6400 arm arm1176 smdk6400 samsung s3c64xx
@echo "CONFIG_NAND_U_BOOT = y" >> $(obj)include/config.mk
 
+mini6410_config :  unconfig
+   @mkdir -p $(obj)include
+   @$(MKCONFIG) mini6410 arm arm1176 mini6410 friendly_arm s3c64xx
+
 #
 # MIPS
 #
diff --git a/arch/arm/cpu/arm1176/s3c64xx/Makefile 
b/arch/arm/cpu/arm1176/s3c64xx/Makefile
index b527939..6ce2b06 100644
--- a/arch/arm/cpu/arm1176/s3c64xx/Makefile
+++ b/arch/arm/cpu/arm1176/s3c64xx/Makefile
@@ -1,4 +1,7 @@
 #
+# (C) Copyright 2010
+# Darius Augulis, 
+#
 # (C) Copyright 2000-2003
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 #
@@ -30,8 +33,7 @@ LIB   = $(obj)lib$(SOC).a
 
 SOBJS  = reset.o
 
-COBJS-$(CONFIG_S3C6400)+= cpu_init.o speed.o
-COBJS-y+= timer.o
+COBJS-y+= timer.o cpu_init.o speed.o
 
 OBJS   := $(addprefix $(obj),$(SOBJS) $(COBJS-y))
 
diff --git a/board/friendly_arm/mini6410/Makefile 
b/board/friendly_arm/mini6410/Makefile
new file mode 100644
index 000..a1dbc41
--- /dev/null
+++ b/board/friendly_arm/mini6410/Makefile
@@ -0,0 +1,59 @@
+#
+# (C) Copyright 2010
+# Darius Augulis, 
+#
+# (C) Copyright 2000, 2001, 2002
+# Wolfgang Denk, DENX Software Engineering, w...@denx.de.
+#
+# (C) Copyright 2008
+# Guennadi Liakhovetki, DENX Software Engineering, 
+#
+# 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+#
+
+include $(TOPDIR)/config.mk
+
+LIB= $(obj)lib$(BOARD).a
+
+COBJS  += mini6410.o
+SOBJS  := lowlevel_init.o
+
+SRCS   := $(SOBJS:.o=.S) $(COBJS:.o=.c)
+OBJS   := $(addprefix $(obj),$(COBJS))
+SOBJS  := $(addprefix $(obj),$(SOBJS))
+
+.PHONY: all
+
+all: $(LIB)
+
+$(LIB):$(obj).depend $(OBJS) $(SOBJS)
+   $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS)
+
+clean:
+   rm -f $(SOBJS) $(OBJS)
+
+distclean: clean
+   rm -f $(LIB) core *.bak *~ .depend
+
+#
+# This is for $(obj).depend target
+include $(SRCTREE)/rules.mk
+
+sinclude $(obj).depend
+
+#
diff -

Re: [U-Boot] [PATCH v2] malloc: Fix issue with calloc memory possibly being non-zero

[Wolfgang Denk]

Dear Kumar Gala,

In message <1289868103-7702-1-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> Since we set #define MORECORE_CLEARS 1, the code assumes 'sbrk' always
> returns zero'd out memory.  However since its possible that free()
> returns memory back to sbrk() via malloc_trim we could possible get
> non-zero'd memory from sbrk().  This is a problem for when code might
> call calloc() and expect the memory to have been zero'd out.
> 
> There are two possible solutions to this problem.
> 1. change #define MORECORE_CLEARS 0
> 2. memset to zero memory returned to sbrk.
> 
> We go with the second since the sbrk being called to free up memory
> should be pretty rare.
> 
> The following code problems an example test to show the issue.  This
> test code was inserted right after the call to mem_malloc_init().
> 
> ...
>u8 *p2;
>int i;
> 
>printf("MALLOC TEST\n");
>p1 = malloc(135176);
>printf("P1 = %p\n", p1);
>memset(p1, 0xab, 135176);
> 
>free(p1);
>p2 = calloc(4097, 1);
>printf("P2 = %p %p\n", p2, p2 + 4097);
> 
>for (i = 0; i < 4097; i++) {
>  if (p2[i] != 0)
>  printf("miscompare at byte %d got %x\n", i, p2[i]);
> 
>free(p2);
>printf("END MALLOC TEST\n\n");
> ...
> 
> Signed-off-by: Kumar Gala 
> Tested-by: Wolfgang Denk 
> ---
> * Fix commit message screw up
> 
>  common/dlmalloc.c |7 +++
>  1 files changed, 7 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
Memories of you remind me of you.   - Karl Lehenbauer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] net: e1000: typo using wrong argument to sizeof

[Wolfgang Denk]

Dear Matthew McClintock,

In message <1289865773-10922-1-git-send-email-...@freescale.com> you wrote:
> Typo from 4b29bdb0ed08412d225a8be94f61fc6c37a59dd5
> 
> Signed-off-by: Matthew McClintock 
> ---
>  drivers/net/e1000.c |2 +-
>  1 files changed, 1 insertions(+), 1 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
"A child is a person who can't understand why someone would give away
a perfectly good kitten."   - Doug Larson
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mpc83xx: Make it boot again

[Joakim Tjernlund]

Scott Wood  wrote on 2010/11/17 20:27:01:
>
> On Wed, 17 Nov 2010 20:15:01 +0100
> Joakim Tjernlund  wrote:
>
> > Scott Wood  wrote on 2010/11/17 20:03:25:
> > > The "load, conditional branch, isync" sequence is documented in the
> > > architecture manual (1.7.1), "even if the effects of the 'dependency'
> > > are independent of the value loaded".
> >
> > So it doesn't matter what address you do twi on?
> > Still, it would make a little more sense if
> > it read twi 0,r3,0
>
> It's not an address, it's data that is being compared with zero.  And it
> has to be r4, since that's what you want to create the data dependency
> on.

aha, should have looked closer on twi.

>
> The architecture suggests a similar but slightly longer sequence (but
> I don't think the wording rules out using twi), which may make the
> intent clearer:
>
> lwz   r4, ...
> cmpw   r4, r4
> beq   1f
> 1: isync

I hope so because this is a lot of fuzz for something so
simple, especially as the space is already GUARDED and no cache.

 Jocke

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

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Scott Wood]

On Wed, 17 Nov 2010 03:25:05 -0700
"Xie Shaohui-B21989"  wrote:

> From: Wood Scott-B07421 
> Sent: Wednesday, November 17, 2010 5:55 AM
> To: Wolfgang Denk
> Cc: Xie Shaohui-B21989; u-boot@lists.denx.de; Gala Kumar-B11780
> Subject: Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from
> espi flash for p4080ds.
> 
>  
> Yes, a simple C tool to take an existing PBL or RCW dump and "espi-ize"
> it into a PBL dump would be nice.  The user will still need to acquire
> the existing RCW manually.  This only needs to be done once on a board;
> it's not part of building a U-Boot image.
> 
> 
> 
> 
> [Xie Shaohui] A simple C tool will make things more complex, the
> pbl_image_tool does the same thing

It doesn't do the same thing for poeple who don't have access to it.

Plus, requiring the user to do a bunch of manual stuff is not "the same
thing" as something more automated.

More work for us upfront is not the same as "more complex".

> and it is irreplaceable,

Tell that to the people trying to replace it with some big
Eclipse-based thing. :-)

> something like RCW has to be produced manually, and because there is no
> near-universal default RCW, this README took a basic assumption that
> user already can boot from NOR flash, so user can reuse the RCW dump of
> NOR u-boot with change "PBI_SRC" and "BOOT_LOC" only.

Yes.  But once the user provides an RCW, everything else should be
automatable.

-Scott

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

Re: [U-Boot] [PATCH] powerpc/85xx: Relocate env_addr if we CONFIG_SYS_RAMBOOT

[Wolfgang Denk]

Dear Kumar Gala,

In message <1290008461-21171-1-git-send-email-ga...@kernel.crashing.org> you 
wrote:
> We use CONFIG_SYS_RAMBOOT for when boot out of NAND, SPI, SDHC/MMC
> and utilize a L2 or L3 cache in SRAM mode.  In this case we will
> end up changing the cache from SRAM mode back to cache before we
> relocate the environment properly in env_relocate().
> 
> So we need to manual relocate the env pointer out of SRAM into DDR.
> 
> Signed-off-by: Kumar Gala 
> ---
>  arch/powerpc/lib/board.c |   12 
>  1 files changed, 12 insertions(+), 0 deletions(-)
> 
> diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
> index 2e0749d..5ce9caa 100644
> --- a/arch/powerpc/lib/board.c
> +++ b/arch/powerpc/lib/board.c
> @@ -645,6 +645,18 @@ void board_init_r (gd_t *id, ulong dest_addr)
>   gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;
>  #endif
>  
> +#if defined(CONFIG_MPC85xx) && defined(CONFIG_SYS_RAMBOOT)
> + /*
> +  * We use CONFIG_SYS_RAMBOOT for when boot out of NAND, SPI, SDHC/MMC

I think this is a bad misuse of the CONFIG_SYS_RAMBOOT variable here.
Assume I have a 85xx system where U-Boot gets loaded by some means
into DDR.  Of course I will have CONFIG_MPC85xx and CONFIG_SYS_RAMBOOT
set, but I do not want in any way that this special mechanism kicks
in.

Please use a (new) specific feature-define for this.

Please also make sure to check other parts of the code if they use
this obviously unsuitable construct!


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
We fight only when there is no other choice. We prefer  the  ways  of
peaceful contact.
-- Kirk, "Spectre of the Gun", stardate 4385.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Wolfgang Denk]

Dear Kumar Gala,

In message  you wrote:
> 
> How does kwbimage.c work?  Does it just wrap the image generated by mkimage 
> differently?  Can it take any additional input files?

It does take an additional input file.

We have several such externsion in "mkimage" now: Marvell has their
"kwbimage" format, Freescale has their "imximage" format. 

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
"Ahead warp factor 1"  - Captain Kirk
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Wolfgang Denk]

Dear Steve Sakoman,

In message  you 
wrote:
>
> After writing the environment with fw_setenv in linux, u-boot's read
> of the environment on the subsequent boot always fails with either
> EBADMSG or EUCLEAN.

Can you read - in U-Boot - any other data written in Linux?
Ecventually there is some discrepance for example in the use of sw
versus hw ECC or such?

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
Include the success of others in your dreams for your own success.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Scott Wood]

On Wed, 17 Nov 2010 13:42:43 +0100
Detlev Zundel  wrote:

> > Yes, a simple C tool to take an existing PBL or RCW dump and "espi-ize"
> > it into a PBL dump would be nice.  The user will still need to acquire
> > the existing RCW manually.  This only needs to be done once on a board;
> > it's not part of building a U-Boot image.
> 
> @Scott: What is meant by "acquiring the existing RCW"?  Can't we have a
> tool that is fed with a value for RCW?

I mean that a simple tool could take an existing RCW and modify it for
espi boot, but it needs to take as input an RCW that is valid for other
parameters.

The least error prone way to do this, for a user that wants to take a
board that's already successfully booting from NOR and make it boot
from eSPI, is to extract the RCW they're already using from the board.

Creating an RCW from scratch is more complicated, which is why we
have that javascript tool -- though we could provide some example RCWs
for common configs.

> > This README describes how to build an Image can be used by PBL (pre-boot
> > loader), building u-boot image is the first step, then RCW, PBI
> > commands, XXD dump of u-boot.bin, the tool will combine the RCW and PBI
> > and XXD dump together to produce the PBL XXD file, suppose the PBL XXD
> > file is saved as x.xxd, we need to run "xxd -r x.xxd > pbl_image.bin" to
> > produce the final PBL Image. Take a look at the whole process, I see no
> > way it can be scripted / automatized.
> 
> I said it once before, look at how kwbimage wraps up u-boot.bin into
> such an "augmented" image.  If the Marvell guys can do this for their
> platform, I see no reason why this cannot be done for your platform.

Sure, once you have a valid input RCW it should be possible to automate
the rest.

-Scott

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

Re: [U-Boot] fw_setenv broken?

[Steve Sakoman]

On Wed, Nov 17, 2010 at 9:39 AM, Wolfgang Denk  wrote:
> Dear Stefano Babic,
>
> In message <4ce4092b.7090...@denx.de> you wrote:
>> On 11/17/2010 05:30 PM, Steve Sakoman wrote:
>> > I'm seeing some strange behavior with the fw_setenv tools on OMAP.
>> >
>> > Here's what I see when using the tools on OMAP (overo in this case):
>> >
>> > 1. fw_printenv prints the environment with no issues [1]
>> > 2. fw_setenv allows me to change a variable with no reported errors [2]
>> > 3. fw_printenv will print the changed environment, however the variables
>> > are not sorted [3]
>>
>> I tested yesterday on a davinci board, I can confirm this behavior, I
>> have not thought was an error. I do not see any code in fw_env.c to sort
>> variables. I konow the variables are sorted in u-boot, but do we ever
>> have this feature on the userland fw_printenv ?
>
> Indeed this behaviour is normal. fw_printenv does not sort the output
> (not yet - patches welcome).
>
>> > I added debug printf's to readenv() in env_nand.c and the root cause is
>> > an error return from ret=nand_read(&nand_info[0], offset, &len,
>> > char_ptr)).  I get an error code of -74
>> >
>> > Before I spend too much time on this I wanted to check to see if others
>> > are seeing this issue, or whether it might be OMAP specific.
>>
>> At least this should not be a general failure, because it works on my
>> target. It could be also nand specific.
>
> Thanks for confirming this.
>
> Well, the next step should be a review of the code, where error -74
> gets set and what that probably means...

I've experimented on a couple of boards and it seems to always fail.

The nand_do_read_ops function in nand_base.c ends like so:

if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;

return  mtd->ecc_stats.corrected - stats.corrected ? -EUCLEAN : 0;
}

After writing the environment with fw_setenv in linux, u-boot's read
of the environment on the subsequent boot always fails with either
EBADMSG or EUCLEAN.

I'll keep digging, but perhaps the above might mean something to
someone with more knowledge of the nand driver.

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

Re: [U-Boot] Pull request: u-boot-arm

[Wolfgang Denk]

Dear Wolfgang Denk,

In message <20101117195029.907fb14e...@gemini.denx.de> you wrote:
> The following changes since commit d963e84c92a63b4e6c4f2f80482a5ecbe9b24fe0:
> 
>   Merge branch 'master' of /home/wd/git/u-boot/master (2010-11-12 22:24:06 
> +0100)
> 
> are available in the git repository at:
> 
>   git://git.denx.de/u-boot-arm.git master
> 
> Alagu Sankar (1):
>   mmc: Add multi-block read support to the generic mmc driver
> 
> Albert Aribaud (2):
>   ARM: fix linker file for newer ld support
>   tx25: fix linker file for newer ld support
> 
> Enric Balletbo i Serra (2):
>   ARMV7: OMAP3: Use generic mmc driver on IGEP v2
>   ARMV7: OMAP3: Use generic mmc driver on OMAP3 IGEP module
> 
> Heiko Schocher (1):
>   armv7, beagle: Second SDRAM bank don;t work
> 
> Koen Kooi (1):
>   ARMV7: OMAP3: Add expansion board detection for Beagle
> 
> Reinhard Meyer (2):
>   AT91: add 2nd SPI to 9260/9XE/9G20
>   AT91: add header file for the Shutdown Controller
> 
> Sanjeev Premi (3):
>   omap3evm: Support relocation
>   omap3evm: Wrap function under CONFIG_USB_OMAP3
>   omap3evm: Fix mechanism to identify board revision
> 
> Steve Sakoman (5):
>   ARMV7: OMAP3: IGEP: Rename TEXT_BASE
>   ARMV7: Fix build for non-OMAP3 boards
>   ARMV7: OMAP3: Add expansion board detection for Overo
>   ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
>   mmc: Clean up generic mmc driver multi-block write functions
> 
> Wolfgang Denk (2):
>   Merge branch 'at91' of git://git.denx.de/u-boot-atmel
>   Merge branch 'master' of git://git.denx.de/u-boot-ti
> 
>  arch/arm/cpu/arm1136/start.S |   16 ---
>  arch/arm/cpu/arm1136/u-boot.lds  |   38 ---
>  arch/arm/cpu/arm1176/u-boot.lds  |   37 +++
>  arch/arm/cpu/arm926ejs/u-boot.lds|   30 +++--
>  arch/arm/cpu/armv7/omap3/sdrc.c  |7 ++
>  arch/arm/cpu/armv7/start.S   |   24 
>  arch/arm/cpu/armv7/u-boot.lds|   46 +
>  arch/arm/cpu/pxa/u-boot.lds  |   35 --
>  arch/arm/include/asm/arch-at91/at91_shdwn.h  |   38 +++
>  arch/arm/include/asm/arch-at91/at91sam9260.h |1 +
>  arch/arm/include/asm/arch-at91/hardware.h|1 +
>  arch/arm/include/asm/arch-at91/memory-map.h  |1 +
>  arch/arm/lib/cache.c |2 +-
>  board/isee/igep0020/config.mk|2 +-
>  board/isee/igep0020/igep0020.c   |9 ++
>  board/isee/igep0030/config.mk|3 +-
>  board/isee/igep0030/igep0030.c   |9 ++
>  board/overo/overo.c  |  115 
>  board/overo/overo.h  |4 +
>  board/ti/beagle/beagle.c |   95 
>  board/ti/beagle/beagle.h |   46 -
>  board/ti/evm/config.mk   |2 +-
>  board/ti/evm/evm.c   |   24 -
>  board/ti/evm/evm.h   |2 +
>  drivers/mmc/mmc.c|  148 +
>  include/configs/igep0020.h   |9 ++-
>  include/configs/igep0030.h   |9 ++-
>  include/configs/omap3_beagle.h   |8 +-
>  include/configs/omap3_evm.h  |   11 ++
>  include/configs/omap3_overo.h|7 +-
>  include/configs/omap4_panda.h|6 +-
>  include/configs/omap4_sdp4430.h  |6 +-
>  nand_spl/board/karo/tx25/u-boot.lds  |   40 
>  33 files changed, 576 insertions(+), 255 deletions(-)
>  create mode 100644 arch/arm/include/asm/arch-at91/at91_shdwn.h

Applied.

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 whole world is about three drinks behind." - Humphrey Bogart
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Sebastien Carlier]

Dear Mike,

On 2010-11-17 13:06:49, Mike Frysinger wrote:
> On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
> > On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> > > I notice that the patch affects the size of the resulting U-Boot
> > > images.
> > 
> > The size increase you noted seems to completely go away when adding
> > --gc-sections to LDFLAGS, but this option apparently brings its own
> > issues when the linker discards important unreferenced bits:
> > 
> > http://www.mail-archive.com/u-boot@lists.denx.de/msg41762.html
> > http://www.mail-archive.com/u-boot@lists.denx.de/msg42063.html
> > 
> > These problems can be fixed within linker scripts, but I think it might
> > be safer to use --gc-sections for diagnostic purposes only...
> 
> it's really not that hard to fix things to work with --gc-sections (ive been 
> using it on Blackfin for literally years at this point).  people really 
> should 
> be driving to have that supported everywhere.

Maybe I was being overly conservative.  With --gc-sections, I assume the
linker only needs to be told to keep any section that has no external
references to it, which would only include startup code and reset
vectors.  Is that accurate?  Is there any other case that may need
special handling?

I suppose -ffunction-sections and -fdata-sections increase compile time;
are they worth it in practice?  The few cases I have seen involved whole
objects being unused, so just --gc-sections would deal with them.

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

[U-Boot] Pull request: u-boot-arm

[Wolfgang Denk]

The following changes since commit d963e84c92a63b4e6c4f2f80482a5ecbe9b24fe0:

  Merge branch 'master' of /home/wd/git/u-boot/master (2010-11-12 22:24:06 
+0100)

are available in the git repository at:

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

Alagu Sankar (1):
  mmc: Add multi-block read support to the generic mmc driver

Albert Aribaud (2):
  ARM: fix linker file for newer ld support
  tx25: fix linker file for newer ld support

Enric Balletbo i Serra (2):
  ARMV7: OMAP3: Use generic mmc driver on IGEP v2
  ARMV7: OMAP3: Use generic mmc driver on OMAP3 IGEP module

Heiko Schocher (1):
  armv7, beagle: Second SDRAM bank don;t work

Koen Kooi (1):
  ARMV7: OMAP3: Add expansion board detection for Beagle

Reinhard Meyer (2):
  AT91: add 2nd SPI to 9260/9XE/9G20
  AT91: add header file for the Shutdown Controller

Sanjeev Premi (3):
  omap3evm: Support relocation
  omap3evm: Wrap function under CONFIG_USB_OMAP3
  omap3evm: Fix mechanism to identify board revision

Steve Sakoman (5):
  ARMV7: OMAP3: IGEP: Rename TEXT_BASE
  ARMV7: Fix build for non-OMAP3 boards
  ARMV7: OMAP3: Add expansion board detection for Overo
  ARMV7: OMAP: Fix build after introduction of GENERATED_GBL_DATA_SIZE
  mmc: Clean up generic mmc driver multi-block write functions

Wolfgang Denk (2):
  Merge branch 'at91' of git://git.denx.de/u-boot-atmel
  Merge branch 'master' of git://git.denx.de/u-boot-ti

 arch/arm/cpu/arm1136/start.S |   16 ---
 arch/arm/cpu/arm1136/u-boot.lds  |   38 ---
 arch/arm/cpu/arm1176/u-boot.lds  |   37 +++
 arch/arm/cpu/arm926ejs/u-boot.lds|   30 +++--
 arch/arm/cpu/armv7/omap3/sdrc.c  |7 ++
 arch/arm/cpu/armv7/start.S   |   24 
 arch/arm/cpu/armv7/u-boot.lds|   46 +
 arch/arm/cpu/pxa/u-boot.lds  |   35 --
 arch/arm/include/asm/arch-at91/at91_shdwn.h  |   38 +++
 arch/arm/include/asm/arch-at91/at91sam9260.h |1 +
 arch/arm/include/asm/arch-at91/hardware.h|1 +
 arch/arm/include/asm/arch-at91/memory-map.h  |1 +
 arch/arm/lib/cache.c |2 +-
 board/isee/igep0020/config.mk|2 +-
 board/isee/igep0020/igep0020.c   |9 ++
 board/isee/igep0030/config.mk|3 +-
 board/isee/igep0030/igep0030.c   |9 ++
 board/overo/overo.c  |  115 
 board/overo/overo.h  |4 +
 board/ti/beagle/beagle.c |   95 
 board/ti/beagle/beagle.h |   46 -
 board/ti/evm/config.mk   |2 +-
 board/ti/evm/evm.c   |   24 -
 board/ti/evm/evm.h   |2 +
 drivers/mmc/mmc.c|  148 +
 include/configs/igep0020.h   |9 ++-
 include/configs/igep0030.h   |9 ++-
 include/configs/omap3_beagle.h   |8 +-
 include/configs/omap3_evm.h  |   11 ++
 include/configs/omap3_overo.h|7 +-
 include/configs/omap4_panda.h|6 +-
 include/configs/omap4_sdp4430.h  |6 +-
 nand_spl/board/karo/tx25/u-boot.lds  |   40 
 33 files changed, 576 insertions(+), 255 deletions(-)
 create mode 100644 arch/arm/include/asm/arch-at91/at91_shdwn.h

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
 This message was made from 100% recycled electrons. 
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V5 2/2] tx25: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert Aribaud,

In message <1289853964-6525-2-git-send-email-albert.arib...@free.fr> you wrote:
> older ld emitted all ELF relocations in input sections named
> .rel.dyn, whereas newer ld uses names of the form .rel*. The
> linker script only collected .rel.dyn input sections. Rewrite
> to collect all .rel* input sections.
> 
> Signed-off-by: Albert Aribaud 
> ---
>  nand_spl/board/karo/tx25/u-boot.lds |   40 --
>  1 files changed, 19 insertions(+), 21 deletions(-)

Applied to u-boot-arm, 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 number you have dialed is imaginary. Please divide by 0  and  try
again.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH V5 1/2] ARM: fix linker file for newer ld support

[Wolfgang Denk]

Dear Albert Aribaud,

In message <1289853964-6525-1-git-send-email-albert.arib...@free.fr> you wrote:
> older ld emitted all ELF relocations in input sections named
> .rel.dyn, whereas newer ld uses names of the form .rel*. The
> linker script only collected .rel.dyn input sections. Rewrite
> to collect all .rel* input sections.
> 
> Signed-off-by: Albert Aribaud 
> ---
> V1Initial submission
> V2arm926ejs: added ALIGN between bss and .rel.dyn sections
>   tx25: removed GOT and datarel output sections
>   tx25: fixed typo in config file commit message
> V3arm926ejs: overlaid .bss and .rel.dyn sections
>   tx25: overlaid .bss and .rel.dyn sections
> V4arm926ejs and tx25: fixed overlay
>   tx25: removed third patch as u-boot size remains small enough
> V5added u-boot.lds/start.S fix for arm1136, arm1176, pxa, armv7.
> 
>  arch/arm/cpu/arm1136/start.S  |   16 -
>  arch/arm/cpu/arm1136/u-boot.lds   |   38 --
>  arch/arm/cpu/arm1176/u-boot.lds   |   37 ++---
>  arch/arm/cpu/arm926ejs/u-boot.lds |   30 ++-
>  arch/arm/cpu/armv7/start.S|   24 ---
>  arch/arm/cpu/armv7/u-boot.lds |   46 
> -
>  arch/arm/cpu/pxa/u-boot.lds   |   35 +++-
>  7 files changed, 105 insertions(+), 121 deletions(-)

Applied to u-boot-arm, 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 very few personal problems that cannot be solved through  a
suitable application of high explosives.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

[U-Boot] [PATCH] [v3] powerpc/85xx: introduce 'fdt verify' command

[Timur Tabi]

Introduce the 'fdt verify' command, which verifies some of the physical
addresses in the device tree.

U-Boot uses macros to determine where devices should be located in physical
memory, and Linux uses the device tree to determine where the devices are
actually located.  However, U-Boot does not update the device tree with those
addresses when it boots the operating system.  This means that it's possible
to use a device tree with the wrong addresses, and U-Boot won't complain.
This frequently happens when U-Boot is compiled for 32-bit physical addresses,
but the device tree uses 36-bit addresses.

It's not safe or practical to have U-Boot update the addresses in the device
tree, mostly because U-Boot is not aware of all the devices.  We can, however,
spot-check a few common devices to see if the addresses match, and then display
a warning if they do not.

Signed-off-by: Timur Tabi 
---
 arch/powerpc/cpu/mpc85xx/fdt.c |  170 
 common/cmd_fdt.c   |   21 +-
 common/fdt_support.c   |  170 
 include/fdt_support.h  |   28 +++
 4 files changed, 387 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 53e0596..ede33e7 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -393,6 +393,176 @@ static void ft_fixup_qe_snum(void *blob)
 }
 #endif
 
+/*
+ * For some CCSR devices, we only have the virtual address, not the physical
+ * address.  This is because we map CCSR as a whole, so we typically don't need
+ * a macro for the physical address of any device within CCSR.  In this case,
+ * we calculate the physical address of that device using it's the difference
+ * between the virtual address of the device and the virtual address of the
+ * beginning of CCSR.
+ */
+#define CCSR_VIRT_TO_PHYS(x) \
+   (CONFIG_SYS_CCSRBAR_PHYS + ((x) - CONFIG_SYS_CCSRBAR))
+
+#ifdef CONFIG_PCI
+
+/*
+ * Verify the addresses for all of the PCI controllers
+ *
+ * PCI is complicated because there is no correlation between the numbering
+ * of the controllers by U-Boot and the numbering the device tree.  So we need
+ * to search all of the aliases until we find a patch
+ */
+static void fdt_verify_pci_aliases(void *blob)
+{
+   int off;
+
+   for (off = fdt_next_pci_node(blob, -1); off != -FDT_ERR_NOTFOUND;
+off = fdt_next_pci_node(blob, off)) {
+   const u32 *reg;
+   u64 addr;
+
+   reg = fdt_getprop(blob, off, "reg", NULL);
+   if (!reg || !*reg)
+   continue;
+
+   addr = fdt_translate_address(blob, off, reg);
+   if (!addr) {
+   /* We can't determine the base address, so skip it */
+   continue;
+   }
+
+#ifdef CONFIG_SYS_PCI1_MEM_PHYS
+   if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCI1_ADDR)) {
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCI1_MEM_PHYS,
+   CONFIG_SYS_PCI1_MEM_SIZE, 0);
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCI1_IO_PHYS,
+   CONFIG_SYS_PCI1_IO_SIZE, 1);
+   continue;
+   }
+#endif
+#ifdef CONFIG_SYS_PCI2_MEM_PHYS
+   if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCI2_ADDR)) {
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCI2_MEM_PHYS,
+   CONFIG_SYS_PCI2_MEM_SIZE, 0);
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCI2_IO_PHYS,
+   CONFIG_SYS_PCI2_IO_SIZE, 1);
+   continue;
+   }
+#endif
+#ifdef CONFIG_SYS_PCIE1_MEM_PHYS
+   if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCIE1_ADDR)) {
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCIE1_MEM_PHYS,
+   CONFIG_SYS_PCIE1_MEM_SIZE, 0);
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCIE1_IO_PHYS,
+   CONFIG_SYS_PCIE1_IO_SIZE, 1);
+   continue;
+   }
+#endif
+#ifdef CONFIG_SYS_PCIE2_MEM_PHYS
+   if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCIE2_ADDR)) {
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCIE2_MEM_PHYS,
+   CONFIG_SYS_PCIE2_MEM_SIZE, 0);
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCIE2_IO_PHYS,
+   CONFIG_SYS_PCIE2_IO_SIZE, 1);
+   continue;
+   }
+#endif
+#ifdef CONF

Re: [U-Boot] [PATCH] mpc83xx: Make it boot again

[Scott Wood]

On Wed, 17 Nov 2010 20:15:01 +0100
Joakim Tjernlund  wrote:

> Scott Wood  wrote on 2010/11/17 20:03:25:
> > The "load, conditional branch, isync" sequence is documented in the
> > architecture manual (1.7.1), "even if the effects of the 'dependency'
> > are independent of the value loaded".
> 
> So it doesn't matter what address you do twi on?
> Still, it would make a little more sense if
> it read twi 0,r3,0

It's not an address, it's data that is being compared with zero.  And it
has to be r4, since that's what you want to create the data dependency
on.

The architecture suggests a similar but slightly longer sequence (but
I don't think the wording rules out using twi), which may make the
intent clearer:

lwz r4, ...
cmpwr4, r4
beq 1f
1: isync

-Scott

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

Re: [U-Boot] [PATCH] mpc83xx: Make it boot again

[Joakim Tjernlund]

Scott Wood  wrote on 2010/11/17 20:03:25:
>
> On Wed, 17 Nov 2010 18:26:02 +0100
> Joakim Tjernlund  wrote:
>
> > Scott Wood  wrote on 2010/11/17 18:05:37:
> > >
> > > On Wed, 17 Nov 2010 17:57:53 +0100
> > > Joakim Tjernlund  wrote:
> > >
> > > > After adding some more stuff in start.S I find that a lwz isn't
> > > > enough. An extra isync fixes this though
> > > >
> > > >  lwz r4, LBLAWAR1(r3)
> > > >  isync
> > > >
> > > > So something is missing but what? I guess isync isn't it either but
> > > > it works for now.
> > >
> > > As I said before, the sequence we follow in the normal I/O accessors is:
> > >
> > > lwz   r4, LBLAWAR1(r3)
> > > twi   0, r4, 0
> > > isync
> >
> > That works too. I do wonder if twi ..,r4,.. is correct though?
> > Even a
> >  lwz r4, LBLAWAR1(r3)
> >  nop
> > works.
>
> Just because you can get away with something doesn't mean that it's
> theoretically sufficient.  We got away with nothing at all until
> recently.

Right, was just saying ..

>
> The "load, conditional branch, isync" sequence is documented in the
> architecture manual (1.7.1), "even if the effects of the 'dependency'
> are independent of the value loaded".

So it doesn't matter what address you do twi on?
Still, it would make a little more sense if
it read twi 0,r3,0

   Jocke

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

Re: [U-Boot] [PATCH] mpc83xx: Make it boot again

[Scott Wood]

On Wed, 17 Nov 2010 18:26:02 +0100
Joakim Tjernlund  wrote:

> Scott Wood  wrote on 2010/11/17 18:05:37:
> >
> > On Wed, 17 Nov 2010 17:57:53 +0100
> > Joakim Tjernlund  wrote:
> >
> > > After adding some more stuff in start.S I find that a lwz isn't
> > > enough. An extra isync fixes this though
> > >
> > >  lwz r4, LBLAWAR1(r3)
> > >  isync
> > >
> > > So something is missing but what? I guess isync isn't it either but
> > > it works for now.
> >
> > As I said before, the sequence we follow in the normal I/O accessors is:
> >
> > lwz   r4, LBLAWAR1(r3)
> > twi   0, r4, 0
> > isync
> 
> That works too. I do wonder if twi ..,r4,.. is correct though?
> Even a
>  lwz r4, LBLAWAR1(r3)
>  nop
> works.

Just because you can get away with something doesn't mean that it's
theoretically sufficient.  We got away with nothing at all until
recently.

The "load, conditional branch, isync" sequence is documented in the
architecture manual (1.7.1), "even if the effects of the 'dependency'
are independent of the value loaded".

-Scott

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

Re: [U-Boot] [PATCH] [v2] powerpc/85xx: introduce 'fdt verify' command

[Timur Tabi]

Wolfgang Denk wrote:
>> >  struct fdt_header *working_fdt;
>> > @@ -436,6 +450,10 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc, 
>> > char * const argv[])
>> >else if (strncmp(argv[1], "re", 2) == 0) {
>> >fdt_resize(working_fdt);
>> >}
>> > +  /* verify the addresses in the fdt */
>> > +  else if (argv[1][0] == 'v') {
>> > +  fdt_verify_addresses(working_fdt);
>> > +  }
>> >else {
> 2x incorrect coding style - the "else" goes on the saame line with the
> '}' and the '{'
> 

Ah, the bottom half of the switch statement uses this style:

}
else if


But the top half uses this style:

} else if

And the top half is correct.

-- 
Timur Tabi
Linux kernel developer at Freescale

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

Re: [U-Boot] fw_setenv broken?

[Wolfgang Denk]

Dear Mike Frysinger,

In message <201011171313.27696.vap...@gentoo.org> you wrote:
>
> > Indeed this behaviour is normal. fw_printenv does not sort the output
> > (not yet - patches welcome).
> 
> why bloat the code ?  why cant people simply: `fw_printenv | sort` ?

Well, you are of course right, but some people expect consistent
behaviour. And in U-Boot "printenv" will sort the output.

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
Certainly there are things in life that money  can't  buy,  but  it's
very funny - Did you ever try buying them without money? - Ogden Nash
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] [v2] powerpc/85xx: introduce 'fdt verify' command

[Wolfgang Denk]

Dear Timur Tabi,

In message <1290015805-18791-1-git-send-email-ti...@freescale.com> you wrote:
> Introduce the 'fdt verify' command, which verifies some of the physical
> addresses in the device tree.

> + addr = fdt_translate_address(blob, off, reg);
> + if (!addr)
> + /* We can't determine the base address, so skip it */
> + continue;

Braces needed for multiline statements.

> +/*
> + * Verify the device addresses in the device tree
> + *
> + * This function compares several CONFIG_xxx macros that contain physical
> + * addresses with the corresponding nodes in the device tree, to see if the
> + * physical addresses are all correct.  For example, if 
> CONFIG_SYS_NS16550_COM1
> + * is defined, then it contains the virtual address of the first UART.  We
> + * convert this to a physical address and compare that with the physical
> + * address of the first ns16550-compatible node in the device tree.  If they
> + * don't match, then we display a warning.
> + */

LIne toolong. Please check and fix globally.

> + if (ccsr != CONFIG_SYS_CCSRBAR_PHYS)
> + printf("Warning: U-Boot configured CCSR at address %llx, " \
> +"but the device tree has it at %llx\n",
> +(uint64_t) CONFIG_SYS_CCSRBAR_PHYS, ccsr);

Braces needed for multiline statements. Please fix globally.

No backslash needed at end of line, please remove.

>  struct fdt_header *working_fdt;
> @@ -436,6 +450,10 @@ int do_fdt (cmd_tbl_t * cmdtp, int flag, int argc, char 
> * const argv[])
>   else if (strncmp(argv[1], "re", 2) == 0) {
>   fdt_resize(working_fdt);
>   }
> + /* verify the addresses in the fdt */
> + else if (argv[1][0] == 'v') {
> + fdt_verify_addresses(working_fdt);
> + }
>   else {

2x incorrect coding style - the "else" goes on the saame line with the
'}' and the '{'

> + if (addr != dt_addr)
> + printf("Warning: U-Boot configured device %s at address %llx,\n"
> +"but the device tree has it address %llx.\n",
> +alias, (u64)addr, dt_addr);

Braces needed.

> + if (parent_address_cells == 1)
> + dt_addr = be32_to_cpup(ranges + address_cells);
> + else
> + /* parent_address_cells == 2 */
> + dt_addr = be64_to_cpup(ranges + address_cells);

and again.

> + if (size_cells == 1)
> + dt_size = be32_to_cpup(ranges + address_cells +
> +parent_address_cells);

and again.

> + else
> + /* size_cells == 2 */
> + dt_size = be64_to_cpup(ranges + address_cells +
> +   parent_address_cells);

and again. etc. etc.

> +
> + /*
> +  * Check for matches.  If the address matches but is the wrong
> +  * type or wrong size, then return an error.
> +  */
> + if ((attr & PCI_CELL0_SS_MASK) == PCI_CELL0_SS_IO) {
> + if (is_io && (dt_addr == addr)) {
> + if (dt_size == size)
> + return;
> + else
> + goto wrong_size;
> + }
> + if (!is_io && (dt_addr == addr))
> + goto wrong_type;
> + } else {
> + if (!is_io && (dt_addr == addr)) {
> + if (dt_size == size)
> + return;
> + else
> + goto wrong_size;
> + }
> + if (is_io && (dt_addr == addr))
> + goto wrong_type;
> + }

Factor out the "(dt_addr == addr)" from all 4 "if"s.

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
Human beings were created by water to transport it uphill.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Mike Frysinger]

On Wednesday, November 17, 2010 12:39:33 Wolfgang Denk wrote:
> Stefano Babic wrote:
> > On 11/17/2010 05:30 PM, Steve Sakoman wrote:
> > > I'm seeing some strange behavior with the fw_setenv tools on OMAP.
> > > 
> > > Here's what I see when using the tools on OMAP (overo in this case):
> > > 
> > > 1. fw_printenv prints the environment with no issues [1]
> > > 2. fw_setenv allows me to change a variable with no reported errors [2]
> > > 3. fw_printenv will print the changed environment, however the
> > > variables are not sorted [3]
> > 
> > I tested yesterday on a davinci board, I can confirm this behavior, I
> > have not thought was an error. I do not see any code in fw_env.c to sort
> > variables. I konow the variables are sorted in u-boot, but do we ever
> > have this feature on the userland fw_printenv ?
> 
> Indeed this behaviour is normal. fw_printenv does not sort the output
> (not yet - patches welcome).

why bloat the code ?  why cant people simply: `fw_printenv | sort` ?
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] request for ubifs recovery support

[Albert ARIBAUD]

Le 17/11/2010 19:01, Quotient Remainder a écrit :
> Ar Céad, 2010-11-17 ag 17:25 +0100, scríobh Albert ARIBAUD:
>
>> Do you mean that, in Linux, you do a power cycle without (syncing and)
>> unmounting a file system that will be critical to properly booting later
>> on? If so, what is the rationale behind this too-quick power cycle?
>
> Yes, I'm testing power-fail tolerance!  The RFS is mounted in sync mode
> so unless I'm missing something the sync should have occurred before the
> command prompt reappears, right?
>
>>
>> Seems to me you should start by the preventive measure of avoiding the
>> corruption in the first place (do a cp; sync; umount...) rather than
>> relying on a curative measure of recovery attempts.
>
> Ideally, yes and "sync" before power-down works but that's not what
> these tests are checking.  With the RFS not in sync mode, it works;
> "sync" command with sync mount currently untested.


Ok, now I understand why you do this cp-then-powercycle routine.

Granted, cp on a sync mount should have finished when you get back to 
the prompt, so that's one Linux, not U-boot, issue to dig into; but 
anyway, if you're testing for powerfail conditions, I guess you also 
test power-cycling in the middle of the cp, so you may end up with a 
corrupted ubifs anyway.

I guess if you or Eric know how to enable ubifs recovery in u-boot, the 
simplest course of action is to just go ahead and try it -- but I still 
think the cp+powercycle issue is caused purely in Linux and should be 
fixed there.

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

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Mike Frysinger]

On Wednesday, November 17, 2010 08:30:56 Sebastien Carlier wrote:
> On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> > I notice that the patch affects the size of the resulting U-Boot
> > images.
> 
> The size increase you noted seems to completely go away when adding
> --gc-sections to LDFLAGS, but this option apparently brings its own
> issues when the linker discards important unreferenced bits:
> 
> http://www.mail-archive.com/u-boot@lists.denx.de/msg41762.html
> http://www.mail-archive.com/u-boot@lists.denx.de/msg42063.html
> 
> These problems can be fixed within linker scripts, but I think it might
> be safer to use --gc-sections for diagnostic purposes only...

it's really not that hard to fix things to work with --gc-sections (ive been 
using it on Blackfin for literally years at this point).  people really should 
be driving to have that supported everywhere.
-mike


signature.asc
Description: This is a digitally signed message part.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] request for ubifs recovery support

[Quotient Remainder]

Ar Céad, 2010-11-17 ag 17:25 +0100, scríobh Albert ARIBAUD:

> Do you mean that, in Linux, you do a power cycle without (syncing and) 
> unmounting a file system that will be critical to properly booting later 
> on? If so, what is the rationale behind this too-quick power cycle?

Yes, I'm testing power-fail tolerance!  The RFS is mounted in sync mode
so unless I'm missing something the sync should have occurred before the
command prompt reappears, right?

> 
> Seems to me you should start by the preventive measure of avoiding the 
> corruption in the first place (do a cp; sync; umount...) rather than 
> relying on a curative measure of recovery attempts.

Ideally, yes and "sync" before power-down works but that's not what
these tests are checking.  With the RFS not in sync mode, it works;
"sync" command with sync mount currently untested.


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

Re: [U-Boot] fw_setenv broken?

[Steve Sakoman]

On Wed, 2010-11-17 at 18:39 +0100, Wolfgang Denk wrote:
> Dear Stefano Babic,
> 
> In message <4ce4092b.7090...@denx.de> you wrote:
> > On 11/17/2010 05:30 PM, Steve Sakoman wrote:
> > > I'm seeing some strange behavior with the fw_setenv tools on OMAP.
> > > 
> > > Here's what I see when using the tools on OMAP (overo in this case):
> > > 
> > > 1. fw_printenv prints the environment with no issues [1]
> > > 2. fw_setenv allows me to change a variable with no reported errors [2]
> > > 3. fw_printenv will print the changed environment, however the variables
> > > are not sorted [3]
> > 
> > I tested yesterday on a davinci board, I can confirm this behavior, I
> > have not thought was an error. I do not see any code in fw_env.c to sort
> > variables. I konow the variables are sorted in u-boot, but do we ever
> > have this feature on the userland fw_printenv ?
> 
> Indeed this behaviour is normal. fw_printenv does not sort the output
> (not yet - patches welcome).
> 
> > > I added debug printf's to readenv() in env_nand.c and the root cause is
> > > an error return from ret=nand_read(&nand_info[0], offset, &len,
> > > char_ptr)).  I get an error code of -74
> > > 
> > > Before I spend too much time on this I wanted to check to see if others
> > > are seeing this issue, or whether it might be OMAP specific.
> > 
> > At least this should not be a general failure, because it works on my
> > target. It could be also nand specific.
> 
> Thanks for confirming this.
> 
> Well, the next step should be a review of the code, where error -74
> gets set and what that probably means...

Well, since -74 is EBADMSG, I suspect the error occurs at the following
code in nand_do_read_ops() in nand-base.c:

if (mtd->ecc_stats.failed - stats.failed)
return -EBADMSG;

I'm not real familiar with the nand driver code, so I'll add some debug
printfs and see if I can determine why this is happening.

Steve


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

[U-Boot] [PATCH] [v2] powerpc/85xx: introduce 'fdt verify' command

[Timur Tabi]

Introduce the 'fdt verify' command, which verifies some of the physical
addresses in the device tree.

U-Boot uses macros to determine where devices should be located in physical
memory, and Linux uses the device tree to determine where the devices are
actually located.  However, U-Boot does not update the device tree with those
addresses when it boots the operating system.  This means that it's possible
to use a device tree with the wrong addresses, and U-Boot won't complain.
This frequently happens when U-Boot is compiled for 32-bit physical addresses,
but the device tree uses 36-bit addresses.

It's not safe or practical to have U-Boot update the addresses in the device
tree, mostly because U-Boot is not aware of all the devices.  We can, however,
spot-check a few common devices to see if the addresses match, and then display
a warning if they do not.

Signed-off-by: Timur Tabi 
---
 arch/powerpc/cpu/mpc85xx/fdt.c |  168 
 common/cmd_fdt.c   |   19 +
 common/fdt_support.c   |  165 +++
 include/fdt_support.h  |   28 +++
 4 files changed, 380 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/cpu/mpc85xx/fdt.c b/arch/powerpc/cpu/mpc85xx/fdt.c
index 53e0596..91ffbc3 100644
--- a/arch/powerpc/cpu/mpc85xx/fdt.c
+++ b/arch/powerpc/cpu/mpc85xx/fdt.c
@@ -393,6 +393,174 @@ static void ft_fixup_qe_snum(void *blob)
 }
 #endif
 
+/*
+ * For some CCSR devices, we only have the virtual address, not the physical
+ * address.  This is because we map CCSR as a whole, so we typically don't need
+ * a macro for the physical address of any device within CCSR.  In this case,
+ * we calculate the physical address of that device using it's the difference
+ * between the virtual address of the device and the virtual address of the
+ * beginning of CCSR.
+ */
+#define CCSR_VIRT_TO_PHYS(x) \
+   (CONFIG_SYS_CCSRBAR_PHYS + ((x) - CONFIG_SYS_CCSRBAR))
+
+#ifdef CONFIG_PCI
+
+/*
+ * Verify the addresses for all of the PCI controllers
+ *
+ * PCI is complicated because there is no correlation between the numbering
+ * of the controllers by U-Boot and the numbering the device tree.  So we need
+ * to search all of the aliases until we find a patch
+ */
+static void fdt_verify_pci_aliases(void *blob)
+{
+   int off;
+
+   for (off = fdt_next_pci_node(blob, -1); off != -FDT_ERR_NOTFOUND;
+off = fdt_next_pci_node(blob, off)) {
+   const u32 *reg;
+   u64 addr;
+
+   reg = fdt_getprop(blob, off, "reg", NULL);
+   if (!reg || !*reg)
+   continue;
+
+   addr = fdt_translate_address(blob, off, reg);
+   if (!addr)
+   /* We can't determine the base address, so skip it */
+   continue;
+
+#ifdef CONFIG_SYS_PCI1_MEM_PHYS
+   if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCI1_ADDR)) {
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCI1_MEM_PHYS,
+   CONFIG_SYS_PCI1_MEM_SIZE, 0);
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCI1_IO_PHYS,
+   CONFIG_SYS_PCI1_IO_SIZE, 1);
+   continue;
+   }
+#endif
+#ifdef CONFIG_SYS_PCI2_MEM_PHYS
+   if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCI2_ADDR)) {
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCI2_MEM_PHYS,
+   CONFIG_SYS_PCI2_MEM_SIZE, 0);
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCI2_IO_PHYS,
+   CONFIG_SYS_PCI2_IO_SIZE, 1);
+   continue;
+   }
+#endif
+#ifdef CONFIG_SYS_PCIE1_MEM_PHYS
+   if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCIE1_ADDR)) {
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCIE1_MEM_PHYS,
+   CONFIG_SYS_PCIE1_MEM_SIZE, 0);
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCIE1_IO_PHYS,
+   CONFIG_SYS_PCIE1_IO_SIZE, 1);
+   continue;
+   }
+#endif
+#ifdef CONFIG_SYS_PCIE2_MEM_PHYS
+   if (addr == CCSR_VIRT_TO_PHYS(CONFIG_SYS_PCIE2_ADDR)) {
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCIE2_MEM_PHYS,
+   CONFIG_SYS_PCIE2_MEM_SIZE, 0);
+   fdt_check_pci_addresses(blob, off,
+   CONFIG_SYS_PCIE2_IO_PHYS,
+   CONFIG_SYS_PCIE2_IO_SIZE, 1);
+   continue;
+   }
+#endif
+#ifdef CONFIG_SYS_PCIE3_MEM_PHYS

Re: [U-Boot] Detecting U-boot in linux kernel startup

[Wolfgang Denk]

Dear Kristoffer Ericson,

In message <20101117170442.ga...@boggieman> you wrote:
> 
> Im in the situation where most of the hp jornada 700-series handhelds
> got a rom containing wince while mine (and shortly alot more) contain uboot.
> So instead of adding alot of #ifdefs inside the kernel, I thought that I could
> do a check at bootup instead. I basicly need some unique id that only the 
> flashrom
> would contain (e.g "u-boot ..blabla).
> 
> So, any good location/string to check to confirm that its infact u-boot on the
> rom and not wince?

Why not just add a unique marker to the kernel's command line when
booting from U-Boot?


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
Leave bigotry in your quarters; there's no room for it on the bridge.
-- Kirk, "Balance of Terror", stardate 1709.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] fw_setenv broken?

[Wolfgang Denk]

Dear Stefano Babic,

In message <4ce4092b.7090...@denx.de> you wrote:
> On 11/17/2010 05:30 PM, Steve Sakoman wrote:
> > I'm seeing some strange behavior with the fw_setenv tools on OMAP.
> > 
> > Here's what I see when using the tools on OMAP (overo in this case):
> > 
> > 1. fw_printenv prints the environment with no issues [1]
> > 2. fw_setenv allows me to change a variable with no reported errors [2]
> > 3. fw_printenv will print the changed environment, however the variables
> > are not sorted [3]
> 
> I tested yesterday on a davinci board, I can confirm this behavior, I
> have not thought was an error. I do not see any code in fw_env.c to sort
> variables. I konow the variables are sorted in u-boot, but do we ever
> have this feature on the userland fw_printenv ?

Indeed this behaviour is normal. fw_printenv does not sort the output
(not yet - patches welcome).

> > I added debug printf's to readenv() in env_nand.c and the root cause is
> > an error return from ret=nand_read(&nand_info[0], offset, &len,
> > char_ptr)).  I get an error code of -74
> > 
> > Before I spend too much time on this I wanted to check to see if others
> > are seeing this issue, or whether it might be OMAP specific.
> 
> At least this should not be a general failure, because it works on my
> target. It could be also nand specific.

Thanks for confirming this.

Well, the next step should be a review of the code, where error -74
gets set and what that probably means...

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
No one is fit to be trusted with power. ... No one. ... Any  man  who
has lived at all knows the follies and wickedness he's capabel of ...
And  if  he  does  know it, he knows also that neither he nor any man
ought to be allowed to decide a single human fate.
- C. P. Snow,  The Light and the Dark
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] mpc83xx: Make it boot again

[Joakim Tjernlund]

Scott Wood  wrote on 2010/11/17 18:05:37:
>
> On Wed, 17 Nov 2010 17:57:53 +0100
> Joakim Tjernlund  wrote:
>
> > > From: Liu Dave-R63238 
> > > To: Andre Schwarz 
> > > Cc: Wood Scott-B07421 , ku...@theia.denx.de, Tabi 
> > > Timur-B04825 , Phillips Kim-R1AAHA 
> > > , Gala , U-Boot List 
> > > 
> > > Date: 2010/11/15 17:58
> > > Subject: Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
> > > Sent by: u-boot-boun...@lists.denx.de
> > >
> > > > The experts found an issue within init code and it looks like a proper
> > > > patch will be added to mainline shortly.
> > > > The discussion of the proper fix is right in this thread ...
> > >
> > > It should be timing issue in the SoC, software did not have a proper
> > > process to handle
> > > IMMR registers accessing.
> > >
> > > I agree Kumar on this.
> > > Adding the read back with load is needing for the LAW window changing.
> > > And something like sync/eieio instruction also need to be added between
> > > stw and lwz...
> > > to have a proper order accessing.
> >
> > After adding some more stuff in start.S I find that a lwz isn't
> > enough. An extra isync fixes this though
> >
> >  lwz r4, LBLAWAR1(r3)
> >  isync
> >
> > So something is missing but what? I guess isync isn't it either but
> > it works for now.
>
> As I said before, the sequence we follow in the normal I/O accessors is:
>
> lwz   r4, LBLAWAR1(r3)
> twi   0, r4, 0
> isync

That works too. I do wonder if twi ..,r4,.. is correct though?
Even a
 lwz r4, LBLAWAR1(r3)
 nop
works.
>
> Unless we have a good reason to deviate from that -- or a good reason
> why that sequence is not necessary in general -- I think we should
> use it here as well.

Seems so. My start.S is a mess but the code added when this happened is
unrelated. It just pushes the map_xxx/remap_xxx funs further down.

  Jocke

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

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Kumar Gala]

On Nov 16, 2010, at 10:21 AM, Detlev Zundel wrote:

> Hi Shaohui Xie,
> 
> [...]
> 
>> Can you not provide a plain and simple AUTOMATIC way to get this
>> result? some plain stupid command line tool? Something that works as
>> a simple "make XXX" ?  So it can be scripted / automatized / used?
> 
> Maybe have a look at "tools/kwbimage.c".  This is a tool for kirkwood
> chips to build "wrapped images".
> 
> I'm not into this tool, but it sounds like it tries to solve a similar
> problem, so maybe you can leverage what's already there?

How does kwbimage.c work?  Does it just wrap the image generated by mkimage 
differently?  Can it take any additional input files?

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

Re: [U-Boot] [PATCH] mpc83xx: Make it boot again

[Scott Wood]

On Wed, 17 Nov 2010 17:57:53 +0100
Joakim Tjernlund  wrote:

> > From: Liu Dave-R63238 
> > To: Andre Schwarz 
> > Cc: Wood Scott-B07421 , ku...@theia.denx.de, Tabi 
> > Timur-B04825 , Phillips Kim-R1AAHA 
> > , Gala , U-Boot List 
> > 
> > Date: 2010/11/15 17:58
> > Subject: Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
> > Sent by: u-boot-boun...@lists.denx.de
> >
> > > The experts found an issue within init code and it looks like a proper
> > > patch will be added to mainline shortly.
> > > The discussion of the proper fix is right in this thread ...
> >
> > It should be timing issue in the SoC, software did not have a proper
> > process to handle
> > IMMR registers accessing.
> >
> > I agree Kumar on this.
> > Adding the read back with load is needing for the LAW window changing.
> > And something like sync/eieio instruction also need to be added between
> > stw and lwz...
> > to have a proper order accessing.
> 
> After adding some more stuff in start.S I find that a lwz isn't
> enough. An extra isync fixes this though
> 
>  lwz r4, LBLAWAR1(r3)
>  isync
> 
> So something is missing but what? I guess isync isn't it either but
> it works for now.

As I said before, the sequence we follow in the normal I/O accessors is:

lwz r4, LBLAWAR1(r3)
twi 0, r4, 0
isync

Unless we have a good reason to deviate from that -- or a good reason
why that sequence is not necessary in general -- I think we should
use it here as well.

-Scott

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

[U-Boot] Detecting U-boot in linux kernel startup

[Kristoffer Ericson]

Greetings,

Im in the situation where most of the hp jornada 700-series handhelds
got a rom containing wince while mine (and shortly alot more) contain uboot.
So instead of adding alot of #ifdefs inside the kernel, I thought that I could
do a check at bootup instead. I basicly need some unique id that only the 
flashrom
would contain (e.g "u-boot ..blabla).

So, any good location/string to check to confirm that its infact u-boot on the
rom and not wince?

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

Re: [U-Boot] [PATCH] mpc83xx: Make it boot again

[Liu Dave-R63238]

>After adding some more stuff in start.S I find that a lwz isn't
> enough. An extra isync fixes this though
> lwz r4, LBLAWAR1(r3)
>  isync

> So something is missing but what? I guess isync isn't it either but
> it works for now.

Joakim,
Please post more code to the list to have a better understanding your situation.

Thanks,
 Dave


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

Re: [U-Boot] [PATCH] mpc83xx: Make it boot again

[Joakim Tjernlund]

> From: Liu Dave-R63238 
> To: Andre Schwarz 
> Cc: Wood Scott-B07421 , ku...@theia.denx.de, Tabi 
> Timur-B04825 , Phillips Kim-R1AAHA 
> , Gala , U-Boot List 
> 
> Date: 2010/11/15 17:58
> Subject: Re: [U-Boot] [PATCH] mpc83xx: Make it boot again
> Sent by: u-boot-boun...@lists.denx.de
>
> > The experts found an issue within init code and it looks like a proper
> > patch will be added to mainline shortly.
> > The discussion of the proper fix is right in this thread ...
>
> It should be timing issue in the SoC, software did not have a proper
> process to handle
> IMMR registers accessing.
>
> I agree Kumar on this.
> Adding the read back with load is needing for the LAW window changing.
> And something like sync/eieio instruction also need to be added between
> stw and lwz...
> to have a proper order accessing.

After adding some more stuff in start.S I find that a lwz isn't
enough. An extra isync fixes this though

 lwz r4, LBLAWAR1(r3)
 isync

So something is missing but what? I guess isync isn't it either but
it works for now.

 Jocke

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

Re: [U-Boot] fw_setenv broken?

[Stefano Babic]

On 11/17/2010 05:30 PM, Steve Sakoman wrote:
> I'm seeing some strange behavior with the fw_setenv tools on OMAP.
> 
> Here's what I see when using the tools on OMAP (overo in this case):
> 
> 1. fw_printenv prints the environment with no issues [1]
> 2. fw_setenv allows me to change a variable with no reported errors [2]
> 3. fw_printenv will print the changed environment, however the variables
> are not sorted [3]

I tested yesterday on a davinci board, I can confirm this behavior, I
have not thought was an error. I do not see any code in fw_env.c to sort
variables. I konow the variables are sorted in u-boot, but do we ever
have this feature on the userland fw_printenv ?

> 4. Since all seems well at this point, I reboot.  There is an error
> reading the new environment [4]

I cannot confirm that. I made the same test, environment is stored on a
SPI flash. No CRC error, the environment was restored correctly after a
reset and/or power cycle.

> I added debug printf's to readenv() in env_nand.c and the root cause is
> an error return from ret=nand_read(&nand_info[0], offset, &len,
> char_ptr)).  I get an error code of -74
> 
> Before I spend too much time on this I wanted to check to see if others
> are seeing this issue, or whether it might be OMAP specific.

At least this should not be a general failure, because it works on my
target. It could be also nand specific.

Best regards,
Stefano

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

Re: [U-Boot] [PATCH 1/2][NEXT] Davinci 8xx: Move common functions to share code

[Stefano Babic]

On 11/17/2010 05:26 PM, Ben Gardiner wrote:
> Hi Stefano,
> 

Hi Ben,

> I was unable to test this series on top of Sugosh's and my patches
> even after re-basing my patch on top of his by moving the
> da850_emac_mii_mode_sel declaration from
> board/davinci/da8xxevm/common.h to the location from which you have
> removed it above.
> 
> It looked like the removal of this file also needs to move the kick
> register declarations that Sugosh added here.
> 
> I'm guessing you are working from a tree that is very close but not
> quite equal to mainline plus the patches you referenced in the cover
> letter.

Let's see. I am working on TOT of u-boot mainline, and I have applied
Sugosh's and your patch. Last u-boot commit in mainline is:

commit 8ad25bf8d9233eb7d0b614612108622a59069354
Author: Ben Warren 
Date:   Tue Aug 31 23:05:04 2010 -0700

Net: clarify board/cpu_eth_init calls

I have then applied in the order the two SPI flash I have already sent
and you tested, Sugosh's patch and your patch. At the very top there is
my patchset. This is my git log, I drop some part of the commit id to
avoid wrapping:

6a1b17dd5cdaeb4c Davinci: add support for the ea20 board
5195253f20d5bedb Davinci 8xx: Move common functions to share code
8e6ed317d74b3b4d da850: Add RMII support for EMAC
9c1455c63dafc292 Move and rename common headers from under board/davinci.
4ccdfedb55b65f30 da850: Enable SPI Flash
0aacad5f81caac89 da8xx: Add cpu_is_da8xx macros
8ad25bf8d9233eb7 Net: clarify board/cpu_eth_init calls
   ^
   |--- this is actual u-boot TOT

I think it is correct - patches are always sent on the actual u-boot
TOT. However, in this case my patches need that other patches (yours and
Sugosh's) are applied. I have tried to apply patches in the same order I
have seen, but we can have a different order.

> I don't know what is the best way to proceed... I like the current
> state of this patch series. I was unable to apply the three patch
> series (Sugosh's, Yours and mine) in any order without conflicts.

Let's see if something is missing ;-)

Best regards,
Stefano Babic

-- 
=
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] fw_setenv broken?

[Steve Sakoman]

I'm seeing some strange behavior with the fw_setenv tools on OMAP.

Here's what I see when using the tools on OMAP (overo in this case):

1. fw_printenv prints the environment with no issues [1]
2. fw_setenv allows me to change a variable with no reported errors [2]
3. fw_printenv will print the changed environment, however the variables
are not sorted [3]
4. Since all seems well at this point, I reboot.  There is an error
reading the new environment [4]

I added debug printf's to readenv() in env_nand.c and the root cause is
an error return from ret=nand_read(&nand_info[0], offset, &len,
char_ptr)).  I get an error code of -74

Before I spend too much time on this I wanted to check to see if others
are seeing this issue, or whether it might be OMAP specific.

Regards,

Steve


[1] 

r...@omap3-multi:~# fw_printenv 
baudrate=115200
bootcmd=if mmc rescan ${mmcdev}; then if run loadbootscript; then run
bootscript; else if run loaduimage; then run mmcboot; else run nandboot;
fi; fi; else run nandboot; fi
bootdelay=5
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
console=ttyS2,115200n8
defaultdisplay=dvi
dieid#=1e1e000404032d460d01900b
dvimode=1024x768mr...@60
ethact=smc911x-0
loadaddr=0x8200
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage
mmcargs=setenv bootargs console=${console} mpurate=${mpurate} vram=
${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
mmcdev=0
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext3 rootwait
mpurate=500
nandargs=setenv bootargs console=${console} mpurate=${mpurate} vram=
${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr}
28 40; bootm ${loadaddr}
nandroot=/dev/mtdblock4 rw
nandrootfstype=jffs2
stderr=serial
stdin=serial
stdout=serial
vram=12M

[2]

r...@omap3-multi:~# fw_setenv mpurate 720

[3]

r...@omap3-multi:~# fw_printenv 
baudrate=115200
bootcmd=if mmc rescan ${mmcdev}; then if run loadbootscript; then run
bootscript; else if run loaduimage; then run mmcboot; else run nandboot;
fi; fi; else run nandboot; fi
bootdelay=5
bootscript=echo Running bootscript from mmc ...; source ${loadaddr}
console=ttyS2,115200n8
defaultdisplay=dvi
dieid#=1e1e000404032d460d01900b
dvimode=1024x768mr...@60
ethact=smc911x-0
loadaddr=0x8200
loadbootscript=fatload mmc ${mmcdev} ${loadaddr} boot.scr
loaduimage=fatload mmc ${mmcdev} ${loadaddr} uImage
mmcargs=setenv bootargs console=${console} mpurate=${mpurate} vram=
${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} root=${mmcroot} rootfstype=${mmcrootfstype}
mmcboot=echo Booting from mmc ...; run mmcargs; bootm ${loadaddr}
mmcdev=0
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext3 rootwait
nandargs=setenv bootargs console=${console} mpurate=${mpurate} vram=
${vram} omapfb.mode=dvi:${dvimode} omapfb.debug=y omapdss.def_disp=
${defaultdisplay} root=${nandroot} rootfstype=${nandrootfstype}
nandboot=echo Booting from nand ...; run nandargs; nand read ${loadaddr}
28 40; bootm ${loadaddr}
nandroot=/dev/mtdblock4 rw
nandrootfstype=jffs2
stderr=serial
stdin=serial
stdout=serial
vram=12M
mpurate=720

[4]

U-Boot 2010.12-rc1 (Nov 17 2010 - 08:04:09)

OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 600 mHz
Gumstix Overo board + LPDDR/NAND
I2C:   ready
DRAM:  256 MiB
NAND:  256 MiB
MMC:   OMAP SD/MMC: 0
*** Warning - readenv() failed, using default environment



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

Re: [U-Boot] [PATCH 1/2][NEXT] Davinci 8xx: Move common functions to share code

[Ben Gardiner]

Hi Stefano,

On Wed, Nov 17, 2010 at 5:09 AM, Stefano Babic  wrote:
> [...]
> diff --git a/arch/arm/include/asm/arch-davinci/da8xx_common.h 
> b/arch/arm/include/asm/arch-davinci/da8xx_common.h
> deleted file mode 100644
> index 8b564f7..000
> --- a/arch/arm/include/asm/arch-davinci/da8xx_common.h
> +++ /dev/null
> @@ -1,33 +0,0 @@
> -/*
> - * Copyright (C) 2010 Texas Instruments Incorporated - http://www.ti.com/
> - *
> - * 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., 675 Mass Ave, Cambridge, MA 02139, USA.
> - */
> -
> -#ifndef __COMMON_H
> -#define __COMMON_H
> -
> -struct lpsc_resource {
> -       const int       lpsc_no;
> -};
> -
> -void irq_init(void);
> -int da8xx_configure_lpsc_items(const struct lpsc_resource *item,
> -                                   int n_items);
> -#if defined(CONFIG_DRIVER_TI_EMAC) && defined(CONFIG_MACH_DAVINCI_DA850_EVM)
> -void da850_emac_mii_mode_sel(int mode_sel);
> -#endif

I was unable to test this series on top of Sugosh's and my patches
even after re-basing my patch on top of his by moving the
da850_emac_mii_mode_sel declaration from
board/davinci/da8xxevm/common.h to the location from which you have
removed it above.

It looked like the removal of this file also needs to move the kick
register declarations that Sugosh added here.

I'm guessing you are working from a tree that is very close but not
quite equal to mainline plus the patches you referenced in the cover
letter.

I don't know what is the best way to proceed... I like the current
state of this patch series. I was unable to apply the three patch
series (Sugosh's, Yours and mine) in any order without conflicts.

Best Regards,
Ben Gardiner

---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] request for ubifs recovery support

[Albert ARIBAUD]

Le 17/11/2010 17:01, Quotient Remainder a écrit :
> Ar Aoine, 2010-09-17 ag 12:44 -0400, scríobh Eric Cooper:
>> But I just discovered that it has a fatal disadvantage.  My device
>> can't reboot when the ubifs is corrupted, which happened today after a
>> power failure:
>>
>>  UBIFS: recovery needed
>>  Error reading superblock on volume 'ubi:root'!
>>
>> Ubifs includes recovery code, but since u-boot treats it as a
>> read-only mount, this is never performed.  Once I booted Linux,
>> everything was fine.
>>
>> I'd like to request that the read-only flag be removed (at least to
>> allow recovery) so that the ubifs-only scheme can be used reliably.
>>
>
> Has this received any attention or is there an existing way to recover
> from these types of error?
>
> In devices I'm using, the problem is most apparent when the UBIFS RFS is
> mounted with "rootflags=sync" and a large file is copied into that RFS
> in Linux.  When the unit's power is cycled immediately on the "cp"
> command returning, the ubifsload command in U-Boot fails with the same
> error as mentioned by Eric Cooper above.

I don't know ubifs very well to say the least, but something strikes me 
in what you describe: ''the unit's power is cycled immediately on the 
"cp" command returning''.

Do you mean that, in Linux, you do a power cycle without (syncing and) 
unmounting a file system that will be critical to properly booting later 
on? If so, what is the rationale behind this too-quick power cycle?

Seems to me you should start by the preventive measure of avoiding the 
corruption in the first place (do a cp; sync; umount...) rather than 
relying on a curative measure of recovery attempts.

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

Re: [U-Boot] request for ubifs recovery support

[Quotient Remainder]

Ar Aoine, 2010-09-17 ag 12:44 -0400, scríobh Eric Cooper:
> But I just discovered that it has a fatal disadvantage.  My device
> can't reboot when the ubifs is corrupted, which happened today after a
> power failure:
> 
> UBIFS: recovery needed
> Error reading superblock on volume 'ubi:root'!
> 
> Ubifs includes recovery code, but since u-boot treats it as a
> read-only mount, this is never performed.  Once I booted Linux,
> everything was fine.
> 
> I'd like to request that the read-only flag be removed (at least to
> allow recovery) so that the ubifs-only scheme can be used reliably.
> 

Has this received any attention or is there an existing way to recover
from these types of error?

In devices I'm using, the problem is most apparent when the UBIFS RFS is
mounted with "rootflags=sync" and a large file is copied into that RFS
in Linux.  When the unit's power is cycled immediately on the "cp"
command returning, the ubifsload command in U-Boot fails with the same
error as mentioned by Eric Cooper above.


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

Re: [U-Boot] [PATCH v3 1/1] imx: Get fec mac address from fuse

[Wolfgang Denk]

Dear Jason Liu,

In message <1290002970-8002-1-git-send-email-r64...@freescale.com> you wrote:
> The patch is to support getting FEC MAC address from fuse bank.
> 
> Signed-off-by: Jason Liu 
...
> --- a/arch/arm/cpu/arm926ejs/mx27/generic.c
> +++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
> @@ -313,6 +313,16 @@ void mx27_fec_init_pins(void)
>   for (i = 0; i < ARRAY_SIZE(mode); i++)
>   imx_gpio_mode(mode[i]);
>  }
> +
> +void imx_get_mac_from_fuse(unsigned char *mac)
> +{
> + int i;
> + struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
> + struct fuse_bank0 *fuse = (struct fuse_bank0 *)&iim->bank[0];

I think this is wrong. You don't want the address of the bank, but of
the "fuse_regs" element.

> +for (i = 0; i < 6; i++)
> + mac[6-1-i] = readl(&fuse->mac_addr[i]);

Please use TABs for indentation.

> +#if defined(CONFIG_FEC_MXC)
> +void imx_get_mac_from_fuse(unsigned char *mac)
> +{
> + int i;
> + struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
> + struct fuse_bank1 *fuse = (struct fuse_bank1 *)&iim->bank[1];

Again, this shouldbe "fuse_regs".

> +for (i = 0; i < 6; i++)
> +mac[i] = readl(&fuse->mac_addr[i]);

Ditto.

> + struct {
> + u32 fuse_regs[0x20];
> + u32 fuse_rsvd[0xe0];
> + } bank[3];
>  };
> +
> +struct fuse_bank0 {
> + u32 fuse1_26[0x1a];
> + u32 mac_addr[6];
> +};

This is misleading. "fuse_bank0" does not descibe the whole bank0, but
only the "fuse_regs" part of it, so you better rename this into
"fuse_bank0_regs" or similar.

"fuse1_26" is a strange name. I think I understand what you mean, but
then it should probably be "fuse0_25" ?  or "fuse0_0x19"? 
Or "unused" or "reserved" or ... ?

> +struct fuse_bank0 {
> + u32 fuse1_4[4];
> + u32 mac_addr[6];
> + u32 word11_32[0x16];
>  };

Please use consistent names. "word..." does not fit here at all.

Again, think the names fuse1_4 and fuse11_32 are probaly misleading
(0 - 3 and 10 - 31).

And also, I think this should be "fuse_bank0_fuse_regs".

> +struct fuse_bank1 {
> + u32 fuse1_9[9];
> + u32 mac_addr[6];
> + u32 fuse6_32[0x11];
> +};

Same comments again.


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
You have the capacity to learn from  mistakes.  You'll  learn  a  lot
today.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode"

[Peter Tyser]

Hi Zhao,

> In message <1289986984-2314-1-git-send-email-b26...@freescale.com> you wrote:
> > On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse
> > VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS)
> > for SGMII mode cause link problems.
> > 
> > Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it.

Based on my company's discussions with Freescale and Freescale's
appnotes I believe that the current implementation is correct.  I make
reference to some of this in the original patch:
http://old.nabble.com/-U-Boot---PATCH--tsec:-Force-TBI-PHY-to-1000Mbps-full-duplex-in-SGMII-mode-td26188785.html

We use Broadcom PHYs on our boards, which likely has something to do
with the discrepancies between the P2020DS/MPC8572DS vs the
XPedite5370/XPedite5500.  Unless you have additional information that
shows that in-band SGMII auto-negotiation does work per the spec I'd
prefer to keep the current tsec.c code and add
CONFIG_TSEC_TBICR_SETTINGS workarounds to the P2020DS (already done in
commit 90b5bf211b85eee10c34cbeb907ce381142b7c99?) and MPC8572DS.

Best,
Peter

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

[U-Boot] [PATCH] powerpc/85xx: Relocate env_addr if we CONFIG_SYS_RAMBOOT

[Kumar Gala]

We use CONFIG_SYS_RAMBOOT for when boot out of NAND, SPI, SDHC/MMC
and utilize a L2 or L3 cache in SRAM mode.  In this case we will
end up changing the cache from SRAM mode back to cache before we
relocate the environment properly in env_relocate().

So we need to manual relocate the env pointer out of SRAM into DDR.

Signed-off-by: Kumar Gala 
---
 arch/powerpc/lib/board.c |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/lib/board.c b/arch/powerpc/lib/board.c
index 2e0749d..5ce9caa 100644
--- a/arch/powerpc/lib/board.c
+++ b/arch/powerpc/lib/board.c
@@ -645,6 +645,18 @@ void board_init_r (gd_t *id, ulong dest_addr)
gd->cpu += dest_addr - CONFIG_SYS_MONITOR_BASE;
 #endif
 
+#if defined(CONFIG_MPC85xx) && defined(CONFIG_SYS_RAMBOOT)
+   /*
+* We use CONFIG_SYS_RAMBOOT for when boot out of NAND, SPI, SDHC/MMC
+* and utilize a L2 or L3 cache in SRAM mode.  In this case we will
+* end up changing the cache from SRAM mode back to cache before we
+* relocate the environment properly in env_relocate().
+*
+* So we need to manual relocate the env pointer out of SRAM into DDR.
+*/
+   gd->env_addr += dest_addr - CONFIG_SYS_MONITOR_BASE;
+#endif
+
 #ifdef CONFIG_SERIAL_MULTI
serial_initialize();
 #endif
-- 
1.7.2.3

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

[U-Boot] [PATCH v3 1/1] imx: Get fec mac address from fuse

[Jason Liu]

The patch is to support getting FEC MAC address from fuse bank.

Signed-off-by: Jason Liu 

---
Changes for v2:
 - correct the mac address byte order according to review comments
 - add memset(edev, 0. sizeof(*edev)) when do fec_probe,
 - fix some code comments
Changes for v3:
 - rebase
 - address the comments of Stefano, make the imx_get_mac_from_fuse(),
   declared independently inside each imx-regs.h to make it specific
   for each processor, because it accesses to different structures.
 - address the comments of Wolfgang and Stefano, use struct to access
  mac_addr fuse.
---
 arch/arm/cpu/arm926ejs/mx25/generic.c |   10 
 arch/arm/cpu/arm926ejs/mx27/generic.c |   10 
 arch/arm/cpu/armv7/mx5/soc.c  |   12 ++
 arch/arm/include/asm/arch-mx25/imx-regs.h |   19 +--
 arch/arm/include/asm/arch-mx27/imx-regs.h |   18 ++-
 arch/arm/include/asm/arch-mx5/imx-regs.h  |   34 +
 drivers/net/fec_mxc.c |   15 +
 7 files changed, 90 insertions(+), 28 deletions(-)

diff --git a/arch/arm/cpu/arm926ejs/mx25/generic.c 
b/arch/arm/cpu/arm926ejs/mx25/generic.c
index b80a389..fa37a9b 100644
--- a/arch/arm/cpu/arm926ejs/mx25/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx25/generic.c
@@ -260,4 +260,14 @@ void mx25_fec_init_pins (void)
writel (outpadctl, &padctl->pad_fec_tdata1);
 
 }
+
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank0 *fuse = (struct fuse_bank0 *)&iim->bank[0];
+
+   for (i = 0; i < 6; i++)
+   mac[i] = readl(&fuse->mac_addr[i]);
+}
 #endif /* CONFIG_FEC_MXC */
diff --git a/arch/arm/cpu/arm926ejs/mx27/generic.c 
b/arch/arm/cpu/arm926ejs/mx27/generic.c
index ae2ce58..e690337 100644
--- a/arch/arm/cpu/arm926ejs/mx27/generic.c
+++ b/arch/arm/cpu/arm926ejs/mx27/generic.c
@@ -313,6 +313,16 @@ void mx27_fec_init_pins(void)
for (i = 0; i < ARRAY_SIZE(mode); i++)
imx_gpio_mode(mode[i]);
 }
+
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank0 *fuse = (struct fuse_bank0 *)&iim->bank[0];
+
+for (i = 0; i < 6; i++)
+   mac[6-1-i] = readl(&fuse->mac_addr[i]);
+}
 #endif /* CONFIG_FEC_MXC */
 
 #ifdef CONFIG_MXC_MMC
diff --git a/arch/arm/cpu/armv7/mx5/soc.c b/arch/arm/cpu/armv7/mx5/soc.c
index 7c7a565..d156476 100644
--- a/arch/arm/cpu/armv7/mx5/soc.c
+++ b/arch/arm/cpu/armv7/mx5/soc.c
@@ -100,6 +100,18 @@ int cpu_eth_init(bd_t *bis)
return rc;
 }
 
+#if defined(CONFIG_FEC_MXC)
+void imx_get_mac_from_fuse(unsigned char *mac)
+{
+   int i;
+   struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE;
+   struct fuse_bank1 *fuse = (struct fuse_bank1 *)&iim->bank[1];
+
+for (i = 0; i < 6; i++)
+mac[i] = readl(&fuse->mac_addr[i]);
+}
+#endif
+
 /*
  * Initializes on-chip MMC controllers.
  * to override, implement board_mmc_init()
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h 
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index f5a2929..b6f33ac 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -36,6 +36,7 @@
 #ifndef __ASSEMBLY__
 #ifdef CONFIG_FEC_MXC
 extern void mx25_fec_init_pins(void);
+extern void imx_get_mac_from_fuse(unsigned char *mac);
 #endif
 
 /* Clock Control Module (CCM) registers */
@@ -129,12 +130,17 @@ struct iim_regs {
u32 iim_srev;
u32 iim_prog_p;
u32 res1[0x1f5];
-   u32 iim_bank_area0[0x20];
-   u32 res2[0xe0];
-   u32 iim_bank_area1[0x20];
-   u32 res3[0xe0];
-   u32 iim_bank_area2[0x20];
+   struct {
+   u32 fuse_regs[0x20];
+   u32 fuse_rsvd[0xe0];
+   } bank[3];
 };
+
+struct fuse_bank0 {
+   u32 fuse1_26[0x1a];
+   u32 mac_addr[6];
+};
+
 #endif
 
 /* AIPS 1 */
@@ -312,7 +318,4 @@ struct iim_regs {
 #define WSR_UNLOCK10x
 #define WSR_UNLOCK20x
 
-/* FUSE bank offsets */
-#define IIM0_MAC   0x1a
-
 #endif /* _IMX_REGS_H */
diff --git a/arch/arm/include/asm/arch-mx27/imx-regs.h 
b/arch/arm/include/asm/arch-mx27/imx-regs.h
index 6ecddaa..06a06a9 100644
--- a/arch/arm/include/asm/arch-mx27/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx27/imx-regs.h
@@ -34,6 +34,7 @@ extern void mx27_uart_init_pins(void);
 
 #ifdef CONFIG_FEC_MXC
 extern void mx27_fec_init_pins(void);
+extern void imx_get_mac_from_fuse(unsigned char *mac);
 #endif /* CONFIG_FEC_MXC */
 
 #ifdef CONFIG_MXC_MMC
@@ -203,8 +204,18 @@ struct iim_regs {
u32 iim_scs2;
u32 iim_scs3;
u32 res[0x1F0];
-   u32 iim_bank_area0[0x100];
+   struct {
+   u32 fuse_regs[0x20];
+   u32 fuse_rsvd[0xe0];
+   } bank[1];
+};
+
+struct fuse_bank0 {
+   u32 

Re: [U-Boot] [PATCH 0/3] Net Boot Controller

[tristan]

Thank you for your time. As I understand, there are some ways to achieve
almost the same feature using only the preboot command.
I'll take a closer look at it.

Regards

2010/11/17 Wolfgang Denk 

> Dear tristan,
>
> In message 
> >
> you wrote:
> >
> > > Is NBC a standard ? Could you provide a link describing this protocol ?
> >
> > NBC is not a standard, this is just a simple protocol I designed for this
> > purpose
>
> Sorry, but in this case, and considering all the othe rproblems
> pointed out by Stefano, please maintain this code out of tree. We
> will not add this to mainline.
>
> NAK for all three patches.
>
> 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
> No problem is insoluble.
>-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
>



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

Re: [U-Boot] [PATCH 0/3] Net Boot Controller

[Wolfgang Denk]

Dear tristan,

In message  you 
wrote:
>
> > Is NBC a standard ? Could you provide a link describing this protocol ?
> 
> NBC is not a standard, this is just a simple protocol I designed for this
> purpose

Sorry, but in this case, and considering all the othe rproblems
pointed out by Stefano, please maintain this code out of tree. We
will not add this to mainline.

NAK for all three patches.

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
No problem is insoluble.
-- Dr. Janet Wallace, "The Deadly Years", stardate 3479.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Wolfgang Denk]

Dear Sebastien Carlier,

In message <20101117133056.gb23...@safe.home.local> you wrote:
> 
> Unfortunately I have not been able to reproduce these errors with the
> toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
> emdebian squeeze packages).  Can you please point me to the toolchain
> you are using?

I'm using ELDk 4.2 as reference. Please see
ftp://ftp.denx.de/pub/eldk/4.2/ppc-linux-x86/iso/

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The more sins you confess, the more books you will sell.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] the d-cache is not unlocked

[Wolfgang Denk]

Dear Baidu Boy,

In message  you 
wrote:
> 
> For the e300 core, we can see the d-cache is locked as SRAM for the stack in
> start.S file by calling the function  lock_ram_in_cache:
> ---
> arch/powerpc/cpu/mpc83xx/start.S
> #ifdef CONFIG_SYS_INIT_RAM_LOCK
> bl  lock_ram_in_cache
> sync
> #endif
> ---
> But we do not unlock the 4-KB d-cache which we locked in start.S for e300
> ---
> arch/powerpc/lib/board.c
> #if defined(CONFIG_SYS_INIT_RAM_LOCK) && defined(CONFIG_E500)
> unlock_ram_in_cache();  /* it's time to unlock D-cache in e500 */
> #endif
> ---

I don't see a question in your message, so what exactly is the
pourpose of this posting?

If you suggest a change to the code, then please come up with a patch,
test it on your system(s) and submit it to the mailing list. 

For details please see http://www.denx.de/wiki/U-Boot/Patches

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 use of Microsoft crippleware systems is a sin that  carries  with
it its own punishment.
 -- Tom Christiansen in <6bo3fr$pj...@csnews.cs.colorado.edu>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Net Boot Controller

[Stefano Babic]

On 11/17/2010 02:17 PM, tristan wrote:
> Is NBC a standard ? Could you provide a link describing this protocol ?
> 
> 
> NBC is not a standard, this is just a simple protocol I designed for
> this purpose

IMHO we should not add such as protocol to u-boot, considering that
u-boot already implements standard ways (DHCP, BOOTP) to achieve what
you want.
Your solution works only locally and you have to synchronize yourself to
send the broadcast message when you reset the board. DHCP works in anyway.

Michael sent an example how to switch the console to NetConsole. Is it
not suitable for you ? You could add the dhcp command to the preboot
variable if you need to obtain an IP address after a reset.

> I did think about using DHCP for this, but finally decided to use a new
> packet format since the use is very specific and using DHCP 

Not really, Your protocol is a way to set the IP address, after that you
switch the console. Providing network addresses is exactly the DHCP's job.

> All the packets are sent to the broadcast adress, so if two boards are
> waiting at the same time there will be a conflict. 

This is not good...

> The way to use it in my mind is to start broadcasting with sendnbc, and
> then start the board.
> As the sendnbc tool will stop broadcasting right after one target
> answered to the packet by sending back the u-booy prompt, the only case
> that can lead to this problem is if both targets are started exactly at
> the same time.

It not so uncommon to have a lot of boards connected to the same
network. If all of them support your protocol, we get in big trouble.

Best regards,
Stefano Babic

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

Re: [U-Boot] [PATCH 2/3] Add sendnbc tool to broadcast NBC magic packet

[tristan]

Hi Mike,

Thank you for all your correction hints.
I used the Lindent script to check for mistakes, but obviously, this was not
enought, and I will correct all these with care.

Regards

2010/11/17 Mike Frysinger 

> On Tuesday, November 16, 2010 13:04:32 tristan.lel...@blunderer.org wrote:
> > --- /dev/null
> > +++ b/tools/sendnbc.c
> > @@ -0,0 +1,219 @@
> > +#include 
>
> missing licensing & copyright header
>
> > +static void usage (char *argv0)
>
> style problems throughout this file too
>
> > + printf
> > + ("SENDNBC: sends a magic packet to u-boot board to interrupt
> the
> > autoboot\n"); +   printf (" and reconfigure u-boot in
> netconsole
> > mode.\n"); +  printf
> > + (" Use in combination with netconsole to connect and
> > control\n"); +printf ("your u-boot device\n");
> > + printf
> > + ("   Ex: BOARD_IP=192.168.0.2 ./sendnbc -i $BOARD_IP -d eth0 &&
> > ./netconsole $BOARD_IP\n"); + printf ("\nusage: %s [options]\n", argv0);
> > + printf (" -i : the ip addr to assign to u-boot board\n");
> > + printf (" -m : the targeted board mac addr \n");
> > + printf (" -n : the targeted board hostname \n");
> > + printf
> > + (" -d : the net interface to use for broadcasting (ex:
> eth0).
> > Must be root to use this option\n"); +printf (" -h: display this
> > help\n");
>
> multiple calls to printf() is such a waste.  combine all the strings into
> one
> and call printf() just once.
> -mike
>



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

Re: [U-Boot] [RAM MEMORY] Hardware Replacement.

[Wolfgang Denk]

Dear Rodolfo Oliveira,

In message  you 
wrote:
>
> I'm upgrading my hardware RAM, but I found a problem.

Why are you reposting the same question again?

Please read http://catb.org/esr/faqs/smart-questions.html#id445111


> After replacing the RAM MT48LC32M4A2 by IS42S16800E the following message
> appeared:
> "Memory (date line) error at , wrote , read
> 89abcdef89abc def!"
> This error happens in executing the u-boot.
> 
> Does anyone know what problem is this?
> I looked at the two memories and ram it are similar.

Well, similar is not identical, and probably not even similar enough.

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've tried (in vi) "g/[a-z]\n[a-z]/s//_/"...but that doesn't
: cut it.  Any ideas?  (I take it that it may be a two-pass sort of solution).
In the first pass, install perl. :-) Larry Wall <6...@jpl-devvax.jpl.nasa.gov>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v3] Switch from archive libraries to partial linking

[Sebastien Carlier]

Dear Wolfgang,

On 2010-11-15 11:54:07, Wolfgang Denk wrote:
> 
> I notice that the patch affects the size of the resulting U-Boot
> images.

The size increase you noted seems to completely go away when adding
--gc-sections to LDFLAGS, but this option apparently brings its own
issues when the linker discards important unreferenced bits:

http://www.mail-archive.com/u-boot@lists.denx.de/msg41762.html
http://www.mail-archive.com/u-boot@lists.denx.de/msg42063.html

These problems can be fixed within linker scripts, but I think it might
be safer to use --gc-sections for diagnostic purposes only...

> MPC8xx boards break with long lists of multiple definitions of
> symbols, like that:
> 
> Configuring for FPS860L board...
> lib/libgeneric.o: In function `vsprintf':
> /home/wd/git/u-boot/work/lib/vsprintf.c:480: multiple definition of `vsprintf'
> ...
> 
> Have you seen that, too?

Unfortunately I have not been able to reproduce these errors with the
toolchain I am using (gcc 4.4.5 and binutils 2.20.1.20100303, based on
emdebian squeeze packages).  Can you please point me to the toolchain
you are using?

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

Re: [U-Boot] [PATCH 1/3] Add support for Net Boot Controller (NBC) packet

[Wolfgang Denk]

Dear tristan.lel...@blunderer.org,

In message 
<732b4e4395e5c02bb01c1fd7b7f8ce085a208950.1289929762.git.blunde...@blunderer.org>
 you wrote:
> From: Tristan Lelong 
> 
> This adds the core NBC feature:
>  * Integration into u-boot
>  * NBC packet processing
>  * NetConsole reconfigure


Like Stefano I wonder if this is protocol is ion any way standardized?
For example, I cannot find a coresponding RFC for it.

And why is it needed?  DHCP should work fine, doesn't it?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Artificial Intelligence is no match for natural stupidity.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Net Boot Controller

[tristan]

Hi Michael,

2010/11/17 Michael Zaidman 

> Hi Tristan,
>
> On Tue, Nov 16, 2010 at 8:04 PM,  wrote:
> >
> > From: Tristan Lelong 
> >
> > This patch allow to interrupt u-boot autoboot from remote PC and
> auto-reconfigure a netconsole redirected to this remote PC
> >
> > Tristan Lelong (3):
> >  Add support for Net Boot Controller (NBC) packet
> >  Add sendnbc tool to broadcast NBC magic packet
> >  Add the NBC + netconsole corresponding documentation
> >
>
> We usually need netconsole when serial console is not the option. The
> u-boot autorun lasts for few seconds only afterwards the control is
> passed to OS. That means that u-boot will be capable of NBC catching
> during very sort period of time. How the user is supposed to know when
> to issue the NBC packet?
>

You're right, netconsole is there when the serial console is not an option.
The best example for me would be in a training class for embedded linux
(where u-boot is not the subject but only a tool to handle kernels and
rootfs), the need for several serial adapter is a real constrain that can be
avoided.

The sendnbc will broadcast in a loop NBC packets until one board answer by
sending the u-boot prompt. So, the user won't need to be aware of the right
moment to send the packets, he will just start broadcasting and then start
the board.


>
> It is also not clear how proposed feature will coexist with BOOTP?
>
> In order to remotely connect to u-boot via netconsole I use the
> following approach - the u-boot wakes up with serial console and after
> few seconds switches to netconsole if user did not hit any key to stay
> with serial console.
>

here, I choosed to add the "wait on NBC packet" after the "serial console
autoboot abort" feature. This is done to keep the serial console with the
higher priority and give the opportunity to skip nbc feature if a serial
console is available.


>
> The code is very simple and compact.
>
> Add to your board configuration file:
>
> #define CONFIG_NETCONSOLE   1
> #define CONFIG_PREBOOT  "setenv stdout nc;setenv stderr nc;setenv stdin
> nc;"
>
> Override the last_stage_init() in your board .c file:
>
> int last_stage_init(void)
> {
>int i, abort = 0;
>int bootdelay = 2; /* Seconds */
>
>printf("\nHit any key to stay with serial console: %2d ",
> bootdelay);
>
>while ((bootdelay-- > 0) && (!abort)) {
>
>/* delay 100 * 10mS */
>for (i=0; !abort && i<100; ++i) {
>if (tstc()) { /* we got a key press */
>abort  = 1;
>bootdelay = 0; /* no more delay */
>(void)getc(); /* consume input */
>setenv("preboot","echo");
>break;
>}
>udelay(1);
>}
>printf("\b\b\b%2d ", bootdelay);
>}
>putc('\n');
>
>return 0;
> }
>
>
>
> Regards,
> Michael
>

Regards


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

Re: [U-Boot] [RESEND PATCH v4 2/2] TI: DaVinci DA850 EVM: support passing maximum allowed cpu clock rate information to kernel

[Nori, Sekhar]

On Wed, Nov 17, 2010 at 17:02:50, Nori, Sekhar wrote:
> The TI DA850/OMAP-L138/AM18x EVM can be populated with devices
> having different maximum allowed CPU clock rating.
>
> The maximum clock the chip can support can only be determined from
> the label on the package (not software readable).
>
> Introduce a method to pass the maximum allowed clock rate information
> to kernel using ATAG_REVISION. The kernel uses this information to
> determine the maximum cpu clock rate reachable using cpufreq.
>
> Note that U-Boot itself does not set the CPU clock rate. The CPU
> clock is setup by a primary bootloader ("UBL"). The rate setup by
> UBL could be different from the maximum clock rate supported by the
> device.
>
> Signed-off-by: Sekhar Nori 

Ben had sent a Tested-by: earlier which I failed to
include here. Sorry about that. Here it is:

Tested-by: Ben Gardiner 

Thanks,
Sekhar

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

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Wolfgang Denk]

Dear Xie Shaohui-B21989,

In message 
<267a3b246c22c34a8e574051858e0770018...@039-sn1mpn1-003.039d.mgd.msft.net> you 
wrote:
>
> This README describes how to build an Image can be used by PBL (pre-boot
> loader), building u-boot image is the first step, then RCW, PBI
> commands, XXD dump of u-boot.bin, the tool will combine the RCW and PBI
> and XXD dump together to produce the PBL XXD file, suppose the PBL XXD
> file is saved as x.xxd, we need to run "xxd -r x.xxd > pbl_image.bin" to
> produce the final PBL Image. Take a look at the whole process, I see no
> way it can be scripted / automatized.

You cannot reasonably expect of any of your users to go through
such a pain.  This is plain unacceptable.

Please come up with a simple solution that can be integrated into the
U-Boot build procedure.

Things like hex-dumping images and copy & pasting the hexdumps to
some proprietary tool and then going through the same pain again just
backwards may have been acceptable 20 years ago.  Not so any more.

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
We Klingons believe as you do -- the sick should die. Only the strong
should live.
-- Kras, "Friday's Child", stardate 3497.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 0/3] Net Boot Controller

[tristan]

Hi Stefano,

2010/11/17 Stefano Babic 

> On 11/16/2010 07:04 PM, tristan.lel...@blunderer.org wrote:
> > From: Tristan Lelong 
> >
> > This patch allow to interrupt u-boot autoboot from remote PC and
> auto-reconfigure a netconsole redirected to this remote PC
> >
> > Tristan Lelong (3):
> >   Add support for Net Boot Controller (NBC) packet
> >   Add sendnbc tool to broadcast NBC magic packet
> >   Add the NBC + netconsole corresponding documentation
> >
>
> Hi Tristan,
>
> >  common/main.c |5 +
> >  doc/README.netconsole |   66 +++
> >  include/net.h |6 +-
> >  net/Makefile  |2 +
> >  net/nbc.c |  143 
> >  net/nbc.h |   39 +
> >  net/net.c |   17 
> >  tools/Makefile|6 ++
> >  tools/sendnbc.c   |  219
> +
> >  9 files changed, 502 insertions(+), 1 deletions(-)
> >  create mode 100644 doc/README.netconsole
> >  create mode 100644 net/nbc.c
> >  create mode 100644 net/nbc.h
> >  create mode 100644 tools/sendnbc.c
>
> Is NBC a standard ? Could you provide a link describing this protocol ?
>

NBC is not a standard, this is just a simple protocol I designed for this
purpose


>
> I am quite confuse, this seems a way to replace DHCP in a simplest form
> to set up the ip address using some sort of knocking-port. As additional
> feature, the


> Why cannot we reach the same result using the "Vendor Specific
> Information" (or another option field) of DHCP answer ? You can set
> there some infos that the target could understand.
>

I did think about using DHCP for this, but finally decided to use a new
packet format since the use is very specific and using DHCP


>
> It seems to me that the first packet is always sent to the broadcast
> address. What happens if we have two boards on the network, both waiting
> in autoboot ? Do they obtain the same ip address ?
>

All the packets are sent to the broadcast adress, so if two boards are
waiting at the same time there will be a conflict.
The way to use it in my mind is to start broadcasting with sendnbc, and then
start the board.
As the sendnbc tool will stop broadcasting right after one target answered
to the packet by sending back the u-booy prompt, the only case that can lead
to this problem is if both targets are started exactly at the same time.

Indeed there could be some potential improvement on this conflicted
situation.

Regards


>
> Best regards,
> Stefano Babic
>
> --
> =
> 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
> =
>



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

Re: [U-Boot] [PATCH] revert "tsec: Force TBI PHY to 1000Mbps full duplex in SGMII mode"

[Wolfgang Denk]

Dear Zhao Chenhui,

In message <1289986984-2314-1-git-send-email-b26...@freescale.com> you wrote:
> On P2020DS and MPC8572DS, the link to SGMII card which use Vitesse
> VSC8234 PHY can't come up. Current TBI PHY settings(TBICR_SETTINGS)
> for SGMII mode cause link problems.
> 
> Revert commit 46e91674fb4b6d06c6a4984c0b5ac7d9a16923f4, and fix it.

This patch description is wrong, as you do not simply revert that
patch.  Instead, you modify  the code, shifting the setting from a
geric one into a XPEDITE5370 specific one.

When doing so, you should at least put the respective board maintainer
on CC.  I understand your patch was not even tested on the XPEDITE5370
board?


But actually I think your approach is wrong - Peter's solution looks
reasobanle to me.  When your boards with a specific PHY have problems,
then your boards should add appropriate CONFIG_TSEC_TBICR_SETTINGS to
their board config files.


If you insist in changing this code, you might as well clean it up a
bit, like that:


diff --git a/drivers/net/tsec.c b/drivers/net/tsec.c
index 9b5dd92..c205a7e 100644
--- a/drivers/net/tsec.c
+++ b/drivers/net/tsec.c
@@ -292,13 +292,11 @@ static uint tsec_local_mdio_read(volatile tsec_mdio_t 
*phyregs,
 
 /* By default force the TBI PHY into 1000Mbps full duplex when in SGMII mode */
 #ifndef CONFIG_TSEC_TBICR_SETTINGS
-#define TBICR_SETTINGS ( \
+#define CONFIG_TSEC_TBICR_SETTINGS ( \
TBICR_PHY_RESET \
| TBICR_FULL_DUPLEX \
| TBICR_SPEED1_SET \
)
-#else
-#define TBICR_SETTINGS CONFIG_TSEC_TBICR_SETTINGS
 #endif /* CONFIG_TSEC_TBICR_SETTINGS */
 
 /* Configure the TBI for SGMII operation */
@@ -311,7 +309,7 @@ static void tsec_configure_serdes(struct tsec_private *priv)
tsec_local_mdio_write(priv->phyregs_sgmii, priv->regs->tbipa, 
TBI_TBICON,
TBICON_CLK_SELECT);
tsec_local_mdio_write(priv->phyregs_sgmii, priv->regs->tbipa, TBI_CR,
-   TBICR_SETTINGS);
+   CONFIG_TSEC_TBICR_SETTINGS);
 }
 
 /* Discover which PHY is attached to the device, and configure it



Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
An Elephant is a mouse with an Operating System.  - Knuth
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] mx51evk: savenv or env save command does not work

[Stefano Babic]

On 11/17/2010 02:04 PM, Wolfgang Denk wrote:
> Dear Stefano Babic,
> 
> In message <4ce395a0.7060...@denx.de> you wrote:
>> On 11/17/2010 09:01 AM, Jason Liu wrote:
>>> fix saveenv or env save command not work on mx51evk board.
>>> with this patch, we can use savenv or env save to
>>> store enviroments to mmc card slot 0
>>>
>>> Signed-off-by: Jason Liu 
>>>
>>> ---
>>> Changes for v2:
>>>   - Change MMC env size to 8KiB for the consideration for quick boot
>>> ---
>>>  include/configs/mx51evk.h |7 ---
>>>  1 files changed, 4 insertions(+), 3 deletions(-)
>>
>> Applied to u-boot-imx, thanks.
> 
> Arghh... Please allow others at least a few minutes for review.
> Better a few days.

Sorry, it seemed to me there is a general agreement about the point and
8Kib, even if it less as suggested, is suitable in most cases. At least,
this is what I thought, but I was too fast.

I will be not so hurried in future.

Best regards,
Stefano Babic


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

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Stephan Linz]

Am Mittwoch, 17. November 2010, um 13:58:33 schrieb Wolfgang Denk:
> Dear Stephan Linz,
>
> In message <201011170857.24521.l...@li-pro.net> you wrote:
> > Am Freitag, 12. November 2010, um 12:11:42 schrieb Michal Simek:
> > > > - Network:
> > > > --
> > > >
> > > >   Ben Warren has informed me that he has to give up Network
> > > >   custodianship.
> >
> > Hm, I'm sadly to hear about this fact. But so I think the answer to my
> > question is more difficult:
> > http://www.mail-archive.com/u-boot@lists.denx.de/msg42469.html
> >
> > Who maintains the Network in the near future (I mean short time)?
>
> As always when there is nobody else I will try and do what needs to be
> done.
>

Hi Wolfgang,

please note Michal's answer to my post yesterday. He has pushed its work into 
the microplace tree. Thats a good starting point to me. 


-- 
Best regards,
Stephan Linz
__
OpenDCC: http://www.li-pro.net/opendcc.phtml
PC/M: http://www.li-pro.net/pcm.phtml
CDK4AVR: http://cdk4avr.sourceforge.net/
CDK4NIOS: http://cdk4nios.sourceforge.net/
CDK4MSP: http://cdk4msp.sourceforge.net/
CPM4L: http://download.opensuse.org/repositories/home:/rexut:/CPM4L
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] mx51evk: savenv or env save command does not work

[Wolfgang Denk]

Dear Stefano Babic,

In message <4ce395a0.7060...@denx.de> you wrote:
> On 11/17/2010 09:01 AM, Jason Liu wrote:
> > fix saveenv or env save command not work on mx51evk board.
> > with this patch, we can use savenv or env save to
> > store enviroments to mmc card slot 0
> > 
> > Signed-off-by: Jason Liu 
> > 
> > ---
> > Changes for v2:
> >   - Change MMC env size to 8KiB for the consideration for quick boot
> > ---
> >  include/configs/mx51evk.h |7 ---
> >  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> Applied to u-boot-imx, thanks.

Arghh... Please allow others at least a few minutes for review.
Better a few 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
(null cookie; hope that's ok)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH v2 1/1] mx51evk: savenv or env save command does not work

[Wolfgang Denk]

Dear Jason Liu,

In message <1289980878-31714-1-git-send-email-r64...@freescale.com> you wrote:
> fix saveenv or env save command not work on mx51evk board.
> with this patch, we can use savenv or env save to
> store enviroments to mmc card slot 0
> 
> Signed-off-by: Jason Liu 
> 
> ---
> Changes for v2:
>   - Change MMC env size to 8KiB for the consideration for quick boot
> ---
>  include/configs/mx51evk.h |7 ---
>  1 files changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
> index f98438d..b4e5738 100644
> --- a/include/configs/mx51evk.h
> +++ b/include/configs/mx51evk.h
> @@ -216,8 +216,9 @@
>   */
>  #define CONFIG_SYS_NO_FLASH
>  
> -#define CONFIG_ENV_SECT_SIZE(128 * 1024)
> -#define CONFIG_ENV_SIZE  CONFIG_ENV_SECT_SIZE
> -#define CONFIG_ENV_IS_NOWHERE
> +#define CONFIG_ENV_OFFSET  (6 * 64 * 1024)
> +#define CONFIG_ENV_SIZE(8 * 1024)
> +#define CONFIG_ENV_IS_IN_MMC
> +#define CONFIG_SYS_MMC_ENV_DEV 0

The suggested env size was 16 KiB.

And I think you should add a comment where the 6 * 64 * 1024 is coming
from and why exactly this values is considered to be a good 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: w...@denx.de
"Open the pod bay doors, HAL."- Dave Bowman, 2001
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 1/1] mx51evk: savenv or env save command does not work

[Wolfgang Denk]

Dear Jason Liu,

In message  you 
wrote:
>
> OK, I will set it to 8KiB for mx51evk.

You are falling from one extreme into the next one.
Why not using 16 KiB as suggested?

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 may be synthetic, but I'm not stupid"  -  the  artificial  person,
from _Aliens_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [STATUS] Custodian changes, using Patchwork

[Wolfgang Denk]

Dear Stephan Linz,

In message <201011170857.24521.l...@li-pro.net> you wrote:
> Am Freitag, 12. November 2010, um 12:11:42 schrieb Michal Simek:
> > > - Network:
> > > --
> > >
> > >   Ben Warren has informed me that he has to give up Network
> > >   custodianship.
> 
> Hm, I'm sadly to hear about this fact. But so I think the answer to my 
> question is more difficult:
> http://www.mail-archive.com/u-boot@lists.denx.de/msg42469.html
> 
> Who maintains the Network in the near future (I mean short time)?

As always when there is nobody else I will try and do what needs to be
done.

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 they're going to take all this money that we  spend  now  on
war and death --"   "And make them spend it on life."
-- Edith Keeler and Kirk, "The City on the Edge of Forever",
   stardate unknown.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Re: [U-Boot] [PATCH 2/2][v2] Add readme of how to boot from espi flash for p4080ds.

[Detlev Zundel]

Hi Xie,

[...]

>> What is ACS?
>
> Don't know, I don't even have a reference to that in my copy of the RCW
> tool. :-P
>
> [Xie Shaohui] I don't know what is the ACS stands for either, but it is
> a XXD object dump file used by the tool to produce PBI, for example
> after  run "xxd u-boot.bin > u-boot.xxd", the output u-boot.xxd is the
> "XXD object dump file". If you take a look at the tool, you will find a
> selection labeled with "ACS File (XXD object dump)" in tab "PBI".

>From my point of view we simply do not want a U-Boot configuration that
needs to visit an external website to even _compile_ the code.  Let
alone copying stuff to and from, hex dumping it etc.  This is not
acceptable.

>> > +   make P4080DS_PBL_BOOT_INDIRECT_config
>> > +   make CROSS_COMPILE=powerpc-none-linux-gnuspe- all
>> > +   xxd u-boot.bin > u-boot.xxd
>>
>> > +3. Producing PBI commands
>> > +Switch to tab "PBI" and paste commands below into text field
> (please note these
>> > +commands are for CPC1 used as SRAM only, change corresponding
> register setting
>> > +if CPC2 need to be used as SRAM), then choose "ACS File (XXD Object
> Dump)",
>> > +change Offset to "f8", and click "Browse" to select the
> u-boot.xxd file
>> > +produced in step 2, and click "Add PBI Data", after it finished,
> paste
>> > +"09138000 " and "091380c0 " at the end.
>>
>> This must be a bad joke.
>>
>> Can you not provide a plain and simple AUTOMATIC way to get this
>> result? some plain stupid command line tool? Something that works as
>> a simple "make XXX" ?  So it can be scripted / automatized / used?
>
> Yes, a simple C tool to take an existing PBL or RCW dump and "espi-ize"
> it into a PBL dump would be nice.  The user will still need to acquire
> the existing RCW manually.  This only needs to be done once on a board;
> it's not part of building a U-Boot image.

@Scott: What is meant by "acquiring the existing RCW"?  Can't we have a
tool that is fed with a value for RCW?

> [Xie Shaohui] A simple C tool will make things more complex, the
> pbl_image_tool does the same thing and it is irreplaceable, something

No tool is irreplaceable, ever.

> like RCW has to be produced manually, and because there is no
> near-universal default RCW, this README took a basic assumption that
> user already can boot from NOR flash, so user can reuse the RCW dump of
> NOR u-boot with change "PBI_SRC" and "BOOT_LOC" only.
>
> This README describes how to build an Image can be used by PBL (pre-boot
> loader), building u-boot image is the first step, then RCW, PBI
> commands, XXD dump of u-boot.bin, the tool will combine the RCW and PBI
> and XXD dump together to produce the PBL XXD file, suppose the PBL XXD
> file is saved as x.xxd, we need to run "xxd -r x.xxd > pbl_image.bin" to
> produce the final PBL Image. Take a look at the whole process, I see no
> way it can be scripted / automatized.

I said it once before, look at how kwbimage wraps up u-boot.bin into
such an "augmented" image.  If the Marvell guys can do this for their
platform, I see no reason why this cannot be done for your platform.

Cheers
  Detlev

-- 
coding notes: the en/decryption routines each use 6 necessary register
variables,  with  4  being  actively  used at  once  during  the inner
iterations.  if you don't have 4 register variables get a new machine.
   -- Dana L. How (descore-readme.txt)
--
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