Re: [U-Boot] How can i add intterrupt for AT91SAM9260EK board
Hello, Am Donnerstag, 29. Juli 2010, 08:25:53 schrieb Reinhard Meyer: > You have add interrupt handling (write source) to AT91 in general and > provide a patch for that. > > But first you have to define why you need interrupts (in the u-boot > phase) in the first place. One reason would be to workaround errata 44.3.5.1 (RSTC: Reset During SDRAM Accesses) on the AT91SAM9G20 which traps the reset interrupt to shutdown the SDRAM controller properly -.- Best regards, Alexander ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] How can i add intterrupt for AT91SAM9260EK board
zhou yu wrote: > Hi all, > Hi Zhou Yu, > I want to add a interrupt for AT91SAM9260EK board. When I define > CONFIG_USE_IRQ in at91sam9260ek.h, > then compile, I got error message "error: CONFIG_USE_IRQ not supported". I > don't know why put this message here so I commented out. > It is there BECAUSE the current source for AT91 does NOT support interrupts... > Then I define CONFIG_STACKSIZE_IRQ, CONFIG_STACKSIZE_FIQ like this, and > compile complete. > #define CONFIG_STACKSIZE_IRQ 4096 > #define CONFIG_STACKSIZE_FIQ 4096 > > Download u-boot.bin to my board with sam-ba.exe, and reset. When u-boot run > to enable_interrupts() in board.c, the board halt. > > What should I do? Thank you! > It requires more than commenting the message out :) You have add interrupt handling (write source) to AT91 in general and provide a patch for that. But first you have to define why you need interrupts (in the u-boot phase) in the first place. Best Regards Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] How can i add intterrupt for AT91SAM9260EK board
Hi all, I want to add a interrupt for AT91SAM9260EK board. When I define CONFIG_USE_IRQ in at91sam9260ek.h, then compile, I got error message "error: CONFIG_USE_IRQ not supported". I don't know why put this message here so I commented out. Then I define CONFIG_STACKSIZE_IRQ, CONFIG_STACKSIZE_FIQ like this, and compile complete. #define CONFIG_STACKSIZE_IRQ 4096 #define CONFIG_STACKSIZE_FIQ 4096 Download u-boot.bin to my board with sam-ba.exe, and reset. When u-boot run to enable_interrupts() in board.c, the board halt. What should I do? Thank you! BTW: Hardware has been verified is good. Yours lightrain ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] ATMEL Custodians == /dev/null ??
On Wednesday, July 28, 2010 22:02:12 Reinhard Meyer wrote: > it seems that Atmel is not willing to provide manpower for custodians. i think the linux/open source team there saw some shrinkage, and/or the higher ups thought a change in direction away from working with the community/upstream was the way to go (and to simply maintain an internal fork perpetually). i'm of course just speculating based on their drop off in submissions in general across open source projects and have no direct knowledge of anything. from the developers pov, they probably dont have much choice. when the economy shrinks and your boss says that is no longer your job, then it's a hard choice. do the right thing or continue to eat ;). > I have spend considerable extra time to split my work towards the u-boot > port of our new boards into separate patches for the AT91 SoCs. > > I have sent them to the list some weeks ago only to see that exactly > NOTHING happens to move them towards mainstream. > > Unless something happens soon in that regard I will in the future > refrain from investing extra hours to create patches for Atmel hardware. if the maintainers are effectively dead, then i'd suggest someone (i.e. Wolfgang) hand the custodian role over to someone willing to do the work. employment by the company who owns the processor in question only goes so far. vastly more important are the people doing the actual work and in this case, it seems like that person might be you vs anyone with @atmel.com in their e- mail address. -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
[U-Boot] How to handle binary data file in u-boot
Hi Experts, We have implemented an display utilty in u-boot and this utlity needs a waveform file. We are planning to release this display utility, but we don't know how to do with the waveform file. The file is as large as 800KB. Now we just put the waveform file on mmc and read it out in boot. Is there any better way to deliver this binary waveform file as part of the bootloader? How is this case typically handled? Thanks in advance. Yours Terry ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] flash_protect: check for NULL flash info
If a flash is unable to be detected, and then someone calls flash_protect
on it (like the common code does in flash_init), the flash_protect logic
will dereference a NULL pointer.
Since flash_protect already does sanity checking on the info structs, add
a NULL pointer check in there.
Signed-off-by: Mike Frysinger
---
common/flash.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/common/flash.c b/common/flash.c
index eb4b2f5..683978e 100644
--- a/common/flash.c
+++ b/common/flash.c
@@ -43,15 +43,18 @@ extern flash_info_t flash_info[]; /* info for FLASH chips
*/
void
flash_protect (int flag, ulong from, ulong to, flash_info_t *info)
{
- ulong b_end = info->start[0] + info->size - 1; /* bank end address */
- short s_end = info->sector_count - 1; /* index of last sector */
+ ulong b_end;
+ short s_end;
int i;
/* Do nothing if input data is bad. */
- if (info->sector_count == 0 || info->size == 0 || to < from) {
+ if (!info || info->sector_count == 0 || info->size == 0 || to < from) {
return;
}
+ s_end = info->sector_count - 1; /* index of last sector */
+ b_end = info->start[0] + info->size - 1;/* bank end address */
+
debug ("flash_protect %s: from 0x%08lX to 0x%08lX\n",
(flag & FLAG_PROTECT_SET) ? "ON" :
(flag & FLAG_PROTECT_CLEAR) ? "OFF" : "???",
--
1.7.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 0/2] ARMV7: Add support for Versatile Express CortexA9x4
From: Matt Waddel Adds support for the ARM quad-core Cortex-A9 processor. This system includes a motherboard(Versatile Express), daughterboard(Coretile), and an SOC(Cortex-A9 quad core). The serial port, ethernet, and flash systems work with these additions. The 2nd patch fixes a bug in the "set baudrate xxx" functionality. Version 2 - Removed unneeded multi-core low_level setup code. Matt Waddel (2): ARMV7: Versatile Express Coretile CortexA9x4 support ARMV7: Fixed baudrate setting in pl01x driver MAINTAINERS|4 + MAKEALL|1 + arch/arm/include/asm/arch-armv7/sysctrl.h | 68 arch/arm/include/asm/arch-armv7/systimer.h | 50 ++ arch/arm/include/asm/arch-armv7/wdt.h | 55 +++ board/armltd/vexpress/Makefile | 50 ++ board/armltd/vexpress/ca9x4_ct_vxp.c | 231 board/armltd/vexpress/config.mk| 26 +++ board/armltd/vexpress/u-boot.lds | 50 ++ boards.cfg |1 + drivers/serial/serial_pl01x.c |5 +- include/configs/ca9x4_ct_vxp.h | 181 ++ 12 files changed, 721 insertions(+), 1 deletions(-) create mode 100644 arch/arm/include/asm/arch-armv7/sysctrl.h create mode 100644 arch/arm/include/asm/arch-armv7/systimer.h create mode 100644 arch/arm/include/asm/arch-armv7/wdt.h create mode 100644 board/armltd/vexpress/Makefile create mode 100644 board/armltd/vexpress/ca9x4_ct_vxp.c create mode 100644 board/armltd/vexpress/config.mk create mode 100644 board/armltd/vexpress/u-boot.lds create mode 100644 include/configs/ca9x4_ct_vxp.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 2/2] ARMV7: Fixed baudrate setting in pl01x driver
From: Matt Waddel
The pl01x serial driver was lacking the code to switch baudrates from the
command line. Fixed by simply saving the new baudrate and calling
serial_init() again.
Signed-off-by: Matt Waddel
---
drivers/serial/serial_pl01x.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/serial/serial_pl01x.c b/drivers/serial/serial_pl01x.c
index c645cef..5cd5b9c 100644
--- a/drivers/serial/serial_pl01x.c
+++ b/drivers/serial/serial_pl01x.c
@@ -41,13 +41,14 @@
* Versatile PB has four UARTs.
*/
#define CONSOLE_PORT CONFIG_CONS_INDEX
-#define baudRate CONFIG_BAUDRATE
static volatile unsigned char *const port[] = CONFIG_PL01x_PORTS;
#define NUM_PORTS (sizeof(port)/sizeof(port[0]))
static void pl01x_putc (int portnum, char c);
static int pl01x_getc (int portnum);
static int pl01x_tstc (int portnum);
+unsigned int baudRate = CONFIG_BAUDRATE;
+DECLARE_GLOBAL_DATA_PTR;
#ifdef CONFIG_PL010_SERIAL
@@ -183,6 +184,8 @@ int serial_tstc (void)
void serial_setbrg (void)
{
+ baudRate = gd->baudrate;
+ serial_init();
}
static void pl01x_putc (int portnum, char c)
--
1.7.0.4
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH V2 1/2] ARMV7: Versatile Express Coretile CortexA9x4 support
From: Matt Waddel
Adds support for the ARM quad-core Cortex-A9 processor. This system
includes a motherboard(Versatile Express), daughterboard(Coretile),
and SOC(Cortex-A9 quad core). The serial port, ethernet, and flash
systems work with these additions. The naming convention is:
SOC -> CortexA9 quad core = ca9x4
daughterboard -> Coretile = ct
motherboard -> Versatile Express = vxp
This gives ca9x4_ct_vxp.c as the board support file.
Signed-off-by: Matt Waddel
---
MAINTAINERS|4 +
MAKEALL|1 +
arch/arm/include/asm/arch-armv7/sysctrl.h | 68
arch/arm/include/asm/arch-armv7/systimer.h | 50 ++
arch/arm/include/asm/arch-armv7/wdt.h | 55 +++
board/armltd/vexpress/Makefile | 50 ++
board/armltd/vexpress/ca9x4_ct_vxp.c | 231
board/armltd/vexpress/config.mk| 26 +++
board/armltd/vexpress/u-boot.lds | 50 ++
boards.cfg |1 +
include/configs/ca9x4_ct_vxp.h | 181 ++
11 files changed, 717 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-armv7/sysctrl.h
create mode 100644 arch/arm/include/asm/arch-armv7/systimer.h
create mode 100644 arch/arm/include/asm/arch-armv7/wdt.h
create mode 100644 board/armltd/vexpress/Makefile
create mode 100644 board/armltd/vexpress/ca9x4_ct_vxp.c
create mode 100644 board/armltd/vexpress/config.mk
create mode 100644 board/armltd/vexpress/u-boot.lds
create mode 100644 include/configs/ca9x4_ct_vxp.h
diff --git a/MAINTAINERS b/MAINTAINERS
index 4b91b0f..31ff42f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -800,6 +800,10 @@ Hugo Villeneuve
SFFSDR ARM926EJS
+Matt Waddel
+
+ vexpressARM ARMV7 (quad core)
+
Prafulla Wadaskar
mv88f6281gtw_ge ARM926EJS (Kirkwood SoC)
diff --git a/MAKEALL b/MAKEALL
index 2133559..88b1843 100755
--- a/MAKEALL
+++ b/MAKEALL
@@ -663,6 +663,7 @@ LIST_ARMV7="\
omap4_sdp4430 \
s5p_goni\
smdkc100\
+ ca9x4_ct_vxp\
"
#
diff --git a/arch/arm/include/asm/arch-armv7/sysctrl.h
b/arch/arm/include/asm/arch-armv7/sysctrl.h
new file mode 100644
index 000..50cf661
--- /dev/null
+++ b/arch/arm/include/asm/arch-armv7/sysctrl.h
@@ -0,0 +1,68 @@
+/*
+ * (C) Copyright 2010 Linaro
+ * Matt Waddel,
+ *
+ * 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
+ */
+#ifndef _SYSCTRL_H_
+#define _SYSCTRL_H_
+
+/* System controller (SP810) register definitions */
+#define SP810_TIMER0_EnSel (1 << 15)
+#define SP810_TIMER1_EnSel (1 << 17)
+#define SP810_TIMER2_EnSel (1 << 19)
+#define SP810_TIMER3_EnSel (1 << 21)
+
+struct sysctrl {
+ u32 scctrl; /* 0x000 */
+ u32 scsysstat;
+ u32 scimctrl;
+ u32 scimstat;
+ u32 scxtalctrl;
+ u32 scpllctrl;
+ u32 scpllfctrl;
+ u32 scperctrl0;
+ u32 scperctrl1;
+ u32 scperen;
+ u32 scperdis;
+ u32 scperclken;
+ u32 scperstat;
+ u32 res1[0x3ac];
+ u32 scsysid0; /* 0xee0 */
+ u32 scsysid1;
+ u32 scsysid2;
+ u32 scsysid3;
+ u32 scitcr;
+ u32 scitir0;
+ u32 scitir1;
+ u32 scitor;
+ u32 sccntctrl;
+ u32 sccntdata;
+ u32 sccntstep;
+ u32 res2[0x32];
+ u32 scperiphid0;/* 0xfe0 */
+ u32 scperiphid1;
+ u32 scperiphid2;
+ u32 scperiphid3;
+ u32 scpcellid0;
+ u32 scpcellid1;
+ u32 scpcellid2;
+ u32 scpcellid3;
+};
+#endif /* _SYSCTRL_H_ */
diff --git a/arch/arm/include/asm/arch-armv7/systimer.h
b/arch/arm/include/asm/arch-armv7/systimer.h
new file mode 100644
index 000..085e2d8
--- /dev/null
+++ b/arch/arm/include/asm/arch-armv7/systimer.h
@@ -0,0 +1,50 @@
+/*
+ * (C) Copyright 2010 Linaro
+ * Matt Waddel,
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
[U-Boot] ATMEL Custodians == /dev/null ??
Hello all, it seems that Atmel is not willing to provide manpower for custodians. I have spend considerable extra time to split my work towards the u-boot port of our new boards into separate patches for the AT91 SoCs. I have sent them to the list some weeks ago only to see that exactly NOTHING happens to move them towards mainstream. Unless something happens soon in that regard I will in the future refrain from investing extra hours to create patches for Atmel hardware. With Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] U-Boot-pxa
Dne Čt 22. července 2010 17:01:37 Marek Vasut napsal(a): > Hi, please merge my "for-wd-master" branch into u-boot.git "master" branch. > Thanks Hi Wolfgang, I added two more patches. Here's a revised pull request, please merge my "for- wd-master" branch into u-boot.git "master" branch. Thanks! The following changes since commit 1f82ff4777f360e92aa37bbbed647f7b9d9d2044: Merge branch 'master' of git://git.denx.de/u-boot-video (2010-07-17 20:49:59 +0200) are available in the git repository at: http://git.denx.de/u-boot-pxa.git for-wd-master Marek Vasut (9): ARM: Define __raw_readX and __raw_writeX PXA: pxafb: Add ACX517AKN support common: Enable serial for PXA250 PXA: Palm Tungsten|C Support PXA: pxafb: Add support for Sharp LQ038J7DH53 PXA: Add initial Palm LifeDrive support PXA: Vpac270 config fixes PXA: Balloon3 board support PXA: Voipac270 128MB module support MAKEALL|3 +- Makefile |7 +- arch/arm/cpu/pxa/pxafb.c | 68 + arch/arm/include/asm/io.h | 46 ++- board/balloon3/Makefile| 48 +++ board/balloon3/balloon3.c | 244 board/balloon3/config.mk |1 + board/balloon3/lowlevel_init.S | 40 ++ board/balloon3/u-boot.lds | 55 +++ board/palmld/Makefile | 54 +++ board/palmld/config.mk |1 + board/palmld/lowlevel_init.S | 46 ++ board/palmld/palmld.c | 81 +++ board/palmld/u-boot.lds| 56 board/palmtc/Makefile | 54 +++ board/palmtc/config.mk |3 + board/palmtc/lowlevel_init.S | 40 ++ board/palmtc/palmtc.c | 77 ++ board/palmtc/u-boot.lds| 56 board/vpac270/vpac270.c|7 +- boards.cfg |3 + common/serial.c|2 +- include/configs/balloon3.h | 303 include/configs/palmld.h | 275 include/configs/palmtc.h | 250 + include/configs/vpac270.h | 32 - 26 files changed, 1839 insertions(+), 13 deletions(-) create mode 100644 board/balloon3/Makefile create mode 100644 board/balloon3/balloon3.c create mode 100644 board/balloon3/config.mk create mode 100644 board/balloon3/lowlevel_init.S create mode 100644 board/balloon3/u-boot.lds create mode 100644 board/palmld/Makefile create mode 100644 board/palmld/config.mk create mode 100644 board/palmld/lowlevel_init.S create mode 100644 board/palmld/palmld.c create mode 100644 board/palmld/u-boot.lds create mode 100644 board/palmtc/Makefile create mode 100644 board/palmtc/config.mk create mode 100644 board/palmtc/lowlevel_init.S create mode 100644 board/palmtc/palmtc.c create mode 100644 board/palmtc/u-boot.lds create mode 100644 include/configs/balloon3.h create mode 100644 include/configs/palmld.h create mode 100644 include/configs/palmtc.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] strange thing: u-boot's vsprintf overrun on DM355
hi,all:
I encounter strange thing again. :(
it seems the vsprintf will overrun. have someone met before?
To debug it ,I define a function writing character directly to the register:
"u_sendstring()"
Here is the code for debugging printf:
void printf(const char *fmt, ...)
{
va_list args;
uint i;
char printbuffer[CONFIG_SYS_PBSIZE];
va_start(args, fmt);
/* For this to work, printbuffer must be larger than
* anything we ever want to print.
*/
u_sendstring("printf2\n");
i = vsprintf(printbuffer, fmt, args);
u_sendstring("printf3\n");
va_end(args);
puts(printbuffer);
}
and here is the output:
DM3xx=>>:DONEprintf2
DM3xx=>>: printf3
DM3xx=>>: U-Boot 2009.03 ( 2010 - 23:14:17)
DM3xx=>>: I2C: ready
DM3xx=>>: DRAM: printf2
DM3xx=>>: printf3
DM3xx=>>: 128printf2
DM3xx=>>: printf3
DM3xx=>>: MB
DM3xx=>>: NAND: board_nand_init end
DM3xx=>>: nand_scan1
DM3xx=>>: nand_scan_ident1
DM3xx=>>: nand_scan_ident2
DM3xx=>>: nand_get_flash_type1
DM3xx=>>: nand_get_flash_type2
DM3xx=>>: nand_get_flash_type4
DM3xx=>>: printf2n BOOTME
DM3xx=>>: BOOTME
DM3xx=>>: BOOTME
DM3xx=>>: BOOTME
/// weill, you can see that the first string will output
correctly,such as "128" "MB", but when it ran to nand_get_flash_type(), the
chip reboot.
static struct nand_flash_dev *nand_get_flash_type(struct mtd_info *mtd,
struct nand_chip *chip, int busw, int *maf_id)
{
struct nand_flash_dev *type = NULL;
int i, dev_id, maf_idx;
int tmp_id, tmp_manf;
/* Select the device */
chip->select_chip(mtd, 0);
u_sendstring("nand_get_flash_type1\n");
.
u_sendstring("nand_get_flash_type4\n");
printk("NAND device: Manufacturer ID:"
" 0x%02x, Chip ID: 0x%02x (%s %s)\n", *maf_id, dev_id,
nand_manuf_ids[maf_idx].name, type->name);
u_sendstring("nand_get_flash_type5\n");
return type;
}
printk is just printf. So as i describe above, the code ran to vsprintf and
no respond anymore.
How could this happen? Is it another hardware bug?
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] powerpc/85xx: Add memory test feature for mpc85xx.
Wolfgang, As Timur pointed out, the post framework doesn't work for us. After U-boot relocate itself to RAM, we have only 2GB memory to test. The best place is before relocation. Many other boards do that. Following your idea of reusing code, I can only reuse the test pattern generator. I am open to suggestions. York Sun - Original Message - From:"Wolfgang Denk" To:"York Sun" Cc:"Timur Tabi" , "Kumar Gala" , "u-boot@lists.denx.de" Sent:7/28/2010 4:50 PM Subject:Re: [U-Boot] [PATCH 8/8] powerpc/85xx: Add memory test feature for mpc85xx. Dear York Sun, In message <1280351179.8571.63.ca...@oslab-l1> you wrote: > > > We already have too many different implementations of a memory test in > > U-Boot, and I will not accept adding yet another one. > > > I can reuse your testing code but have to move the desired code out of > memory.c file to avoid the need for CONFIG_POST and > CONFIG_SYS_POST_MEMORY. I also add a progress indicator. My testing NAK, and NAK. Please integrate your code into the existing POST framework instead, as a number of other boards already did. A progress indicator may be a nice little toy, but how does it integrate into the POST framework? > target is 2GB at a time, up to physically memory size which is easily > over 8GB. Without progress indicator, it feels hung when it is actually > running. Yes, memory testing takes time. In the context of a power-on self test (and this is what you are doing, right?) we should take care to fit it into the existing framework, though. > Please take a look at the patch below. Instead of integrating your needs into an existing framework you invent yet another one. I don't want to have this, sorry. 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 can you tell when sour cream goes bad? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] powerpc/85xx: Add memory test feature for mpc85xx.
Dear York Sun, In message <1280351179.8571.63.ca...@oslab-l1> you wrote: > > > We already have too many different implementations of a memory test in > > U-Boot, and I will not accept adding yet another one. > > > I can reuse your testing code but have to move the desired code out of > memory.c file to avoid the need for CONFIG_POST and > CONFIG_SYS_POST_MEMORY. I also add a progress indicator. My testing NAK, and NAK. Please integrate your code into the existing POST framework instead, as a number of other boards already did. A progress indicator may be a nice little toy, but how does it integrate into the POST framework? > target is 2GB at a time, up to physically memory size which is easily > over 8GB. Without progress indicator, it feels hung when it is actually > running. Yes, memory testing takes time. In the context of a power-on self test (and this is what you are doing, right?) we should take care to fit it into the existing framework, though. > Please take a look at the patch below. Instead of integrating your needs into an existing framework you invent yet another one. I don't want to have this, sorry. 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 can you tell when sour cream goes bad? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] powerpc/85xx: Add memory test feature for mpc85xx.
Wolfgang,
On Thu, 2010-07-15 at 11:07 +0200, Wolfgang Denk wrote:
> Dear Timur Tabi,
>
> In message you
> wrote:
> >
> > > NAK.
> > >
> > > Please do not reinvent the wheel and add yet another meory test. Use
> > > one of the existing memory tests we already have -
> > > post/drivers/memory.c comes to mind.
> >
> > That code is not capable of testing more than 2GB of RAM. It assumes
> > that memory has already been initialized, but on PowerPC parts, we
> > only ever map 2GB of DDR. We need a memory test that covers all of
> > DDR, but that requries PowerPC-specific code to create sliding TLB
> > windows during the memory test.
>
> Then please extend the existing code and add the missing features.
>
> We already have too many different implementations of a memory test in
> U-Boot, and I will not accept adding yet another one.
>
I can reuse your testing code but have to move the desired code out of
memory.c file to avoid the need for CONFIG_POST and
CONFIG_SYS_POST_MEMORY. I also add a progress indicator. My testing
target is 2GB at a time, up to physically memory size which is easily
over 8GB. Without progress indicator, it feels hung when it is actually
running.
Please take a look at the patch below.
Regards,
York
>From 58002b8f549ca114583b72f541032fb106b6bf66 Mon Sep 17 00:00:00 2001
From: York Sun
Date: Wed, 23 Jun 2010 11:18:48 -0500
Subject: [PATCH] Add memory test feature for mpc85xx.
Reuse memory test code for POST. Move the actually pattern generator
and testing out of POST.
If enabled in config file and hwconfig, the memory test is performed
after DDR initialization when U-boot stills runs in flash and cache.
Whole memory is testable. However, only the low 2GB space is mapped
for DDR. The testing is conducted in the 2GB window and uses TLBs to
map the higher physical address into the 2GB window if the total
memory is more than 2GB. After the testing, DDR is remapped with up
to 2GB memory from the lowest address.
If memory test fails, DDR DIMM SPD and DDR controller registers are
dumped. All zero values are omitted for better viewing.
A worker function __setup_ddr_tlbs() is introduced to implemente more
control on physical address mapping.
Signed-off-by: York Sun
---
This patch is for discussion where to put the memory test code.
arch/powerpc/cpu/mpc85xx/Makefile|2 +
arch/powerpc/cpu/mpc85xx/memtest.c | 220 +
arch/powerpc/cpu/mpc85xx/tlb.c | 16 +-
doc/README.fsl-ddr | 13 +-
post/drivers/Makefile|2 +-
post/drivers/memory.c| 426 +-
post/drivers/{memory.c => memtest_pattern.c} | 147 ++---
7 files changed, 346 insertions(+), 480 deletions(-)
create mode 100644 arch/powerpc/cpu/mpc85xx/memtest.c
copy post/drivers/{memory.c => memtest_pattern.c} (79%)
diff --git a/arch/powerpc/cpu/mpc85xx/Makefile
b/arch/powerpc/cpu/mpc85xx/Makefile
index 2c12ef2..383de6a 100644
--- a/arch/powerpc/cpu/mpc85xx/Makefile
+++ b/arch/powerpc/cpu/mpc85xx/Makefile
@@ -62,6 +62,8 @@ COBJS-$(CONFIG_PPC_P3041) += ddr-gen3.o
COBJS-$(CONFIG_PPC_P4080) += ddr-gen3.o
COBJS-$(CONFIG_PPC_P5020) += ddr-gen3.o
+COBJS-${CONFIG_SYS_DRAM_TEST} += memtest.o
$(TOPDIR)/post/drivers/memtest_pattern.o
+
COBJS-$(CONFIG_CPM2) += ether_fcc.o
COBJS-$(CONFIG_OF_LIBFDT) += fdt.o
COBJS-$(CONFIG_FSL_CORENET) += liodn.o liodn_r1.o
diff --git a/arch/powerpc/cpu/mpc85xx/memtest.c
b/arch/powerpc/cpu/mpc85xx/memtest.c
new file mode 100644
index 000..b873136
--- /dev/null
+++ b/arch/powerpc/cpu/mpc85xx/memtest.c
@@ -0,0 +1,220 @@
+/*
+ * Copyright (C) 2010 Freescale Semiconductor, Inc.
+ * York Sun
+ *
+ * See file CREDITS for list of people who contributed to this
+ * project.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of
+ * the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
+ * MA 02111-1307 USA
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+DECLARE_GLOBAL_DATA_PTR;
+
+/* Board-specific functions defined in each board's ddr.c */
+void fsl_ddr_get_spd(generic_spd_eeprom_t *ctrl_dimms_spd,
+ unsigned int ctrl_num);
+void read_tlbcam_entry(int idx, u32 *valid, u32 *tsize, unsigned long *epn,
+ phys_addr_t *rpn);
+unsigned int __setup_ddr_tlbs(phys_addr_t p_addr, unsigned int memsize
Re: [U-Boot] [PATCH 5/5] New implementation for internal handling of environment variables.
Dear Matthias Fuchs,
In message <201007261652.39368.matthias.fu...@esd-electronics.com> you wrote:
>
> I could think of some situations where the new env command
> is helpful. But more during development than for production systems.
It depends. "Reset to factory defaults" is a not so uncommon request.
And acceleration of scripts is not so uncommon either.
> Switching between environment profiles would be cool. And a "env default -f"
> behavior that keeps MAC addresses and serial# is also on my wishlist.
Actually neither MAC addresses nor serial# are part of the default
environment.
> I did some testing on our PMC440 with environment in EEPROM.
> Please see some comments below.
Thanks.
> > +static int do_env_export(cmd_tbl_t *cmdtp, int flag, int argc, char *
> > const argv[])
> > +{
> > + charbuf[32];
> > + char*addr, *cmd, *res;
> > + size_t size;
> > + ssize_t len;
> > + env_t *envp = (env_t *)addr;
> addr is uninitialized. declaration is enough here.
Will check this.
...
> > + if (chk) { /* export as checksum protected block */
> Add:
> envp = (env_t *)addr;
> > + res = (char *)&envp->data;
> > + } else {/* export as raw binary data */
> > + res = (char *)&addr;
> Should'n this be
> res = addr;
No. We need the address of the pointer variable, so the function can
store the result pointer there.
...
> Fixes for non-building board (AR405, CANBT, PMC440) will come up shortly.
Thanks a lot.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for Winbond W25Q64 SPI flash
On Wednesday, July 28, 2010 13:23:34 Paulraj, Sandeep wrote: > The patch will need your signed-off-by > > And a patch description once you fix those issues, patch looks fine and should be OK for merging. i'll pick it up if Wolfgang doesnt, but it should be OK to merge for this release. -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
[U-Boot] Please pull u-boot-ti/master
Wolfgang, Please pull u-boot-ti/master. I ran MAKEALL and saw no issues. The patch modifying the I2c driver has an ACK from Heiko. The patch restructuring the USB driver actually was a simple patch adding some more #defines so i went ahead and added it. Thanks, Sandeep The following changes since commit e9aecdec153ae166739858e6a570432449b979f7: Wolfgang Denk (1): Merge branch 'master' of git://git.denx.de/u-boot-ti are available in the git repository at: git://git.denx.de/u-boot-ti.git master Steve Sakoman (8): ARMV7: Add pad mux support for OMAP4 ARMV7: Fix udelay for OMAP4 ARMV7: Modify i2c driver for more reliable operation on OMAP4 ARMV7: Add support for the TWL6030 I2C power chip used in OMAP4 systems ARMV7: Restructure omap3 musb driver to allow code sharing between OMAP3 and OMAP4 ARMV7: Enable musb driver and usbtty on OMAP4430 SDP ARMV7: Enable musb driver and usbtty on OMAP4 Panda ARMV7: Update default environment for OMAP4 boards arch/arm/cpu/armv7/omap-common/timer.c |9 - arch/arm/cpu/armv7/omap4/board.c| 11 + arch/arm/include/asm/arch-omap3/cpu.h |3 + arch/arm/include/asm/arch-omap3/i2c.h |4 +- arch/arm/include/asm/arch-omap4/cpu.h |3 + arch/arm/include/asm/arch-omap4/mux_omap4.h | 344 +++ arch/arm/include/asm/arch-omap4/omap4.h |2 + arch/arm/include/asm/arch-omap4/sys_proto.h |1 + board/ti/panda/panda.c | 26 ++ board/ti/panda/panda.h | 265 + board/ti/sdp4430/sdp.c | 26 ++ board/ti/sdp4430/sdp.h | 265 + drivers/i2c/omap24xx_i2c.c | 31 ++- drivers/i2c/omap24xx_i2c.h |4 + drivers/power/Makefile |1 + drivers/power/twl6030.c | 77 ++ drivers/usb/musb/omap3.c| 16 ++ drivers/usb/musb/omap3.h|3 +- include/configs/omap4_panda.h | 26 ++- include/configs/omap4_sdp4430.h | 26 ++- include/twl6030.h | 90 +++ 21 files changed, 1208 insertions(+), 25 deletions(-) create mode 100644 arch/arm/include/asm/arch-omap4/mux_omap4.h create mode 100644 board/ti/panda/panda.h create mode 100644 board/ti/sdp4430/sdp.h create mode 100644 drivers/power/twl6030.c create mode 100644 include/twl6030.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Add support for Winbond W25Q64 SPI flash
The patch will need your signed-off-by
And a patch description
> ---
> drivers/mtd/spi/winbond.c |9 +
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
> index ff1df25..de3aeb8 100644
> --- a/drivers/mtd/spi/winbond.c
> +++ b/drivers/mtd/spi/winbond.c
> @@ -27,6 +27,7 @@
> #define WINBOND_ID_W25X160x3015
> #define WINBOND_ID_W25X320x3016
> #define WINBOND_ID_W25X640x3017
> +#define WINBOND_ID_W25Q640x4017
>
> #define WINBOND_SR_WIP (1 << 0)/* Write-in-Progress */
>
> @@ -77,6 +78,14 @@ static const struct winbond_spi_flash_params
> winbond_spi_flash_table[] = {
> .nr_blocks = 128,
> .name = "W25X64",
> },
> + {
> + .id = WINBOND_ID_W25Q64,
> + .l2_page_size = 8,
> + .pages_per_sector = 16,
> + .sectors_per_block = 16,
> + .nr_blocks = 128,
> + .name = "W25Q64",
> + },
> };
>
> static int winbond_wait_ready(struct spi_flash *flash, unsigned long
> timeout)
> --
> 1.6.3.3
>
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Add support for Winbond W25Q64 SPI flash
---
drivers/mtd/spi/winbond.c |9 +
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/spi/winbond.c b/drivers/mtd/spi/winbond.c
index ff1df25..de3aeb8 100644
--- a/drivers/mtd/spi/winbond.c
+++ b/drivers/mtd/spi/winbond.c
@@ -27,6 +27,7 @@
#define WINBOND_ID_W25X16 0x3015
#define WINBOND_ID_W25X32 0x3016
#define WINBOND_ID_W25X64 0x3017
+#define WINBOND_ID_W25Q64 0x4017
#define WINBOND_SR_WIP (1 << 0)/* Write-in-Progress */
@@ -77,6 +78,14 @@ static const struct winbond_spi_flash_params
winbond_spi_flash_table[] = {
.nr_blocks = 128,
.name = "W25X64",
},
+ {
+ .id = WINBOND_ID_W25Q64,
+ .l2_page_size = 8,
+ .pages_per_sector = 16,
+ .sectors_per_block = 16,
+ .nr_blocks = 128,
+ .name = "W25Q64",
+ },
};
static int winbond_wait_ready(struct spi_flash *flash, unsigned long timeout)
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Add support for Winbond W25Q64 SPI flash
This patch adds support for Winbond W25Q64 SPI flash. It's tested on a custom Spartan-6 board, and used on Xilinx' SP601 evaluation board. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] spi utility command support
On Wednesday, July 28, 2010 10:01:44 shashikiran.bevenka...@wipro.com wrote: >What all the steps to enable spi utility command in u-boot for > MPC8569MDS board?. SPI-Flash (M25P40) is connected to MPC8569MDS processor > over SPI interface. you already asked this and i gave you the direction to look -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] spi utility command support
On Wed 28 Jul 2010 10:01, shashikiran.bevenka...@wipro.com pondered: [snip] > The information contained in this electronic message and any attachments > to this message are intended for the exclusive use of the addressee(s) > and may contain proprietary, confidential or privileged information. If > you are not the intended recipient, you should not disseminate, distribute > or copy this e-mail. Please notify the sender immediately and destroy all > copies of this message and any attachments. Such disclaimers are inappropriate for mail sent to public lists. If your company automatically adds something like this to outgoing mail, and you can't convince them to stop, you might consider using a free web-based e-mail account. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] spi utility command support
Hi, What all the steps to enable spi utility command in u-boot for MPC8569MDS board?. SPI-Flash (M25P40) is connected to MPC8569MDS processor over SPI interface. Thanks & Regards, Shashikiran. Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Fwd: FW: [PATCH 1/2] ARMV7: Versatile Express Coretile quad-core Cortex-A9 support
-- Forwarded message -- From: Peter Pearse Date: Wed, Jul 28, 2010 at 9:12 AM Subject: Re: FW: [U-Boot] [PATCH 1/2] ARMV7: Versatile Express Coretile quad-core Cortex-A9 support To: Peter Pearse Tom The ARM Boot Monitor, supplied with all Versatile Express boards, places the spare cores into WFI and this is what the current kernel code [ arch/arm/mach-vexpress/platsmp.c::boot_secondary() ] expects. If it runs after the ARM Boot Monitor, u-boot need not touch the spare cores. If u-boot is to be run stand alone, without the ARM Boot Monitor, then it needs to initialize the boards GICs otherwise the wakeup interrupts issued during kernel boot will not reach the cores in WFI. Should you wish to put the cores into WFE, rather than WFI the kernel will need patching to issue the necessary event(s). I believe there is some reason that WFE is deprecated for this use - I'll check further Regards Peter On Wed, Jul 28, 2010 at 9:01 AM, Peter Pearse wrote: > > > > > *From:* u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] > *On Behalf Of *Matt Waddel > *Sent:* 28 July 2010 00:39 > *To:* u-boot@lists.denx.de > *Subject:* [U-Boot] [PATCH 1/2] ARMV7: Versatile Express Coretile > quad-core Cortex-A9 support > > > > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC8536DS SD u-boot issue
Dear all, I have an issue with u-boot 2010.06 for mpc8536ds and SD card. (actually not sure if it is specific for 2010.06). If I try to access the SD card (a SanDisk 2GB cl2 card), from within u-boot I often get errors. The odd thing is that the errors are not always at the same place. Below is a log. As you can see from the log reading the first blocks works nicely, but at arund block 64 things become fuzzy. The last few tests show that sometimes it does manage to read a block whereas the next try it might not read that block (or the other way around) => mmc read 0 10 0 100 MMC read: dev # 0, block # 0, count 256 ... block read failed: -18 64 blocks read: ERROR => mmc read 0 10 0 5 MMC read: dev # 0, block # 0, count 5 ... 5 blocks read: OK => mmc read 0 10 0 10 MMC read: dev # 0, block # 0, count 16 ... 16 blocks read: OK => mmc read 0 10 0 100 MMC read: dev # 0, block # 0, count 256 ... block read failed: -18 65 blocks read: ERROR => mmc read 0 10 63 10 MMC read: dev # 0, block # 99, count 16 ... block read failed: -18 1 blocks read: ERROR => mmc read 0 10 63 10 MMC read: dev # 0, block # 99, count 16 ... block read failed: -18 4 blocks read: ERROR => mmc read 0 10 63 10 MMC read: dev # 0, block # 99, count 16 ... block read failed: -18 2 blocks read: ERROR => mmc read 0 10 63 10 MMC read: dev # 0, block # 99, count 16 ... block read failed: -18 5 blocks read: ERROR => mmc read 0 10 63 10 MMC read: dev # 0, block # 99, count 16 ... block read failed: -18 3 blocks read: ERROR The strange thing is that the card under linux works like a charm: r...@unknown:~# dd if=/dev/mmcblk0 of=/dev/null count=200 200+0 records in 200+0 records out 102400 bytes (102 kB) copied, 0.0231558 s, 4.4 MB/s r...@unknown:~# dd if=/dev/mmcblk0 of=/dev/null count=200 200+0 records in 200+0 records out 102400 bytes (102 kB) copied, 0.0234544 s, 4.4 MB/s r...@unknown:~# dd if=/dev/mmcblk0 of=/dev/null count=200 200+0 records in 200+0 records out 102400 bytes (102 kB) copied, 0.0233649 s, 4.4 MB/s r...@unknown:~# dd if=/dev/mmcblk0 of=/dev/null count=200 200+0 records in 200+0 records out 102400 bytes (102 kB) copied, 0.0232536 s, 4.4 MB/s r...@unknown:~# dd if=/dev/mmcblk0 of=/dev/null count=1000 1000+0 records in 1000+0 records out 512000 bytes (512 kB) copied, 0.0713617 s, 7.2 MB/s r...@unknown:~# dd if=/dev/mmcblk0 of=/dev/null bs=1M 1938+1 records in 1938+1 records out 2032664576 bytes (2.0 GB) copied, 184.323 s, 11.0 MB/s This is from a fresh boot. It might be the 2nd and further tests get data from the buffer cache but initially the data is read from the card Anyone a suggestion? I really would like to be able to load my kernel off the card. Or is there a different type/brand of card that is better suited? Best regards, Frans. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
