Re: [U-Boot] [PATCH][v0]p1_p2_rdb: to set SQW/INT pin of RTC as INT line
Dear Kumar, As there is no feedback on this patch in the maillist. Please pull this upstream. Thanks Priyanka -Original Message- From: Jain Priyanka-B32167 Sent: Monday, October 25, 2010 2:53 PM To: u-boot@lists.denx.de Cc: Jain Priyanka-B32167; Gala Kumar-B11780 Subject: [U-Boot] [PATCH][v0]p1_p2_rdb: to set SQW/INT pin of RTC as INT line p1_p2_rdb : SQW/INT pin in RTC can be used for generating square wave(by default) or as interrupt line. U-boot is registering this pin for interrupts. Configuring SQW/INT bit as interrupt line during board initialization to avoid spurious interrupts generated by square wave. Signed-off-by: Priyanka Jain priyanka.j...@freescale.com --- board/freescale/p1_p2_rdb/p1_p2_rdb.c |1 + include/configs/P1_P2_RDB.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/board/freescale/p1_p2_rdb/p1_p2_rdb.c b/board/freescale/p1_p2_rdb/p1_p2_rdb.c index fae31f2..0043184 100644 --- a/board/freescale/p1_p2_rdb/p1_p2_rdb.c +++ b/board/freescale/p1_p2_rdb/p1_p2_rdb.c @@ -156,6 +156,7 @@ int board_early_init_r(void) set_tlb(1, flashbase, CONFIG_SYS_FLASH_BASE_PHYS, MAS3_SX|MAS3_SW|MAS3_SR, MAS2_I|MAS2_G, 0, flash_esel, BOOKE_PAGESZ_16M, 1); + rtc_reset(); return 0; } diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h index cff0ed3..ba0c724 100644 --- a/include/configs/P1_P2_RDB.h +++ b/include/configs/P1_P2_RDB.h @@ -344,6 +344,7 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); #define CONFIG_SYS_EEPROM_BUS_NUM 1 #define CONFIG_RTC_DS1337 +#define CONFIG_SYS_RTC_DS1337_NOOSC #define CONFIG_SYS_I2C_RTC_ADDR0x68 /* * General PCI -- 1.6.5.6 ___ 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] ALERT! 90% of all board configurations BROKEN
Le 26/10/2010 02:11, Reinhard Meyer a écrit : That is #ifdef-ed away in case of ARM-relocation. Perhaps we should remove all code that pertains to WITHOUT_RELOC... Would make the rest of the code less obscure... I changed my board.config like this: ... /*#define CONFIG_SYS_GBL_DATA_SIZE 128*/ /* 128 bytes for initial data */ ... #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 /*- CONFIG_SYS_GBL_DATA_SIZE*/) ... and it still compiles. The second line is the only use of GBL_DATA_SIZE, since that is often set to somewhere in SRAM, it is still ok - even if set to the end of SRAM it will most likely wrap into the repeated SRAM image on most SoCs. Not all SoCs have SRAM. While the kirkwood family always has it, as does the Marvell 5182, the 5281 doesn't, for instance. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] RTC driver for PT7C4338 chip.
Dear Kumar,
As there is no feedback on this patch in the maillist. Please pull this
upstream.
Thanks
Priyanka
-Original Message-
From: Jain Priyanka-B32167
Sent: Thursday, October 21, 2010 9:22 AM
To: u-boot@lists.denx.de
Cc: Jain Priyanka-B32167
Subject: [PATCH][v2] RTC driver for PT7C4338 chip.
PT7C4338 chip is manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Freescale P1010RDB uses PT7C4338 as RTC.
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Acked-by: Timur Tabi ti...@freescale.com
---
Incoperated Heiko's and Wolfgang Denk's review comments.
drivers/rtc/Makefile |1 +
drivers/rtc/pt7c4338.c | 146
2 files changed, 147 insertions(+), 0 deletions(-) create mode 100644
drivers/rtc/pt7c4338.c
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile index
98734db..bbf9a7e 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -57,6 +57,7 @@ COBJS-$(CONFIG_RTC_MPC5200) += mpc5xxx.o
COBJS-$(CONFIG_RTC_MPC8xx) += mpc8xx.o
COBJS-$(CONFIG_RTC_PCF8563) += pcf8563.o
COBJS-$(CONFIG_RTC_PL031) += pl031.o
+COBJS-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
COBJS-$(CONFIG_RTC_RS5C372A) += rs5c372.o
COBJS-$(CONFIG_RTC_RTC4543) += rtc4543.o
COBJS-$(CONFIG_RTC_RX8025) += rx8025.o
diff --git a/drivers/rtc/pt7c4338.c b/drivers/rtc/pt7c4338.c new file
mode 100644 index 000..8b31649
--- /dev/null
+++ b/drivers/rtc/pt7c4338.c
@@ -0,0 +1,146 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ *
+ * Author: Priyanka Jain priyanka.j...@freescale.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
+ */
+
+/*
+ * This file provides Date Time support (no alarms) for PT7C4338
chip.
+ *
+ * This file is based on drivers/rtc/ds1337.c
+ *
+ * PT7C4338 chip is manufactured by Pericom Technology Inc.
+ * It is a serial real-time clock which provides
+ * 1)Low-power clock/calendar.
+ * 2)Programmable square-wave output.
+ * It has 56 bytes of nonvolatile RAM.
+ *
+ * Freescale P1010RDB uses PT7C4338 as RTC.
+ */
+
+#include common.h
+#include command.h
+#include rtc.h
+#include i2c.h
+
+/* RTC register addresses */
+#define RTC_SEC_REG_ADDR0x0
+#define RTC_MIN_REG_ADDR0x1
+#define RTC_HR_REG_ADDR 0x2
+#define RTC_DAY_REG_ADDR0x3
+#define RTC_DATE_REG_ADDR 0x4
+#define RTC_MON_REG_ADDR0x5
+#define RTC_YR_REG_ADDR 0x6
+#define RTC_CTL_STAT_REG_ADDR 0x7
+
+/* RTC second register address bit */
+#define RTC_SEC_BIT_CH 0x80/* Clock Halt (in Register 0) */
+
+/* RTC control and status register bits */
+#define RTC_CTL_STAT_BIT_RS00x1/* Rate select 0 */
+#define RTC_CTL_STAT_BIT_RS10x2/* Rate select 1 */
+#define RTC_CTL_STAT_BIT_SQWE 0x10 /* Square Wave Enable */
+#define RTC_CTL_STAT_BIT_OSF0x20 /* Oscillator Stop Flag */
+#define RTC_CTL_STAT_BIT_OUT0x80 /* Output Level Control */
+
+/* RTC reset value */
+#define RTC_PT7C4338_RESET_VAL \
+ (RTC_CTL_STAT_BIT_RS0 | RTC_CTL_STAT_BIT_RS1 |
RTC_CTL_STAT_BIT_OUT)
+
+/** Helper functions /
+static u8 rtc_read(u8 reg)
+{
+ return i2c_reg_read(CONFIG_SYS_I2C_RTC_ADDR, reg); }
+
+static void rtc_write(u8 reg, u8 val)
+{
+ i2c_reg_write(CONFIG_SYS_I2C_RTC_ADDR, reg, val); }
+//
+
+/* Get the current time from the RTC */ int rtc_get(struct rtc_time
+*tmp) {
+ int ret = 0;
+ u8 sec, min, hour, mday, wday, mon, year, ctl_stat;
+
+ ctl_stat = rtc_read(RTC_CTL_STAT_REG_ADDR);
+ sec = rtc_read(RTC_SEC_REG_ADDR);
+ min = rtc_read(RTC_MIN_REG_ADDR);
+ hour = rtc_read(RTC_HR_REG_ADDR);
+ wday = rtc_read(RTC_DAY_REG_ADDR);
+ mday = rtc_read(RTC_DATE_REG_ADDR);
+ mon = rtc_read(RTC_MON_REG_ADDR);
+ year = rtc_read(RTC_YR_REG_ADDR);
+ debug(Get RTC year: %02x mon: %02x mday: %02x wday: %02x
+ hr: %02x min: %02x sec: %02x control_status: %02x\n,
+ year, mon, mday, wday, hour, min, sec, ctl_stat);
+
+
Re: [U-Boot] ALERT! 90% of all board configurations BROKEN
Hello Reinhard, Reinhard Meyer wrote: Dear Wolfgang Denk, this is an ALERT! I just noticed (when debugging a strage phenomenon) that most of the board configurations (170 out of 191 for PowerPC, _ALL_ for ARM) are broken, because the size of struct global_data has grown but CONFIG_SYS_GBL_DATA_SIZE has not been adapted (commit 91a7675 added 32 bytes - and yes, I am to blame for that, where is that brown paper bag...) Fact is, the overwhelming majority of boards has currently problems like this: sizeof(struct global_data) = 136, CONFIG_SYS_GBL_DATA_SIZE = 128 This may appear to work, or may cause funny errors, or simply hangs the board hard very early in booting. Grep-ing for CONFIG_SYS_GBL_DATA_SIZE in *.[chsS] Makefile *.ld it seems to me that with ELF-reloc active that define is not used anywhere at least in ARM. Or did I miss a place? Yep, for example I use it on the beagle3 board, look in: include/configs/omap3_beagle.h Checked sizeof(struct global_data) on beagle board, I get 92 bytes, which is OK with the define in the boardconfig: #define CONFIG_SYS_GBL_DATA_SIZE128 /* bytes reserved for */ /* initial data */ A fast look in arch/arm/include/asm/global_data.h: I think there should be only problems on arm boards, if CONFIG_AT91FAMILY is defined, because this define adds + 44 bytes ... bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mail list threading problem or mailer problem?
On Tue, Oct 26, 2010 at 1:36 AM, Shawn Guo wrote: Hi Mike, please do not top post I did not mean the threading view in gmail web client, but http://lists.denx.de/pipermail/u-boot/2010-October/thread.html so you're just talking about how pipermail is archiving things ? gmane seems to do it fine. -mike ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6 03/10] 83xx/85xx/86xx: LBC register cleanup
On Oct 25, 2010, at 8:34 AM, Wolfgang Denk wrote: Dear Becky, In message 1276792647-4563-4-git-send-email-bec...@kernel.crashing.org you wrote: Currently, 83xx, 86xx, and 85xx have a lot of duplicated code dedicated to defining and manipulating the LBC registers. Merge this into a single spot. To do this, we have to decide on a common name for the data structure that holds the lbc registers - it will now be known as fsl_lbc_t, and we adopt a common name for the immap layouts that include the lbc - this was previously known as either im_lbc or lbus; use the former. In addition, create accessors for the BR/OR regs that use in/out_be32 and use those instead of the mismash of access methods currently in play. I have done a successful ppc build all and tested a board or two from each processor family. Signed-off-by: Becky Bruce bec...@kernel.crashing.org Acked-by: Kim Phillips kim.phill...@freescale.com Unfortunately it turns out that this commit breaks flash support on the TQM85xx boards; saveenv will fails like this: = save Saving Environment to Flash... Un-Protected 2 sectors Un-Protected 2 sectors Erasing Flash... .. done Erased 2 sectors Writing to Flash... Flash not Erased Protected 2 sectors Protected 2 sectors Attempts to update the U-Boot image in flash fail with Copy to Flash... Outside available Flash etc. Looking at your patch (which probably works on other boards) I don't see an immediate problem; also, the BR0/OR0, BR1/OR1 mappings look the same, and flash detection appears to be normale. Do you have an ideas what I should look for? Hmm, how about dumping all of the LBC registers and comparing before/after this change. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Timer implementations (was: Re: [PATCH v2] mmc: omap: timeout counter fix)
I just had a look at other ARM implementations of timer.c.
Some have a colourful mix of 32 and 64 bits values, resulting
in some 64 bit timer functions returning the upper 32 bits always
cleared.
Some implement udelay() in the while (xxxtime() endtime); variant.
I will fix this for at91 and submit a patch.
I also see that:
void reset_timer(void)
{
gd-timer_reset_value = get_ticks();
}
ulong get_timer(ulong base)
{
return tick_to_time(get_ticks() - gd-timer_reset_value) - base;
}
If implemented with true 64 bits for get_ticks() that function is useable
for timeout programming:
ulong timeval = get_timer (0);
do {
...
} while (get_timer (timeval) TIMEOUT);
It appears that the base parameter and return value is in CONFIG_SYS_HZ
units, and not in native ticks. That causes 64 bit mul/div every
time get_timer() is called. Won't hurt in a timeout loop, though.
I guess the theoretically unnecessary function reset_timer() might have been
invented to mask the issue of 32 bit wraparounds when get_timer() is not truly
64 bits???
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
On 10/25/2010 11:01 PM, Reinhard Meyer wrote:
Dear Wolfgang Denk,
Dear Reinhard Meyer,
In message4cc66a67.4000...@emk-elektronik.de you wrote:
It fails in case the timer wraps around.
Assume 32 bit counters, start time = 0xFFF0, delay = 0x20. It
will compute end = 0x10, the while codition is immediately false, and
you don't have any delay at all, which most probably generates a
false error condition.
I used and assumed a 64 bit counter, that will not wrap around while
our civilization still exists...
The code is still wrong, and as a simple correct implementation exists
there is no excuse for using such incorrect code.
Please fix that!
Agreed here. People are invited to dig through u-boot and find all
those places.
If get_ticks() is only 32 bits worth, both methods will misbehave
at a 32 bit wrap over.
No.
start = time();
while ((time() - start)delay)
...
This works much better (assuming unsigned arithmetics).
True, provided the underlying timer is really 64 bits, otherwise
this fails, too...
You are wrong. Try for example this:
- snip ---
#includestdio.h
int main(void)
{
unsigned int time = 0xFFF0;
unsigned int delay = 0x20;
unsigned int start;
You are wrong here, because you take it out of context.
My demo is using the (declared as) 64 bit function get_ticks().
I mentioned above that this function MUST be truly returning 64
bits worth of (incrementing) value to make any version work.
If get_ticks() just returns a 32 bit counter value neither method will work
reliably. Just check all implementations that this function is implemented
correctly.
Hi All,
I have wondered for quite some time about the rush to make
get_ticks() return a 64 bit value. For any reasonable purpose, like
waiting a few seconds for something to complete, a 32 bit timebase is
plenty adequate. If the number of ticks per second is 10, i.e. a
1 GHz clock rate, the clock wraps in a 32 bit word about every five
seconds.
The trick is that time always moves forward, so a current get_ticks() -
a previous get_ticks() is ALWAYS a positive number. It is necessary to
check the clock more often than (0X1 - your_timeout) times per
second, but unless your timeout is very near the maximum time that fits
into 32 bits, this won't be a problem. Most CPUs have a counter that
count at a reasonable rate. Some CPUs also have a cycle counter that
runs at the CPU clock rate. These counters are useful to determine
exactly how many machine cycles a certain process took, and therefore
they have high resolution. Timers for simple delays neither need nor
want such resolution. If the only counter available on you CPU runs at
several GHz, and is 64 bits long, just shift it right a few bits to
reduce the resolution to a reasonable resolution and return a 32 bit
value. There is no need for a bunch of long long variables and extra
code running around to process simple timeouts. It may be that we need a
different routine for precision timing measurements with high
resolution, but it needn't, and probably shouldn't IMHO be get_ticks().
Best Regards,
Bill Campbell
___
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][v2] RTC driver for PT7C4338 chip.
On Oct 26, 2010, at 1:22 AM, Jain Priyanka-B32167 wrote: Dear Kumar, As there is no feedback on this patch in the maillist. Please pull this upstream. Thanks Priyanka I don't normally pick up drivers that are outside of the 8xxx space. Either a subsystem maintainer or Wolfgang would do that. Also, we are in the middle of a merge/fix cycle for the v2010.12 release. This patch would be for 'next' at this point. - k ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Mail list threading problem or mailer problem?
On Tue, Oct 26, 2010 at 2:41 PM, Mike Frysinger vap...@gentoo.org wrote: On Tue, Oct 26, 2010 at 1:36 AM, Shawn Guo wrote: I did not mean the threading view in gmail web client, but http://lists.denx.de/pipermail/u-boot/2010-October/thread.html so you're just talking about how pipermail is archiving things ? gmane seems to do it fine. -mike Yes, you are right. -- Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v3] RTC driver for PT7C4338 chip.
PT7C4338 chip is manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Freescale P1010RDB uses PT7C4338 as RTC.
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Acked-by: Timur Tabi ti...@freescale.com
---
drivers/rtc/Makefile |1 +
drivers/rtc/pt7c4338.c | 144
2 files changed, 145 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/pt7c4338.c
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 98734db..bbf9a7e 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -57,6 +57,7 @@ COBJS-$(CONFIG_RTC_MPC5200) += mpc5xxx.o
COBJS-$(CONFIG_RTC_MPC8xx) += mpc8xx.o
COBJS-$(CONFIG_RTC_PCF8563) += pcf8563.o
COBJS-$(CONFIG_RTC_PL031) += pl031.o
+COBJS-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
COBJS-$(CONFIG_RTC_RS5C372A) += rs5c372.o
COBJS-$(CONFIG_RTC_RTC4543) += rtc4543.o
COBJS-$(CONFIG_RTC_RX8025) += rx8025.o
diff --git a/drivers/rtc/pt7c4338.c b/drivers/rtc/pt7c4338.c
new file mode 100644
index 000..26e2c1e
--- /dev/null
+++ b/drivers/rtc/pt7c4338.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ *
+ * Author: Priyanka Jain priyanka.j...@freescale.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
+ */
+
+/*
+ * This file provides Date Time support (no alarms) for PT7C4338 chip.
+ *
+ * This file is based on drivers/rtc/ds1337.c
+ *
+ * PT7C4338 chip is manufactured by Pericom Technology Inc.
+ * It is a serial real-time clock which provides
+ * 1)Low-power clock/calendar.
+ * 2)Programmable square-wave output.
+ * It has 56 bytes of nonvolatile RAM.
+ */
+
+#include common.h
+#include command.h
+#include rtc.h
+#include i2c.h
+
+/* RTC register addresses */
+#define RTC_SEC_REG_ADDR0x0
+#define RTC_MIN_REG_ADDR0x1
+#define RTC_HR_REG_ADDR 0x2
+#define RTC_DAY_REG_ADDR0x3
+#define RTC_DATE_REG_ADDR 0x4
+#define RTC_MON_REG_ADDR0x5
+#define RTC_YR_REG_ADDR 0x6
+#define RTC_CTL_STAT_REG_ADDR 0x7
+
+/* RTC second register address bit */
+#define RTC_SEC_BIT_CH 0x80/* Clock Halt (in Register 0) */
+
+/* RTC control and status register bits */
+#define RTC_CTL_STAT_BIT_RS00x1/* Rate select 0 */
+#define RTC_CTL_STAT_BIT_RS10x2/* Rate select 1 */
+#define RTC_CTL_STAT_BIT_SQWE 0x10 /* Square Wave Enable */
+#define RTC_CTL_STAT_BIT_OSF0x20 /* Oscillator Stop Flag */
+#define RTC_CTL_STAT_BIT_OUT0x80 /* Output Level Control */
+
+/* RTC reset value */
+#define RTC_PT7C4338_RESET_VAL \
+ (RTC_CTL_STAT_BIT_RS0 | RTC_CTL_STAT_BIT_RS1 | RTC_CTL_STAT_BIT_OUT)
+
+/** Helper functions /
+static u8 rtc_read(u8 reg)
+{
+ return i2c_reg_read(CONFIG_SYS_I2C_RTC_ADDR, reg);
+}
+
+static void rtc_write(u8 reg, u8 val)
+{
+ i2c_reg_write(CONFIG_SYS_I2C_RTC_ADDR, reg, val);
+}
+//
+
+/* Get the current time from the RTC */
+int rtc_get(struct rtc_time *tmp)
+{
+ int ret = 0;
+ u8 sec, min, hour, mday, wday, mon, year, ctl_stat;
+
+ ctl_stat = rtc_read(RTC_CTL_STAT_REG_ADDR);
+ sec = rtc_read(RTC_SEC_REG_ADDR);
+ min = rtc_read(RTC_MIN_REG_ADDR);
+ hour = rtc_read(RTC_HR_REG_ADDR);
+ wday = rtc_read(RTC_DAY_REG_ADDR);
+ mday = rtc_read(RTC_DATE_REG_ADDR);
+ mon = rtc_read(RTC_MON_REG_ADDR);
+ year = rtc_read(RTC_YR_REG_ADDR);
+ debug(Get RTC year: %02x mon: %02x mday: %02x wday: %02x
+ hr: %02x min: %02x sec: %02x control_status: %02x\n,
+ year, mon, mday, wday, hour, min, sec, ctl_stat);
+
+ if (ctl_stat RTC_CTL_STAT_BIT_OSF) {
+ printf(### Warning: RTC oscillator has stopped\n);
+ /* clear the OSF flag */
+ rtc_write(RTC_CTL_STAT_REG_ADDR,
+ rtc_read(RTC_CTL_STAT_REG_ADDR)\
+~RTC_CTL_STAT_BIT_OSF);
+ ret = -1;
+ }
+
+ tmp-tm_sec = bcd2bin(sec 0x7F);
+ tmp-tm_min = bcd2bin(min
Re: [U-Boot] ppc4xx:tftp error
Dear Stefan Thank you very much for your replay! Hi Tim, On Sunday 24 October 2010 11:42:51 Tim Rachman wrote: According to your useful guides in our previous Emails, I examined again my ddr sdram parameters that i had set in u-boot. I'm interfacing HYB25D512160AT–7 to PPC440EP, with 133MHz plb frequency. What SDRAM/DDR init code are you using? Is it arch/powerpc/cpu/ppc4xx/sdram.c? Yes, I am. But I changed some parameters according to HYB25D512160AT–7 datasheet. unfortunately, I couldn't reach to an stable state, without error, in tftp a file . So I have two questions: At first: Would you mind to introduce me some useful links/Docs about initializing ddr sdram specially about testing memory in burst mode? This is a complex subject. One of the best tests we've found so far, is running Linux and compiling a Linux kernel on an NFS mounted file system. This generates all kinds of access patterns to and from the SDRAM interface. This test showed problems on boards that previously ran all kind of normal RAM tests without errors. I understand that this is not possible for you right now, since you will have problems loading a Linux kernel and especially mounting an NFS file system. You're right. I changed DDR SDRAM parameters but error remains , error occurs randomly. I need to find a way for testing ram in similar condition (burst mode) rather than tftp, I haven't run OS, but I think even I run an OS , I will have error, specially in net related operations. 2. I wrote for you I monitored *(hw_p-rx[user_index].data_ptr) data in ppc_4xx_eth_rx() functionin \driver\net\4xx_enet.c , and data was incorrect too at this stage. , Is hw_p-rx[user_index].data_ptr the memory location of DMAing eth packets directly? Yes, data_ptr as part of the mal_desc_t struct points to the data buffer. And the EMAC DMA controller (MAL) will transfer the data directly to and from this buffer. Note that the PPC4xx ethernet driver is used on many platforms without any such problems. So I don't think that this driver is responsible for the problem you're facing. I share Wolfgangs feelings, that an SDRAM configuation/setup related problem is more likely. A point: Our custom board doesn't have PCI , Is it possible that some setting in PCI routins of yosemite BSP has effect on their shared PLB BUS? BTW, I focus on SDRAM configuration more, Hopefully problem will be solved. Again, I thank for your consideration! 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 v2] mmc: omap: timeout counter fix
Dear Reinhard Meyer,
In message 4cc66eca.9000...@emk-elektronik.de you wrote:
Agreed here. People are invited to dig through u-boot and find all
those places.
You know the ones you added best :-)
int main(void)
{
unsigned int time = 0xFFF0;
unsigned int delay = 0x20;
unsigned int start;
You are wrong here, because you take it out of context.
I am not wrong. Feel free to replace unsigned int by unsigned long
long, and 0xFFF0 by 0xFFF0ULL, and the %X by %llX.
My demo is using the (declared as) 64 bit function get_ticks().
I mentioned above that this function MUST be truly returning 64
bits worth of (incrementing) value to make any version work.
What's the difference? It is inherently wrong to believe an overflow
would never occur just because the precision of a number is long
enough. Remeber y2k issues. Remember the time overflog for UNIX
systems in 2038, etc. etc.
If get_ticks() just returns a 32 bit counter value neither method will work
reliably. Just check all implementations that this function is implemented
correctly.
No, the code is still WRONG. It'ss just that the problem is less
likely to hit.
BTW - who says the timer starts counting at 0 ?
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Lack of skill dictates economy of style.- Joey Ramone
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH][v2] RTC driver for PT7C4338 chip.
Dear Kumar Gala, In message 1baab06c-391a-4eeb-bd42-ec4c65a7e...@kernel.crashing.org you wrote: I don't normally pick up drivers that are outside of the 8xxx space. Either a subsystem maintainer or Wolfgang would do that. Also, we are in the middle of a merge/fix cycle for the v2010.12 release. This patch would be for 'next' at this point. Right. I have / had this queued for 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 Q: How many IBM CPU's does it take to execute a job? A: Four; three to hold it down, and one to rip its head off. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] imx: Get fec mac address from fuse
On 10/22/2010 01:25 PM, Jason Liu wrote: The patch is to support getting FEC MAC address from fuse bank. Signed-off-by: Jason Liu r64...@freescale.com Hi Jason, patch is related to a network driver, so Ben should be informed, too. + /* + * The MX27 can store the mac address in internal eeprom + * This mechanism is also supported now by MX51 or MX25 + */ If all supported processors implement the same way, we do not need to distinguish. The comment does not add any further info. struct iim_regs *iim = (struct iim_regs *)IMX_IIM_BASE; int i; for (i = 0; i 6; i++) - mac[6-1-i] = readl(iim-iim_bank_area0[IIM0_MAC + i]); + mac[6-1-i] = readl(iim-iim_bank_area[IIM_MAC + i]); return !is_valid_ether_addr(mac); -#endif } static int fec_set_hwaddr(struct eth_device *dev) @@ -414,9 +410,6 @@ static int fec_init(struct eth_device *dev, bd_t* bd) uint32_t base; struct fec_priv *fec = (struct fec_priv *)dev-priv; - /* Initialize MAC address */ - fec_set_hwaddr(dev); - Not sure. Why is this call removed ? We have changed the storage for the MAC address, but we need always to set the FEC controller. What is the reason to drop it ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
Dear Wolfgang Denk,
Dear Reinhard Meyer,
In message 4cc66eca.9000...@emk-elektronik.de you wrote:
Agreed here. People are invited to dig through u-boot and find all
those places.
You know the ones you added best :-)
int main(void)
{
unsigned int time = 0xFFF0;
unsigned int delay = 0x20;
unsigned int start;
You are wrong here, because you take it out of context.
I am not wrong. Feel free to replace unsigned int by unsigned long
long, and 0xFFF0 by 0xFFF0ULL, and the %X by %llX.
My demo is using the (declared as) 64 bit function get_ticks().
I mentioned above that this function MUST be truly returning 64
bits worth of (incrementing) value to make any version work.
What's the difference? It is inherently wrong to believe an overflow
would never occur just because the precision of a number is long
enough. Remeber y2k issues. Remember the time overflog for UNIX
systems in 2038, etc. etc.
If get_ticks() just returns a 32 bit counter value neither method will work
reliably. Just check all implementations that this function is implemented
correctly.
You should really try to understand what I am saying here:
IF get_timer() returns 0x to 0x and wraps back
to 0x (thats how it is or was implemented in SOME architectures)
neither mine (agreed to be wrong) nor your code would work if it uses 64 bits
vars.
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] MX5: board version not printed corretly on MX51EVK
On 10/22/2010 01:25 PM, Jason Liu wrote:
Fix the board version printing issue on MX51EVK. Need to read
the board version via get_cpu_rev and not rely on system_rev
due to the system_rev not initialized at boardchecking time.
Signed-off-by: Jason Liu r64...@freescale.com
---
board/freescale/mx51evk/mx51evk.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
Hi Jason,
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index d6bb71c..c532603 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -438,6 +438,8 @@ int board_late_init(void)
int checkboard(void)
{
+ u32 system_rev = get_cpu_rev();
+
puts(Board: MX51EVK );
switch (system_rev 0xff) {
Then we need to clean up other part of the code: system_rev should be
not declared globally in the file and must be removed. In the same time,
get_board_rev() should be changed. It seems it is in any case wrong,
because it returns the same value, and this means get_cpu_rev().
As this is a cpu revision and not a board revision, it is not correct.
If the board revision cannot be determined correctly at runtime, we
should return a fixed value. but certainly not the cpu revision.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timer implementations
Wolfgang Denk schrieb:
Dear Reinhard Meyer,
In message 4cc67ca1.9090...@emk-elektronik.de you wrote:
If implemented with true 64 bits for get_ticks() that function is useable
for timeout programming:
ulong timeval = get_timer (0);
do {
...
} while (get_timer (timeval) TIMEOUT);
It appears that the base parameter and return value is in CONFIG_SYS_HZ
units, and not in native ticks. That causes 64 bit mul/div every
time get_timer() is called. Won't hurt in a timeout loop, though.
But it will hurt in othe rplaces.
Also, this code _is_ a bit different, as get_timer(0) makes sure
the counter starts ticking again at 0
Nope, it does not reset the counter itself. It returns the current
counter value (recalculated into CONFIG_SYS_HZ units).
Maybe you mean reset_timer() instead?
In arm9226ejs/omap/timer.c udelay() is implemented with reset_timer()
and get_timer(). Since those functions are inherently not nestable,
beware of base=get_timer(0); do { ... udelay(xx); ... } while (get_timer(base)
TIMEOUT);
constructs!
, and get_timer() is defined to
have millisecond resolution.
Actually CONFIG_SYS_HZ (whatever that is).
So you have a guaranteed 2^32
milliseconds or 4294967 seconds or about 3.3 years available which
indeed should be sufficient to implement standard timeouts.
I think it is necessary to summarize all implicit or explicit documented
defined to have's regarding the timer and then to verify that all
implementations adhere to them.
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
On 10/25/2010 05:14 PM, Shawn Guo wrote: +#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (IRAM_BASE_ADDR + 0x1000) What is the meaning of the offset at 0x1000 ? Is there something at IRAM_BASE_ADDR ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
Hi Stefano, On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic sba...@denx.de wrote: On 10/25/2010 05:14 PM, Shawn Guo wrote: +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (IRAM_BASE_ADDR + 0x1000) What is the meaning of the offset at 0x1000 ? Is there something at IRAM_BASE_ADDR ? I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp) which decrease the address. Is it not the case? -- Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ppc4xx:tftp error
Hi Tim, (please try to quote correctly upon replying, your answers are hard to read) On Tuesday 26 October 2010 09:21:50 Tim Rachman wrote: According to your useful guides in our previous Emails, I examined again my ddr sdram parameters that i had set in u-boot. I'm interfacing HYB25D512160AT–7 to PPC440EP, with 133MHz plb frequency. What SDRAM/DDR init code are you using? Is it arch/powerpc/cpu/ppc4xx/sdram.c? Yes, I am. But I changed some parameters according to HYB25D512160AT–7 datasheet. Which changes did you make exactly? Are you using the sdram_tr1_set() function to fine-tune the controller settings? snip A point: Our custom board doesn't have PCI , Is it possible that some setting in PCI routins of yosemite BSP has effect on their shared PLB BUS? No, I don't think so. But you should create a real board port for your custom board and remove such unused features as PCI in this process. BTW, I focus on SDRAM configuration more, Hopefully problem will be solved. Good luck. 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 2/2] mx51evk: correct internal RAM base address
On 10/25/2010 07:02 PM, Jason Liu wrote: HI, Shawn 2010/10/25 Shawn Guo shawn@gmail.com: i.mx51 internal RAM starts from 0x1FFE than 0x1FFE8000 Correctly speaking, i.mx51 TO1 SCCv2 RAM strart from 0x1FF8 0x1FFE8000, you mean. TO3 should be starting from 0x1FFE Maybe you need fix the commit log and state it clearly. Then there could be a problem. If we set the IRAM as for TO3, u-boot does not run on boards with TO1 (never seen) and TO2 (I used a board with it. Freescale sold several boards with TO2, so I do not think we can simply drop it). The stackpointer used before the relocation should be in an area common at least for TO2 and TO3. Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
On Tue, Oct 26, 2010 at 4:14 PM, Stefano Babic sba...@denx.de wrote: On 10/26/2010 10:05 AM, Shawn Guo wrote: Hi Stefano, On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic sba...@denx.de wrote: On 10/25/2010 05:14 PM, Shawn Guo wrote: +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (IRAM_BASE_ADDR + 0x1000) What is the meaning of the offset at 0x1000 ? Is there something at IRAM_BASE_ADDR ? I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp) which decrease the address. Is it not the case? Yes, my doubt is due to the fact that we do not set the SP at the end of the IRAM and we set it to an arbitrary address in between. At this point, IRAM is totally free for u-boot to use, so I simply reserved 4 KB from start. -- Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ALERT! 90% of all board configurations BROKEN
Dear Albert ARIBAUD, That is #ifdef-ed away in case of ARM-relocation. Perhaps we should remove all code that pertains to WITHOUT_RELOC... Would make the rest of the code less obscure... I changed my board.config like this: ... /*#define CONFIG_SYS_GBL_DATA_SIZE 128*/ /* 128 bytes for initial data */ ... #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 /*- CONFIG_SYS_GBL_DATA_SIZE*/) I must confess I copied that #define from other boards without much reasoning about it:) ... and it still compiles. The second line is the only use of GBL_DATA_SIZE, since that is often set to somewhere in SRAM, it is still ok - even if set to the end of SRAM it will most likely wrap into the repeated SRAM image on most SoCs. Not all SoCs have SRAM. While the kirkwood family always has it, as does the Marvell 5182, the 5281 doesn't, for instance. Point is, that probably there is enough space above CONFIG_SYS_INIT_SP_ADDR to hold the global data before relocation without overwriting essential values and without hitting an access fault, so the mistake did not hurt. And as Heiko points out, the global data is well below 128 bytes in the usual ARM cases. With ELF relocation (on AT91) boards the single use of CONFIG_SYS_GBL_DATA_SIZE is to reserve space above CONFIG_SYS_INIT_SP_ADDR. To really document that relationship, I will reorder the defines in my board.h: #define CONFIG_SYS_GBL_DATA_SIZE 256/* 256 bytes for initial data */ #define CONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
Hi Heiko, On Tue, Oct 26, 2010 at 4:25 PM, Heiko Schocher h...@denx.de wrote: Hello Stefano, Stefano Babic wrote: On 10/26/2010 10:05 AM, Shawn Guo wrote: Hi Stefano, On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic sba...@denx.de wrote: On 10/25/2010 05:14 PM, Shawn Guo wrote: +#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (IRAM_BASE_ADDR + 0x1000) What is the meaning of the offset at 0x1000 ? Is there something at IRAM_BASE_ADDR ? I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp) which decrease the address. Is it not the case? Yes, my doubt is due to the fact that we do not set the SP at the end of the IRAM and we set it to an arbitrary address in between. We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE - CONFIG_SYS_GBL_DATA_SIZE) Since u-boot is running in external memory, shouldn't CONFIG_SYS_GBL_DATA_SIZE be using the external memory space other than IRAM? -- Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
On 10/26/2010 10:25 AM, Heiko Schocher wrote: Hello Stefano, Stefano Babic wrote: On 10/26/2010 10:05 AM, Shawn Guo wrote: Hi Stefano, On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic sba...@denx.de wrote: On 10/25/2010 05:14 PM, Shawn Guo wrote: +#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (IRAM_BASE_ADDR + 0x1000) What is the meaning of the offset at 0x1000 ? Is there something at IRAM_BASE_ADDR ? I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp) which decrease the address. Is it not the case? Yes, my doubt is due to the fact that we do not set the SP at the end of the IRAM and we set it to an arbitrary address in between. We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE - CONFIG_SYS_GBL_DATA_SIZE) Agree, this is what I set for the vision2 board. We should be consistent and do the same for the mx51evk. Don;t know if IRAM_BASE_SIZE exists ... we must define it. I set it in the board configuration file, but it is wrong. The value should be moved into register definition file for the SoC (imx-regs.h) Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
Hello Shawn, Shawn Guo wrote: Hi Heiko, On Tue, Oct 26, 2010 at 4:25 PM, Heiko Schocher h...@denx.de wrote: Hello Stefano, Stefano Babic wrote: On 10/26/2010 10:05 AM, Shawn Guo wrote: Hi Stefano, On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic sba...@denx.de wrote: On 10/25/2010 05:14 PM, Shawn Guo wrote: +#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (IRAM_BASE_ADDR + 0x1000) What is the meaning of the offset at 0x1000 ? Is there something at IRAM_BASE_ADDR ? I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp) which decrease the address. Is it not the case? Yes, my doubt is due to the fact that we do not set the SP at the end of the IRAM and we set it to an arbitrary address in between. We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE - CONFIG_SYS_GBL_DATA_SIZE) Since u-boot is running in external memory, shouldn't CONFIG_SYS_GBL_DATA_SIZE be using the external memory space other than IRAM? U-Boot uses only before relocation the sp @CONFIG_SYS_INIT_SP_ADDR. This is for example for boards, which boots from NOR flash, and they have no working RAM before relocation. So Stackpointer should be setup in some none SDRAM. After relocation, Stackpointer is setup in SDRAM, and CONFIG_SYS_INIT_SP_ADDR is not longer used. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
Hello Stefano, Stefano Babic wrote: On 10/26/2010 10:25 AM, Heiko Schocher wrote: Hello Stefano, Stefano Babic wrote: On 10/26/2010 10:05 AM, Shawn Guo wrote: Hi Stefano, On Tue, Oct 26, 2010 at 3:59 PM, Stefano Babic sba...@denx.de wrote: On 10/25/2010 05:14 PM, Shawn Guo wrote: +#define CONFIG_SYS_SDRAM_BASEPHYS_SDRAM_1 +#define CONFIG_SYS_INIT_SP_ADDR (IRAM_BASE_ADDR + 0x1000) What is the meaning of the offset at 0x1000 ? Is there something at IRAM_BASE_ADDR ? I thought CONFIG_SYS_INIT_SP_ADDR is assigned to stack pointer (sp) which decrease the address. Is it not the case? Yes, my doubt is due to the fact that we do not set the SP at the end of the IRAM and we set it to an arbitrary address in between. We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE - CONFIG_SYS_GBL_DATA_SIZE) Agree, this is what I set for the vision2 board. We should be consistent and do the same for the mx51evk. Yep. Don;t know if IRAM_BASE_SIZE exists ... we must define it. I set it in the board configuration file, but it is wrong. The value should be moved into register definition file for the SoC (imx-regs.h) Full-Ack. This is a SoC define, not board dependend. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
On Tue, Oct 26, 2010 at 4:34 PM, Stefano Babic sba...@denx.de wrote: On 10/26/2010 10:25 AM, Heiko Schocher wrote: We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE - CONFIG_SYS_GBL_DATA_SIZE) Agree, this is what I set for the vision2 board. We should be consistent and do the same for the mx51evk. Don;t know if IRAM_BASE_SIZE exists ... we must define it. I set it in the board configuration file, but it is wrong. The value should be moved into register definition file for the SoC (imx-regs.h) I see many other platforms using 0x1000 offset way to define CONFIG_SYS_INIT_SP_ADDR, so I did that to make it a little bit more common. But I'm fine to start from the end, and will send v3 of this patch soon. -- Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
Hi Reinhard On Tue, Oct 26, 2010 at 5:04 PM, Reinhard Meyer u-b...@emk-elektronik.de wrote: Dear Shawn Guo, On Tue, Oct 26, 2010 at 4:34 PM, Stefano Babic sba...@denx.de wrote: On 10/26/2010 10:25 AM, Heiko Schocher wrote: We should set the CONFIG_SYS_INIT_SP_ADDR @ (IRAM_BASE_ADDR + IRAM_BASE_SIZE - CONFIG_SYS_GBL_DATA_SIZE) Agree, this is what I set for the vision2 board. We should be consistent and do the same for the mx51evk. Don;t know if IRAM_BASE_SIZE exists ... we must define it. I set it in the board configuration file, but it is wrong. The value should be moved into register definition file for the SoC (imx-regs.h) I see many other platforms using 0x1000 offset way to define CONFIG_SYS_INIT_SP_ADDR, so I did that to make it a little bit more common. But I'm fine to start from the end, and will send v3 of this patch soon. I just tried to add the symbolic version #define CONFIG_SYS_INIT_SP_ADDR (xxx_SRAM_BASE + xxx_SRAM_SIZE - CONFIG_SYS_GBL_DATA_SIZE) in AT91, but that means (assuming those xxx- defines come from an SoC specific file) that in start.s the includes #if defined(CONFIG_OMAP1610) #include ./configs/omap1510.h #elif defined(CONFIG_OMAP730) #include ./configs/omap730.h #endif have to be expanded for every SoC in question. Or to include the soc.h into the board.h... Which way to go? I'm going the way of including soc.h into board.h, as I see omap3_beagle.h is doing this way. -- Regards, Shawn ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2] imx25: Fix reset
This patch fixes the reset command on imx25
Signed-off-by: Matthias Weisser weiss...@arcor.de
---
arch/arm/cpu/arm926ejs/mx25/reset.c |8
arch/arm/include/asm/arch-mx25/imx-regs.h | 10 +-
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/arch/arm/cpu/arm926ejs/mx25/reset.c
b/arch/arm/cpu/arm926ejs/mx25/reset.c
index 1e33150..27270c3 100644
--- a/arch/arm/cpu/arm926ejs/mx25/reset.c
+++ b/arch/arm/cpu/arm926ejs/mx25/reset.c
@@ -43,14 +43,14 @@ void reset_cpu (ulong ignored)
{
struct wdog_regs *regs = (struct wdog_regs *)IMX_WDT_BASE;
/* Disable watchdog and set Time-Out field to 0 */
- writel (0x, regs-wcr);
+ writew(0x, regs-wcr);
/* Write Service Sequence */
- writel (0x, regs-wsr);
- writel (0x, regs-wsr);
+ writew(0x, regs-wsr);
+ writew(0x, regs-wsr);
/* Enable watchdog */
- writel (WCR_WDE, regs-wcr);
+ writew(WCR_WDE, regs-wcr);
while (1) ;
}
diff --git a/arch/arm/include/asm/arch-mx25/imx-regs.h
b/arch/arm/include/asm/arch-mx25/imx-regs.h
index f709bd8..fe258a8 100644
--- a/arch/arm/include/asm/arch-mx25/imx-regs.h
+++ b/arch/arm/include/asm/arch-mx25/imx-regs.h
@@ -108,11 +108,11 @@ struct gpt_regs {
/* Watchdog Timer (WDOG) registers */
struct wdog_regs {
- u32 wcr;/* Control */
- u32 wsr;/* Service */
- u32 wrsr; /* Reset Status */
- u32 wicr; /* Interrupt Control */
- u32 wmcr; /* Misc Control */
+ u16 wcr;/* Control */
+ u16 wsr;/* Service */
+ u16 wrsr; /* Reset Status */
+ u16 wicr; /* Interrupt Control */
+ u16 wmcr; /* Misc Control */
};
/* IIM control registers */
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH][v4] RTC driver for PT7C4338 chip.
PT7C4338 chip is being manufactured by Pericom Technology Inc.
It is a serial real-time clock which provides:
1)Low-power clock/calendar.
2)Programmable square-wave output.
It has 56 bytes of nonvolatile RAM.
Signed-off-by: Priyanka Jain priyanka.j...@freescale.com
Acked-by: Timur Tabi ti...@freescale.com
---
PT7C4338 RTC driver is verified on Freescale P1010RDB.
Changes for v1:
Incoperated Heiko's review comments
-keeping the Makefile list sorted.
-Removing unneccesary blank lines.
Changes for v2:
Incoperated Wolfgang Denk's review comments
-Merging two checks of RTC Oscillator stop check into one
Changes for v3:
-Removing board name from pt7c4338.c file as this can be used
for any board having PT7C4338 chip.
Changes for v4:
Incoperated Wolfgang Denk's review comments
-Attaching patch change log
drivers/rtc/Makefile |1 +
drivers/rtc/pt7c4338.c | 144
2 files changed, 145 insertions(+), 0 deletions(-)
create mode 100644 drivers/rtc/pt7c4338.c
diff --git a/drivers/rtc/Makefile b/drivers/rtc/Makefile
index 98734db..bbf9a7e 100644
--- a/drivers/rtc/Makefile
+++ b/drivers/rtc/Makefile
@@ -57,6 +57,7 @@ COBJS-$(CONFIG_RTC_MPC5200) += mpc5xxx.o
COBJS-$(CONFIG_RTC_MPC8xx) += mpc8xx.o
COBJS-$(CONFIG_RTC_PCF8563) += pcf8563.o
COBJS-$(CONFIG_RTC_PL031) += pl031.o
+COBJS-$(CONFIG_RTC_PT7C4338) += pt7c4338.o
COBJS-$(CONFIG_RTC_RS5C372A) += rs5c372.o
COBJS-$(CONFIG_RTC_RTC4543) += rtc4543.o
COBJS-$(CONFIG_RTC_RX8025) += rx8025.o
diff --git a/drivers/rtc/pt7c4338.c b/drivers/rtc/pt7c4338.c
new file mode 100644
index 000..26e2c1e
--- /dev/null
+++ b/drivers/rtc/pt7c4338.c
@@ -0,0 +1,144 @@
+/*
+ * Copyright 2010 Freescale Semiconductor, Inc.
+ *
+ * Author: Priyanka Jain priyanka.j...@freescale.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
+ */
+
+/*
+ * This file provides Date Time support (no alarms) for PT7C4338 chip.
+ *
+ * This file is based on drivers/rtc/ds1337.c
+ *
+ * PT7C4338 chip is manufactured by Pericom Technology Inc.
+ * It is a serial real-time clock which provides
+ * 1)Low-power clock/calendar.
+ * 2)Programmable square-wave output.
+ * It has 56 bytes of nonvolatile RAM.
+ */
+
+#include common.h
+#include command.h
+#include rtc.h
+#include i2c.h
+
+/* RTC register addresses */
+#define RTC_SEC_REG_ADDR0x0
+#define RTC_MIN_REG_ADDR0x1
+#define RTC_HR_REG_ADDR 0x2
+#define RTC_DAY_REG_ADDR0x3
+#define RTC_DATE_REG_ADDR 0x4
+#define RTC_MON_REG_ADDR0x5
+#define RTC_YR_REG_ADDR 0x6
+#define RTC_CTL_STAT_REG_ADDR 0x7
+
+/* RTC second register address bit */
+#define RTC_SEC_BIT_CH 0x80/* Clock Halt (in Register 0) */
+
+/* RTC control and status register bits */
+#define RTC_CTL_STAT_BIT_RS00x1/* Rate select 0 */
+#define RTC_CTL_STAT_BIT_RS10x2/* Rate select 1 */
+#define RTC_CTL_STAT_BIT_SQWE 0x10 /* Square Wave Enable */
+#define RTC_CTL_STAT_BIT_OSF0x20 /* Oscillator Stop Flag */
+#define RTC_CTL_STAT_BIT_OUT0x80 /* Output Level Control */
+
+/* RTC reset value */
+#define RTC_PT7C4338_RESET_VAL \
+ (RTC_CTL_STAT_BIT_RS0 | RTC_CTL_STAT_BIT_RS1 | RTC_CTL_STAT_BIT_OUT)
+
+/** Helper functions /
+static u8 rtc_read(u8 reg)
+{
+ return i2c_reg_read(CONFIG_SYS_I2C_RTC_ADDR, reg);
+}
+
+static void rtc_write(u8 reg, u8 val)
+{
+ i2c_reg_write(CONFIG_SYS_I2C_RTC_ADDR, reg, val);
+}
+//
+
+/* Get the current time from the RTC */
+int rtc_get(struct rtc_time *tmp)
+{
+ int ret = 0;
+ u8 sec, min, hour, mday, wday, mon, year, ctl_stat;
+
+ ctl_stat = rtc_read(RTC_CTL_STAT_REG_ADDR);
+ sec = rtc_read(RTC_SEC_REG_ADDR);
+ min = rtc_read(RTC_MIN_REG_ADDR);
+ hour = rtc_read(RTC_HR_REG_ADDR);
+ wday = rtc_read(RTC_DAY_REG_ADDR);
+ mday = rtc_read(RTC_DATE_REG_ADDR);
+ mon = rtc_read(RTC_MON_REG_ADDR);
+ year = rtc_read(RTC_YR_REG_ADDR);
+ debug(Get RTC year: %02x mon: %02x mday: %02x wday: %02x
+ hr:
Re: [U-Boot] [PATCH V2] imx25: Fix reset
Dear Matthias Weisser, This patch fixes the reset command on imx25 Signed-off-by: Matthias Weisser weiss...@arcor.de + writew(0x, regs-wcr); + writew(0x, regs-wsr); + writew(0x, regs-wsr); It might be nicer to use 16 Bit constants (with 4 hex digits) here..? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ALERT! 90% of all board configurations BROKEN
Dear Reinhard Meyer, In message 4cc6909f.4060...@emk-elektronik.de you wrote: Dear Albert ARIBAUD, That is #ifdef-ed away in case of ARM-relocation. Perhaps we should remove all code that pertains to WITHOUT_RELOC... Would make the rest of the code less obscure... I changed my board.config like this: ... /*#define CONFIG_SYS_GBL_DATA_SIZE 128*/ /* 128 bytes for initial data */ ... #defineCONFIG_SYS_INIT_SP_ADDR (CONFIG_SYS_SDRAM_BASE + 0x1000 /*- CONFIG_SYS_GBL_DATA_SIZE*/) I must confess I copied that #define from other boards without much reasoning about it:) I just mentioned it in another mail: there is lots of confusion in this area, and little common code. I will try to remove all of this. All we need is the address and size of the initial RAM area; all the rest can (now) be automatically calculated. Patches are in the works. 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 Emotions are alien to me. I'm a scientist. -- Spock, This Side of Paradise, stardate 3417.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 1/2] Freescale 85xx/P1/P2 eSPI controller driver
Driver for the Freescale eSPI controller found in 85xx, P1/P2 and P4xx SoCs.
Signed-off-by: Can Aydin can.ay...@locatacorp.com
---
Changes for v2:
- Coding style cleanup
- Removed modifications to common code
Changes for v3:
- fixed whitespace between function calls and parameters
- replaced unneeded byte copy test function with memcpy
- removed dead code and C++ style comments
- separated board configuration patch from driver patch
drivers/spi/Makefile |1 +
drivers/spi/fsl_espi.c | 240
include/fsl_espi.h | 50 ++
3 files changed, 291 insertions(+), 0 deletions(-)
create mode 100644 drivers/spi/fsl_espi.c
create mode 100644 include/fsl_espi.h
diff --git a/drivers/spi/Makefile b/drivers/spi/Makefile
index dfcbb8b..1aaa8e7 100644
--- a/drivers/spi/Makefile
+++ b/drivers/spi/Makefile
@@ -31,6 +31,7 @@ COBJS-$(CONFIG_ATMEL_SPI) += atmel_spi.o
COBJS-$(CONFIG_BFIN_SPI) += bfin_spi.o
COBJS-$(CONFIG_CF_SPI) += cf_spi.o
COBJS-$(CONFIG_DAVINCI_SPI) += davinci_spi.o
+COBJS-$(CONFIG_FSL_ESPI) += fsl_espi.o
COBJS-$(CONFIG_KIRKWOOD_SPI) += kirkwood_spi.o
COBJS-$(CONFIG_MPC52XX_SPI) += mpc52xx_spi.o
COBJS-$(CONFIG_MPC8XXX_SPI) += mpc8xxx_spi.o
diff --git a/drivers/spi/fsl_espi.c b/drivers/spi/fsl_espi.c
new file mode 100644
index 000..749d3f1
--- /dev/null
+++ b/drivers/spi/fsl_espi.c
@@ -0,0 +1,240 @@
+/*
+ * Freescale eSPI controller driver.
+ *
+ * Copyright 2010 Locata Corporation Pty. Ltd.
+ * Author: Can Aydin can.ay...@locatacorp.com
+ * Collab: Clayton Gumbrellclayton.gumbr...@locatacorp.com
+ *
+ * Adapted from Freescale ltib code by Mingkai Hu (mingkai...@freescale.com)
+ * Copyright 2009 Freescale Semiconductor, Inc.
+ *
+ * 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 malloc.h
+#include spi.h
+#include fsl_espi.h
+#include asm/immap_85xx.h
+
+struct spi_slave *spi_setup_slave(unsigned int bus, unsigned int cs,
+ unsigned int max_hz, unsigned int mode)
+{
+ volatile ccsr_espi_t *espi = (void *)(CONFIG_SYS_MPC85xx_ESPI_ADDR);
+ struct spi_slave *slave;
+ sys_info_t sysinfo;
+ unsigned long spibrg = 0;
+ unsigned char pm = 0;
+ int i;
+
+ if (!spi_cs_is_valid(bus, cs))
+ return NULL;
+
+ slave = malloc(sizeof(struct spi_slave));
+ if (!slave)
+ return NULL;
+
+ slave-bus = bus;
+ slave-cs = cs;
+
+ /* Enable eSPI interface */
+ espi-mode = ESPI_MODE_RXTHR(3) | ESPI_MODE_TXTHR(4) | ESPI_MODE_EN;
+
+ espi-event = 0x; /* Clear all eSPI events */
+ espi-mask = 0x;/* Mask all eSPI interrupts */
+
+ /* Init CS mode interface */
+ for (i = 0; i ESPI_MAX_CS_NUM; i++)
+ espi-csmode[i] = ESPI_CSMODE_INIT_VAL;
+
+ espi-csmode[cs] =
+ ~(ESPI_CSMODE_PM(0xF) | ESPI_CSMODE_DIV16
+ | ESPI_CSMODE_CI_INACTIVEHIGH | ESPI_CSMODE_CP_BEGIN_EDGCLK
+ | ESPI_CSMODE_REV_MSB_FIRST | ESPI_CSMODE_LEN(ESPI_MAX_CHARSIZE));
+
+ /* Set eSPI BRG clock source */
+ get_sys_info(sysinfo);
+ spibrg = sysinfo.freqSystemBus / 2;
+ if ((spibrg / max_hz) 32) {
+ espi-csmode[cs] |= ESPI_CSMODE_DIV16;
+ pm = spibrg / (max_hz * 16 * 2);
+ if (pm 16) {
+ pm = 16;
+ debug(Requested speed is too low: %d Hz
+ %u Hz is used.\n, max_hz,
+ (uint) (spibrg / (32 * 16)));
+ }
+ } else
+ pm = spibrg / (max_hz * 2);
+ if (pm)
+ pm--;
+ espi-csmode[cs] |= ESPI_CSMODE_PM(pm);
+
+ /* Set eSPI mode */
+ if (mode SPI_CPHA)
+ espi-csmode[cs] |= ESPI_CSMODE_CP_BEGIN_EDGCLK;
+ if (mode SPI_CPOL)
+ espi-csmode[cs] |= ESPI_CSMODE_CI_INACTIVEHIGH;
+
+ /* Character bit order: msb first */
+ espi-csmode[cs] |= ESPI_CSMODE_REV_MSB_FIRST;
+
+ /* Character length in bits, between 0x3~0xf, i.e. 4bits~16bits */
+ espi-csmode[cs] |= ESPI_CSMODE_LEN(ESPI_CHARSIZE);
+
+ return slave;
+}
+
Re: [U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
Dear Heiko Schocher, In message 4cc693fe.4090...@denx.de you wrote: Don;t know if IRAM_BASE_SIZE exists ... we must define it. I set it in the board configuration file, but it is wrong. The value should be moved into register definition file for the SoC (imx-regs.h) Full-Ack. This is a SoC define, not board dependend. It may be board dependent - for exmaple, when there is some large and conveniently usable SRAM on a board, you might want to use that instead of any limited area on the SoC. 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 Either one of us, by himself, is expendable. Both of us are not. -- Kirk, The Devil in the Dark, stardate 3196.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v3 2/2] Freescale 85xx/P1/P2 eSPI controller driver
Add support for Freescale eSPI driver in P1/P2 board configuration Signed-off-by: Can Aydin can.ay...@locatacorp.com --- Changes for v2: - Coding style cleanup - Removed modifications to common code Changes for v3: - fixed whitespace between function calls and parameters - replaced unneeded byte copy test function with memcpy - removed dead code and C++ style comments - separated board configuration patch from driver patch include/configs/P1_P2_RDB.h |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/include/configs/P1_P2_RDB.h b/include/configs/P1_P2_RDB.h index cff0ed3..33f1b1e 100644 --- a/include/configs/P1_P2_RDB.h +++ b/include/configs/P1_P2_RDB.h @@ -172,6 +172,13 @@ extern unsigned long get_board_sys_clk(unsigned long dummy); */ /* + * eSPI - Enhanced SPI + */ +#define CONFIG_FSL_ESPI +#define CONFIG_HARD_SPI +#define CONFIG_CMD_SPI + +/* * Local Bus Definitions */ #define CONFIG_SYS_FLASH_BASE 0xef00 /* start of FLASH 16M */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Not getting any prompt on hyper terminal
Dear All, I am new to this U-Boot boot loader environment. We have a AMCC PPC 440EP processor board which is derived from AMCC Yosemite board. I meant, we have prepared (customised) our own board which is equivalent to AMCC Yosemite board. For this board, I build the U-Boot boot loader with the help of ELDK on Ubuntu x86 host system. However, I have modified the following file contents as per my board and processor attributes. file name located directory - 1) yosemite.hu-boot/include/configs 2) board.c u-boot/arch/powerpc/lib 3) init.S and yosemite.c u-boot/board/amcc/yosemite 4) start.S u-boot/arch/powerpc/cpu/ppc4xx After above four file modifications, the u-boot.bin file is created and able to load into our board. However, we are NOT getting any prompt on the hyper terminal. When we debug the sources through our laterbach debugger, we found that the control entered into the relocate_code() function which is called from board_init_f () function. The board_init_f () function is available in board.c file. However, the relocate_code() is implemented in the start.S file. As this is a assembly file, I am not able to understand it completely. The memories that we are using in our board are DDR SDRAM (64MB - Bank0), Boot flash (32MB - CS0), Application flash (32MB - CS1). We modified these parameters in the yosemite.h file and after loading the u-boot.bin file, we are able to see all the memories configured correctly. However, we are not getting the U-Boot prompt on the hyper terminal. Please let me know, If I am missing any thing here. Any help would be greatly appreciated. Thanks and Regards, Srinivas G ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] net: ne2000: Add spport RTL-8019AS
Add infomation of RTL-8016AS to hw_info.
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org
CC: Ben Warren biggerbadder...@gmail.com
---
drivers/net/ne2000.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ne2000.c b/drivers/net/ne2000.c
index ab5eec7..7a85314 100644
--- a/drivers/net/ne2000.c
+++ b/drivers/net/ne2000.c
@@ -164,7 +164,8 @@ static hw_info_t hw_info[] = {
{ /* Volktek NPL-402CT */ 0x0060, 0x00, 0x40, 0x05, 0 },
{ /* NEC PC-9801N-J12 */ 0x0ff0, 0x00, 0x00, 0x4c, 0 },
{ /* PCMCIA Technology OEM */ 0x01c8, 0x00, 0xa0, 0x0c, 0 },
- { /* Qemu */ 0x0, 0x52, 0x54, 0x00, 0 }
+ { /* Qemu */ 0x0, 0x52, 0x54, 0x00, 0 },
+ { /* RTL8019AS */ 0x0, 0x0, 0x18, 0x5f, 0 }
};
#define NR_INFO(sizeof(hw_info)/sizeof(hw_info_t))
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] sh: Add support SH7706
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- arch/sh/include/asm/cpu_sh3.h|6 +++- arch/sh/include/asm/cpu_sh7706.h | 53 ++ 2 files changed, 57 insertions(+), 2 deletions(-) create mode 100644 arch/sh/include/asm/cpu_sh7706.h diff --git a/arch/sh/include/asm/cpu_sh3.h b/arch/sh/include/asm/cpu_sh3.h index 6db38a2..385f5dc 100644 --- a/arch/sh/include/asm/cpu_sh3.h +++ b/arch/sh/include/asm/cpu_sh3.h @@ -1,5 +1,5 @@ /* - * (C) Copyright 2007 Nobuhiro Iwamatsu iwama...@nigauri.org + * (C) Copyright 2007-2009 Nobuhiro Iwamatsu iwama...@nigauri.org * (C) Copyright 2007 Yoshihiro Shimoda shimoda.yoshih...@renesas.com * * This program is free software; you can redistribute it and/or @@ -31,7 +31,9 @@ #define CACHE_OC_NUM_ENTRIES 256 #define CACHE_OC_ENTRY_SHIFT 4 -#if defined(CONFIG_CPU_SH7710) +#if defined(CONFIG_CPU_SH7706) +#include asm/cpu_sh7706.h +#elif defined(CONFIG_CPU_SH7710) #include asm/cpu_sh7710.h #elif defined(CONFIG_CPU_SH7720) #include asm/cpu_sh7720.h diff --git a/arch/sh/include/asm/cpu_sh7706.h b/arch/sh/include/asm/cpu_sh7706.h new file mode 100644 index 000..d093f88 --- /dev/null +++ b/arch/sh/include/asm/cpu_sh7706.h @@ -0,0 +1,53 @@ +#ifndef _ASM_CPU_SH7706_H_ +#define _ASM_CPU_SH7706_H_ + +#define CACHE_OC_NUM_WAYS 4 +#define CCR_CACHE_INIT 0x000D + +/* MMU and Cache control */ +#define MMUCR 0xFFE0 +#define CCR0xFFEC + +/* PFC */ +#define PACR 0xA4050100 +#define PBCR 0xA4050102 +#define PCCR 0xA4050104 +#define PETCR 0xA4050106 + +/* Port Data Registers */ +#define PADR 0xA4050120 +#define PBDR 0xA4050122 +#define PCDR 0xA4050124 + +/* BSC */ +#defineFRQCR 0xff80 +#defineBCR10xff60 +#defineBCR20xff62 +#defineWCR10xff64 +#defineWCR20xff66 +#defineMCR 0xff68 + +/* SDRAM controller */ +#defineDCR 0xff6a +#defineRTCSR 0xff6e +#defineRTCNT 0xff70 +#defineRTCOR 0xff72 +#defineRFCR0xff74 +#define SDMR 0xD000 +#define CS3_R 0xE460 + +/* SCIF */ +#define SCSMR_20xA4000150 +#define SCIF0_BASE SCSMR_2 + +/* Timer */ +#define TSTR0 0xFE92 +#define TSTR TSTR0 +#define TCNT0 0xFE98 +#define TCR0 0xFE9C + +/* On chip oscillator circuits */ +#defineWTCNT 0xFF84 +#defineWTCSR 0xFF86 + +#endif /* _ASM_CPU_SH7706_H_ */ -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3] sh: Add support showing KByte of flash memory size
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- arch/sh/lib/board.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) diff --git a/arch/sh/lib/board.c b/arch/sh/lib/board.c index a302fc2..bf3a5cc 100644 --- a/arch/sh/lib/board.c +++ b/arch/sh/lib/board.c @@ -1,5 +1,5 @@ /* - * Copyright (C) 2007,2008 + * Copyright (C) 2007, 2008, 2010 * Nobuhiro Iwamatsu iwama...@nigauri.org * * This program is free software; you can redistribute it and/or @@ -46,7 +46,11 @@ static int sh_flash_init(void) DECLARE_GLOBAL_DATA_PTR; gd-bd-bi_flashsize = flash_init(); - printf(FLASH: %ldMB\n, gd-bd-bi_flashsize / (1024*1024)); + + if (gd-bd-bi_flashsize = (1024 * 1024)) + printf(FLASH: %ldMB\n, gd-bd-bi_flashsize / (1024*1024)); + else + printf(FLASH: %ldKB\n, gd-bd-bi_flashsize / 1024); return 0; } -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] sh: Add support shmin board
This adds support for the SHMIN SH7706 board(T-SH7706LAN). The CPU of this board is SH7706. There are SDRAM of 32M byte, Flash memory of 512K byte, Serial, 10Base Ether and MMC. http://web.kyoto-inet.or.jp/people/takagaki/T-SH7706/T-SH7706.htm Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org --- MAINTAINERS |1 + board/shmin/Makefile| 49 ++ board/shmin/config.mk | 27 ++ board/shmin/lowlevel_init.S | 36 + board/shmin/shmin.c | 108 boards.cfg |1 + include/configs/shmin.h | 115 +++ 7 files changed, 337 insertions(+), 0 deletions(-) create mode 100644 board/shmin/Makefile create mode 100644 board/shmin/config.mk create mode 100644 board/shmin/lowlevel_init.S create mode 100644 board/shmin/shmin.c create mode 100644 include/configs/shmin.h diff --git a/MAINTAINERS b/MAINTAINERS index b0da631..27dc6c1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1001,6 +1001,7 @@ Nobuhiro Iwamatsu iwama...@nigauri.org SH7763RDP SH7763 RSK7203 SH7203 AP325RXASH7723 + SHMIN SH7706 Mark Jonas mark.jo...@de.bosch.com diff --git a/board/shmin/Makefile b/board/shmin/Makefile new file mode 100644 index 000..be04e2c --- /dev/null +++ b/board/shmin/Makefile @@ -0,0 +1,49 @@ +# +# Copyright (C) 2010 Nobuhiro Iwamatsu +# Copyright (C) 2008 Renesas Solutions Corp. +# +# u-boot/board/shmin/Makefile +# +# 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= lib$(BOARD).a + +OBJS := shmin.o +SOBJS := lowlevel_init.o + +LIB:= $(addprefix $(obj),$(LIB)) +OBJS := $(addprefix $(obj),$(OBJS)) +SOBJS := $(addprefix $(obj),$(SOBJS)) + +$(LIB):$(obj).depend $(OBJS) $(SOBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) $(SOBJS) + +clean: + rm -f $(SOBJS) $(OBJS) + +distclean: clean + rm -f $(LIB) core *.bak .depend + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/board/shmin/config.mk b/board/shmin/config.mk new file mode 100644 index 000..eca20d4 --- /dev/null +++ b/board/shmin/config.mk @@ -0,0 +1,27 @@ +# +# Copyright (C) 2010 Nobuhiro Iwamatsu +# +# u-boot/board/shmin/config.mk +# +# 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 + +# +# TEXT_BASE refers to image _after_ relocation. +# +# NOTE: Must match value used in u-boot.lds (in this directory). +# + +CONFIG_SYS_TEXT_BASE = 0x8DFC diff --git a/board/shmin/lowlevel_init.S b/board/shmin/lowlevel_init.S new file mode 100644 index 000..b29da35 --- /dev/null +++ b/board/shmin/lowlevel_init.S @@ -0,0 +1,36 @@ +/* + * (C) Copyright 2008, 2010 Nobuhiro Iwamatsu iwama...@nigauri.org + * + * 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.,
Re: [U-Boot] [PATCH V2] imx25: Fix reset
Am 26.10.2010 11:27, schrieb Reinhard Meyer: Dear Matthias Weisser, This patch fixes the reset command on imx25 Signed-off-by: Matthias Weisserweiss...@arcor.de +writew(0x,regs-wcr); +writew(0x,regs-wsr); +writew(0x,regs-wsr); It might be nicer to use 16 Bit constants (with 4 hex digits) here..? Sure. Would be nicer. I wait a bit for further comments and will create a V3 then. Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] U-boot versions - reply to RM + SW
In article 2dd330d8-59ec-4a42-b251-360e19620...@googlemail.com, andreas.de...@googlemail.com (Andreas Bießmann) wrote: *From:* Andreas Bießmann andreas.de...@googlemail.com *To:* from_denx_ub...@dexdyne.com *Date:* Mon, 25 Oct 2010 19:14:07 +0200 Dear David Collier, Am 25.10.2010 um 15:46 schrieb David Collier: I posted a question about NAND on AVR32, and both Reinhard Meyer and Scott Wood said why aren't you using the latest source The reason of course is that from 2008:10 until very recently, the AVR32 version didn't work - some issue to do with the memory mapping when writing flash. This issue was fixed in 1f36f73fe70560a2bd286a7abc8530fdc93af9ae somewhere in August and is therefore mainline since v2010.09 regards Andreas Bießmann Thanks Andreas - but it will be a lot of work to forward my working patches across the 2-year gap :-( D ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timer implementations
Dear Reinhard Meyer, In message 4cc6aadc.8050...@emk-elektronik.de you wrote: Then the define CONFIG_SYS_HZ should not be in every board.h since that suggests that a board developer has some freedom there... Agreed - there are historical reasons this has ever been changable at all. and MOST IMPORTANT that some implementations of udelay() might call reset_timer() and therefore break an outer timeout loop !!! Such implementations are inherently broken and need to be fixed. It is also open if reset_timer() does actually reset the hardware timer (e.g. tbu/tbl at PPC) - which would be messing up any time difference calculation using get_ticks() - or does emulate that by remembering the hardware value and subtracting it later in every subsequent get_timer() call? This is an implementation detail. 2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC). Since they are defined as having 64 bits they MUST not wrap at 32 bits, i.e. if the hardware provides only 32 bits, the upper 32 bits must be emulated by software. Right. Otherwise we have to document that get_ticks() cannot be used to get 64 bit time differences. No. Such an implementation is broken and needs fixing. If you really closely look at the various implementations of those timers, you will easyly see the wide variations implemented there. Yes, I am aware of this :-( Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de ...though his invention worked superbly -- his theory was a crock of sewage from beginning to end. - Vernor Vinge, The Peace War ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3 V2] Move and rename common headers from under board/davinci.
On Mon, Oct 25, 2010 at 4:08 PM, Sughosh Ganu urwithsugh...@gmail.com wrote: Move the davinci common headers to the architecture specific include file path. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com Applies to c163f4478ca72f51b28b55f74addc8fe029d7b83 of git://git.denx.de/u-boot.git. No checkpatch.pl errors or warnings. The resulting u-boot is usable; tested on da850evm with NAND, env.oob and tftp. Tested-by: Ben Gardiner bengardi...@nanometrics.ca Best Regards, Ben Gardiner --- Nanometrics Inc. http://www.nanometrics.ca ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3 V2] Make board_init_f under nand_boot.c a weak function.
On Mon, Oct 25, 2010 at 4:08 PM, Sughosh Ganu urwithsugh...@gmail.com wrote:
Enable board_init_f to be overridden with a board specific
funtion.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
Applies to c163f4478ca72f51b28b55f74addc8fe029d7b83 of
git://git.denx.de/u-boot.git.
This patch has checkpatch.pl warnings:
WARNING: space prohibited between function name and open parenthesis '('
#94: FILE: nand_spl/nand_boot.c:225:
+void __board_init_f (ulong bootflag)
WARNING: line over 80 characters
#99: FILE: nand_spl/nand_boot.c:230:
+void board_init_f (ulong bootflag)__attribute__((weak,
alias(__board_init_f)));
WARNING: space prohibited between function name and open parenthesis '('
#99: FILE: nand_spl/nand_boot.c:230:
+void board_init_f (ulong bootflag)__attribute__((weak,
alias(__board_init_f)));
The resulting u-boot is usable; tested on da850evm with NAND, env.oob and tftp.
Best Regards,
Ben Gardiner
---
Nanometrics Inc.
http://www.nanometrics.ca
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 V2] Add support for hawkboard
On Mon, Oct 25, 2010 at 4:09 PM, Sughosh Ganu urwithsugh...@gmail.com wrote:
The patch adds basic board support for TI's OMAP-L138 based
Hawkboard. This board is pretty similar to the da850 EVM. Support for
nand and network access is added in this version.
The following bootup procedure is used.
At reset, the Rom Boot Loader(RBL), initialises the ddr and the nand
controllers and copies the second stage bootloader(nand_spl) to
RAM. The secondary bootloader then copies u-boot from a predefined
location in the nand flash to the RAM, and passes control to the
u-boot image.
Three config options are supported
* hawkboard_config - Used to create the u-boot.bin. Tftp the
u-boot.bin image to the RAM from u-boot, and flash to the nand flash
at address 0xe.
* hawkboard_nand_config - Used to generate the secondary
bootloader(nand_spl) image. This creates an elf file u-boot-spl
under nand_spl/. Create an AIS signed image using this file, and
flash it to the nand flash at address 0x2. The ais file should
fit in one block.
* hawkboard_uart_config - This is same as the first image, but with
the TEXT_BASE as expected by the RBL(0xc108). Create the AIS
Signed bin, as use the normal UART boot procedure to boot the image.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
Applies to c163f4478ca72f51b28b55f74addc8fe029d7b83 of
git://git.denx.de/u-boot.git.
This patch has checkpatch.pl warnings and errors:
ERROR: return is not a function, parentheses are not required#456:
FILE: board/davinci/da8xxevm/hawkboard.c:58:
+ return(0);
WARNING: space prohibited between function name and open parenthesis '('
#459: FILE: board/davinci/da8xxevm/hawkboard.c:61:
+int misc_init_r (void)
WARNING: line over 80 characters
#463: FILE: board/davinci/da8xxevm/hawkboard.c:65:
+ printf (ARM Clock : %s MHz\n, strmhz(buf,
clk_get(DAVINCI_ARM_CLKID)));
WARNING: space prohibited between function name and open parenthesis '('
#463: FILE: board/davinci/da8xxevm/hawkboard.c:65:
+ printf (ARM Clock : %s MHz\n, strmhz(buf,
clk_get(DAVINCI_ARM_CLKID)));
ERROR: return is not a function, parentheses are not required
#465: FILE: board/davinci/da8xxevm/hawkboard.c:67:
+ return(0);
ERROR: space required after that ',' (ctx:VxV)
#537: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:65:
+ { pinmux(12),1, 5 },
^
ERROR: space required after that ',' (ctx:VxV)
#538: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:66:
+ { pinmux(12),1, 6 }
^
WARNING: space prohibited between function name and open parenthesis '('
#569: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:97:
+void board_init_f (ulong bootflag)
ERROR: code indent should use tabs where possible
#601: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:129:
+^I CONFIG_SYS_NS16550_CLK / 16 / CONFIG_BAUDRATE);$
WARNING: space prohibited between function name and open parenthesis '('
#605: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:133:
+ relocate_code (CONFIG_SYS_NAND_U_BOOT_RELOC_SP, (gd_t *)gd,
WARNING: space prohibited between function name and open parenthesis '('
#631: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:159:
+void hang (void)
WARNING: space prohibited between function name and open parenthesis '('
#633: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:161:
+ puts (### ERROR ### Please RESET the board ###\n);
ERROR: trailing statements should be on next line
#634: FILE: board/davinci/da8xxevm/hawkboard_nand_spl.c:162:
+ for (;;);
+ for (;;);
WARNING: line over 80 characters
#721: FILE: include/configs/hawkboard.h:54:
+#define PHYS_SDRAM_1 DAVINCI_DDR_EMIF_DATA_BASE /* DDR Start
*/
WARNING: line over 80 characters
#725: FILE: include/configs/hawkboard.h:58:
+#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x1000
- \
WARNING: line over 80 characters
#842: FILE: include/configs/hawkboard.h:175:
+ mem=128M console=ttyS2,115200n8 root=/dev/ram0 rw initrd=0xc118,
\
total: 6 errors, 10 warnings, 823 lines checked
../sugosh-da8xx-v2/3of3.patch has style problems, please review. If
any of these errors
are false positives report them to the maintainer, see
CHECKPATCH in MAINTAINERS.
I was also unable to build the da850evm u-boot with this patch applied:
$make mrproper ; make da850evm_config ; make -j9 all|grep -E '( error| warning)'
awk '(NF $1 !~ /^#/) { print $1 : $1 _config; $(MAKE) }'
boards.cfg .boards.depend
Configuring for da850evm board...
davinci_pinmux.c:30:26: error: davinci_misc.h: No such file or directory
make[1]: *** No rule to make target `.depend', needed by `libdavinci.a'. Stop.
make: *** [board/davinci/common/libdavinci.a] Error 2
make: *** Waiting for unfinished jobs
make: *** wait: No child processes. Stop.
For your next patch submission, I recommend running checkpatch.pl
(from a recent linux kernel scripts/ directory)
Re: [U-Boot] Not getting any prompt on hyper terminal
Dear Srinivas Ganji, In message aanlktimgrgax47ygywvo-jdxa-pqpaf0sbb8c0be5...@mail.gmail.com you wrote: You should never need to modify arch/powerpc/lib/board.c and arch/powerpc/cpu/ppc4xx/start.S. I recommend you undo thse changes. We have modified the start.S file for the following #define as our flash start address is 0xFF00 according to flash size. Please look at the code. You do not have to change this file. Just provide a correct definition in your board config file. Please do not meddle with global files. We have added only debug statements in board.c. We did not change any value/variable in this file. Only adding debug statements may break a board as well, if you don't know exactly what you are doing. We are using yosemite board configuration files as we derived our board as per the yosemite board. Please let me know, if there is any document / README for creating the own config files. There is a little help in the README. make YOSEMITE_config I am pretty sure this is NOT the command you used. Note thate case matters. The README file which is available in the main u-boot directory says use CAPITAL letters YOSEMITE only. That is the reason, I used it. I also saw in the google where they used the CAPITAL letters for I really have no idea what you are talking about: there is not a single reference to Yosemite (in whatever spelling) in the README. And the make target is yosemite_config, and has always been like that. If this is different for you, your source tree must be seriously modified (read: messed up). Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The software required `Windows 95 or better', so I installed Linux. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timer implementations
Dear Wolfgang Denk,
Then the define CONFIG_SYS_HZ should not be in every board.h since that
suggests that a board developer has some freedom there...
Agreed - there are historical reasons this has ever been changable at
all.
and MOST IMPORTANT that some implementations of udelay() might
call reset_timer() and therefore break an outer timeout loop !!!
Such implementations are inherently broken and need to be fixed.
Found such in arm926ejs/omap... But then, that timer is multiple-broken:
relocation broken (uses static data), returns 32 a bit value in get_ticks(),
returns CONFIG_SYS_HZ in get_tbclk() instead of the rate get_ticks()
increments...
PXA:
void udelay_masked (unsigned long usec)
{
unsigned long long tmp;
ulong tmo;
tmo = us_to_tick(usec);
tmp = get_ticks() + tmo;/* get current timestamp */
while (get_ticks() tmp)
/* loop till event _OR FOREVER is tmp happens to be 32 bit_ */
/*NOP*/;
}
unsigned long long get_ticks(void)
{
return readl(OSCR);
}
- not any better :( -- its the same code that AT91 had before I fixed it.
It is also open if reset_timer() does actually reset the hardware timer
(e.g. tbu/tbl at PPC) - which would be messing up any time difference
calculation using get_ticks() - or does emulate that by remembering
the hardware value and subtracting it later in every subsequent
get_timer() call?
This is an implementation detail.
IF we require that get_ticks() and get_timer() shall not interfere with
each other and IF both are based on the same hardware timer only the
second method is available (same if the hardware timer is not easyly
resettable).
2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC).
Since they are defined as having 64 bits they MUST not wrap at 32 bits,
i.e. if the hardware provides only 32 bits, the upper 32 bits must be
emulated by software.
Right.
Otherwise we have to document that get_ticks() cannot be used to get
64 bit time differences.
No. Such an implementation is broken and needs fixing.
Original AT91 timer.c was like that, and I think other ARMs where this was
copied around should be looked at... I don't know when get_timer() became
64 bits, but it seems that some implementations just did change the return
type: uint64 get_timer(void) {return (uint64)timer_val_32;}
If you really closely look at the various implementations of those
timers, you will easyly see the wide variations implemented there.
Yes, I am aware of this :-(
I will start beautifying the AT91 timer - its already quite there,
except for a possible timer wrap problem in udelay() after a few billion
years :)
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Premi, Sanjeev Sent: Tuesday, October 19, 2010 10:25 PM To: Loïc Minier Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot -Original Message- From: Loïc Minier [mailto:l...@dooz.org] Sent: Tuesday, October 19, 2010 10:14 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH 1/1] omap3evm: Support for fast boot On Tue, Oct 19, 2010, Sanjeev Premi wrote: +#undef CONFIG_FAST_BOOT I wonder whether CONFIG_FAST_BOOT would cause confusion if u-boot gains support for Android fastboot someday? http://en.wikipedia.org/wiki/Fastboot http://android-dls.com/wiki/index.php?title=Fastboot [sp] The intent here is to boot faster - hence the name. Wasn't aware of any Android overlap. How about any of these: - CONFIG_SMALL_SIZE - CONFIG_FASTER_BOOT :) ^^ Any other suggestions? [sp] Didn't hear any other suggestions. But I had one more, CONFIG_QUICK_BOOT. Loic, does this seem okay? ~sanjeev ~sanjeev -- Loïc Minier ___ 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 v2] mmc: omap: timeout counter fix
Ghorai, Sukumar had written, on 10/26/2010 12:34 AM, the following: [...] [Ghorai] Thanks.. This is the best approach. Otherwise udelay() will increase the boot time. Please define increase the boot time with the context to the patch where you think the increase of boot time will be? In my experience, it has not. the iterations are such that: while (condition_not_met) udelay(10); This is reasonable enough to wait till the condition is met. a) u-boot boot logic is not invoked until mmc part 0 is invoked - u-boot boot time does not change b) the actual fatload by itself will only incur minor latency addition - IMHO - necessary addition - in cases where the check conditions are not met. would be great if you can illustrate within the patch areas which need continuous checks Vs the ones that do not need continuous checks. -- Regards, Nishanth Menon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
-Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 8:38 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 20:10 +0530, Premi, Sanjeev wrote: -Original Message- From: Steve Sakoman [mailto:st...@sakoman.com] Sent: Monday, October 25, 2010 6:52 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: RE: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards On Mon, 2010-10-25 at 15:28 +0530, Premi, Sanjeev wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Saturday, October 23, 2010 2:20 AM To: u-boot@lists.denx.de Subject: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards Commit c3d3a54 uses CONFIG_ARMV7 to determine whether to call the v7_flush_cache_all function. This breaks the build for all non-OMAP3 boards (like Panda and OMAP4430SDP) since there is only a v7_flush_cache_all implementation for OMAP3. This patch uses CONFIG_OMAP3XXX instead of CONFIG_ARMV7 so that only boards with a v7_flush_cache_all will make the call. [sp] Is this call board specific? No, it is not. [sp] I asked because I can see omap3/cache.S but not under omap-common/ (as I was expecting) - neither in omap4/ Doesn't this patch works-around the problem by using CONFIG_OMAP34XX? Yes, this is a hopefully temporary fix to allow non-OMAP3 ARMV7 boards to build. Wouldn't change in cache.S (or Makefile) be better solution/ or workaround. At least workaround will be visible to more eyes. Ideally we would have a generic ARMV7 implementation that would work for even non-OMAP ARMV7 processors. Someone who is familiar with the differences in ARMV7 cache implementations from the various silicon vendors would need to do this. This beyond my knowledge. A second best solution would be to have a cache.S that worked for both OMAP3 and OMAP4 in omap-common/ If this isn't possible, then we should add an OMAP4 specific cache.S in omap4/ But until we settle on the proper long term strategy this patch should be applied so that non-OMAP3 ARMV7 boards will build. Can we indicate either in the title/ description that patch is temporary? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] include/asm-offsets.h: automatically generate assembler constants
A recurrent issue is that certain C level constructs like sizeof() or
offsetof() cannot be used in assembler files, which is inconvenient
when such constructs are used in the definition of macro names etc.
To avoid duplication of such definitions (and thus another cause of
problems), we adapt the Linux way to automatically generate the
respective definitions from the respective C header files.
In Linux, this is implemented in include/linux/kbuild.h, Kbuild, and
arch/*/kernel/asm-offsets.c; we adapt the code from the Linux v2.6.36
kernel tree.
We also copy the concept of the include/generated/ directory which can
be used to hold other automatically generated files as well.
We start with an architecture-independent lib/asm-offsets.c which
generates include/generated/generic-asm-offsets.h (included by
include/asm-offsets.h, which is what will be referred to in the actual
source code). Later this may be extended by architecture-specific
arch/*/lib/asm-offsets.c files that will generate a
include/generated/asm-offsets.h.
---
.gitignore |3 +++
Makefile | 23 ---
include/asm-offsets.h |2 ++
include/linux/kbuild.h | 20
lib/asm-offsets.c | 25 +
tools/scripts/make-asm-offsets | 27 +++
6 files changed, 97 insertions(+), 3 deletions(-)
create mode 100644 include/asm-offsets.h
create mode 100644 include/linux/kbuild.h
create mode 100644 lib/asm-offsets.c
create mode 100755 tools/scripts/make-asm-offsets
diff --git a/.gitignore b/.gitignore
index 67d2cd6..e71f6ac 100644
--- a/.gitignore
+++ b/.gitignore
@@ -40,6 +40,9 @@
/errlog
/reloc_off
+/include/generated/
+/lib/asm-offsets.s
+
# stgit generated dirs
patches-*
.stgit-edit.txt
diff --git a/Makefile b/Makefile
index f8e13d7..737eb11 100644
--- a/Makefile
+++ b/Makefile
@@ -372,7 +372,8 @@ GEN_UBOOT = \
cd $(LNDIR) $(LD) $(LDFLAGS) $$UNDEF_SYM $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
-$(obj)u-boot: depend $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT)
$(obj)u-boot.lds
+$(obj)u-boot: depend \
+ $(SUBDIRS) $(OBJS) $(LIBBOARD) $(LIBS) $(LDSCRIPT)
$(obj)u-boot.lds
$(GEN_UBOOT)
ifeq ($(CONFIG_KALLSYMS),y)
smap=`$(call SYSTEM_MAP,u-boot) | \
@@ -426,7 +427,9 @@ updater:
# Explicitly make _depend in subdirs containing multiple targets to prevent
# parallel sub-makes creating .depend files simultaneously.
-depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) $(obj)include/autoconf.mk
+depend dep:$(TIMESTAMP_FILE) $(VERSION_FILE) \
+ $(obj)include/autoconf.mk \
+ $(obj)include/generated/generic-asm-offsets.h
for dir in $(SUBDIRS) $(CPUDIR) $(dir $(LDSCRIPT)) ; do \
$(MAKE) -C $$dir _depend ; done
@@ -453,7 +456,7 @@ $(obj)System.map: $(obj)u-boot
@$(call SYSTEM_MAP,$) $(obj)System.map
#
-# Auto-generate the autoconf.mk file (which is included by all makefiles)
+# Auto-generate the autoconi.mk file (which is included by all makefiles)
#
# This target actually generates 2 files; autoconf.mk and autoconf.mk.dep.
# the dep file is only include in this top level makefile to determine when
@@ -473,6 +476,18 @@ $(obj)include/autoconf.mk: $(obj)include/config.h
sed -n -f tools/scripts/define2mk.sed $...@.tmp \
mv $...@.tmp $@
+$(obj)include/generated/generic-asm-offsets.h: $(obj)include/autoconf.mk.dep \
+ $(obj)lib/asm-offsets.s
+ @$(XECHO) Generating $@
+ tools/scripts/make-asm-offsets $(obj)lib/asm-offsets.s $@
+
+$(obj)lib/asm-offsets.s: $(obj)include/autoconf.mk.dep \
+ $(src)lib/asm-offsets.c
+ @mkdir -p $(obj)lib
+ $(CC) -DDO_DEPS_ONLY \
+ $(CFLAGS) $(CFLAGS_$(BCURDIR)/$(@F)) $(CFLAGS_$(BCURDIR)) \
+ -o $@ $(src)lib/asm-offsets.c -c -S
+
#
else # !config.mk
all $(obj)u-boot.hex $(obj)u-boot.srec $(obj)u-boot.bin \
@@ -1214,6 +1229,7 @@ clean:
$(obj)u-boot.lds \
$(obj)arch/blackfin/cpu/bootrom-asm-offsets.[chs]
@rm -f $(obj)include/bmp_logo.h
+ @rm -f $(obj)lib/asm-offsets.s
@rm -f $(obj)nand_spl/{u-boot.lds,u-boot-spl,u-boot-spl.map,System.map}
@rm -f $(obj)onenand_ipl/onenand-{ipl,ipl.bin,ipl.map}
@rm -f $(ONENAND_BIN)
@@ -1237,6 +1253,7 @@ clobber: clean
@rm -f $(obj)tools/{env/crc32.c,inca-swap-bytes}
@rm -f $(obj)arch/powerpc/cpu/mpc824x/bedbug_603e.c
@rm -f $(obj)include/asm/proc $(obj)include/asm/arch $(obj)include/asm
+ @rm -fr $(obj)include/generated
@[ ! -d $(obj)nand_spl ] || find
[U-Boot] [PATCH 0/3] Introduce asm-offsets and fix CONFIG_SYS_GBL_DATA_SIZE problems
The following patch series starts some clean up of for the handling f initial data; the most important change is the replacement of a manually configured (and thus often wrong) CONFIG_SYS_GBL_DATA_SIZE by an automatically generated value. More similar clean-ups can and will be done, but this is stuff for the next merge window (or the next branch); here we focus on a fix for the CONFIG_SYS_GBL_DATA_SIZE problems. The changes are mostly simple and straightforward, but they are huge as they affect a lots of files. [PATCH 1/3] Rename CONFIG_SYS_INIT_RAM_END into CONFIG_SYS_INIT_RAM_SIZE CONFIG_SYS_INIT_RAM_END was a misnomer as it suggests this might be some end address; to make the meaning more clear we rename it into CONFIG_SYS_INIT_RAM_SIZE No other code changes are performed in this patch, only minor editing of white space (due to the changed length) and the comments was done, where noticed. Note that the code for the PATI and cmi_mpc5xx board configurations looks seriously broken. Last known maintainers on Cc: Signed-off-by: Wolfgang Denk w...@denx.de Cc: Denis Peter d.pe...@mpl.ch Cc: Martin Winistoerfer martinwinistoer...@gmx.ch --- README |2 +- arch/m68k/lib/board.c |2 +- arch/powerpc/cpu/74xx_7xx/start.S |4 ++-- arch/powerpc/cpu/mpc83xx/start.S |4 ++-- arch/powerpc/cpu/mpc86xx/start.S |4 ++-- arch/powerpc/cpu/ppc4xx/start.S| 22 +++--- board/fads/fads.h |4 ++-- include/configs/A3000.h|4 ++-- include/configs/ADCIOP.h |4 ++-- include/configs/AMX860.h |4 ++-- include/configs/AP1000.h |4 ++-- include/configs/APC405.h |4 ++-- include/configs/AR405.h|4 ++-- include/configs/ASH405.h |4 ++-- include/configs/ATUM8548.h |4 ++-- include/configs/Adder.h|4 ++-- include/configs/Alaska8220.h |4 ++-- include/configs/BAB7xx.h |4 ++-- include/configs/BC3450.h |6 +++--- include/configs/BMW.h |4 ++-- include/configs/CANBT.h|4 ++-- include/configs/CATcenter.h|4 ++-- include/configs/CMS700.h |4 ++-- include/configs/CPC45.h|4 ++-- include/configs/CPCI2DP.h |4 ++-- include/configs/CPCI405.h |4 ++-- include/configs/CPCI4052.h |4 ++-- include/configs/CPCI405AB.h|4 ++-- include/configs/CPCI405DT.h|4 ++-- include/configs/CPCI750.h |4 ++-- include/configs/CPCIISER4.h|4 ++-- include/configs/CPU86.h|4 ++-- include/configs/CPU87.h|4 ++-- include/configs/CRAYL1.h |8 include/configs/CU824.h|4 ++-- include/configs/DASA_SIM.h |4 ++-- include/configs/DB64360.h |4 ++-- include/configs/DB64460.h |4 ++-- include/configs/DP405.h|4 ++-- include/configs/DU405.h|4 ++-- include/configs/DU440.h|4 ++-- include/configs/EB+MCF-EV123.h |8 include/configs/ELPPC.h|4 ++-- include/configs/ELPT860.h |4 ++-- include/configs/EP88x.h|4 ++-- include/configs/ERIC.h |4 ++-- include/configs/ESTEEM192E.h |4 ++-- include/configs/ETX094.h |4 ++-- include/configs/EVB64260.h |4 ++-- include/configs/EXBITGEN.h |4 ++-- include/configs/FADS823.h |4 ++-- include/configs/FADS850SAR.h |4 ++-- include/configs/FLAGADM.h |4 ++-- include/configs/FPS850L.h |4 ++-- include/configs/FPS860L.h |4 ++-- include/configs/G2000.h|4 ++-- include/configs/GEN860T.h |4 ++-- include/configs/GENIETV.h |4 ++-- include/configs/HH405.h|4 ++-- include/configs/HIDDEN_DRAGON.h|8 include/configs/HUB405.h |4 ++-- include/configs/IAD210.h |4 ++-- include/configs/ICU862.h |4 ++-- include/configs/IDS8247.h |4 ++-- include/configs/IP860.h|4 ++-- include/configs/IPHASE4539.h |4 ++-- include/configs/ISPAN.h|4 ++-- include/configs/IVML24.h |8
Re: [U-Boot] [PATCH 2/3] include/asm-offsets.h: automatically generate assembler constants
On Tuesday 26 October 2010, 16:00:00 Wolfgang Denk wrote: @@ -453,7 +456,7 @@ $(obj)System.map: $(obj)u-boot @$(call SYSTEM_MAP,$) $(obj)System.map # -# Auto-generate the autoconf.mk file (which is included by all makefiles) +# Auto-generate the autoconi.mk file (which is included by all makefiles) # # This target actually generates 2 files; autoconf.mk and autoconf.mk.dep. # the dep file is only include in this top level makefile to determine when I think thats a typo. Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] include/asm-offsets.h: automatically generate assembler constants
Dear Alexander Stein, In message 201010261611.59856.alexander.st...@systec-electronic.com you wrote: On Tuesday 26 October 2010, 16:00:00 Wolfgang Denk wrote: @@ -453,7 +456,7 @@ $(obj)System.map: $(obj)u-boot @$(call SYSTEM_MAP,$) $(obj)System.map # -# Auto-generate the autoconf.mk file (which is included by all makefiles) +# Auto-generate the autoconi.mk file (which is included by all makefiles) # # This target actually generates 2 files; autoconf.mk and autoconf.mk.dep. # the dep file is only include in this top level makefile to determine when I think thats a typo. oops. thanks, will fix that! Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is better for civilization to be going down the drain than to be coming up it. - Henry Allen ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timer implementations
Reinhard Meyer had written, on 10/26/2010 02:57 AM, the following:
Wolfgang Denk schrieb:
Dear Reinhard Meyer,
In message 4cc67ca1.9090...@emk-elektronik.de you wrote:
If implemented with true 64 bits for get_ticks() that function is useable
for timeout programming:
ulong timeval = get_timer (0);
do {
...
} while (get_timer (timeval) TIMEOUT);
It appears that the base parameter and return value is in CONFIG_SYS_HZ
units, and not in native ticks. That causes 64 bit mul/div every
time get_timer() is called. Won't hurt in a timeout loop, though.
But it will hurt in othe rplaces.
Also, this code _is_ a bit different, as get_timer(0) makes sure
the counter starts ticking again at 0
Nope, it does not reset the counter itself. It returns the current
counter value (recalculated into CONFIG_SYS_HZ units).
Maybe you mean reset_timer() instead?
In arm9226ejs/omap/timer.c udelay() is implemented with reset_timer()
and get_timer(). Since those functions are inherently not nestable,
beware of base=get_timer(0); do { ... udelay(xx); ... } while
(get_timer(base) TIMEOUT);
constructs!
At least the omap3+ code arch/arm/cpu/armv7/omap-common/timer.c
__udelay() does'nt seem to reset the timer
BUT,
unsigned long long get_ticks(void)
{
return get_timer(0);
}
ulong get_timer(ulong base)
{return get_timer_masked() - base;
}
ulong get_timer_masked(void)
{
/* current tick value */
ulong now = readl(timer_base-tcrr) / (TIMER_CLOCK /
CONFIG_SYS_HZ);
if (now = lastinc) /* normal mode (non roll) */
/* move stamp fordward with absoulte diff ticks */
timestamp += (now - lastinc);
else/* we have rollover of incrementer */
timestamp += ((TIMER_LOAD_VAL / (TIMER_CLOCK /
CONFIG_SYS_HZ))
- lastinc) + now;
lastinc = now;
return timestamp;
}
if I am not mistaken, this is 32bit long.. but since we have as wdenk
mentions below a 2^32 tick duration, we can safely go with an option
such as:
/* If we fail after 1 second wait, something is really bad */
#define MAX_RETRY_US(1 * 1000 * 1000)
uint64_t etime; /* actually this could be u32 */
etime = get_ticks() + usec2ticks(MAX_RETRY_US);
while (!(readl(mmc_base-stat) CC_MASK)) {
if (get_ticks() = etime) {
printf(%s: timedout waiting for cc2!\n, __func__);
return;
}
}
sounds right?
, and get_timer() is defined to
have millisecond resolution.
Actually CONFIG_SYS_HZ (whatever that is).
So you have a guaranteed 2^32
milliseconds or 4294967 seconds or about 3.3 years available which
indeed should be sufficient to implement standard timeouts.
I think it is necessary to summarize all implicit or explicit documented
defined to have's regarding the timer and then to verify that all
implementations adhere to them.
yes indeed.. :(
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timer implementations
Dear Nishanth Menon,
In message 4cc6efb1.9000...@ti.com you wrote:
uint64_t etime; /* actually this could be u32 */
etime = get_ticks() + usec2ticks(MAX_RETRY_US);
while (!(readl(mmc_base-stat) CC_MASK)) {
if (get_ticks() = etime) {
printf(%s: timedout waiting for cc2!\n, __func__);
return;
}
}
sounds right?
No. This code is always wrong. Please fix it as described.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
The first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
On Tuesday, October 26, 2010 10:00:01 Wolfgang Denk wrote: --- a/arch/blackfin/include/asm/config.h +++ b/arch/blackfin/include/asm/config.h -#ifndef CONFIG_SYS_GBL_DATA_SIZE -# define CONFIG_SYS_GBL_DATA_SIZE (128) +#ifndef GENERATED_GBL_DATA_SIZE #endif might as well delete this whole construct otherwise, the rest of the Blackfin stuff looks sane to me -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] Timer implementations
Wolfgang Denk had written, on 10/26/2010 10:17 AM, the following:
Dear Nishanth Menon,
In message 4cc6efb1.9000...@ti.com you wrote:
uint64_t etime; /* actually this could be u32 */
etime = get_ticks() + usec2ticks(MAX_RETRY_US);
while (!(readl(mmc_base-stat) CC_MASK)) {
if (get_ticks() = etime) {
printf(%s: timedout waiting for cc2!\n, __func__);
return;
}
}
sounds right?
No. This code is always wrong. Please fix it as described.
Apologies on being a dudhead, I suppose you mean the following:
ulong start;
start = get_timer(0);
while (!(readl(mmc_base-stat) CC_MASK)) {
if (get_timer(start) usec2ticks(MAX_RETRY_US)) {
printf(%s: timedout waiting for cc2!\n, __func__);
return;
}
}
would this be better?
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
Hi Wolfgang, On Tuesday 26 October 2010 16:41:07 Wolfgang Denk wrote: You are right, especially as the resulting start address of the global data is usually also used as the top of the internal stack. Guess we should align it on 16 bytes, to be sure. Yes, we already had this 8-byte stack align problem on ARM, IIRC. BTW - this uncovers a number of other problems. commit 800eb096 POST cleanup. inserts a single data word between global data and initial stack, thus also breaking stack alignment. I think this approach is wrong, the POST word should be made part of the global_data instead. Good idea. 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 1/1] omap3evm: Support for fast boot
On Tue, Oct 26, 2010, Premi, Sanjeev wrote: [sp] Didn't hear any other suggestions. But I had one more, CONFIG_QUICK_BOOT. I don't have a strong feeling either way; I just wanted fastboot to be used in a confusing way. Your patch seems to be largely a tuned u-boot config stripping down u-boot to be smaller and faster; I'm not sure whether there's anything similar in u-boot. -- Loïc Minier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Road sweeper
Hello,good morning, My name is kelvin brown and i want to make an order enquirer about road sweeper, and i want RS-48 Single Sweep Fodmaster and i want to know the types and models you do have and also with the prices and types of payment you do accepts.Thanks hope to hear from you soon. Regards Kelvin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timer implementations
Dear Nishanth Menon,
In message 4cc6f23a.2040...@ti.com you wrote:
No. This code is always wrong. Please fix it as described.
Apologies on being a dudhead, I suppose you mean the following:
ulong start;
start = get_timer(0);
while (!(readl(mmc_base-stat) CC_MASK)) {
if (get_timer(start) usec2ticks(MAX_RETRY_US)) {
printf(%s: timedout waiting for cc2!\n, __func__);
return;
}
}
would this be better?
No, not at all, as get_timer() returns milliseconds, not ticks.
You probably want something like:
ulong start = get_timer(0);
while (!(readl(mmc_base-stat) CC_MASK)) {
if (get_timer(0) - start = MAX_RETRY_US/1000) {
printf(...);
return;
}
udelay(100);
}
or such.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
He had quite a powerful intellect, but it was as powerful like a
locomotive, and ran on rails and was therefore almost impossible to
steer. - Terry Pratchett, _Lords and Ladies_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
Dear Mike Frysinger, In message 201010261117.56528.vap...@gentoo.org you wrote: On Tuesday, October 26, 2010 10:00:01 Wolfgang Denk wrote: --- a/arch/blackfin/include/asm/config.h +++ b/arch/blackfin/include/asm/config.h -#ifndef CONFIG_SYS_GBL_DATA_SIZE -# define CONFIG_SYS_GBL_DATA_SIZE (128) +#ifndef GENERATED_GBL_DATA_SIZE #endif might as well delete this whole construct OK, will do on check-in. otherwise, the rest of the Blackfin stuff looks sane to me 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 Quotation, n. The act of repeating erroneously the words of another. The words erroneously repeated. - Ambrose Bierce _The Devil's Dictionary_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2] imx25: Fix reset
Hi, 2010/10/26 Matthias Weißer weiss...@arcor.de: Am 26.10.2010 11:27, schrieb Reinhard Meyer: Dear Matthias Weisser, This patch fixes the reset command on imx25 Signed-off-by: Matthias Weisserweiss...@arcor.de + writew(0x,regs-wcr); + writew(0x,regs-wsr); + writew(0x,regs-wsr); It might be nicer to use 16 Bit constants (with 4 hex digits) here..? Sure. Would be nicer. I wait a bit for further comments and will create a V3 then. Add please append to the commit log about why you make such change? It will be clear to read and understand your change for this patch. Matthias ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3 V3] Move and rename common headers from under board/davinci.
Move the davinci common headers to the architecture specific include file path. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com --- Changes since V2: * No change in this patch of the patchset .../arm/include/asm/arch-davinci/da8xx_common.h|0 .../arm/include/asm/arch-davinci/davinci_misc.h|0 board/davinci/common/misc.c|2 +- board/davinci/da8xxevm/common.c|2 +- board/davinci/da8xxevm/da830evm.c |4 ++-- board/davinci/da8xxevm/da850evm.c |4 ++-- board/davinci/dm355evm/dm355evm.c |2 +- board/davinci/dm355leopard/dm355leopard.c |2 +- board/davinci/dm365evm/dm365evm.c |2 +- board/davinci/dvevm/dvevm.c|2 +- board/davinci/schmoogie/schmoogie.c|2 +- board/davinci/sffsdr/sffsdr.c |2 +- board/davinci/sonata/sonata.c |2 +- 13 files changed, 13 insertions(+), 13 deletions(-) rename board/davinci/da8xxevm/common.h = arch/arm/include/asm/arch-davinci/da8xx_common.h (100%) rename board/davinci/common/misc.h = arch/arm/include/asm/arch-davinci/davinci_misc.h (100%) diff --git a/board/davinci/da8xxevm/common.h b/arch/arm/include/asm/arch-davinci/da8xx_common.h similarity index 100% rename from board/davinci/da8xxevm/common.h rename to arch/arm/include/asm/arch-davinci/da8xx_common.h diff --git a/board/davinci/common/misc.h b/arch/arm/include/asm/arch-davinci/davinci_misc.h similarity index 100% rename from board/davinci/common/misc.h rename to arch/arm/include/asm/arch-davinci/davinci_misc.h diff --git a/board/davinci/common/misc.c b/board/davinci/common/misc.c index b60a46e..71e7822 100644 --- a/board/davinci/common/misc.c +++ b/board/davinci/common/misc.c @@ -29,7 +29,7 @@ #include net.h #include asm/arch/hardware.h #include asm/io.h -#include misc.h +#include asm/arch/davinci_misc.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/da8xxevm/common.c b/board/davinci/da8xxevm/common.c index 9cd5204..36bf693 100644 --- a/board/davinci/da8xxevm/common.c +++ b/board/davinci/da8xxevm/common.c @@ -20,7 +20,7 @@ #include asm/io.h #include asm/arch/hardware.h -#include common.h +#include asm/arch/da8xx_common.h #ifndef CONFIG_USE_IRQ void irq_init(void) diff --git a/board/davinci/da8xxevm/da830evm.c b/board/davinci/da8xxevm/da830evm.c index 8a9f988..b6b7e37 100644 --- a/board/davinci/da8xxevm/da830evm.c +++ b/board/davinci/da8xxevm/da830evm.c @@ -40,8 +40,8 @@ #include asm/arch/emif_defs.h #include asm/arch/emac_defs.h #include asm/io.h -#include ../common/misc.h -#include common.h +#include asm/arch/davinci_misc.h +#include asm/arch/da8xx_common.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/da8xxevm/da850evm.c b/board/davinci/da8xxevm/da850evm.c index c8c5e1b..0420ad5 100644 --- a/board/davinci/da8xxevm/da850evm.c +++ b/board/davinci/da8xxevm/da850evm.c @@ -29,8 +29,8 @@ #include asm/arch/emif_defs.h #include asm/arch/emac_defs.h #include asm/io.h -#include ../common/misc.h -#include common.h +#include asm/arch/davinci_misc.h +#include asm/arch/da8xx_common.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/dm355evm/dm355evm.c b/board/davinci/dm355evm/dm355evm.c index 87f284c..b9260b8 100644 --- a/board/davinci/dm355evm/dm355evm.c +++ b/board/davinci/dm355evm/dm355evm.c @@ -22,7 +22,7 @@ #include asm/arch/hardware.h #include asm/arch/emif_defs.h #include asm/arch/nand_defs.h -#include ../common/misc.h +#include asm/arch/davinci_misc.h #include net.h #include netdev.h diff --git a/board/davinci/dm355leopard/dm355leopard.c b/board/davinci/dm355leopard/dm355leopard.c index e89786e..0ee0d11 100644 --- a/board/davinci/dm355leopard/dm355leopard.c +++ b/board/davinci/dm355leopard/dm355leopard.c @@ -22,7 +22,7 @@ #include asm/arch/hardware.h #include asm/arch/gpio_defs.h #include asm/arch/nand_defs.h -#include ../common/misc.h +#include asm/arch/davinci_misc.h #include net.h #include netdev.h diff --git a/board/davinci/dm365evm/dm365evm.c b/board/davinci/dm365evm/dm365evm.c index 85dbe2a..bc681f7 100644 --- a/board/davinci/dm365evm/dm365evm.c +++ b/board/davinci/dm365evm/dm365evm.c @@ -24,7 +24,7 @@ #include asm/arch/nand_defs.h #include asm/arch/gpio_defs.h #include netdev.h -#include ../common/misc.h +#include asm/arch/davinci_misc.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/dvevm/dvevm.c b/board/davinci/dvevm/dvevm.c index 073c21a..d5c851b 100644 --- a/board/davinci/dvevm/dvevm.c +++ b/board/davinci/dvevm/dvevm.c @@ -27,7 +27,7 @@ #include common.h #include i2c.h #include asm/arch/hardware.h -#include ../common/misc.h +#include asm/arch/davinci_misc.h DECLARE_GLOBAL_DATA_PTR; diff --git a/board/davinci/schmoogie/schmoogie.c b/board/davinci/schmoogie/schmoogie.c index 80a0f9f..8b615a9 100644 --- a/board/davinci/schmoogie/schmoogie.c +++
[U-Boot] [PATCH 2/3 V3] Make board_init_f under nand_boot.c a weak function
Enable board_init_f to be overridden with a board
specific function.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
---
Changes since V2:
* Fix the checkpatch warnings
nand_spl/nand_boot.c |8 +---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index ccd0af2..01ff3e3 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -222,11 +222,13 @@ static int nand_load(struct mtd_info *mtd, unsigned int
offs,
}
#if defined(CONFIG_ARM) !defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
-void board_init_f (ulong bootflag)
+void __board_init_f(ulong bootflag)
{
- relocate_code (CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
- CONFIG_SYS_TEXT_BASE);
+ relocate_code(CONFIG_SYS_TEXT_BASE - TOTAL_MALLOC_LEN, NULL,
+ CONFIG_SYS_TEXT_BASE);
}
+void board_init_f(ulong bootflag)__attribute__((weak,
+alias(__board_init_f)));
#endif
/*
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/3 V3] Add board support for hawkboard
The patch adds basic board support for TI's OMAP-L138 based
Hawkboard. This board is pretty similar to the da850 EVM. Support for
nand and network access is added in this version.
The following bootup procedure is used.
At reset, the Rom Boot Loader(RBL), initialises the ddr and the nand
controllers and copies the second stage bootloader(nand_spl) to
RAM. The secondary bootloader then copies u-boot from a predefined
location in the nand flash to the RAM, and passes control to the
u-boot image.
Three config options are supported
* hawkboard_config - Used to create the u-boot.bin. Tftp the
u-boot.bin image to the RAM from u-boot, and flash to the nand flash
at address 0xe.
* hawkboard_nand_config - Used to generate the secondary
bootloader(nand_spl) image. This creates an elf file u-boot-spl
under nand_spl/. Create an AIS signed image using this file, and
flash it to the nand flash at address 0x2. The ais file should
fit in one block.
* hawkboard_uart_config - This is same as the first image, but with
the TEXT_BASE as expected by the RBL(0xc108). Create the AIS
Signed bin, as use the normal UART boot procedure to boot the image.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
---
Changes since V2:
* Fix the checkpatch errors.
* Fix the build issue on da850evm due to a missed out change.
MAINTAINERS |5 +
arch/arm/include/asm/arch-davinci/da8xx_common.h |3 +
arch/arm/include/asm/arch-davinci/hardware.h |5 +-
board/davinci/common/Makefile|2 +-
board/davinci/common/davinci_pinmux.c| 105 +++
board/davinci/common/misc.c | 75
board/davinci/da8xxevm/Makefile |2 +
board/davinci/da8xxevm/hawkboard.c | 69
board/davinci/da8xxevm/hawkboard_nand_spl.c | 164 +
boards.cfg |3 +
drivers/mtd/nand/davinci_nand.c |1 +
include/configs/hawkboard.h | 205 ++
nand_spl/board/davinci/da8xxevm/Makefile | 141 +++
nand_spl/board/davinci/da8xxevm/u-boot.lds | 75
14 files changed, 778 insertions(+), 77 deletions(-)
create mode 100644 board/davinci/common/davinci_pinmux.c
create mode 100644 board/davinci/da8xxevm/hawkboard.c
create mode 100644 board/davinci/da8xxevm/hawkboard_nand_spl.c
create mode 100644 include/configs/hawkboard.h
create mode 100644 nand_spl/board/davinci/da8xxevm/Makefile
create mode 100644 nand_spl/board/davinci/da8xxevm/u-boot.lds
diff --git a/MAINTAINERS b/MAINTAINERS
index b0da631..d7efc71 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -849,6 +849,11 @@ Alex Z
lartSA1100
dnp1110 SA1110
+Syed Mohammed Khasim sm.kha...@gmail.com
+Sughosh Ganu urwithsugh...@gmail.com
+
+ hawkboard ARM926EJS (OMAP-L138)
+
-
Unknown / orphaned boards:
diff --git a/arch/arm/include/asm/arch-davinci/da8xx_common.h
b/arch/arm/include/asm/arch-davinci/da8xx_common.h
index 7ae63a6..bc3092d 100644
--- a/arch/arm/include/asm/arch-davinci/da8xx_common.h
+++ b/arch/arm/include/asm/arch-davinci/da8xx_common.h
@@ -19,6 +19,9 @@
#ifndef __COMMON_H
#define __COMMON_H
+#defineHAWKBOARD_KICK0_UNLOCK 0x83e70b13
+#defineHAWKBOARD_KICK1_UNLOCK 0x95a4f1e0
+
struct lpsc_resource {
const int lpsc_no;
};
diff --git a/arch/arm/include/asm/arch-davinci/hardware.h
b/arch/arm/include/asm/arch-davinci/hardware.h
index 3520cf8..d006ac1 100644
--- a/arch/arm/include/asm/arch-davinci/hardware.h
+++ b/arch/arm/include/asm/arch-davinci/hardware.h
@@ -379,7 +379,10 @@ int clk_get(enum davinci_clk_ids id);
/* Boot config */
struct davinci_syscfg_regs {
dv_reg revid;
- dv_reg rsvd[71];
+ dv_reg rsvd[13];
+ dv_reg kick0;
+ dv_reg kick1;
+ dv_reg rsvd1[56];
dv_reg pinmux[20];
dv_reg suspsrc;
dv_reg chipsig;
diff --git a/board/davinci/common/Makefile b/board/davinci/common/Makefile
index 8d9ea00..dd022f6 100644
--- a/board/davinci/common/Makefile
+++ b/board/davinci/common/Makefile
@@ -29,7 +29,7 @@ endif
LIB= $(obj)lib$(VENDOR).a
-COBJS := misc.o
+COBJS := misc.o davinci_pinmux.o
SRCS := $(SOBJS:.o=.S) $(COBJS:.o=.c)
OBJS := $(addprefix $(obj),$(COBJS))
diff --git a/board/davinci/common/davinci_pinmux.c
b/board/davinci/common/davinci_pinmux.c
new file mode 100644
index 000..ce58f71
--- /dev/null
+++ b/board/davinci/common/davinci_pinmux.c
@@ -0,0 +1,105 @@
+/*
+ * DaVinci pinmux functions.
+ *
+ * Copyright (C) 2009 Nick Thompson, GE Fanuc Ltd, nick.thomp...@gefanuc.com
+ * Copyright (C) 2007 Sergey Kubushyn k...@koi8.net
+ * Copyright (C) 2008 Lyrtech www.lyrtech.com
+ * Copyright (C) 2004 Texas Instruments.
[U-Boot] [PATCH v3] mmc: omap: timeout counter fix
Having a loop with a counter is no timing guarentee for timing
accuracy or compiler optimizations. For e.g. the same loop counter
which runs when the MPU is running at 600MHz will timeout in around
half the time when running at 1GHz. or the example where GCC 4.5
compiles with different optimization compared to GCC 4.4. use timer
to keep track of time elapse and we use an emperical number - 1sec
for a worst case timeout. This should never happen, and is adequate
imaginary condition for us to fail with timeout.
Signed-off-by: Nishanth Menon n...@ti.com
---
V3: changed the delay logic, removed udelays which was introduced in
v2 as the intent was purely to have predictable time delays. the timer
logic is based on the discussion in ML using get_timer
V2: http://www.mail-archive.com/u-boot@lists.denx.de/msg40972.html
additional cleanups + made MAX_RETRY a macro for reuse throughout
the file. tested on PandaBoard with 1GHz boot frequency and GCC4.5 on
u-boot 2010.09 + mmc patches. Requesting testing on other platforms
V1: http://www.mail-archive.com/u-boot@lists.denx.de/msg40969.html
drivers/mmc/omap_hsmmc.c | 107 +++---
1 files changed, 82 insertions(+), 25 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 9271470..5271794 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -31,6 +31,9 @@
#include asm/io.h
#include asm/arch/mmc_host_def.h
+/* If we fail after 1 second wait, something is really bad */
+#define MAX_RETRY_MS 1000
+
static int mmc_read_data(hsmmc_t *mmc_base, char *buf, unsigned int size);
static int mmc_write_data(hsmmc_t *mmc_base, const char *buf, unsigned int
siz);
static struct mmc hsmmc_dev[2];
@@ -70,18 +73,29 @@ unsigned char mmc_board_init(hsmmc_t *mmc_base)
void mmc_init_stream(hsmmc_t *mmc_base)
{
+ ulong start;
writel(readl(mmc_base-con) | INIT_INITSTREAM, mmc_base-con);
writel(MMC_CMD0, mmc_base-cmd);
- while (!(readl(mmc_base-stat) CC_MASK))
- ;
+ start = get_timer(0);
+ while (!(readl(mmc_base-stat) CC_MASK)) {
+ if (get_timer(0) - start MAX_RETRY_MS) {
+ printf(%s: timedout waiting for cc!\n, __func__);
+ return;
+ }
+ }
writel(CC_MASK, mmc_base-stat)
;
writel(MMC_CMD0, mmc_base-cmd)
;
- while (!(readl(mmc_base-stat) CC_MASK))
- ;
+ start = get_timer(0);
+ while (!(readl(mmc_base-stat) CC_MASK)) {
+ if (get_timer(0) - start MAX_RETRY_MS) {
+ printf(%s: timedout waiting for cc2!\n, __func__);
+ return;
+ }
+ }
writel(readl(mmc_base-con) ~INIT_INITSTREAM, mmc_base-con);
}
@@ -91,16 +105,28 @@ static int mmc_init_setup(struct mmc *mmc)
hsmmc_t *mmc_base = (hsmmc_t *)mmc-priv;
unsigned int reg_val;
unsigned int dsor;
+ ulong start;
mmc_board_init(mmc_base);
writel(readl(mmc_base-sysconfig) | MMC_SOFTRESET,
mmc_base-sysconfig);
- while ((readl(mmc_base-sysstatus) RESETDONE) == 0)
- ;
+ start = get_timer(0);
+ while ((readl(mmc_base-sysstatus) RESETDONE) == 0) {
+ if (get_timer(0) - start MAX_RETRY_MS) {
+ printf(%s: timedout waiting for cc2!\n, __func__);
+ return TIMEOUT;
+ }
+ }
writel(readl(mmc_base-sysctl) | SOFTRESETALL, mmc_base-sysctl);
- while ((readl(mmc_base-sysctl) SOFTRESETALL) != 0x0)
- ;
+ start = get_timer(0);
+ while ((readl(mmc_base-sysctl) SOFTRESETALL) != 0x0) {
+ if (get_timer(0) - start MAX_RETRY_MS) {
+ printf(%s: timedout waiting for softresetall!\n,
+ __func__);
+ return TIMEOUT;
+ }
+ }
writel(DTW_1_BITMODE | SDBP_PWROFF | SDVS_3V0, mmc_base-hctl);
writel(readl(mmc_base-capa) | VS30_3V0SUP | VS18_1V8SUP,
mmc_base-capa);
@@ -116,8 +142,13 @@ static int mmc_init_setup(struct mmc *mmc)
(ICE_STOP | DTO_15THDTO | CEN_DISABLE));
mmc_reg_out(mmc_base-sysctl, ICE_MASK | CLKD_MASK,
(dsor CLKD_OFFSET) | ICE_OSCILLATE);
- while ((readl(mmc_base-sysctl) ICS_MASK) == ICS_NOTREADY)
- ;
+ start = get_timer(0);
+ while ((readl(mmc_base-sysctl) ICS_MASK) == ICS_NOTREADY) {
+ if (get_timer(0) - start MAX_RETRY_MS) {
+ printf(%s: timedout waiting for ics!\n, __func__);
+ return TIMEOUT;
+ }
+ }
writel(readl(mmc_base-sysctl) | CEN_ENABLE, mmc_base-sysctl);
writel(readl(mmc_base-hctl) | SDBP_PWRON, mmc_base-hctl);
@@ -137,14 +168,23 @@
Re: [U-Boot] [PATCH] MPC8315ERD: fix build error
In message 1287929649-19180-1-git-send-email...@denx.de you wrote: Commit 29c6fbe MPC5121: Add USB EHCI support renamed CONFIG_SYS_MPC8xxx_USB_ADDR into CONFIG_SYS_FSL_USB_ADDR but missed to update arch/powerpc/cpu/mpc83xx/cpu_init.c, resulting in: cpu_init.c: In function 'cpu_init_f': cpu_init.c:332: error: 'CONFIG_SYS_MPC8xxx_USB_ADDR' undeclared (first use in this function) cpu_init.c:332: error: (Each undeclared identifier is reported only once cpu_init.c:332: error: for each function it appears in.) make[1]: *** [/work/wd/tmp-ppc/arch/powerpc/cpu/mpc83xx/cpu_init.o] Error 1 Fix this. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Kim Phillips kim.phill...@freescale.com --- arch/powerpc/cpu/mpc83xx/cpu_init.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied. Hope this is OK with you, Kim? 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 Well, the way I see it, logic is only a way of being ignorant by num- bers. - 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] hcu4, hcu5: fix out of tree building
In message 1287931883-19065-1-git-send-email...@denx.de you wrote: Out of tree building of the Netstal hcu4 and hcu5 boards failed like that: Assembler messages: Fatal error: can't create /work/wd/tmp-ppc/board/netstal/hcu4/../common/fixed_sdram.o: No such file or directory Assembler messages: Fatal error: can't create /work/wd/tmp-ppc/board/netstal/hcu4/../common/nm_bsp.o: No such file or directory make[1]: *** [/work/wd/tmp-ppc/board/netstal/hcu4/../common/fixed_sdram.o] Error 2 Adapt (and simplify) the respective Makefiles. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Niklaus Giger niklaus.gi...@netstal.com --- board/netstal/hcu4/Makefile | 20 ++-- board/netstal/hcu5/Makefile | 17 + 2 files changed, 19 insertions(+), 18 deletions(-) Applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It would seem that evil retreats when forcibly confronted -- Yarnek of Excalbia, The Savage Curtain, stardate 5906.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ARM: Use consistent assembler syntax
Dear Gray Remlin, In message 4cc44e47.2050...@rocketmail.com you wrote: Signed-off-by: Gray Remlin g_rem...@rocketmail.com --- Patch V3 Subject line correction change to patch v2 from arm926ejs: Fix two occurrences of illegal syntax assembler instructions originally used in patch v1, as it now impacts more than one CPU type. arch/arm/cpu/arm1136/start.S |4 ++-- arch/arm/cpu/arm926ejs/start.S |4 ++-- arch/arm/cpu/armv7/start.S |4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index 29ed065..0425b54 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -238,7 +238,7 @@ copy_loop: add r3, r3, r0 /* r3 - rel dyn end in FLASH */ fixloop: ldr r0, [r2]/* r0 - location to fix up, IN FLASH! */ - add r0, r9 /* r0 - location to fix up in RAM */ + add r0, r0, r9 /* r0 - location to fix up in RAM */ ldr r1, [r2, #4] and r8, r1, #0xff cmp r8, #23 /* relative fixup? */ @@ -252,7 +252,7 @@ fixabs: mov r1, r1, LSR #4 /* r1 - symbol index in .dynsym */ add r1, r10, r1 /* r1 - address of symbol in table */ Your patch is line wrapped and white space corrupted. I applied it manually, but please fix your mailer, or, even better, use git send-email to submit patches. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Peace was the way. -- Kirk, The City on the Edge of Forever, stardate unknown ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-i2c
Dear Heiko Schocher, In message 4cc51ed5.8040...@denx.de you wrote: Hello Wolfgang, The following changes since commit fff6ec382c139eb242bd85356e66a0bc43becb63: Fix building for 83xx boards with USB support (2010-10-21 20:00:41 +0200) are available in the git repository at: git://git.denx.de/u-boot-i2c.git master Steve Sakoman (1): ARMV7: OMAP: I2C driver: Fix bug found in 37XX testing drivers/i2c/omap24xx_i2c.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de There is a biblical analogy I'd like to draw here. Casts are to C++ Programmers what the apple was to Eve. - Scott Douglas Meyers ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-ppc4xx/master
Dear Stefan Roese, In message 201010251732.17729...@denx.de you wrote: The following changes since commit c163f4478ca72f51b28b55f74addc8fe029d7b83: Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master (2010-10-25 08:06:52 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-ppc4xx.git master Dirk Eibach (1): ppc4xx: Add Io and IoCon 405EP board support Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 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] Pull request u-boot-blackfin.git
Dear Mike Frysinger, In message 1288058944-10850-1-git-send-email-vap...@gentoo.org you wrote: The following changes since commit c163f4478ca72f51b28b55f74addc8fe029d7b83: Merge branch 'master' of ssh://gemini/home/wd/git/u-boot/master (2010-10-25 08:06:52 +0200) are available in the git repository at: git://www.denx.de/git/u-boot-blackfin.git master Mike Frysinger (2): Blackfin: bf527-ezkit-v2: move to boards.cfg Blackfin: adi boards: set compiled size limits MAKEALL |4 +--- Makefile |8 boards.cfg|1 + include/configs/bf548-ezkit.h |1 + include/configs/bfin_adi_common.h |3 +++ 5 files changed, 6 insertions(+), 11 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The optimum committee has no members. - Norman Augustine ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] Rename CONFIG_SYS_INIT_RAM_END into CONFIG_SYS_INIT_RAM_SIZE
In message 1288101601-24871-2-git-send-email...@denx.de you wrote: CONFIG_SYS_INIT_RAM_END was a misnomer as it suggests this might be some end address; to make the meaning more clear we rename it into CONFIG_SYS_INIT_RAM_SIZE No other code changes are performed in this patch, only minor editing of white space (due to the changed length) and the comments was done, where noticed. Note that the code for the PATI and cmi_mpc5xx board configurations looks seriously broken. Last known maintainers on Cc: Signed-off-by: Wolfgang Denk w...@denx.de Cc: Denis Peter d.pe...@mpl.ch Cc: Martin Winistoerfer martinwinistoer...@gmx.ch Applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Disobedience: The silver lining to the cloud of servitude. - Ambrose Bierce ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3 v2] include/asm-offsets.h: automatically generate assembler constants
In message 1288102798-5475-1-git-send-email...@denx.de you wrote: A recurrent issue is that certain C level constructs like sizeof() or offsetof() cannot be used in assembler files, which is inconvenient when such constructs are used in the definition of macro names etc. To avoid duplication of such definitions (and thus another cause of problems), we adapt the Linux way to automatically generate the respective definitions from the respective C header files. In Linux, this is implemented in include/linux/kbuild.h, Kbuild, and arch/*/kernel/asm-offsets.c; we adapt the code from the Linux v2.6.36 kernel tree. We also copy the concept of the include/generated/ directory which can be used to hold other automatically generated files as well. We start with an architecture-independent lib/asm-offsets.c which generates include/generated/generic-asm-offsets.h (included by include/asm-offsets.h, which is what will be referred to in the actual source code). Later this may be extended by architecture-specific arch/*/lib/asm-offsets.c files that will generate a include/generated/asm-offsets.h. Signed-off-by: Wolfgang Denk w...@denx.de --- v2: fix typo add SoB line Aplied. 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 e-credibility: the non-guaranteeable likelihood that the electronic data you're seeing is genuine rather than somebody's made-up crap. - Karl Lehenbauer ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
In message 1288104730-25651-1-git-send-email...@denx.de you wrote: CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not being able to use sizeof(struct global_data) in assembler files. Recent experience has shown that manual synchronization is not reliable enough. This patch renames CONFIG_SYS_GBL_DATA_SIZE into GENERATED_GBL_DATA_SIZE which gets automatically generated by the asm-offsets tool. In the result, all definitions of this value can be deleted from the board config files. We have to make sure that all files that reference such data include the new asm-offsets.h file. No other changes have been done yet, but it is obvious that similar changes / simplifications can be done for other, related macro definitions as well. Signed-off-by: Wolfgang Denk w...@denx.de --- v2: round global data size up to a multiple of 16 to guarantee sufficient alignment of the initial stack. Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Is a computer language with goto's totally Wirth-less? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot text console
Dear Kallol Biswas, In message aanlktinaaxegvjxa2unfu262efqo=tr9lrywxanat...@mail.gmail.com you wrote: I have a customer request to build BIOS like user interface(UI) for u-boot over serial port? Something like text console with tabs on the top. Each tab will have sub-items just like BIOS. This is for a PPC platform. Is there any existing software/code base that can be used? The OpenMoko port had a menu implementation which could be reused. Alternatively, similar code has recently been added to BareBox; adapting this should be not too difficult either. 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 Punishment becomes ineffective after a certain point. Men become in- sensitive. -- Eneg, Patterns of Force, stardate 2534.7 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: fix address setup in start.S
Dear Darius Augulis, In message 20101025104524.12379.22378.st...@darius-desktop you wrote: Fix address setup bug for ARM. This bug stops u-boot booting if CONFIG_SKIP_RELOCATE_UBOOT is defined. Signed-off-by: Darius Augulis augulis.dar...@gmail.com --- arch/arm/cpu/arm1136/start.S |6 -- arch/arm/cpu/arm926ejs/start.S |6 -- arch/arm/cpu/armv7/start.S |6 -- arch/arm/cpu/pxa/start.S |6 -- 4 files changed, 16 insertions(+), 8 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de 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 v2] arm1176: fix relocation
Dear Darius Augulis, In message 20101025104707.12408.13906.st...@darius-desktop you wrote: Fix relocation code for arm1176, do it like other ARM CPU's are doing. Tested only with CONFIG_SKIP_RELOCATE_UBOOT defined and using nand_spl (booting from nand). Test done on s3c6410 based board (not yet supported in main line). Signed-off-by: Darius Augulis augulis.dar...@gmail.com --- Changes since v1: - Heiko comments fixed arch/arm/cpu/arm1176/start.S| 143 +++ arch/arm/cpu/arm1176/u-boot.lds | 15 +++- 2 files changed, 97 insertions(+), 61 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de It is a good thing for an uneducated man to read books of quotations. - Sir Winston Churchill _My Early Life_ ch. 9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sparc: add asm/unaligned.h
Dear Daniel Hellstrom, In message 4cc54d00.6040...@gaisler.com you wrote: Mike Frysinger wrote: It isn't possible to build any sparc boards without this ... I'm working on a new patch set with some of the patches going through the net repo instead, according to Wolfgangs comments. It is probably easier for me to make fewer commits every time submitting, and submitting multiple times. But it looks like a serious bug fix, so it should go in _now_, should it not? 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 How come everyone's going so slow if it's called rush hour? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] cmd_net: drop spurious comma in U_BOOT_CMD
Dear Mike Frysinger, In message 1287560010-31252-1-git-send-email-vap...@gentoo.org you wrote: Building for boards that have CONFIG_CMD_CDP enabled fail with: cmd_net.c:301: error: expected expression before ',' token Signed-off-by: Mike Frysinger vap...@gentoo.org --- common/cmd_net.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de America has been discovered before, but it has always been hushed up. - Oscar Wilde ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm, bootm: Fix compile warning
Dear Heiko Schocher, In message 1287988418-28003-1-git-send-email...@denx.de you wrote: Fix warning: bootm.c: In function 'bootm_linux_fdt': bootm.c:181: warning: unused variable 's' bootm.c:180: warning: unused variable 'bd' Signed-off-by: Heiko Schocher h...@denx.de --- arch/arm/lib/bootm.c |2 -- 1 files changed, 0 insertions(+), 2 deletions(-) Applied, thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Don't put off for tomorrow what you can do today, because if you enjoy it today you can do it again tomorrow. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Remove config.mk for da8xxevm based boards.
Dear Sughosh Ganu, In message 1287775683-17887-1-git-send-email-urwithsugh...@gmail.com you wrote: Move CONFIG_SYS_TEXT_BASE to the board's config file, and remove the now unnecessary config.mk file. Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com --- board/davinci/da8xxevm/config.mk | 43 -- include/configs/da830evm.h |1 + include/configs/da850evm.h |1 + 3 files changed, 2 insertions(+), 43 deletions(-) delete mode 100644 board/davinci/da8xxevm/config.mk Applied, thanks. Dear Sandeep, hope it's OK that I pulled this directly. 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 How many QA engineers does it take to screw in a lightbulb? 3: 1 to screw it in and 2 to say I told you so when it doesn't work. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ARM: use the same branch insn on all architectures
In message 1287868958-29447-1-git-send-email...@denx.de you wrote: For the fixloop implementation in start.S a number of different instructions was used. Unify code so all architectures use blo here because it is more robust in case of incorrect alignments. Signed-off-by: Wolfgang Denk w...@denx.de Cc: Albert ARIBAUD albert.arib...@free.fr Cc: Minkyu Kang mk7.k...@samsung.com Cc: Sandeep Paulraj s-paul...@ti.com Cc: Prafulla Wadaskar prafu...@marvell.com Cc: Stefano Babic sba...@denx.de Cc: Marek Vasut marek.va...@gmail.com --- arch/arm/cpu/arm1136/start.S |2 +- arch/arm/cpu/arm1176/start.S |2 +- arch/arm/cpu/arm720t/start.S |2 +- arch/arm/cpu/arm920t/start.S |2 +- arch/arm/cpu/arm925t/start.S |2 +- arch/arm/cpu/arm946es/start.S |2 +- arch/arm/cpu/arm_intcm/start.S |2 +- arch/arm/cpu/ixp/start.S |2 +- arch/arm/cpu/lh7a40x/start.S |2 +- arch/arm/cpu/s3c44b0/start.S |2 +- arch/arm/cpu/sa1100/start.S|2 +- 11 files changed, 11 insertions(+), 11 deletions(-) Applied. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The Buddha, the Godhead, resides quite as comfortably in the circuits of a digital computer or the gears of a cycle transmission as he does at the top of a mountain or in the petals of a flower. - R. Pirsig, Zen and the Art of Motorcycle Maintenance ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] tqm85xx: Update PCI code
Dear Peter Tyser,
In message 1285785448-4703-3-git-send-email-pty...@xes-inc.com you wrote:
Update to use the recent, common FSL PCI initialization code.
Signed-off-by: Peter Tyser pty...@xes-inc.com
CC: s...@denx.de
---
board/tqc/tqm85xx/law.c |4 +-
board/tqc/tqm85xx/tlb.c | 10 ++--
board/tqc/tqm85xx/tqm85xx.c | 151
---
include/configs/TQM85xx.h | 20 +++---
4 files changed, 59 insertions(+), 126 deletions(-)
This commit needs fixing.
First, it corrupts the output. Some patch like this should be added:
diff --git a/board/tqc/tqm85xx/tqm85xx.c b/board/tqc/tqm85xx/tqm85xx.c
index 2c3885f..027c429 100644
--- a/board/tqc/tqm85xx/tqm85xx.c
+++ b/board/tqc/tqm85xx/tqm85xx.c
@@ -567,7 +567,7 @@ void pci_init_board (void)
if (!(devdisr MPC85xx_DEVDISR_PCI1)) {
SET_STD_PCI_INFO(pci_info[num], 1);
pcie_ep = fsl_setup_hose(pci1_hose, pci_info[num].regs);
- printf (\n PCI1: %d bit, %s MHz, %s, %s, %s\n,
+ printf (PCI1: %d bit, %s MHz, %s, %s, %s\n,
(pci_32) ? 32 : 64,
(pci_speed == ) ? 33 :
(pci_speed == ) ? 66 : unknown,
@@ -591,7 +591,7 @@ void pci_init_board (void)
}
#endif
} else {
- printf(PCI1: disabled\n);
+ printf(PCI1: disabled\n);
}
#else
setbits_be32(gur-devdisr, MPC85xx_DEVDISR_PCI1);
Even worse, we now see a (badly formatted, but this is just an added
bonus)
Scanning PCI bus 00
PCIE1 on bus 00 - 00
which is completely bogus as there on these boards nor on these
processors.
Can you please provide a fix?
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
It's like deja vu all over again. - Yogi Berra
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
+ /* Round up to make sure size gives nice stack alignment */
+ DEFINE(GENERATED_GBL_DATA_SIZE,
+ (sizeof(struct global_data)+15) ~15);
+
This has already been applied, sooner than usual. Isn't it cleaner to
force alignment on the structure itself? This way different architectures
may use different values, if the need arises.
This shows it.
struct a {
int i;
} __attribute__((aligned(16)));
struct b {
int i;
};
int main()
{
printf(%i %i\n, sizeof(struct a), sizeof(struct b));
}
It prints 16 4 as expected.
/alessandro
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V6 03/10] 83xx/85xx/86xx: LBC register cleanup
Dear Kumar, In message e39353d6-873a-41a6-b5ab-211ff6173...@kernel.crashing.org you wrote: Hmm, how about dumping all of the LBC registers and comparing before/after this change. After the change (here with 2010.09-00558-g79e6313): Board: TQM8555, serial# ABC0555 casl=25 I2C: ready DRAM: 128 MiB FLASH: 128 MiB L2:256 KB already enabled = fli Bank # 1: CFI conformant FLASH (32 x 16) Size: 64 MB in 512 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E Erase timeout: 16384 ms, write timeout: 1 ms Buffer write timeout: 5 ms, buffer size: 32 bytes Sector Start Addresses: F800 E F802 E F804 E F806 E F808 E F80A E F80C E F80E E F810 E F812 E ... FBF2 E FBF4FBF6 E FBF8FBFA FBFCFBFE Bank # 2: CFI conformant FLASH (128 x 128) Size: 64 MB in 512 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E Erase timeout: 16384 ms, write timeout: 1 ms Buffer write timeout: 5 ms, buffer size: 32 bytes Sector Start Addresses: FC00FC02FC04FC06FC08 FC0AFC0CFC0EFC10FC12 ... FFF2FFF4 RO FFF6 RO FFF8 RO FFFA RO FFFC RO FFFE RO ccsrbar: 0x000e 917504 altcbar: 0x 0 altcsr : 0x 0 bptr : 0x 0 lawbar0: 0x 0 lawar0 : 0x80f0001e -2131754978 lawbar1: 0x0008 524288 lawar1 : 0x801c -2147483620 lawbar2: 0x000f8000 1015808 lawar2 : 0x8040001a -2143289318 lawbar3: 0x000e2000 925696 lawar3 : 0x8017 -2147483625 lawbar4: 0x000c 786432 lawar4 : 0x80c0001c -2134900708 lawbar5: 0x 0 lawar5 : 0x 0 lawbar6: 0x 0 lawsa6 : 0x 0 lawbar7: 0x 0 lawsa7 : 0x 0 br0: 0xf8001801 -134211583 br1: 0xf8001801 -134211583 br2: 0x 0 br3: 0x 0 br4: 0x 0 br5: 0x 0 br6: 0x 0 br7: 0x 0 or0: 0xfc40 -67108800 or1: 0xfc40 -67108800 or2: 0x 0 or3: 0x 0 or4: 0x 0 or5: 0x 0 or6: 0x 0 or7: 0x 0 before (here with v2010.06): Board: TQM8555, serial# ABC0555 casl=25 I2C: ready DRAM: 128 MiB FLASH: 128 MiB L2:256 KB enabled = fli Bank # 1: CFI conformant FLASH (32 x 16) Size: 64 MB in 512 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E Erase timeout: 16384 ms, write timeout: 1 ms Buffer write timeout: 5 ms, buffer size: 32 bytes Sector Start Addresses: F800 E F802 E F804 E F806 E F808 E F80A E F80C E F80E E F810 E F812 E ... FBF2 E FBF4 E FBF6 E FBF8 E FBFA E FBFC E FBFE E Bank # 2: CFI conformant FLASH (32 x 16) Size: 64 MB in 512 Sectors AMD Standard command set, Manufacturer ID: 0x01, Device ID: 0x227E Erase timeout: 16384 ms, write timeout: 1 ms Buffer write timeout: 5 ms, buffer size: 32 bytes Sector Start Addresses: FC00 E FC02 E FC04 E FC06 E FC08 E FC0A E FC0C E FC0E E FC10 E FC12 E ... FFF2 E FFF4 RO FFF6 E RO FFF8 RO FFFA RO FFFC RO FFFE RO ccsrbar: 0x000e 917504 altcbar: 0x 0 altcsr : 0x 0 bptr : 0x 0 lawbar0: 0x 0 lawar0 : 0x80f0001e -2131754978 lawbar1: 0x0008 524288 lawar1 : 0x801c -2147483620 lawbar2: 0x000f8000 1015808 lawar2 : 0x8040001a -2143289318 lawbar3: 0x000e2000 925696 lawar3 : 0x8017 -2147483625 lawbar4: 0x000c 786432 lawar4 : 0x80c0001c -2134900708 lawbar5: 0x 0 lawar5 : 0x 0 lawbar6: 0x 0 lawsa6 : 0x 0 lawbar7: 0x 0 lawsa7 : 0x 0 br0: 0xfc001801 -67102719 br1: 0xf8001801 -134211583 br2: 0x 0 br3: 0x 0 br4: 0x 0 br5: 0x 0 br6: 0x 0 br7: 0x 0 or0: 0xfc40 -67108800 or1: 0xfc40 -67108800 or2: 0x 0 or3
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
Dear Alessandro Rubini, In message 20101026195429.ga1...@morgana.i.gnudd.com you wrote: This has already been applied, sooner than usual. Isn't it cleaner to force alignment on the structure itself? This way different architectures may use different values, if the need arises. It would be better, but how to implement that? Please keep in mind that the pointers are set up in aseembler code, where we don't have such things as struct etc. We're dealing with raw addresses here, which is the reason we have to go through all this effort with asm-offsets and such. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I have a very small mind and must live with it.-- Edsger Dijkstra ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
This has already been applied, sooner than usual. Isn't it cleaner to force alignment on the structure itself? This way different architectures may use different values, if the need arises. It would be better, but how to implement that? Instead of: DEFINE(GENERATED_GBL_DATA_SIZE, (sizeof(struct global_data)+15) ~15); I'd use: DEFINE(GENERATED_GBL_DATA_SIZE, (sizeof(struct global_data)), leaving the alignment requirement in the structure itself (include/asm/global_data.h for each architecture). /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V7] POST cleanup.
Dear Michael Zaidman,
In message
d520c6ef298416a03789ebfa4e05e257b5331693.1284965175.git.michael.zaid...@gmail.com
you wrote:
- Revives POST for blackfin arch;
- Removes redundant code:
arch/blackfin/lib/post.c
arch/powerpc/cpu/ppc4xx/commproc.c
arch/powerpc/cpu/mpc512x/common.c
- fixes up the post_word_{load|store} usage.
Unfortunately it turns out that the code now contains a few nasty
bugs...
...
#define CONFIG_SYS_GBL_DATA_OFFSET (CONFIG_SYS_INIT_RAM_END -
CONFIG_SYS_GBL_DATA_SIZE)
-#define CONFIG_SYS_POST_WORD_ADDR(CONFIG_SYS_GBL_DATA_OFFSET - 0x4)
-#define CONFIG_SYS_INIT_SP_OFFSETCONFIG_SYS_POST_WORD_ADDR
+#define CONFIG_SYS_INIT_SP_OFFSET(CONFIG_SYS_GBL_DATA_OFFSET - 0x4)
This is a seriously broken design, as it sneaks in storage for a
variable in a storage location where it is not expected.
The official layout is that we have CONFIG_SYS_INIT_RAM_BYTES
available; the top CONFIG_SYS_GBL_DATA_SIZE bytes (now
GENERATED_GBL_DATA_SIZE) are used for global data, and the part below
is used for the stack. No other room is reserved there.
Shifting down the stack by 4 bytes as it's done here causes that the
stack is not correctly aligned any more, which may cause really nasty
subsequent errors.
But it's even worse.
diff --git a/include/configs/mpc5121-common.h
b/include/configs/mpc5121-common.h
index 96fab20..afae1ab 100644
--- a/include/configs/mpc5121-common.h
+++ b/include/configs/mpc5121-common.h
...
-#define CONFIG_SYS_POST_WORD_ADDR(CONFIG_SYS_GBL_DATA_OFFSET - 0x4)
-#define CONFIG_SYS_INIT_SP_OFFSETCONFIG_SYS_POST_WORD_ADDR
+#define CONFIG_SYS_INIT_SP_OFFSET(CONFIG_SYS_GBL_DATA_OFFSET - 0x4)
There the same is done, but what happens actually?
Have a look how the stack setup gets implemented in
arch/powerpc/cpu/mpc512x/start.S:
...
244 in_flash:
245 lis r1, (CONFIG_SYS_INIT_RAM_ADDR +
CONFIG_SYS_GBL_DATA_OFFSET)@h
246 ori r1, r1, (CONFIG_SYS_INIT_RAM_ADDR +
CONFIG_SYS_GBL_DATA_OFFSET)@l
247
248 li r0, 0 /* Make room for stack frame header and */
249 stwur0, -4(r1) /* clear final stack frame so that */
250 stwur0, -4(r1) /* stack backtraces terminate cleanly */
...
As you can see, the code does not use CONFIG_SYS_INIT_SP_OFFSET at
all; instead it performs a calculation which should be redundant, but
in the current code it means that the location of the POST_WORD is
right in the initial stack.
I did not check if the code for other processors has similar issues.
Reserving private storage like that is bad, as other involved
parties probably have no knowledge of such a private reservation.
Why do we not simply reserve a word in the global data structure instead?
This bug needs pretty urgent fixing.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
I wish Captain Vimes were here. He wouldn't have known what to do
either, but he's got a much better vocabulary to be baffled in.
- Terry Pratchett, _Guards! Guards!_
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
Dear Alessandro Rubini, In message 20101026205756.ga2...@morgana.i.gnudd.com you wrote: Instead of: DEFINE(GENERATED_GBL_DATA_SIZE, (sizeof(struct global_data)+15) ~15); I'd use: DEFINE(GENERATED_GBL_DATA_SIZE, (sizeof(struct global_data)), leaving the alignment requirement in the structure itself (include/asm/global_data.h for each architecture). Is it guaranteed (I mean by the C standard) that the alignment of a struct (which affects only the possible start address) also has effect on the sizeof() for that struct, in the sense that sizeof() is guaranteed to be a multiple of that alignment requirement? 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 panic: kernel trap (ignored) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
Is it guaranteed (I mean by the C standard) that the alignment of a struct (which affects only the possible start address) also has effect on the sizeof() for that struct, in the sense that sizeof() is guaranteed to be a multiple of that alignment requirement? Yes. Because if you make an array, all of them must be aligned, and the size of an array is a multiple of sizeof(array_item). While alignment is not in the standard, the sizeof/array relationship is. It's in C99 draft (http://busybox.net/~landley/c99-draft.html) 6.5.3.4 The sizeof operator #6 EXAMPLE 2 Another use of the sizeof operator is to compute the number of elements in an array: sizeof array / sizeof array[0] /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Timer implementations
On 10/26/2010 6:33 AM, Reinhard Meyer wrote:
Dear Wolfgang Denk,
Then the define CONFIG_SYS_HZ should not be in everyboard.h since that
suggests that a board developer has some freedom there...
Agreed - there are historical reasons this has ever been changable at
all.
and MOST IMPORTANT that some implementations of udelay() might
call reset_timer() and therefore break an outer timeout loop !!!
Such implementations are inherently broken and need to be fixed.
Found such in arm926ejs/omap... But then, that timer is multiple-broken:
relocation broken (uses static data), returns 32 a bit value in get_ticks(),
returns CONFIG_SYS_HZ in get_tbclk() instead of the rate get_ticks()
increments...
PXA:
void udelay_masked (unsigned long usec)
{
unsigned long long tmp;
ulong tmo;
tmo = us_to_tick(usec);
tmp = get_ticks() + tmo;/* get current timestamp */
while (get_ticks() tmp)
/* loop till event _OR FOREVER is tmp happens to be 32 bit_ */
/*NOP*/;
}
unsigned long long get_ticks(void)
{
return readl(OSCR);
}
- not any better :( -- its the same code that AT91 had before I fixed it.
It is also open if reset_timer() does actually reset the hardware timer
(e.g. tbu/tbl at PPC) - which would be messing up any time difference
calculation using get_ticks() - or does emulate that by remembering
the hardware value and subtracting it later in every subsequent
get_timer() call?
This is an implementation detail.
IF we require that get_ticks() and get_timer() shall not interfere with
each other and IF both are based on the same hardware timer only the
second method is available (same if the hardware timer is not easyly
resettable).
2. get_ticks() and friends operate at a higher rate (tbu/tbl for PPC).
Since they are defined as having 64 bits they MUST not wrap at 32 bits,
i.e. if the hardware provides only 32 bits, the upper 32 bits must be
emulated by software.
Right.
Otherwise we have to document that get_ticks() cannot be used to get
64 bit time differences.
No. Such an implementation is broken and needs fixing.
Original AT91 timer.c was like that, and I think other ARMs where this was
copied around should be looked at... I don't know when get_timer() became
64 bits, but it seems that some implementations just did change the return
type: uint64 get_timer(void) {return (uint64)timer_val_32;}
Hi All,
I am pretty sure the migration to 64 bits was caused by 1) people
not understanding that the timer operating on time DIFFERENCES would
work fine even if the underlying timer wrapped around (most probable
problem) and possibly 2) broken timer functions causing bogus timeouts,
improperly fixed by switching to 64 bits.
I think u-boot could get along just fine with only 2 time related
functions, uint_32 get_timer(uint_32 base) and udelay(uint 32 delay).
udelay will only work on small values of delay, on the order of
milliseconds. It is to be used when a short but precise delay in
microsecond resolution is required. Users of get_timer must understand
that it is only valid if it is called often enough, i.e. at least once
per period of the underlying timer. This is required because u-boot
does not want to rely on interrupts as a timer update method. Therefore,
all uses of get_timer must 1) call it once initially to get a start
value, and 2) call get_timer at least once per period of the underlying
hardware counter. This underlying period is guaranteed to be at least
4.29 seconds (32 bit counter at 4 GHz). Note that this does NOT mean
that the total wait must be less than 4.29 seconds, only that the rate
at which the elapsed time is TESTED must be adequate.
In order to implement this functionality, at least one hardware timer of
some kind is required. An additional software timer in 1 ms resolution
may be useful in maintaining the software time. If the hardware timer
update rate is programmable, u-boot MAY set the update rate on
initialization On initialization, u-boot MAY reset the hardware timer
and MAY reset any associated software timer. The hardware timer MAY be
started on initialization. On each call to get_timer(), u-boot MUST
start the hardware timer if it was not started already. On calls to
get_timer, u-boot MUST NOT reset the hardware timer if it was already
started. The software timer MAY be reset if u-boot can unambiguously
determine that more than 4.29 seconds has elapsed since the last call
to get_timer.
The simplest case for implementing this scheme is if two programmable
timers exist that can be set to 1ms and 1us. The timers are initialized
at start-up, get_timer just returns the 32 bit 1 ms timer and udelay
just waits for the number of ticks required on the second timer to
elapse. The most common harder case is where there is only one timer
available, it is running at 1 us per tick or faster, and we cannot
control the rate. udelay is still
[U-Boot] [PATCH] post/drivers/i2c.c: fix compile error
Commit 7e263ce post/i2c: Clean up detection logic added a const
qualifier to the declaration of i2c_addr_list[], missing the fact that
the list gets modified later in the code, which results in build
errors like these:
i2c.c: In function 'i2c_post_test':
i2c.c:88: error: assignment of read-only location
Remove the incorrect const.
Signed-off-by: Wolfgang Denk w...@denx.de
Cc: Peter Tyser pty...@xes-inc.com
Cc: Heiko Schocher h...@denx.de
---
post/drivers/i2c.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/post/drivers/i2c.c b/post/drivers/i2c.c
index 3080e81..4a1b1a4 100644
--- a/post/drivers/i2c.c
+++ b/post/drivers/i2c.c
@@ -74,7 +74,7 @@ int i2c_post_test (int flags)
#else
unsigned int ret = 0;
int j;
- const unsigned char i2c_addr_list[] = CONFIG_SYS_POST_I2C_ADDRS;
+ unsigned char i2c_addr_list[] = CONFIG_SYS_POST_I2C_ADDRS;
/* Start at address 1, address 0 is the general call address */
for (i = 1; i 128; i++) {
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
Dear Alessandro Rubini, In message 20101026211821.ga2...@morgana.i.gnudd.com you wrote: Is it guaranteed (I mean by the C standard) that the alignment of a struct (which affects only the possible start address) also has effect on the sizeof() for that struct, in the sense that sizeof() is guaranteed to be a multiple of that alignment requirement? Yes. Because if you make an array, all of them must be aligned, and the size of an array is a multiple of sizeof(array_item). While alignment is not in the standard, the sizeof/array relationship is. I am not convinced, as we don't have an array context here. It's in C99 draft (http://busybox.net/~landley/c99-draft.html) 6.5.3.4 The sizeof operator #6 EXAMPLE 2 Another use of the sizeof operator is to compute the number of elements in an array: sizeof array / sizeof array[0] I don't see that with struct foo x; struct foo y[N]; we have a guarantee that sizeof(x) == sizeof(y[0]). Maybe I'm just paranoid... 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 Until you walk a mile in another man's moccasins, you can't imagine the smell. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3 v2] Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value
I am not convinced, as we don't have an array context here. But sizeof(struct x) doesn't depend on how struct x is used. You can declare a pointer and then allocate for an array. I don't see that with struct foo x; struct foo y[N]; we have a guarantee that sizeof(x) == sizeof(y[0]). Yes, I see this requirement. But maybe we're already bikeshedding: I won't get offended if you keep the global +15 ~15. regards /alessandro ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
