Re: [U-Boot] [PATCH 4/6] usb: bugfix driver/usb/host/ehci-hcd.c function ehci_submit_root
-Original Message-
From: Kumar Gala [mailto:ga...@kernel.crashing.org]
Sent: Wednesday, July 08, 2009 7:43 PM
To: Michael Trimarchi
Cc: Prafulla Wadaskar; Remy Bohmer; u-boot@lists.denx.de;
Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit
Subject: Re: [U-Boot] [PATCH 4/6] usb: bugfix
driver/usb/host/ehci-hcd.c function ehci_submit_root
On Jul 8, 2009, at 1:44 AM, Michael Trimarchi wrote:
Prafulla Wadaskar wrote:
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de
] On Behalf Of Remy Bohmer
Sent: Wednesday, July 08, 2009 12:16 AM
To: Michael Trimarchi; Ashish Karkare; Prabhanjan Sarnaik; Ronen
Shitrit
Cc: u-boot@lists.denx.de
Subject: Re: [U-Boot] [PATCH 4/6] usb: bugfix
driver/usb/host/ehci-
hcd.c function ehci_submit_root
Hello All,
2009/7/4 Michael Trimarchi trimar...@gandalf.sssup.it:
Jean-Christophe PLAGNIOL-VILLARD wrote:
On 20:56 Mon 29 Jun , Prafulla Wadaskar wrote:
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
drivers/usb/host/ehci-hcd.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
Remy could you look the marvell usb patch?
I think that this one is correct but not yet tested
Sorry for not being very responsive these days... it is vacation
time... ;-)
This patch of Michael looks good, and I prefer that patch
above the
marvell usb patch.
Patch by me ;-D
If anybody of you are able of testing it, I can apply it.
(I do not
have the proper hardware myself)
Dear Remy
This patch is last dependency to enable Kirkwood Sheevaplug board support.
And I think, nobody else has tested it.
Please kindly apply it before sending pull request for usb.
Regards..
Prafulla . .
Hi Kumar
I have seen a patch by you to this file
Ref: http://lists.denx.de/pipermail/u-boot/2009-July/055652.html
I hope you have h/w and tested ehci-hcd driver :-) Can you pls
comment on this?
FYI: I have tested it for Sheevaplug Kirkwood hardware If
you get a
chance, pls go through my patch, I feel it is logical and
even in the
kernel too. (ref: line 379: linux/drivers/usb/core/
hcd.c)
I wonder why it has not been detected on any other platforms yet!
Any one ...Any comments ??
Because there was an error in the switch :( maybe, that I fix in my
patch, but I can't test now because I don't have any hardware.
- typeReq = req-request 8 | req-requesttype;
+ typeReq = req-request | req-requesttype 8;
- switch (le16_to_cpu(typeReq)) {
+ switch (typeReq) {
I'm quite confused by this.. I was just fixing some warnings
from the fact that we did some read's but never used the
results. If that code has changed (or is going to) than my
patch is not needed. I don't think the patch I posted has
any side effects beyond getting rid of the warnings.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug
Jean, On 14:45 Mon 29 Jun , Dieter Kiermaier wrote: Hi, patch 2 of 2 which adds Kirkwood GPIO support to Sheevaplug. Any comments are welcome! Dieter From 528b24be54256cee20f965bc772390034eaeb232 Mon Sep 17 00:00:00 2001 From: Dieter Kiermaier dk-arm-li...@gmx.de Date: Mon, 29 Jun 2009 14:29:15 +0200 Subject: [PATCH] Sheevaplug: Add Kirkwood gpio support to Sheevaplug Signed-off-by: Dieter Kiermaier dk-arm-li...@gmx.de --- board/Marvell/sheevaplug/sheevaplug.c |1 + include/configs/sheevaplug.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/board/Marvell/sheevaplug/sheevaplug.c b/board/Marvell/sheevaplug/sheevaplug.c index 547126a..fa28fea 100644 --- a/board/Marvell/sheevaplug/sheevaplug.c +++ b/board/Marvell/sheevaplug/sheevaplug.c @@ -26,6 +26,7 @@ #include miiphy.h #include asm/arch/kirkwood.h #include asm/arch/mpp.h +#include asm/arch/gpio.h #include sheevaplug.h DECLARE_GLOBAL_DATA_PTR; diff --git a/include/configs/sheevaplug.h b/include/configs/sheevaplug.h index e62353c..7455c29 100644 --- a/include/configs/sheevaplug.h +++ b/include/configs/sheevaplug.h @@ -43,6 +43,7 @@ #define CONFIG_MD5 /* get_random_hex on krikwood needs MD5 support */ #define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */ #define CONFIG_KIRKWOOD_EGIGA_INIT /* Enable GbePort0/1 for kernel */ +#define CONFIG_KIRKWOOD_GPIO /* Enable GPIO Support */ #define CONFIG_KIRKWOOD_USBPHY_INIT/* Enable USB PHY init for kernel */ #define CONFIG_KIRKWOOD_RGMII_PAD_1V8 /* Set RGMII Pad voltage to 1.8V */ why do you need it?? I fear it is of no need - it seems it is left from some earlier testing :( Should i repost the patch? Thanks, Dieter Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH1/2] Kirkwood: add Marvell Kirkwood gpio driver
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Heiko Schocher Sent: Thursday, July 09, 2009 11:11 AM To: Jean-Christophe PLAGNIOL-VILLARD Cc: Nicolas Pitre; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH1/2] Kirkwood: add Marvell Kirkwood gpio driver Hello Jean-Christophe, Jean-Christophe PLAGNIOL-VILLARD wrote: On 14:45 Mon 29 Jun , Dieter Kiermaier wrote: Hi again, Here is my first out of 2 patches which adds gpio support to arch/kirkwood. Any suggestions? Cheers, Dieter From fcdea0c7bba3c25a1fb183bbcaf6d1a4ec32a157 Mon Sep 17 00:00:00 2001 From: Dieter Kiermaier dk-arm-li...@gmx.de Date: Mon, 29 Jun 2009 14:22:13 +0200 Subject: [PATCH] Kirkwood: add Marvell Kirkwood gpio driver Signed-off-by: Dieter Kiermaier dk-arm-li...@gmx.de looks fine Prafulla nico for you? Okay, Ack, mostly code coming from Linux :-) Regards.. Prafulla . . I actually tested this driver on the suen3 board with the i2c bitbang driver and it works fine :-), so I do a: Tested-by: Heiko Schocher h...@denx.de bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] usb: add Marvell Kirkwood ehci host controller driver
-Original Message- From: l.ping...@gmail.com [mailto:l.ping...@gmail.com] On Behalf Of Remy Bohmer Sent: Thursday, July 09, 2009 1:20 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Prabhanjan Sarnaik; Ronen Shitrit; Ashish Karkare Subject: Re: [PATCH 5/6] usb: add Marvell Kirkwood ehci host controller driver Hi, 2009/7/8 Prafulla Wadaskar prafu...@marvell.com: -Original Message- From: Prafulla Wadaskar [mailto:prafu...@marvell.com] Sent: Monday, June 29, 2009 8:57 PM To: u-boot@lists.denx.de Cc: Prabhanjan Sarnaik; Ronen Shitrit; Ashish Karkare; Prafulla Wadaskar Subject: [PATCH 5/6] usb: add Marvell Kirkwood ehci host controller driver This driver is tested on Sheevaplug platform Dear Remy Sorry for pinging :-) May be this has been skipped from your huge inbox :-) No, it was in there, I just overlooked it... Can you pls kindly provide your feedback on this patch or Shall I repost it? This patch looks fine to me. Applied to u-boot-usb. Thanks Remy As stated in other email thread too. Now all dependencies for Sheevaplug board support are in accepted state except this patch http://lists.denx.de/pipermail/u-boot/2009-June/055112.html Regards.. Prafulla . . Thanks. Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bootcount support on arm/kirkwood
Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, July 09, 2009 12:29 AM To: Prafulla Wadaskar Cc: h...@denx.de; U-Boot user list; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] bootcount support on arm/kirkwood Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202dd54d...@sc-vexch1.marvell. com you wrote: I searched for some space on this CPU for implementing this feature, but could not find any (at least 4 bytes = 1 register), which not lost his value on a reset of this CPU. There is reset counter register on Kirkwood which counts the time for which H/w Reset is pressed-n-hold. This is generally used to trigger Factory Reset Kind of function using reset key. I don't think you are searching for the same. Do you? No, he doesn't. He needs a register that is guaranteed to keep it''s values across a processor reset. With Kirkwood, the only way to implement it is with flash assist No chance? Is there really no register/mem array which keep its value across a processor reset? There is a Security Accelerator SRAM on this chip. Couldn;t I use it? (I looked at it, but it seems, the SRAM gets initialized by reset, but maybe there is a way to deactivate this initialization?) thanks in advance Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCHv2 1/3] A320: driver for FTMAC100 ethernet controller
Dear Jean-Christophe,
2009/7/8 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com:
On 19:12 Wed 01 Jul , Po-Yu Chuang wrote:
This patch adds an FTMAC100 ethernet driver for Faraday A320 evaluation
board.
it's seem good for me
but I'll add it after the core soc
Thank you for your detailed review.
I will resubmit this patch with new soc patch.
diff --git a/drivers/net/Makefile b/drivers/net/Makefile
index c6097c3..8edf529 100644
--- a/drivers/net/Makefile
+++ b/drivers/net/Makefile
@@ -38,6 +38,7 @@ COBJS-$(CONFIG_E1000) += e1000.o
COBJS-$(CONFIG_EEPRO100) += eepro100.o
COBJS-$(CONFIG_ENC28J60) += enc28j60.o
COBJS-$(CONFIG_FSLDMAFEC) += fsl_mcdmafec.o mcfmii.o
+COBJS-$(CONFIG_DRIVER_FTMAC100) += ftmac100.o
please remove the DRIVER_
OK, but some recent patches use DRIVER_ naming.
CONFIG_DRIVER_TI_EMAC
CONFIG_DRIVER_AX88180
Is it not the preferred style?
COBJS-$(CONFIG_GRETH) += greth.o
COBJS-$(CONFIG_INCA_IP_SWITCH) += inca-ip_sw.o
COBJS-$(CONFIG_KIRKWOOD_EGIGA) += kirkwood_egiga.o
diff --git a/drivers/net/ftmac100.c b/drivers/net/ftmac100.c
new file mode 100644
index 000..3057822
--- /dev/null
+++ b/drivers/net/ftmac100.c
+static void ftmac100_reset (struct eth_device *dev)
+{
+ volatile struct ftmac100 *ftmac100 = (struct ftmac100 *)dev-iobase;
do you really need to have all the struct volatile?
I had submitted a v3 of this driver which removed unnecessary volatiles
according to the warnings told by checkpatch.pl.
http://lists.denx.de/pipermail/u-boot/2009-July/055421.html
Please ignore it, since I need to resubmit a new patch later.
+
+ debug (%s()\n, __func__);
+
+ writel (FTMAC100_MACCR_SW_RST, ftmac100-maccr);
+
+ while (readl (ftmac100-maccr) FTMAC100_MACCR_SW_RST) ;
+}
+
+/*
+ * Set MAC address
+ */
+int ftmac100_initialize (bd_t * bd)
+{
+ struct eth_device *dev;
+ struct ftmac100_data *priv;
+
+ if (!(dev = malloc (sizeof *dev))) {
use calloc instead
Is it preferred way?
No driver in driver/net/ uses calloc.
+ printf (%s(): failed to allocate dev\n, __func__);
+ goto out;
+ }
+
+ /* Transmit and receive descriptors should align to 16 bytes */
+
+ if (!(priv = memalign (16, sizeof (struct ftmac100_data {
+ printf (%s(): failed to allocate priv\n, __func__);
+ goto free_dev;
+ }
+
+ memset (dev, 0, sizeof (*dev));
+ memset (priv, 0, sizeof (*priv));
+
+ sprintf (dev-name, FTMAC100);
+ dev-iobase = CONFIG_SYS_MAC100_BASE;
+ dev-init = ftmac100_init;
please use tab for indent
ok, fixed.
+ dev-halt = ftmac100_halt;
+ dev-send = ftmac100_send;
+ dev-recv = ftmac100_recv;
+ dev-priv = priv;
best regards,
Po-Yu Chuang
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND 3/3] arm: Added support for jadecpu board based on Jade SoC
Hello Jean-Christophe
+int board_init(void)
+{
+/* arch number of Versatile Board */
+gd-bd-bi_arch_number = 0 /*MACH_TYPE_GSJADECPU*/;
nack
How to get a arch number? As I don't use Linux on that board
I don't think I need one. What is the right way to handle
such a situation? Dont't set bi_arch_number at all?
+#define CCNT_BASE 0xfff42000
please move define to proper header
+#define CDEBUG1 0xec
+
+#define DDR2C_BASE 0xf300
+#define DRIC0x00
+#define DRIC1 0x02
+#define DRIC2 0x04
+#define DRCA0x06
+#define DRCM0x08
+#define DRCST1 0x0a
+#define DRCST2 0x0c
+#define DRCR0x0e
+#define DRCF0x20
+#define DRASR 0x30
+#define DRIMS 0x50
+#define DROS0x60
+#define DRIBSLI 0x62
+#define DRIBSODT1 0x64
+#define DRIBSOCD0x66
+#define DRIBSOCD2 0x68
+#define DROABA 0x70
+#define DROBV 0x80
+#define DROBS 0x84
+#define DROBSR1 0x86
+#define DROBSR2 0x88
+#define DROBSR3 0x8a
+#define DROBSR4 0x8c
+#define DRIMR1 0x90
+#define DRIMR2 0x92
+#define DRIMR3 0x94
+#define DRIMR4 0x96
+#define DROISR1 0x98
+#define DROISR2 0x9a
what is this define?
I will check this and move the needed ones to jade.h
+
+.macro wait, count
+mov r4, #\count
+3:
+subsr4, r4, #0x1
+bne 3b
+
+.endm
please use include/asm-arm/macro.h
I don't have this file here. Is it currently included in the
master branch of u-boot?
+/*
+ * Reset CPU by writing SWRSTREQ to CRSR-register
+ */
+.globl reset_cpu
+reset_cpu:
+ldr r0, =0xfffe7000 /* CRG Base address */
+ldr r2, =0x0002 /* SWRSTREQ */
+str r2, [r0, #0x0c]
+
+_loop_forever:
+b _loop_forever
is it board or soc specific reset?
Reset is soc specific. I will move it to reset.c in the soc dir.
Right?
this ram init is board or soc specific?
RAM init is board specific as the soc could use other RAM
configurations on other boards. So I think it should stay here.
+#define CONFIG_SYS_HZ 1000
+#define CONFIG_JADE_IOCLK (4150)
+#define CONFIG_SYS_TIMERBASE0xfffe
I guess it's soc specific so please move it to proper header
For the timer base, yes.
+#define VIDEO_KBD_INIT_FCT 0
+#define VIDEO_TSTC_FCT serial_tstc
+#define VIDEO_GETC_FCT serial_getc
??
why?
Well, copy + paste from other board. Even if video is stdout/stdin
serial port is used for input. Better way would be...?
I will fix the points from the other mails also.
Thanks for your time,
Matthias
Amtsgericht Freiburg HRA 602707
Ust. ID-Nr.: DE232464428
Geschäftsführer:
Dipl. Ing. (FH) Martin Graf
Dipl. Ing. (FH) David Graf
Dipl. Inf. Fabian Graf
Komplementärin:
GRAF-SYTECO Verwaltungs-GmbH
Amtsgericht Freiburg HRB 602868
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3
Hi Jean Christophe, thanks for your reply. could you specify the size impact and performance impact? and on which board do you test it? I tested u-boot over sh platforms and no size impact happens (just differencies of few bytes, you can verify this by yourself) About performances, really I obtain a 15% improvement during decompression. Moreover I have to say that, working for my company, we have improved more and more u-boot time just applying other patches regarding different area other than the zlib common one. Please, let me know if my patch will be useful for the community. Best Regards, Giuseppe -Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Thursday, July 09, 2009 12:53 AM To: Giuseppe CONDORELLI Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] zlib: updated to v.1.2.3 On 07:04 Mon 29 Jun , Giuseppe CONDORELLI wrote: This patch updates zlib to the latest stable version. Only relevant zlib parts were ported to u-boot tree, as already did for the current zlib (0.95). New zlib guarantees a faster inflate performances other then others improvements as explained at www.zlib.net Signed-off-by: Giuseppe Condorelli giuseppe.condore...@st.com --- include/u-boot/zlib.h | 718 ++--- lib_generic/zlib.c| 3930 + 2 files changed, 2463 insertions(+), 2185 deletions(-) could you specify the size impact and performance impact? and on which board do you test it? Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bootcount support on arm/kirkwood
-Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 09, 2009 12:05 PM To: Prafulla Wadaskar Cc: Wolfgang Denk; U-Boot user list; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] bootcount support on arm/kirkwood Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, July 09, 2009 12:29 AM To: Prafulla Wadaskar Cc: h...@denx.de; U-Boot user list; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] bootcount support on arm/kirkwood Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202dd54d...@sc-vexch1.marvell. com you wrote: I searched for some space on this CPU for implementing this feature, but could not find any (at least 4 bytes = 1 register), which not lost his value on a reset of this CPU. There is reset counter register on Kirkwood which counts the time for which H/w Reset is pressed-n-hold. This is generally used to trigger Factory Reset Kind of function using reset key. I don't think you are searching for the same. Do you? No, he doesn't. He needs a register that is guaranteed to keep it''s values across a processor reset. With Kirkwood, the only way to implement it is with flash assist No chance? Is there really no register/mem array which keep its value across a processor reset? There is a Security Accelerator SRAM on this chip. Couldn;t I use it? (I looked at it, but it seems, the SRAM gets initialized by reset, but maybe there is a way to deactivate this initialization?) Do you want only across reboots(i.e. resets)? How about re-power cycle? Regards.. Prafulla . . thanks in advance Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug
Hi Jean, hi Prafulla, here the corrected version. Many thanks, Dieter On 14:45 Mon 29 Jun , Dieter Kiermaier wrote: Hi, patch 2 of 2 which adds Kirkwood GPIO support to Sheevaplug. Any comments are welcome! Dieter From 528b24be54256cee20f965bc772390034eaeb232 Mon Sep 17 00:00:00 2001 From: Dieter Kiermaier dk-arm-li...@gmx.de Date: Mon, 29 Jun 2009 14:29:15 +0200 Subject: [PATCH] Sheevaplug: Add Kirkwood gpio support to Sheevaplug Signed-off-by: Dieter Kiermaier dk-arm-li...@gmx.de --- board/Marvell/sheevaplug/sheevaplug.c |1 + include/configs/sheevaplug.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/board/Marvell/sheevaplug/sheevaplug.c b/board/Marvell/sheevaplug/sheevaplug.c index 547126a..fa28fea 100644 --- a/board/Marvell/sheevaplug/sheevaplug.c +++ b/board/Marvell/sheevaplug/sheevaplug.c @@ -26,6 +26,7 @@ #include miiphy.h #include asm/arch/kirkwood.h #include asm/arch/mpp.h +#include asm/arch/gpio.h #include sheevaplug.h DECLARE_GLOBAL_DATA_PTR; diff --git a/include/configs/sheevaplug.h b/include/configs/sheevaplug.h index e62353c..7455c29 100644 --- a/include/configs/sheevaplug.h +++ b/include/configs/sheevaplug.h @@ -43,6 +43,7 @@ #define CONFIG_MD5 /* get_random_hex on krikwood needs MD5 support */ #define CONFIG_SKIP_LOWLEVEL_INIT /* disable board lowlevel_init */ #define CONFIG_KIRKWOOD_EGIGA_INIT /* Enable GbePort0/1 for kernel */ +#define CONFIG_KIRKWOOD_GPIO /* Enable GPIO Support */ #define CONFIG_KIRKWOOD_USBPHY_INIT/* Enable USB PHY init for kernel */ #define CONFIG_KIRKWOOD_RGMII_PAD_1V8 /* Set RGMII Pad voltage to 1.8V */ why do you need it?? Best Regards, J. From b365a66d5134a11d697e5bf0d9d30c116b7d0f0e Mon Sep 17 00:00:00 2001 From: Dieter Kiermaier dk-arm-li...@gmx.de Date: Mon, 29 Jun 2009 14:29:15 +0200 Subject: [PATCH] Sheevaplug: Add Kirkwood gpio support to Sheevaplug Signed-off-by: Dieter Kiermaier dk-arm-li...@gmx.de --- board/Marvell/sheevaplug/sheevaplug.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/board/Marvell/sheevaplug/sheevaplug.c b/board/Marvell/sheevaplug/sheevaplug.c index 547126a..fa28fea 100644 --- a/board/Marvell/sheevaplug/sheevaplug.c +++ b/board/Marvell/sheevaplug/sheevaplug.c @@ -26,6 +26,7 @@ #include miiphy.h #include asm/arch/kirkwood.h #include asm/arch/mpp.h +#include asm/arch/gpio.h #include sheevaplug.h DECLARE_GLOBAL_DATA_PTR; -- 1.5.4.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
Hi Wolfgang,
On Wednesday 08 July 2009 20:53:58 Wolfgang Denk wrote:
diff --git a/MAKEALL b/MAKEALL
index 41f1445..6c80694 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -524,6 +524,7 @@ LIST_ARM9= \
scb9328 \
smdk2400\
smdk2410\
+ suen3 \
trab\
VCMA9 \
versatile \
This is the ARM9 list. Are you sure the board belongs there?
It's using the U-Boot ARM926EJS infrastructure (ARMv5TE). Which the board in
this list seem to be using as well. So yes, I guess the board belongs here.
diff --git a/Makefile b/Makefile
index 2a06440..3afc4ba 100644
--- a/Makefile
+++ b/Makefile
@@ -2925,6 +2925,9 @@ smdk2400_config : unconfig
smdk2410_config: unconfig
@$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 samsung s3c24x0
+suen3_config: unconfig
+ @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) keymile kirkwood
+
This is the ARM9xxx section. Are you sure the board belongs there?
Yes.
diff --git a/board/keymile/suen3/suen3.c b/board/keymile/suen3/suen3.c
new file mode 100644
index 000..231745f
--- /dev/null
+++ b/board/keymile/suen3/suen3.c
@@ -0,0 +1,127 @@
..
+int dram_init(void)
+{
+ int i;
+
+ for (i = 0; i CONFIG_NR_DRAM_BANKS; i++) {
+ gd-bd-bi_dram[i].start = kw_sdram_bar(i);
+ gd-bd-bi_dram[i].size = kw_sdram_bs(i);
+ }
+ return 0;
+}
Maybe we can have get_ram_size() support with auto-sizing and testing
here?
OK, I'll will change it.
diff --git a/include/configs/suen3.h b/include/configs/suen3.h
new file mode 100644
index 000..1b971e0
--- /dev/null
+++ b/include/configs/suen3.h
..
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ load=tftp 40 suen3/u-boot.bin\0 \
+ update=nand erase 0 6;nand write 40 0 6\0 \
+ upd=run load update\0 \
+ mtdparts=orion_nand:512k(uboot),5...@512k(env), \
+ 2...@1m(kernel),1...@3m(rootfs)\0 \
..
+#define MTDPARTS_DEFAULT mtdparts=orion_nand:512k(u-boot), \
+ 256k(env),\
+ 2m(kernel), \
+ 16m(rootfs), \
+ 32m(fs), \
+ -(ubifs)
This seems inconsistent to me. How about defining MTDPARTS_DEFAULT
first, and then just inserting the already defined value, so you can
be sure that this doesn;t happen again?
Yes, good catch. Will change. Thanks for spotting.
Best regards,
Stefan
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug
-Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Thursday, July 09, 2009 12:25 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de; Prafulla Wadaskar Subject: Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug Hi Jean, hi Prafulla, here the corrected version. Many thanks, Dieter On 14:45 Mon 29 Jun , Dieter Kiermaier wrote: Hi, patch 2 of 2 which adds Kirkwood GPIO support to Sheevaplug. Any comments are welcome! Hi Dieter Thanks for your efforts That's good, gpio driver is supported for Kirkwood but, Again question remains the same- Why do you need gpio support on Sheevaplug? Whereas you have no evidence to use it. Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] at91: Introduction of at91sam9g45 SOC.
AT91sam9g45 series is an ARM 926ej-s SOC family clocked at 400/133MHz. It embeds USB high speed host and device, LCD, DDR2 RAM, and a full set of peripherals. The first board that embeds at91sam9g45 chip is the AT91SAM9G45-EKES. On the board you can find 2 USART, USB high speed, a 480*272 LG lcd, ethernet, gpio/joystick/buttons. Signed-off-by: Sedji Gaouaou sedji.gaou...@atmel.com --- MAINTAINERS |3 + MAKEALL | 37 ++-- Makefile| 25 ++ board/atmel/at91sam9m10g45ek/Makefile | 55 board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c | 334 +++ board/atmel/at91sam9m10g45ek/config.mk |1 + board/atmel/at91sam9m10g45ek/led.c | 41 +++ cpu/arm926ejs/at91/Makefile |2 + cpu/arm926ejs/at91/at91sam9m10g45_devices.c | 175 cpu/arm926ejs/at91/clock.c | 12 +- doc/README.at91 | 20 ++ drivers/net/macb.c |6 +- include/asm-arm/arch-at91/at91_pmc.h|1 + include/asm-arm/arch-at91/at91sam9_matrix.h |2 + include/asm-arm/arch-at91/at91sam9g45.h | 139 ++ include/asm-arm/arch-at91/at91sam9g45_matrix.h | 153 +++ include/asm-arm/arch-at91/clk.h |5 + include/asm-arm/arch-at91/hardware.h|6 + include/asm-arm/arch-at91/memory-map.h |1 + include/configs/at91sam9m10g45ek.h | 225 +++ 20 files changed, 1221 insertions(+), 22 deletions(-) create mode 100644 board/atmel/at91sam9m10g45ek/Makefile create mode 100644 board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c create mode 100644 board/atmel/at91sam9m10g45ek/config.mk create mode 100644 board/atmel/at91sam9m10g45ek/led.c create mode 100644 cpu/arm926ejs/at91/at91sam9m10g45_devices.c create mode 100644 include/asm-arm/arch-at91/at91sam9g45.h create mode 100644 include/asm-arm/arch-at91/at91sam9g45_matrix.h create mode 100644 include/configs/at91sam9m10g45ek.h diff --git a/MAINTAINERS b/MAINTAINERS index c874a67..41a0ac5 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -543,6 +543,9 @@ Daniel Gorsulowski daniel.gorsulow...@esd.eu meesc ARM926EJS (AT91SAM9263 SoC) +Sedji Gaouaousedji.gaou...@atmel.com + at91sam9m10g45ekARM926EJS (AT91SAM9G45 SoC) + Marius Gröger m...@sysgo.de impa7 ARM720T (EP7211) diff --git a/MAKEALL b/MAKEALL index a935211..563e871 100755 --- a/MAKEALL +++ b/MAKEALL @@ -571,24 +571,25 @@ LIST_ARM_CORTEX_A8= \ ## AT91 Systems # -LIST_at91=\ - afeb9260\ - at91cap9adk \ - at91rm9200dk\ - at91rm9200ek\ - at91sam9260ek \ - at91sam9261ek \ - at91sam9263ek \ - at91sam9g20ek \ - at91sam9rlek\ - cmc_pu2 \ - csb637 \ - kb9202 \ - meesc \ - mp2usb \ - m501sk \ - pm9261 \ - pm9263 \ +LIST_at91=\ + afeb9260\ + at91cap9adk \ + at91rm9200dk\ + at91rm9200ek\ + at91sam9260ek \ + at91sam9261ek \ + at91sam9263ek \ + at91sam9m10g45ek\ + at91sam9g20ek \ + at91sam9rlek\ + cmc_pu2 \ + csb637 \ + kb9202 \ + meesc \ + mp2usb \ + m501sk \ + pm9261 \ + pm9263 \ # diff --git a/Makefile b/Makefile index e89c592..2f1df61 100644 --- a/Makefile +++ b/Makefile @@ -2775,6 +2775,31 @@ meesc_config : unconfig pm9261_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9261 ronetix at91 +at91sam9m10g45ek_nandflash_config \ +at91sam9m10g45ek_dataflash_config \ +at91sam9m10g45ek_dataflash_cs0_config \ +at91sam9m10g45ek_config \ +at91sam9g45ekes_nandflash_config \ +at91sam9g45ekes_dataflash_config \ +at91sam9g45ekes_dataflash_cs0_config \ +at91sam9g45ekes_config : unconfig + @mkdir -p $(obj)include + @if [ $(findstring 9m10,$@) ] ; then \ + echo #define CONFIG_AT91SAM9M10G45EK 1 $(obj)include/config.h ; \ + $(XECHO) ... 9M10G45 Variant ; \ + else \ + echo #define CONFIG_AT91SAM9G45EKES 1 $(obj)include/config.h ; \ + fi; + + @if [ $(findstring _nandflash,$@) ] ; then \ + echo #define CONFIG_SYS_USE_NANDFLASH 1
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
Hi Prafulla, On Wednesday 08 July 2009 19:48:19 Prafulla Wadaskar wrote: MAINTAINERS |1 + MAKEALL |1 + Makefile |3 + board/keymile/suen3/Makefile | 51 + board/keymile/suen3/config.mk | 25 board/keymile/suen3/sdramregs.txt | 28 + This file will be of no use until we have proposed bin_dep.sh and doimage utility in place. Even without doimage and/or bin_dep.sh in place, I think it makes perfect sense to include this SDRAM init file in the board directory. Mainly because of two reasons: a) Keep bootloader related files in one place (SDRAM init is crucial for correct operation) b) Keep those files under revision control And I don't think that anything really speaks against having this file in this place for now. But anyway, we should try to get at least your bin_dep.sh infrastructure accepter. Or at least restart the discussion about it (and probably about doimage as well). board/keymile/suen3/suen3.c | 127 + include/configs/suen3.h | 221 + 8 files changed, 457 insertions(+), 0 deletions(-) create mode 100644 board/keymile/suen3/Makefile create mode 100644 board/keymile/suen3/config.mk create mode 100644 board/keymile/suen3/sdramregs.txt create mode 100644 board/keymile/suen3/suen3.c create mode 100644 include/configs/suen3.h diff --git a/MAINTAINERS b/MAINTAINERS index 705bac5..ce117e1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -637,6 +637,7 @@ Stefan Roese s...@denx.de ixdpg425xscale pdnb3 xscale scpuxscale + suen3 ARM926EJS (Kirkwood SoC) Alessandro Rubini rub...@unipv.it Nomadik Linux Team stn_wmm_nomadik_li...@list.st.com diff --git a/MAKEALL b/MAKEALL index 41f1445..6c80694 100755 --- a/MAKEALL +++ b/MAKEALL @@ -524,6 +524,7 @@ LIST_ARM9= \ scb9328 \ smdk2400\ smdk2410\ + suen3 \ trab\ VCMA9 \ versatile \ diff --git a/Makefile b/Makefile index 2a06440..3afc4ba 100644 --- a/Makefile +++ b/Makefile @@ -2925,6 +2925,9 @@ smdk2400_config : unconfig smdk2410_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 samsung s3c24x0 +suen3_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) keymile +kirkwood + SX1_stdout_serial_config \ SX1_config:unconfig @mkdir -p $(obj)include diff --git a/board/keymile/suen3/Makefile b/board/keymile/suen3/Makefile new file mode 100644 index 000..de05cc8 --- /dev/null +++ b/board/keymile/suen3/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com # Prafulla Wadaskar +prafu...@marvell.com # # See file CREDITS for list of people who +contributed to this # project. I think you forgot to change these lines :-) I didn't change much in this file, so I didn't change the copyright header. +# +# 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., 51 Franklin Street, Fifth Floor, Boston, # MA +02110-1301 USA # + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := suen3.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# ## +## + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# ## +## diff --git a/board/keymile/suen3/config.mk b/board/keymile/suen3/config.mk new file mode 100644 index 000..fb29a1b --- /dev/null +++ b/board/keymile/suen3/config.mk @@ -0,0 +1,25 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
Hi Stefan, hi Prafulla, Hi Prafulla, On Wednesday 08 July 2009 19:48:19 Prafulla Wadaskar wrote: MAINTAINERS |1 + MAKEALL |1 + Makefile |3 + board/keymile/suen3/Makefile | 51 + board/keymile/suen3/config.mk | 25 board/keymile/suen3/sdramregs.txt | 28 + This file will be of no use until we have proposed bin_dep.sh and doimage utility in place. Even without doimage and/or bin_dep.sh in place, I think it makes perfect sense to include this SDRAM init file in the board directory. Mainly because of two reasons: a) Keep bootloader related files in one place (SDRAM init is crucial for correct operation) b) Keep those files under revision control And I don't think that anything really speaks against having this file in this place for now. But anyway, we should try to get at least your bin_dep.sh infrastructure accepter. Or at least restart the discussion about it (and probably about doimage as well). I would prefer this, too. If I'm allowed to vote for this :) Dieter board/keymile/suen3/suen3.c | 127 + include/configs/suen3.h | 221 + 8 files changed, 457 insertions(+), 0 deletions(-) create mode 100644 board/keymile/suen3/Makefile create mode 100644 board/keymile/suen3/config.mk create mode 100644 board/keymile/suen3/sdramregs.txt create mode 100644 board/keymile/suen3/suen3.c create mode 100644 include/configs/suen3.h diff --git a/MAINTAINERS b/MAINTAINERS index 705bac5..ce117e1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -637,6 +637,7 @@ Stefan Roese s...@denx.de ixdpg425xscale pdnb3 xscale scpuxscale + suen3 ARM926EJS (Kirkwood SoC) Alessandro Rubini rub...@unipv.it Nomadik Linux Team stn_wmm_nomadik_li...@list.st.com diff --git a/MAKEALL b/MAKEALL index 41f1445..6c80694 100755 --- a/MAKEALL +++ b/MAKEALL @@ -524,6 +524,7 @@ LIST_ARM9= \ scb9328 \ smdk2400\ smdk2410\ + suen3 \ trab\ VCMA9 \ versatile \ diff --git a/Makefile b/Makefile index 2a06440..3afc4ba 100644 --- a/Makefile +++ b/Makefile @@ -2925,6 +2925,9 @@ smdk2400_config : unconfig smdk2410_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm920t smdk2410 samsung s3c24x0 +suen3_config: unconfig + @$(MKCONFIG) $(@:_config=) arm arm926ejs $(@:_config=) keymile +kirkwood + SX1_stdout_serial_config \ SX1_config: unconfig @mkdir -p $(obj)include diff --git a/board/keymile/suen3/Makefile b/board/keymile/suen3/Makefile new file mode 100644 index 000..de05cc8 --- /dev/null +++ b/board/keymile/suen3/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2009 +# Marvell Semiconductor www.marvell.com # Prafulla Wadaskar +prafu...@marvell.com # # See file CREDITS for list of people who +contributed to this # project. I think you forgot to change these lines :-) I didn't change much in this file, so I didn't change the copyright header. +# +# 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., 51 Franklin Street, Fifth Floor, Boston, # MA +02110-1301 USA # + +include $(TOPDIR)/config.mk + +LIB = $(obj)lib$(BOARD).a + +COBJS:= suen3.o + +SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) +SOBJS:= $(addprefix $(obj),$(SOBJS)) + +$(LIB): $(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# ## +## + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# ## +## diff --git a/board/keymile/suen3/config.mk
Re: [U-Boot] bootcount support on arm/kirkwood
Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Heiko Schocher [mailto:h...@denx.de] Sent: Thursday, July 09, 2009 12:05 PM To: Prafulla Wadaskar Cc: Wolfgang Denk; U-Boot user list; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] bootcount support on arm/kirkwood Hello Prafulla, Prafulla Wadaskar wrote: -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, July 09, 2009 12:29 AM To: Prafulla Wadaskar Cc: h...@denx.de; U-Boot user list; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] bootcount support on arm/kirkwood Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202dd54d...@sc-vexch1.marvell. com you wrote: I searched for some space on this CPU for implementing this feature, but could not find any (at least 4 bytes = 1 register), which not lost his value on a reset of this CPU. There is reset counter register on Kirkwood which counts the time for which H/w Reset is pressed-n-hold. This is generally used to trigger Factory Reset Kind of function using reset key. I don't think you are searching for the same. Do you? No, he doesn't. He needs a register that is guaranteed to keep it''s values across a processor reset. With Kirkwood, the only way to implement it is with flash assist No chance? Is there really no register/mem array which keep its value across a processor reset? There is a Security Accelerator SRAM on this chip. Couldn;t I use it? (I looked at it, but it seems, the SRAM gets initialized by reset, but maybe there is a way to deactivate this initialization?) Do you want only across reboots(i.e. resets)? How about re-power cycle? Yes, I need this only across reboots (processor resets). If the board is powered off/on, the value of this area gets new initialized from software. bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
On Thursday 09 July 2009 09:21:33 Dieter Kiermaier wrote: On Wednesday 08 July 2009 19:48:19 Prafulla Wadaskar wrote: MAINTAINERS |1 + MAKEALL |1 + Makefile |3 + board/keymile/suen3/Makefile | 51 + board/keymile/suen3/config.mk | 25 board/keymile/suen3/sdramregs.txt | 28 + This file will be of no use until we have proposed bin_dep.sh and doimage utility in place. Even without doimage and/or bin_dep.sh in place, I think it makes perfect sense to include this SDRAM init file in the board directory. Mainly because of two reasons: a) Keep bootloader related files in one place (SDRAM init is crucial for correct operation) b) Keep those files under revision control And I don't think that anything really speaks against having this file in this place for now. But anyway, we should try to get at least your bin_dep.sh infrastructure accepter. Or at least restart the discussion about it (and probably about doimage as well). I would prefer this, too. If I'm allowed to vote for this :) Sure you are. At least if you share my opinion! ;) Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] usb: add Marvell Kirkwood ehci host controller driver
Hello Prafulla,
As stated in other email thread too.
Now all dependencies for Sheevaplug board support are in accepted state
except this patch http://lists.denx.de/pipermail/u-boot/2009-June/055112.html
I know that but I cannot test it because I do not have the hardware,
so I depend on others here. (it might be even you). I already
mentioned that I would prefer the cleanup patch from Michael
Trimarchi, if it is correct.
At least there is 1 significant difference between your patch and the
patch of Michael
Your patch contains this:
- typeReq = req-request 8 | req-requesttype;
+ typeReq = req-request | req-requesttype 8;
switch (le16_to_cpu(typeReq)) {
and Michael patch contains this:
- typeReq = req-request 8 | req-requesttype;
+ typeReq = req-request | req-requesttype 8;
- switch (le16_to_cpu(typeReq)) {
+ switch (typeReq) {
So, at least one of them is wrong.
This difference is reason enough for me to not pull either patch in
until this is clear.
Kind Regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants
Dear Scott Wood, In message 4a551d5a.5060...@freescale.com you wrote: But then applying this patch would break some boards that are working now. Shirking off responsibility and have the board maintainers fix it again is IMHO not the right thing to do. What would break? If things would no longer fit where they currently fit, that could happen on any change that increases code size -- Right, which is why I continue to resist to certain changes that increase code size. possibly even just by changing compilers (this exact thing happened to the NAND bootstrap on some boards with very recent GCC). That's life, But then changing the tool chain is something that is under control of the board maintainer, so he is automatically also called on fixing any problems resulting from this. This is different from changes that other people are doing. A quick grep shows several instances of %ll/%L in other places that may not be obvious to the board maintainer (cmd_mmc, ubi, disk/part_efi, cpu/mpc8xxx/ddr, lmb, disk/part, cmd_ide, reiserfs). Boards that use those without 64-bit printf are broken *right now*. Agreed. It would be good to get at least error messages for such cases. It is not good that they go through unnoticed. 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 sense in being precise when you don't even know what you're talking about. -- John von Neumann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
Hello Stefan, Stefan Roese wrote: On Wednesday 08 July 2009 20:53:58 Wolfgang Denk wrote: diff --git a/MAKEALL b/MAKEALL index 41f1445..6c80694 100755 --- a/MAKEALL +++ b/MAKEALL [...] +#define CONFIG_EXTRA_ENV_SETTINGS \ + load=tftp 40 suen3/u-boot.bin\0 \ + update=nand erase 0 6;nand write 40 0 6\0 \ + upd=run load update\0 \ + mtdparts=orion_nand:512k(uboot),5...@512k(env), \ + 2...@1m(kernel),1...@3m(rootfs)\0 \ .. +#define MTDPARTS_DEFAULT mtdparts=orion_nand:512k(u-boot), \ + 256k(env),\ + 2m(kernel), \ + 16m(rootfs), \ + 32m(fs), \ + -(ubifs) This seems inconsistent to me. How about defining MTDPARTS_DEFAULT first, and then just inserting the already defined value, so you can be sure that this doesn;t happen again? Yes, good catch. Will change. Thanks for spotting. Maybe you have a look at: include/configs/km8xx.h for an example. bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bootcount support on arm/kirkwood
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202dd54d...@sc-vexch1.marvell.com you wrote: No, he doesn't. He needs a register that is guaranteed to keep it''s values across a processor reset. With Kirkwood, the only way to implement it is with flash assist There is not a single register in the whole CPU and all the peripherals it implements that keeps it's value over a reset? I'd really be surprised if that was indeed true. Could you please check again? Maybe ask the chip designers? 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 two ways to write error-free programs. Only the third one works. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] bootcount support on arm/kirkwood
Dear Prafulla Wadaskar, In message 73173d32e9439e4abb5151606c3e19e202dd54d...@sc-vexch1.marvell.com you wrote: No chance? Is there really no register/mem array which keep its value across a processor reset? ... Do you want only across reboots(i.e. resets)? How about re-power cycle? It needs to keep it's value only through resets; it is assumed that power cycling gets detected independently from that, in which case this boot counter would be reset to 0. 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 Puritan is someone who is deathly afraid that someone, somewhere, is having fun. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How to start U-Boot for i.MX31 NAND out of RedBoot (out of RAM)
Hello Magnus Lilja lilja.mag...@gmail.com 08.07.09 17.42 Uhr Hi You should define CONFIG_SKIP_LOWLEVEL_INIT since redboot has already setup the SDRAM. If you load U-boot to the address it's set up to execute from you should also define CONFIG_SKIP_RELOCATE_UBOOT. It's been a long while since I used redboot to start u-boot (on the i.MX31 PDK) so I don't remember the correct redboot command but make sure the MMU is off when jumping to U-Boot. Regards, Magnus I made the defines you mentioned above and build the image with make mx31guf_config (it's quite similar to the PDK board). Then I loaded the resulting u-boot.bin to 0x8100 and tried to run 0x8100. The run command is with caches and MMU tured off. I get absolutely no output on the console and I have to reset the board. What could be the problem? How can I debug this? Thanks a lot for your help. Best Regards Ulrich Gerster ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] MAINTAINERS: fix sorting, remove duplicates.
Signed-off-by: Wolfgang Denk w...@denx.de --- MAINTAINERS | 20 1 files changed, 8 insertions(+), 12 deletions(-) diff --git a/MAINTAINERS b/MAINTAINERS index 705bac5..0041112 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -583,6 +583,10 @@ Prakash Kumar prak...@embedx.com cerf250 xscale +Sergey Lapin sla...@ossfans.org + + afeb9260ARM926EJS (AT91SAM9260 SoC) + Guennadi Liakhovetski g.liakhovet...@gmx.de imx31_phycore_eet i.MX31 @@ -682,10 +686,6 @@ Alex Z lartSA1100 dnp1110 SA1110 -Sergey Lapin sla...@ossfans.org - - afeb9260ARM926EJS (AT91SAM9260 SoC) - - Unknown / orphaned boards: @@ -782,14 +782,14 @@ Michal Simek mon...@monstr.eu # Board CPU # # -Matthias Fuchs matthias.fu...@esd-electronics.com - - TASREG MCF5249 - Hayden Fraser hayden.fra...@freescale.com M5253EVBE mcf52x2 +Matthias Fuchs matthias.fu...@esd-electronics.com + + TASREG MCF5249 + TsiChung Liew tsi-chung.l...@freescale.com M52277EVB mcf5227x @@ -862,10 +862,6 @@ Yoshihiro Shimoda shimoda.yoshih...@renesas.com MS7720SESH7720 R0P77850011RL SH7785 -Yusuke Goda goda.yus...@renesas.com - - MIGO-R SH7722 - # # Blackfin Systems:# # # -- 1.6.0.6 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8]: Handle VID header offset in ubi part command
On Tuesday 07 July 2009 16:59:46 Simon Kagstrom wrote: The VID header offset is sometimes needed to initialize the UBI partition. This patch adds it (optionally) to the command line for the ubi part command. (Lines have been properly wrapped since last version) Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net Acked-by: Stefan Roese s...@denx.de Applied to u-boot-ubi. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ubi
The following changes since commit a350d0d37d7c113afbd9b0d2cf60ac542007f9e6: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://www.denx.de/git/u-boot-ubi.git master Simon Kagstrom (1): Handle VID header offset in ubi part command common/cmd_ubi.c | 21 - 1 files changed, 16 insertions(+), 5 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
-Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: Thursday, July 09, 2009 12:54 PM To: dk-arm-li...@gmx.de Cc: u-boot@lists.denx.de; Prafulla Wadaskar; Ashish Karkare; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support On Thursday 09 July 2009 09:21:33 Dieter Kiermaier wrote: On Wednesday 08 July 2009 19:48:19 Prafulla Wadaskar wrote: MAINTAINERS |1 + MAKEALL |1 + Makefile |3 + board/keymile/suen3/Makefile | 51 + board/keymile/suen3/config.mk | 25 board/keymile/suen3/sdramregs.txt | 28 + This file will be of no use until we have proposed bin_dep.sh and doimage utility in place. Even without doimage and/or bin_dep.sh in place, I think it makes perfect sense to include this SDRAM init file in the board directory. Mainly because of two reasons: a) Keep bootloader related files in one place (SDRAM init is crucial for correct operation) b) Keep those files under revision control And I don't think that anything really speaks against having this file in this place for now. But anyway, we should try to get at least your bin_dep.sh infrastructure accepter. Or at least restart the discussion about it (and probably about doimage as well). I would prefer this, too. If I'm allowed to vote for this :) Sure you are. At least if you share my opinion! ;) Thanks a lot for your support :-) I will repost these patches soon, (by afternoon) Regards.. Prafulla . . Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3 3/3] A320: Add support for Faraday A320 evaluation board
Dear Po-Yu Chuang, In message ec1aee9f0907090036q4b18f1b4sf6e4b2940c6f1...@mail.gmail.com you wrote: --- a/MAINTAINERS +++ b/MAINTAINERS @@ -680,6 +680,10 @@ Sergey Lapin sla...@ossfans.org afeb9260ARM926EJS (AT91 SAM9260 SoC) +Po-Yu Chuang ratb...@faraday-tech.com + + a320FA526 (ARM v4/reuse arm920t source) faraday SoC Please keep list of maintainers alphabetically sorted. What is the key for sorting? I cannot figure it out. The key is the last name of the maintainer. I just notice that the afeb9260 entry is wrong. Will send a patch to fix this. +a320_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm920t a320 faraday fa raday This is a arm920t processor, so please add it in ARM720T Systems section. +### ## ## ARM720T Systems ## ### 720t? Sorry, I meant ARM92xT Systems section. How about integrator section? Many 920t boards are there. I don't think your board is an integrator board, or is 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 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] [PATCH] MAINTAINERS: fix sorting, remove duplicates.
In message 1247126279-2680-1-git-send-email...@denx.de you wrote: Signed-off-by: Wolfgang Denk w...@denx.de --- MAINTAINERS | 20 1 files changed, 8 insertions(+), 12 deletions(-) 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 I object to intellect without discipline; I object to power without constructive purpose. -- Spock, The Squire of Gothos, stardate 2124.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] pxa: add clock for system bus 2 arbiter
ping? On Tue, Jun 23, 2009 at 05:30:04PM +0200, Daniel Mack wrote: From: Daniel Mack dan...@caiaq.de To: u-boot@lists.denx.de Cc: Daniel Mack dan...@caiaq.de Subject: [PATCH 1/2] pxa: add clock for system bus 2 arbiter Date: Tue, 23 Jun 2009 17:30:04 +0200 Message-Id: 1245771005-23299-1-git-send-email-dan...@caiaq.de X-Mailer: git-send-email 1.6.3.1 This clock is needed for systems using the USB2 device unit or the 2d graphics accelerator. Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/arch-pxa/pxa-regs.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 5a0885a..1f81e11 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1952,6 +1952,7 @@ typedef void(*ExcpHndlr) (void) ; #define CKENA_2_USBHOST (1 2)/* USB Host Unit Clock Enable */ #define CKENA_1_LCD (1 1)/* LCD Unit Clock Enable */ +#define CKENB_9_SYSBUS2 (1 9)/* System bus 2 */ #define CKENB_8_1WIRE((1 8) + 32) /* One Wire Interface Unit Clock Enable */ #define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ #define CKENB_6_IRQ ((1 6) + 32) /* Interrupt Controller Clock Enable */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] pxa: fix CKEN_B register bits
ping? On Tue, Jun 23, 2009 at 05:30:05PM +0200, Daniel Mack wrote: From: Daniel Mack dan...@caiaq.de To: u-boot@lists.denx.de Cc: Daniel Mack dan...@caiaq.de Subject: [PATCH 2/2] pxa: fix CKEN_B register bits Date: Tue, 23 Jun 2009 17:30:05 +0200 Message-Id: 1245771005-23299-2-git-send-email-dan...@caiaq.de X-Mailer: git-send-email 1.6.3.1 The current defition for CKEN_B register bits is nonsense. Adding 32 to the shifted value is equal to '| (1 5)', and this bit is marked 'reserved' in the PXA docs. Signed-off-by: Daniel Mack dan...@caiaq.de --- include/asm-arm/arch-pxa/pxa-regs.h | 12 ++-- 1 files changed, 6 insertions(+), 6 deletions(-) diff --git a/include/asm-arm/arch-pxa/pxa-regs.h b/include/asm-arm/arch-pxa/pxa-regs.h index 1f81e11..2a723dc 100644 --- a/include/asm-arm/arch-pxa/pxa-regs.h +++ b/include/asm-arm/arch-pxa/pxa-regs.h @@ -1953,12 +1953,12 @@ typedef void (*ExcpHndlr) (void) ; #define CKENA_1_LCD (1 1)/* LCD Unit Clock Enable */ #define CKENB_9_SYSBUS2 (1 9)/* System bus 2 */ -#define CKENB_8_1WIRE((1 8) + 32) /* One Wire Interface Unit Clock Enable */ -#define CKENB_7_GPIO ((1 7) + 32) /* GPIO Clock Enable */ -#define CKENB_6_IRQ ((1 6) + 32) /* Interrupt Controller Clock Enable */ -#define CKENB_4_I2C ((1 4) + 32) /* I2C Unit Clock Enable */ -#define CKENB_1_PWM1 ((1 1) + 32) /* PWM2 PWM3 Clock Enable */ -#define CKENB_0_PWM0 ((1 0) + 32) /* PWM0 PWM1 Clock Enable */ +#define CKENB_8_1WIRE(1 8)/* One Wire Interface Unit Clock Enable */ +#define CKENB_7_GPIO (1 7)/* GPIO Clock Enable */ +#define CKENB_6_IRQ (1 6)/* Interrupt Controller Clock Enable */ +#define CKENB_4_I2C (1 4)/* I2C Unit Clock Enable */ +#define CKENB_1_PWM1 (1 1)/* PWM2 PWM3 Clock Enable */ +#define CKENB_0_PWM0 (1 0)/* PWM0 PWM1 Clock Enable */ #else /* if defined CONFIG_CPU_MONAHANS */ -- 1.6.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug
-Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Thursday, July 09, 2009 12:50 PM To: Prafulla Wadaskar Subject: Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug Hi Prafulla, -Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Thursday, July 09, 2009 12:25 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de; Prafulla Wadaskar Subject: Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug Hi Jean, hi Prafulla, here the corrected version. Many thanks, Dieter On 14:45 Mon 29 Jun , Dieter Kiermaier wrote: Hi, patch 2 of 2 which adds Kirkwood GPIO support to Sheevaplug. Any comments are welcome! Hi Dieter Thanks for your efforts That's good, gpio driver is supported for Kirkwood but, Again question remains the same- Why do you need gpio support on Sheevaplug? Whereas you have no evidence to use it. That's a good question :) I need gpio support for my own board which will come up the next 2 months. So maybe you're right. There is no need for GPIO support on SheevaPlug. Well.. you better post separate patch for your board that needs to use gpio support. On the other hand there are maybe some hackers out there using sheevaplug not only as it is. So maybe there is a need for some GPIO bitbanging? At least if you open the case :) I will post this information on plug forum (http://plugcomputer.org/plugforum/index.php). Also a small how-to doc to uses gpio support for bit bang interface. Also many thanks to all of you out there for such a nice boot loader :) Dieter Thanks to yourself too :-) let's make it further better. Regards. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug
Hi, -Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Thursday, July 09, 2009 12:50 PM To: Prafulla Wadaskar Subject: Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug Hi Prafulla, -Original Message- From: Dieter Kiermaier [mailto:dk-arm-li...@gmx.de] Sent: Thursday, July 09, 2009 12:25 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de; Prafulla Wadaskar Subject: Re: [U-Boot] [PATCH2/2] Sheevaplug: Add Kirkwood gpio support to Sheevaplug Hi Jean, hi Prafulla, here the corrected version. Many thanks, Dieter On 14:45 Mon 29 Jun , Dieter Kiermaier wrote: Hi, patch 2 of 2 which adds Kirkwood GPIO support to Sheevaplug. Any comments are welcome! Hi Dieter Thanks for your efforts That's good, gpio driver is supported for Kirkwood but, Again question remains the same- Why do you need gpio support on Sheevaplug? Whereas you have no evidence to use it. That's a good question :) I need gpio support for my own board which will come up the next 2 months. So maybe you're right. There is no need for GPIO support on SheevaPlug. Well.. you better post separate patch for your board that needs to use gpio support. Would be the best solution. Is there anything I have to know if I want u-boot to support my own board? On the other hand there are maybe some hackers out there using sheevaplug not only as it is. So maybe there is a need for some GPIO bitbanging? At least if you open the case :) I will post this information on plug forum (http://plugcomputer.org/plugforum/index.php). Also a small how-to doc to uses gpio support for bit bang interface. Good idea. Also many thanks to all of you out there for such a nice boot loader :) Dieter Thanks to yourself too :-) let's make it further better. Yep. Dieter Regards. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi
On Thu, 9 Jul 2009 09:59:56 +0200 Stefan Roese s...@denx.de wrote: The following changes since commit a350d0d37d7c113afbd9b0d2cf60ac542007f9e6: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://www.denx.de/git/u-boot-ubi.git master Simon Kagstrom (1): Handle VID header offset in ubi part command Thanks for applying this! However, I think the [PATCH 8/8]: Command improvements for ubifs patch should also be uncontroversial: http://lists.denx.de/pipermail/u-boot/2009-July/055602.html It's basically just a check for the number of arguments passed and a description of what the command does. To use ubifs on ARM, I also need the rest of the patch series http://lists.denx.de/pipermail/u-boot/2009-July/055594.html but I haven't seen any comments on that so far. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi
On Thursday 09 July 2009 10:16:11 Simon Kagstrom wrote: The following changes since commit a350d0d37d7c113afbd9b0d2cf60ac542007f9e6: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://www.denx.de/git/u-boot-ubi.git master Simon Kagstrom (1): Handle VID header offset in ubi part command Thanks for applying this! However, I think the [PATCH 8/8]: Command improvements for ubifs patch should also be uncontroversial: http://lists.denx.de/pipermail/u-boot/2009-July/055602.html It's basically just a check for the number of arguments passed and a description of what the command does. Yes. And I already acked it on the list. Please note that I'm only the co- custodian for the UBI repository. We have no UBIFS custodian. So it needs to get into mainline via Wolfgang. To use ubifs on ARM, I also need the rest of the patch series http://lists.denx.de/pipermail/u-boot/2009-July/055594.html but I haven't seen any comments on that so far. No comments doesn't have to be a bad sign. So nobody has something to complain about them. In fact I think your patches are good. So I'll probably send a few acked-by's soon. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8]: Move __set/clear_bit from ubifs.h to bitops.h
On Tuesday 07 July 2009 15:56:31 Simon Kagstrom wrote: Move __set/clear_bit from ubifs.h to bitops.h __set_bit and __clear_bit are defined in ubifs.h as well as in asm/include/bitops.h for some architectures. This patch moves the generic implementation to include/linux/bitops.h and uses that unless it's defined by the architecture. Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net Acked-by: Stefan Roese s...@denx.de Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi
On Thu, 9 Jul 2009 10:24:42 +0200 Stefan Roese s...@denx.de wrote: Thanks for applying this! However, I think the [PATCH 8/8]: Command improvements for ubifs patch should also be uncontroversial: Yes. And I already acked it on the list. Please note that I'm only the co- custodian for the UBI repository. We have no UBIFS custodian. So it needs to get into mainline via Wolfgang. Ah, OK! I simply assumed UBI/UBIFS maintenance went together and that it simply got missed. To use ubifs on ARM, I also need the rest of the patch series http://lists.denx.de/pipermail/u-boot/2009-July/055594.html but I haven't seen any comments on that so far. No comments doesn't have to be a bad sign. So nobody has something to complain about them. In fact I think your patches are good. So I'll probably send a few acked-by's soon. Well my worry with the series is that it touches pretty much all architectures, which I haven't been able to test. So that is basically where I'd like some feedback. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi
On Thursday 09 July 2009 10:32:02 Simon Kagstrom wrote: To use ubifs on ARM, I also need the rest of the patch series http://lists.denx.de/pipermail/u-boot/2009-July/055594.html but I haven't seen any comments on that so far. No comments doesn't have to be a bad sign. So nobody has something to complain about them. In fact I think your patches are good. So I'll probably send a few acked-by's soon. Well my worry with the series is that it touches pretty much all architectures, which I haven't been able to test. So that is basically where I'd like some feedback. Unfortunately we don't have many boards in mainline U-Boot yet that include UBI/UBIFS till now. So problems in this area might get unnoticed right now. Did you at least compile-test your patchset on some of the other architectures (PPC, MIPS...)? Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/8]: Use do_div from div64.h for vsprintf
On Tuesday 07 July 2009 15:59:27 Simon Kagstrom wrote: Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net Acked-by: Stefan Roese s...@denx.de Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8]: Add unaligned.h for arm
On Tuesday 07 July 2009 15:58:51 Simon Kagstrom wrote: This patch adds unaligned.h for ARM (needed to build with LZO compression). The file is taken from the linux kernel, but includes u-boot headers instead. Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net Acked-by: Stefan Roese s...@denx.de Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
Hi, On Wednesday 08 July 2009 22:57, Wolfgang Denk wrote: Dear Matthias Fuchs, In message 200907082251.27180.matthias.fu...@esd-electronics.com you wrote: Do we have some old PPCBoot CVS accessible somewhere? I want to find out what exactly is covers by the IBM license. Sure. See http://sourceforge.net/projects/ppcboot/develop Best regards, Wolfgang Denk I just checked the nine years old initial version of 405gp_pci.c: http://ppcboot.cvs.sourceforge.net/viewvc/ppcboot/ppcboot/cpu/ppc4xx/405gp_pci.c?revision=1.1view=markup I do not see that this file has anything in common with the current 4xx_pci.c code! One could say that setting up the PMM registes looks a little as is comes from the old IBM code, but can writing zeros into some registers really stop us from cleaning up this license issue? If so, I see no way to reach the GPL cleanup goal. I will submit a cleanup patch for the 4xx_pci.c when we are common in this point. I also request Ack-bys at least from you and Stefan on my patch to not have one foot in the grave :-) Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
Hi Prafulla, On Thursday 09 July 2009 09:15:29 Stefan Roese wrote: +++ b/board/keymile/suen3/sdramregs.txt Under which license? GPL of course. ;) And one question about this: Does doimage allow comments? And if yes, what's the comment control character? Is C-style supported (/*)? I tried to put some comment lines into this file (/*, //, #, ;) but nothing worked so far. doimage just didn't finish building the image. Any ideas what could be used for a comment line? Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/4]: arm: Kirkwood: Set MAC address during registration for kirkwood egiga
-Original Message- From: Simon Kagstrom [mailto:simon.kagst...@netinsight.net] Sent: Wednesday, July 08, 2009 4:32 PM Cc: U-Boot ML; Prafulla Wadaskar Subject: [PATCH 1/4]: arm: Kirkwood: Set MAC address during registration for kirkwood egiga This patch sets the MAC address during registration in addition to during device init. Since U-boot might not access the ethernet device, Linux might end up with the MAC address unset. Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- drivers/net/kirkwood_egiga.c |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c index 3c5db19..d760e1d 100644 --- a/drivers/net/kirkwood_egiga.c +++ b/drivers/net/kirkwood_egiga.c @@ -653,6 +653,8 @@ int kirkwood_egiga_initialize(bd_t * bis) dev-send = (void *)kwgbe_send; dev-recv = (void *)kwgbe_recv; + port_uc_addr_set(dkwgbe-regs, dev-enetaddr); + eth_register(dev); #if defined(CONFIG_MII) || defined(CONFIG_CMD_MII) -- Ack. Good catch, I had removed it during code size reduction :-( Regards.. Prafulla . . 1.6.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi
On Thu, 9 Jul 2009 10:36:58 +0200 Stefan Roese s...@denx.de wrote: Unfortunately we don't have many boards in mainline U-Boot yet that include UBI/UBIFS till now. So problems in this area might get unnoticed right now. Did you at least compile-test your patchset on some of the other architectures (PPC, MIPS...)? Well, the only other cross-compiler I had around is for powerpc. I built for the MPC8349ITX board, and that compiled just fine. But then again PPC already had ffs/fls. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support
-Original Message- From: Stefan Roese [mailto:s...@denx.de] Sent: Thursday, July 09, 2009 2:19 PM To: u-boot@lists.denx.de Cc: Prafulla Wadaskar; Ashish Karkare; Prabhanjan Sarnaik Subject: Re: [U-Boot] [PATCH 4/4] arm/kirkwood: Add Keymile SUEN3 support Hi Prafulla, On Thursday 09 July 2009 09:15:29 Stefan Roese wrote: +++ b/board/keymile/suen3/sdramregs.txt Under which license? GPL of course. ;) And one question about this: Does doimage allow comments? And if yes, what's the comment control character? Is C-style supported (/*)? No, this need to be added to doImage code. Regards.. Prafula . . I tried to put some comment lines into this file (/*, //, #, ;) but nothing worked so far. doimage just didn't finish building the image. Any ideas what could be used for a comment line? Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi
On Thursday 09 July 2009 10:49:47 Simon Kagstrom wrote: Did you at least compile-test your patchset on some of the other architectures (PPC, MIPS...)? Well, the only other cross-compiler I had around is for powerpc. I built for the MPC8349ITX board, and that compiled just fine. But then again PPC already had ffs/fls. Well, that's a good sign then. You didn't break the PPC implementation with your patch. ;) Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
On Thursday 09 July 2009 10:44:13 Matthias Fuchs wrote: I just checked the nine years old initial version of 405gp_pci.c: http://ppcboot.cvs.sourceforge.net/viewvc/ppcboot/ppcboot/cpu/ppc4xx/405gp_ pci.c?revision=1.1view=markup I do not see that this file has anything in common with the current 4xx_pci.c code! One could say that setting up the PMM registes looks a little as is comes from the old IBM code, but can writing zeros into some registers really stop us from cleaning up this license issue? Yes, those files don't have much in common any more. Only some comments (which could be removed or rewritten) and and the sequence of some register initialisation. But again, IANAL and I don't really know if we can remove the IBM header with such a history. If so, I see no way to reach the GPL cleanup goal. I will submit a cleanup patch for the 4xx_pci.c when we are common in this point. I also request Ack-bys at least from you and Stefan on my patch to not have one foot in the grave :-) Heh, don't be such a coward! No risk, no fun! ;) Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
On Thursday 09 July 2009 11:00, Stefan Roese wrote: On Thursday 09 July 2009 10:44:13 Matthias Fuchs wrote: I just checked the nine years old initial version of 405gp_pci.c: http://ppcboot.cvs.sourceforge.net/viewvc/ppcboot/ppcboot/cpu/ppc4xx/405gp_ pci.c?revision=1.1view=markup I do not see that this file has anything in common with the current 4xx_pci.c code! One could say that setting up the PMM registes looks a little as is comes from the old IBM code, but can writing zeros into some registers really stop us from cleaning up this license issue? Yes, those files don't have much in common any more. Only some comments (which could be removed or rewritten) and and the sequence of some register initialisation. But again, IANAL and I don't really know if we can remove the IBM header with such a history. It seems nobody is a lawyer! So I think this issue cannot be solved by the U-boot community and therefore the only way seems to be the removal of this file in August as stated in the feature-removal plan. I will not start cleaning up this file as it seems to be a waste of time when the file will be removed in August. Stefan, how do you plan to reach the August goal? If so, I see no way to reach the GPL cleanup goal. I will submit a cleanup patch for the 4xx_pci.c when we are common in this point. I also request Ack-bys at least from you and Stefan on my patch to not have one foot in the grave :-) Heh, don't be such a coward! No risk, no fun! ;) When I go through my posting I must admit that I never said IANAL. But many others did. Perhaps we can setup an open source developer jail where everything is allowed because they cannot put you deeper in jail :-) Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Can't start Linux if U-Boot built with CONFIG_WATCHDOG
Hello all,
I've added watchdog support based on U-Boot (git) for the m68k coldfire
mcf54455evb platform. I've fed the patch to the maintainer to help in
development.
However, I am unable to start my m68k w/MMU coldfire Linux kernel from
U-Boot if U-Boot is built with CONFIG_WATCHDOG regardless if the
watchdog_enable(), watchdog_reset() and watchdog_disable() functions
touch hardware or not.
I initially thought this was a problem with enabling the watchdog
somehow (ie when Linux started, some hw configuration in the device was
getting upset or corrupted etc resulting in the failure), but when I
commented out the code from the above functions that actually accesses
the hw (ie to enable, kick and disable the watchdog timer hw block),
Linux is still unable to start.
In fact, I don't think Linux actually gets started! That's the problem.
If I rebuild the same U-Boot code base with CONFIG_WATCHDOG undefined,
Linux can start just fine. As far as I can tell, there are no functional
differences in building U-Boot with or without CONFIG_WATCHDOG enabled
when the functions above are stubs and do absolutely nothing at all.
If I build U-Boot with debug, what I see is as follows:
## Transferring control to Linux (at address 4002) ...
BIV
...and then the board is dead. I occasionally see something like the
following from U-Boot:
*** Unexpected exception ***
Vector Number: 4 Format: 04 Fault Status: 0
PC: 4fdbfdc8 SR: 2700 SP: 4fd72a64
D0: 0004 D1: 03f9 D2: 4fdb4202 D3: 004fa3da
D4: D5: 4fdc7c8c D6: 122c0034 D7: 4fd82f76
A0: 4033cb98 A1: 4025aa39 A2: 4002 A3: 4fdbfdc8
A4: A5: 4fdc5800 A6: 4fd72afb
*** Please Reset Board! ***
The 'BIV' is relevant because in my 2.6.29 kernel src
arch/m68k/include/asm/bootinfo_mm.h, BOOTINFOV_MAGIC is defined to be
0x4249561A which is BIV^Z. This ascii text is located in the kernel
image header info:
From arch/m68k/coldfire/head.S:
.section .text.head,ax
ENTRY(_stext)
bras1f /* Jump over bootinfo version numbers */
.long BOOTINFOV_MAGIC
.long 0
And from U-Boot itself:
- md ${loadaddr}
4001: 27051956 97342d7d 4a54afd5 0030'..V.4-}JT...0..
40010010: 4002 4002 8a006fc1 050c0200@@.o.
40010020: 4c696e75 78204b65 726e656c 20496d61Linux Kernel Ima
40010030: 6765 ge..
40010040: 60084249 561a 4ef9 40304000`.biv...@0@.
I suspect that the failure of starting Linux is caused by some mismatch
in data structures (or versions there of) shared/copied between Linux
and U-Boot and that this data has somehow changed when U-Boot is built
with CONFIG_WATCHDOG #defined. However, I can't find any evidence of
this in the U-Boot code base. The bras instruction above must be key and
I suspect that this is the area causing the problem.
Can anybody offer any advice / explanation of what exactly could be
going on and why? I wouldn't have expected that defining CONFIG_WATCHDOG
would change anything as fundamental as this.
Apologies for the cross-post (U-Boot and m68k kernel dev) but I hope to
get opinions/feedback/help from both communities.
Any assistance very much appreciated indeed.
Many thanks,
-- Matt
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] Added support for splash screen positioning
Hi Matthias Matthias Fuchs matthias.fu...@esd.eu schrieb am 06.07.2009 um 11:23: Hi, I posted a similiar patch a long time ago: http://lists.denx.de/pipermail/u-boot/2007-July/022741.html Missed that. Sorry. If we can use a powerful splashimage variable, I would vote for my patch and check it on top of git. I would also vote for that one, but... I can understand Wolfgang's objection but please keep the amount of variables for positioning on a reasonable level. Just one for the stuff behind the address (see my proposed format) would be ok for me. I would also prefer the additional variable. I would propose splashpos=x,y where x and y could be: l - Left m - Center (not c because of clash with hex numbers) r - Right number - Exact positioning If you don't have the time to implement this I could add this to my patch (which also adds this to the lcd code). Matthias Amtsgericht Freiburg HRA 602707 Ust. ID-Nr.: DE232464428 Geschäftsführer: Dipl. Ing. (FH) Martin Graf Dipl. Ing. (FH) David Graf Dipl. Inf. Fabian Graf Komplementärin: GRAF-SYTECO Verwaltungs-GmbH Amtsgericht Freiburg HRB 602868 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
On Thursday 09 July 2009 11:24:39 Matthias Fuchs wrote: Yes, those files don't have much in common any more. Only some comments (which could be removed or rewritten) and and the sequence of some register initialisation. But again, IANAL and I don't really know if we can remove the IBM header with such a history. It seems nobody is a lawyer! So I think this issue cannot be solved by the U-boot community and therefore the only way seems to be the removal of this file in August as stated in the feature-removal plan. I will not start cleaning up this file as it seems to be a waste of time when the file will be removed in August. Stefan, how do you plan to reach the August goal? I just realised in this thread that this IBM license is incompatible with the GPL. So it's new to me. And even worse, it doesn't only affect the PCI code but also the 4xx EMAC code. So if we have to really remove all the code with this IBM header, 4xx support will be in really bad shape. :-( So it's even more important to know, if such files as this 4xx PCI code, which has nearly nothing in common with the original IBM code, can move to GPL. Not sure how to solve this issue though. Perhaps we should ask somebody at IBM? Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] powerpc: updates for the keymile boards
following patch series makes a lot of updates for the existing keymile boards kmeter1, kmsupx4, mgcoge and mgsuvd. Also add nand support and an i2c deblock function for the kmeter1 board. The following changes since commit a350d0d37d7c113afbd9b0d2cf60ac542007f9e6: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians Heiko Schocher (3): powerpc: updates for the keymile boards i2c, mpc83xx: add CONFIG_SYS_I2C_INIT_BOARD for fsl_i2c 83xx, kmeter1: added NAND support board/keymile/common/common.c| 55 +- board/keymile/common/common.h| 10 +++ board/keymile/km8xx/km8xx.c | 42 +++ board/keymile/kmeter1/Makefile |2 +- board/keymile/kmeter1/kmeter1.c | 51 + board/keymile/kmeter1/nand.c | 153 ++ board/keymile/mgcoge/mgcoge.c| 67 - drivers/i2c/fsl_i2c.c|6 ++ include/configs/keymile-common.h | 17 - include/configs/km8xx.h |2 - include/configs/kmeter1.h| 13 ++-- include/configs/mgcoge.h | 24 +++--- include/i2c.h|2 + 13 files changed, 387 insertions(+), 57 deletions(-) create mode 100644 board/keymile/kmeter1/nand.c -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] powerpc: updates for the keymile boards
- CONFIG_SYS_MAX_I2C_BUS changed to 1
We use only one I2C hardwarecontroller on this boards, so
change the CONFIG_SYS_MAX_I2C_BUS to 1.
- common: dont print errormsg if second IVM Block lacks.
- 82xx, mgcoge: fix double mtdpart entry in environment
- 82xx, mgcoge: activate on second Flash the second bank.
- common: CONFIG_ENV_SIZE 0x4000 for all keymile boards
- common: Change malloc size to 1MByte for all Keymile boards
We need a bigger malloc area for the environment support (128k)
on some Keymile boards (kmeter1) and the upcoming UBI support.
Change it to 1MB for all Keymile boards to be on the save side.
Also define CONFIG_SYS_64BIT_VSPRINTF which is needed for
UBI/UBIFS support.
- Add UBI support to all Keymile boards
- change manner of writing /localbus/ranges node
instead of writting the complete /localbus/ranges node
before booting Linux, only update the ranges entries
which gets dynamical detected (size of flashes).
This is needed, because keymile adds in the DTS
/localbus/ranges node entries, which u-boot must
not overwrite/delete.
- kmeter, mgcoge: define 2 seperate regions needed for the Intel P30 chips
The Intel P30 chip has 2 non-identical chips on
one die, so we need to define 2 seperate regions
that are scanned by physmap_of independantly.
- kmeter1: Add MTD concat support to Keymile boards
- 82xx, mgcoge: add unlock=yes to default environment
- added CONFIG_MTD_DEVICE to get in sync with mainline code
Signed-off-by: Heiko Schocher h...@denx.de
Signed-off-by: Stefan Roese s...@denx.de
---
board/keymile/common/common.c| 35 ++--
board/keymile/common/common.h| 10 ++
board/keymile/km8xx/km8xx.c | 42
board/keymile/kmeter1/kmeter1.c | 51 +
board/keymile/mgcoge/mgcoge.c| 67 +++---
include/configs/keymile-common.h | 17 +-
include/configs/km8xx.h |2 -
include/configs/kmeter1.h|7 +---
include/configs/mgcoge.h | 24 +++--
include/i2c.h|2 +
10 files changed, 202 insertions(+), 55 deletions(-)
diff --git a/board/keymile/common/common.c b/board/keymile/common/common.c
index b2bd7fd..2594623 100644
--- a/board/keymile/common/common.c
+++ b/board/keymile/common/common.c
@@ -203,8 +203,9 @@ static int ivm_check_crc (unsigned char *buf, int block)
crceeprom = (buf[CONFIG_SYS_IVM_EEPROM_PAGE_LEN - 1] + \
buf[CONFIG_SYS_IVM_EEPROM_PAGE_LEN - 2] * 256);
if (crc != crceeprom) {
- printf (Error CRC Block: %d EEprom: calculated: %lx EEprom:
%lx\n,
- block, crc, crceeprom);
+ if (block == 0)
+ printf (Error CRC Block: %d EEprom: calculated: \
+ %lx EEprom: %lx\n, block, crc, crceeprom);
return -1;
}
return 0;
@@ -287,7 +288,7 @@ int ivm_analyze_eeprom (unsigned char *buf, int len)
GET_STRING(IVM_CustomerProductID, IVM_POS_CUSTOMER_PROD_ID, 32)
if (ivm_check_crc (buf[CONFIG_SYS_IVM_EEPROM_PAGE_LEN * 2], 2) != 0)
- return -2;
+ return 0;
ivm_analyze_block2 (buf[CONFIG_SYS_IVM_EEPROM_PAGE_LEN * 2],
CONFIG_SYS_IVM_EEPROM_PAGE_LEN);
return 0;
@@ -527,6 +528,34 @@ int fdt_set_node_and_value (void *blob,
}
return ret;
}
+int fdt_get_node_and_value (void *blob,
+ char *nodename,
+ char *propname,
+ void **var)
+{
+ int len;
+ int nodeoffset = 0;
+
+ nodeoffset = fdt_path_offset (blob, nodename);
+ if (nodeoffset = 0) {
+ *var = (void *)fdt_getprop (blob, nodeoffset, propname, len);
+ if (len == 0) {
+ /* no value */
+ printf (%s no value\n, __FUNCTION__);
+ return -1;
+ } else if (len 0) {
+ return len;
+ } else {
+ printf (libfdt fdt_getprop(): %s\n,
+ fdt_strerror(len));
+ return -2;
+ }
+ } else {
+ printf(%s: cannot find %s node err:%s\n, __FUNCTION__,
+ nodename, fdt_strerror (nodeoffset));
+ return -3;
+ }
+}
#endif
int ethernet_present (void)
diff --git a/board/keymile/common/common.h b/board/keymile/common/common.h
index d3d6814..a38c727 100644
--- a/board/keymile/common/common.h
+++ b/board/keymile/common/common.h
@@ -17,4 +17,14 @@ int ivm_read_eeprom (void);
#ifdef CONFIG_KEYMILE_HDLC_ENET
int keymile_hdlc_enet_initialize (bd_t *bis);
#endif
+
+int fdt_set_node_and_value (void *blob,
+ char *nodename,
+ char *regname,
+
[U-Boot] [PATCH 2/3] i2c, mpc83xx: add CONFIG_SYS_I2C_INIT_BOARD for fsl_i2c
This patch adds the possibility to call a board specific
i2c bus reset routine for the fsl_i2c bus driver, and adds
this option for the keymile kmeter1 board.
The deblock sequence for this board is implemented and
tested in the following way:
CR = 0x20 (release SDA and SCL pin)
CR = 0xa0 (start read)
dummy read
dummy read
if 2. dummy read == 0x00
3. dummy read
CR = 0x80 (SDA and SCL now 1 SR = 0x86)
CR = 0x00 (Modul reset SR=0x81)
CR = 0x80 (SDA and SCL = 1, SR = 0x81)
Signed-off-by: Heiko Schocher h...@denx.de
---
board/keymile/common/common.c | 20
drivers/i2c/fsl_i2c.c |6 ++
include/configs/kmeter1.h |1 -
3 files changed, 26 insertions(+), 1 deletions(-)
diff --git a/board/keymile/common/common.c b/board/keymile/common/common.c
index 2594623..ec27bda 100644
--- a/board/keymile/common/common.c
+++ b/board/keymile/common/common.c
@@ -424,6 +424,7 @@ static int get_scl (void)
#endif
+#if !defined(CONFIG_KMETER1)
static void writeStartSeq (void)
{
set_sda (1);
@@ -474,6 +475,7 @@ static int i2c_make_abort (void)
get_sda ();
return ret;
}
+#endif
/**
* i2c_init_board - reset i2c bus. When the board is powercycled during a
@@ -481,6 +483,23 @@ static int i2c_make_abort (void)
*/
void i2c_init_board(void)
{
+#if defined(CONFIG_KMETER1)
+ struct fsl_i2c *dev;
+ dev = (struct fsl_i2c *) (CONFIG_SYS_IMMR + CONFIG_SYS_I2C_OFFSET);
+ uchar dummy;
+
+ out_8 (dev-cr, (I2C_CR_MSTA));
+ out_8 (dev-cr, (I2C_CR_MEN | I2C_CR_MSTA));
+ dummy = in_8(dev-dr);
+ dummy = in_8(dev-dr);
+ if (dummy != 0xff) {
+ dummy = in_8(dev-dr);
+ }
+ out_8 (dev-cr, (I2C_CR_MEN));
+ out_8 (dev-cr, 0x00);
+ out_8 (dev-cr, (I2C_CR_MEN));
+
+#else
#if defined(CONFIG_HARD_I2C)
volatile immap_t *immap = (immap_t *)CONFIG_SYS_IMMR ;
volatile i2c8260_t *i2c = (i2c8260_t *)immap-im_i2c;
@@ -500,6 +519,7 @@ void i2c_init_board(void)
/* Set the PortPins back to use for I2C */
setports (0);
#endif
+#endif
}
#endif
#endif
diff --git a/drivers/i2c/fsl_i2c.c b/drivers/i2c/fsl_i2c.c
index 6ab7d3d..ce0f301 100644
--- a/drivers/i2c/fsl_i2c.c
+++ b/drivers/i2c/fsl_i2c.c
@@ -178,6 +178,12 @@ i2c_init(int speed, int slaveadd)
struct fsl_i2c *dev;
unsigned int temp;
+#ifdef CONFIG_SYS_I2C_INIT_BOARD
+ /* call board specific i2c bus reset routine before accessing the */
+ /* environment, which might be in a chip on that bus. For details */
+ /* about this problem see doc/I2C_Edge_Conditions. */
+ i2c_init_board();
+#endif
dev = (struct fsl_i2c *) (CONFIG_SYS_IMMR + CONFIG_SYS_I2C_OFFSET);
writeb(0, dev-cr);/* stop I2C controller */
diff --git a/include/configs/kmeter1.h b/include/configs/kmeter1.h
index 1735683..811ba88 100644
--- a/include/configs/kmeter1.h
+++ b/include/configs/kmeter1.h
@@ -33,7 +33,6 @@
/* include common defines/options for all Keymile boards */
#include keymile-common.h
-#undef CONFIG_SYS_I2C_INIT_BOARD
#define CONFIG_MISC_INIT_R 1
/*
* System Clock Setup
--
1.6.0.6
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] 83xx, kmeter1: added NAND support
Signed-off-by: Heiko Schocher h...@denx.de
---
board/keymile/kmeter1/Makefile |2 +-
board/keymile/kmeter1/nand.c | 153
include/configs/kmeter1.h |5 ++
3 files changed, 159 insertions(+), 1 deletions(-)
create mode 100644 board/keymile/kmeter1/nand.c
diff --git a/board/keymile/kmeter1/Makefile b/board/keymile/kmeter1/Makefile
index 12a1518..0eaa234 100644
--- a/board/keymile/kmeter1/Makefile
+++ b/board/keymile/kmeter1/Makefile
@@ -28,7 +28,7 @@ endif
LIB= $(obj)lib$(BOARD).a
-COBJS += $(BOARD).o ../common/common.o
+COBJS += $(BOARD).o ../common/common.o nand.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/keymile/kmeter1/nand.c b/board/keymile/kmeter1/nand.c
new file mode 100644
index 000..0675b53
--- /dev/null
+++ b/board/keymile/kmeter1/nand.c
@@ -0,0 +1,153 @@
+/*
+ * (C) Copyright 2009
+ * Heiko Schocher, DENX Software Engineering, h...@denx.de
+ *
+ * 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 common.h
+
+#if defined(CONFIG_CMD_NAND)
+
+#include nand.h
+#include asm/io.h
+
+#define CONFIG_NAND_MODE_REG (CONFIG_SYS_NAND_BASE + 0x2)
+#define CONFIG_NAND_DATA_REG (CONFIG_SYS_NAND_BASE + 0x3)
+
+#define read_mode()in_8((volatile unsigned char __iomem *) \
+ CONFIG_NAND_MODE_REG)
+#define write_mode(val)out_8((volatile unsigned char __iomem *) \
+ CONFIG_NAND_MODE_REG, val)
+#define read_data()in_8((volatile unsigned char __iomem *) \
+ CONFIG_NAND_DATA_REG)
+#define write_data(val)out_8((volatile unsigned char __iomem *) \
+ CONFIG_NAND_DATA_REG, val)
+
+#define KPN_RDY2 (1 7)
+#define KPN_RDY1 (1 6)
+#define KPN_WPN(1 4)
+#define KPN_CE2N (1 3)
+#define KPN_CE1N (1 2)
+#define KPN_ALE(1 1)
+#define KPN_CLE(1 0)
+
+#define KPN_DEFAULT_CHIP_DELAY 50
+
+static int kpn_chip_ready(void)
+{
+ if (read_mode() KPN_RDY1)
+ return 1;
+
+ return 0;
+}
+
+static void kpn_wait_rdy(void)
+{
+ int cnt = 100;
+
+ while (--cnt !kpn_chip_ready())
+ udelay(1);
+
+ if (!cnt)
+ printf (timeout while waiting for RDY\n);
+}
+
+static void kpn_nand_hwcontrol(struct mtd_info *mtd, int cmd, unsigned int
ctrl)
+{
+ u8 reg_val = read_mode();
+
+ if (ctrl NAND_CTRL_CHANGE) {
+ if ( ctrl NAND_NCE)
+ reg_val = reg_val ~KPN_CE1N;
+ else
+ reg_val = reg_val | KPN_CE1N;
+ write_mode(reg_val);
+ }
+ if (cmd == NAND_CMD_NONE)
+ return;
+
+ reg_val = reg_val ~(KPN_ALE + KPN_CLE);
+ if (ctrl NAND_CLE)
+ reg_val = reg_val | KPN_CLE;
+ if (ctrl NAND_ALE)
+ reg_val = reg_val | KPN_ALE;
+
+ /* select register */
+ write_mode(reg_val);
+
+ /* write cmd */
+ write_data(cmd);
+
+ /* deselect register */
+ reg_val = reg_val ~(KPN_ALE + KPN_CLE);
+ write_mode(reg_val);
+
+ /* wait until flash is ready */
+ kpn_wait_rdy();
+}
+
+static u_char kpn_nand_read_byte(struct mtd_info *mtd)
+{
+ return read_data();
+}
+
+static void kpn_nand_write_buf(struct mtd_info *mtd, const u_char *buf, int
len)
+{
+ int i;
+
+ for (i = 0; i len; i++) {
+ write_data(buf[i]);
+ kpn_wait_rdy();
+ }
+}
+
+static void kpn_nand_read_buf(struct mtd_info *mtd, u_char *buf, int len)
+{
+ int i;
+
+ for (i = 0; i len; i++) {
+ buf[i] = read_data();
+ }
+}
+
+static int kpn_nand_dev_ready(struct mtd_info *mtd)
+{
+ kpn_wait_rdy();
+
+ return 1;
+}
+
+int board_nand_init(struct nand_chip *nand)
+{
+ nand-ecc.mode = NAND_ECC_SOFT;
+
+ /* Reference hardware control function */
+ nand-cmd_ctrl = kpn_nand_hwcontrol;
+ nand-read_byte = kpn_nand_read_byte;
+ nand-write_buf = kpn_nand_write_buf;
+ nand-read_buf =
Re: [U-Boot] Please pull u-boot-ubi
Dear Stefan Roese, In message 200907091024.42759...@denx.de you wrote: Yes. And I already acked it on the list. Please note that I'm only the co- custodian for the UBI repository. We have no UBIFS custodian. So it needs to get into mainline via Wolfgang. I see UBIFS and UBI as one topic. Please run it through your UBI repo. 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 Experience is what causes a person to make new mistakes instead of old ones. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] asm-generic: Consolidate errno.h to asm-generic/errno.h
Michal Simek wrote: Hi Custodians, Do you have any problem with this asm-generic/errno.h patch? Patch is available in u-boot-microblaze.git asm-generic branch. Looks good to me too. Haavard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
Dear Stefan Roese, In message 200907091151.51598...@denx.de you wrote: So it's even more important to know, if such files as this 4xx PCI code, which has nearly nothing in common with the original IBM code, can move to GPL. Not sure how to solve this issue though. Perhaps we should ask somebody at IBM? Try it, but don;t expect answers before next year ;-) BTW - what's the situation with the corresponding Linux headers? 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 Murder is contrary to the laws of man and God. -- M-5 Computer, The Ultimate Computer, stardate 4731.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Reset problem in IROM mode
Hi all, I am using samsung 2416 and 2451 boards. in 2416 board in IROM mode If I do watchdog reset (by using command RESET or directly writing in watchdog registers)the board will reset and comes to boot prompt .but in my 2451 samsung board the if I do watchdog reset (by using command RESET or directly writing in watchdog registers). board will hang it will not restart. but power on reset will work fine in both modes. can anybody give any idea how the bootloader will work in IROM mode and how the stepping stone code and reset vector jump instruction will work in this mode . Regards, Kishore. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Reset problem in IROM mode
Hi all, adding to my qustion , Iam using U-boot and 1.1.6 version for ARM9 board. On Thu, Jul 9, 2009 at 3:36 PM, kishore choudhari kkchoud...@gmail.comwrote: Hi all, I am using samsung 2416 and 2451 boards. in 2416 board in IROM mode If I do watchdog reset (by using command RESET or directly writing in watchdog registers)the board will reset and comes to boot prompt .but in my 2451 samsung board the if I do watchdog reset (by using command RESET or directly writing in watchdog registers). board will hang it will not restart. but power on reset will work fine in both modes. can anybody give any idea how the bootloader will work in IROM mode and how the stepping stone code and reset vector jump instruction will work in this mode . Regards, Kishore. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] 83xx, kmeter1: added NAND support
Hi Heiko, On Thursday 09 July 2009 12:04:41 Heiko Schocher wrote: Signed-off-by: Heiko Schocher h...@denx.de --- board/keymile/kmeter1/Makefile |2 +- board/keymile/kmeter1/nand.c I suggest to move this NAND driver into the drivers/mtd/nand directory (e.g. drivers/mtd/nand/kmeter1_nand.c). We try to collect all drivers here. This makes maintenance easier. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ubi
On Thursday 09 July 2009 12:05:31 Wolfgang Denk wrote: Yes. And I already acked it on the list. Please note that I'm only the co- custodian for the UBI repository. We have no UBIFS custodian. So it needs to get into mainline via Wolfgang. I see UBIFS and UBI as one topic. Please run it through your UBI repo. Thanks. So I'm promoted from UBI co-custodian to UBIFS custodian? ;) OK, I'll try to take care of UBIFS related patches for now. Will send an updated ubi/ubifs pull request soon. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
On Thursday 09 July 2009 12:10:10 Wolfgang Denk wrote: So it's even more important to know, if such files as this 4xx PCI code, which has nearly nothing in common with the original IBM code, can move to GPL. Not sure how to solve this issue though. Perhaps we should ask somebody at IBM? Try it, but don;t expect answers before next year ;-) BTW - what's the situation with the corresponding Linux headers? The Linux code is completely different here. I based my 4xx code in my first U-Boot port on the IBM PIBS code and not Linux. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH RESEND] Added support for splash screen positioning
On Thursday 09 July 2009 11:45, Matthias Weisser wrote: Hi Matthias Matthias Fuchs matthias.fu...@esd.eu schrieb am 06.07.2009 um 11:23: Hi, I posted a similiar patch a long time ago: http://lists.denx.de/pipermail/u-boot/2007-July/022741.html Missed that. Sorry. If we can use a powerful splashimage variable, I would vote for my patch and check it on top of git. I would also vote for that one, but... Cool. I can understand Wolfgang's objection but please keep the amount of variables for positioning on a reasonable level. Just one for the stuff behind the address (see my proposed format) would be ok for me. I would also prefer the additional variable. I would propose splashpos=x,y I thought about that name also :-) where x and y could be: l - Left m - Center (not c because of clash with hex numbers) Good idea. r - Right Don't forget t (top) and b (bottom). number - Exact positioning What about [-]number? Could be used to position from the opposite side. With this syntax we even do not need l/r/t/b at all. E.g.: splashpos=m,-20 # x'centered and 20 pixel from bottom splashpos=-0,-0 # rigth, bottom screen corner Just an idea :-) If you don't have the time to implement this I could add this to my patch (which also adds this to the lcd code). Yes please. I will do some testing on my board. Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2 v6] Make libgcc inclusion from common Makefile overridable by platform config file
This patch allows to override the libgcc Makefile inclusion from the toplevel Makefile by the arch config.mk files. This is in preparation for the ARM architecture to move away from including libgcc functions and only using self-contained U-Boot functions as done in Linux. Currently all the ARM boards that use NAND are broken due to the addition of 64 Bit device size support. In the past we have seen similar problems with different tool chains due to EABI and FPU for example. With this patch and this one: ARM: Don't include libgcc anymore we move away from all these problems on ARM since we don't include any functions from libgcc anymore. Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com Acked-by: Mike Frysinger vap...@gentoo.org --- Makefile |3 ++- api_examples/Makefile|4 +--- board/netstar/Makefile |4 +--- board/sl8245/config.mk |1 - board/trab/Makefile |2 -- board/voiceblue/Makefile |4 +--- examples/Makefile|2 +- 7 files changed, 6 insertions(+), 14 deletions(-) diff --git a/Makefile b/Makefile index 2a06440..e2a61fb 100644 --- a/Makefile +++ b/Makefile @@ -288,7 +288,8 @@ LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).a LIBBOARD := $(addprefix $(obj),$(LIBBOARD)) # Add GCC lib -PLATFORM_LIBS += -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc +PLATFORM_LIBGCC ?= -L $(shell dirname `$(CC) $(CFLAGS) -print-libgcc-file-name`) -lgcc +PLATFORM_LIBS += $(PLATFORM_LIBGCC) ifeq ($(CONFIG_NAND_U_BOOT),y) NAND_SPL = nand_spl diff --git a/api_examples/Makefile b/api_examples/Makefile index 4c01437..4bfa7e6 100644 --- a/api_examples/Makefile +++ b/api_examples/Makefile @@ -56,8 +56,6 @@ OBJS := $(addprefix $(obj),$(COBJS)) ELF:= $(addprefix $(obj),$(ELF)) BIN:= $(addprefix $(obj),$(BIN)) -gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`) - CPPFLAGS += -I.. all: $(obj).depend $(OBJS) $(LIB) $(ELF) $(BIN) @@ -70,7 +68,7 @@ $(ELF): $(obj)%: $(obj)%.o $(LIB) $(LD) $(obj)crt0.o -Ttext $(LOAD_ADDR) \ -o $@ $ $(LIB) \ - -L$(gcclibdir) -lgcc + $(PLATFORM_LIBGCC) $(BIN): $(obj)%.bin: $(obj)% diff --git a/board/netstar/Makefile b/board/netstar/Makefile index 91bac38..a52ded4 100644 --- a/board/netstar/Makefile +++ b/board/netstar/Makefile @@ -36,8 +36,6 @@ SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c \ OBJS := $(addprefix $(obj),$(COBJS)) SOBJS := $(addprefix $(obj),$(SOBJS)) -gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`) - LOAD_ADDR = 0x1040 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds lnk = $(if $(obj),$(obj),.) @@ -55,7 +53,7 @@ $(obj)eeprom.srec:$(obj)eeprom.o $(obj)eeprom_start.o -o $(:.o=) -e eeprom eeprom.o eeprom_start.o \ -L$(obj)../../examples -lstubs \ -L$(obj)../../lib_generic -lgeneric \ - -L$(gcclibdir) -lgcc + $(PLATFORM_LIBGCC) $(OBJCOPY) -O srec $(:.o=) $@ $(obj)eeprom.bin: $(obj)eeprom.srec diff --git a/board/sl8245/config.mk b/board/sl8245/config.mk index 022512b..299fc6c 100644 --- a/board/sl8245/config.mk +++ b/board/sl8245/config.mk @@ -28,4 +28,3 @@ TEXT_BASE = 0xFFF0 PLATFORM_CPPFLAGS += -DTEXT_BASE=$(TEXT_BASE) -PLATFORM_LIBS += $(shell $(CC) -print-libgcc-file-name) diff --git a/board/trab/Makefile b/board/trab/Makefile index 30e5fbb..a3661c4 100644 --- a/board/trab/Makefile +++ b/board/trab/Makefile @@ -36,8 +36,6 @@ SOBJS := $(addprefix $(obj),$(SOBJS)) OBJS_FKT := $(addprefix $(obj),$(COBJS_FKT)) -gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`) - LOAD_ADDR = 0xc10 # diff --git a/board/voiceblue/Makefile b/board/voiceblue/Makefile index e7c1cbb..369dc0b 100644 --- a/board/voiceblue/Makefile +++ b/board/voiceblue/Makefile @@ -33,8 +33,6 @@ SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c) eeprom.c eeprom_start.S OBJS := $(addprefix $(obj),$(COBJS)) SOBJS := $(addprefix $(obj),$(SOBJS)) -gcclibdir := $(shell dirname `$(CC) -print-libgcc-file-name`) - LOAD_ADDR = 0x1040 LDSCRIPT = $(TOPDIR)/board/$(BOARDDIR)/eeprom.lds lnk = $(if $(obj),$(obj),.) @@ -49,7 +47,7 @@ $(obj)eeprom.srec:$(obj)eeprom.o $(obj)eeprom_start.o -o $(:.o=) -e eeprom eeprom.o eeprom_start.o \ -L$(obj)../../examples -lstubs \ -L$(obj)../../lib_generic -lgeneric \ - -L$(gcclibdir) -lgcc + $(PLATFORM_LIBGCC) $(OBJCOPY) -O srec $(:.o=) $@ $(obj)eeprom.bin: $(obj)eeprom.srec diff --git a/examples/Makefile b/examples/Makefile index dbcfa92..5bd13f1 100644 --- a/examples/Makefile +++ b/examples/Makefile @@ -178,7 +178,7 @@ $(ELF): $(obj)%: $(obj)%.o $(LIB) $(LD) -g $(EX_LDFLAGS) -Ttext $(LOAD_ADDR) \ -o $@ -e
[U-Boot] [GIT PULL] Please pull asm-generic
Hi Wolfgang, Please pull my asm-generic branch. There is only one patch which create asm-generic folder with errno.h. I have got ack from ppc40x, blackfin, arm, coldfire and avr custodians. Thanks, Michal The following changes since commit 59869ca72df8bc4e4ffa9dd17cb6673bbe010272: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-video are available in the git repository at: git://git.denx.de/u-boot-microblaze.git asm-generic Michal Simek (1): asm-generic: Consolidate errno.h to asm-generic/errno.h board/Marvell/db64360/mv_eth.h |3 +- board/Marvell/db64460/mv_eth.h |2 +- board/prodrive/p3mx/mv_eth.h |2 +- include/asm-arm/errno.h| 139 +- include/asm-avr32/errno.h | 133 + include/asm-blackfin/errno.h | 157 +--- .../ppc_error_no.h = include/asm-generic/errno.h | 47 +++ include/asm-m68k/errno.h | 139 +- include/asm-microblaze/errno.h |1 + include/asm-ppc/errno.h| 139 +- include/asm-sh/errno.h | 157 +--- include/asm-sparc/errno.h | 163 +--- 12 files changed, 30 insertions(+), 1052 deletions(-) rename board/Marvell/common/ppc_error_no.h = include/asm-generic/errno.h (87%) create mode 100644 include/asm-microblaze/errno.h -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8]: Command improvements for ubifs
On Tuesday 07 July 2009 16:01:02 Simon Kagstrom wrote: Check that an argument is passed to ubifsmount and that addresses and sizes are actually numbers for ubifsload. Also improve the instructions a bit. Applied to u-boot-ubi. Thanks. Simon, one request for your next patches. Please add a keyword to the patch subject, e.g.: ARM: Add unaligned.h or UBI: Handle VID header offset in ubi part command Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-ubi (v2)
The following changes since commit a350d0d37d7c113afbd9b0d2cf60ac542007f9e6: Wolfgang Denk (1): Merge branch 'master' of /home/wd/git/u-boot/custodians are available in the git repository at: git://www.denx.de/git/u-boot-ubi.git master Simon Kagstrom (2): Handle VID header offset in ubi part command Command improvements for ubifs common/cmd_ubi.c | 21 - common/cmd_ubifs.c | 26 +- 2 files changed, 37 insertions(+), 10 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-v2 and GPL license version?
Hi Jerry, Kumar Gala wrote: Sascha, You seem to be the person acting as maintainer of u-boot-v2. Do you have any input if u-boot-v2 would stay with GPLv2 or move to GPLv3? - k U-Boot v2 is the usage case I had in mind in my question: Would U-Boot be willing to have as much GPLv2++ (GPLv3) as possible, and supporting a run time plug-in system to accommodate GPLv2-only modules? http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/61801/focus=62886 RMS' opinion was that this approach could be taken WRT GPLv3 of the U-Boot core and allow GPLv2 plug-ins, preferably via an explicit exception. He was also OK with the concept from an ethical point of view. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/61801/focus=62920 Don't forget that RMS also noted that this case also needs the exception on the GPLv2 only code to be used in conjunction with GPLv3. If we took that approach, it would probably allow TiVoisation - maybe we could craft the GPLv3 s/w to prevent add-on modules from TiVoing the whole, but I think that would be difficult... if GPLv2 modules are added and initialized at start up time, it would be pretty hard to prevent a TiVo module from locking down the whole. Since the primary point of going to GPLv3 is anti-TiVoism and the primary (only?) argument against going to GPLv3 is to allow TiVoism, from that point of view the GPLv3/GPLv2-plugin combination is a failure.[1] Indeed. Wolfgang's last word was pretty adamant about taking U-Boot to GPLv3. I see the U-Boot v2 GPLv3/GPLv2-plugin technique as a way to take the core to GPLv3 without needlessly re-writing the parts we've borrowed from linux (in fact, it encourages borrowing from linux, which is a Good Thing[tm]). Asking Linux authors to license their code as GPLv2+ is also an option. Incidentally drivers/rtc-bfin.c is one example of GPL-2 or later in the Linux tree. Cheers Detlev -- The only use I can find for vi is editing the emacs sources while porting them to a new machine. -- Larry Campbell -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-v2 and GPL license version?
Detlev Zundel wrote: Hi Jerry, Kumar Gala wrote: Sascha, You seem to be the person acting as maintainer of u-boot-v2. Do you have any input if u-boot-v2 would stay with GPLv2 or move to GPLv3? - k U-Boot v2 is the usage case I had in mind in my question: Would U-Boot be willing to have as much GPLv2++ (GPLv3) as possible, and supporting a run time plug-in system to accommodate GPLv2-only modules? http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/61801/focus=62886 RMS' opinion was that this approach could be taken WRT GPLv3 of the U-Boot core and allow GPLv2 plug-ins, preferably via an explicit exception. He was also OK with the concept from an ethical point of view. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/61801/focus=62920 Don't forget that RMS also noted that this case also needs the exception on the GPLv2 only code to be used in conjunction with GPLv3. Oops, I /had/ forgotten that. That puts a pretty big pothole in that road. :-/ Best case, we would still have to contact all the authors of GPLv2 drivers and convince them to change their copyright licensing. Worst case, some wouldn't agree to the license change and we would have to rewrite their code, resulting in no net gain. Cheers Detlev Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] pxa: add clock for system bus 2 arbiter
Hello Jean-Christophe, 2009/7/9 Daniel Mack dan...@caiaq.de: ping? On Tue, Jun 23, 2009 at 05:30:04PM +0200, Daniel Mack wrote: From: Daniel Mack dan...@caiaq.de To: u-boot@lists.denx.de Cc: Daniel Mack dan...@caiaq.de Subject: [PATCH 1/2] pxa: add clock for system bus 2 arbiter Date: Tue, 23 Jun 2009 17:30:04 +0200 Message-Id: 1245771005-23299-1-git-send-email-dan...@caiaq.de X-Mailer: git-send-email 1.6.3.1 This clock is needed for systems using the USB2 device unit or the 2d graphics accelerator. Signed-off-by: Daniel Mack dan...@caiaq.de I guess this patch should go in your tree. Can you please take a look at it? Remy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/3] DMA ECC update
Ira W. Snyder wrote:
On Wed, Jul 08, 2009 at 05:59:33PM -0500, Peter Tyser wrote:
On Wed, 2009-07-08 at 15:31 -0700, Ira W. Snyder wrote:
On Wed, Jul 08, 2009 at 02:28:39PM -0500, Peter Tyser wrote:
These changes bring the 83xx SDRAM ECC initialization in line
with the 85xx/86xx boards and also fixes a minor bug in fsl_dma.c.
I don't have any 83xx boards to test on, so it would be appreciated
if someone with 83xx hardware that uses ECC could give the patches
a shot.
It'd be nice if SDRAM could be initialized via the DDR controller
with CONFIG_ECC_INIT_VIA_DDRCONTROLLER on the 83xx platform too,
but I'm not going to tackle it:)
The patches also resolve the compile error Stefan brought up with
non-freescale boards with CONFIG_ECC.
Peter Tyser (3):
83xx: Default to using DMA to initialize SDRAM
83xx: Added CONFIG_MEM_INIT_VALUE for boards with ECC
fsl_dma: Fix SDRAM initial value
Something in this patch makes the ECC DDR initialization VERY slow. It
used to take 5 seconds, now it takes ~20 seconds for the memory to
initialize.
I wonder why the CPU method would be so much faster?
Other than the speed, I can confirm that it works as expected on my
8349emds-based board. I see no reason why there would be a problem on
the mpc8349emds, though I cannot test on the eval board itself. I do not
have an ECC SDRAM module.
Thanks for testing Ira. The original code had the instruction cache
enabled during SDRAM init, but it'd be pretty amazing if it gave that
much performance boost. I would have guessed that the DMA init would
have been faster even without the icache enabled.
If you have a second, could you try adding this patch on top of the
previous ones? It'd be interesting to see where the bottleneck is with
and without the icache...
It didn't apply cleanly (I'm not sure why), but I applied it (fixed the
missing semicolon).
It makes the DMA initialization normal speed again. The DMA in the for
loop takes the longest (as expected).
So yes, strangely it makes a HUGE difference. The total time is 3
seconds now. It is now faster than the previous CPU method.
Not that strangely. In fsl_dma.c, the dma_check() routine does a
busy-poll to wait for the DMA to complete:
80 static uint dma_check(void) {
81 volatile fsl_dma_t *dma = dma_base-dma[0];
82 uint status;
83
84 /* While the channel is busy, spin */
85 do {
86 status = in_dma32(dma-sr);
87 } while (status FSL_DMA_SR_CB);
With icache enabled, this is going to run out of instruction cache and
not compete with the DMA engine on the SDRAM bus. With icache disabled,
the processor is going to be fetching instructions from SDRAM *one* *by*
*one* (no bursting - quadruple whammy), competing with the DMA engine
and thus destroying the DMA engine's performance.
Aside: SDRAM performance *sucks* when address/data pipelining and
bursting is turned off or gets defeated. I ran the numbers a while back
and came to the realization that dynamic RAM access times have *not*
changed substantially in 20 years. The difference is that the memory
subsystem is now a WHOLE lot better at hiding the access delay by
pipelining additional requests to fill the time waiting for the first
access to produce its data.
IOW, cache on the CPU and the SDRAM bursting/pipelining is what is
faster, not the memory within the SDRAM itself.
[snip]
Ira
Thanks,
Peter
Thanks,
gvb
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull asm-generic
On 13:00 Thu 09 Jul , Michal Simek wrote: Hi Wolfgang, Please pull my asm-generic branch. There is only one patch which create asm-generic folder with errno.h. I have got ack from ppc40x, blackfin, arm, coldfire and avr custodians. please add this info in the commit Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [GIT PULL] Please pull asm-generic
Jean-Christophe PLAGNIOL-VILLARD wrote: On 13:00 Thu 09 Jul , Michal Simek wrote: Hi Wolfgang, Please pull my asm-generic branch. There is only one patch which create asm-generic folder with errno.h. I have got ack from ppc40x, blackfin, arm, coldfire and avr custodians. please add this info in the commit done. Michal Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
Dear Stefan Roese, In message 200907091215.59930...@denx.de you wrote: BTW - what's the situation with the corresponding Linux headers? The Linux code is completely different here. I based my 4xx code in my first U-Boot port on the IBM PIBS code and not Linux. Then maybe we can import the relevant stuff from Linux? 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 Teenagers are people who express a burning desire to be different by dressing exactly alike. There are some strings. They're just not attached. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/4] OMAP3 pandora: pin mux updates
On Thu, Jul 9, 2009 at 1:44 AM, Jean-Christophe PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote: On 00:29 Wed 08 Jul , Grazvydas Ignotas wrote: This patch series clean up and update pin mux for pandora. The update is needed for rev3 or later boards to work properly, but older boards still work after this. Grazvydas Ignotas (4): OMAP3 pandora: pin mux cleanup OMAP3 pandora: setup pin mux for pins used on rev3 boards OMAP3 pandora: setup pulls for various GPIOs OMAP3 pandora: Fix CKE1 MUX setting to allow self-refresh board/omap3/pandora/pandora.h | 86 + 1 files changed, 35 insertions(+), 51 deletions(-) what is the status of the precedent rev at the end of the patch series? Works fine except one analog controller, but I have the only rev2 board with them and don't mind about that. All other boards with analog controllers are rev3 and need these patches to work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Copyright/License text in cpu/ppc4xx/4xx_pci.c
On Thursday 09 July 2009 14:20:40 Wolfgang Denk wrote: BTW - what's the situation with the corresponding Linux headers? The Linux code is completely different here. I based my 4xx code in my first U-Boot port on the IBM PIBS code and not Linux. Then maybe we can import the relevant stuff from Linux? Sure, we could. But as you may understand this is a quite big task. And looking closer, even start.S and many 4xx related headers have this IBM header. :-( Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants
Stefan Roese wrote: On Thursday 09 July 2009 00:18:54 Jerry Van Baren wrote: Regardless of the in/out debate, we should print a warning if %ll is used but not supported. I would suggest simply printing the %lld (or whatever the format is) and pop two longs from the varargs. That would make it clear something is missing and probably wrong. I don't like printing half and discarding half: it will be erroneous with no warning if the upper half != 0. It would also have endian complications since the half you want to discard depends on the machine's endianness (not insurmountable). One possible enhancement is to special-case %ll[0-9]*[Xx] and treat it as as two %08lx formats. Hmmm, this would need correct endian handling too. :-/ All this would increase the code size for those boards not supporting the 64bit printf format. Not sure by how much, but I suggest to just fix the problem by supporting this format correctly instead of adding new code to print some warnings here. Best regards, Stefan That is what Scott is trying to do, but fixing 64bit printf causes a 2K++ increase in size to the boards that don't currently support 64bit printf (some of which are broken due to the error). Wolfgang is resisting that. Adding code to print a warning and handle the varargs properly will probably be less than 100 bytes. It looks like this is the compromise Wolfgang favors. On a related note, I am *strongly* opposed to popping a long long and only printing half of it. While odds are good that it will be correct, when the upper half is non-zero, it will be silently printing a totally erroneous value. FWIIW, in the avionics business, silently displaying an erroneous value is the unpardonable sin. http://en.wikipedia.org/wiki/Unpardonable_sin It is better to sometimes not display correct data and never display incorrect data than it is to rarely (as in 1e-9 .. 1e-12) display incorrect data. Hundreds of people have died because of this.[1] Best regards, gvb [1] Just a couple examples: http://online.wsj.com/article/SB124411224440184797.html (unknown cause, but incorrect airspeed indication is a known contributing factor) http://www.computerweekly.com/blogs/tony_collins/2009/06/youre-flying-too-fast-and-too.html http://www.computerweekly.com/Articles/2009/06/12/236425/crash-one-birgenair-flight-301.htm http://www.computerweekly.com/Articles/2009/06/12/236431/crash-two-aeroper-flight-603.htm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v2] 83xx: Default to using DMA to initializeSDRAM
Liu Dave-R63238 wrote: According to Ira, the DMA method was faster than the cpu method: It makes the DMA initialization normal speed again. The DMA in the for loop takes the longest (as expected). So yes, strangely it (enabling the icache) makes a HUGE difference. The total time is 3 seconds now. It is now faster than the previous CPU method. Logically the DMA method should be faster, and Ira's results seem to reinforce this. I don't have an 83xx board to test on, so let me know if others have different results than Ira. I did the DMA init test with the orignal DMA code. At that time The DMA method is slower than CPU method. Strange why the result is different. Instruction cache enabled/disabled is the difference - it eliminates instruction fetches from competing with the DMA engine on the SDRAM bus. See my recent message: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63152/focus=63308 FWIIW, in our experience with various PowerPC processors, using the CPU's dcbz (data cache block set to zero) instruction is also very fast, but it only works if you want to initialize memory to zero. You need to enable data caching (obviously) and not having instruction cache enabled would cripple that method too. [snip] Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants
On Thursday 09 July 2009 14:24:49 Jerry Van Baren wrote: All this would increase the code size for those boards not supporting the 64bit printf format. Not sure by how much, but I suggest to just fix the problem by supporting this format correctly instead of adding new code to print some warnings here. Best regards, Stefan That is what Scott is trying to do, but fixing 64bit printf causes a 2K++ increase in size to the boards that don't currently support 64bit printf (some of which are broken due to the error). Wolfgang is resisting that. Adding code to print a warning and handle the varargs properly will probably be less than 100 bytes. It looks like this is the compromise Wolfgang favors. I doubt that this could be done in less than 100 bytes. A descriptive error message string alone will probably be around = 60 chars. But I know this is nitpicking. I'm still voting for adding this 2k and doing it correctly on all boards. With the option to disable this 64bit support (as Scott suggested) on boards with very tight resources. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 v2] 83xx: Default to using DMA to initializeSDRAM
Jerry Van Baren wrote: Liu Dave-R63238 wrote: According to Ira, the DMA method was faster than the cpu method: It makes the DMA initialization normal speed again. The DMA in the for loop takes the longest (as expected). So yes, strangely it (enabling the icache) makes a HUGE difference. The total time is 3 seconds now. It is now faster than the previous CPU method. Logically the DMA method should be faster, and Ira's results seem to reinforce this. I don't have an 83xx board to test on, so let me know if others have different results than Ira. I did the DMA init test with the orignal DMA code. At that time The DMA method is slower than CPU method. Strange why the result is different. Instruction cache enabled/disabled is the difference - it eliminates instruction fetches from competing with the DMA engine on the SDRAM bus. See my recent message: http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/63152/focus=63308 Oops, that isn't going to be exactly correct since we aren't running out of RAM yet so instruction fetching isn't going to compete on the SDRAM bus directly. I stand by the general theory, however, that it is bus contention of some sort - I would speculate the arbitration of the local bus to flash vs. the DMA engine to SDRAM. Logically they should be independent, but they may not be due to internal interference (both using the same internal bus?) or simplifying assumptions in the arbitrator implementation. [snip] Best regards, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Enable support for 64bit printf on all PPC4xx variants
Stefan Roese wrote: On Thursday 09 July 2009 14:24:49 Jerry Van Baren wrote: All this would increase the code size for those boards not supporting the 64bit printf format. Not sure by how much, but I suggest to just fix the problem by supporting this format correctly instead of adding new code to print some warnings here. Best regards, Stefan That is what Scott is trying to do, but fixing 64bit printf causes a 2K++ increase in size to the boards that don't currently support 64bit printf (some of which are broken due to the error). Wolfgang is resisting that. Adding code to print a warning and handle the varargs properly will probably be less than 100 bytes. It looks like this is the compromise Wolfgang favors. I doubt that this could be done in less than 100 bytes. A descriptive error message string alone will probably be around = 60 chars. But I know this is nitpicking. Agreed. FWIIW, I wasn't assuming a /descriptive/ error message. I was assuming printf would simply print the format string, e.g. %lld, rather than a possibly erroneous value. Another alternative would be to do the spreadsheet idiom and print hashes . I'm still voting for adding this 2k and doing it correctly on all boards. With the option to disable this 64bit support (as Scott suggested) on boards with very tight resources. Me too. shrug Best regards, Stefan Thanks, gvb ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 5/6] usb: add Marvell Kirkwood ehci host controller driver
-Original Message-
From: l.ping...@gmail.com [mailto:l.ping...@gmail.com] On
Behalf Of Remy Bohmer
Sent: Thursday, July 09, 2009 1:00 PM
To: Prafulla Wadaskar; Michael Trimarchi
Cc: u-boot@lists.denx.de; Prabhanjan Sarnaik; Ronen Shitrit;
Ashish Karkare
Subject: Re: [PATCH 5/6] usb: add Marvell Kirkwood ehci host
controller driver
Hello Prafulla,
As stated in other email thread too.
Now all dependencies for Sheevaplug board support are in accepted
state except this patch
http://lists.denx.de/pipermail/u-boot/2009-June/055112.html
I know that but I cannot test it because I do not have the
hardware, so I depend on others here. (it might be even you).
I already mentioned that I would prefer the cleanup patch
from Michael Trimarchi, if it is correct.
At least there is 1 significant difference between your patch
and the patch of Michael
Your patch contains this:
- typeReq = req-request 8 | req-requesttype;
+ typeReq = req-request | req-requesttype 8;
switch (le16_to_cpu(typeReq)) {
and Michael patch contains this:
- typeReq = req-request 8 | req-requesttype;
+ typeReq = req-request | req-requesttype 8;
- switch (le16_to_cpu(typeReq)) {
+ switch (typeReq) {
Dear Remy
These two lines makes no difference for me since le16_to_cpu macro doesn't
change anything for arm little-endian machines (i.e. Sheevaplug)
Well.. for big endian machines someone need to check since it swaps bytes.
I think we should not remove this macro since it provides arch specific
abstraction.
Regards..
Prafulla . .
So, at least one of them is wrong.
This difference is reason enough for me to not pull either
patch in until this is clear.
Kind Regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH RESEND] Added support for splash screen positioning
This patch adds support splash image positioning by adding an
additional variable splashpos to the environment. Please see
README for details.
Signed-off-by: Matthias Weisser matthias.weis...@graf-syteco.de
---
README | 19 +++
common/lcd.c| 39 +--
drivers/video/cfb_console.c | 36 +++-
3 files changed, 91 insertions(+), 3 deletions(-)
diff --git a/README b/README
index 561c100..bbc9e06
--- a/README
+++ b/README
@@ -1074,6 +1074,25 @@ The following options need to be configured:
allows for a silent boot where a splash screen is
loaded very quickly after power-on.
+ CONFIG_SPLASH_SCREEN_ALIGN
+
+ If this option is set the splash image can be freely positioned
+ on the screen. Environment variable splashpos=x,y specifies
+ the position. If a positive number is given it is used as
+ number of pixel from left/top. If a negativ number is given it
+ is used as number of pixel from right/bottom. You can also
+ specify 'm' for centering the image.
+
+ Example:
+ setenv splashpos=m,m
+ = Image at center of screen
+
+ setenv splashpos=30,20
+ = Image at x = 20 and y = 30
+
+ setenv splashpos=-10,m
+ = Image at x = dspWidth - bmpWidth - 9 and y = center
+
- Gzip compressed BMP image support: CONFIG_VIDEO_BMP_GZIP
If this option is set, additionally to standard BMP
diff --git a/common/lcd.c b/common/lcd.c
index 74a5c77..b9a698d
--- a/common/lcd.c
+++ b/common/lcd.c
@@ -620,6 +620,11 @@ void bitmap_plot (int x, int y)
* Display the BMP file located at address bmp_image.
* Only uncompressed.
*/
+
+#ifdef CONFIG_SPLASH_SCREEN_ALIGN
+#define BMP_ALIGN_CENTER 0x7FFF
+#endif
+
int lcd_display_bitmap(ulong bmp_image, int x, int y)
{
#if !defined(CONFIG_MCC200)
@@ -731,6 +736,19 @@ int lcd_display_bitmap(ulong bmp_image, int x, int y)
#endif
padded_line = (width0x3) ? ((width~0x3)+4) : (width);
+
+#ifdef CONFIG_SPLASH_SCREEN_ALIGN
+ if (x == BMP_ALIGN_CENTER)
+ x = max(0, (pwidth - width) / 2);
+ else if (x 0)
+ x = max(0, pwidth - width + x + 1);
+
+ if (y == BMP_ALIGN_CENTER)
+ y = max(0, (panel_info.vl_row - height) / 2);
+ else if (y 0)
+ y = max(0, panel_info.vl_row - height + y + 1);
+#endif /* CONFIG_SPLASH_SCREEN_ALIGN */
+
if ((x + width)pwidth)
width = pwidth - x;
if ((y + height)panel_info.vl_row)
@@ -809,9 +827,26 @@ static void *lcd_logo (void)
static int do_splash = 1;
if (do_splash (s = getenv(splashimage)) != NULL) {
- addr = simple_strtoul(s, NULL, 16);
+ int x = 0, y = 0;
do_splash = 0;
+ addr = simple_strtoul (s, NULL, 16);
+#ifdef CONFIG_SPLASH_SCREEN_ALIGN
+ if ((s = getenv (splashpos)) != NULL) {
+ if (s[0] == 'm')
+ x = BMP_ALIGN_CENTER;
+ else
+ x = simple_strtol (s, NULL, 0);
+
+ if ((s = strchr (s + 1, ',')) != NULL) {
+ if (s[1] == 'm')
+ y = BMP_ALIGN_CENTER;
+ else
+ y = simple_strtol (s + 1, NULL, 0);
+ }
+ }
+#endif /* CONFIG_SPLASH_SCREEN_ALIGN */
+
#ifdef CONFIG_VIDEO_BMP_GZIP
bmp_image_t *bmp = (bmp_image_t *)addr;
unsigned long len;
@@ -822,7 +857,7 @@ static void *lcd_logo (void)
}
#endif
- if (lcd_display_bitmap (addr, 0, 0) == 0) {
+ if (lcd_display_bitmap (addr, x, y) == 0) {
return ((void *)lcd_base);
}
}
diff --git a/drivers/video/cfb_console.c b/drivers/video/cfb_console.c
index bcafb27..6adce19
--- a/drivers/video/cfb_console.c
+++ b/drivers/video/cfb_console.c
@@ -193,6 +193,11 @@ CONFIG_VIDEO_HW_CURSOR: - Uses the hardware cursor
capability of the
#if defined(CONFIG_CMD_BMP) || defined(CONFIG_SPLASH_SCREEN)
#include watchdog.h
#include bmp_layout.h
+
+#ifdef CONFIG_SPLASH_SCREEN_ALIGN
+#define BMP_ALIGN_CENTER 0x7FFF
+#endif
+
#endif
/*/
@@ -877,6 +882,18 @@ int video_display_bitmap (ulong bmp_image, int x, int y)
padded_line = (((width * bpp + 7) / 8) + 3) ~0x3;
+#ifdef CONFIG_SPLASH_SCREEN_ALIGN
+ if (x == BMP_ALIGN_CENTER)
+ x = max(0, (VIDEO_VISIBLE_COLS - width) / 2);
+ else if (x 0)
+
Re: [U-Boot] [PATCH 5/6] usb: add Marvell Kirkwood ehci host controller driver
Hi,
At least there is 1 significant difference between your patch
and the patch of Michael
Your patch contains this:
- typeReq = req-request 8 | req-requesttype;
+ typeReq = req-request | req-requesttype 8;
switch (le16_to_cpu(typeReq)) {
and Michael patch contains this:
- typeReq = req-request 8 | req-requesttype;
+ typeReq = req-request | req-requesttype 8;
- switch (le16_to_cpu(typeReq)) {
+ switch (typeReq) {
Dear Remy
These two lines makes no difference for me since le16_to_cpu macro doesn't
change anything for arm little-endian machines (i.e. Sheevaplug)
Well.. for big endian machines someone need to check since it swaps bytes.
Exactly!
I think we should not remove this macro since it provides arch specific
abstraction.
Well, that depends, if it is not needed it should be removed...
So, still I would not prefer to apply patches from which it is obvious
that there is something wrong with it.
Kind Regards,
Remy
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] 83xx, kmeter1: added NAND support
Hello Stefan, Stefan Roese wrote: On Thursday 09 July 2009 12:04:41 Heiko Schocher wrote: Signed-off-by: Heiko Schocher h...@denx.de --- board/keymile/kmeter1/Makefile |2 +- board/keymile/kmeter1/nand.c I suggest to move this NAND driver into the drivers/mtd/nand directory (e.g. drivers/mtd/nand/kmeter1_nand.c). We try to collect all drivers here. This makes maintenance easier. Hmm... this is not a nand driver, just some board specific functions. Should this go really in drivers/mtd/nand? bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] 83xx, kmeter1: added NAND support
On Thursday 09 July 2009 16:59:02 Heiko Schocher wrote: board/keymile/kmeter1/Makefile |2 +- board/keymile/kmeter1/nand.c I suggest to move this NAND driver into the drivers/mtd/nand directory (e.g. drivers/mtd/nand/kmeter1_nand.c). We try to collect all drivers here. This makes maintenance easier. Hmm... this is not a nand driver, just some board specific functions. Yes, it's still a NAND driver. Please take a look at a few of the other drivers in this directory. E.g. drivers/mtd/nand/atmel_nand.c. You will see that those are similar to your board specific driver. Implementing the HW- interface for the NAND infrastructure. Should this go really in drivers/mtd/nand? Yes, please. Thanks. Best regards, Stefan = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/9] Move architecture specific config.mk files into subdirs
This cleans up U-Boot's toplevel directory a bit and makes the architecture 'config.mk' file naming and location similar to board and cpu 'config.mk' files Signed-off-by: Peter Tyser pty...@xes-inc.com --- config.mk|2 +- arm_config.mk = lib_arm/config.mk |0 avr32_config.mk = lib_avr32/config.mk |0 blackfin_config.mk = lib_blackfin/config.mk |0 i386_config.mk = lib_i386/config.mk |0 m68k_config.mk = lib_m68k/config.mk |0 microblaze_config.mk = lib_microblaze/config.mk |0 mips_config.mk = lib_mips/config.mk |0 nios_config.mk = lib_nios/config.mk |0 nios2_config.mk = lib_nios2/config.mk |0 ppc_config.mk = lib_ppc/config.mk |0 sh_config.mk = lib_sh/config.mk |0 sparc_config.mk = lib_sparc/config.mk |0 13 files changed, 1 insertions(+), 1 deletions(-) rename arm_config.mk = lib_arm/config.mk (100%) rename avr32_config.mk = lib_avr32/config.mk (100%) rename blackfin_config.mk = lib_blackfin/config.mk (100%) rename i386_config.mk = lib_i386/config.mk (100%) rename m68k_config.mk = lib_m68k/config.mk (100%) rename microblaze_config.mk = lib_microblaze/config.mk (100%) rename mips_config.mk = lib_mips/config.mk (100%) rename nios_config.mk = lib_nios/config.mk (100%) rename nios2_config.mk = lib_nios2/config.mk (100%) rename ppc_config.mk = lib_ppc/config.mk (100%) rename sh_config.mk = lib_sh/config.mk (100%) rename sparc_config.mk = lib_sparc/config.mk (100%) diff --git a/config.mk b/config.mk index 7fc0453..02700f3 100644 --- a/config.mk +++ b/config.mk @@ -84,5 +84,5 @@ sinclude $(OBJTREE)/include/autoconf.mk ifdef ARCH -sinclude $(TOPDIR)/$(ARCH)_config.mk # include architecture dependend rules +sinclude $(TOPDIR)/lib_$(ARCH)/config.mk # include architecture dependend rules endif ifdef CPU diff --git a/arm_config.mk b/lib_arm/config.mk similarity index 100% rename from arm_config.mk rename to lib_arm/config.mk diff --git a/avr32_config.mk b/lib_avr32/config.mk similarity index 100% rename from avr32_config.mk rename to lib_avr32/config.mk diff --git a/blackfin_config.mk b/lib_blackfin/config.mk similarity index 100% rename from blackfin_config.mk rename to lib_blackfin/config.mk diff --git a/i386_config.mk b/lib_i386/config.mk similarity index 100% rename from i386_config.mk rename to lib_i386/config.mk diff --git a/m68k_config.mk b/lib_m68k/config.mk similarity index 100% rename from m68k_config.mk rename to lib_m68k/config.mk diff --git a/microblaze_config.mk b/lib_microblaze/config.mk similarity index 100% rename from microblaze_config.mk rename to lib_microblaze/config.mk diff --git a/mips_config.mk b/lib_mips/config.mk similarity index 100% rename from mips_config.mk rename to lib_mips/config.mk diff --git a/nios_config.mk b/lib_nios/config.mk similarity index 100% rename from nios_config.mk rename to lib_nios/config.mk diff --git a/nios2_config.mk b/lib_nios2/config.mk similarity index 100% rename from nios2_config.mk rename to lib_nios2/config.mk diff --git a/ppc_config.mk b/lib_ppc/config.mk similarity index 100% rename from ppc_config.mk rename to lib_ppc/config.mk diff --git a/sh_config.mk b/lib_sh/config.mk similarity index 100% rename from sh_config.mk rename to lib_sh/config.mk diff --git a/sparc_config.mk b/lib_sparc/config.mk similarity index 100% rename from sparc_config.mk rename to lib_sparc/config.mk -- 1.6.2.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/9] Move lib_arm to lib/arm
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
README |2 +-
board/actux1/u-boot.lds|2 +-
board/actux2/u-boot.lds|2 +-
board/actux3/u-boot.lds|2 +-
board/freescale/mx31ads/u-boot.lds |2 +-
board/trab/Makefile|4 ++--
board/trab/u-boot.lds |2 +-
doc/README.LED |2 +-
include/configs/B2.h |2 +-
{lib_arm = lib/arm}/Makefile |0
{lib_arm = lib/arm}/_ashldi3.S|0
{lib_arm = lib/arm}/_ashrdi3.S|0
{lib_arm = lib/arm}/_divsi3.S |0
{lib_arm = lib/arm}/_modsi3.S |0
{lib_arm = lib/arm}/_udivsi3.S|0
{lib_arm = lib/arm}/_umodsi3.S|0
{lib_arm = lib/arm}/board.c |0
{lib_arm = lib/arm}/bootm.c |0
{lib_arm = lib/arm}/cache-cp15.c |0
{lib_arm = lib/arm}/cache.c |0
{lib_arm = lib/arm}/config.mk |0
{lib_arm = lib/arm}/div0.c|0
{lib_arm = lib/arm}/interrupts.c |0
{lib_arm = lib/arm}/reset.c |0
24 files changed, 10 insertions(+), 10 deletions(-)
rename {lib_arm = lib/arm}/Makefile (100%)
rename {lib_arm = lib/arm}/_ashldi3.S (100%)
rename {lib_arm = lib/arm}/_ashrdi3.S (100%)
rename {lib_arm = lib/arm}/_divsi3.S (100%)
rename {lib_arm = lib/arm}/_modsi3.S (100%)
rename {lib_arm = lib/arm}/_udivsi3.S (100%)
rename {lib_arm = lib/arm}/_umodsi3.S (100%)
rename {lib_arm = lib/arm}/board.c (100%)
rename {lib_arm = lib/arm}/bootm.c (100%)
rename {lib_arm = lib/arm}/cache-cp15.c (100%)
rename {lib_arm = lib/arm}/cache.c (100%)
rename {lib_arm = lib/arm}/config.mk (100%)
rename {lib_arm = lib/arm}/div0.c (100%)
rename {lib_arm = lib/arm}/interrupts.c (100%)
rename {lib_arm = lib/arm}/reset.c (100%)
diff --git a/README b/README
index 28991c3..e3ea156 100644
--- a/README
+++ b/README
@@ -182,5 +182,5 @@ Directory Hierarchy:
- examples Example code for standalone applications, etc.
- include Header Files
-- lib_arm Files generic to ARM architecture
+- lib/arm Files generic to ARM architecture
- lib_avr32Files generic to AVR32 architecture
- lib_blackfin Files generic to Blackfin architecture
diff --git a/board/actux1/u-boot.lds b/board/actux1/u-boot.lds
index 836775f..a695056 100644
--- a/board/actux1/u-boot.lds
+++ b/board/actux1/u-boot.lds
@@ -34,5 +34,5 @@ SECTIONS
lib_generic/string.o(.text)
lib_generic/vsprintf.o(.text)
- lib_arm/board.o(.text)
+ lib/arm/board.o(.text)
common/dlmalloc.o(.text)
cpu/ixp/cpu.o(.text)
diff --git a/board/actux2/u-boot.lds b/board/actux2/u-boot.lds
index 0752656..4423000 100644
--- a/board/actux2/u-boot.lds
+++ b/board/actux2/u-boot.lds
@@ -34,5 +34,5 @@ SECTIONS
lib_generic/string.o(.text)
lib_generic/vsprintf.o(.text)
- lib_arm/board.o(.text)
+ lib/arm/board.o(.text)
common/dlmalloc.o(.text)
cpu/ixp/cpu.o(.text)
diff --git a/board/actux3/u-boot.lds b/board/actux3/u-boot.lds
index a69e7db..985271d 100644
--- a/board/actux3/u-boot.lds
+++ b/board/actux3/u-boot.lds
@@ -34,5 +34,5 @@ SECTIONS
lib_generic/string.o (.text)
lib_generic/vsprintf.o (.text)
- lib_arm/board.o (.text)
+ lib/arm/board.o (.text)
common/dlmalloc.o (.text)
cpu/ixp/cpu.o (.text)
diff --git a/board/freescale/mx31ads/u-boot.lds
b/board/freescale/mx31ads/u-boot.lds
index 3182aa6..9482d60 100644
--- a/board/freescale/mx31ads/u-boot.lds
+++ b/board/freescale/mx31ads/u-boot.lds
@@ -40,5 +40,5 @@ SECTIONS
cpu/arm1136/start.o (.text)
board/freescale/mx31ads/libmx31ads.a (.text)
- lib_arm/libarm.a (.text)
+ lib/arm/libarm.a (.text)
net/libnet.a (.text)
drivers/mtd/libmtd.a (.text)
diff --git a/board/trab/Makefile b/board/trab/Makefile
index 30e5fbb..9233f49 100644
--- a/board/trab/Makefile
+++ b/board/trab/Makefile
@@ -52,6 +52,6 @@ $(obj)trab_fkt.srec: $(OBJS_FKT) $(LIB)
-L$(obj)../../examples -lstubs \
-L$(obj)../../lib_generic -lgeneric \
- $(obj)../../lib_arm/div0.o \
- $(obj)../../lib_arm/_*.o
+ $(obj)../../lib/arm/div0.o \
+ $(obj)../../lib/arm/_*.o
$(OBJCOPY) -O srec $(:.o=) $@
diff --git a/board/trab/u-boot.lds b/board/trab/u-boot.lds
index d8bcfa4..2e0e721 100644
--- a/board/trab/u-boot.lds
+++ b/board/trab/u-boot.lds
@@ -34,5 +34,5 @@ SECTIONS
{
cpu/arm920t/start.o (.text)
- lib_arm/_umodsi3.o(.text)
+ lib/arm/_umodsi3.o(.text)
lib_generic/zlib.o(.text)
lib_generic/crc32.o (.text)
[U-Boot] [PATCH 0/9] Clean up top-level directory structure
This series moves api_examples to api/examples and moves all
lib* directories into a common lib/ directory. It also
moves the ARCH_config.mk files into their corresponding
lib directory.
Seeing 12 lib_ARCH directories and 12 ARCH_config.mk
files in U-Boot's top level always annoyed me, and I
finally had some time to reorganize:)
I compile tested on all PPC boards and verified an out of
tree build.
This series needs the api_examples Make cleanup applied:
http://www.mail-archive.com/u-boot@lists.denx.de/msg16032.html
Peter Tyser (9):
Move architecture specific config.mk files into subdirs
Move lib_ppc to lib/ppc
Move lib_arm to lib/arm
Move lib_i386 to lib/i386
Move lib_m68k to lib/m68k
Move remaining lib_ARCH to lib/ARCH
Move lib_generic to lib/generic
Move libfdt to lib/libfdt
Move api_examples to api/examples
Makefile | 20
README | 24 ++--
{api_examples = api/examples}/.gitignore |0
{api_examples = api/examples}/Makefile| 22 +-
{api_examples = api/examples}/crt0.S |0
{api_examples = api/examples}/demo.c |0
{api_examples = api/examples}/glue.c |0
{api_examples = api/examples}/glue.h |0
{api_examples = api/examples}/libgenwrap.c|2 +-
board/BuS/EB+MCF-EV123/u-boot.lds |8 +++---
board/LEOX/elpt860/u-boot.lds | 18 +++---
board/LEOX/elpt860/u-boot.lds.debug|4 +-
board/RPXClassic/u-boot.lds|8 +++---
board/RPXClassic/u-boot.lds.debug |4 +-
board/RPXlite/u-boot.lds |8 +++---
board/RPXlite/u-boot.lds.debug |4 +-
board/RPXlite_dw/u-boot.lds|8 +++---
board/RPXlite_dw/u-boot.lds.debug |4 +-
board/RRvision/u-boot.lds | 12 +-
board/actux1/u-boot.lds|6 ++--
board/actux2/u-boot.lds|6 ++--
board/actux3/u-boot.lds|6 ++--
board/amirix/ap1000/u-boot.lds |6 ++--
board/atum8548/u-boot.lds |6 ++--
board/bf518f-ezbrd/config.mk |2 +-
board/bf526-ezbrd/config.mk|2 +-
board/bf527-ezkit/config.mk|2 +-
board/bf533-ezkit/config.mk|2 +-
board/bf533-stamp/config.mk|2 +-
board/bf537-stamp/config.mk|2 +-
board/bf538f-ezkit/config.mk |2 +-
board/bf548-ezkit/config.mk|2 +-
board/bf561-ezkit/config.mk|2 +-
board/c2mon/u-boot.lds |8 +++---
board/c2mon/u-boot.lds.debug |4 +-
board/cm-bf527/config.mk |2 +-
board/cm-bf533/config.mk |2 +-
board/cm-bf537e/config.mk |2 +-
board/cm-bf548/config.mk |2 +-
board/cm-bf561/config.mk |2 +-
board/cobra5272/u-boot.lds |4 +-
board/cogent/u-boot.lds.debug |4 +-
board/cray/L1/u-boot.lds |6 ++--
board/cray/L1/u-boot.lds.debug |6 ++--
board/csb272/u-boot.lds|8 +++---
board/csb472/u-boot.lds|8 +++---
board/dave/PPChameleonEVB/u-boot.lds |6 ++--
board/eltec/mhpc/u-boot.lds.debug |4 +-
board/emk/top860/u-boot.lds.debug |6 ++--
board/eric/u-boot.lds |6 ++--
board/esd/ocrtc/u-boot.lds |6 ++--
board/esd/tasreg/u-boot.lds|4 +-
board/esteem192e/u-boot.lds|8 +++---
board/etx094/u-boot.lds|4 +-
board/etx094/u-boot.lds.debug |8 +++---
board/exbitgen/u-boot.lds |6 ++--
board/fads/u-boot.lds.debug|6 ++--
board/flagadm/u-boot.lds.debug |4 +-
board/freescale/m52277evb/u-boot.spa |4 +-
board/freescale/m5235evb/u-boot.16 |6 ++--
board/freescale/m5235evb/u-boot.32 |4 +-
board/freescale/m5249evb/u-boot.lds|4 +-
board/freescale/m5253demo/u-boot.lds |4 +-
board/freescale/m5253evbe/u-boot.lds |4 +-
board/freescale/m5271evb/u-boot.lds|4 +-
[U-Boot] [PATCH 2/9] Move lib_ppc to lib/ppc
Signed-off-by: Peter Tyser pty...@xes-inc.com --- Makefile |4 README|4 ++-- api_examples/Makefile |4 ++-- board/LEOX/elpt860/u-boot.lds | 10 +- board/RPXClassic/u-boot.lds |2 +- board/RPXlite/u-boot.lds |2 +- board/RPXlite_dw/u-boot.lds |2 +- board/RRvision/u-boot.lds |6 +++--- board/amirix/ap1000/u-boot.lds|2 +- board/atum8548/u-boot.lds |2 +- board/c2mon/u-boot.lds|2 +- board/cray/L1/u-boot.lds |2 +- board/cray/L1/u-boot.lds.debug|2 +- board/csb272/u-boot.lds |4 ++-- board/csb472/u-boot.lds |4 ++-- board/dave/PPChameleonEVB/u-boot.lds |2 +- board/emk/top860/u-boot.lds.debug |2 +- board/eric/u-boot.lds |2 +- board/esd/ocrtc/u-boot.lds|2 +- board/esteem192e/u-boot.lds |2 +- board/etx094/u-boot.lds.debug |4 ++-- board/exbitgen/u-boot.lds |2 +- board/fads/u-boot.lds.debug |2 +- board/freescale/mpc7448hpc2/tsi108_init.c |2 +- board/freescale/mpc8610hpcd/u-boot.lds|2 +- board/freescale/mpc8641hpcn/u-boot.lds|2 +- board/genietv/u-boot.lds |2 +- board/genietv/u-boot.lds.debug|2 +- board/hermes/u-boot.lds |6 +++--- board/hermes/u-boot.lds.debug |6 +++--- board/hymod/u-boot.lds|2 +- board/icu862/u-boot.lds |2 +- board/icu862/u-boot.lds.debug |2 +- board/ip860/u-boot.lds|6 +++--- board/ip860/u-boot.lds.debug |6 +++--- board/ivm/u-boot.lds.debug|2 +- board/jse/jse.c |6 +++--- board/jse/sdram.c |2 +- board/keymile/km8xx/u-boot.lds|6 +++--- board/kup/kup4k/u-boot.lds|2 +- board/kup/kup4x/u-boot.lds|2 +- board/lantec/u-boot.lds |2 +- board/lwmon/u-boot.lds.debug |2 +- board/mbx8xx/u-boot.lds.debug |2 +- board/ml2/u-boot.lds |2 +- board/ml2/u-boot.lds.debug|2 +- board/mousse/u-boot.lds |4 ++-- board/mousse/u-boot.lds.rom |2 +- board/mpc8540eval/u-boot.lds |2 +- board/mpl/mip405/u-boot.lds |2 +- board/mpl/pip405/u-boot.lds |2 +- board/mpl/pip405/u-boot.lds.debug |2 +- board/netphone/u-boot.lds |6 +++--- board/netstal/hcu4/hcu4.c |2 +- board/netstal/hcu5/README.txt |6 +++--- board/netstal/hcu5/hcu5.c |2 +- board/netstal/mcu25/mcu25.c |2 +- board/netta/u-boot.lds|6 +++--- board/netta2/u-boot.lds |6 +++--- board/netvia/u-boot.lds |6 +++--- board/pm854/u-boot.lds|2 +- board/pm856/u-boot.lds|2 +- board/quantum/u-boot.lds |2 +- board/rbc823/u-boot.lds |2 +- board/rmu/u-boot.lds |2 +- board/sandburst/karef/u-boot.lds |2 +- board/sandburst/karef/u-boot.lds.debug|2 +- board/sandburst/metrobox/u-boot.lds |2 +- board/sandburst/metrobox/u-boot.lds.debug |2 +- board/sbc405/u-boot.lds |2 +- board/sbc8548/u-boot.lds |2 +- board/sbc8560/u-boot.lds |2 +- board/sbc8641d/u-boot.lds |2 +- board/sc3/u-boot.lds |2 +- board/siemens/CCM/u-boot.lds |2 +- board/siemens/IAD210/u-boot.lds |4 ++-- board/siemens/pcu_e/u-boot.lds.debug |2 +- board/snmc/qs850/u-boot.lds |6 +++--- board/snmc/qs860t/u-boot.lds |6 +++--- board/socrates/u-boot.lds |2 +- board/spc1920/u-boot.lds |6 +++--- board/spd8xx/u-boot.lds.debug |2 +- board/stxgp3/u-boot.lds |2 +- board/stxssa/stxssa.c |2 +- board/stxssa/u-boot.lds |2 +-
[U-Boot] [PATCH 5/9] Move lib_m68k to lib/m68k
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
README |2 +-
board/cobra5272/u-boot.lds |2 +-
board/esd/tasreg/u-boot.lds |2 +-
board/freescale/m52277evb/u-boot.spa |2 +-
board/freescale/m5235evb/u-boot.16 |4 ++--
board/freescale/m5235evb/u-boot.32 |2 +-
board/freescale/m5249evb/u-boot.lds |2 +-
board/freescale/m5253demo/u-boot.lds |2 +-
board/freescale/m5253evbe/u-boot.lds |2 +-
board/freescale/m5271evb/u-boot.lds |2 +-
board/freescale/m5272c3/u-boot.lds |2 +-
board/freescale/m53017evb/u-boot.lds |2 +-
board/freescale/m5329evb/u-boot.lds |4 ++--
board/freescale/m5373evb/u-boot.lds |4 ++--
board/freescale/m54451evb/u-boot.spa |4 ++--
board/freescale/m54451evb/u-boot.stm |2 +-
board/freescale/m54455evb/u-boot.atm |4 ++--
board/freescale/m54455evb/u-boot.int |4 ++--
board/freescale/m547xevb/u-boot.lds |4 ++--
board/freescale/m548xevb/u-boot.lds |4 ++--
board/idmr/u-boot.lds|2 +-
doc/README.m52277evb | 12 ++--
doc/README.m53017evb | 12 ++--
doc/README.m5373evb | 12 ++--
doc/README.m54455evb | 12 ++--
doc/README.m5475evb | 10 +-
{lib_m68k = lib/m68k}/Makefile |0
{lib_m68k = lib/m68k}/board.c |0
{lib_m68k = lib/m68k}/bootm.c |0
{lib_m68k = lib/m68k}/cache.c |0
{lib_m68k = lib/m68k}/config.mk |0
{lib_m68k = lib/m68k}/interrupts.c |0
{lib_m68k = lib/m68k}/time.c|0
{lib_m68k = lib/m68k}/traps.c |0
34 files changed, 58 insertions(+), 58 deletions(-)
rename {lib_m68k = lib/m68k}/Makefile (100%)
rename {lib_m68k = lib/m68k}/board.c (100%)
rename {lib_m68k = lib/m68k}/bootm.c (100%)
rename {lib_m68k = lib/m68k}/cache.c (100%)
rename {lib_m68k = lib/m68k}/config.mk (100%)
rename {lib_m68k = lib/m68k}/interrupts.c (100%)
rename {lib_m68k = lib/m68k}/time.c (100%)
rename {lib_m68k = lib/m68k}/traps.c (100%)
diff --git a/README b/README
index 7de0a86..95ac65b 100644
--- a/README
+++ b/README
@@ -187,5 +187,5 @@ Directory Hierarchy:
- lib_generic Files generic to all architectures
- lib/i386 Files generic to i386architecture
-- lib_m68k Files generic to m68karchitecture
+- lib/m68k Files generic to m68karchitecture
- lib_mips Files generic to MIPSarchitecture
- lib_nios Files generic to NIOSarchitecture
diff --git a/board/cobra5272/u-boot.lds b/board/cobra5272/u-boot.lds
index 7e716bb..e866689 100644
--- a/board/cobra5272/u-boot.lds
+++ b/board/cobra5272/u-boot.lds
@@ -57,5 +57,5 @@ SECTIONS
cpu/mcf52x2/start.o(.text)
cpu/mcf52x2/cpu_init.o (.text)
-lib_m68k/traps.o (.text)
+lib/m68k/traps.o (.text)
cpu/mcf52x2/interrupts.o (.text)
common/dlmalloc.o (.text)
diff --git a/board/esd/tasreg/u-boot.lds b/board/esd/tasreg/u-boot.lds
index e3230b9..e072c5d 100644
--- a/board/esd/tasreg/u-boot.lds
+++ b/board/esd/tasreg/u-boot.lds
@@ -57,5 +57,5 @@ SECTIONS
cpu/mcf52x2/start.o(.text)
-lib_m68k/traps.o (.text)
+lib/m68k/traps.o (.text)
cpu/mcf52x2/interrupts.o (.text)
common/dlmalloc.o (.text)
diff --git a/board/freescale/m52277evb/u-boot.spa
b/board/freescale/m52277evb/u-boot.spa
index 7ae70d4..1105456 100644
--- a/board/freescale/m52277evb/u-boot.spa
+++ b/board/freescale/m52277evb/u-boot.spa
@@ -58,5 +58,5 @@ SECTIONS
cpu/mcf5227x/start.o (.text)
cpu/mcf5227x/libmcf5227x.a (.text)
-lib_m68k/libm68k.a (.text)
+lib/m68k/libm68k.a (.text)
lib_generic/libgeneric.a (.text)
common/cmd_mem.o (.text)
diff --git a/board/freescale/m5235evb/u-boot.16
b/board/freescale/m5235evb/u-boot.16
index c134884..da9b61a 100644
--- a/board/freescale/m5235evb/u-boot.16
+++ b/board/freescale/m5235evb/u-boot.16
@@ -58,6 +58,6 @@ SECTIONS
cpu/mcf523x/start.o(.text)
cpu/mcf523x/cpu_init.o (.text)
-lib_m68k/traps.o (.text)
-lib_m68k/interrupts.o (.text)
+lib/m68k/traps.o (.text)
+lib/m68k/interrupts.o (.text)
common/dlmalloc.o (.text)
lib_generic/zlib.o (.text)
diff --git a/board/freescale/m5235evb/u-boot.32
b/board/freescale/m5235evb/u-boot.32
index 53c337d..99cdd78 100644
--- a/board/freescale/m5235evb/u-boot.32
+++ b/board/freescale/m5235evb/u-boot.32
@@ -61,5 +61,5 @@ SECTIONS
cpu/mcf523x/interrupts.o (.text)
cpu/mcf523x/speed.o(.text)
-lib_m68k/libm68k.a (.text)
+lib/m68k/libm68k.a (.text)
common/dlmalloc.o (.text)
common/cmd_bootm.o (.text)
diff --git a/board/freescale/m5249evb/u-boot.lds
[U-Boot] [PATCH 6/9] Move remaining lib_ARCH to lib/ARCH
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Makefile |8 ++--
README | 12 ++--
config.mk|1 -
doc/README.nios |2 +-
include/common.h |8
{lib_avr32 = lib/avr32}/Makefile|0
{lib_avr32 = lib/avr32}/board.c |0
{lib_avr32 = lib/avr32}/bootm.c |0
{lib_avr32 = lib/avr32}/config.mk |0
{lib_avr32 = lib/avr32}/interrupts.c|0
{lib_avr32 = lib/avr32}/memset.S|0
{lib_blackfin = lib/blackfin}/.gitignore|0
{lib_blackfin = lib/blackfin}/Makefile |0
{lib_blackfin = lib/blackfin}/board.c |0
{lib_blackfin = lib/blackfin}/boot.c|0
{lib_blackfin = lib/blackfin}/cache.c |0
{lib_blackfin = lib/blackfin}/clocks.c |0
{lib_blackfin = lib/blackfin}/config.mk |0
{lib_blackfin = lib/blackfin}/memcmp.S |0
{lib_blackfin = lib/blackfin}/memcpy.S |0
{lib_blackfin = lib/blackfin}/memmove.S |0
{lib_blackfin = lib/blackfin}/memset.S |0
{lib_blackfin = lib/blackfin}/muldi3.c |0
{lib_blackfin = lib/blackfin}/post.c|0
{lib_blackfin = lib/blackfin}/string.c |0
{lib_blackfin = lib/blackfin}/tests.c |0
{lib_blackfin = lib/blackfin}/u-boot.lds.S |0
{lib_microblaze = lib/microblaze}/Makefile |0
{lib_microblaze = lib/microblaze}/board.c |0
{lib_microblaze = lib/microblaze}/bootm.c |0
{lib_microblaze = lib/microblaze}/cache.c |0
{lib_microblaze = lib/microblaze}/config.mk |0
{lib_microblaze = lib/microblaze}/time.c|0
{lib_mips = lib/mips}/Makefile |0
{lib_mips = lib/mips}/board.c |0
{lib_mips = lib/mips}/bootm.c |0
{lib_mips = lib/mips}/bootm_qemu_mips.c |0
{lib_mips = lib/mips}/config.mk |0
{lib_mips = lib/mips}/time.c|0
{lib_nios = lib/nios}/Makefile |0
{lib_nios = lib/nios}/board.c |0
{lib_nios = lib/nios}/bootm.c |0
{lib_nios = lib/nios}/cache.c |0
{lib_nios = lib/nios}/config.mk |0
{lib_nios = lib/nios}/divmod.c |0
{lib_nios = lib/nios}/math.h|0
{lib_nios = lib/nios}/mult.c|0
{lib_nios = lib/nios}/time.c|0
{lib_nios2 = lib/nios2}/Makefile|0
{lib_nios2 = lib/nios2}/board.c |0
{lib_nios2 = lib/nios2}/bootm.c |0
{lib_nios2 = lib/nios2}/cache.S |0
{lib_nios2 = lib/nios2}/config.mk |0
{lib_nios2 = lib/nios2}/divmod.c|0
{lib_nios2 = lib/nios2}/math.h |0
{lib_nios2 = lib/nios2}/mult.c |0
{lib_nios2 = lib/nios2}/time.c |0
{lib_sh = lib/sh}/Makefile |0
{lib_sh = lib/sh}/board.c |0
{lib_sh = lib/sh}/bootm.c |0
{lib_sh = lib/sh}/config.mk |0
{lib_sh = lib/sh}/time.c|0
{lib_sh = lib/sh}/time_sh2.c|0
{lib_sparc = lib/sparc}/Makefile|0
{lib_sparc = lib/sparc}/board.c |0
{lib_sparc = lib/sparc}/bootm.c |0
{lib_sparc = lib/sparc}/cache.c |0
{lib_sparc = lib/sparc}/config.mk |0
{lib_sparc = lib/sparc}/interrupts.c|0
{lib_sparc = lib/sparc}/time.c |0
70 files changed, 13 insertions(+), 18 deletions(-)
rename {lib_avr32 = lib/avr32}/Makefile (100%)
rename {lib_avr32 = lib/avr32}/board.c (100%)
rename {lib_avr32 = lib/avr32}/bootm.c (100%)
rename {lib_avr32 = lib/avr32}/config.mk (100%)
rename {lib_avr32 = lib/avr32}/interrupts.c (100%)
rename {lib_avr32 = lib/avr32}/memset.S (100%)
rename {lib_blackfin = lib/blackfin}/.gitignore (100%)
rename {lib_blackfin = lib/blackfin}/Makefile (100%)
rename {lib_blackfin = lib/blackfin}/board.c (100%)
rename {lib_blackfin = lib/blackfin}/boot.c (100%)
rename {lib_blackfin = lib/blackfin}/cache.c (100%)
rename {lib_blackfin = lib/blackfin}/clocks.c (100%)
rename {lib_blackfin = lib/blackfin}/config.mk (100%)
rename {lib_blackfin = lib/blackfin}/memcmp.S (100%)
rename {lib_blackfin = lib/blackfin}/memcpy.S (100%)
rename {lib_blackfin = lib/blackfin}/memmove.S (100%)
rename {lib_blackfin = lib/blackfin}/memset.S (100%)
rename {lib_blackfin = lib/blackfin}/muldi3.c (100%)
rename {lib_blackfin = lib/blackfin}/post.c (100%)
rename {lib_blackfin = lib/blackfin}/string.c (100%)
rename {lib_blackfin = lib/blackfin}/tests.c (100%)
rename {lib_blackfin = lib/blackfin}/u-boot.lds.S (100%)
rename {lib_microblaze = lib/microblaze}/Makefile (100%)
[U-Boot] [PATCH 4/9] Move lib_i386 to lib/i386
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
README |2 +-
doc/TODO-i386|2 +-
include/asm-i386/interrupt.h |2 +-
include/asm-i386/u-boot-i386.h |4 ++--
{lib_i386 = lib/i386}/Makefile |0
{lib_i386 = lib/i386}/bios.S|0
{lib_i386 = lib/i386}/bios.h|0
{lib_i386 = lib/i386}/bios_pci.S|0
{lib_i386 = lib/i386}/bios_setup.c |0
{lib_i386 = lib/i386}/board.c |0
{lib_i386 = lib/i386}/bootm.c |0
{lib_i386 = lib/i386}/config.mk |0
{lib_i386 = lib/i386}/interrupts.c |0
{lib_i386 = lib/i386}/pcat_interrupts.c |0
{lib_i386 = lib/i386}/pcat_timer.c |0
{lib_i386 = lib/i386}/pci.c |0
{lib_i386 = lib/i386}/pci_type1.c |0
{lib_i386 = lib/i386}/realmode.c|0
{lib_i386 = lib/i386}/realmode_switch.S |0
{lib_i386 = lib/i386}/timer.c |0
{lib_i386 = lib/i386}/video.c |0
{lib_i386 = lib/i386}/video_bios.c |0
{lib_i386 = lib/i386}/zimage.c |0
23 files changed, 5 insertions(+), 5 deletions(-)
rename {lib_i386 = lib/i386}/Makefile (100%)
rename {lib_i386 = lib/i386}/bios.S (100%)
rename {lib_i386 = lib/i386}/bios.h (100%)
rename {lib_i386 = lib/i386}/bios_pci.S (100%)
rename {lib_i386 = lib/i386}/bios_setup.c (100%)
rename {lib_i386 = lib/i386}/board.c (100%)
rename {lib_i386 = lib/i386}/bootm.c (100%)
rename {lib_i386 = lib/i386}/config.mk (100%)
rename {lib_i386 = lib/i386}/interrupts.c (100%)
rename {lib_i386 = lib/i386}/pcat_interrupts.c (100%)
rename {lib_i386 = lib/i386}/pcat_timer.c (100%)
rename {lib_i386 = lib/i386}/pci.c (100%)
rename {lib_i386 = lib/i386}/pci_type1.c (100%)
rename {lib_i386 = lib/i386}/realmode.c (100%)
rename {lib_i386 = lib/i386}/realmode_switch.S (100%)
rename {lib_i386 = lib/i386}/timer.c (100%)
rename {lib_i386 = lib/i386}/video.c (100%)
rename {lib_i386 = lib/i386}/video_bios.c (100%)
rename {lib_i386 = lib/i386}/zimage.c (100%)
diff --git a/README b/README
index e3ea156..7de0a86 100644
--- a/README
+++ b/README
@@ -186,5 +186,5 @@ Directory Hierarchy:
- lib_blackfin Files generic to Blackfin architecture
- lib_generic Files generic to all architectures
-- lib_i386 Files generic to i386architecture
+- lib/i386 Files generic to i386architecture
- lib_m68k Files generic to m68karchitecture
- lib_mips Files generic to MIPSarchitecture
diff --git a/doc/TODO-i386 b/doc/TODO-i386
index 84113f8..9769578 100644
--- a/doc/TODO-i386
+++ b/doc/TODO-i386
@@ -9,5 +9,5 @@ i386 port missing features:
(and used by INT 10h and INT 16h handlers for console I/O during early
linux boot...)
-* missing functions in lib_i386 and cpu/i386
+* missing functions in lib/i386 and cpu/i386
* speaker beep interface
diff --git a/include/asm-i386/interrupt.h b/include/asm-i386/interrupt.h
index 7f408cb..ae7540f 100644
--- a/include/asm-i386/interrupt.h
+++ b/include/asm-i386/interrupt.h
@@ -31,5 +31,5 @@
void set_vector(u8 intnum, void *routine);
-/* lib_i386/interupts.c */
+/* lib/i386/interupts.c */
void disable_irq(int irq);
void enable_irq(int irq);
diff --git a/include/asm-i386/u-boot-i386.h b/include/asm-i386/u-boot-i386.h
index 3921e01..b9c6d25 100644
--- a/include/asm-i386/u-boot-i386.h
+++ b/include/asm-i386/u-boot-i386.h
@@ -50,5 +50,5 @@ typedef void (timer_fnc_t) (void);
int register_timer_isr (timer_fnc_t *isr_func);
-/* Architecture specific - can be in cpu/i386/, lib_i386/, or $(BOARD)/ */
+/* Architecture specific - can be in cpu/i386/, lib/i386/, or $(BOARD)/ */
int timer_init(void);
@@ -66,5 +66,5 @@ void isa_unmap_rom(u32 addr);
u32 isa_map_rom(u32 bus_addr, int size);
-/* lib_i386/... */
+/* lib/i386/... */
int video_bios_init(void);
int video_init(void);
diff --git a/lib_i386/Makefile b/lib/i386/Makefile
similarity index 100%
rename from lib_i386/Makefile
rename to lib/i386/Makefile
diff --git a/lib_i386/bios.S b/lib/i386/bios.S
similarity index 100%
rename from lib_i386/bios.S
rename to lib/i386/bios.S
diff --git a/lib_i386/bios.h b/lib/i386/bios.h
similarity index 100%
rename from lib_i386/bios.h
rename to lib/i386/bios.h
diff --git a/lib_i386/bios_pci.S b/lib/i386/bios_pci.S
similarity index 100%
rename from lib_i386/bios_pci.S
rename to lib/i386/bios_pci.S
diff --git a/lib_i386/bios_setup.c b/lib/i386/bios_setup.c
similarity index 100%
rename from lib_i386/bios_setup.c
rename to lib/i386/bios_setup.c
diff --git a/lib_i386/board.c b/lib/i386/board.c
similarity index 100%
rename from lib_i386/board.c
rename to lib/i386/board.c
diff --git a/lib_i386/bootm.c b/lib/i386/bootm.c
similarity index 100%
rename from lib_i386/bootm.c
rename to lib/i386/bootm.c
diff --git a/lib_i386/config.mk b/lib/i386/config.mk
similarity index 100%
rename from lib_i386/config.mk
rename to lib/i386/config.mk
[U-Boot] [PATCH 9/9] Move api_examples to api/examples
Signed-off-by: Peter Tyser pty...@xes-inc.com
---
Makefile|4 ++--
{api_examples = api/examples}/.gitignore |0
{api_examples = api/examples}/Makefile |8
{api_examples = api/examples}/crt0.S |0
{api_examples = api/examples}/demo.c |0
{api_examples = api/examples}/glue.c |0
{api_examples = api/examples}/glue.h |0
{api_examples = api/examples}/libgenwrap.c |0
8 files changed, 6 insertions(+), 6 deletions(-)
rename {api_examples = api/examples}/.gitignore (100%)
rename {api_examples = api/examples}/Makefile (91%)
rename {api_examples = api/examples}/crt0.S (100%)
rename {api_examples = api/examples}/demo.c (100%)
rename {api_examples = api/examples}/glue.c (100%)
rename {api_examples = api/examples}/glue.h (100%)
rename {api_examples = api/examples}/libgenwrap.c (100%)
diff --git a/Makefile b/Makefile
index ee3b6bf..41a40e2 100644
--- a/Makefile
+++ b/Makefile
@@ -142,5 +142,5 @@ endif
SUBDIRS= tools \
examples \
- api_examples
+ api/examples
.PHONY : $(SUBDIRS)
@@ -3609,5 +3609,5 @@ clean:
@rm -f $(obj)nand_spl/{u-boot-spl,u-boot-spl.map,System.map}
@rm -f
$(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl-2k.bin,ipl-4k.bin,ipl.map}
- @rm -f $(obj)api_examples/demo $(TIMESTAMP_FILE) $(VERSION_FILE)
+ @rm -f $(obj)api/examples/demo $(TIMESTAMP_FILE) $(VERSION_FILE)
@find $(OBJTREE) -type f \
\( -name 'core' -o -name '*.bak' -o -name '*~' \
diff --git a/api_examples/.gitignore b/api/examples/.gitignore
similarity index 100%
rename from api_examples/.gitignore
rename to api/examples/.gitignore
diff --git a/api_examples/Makefile b/api/examples/Makefile
similarity index 91%
rename from api_examples/Makefile
rename to api/examples/Makefile
index db9f6ea..5ca1584 100644
--- a/api_examples/Makefile
+++ b/api/examples/Makefile
@@ -34,5 +34,5 @@ OUTPUT-$(CONFIG_API) = $(obj)demo
OUTPUT = $(OUTPUT-y)
-# Source files located in the api_examples directory
+# Source files located in the api/examples directory
SOBJ_FILES-$(CONFIG_API) += crt0.o
COBJ_FILES-$(CONFIG_API) += demo.o
@@ -40,5 +40,5 @@ COBJ_FILES-$(CONFIG_API) += glue.o
COBJ_FILES-$(CONFIG_API) += libgenwrap.o
-# Source files which exist outside the api_examples directory
+# Source files which exist outside the api/examples directory
EXT_COBJ_FILES-$(CONFIG_API) += lib/generic/crc32.o
EXT_COBJ_FILES-$(CONFIG_API) += lib/generic/ctype.o
@@ -52,6 +52,6 @@ endif
SRCS += $(addprefix $(SRCTREE)/,$(EXT_COBJ_FILES-y:.o=.c))
SRCS += $(addprefix $(SRCTREE)/,$(EXT_SOBJ_FILES-y:.o=.S))
-SRCS += $(addprefix $(SRCTREE)/api_examples/,$(COBJ_FILES-y:.o=.c))
-SRCS += $(addprefix $(SRCTREE)/api_examples/,$(SOBJ_FILES-y:.o=.S))
+SRCS += $(addprefix $(SRCTREE)/api/examples/,$(COBJ_FILES-y:.o=.c))
+SRCS += $(addprefix $(SRCTREE)/api/examples/,$(SOBJ_FILES-y:.o=.S))
# Create a list of object files to be compiled
diff --git a/api_examples/crt0.S b/api/examples/crt0.S
similarity index 100%
rename from api_examples/crt0.S
rename to api/examples/crt0.S
diff --git a/api_examples/demo.c b/api/examples/demo.c
similarity index 100%
rename from api_examples/demo.c
rename to api/examples/demo.c
diff --git a/api_examples/glue.c b/api/examples/glue.c
similarity index 100%
rename from api_examples/glue.c
rename to api/examples/glue.c
diff --git a/api_examples/glue.h b/api/examples/glue.h
similarity index 100%
rename from api_examples/glue.h
rename to api/examples/glue.h
diff --git a/api_examples/libgenwrap.c b/api/examples/libgenwrap.c
similarity index 100%
rename from api_examples/libgenwrap.c
rename to api/examples/libgenwrap.c
--
1.6.2.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC] - sanve the server's mac address...
On Wed 8 Jul 2009 14:50, Robin Getz pondered:
Linux's netconsole works much better when you can pass it the MAC
address of the server. (otherwise it just uses broadcast, which
everyone else on my network complains about :)
This sets the evn var serveraddr (to match ethaddr), so that you
can pass it to linux with whatever bootargs you want to
addnetconsole=set bootargs $(bootargs)
netconso...@$(ipaddr)/eth0,@$(serverip)/$(serveraddr)
I'm sure this is white space damaged - but you get the idea...
Wolfgang - did you want me to push this through the Blackfin tree
(via Mike) or wait for Ben?
Index: net/net.c
===
--- net/net.c (revision 1961)
+++ net/net.c (working copy)
@@ -1273,6 +1273,15 @@
/* are we waiting for a reply */
if (!NetArpWaitPacketIP || !NetArpWaitPacketMAC)
break;
+
+#ifdef CONFIG_KEEP_SERVERADDR
+ if (NetServerIP == NetArpWaitPacketIP) {
+ char buf[20];
+ sprintf(buf, %pM, arp-ar_data);
+ setenv(serveraddr, buf);
+ }
+#endif
+
#ifdef ET_DEBUG
printf(Got ARP REPLY, set server/gtwy eth addr
(%pM)\n,
arp-ar_data)
___
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Numonyx Axcell M29EW write problems with CFG_FLASH_USE_BUFFER_WRITE in u-boot 1.2.0
Dear all, if I enable the flag CFG_FLASH_USE_BUFFER_WRITE in the u-boot configuration (u-boot 1.2.0 I get a timeout when trying to write the flash Numonyx Axcell M29EW. Have you any idea about this problem? Bye, Antonio. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot-v2 and GPL license version?
On Thursday 09 July 2009 07:21:16 Detlev Zundel wrote: Wolfgang's last word was pretty adamant about taking U-Boot to GPLv3. I see the U-Boot v2 GPLv3/GPLv2-plugin technique as a way to take the core to GPLv3 without needlessly re-writing the parts we've borrowed from linux (in fact, it encourages borrowing from linux, which is a Good Thing[tm]). Asking Linux authors to license their code as GPLv2+ is also an option. Incidentally drivers/rtc-bfin.c is one example of GPL-2 or later in the Linux tree. the Blackfin code has been licensed under GPLv2 or later only as a courtesy. we dont care what other people do with it so long as the places where we have to maintain it stay GPLv2. apparently this was naive of us wrt u-boot. -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] [RFC] - sanve the server's mac address...
On Thursday 09 July 2009 11:12:47 Robin Getz wrote: On Wed 8 Jul 2009 14:50, Robin Getz pondered: Linux's netconsole works much better when you can pass it the MAC address of the server. (otherwise it just uses broadcast, which everyone else on my network complains about :) This sets the evn var serveraddr (to match ethaddr), so that you can pass it to linux with whatever bootargs you want to addnetconsole=set bootargs $(bootargs) netconso...@$(ipaddr)/eth0,@$(serverip)/$(serveraddr) I'm sure this is white space damaged - but you get the idea... Wolfgang - did you want me to push this through the Blackfin tree (via Mike) or wait for Ben? all net stuff goes through Ben -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] [PATCH 1/3 v2] 83xx: Default to using DMA to initialize SDRAM
On Wed, Jul 08, 2009 at 05:58:50PM -0700, Ira W. Snyder wrote:
On Wed, Jul 08, 2009 at 07:32:26PM -0500, Peter Tyser wrote:
On Thu, 2009-07-09 at 08:24 +0800, Liu Dave-R63238 wrote:
When SDRAM ECC is enabled and CONFIG_ECC_INIT_VIA_DDRCONTROLLER is not
defined use DMA to set SDRAM to a known state. Previously a
sequence of
64-bit stores was used.
IIRC, the DMA init SDRAM is slower than the 64bit stores.
It is why I added these code here.
I suggest to keep the way.
According to Ira, the DMA method was faster than the cpu method:
It makes the DMA initialization normal speed again. The DMA in the for
loop takes the longest (as expected).
So yes, strangely it (enabling the icache) makes a HUGE difference. The
total time is 3 seconds now. It is now faster than the previous CPU
method.
Logically the DMA method should be faster, and Ira's results seem to
reinforce this. I don't have an 83xx board to test on, so let me know
if others have different results than Ira.
I didn't check the SDRAM init time with code, only by a rough estimate.
(Counting one one-thousand, two one-thousand...). I can add back the
time measuring code, and be really sure which one is faster.
Both the DMA and CPU methods are definitely on the same order of
magnitude. The time taken by the CFI flash driver is MUCH longer than
the SDRAM initialization. I wonder, should the icache be enabled for
that as well?
I'll do some more testing when I get back to the office tomorrow.
Ok, I've added back the get_tbms() code, and created a routine to
initialize ECC with the CPU. I've inlined my patch below, just for
reference.
DMA 945ms
CPU 581ms
As an interesting comparison, I also benchmarked the method of using the
DDR controller to initialize ECC.
DDRC 129ms
So there you have it. Dave Liu is correct, the CPU method is faster,
though definitely on the same order of magnitude with the
icache_enable()/icache_disable() patch.
I may stick with the DDRC method on my board, the difference is just
amazing. The flash init still takes up most of the boot process,
however.
Peter, feel free to fold the patch below into your own work.
Ira
From 5cc24043352a90bf8ac89b5db0bc07a97e24d5d1 Mon Sep 17 00:00:00 2001
From: Ira W. Snyder i...@ovro.caltech.edu
Date: Thu, 9 Jul 2009 08:45:09 -0700
Subject: [PATCH] mpc83xx: initialize ECC SDRAM with CPU
Signed-off-by: Ira W. Snyder i...@ovro.caltech.edu
---
cpu/mpc83xx/spd_sdram.c | 58 +++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/cpu/mpc83xx/spd_sdram.c b/cpu/mpc83xx/spd_sdram.c
index ab6a2bb..7e093ae 100644
--- a/cpu/mpc83xx/spd_sdram.c
+++ b/cpu/mpc83xx/spd_sdram.c
@@ -1,3 +1,4 @@
+#define DEBUG 1
/*
* (C) Copyright 2006-2007 Freescale Semiconductor, Inc.
*
@@ -825,18 +826,75 @@ long int spd_sdram()
#if defined(CONFIG_DDR_ECC) !defined(CONFIG_ECC_INIT_VIA_DDRCONTROLLER)
/*
+ * Use timebase counter, get_timer() is not availabe
+ * at this point of initialization yet.
+ */
+static unsigned long get_tbms (void)
+{
+ unsigned long tbl;
+ unsigned long tbu1, tbu2;
+ unsigned long ms;
+ unsigned long long tmp;
+
+ ulong tbclk = get_tbclk();
+
+ /* get the timebase ticks */
+ do {
+ asm volatile (mftbu %0:=r (tbu1):);
+ asm volatile (mftb %0:=r (tbl):);
+ asm volatile (mftbu %0:=r (tbu2):);
+ } while (tbu1 != tbu2);
+
+ /* convert ticks to ms */
+ tmp = (unsigned long long)(tbu1);
+ tmp = (tmp 32);
+ tmp += (unsigned long long)(tbl);
+ ms = tmp/(tbclk/1000);
+
+ return ms;
+}
+
+void cpu_meminit(uint val, uint size)
+{
+ register u64 *p;
+ unsigned int pattern[2];
+
+ icache_enable();
+
+ pattern[0] = val;
+ pattern[1] = val;
+
+ for (p = 0; p (u64*)(size); p++)
+ ppcDWstore((u32*)p, pattern);
+
+ asm volatile (sync);
+
+ icache_disable();
+}
+
+/*
* Initialize all of memory for ECC, then enable errors.
*/
void ddr_enable_ecc(unsigned int dram_size)
{
volatile immap_t *immap = (immap_t *)CONFIG_SYS_IMMR;
volatile ddr83xx_t *ddr= immap-ddr;
+ unsigned long s, e;
debug(\nInitializing ECC!\n);
+ s = get_tbms();
+#if 0
+ debug(\nInitializing ECC (using DMA)!\n);
dma_meminit(CONFIG_MEM_INIT_VALUE, dram_size);
+#else
+ debug(\nInitializing ECC (using CPU)!\n);
+ cpu_meminit(CONFIG_MEM_INIT_VALUE, dram_size);
+#endif
+ e = get_tbms();
debug(\nREADY!\n);
+ debug(ddr init duration: %ld ms\n, e - s);
/* Clear All ECC Errors */
if ((ddr-err_detect ECC_ERROR_DETECT_MME) == ECC_ERROR_DETECT_MME)
--
1.5.4.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
