[U-Boot] [PATCH v6 1/2] arm: A320: driver for FTRTC010 real time clock
From: Po-Yu Chuang ratb...@faraday-tech.com
This patch adds an FTRTC010 driver for Faraday A320 evaluation board.
Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com
---
drivers/rtc/Makefile |1 +
drivers/rtc/ftrtc010.c | 124
2 files changed, 125 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/ftrtc010.c
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 822dc1a..25252b5 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -40,6 +40,7 @@ COBJS-$(CONFIG_RTC_DS1556) += ds1556.o
COBJS-$(CONFIG_RTC_DS164x) += ds164x.o
COBJS-$(CONFIG_RTC_DS174x) += ds174x.o
COBJS-$(CONFIG_RTC_DS3231) += ds3231.o
+COBJS-$(CONFIG_RTC_FTRTC010) += ftrtc010.o
COBJS-$(CONFIG_RTC_ISL1208) += isl1208.o
COBJS-$(CONFIG_RTC_M41T11) += m41t11.o
COBJS-$(CONFIG_RTC_M41T60) += m41t60.o
diff --git a/drivers/rtc/ftrtc010.c b/drivers/rtc/ftrtc010.c
new file mode 100644
index 000..c3c0bc2
--- /dev/null
+++ b/drivers/rtc/ftrtc010.c
@@ -0,0 +1,124 @@
+/*
+ * Faraday FTRTC010 Real Time Clock
+ *
+ * (C) Copyright 2009 Faraday Technology
+ * Po-Yu Chuang ratb...@faraday-tech.com
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include config.h
+#include common.h
+#include rtc.h
+#include asm/io.h
+
+struct ftrtc010 {
+ unsigned int sec; /* 0x00 */
+ unsigned int min; /* 0x04 */
+ unsigned int hour; /* 0x08 */
+ unsigned int day; /* 0x0c */
+ unsigned int alarm_sec; /* 0x10 */
+ unsigned int alarm_min; /* 0x14 */
+ unsigned int alarm_hour;/* 0x18 */
+ unsigned int record;/* 0x1c */
+ unsigned int cr;/* 0x20 */
+};
+
+/*
+ * RTC Control Register
+ */
+#define FTRTC010_CR_ENABLE (1 0)
+#define FTRTC010_CR_INTERRUPT_SEC (1 1)/* per second irq */
+#define FTRTC010_CR_INTERRUPT_MIN (1 2)/* per minute irq */
+#define FTRTC010_CR_INTERRUPT_HR (1 3)/* per hour irq */
+#define FTRTC010_CR_INTERRUPT_DAY (1 4)/* per dayirq */
+
+static struct ftrtc010 *rtc = (struct ftrtc010 *)CONFIG_FTRTC010_BASE;
+
+static void ftrtc010_enable (void)
+{
+ writel (FTRTC010_CR_ENABLE, rtc-cr);
+}
+
+/*
+ * return current time in seconds
+ */
+static unsigned long ftrtc010_time (void)
+{
+ unsigned long day;
+ unsigned long hour;
+ unsigned long minute;
+ unsigned long second;
+ unsigned long second2;
+
+ do {
+ second = readl (rtc-sec);
+ day = readl (rtc-day);
+ hour= readl (rtc-hour);
+ minute = readl (rtc-min);
+ second2 = readl (rtc-sec);
+ } while (second != second2);
+
+ return day * 24 * 60 * 60 + hour * 60 * 60 + minute * 60 + second;
+}
+
+/*
+ * Get the current time from the RTC
+ */
+
+int rtc_get (struct rtc_time *tmp)
+{
+ unsigned long now;
+
+ debug (%s(): record register: %x\n,
+ __func__, readl (rtc-record));
+
+ now = ftrtc010_time () + readl (rtc-record);
+
+ to_tm (now, tmp);
+
+ return 0;
+}
+
+/*
+ * Set the RTC
+ */
+int rtc_set (struct rtc_time *tmp)
+{
+ unsigned long new;
+ unsigned long now;
+
+ debug (%s(): DATE: %4d-%02d-%02d (wday=%d) TIME: %2d:%02d:%02d\n,
+ __func__,
+ tmp-tm_year, tmp-tm_mon, tmp-tm_mday, tmp-tm_wday,
+ tmp-tm_hour, tmp-tm_min, tmp-tm_sec);
+
+ new = mktime (tmp-tm_year, tmp-tm_mon, tmp-tm_mday, tmp-tm_hour,
+ tmp-tm_min, tmp-tm_sec);
+
+ now = ftrtc010_time ();
+
+ debug (%s(): write %lx to record register\n, __func__, new - now);
+
+ writel (new - now, rtc-record);
+
+ return 0;
+}
+
+void rtc_reset (void)
+{
+ debug (%s()\n, __func__);
+ ftrtc010_enable ();
+}
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v6 2/2] arm: A320: Add support for Faraday A320 evaluation board
From: Po-Yu Chuang ratb...@faraday-tech.com This patch adds support for A320 evaluation board from Faraday. This board uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM. FA526 is an ARMv4 processor and uses the ARM920T source in this patch. Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + board/faraday/a320evb/Makefile| 51 board/faraday/a320evb/a320evb.c | 73 +++ board/faraday/a320evb/config.mk | 35 + board/faraday/a320evb/lowlevel_init.S | 118 + cpu/arm920t/a320/Makefile | 47 +++ cpu/arm920t/a320/ftsmc020.c | 51 cpu/arm920t/a320/reset.S | 22 cpu/arm920t/a320/timer.c | 193 include/asm-arm/arch-a320/a320.h | 35 + include/asm-arm/arch-a320/ftpmu010.h | 190 include/asm-arm/arch-a320/ftsdmc020.h | 103 +++ include/asm-arm/arch-a320/ftsmc020.h | 79 include/asm-arm/arch-a320/fttmr010.h | 73 +++ include/configs/a320evb.h | 222 + 17 files changed, 1300 insertions(+), 0 deletions(-) create mode 100644 board/faraday/a320evb/Makefile create mode 100644 board/faraday/a320evb/a320evb.c create mode 100644 board/faraday/a320evb/config.mk create mode 100644 board/faraday/a320evb/lowlevel_init.S create mode 100644 cpu/arm920t/a320/Makefile create mode 100644 cpu/arm920t/a320/ftsmc020.c create mode 100644 cpu/arm920t/a320/reset.S create mode 100644 cpu/arm920t/a320/timer.c create mode 100644 include/asm-arm/arch-a320/a320.h create mode 100644 include/asm-arm/arch-a320/ftpmu010.h create mode 100644 include/asm-arm/arch-a320/ftsdmc020.h create mode 100644 include/asm-arm/arch-a320/ftsmc020.h create mode 100644 include/asm-arm/arch-a320/fttmr010.h create mode 100644 include/configs/a320evb.h diff --git a/MAINTAINERS b/MAINTAINERS index 79873f3..aa54bdb 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -533,6 +533,10 @@ Rick Bronson r...@efn.org AT91RM9200DKat91rm9200 +Po-Yu Chuang ratb...@faraday-tech.com + + a320evb FA526 (ARM920T-like) (a320 SoC) + George G. Davis gda...@mvista.com assabet SA1100 diff --git a/MAKEALL b/MAKEALL index 5882ceb..7c742b6 100755 --- a/MAKEALL +++ b/MAKEALL @@ -505,6 +505,7 @@ LIST_ARM7= \ # LIST_ARM9=\ + a320evb \ ap920t \ ap922_XA10 \ ap926ejs\ diff --git a/Makefile b/Makefile index c9d315a..a3fb0b8 100644 --- a/Makefile +++ b/Makefile @@ -2661,6 +2661,9 @@ shannon_config: unconfig ## ARM92xT Systems # +a320evb_config : unconfig + @$(MKCONFIG) $(@:_config=) arm arm920t a320evb faraday a320 + # ## Atmel AT91RM9200 Systems # diff --git a/board/faraday/a320evb/Makefile b/board/faraday/a320evb/Makefile new file mode 100644 index 000..74f660d --- /dev/null +++ b/board/faraday/a320evb/Makefile @@ -0,0 +1,51 @@ +# +# (C) Copyright 2000-2006 +# Wolfgang Denk, DENX Software Engineering, w...@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 $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := a320evb.o +SOBJS := lowlevel_init.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 $(obj).depend + +# + +# defines $(obj).depend target +include
Re: [U-Boot] [PATCH] net: See to it that sent data is aligned to the ethernet controllers wishes
On Wed, 19 Aug 2009 09:55:46 -0700 Ben Warren biggerbadder...@gmail.com wrote: My preference is for the drivers to handle alignment. OK, I'm fine with that. I'd like to withdraw this patch then. I like Dave's idea of creating a buffer (or multiple buffers) in initialization(), then memcpy'ing to to it in the send() routine. You could make it smart to only memcpy if the frame is not aligned as needed. It already only memcpys unaligned buffers, but I'll go with Daves suggestion and allocate it at startup instead. Your original patch created a buffer of size 9000, which I commented was probably bigger than necessary. I didn't see a response to that (which doesn't mean you didn't send one, but I get a lot of e-mail :) I was off for vacation [*], so I only sent it this week. I'll rework this patch a bit to address a small bug I found. Thanks for the comments! // Simon [*] By now the U-boot list is probably tired of hearing about my vacation, but I can assure you that I had a good time! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v6 2/2] arm: A320: Add support for Faraday A320 evaluation board
Dear Jean-Christophe PLAGNIOL-VILLARD, 2009/8/20 ratbert.chu...@gmail.com: From: Po-Yu Chuang ratb...@faraday-tech.com This patch adds support for A320 evaluation board from Faraday. This board uses FA526 processor by default and has 512kB and 32MB NOR flash, 64M RAM. FA526 is an ARMv4 processor and uses the ARM920T source in this patch. Signed-off-by: Po-Yu Chuang ratb...@faraday-tech.com --- MAINTAINERS | 4 + MAKEALL | 1 + Makefile | 3 + board/faraday/a320evb/Makefile | 51 board/faraday/a320evb/a320evb.c | 73 +++ board/faraday/a320evb/config.mk | 35 + board/faraday/a320evb/lowlevel_init.S | 118 + cpu/arm920t/a320/Makefile | 47 +++ cpu/arm920t/a320/ftsmc020.c | 51 cpu/arm920t/a320/reset.S | 22 cpu/arm920t/a320/timer.c | 193 include/asm-arm/arch-a320/a320.h | 35 + include/asm-arm/arch-a320/ftpmu010.h | 190 include/asm-arm/arch-a320/ftsdmc020.h | 103 +++ include/asm-arm/arch-a320/ftsmc020.h | 79 include/asm-arm/arch-a320/fttmr010.h | 73 +++ include/configs/a320evb.h | 222 + 17 files changed, 1300 insertions(+), 0 deletions(-) create mode 100644 board/faraday/a320evb/Makefile create mode 100644 board/faraday/a320evb/a320evb.c create mode 100644 board/faraday/a320evb/config.mk create mode 100644 board/faraday/a320evb/lowlevel_init.S create mode 100644 cpu/arm920t/a320/Makefile create mode 100644 cpu/arm920t/a320/ftsmc020.c create mode 100644 cpu/arm920t/a320/reset.S create mode 100644 cpu/arm920t/a320/timer.c create mode 100644 include/asm-arm/arch-a320/a320.h create mode 100644 include/asm-arm/arch-a320/ftpmu010.h create mode 100644 include/asm-arm/arch-a320/ftsdmc020.h create mode 100644 include/asm-arm/arch-a320/ftsmc020.h create mode 100644 include/asm-arm/arch-a320/fttmr010.h create mode 100644 include/configs/a320evb.h I failed to CC you again, but the patches appear in the mailing list. Hope you can see them. The command I used is like below. Is there anything wrong? git send-email \ --from=ratbert.chu...@gmail.com \ --to=u-b...@lists.denx.de \ --cc=plagn...@jcrosoft.com \ --cc...@denx.de \ --cc=augulis.dar...@gmail.com \ 0002-arm-A320-Add-support-for-Faraday-A320-evaluation-boa.patch 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] e1000 Rx timeout with 82541ER
On Thu, 2009-08-20 at 10:36 +0800, Zang Roy-R61911 wrote: -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Wednesday, August 19, 2009 7:58 AM To: André Schwarz Cc: Zang Roy-R61911; Ben Warren; U-Boot List Subject: Re: [U-Boot] e1000 Rx timeout with 82541ER Dear =?ISO-8859-1?Q?Andr=E9?= Schwarz, In message 1250683805.22118.22.ca...@swa-m460 you wrote: with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot of changes. Well, it should be straightforward to git-bisect this issue... Could you help to send me the error log? I do not have 82541ER card to try. ok - please give me some days. Hopefully I can send you some output/questions on tuesday. Regards, André Thank.s roy MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Hans-Joachim Reich ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v4] arm: kirkwood: See to it that sent data is 8-byte aligned
U-boot might use non-8-byte-aligned addresses for sending data, which
the kwgbe_send doesn't accept (bootp does this for me). This patch
copies the data to be sent to a malloced temporary buffer if it is
non-aligned.
v2: Malloc send buffer
v3: No need to use jumbo frames, use 1518 bytes buffer instead
v4: Correct alignment passed to memalign (should be 8!),
allocate buffer at initialization(), use PKTSIZE_ALIGN
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
drivers/net/kirkwood_egiga.c | 21 +
drivers/net/kirkwood_egiga.h |1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 9ac9c1f..008c5dd 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -494,18 +494,26 @@ static int kwgbe_send(struct eth_device *dev, volatile
void *dataptr,
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe-regs;
struct kwgbe_txdesc *p_txdesc = dkwgbe-p_txdesc;
+ void *p = (void *)dataptr;
u32 cmd_sts;
+ /* Copy buffer if it's misaligned */
if ((u32) dataptr 0x07) {
- printf(Err..(%s) xmit dataptr not 64bit aligned\n,
- __FUNCTION__);
- return -1;
+ if (datasize PKTSIZE_ALIGN) {
+ printf(Non-aligned data too large (%d)\n,
+ datasize);
+ return -1;
+ }
+
+ memcpy(dkwgbe-p_aligned_txbuf, p, datasize);
+ p = dkwgbe-p_aligned_txbuf;
}
+
p_txdesc-cmd_sts = KWGBE_ZERO_PADDING | KWGBE_GEN_CRC;
p_txdesc-cmd_sts |= KWGBE_TX_FIRST_DESC | KWGBE_TX_LAST_DESC;
p_txdesc-cmd_sts |= KWGBE_BUFFER_OWNED_BY_DMA;
p_txdesc-cmd_sts |= KWGBE_TX_EN_INTERRUPT;
- p_txdesc-buf_ptr = (u8 *) dataptr;
+ p_txdesc-buf_ptr = (u8 *) p;
p_txdesc-byte_cnt = datasize;
/* Apply send command using zeroth RXUQ */
@@ -622,8 +630,13 @@ int kirkwood_egiga_initialize(bd_t * bis)
* PKTSIZE_ALIGN + 1)))
goto error3;
+ if (!(dkwgbe-p_aligned_txbuf = memalign(8, PKTSIZE_ALIGN)))
+ goto error4;
+
if (!(dkwgbe-p_txdesc = (struct kwgbe_txdesc *)
memalign(PKTALIGN, sizeof(struct kwgbe_txdesc) + 1))) {
+ free(dkwgbe-p_aligned_txbuf);
+ error4:
free(dkwgbe-p_rxbuf);
error3:
free(dkwgbe-p_rxdesc);
diff --git a/drivers/net/kirkwood_egiga.h b/drivers/net/kirkwood_egiga.h
index 9c893d1..16d5214 100644
--- a/drivers/net/kirkwood_egiga.h
+++ b/drivers/net/kirkwood_egiga.h
@@ -499,6 +499,7 @@ struct kwgbe_device {
struct kwgbe_rxdesc *p_rxdesc;
struct kwgbe_rxdesc *p_rxdesc_curr;
u8 *p_rxbuf;
+ u8 *p_aligned_txbuf;
};
#endif /* __EGIGA_H__ */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:kirkwood Wait for the link to come up on kirkwood network init
On Wed, 19 Aug 2009 10:08:02 -0700
Ben Warren biggerbadder...@gmail.com wrote:
- u16 phyadr;
- miiphy_read(dev-name, 0xEE, 0xEE, phyadr);
- if (!miiphy_link(dev-name, phyadr)) {
- printf(%s: No link on %s\n, __FUNCTION__, dev-name);
Please use __func__ instead. It's defined in C99, while __FUNCTION__
isn't (or so I've read)
I'll remove the function name part completely.
- return -1;
+ /* Wait up to 5s for the link status */
+ for (i = 0; i 5; i++) {
+ u16 phyadr;
Please put this variable declaration outside of the 'for' loop
+ miiphy_read(dev-name, 0xEE, 0xEE, phyadr);
What does '0xEE' mean? I know you didn't write it, but magic numbers
are bad.
Good question. After looking around a bit, I end up in smi_reg_read in
the same file:
static int smi_reg_read(char *devname, u8 phy_adr, u8 reg_ofs, u16 * data)
{
[...]
/* Phyadr read request */
if (phy_adr == 0xEE reg_ofs == 0xEE) {
/* */
*data = (u16) (KWGBEREG_RD(regs-phyadr) PHYADR_MASK);
return 0;
[...]
}
which is registered for the PHY reads with miiphy_register. So it's a
file-local magic number. I'll cook up another patch which adresses this.
// Simon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] [repost]: arm: kirkwood: See to it that sent data is 8-byte aligned
U-boot might use non-8-byte-aligned addresses for sending data, which
the kwgbe_send doesn't accept (bootp does this for me). This patch
copies the data to be sent to a malloced temporary buffer if it is
non-aligned.
v2: Malloc send buffer
v3: No need to use jumbo frames, use 1518 bytes buffer instead
v4: Correct alignment passed to memalign (should be 8!),
allocate buffer at initialization(), use PKTSIZE_ALIGN
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
drivers/net/kirkwood_egiga.c | 21 +
drivers/net/kirkwood_egiga.h |1 +
2 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 9f36633..479035d 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -500,18 +500,26 @@ static int kwgbe_send(struct eth_device *dev, volatile
void *dataptr,
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe-regs;
struct kwgbe_txdesc *p_txdesc = dkwgbe-p_txdesc;
+ void *p = (void *)dataptr;
u32 cmd_sts;
+ /* Copy buffer if it's misaligned */
if ((u32) dataptr 0x07) {
- printf(Err..(%s) xmit dataptr not 64bit aligned\n,
- __FUNCTION__);
- return -1;
+ if (datasize PKTSIZE_ALIGN) {
+ printf(Non-aligned data too large (%d)\n,
+ datasize);
+ return -1;
+ }
+
+ memcpy(dkwgbe-p_aligned_txbuf, p, datasize);
+ p = dkwgbe-p_aligned_txbuf;
}
+
p_txdesc-cmd_sts = KWGBE_ZERO_PADDING | KWGBE_GEN_CRC;
p_txdesc-cmd_sts |= KWGBE_TX_FIRST_DESC | KWGBE_TX_LAST_DESC;
p_txdesc-cmd_sts |= KWGBE_BUFFER_OWNED_BY_DMA;
p_txdesc-cmd_sts |= KWGBE_TX_EN_INTERRUPT;
- p_txdesc-buf_ptr = (u8 *) dataptr;
+ p_txdesc-buf_ptr = (u8 *) p;
p_txdesc-byte_cnt = datasize;
/* Apply send command using zeroth RXUQ */
@@ -628,8 +636,13 @@ int kirkwood_egiga_initialize(bd_t * bis)
* PKTSIZE_ALIGN + 1)))
goto error3;
+ if (!(dkwgbe-p_aligned_txbuf = memalign(8, PKTSIZE_ALIGN)))
+ goto error4;
+
if (!(dkwgbe-p_txdesc = (struct kwgbe_txdesc *)
memalign(PKTALIGN, sizeof(struct kwgbe_txdesc) + 1))) {
+ free(dkwgbe-p_aligned_txbuf);
+ error4:
free(dkwgbe-p_rxbuf);
error3:
free(dkwgbe-p_rxdesc);
diff --git a/drivers/net/kirkwood_egiga.h b/drivers/net/kirkwood_egiga.h
index 9c893d1..16d5214 100644
--- a/drivers/net/kirkwood_egiga.h
+++ b/drivers/net/kirkwood_egiga.h
@@ -499,6 +499,7 @@ struct kwgbe_device {
struct kwgbe_rxdesc *p_rxdesc;
struct kwgbe_rxdesc *p_rxdesc_curr;
u8 *p_rxbuf;
+ u8 *p_aligned_txbuf;
};
#endif /* __EGIGA_H__ */
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3]: Wait for the link to come up on kirkwood network init
This patch makes the device wait for up to 5 seconds for the link to
come up, similar to what many of the other network drivers do. This
avoids confusing situations where, e.g., a tftp fails when initiated
early after U-boot has started (before the link has come up).
v2: Remove function name from printout
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
drivers/net/kirkwood_egiga.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index 065e335..9f36633 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -400,6 +400,7 @@ static int kwgbe_init(struct eth_device *dev)
{
struct kwgbe_device *dkwgbe = to_dkwgbe(dev);
struct kwgbe_registers *regs = dkwgbe-regs;
+ int i;
/* setup RX rings */
kwgbe_init_rx_desc_ring(dkwgbe);
@@ -447,13 +448,20 @@ static int kwgbe_init(struct eth_device *dev)
#if (defined (CONFIG_MII) || defined (CONFIG_CMD_MII)) \
defined (CONFIG_SYS_FAULT_ECHO_LINK_DOWN)
- u16 phyadr;
- miiphy_read(dev-name, KIRKWOOD_PHY_ADR_REQUEST,
- KIRKWOOD_PHY_ADR_REQUEST, phyadr);
- if (!miiphy_link(dev-name, phyadr)) {
- printf(%s: No link on %s\n, __FUNCTION__, dev-name);
- return -1;
+ /* Wait up to 5s for the link status */
+ for (i = 0; i 5; i++) {
+ u16 phyadr;
+
+ miiphy_read(dev-name, KIRKWOOD_PHY_ADR_REQUEST,
+ KIRKWOOD_PHY_ADR_REQUEST, phyadr);
+ /* Return if we get link up */
+ if (miiphy_link(dev-name, phyadr))
+ return 0;
+ udelay(100);
}
+
+ printf(No link on %s\n, dev-name);
+ return -1;
#endif
return 0;
}
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3]: arm:Kirkwood network driver fixes
Hi! Three patches to fix various network driver issues on kirkwood. Patch 3 is a repost of the patch sent earlier today which is rebased on top of the other two. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm:kirkwood See to it that sent data is 8-byte aligned
-Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Thursday, August 20, 2009 4:07 AM To: Simon Kagstrom Cc: Prafulla Wadaskar; U-Boot ML; Prabhanjan Sarnaik; Ashish Karkare Subject: Re: [U-Boot] [PATCH] arm:kirkwood See to it that sent data is 8-byte aligned On 12:48 Tue 18 Aug , Simon Kagstrom wrote: Thanks for the review Prafulla! On Tue, 18 Aug 2009 03:12:07 -0700 Prafulla Wadaskar prafu...@marvell.com wrote: v2: Malloc send buffer (comment from Stefan Roese) Malloc will always be an overhead. It's only allocated once (the first time a non-aligned buffer is passed), so the overhead is minimal. I strongly recommend- we should pass aligned buffers from upper layers to avoid such rework in all low level drivers, (few are already aligned). We could put the same fix in eth_send instead. Then the issue is really just how we know what alignment requirement to go for. I guess one could add a field to the eth_device structure to store this and then fixup all drivers to supply this. If the rest of you thinks this is a good idea, I can cook up a patch. Opinions? some drivers would also have the possibility to have multiple receive buffer specially when you use dma so IMHO it make more sense to let each drivers handle it itself In that case it makes more sense to implement this even for rx path too in upper layer. We should always push common functionalities to upper layers And this is very generic need for any driver that uses dma for transfers Regards.. Prafulla . . Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH mkimage branch] tools/mkimage: fix compiler warnings, use const
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk
Sent: Wednesday, August 19, 2009 3:24 PM
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH mkimage branch] tools/mkimage: fix
compiler warnings, use const
This fixes some compiler warnings:
tools/default_image.c:141: warning: initialization from
incompatible pointer type
tools/fit_image.c:202: warning: initialization from
incompatible pointer type
and changes to code to use const attributes in a few places where
it's appropriate.
Dear Wolfgang
99% of the changes in this patch is to add const attributes.
Can you pls explain here- how useful it is to add const.
Or do it make more sense just to fix the warnings in respective functions?
I have posted a patch for the same
For ex.
Regards..
Prafulla . .
Signed-off-by: Wolfgang Denk w...@denx.de
---
common/image.c | 39 ---
include/image.h | 34 +-
tools/mkimage.h |2 +-
3 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/common/image.c b/common/image.c
index e22c974..f3dd647 100644
--- a/common/image.c
+++ b/common/image.c
@@ -65,7 +65,7 @@ extern int do_bdinfo(cmd_tbl_t *cmdtp, int
flag, int argc, char *argv[]);
DECLARE_GLOBAL_DATA_PTR;
-static image_header_t* image_get_ramdisk (ulong rd_addr,
uint8_t arch,
+static const image_header_t* image_get_ramdisk (ulong
rd_addr, uint8_t arch,
int verify);
#else
#include mkimage.h
@@ -166,7 +166,7 @@ static void genimg_print_time (time_t timestamp);
/*
/
/* Legacy format routines */
/*
/
-int image_check_hcrc (image_header_t *hdr)
+int image_check_hcrc (const image_header_t *hdr)
{
ulong hcrc;
ulong len = image_get_header_size ();
@@ -181,7 +181,7 @@ int image_check_hcrc (image_header_t *hdr)
return (hcrc == image_get_hcrc (hdr));
}
-int image_check_dcrc (image_header_t *hdr)
+int image_check_dcrc (const image_header_t *hdr)
{
ulong data = image_get_data (hdr);
ulong len = image_get_data_size (hdr);
@@ -203,7 +203,7 @@ int image_check_dcrc (image_header_t *hdr)
* returns:
* number of components
*/
-ulong image_multi_count (image_header_t *hdr)
+ulong image_multi_count (const image_header_t *hdr)
{
ulong i, count = 0;
uint32_t *size;
@@ -236,7 +236,7 @@ ulong image_multi_count (image_header_t *hdr)
* data address and size of the component, if idx is valid
* 0 in data and len, if idx is out of range
*/
-void image_multi_getimg (image_header_t *hdr, ulong idx,
+void image_multi_getimg (const image_header_t *hdr, ulong idx,
ulong *data, ulong *len)
{
int i;
@@ -272,7 +272,7 @@ void image_multi_getimg (image_header_t
*hdr, ulong idx,
}
}
-static void image_print_type (image_header_t *hdr)
+static void image_print_type (const image_header_t *hdr)
{
const char *os, *arch, *type, *comp;
@@ -286,7 +286,7 @@ static void image_print_type (image_header_t *hdr)
/**
* image_print_contents - prints out the contents of the
legacy format image
- * @hdr: pointer to the legacy format image header
+ * @ptr: pointer to the legacy format image header
* @p: pointer to prefix string
*
* image_print_contents() formats a multi line legacy image
contents description.
@@ -296,8 +296,9 @@ static void image_print_type (image_header_t *hdr)
* returns:
* no returned results
*/
-void image_print_contents (image_header_t *hdr)
+void image_print_contents (const void *ptr)
{
+ const image_header_t *hdr = (const image_header_t *)ptr;
const char *p;
#ifdef USE_HOSTCC
@@ -363,10 +364,10 @@ void image_print_contents (image_header_t *hdr)
* pointer to a ramdisk image header, if image was found
and valid
* otherwise, return NULL
*/
-static image_header_t* image_get_ramdisk (ulong rd_addr,
uint8_t arch,
+static const image_header_t *image_get_ramdisk (ulong
rd_addr, uint8_t arch,
int verify)
{
- image_header_t *rd_hdr = (image_header_t *)rd_addr;
+ const image_header_t *rd_hdr = (const image_header_t *)rd_addr;
if (!image_check_magic (rd_hdr)) {
puts (Bad Magic Number\n);
@@ -628,13 +629,13 @@ int genimg_get_comp_id (const char *name)
*/
int genimg_get_format (void *img_addr)
{
- ulong format = IMAGE_FORMAT_INVALID;
- image_header_t *hdr;
+ ulong format = IMAGE_FORMAT_INVALID;
+ const image_header_t *hdr;
#if defined(CONFIG_FIT) || defined(CONFIG_OF_LIBFDT)
- char*fit_hdr;
+ char *fit_hdr;
Re: [U-Boot] Weird issues with u-boot on Microblaze
Hi, I've been trying to bring up a vanilla kernel on an XUPV5-LX110T board, and have been having all sorts of odd issues with U-Boot. For example, if I try to enable FIT image support (as noted on http://www.monstr.eu/wiki/doku.php?id=uboot:uboot ), I get CONFIG_BOOTMAPSZ undefined. I've also had to edit image.h to get the thing to compile. image.c: In function ‘boot_get_fdt’: image.c:1510: error: ‘bootm_headers_t’ has no member named ‘fit_hdr_fdt’ image.c:1511: error: ‘bootm_headers_t’ has no member named ‘fit_uname_fdt’ image.c:1512: error: ‘bootm_headers_t’ has no member named ‘fit_noffset_fdt’ the fix: edit image.h (line 221): #if defined(CONFIG_OF_LIBFDT) /* WAS: CONFIG_PPC */ FIT support is not in mainline u-boot. Only in my testing repository. If I fix that and try to load a FIT image with a kernel and device-tree, the bootm command completely ignores the device tree; unfortunately, Yes the same thing as with FIT. Not in mainline yet. Simple no time. But I have patches in my tree and I want to send them to next merge open window. I don't have a log of this on hand, because now even image loading has broken somehow. For example, fatls ace 0 gives131074 . , and attempting DHCP boot results in a spew of ARP Retry count exceeded; starting again -- retry count exceeded, despite it never having tried even once? I'll test it. I've attached a log of the console output under both conditions, as well as the config.mk and xparameters.h under microblaze_generic; for some reason, the given U-Boot BSP assumes 100MHz, despite the board using 125MHz. Does anyone have advice for getting u-boot to work on this board? I have fix for u-boot bsp which fix it. The same issue is for uart16550. I am going to update my git repo at http://git.monstr.eu/git/gitweb.cgi There will be updated u-boot bsp too. Thanks, Michal Thanks in advance for any help. ___ 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 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3]: arm:kirkwood Define kirkwood phy address magic number
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
drivers/net/kirkwood_egiga.c | 14 ++
1 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c
index f31fefc..065e335 100644
--- a/drivers/net/kirkwood_egiga.c
+++ b/drivers/net/kirkwood_egiga.c
@@ -38,6 +38,8 @@
#include asm/arch/kirkwood.h
#include kirkwood_egiga.h
+#define KIRKWOOD_PHY_ADR_REQUEST 0xee
+
/*
* smi_reg_read - miiphy_read callback function.
*
@@ -52,7 +54,8 @@ static int smi_reg_read(char *devname, u8 phy_adr, u8
reg_ofs, u16 * data)
u32 timeout;
/* Phyadr read request */
- if (phy_adr == 0xEE reg_ofs == 0xEE) {
+ if (phy_adr == KIRKWOOD_PHY_ADR_REQUEST
+ reg_ofs == KIRKWOOD_PHY_ADR_REQUEST) {
/* */
*data = (u16) (KWGBEREG_RD(regs-phyadr) PHYADR_MASK);
return 0;
@@ -127,7 +130,8 @@ static int smi_reg_write(char *devname, u8 phy_adr, u8
reg_ofs, u16 data)
u32 timeout;
/* Phyadr write request*/
- if (phy_adr == 0xEE reg_ofs == 0xEE) {
+ if (phy_adr == KIRKWOOD_PHY_ADR_REQUEST
+ reg_ofs == KIRKWOOD_PHY_ADR_REQUEST) {
KWGBEREG_WR(regs-phyadr, data);
return 0;
}
@@ -444,7 +448,8 @@ static int kwgbe_init(struct eth_device *dev)
#if (defined (CONFIG_MII) || defined (CONFIG_CMD_MII)) \
defined (CONFIG_SYS_FAULT_ECHO_LINK_DOWN)
u16 phyadr;
- miiphy_read(dev-name, 0xEE, 0xEE, phyadr);
+ miiphy_read(dev-name, KIRKWOOD_PHY_ADR_REQUEST,
+ KIRKWOOD_PHY_ADR_REQUEST, phyadr);
if (!miiphy_link(dev-name, phyadr)) {
printf(%s: No link on %s\n, __FUNCTION__, dev-name);
return -1;
@@ -670,7 +675,8 @@ int kirkwood_egiga_initialize(bd_t * bis)
#if defined(CONFIG_MII) || defined(CONFIG_CMD_MII)
miiphy_register(dev-name, smi_reg_read, smi_reg_write);
/* Set phy address of the port */
- miiphy_write(dev-name, 0xEE, 0xEE, PHY_BASE_ADR + devnum);
+ miiphy_write(dev-name, KIRKWOOD_PHY_ADR_REQUEST,
+ KIRKWOOD_PHY_ADR_REQUEST, PHY_BASE_ADR +
devnum);
#endif
}
return 0;
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/4]: Define ffs/fls for all architectures
On Thu, 20 Aug 2009 01:11:09 +0200 Jean-Christophe PLAGNIOL-VILLARD plagn...@jcrosoft.com wrote: On 11:13 Tue 18 Aug , Simon Kagstrom wrote: Define ffs/fls for all architectures UBIFS requires fls(), which is not defined for arm (and some other architectures) and this patch adds it. The implementation is taken from Linux and is generic. ffs() is also defined for those that miss it. v2: Unify code style (empty line between ffs/fls) please this Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- here I didn't add that myself - it's git format-patch that put it there. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 0/4]: bitops cleanup and fixes
Hi again! This patch series is an update to [PATCH 0/4]: bitops cleanup and fixes: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/66184 and contains the patches which were not accepted. The patches are: 0001-Move-__set-clear_bit-from-ubifs.h-to-bitops.h.patch - Code style updates. I chose to not create asm-generic/include/bitops/ (Jean-Christophes comment) since I feel that should go together with a larger restructuring. - Updated to put BIT_MASK above the include of asm/bitops.h 0002-Make-arm-bitops-endianness-independent.patch - New patch which takes on the endianeess issue in arm bitops 0003-Define-ffs-fls-for-all-architectures.patch - Code style updates (Wolfgangs comment). 0004-Define-test_and_set_bit-and-test_and_clear-bit-for-A.patch - Defines test_and_set_bit etc for ARM. Uses the non-atomic __test_and_set_bit. remove-dupliace-cr.patch was accepted into the u-boot-arm tree, so I'm not reposting it. // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 1/4]: Move __set/clear_bit from ubifs.h to bitops.h
__set_bit and __clear_bit are defined in ubifs.h as well as in
asm/include/bitops.h for some architectures. This patch moves
the generic implementation to include/linux/bitops.h and uses
that unless it's defined by the architecture.
v2: Unify code style (newline between __set_bit and __clear_bit)
v3: Move BIT_MASK and BIT_WORD above the include of asm/bitops.h
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
fs/ubifs/ubifs.h | 32
include/asm-avr32/bitops.h |4
include/asm-m68k/bitops.h |4
include/asm-nios/bitops.h |4
include/asm-nios2/bitops.h |4
include/asm-ppc/bitops.h |4
include/asm-sh/bitops.h|5 +
include/asm-sparc/bitops.h |4
include/linux/bitops.h | 29 +
9 files changed, 58 insertions(+), 32 deletions(-)
diff --git a/fs/ubifs/ubifs.h b/fs/ubifs/ubifs.h
index 43865aa..06772af 100644
--- a/fs/ubifs/ubifs.h
+++ b/fs/ubifs/ubifs.h
@@ -449,38 +449,6 @@ static inline ino_t parent_ino(struct dentry *dentry)
return res;
}
-/* linux/include/linux/bitops.h */
-
-#define BIT_MASK(nr) (1UL ((nr) % BITS_PER_LONG))
-#define BIT_WORD(nr) ((nr) / BITS_PER_LONG)
-
-/* linux/include/asm-generic/bitops/non-atomic.h */
-
-/**
- * __set_bit - Set a bit in memory
- * @nr: the bit to set
- * @addr: the address to start counting from
- *
- * Unlike set_bit(), this function is non-atomic and may be reordered.
- * If it's called on the same region of memory simultaneously, the effect
- * may be that only one operation succeeds.
- */
-static inline void __set_bit(int nr, volatile unsigned long *addr)
-{
- unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
-
- *p |= mask;
-}
-
-static inline void __clear_bit(int nr, volatile unsigned long *addr)
-{
- unsigned long mask = BIT_MASK(nr);
- unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
-
- *p = ~mask;
-}
-
/* debug.c */
#define DEFINE_SPINLOCK(...)
diff --git a/include/asm-avr32/bitops.h b/include/asm-avr32/bitops.h
index f15fd46..b1cf2fb 100644
--- a/include/asm-avr32/bitops.h
+++ b/include/asm-avr32/bitops.h
@@ -22,4 +22,8 @@
#ifndef __ASM_AVR32_BITOPS_H
#define __ASM_AVR32_BITOPS_H
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#endif /* __ASM_AVR32_BITOPS_H */
diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
index 0f9e8ab..fb472e6 100644
--- a/include/asm-m68k/bitops.h
+++ b/include/asm-m68k/bitops.h
@@ -15,6 +15,10 @@ extern int test_and_set_bit(int nr, volatile void *addr);
extern int test_and_clear_bit(int nr, volatile void *addr);
extern int test_and_change_bit(int nr, volatile void *addr);
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#ifdef __KERNEL__
/*
diff --git a/include/asm-nios/bitops.h b/include/asm-nios/bitops.h
index 7744212..76c52c2 100644
--- a/include/asm-nios/bitops.h
+++ b/include/asm-nios/bitops.h
@@ -34,4 +34,8 @@ extern int test_and_change_bit(int nr, volatile void * addr);
extern int test_bit(int nr, volatile void * a);
extern int ffs(int i);
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#endif /* _ASM_NIOS_BITOPS_H */
diff --git a/include/asm-nios2/bitops.h b/include/asm-nios2/bitops.h
index e6c1a85..da04b40 100644
--- a/include/asm-nios2/bitops.h
+++ b/include/asm-nios2/bitops.h
@@ -34,4 +34,8 @@ extern int test_and_change_bit(int nr, volatile void * addr);
extern int test_bit(int nr, volatile void * a);
extern int ffs(int i);
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#endif /* __ASM_NIOS2_BITOPS_H */
diff --git a/include/asm-ppc/bitops.h b/include/asm-ppc/bitops.h
index daa66cf..fd7f599 100644
--- a/include/asm-ppc/bitops.h
+++ b/include/asm-ppc/bitops.h
@@ -144,6 +144,10 @@ extern __inline__ int test_and_change_bit(int nr, volatile
void *addr)
}
#endif /* __INLINE_BITOPS */
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
extern __inline__ int test_bit(int nr, __const__ volatile void *addr)
{
__const__ unsigned int *p = (__const__ unsigned int *) addr;
diff --git a/include/asm-sh/bitops.h b/include/asm-sh/bitops.h
index 410fba4..f102e7e 100644
--- a/include/asm-sh/bitops.h
+++ b/include/asm-sh/bitops.h
@@ -146,6 +146,11 @@ static inline int ffs (int x)
}
return r;
}
+
+#define __set_bit(nr, addr) generic_set_bit(nr, addr)
+
+#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+
#endif /* __KERNEL__ */
#endif /* __ASM_SH_BITOPS_H */
diff --git a/include/asm-sparc/bitops.h b/include/asm-sparc/bitops.h
index
[U-Boot] [PATCH v2 2/4]: Make arm bitops endianness-independent
Bring over the bitop implementations from the Linux
include/asm-generic/bitops/non-atomic.h to provide
endianness-independence.
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
include/asm-arm/bitops.h | 45 +++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 4b8bab2..04ae68c 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -27,57 +27,66 @@ extern void set_bit(int nr, volatile void * addr);
static inline void __set_bit(int nr, volatile void *addr)
{
- ((unsigned char *) addr)[nr 3] |= (1U (nr 7));
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p |= mask;
}
extern void clear_bit(int nr, volatile void * addr);
static inline void __clear_bit(int nr, volatile void *addr)
{
- ((unsigned char *) addr)[nr 3] = ~(1U (nr 7));
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p = ~mask;
}
extern void change_bit(int nr, volatile void * addr);
static inline void __change_bit(int nr, volatile void *addr)
{
- ((unsigned char *) addr)[nr 3] ^= (1U (nr 7));
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+
+ *p ^= mask;
}
extern int test_and_set_bit(int nr, volatile void * addr);
static inline int __test_and_set_bit(int nr, volatile void *addr)
{
- unsigned int mask = 1 (nr 7);
- unsigned int oldval;
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
- oldval = ((unsigned char *) addr)[nr 3];
- ((unsigned char *) addr)[nr 3] = oldval | mask;
- return oldval mask;
+ *p = old | mask;
+ return (old mask) != 0;
}
extern int test_and_clear_bit(int nr, volatile void * addr);
static inline int __test_and_clear_bit(int nr, volatile void *addr)
{
- unsigned int mask = 1 (nr 7);
- unsigned int oldval;
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
- oldval = ((unsigned char *) addr)[nr 3];
- ((unsigned char *) addr)[nr 3] = oldval ~mask;
- return oldval mask;
+ *p = old ~mask;
+ return (old mask) != 0;
}
extern int test_and_change_bit(int nr, volatile void * addr);
static inline int __test_and_change_bit(int nr, volatile void *addr)
{
- unsigned int mask = 1 (nr 7);
- unsigned int oldval;
+ unsigned long mask = BIT_MASK(nr);
+ unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr);
+ unsigned long old = *p;
- oldval = ((unsigned char *) addr)[nr 3];
- ((unsigned char *) addr)[nr 3] = oldval ^ mask;
- return oldval mask;
+ *p = old ^ mask;
+ return (old mask) != 0;
}
extern int find_first_zero_bit(void * addr, unsigned size);
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 3/4]: Define ffs/fls for all architectures
UBIFS requires fls(), which is not defined for arm (and some other
architectures) and this patch adds it. The implementation is taken from
Linux and is generic. ffs() is also defined for those that miss it.
v2: Unify code style (empty line between ffs/fls)
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
include/asm-arm/bitops.h|4
include/asm-avr32/bitops.h |4
include/asm-i386/bitops.h |2 ++
include/asm-m68k/bitops.h |2 ++
include/asm-microblaze/bitops.h |2 ++
include/asm-mips/bitops.h |2 ++
include/asm-nios/bitops.h |5 -
include/asm-nios2/bitops.h |5 -
include/asm-sh/bitops.h |2 ++
include/asm-sparc/bitops.h |4
include/linux/bitops.h | 37 +
11 files changed, 67 insertions(+), 2 deletions(-)
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index 04ae68c..b3a9578 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -17,6 +17,8 @@
#ifdef __KERNEL__
+#include asm/types.h
+
#define smp_mb__before_clear_bit() do { } while (0)
#define smp_mb__after_clear_bit() do { } while (0)
@@ -126,6 +128,8 @@ static inline unsigned long ffz(unsigned long word)
#define ffs(x) generic_ffs(x)
+#define fls(x) generic_fls(x)
+
/*
* hweightN: returns the hamming weight (i.e. the number
* of bits set) of a N-bit word
diff --git a/include/asm-avr32/bitops.h b/include/asm-avr32/bitops.h
index b1cf2fb..5fa20e2 100644
--- a/include/asm-avr32/bitops.h
+++ b/include/asm-avr32/bitops.h
@@ -26,4 +26,8 @@
#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
+
#endif /* __ASM_AVR32_BITOPS_H */
diff --git a/include/asm-i386/bitops.h b/include/asm-i386/bitops.h
index b768e20..71c2256 100644
--- a/include/asm-i386/bitops.h
+++ b/include/asm-i386/bitops.h
@@ -350,6 +350,8 @@ static __inline__ int ffs(int x)
return r+1;
}
+#define fls(x) generic_fls(x)
+
/**
* hweightN - returns the hamming weight of a N-bit word
* @x: the word to weigh
diff --git a/include/asm-m68k/bitops.h b/include/asm-m68k/bitops.h
index fb472e6..a38a62a 100644
--- a/include/asm-m68k/bitops.h
+++ b/include/asm-m68k/bitops.h
@@ -56,6 +56,8 @@ extern __inline__ int ffs(int x)
}
#define __ffs(x) (ffs(x) - 1)
+#define fls(x) generic_fls(x)
+
#endif /* __KERNEL__ */
#endif /* _M68K_BITOPS_H */
diff --git a/include/asm-microblaze/bitops.h b/include/asm-microblaze/bitops.h
index 04ea020..e277ab8 100644
--- a/include/asm-microblaze/bitops.h
+++ b/include/asm-microblaze/bitops.h
@@ -266,6 +266,8 @@ found_middle:
#define ffs(x) generic_ffs(x)
+#define fls(x) generic_fls(x)
+
/*
* hweightN: returns the hamming weight (i.e. the number
* of bits set) of a N-bit word
diff --git a/include/asm-mips/bitops.h b/include/asm-mips/bitops.h
index 659ac9d..76b9baa 100644
--- a/include/asm-mips/bitops.h
+++ b/include/asm-mips/bitops.h
@@ -716,6 +716,8 @@ static __inline__ unsigned long ffz(unsigned long word)
#define ffs(x) generic_ffs(x)
+#define fls(x) generic_fls(x)
+
/*
* hweightN - returns the hamming weight of a N-bit word
* @x: the word to weigh
diff --git a/include/asm-nios/bitops.h b/include/asm-nios/bitops.h
index 76c52c2..33714c4 100644
--- a/include/asm-nios/bitops.h
+++ b/include/asm-nios/bitops.h
@@ -32,7 +32,10 @@ extern void change_bit(unsigned long nr, volatile void
*addr);
extern int test_and_set_bit(int nr, volatile void * a);
extern int test_and_change_bit(int nr, volatile void * addr);
extern int test_bit(int nr, volatile void * a);
-extern int ffs(int i);
+
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
#define __set_bit(nr, addr) generic_set_bit(nr, addr)
diff --git a/include/asm-nios2/bitops.h b/include/asm-nios2/bitops.h
index da04b40..1fac52c 100644
--- a/include/asm-nios2/bitops.h
+++ b/include/asm-nios2/bitops.h
@@ -32,7 +32,10 @@ extern void change_bit(unsigned long nr, volatile void
*addr);
extern int test_and_set_bit(int nr, volatile void * a);
extern int test_and_change_bit(int nr, volatile void * addr);
extern int test_bit(int nr, volatile void * a);
-extern int ffs(int i);
+
+#define ffs(x) generic_ffs(x)
+
+#define fls(x) generic_fls(x)
#define __set_bit(nr, addr) generic_set_bit(nr, addr)
diff --git a/include/asm-sh/bitops.h b/include/asm-sh/bitops.h
index f102e7e..8021455 100644
--- a/include/asm-sh/bitops.h
+++ b/include/asm-sh/bitops.h
@@ -147,6 +147,8 @@ static inline int ffs (int x)
return r;
}
+#define fls(x) generic_fls(x)
+
#define __set_bit(nr, addr) generic_set_bit(nr, addr)
#define __clear_bit(nr, addr) generic_clear_bit(nr, addr)
diff --git a/include/asm-sparc/bitops.h b/include/asm-sparc/bitops.h
index b1bcb53..942029f 100644
--- a/include/asm-sparc/bitops.h
+++ b/include/asm-sparc/bitops.h
@@ -30,4 +30,8 @@
#define
[U-Boot] [PATCH v2 4/4]: Define test_and_set_bit and test_and_clear bit for ARM
Needed for (e.g.) ubifs support to work.
Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net
---
include/asm-arm/bitops.h | 27 ---
1 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/include/asm-arm/bitops.h b/include/asm-arm/bitops.h
index b3a9578..b62ff90 100644
--- a/include/asm-arm/bitops.h
+++ b/include/asm-arm/bitops.h
@@ -18,6 +18,7 @@
#ifdef __KERNEL__
#include asm/types.h
+#include asm/proc/system.h
#define smp_mb__before_clear_bit() do { } while (0)
#define smp_mb__after_clear_bit() do { } while (0)
@@ -55,8 +56,6 @@ static inline void __change_bit(int nr, volatile void *addr)
*p ^= mask;
}
-extern int test_and_set_bit(int nr, volatile void * addr);
-
static inline int __test_and_set_bit(int nr, volatile void *addr)
{
unsigned long mask = BIT_MASK(nr);
@@ -67,7 +66,17 @@ static inline int __test_and_set_bit(int nr, volatile void
*addr)
return (old mask) != 0;
}
-extern int test_and_clear_bit(int nr, volatile void * addr);
+static inline int test_and_set_bit(int nr, volatile void * addr)
+{
+ unsigned long flags;
+ int out;
+
+ local_irq_save(flags);
+ out = __test_and_set_bit(nr, addr);
+ local_irq_restore(flags);
+
+ return out;
+}
static inline int __test_and_clear_bit(int nr, volatile void *addr)
{
@@ -79,6 +88,18 @@ static inline int __test_and_clear_bit(int nr, volatile void
*addr)
return (old mask) != 0;
}
+static inline int test_and_clear_bit(int nr, volatile void * addr)
+{
+ unsigned long flags;
+ int out;
+
+ local_irq_save(flags);
+ out = __test_and_clear_bit(nr, addr);
+ local_irq_restore(flags);
+
+ return out;
+}
+
extern int test_and_change_bit(int nr, volatile void * addr);
static inline int __test_and_change_bit(int nr, volatile void *addr)
--
1.6.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding support for DevKit8000
On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote:
board/omap3/devkit8000/Makefile | 52 +
board/omap3/devkit8000/config.mk| 35
board/omap3/devkit8000/devkit8000.c | 124
board/omap3/devkit8000/devkit8000.h | 373
+++
no need board are allow in board/omap3
please create your own vendor dirent or just put it in board/
What do you mean with that?
On Thu, Aug 20, 2009 at 7:18 AM, Jean-Christophe
PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote:
+void reset_phy(void)
+{
+ eth_init(gd-bd);
+}
NACK
the net need to be init only when you use it
The kernel will try to use the already (temporally) programmed MAC address.
I always init it because that way no kernel hack for the MAC address
is required.
Is it ok if I add a comment?
no sorry
this will be also nack by Wolfgang
to program the mac you need to create a initramfs in your kernel wich generate
the same thing or read the content of the U-Boot env via fw_printenv
and use ifconfig hw ether
ok, I think this will break nfsroot.
I don't think it's possible to init ethernet with a initramfs before
mounting the rootfs.
There are several boards doing the same because of nfsroot:
board/ronetix/pm9261/pm9261.c
board/ronetix/pm9263/pm9263.c
board/afeb9260/afeb9260.c
board/atmel/at91cap9adk/at91cap9adk.c
board/atmel/at91sam9260ek/at91sam9260ek.c
board/atmel/at91sam9261ek/at91sam9261ek.c
board/atmel/at91sam9263ek/at91sam9263ek.c
board/atmel/at91sam9m10g45ek/at91sam9m10g45ek.c
Is there any command to call eth_init() in a script?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Wednesday, August 19, 2009 12:50 PM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik;
Ronen Shitrit
Subject: Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add
SYSRSTn Duration Counter Support
Dear Prafulla Wadaskar,
In message
1250679240-17557-1-git-send-email-prafu...@marvell.com you wrote:
I am sorry for previous post v2, pls ignore it, this is the
right patch for the same
This comment does not belong to the commit message. Please move below
the --- line.
Okay I will add this in my next post
This feature can be used to trigger special command
sysrstcmd using
reset key long press event and environment variable
sysrstdelay is set
(useful for reset to factory or manufacturing mode execution)
Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
The counter value is stored in the SYSRSTn Length Counter Register
The counter is based on the 25-MHz reference clock (40ns)
It is a 29-bit counter, yielding a maximum counting duration of
2^29/25 MHz (21.4 seconds). When the counter reach its
maximum value,
it remains at this value until counter reset is triggered by setting
bit 31 of KW_REG_SYSRST_CNT
Implementation:
Upon long reset assertion ( ${sysrstdleay} in secs)
sysrstcmd will be
That's a typo, it's sysrstdelay, right? Please fix while we are at
it.
Thanks.. I will take care
+static void kw_sysrst_action(void)
+{
+ int ret;
+ char *s = getenv(sysrstcmd);
+
+ if (!s) {
+ printf(Error.. %s failed, check sysrstcmd\n,
+ __FUNCTION__);
+ return;
Why is this considered an error? I think it is perfectly legal to not
define this environment variable. For example, it is also no error to
set bootdelay and not define bootcmd. I think we should implement
consistent behaviour.
It is similar with one difference- sysrstcmd is additionally gated with h/w
trigger,
Secondly it is not as known as bootcmd, so it is always better to throw some
error message.
This save some of developer's time and email exchanges :-)
+ }
+
+ printf(Starting %s process...\n, __FUNCTION__);
This should be a debug(), I think. Don't produce too much output.
+ if (ret 0)
+ printf(Error.. %s failed\n, __FUNCTION__);
+ else
+ printf(%s process finished\n, __FUNCTION__);
Ditto - please turn into debug().
Okay no issues..I will do it
+
+static void kw_sysrst_check(void)
+{
+ u32 sysrst_cnt, sysrst_dly;
+ char *s;
+
+ /*
+* no action if sysrstdelay environment variable is not defined
+*/
+ s = getenv(sysrstdelay);
+ if (s == NULL)
+ return;
+
+ /* read sysrstdelay value */
+ sysrst_dly = (u32) simple_strtoul(s, NULL, 10);
+
+ /* read SysRst Length counter register (bits 28:0) */
+ sysrst_cnt = (0x1fff readl(KW_REG_SYSRST_CNT));
+ printf(H/w Rst hold time: %d.%d secs\n,
+ sysrst_cnt / SYSRST_CNT_1SEC_VAL,
+ sysrst_cnt % SYSRST_CNT_1SEC_VAL);
This should be debvug(), too ?
Does it harm if we keep this info?
It is just like cpu name, speed etc.
SysRST is a feature provided by h/w that we are supporting,
It may help users who are willing to use this feature
Any way it is gated by sysrstdelay
So I think we must keep this print alive
Regards..
Prafulla . .
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
If a person (a) is poorly, (b) receives treatment intended to make
him better, and (c) gets better, then no power of reasoning known to
medical science can convince him that it may not have been the
treatment that restored his health.
- Sir Peter Medawar, The Art of the Soluble
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] mpc83xx: tqm8349 - remove pci flash window conflict
Dear Kim Phillips, In message 20090819200321.a0900c41.kim.phill...@freescale.com you wrote: commit 9993e196da707a0a1cd4584f1fcef12382c1c144 mpc83xx: convert all remaining boards over to 83XX_GENERIC_PCI remapped pci windows on tqm834x to make it more consistent with the other 83xx boards. During that time however, the author failed to realize that FLASH_BASE was occupying the same range as what PCI1_MEM_BASE was being assigned. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- WD, if you have time, please test - I don't have a tqm834x board. TIA. include/configs/TQM834x.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Tested-by: Wolfgang Denk w...@denx.de I can verify that the original problem (non working flash support) gets fixed by this patch: without the patch: U-Boot 2009.06-00513-g982adfc (Jul 24 2009 - 15:42:41) MPC83XX Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c1, MPC8349E, Rev: 1.1 at 533.328 MHz, CSB: 266.664 MHz Board: TQM834x PCI1: 32 bit, 33 MHz I2C: ready DRAM: 256 MB FLASH: ## Unknown FLASH on Bank 1 - Size = 0x0200 = 0 MB 32 MB PCI: Bus Dev VenId DevId Class Int 00 0b 104c ac55 0607 ff 00 0b 104c ac55 0607 ff DTT: 1 is 27 C Net: TSEC0, TSEC1 ... with the patch: U-Boot 2009.08-rc2-00026-g5c023da (Aug 20 2009 - 10:41:53) MPC83XX Reset Status: External/Internal Soft, External/Internal Hard CPU: e300c1, MPC8349E, Rev: 1.1 at 533.328 MHz, CSB: 266.664 MHz Board: TQM834x PCI1: 32 bit, 33 MHz I2C: ready DRAM: 256 MB FLASH: 32 MB PCI: Bus Dev VenId DevId Class Int 00 0b 104c ac55 0607 ff 00 0b 104c ac55 0607 ff DTT: 1 is 34 C Net: TSEC0, TSEC1 ... But I have a question (unrelated to this patch): With recent versions of U-Boot I see unstable network behaviour: = run load TSEC0: No link. TSEC1: No link. = run load Speed: 1000, full duplex Using TSEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.205.1 Filename 'tqm834x/u-boot.bin'. Load address: 0x20 Loading: ##Got error 4 done Bytes transferred = 253376 (3ddc0 hex) = run load Speed: 1000, full duplex Using TSEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.205.1 Filename 'tqm834x/u-boot.bin'. Load address: 0x20 Loading: #Got error 4 #Got error 4 Got error 4 T T done Bytes transferred = 253376 (3ddc0 hex) = run load Speed: 1000, full duplex Using TSEC0 device TFTP from server 192.168.1.1; our IP address is 192.168.205.1 Filename 'tqm834x/u-boot.bin'. Load address: 0x20 Loading: ###Got error 4 #Got error 4 Got error 4 Got error 4 #Got error 4 # done Bytes transferred = 253376 (3ddc0 hex) Do you have any idea what might go wrong here? [Sorry, I didn't find time yet to try bisecting this, but maybe this rings a bell to you?] Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de EARTH smog | bricks AIR -- mud -- FIRE soda water | tequila WATER ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] [repost]: arm: kirkwood: See to it that sent data is 8-byte aligned
-Original Message-
From: u-boot-boun...@lists.denx.de
[mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Kagstrom
Sent: Thursday, August 20, 2009 1:44 PM
To: U-Boot ML
Subject: [U-Boot] [PATCH 3/3] [repost]: arm: kirkwood: See to
it that sent data is 8-byte aligned
U-boot might use non-8-byte-aligned addresses for sending data, which
the kwgbe_send doesn't accept (bootp does this for me). This patch
copies the data to be sent to a malloced temporary buffer if it is
non-aligned.
snip...
diff --git a/drivers/net/kirkwood_egiga.h
b/drivers/net/kirkwood_egiga.h
index 9c893d1..16d5214 100644
--- a/drivers/net/kirkwood_egiga.h
+++ b/drivers/net/kirkwood_egiga.h
@@ -499,6 +499,7 @@ struct kwgbe_device {
struct kwgbe_rxdesc *p_rxdesc;
struct kwgbe_rxdesc *p_rxdesc_curr;
u8 *p_rxbuf;
+ u8 *p_aligned_txbuf;
};
#endif /* __EGIGA_H__ */
--
1.6.0.4
Ack,
Technically this patch is okay,
Unless we all agree this to be done in low level drivers :-)
Regards..
Prafulla . .
___
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 mkimage branch] tools/mkimage: fix compiler warnings, use const
Dear Prafulla, In message 73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell.com you wrote: This fixes some compiler warnings: tools/default_image.c:141: warning: initialization from incompatible pointer type tools/fit_image.c:202: warning: initialization from incompatible pointer type and changes to code to use const attributes in a few places where it's appropriate. 99% of the changes in this patch is to add const attributes. Yes, indeed. Can you pls explain here- how useful it is to add const. Well, adding const where appropriate is definitely a good thing, as it const augments data-hiding and encapsulation and allows the compiler to check for (and prevent!) unintended modification of data structures, i. e. for programming errors. Also, it helps the compiler for better optimization. Or do it make more sense just to fix the warnings in respective functions? I have posted a patch for the same I did not see any patch form you addressing these warnings? My const-adding patch was the more or less direct result of getting rid of the warnings without using additional type casts. I think using const is a good thing. I am aware that it sometimes becomes painful, and some consider it a waste of time. 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 God made machine language; all the rest is the work of man. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting to Broadcom BCM7038 (Hermes board)
Not quite. A quick check reveals that the bcm7038 is a r5000 based mips64 bit at heart (I'm a little confused here, there seem to be also 32bit r5000?). So not only will you be doing a new cpu port (level 2), but really a new architecture , i.e. mips64 - so you enter the game at level 3 ;) That's not quite correct. IIRC, the purple board also uses a 64bit MIPS processor (5Kc). So it's just anothe rnew board port. The core in the BCM7038 is a 5Kf, I'm not sure how the minor revision effects something like UBoot, would any registers be different? As for it being 64bit, the current bootloader is being compiled with a 32bit version of mipsel-uclibc-gcc, so it runs 32bit code fine. Would this be easier, or does the fact it's a 64bit processor mean there's other changes which need to be taken into account in UBoot? And of course there is a number of companies who are specialized in performing such ports, um... I'd prefer to perform this port myself (if possible!) it's no fun being a hobbiest when you get someone else to do all your work. SATA drivers will go below drivers/block, but yes, this is the theory. Ok I think I get it now, in the cpu directory goes the code specific for bringing up the cpu, using the cache, etc. So the board directory would contain code for accessing the flash, init'ing memory, etc. And drivers would go into drivers/ as you said. There's one fundamental thing I still need to get sorted in my head, what exactly is the role of UBoot? Is it just there to assist in creating a bootloader? So the cpu code would do the main bringup, board specific code would init the memory then use drivers provided by UBoot to access what it needs to load the kernel, then calls code in UBoot to start it? Or does UBoot perform a more invasive role than that? Thank you for your help so far. -- Regards, Peter Belm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
Dear Prafulla Wadaskar,
In message 73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell.com
you wrote:
+ if (!s) {
+ printf(Error.. %s failed, check sysrstcmd\n,
+ __FUNCTION__);
+ return;
Why is this considered an error? I think it is perfectly legal to not
define this environment variable. For example, it is also no error to
set bootdelay and not define bootcmd. I think we should implement
consistent behaviour.
It is similar with one difference- sysrstcmd is additionally gated with h/w
trigger,
Um... yes... agreed, but that's not actually so special. Consider for
example the use of altbootcmd in connection with the boot count limit
feature, or the failbootcmd which gets run in case of critical POST
errors. None of these produce any such error messages. For consistency
I recommend to remove this message here, too.
Secondly it is not as known as bootcmd, so it is always better to throw some
error message.
This save some of developer's time and email exchanges :-)
Well, for developers it may be useful during test - but it should not
be present for regular users of the production version. Maybe you
change it into a debug() ?
...
+ sysrst_cnt = (0x1fff readl(KW_REG_SYSRST_CNT));
+ printf(H/w Rst hold time: %d.%d secs\n,
+ sysrst_cnt / SYSRST_CNT_1SEC_VAL,
+ sysrst_cnt % SYSRST_CNT_1SEC_VAL);
This should be debvug(), too ?
Does it harm if we keep this info?
Well, yes, it does. It adds output, which makes the boot process more
noisy and addds to the boot time. And normally none of the end users
will actually ever look at this information.
It is just like cpu name, speed etc.
Well, this _is_ information which the end users regularly check and
pay attention to.
SysRST is a feature provided by h/w that we are supporting,
It may help users who are willing to use this feature
Any way it is gated by sysrstdelay
So I think we must keep this print alive
Really? What is the advantage for the enduser to know if he pressed
the button for 5.1 or 5.3 seconds?
Please make it a debug().
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
...this does not mean that some of us should not want, in a rather
dispassionate sort of way, to put a bullet through csh's head.
- Larry Wall in 1992aug6.221512.5...@netlabs.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3]: arm:kirkwood Define kirkwood phy address magic number
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Simon Kagstrom Sent: Thursday, August 20, 2009 1:42 PM Cc: U-Boot ML Subject: [U-Boot] [PATCH 1/3]: arm:kirkwood Define kirkwood phy address magic number Signed-off-by: Simon Kagstrom simon.kagst...@netinsight.net --- drivers/net/kirkwood_egiga.c | 14 ++ 1 files changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/net/kirkwood_egiga.c b/drivers/net/kirkwood_egiga.c index f31fefc..065e335 100644 --- a/drivers/net/kirkwood_egiga.c +++ b/drivers/net/kirkwood_egiga.c @@ -38,6 +38,8 @@ #include asm/arch/kirkwood.h #include kirkwood_egiga.h +#define KIRKWOOD_PHY_ADR_REQUEST 0xee define this in header file Basically this is needed in drivers/net/phy/mv88e61xx.c for multi chip support in this case we need to define this in include/miiphy.h. which conflicts with other phy address definition, that's why not done earlier It makes more sense to add APIs miiphy_read/write_phyadr to miiutils Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting to Broadcom BCM7038 (Hermes board)
Dear Peter Belm, In message 574bb010908200229m7da12930s39f7bc40a2384...@mail.gmail.com you wrote: That's not quite correct. IIRC, the purple board also uses a 64bit MIPS processor (5Kc). So it's just anothe rnew board port. The core in the BCM7038 is a 5Kf, I'm not sure how the minor revision effects something like UBoot, would any registers be different? As for it Well, _all_ hardware differences affect U-Boot. You will need a really detailed understanding of the processor and your board. being 64bit, the current bootloader is being compiled with a 32bit version of mipsel-uclibc-gcc, so it runs 32bit code fine. Would this be easier, or Right. That's what we do in case of the purple board, too. does the fact it's a 64bit processor mean there's other changes which need to be taken into account in UBoot? This obviously depends on your hardware design. We cannot answer this question. Ok I think I get it now, in the cpu directory goes the code specific for bringing up the cpu, using the cache, etc. So the board directory would contain code for accessing the flash, init'ing memory, etc. And drivers would go into drivers/ as you said. Assuming you use standard flash chips, no code to access the flash should co to the board directory. You should use the existing standard drivers instead. There's one fundamental thing I still need to get sorted in my head, what exactly is the role of UBoot? Is it just there to assist in creating a bootloader? So the cpu code would do the main bringup, board specific code U-Boot _is_ the boot loader. would init the memory then use drivers provided by UBoot to access what it needs to load the kernel, then calls code in UBoot to start it? Or does UBoot perform a more invasive role than that? All the tasks you mention here are performed by U-Boot. U-Boot _is_ the boot loader. 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 Microsoft Multitasking: several applications can crash at the same time. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
-Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Thursday, August 20, 2009 10:50 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: v2: updated as per review feedback for v1 bug fix in the previous post (V2) fixed ok but I think make optionnal will be better Hi Jean Thanks.. I didn't understod what you want to say here, can you pls explain? the patch is fine for I but I think we may create a CONFIG_ somethink to enable it only if the use want it and do not impact the U-Boot size otherwise Okay I got it WE can do this but, There are just two APIs, overall size impact is not much (100 bytes max). And this is very useful feature. So can we make it by default enabled? Regards... Prafulla .. Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Porting to Broadcom BCM7038 (Hermes board)
All the tasks you mention here are performed by U-Boot. U-Boot _is_ the boot loader. Right, I'm just having trouble getting to grips with the code flow, the start.S in the CPU is the initial entry point, at what point does that hand over to U-Boot? Any chance you could give me a brief overview of the code flow? In particular where the code I need to write fits in with the boot process, i.e. where I need to interface with U-Boot. Once I've got a better idea of how U-Boot boots, I should be able to get started at least. -- Regards, Peter Belm ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH mkimage branch] tools/mkimage: fix compiler warnings, use const
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, August 20, 2009 2:58 PM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH mkimage branch] tools/mkimage: fix compiler warnings, use const Dear Prafulla, In message 73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell. com you wrote: This fixes some compiler warnings: tools/default_image.c:141: warning: initialization from incompatible pointer type tools/fit_image.c:202: warning: initialization from incompatible pointer type and changes to code to use const attributes in a few places where it's appropriate. 99% of the changes in this patch is to add const attributes. Yes, indeed. Can you pls explain here- how useful it is to add const. Well, adding const where appropriate is definitely a good thing, as it const augments data-hiding and encapsulation and allows the compiler to check for (and prevent!) unintended modification of data structures, i. e. for programming errors. Also, it helps the compiler for better optimization. Ack Or do it make more sense just to fix the warnings in respective functions? I have posted a patch for the same I did not see any patch form you addressing these warnings? It's in my mailq :-(, I will repost it just FYI Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1 v2][Net] Convert CS8900 Ethernet driver to CONFIG_NET_MULTI API
Dear Ben Warren, In message f8328f7c0908132336k18e260d4xac72469559404...@mail.gmail.com you wrote: I looked at a disassembly of this code and it looked like it should work. In this case, the base offset of the device is in r2 (0x07000300) and the code does store operations on this +#4 and +#6, which were the offsets in the original. I guess it would be useful to printf something like: printf(addr = %#08x\n, priv-regs-txcmd) just to make sure it's 0x07000304. Other than that, I'm stumped. I'll review the code again to see if anything jumps out. Hm... adding this patch: diff --git a/drivers/net/cs8900.c b/drivers/net/cs8900.c index 5b9c4cb..0f86c39 100644 --- a/drivers/net/cs8900.c +++ b/drivers/net/cs8900.c @@ -215,6 +215,11 @@ static int cs8900_send(struct eth_device *dev, struct cs8900_priv *priv = (struct cs8900_priv *)(dev-priv); retry: + printf(priv=%#08x regs=%#08x txcmd=%#08x\n, + (unsigned int)priv, + (unsigned int)(priv-regs), + (unsigned int)(priv-regs-txcmd)); + /* initiate a transmit sequence */ writel(PP_TxCmd_TxStart_Full, priv-regs-txcmd); writel(length, priv-regs-txlen); And testing on the mx31ads board I get this: = run load Using CS8900-0 device TFTP from server 192.168.1.1; our IP address is 192.168.20.9 Filename 'mx31ads/u-boot.bin'. Load address: 0x8080 Loading: priv=0x87ed8100 regs=0xb4020300 txcmd=0xb4020304 hangs 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 On the subject of C program indentation: In My Egotistical Opinion, most people's C programs should be indented six feet downward and covered with dirt. - Blair P. Houghton ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 83xx and LCRR setting
Hello Kim, Kim Phillips schrieb: On Tue, 18 Aug 2009 15:23:47 +0200 Heiko Schocher h...@denx.de wrote: Hello Kim, Hello Heiko, sorry for the late reply, I actually work on an u-boot mpc8321 port (mostly identical with the kmeter1 port already in mainline), and I have to set the LCRR (Clock Ratio Register Reference Manual 10.3.1.14). As I see in cpu/mpc83xx/cpu_init.c cpu_init_f() this is done while running from flash. Hmm... the Reference manual says in chapter 10.3.1.14 page 474: NOTE For proper operation of the system, this register setting must not be altered while local bus memories or devices are being accessed. Special care needs to be taken when running instructions from an local bus controller memory. Hmm... On my board (and for example on the MPC832XEMDS) the flash is connected to the localbus ... and this register setting is done, while running from flash ... Hmm.. is this safe? yeah, I'm not quite sure how that works myself! I stumbled over this, just because I didn;t set this LCRR_DBYP bit, which the CPU sets after a reset, so what Do you think about this patch? 832x, LCRR: change only the valid bits for this register Signed-off-by: Heiko Schocher h...@denx.de --- cpu/mpc83xx/cpu_init.c|6 ++ include/asm-ppc/fsl_lbc.h |4 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/cpu/mpc83xx/cpu_init.c b/cpu/mpc83xx/cpu_init.c index ea4f2af..b5f64a8 100644 --- a/cpu/mpc83xx/cpu_init.c +++ b/cpu/mpc83xx/cpu_init.c @@ -193,8 +193,14 @@ void cpu_init_f (volatile immap_t * im) */ im-reset.rmr = (RMR_CSRE (1RMR_CSRE_SHIFT)); +#if defined(CONFIG_MPC832x) + /* LCRR - Clock Ratio Register (10.3.1.14) */ + im-lbus.lcrr = (im-lbus.lcrr LCRR_MASK) | \ + (CONFIG_SYS_LCRR ~LCRR_MASK); +#else /* LCRR - Clock Ratio Register (10.3.1.16) */ im-lbus.lcrr = CONFIG_SYS_LCRR; +#endif /* Enable Time Base Decrimenter ( so we will have udelay() )*/ im-sysconf.spcr |= SPCR_TBEN; diff --git a/include/asm-ppc/fsl_lbc.h b/include/asm-ppc/fsl_lbc.h index a28082e..2c7a94b 100644 --- a/include/asm-ppc/fsl_lbc.h +++ b/include/asm-ppc/fsl_lbc.h @@ -315,6 +315,10 @@ #define LCRR_CLKDIV_4 0x0004 #define LCRR_CLKDIV_8 0x0008 +#if defined(CONFIG_MPC832x) +#define LCRR_MASK 0xFFFCFFF0 +#endif + /* LTEDR - Transfer Error Check Disable Register */ #define LTEDR_BMD 0x8000 /* Bus monitor disable */ -- 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
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
-Original Message-
From: Wolfgang Denk [mailto:w...@denx.de]
Sent: Thursday, August 20, 2009 3:08 PM
To: Prafulla Wadaskar
Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik;
Ronen Shitrit
Subject: Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add
SYSRSTn Duration Counter Support
Dear Prafulla Wadaskar,
In message
73173d32e9439e4abb5151606c3e19e202e3915...@sc-vexch1.marvell.
com you wrote:
+ if (!s) {
+ printf(Error.. %s failed, check sysrstcmd\n,
+ __FUNCTION__);
+ return;
Why is this considered an error? I think it is perfectly
legal to not
define this environment variable. For example, it is also
no error to
set bootdelay and not define bootcmd. I think we
should implement
consistent behaviour.
It is similar with one difference- sysrstcmd is
additionally gated with h/w trigger,
Um... yes... agreed, but that's not actually so special. Consider for
example the use of altbootcmd in connection with the boot
count limit
feature, or the failbootcmd which gets run in case of critical POST
errors. None of these produce any such error messages. For consistency
I recommend to remove this message here, too.
Secondly it is not as known as bootcmd, so it is always
better to throw some error message.
This save some of developer's time and email exchanges :-)
Well, for developers it may be useful during test - but it should not
be present for regular users of the production version. Maybe you
change it into a debug() ?
Agreed I will do this.
...
+ sysrst_cnt = (0x1fff readl(KW_REG_SYSRST_CNT));
+ printf(H/w Rst hold time: %d.%d secs\n,
+ sysrst_cnt / SYSRST_CNT_1SEC_VAL,
+ sysrst_cnt % SYSRST_CNT_1SEC_VAL);
This should be debvug(), too ?
Does it harm if we keep this info?
Well, yes, it does. It adds output, which makes the boot process more
noisy and addds to the boot time. And normally none of the end users
will actually ever look at this information.
That's understood but only in case sysrstdelay is defined which is not default
case :-)
It is just like cpu name, speed etc.
Well, this _is_ information which the end users regularly check and
pay attention to.
SysRST is a feature provided by h/w that we are supporting,
It may help users who are willing to use this feature
Any way it is gated by sysrstdelay
So I think we must keep this print alive
Really? What is the advantage for the enduser to know if he pressed
the button for 5.1 or 5.3 seconds?
No, I mean it is useful in case of 4.9 or 5.1 :-)
Please make it a debug().
Should I? even though by default it will not show up :-)
Regards..
Prafulla . .
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
...this does not mean that some of us should not want, in a rather
dispassionate sort of way, to put a bullet through csh's head.
- Larry Wall in 1992aug6.221512.5...@netlabs.com
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] arm: Kirkwood: add SYSRSTn Duration Counter Support
This feature can be used to trigger special command sysrstcmd using
reset key long press event and environment variable sysrstdelay is set
(useful for reset to factory or manufacturing mode execution)
Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
The counter value is stored in the SYSRSTn Length Counter Register
The counter is based on the 25-MHz reference clock (40ns)
It is a 29-bit counter, yielding a maximum counting duration of
2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
it remains at this value until counter reset is triggered by setting
bit 31 of KW_REG_SYSRST_CNT
Implementation:
Upon long reset assertion ( ${sysrstdelay} in secs) sysrstcmd will be
executed if pre-defined in environment variables.
This feature will be disabled if sysrstdelay variable is unset.
for-ex.
setenv sysrst_cmd echo starting factory reset;
nand erase 0xa 0x2;
echo finish ed sysrst command;
will erase particular nand sector if triggered by this event
Signed-off-by: Prafulla Wadaskar prafu...@marvell.com
---
Change log:
v2: updated as per review feedback for v1
bug fix in the previous post (V2) fixed
v2 repost:
I am sorry for previous post v2, pls ignore it, this is the right patch for the
same
v3: updated as per review feedback for v2
all possible messages termed as debug
cpu/arm926ejs/kirkwood/cpu.c| 75 +++
include/asm-arm/arch-kirkwood/cpu.h |2 +
2 files changed, 77 insertions(+), 0 deletions(-)
diff --git a/cpu/arm926ejs/kirkwood/cpu.c b/cpu/arm926ejs/kirkwood/cpu.c
index 795a739..3b978e2 100644
--- a/cpu/arm926ejs/kirkwood/cpu.c
+++ b/cpu/arm926ejs/kirkwood/cpu.c
@@ -195,6 +195,78 @@ int kw_config_mpp(u32 mpp0_7, u32 mpp8_15, u32 mpp16_23,
u32 mpp24_31,
return 0;
}
+/*
+ * SYSRSTn Duration Counter Support
+ *
+ * Kirkwood SoC implements a hardware-based SYSRSTn duration counter.
+ * When SYSRSTn is asserted low, a SYSRSTn duration counter is running.
+ * The SYSRSTn duration counter is useful for implementing a manufacturer
+ * or factory reset. Upon a long reset assertion that is greater than a
+ * pre-configured environment variable value for sysrstdelay,
+ * The counter value is stored in the SYSRSTn Length Counter Register
+ * The counter is based on the 25-MHz reference clock (40ns)
+ * It is a 29-bit counter, yielding a maximum counting duration of
+ * 2^29/25 MHz (21.4 seconds). When the counter reach its maximum value,
+ * it remains at this value until counter reset is triggered by setting
+ * bit 31 of KW_REG_SYSRST_CNT
+ */
+static void kw_sysrst_action(void)
+{
+ int ret;
+ char *s = getenv(sysrstcmd);
+
+ if (!s) {
+ debug(Error.. %s failed, check sysrstcmd\n,
+ __FUNCTION__);
+ return;
+ }
+
+ debug(Starting %s process...\n, __FUNCTION__);
+#if !defined(CONFIG_SYS_HUSH_PARSER)
+ ret = run_command (s, 0);
+#else
+ ret = parse_string_outer(s, FLAG_PARSE_SEMICOLON
+ | FLAG_EXIT_FROM_LOOP);
+#endif
+ if (ret 0)
+ debug(Error.. %s failed\n, __FUNCTION__);
+ else
+ debug(%s process finished\n, __FUNCTION__);
+}
+
+static void kw_sysrst_check(void)
+{
+ u32 sysrst_cnt, sysrst_dly;
+ char *s;
+
+ /*
+* no action if sysrstdelay environment variable is not defined
+*/
+ s = getenv(sysrstdelay);
+ if (s == NULL)
+ return;
+
+ /* read sysrstdelay value */
+ sysrst_dly = (u32) simple_strtoul(s, NULL, 10);
+
+ /* read SysRst Length counter register (bits 28:0) */
+ sysrst_cnt = (0x1fff readl(KW_REG_SYSRST_CNT));
+ debug(H/w Rst hold time: %d.%d secs\n,
+ sysrst_cnt / SYSRST_CNT_1SEC_VAL,
+ sysrst_cnt % SYSRST_CNT_1SEC_VAL);
+
+ /* clear the counter for next valid read*/
+ writel(1 31, KW_REG_SYSRST_CNT);
+
+ /*
+* sysrst_action:
+* if H/w Reset key is pressed and hold for time
+* more than sysrst_dly in seconds
+*/
+ if (sysrst_cnt = SYSRST_CNT_1SEC_VAL * sysrst_dly)
+ kw_sysrst_action();
+}
+
#if defined(CONFIG_DISPLAY_CPUINFO)
int print_cpuinfo(void)
{
@@ -298,6 +370,9 @@ int arch_misc_init(void)
temp = get_cr();
set_cr(temp ~CR_V);
+ /* checks and execute resset to factory event */
+ kw_sysrst_check();
+
return 0;
}
#endif /* CONFIG_ARCH_MISC_INIT */
diff --git a/include/asm-arm/arch-kirkwood/cpu.h
b/include/asm-arm/arch-kirkwood/cpu.h
index d1440af..b3022a3 100644
--- a/include/asm-arm/arch-kirkwood/cpu.h
+++ b/include/asm-arm/arch-kirkwood/cpu.h
@@ -36,6 +36,8 @@
((_x ? KW_EGIGA0_BASE : KW_EGIGA1_BASE) + 0x44c)
#define KW_REG_DEVICE_ID (KW_MPP_BASE + 0x34)
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Prafulla Wadaskar Sent: Thursday, August 20, 2009 3:16 PM To: Jean-Christophe PLAGNIOL-VILLARD Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support -Original Message- From: Jean-Christophe PLAGNIOL-VILLARD [mailto:plagn...@jcrosoft.com] Sent: Thursday, August 20, 2009 10:50 AM To: Prafulla Wadaskar Cc: u-boot@lists.denx.de; Ashish Karkare; Prabhanjan Sarnaik; Ronen Shitrit Subject: Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support Signed-off-by: Prafulla Wadaskar prafu...@marvell.com --- Change log: v2: updated as per review feedback for v1 bug fix in the previous post (V2) fixed ok but I think make optionnal will be better Hi Jean Thanks.. I didn't understod what you want to say here, can you pls explain? the patch is fine for I but I think we may create a CONFIG_ somethink to enable it only if the use want it and do not impact the U-Boot size otherwise Okay I got it WE can do this but, There are just two APIs, overall size impact is not much (100 bytes max). The actual u-boot.bin size diff for newly posted patch is (169464- 169344= 120 bytes) Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Incorrect CONFIG_SYS_MONITOR_LEN on MPC85xx boards
Hi, All FSL MPC85xx boards define CONFIG_SYS_MONITOR_LEN as 256K although actual size of u-boot binary is 512K. XES Xpedite boards seem to do the right thing. I was wandering whether CONFIG_SYS_MONITOR_LEN for 85xx boards can be defined in terms of CONFIG_SYS_MONITOR_BASE, similar to AMCC boards ? #define CONFIG_SYS_MONITOR_LEN(0x - CONFIG_SYS_MONITOR_BASE + 1) Felix. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] 83xx and LCRR setting
Hi Heiko, I stumbled over this, just because I didn;t set this LCRR_DBYP bit, which the CPU sets after a reset, so what Do you think about this patch? 832x, LCRR: change only the valid bits for this register Signed-off-by: Heiko Schocher h...@denx.de --- cpu/mpc83xx/cpu_init.c|6 ++ include/asm-ppc/fsl_lbc.h |4 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/cpu/mpc83xx/cpu_init.c b/cpu/mpc83xx/cpu_init.c index ea4f2af..b5f64a8 100644 --- a/cpu/mpc83xx/cpu_init.c +++ b/cpu/mpc83xx/cpu_init.c @@ -193,8 +193,14 @@ void cpu_init_f (volatile immap_t * im) */ im-reset.rmr = (RMR_CSRE (1RMR_CSRE_SHIFT)); +#if defined(CONFIG_MPC832x) + /* LCRR - Clock Ratio Register (10.3.1.14) */ + im-lbus.lcrr = (im-lbus.lcrr LCRR_MASK) | \ + (CONFIG_SYS_LCRR ~LCRR_MASK); +#else /* LCRR - Clock Ratio Register (10.3.1.16) */ im-lbus.lcrr = CONFIG_SYS_LCRR; +#endif Please don't invent yet another conditional here. Why not do a #if defined LCCR_MASK ... #endif or maybe even always use the mask, define it in the board config and do a #if !defined(LCCR_MASK) #define LCCR_MASK 0x #endif This really depends if and how this applies to the other members of the 83xx family. And, by the way, we should _really_ be using accessor macros all around ;) Cheers Detlev -- Bacchus, n. A convenient deity invented by the ancients as an excuse for getting drunk. -- 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] Porting to Broadcom BCM7038 (Hermes board)
Hi Wolfgang, Dear Detlev Zundel, In message m2prardbo5@ohwell.denx.de you wrote: Not quite. A quick check reveals that the bcm7038 is a r5000 based mips64 bit at heart (I'm a little confused here, there seem to be also 32bit r5000?). So not only will you be doing a new cpu port (level 2), but really a new architecture , i.e. mips64 - so you enter the game at level 3 ;) That's not quite correct. IIRC, the purple board also uses a 64bit MIPS processor (5Kc). So it's just anothe rnew board port. Yep, I've seen this. But as this board defines CONFIG_MIPS32 in its config, I wasn't so sure about the real situation. Cheers Detlev -- Win32 sucks so hard it could pull matter out of a Black Hole. -- Pohl Longsine -- 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] Porting to Broadcom BCM7038 (Hermes board)
Hi Peter, All the tasks you mention here are performed by U-Boot. U-Boot _is_ the boot loader. Right, I'm just having trouble getting to grips with the code flow, the start.S in the CPU is the initial entry point, at what point does that hand over to U-Boot? Any chance you could give me a brief overview of the code flow? In particular where the code I need to write fits in with the boot process, i.e. where I need to interface with U-Boot. Once I've got a better idea of how U-Boot boots, I should be able to get started at least. Be sure to read the section Implementation Internals in the README. Other than that, simply trace the flow (on a piece of paper) for a comparable board, e.g. the purple board which seems to be pretty close to what you have. Another hint is that functions in U-Boot ending with _f are run from flash, wherease functions ending in _r run already relocated from RAM. I hope this gets you started. Cheers Detlev -- It's like manually inflatable airbags -- people will never think to use it in time to actually get any help from it. -- Miles Bader in 20030607122005.ga1...@gnu.org -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc4xx: Rename compactcenter to intip
Signed-off-by: Dirk Eibach eib...@gdsys.de --- include/configs/compactcenter.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/compactcenter.h b/include/configs/compactcenter.h index f8a1bbb..9d33f56 100644 --- a/include/configs/compactcenter.h +++ b/include/configs/compactcenter.h @@ -39,8 +39,8 @@ #define CONFIG_HOSTNAMEdevconcenter #define CONFIG_IDENT_STRING devconcenter 0.02 #else -#define CONFIG_HOSTNAMEcompactcenter -#define CONFIG_IDENT_STRING compactcenter 0.02 +#define CONFIG_HOSTNAMEintip +#define CONFIG_IDENT_STRING intip 0.02 #endif #define CONFIG_440 1 #define CONFIG_4xx 1 /* ... PPC4xx family */ -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Rename compactcenter to intip
Hi Dirk, On Thursday 20 August 2009 13:23:03 Dirk Eibach wrote: Signed-off-by: Dirk Eibach eib...@gdsys.de --- include/configs/compactcenter.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/configs/compactcenter.h b/include/configs/compactcenter.h index f8a1bbb..9d33f56 100644 --- a/include/configs/compactcenter.h +++ b/include/configs/compactcenter.h @@ -39,8 +39,8 @@ #define CONFIG_HOSTNAME devconcenter #define CONFIG_IDENT_STRING devconcenter 0.02 #else -#define CONFIG_HOSTNAME compactcenter -#define CONFIG_IDENT_STRING compactcenter 0.02 +#define CONFIG_HOSTNAME intip +#define CONFIG_IDENT_STRING intip 0.02 Just checking: You only want to change the printed name upon bootup from compactcenter to intip? Not the U-Boot target name? Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Rename compactcenter to intip
Just checking: You only want to change the printed name upon bootup from compactcenter to intip? Not the U-Boot target name? That's it. Since this might be sold as an OEM product, we need a more generic name to be displayed. Cheers Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3]: arm:kirkwood Define kirkwood phy address magic number
On Thu, 20 Aug 2009 02:40:48 -0700 Prafulla Wadaskar prafu...@marvell.com wrote: +#define KIRKWOOD_PHY_ADR_REQUEST 0xee define this in header file Basically this is needed in drivers/net/phy/mv88e61xx.c for multi chip support in this case we need to define this in include/miiphy.h. which conflicts with other phy address definition, that's why not done earlier It makes more sense to add APIs miiphy_read/write_phyadr to miiutils But is this really general functionality? miiphy.h is something I suppose should be generic between phys and not contain device-specific things like this. Perhaps we should revive the patches that move out the phy initialization from sheevaplug.c and place the define and some implementation there? // Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] jffs2: some fixes to summary support
Hi Mike,
Mike Frysinger wrote:
+#ifdef CONFIG_JFFS2_SUMMARY
+static u32 sum_get_unaligned32(u32 *ptr)
+{
+u32 val;
+u8 *p = (u8 *)ptr;
+
+val = *p | (*(p + 1) 8) | (*(p + 2) 16) | (*(p + 3) 24);
+
+return __le32_to_cpu(val);
+}
+
+static u16 sum_get_unaligned16(u16 *ptr)
+{
+u16 val;
+u8 *p = (u8 *)ptr;
+
+val = *p | (*(p + 1) 8);
+
+return __le16_to_cpu(val);
+}
do get_unaligned_le16 and such not work ?
Nope. They do only some typecasting and resulting code still uses word
(halfword) access instructions.
Regards, Ilya.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache
Jean-Christophe PLAGNIOL-VILLARD wrote: Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches. no this code is omap3 specific and there is no need ot this rename or move the function make no sense Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff. the flush MUST NOT be soc specific as there is NO need to do this at all so NACK Let's summarize: - First, you NACK because of device_type and function name - Then, you mention this code is omap3 specific - Then, you mention this code is not needed at all Sorry, but this sounds somehow confusing, better let us stop here. As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more. At the weekend, I missed the point why this code is OMAP3 specific and why it has to be moved to omap3 directory, so short update: It calls OMAP3 ROM code. This doesn't work on other Cortex A8, e.g. Samsung. That is, it must be moved to not stall others any more. so I'll repeat this only once there no need to call the rom code as the generic armv7 cache full work fine so no-need to use omap3 specific code I am not sure if the generic code can replace the omap3 code. I do not have access to the ROM code. From what I have seen on the l2_cache code, it seems that in some cases that the ROM code handles earlier revs of the hardware. I would be in favor of phasing in the new generic code so that if older hardware needed to use the ROM code it could. Not know knowing full effect of the change we should go slowly and provide options for legacy support up front. Tom Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH/RFC] drivers/mmc/mmc.c: change the controller frequency before the card frequency
On Thu, Aug 20, 2009 at 01:42:04AM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : On 14:16 Wed 19 Aug , Albin Tonnerre wrote: While rewriting the atmel_mci driver to use the new MMC_GENERIC API (and allow the use of SD/MMC on AT91 in the process), it appeared that switching the card frequency before the controller frequency resulted in the answer from the card never being received. Changing the controller frequency before the controller frequency fixes that. IIRC it's not correct you are supposed to switch the card to higherfreq and then the bus speed This was an error on my side, sorry for the noise. could show the patch of the atmel_mci to help It's not complete yet, but I'll be sure to post it for comments as soon as i'm done. Best Regards, J. Regards, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Regarding linux kernel booting.
Hi all, I am in bit of peculiar problem on booting linux kernel on my MPC7448-TSi108 based custom board. I am using u-boot 1.3.4 which was compiled on ELDK- 4.0. when i use bootp command to download the kernel image from the tftp server that was already working with other custom boards the kernel is not getting downloaded but if i am setting it to another environment variable i.e set ideboot bootp and try to boot using run ideboot this time the kernel image file is getting downloaded. kindly give me suggestion on this. i don't have any clue on what is happening ? The host system what ever i used for compilation is also same. Regards, T. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding linux kernel booting.
Hi Thirumalai, I am in bit of peculiar problem on booting linux kernel on my MPC7448-TSi108 based custom board. I am using u-boot 1.3.4 which was compiled on ELDK- 4.0. when i use bootp command to download the kernel image from the tftp server that was already working with other custom boards the kernel is not getting downloaded but if i am setting it to another environment variable i.e set ideboot bootp and try to boot using run ideboot this time the kernel image file is getting downloaded. kindly give me suggestion on this. i don't have any clue on what is happening ? The host system what ever i used for compilation is also same. Post a transcript of a session which shows how bootp fails and how the run ideboot succeeds. Without this, we have no idea what is not getting downloaded actually means. Apart from that this paragraph is the usual why don't you use a recent U-Boot and toolchain and is the problem then still reproducible paragraph? Hopefully, this relieves Wolfgang of writing at least one mail :) Thanks Detlev -- If you currently have a 32-bit UNIX system, you are advised to trade it in for a 64-bit one sometime before the year 2106. -- Andrew S. Tanenbaum: Modern Operating Systems, 2nd Edition -- 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] building u-boot using ELDK on 64-bit fedora 11
Hi Robert, i spent a few minutes earlier this morning building the latest u-boot for my beagleboard using the ELDK 4.2 arm toolchain on my 64-bit fedora 11 system and since google showed me there was some discussion as to how to do that on 64-bit debian, i figured i'd just verify that what i did seemed sane. i downloaded the ELDK 4.2 arm iso and installed, at which point i got numerous errors about a missing zlib library. since i already had glibc.i586 installed for other reasons, i just did: # yum install zlib.i586 at which point another attempt at installing ELDK worked fine. Is http://www.denx.de/wiki/DULG/ELDKUsageIn64BitEnvironment a correct interpretation of this text? Thanks Detlev -- debian is a prototype for a future version of emacs. -- Thien-Thi Nguyen in 7eekubiffq@ada2.unipv.it -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-40 Fax: (+49)-8142-66989-80 Email: d...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] mpc8377erdb: change DDR settings to those from latest bsp
On Aug 19, 2009, at 8:04 PM, Kim Phillips wrote: when using Linus' 83xx_defconfig, the mpc8377rdb would hanging at boot at either: NET: Registered protocol family 16 or the io scheduler cfq registered message. Fixing up these DDR settings appears to fix the problem. Signed-off-by: Kim Phillips kim.phill...@freescale.com --- include/configs/MPC837XERDB.h |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) seems like a fix for v2009.08 - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc/85xx: Added CONFIG_MAX_CPUS for P1020
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next include/asm-ppc/config.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-ppc/config.h b/include/asm-ppc/config.h index fd7961c..fb9c20e 100644 --- a/include/asm-ppc/config.h +++ b/include/asm-ppc/config.h @@ -38,8 +38,8 @@ #endif #endif -#if defined(CONFIG_MPC8572) || defined(CONFIG_P2020) \ - || defined(CONFIG_MPC8641) +#if defined(CONFIG_MPC8572) || defined(CONFIG_P2020) || \ + defined(CONFIG_P1020) || defined(CONFIG_MPC8641) #define CONFIG_MAX_CPUS2 #else #define CONFIG_MAX_CPUS1 -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc/85xx: P1020RDB Support Added
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next Makefile |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index f92ef30..337bf89 100644 --- a/Makefile +++ b/Makefile @@ -2499,6 +2499,11 @@ P2020RDB_config: unconfig @echo #define CONFIG_P2020 $(obj)include/config.h ; @$(MKCONFIG) -a P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale +P1020RDB_config: unconfig + @mkdir -p $(obj)include + @echo #define CONFIG_P1020 $(obj)include/config.h ; + @$(MKCONFIG) -a P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale + PM854_config: unconfig @$(MKCONFIG) $(@:_config=) ppc mpc85xx pm854 -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc/85xx: Added single core members of FSL P1 P2 processors series
P2010 - single core variant of P2020
P1011 - Single core variant of P1020
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
- applies on git.denx.de/u-boot-mpc85xx.git branch-next
cpu/mpc85xx/Makefile|2 ++
cpu/mpc8xxx/cpu.c |4
drivers/misc/fsl_law.c |3 ++-
include/asm-ppc/processor.h |4
4 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/cpu/mpc85xx/Makefile b/cpu/mpc85xx/Makefile
index 1477eac..df5a177 100644
--- a/cpu/mpc85xx/Makefile
+++ b/cpu/mpc85xx/Makefile
@@ -50,7 +50,9 @@ COBJS-$(CONFIG_MPC8572) += ddr-gen3.o
COBJS-$(CONFIG_MPC8536) += ddr-gen3.o
COBJS-$(CONFIG_MPC8569)+= ddr-gen3.o
COBJS-$(CONFIG_P2020) += ddr-gen3.o
+COBJS-$(CONFIG_P2010) += ddr-gen3.o
COBJS-$(CONFIG_P1020) += ddr-gen3.o
+COBJS-$(CONFIG_P1011) += ddr-gen3.o
COBJS-$(CONFIG_MPC8536) += mpc8536_serdes.o
COBJS = traps.o cpu.o cpu_init.o speed.o interrupts.o tlb.o \
diff --git a/cpu/mpc8xxx/cpu.c b/cpu/mpc8xxx/cpu.c
index fbab998..4a30215 100644
--- a/cpu/mpc8xxx/cpu.c
+++ b/cpu/mpc8xxx/cpu.c
@@ -66,8 +66,12 @@ struct cpu_type cpu_type_list [] = {
CPU_TYPE_ENTRY(8572, 8572_E, 2),
CPU_TYPE_ENTRY(P2020, P2020, 2),
CPU_TYPE_ENTRY(P2020, P2020_E, 2),
+ CPU_TYPE_ENTRY(P2010, P2010, 1),
+ CPU_TYPE_ENTRY(P2010, P2010_E, 1),
CPU_TYPE_ENTRY(P1020, P1020, 2),
CPU_TYPE_ENTRY(P1020, P1020_E, 2),
+ CPU_TYPE_ENTRY(P1011, P1011, 1),
+ CPU_TYPE_ENTRY(P1011, P1011_E, 1),
#elif defined(CONFIG_MPC86xx)
CPU_TYPE_ENTRY(8610, 8610, 1),
CPU_TYPE_ENTRY(8641, 8641, 2),
diff --git a/drivers/misc/fsl_law.c b/drivers/misc/fsl_law.c
index af7b729..72665ab 100644
--- a/drivers/misc/fsl_law.c
+++ b/drivers/misc/fsl_law.c
@@ -39,7 +39,8 @@ DECLARE_GLOBAL_DATA_PTR;
defined(CONFIG_MPC8641) || defined(CONFIG_MPC8610)
#define FSL_HW_NUM_LAWS 10
#elif defined(CONFIG_MPC8536) || defined(CONFIG_MPC8572) || \
- defined(CONFIG_P2020) || defined(CONFIG_P1020)
+ defined(CONFIG_P2020) || defined(CONFIG_P2010) || \
+ defined(CONFIG_P1020) || defined(CONFIG_P1011)
#define FSL_HW_NUM_LAWS 12
#else
#error FSL_HW_NUM_LAWS not defined for this platform
diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/processor.h
index 5547245..de23ad8 100644
--- a/include/asm-ppc/processor.h
+++ b/include/asm-ppc/processor.h
@@ -1011,8 +1011,12 @@
#define SVR_8572_E 0x80E800
#define SVR_P2020 0x80E200
#define SVR_P2020_E0x80EA00
+#define SVR_P2010 0x80E300
+#define SVR_P2010_E0x80EB00
#define SVR_P1020 0x80E400
#define SVR_P1020_E0x80EC00
+#define SVR_P1011 0x80E500
+#define SVR_P1011_E0x80ED00
#define SVR_8610 0x80A000
#define SVR_8641 0x809000
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc/85xx: Added support for P1011RDB and P2010RDB
P2010 and P1011 are single core variants of P2020 and P1010 respectively. The board(RDB) will be same. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next Makefile | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 337bf89..4c0e08d 100644 --- a/Makefile +++ b/Makefile @@ -2499,11 +2499,21 @@ P2020RDB_config:unconfig @echo #define CONFIG_P2020 $(obj)include/config.h ; @$(MKCONFIG) -a P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale +P2010RDB_config: unconfig + @mkdir -p $(obj)include + @echo #define CONFIG_P2010 $(obj)include/config.h ; + @$(MKCONFIG) -a P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale + P1020RDB_config: unconfig @mkdir -p $(obj)include @echo #define CONFIG_P1020 $(obj)include/config.h ; @$(MKCONFIG) -a P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale +P1011RDB_config: unconfig + @mkdir -p $(obj)include + @echo #define CONFIG_P1011 $(obj)include/config.h ; + @$(MKCONFIG) -a P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale + PM854_config: unconfig @$(MKCONFIG) $(@:_config=) ppc mpc85xx pm854 -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] driver/fsl_pci: Added fsl_pci_init_port function to initialize a single PCIe port.
* Added a generic function fsl_pci_init_port in drivers/pci/fsl_pci.c
to initialize a PCIe port.
* fsl_pci_init_port can be called from board specific pcie initialization
routine, per-port.
* This will reduce the code redundancy in the most of the Freescale board
specific PCIe inits.
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
- applies on git.denx.de/u-boot-mpc85xx.git branch-next
drivers/pci/fsl_pci_init.c | 41 +
include/asm-ppc/fsl_pci.h | 26 ++
2 files changed, 67 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/fsl_pci_init.c b/drivers/pci/fsl_pci_init.c
index ee89aaa..9e9e1b7 100644
--- a/drivers/pci/fsl_pci_init.c
+++ b/drivers/pci/fsl_pci_init.c
@@ -412,6 +412,47 @@ void fsl_pci_init(struct pci_controller *hose, u32
cfg_addr, u32 cfg_data)
}
}
+int fsl_pci_init_port(struct fsl_pci_info *pci_info,
+ struct pci_controller *hose, int busno)
+{
+ volatile ccsr_fsl_pci_t *pci;
+ struct pci_region *r;
+
+ pci = (ccsr_fsl_pci_t *) pci_info-regs;
+
+ if (in_be32(pci-pme_msg_det)) {
+ out_be32(pci-pme_msg_det, 0x);
+ debug ( with errors. Clearing. Now 0x%08x,
+ pci-pme_msg_det);
+ }
+
+ r = hose-regions + hose-region_count;
+
+ /* outbound memory */
+ pci_set_region(r++,
+ pci_info-mem_bus,
+ pci_info-mem_phys,
+ pci_info-mem_size,
+ PCI_REGION_MEM);
+
+ /* outbound io */
+ pci_set_region(r++,
+ pci_info-io_bus,
+ pci_info-io_phys,
+ pci_info-io_size,
+ PCI_REGION_IO);
+
+ hose-region_count = r - hose-regions;
+ hose-first_busno = busno;
+
+ fsl_pci_init(hose, (u32)pci-cfg_addr, (u32)pci-cfg_data);
+
+ printf(\nPCIE%x on bus %02x - %02x\n, pci_info-pci_num,
+ hose-first_busno, hose-last_busno);
+
+ return(hose-last_busno + 1);
+}
+
/* Enable inbound PCI config cycles for agent/endpoint interface */
void fsl_pci_config_unlock(struct pci_controller *hose)
{
diff --git a/include/asm-ppc/fsl_pci.h b/include/asm-ppc/fsl_pci.h
index b2ff0e9..2b6421a 100644
--- a/include/asm-ppc/fsl_pci.h
+++ b/include/asm-ppc/fsl_pci.h
@@ -154,4 +154,30 @@ typedef struct ccsr_pci {
charres24[252];
} ccsr_fsl_pci_t;
+struct fsl_pci_info {
+ phys_size_t regs;
+ pci_addr_t mem_bus;
+ phys_size_t mem_phys;
+ pci_size_t mem_size;
+ pci_addr_t io_bus;
+ phys_size_t io_phys;
+ pci_size_t io_size;
+ int pci_num;
+};
+
+int fsl_pci_init_port(struct fsl_pci_info *pci_info,
+ struct pci_controller *hose, int busno);
+
+#define SET_STD_PCIE_INFO(x, num) \
+{ \
+ x.regs = CONFIG_SYS_PCIE##num##_ADDR; \
+ x.mem_bus = CONFIG_SYS_PCIE##num##_MEM_BUS; \
+ x.mem_phys = CONFIG_SYS_PCIE##num##_MEM_PHYS; \
+ x.mem_size = CONFIG_SYS_PCIE##num##_MEM_SIZE; \
+ x.io_bus = CONFIG_SYS_PCIE##num##_IO_BUS; \
+ x.io_phys = CONFIG_SYS_PCIE##num##_IO_PHYS; \
+ x.io_size = CONFIG_SYS_PCIE##num##_IO_SIZE; \
+ x.pci_num = num; \
+}
+
#endif
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ppc/85xx: Added PCIe support for P1 P2 RDB
* Added PCIe support for P1 P2 RDB
* Calls the fsl_pci_init_port function to initialize all the PCIe ports
on the board.
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
- applies on git.denx.de/u-boot-mpc85xx.git branch-next
board/freescale/p1_p2_rdb/Makefile |1 +
board/freescale/p1_p2_rdb/pci.c| 112
include/configs/P1_P2_RDB.h|6 ++
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/p1_p2_rdb/pci.c
diff --git a/board/freescale/p1_p2_rdb/Makefile
b/board/freescale/p1_p2_rdb/Makefile
index 9107263..c366f7c 100644
--- a/board/freescale/p1_p2_rdb/Makefile
+++ b/board/freescale/p1_p2_rdb/Makefile
@@ -27,6 +27,7 @@ LIB = $(obj)lib$(BOARD).a
COBJS-y+= $(BOARD).o
COBJS-y+= law.o
COBJS-y+= tlb.o
+COBJS-$(CONFIG_PCI) += pci.o
COBJS-y+= ddr.o
SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c)
diff --git a/board/freescale/p1_p2_rdb/pci.c b/board/freescale/p1_p2_rdb/pci.c
new file mode 100644
index 000..3867705
--- /dev/null
+++ b/board/freescale/p1_p2_rdb/pci.c
@@ -0,0 +1,112 @@
+/*
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT 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
+#include command.h
+#include pci.h
+#include asm/immap_85xx.h
+#include asm/io.h
+#include asm/fsl_pci.h
+#include libfdt.h
+#include fdt_support.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+#ifdef CONFIG_PCIE1
+static struct pci_controller pcie1_hose;
+#endif
+
+#ifdef CONFIG_PCIE2
+static struct pci_controller pcie2_hose;
+#endif
+
+void pci_init_board(void)
+{
+ struct fsl_pci_info pci_info[2];
+ volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
+ uint devdisr = in_be32(gur-devdisr);
+ uint io_sel = (in_be32(gur-pordevsr) MPC85xx_PORDEVSR_IO_SEL) 19;
+ uint host_agent = (in_be32(gur-porbmsr) MPC85xx_PORBMSR_HA) 16;
+ int num = 0;
+ int first_free_busno = 0;
+ int last_busno;
+
+ int pcie_ep, pcie_configured;
+
+ debug ( pci_init_board: devdisr=%x, io_sel=%x, host_agent=%x\n,
+ devdisr, io_sel, host_agent);
+
+ if (!(gur-pordevsr MPC85xx_PORDEVSR_SGMII2_DIS))
+ printf (eTSEC2 is in sgmii mode.\n);
+
+#ifdef CONFIG_PCIE2
+ SET_STD_PCIE_INFO(pci_info[num], 2);
+ pcie_ep = (host_agent == 2) || (host_agent == 4) ||
+ (host_agent == 6) || (host_agent == 0);
+ pcie_configured = (io_sel == 0xE);
+
+ if (pcie_configured !(devdisr MPC85xx_DEVDISR_PCIE)){
+ printf (\n PCIE2 connected to Slot 1 as %s (base address %x),
+ pcie_ep ? End Point: Root Complex,
pci_info[num].regs);
+ last_busno = fsl_pci_init_port(pci_info[num],
+ pcie2_hose, first_free_busno);
+ first_free_busno = last_busno;
+ num++;
+ } else {
+ printf (PCIE2: disabled\n);
+ }
+#else
+ set_bits32(gur-devdisr, MPC85xx_DEVDISR_PCIE2); /* disable */
+#endif
+
+#ifdef CONFIG_PCIE1
+ SET_STD_PCIE_INFO(pci_info[num], 1);
+
+ pcie_ep = (host_agent = 1) || (host_agent == 4) ||
+ (host_agent == 5);
+ pcie_configured = (io_sel == 0xE);
+
+ if (pcie_configured !(devdisr MPC85xx_DEVDISR_PCIE)){
+ printf (\n PCIE1 connected to Slot 2 as %s (base address %x),
+ pcie_ep ? End Point : Root Complex,
+ pci_info[num].regs);
+ last_busno = fsl_pci_init_port(pci_info[num],
+ pcie1_hose, first_free_busno);
+ first_free_busno = last_busno;
+ num++;
+ } else {
+ printf (PCIE1: disabled\n);
+ }
+#else
+ set_bits32(gur-devdisr, MPC85xx_DEVDISR_PCIE); /* disable */
+#endif
+}
+
+void ft_pci_board_setup(void *blob)
+{
+#ifdef CONFIG_PCIE2
+ ft_fsl_pci_setup(blob, pci1, pcie2_hose);
+#endif
+#ifdef CONFIG_PCIE1
+ ft_fsl_pci_setup(blob, pci2, pcie1_hose);
+#endif
+}
diff --git
Re: [U-Boot] [PATCH] Adding support for DevKit8000
On 10:55 Thu 20 Aug , Frederik Kriewitz wrote:
On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe
PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote:
board/omap3/devkit8000/Makefile | 52 +
board/omap3/devkit8000/config.mk| 35
board/omap3/devkit8000/devkit8000.c | 124
board/omap3/devkit8000/devkit8000.h | 373
+++
no need board are allow in board/omap3
please create your own vendor dirent or just put it in board/
What do you mean with that?
board/devkit8000/devkit8000.h
or board/embedinfo/devkit8000/devkit8000.h
On Thu, Aug 20, 2009 at 7:18 AM, Jean-Christophe
PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote:
+void reset_phy(void)
+{
+ eth_init(gd-bd);
+}
NACK
the net need to be init only when you use it
The kernel will try to use the already (temporally) programmed MAC address.
I always init it because that way no kernel hack for the MAC address
is required.
Is it ok if I add a comment?
no sorry
this will be also nack by Wolfgang
to program the mac you need to create a initramfs in your kernel wich
generate
the same thing or read the content of the U-Boot env via fw_printenv
and use ifconfig hw ether
ok, I think this will break nfsroot.
I don't think it's possible to init ethernet with a initramfs before
mounting the rootfs.
pivot root is your friend
and generate the mac address at the openof the device in the kernel
There are several boards doing the same because of nfsroot:
I known but it's not allow anyway
Is there any command to call eth_init() in a script?
if you download the uImage from the net it work
but the best will be to handle this in a initramfs
Best Regards,
J.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260/TNY-A9G20 boards
On Wed, Aug 19, 2009 at 11:30:05PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : On 21:14 Wed 19 Aug , Albin Tonnerre wrote: diff --git a/MAKEALL b/MAKEALL index edebaea..5882ceb 100755 --- a/MAKEALL +++ b/MAKEALL @@ -607,6 +607,7 @@ LIST_at91= \ m501sk \ pm9261 \ pm9263 \ + tny_a9260 \ why not 9g20 too? Oops. Thanks. # diff --git a/Makefile b/Makefile index 329e0f5..2abaeeb 100644 --- a/Makefile +++ b/Makefile @@ -2838,6 +2838,16 @@ at91sam9g45ekes_config : unconfig pm9263_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91 +TNY_A9G20_NANDFLASH_config \ +TNY_A9G20_EEPROM_config \ +TNY_A9G20_config \ +TNY_A9260_NANDFLASH_config \ +TNY_A9260_EEPROM_config \ +TNY_A9260_config : unconfig + @mkdir -p $(obj)include + @echo #define CONFIG_$(@:_config=) 1 $(obj)include/config.h try somethink like this so you do not need to put the config name uppercase @echo -n #define $(obj)include/config.h @echo$(@:_config=) | tr [a-z] [A-Z] $(obj)include/config.h I think I'll go with uppercase. If the shell ends up being /bin/sh, it might not provide the '-n' switch for echo, so I'd rather avoid it when possible. Thanks for your comments, -- Albin Tonnerre, Free Electrons Kernel, drivers and embedded Linux development, consulting, training and support. http://free-electrons.com signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ARM Cortex8 Rename and move v7_flush_dcache_all to flush_dcache
Tom wrote: Jean-Christophe PLAGNIOL-VILLARD wrote: Applying the basic functionality (function move) now allows others to finally go on with their long waiting patches. no this code is omap3 specific and there is no need ot this rename or move the function make no sense Yes, it is OMAP3 specific (as already mentioned in the patch description). So it's totally fine to move it to an OMAP3 specific file. So it's totally fine that others (!= OMAP3, e.g Samsung) can re-use arm_cortexa8 stuff without the burden of OMAP3 stuff. the flush MUST NOT be soc specific as there is NO need to do this at all so NACK Let's summarize: - First, you NACK because of device_type and function name - Then, you mention this code is omap3 specific - Then, you mention this code is not needed at all Sorry, but this sounds somehow confusing, better let us stop here. As already mentioned, let us apply the patch so that other Cortex A8 patches are not stalled any more. At the weekend, I missed the point why this code is OMAP3 specific and why it has to be moved to omap3 directory, so short update: It calls OMAP3 ROM code. This doesn't work on other Cortex A8, e.g. Samsung. That is, it must be moved to not stall others any more. so I'll repeat this only once there no need to call the rom code as the generic armv7 cache full work fine so no-need to use omap3 specific code I am not sure if the generic code can replace the omap3 code. I do not have access to the ROM code. From what I have seen on the l2_cache code, it seems that in some cases that the ROM code handles earlier revs of the hardware. I would be in favor of phasing in the new generic code so that if older hardware needed to use the ROM code it could. Not know knowing full effect of the change we should go slowly and provide options for legacy support up front. Yes. Agreed. Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v8] Support for the Calao TNY-A9260/TNY-A9G20 boards
The Calao TNY-A9260 and TNY-9G20 are boards manufactured and sold by Calao Systems http://www.calao-systems.com. Their components are very similar to the AT91SAM9260EK board, so their configuration is based on the configuration of this board. There are however some differences: different clocks, no LCD, no ethernet. They also can use SPI EEPROM to store the environment. Signed-off-by: Albin Tonnerre albin.tonne...@free-electrons.com --- Changes in v7: - As per Jean-Christophe's commentes, fix long lines and use uppercase for defines in include/configs/tny_a9260.h. Slightly rework the ifdef logic in the process - Add an entry in MAINTAINERS for the tny_a9g20 as weel, since both 9260 and 9g20 are supported Changes in v8: - Update MAKEALL to reflect the changes in Makefile, and add the tny_a9g20 MAINTAINERS |5 + MAKEALL |2 + Makefile | 10 ++ board/calao/tny_a9260/Makefile | 55 ++ board/calao/tny_a9260/config.mk |1 + board/calao/tny_a9260/spi.c | 50 + board/calao/tny_a9260/tny_a9260.c| 110 +++ cpu/arm926ejs/at91/at91sam9260_devices.c |2 +- include/configs/tny_a9260.h | 172 ++ 9 files changed, 406 insertions(+), 1 deletions(-) create mode 100644 board/calao/tny_a9260/Makefile create mode 100644 board/calao/tny_a9260/config.mk create mode 100644 board/calao/tny_a9260/spi.c create mode 100644 board/calao/tny_a9260/tny_a9260.c create mode 100644 include/configs/tny_a9260.h diff --git a/MAINTAINERS b/MAINTAINERS index 620604c..91e2c7f 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -681,6 +681,11 @@ Andrea Scian andrea.sc...@dave-tech.it B2 ARM7TDMI (S3C44B0X) +Albin Tonnerre albin.tonne...@free-electrons.com + + tny_a9260 ARM926EJS (AT91SAM9260 SoC) + tny_a9g20 ARM926EJS (AT91SAM9G20 SoC) + Greg Ungerer greg.unge...@opengear.com cm4008 ks8695p diff --git a/MAKEALL b/MAKEALL index edebaea..accb3bc 100755 --- a/MAKEALL +++ b/MAKEALL @@ -607,6 +607,8 @@ LIST_at91= \ m501sk \ pm9261 \ pm9263 \ + TNY_A9260 \ + TNY_A9G20 \ # diff --git a/Makefile b/Makefile index 329e0f5..2abaeeb 100644 --- a/Makefile +++ b/Makefile @@ -2838,6 +2838,16 @@ at91sam9g45ekes_config : unconfig pm9263_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91 +TNY_A9G20_NANDFLASH_config \ +TNY_A9G20_EEPROM_config \ +TNY_A9G20_config \ +TNY_A9260_NANDFLASH_config \ +TNY_A9260_EEPROM_config \ +TNY_A9260_config : unconfig + @mkdir -p $(obj)include + @echo #define CONFIG_$(@:_config=) 1 $(obj)include/config.h + @$(MKCONFIG) -a tny_a9260 arm arm926ejs tny_a9260 calao at91 + ## ARM Integrator boards - see doc/README-integrator for more info. integratorap_config\ diff --git a/board/calao/tny_a9260/Makefile b/board/calao/tny_a9260/Makefile new file mode 100644 index 000..21f5ed1 --- /dev/null +++ b/board/calao/tny_a9260/Makefile @@ -0,0 +1,55 @@ +# +# (C) Copyright 2003-2008 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2008 +# Stelian Pop stelian@leadtechdesign.com +# Lead Tech Design www.leadtechdesign.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS-y+= tny_a9260.o +COBJS-$(CONFIG_ATMEL_SPI) += spi.o + +SRCS := $(SOBJS:.o=.S) $(COBJS-y:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS-y)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines
Re: [U-Boot] [PATCH] 85xx: Fix memory test range on MPC8536DS
On Aug 15, 2009, at 7:08 AM, Felix Radensky wrote: With current values of CONFIG_SYS_MEMTEST_START and CONFIG_SYS_MEMTEST_END memory test hangs if run without arguments. Set them to sane values, so that all available 512MB of RAM excluding exception vectors at the bottom and u-boot code and stack at the top can be tested. Signed-off-by: Felix Radensky fe...@embedded-sol.com --- include/configs/MPC8536DS.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) applied to next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/10] Add L2SRAM Register's macro definition
On Aug 18, 2009, at 2:37 AM, Mingkai Hu wrote: Signed-off-by: Mingkai Hu mingkai...@freescale.com --- cpu/mpc85xx/cpu_init.c |5 +++-- include/asm-ppc/immap_85xx.h |5 + 2 files changed, 8 insertions(+), 2 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added CONFIG_MAX_CPUS for P1020
On Aug 20, 2009, at 8:25 AM, Poonam Aggrwal wrote: Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next include/asm-ppc/config.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) On Aug 18, 2009, at 2:37 AM, Mingkai Hu wrote: Signed-off-by: Mingkai Hu mingkai...@freescale.com --- cpu/mpc85xx/cpu_init.c |5 +++-- include/asm-ppc/immap_85xx.h |5 + 2 files changed, 8 insertions(+), 2 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: P1020RDB Support Added
On Aug 20, 2009, at 8:27 AM, Poonam Aggrwal wrote: Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next Makefile |5 + 1 files changed, 5 insertions(+), 0 deletions(-) Added to MAKEALL and kept list in Makefile sorted (in the future make sure to do those two things) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ERROR: too many flash sectors
Hi , everyone .
My u-boot version is 2009-01 and i try porting u-boot on pxa270 development
board.
when i power on my board then minicom show these information
DRAM: 64 MB
ERROR: too many flash sectors
ERROR: too many flash sectors
Flash:32 MB
then i can save setenv , but when i earse my flash ,it cause one error
Error: end address not on sector boundary
and here is my flinfo :
Bank # 1: CFI conformant FLASH (32 x 16) Size: 32 MB in 128 Sectors
Intel Extended command set, Manufacturer ID: 0x89, Device ID: 0x18
Erase timeout: 4096 ms, write timeout: 1 ms
Buffer write timeout: 2 ms, buffer size: 64 bytes
Sector Start Addresses:
RO 0004 RO 0008 RO 000C RO 0010
RO
etc...
And i dont know my network chip work or not . ( my chip is LAN91C113 )
when i ping some address , it show
ethid=...
LAN91C113:PHY auto-negotiate timed out
then my bootloader freeze
would someone can help me ? thanks.
--
View this message in context:
http://www.nabble.com/-U-Boot--ERROR%3A-too-many-flash-sectors-tp25063511p25063511.html
Sent from the Uboot - Users mailing list archive at Nabble.com.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added support for P1011RDB and P2010RDB
On Aug 20, 2009, at 8:29 AM, Poonam Aggrwal wrote: P2010 and P1011 are single core variants of P2020 and P1010 respectively. The board(RDB) will be same. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next Makefile | 10 ++ 1 files changed, 10 insertions(+), 0 deletions(-) Added to MAKEALL and kept list in Makefile sorted (in the future make sure to do those two things) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added single core members of FSL P1 P2 processors series
On Aug 20, 2009, at 8:27 AM, Poonam Aggrwal wrote: P2010 - single core variant of P2020 P1011 - Single core variant of P1020 Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- - applies on git.denx.de/u-boot-mpc85xx.git branch-next cpu/mpc85xx/Makefile|2 ++ cpu/mpc8xxx/cpu.c |4 drivers/misc/fsl_law.c |3 ++- include/asm-ppc/processor.h |4 4 files changed, 12 insertions(+), 1 deletions(-) applied to 85xx next - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Support for the Calao TNY-A9260/TNY-A9G20 boards
On 15:43 Thu 20 Aug , Albin Tonnerre wrote: On Wed, Aug 19, 2009 at 11:30:05PM +0200, Jean-Christophe PLAGNIOL-VILLARD wrote : On 21:14 Wed 19 Aug , Albin Tonnerre wrote: diff --git a/MAKEALL b/MAKEALL index edebaea..5882ceb 100755 --- a/MAKEALL +++ b/MAKEALL @@ -607,6 +607,7 @@ LIST_at91= \ m501sk \ pm9261 \ pm9263 \ + tny_a9260 \ why not 9g20 too? Oops. Thanks. # diff --git a/Makefile b/Makefile index 329e0f5..2abaeeb 100644 --- a/Makefile +++ b/Makefile @@ -2838,6 +2838,16 @@ at91sam9g45ekes_config : unconfig pm9263_config: unconfig @$(MKCONFIG) $(@:_config=) arm arm926ejs pm9263 ronetix at91 +TNY_A9G20_NANDFLASH_config \ +TNY_A9G20_EEPROM_config \ +TNY_A9G20_config \ +TNY_A9260_NANDFLASH_config \ +TNY_A9260_EEPROM_config \ +TNY_A9260_config : unconfig + @mkdir -p $(obj)include + @echo #define CONFIG_$(@:_config=) 1 $(obj)include/config.h try somethink like this so you do not need to put the config name uppercase @echo -n #define $(obj)include/config.h @echo$(@:_config=) | tr [a-z] [A-Z] $(obj)include/config.h I think I'll go with uppercase. If the shell ends up being /bin/sh, it might not provide the '-n' switch for echo, so I'd rather avoid it when possible. you can use \c too but as you prefer Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add Transfer Size Option to tftp
Optionally add RFC 2349 Transfer Size Option, so we can minimize the
time spent sending data over the UART (now print a single line during a
tftp transfer).
- If turned on (CONFIG_TFTP_TSIZE), U-Boot asks for the size of the file.
- if receives the file size, a single line (50 chars) are printed.
one hash mark == 2% of the file downloaded.
- if it doesn't receive the file size (the server doesn't support RFC
2349, prints standard hash marks (one mark for each UDP frame).
Signed-off-by: Robin Getz rg...@blackfin.uclinux.org
---
net/tftp.c | 42 --
1 files changed, 40 insertions(+), 2 deletions(-)
diff --git a/net/tftp.c b/net/tftp.c
index 0fa7033..865f41a 100644
--- a/net/tftp.c
+++ b/net/tftp.c
@@ -56,6 +56,10 @@ static ulong TftpLastBlock; /* last packet sequence
number received */
static ulong TftpBlockWrap; /* count of sequence number wraparounds
*/
static ulong TftpBlockWrapOffset;/* memory offset due to wrapping
*/
static int TftpState;
+#ifdef CONFIG_TFTP_TSIZE
+static int TftpTsize; /* The file size reported by the server
*/
+static short TftpNumchars; /* The number of hashes we printed
*/
+#endif
#define STATE_RRQ 1
#define STATE_DATA 2
@@ -202,6 +206,10 @@ TftpSend (void)
sprintf((char *)pkt, %lu, TIMEOUT / 1000);
debug(send option \timeout %s\\n, (char *)pkt);
pkt += strlen((char *)pkt) + 1;
+#ifdef CONFIG_TFTP_TSIZE
+ memcpy((char *)pkt, tsize\\0, 8);
+ pkt += 8;
+#endif
/* try for more effic. blk size */
pkt += sprintf((char *)pkt,blksize%c%d%c,
0,TftpBlkSizeOption,0);
@@ -311,8 +319,14 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
simple_strtoul((char*)pkt+i+8,NULL,10);
debug(Blocksize ack: %s, %d\n,
(char*)pkt+i+8,TftpBlkSize);
- break;
}
+#ifdef CONFIG_TFTP_TSIZE
+ if (strcmp ((char*)pkt+i,tsize) == 0) {
+ TftpTsize =
simple_strtoul((char*)pkt+i+6,NULL,10);
+ debug(size = %s, %d\n,
+(char*)pkt+i+6, TftpTsize);
+ }
+#endif
}
#ifdef CONFIG_MCAST_TFTP
parse_multicast_oack((char *)pkt,len-1);
@@ -338,7 +352,16 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
TftpBlockWrap++;
TftpBlockWrapOffset += TftpBlkSize * TFTP_SEQUENCE_SIZE;
printf (\n\t %lu MB received\n\t ,
TftpBlockWrapOffset20);
- } else {
+ }
+#ifdef CONFIG_TFTP_TSIZE
+ else if (TftpTsize) {
+ while (TftpNumchars NetBootFileXferSize * 50 /
TftpTsize) {
+ putc('#');
+ TftpNumchars++;
+ }
+ }
+#endif
+ else {
if (((TftpBlock - 1) % 10) == 0) {
putc ('#');
} else if ((TftpBlock % (10 * HASHES_PER_LINE)) == 0) {
@@ -432,6 +455,13 @@ TftpHandler (uchar * pkt, unsigned dest, unsigned src,
unsigned len)
* We received the whole thing. Try to
* run it.
*/
+#ifdef CONFIG_TFTP_TSIZE
+ /* Print out the hash marks for the last packet
received */
+ while (TftpTsize TftpNumchars 49) {
+ putc('#');
+ TftpNumchars++;
+ }
+#endif
puts (\ndone\n);
NetState = NETLOOP_SUCCESS;
}
@@ -561,6 +595,10 @@ TftpStart (void)
#ifdef CONFIG_MCAST_TFTP
mcast_cleanup();
#endif
+#ifdef CONFIG_TFTP_TSIZE
+ TftpTsize = 0;
+ TftpNumchars = 0;
+#endif
TftpSend ();
}
--
1.6.0.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ERROR: too many flash sectors
On Thursday 20 August 2009 16:45:28 SlinceArm wrote: Hi , everyone . My u-boot version is 2009-01 and i try porting u-boot on pxa270 development board. when i power on my board then minicom show these information DRAM: 64 MB ERROR: too many flash sectors ERROR: too many flash sectors This error is important. Searching in the source code gives you an hint. You should increase CONFIG_SYS_MAX_FLASH_SECT to match you hardware. Cheers, Stefan -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: off...@denx.de ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added single core members of FSL P1 P2 processors series
Dear Poonam Aggrwal, In message 1250774865-20228-1-git-send-email-poonam.aggr...@freescale.com you wrote: P2010 - single core variant of P2020 P1011 - Single core variant of P1020 Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- - applies on git.denx.de/u-boot-mpc85xx.git branch-next cpu/mpc85xx/Makefile|2 ++ cpu/mpc8xxx/cpu.c |4 drivers/misc/fsl_law.c |3 ++- include/asm-ppc/processor.h |4 4 files changed, 12 insertions(+), 1 deletions(-) diff --git a/cpu/mpc85xx/Makefile b/cpu/mpc85xx/Makefile index 1477eac..df5a177 100644 --- a/cpu/mpc85xx/Makefile +++ b/cpu/mpc85xx/Makefile @@ -50,7 +50,9 @@ COBJS-$(CONFIG_MPC8572) += ddr-gen3.o COBJS-$(CONFIG_MPC8536) += ddr-gen3.o COBJS-$(CONFIG_MPC8569) += ddr-gen3.o COBJS-$(CONFIG_P2020)+= ddr-gen3.o +COBJS-$(CONFIG_P2010)+= ddr-gen3.o COBJS-$(CONFIG_P1020)+= ddr-gen3.o +COBJS-$(CONFIG_P1011)+= ddr-gen3.o Please keep all such lists sorted. 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 In the strict scientific sense we all feed on death -- even vegetarians. -- Spock, Wolf in the Fold, stardate 3615.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/fsl_pci: Added fsl_pci_init_port function to initialize a single PCIe port.
On Aug 20, 2009, at 10:12 AM, Wolfgang Denk wrote: Dear Poonam Aggrwal, In message 1250775038-20372-1-git-send-email-poonam.aggr...@freescale.com you wrote: * Added a generic function fsl_pci_init_port in drivers/pci/ fsl_pci.c to initialize a PCIe port. * fsl_pci_init_port can be called from board specific pcie initialization routine, per-port. * This will reduce the code redundancy in the most of the Freescale board specific PCIe inits. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- NAK. I see just dead code added, without any users. If this gets used somewhere, this should be visible in the patch, and lead to code removed somewhere? It gets used in the patch 'Added PCIe support for P1 P2 RDB'. I also will look at using it on other boards to remove code. However I don't think we need one patch that adds the interface and does the board code changes or additions (unless you have to do them to keep compiling sane). I agree this should have been label'd 1/2 and the 'Added PCIe support for P1/P2 RDB' as 2/2. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: compiler options cleanup - improve tool chain support
Results: I was unable to compile without the patch in this thread http://lists.denx.de/pipermail/u-boot/2009-August/058193.html (which is normal because of gcc-4.4.1). With 'MAKEALL arm' I have no compile errors except for: * actux1, actux2, actux3, actux4, ixdp425, ixdpg425, pdnb3, which seem to be big endian (my toolchain only generates binaries for little endian). * and trab board with this error: armel-unknown-linux-gnueabi-ld: ../../lib_arm/div0.o: No such file: No such file or directory I've tested it with gcc 4.1.2 and 4.3.3 from Buildroot, with the same results. Tests only without USE_PRIVATE_LIBGCC=yes. Tested-by: Andrzej Wolski awol...@poczta.fm Regards -- Wygraj telefon dla swojego dziecka. 20 sztuk czeka! Sprawdz http://link.interia.pl/f22d8 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc4xx: Rename compactcenter to intip
Dear Eibach, Dirk, In message 48d3d52125c49b43ae880038e2e5314b025...@srv101.gdsys.de you wrote: Just checking: You only want to change the printed name upon bootup from compactcenter to intip? Not the U-Boot target name? That's it. Since this might be sold as an OEM product, we need a more generic name to be displayed. But that's pretty confusing, isn't it? Why not change the config name as well? 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 Crash programs fail because they are based on the theory that, with nine women pregnant, you can get a baby a month. - Wernher von Braun ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added PCIe support for P1 P2 RDB
Dear Poonam Aggrwal,
In message 1250775054-20418-1-git-send-email-poonam.aggr...@freescale.com you
wrote:
* Added PCIe support for P1 P2 RDB
* Calls the fsl_pci_init_port function to initialize all the PCIe ports
on the board.
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
- applies on git.denx.de/u-boot-mpc85xx.git branch-next
board/freescale/p1_p2_rdb/Makefile |1 +
board/freescale/p1_p2_rdb/pci.c| 112
include/configs/P1_P2_RDB.h|6 ++
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/p1_p2_rdb/pci.c
diff --git a/board/freescale/p1_p2_rdb/Makefile
b/board/freescale/p1_p2_rdb/Makefile
index 9107263..c366f7c 100644
--- a/board/freescale/p1_p2_rdb/Makefile
+++ b/board/freescale/p1_p2_rdb/Makefile
@@ -27,6 +27,7 @@ LIB = $(obj)lib$(BOARD).a
COBJS-y += $(BOARD).o
COBJS-y += law.o
COBJS-y += tlb.o
+COBJS-$(CONFIG_PCI) += pci.o
COBJS-y += ddr.o
Please (make and) keep list sorted.
...
+void ft_pci_board_setup(void *blob)
+{
+#ifdef CONFIG_PCIE2
+ ft_fsl_pci_setup(blob, pci1, pcie2_hose);
PCIE2 ... pci1 ... pcie2 ???
+#endif
+#ifdef CONFIG_PCIE1
+ ft_fsl_pci_setup(blob, pci2, pcie1_hose);
PCIE1 ... pci2 ... pcie1 ???
This looks broken to me?
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
As far as the laws of mathematics refer to reality, they are not cer-
tain, and as far as they are certain, they do not refer to reality.
-- Albert Einstein
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/fsl_pci: Added fsl_pci_init_port function to initialize a single PCIe port.
-Original Message- From: Kumar Gala [mailto:ga...@kernel.crashing.org] Sent: Thursday, August 20, 2009 8:54 PM To: Wolfgang Denk Cc: Aggrwal Poonam-B10812; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] driver/fsl_pci: Added fsl_pci_init_port function to initialize a single PCIe port. On Aug 20, 2009, at 10:12 AM, Wolfgang Denk wrote: Dear Poonam Aggrwal, In message 1250775038-20372-1-git-send-email-poonam.aggr...@freescale.com you wrote: * Added a generic function fsl_pci_init_port in drivers/pci/ fsl_pci.c to initialize a PCIe port. * fsl_pci_init_port can be called from board specific pcie initialization routine, per-port. * This will reduce the code redundancy in the most of the Freescale board specific PCIe inits. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- NAK. I see just dead code added, without any users. If this gets used somewhere, this should be visible in the patch, and lead to code removed somewhere? It gets used in the patch 'Added PCIe support for P1 P2 RDB'. I also will look at using it on other boards to remove code. However I don't think we need one patch that adds the interface and does the board code changes or additions (unless you have to do them to keep compiling sane). I agree this should have been label'd 1/2 and the 'Added PCIe support for P1/P2 RDB' as 2/2. Yes my mistake here, I should have shown the patch dependancy. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added CONFIG_MAX_CPUS for P1020
Dear Poonam Aggrwal, In message 1250774735-20130-1-git-send-email-poonam.aggr...@freescale.com you wrote: Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next include/asm-ppc/config.h |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-ppc/config.h b/include/asm-ppc/config.h index fd7961c..fb9c20e 100644 --- a/include/asm-ppc/config.h +++ b/include/asm-ppc/config.h @@ -38,8 +38,8 @@ #endif #endif -#if defined(CONFIG_MPC8572) || defined(CONFIG_P2020) \ - || defined(CONFIG_MPC8641) +#if defined(CONFIG_MPC8572) || defined(CONFIG_P2020) || \ + defined(CONFIG_P1020) || defined(CONFIG_MPC8641) Please keep the list sorted. 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 Gods don't like people not doing much work. People who aren't busy all the time might start to _think_. - Terry Pratchett, _Small Gods_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: P1020RDB Support Added
Dear Kumar Gala, In message f3fb164c-23ca-4334-883a-eb556596e...@kernel.crashing.org you wrote: On Aug 20, 2009, at 8:27 AM, Poonam Aggrwal wrote: Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next Makefile |5 + 1 files changed, 5 insertions(+), 0 deletions(-) Added to MAKEALL and kept list in Makefile sorted (in the future make sure to do those two things) applied to 85xx next Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You ain't experienced... Well, nor are you. That's true. But the point is ... the point is ... the point is we've been not experienced for a lot longer than you. We've got a lot of experience of not having any experience. - Terry Pratchett, _Witches Abroad_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added single core members of FSL P1 P2 processors series
Dear Kumar Gala, In message d48d44de-5582-4b00-81b8-68c0ed9a2...@kernel.crashing.org you wrote: On Aug 20, 2009, at 8:27 AM, Poonam Aggrwal wrote: P2010 - single core variant of P2020 P1011 - Single core variant of P1020 Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- - applies on git.denx.de/u-boot-mpc85xx.git branch-next cpu/mpc85xx/Makefile|2 ++ cpu/mpc8xxx/cpu.c |4 drivers/misc/fsl_law.c |3 ++- include/asm-ppc/processor.h |4 4 files changed, 12 insertions(+), 1 deletions(-) applied to 85xx next NAK. Lists not sorted. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de We have found all life forms in the galaxy are capable of superior development. -- Kirk, The Gamesters of Triskelion, stardate 3211.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: P1020RDB Support Added
Dear Poonam Aggrwal, In message 1250774822-20182-1-git-send-email-poonam.aggr...@freescale.com you wrote: Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- applies on http://git.denx.de/u-boot-mpc85xx.git branch-next Makefile |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index f92ef30..337bf89 100644 --- a/Makefile +++ b/Makefile @@ -2499,6 +2499,11 @@ P2020RDB_config: unconfig @echo #define CONFIG_P2020 $(obj)include/config.h ; @$(MKCONFIG) -a P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale +P1020RDB_config: unconfig + @mkdir -p $(obj)include + @echo #define CONFIG_P1020 $(obj)include/config.h ; + @$(MKCONFIG) -a P1_P2_RDB ppc mpc85xx p1_p2_rdb freescale + Please keep the list sorted. 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 Gravitation cannot be held responsible for people falling in love. - Albert Einstein ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] driver/fsl_pci: Added fsl_pci_init_port function to initialize a single PCIe port.
Dear Poonam Aggrwal, In message 1250775038-20372-1-git-send-email-poonam.aggr...@freescale.com you wrote: * Added a generic function fsl_pci_init_port in drivers/pci/fsl_pci.c to initialize a PCIe port. * fsl_pci_init_port can be called from board specific pcie initialization routine, per-port. * This will reduce the code redundancy in the most of the Freescale board specific PCIe inits. Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- NAK. I see just dead code added, without any users. If this gets used somewhere, this should be visible in the patch, and lead to code removed somewhere? Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de You cannot propel yourself forward by patting yourself on the back. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] e1000 Rx timeout with 82541ER
-Original Message- From: André Schwarz [mailto:andre.schw...@matrix-vision.de] Sent: Wednesday, August 19, 2009 7:10 AM To: Zang Roy-R61911; Ben Warren Cc: U-Boot List Subject: e1000 Rx timeout with 82541ER Roy, Ben, with latest e1000.c my 82541ER connected to a MPC5200 via PCI is no longer working correctly - I get timeouts after few packets. After having a quick look at the code changes it's obvious that I can't figure out the problem quickly since there has been a lot of changes. This is output of today's version : U-Boot 2009.08-rc2-00025-g2bcbd42-dirty (Aug 19 2009 - 11:28:10) CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: Matrix Vision mvBlueCOUGAR-P Net: e1000: 00:0c:8d:40:00:50 e1000#0 ... Random delay: 734 ms... BOOTP broadcast 1 DHCP client bound to address 192.168.65.230 Using e1000#0 device TFTP from server 192.168.64.1; our IP address is 192.168.65.230; sending through gateway 192.168.65.15 Filename '/mvbc-p2625.boot'. Load address: 0x20 Loading: ###T T T T T T T T T T Retry count exceeded; starting again This is output of v2009.6 : U-Boot 2009.06-00185-g57fe301-dirty (Jun 22 2009 - 12:07:54) CPU: MPC5200B v2.2, Core v1.4 at 396 MHz Bus 132 MHz, IPB 132 MHz, PCI 66 MHz Board: Matrix Vision mvBlueCOUGAR-P Net: e1000: 00:0c:8d:40:00:50 e1000#0 Random delay: 815 ms... BOOTP broadcast 1 DHCP client bound to address 192.168.65.230 Using e1000#0 device TFTP from server 192.168.64.1; our IP address is 192.168.65.230; sending through gateway 192.168.65.15 Filename '/mvbc-p2625.boot'. Load address: 0x20 Loading: # # done Bytes transferred = 1487889 (16b411 hex) Using drivers/net/e1000.c from v2009.6 gives me back a working NIC, i.e. the problem is likely to be there. Have you tried some PCI cards after the PCIe changes ? I have tried 82545EM_COPPER, 82541GI_LF PCI card on 8544DS and 8536DS board. Any ideas ? Try to increase tx_pool and rx_pool to see whether there is improment. static char tx_pool[128 + 16]; static char rx_pool[128 + 16]; Change 128 to 256 or 512 to see. How about ping command? Roy ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added single core members of FSL P1 P2 processors series
-Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: Thursday, August 20, 2009 8:40 PM To: Kumar Gala Cc: Aggrwal Poonam-B10812; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ppc/85xx: Added single core members of FSL P1 P2 processors series Dear Kumar Gala, In message d48d44de-5582-4b00-81b8-68c0ed9a2...@kernel.crashing.org you wrote: On Aug 20, 2009, at 8:27 AM, Poonam Aggrwal wrote: P2010 - single core variant of P2020 P1011 - Single core variant of P1020 Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com Signed-off-by: Kumar Gala ga...@kernel.crashing.org --- - applies on git.denx.de/u-boot-mpc85xx.git branch-next cpu/mpc85xx/Makefile|2 ++ cpu/mpc8xxx/cpu.c |4 drivers/misc/fsl_law.c |3 ++- include/asm-ppc/processor.h |4 4 files changed, 12 insertions(+), 1 deletions(-) applied to 85xx next NAK. Lists not sorted. Sorry, I will re-send. And take care of this in future. Regards Poonam Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de We have found all life forms in the galaxy are capable of superior development. -- Kirk, The Gamesters of Triskelion, stardate 3211.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ppc/85xx: Added PCIe support for P1 P2 RDB
On Aug 20, 2009, at 10:14 AM, Wolfgang Denk wrote:
Dear Poonam Aggrwal,
In message 1250775054-20418-1-git-send-email-poonam.aggr...@freescale.com
you wrote:
* Added PCIe support for P1 P2 RDB
* Calls the fsl_pci_init_port function to initialize all the PCIe
ports
on the board.
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
- applies on git.denx.de/u-boot-mpc85xx.git branch-next
board/freescale/p1_p2_rdb/Makefile |1 +
board/freescale/p1_p2_rdb/pci.c| 112 ++
++
include/configs/P1_P2_RDB.h|6 ++
3 files changed, 119 insertions(+), 0 deletions(-)
create mode 100644 board/freescale/p1_p2_rdb/pci.c
diff --git a/board/freescale/p1_p2_rdb/Makefile b/board/freescale/
p1_p2_rdb/Makefile
index 9107263..c366f7c 100644
--- a/board/freescale/p1_p2_rdb/Makefile
+++ b/board/freescale/p1_p2_rdb/Makefile
@@ -27,6 +27,7 @@ LIB= $(obj)lib$(BOARD).a
COBJS-y += $(BOARD).o
COBJS-y += law.o
COBJS-y += tlb.o
+COBJS-$(CONFIG_PCI) += pci.o
COBJS-y += ddr.o
Please (make and) keep list sorted.
...
+void ft_pci_board_setup(void *blob)
+{
+#ifdef CONFIG_PCIE2
+ft_fsl_pci_setup(blob, pci1, pcie2_hose);
PCIE2 ... pci1 ... pcie2 ???
The device tree has always been more generic and used 'pci' for PCI,
PCI-X, and PCIe buses.
+#endif
+#ifdef CONFIG_PCIE1
+ft_fsl_pci_setup(blob, pci2, pcie1_hose);
PCIE1 ... pci2 ... pcie1 ???
This looks broken to me?
This is actually correct.. This has to do w/stupid FSL documentation
and #. The device tree orders PCI buses based on there register
offset in CCSRBAR. So 0x9000 is pci1, 0xa000 is pci2. However FSL
docs and some internal SoC screwness lists the PCIe controller @ 9000
as PCIE2 and the one at A000 as PCIE1.
Probably should add a comment in the code about this.
- k
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot -Modifying boot sequence on a ARM based board
Hi all, What is the general boot sequence for u-boot. IIRC, its the cpu specific start followed by board specfic stuff, then general init stuff (like misc_init_f) and then the common stuff. The reason i am asking this i want to inject my own boot path based on the presence of certain boot peripherals. I want to override the boot_args with my custom-defined bootargs and then execute bootm from a predefined RAM address. I want to know which is the most appropriate place for soing this. I was initilally thinking it would end up in the board specific code(board/boardname.c) but i am a bit confused when i read the main/common code. Please let me your recommendations on this. -Alfred. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] nand read
Hi, Does mtd has to be enabled/setup for nand read to work? I'm trying to do a I keep getting a read error when trying to read even the first block. NAND read: device 0 offset 0x0, size 0x2 NAND read from offset 0 failed -74 131072 bytes read: ERROR ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] nand read
Spoken too quickly user error. On Thu, Aug 20, 2009 at 11:13 AM, E Robertsone.robertson@gmail.com wrote: Hi, Does mtd has to be enabled/setup for nand read to work? I'm trying to do a I keep getting a read error when trying to read even the first block. NAND read: device 0 offset 0x0, size 0x2 NAND read from offset 0 failed -74 131072 bytes read: ERROR ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [v2][PATCH] ppc/85xx: Added single core members of FSL P1 P2 processors series
P2010 - single core variant of P2020
P1011 - Single core variant of P1020
- Also made changes to keep the lists sorted.
Signed-off-by: Poonam Aggrwal poonam.aggr...@freescale.com
Signed-off-by: Kumar Gala ga...@kernel.crashing.org
---
- applies on git.denx.de/u-boot-mpc85xx.git branch-next
cpu/mpc85xx/Makefile|4 +++-
cpu/mpc8xxx/cpu.c |8 ++--
drivers/misc/fsl_law.c |3 ++-
include/asm-ppc/processor.h |8 ++--
4 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/cpu/mpc85xx/Makefile b/cpu/mpc85xx/Makefile
index 1477eac..1bd8f30 100644
--- a/cpu/mpc85xx/Makefile
+++ b/cpu/mpc85xx/Makefile
@@ -49,8 +49,10 @@ COBJS-$(CONFIG_MPC8544) += ddr-gen2.o
COBJS-$(CONFIG_MPC8572) += ddr-gen3.o
COBJS-$(CONFIG_MPC8536) += ddr-gen3.o
COBJS-$(CONFIG_MPC8569)+= ddr-gen3.o
-COBJS-$(CONFIG_P2020) += ddr-gen3.o
+COBJS-$(CONFIG_P1011) += ddr-gen3.o
COBJS-$(CONFIG_P1020) += ddr-gen3.o
+COBJS-$(CONFIG_P2010) += ddr-gen3.o
+COBJS-$(CONFIG_P2020) += ddr-gen3.o
COBJS-$(CONFIG_MPC8536) += mpc8536_serdes.o
COBJS = traps.o cpu.o cpu_init.o speed.o interrupts.o tlb.o \
diff --git a/cpu/mpc8xxx/cpu.c b/cpu/mpc8xxx/cpu.c
index fbab998..339f6d9 100644
--- a/cpu/mpc8xxx/cpu.c
+++ b/cpu/mpc8xxx/cpu.c
@@ -64,10 +64,14 @@ struct cpu_type cpu_type_list [] = {
CPU_TYPE_ENTRY(8569, 8569_E, 1),
CPU_TYPE_ENTRY(8572, 8572, 2),
CPU_TYPE_ENTRY(8572, 8572_E, 2),
- CPU_TYPE_ENTRY(P2020, P2020, 2),
- CPU_TYPE_ENTRY(P2020, P2020_E, 2),
+ CPU_TYPE_ENTRY(P1011, P1011, 1),
+ CPU_TYPE_ENTRY(P1011, P1011_E, 1),
CPU_TYPE_ENTRY(P1020, P1020, 2),
CPU_TYPE_ENTRY(P1020, P1020_E, 2),
+ CPU_TYPE_ENTRY(P2010, P2010, 1),
+ CPU_TYPE_ENTRY(P2010, P2010_E, 1),
+ CPU_TYPE_ENTRY(P2020, P2020, 2),
+ CPU_TYPE_ENTRY(P2020, P2020_E, 2),
#elif defined(CONFIG_MPC86xx)
CPU_TYPE_ENTRY(8610, 8610, 1),
CPU_TYPE_ENTRY(8641, 8641, 2),
diff --git a/drivers/misc/fsl_law.c b/drivers/misc/fsl_law.c
index af7b729..147fe0a 100644
--- a/drivers/misc/fsl_law.c
+++ b/drivers/misc/fsl_law.c
@@ -39,7 +39,8 @@ DECLARE_GLOBAL_DATA_PTR;
defined(CONFIG_MPC8641) || defined(CONFIG_MPC8610)
#define FSL_HW_NUM_LAWS 10
#elif defined(CONFIG_MPC8536) || defined(CONFIG_MPC8572) || \
- defined(CONFIG_P2020) || defined(CONFIG_P1020)
+ defined(CONFIG_P1011) || defined(CONFIG_P1020) || \
+ defined(CONFIG_P2010) || defined(CONFIG_P2020)
#define FSL_HW_NUM_LAWS 12
#else
#error FSL_HW_NUM_LAWS not defined for this platform
diff --git a/include/asm-ppc/processor.h b/include/asm-ppc/processor.h
index 5547245..dcaf8c0 100644
--- a/include/asm-ppc/processor.h
+++ b/include/asm-ppc/processor.h
@@ -1009,10 +1009,14 @@
#define SVR_8569_E 0x808800
#define SVR_8572 0x80E000
#define SVR_8572_E 0x80E800
-#define SVR_P2020 0x80E200
-#define SVR_P2020_E0x80EA00
+#define SVR_P1011 0x80E500
+#define SVR_P1011_E0x80ED00
#define SVR_P1020 0x80E400
#define SVR_P1020_E0x80EC00
+#define SVR_P2010 0x80E300
+#define SVR_P2010_E0x80EB00
+#define SVR_P2020 0x80E200
+#define SVR_P2020_E0x80EA00
#define SVR_8610 0x80A000
#define SVR_8641 0x809000
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2][repost] arm: Kirkwood: add SYSRSTn Duration Counter Support
Okay I got it WE can do this but, There are just two APIs, overall size impact is not much (100 bytes max). The actual u-boot.bin size diff for newly posted patch is (169464- 169344= 120 bytes) ok fine Best Regards, J. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3] Adding support for DevKit8000
This patch adds support for the DevKit8000 board. Signed-off-by: Frederik Kriewitz frede...@kriewitz.eu --- mach-types.h needs to be synced (MACH_TYPE_DEVKIT8000) --- MAINTAINERS |4 + MAKEALL |1 + Makefile |3 + board/devkit8000/Makefile | 52 ++ board/devkit8000/config.mk| 35 board/devkit8000/devkit8000.c | 127 ++ board/devkit8000/devkit8000.h | 373 + doc/README.devkit8000 |8 + include/configs/devkit8000.h | 322 +++ 9 files changed, 925 insertions(+), 0 deletions(-) create mode 100644 board/devkit8000/Makefile create mode 100644 board/devkit8000/config.mk create mode 100644 board/devkit8000/devkit8000.c create mode 100644 board/devkit8000/devkit8000.h create mode 100644 doc/README.devkit8000 create mode 100644 include/configs/devkit8000.h diff --git a/MAINTAINERS b/MAINTAINERS index 620604c..03b2d10 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -706,6 +706,10 @@ Alex Z lartSA1100 dnp1110 SA1110 +Frederik Kriewitz frede...@kriewitz.eu + + devkit8000 ARM CORTEX-A8 (OMAP3530 SoC) + - Unknown / orphaned boards: diff --git a/MAKEALL b/MAKEALL index edebaea..34235b7 100755 --- a/MAKEALL +++ b/MAKEALL @@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8=\ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ + devkit8000 \ # diff --git a/Makefile b/Makefile index 329e0f5..9e3aa11 100644 --- a/Makefile +++ b/Makefile @@ -3066,6 +3066,9 @@ SMN42_config : unconfig ## ARM CORTEX Systems # +devkit8000_config :unconfig + @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 devkit8000 NULL omap3 + omap3_beagle_config : unconfig @$(MKCONFIG) $(@:_config=) arm arm_cortexa8 beagle omap3 omap3 diff --git a/board/devkit8000/Makefile b/board/devkit8000/Makefile new file mode 100644 index 000..38600c4 --- /dev/null +++ b/board/devkit8000/Makefile @@ -0,0 +1,52 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# (C) Copyright 2009 +# Frederik Kriewitz frede...@kriewitz.eu +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(BOARD).a + +COBJS := devkit8000.o + +SRCS := $(COBJS:.o=.c) +OBJS := $(addprefix $(obj),$(COBJS)) + +$(LIB):$(obj).depend $(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +clean: + rm -f $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak $(obj).depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/devkit8000/config.mk b/board/devkit8000/config.mk new file mode 100644 index 000..6bfcef7 --- /dev/null +++ b/board/devkit8000/config.mk @@ -0,0 +1,35 @@ +# +# (C) Copyright 2006 +# Texas Instruments, www.ti.com +# +# (C) Copyright 2009 +# Frederik Kriewitz frede...@kriewitz.eu +# +# DevKit8000 uses OMAP3 (ARM-CortexA8) cpu +# see http://www.ti.com/ for more information on Texas Instruments +# +# 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,
Re: [U-Boot] [PATCH v3] Adding support for DevKit8000
Hi Frederik, I had some minor aesthetic nitpicks. I'd change the title to Add support for the DevKit8000 board. snip diff --git a/MAINTAINERS b/MAINTAINERS index 620604c..03b2d10 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -706,6 +706,10 @@ Alex Z lartSA1100 dnp1110 SA1110 +Frederik Kriewitz frede...@kriewitz.eu + + devkit8000 ARM CORTEX-A8 (OMAP3530 SoC) + You should maintain the alphabetical order of MAINTAINERS when adding yourself. - Unknown / orphaned boards: diff --git a/MAKEALL b/MAKEALL index edebaea..34235b7 100755 --- a/MAKEALL +++ b/MAKEALL @@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8= \ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ + devkit8000 \ You should maintain the alphabetical order of LIST_ARM_CORTEX_A8. snip +/*--- + * Stack sizes + * + * The stack sizes are set up in start.S using the settings below + */ Other's might disagree, but I think the in the comments above are not necessary/non-standard. I'd personally use: /* * Stack sizes * * The stack sizes are set up in start.S using the settings below */ Or just: /* The stack sizes are set up in start.S using the settings below */ +#define CONFIG_STACKSIZE SZ_128K /* regular stack */ +#ifdef CONFIG_USE_IRQ +#define CONFIG_STACKSIZE_IRQ SZ_4K /* IRQ stack */ +#define CONFIG_STACKSIZE_FIQ SZ_4K /* FIQ stack */ +#endif + +/*--- + * Physical Memory Map + */ +#define CONFIG_NR_DRAM_BANKS 2 /* CS1 may or may not be populated */ +#define PHYS_SDRAM_1 OMAP34XX_SDRC_CS0 +#define PHYS_SDRAM_1_SIZESZ_128M /* at least 128 meg */ +#define PHYS_SDRAM_2 OMAP34XX_SDRC_CS1 + +/* SDRAM Bank Allocation method */ +#define SDRC_R_B_C 1 + +/*--- + * FLASH and environment organization + */ + +/* PISMO SUPPORT *** */ You should use a standard comment style for PISMO SUPPORT, eg less *'s and standard capitalization. + +/* Configure the PISMO */ Maybe get rid of the above comment too - its pretty clear that you're configuring the PISMO based on the PISMO SUPPORT comment above and the define name. +#define PISMO1_NAND_SIZE GPMC_SIZE_128M Best, Peter ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weird issues with u-boot on Microblaze
Michal Simek wrote: Hi, FIT support is not in mainline u-boot. Only in my testing repository. If I fix that and try to load a FIT image with a kernel and device-tree, the bootm command completely ignores the device tree; unfortunately, Yes the same thing as with FIT. Not in mainline yet. Simple no time. But I have patches in my tree and I want to send them to next merge open window. I don't have a log of this on hand, because now even image loading has broken somehow. For example, fatls ace 0 gives131074 . , and attempting DHCP boot results in a spew of ARP Retry count exceeded; starting again -- retry count exceeded, despite it never having tried even once? I'll test it. I've attached a log of the console output under both conditions, as well as the config.mk and xparameters.h under microblaze_generic; for some reason, the given U-Boot BSP assumes 100MHz, despite the board using 125MHz. Does anyone have advice for getting u-boot to work on this board? I have fix for u-boot bsp which fix it. The same issue is for uart16550. I am going to update my git repo at http://git.monstr.eu/git/gitweb.cgi There will be updated u-boot bsp too. Thanks, Michal Thanks in advance for any help. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot Thanks for the help! I cloned your u-boot-microblaze repository, and the same fit_hdr_t issues applied; now I'm also working out other various issues. If it would help, I can attach (or send) my project file or files, and even an image of the CompactFlash card I am using -- it's a 1GB card, with a 100MB fat16 and the rest in ext2. Oddly enough, ext2ls just plain returns silently. u-boot-microblaze/drivers/mtd/cfi_flash.c:2088: undefined reference to `monitor_flash_len' I've also noticed that the top BSP looks in the Xilinx install path and the project path, but not the EDK user repository. Thanks again for the help. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Adding support for DevKit8000
Peter Tyser wrote: Hi Frederik, I had some minor aesthetic nitpicks. I'd change the title to Add support for the DevKit8000 board. snip Unknown / orphaned boards: diff --git a/MAKEALL b/MAKEALL index edebaea..34235b7 100755 --- a/MAKEALL +++ b/MAKEALL @@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8= \ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ +devkit8000 \ You should maintain the alphabetical order of LIST_ARM_CORTEX_A8. What's about using 'omap3_devkit8000' ? Best regards Dirk ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4]: Move __set/clear_bit from ubifs.h to bitops.h
On Thursday 20 August 2009 04:52:50 Simon Kagstrom wrote: --- a/include/asm-sh/bitops.h +++ b/include/asm-sh/bitops.h @@ -146,6 +146,11 @@ static inline int ffs (int x) } return r; } + +#define __set_bit(nr, addr) generic_set_bit(nr, addr) + +#define __clear_bit(nr, addr) generic_clear_bit(nr, addr) this is just silly to put into every arch header. why not do in the common code: #ifndef __set_bit # define __set_bit generice_set_bit #endif -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] ppc/85xx: Added PCIe support for P1 P2 RDB
Dear Kumar Gala, In message 1938b866-a0c2-4152-8085-4bcc4e1a7...@kernel.crashing.org you wrote: PCIE1 ... pci2 ... pcie1 ??? This looks broken to me? This is actually correct.. This has to do w/stupid FSL documentation and #. The device tree orders PCI buses based on there register offset in CCSRBAR. So 0x9000 is pci1, 0xa000 is pci2. However FSL docs and some internal SoC screwness lists the PCIe controller @ 9000 as PCIE2 and the one at A000 as PCIE1. Probably should add a comment in the code about this. Yes, please. This looks just too much like a copy paste error. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There are three ways to get something done: do it yourself, hire someone, or forbid your kids to do it. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/4]: Move __set/clear_bit from ubifs.h to bitops.h
Dear Mike Frysinger, In message 200908201344.37190.vap...@gentoo.org you wrote: +#define __set_bit(nr, addr) generic_set_bit(nr, addr) + +#define __clear_bit(nr, addr) generic_clear_bit(nr, addr) this is just silly to put into every arch header. why not do in the common code: #ifndef __set_bit # define __set_bit generice_set_bit #endif Because it doesn't work? The code usually looks like this: static inline void __set_bit(...)... This defines a static inline function, but _not_ a preprocessor variable of that name. 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 When a program is being tested, it is too late to make design changes. -- Geoffrey James, The Tao of Programming ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] Adding support for DevKit8000
On Thu, Aug 20, 2009 at 7:28 PM, Dirk Behmedirk.be...@googlemail.com wrote: Peter Tyser wrote: Hi Frederik, I had some minor aesthetic nitpicks. I'd change the title to Add support for the DevKit8000 board. I'll fix them Unknown / orphaned boards: diff --git a/MAKEALL b/MAKEALL index edebaea..34235b7 100755 --- a/MAKEALL +++ b/MAKEALL @@ -581,6 +581,7 @@ LIST_ARM_CORTEX_A8= \ omap3_pandora \ omap3_zoom1 \ omap3_zoom2 \ + devkit8000 \ You should maintain the alphabetical order of LIST_ARM_CORTEX_A8. What's about using 'omap3_devkit8000' ? On Thu, Aug 20, 2009 at 7:02 PM, Peter Tyserpty...@xes-inc.com wrote: Hi Frederik, I had some minor aesthetic nitpicks. I'd change the title to Add support for the DevKit8000 board. Ok, I'll fix them. Jean-Christophe asked me to move it out of the omap3 vendor directory: On 10:55 Thu 20 Aug , Frederik Kriewitz wrote: On Thu, Aug 20, 2009 at 12:19 AM, Jean-Christophe PLAGNIOL-VILLARDplagn...@jcrosoft.com wrote: board/omap3/devkit8000/Makefile | 52 + board/omap3/devkit8000/config.mk| 35 board/omap3/devkit8000/devkit8000.c | 124 board/omap3/devkit8000/devkit8000.h | 373 +++ no need board are allow in board/omap3 please create your own vendor dirent or just put it in board/ What do you mean with that? board/devkit8000/devkit8000.h or board/embedinfo/devkit8000/devkit8000.h I'm confused, where am I supposed to use omap3 and where not? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question about Netconsole
Hi All- I have been having troubles getting Netconsole to work on eTSEC2 of a MPC8548 chip. I was hoping that maybe someone here might be able to help me. I'm currently using U-Boot v2009.01. Using the bash script code located in the README.Netconsole file, I have been able to successfully transmit data from the 8548 to my host machine over netcat (using v0.7.1 on Fedora Core 11). I've tested that this path works consistently by only piping stdout to 'nc'. My problem comes when I try to send data from the host machine to the 8548 (piping stdin to 'nc'). It seems like the data is getting transmitted by Netconsole (verified using wireshark), but it isn't getting consistently received by U-Boot. I set the ET_DEBUG flag to 1 so that I could get extra debug information. On rare occasions I have seen that packets are getting received, but this is very rarely. I do know that the connection is OK. I am able to transfer files using tftp without any problems. On one occasion I was able to print out an environment variable (a small victory), but it happened randomly. Does anyone have any idea why this might be happening? Any help would be greatly appreciated. Regards, Jared ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
