[U-Boot] Pull request: u-boot-i2c
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(-) 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] ARM: use the same branch insn on all architectures
Hello Wolfgang, Wolfgang Denk 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(-) Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] ARM: Use consistent assembler syntax
Hello Gray, Gray Remlin 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. Tested on the beagle board Acked-by: Heiko Schocher h...@denx.de bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm1176: fix relocation
Hello Darius, Darius Augulis 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 --- arch/arm/cpu/arm1176/start.S| 139 +++ arch/arm/cpu/arm1176/u-boot.lds | 15 +++- 2 files changed, 94 insertions(+), 60 deletions(-) Thanks, some comments below: diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index 24e5bf4..0d733f7 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S [...] @@ -288,24 +295,44 @@ copy_loop: blo copy_loop #ifndef CONFIG_PRELOADER - /* fix got entries */ - ldr r1, _TEXT_BASE /* Text base */ - mov r0, r7 /* reloc addr */ - ldr r2, _got_start /* addr in Flash */ - ldr r3, _got_end/* addr in Flash */ - sub r3, r3, r1 - add r3, r3, r0 - sub r2, r2, r1 - add r2, r2, r0 - + /* + * fix .rel.dyn relocations + */ + ldr r0, _TEXT_BASE /* r0 - Text base */ + sub r9, r7, r0 /* r9 - relocation offset */ + ldr r10, _dynsym_start_ofs /* r10 - sym table ofs */ + add r10, r10, r0/* r10 - sym table in FLASH */ + ldr r2, _rel_dyn_start_ofs /* r2 - rel dyn start ofs */ + add r2, r2, r0 /* r2 - rel dyn start in FLASH */ + ldr r3, _rel_dyn_end_ofs/* r3 - rel dyn end ofs */ + add r3, r3, r0 /* r3 - rel dyn end in FLASH */ fixloop: - ldr r4, [r2] - sub r4, r4, r1 - add r4, r4, r0 - str r4, [r2] - add r2, r2, #4 + ldr r0, [r2]/* r0 - location to fix up, IN FLASH! */ + add r0, r9 /* r0 - location to fix up in RAM */ should be add r0, r0, r9 + ldr r1, [r2, #4] + and r8, r1, #0xff + cmp r8, #23 /* relative fixup? */ + beq fixrel + cmp r8, #2 /* absolute fixup? */ + beq fixabs + /* ignore unknown type of fixup */ + b fixnext +fixabs: + /* absolute fix: set location to (offset) symbol value */ + mov r1, r1, LSR #4 /* r1 - symbol index in .dynsym */ + add r1, r10, r1 /* r1 - address of symbol in table */ + ldr r1, [r1, #4]/* r1 - symbol value */ + add r1, r9 /* r1 - relocated sym addr */ should be add r1, r1, r9 + b fixnext +fixrel: + /* relative fix: increase location by offset */ + ldr r1, [r0] + add r1, r1, r9 +fixnext: + str r1, [r0] + add r2, r2, #8 /* each rel.dyn entry is 8 bytes */ cmp r2, r3 - bne fixloop + ble fixloop should be blo instead of blo #endif #endif /* #ifndef CONFIG_SKIP_RELOCATE_UBOOT */ [...] bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] arm, bootm: Fix compile warning
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(-)
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 2e7b2e1..a1649ee 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -177,8 +177,6 @@ static int fixup_memory_node(void *blob)
static int bootm_linux_fdt(int machid, bootm_headers_t *images)
{
ulong rd_len;
- bd_t *bd = gd-bd;
- char *s;
void (*kernel_entry)(int zero, int dt_machid, void *dtblob);
ulong bootmap_base = getenv_bootm_low();
ulong of_size = images-ft_len;
--
1.7.2.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NetConsole and network API
Hi: On Viernes, 22 de Octubre de 2010 22:14:45 Joe Hershberger escribió: On Fri, Oct 22, 2010 at 2:23 AM, RaúlSánchez Siles rsanch...@infoglobal.es wrote: Hello Joe: I've also bumped into this issue and I'm not familiar enough with U-Boot to properly think of a solution fixing the issue. However, I share the analisys Stefano did. In my case I use a davinci DM355 custom board, very similar to the EVM. You offered to send a patch some time ago, is there any chance we could see it? I offer to test it. Alternatively, I'm interested in hearing your approach to the solution so maybe I can get a slot to make up a patch from it. Hi Raul, I apologize for not getting to this. As usual, deadline pressure pushes this kind of thing out. I don't have the time to create the patch for the git head and submit it officially at this time, however I can give you the patch against u-boot-2009.11. I'll get to officially submitting it at some point, but for now this is the best I can do for you. Apply this patch to u-boot 2009.11 and then #define CONFIG_NETCONSOLE_PERSIST_ETH in your board config header. I use this on an MPC8313 with the TSEC Ethernet driver and it greatly increases the speed and reliability of the NetConsole. All other protocols such as TFTP still work the same as before. Hopefully this helps. Best regards, -Joe Great! Thank you. I'll address this as soon as I have some time, hopefully among this 2 weeks. Regards -- Raúl Sánchez Siles Departamento de Montaje INFOGLOBAL, S. A. * C/ Virgilio, 2. Ciudad de la Imagen. 28223 Pozuelo de Alarcón (Madrid), España * T: +34 91 506 40 00 * F: +34 91 506 40 01 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arm1176: fix relocation
Hello Darius, Darius Augulis wrote: On 10/24/2010 11:08 PM, Darius Augulis 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 Augulisaugulis.dar...@gmail.com --- arch/arm/cpu/arm1176/start.S| 139 +++ arch/arm/cpu/arm1176/u-boot.lds | 15 +++- 2 files changed, 94 insertions(+), 60 deletions(-) diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index 24e5bf4..0d733f7 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S [...] @@ -377,10 +402,9 @@ clbss_l:str r2, [r0]/* clear loop...*/ _nand_boot: .word nand_boot #else -ldr r0, _TEXT_BASE -ldr r2, _board_init_r -sub r2, r2, r0 -add r2, r2, r7 /* position from board_init_r in RAM */ +ldr r0, _board_init_r_ofs +adr r1, _start +add r2, r0, r1 RFC: I've observed that other ARM CPU's are adding r9 to lr here (add lr, r0, r9). Even though r9 is not pre-loaded with any value in case CONFIG_SKIP_RELOCATE_UBOOT is defined. Is it bug or not? Maybe it's not tested without CONFIG_SKIP_RELOCATE_UBOOT? I've removed this line because uboot stops booting if it's there. Any comments about it? Yep, thats a Bug, thanks for detecting this. But your fix seems to me, is not working for the case if CONFIG_SKIP_RELOCATE_UBOOT is !defined, because then you need this update of the lr register ... so could you please add this line with a #if !defined(CONFIG_SKIP_RELOCATE_UBOOT) ... #endif around it? (And maybe fix all other arm start.S files too?) 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] arm1176: fix relocation
Hello Heiko, thanks for reviewing. ok, I will make patch to fix this bug in all arm*/start.S. Darius. On Mon, Oct 25, 2010 at 10:11 AM, Heiko Schocher h...@denx.de wrote: Hello Darius, Darius Augulis wrote: On 10/24/2010 11:08 PM, Darius Augulis 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 Augulisaugulis.dar...@gmail.com --- arch/arm/cpu/arm1176/start.S | 139 +++ arch/arm/cpu/arm1176/u-boot.lds | 15 +++- 2 files changed, 94 insertions(+), 60 deletions(-) diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index 24e5bf4..0d733f7 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S [...] @@ -377,10 +402,9 @@ clbss_l:str r2, [r0] /* clear loop... */ _nand_boot: .word nand_boot #else - ldr r0, _TEXT_BASE - ldr r2, _board_init_r - sub r2, r2, r0 - add r2, r2, r7 /* position from board_init_r in RAM */ + ldr r0, _board_init_r_ofs + adr r1, _start + add r2, r0, r1 RFC: I've observed that other ARM CPU's are adding r9 to lr here (add lr, r0, r9). Even though r9 is not pre-loaded with any value in case CONFIG_SKIP_RELOCATE_UBOOT is defined. Is it bug or not? Maybe it's not tested without CONFIG_SKIP_RELOCATE_UBOOT? I've removed this line because uboot stops booting if it's there. Any comments about it? Yep, thats a Bug, thanks for detecting this. But your fix seems to me, is not working for the case if CONFIG_SKIP_RELOCATE_UBOOT is !defined, because then you need this update of the lr register ... so could you please add this line with a #if !defined(CONFIG_SKIP_RELOCATE_UBOOT) ... #endif around it? (And maybe fix all other arm start.S files too?) 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] mmc: set tran_speed intead of hard setting
Dear Wolfgang Denk,
On 25 October 2010 13:19, Jaehoon Chung jh80.ch...@samsung.com wrote:
This patch use card's tran_speed instead of hard setting value.
I think mmc_set_clock(mmc, 5200) is not good idea.
because this is hard setting. we need use card's tran_speed.
So If card_caps did't support High speed, we need set card's speed value
Signed-off-by: Jaehoon Chung jh80.ch...@samsung.com
Signed-off-by: Minkyu Kang mk7.k...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
drivers/mmc/mmc.c | 9 +
1 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/mmc/mmc.c b/drivers/mmc/mmc.c
index c543d83..f1b5552 100644
--- a/drivers/mmc/mmc.c
+++ b/drivers/mmc/mmc.c
@@ -815,11 +815,12 @@ int mmc_startup(struct mmc *mmc)
if (mmc-card_caps MMC_MODE_HS) {
if (mmc-card_caps MMC_MODE_HS_52MHz)
- mmc_set_clock(mmc, 5200);
+ mmc-tran_speed = 5200;
else
- mmc_set_clock(mmc, 2600);
- } else
- mmc_set_clock(mmc, 2000);
+ mmc-tran_speed = 2600;
+ }
+
+ mmc_set_clock(mmc, mmc-tran_speed);
}
/* fill in device description */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
This patch has already been reviewed by Andy.
http://lists.denx.de/pipermail/u-boot/2010-May/071213.html
Thanks
Minkyu Kang
--
from. prom.
www.promsoft.net
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs
Jocke, [snip] You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it. of course. Will give it a try as soon as I'll be back to office and have a board at hand ... Just wanted to collect some more feedback. Cheers, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] [NEXT] da830: fixup ARM relocation support
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/84921 There have been no further comments since I posted v3 of this patch 4 weeks ago. It still applies cleanly to my newly updated tree of u-boot. da830evm will not build without it. Can this patch be commited? Thanks, Nick. On 23/09/10 10:32, Nick Thompson wrote: Fixes build breakage in da830evm after commit 97003756249bd790910417eb66f0039bbf06a02c da8xx: fixup ARM relocation support The da8xx fixup commit changed da830/da850 common code to make relocation work in da850, but didn't add the required defines to da830evm_config.h resulting in build failure in the common code. This patch adds those defines for da830, but makes no sense without also referring to the commit mentioned above. Signed-off-by: Nick Thompson nick.thomp...@ge.com Reviewed-by: Ben Gardiner bengardi...@nanometrics.ca --- Changes since v1: removed CONFIG_SKIP_RELOCATE_UBOOT Changes since v2: removed #undef CONFIG_SYS_ARM_WITHOUT_RELOC as it is not defined in the first place. include/configs/da830evm.h | 11 --- 1 files changed, 8 insertions(+), 3 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v3] [NEXT] da830: fixup ARM relocation support
Dear Nick Thompson, In message 4cc53f29.2050...@ge.com you wrote: http://article.gmane.org/gmane.comp.boot-loaders.u-boot/84921 There have been no further comments since I posted v3 of this patch 4 weeks ago. It still applies cleanly to my newly updated tree of u-boot. da830evm will not build without it. I am aware of this. IIRC there are other TI specific patches pending, too. Can this patch be commited? I'm waiting for Sandeep's pull request. 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 when they say 2 + 2 = 5 that I begin to argue.- Eric Pepke ___ 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, 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? 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. 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. 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
[U-Boot] [PATCH v3 2/2] Freescale 85xx/P1/P2 eSPI controller driver
From: Can Aydin can.ay...@locatacorp.com 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] [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
Re: [U-Boot] [PATCH] ARMV7: Fix build for non-OMAP3 boards
-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? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] imx31 USB OTG support?
Hello, Is there any support in uboot for USB OTG of imx31? I am trying to configure USB OTG in device mode for imx31. Any one worked on it or any ideas. Any help will be appreciated. Thanks -- Abbas Raza ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NAND support on AVR32
If you've seen this before, my apologies - this is my 3rd attempt to post this - it doesn't appear in anything I've downloaded, so I assume it's not getting posted. -- I thought the whole point of using this linux and u-boot stuff was that whatever you did, someone else had done it first and you just had to copy them. Well I've been caught out :-) I want to ditch using the uSD card at all on our AVR32 board , and use NAND where we have been using uSD. I have a Linux JFFS2 disk working out of NAND - quite easy as Linux pretty much knew how, once you told it you had a chip. But the u-boot seems to have no clue about NAND on the AVR32 - it doesn't set up the hardware to get to it at all, and there's no code set up in the target board header and code files for any AVR32-based board, as far as I can see!!! I did pull the latest files, but I couldn't spot any relevant additions. I have found some stuff in support for other Atmel devices, which seems relevant. I'm totally in the dark about what u-boot can or should do with ecc . So far I've worked out that I've got to 1. in cpu.c add set up MODE3, CYCLE3, SETUP3, PULSE3 registers for cs3 timing. 2. in target.c/board_early_init_f add hmatrix_slave_write call to enable nand in ebi 3. in target.c/board_early_init_f set up chip select(s) and busy(s) in the GPIO setup to point the right way, and initially turn everything off 4 in target.h #undef CONFIG_NAND_LEGACY #define CONFIG_CMD_NAND #define CONFIG_JFFS2_NAND #define CFG_MAX_NAND_DEVICE #define NAND_MAX_CHIPS #define CFG_NAND_BASE 0x0c00 I'm still pretty woolly about these though CONFIG_MTD_NAND_VERIFY_WRITE CONFIG_MTD_PARTITIONS And I may have missed other compulsory settings 5. create a file called nand.c in the same directory as my target.c - I've based mine on the one for the at91sam9261ek. This needs to implement board_nand_init which must set up service routines cmd_ctrl to alter ALE,CLE etc dev_ready to read the chip ready status chip_delay - no idea! I note that there are a couple of other entries in the nand_chip that are marked BOARDSPECIFIC which I don't set up myself... but I can't see anyone else doing it either! So far I've no clue how the nand.c file gets included in the make of u-boot - is it automatic, or do I need to edit a makefile? ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: fix address setup in start.S
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(-) diff --git a/arch/arm/cpu/arm1136/start.S b/arch/arm/cpu/arm1136/start.S index 29ed065..6a82310 100644 --- a/arch/arm/cpu/arm1136/start.S +++ b/arch/arm/cpu/arm1136/start.S @@ -296,8 +296,10 @@ _nand_boot_ofs jump_2_ram: ldr r0, _board_init_r_ofs adr r1, _start - add r0, r0, r1 - add lr, r0, r9 + add lr, r0, r1 +#ifndef CONFIG_SKIP_RELOCATE_UBOOT + add lr, lr, r9 +#endif /* setup parameters for board_init_r */ mov r0, r5 /* gd_t */ mov r1, r7 /* dest_addr */ diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 863de3b..e7e985a 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -286,8 +286,10 @@ _nand_boot_ofs: #else ldr r0, _board_init_r_ofs adr r1, _start - add r0, r0, r1 - add lr, r0, r9 + add lr, r0, r1 +#ifndef CONFIG_SKIP_RELOCATE_UBOOT + add lr, lr, r9 +#endif /* setup parameters for board_init_r */ mov r0, r5 /* gd_t */ mov r1, r7 /* dest_addr */ diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S index 64c86e9..91e0523 100644 --- a/arch/arm/cpu/armv7/start.S +++ b/arch/arm/cpu/armv7/start.S @@ -274,8 +274,10 @@ clbss_l:strr2, [r0]/* clear loop...*/ jump_2_ram: ldr r0, _board_init_r_ofs adr r1, _start - add r0, r0, r1 - add lr, r0, r9 + add lr, r0, r1 +#ifndef CONFIG_SKIP_RELOCATE_UBOOT + add lr, lr, r9 +#endif /* setup parameters for board_init_r */ mov r0, r5 /* gd_t */ mov r1, r7 /* dest_addr */ diff --git a/arch/arm/cpu/pxa/start.S b/arch/arm/cpu/pxa/start.S index 3c5bd84..73166c8 100644 --- a/arch/arm/cpu/pxa/start.S +++ b/arch/arm/cpu/pxa/start.S @@ -330,8 +330,10 @@ _start_oneboot_ofs #else ldr r0, _board_init_r_ofs adr r1, _start - add r0, r0, r1 - add lr, r0, r9 + add lr, r0, r1 +#ifndef CONFIG_SKIP_RELOCATE_UBOOT + add lr, lr, r9 +#endif /* setup parameters for board_init_r */ mov r0, r5 /* gd_t */ mov r1, r7 /* dest_addr */ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] arm1176: fix relocation
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(-) diff --git a/arch/arm/cpu/arm1176/start.S b/arch/arm/cpu/arm1176/start.S index 24e5bf4..afdc77b 100644 --- a/arch/arm/cpu/arm1176/start.S +++ b/arch/arm/cpu/arm1176/start.S @@ -115,44 +115,52 @@ _armboot_start: /* * These are defined in the board-specific linker script. + * Subtracting _start from them lets the linker put their + * relative position in the executable instead of leaving + * them null. */ -.globl _bss_start -_bss_start: - .word __bss_start -.globl _bss_end -_bss_end: - .word _end +.globl _bss_start_ofs +_bss_start_ofs: + .word __bss_start - _start -#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) -/* IRQ stack memory (calculated at run-time) + 8 bytes */ -.globl IRQ_STACK_START_IN -IRQ_STACK_START_IN: - .word 0x0badc0de +.globl _bss_end_ofs +_bss_end_ofs: + .word _end - _start -.globl _datarel_start -_datarel_start: - .word __datarel_start +.globl _datarel_start_ofs +_datarel_start_ofs: + .word __datarel_start - _start -.globl _datarelrolocal_start -_datarelrolocal_start: - .word __datarelrolocal_start +.globl _datarelrolocal_start_ofs +_datarelrolocal_start_ofs: + .word __datarelrolocal_start - _start -.globl _datarellocal_start -_datarellocal_start: - .word __datarellocal_start +.globl _datarellocal_start_ofs +_datarellocal_start_ofs: + .word __datarellocal_start - _start -.globl _datarelro_start -_datarelro_start: - .word __datarelro_start +.globl _datarelro_start_ofs +_datarelro_start_ofs: + .word __datarelro_start - _start -.globl _got_start -_got_start: - .word __got_start +.globl _rel_dyn_start_ofs +_rel_dyn_start_ofs: + .word __rel_dyn_start - _start -.globl _got_end -_got_end: - .word __got_end +.globl _rel_dyn_end_ofs +_rel_dyn_end_ofs: + .word __rel_dyn_end - _start + +.globl _dynsym_start_ofs +_dynsym_start_ofs: + .word __dynsym_start - _start + +#if !defined(CONFIG_SYS_ARM_WITHOUT_RELOC) +/* IRQ stack memory (calculated at run-time) + 8 bytes */ +.globl IRQ_STACK_START_IN +IRQ_STACK_START_IN: + .word 0x0badc0de /* * the actual reset code @@ -274,9 +282,8 @@ stack_setup: adr r0, _start ldr r2, _TEXT_BASE - ldr r3, _bss_start - sub r2, r3, r2 /* r2 - size of armboot*/ - add r2, r0, r2 /* r2 - source end address */ + ldr r3, _bss_start_ofs + add r2, r0, r3 /* r2 - source end address */ cmp r0, r6 beq clear_bss @@ -288,24 +295,44 @@ copy_loop: blo copy_loop #ifndef CONFIG_PRELOADER - /* fix got entries */ - ldr r1, _TEXT_BASE /* Text base */ - mov r0, r7 /* reloc addr */ - ldr r2, _got_start /* addr in Flash */ - ldr r3, _got_end/* addr in Flash */ - sub r3, r3, r1 - add r3, r3, r0 - sub r2, r2, r1 - add r2, r2, r0 - + /* +* fix .rel.dyn relocations +*/ + ldr r0, _TEXT_BASE /* r0 - Text base */ + sub r9, r7, r0 /* r9 - relocation offset */ + ldr r10, _dynsym_start_ofs /* r10 - sym table ofs */ + add r10, r10, r0/* r10 - sym table in FLASH */ + ldr r2, _rel_dyn_start_ofs /* r2 - rel dyn start ofs */ + add r2, r2, r0 /* r2 - rel dyn start in FLASH */ + ldr r3, _rel_dyn_end_ofs/* r3 - rel dyn end ofs */ + add r3, r3, r0 /* r3 - rel dyn end in FLASH */ fixloop: - ldr r4, [r2] - sub r4, r4, r1 - add r4, r4, r0 - str r4, [r2] - add r2, r2, #4 + ldr r0, [r2]/* r0 - location to fix up, IN FLASH! */ + add r0, r0, r9 /* r0 - location to fix up in RAM */ + ldr r1, [r2, #4] + and r8, r1, #0xff + cmp r8, #23 /* relative fixup? */ + beq fixrel + cmp r8, #2 /* absolute fixup? */ + beq fixabs + /* ignore unknown type of fixup */ + b fixnext +fixabs: + /* absolute fix: set location to (offset) symbol value */ + mov r1, r1, LSR #4 /* r1 - symbol index in .dynsym */ + add r1, r10, r1 /* r1 - address of symbol in table */ + ldr r1, [r1, #4]/*
[U-Boot] SPI on PPC MPC85xx
Hi all, I've been trying to setup SPI on our MPC85xx based board. Unfortunately, compilation of mpc8xxx_spi.c fails due to a missing immap_t datatype. I see, that this datatype is defined in the headers immap_83xx.h and immap_86xx.h but it is not in immap_85xx.h. I am using u-boot-2009.11.1 but I also looked into the latest git sources, and there's no immap_t in that specific file neither. Is there a reason why it is not implemented for MPC85xx? Or do I just need some more defines? So far I only have CONFIG_MPC8XXX_SPI and undef CONFIG_SOFT_SPI. Cheers Matthias Dunda ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] how to configure my ipaddr through a external switch
hi,all. I have a switch (dip16,up to 255 devices) on my board. So I can decide the ipaddr when boot. The ipaddr is set in misc_initr() function, use method: setenv(ipaddr,xxx). when I use tftp, it displays the correct ipaddr i set. for example: TFTP from server 192.168.98.138; our IP address is 192.168.98.35 ( old ip is :#define CONFIG_IPADDR 192.168.98.69) . I use the bootcmd env to boot linux, like this: #define CONFIG_BOOTCOMMAND setenv bootargs mem=96M console=ttyS0,115200n8 root=/dev/nfs nfsroot=$(serverip):/tftpboot/mvfsnew ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask) eth=08:00:3e:26:0a:5b;tftp 8070 uImage;bootm 8070 however , when the kernel is booting , it change the old ip back as the kernel ip: IP-Config: Complete: device=eth0, addr=192.168.98.69, mask=255.255.255.0, gw=192.168.98.1, host=192.168.98.35, domain=, nis-domain=(none), bootserver=192.168.98.138, rootserver=192.168.98.138, rootpath= Looking up port of RPC 13/2 on 192.168.98.138 . finally I found that : IF I don't save env, the IP i config externally is correct. But when I save env, the IP will use the env in flash. How should i change this? thanks. ___ 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
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. Daniel Signed-off-by: Mike Frysinger vap...@gentoo.org --- arch/sparc/include/asm/unaligned.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) create mode 100644 arch/sparc/include/asm/unaligned.h diff --git a/arch/sparc/include/asm/unaligned.h b/arch/sparc/include/asm/unaligned.h new file mode 100644 index 000..6cecbbb --- /dev/null +++ b/arch/sparc/include/asm/unaligned.h @@ -0,0 +1 @@ +#include asm-generic/unaligned.h ___ 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
I was not in the mail list when Jason posted the patch, so I emulated
the reply message.
diff --git a/drivers/net/fec_mxc.c b/drivers/net/fec_mxc.c
index 3f09c2b..e8d7b98 100644
--- a/drivers/net/fec_mxc.c
+++ b/drivers/net/fec_mxc.c
@@ -312,21 +312,17 @@ static void fec_rbd_clean(int last, struct fec_bd *pRbd)
static int fec_get_hwaddr(struct eth_device *dev, unsigned char *mac)
{
-/*
- * The MX27 can store the mac address in internal eeprom
- * This mechanism is not supported now by MX51 or MX25
- */
-#if defined(CONFIG_MX51) || defined(CONFIG_MX25)
- return -1;
-#else
+ /*
+ * The MX27 can store the mac address in internal eeprom
+ * This mechanism is also supported now by MX51 or MX25
+ */
The comment was added to distinguish the MX27 support from MX51/25 on
mac fuse. Since the support becomes common, can we just simply remove
the comment? Also, the mac is implemented in fuse like the message
title tells than eeprom.
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]);
There is a bug. The fix could be as below (tested on mx51evk).
- mac[6-1-i] = readl(iim-iim_bank_area0[IIM0_MAC + i]);
+ mac[i] = readl(iim-iim_bank_area[IIM_MAC + i]);
return !is_valid_ether_addr(mac);
-#endif
}
--
Regards,
Shawn
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Versatile PB compilation problem
I am compiling u-boot for ARM versatile-PB board. But the compilation fails with this error: board.c: In function ‘__dram_init_banksize’: board.c:459: error: ‘CONFIG_SYS_SDRAM_BASE’ undeclared (first use in this function) board.c:459: error: (Each undeclared identifier is reported only once board.c:459: error: for each function it appears in.) board.c: In function ‘board_init_f’: board.c:505: error: ‘CONFIG_SYS_INIT_SP_ADDR’ undeclared (first use in this function) board.c:538: error: ‘CONFIG_SYS_SDRAM_BASE’ undeclared (first use in this function) make[1]: *** [board.o] Error 1 make[1]: Leaving directory `/home/hchauhan/xvisor/u-boot/arch/arm/lib' make: *** [arch/arm/lib/libarm.a] Error 2 Any ideas? I have pulled the tree today from git repository. Thanks Regards Himanshu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND support on AVR32
*From:* Damien Dusha d.du...@gmail.com *To:* from_denx_ub...@dexdyne.com *Date:* Mon, 25 Oct 2010 20:55:23 +1000 HI David, If you've seen this before, my apologies - this is my 3rd attempt to post this - it doesn't appear in anything I've downloaded, so I assume it's not getting posted. If you can't get an answer here, you might like to try avrfreaks, which has a reasonably sized support community at http://www.avrfreaks.net/index.php?name=PNphpBB2file=indexc=5 Cheers, Damien Thanks I tried AVRfreaks but there is no specific u-boot topic, and posting anything about NAND, particularly NAND and u-boot, in the linux conference gets zero response. It really does look like I'm pioneering. D. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND support on AVR32
In article memo.20101025142154.382...@postmaster+dexdyne.com.cix.co.uk, from_denx_ub...@dexdyne.com (David Collier) wrote: *From:* David Collier from_denx_ub...@dexdyne.com *To:* u-boot@lists.denx.de *Date:* Mon, 25 Oct 2010 14:21 +0100 (BST) OK - my apologies I've now used the web browser, and my post is there - the problem is obviously with my download from the mailing list. I still don't see any relies though - so if you cn help I'd be truly grateful :-) David I've studied this a bit, and it does looks as if for the first few days after you join the mailing list, you only get emailed a small percentage of what is going on. Maybe it's something about threading At this moment I seem to be getting 90% plus of all the messages Weird or what D ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] U-boot versions - reply to RM + SW
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. So I've been stuck on a frozen 2008-10. If I have to update to the current source just to do this change it will add some days to the job, and days are precious :-( Thanks for the help anyway. David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs
Jocke, [snip] You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it. finally I got both some time and hardware : 4 nops after _start does the trick, i.e. the board is up and running fine. Diffing both System.maps and U-Boot hexdump gives only trivial results : - in_flash and _start_of_vectors adress increment = 0x10. - offset calculation for relative branch instruction also increases by 0x10. Let me know if you need more information or something else tested. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Versatile PB compilation problem
hi Himanshu, On Mon, Oct 25, 2010 at 6:46 PM, Himanshu Chauhan hschau...@nulltrace.orgwrote: I am compiling u-boot for ARM versatile-PB board. But the compilation fails with this error: board.c: In function ‘__dram_init_banksize’: board.c:459: error: ‘CONFIG_SYS_SDRAM_BASE’ undeclared (first use in this function) board.c:459: error: (Each undeclared identifier is reported only once board.c:459: error: for each function it appears in.) board.c: In function ‘board_init_f’: board.c:505: error: ‘CONFIG_SYS_INIT_SP_ADDR’ undeclared (first use in this function) board.c:538: error: ‘CONFIG_SYS_SDRAM_BASE’ undeclared (first use in this function) make[1]: *** [board.o] Error 1 make[1]: Leaving directory `/home/hchauhan/xvisor/u-boot/arch/arm/lib' make: *** [arch/arm/lib/libarm.a] Error 2 Looks like the board you are compiling does not have support for the ARM relocation added recently. You would need to add valid entries to the board config file. Check this patch as an example http://www.mail-archive.com/u-boot@lists.denx.de/msg36109.html -sughosh ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/10/25 15:50:19: Jocke, [snip] You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it. finally I got both some time and hardware : 4 nops after _start does the trick, i.e. the board is up and running fine. Diffing both System.maps and U-Boot hexdump gives only trivial results : - in_flash and _start_of_vectors adress increment = 0x10. - offset calculation for relative branch instruction also increases by 0x10. Let me know if you need more information or something else tested. I am not looking at this as I am busy but I have an idea or two - CPU bug in 83xx CPUs which uses 0x110 as cold start vector. - Misconfig of HRCW, don't know if you can change the reset vector that way but I guess you need to check. I think a Freescale guy needs to look at this unless you can find something wrong with HRCW Jocke ___ 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 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? Wouldn't change in cache.S (or Makefile) be better solution/ or workaround. At least workaround will be visible to more eyes. ~sanjeev Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs
Jocke, Andre Schwarzandre.schw...@matrix-vision.de wrote on 2010/10/25 15:50:19: Jocke, [snip] You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it. finally I got both some time and hardware : 4 nops after _start does the trick, i.e. the board is up and running fine. Diffing both System.maps and U-Boot hexdump gives only trivial results : - in_flash and _start_of_vectors adress increment = 0x10. - offset calculation for relative branch instruction also increases by 0x10. Let me know if you need more information or something else tested. I am not looking at this as I am busy but I have an idea or two ok - thanks. - CPU bug in 83xx CPUs which uses 0x110 as cold start vector. This is indeed something FSL has to investigate. But at least *some* 83xx boards are running fine ... e300c2 though. - Misconfig of HRCW, don't know if you can change the reset vector that way but I guess you need to check. HRCW reset vector settings are high/low boot only. I think a Freescale guy needs to look at this unless you can find something wrong with HRCW Kim, Timur, can you give any information ? What about your boards ? Is everything running fine using Nor-Boot ? Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ 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
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. Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx51evk: support new relocation scheme
The patchset is to support new relocation scheme and fix the build breakage on master introduced by the relocation scheme. It depends on the following patch from Jason to fix build error introduced by incorrect u-boot.lds. MX5: use common u-boot.lds of cpu layer http://lists.denx.de/pipermail/u-boot/2010-October/079926.html The patchset was tested on mx51evk 3.0 board. Shawn Guo (2): [PATCH 1/2] mx51evk: support new relocation scheme [PATCH 2/2] mx51evk: correct internal RAM base address arch/arm/include/asm/arch-mx5/imx-regs.h |2 +- board/freescale/mx51evk/mx51evk.c|6 +++--- include/configs/mx51evk.h|5 - 3 files changed, 8 insertions(+), 5 deletions(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] mx51evk: support new relocation scheme
This patch is to fix build breakage and support new relocatoin
scheme for mx51evk.
- It includes imx-regs.h in mx51evk.h, so that CSD0_BASE_ADDR and
IRAM_BASE_ADDR can be referred to.
- It uses i.mx51 internal RAM as the init stack, as the internal
RAM is totally free from ROM code when u-boot lives.
Signed-off-by: Shawn Guo shawn@gmail.com
---
board/freescale/mx51evk/mx51evk.c |6 +++---
include/configs/mx51evk.h |5 -
2 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/board/freescale/mx51evk/mx51evk.c
b/board/freescale/mx51evk/mx51evk.c
index c8d7d39..8820698 100644
--- a/board/freescale/mx51evk/mx51evk.c
+++ b/board/freescale/mx51evk/mx51evk.c
@@ -52,9 +52,9 @@ u32 get_board_rev(void)
int dram_init(void)
{
- gd-bd-bi_dram[0].start = PHYS_SDRAM_1;
- gd-bd-bi_dram[0].size = get_ram_size((long *)PHYS_SDRAM_1,
- PHYS_SDRAM_1_SIZE);
+ /* dram_init must store complete ramsize in gd-ram_size */
+ gd-ram_size = get_ram_size((volatile void *)CONFIG_SYS_SDRAM_BASE,
+ PHYS_SDRAM_1_SIZE);
return 0;
}
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 6165473..82f364d 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -24,11 +24,11 @@
#ifndef __CONFIG_H
#define __CONFIG_H
+#include asm/arch/imx-regs.h
/* High Level Configuration Options */
#define CONFIG_MX51/* in a mx51 */
-#define CONFIG_SKIP_RELOCATE_UBOOT
#define CONFIG_SYS_MX5_HCLK2400
#define CONFIG_SYS_MX5_CLK32 32768
@@ -175,6 +175,9 @@
#define PHYS_SDRAM_1 CSD0_BASE_ADDR
#define PHYS_SDRAM_1_SIZE (512 * 1024 * 1024)
+#define CONFIG_SYS_SDRAM_BASE PHYS_SDRAM_1
+#define CONFIG_SYS_INIT_SP_ADDR(IRAM_BASE_ADDR + 0x1000)
+
#define CONFIG_SYS_DDR_CLKSEL 0
#define CONFIG_SYS_CLKTL_CBCDR 0x59E35100
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] mx51evk: correct internal RAM base address
i.mx51 internal RAM starts from 0x1FFE than 0x1FFE8000 Signed-off-by: Shawn Guo shawn@gmail.com --- arch/arm/include/asm/arch-mx5/imx-regs.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/asm/arch-mx5/imx-regs.h index 3ddda40..bcab3db 100644 --- a/arch/arm/include/asm/arch-mx5/imx-regs.h +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h @@ -26,7 +26,7 @@ /* * IRAM */ -#define IRAM_BASE_ADDR 0x1FFE8000 /* internal ram */ +#define IRAM_BASE_ADDR 0x1FFE /* internal ram */ /* * Graphics Memory of GPU */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] mx51evk: consolidate env for mmcboot and netboot
This patch is to consolidate default mx51evk env for two primary
boot modes, mmcboot and netboot.
It also cleans some unused env like netdev, uboot and redundant
env like loadaddr since CONFIG_LOADADDR already defines it.
Signed-off-by: Shawn Guo shawn@gmail.com
---
include/configs/mx51evk.h | 50 ++--
1 files changed, 38 insertions(+), 12 deletions(-)
diff --git a/include/configs/mx51evk.h b/include/configs/mx51evk.h
index 6165473..186cd8c 100644
--- a/include/configs/mx51evk.h
+++ b/include/configs/mx51evk.h
@@ -126,18 +126,42 @@
#define CONFIG_LOADADDR0x9080 /* loadaddr env var */
-#defineCONFIG_EXTRA_ENV_SETTINGS
\
- netdev=eth0\0 \
- uboot_addr=0xa000\0 \
- uboot=u-boot.bin\0\
- loadaddr=0x9080\0 \
- bootargs_base=setenv bootargs console=tty \
- console=ttymxc0,${baudrate}\0\
- bootargs_nfs=setenv bootargs ${bootargs} root=/dev/nfs \
- ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0\
- bootcmd=run bootcmd_net\0 \
- bootcmd_net=run bootargs_base bootargs_nfs; \
- tftpboot ${loadaddr} ${kernel}; bootm\0
+#define CONFIG_EXTRA_ENV_SETTINGS \
+ script=boot.scr\0 \
+ uimage=uImage\0 \
+ mmcdev=0\0 \
+ mmcpart=2\0 \
+ mmcroot=/dev/mmcblk0p3 rw\0 \
+ mmcrootfstype=ext3 rootwait\0 \
+ mmcargs=setenv bootargs console=ttymxc0,${baudrate} \
+ root=${mmcroot} \
+ rootfstype=${mmcrootfstype}\0 \
+ loadbootscript= \
+ fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${script};\0 \
+ bootscript=echo Running bootscript from mmc ...; \
+ source\0 \
+ loaduimage=fatload mmc ${mmcdev}:${mmcpart} ${loadaddr} ${uimage}\0 \
+ mmcboot=echo Booting from mmc ...; \
+ run mmcargs; \
+ bootm\0 \
+ netargs=setenv bootargs console=ttymxc0,${baudrate} \
+ root=/dev/nfs \
+ ip=dhcp nfsroot=${serverip}:${nfsroot},v3,tcp\0 \
+ netboot=echo Booting from net ...; \
+ run netargs; \
+ dhcp ${uimage}; bootm\0 \
+
+#define CONFIG_BOOTCOMMAND \
+ if mmc rescan ${mmcdev}; then \
+ if run loadbootscript; then \
+ run bootscript; \
+ else \
+ if run loaduimage; then \
+ run mmcboot; \
+ else run netboot; \
+ fi; \
+ fi; \
+ else run netboot; fi
#define CONFIG_ARP_TIMEOUT 200UL
@@ -145,6 +169,8 @@
* Miscellaneous configurable options
*/
#define CONFIG_SYS_LONGHELP/* undef to save memory */
+#define CONFIG_SYS_HUSH_PARSER /* use hush command parser */
+#define CONFIG_SYS_PROMPT_HUSH_PS2
#define CONFIG_SYS_PROMPT MX51EVK U-Boot
#define CONFIG_AUTO_COMPLETE
#define CONFIG_SYS_CBSIZE 256 /* Console I/O Buffer Size */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] ppc4xx: Add Io and IoCon 405EP board support
On Thursday 21 October 2010 10:50:05 Dirk Eibach wrote: Board support for the Guntermann Drunck CATCenter Io. Board support for the Guntermann Drunck IoCon. Applied to u-boot-ppc4xx/master. Thanks. 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
[U-Boot] Please pull u-boot-ppc4xx/master
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 MAINTAINERS |2 + board/gdsys/405ep/405ep.c | 93 +++ board/gdsys/405ep/Makefile| 54 + board/gdsys/405ep/io.c| 181 + board/gdsys/405ep/iocon.c | 236 ++ board/gdsys/common/Makefile | 58 ++ board/gdsys/common/fpga.h | 37 ++ board/gdsys/common/miiphybb.c | 102 + board/gdsys/common/osd.c | 247 board/gdsys/common/osd.h | 29 + boards.cfg|2 + include/configs/io.h | 251 include/configs/iocon.h | 252 + 13 files changed, 1544 insertions(+), 0 deletions(-) create mode 100644 board/gdsys/405ep/405ep.c create mode 100644 board/gdsys/405ep/Makefile create mode 100644 board/gdsys/405ep/io.c create mode 100644 board/gdsys/405ep/iocon.c create mode 100644 board/gdsys/common/Makefile create mode 100644 board/gdsys/common/fpga.h create mode 100644 board/gdsys/common/miiphybb.c create mode 100644 board/gdsys/common/osd.c create mode 100644 board/gdsys/common/osd.h create mode 100644 include/configs/io.h create mode 100644 include/configs/iocon.h ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs
Andre Schwarz andre.schw...@matrix-vision.de wrote on 2010/10/25 16:46:42: Jocke, Andre Schwarzandre.schw...@matrix-vision.de wrote on 2010/10/25 15:50:19: Jocke, [snip] You still haven't reported weather the 4 nop's helped or not, yet you seek my help. I am just going to ignore you until you do test it. finally I got both some time and hardware : 4 nops after _start does the trick, i.e. the board is up and running fine. Diffing both System.maps and U-Boot hexdump gives only trivial results : - in_flash and _start_of_vectors adress increment = 0x10. - offset calculation for relative branch instruction also increases by 0x10. Let me know if you need more information or something else tested. I am not looking at this as I am busy but I have an idea or two ok - thanks. - CPU bug in 83xx CPUs which uses 0x110 as cold start vector. This is indeed something FSL has to investigate. But at least *some* 83xx boards are running fine ... e300c2 though. I got a e300c2, mpc8321 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: add header file for the Shutdown Controller
and SHDWN address entry in at91sam9260.h
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de
---
arch/arm/include/asm/arch-at91/at91_shdwn.h | 38 ++
arch/arm/include/asm/arch-at91/at91sam9260.h |1 +
2 files changed, 39 insertions(+), 0 deletions(-)
create mode 100644 arch/arm/include/asm/arch-at91/at91_shdwn.h
diff --git a/arch/arm/include/asm/arch-at91/at91_shdwn.h
b/arch/arm/include/asm/arch-at91/at91_shdwn.h
new file mode 100644
index 000..709e071
--- /dev/null
+++ b/arch/arm/include/asm/arch-at91/at91_shdwn.h
@@ -0,0 +1,38 @@
+/*
+ * Copyright (C) 2010
+ * Reinhard Meyer, reinhard.me...@emk-elektronik.de
+ *
+ * Shutdown Controller
+ * Based on AT91SAM9XE datasheet
+ *
+ * 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.
+ */
+
+#ifndef AT91_SHDWN_H
+#define AT91_SHDWN_H
+
+#ifndef __ASSEMBLY__
+
+typedef struct at91_shdwn {
+ u32 cr; /* Control Rer.WO */
+ u32 mr; /* Mode Register RW 0x0003 */
+ u32 sr; /* Status Register RO 0x */
+} at91_shdwn_t;
+
+#endif /* __ASSEMBLY__ */
+
+#define AT91_SHDW_CR_KEY 0xa500
+#define AT91_SHDW_CR_SHDW 0x0001
+
+#define AT91_SHDW_MR_RTTWKEN 0x0001
+#define AT91_SHDW_MR_CPTWK00x00f0
+#define AT91_SHDW_MR_WKMODE0H2L0x0002
+#define AT91_SHDW_MR_WKMODE0L2H0x0001
+
+#define AT91_SHDW_SR_RTTWK 0x0001
+#define AT91_SHDW_SR_WAKEUP0 0x0001
+
+#endif
diff --git a/arch/arm/include/asm/arch-at91/at91sam9260.h
b/arch/arm/include/asm/arch-at91/at91sam9260.h
index cb34a94..7fd60b7 100644
--- a/arch/arm/include/asm/arch-at91/at91sam9260.h
+++ b/arch/arm/include/asm/arch-at91/at91sam9260.h
@@ -56,6 +56,7 @@
#define AT91_PIO_BASE 0xf400
#define AT91_PMC_BASE 0xfc00
#define AT91_RSTC_BASE 0xfd00
+#define AT91_SHDWN_BASE0xfd10
#define AT91_RTT_BASE 0xfd20
#define AT91_PIT_BASE 0xfd30
#define AT91_WDT_BASE 0xfd40
--
1.5.6.5
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] AT91: add 2nd SPI to 9260/9XE/9G20
Signed-off-by: Reinhard Meyer u-b...@emk-elektronik.de --- arch/arm/include/asm/arch-at91/hardware.h |1 + arch/arm/include/asm/arch-at91/memory-map.h |1 + 2 files changed, 2 insertions(+), 0 deletions(-) diff --git a/arch/arm/include/asm/arch-at91/hardware.h b/arch/arm/include/asm/arch-at91/hardware.h index f5f80e0..6b44d61 100644 --- a/arch/arm/include/asm/arch-at91/hardware.h +++ b/arch/arm/include/asm/arch-at91/hardware.h @@ -23,6 +23,7 @@ #include asm/arch/at91sam9260.h #define AT91_BASE_MCI AT91SAM9260_BASE_MCI #define AT91_BASE_SPI AT91SAM9260_BASE_SPI0 +#define AT91_BASE_SPI1 AT91SAM9260_BASE_SPI1 #define AT91_ID_UHPAT91SAM9260_ID_UHP #define AT91_PMC_UHP AT91SAM926x_PMC_UHP #elif defined(CONFIG_AT91SAM9261) || defined(CONFIG_AT91SAM9G10) diff --git a/arch/arm/include/asm/arch-at91/memory-map.h b/arch/arm/include/asm/arch-at91/memory-map.h index f605f37..d489fa2 100644 --- a/arch/arm/include/asm/arch-at91/memory-map.h +++ b/arch/arm/include/asm/arch-at91/memory-map.h @@ -31,5 +31,6 @@ #define USART2_BASE AT91_USART2 #define USART3_BASE (AT91_BASE_SYS + AT91_DBGU) #define SPI0_BASE AT91_BASE_SPI +#define SPI1_BASE AT91_BASE_SPI1 #endif /* __ASM_ARM_ARCH_MEMORYMAP_H__ */ -- 1.5.6.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] Add board support for hawkboard
hi Wolfgang,
On Fri, Oct 22, 2010 at 2:22 PM, Sughosh Ganu urwithsugh...@gmail.comwrote:
hi Wolfgang,
On Fri Oct 22, 2010 at 10:05:43AM +0200, Wolfgang Denk wrote:
#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);
}
+void board_init_f (ulong bootflag)__attribute__((weak,
alias(__board_init_f)));
#endif
This is a global change that affects all NAND booting boards. This
must be submitted spearately, and you must explain in detail why you
think you need that. Also please mention on which systems this
change
has been tested.
For hawkboard, we need to do some board specific initialisation
which can be included in board_init_f. The freescale boards which
Can you probably do it in any of the other, board dependent init
functions?
Not sure on this one. The only board specific function that gets
called in the nand spl stage is board_init_f.
I was checking the usage of board_init_f in the nand_spl/nand_boot.c file,
and currently only the smdk6400 board uses it. Can we then remove this
function definition from the nand_boot.c file and put it in the respective
board file, like the freescale boards. I think this is a cleaner way of
implementing this. Please le me know, and i will base my changes
accordingly. Thanks.
-sughosh
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfi_flash: Fix problems with status/id read mode
This patch adds some calls to set the flash chip in the read-status-
register- or read-id-mode before the corresponding register is
read back. This problem was detected while porting the common CFI
driver to support the Xilinx DS617 flash chips.
Signed-off-by: Stefan Roese s...@denx.de
---
drivers/mtd/cfi_flash.c | 12
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index c92c7a7..e2317bd 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1426,6 +1426,11 @@ int flash_real_protect (flash_info_t * info, long
sector, int prot)
#endif
};
+ /*
+* Flash needs to be in status register read mode for
+* flash_full_status_check() to work correctly
+*/
+ flash_write_cmd(info, sector, 0, FLASH_CMD_READ_STATUS);
if ((retcode =
flash_full_status_check (info, sector, info-erase_blk_tout,
prot ? protect : unprotect)) == 0) {
@@ -1973,6 +1978,13 @@ ulong flash_get_size (phys_addr_t base, int banknum,
unsigned long max_size)
case CFI_CMDSET_INTEL_PROG_REGIONS:
case CFI_CMDSET_INTEL_EXTENDED:
case CFI_CMDSET_INTEL_STANDARD:
+ /*
+* Set flash to read-id mode. Otherwise
+* reading protected status is not
+* guaranteed.
+*/
+ flash_write_cmd(info, sect_cnt, 0,
+ FLASH_CMD_READ_ID);
info-protect[sect_cnt] =
flash_isset (info, sect_cnt,
FLASH_OFFSET_PROTECT,
--
1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfi_flash: Use flash_read32() in sector_erased()
The function sector_erased() is modified to not use pointer
access, but to use the correct accessor functions. This fixes a
problem on the t3corp board with the Xilinx DS617 flash chips. Here
a board specific accessor function is needed to read from flash
in 32bit mode. This patch enables such an operation mode.
Signed-off-by: Stefan Roese s...@denx.de
---
drivers/mtd/cfi_flash.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index e2317bd..c17c542 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -1112,18 +1112,18 @@ static int sector_erased(flash_info_t *info, int i)
{
int k;
int size;
- volatile unsigned long *flash;
+ u32 *flash;
/*
* Check if whole sector is erased
*/
size = flash_sector_size(info, i);
- flash = (volatile unsigned long *) info-start[i];
+ flash = (u32 *)info-start[i];
/* divide by 4 for longword access */
size = size 2;
for (k = 0; k size; k++) {
- if (*flash++ != 0x)
+ if (flash_read32(flash++) != 0x)
return 0; /* not erased */
}
--
1.7.3.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] cfi_flash: Add optional config register write to cfi-detection
This patch adds the possibility to (optinally) write to the
flash configuration register. The Intel style CFI chips support
such a register that can be used to configure the operation
mode to a non-default value.
This method will be used by the t3corp board, which needs to
configure the DS617 Xilinx flash for async read mode.
Signed-off-by: Stefan Roese s...@denx.de
---
drivers/mtd/cfi_flash.c | 43 +++
include/mtd/cfi_flash.h |2 ++
2 files changed, 45 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/cfi_flash.c b/drivers/mtd/cfi_flash.c
index c17c542..6e617f0 100644
--- a/drivers/mtd/cfi_flash.c
+++ b/drivers/mtd/cfi_flash.c
@@ -74,6 +74,20 @@ flash_info_t flash_info[CFI_MAX_FLASH_BANKS];/*
FLASH chips info */
#define CONFIG_SYS_FLASH_CFI_WIDTH FLASH_CFI_8BIT
#endif
+/*
+ * 0x is an undefined value for the configuration register. When
+ * this value is returned, the configuration register shall not be
+ * written at all (default mode).
+ */
+static u16 cfi_flash_config_reg(int i)
+{
+#ifdef CONFIG_SYS_CFI_FLASH_CONFIG_REGS
+ return ((u16 [])CONFIG_SYS_CFI_FLASH_CONFIG_REGS)[i];
+#else
+ return 0x;
+#endif
+}
+
#if defined(CONFIG_SYS_MAX_FLASH_BANKS_DETECT)
int cfi_flash_num_flash_banks = CONFIG_SYS_MAX_FLASH_BANKS_DETECT;
#endif
@@ -2031,6 +2045,31 @@ void flash_set_verbose(uint v)
flash_verbose = v;
}
+static void cfi_flash_set_config_reg(u32 base, u16 val)
+{
+#ifdef CONFIG_SYS_CFI_FLASH_CONFIG_REGS
+ /*
+* Only set this config register if really defined
+* to a valid value (0x is invalid)
+*/
+ if (val == 0x)
+ return;
+
+ /*
+* Set configuration register. Data is encrypted in the 16 lower
+* address bits.
+*/
+ flash_write16(FLASH_CMD_SETUP, (void *)(base + (val 1)));
+ flash_write16(FLASH_CMD_SET_CR_CONFIRM, (void *)(base + (val 1)));
+
+ /*
+* Finally issue reset-command to bring device back to
+* read-array mode
+*/
+ flash_write16(FLASH_CMD_RESET, (void *)base);
+#endif
+}
+
/*---
*/
unsigned long flash_init (void)
@@ -2054,6 +2093,10 @@ unsigned long flash_init (void)
for (i = 0; i CONFIG_SYS_MAX_FLASH_BANKS; ++i) {
flash_info[i].flash_id = FLASH_UNKNOWN;
+ /* Optionally write flash configuration register */
+ cfi_flash_set_config_reg(cfi_flash_bank_addr(i),
+cfi_flash_config_reg(i));
+
if (!flash_detect_legacy(cfi_flash_bank_addr(i), i))
flash_get_size(cfi_flash_bank_addr(i), i,
cfi_flash_bank_size(i));
diff --git a/include/mtd/cfi_flash.h b/include/mtd/cfi_flash.h
index 2ff00f2..3245b44 100644
--- a/include/mtd/cfi_flash.h
+++ b/include/mtd/cfi_flash.h
@@ -32,6 +32,8 @@
#define FLASH_CMD_ERASE_CONFIRM0xD0
#define FLASH_CMD_WRITE0x40
#define FLASH_CMD_PROTECT 0x60
+#define FLASH_CMD_SETUP0x60
+#define FLASH_CMD_SET_CR_CONFIRM 0x03
#define FLASH_CMD_PROTECT_SET 0x01
#define FLASH_CMD_PROTECT_CLEAR0xD0
#define FLASH_CMD_CLEAR_STATUS 0x50
--
1.7.3.2
___
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
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 TO3 should be starting from 0x1FFE Maybe you need fix the commit log and state it clearly. Signed-off-by: Shawn Guo shawn@gmail.com --- arch/arm/include/asm/arch-mx5/imx-regs.h | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/asm/arch-mx5/imx-regs.h index 3ddda40..bcab3db 100644 --- a/arch/arm/include/asm/arch-mx5/imx-regs.h +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h @@ -26,7 +26,7 @@ /* * IRAM */ -#define IRAM_BASE_ADDR 0x1FFE8000 /* internal ram */ +#define IRAM_BASE_ADDR 0x1FFE /* internal ram */ /* * Graphics Memory of GPU */ -- 1.7.1 ___ 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] powerpc: do not fixup NULL ptrs
Dear Andre Schwarz, In message 4cc58b1b.8040...@matrix-vision.de you wrote: finally I got both some time and hardware : 4 nops after _start does the trick, i.e. the board is up and running fine. This is probably completely unrelated - but check your CONFIG_SYS_GBL_DATA_SIZE setting and make sure it's still = sizeof(struct global_data). 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 O Staat! Wie tief dir alle Besten fluchen! Du bist kein Ziel. Der Mensch muß weiter suchen. - Christian Morgenstern ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support
On Sat, Oct 23, 2010 at 8:14 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Friday, October 15, 2010 3:14 AM To: John Rigby Cc: u-boot@lists.denx.de; Alagu Sankar; Andy Fleming Subject: Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support On Mon, Oct 4, 2010 at 1:32 PM, John Rigby jcri...@gmail.com wrote: Alagu, This never made it into Andy's tree nor upstream. Could you submit a new patch to current upstream with the config option removed as Andy said he did back in May? Maybe we can get it commited via some other maintainer. Steve Sakoman seems to have done some MMC work lately. I've done some testing with this patch on OMAP3 and OMAP4, in the always enabled version. I compared the old legacy mmc driver vs the new generic mmc driver vs new generic mmc driver with multiblock read support added. The good news is that the generic mmc driver for OMAP is almost twice as fast as the old legacy driver. These patches should be in the next u-boot-ti pull request and so will be in mainline shortly. The bad news is that multiblock reads seem to make no difference :-( For reading a 45MB file from an ext3 partition using ext2load I get: legacy: 62 seconds generic: 35 seconds generic w/ multi: 35 seconds I'm happy to resubmit the multi-block read patch because it does seem to work properly and may even yield improvements on other architectures. Would you like me to do that? [Ghorai] would you please try with additional change? Yes! That is much better! Now multiblock reads are faster :-) The results (including the old legacy mmc driver for reference): legacy: 62 seconds generic: 35 seconds generic w/ multi: 9 seconds I will add my Acked-by and Tested-by and submit the final patch to the list later today. Steve $git diff drivers/mmc/omap_hsmmc.c diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index f8b9840..7f3f968 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -401,6 +401,7 @@ int omap_mmc_init(int dev_index) mmc-f_min = 40; mmc-f_max = 5200; + mmc-b_max = 0x; mmc_register(mmc); Steve ___ 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] powerpc: do not fixup NULL ptrs
Wolfgang, Dear Andre Schwarz, In message4cc58b1b.8040...@matrix-vision.de you wrote: finally I got both some time and hardware : 4 nops after _start does the trick, i.e. the board is up and running fine. This is probably completely unrelated - but check your CONFIG_SYS_GBL_DATA_SIZE setting and make sure it's still= sizeof(struct global_data). Having a look at include/asm/global_data.h gives some 40 ulongs for my MPC8377 system. Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough. Nevertheless I doubled to 0x200. The system is still dead after removing the 4 nops after _start. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND support on AVR32
On Mon, 25 Oct 2010 14:21:00 +0100 David Collier from_denx_ub...@dexdyne.com wrote: OK - my apologies I've now used the web browser, and my post is there - the problem is obviously with my download from the mailing list. I still don't see any relies though - so if you cn help I'd be truly grateful :-) There were replies: http://lists.denx.de/pipermail/u-boot/2010-October/078860.html http://lists.denx.de/pipermail/u-boot/2010-October/078861.html They should have also gone directly to your e-mail (separate from the list), assuming from_denx_ub...@dexdyne.com is actually a valid address for you. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Versatile PB compilation problem
On Mon, Oct 25, 2010 at 7:55 PM, sughosh ganu urwithsugh...@gmail.com wrote: hi Himanshu, On Mon, Oct 25, 2010 at 6:46 PM, Himanshu Chauhan hschau...@nulltrace.org wrote: I am compiling u-boot for ARM versatile-PB board. But the compilation fails with this error: board.c: In function ‘__dram_init_banksize’: board.c:459: error: ‘CONFIG_SYS_SDRAM_BASE’ undeclared (first use in this function) board.c:459: error: (Each undeclared identifier is reported only once board.c:459: error: for each function it appears in.) board.c: In function ‘board_init_f’: board.c:505: error: ‘CONFIG_SYS_INIT_SP_ADDR’ undeclared (first use in this function) board.c:538: error: ‘CONFIG_SYS_SDRAM_BASE’ undeclared (first use in this function) make[1]: *** [board.o] Error 1 make[1]: Leaving directory `/home/hchauhan/xvisor/u-boot/arch/arm/lib' make: *** [arch/arm/lib/libarm.a] Error 2 Looks like the board you are compiling does not have support for the ARM relocation added recently. You would need to add valid entries to the board config file. Check this patch as an example http://www.mail-archive.com/u-boot@lists.denx.de/msg36109.html -sughosh Thanks Sughosh. Let me check. - Himanshu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] VoVPN-GW_100MHz: drop unsupported board configuration
On 2010/10/24 4:00 PM, Wolfgang Denk wrote: The 100MHz configuation of the VoVPN-GW has never been supported, so drop it now. Signed-off-by: Wolfgang Denk w...@denx.de --- This commit shows a problem with the concept of the README.scrapyard file: I'm supposed to enter the commit ID for the commit I'm just about to check in; this cannot work. Hope we remember to clean this up when making the next entries... Anybody having any better ideas? Some clever git attributes trick? How about documenting a git command line for showing when a particular set of lines is added? e.g. git blame doc/README.scrapyard This will show the revision at which a particular line was introduced, and will therefore provide a guide to when the feature was removed. Include the cmdline at the top of the scrapyard file, and it should be fairly self-evident, I would hope. Rogan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Versatile PB compilation problem
Looks like the board you are compiling does not have support for the ARM relocation added recently. You would need to add valid entries to the board config file. Check this patch as an example http://www.mail-archive.com/u-boot@lists.denx.de/msg36109.html -sughosh The September archive did the trick for me. I can test my Hypervisor with this image. Since I am not aware of the new U-Boot structure, may be somebody maintaining Versatile PB board, can fix this. Thanks Regards Himanshu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support
-Original Message- From: Steve Sakoman [mailto:sako...@gmail.com] Sent: Monday, October 25, 2010 11:00 PM To: Ghorai, Sukumar Cc: John Rigby; u-boot@lists.denx.de; Alagu Sankar; Andy Fleming Subject: Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support On Sat, Oct 23, 2010 at 8:14 AM, Ghorai, Sukumar s-gho...@ti.com wrote: -Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot- boun...@lists.denx.de] On Behalf Of Steve Sakoman Sent: Friday, October 15, 2010 3:14 AM To: John Rigby Cc: u-boot@lists.denx.de; Alagu Sankar; Andy Fleming Subject: Re: [U-Boot] [PATCH 3/4] MMC Multi-block Support On Mon, Oct 4, 2010 at 1:32 PM, John Rigby jcri...@gmail.com wrote: Alagu, This never made it into Andy's tree nor upstream. Could you submit a new patch to current upstream with the config option removed as Andy said he did back in May? Maybe we can get it commited via some other maintainer. Steve Sakoman seems to have done some MMC work lately. I've done some testing with this patch on OMAP3 and OMAP4, in the always enabled version. I compared the old legacy mmc driver vs the new generic mmc driver vs new generic mmc driver with multiblock read support added. The good news is that the generic mmc driver for OMAP is almost twice as fast as the old legacy driver. These patches should be in the next u-boot-ti pull request and so will be in mainline shortly. The bad news is that multiblock reads seem to make no difference :-( For reading a 45MB file from an ext3 partition using ext2load I get: legacy: 62 seconds generic: 35 seconds generic w/ multi: 35 seconds I'm happy to resubmit the multi-block read patch because it does seem to work properly and may even yield improvements on other architectures. Would you like me to do that? [Ghorai] would you please try with additional change? Yes! That is much better! Now multiblock reads are faster :-) The results (including the old legacy mmc driver for reference): legacy: 62 seconds generic: 35 seconds generic w/ multi: 9 seconds I will add my Acked-by and Tested-by and submit the final patch to the list later today. [Ghorai] please add Tested-by: Sukumar Ghorai s-gho...@ti.com And will submit a separate patch as mentioned below. Steve $git diff drivers/mmc/omap_hsmmc.c diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c index f8b9840..7f3f968 100644 --- a/drivers/mmc/omap_hsmmc.c +++ b/drivers/mmc/omap_hsmmc.c @@ -401,6 +401,7 @@ int omap_mmc_init(int dev_index) mmc-f_min = 40; mmc-f_max = 5200; + mmc-b_max = 0x; mmc_register(mmc); Steve ___ 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 V4] mmc: seperate block number into small parts for multi-write cmd
On Wed, Oct 13, 2010 at 10:38 PM, Lei Wen lei...@marvell.com wrote: Constraint the mmc framework to only send no more than 65535 blocks in one go during the multi-write command. This constraint comes due to the limitation of 16bit width block counter register at some hardware. Signed-off-by: Lei Wen lei...@marvell.com Cc: Reinhard Meyer u-b...@emk-elektronik.de --- V4: clean patch V3: return to the V1 solution that keep the 65535 constraint, but cut the 512KiB dma limitation V2: add additional members in mmc structure What is the status of this patch? I would like to submit a multi-block read patch and need to know whether to assume that this patch will be pushed. Regards, Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] sh: serial: Update serial driver for SH
I copied the setting of CPU from Linux kernel and commonized it.
By this, we can communalize a kernel and information.
And added the serial setting of many CPU's.
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org
---
drivers/serial/serial_sh.c | 199 +
drivers/serial/serial_sh.h | 689
2 files changed, 762 insertions(+), 126 deletions(-)
create mode 100644 drivers/serial/serial_sh.h
diff --git a/drivers/serial/serial_sh.c b/drivers/serial/serial_sh.c
index bfdb2ce..2b29c25 100644
--- a/drivers/serial/serial_sh.c
+++ b/drivers/serial/serial_sh.c
@@ -1,6 +1,7 @@
/*
* SuperH SCIF device driver.
- * Copyright (c) 2007,2008 Nobuhiro Iwamatsu
+ * Copyright (C) 2007,2008,2010 Nobuhiro Iwamatsu
+ * Copyright (C) 2002 - 2008 Paul Mundt
*
* 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
@@ -21,6 +22,8 @@
#include asm/io.h
#include asm/processor.h
+#include serial_sh.h
+
#if defined(CONFIG_CONS_SCIF0)
# define SCIF_BASE SCIF0_BASE
#elif defined(CONFIG_CONS_SCIF1)
@@ -37,141 +40,88 @@
# error Default SCIF doesn't set.
#endif
-/* Base register */
-#define SCSMR (vu_short *)(SCIF_BASE + 0x0)
-#define SCBRR (vu_char *)(SCIF_BASE + 0x4)
-#define SCSCR (vu_short *)(SCIF_BASE + 0x8)
-#define SCFCR (vu_short *)(SCIF_BASE + 0x18)
-#define SCFDR (vu_short *)(SCIF_BASE + 0x1C)
-#if defined(CONFIG_CPU_SH7720) || \
- (defined(CONFIG_CPU_SH7723) defined(CONFIG_SCIF_A))
-# define SCFSR (vu_short *)(SCIF_BASE + 0x14) /* SCSSR */
-# define SCFTDR(vu_char *)(SCIF_BASE + 0x20)
-# define SCFRDR(vu_char *)(SCIF_BASE + 0x24)
+#if defined(CONFIG_SCIF_A)
+ #define SCIF_BASE_PORT PORT_SCIFA
#else
-# define SCFTDR (vu_char *)(SCIF_BASE + 0xC)
-# define SCFSR (vu_short *)(SCIF_BASE + 0x10)
-# define SCFRDR (vu_char *)(SCIF_BASE + 0x14)
+ #define SCIF_BASE_PORT PORT_SCIF
#endif
-#ifdefined(CONFIG_CPU_SH7780) || \
- defined(CONFIG_CPU_SH7785)
-# define SCRFDR(vu_short *)(SCIF_BASE + 0x20)
-# define SCSPTR(vu_short *)(SCIF_BASE + 0x24)
-# define SCLSR (vu_short *)(SCIF_BASE + 0x28)
-# define SCRER (vu_short *)(SCIF_BASE + 0x2C)
-# define LSR_ORER 1
-# define FIFOLEVEL_MASK0xFF
-#elif defined(CONFIG_CPU_SH7763)
-# if defined(CONFIG_CONS_SCIF2)
-# define SCSPTR(vu_short *)(SCIF_BASE + 0x20)
-# define SCLSR (vu_short *)(SCIF_BASE + 0x24)
-# define LSR_ORER 1
-# define FIFOLEVEL_MASK0x1F
-# else
-# define SCRFDR(vu_short *)(SCIF_BASE + 0x20)
-# define SCSPTR(vu_short *)(SCIF_BASE + 0x24)
-# define SCLSR (vu_short *)(SCIF_BASE + 0x28)
-# define SCRER (vu_short *)(SCIF_BASE + 0x2C)
-# define LSR_ORER 1
-# define FIFOLEVEL_MASK0xFF
-# endif
-#elif defined(CONFIG_CPU_SH7723)
-# if defined(CONFIG_SCIF_A)
-# define SCLSR SCFSR
-# define LSR_ORER 0x0200
-# define FIFOLEVEL_MASK0x3F
-#else
-# define SCLSR (vu_short *)(SCIF_BASE + 0x24)
-# define LSR_ORER 1
-# define FIFOLEVEL_MASK0x1F
-#endif
-#elif defined(CONFIG_CPU_SH7750) || \
- defined(CONFIG_CPU_SH7751) || \
- defined(CONFIG_CPU_SH7722) || \
- defined(CONFIG_CPU_SH7203)
-# define SCSPTR(vu_short *)(SCIF_BASE + 0x20)
-# define SCLSR (vu_short *)(SCIF_BASE + 0x24)
-# define LSR_ORER 1
-# define FIFOLEVEL_MASK0x1F
-#elif defined(CONFIG_CPU_SH7720)
-# define SCLSR SCFSR
-# define LSR_ORER 0x0200
-# define FIFOLEVEL_MASK0x1F
-#elif defined(CONFIG_CPU_SH7710) || \
- defined(CONFIG_CPU_SH7712)
-# define SCLSR SCFSR /* SCSSR */
-# define LSR_ORER 1
-# define FIFOLEVEL_MASK0x1F
-#endif
-
-/* SCBRR register value setting */
-#if defined(CONFIG_CPU_SH7720)
-# define SCBRR_VALUE(bps, clk) (((clk * 2) + 16 * bps) / (32 * bps) - 1)
-#elif defined(CONFIG_CPU_SH7723) defined(CONFIG_SCIF_A)
-/* SH7723 SCIFA use bus clock. So clock *2 */
-# define SCBRR_VALUE(bps, clk) (((clk * 2 * 2) + 16 * bps) / (32 * bps) - 1)
-#else /* Generic SuperH */
-# define SCBRR_VALUE(bps, clk) ((clk + 16 * bps) / (32 * bps) - 1)
-#endif
-
-#define SCR_RE (1 4)
-#define SCR_TE (1 5)
-#define FCR_RFRST (1 1)/* RFCL */
-#define FCR_TFRST (1 2)/* TFCL */
-#define FSR_DR (1 0)
-#define FSR_RDF(1 1)
-#define FSR_FER(1 3)
-#define FSR_BRK(1 4)
-#define FSR_FER(1 3)
-#define FSR_TEND (1 6)
-#define FSR_ER (1 7)
-
-/*--*/
+static struct uart_port sh_sci = {
+ .membase= (unsigned char*)SCIF_BASE,
+ .mapbase= SCIF_BASE,
+ .type = SCIF_BASE_PORT,
+};
void serial_setbrg(void)
{
DECLARE_GLOBAL_DATA_PTR;
-
- writeb(SCBRR_VALUE(gd-baudrate,
Re: [U-Boot] [PATCH 01/10 v2] net: rtl8169: Add initialized eth_device structure
Hi, Ben and Wolfgang.
Could you take in these patches?
Best regards,
Nobuhiro
2010/10/19 Nobuhiro Iwamatsu iwama...@nigauri.org:
rtl8169 does not have write_hwaddr function.
However, eth stuff executes write_hwaddr function
because eth_device structure has not been initialized.
Signed-off-by: Nobuhiro Iwamatsu iwama...@nigauri.org
CC: Ben Warren biggerbadder...@gmail.com
---
drivers/net/rtl8169.c | 7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/net/rtl8169.c b/drivers/net/rtl8169.c
index e45d1a5..d6bc514 100644
--- a/drivers/net/rtl8169.c
+++ b/drivers/net/rtl8169.c
@@ -894,7 +894,12 @@ int rtl8169_initialize(bd_t *bis)
debug (rtl8169: REALTEK RTL8169 @0x%x\n, iobase);
dev = (struct eth_device *)malloc(sizeof *dev);
-
+ if (!dev) {
+ printf(Can not allocate memory of rtl8169\n);
+ break;
+ }
+
+ memset(dev, 0, sizeof(*dev));
sprintf (dev-name, RTL8169#%d, card_number);
dev-priv = (void *) devno;
--
1.7.1
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] powerpc: do not fixup NULL ptrs
Dear Andre Schwarz, In message 4cc5c226.8080...@matrix-vision.de you wrote: Having a look at include/asm/global_data.h gives some 40 ulongs for my MPC8377 system. Current CONFIG_SYS_GBL_DATA_SIZE= 0x100 which should be enough. Indeed. I was asking because I just discovered that most of the PowerPC boards are actually broken in this respect - 89 % of them, 170 out of 191 :-( The system is still dead after removing the 4 nops after _start. Sorry, but it was worth a try. 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 you're not part of the solution, you're part of the problem. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ALERT! 90% of all board configurations BROKEN
Hello, 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. If you are debugging strange problems, check this first! In the mean time I will try to come up with a clean solution for that. Um... and 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 No question is too silly to ask. Of course, some questions are too silly to to answer... - L. Wall R. L. Schwartz, _Programming Perl_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3 V2] 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 --- V2: Based on comments from Wolfgang, move the headers under asm/arch-davinci/. .../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 V2] Make board_init_f under nand_boot.c a weak function.
Enable board_init_f to be overridden with a board specific
funtion.
Signed-off-by: Sughosh Ganu urwithsugh...@gmail.com
---
V2:
Splitting this change as a separate patch.
nand_spl/nand_boot.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/nand_spl/nand_boot.c b/nand_spl/nand_boot.c
index ccd0af2..3cda41c 100644
--- a/nand_spl/nand_boot.c
+++ b/nand_spl/nand_boot.c
@@ -222,11 +222,12 @@ 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);
}
+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 V2] Add 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
---
V2:
Taken care of comments from Wolfgang.
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 | 68 +++
board/davinci/da8xxevm/hawkboard_nand_spl.c | 163 +
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, 776 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..53a038e
--- /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.
+ *
+ * See file CREDITS for list of people who contributed to this
+ *
[U-Boot] [PATCH] omap4: board: change global data pointer to file scope
DECLARE_GLOBAL_DATA_PTR is currently defined within the scope
of function while it is a global pointer. Change the scope of
definition to replicate it's global scope. This seems to help
gcc 4.5 optimizations as well.
Signed-off-by: Nishanth Menon n...@ti.com
---
arch/arm/cpu/armv7/omap4/board.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c
index 24a66f5..f967d09 100644
--- a/arch/arm/cpu/armv7/omap4/board.c
+++ b/arch/arm/cpu/armv7/omap4/board.c
@@ -32,6 +32,8 @@
#include asm/arch/sys_proto.h
#include asm/sizes.h
+DECLARE_GLOBAL_DATA_PTR;
+
/*
* Routine: s_init
* Description: Does early system init of muxing and clocks.
@@ -100,7 +102,6 @@ u32 sdram_size(void)
*/
int dram_init(void)
{
- DECLARE_GLOBAL_DATA_PTR;
#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
gd-bd-bi_dram[0].start = 0x8000;
--
1.6.3.3
___
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 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? Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Massage Therapists marketing email list
Prices below are only valid until Friday VOLUME PRICING 2 lists - $99 each 3 lists - $75 each 5 lists - $64 each 7 lists - $52 each Choose from any list below: [ HEALTHCARE ] Complete US Physicians Database Chiropractic Doctors in the USA American Holistic Medicine Providers/Clinics General Dentists in the USA American Veterinarians Veterinary Clinics US Hospitals Nursing Homes int the US Pharmaceutical Company Employees Physical/Occupational Therapy Clinics and Therapists in the US Oncology Physicians in the US US Surgery Centers Massage Therapists/Therapy Clinics in America Acupuncturists/clinics in the US Medical Equipment Suppliers(USA) Mental Health Counselors (USA) Optometrists/Clinics (USA) Psychologists (USA) [ BUSINESS LISTS ] Hotels in the USA Realtors in the USA USA Business Database Manufacturer Database (USA) Financial Planner Database (USA) Finance Professionals Database (USA) [ CONSUMER LISTS ] USA Consumer Database Credit Inquiries Database (USA) American Homeowners [ PROFESSIONALS LISTS ] USA Lawyers Database Criminal Attorneys in the US Email me for counts, breakdowns and sample spreadsheets: maximumresu...@gmx.us email purgef...@gmx.com for delisting - IMPORTANT - This e-mail and the information that it contains may be confidential, legally privileged and protected by law. Access by the intended recipient only is authorised. Any liability (in negligence or otherwise) arising from any third party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. 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. Copyright in this e-mail and attachments created by us belongs to Triage Services Limited. The author also asserts the right to be identified as such and object to any misuse. Should you communicate with anyone at Triage Services Limited by e-mail, you consent to us monitoring and reading any such correspondence. Triage Services Limited Registered No 3459830 :Registered Office : Unit 3B , Meadway Court, Stevenage, Herts SG1 2EF ___ 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 4cc5e865.70...@emk-elektronik.de you wrote: 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. Are you sure? My very first smaple sees: arch/arm/cpu/arm926ejs/start.S 346 /* Set up the stack */ 347 stack_setup: 348 ldr r0, _TEXT_BASE /* upper 128 KiB: relocated uboot */ 349 sub sp, r0, #128/* leave 32 words for abort-stack */ 350 #ifndef CONFIG_PRELOADER 351 sub r0, r0, #CONFIG_SYS_MALLOC_LEN /* malloc area */ 352 sub r0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* bdinfo */ 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 multi-legged creature crawling on your shoulder. -- Spock, A Taste of Armageddon, stardate 3193.9 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] u-boot text console
Hi, 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? Regards, Kallol ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] 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 a udelay(10) to ensure we have a predictable delay.
use an emperical number - 10 uSec ~= 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
---
drivers/mmc/omap_hsmmc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 9271470..9b03ce1 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -137,7 +137,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
{
hsmmc_t *mmc_base = (hsmmc_t *)mmc-priv;
unsigned int flags, mmc_stat;
- unsigned int retry = 0x10;
+ unsigned int retry = 10;
while ((readl(mmc_base-pstate) DATI_MASK) == DATI_CMDDIS)
@@ -202,6 +202,9 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
do {
mmc_stat = readl(mmc_base-stat);
+ if (!mmc_stat) {
+ udelay(10);
+ }
retry--;
} while ((mmc_stat == 0) (retry 0));
--
1.6.3.3
___
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 Wolfgang Denk,
In message4cc5e865.70...@emk-elektronik.de you wrote:
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.
Are you sure? My very first smaple sees:
arch/arm/cpu/arm926ejs/start.S
346 /* Set up the stack
*/
347 stack_setup:
348 ldr r0, _TEXT_BASE /* upper 128 KiB: relocated uboot
*/
349 sub sp, r0, #128/* leave 32 words for abort-stack
*/
350 #ifndef CONFIG_PRELOADER
351 sub r0, r0, #CONFIG_SYS_MALLOC_LEN /* malloc area
*/
352 sub r0, r0, #CONFIG_SYS_GBL_DATA_SIZE /* bdinfo
*/
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.
in start.S:
/* Set stackpointer in internal RAM to call board_init_f */
call_board_init_f:
ldr sp, =(CONFIG_SYS_INIT_SP_ADDR)
ldr r0,=0x
bl board_init_f
in board.c:
void board_init_f (ulong bootflag)
{
bd_t *bd;
init_fnc_t **init_fnc_ptr;
gd_t *id;
ulong addr, addr_sp;
/* Pointer is writable since we allocated a register for it */
gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
So global data is at CONFIG_SYS_INIT_SP_ADDR, stack goes down from
CONFIG_SYS_INIT_SP_ADDR.
Board maintainers for ARM should be aware that CONFIG_SYS_INIT_SP_ADDR
should point to RAM with enough space for global data above and enough
stack space below.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] mmc: omap: timeout counter fix
Menon, Nishanth had written, on 10/25/2010 06:33 PM, the following:
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 a udelay(10) to ensure we have a predictable delay.
use an emperical number - 10 uSec ~= 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
---
drivers/mmc/omap_hsmmc.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 9271470..9b03ce1 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -137,7 +137,7 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
{
hsmmc_t *mmc_base = (hsmmc_t *)mmc-priv;
unsigned int flags, mmc_stat;
- unsigned int retry = 0x10;
+ unsigned int retry = 10;
while ((readl(mmc_base-pstate) DATI_MASK) == DATI_CMDDIS)
@@ -202,6 +202,9 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
do {
mmc_stat = readl(mmc_base-stat);
+ if (!mmc_stat) {
+ udelay(10);
+ }
retry--;
} while ((mmc_stat == 0) (retry 0));
I am dropping this patch instead will post a major timeout cleanup for
omap_hsmmc.c - caught a few other kickers as well :(.. darn the polling
logic is so broken in the code :(
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] 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 a udelay(10) to ensure we have a predictable delay.
use an emperical number - 10 uSec ~= 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
---
V2: 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 | 114 +++---
1 files changed, 97 insertions(+), 17 deletions(-)
diff --git a/drivers/mmc/omap_hsmmc.c b/drivers/mmc/omap_hsmmc.c
index 9271470..f7bdfe9 100644
--- a/drivers/mmc/omap_hsmmc.c
+++ b/drivers/mmc/omap_hsmmc.c
@@ -30,6 +30,7 @@
#include twl4030.h
#include asm/io.h
#include asm/arch/mmc_host_def.h
+#define MAX_RETRY 10
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);
@@ -70,18 +71,32 @@ unsigned char mmc_board_init(hsmmc_t *mmc_base)
void mmc_init_stream(hsmmc_t *mmc_base)
{
+ int retry = MAX_RETRY;
writel(readl(mmc_base-con) | INIT_INITSTREAM, mmc_base-con);
writel(MMC_CMD0, mmc_base-cmd);
- while (!(readl(mmc_base-stat) CC_MASK))
- ;
+ while (!(readl(mmc_base-stat) CC_MASK)) {
+ retry--;
+ udelay(10);
+ if (!retry) {
+ 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))
- ;
+ retry = MAX_RETRY;
+ while (!(readl(mmc_base-stat) CC_MASK)) {
+ retry--;
+ udelay(10);
+ if (!retry) {
+ printf(%s: timedout waiting for cc2!\n, __func__);
+ return;
+ }
+ }
writel(readl(mmc_base-con) ~INIT_INITSTREAM, mmc_base-con);
}
@@ -91,16 +106,31 @@ static int mmc_init_setup(struct mmc *mmc)
hsmmc_t *mmc_base = (hsmmc_t *)mmc-priv;
unsigned int reg_val;
unsigned int dsor;
+ int retry = MAX_RETRY;
mmc_board_init(mmc_base);
writel(readl(mmc_base-sysconfig) | MMC_SOFTRESET,
mmc_base-sysconfig);
- while ((readl(mmc_base-sysstatus) RESETDONE) == 0)
- ;
+ while ((readl(mmc_base-sysstatus) RESETDONE) == 0) {
+ retry--;
+ udelay(10);
+ if (!retry) {
+ 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)
- ;
+ retry = MAX_RETRY;
+ while ((readl(mmc_base-sysctl) SOFTRESETALL) != 0x0) {
+ retry--;
+ udelay(10);
+ if (!retry) {
+ 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 +146,15 @@ 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)
- ;
+ retry = MAX_RETRY;
+ while ((readl(mmc_base-sysctl) ICS_MASK) == ICS_NOTREADY) {
+ retry--;
+ udelay(10);
+ if (!retry) {
+ 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 +174,27 @@ static int mmc_send_cmd(struct mmc *mmc, struct mmc_cmd
*cmd,
{
hsmmc_t *mmc_base = (hsmmc_t *)mmc-priv;
unsigned int flags, mmc_stat;
- unsigned int retry = 0x10;
+ int retry = MAX_RETRY;
-
Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
Dear Nishanth Menon,
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 a udelay(10) to ensure we have a predictable delay.
use an emperical number - 10 uSec ~= 1sec for a worst case timeout.
This should never happen, and is adequate imaginary condition for us
to fail with timeout.
In such cases I prefer to use:
uint64_t etime;
...
etime = get_ticks() + get_tbclk(); /* 1 second */
do {
whatever;
udelay (xx);
} while (condition get_ticks() = etime);
That is far more accurate than calling udelay() 10 times.
(depending on implementation and granularity udelay of a few usecs
might be rounded significantly)
You can still call udelay inside the loop if you don't want
to poll the condition too tightly...
Best Regards,
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
Reinhard Meyer had written, on 10/25/2010 08:14 PM, the following:
Dear Nishanth Menon,
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 a udelay(10) to ensure we have a predictable delay.
use an emperical number - 10 uSec ~= 1sec for a worst case timeout.
This should never happen, and is adequate imaginary condition for us
to fail with timeout.
In such cases I prefer to use:
uint64_t etime;
...
etime = get_ticks() + get_tbclk(); /* 1 second */
do {
whatever;
udelay (xx);
} while (condition get_ticks() = etime);
That is far more accurate than calling udelay() 10 times.
(depending on implementation and granularity udelay of a few usecs
might be rounded significantly)
You can still call udelay inside the loop if you don't want
to poll the condition too tightly...
hmmm.. almost like the jiffies in kernel ;).. timing wise, I see that
the only benefit is that the approach gives a little more accuracy to
the timeout delay - the other benefit is option to loop continuously
instead of delaying with udelays - overall, at least the segments I saw
had no reason to hit the registers so hard (alright we dont have much
else to do.. but still).. I am very open to options from
Sukumar(original author) as well..
--
Regards,
Nishanth Menon
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Pull request u-boot-blackfin.git
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(-) ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2 2/2] mx51evk: correct internal RAM base address
The internal RAM starts from 0x1FFE on final revsion i.mx51 than 0x1FFE8000 which is for older revision. Signed-off-by: Shawn Guo shawn@gmail.com --- Changes for v2: Rewrite the commit message for a better change log. arch/arm/include/asm/arch-mx5/imx-regs.h |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/arm/include/asm/arch-mx5/imx-regs.h b/arch/arm/include/asm/arch-mx5/imx-regs.h index 3ddda40..bcab3db 100644 --- a/arch/arm/include/asm/arch-mx5/imx-regs.h +++ b/arch/arm/include/asm/arch-mx5/imx-regs.h @@ -26,7 +26,7 @@ /* * IRAM */ -#define IRAM_BASE_ADDR 0x1FFE8000 /* internal ram */ +#define IRAM_BASE_ADDR 0x1FFE /* internal ram */ /* * Graphics Memory of GPU */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Report ready to go
Fellow investors, AVEW closed out the day Monday (10/25/10) with a reduction in p r i c e per s h a r e of -25%. The p r i c e per s h a r e of AVEW is now $0.0075 per s h a r e. For those of you who have been following AVEW, you already know that this is a gr8t p r i c e per s h a r e! Have a look at the Historical Report On AVEW. Tomorrow we are expecting a steady rise in the p r i c e per s h a r e as well as v o l u m e, we feel now is the time to do the DUE on AVEW. AVEW Investor Relations Transparency and regular communication with our shareholders is a priority for ActionView International, and we will continue to e x plore additional avenues through which this information can be delivered. -- Actionview International, Inc. Chairman Gary Nerison. Actionview International, Inc. (Stock Symbol: AVEW), our wholly owned subsidiary MatchF i g h ts LLC (MatchF i g h ts.com) and our World Championship Full Contact (WCFC.com) brand is proud to present the very latest in action sports entertainment -- AVEW Overview Full contact f i g h t ing brought to you live, over the internet in streaming high definition format. WCFC (Ticker: AVEW) is designed to appeal to a large, global audience. They have made their events faster paced, more intriguing and more fan oriented by incorporating unique features like: ~No Tap Outs ~Two Minute Rounds ~No Judges ~F a n s Vote Online For The Winner With live internet broadcast, pay-per-view product WCFC (Ticker: AVEW) events are not r e s t r i c t e d by t.v contracts or county borders. Anyone, anywhere that has an internet connection can watch an event and participate through our interactive interface. Disclaimer http://www.212stocks.com/news/unsubscribe.php?M=180658C=8a006dcf4980681129279bb1f29c19f7L=15N=47 The disclaimer is to be read and fully understood before using our site or joining our email list. PLEASE NOTE WELL: The employees of InvestorClueso.com are not Registered as Investment Advisors in any jurisdiction whatsoever. Release of L i a b i l i t y: Through use of this website, viewing or using any of the information, you agree to hold InvestorClueso.com, its operators, owners and employees harmless and to completely release them from any and all abligation due to any and all loss (monetary or otherwise), d a m a ge (monetary or otherwise), or i n j u r y (monetary or otherwise) that you may incur. The information contained herein is based on sources which we believe to be reliable but is not guaranteed by us as being accurate and does not purport to be a complete statement or summary of the available data. Any opinions expressed are subject to change without notice. InvestorClueso.com encourages readers and investors to supplement the information in these reports with independent research and other professional advice. All information on featured companies is provided by the companies profiled or is available from public sources; Investor Clueso, LLC makes no representations, warranties or guarantees as to the accuracy or completeness of the disclosure by the profiled companies. Neither Investor Clueso, LLC nor any of its affiliates are registered investment advisors or broker dealers http://www.212stocks.com/news/unsubscribe.php?M=180658C=8a006dcf4980681129279bb1f29c19f7L=15N=47 Entourage Group Inc. 11511 sw 81 rd Miami Fl 33156 7862669555 ___ 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
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Wolfgang Denk Sent: Tuesday, October 26, 2010 10:06 AM To: Menon, Nishanth Cc: u-boot Subject: Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix Dear Nishanth Menon, In message 1288054924-24989-1-git-send-email...@ti.com you wrote: 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 a udelay(10) to ensure we have a predictable delay. use an emperical number - 10 uSec ~= 1sec for a worst case timeout. Hm... 10 usec = 0.1 sec only... Guess you mean 100,000 x 10 usec = 1 sec ? Best regards, Wolfgang Denk [..snip..] [Menon, Nishanth] - overall, at least the segments I saw had no reason to hit the registers so hard (alright we dont have much else to do.. but still).. I am very open to options from Sukumar(original author) as well.. [Ghorai] I am agreeing with the part where it's looks while(1) loop. And can add retry counter too. otherwise I feel I will increase the boot time. ___ 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 4cc62b6c.30...@emk-elektronik.de you wrote:
In such cases I prefer to use:
uint64_t etime;
...
etime = get_ticks() + get_tbclk(); /* 1 second */
do {
whatever;
udelay (xx);
} while (condition get_ticks() = etime);
That is far more accurate than calling udelay() 10 times.
It may be more accuratre, but it may also be HORRIBLY WRONG!!
Do NOT do that!! NEVER implement such a delay loop as
end = time() + delay;
while (time() end)
...
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.
Correct implementation of a timeout like that should always look like
that:
start = time();
while ((time() - start) delay)
...
This works much better (assuming unsigned arithmetics).
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
Ein weiser Herrscher kann in einem großen Land mehr Gutes bewirken
als in einem kleinen - ein dummer Herrscher aber auch viel mehr Un-
fug. Da weise Herrscher seltener sind als dumme, war ich schon immer
gegen große Reiche skeptisch. - Herbert Rosendorfer
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/2] NDS32: Add N1213 cpu core related stuff.
These patch set have been refreshed and created against mainline master branch. These patches changes from previous PATCH v3: NDS32: Add NDS32 architecture support to u-boot. In order to make these patches could be easily review and maintained, I've split the original Patch v3 into small pieces. Necessary header files for the later patches has been sent already in: [PATCH v4 00/01] NDS32: Add NDS32 architecture support to u-boot. nds32: add header files support for nds32 - PATCH v4 here means there are only header files which has been clean up already for replacing the previous Patch sets v1-v3. CPU and other SoC related stuff has been reorganized based on these header files, so a new patch set should be started. The following two patches provides the necessary functions for supporting N1213 cpu core in u-boot. These files provides the link script and the start.S of N1213 cpu core. File common.h is also required to be changed to support these files. Macpaul Lin (2): nds32: add NDS32 support into common header file nds32/Core_N1213: add N1213 cpu core support for NDS32 arch -- 1.7.3.1 ___ 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 Nishanth Menon, In message 4cc62c81.8000...@ti.com you wrote: You can still call udelay inside the loop if you don't want to poll the condition too tightly... hmmm.. almost like the jiffies in kernel ;).. timing wise, I see that Yes, except for the bugs... ;-) 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 Der Horizont vieler Menschen ist ein Kreis mit Radius Null -- und das nennen sie ihren Standpunkt. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] nds32: add NDS32 support into common header file
Add NDS32 support into common header file. Signed-off-by: Macpaul Lin macp...@andestech.com --- include/common.h |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/common.h b/include/common.h index 6a79ec2..1f3bc32 100644 --- a/include/common.h +++ b/include/common.h @@ -274,6 +274,10 @@ void forceenv (char *, char *); #ifdef CONFIG_I386 /* x86 version to be fixed! */ # include asm/u-boot-i386.h #endif /* CONFIG_I386 */ +#ifdef CONFIG_NDS32 +# include asm/mach-types.h +# include asm/u-boot-nds32.h /* NDS32 version to be fixed! */ +#endif /* CONFIG_NDS32 */ #ifdef CONFIG_AUTO_COMPLETE int env_complete(char *var, int maxv, char *cmdv[], int maxsz, char *buf); -- 1.7.3.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] nds32/Core_N1213: add N1213 cpu core support for NDS32 arch
Add N1213 cpu core support for NDS32 arch. Included lowlevel_init procedures, and linker scripts. NDS32 Core N1213 has the following features. Core: - 16-/32-bit mixable instruction format - 32 general-purpose 32-bit registers - 8-stage pipeline - Dynamic branch prediction - 32/64/128/256 BTB - Return address stack (RAS) - Vector interrupts for internal/external - 3 HW-level nested interruptions - User and super-user mode support - Memory-mapped I/O - Address space up to 4GB Memory Management Unit: - TLB - Optional hardware page table walker - Two groups of page size support Memory Subsystem: - I D cache - I D local memory (LM) Bus Interface: - Synchronous/Asynchronous AHB bus: 0, 1 or 2 ports start.S will start up the CPU core at first, then jump to SoC dependent lowlevel_init.S and watchdog.S to configure peripheral devices. Signed-off-by: Macpaul Lin macp...@andestech.com --- arch/nds32/cpu/n1213/Makefile | 50 + arch/nds32/cpu/n1213/start.S| 449 +++ arch/nds32/cpu/n1213/u-boot.lds | 68 ++ 3 files changed, 567 insertions(+), 0 deletions(-) create mode 100644 arch/nds32/cpu/n1213/Makefile create mode 100644 arch/nds32/cpu/n1213/start.S create mode 100644 arch/nds32/cpu/n1213/u-boot.lds diff --git a/arch/nds32/cpu/n1213/Makefile b/arch/nds32/cpu/n1213/Makefile new file mode 100644 index 000..3b66a57 --- /dev/null +++ b/arch/nds32/cpu/n1213/Makefile @@ -0,0 +1,50 @@ +# +# (C) Copyright 2000, 2001, 2002 +# Wolfgang Denk, DENX Software Engineering, w...@denx.de. +# +# Copyright (C) 2010 Andes Technology Corporation +# Shawn Lin, Andes Technology Corporation nobuh...@andestech.com +# Macpaul Lin, Andes Technology Corporation macp...@andestech.com +# +# See file CREDITS for list of people who contributed to this +# project. +# +# This program is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# This program is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with this program; if not, write to the Free Software +# Foundation, Inc., 59 Temple Place, Suite 330, Boston, +# MA 02111-1307 USA +# + +include $(TOPDIR)/config.mk + +LIB= $(obj)lib$(CPU).a + +START = start.o + +SRCS:= $(START:.o=.S) $(SOBJS:.o=.S) $(COBJS:.o=.c) +OBJS:= $(addprefix $(obj),$(COBJS) $(SOBJS)) +START := $(addprefix $(obj),$(START)) + +all: $(obj).depend $(START) $(LIB) + +$(LIB):$(OBJS) + $(AR) $(ARFLAGS) $@ $(OBJS) + +# + +# defines $(obj).depend target +include $(SRCTREE)/rules.mk + +sinclude $(obj).depend + +# diff --git a/arch/nds32/cpu/n1213/start.S b/arch/nds32/cpu/n1213/start.S new file mode 100644 index 000..411fa1f --- /dev/null +++ b/arch/nds32/cpu/n1213/start.S @@ -0,0 +1,449 @@ +/* + * Andesboot - Startup Code for Whitiger core + * + * Copyright (C) 2006 Andes Technology Corporation + * Copyright (C) 2006 Shawn Lin nobuh...@andestech.com + * Copyright (C) 2010 Macpaul macp...@andestech.com + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +#include config.h +#include common.h +#include version.h + +! +! Jump vector table for EVIC mode +! + +#define ENA_DCAC 2UL +#define DIS_DCAC ~ENA_DCAC +#define ICAC_MEM_KBF_ISET (0x07) ! I Cache sets per way +#define ICAC_MEM_KBF_IWAY (0x073) ! I cache ways +#define ICAC_MEM_KBF_ISZ (0x076) ! I cache line size +#define DCAC_MEM_KBF_DSET (0x07) ! D Cache sets per way +#define DCAC_MEM_KBF_DWAY
Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
-Original Message-
From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de]
On Behalf Of Wolfgang Denk
Sent: Tuesday, October 26, 2010 10:59 AM
To: Reinhard Meyer
Cc: Menon, Nishanth; u-boot
Subject: Re: [U-Boot] [PATCH v2] mmc: omap: timeout counter fix
Dear Reinhard Meyer,
In message 4cc62b6c.30...@emk-elektronik.de you wrote:
In such cases I prefer to use:
uint64_t etime;
...
etime = get_ticks() + get_tbclk(); /* 1 second */
do {
whatever;
udelay (xx);
} while (condition get_ticks() = etime);
That is far more accurate than calling udelay() 10 times.
It may be more accuratre, but it may also be HORRIBLY WRONG!!
Do NOT do that!! NEVER implement such a delay loop as
end = time() + delay;
while (time() end)
...
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.
Correct implementation of a timeout like that should always look like
that:
start = time();
while ((time() - start) delay)
...
This works much better (assuming unsigned arithmetics).
[Ghorai] Thanks.. This is the best approach.
Otherwise udelay() will increase the boot time.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
Ein weiser Herrscher kann in einem großen Land mehr Gutes bewirken
als in einem kleinen - ein dummer Herrscher aber auch viel mehr Un-
fug. Da weise Herrscher seltener sind als dumme, war ich schon immer
gegen große Reiche skeptisch. - Herbert Rosendorfer
___
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] Mail list threading problem or mailer problem?
Dear Shawn Guo, In message aanlkti=zf_cadtwt_y0yqkzy1ps41nwor=yn2p69m...@mail.gmail.com you wrote: Is this some problem with u-boot mail list threading itself or the gmail mailer? As Mike already pointed out, this appears to be a problem with the gmail'w web interface. At http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/87453 you can see how other tools display this thread. 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 equals success, then the formula is A = X + Y + Z. X is work. Y is play. Z is keep your mouth shut. - Albert Einstein ___ 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?
Hi Mike, I did not mean the threading view in gmail web client, but http://lists.denx.de/pipermail/u-boot/2010-October/thread.html The message-id and in-reply-to matches, and the same way works good with linux-arm-kernel list. I also see others' messages having same problem in u-boot list. On Tue, Oct 26, 2010 at 1:08 PM, Mike Frysinger vap...@gentoo.org wrote: On Mon, Oct 25, 2010 at 10:31 PM, Shawn Guo wrote: But I really expect something like below (added In-Reply-To ID). gmail does not respect the reply-to headers when threading stuff in its web client if you have any questions beyond that, look at the raw e-mail and make sure the message id and in reply to headers match. if they dont, it's a bug in whoever sent the e-mail. -mike -- Regards, Shawn ___ 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,
In message4cc62b6c.30...@emk-elektronik.de you wrote:
In such cases I prefer to use:
uint64_t etime;
...
etime = get_ticks() + get_tbclk(); /* 1 second */
do {
whatever;
udelay (xx);
} while (condition get_ticks()= etime);
That is far more accurate than calling udelay() 10 times.
It may be more accuratre, but it may also be HORRIBLY WRONG!!
Do NOT do that!! NEVER implement such a delay loop as
end = time() + delay;
while (time() end)
...
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...
If get_ticks() is only 32 bits worth, both methods will misbehave
at a 32 bit wrap over.
Correct implementation of a timeout like that should always look like
that:
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...
Best would be to assign get_ticks() to a 32 bit unsigned and use
32 bit vars for start and delay as well.
The original udelay() implementation in AT91 would have failed
at a 32 bit wrap over, too (fixed in mainline). I hope other
implementations are done right, too...
Best regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
