Re: [U-Boot] [PATCH v2] lib/hashtable.c: add CONFIG_ENV_MIN_ENTRIES
Dear Wolfgang Denk, Am 06.10.2010 um 22:47 schrieb Wolfgang Denk: Dear =?UTF-8?q?Andreas=20Bie=C3=9Fmann?=, In message 1285966262-73388-1-git-send-email-andreas.de...@googlemail.com you wrote: lib/hashtable.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) Applied, thanks. Best regards, Wolfgang Denk couldn't find this patch mainline. Where did it go? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] board/mpl: Remove mpl-specific memory test command
Peter Tyser schrieb: On Wed, 2010-10-06 at 22:27 +0200, Wolfgang Denk wrote: I think you are right. If you have tiome, please submit patches to remove these, then we will see if anybody cares. Will do. I'm currently trying to bring the VCMA9 port in sync with the recently introduced ARM relocation support feature. Dave signature.asc Description: OpenPGP digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc91111: add write_hwaddr
On 10/07/2010 06:27 PM, Detlev Zundel wrote: Hi Wolfgang, Dear Thomas Chou, In message4cac0b1e.1050...@wytron.com.tw you wrote: I was confused by the greylisting of denx mail server and wondered why the first mail was not received after 12 hours. There is no greylisting on our side. Well actually we do run postgrey. But as yet we did not get any complaints that this interferes with regular usage. The default values of the software should not intrude much on completely unfiltered traffic. Dear Wolfgang and Detlev, The retransmission wait time on my first mail server is quite long and I forgot that there is postgrey on denx mail server, so I sent the patch again using another mail server. I wondered if my first mail server changed IP. Sorry for the noise. Best regards, Thomas ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] Kirkwood: Changes specific to ARM relocation support
Le 07/10/2010 16:58, Prafulla Wadaskar a écrit : All Kirkwood based boards are supported for this new implementation ref: docs/README.arm-relocation Signed-off-by: Prafulla Wadaskarprafu...@marvell.com BTW, Wolfgang, is your offer to provide a branch to put ELF relocation related changes still valid? Even periodically rebased against master would be perfect... Otherwise I can set one up if you prefer. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Crash in env_relocate_spec() of env_mmc.c
Steve Sakoman wrote: Hi Steve, I've been attempting to get the OMAP4 boards working post the ARM relocation changes. Panda was simple. The OMAP4430SDP is proving to be more challenging, as it freezes after printing the DRAM size message. Adding a few printfs revealed that the crash occurs in env_mmc.c's env_relocate_spec() routine. Has anyone else run into this issue? Any advice? I tested, I can see the same issue. The main problem is that mmc_initialize is not called before mmc_init() in arch/arm/lib/board.c if relocation is active. In start_armboot it is called before. The second problem I see is that env_relocate_spec should call env_import() as already done by other environment (I checked with env_nand). I can send a patch that at least on my target solves the problem. Could you test it ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] Crash in env_relocate_spec() of env_mmc.c
mmc_initialize is not called at the startup if the
relocation takes place and the environment is stored
into a MMC card.
Signed-off-by: Stefano Babic sba...@denx.de
---
arch/arm/lib/board.c | 10 +-
common/env_mmc.c | 11 +--
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 5f2dfd0..704ddcb 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -775,6 +775,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
nand_init();/* go init the NAND */
#endif
+#ifdef CONFIG_GENERIC_MMC
+ puts (MMC: );
+ mmc_initialize (bd);
+#endif
+
#if defined(CONFIG_CMD_ONENAND)
onenand_init();
#endif
@@ -854,11 +859,6 @@ extern void davinci_eth_set_mac_addr (const u_int8_t
*addr);
board_late_init ();
#endif
-#ifdef CONFIG_GENERIC_MMC
- puts (MMC: );
- mmc_initialize (gd-bd);
-#endif
-
#ifdef CONFIG_BITBANGMII
bb_miiphy_init();
#endif
diff --git a/common/env_mmc.c b/common/env_mmc.c
index 14203b6..cb7c448 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -130,24 +130,23 @@ void env_relocate_spec(void)
{
#if !defined(ENV_IS_EMBEDDED)
struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV);
+ char buf[CONFIG_ENV_SIZE];
if (init_mmc_for_env(mmc))
return;
- if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, env_ptr))
- return use_default();
-
- if (crc32(0, env_ptr-data, ENV_SIZE) != env_ptr-crc)
+ if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, buf))
return use_default();
gd-env_valid = 1;
+
+ env_import(buf, 1);
#endif
}
#if !defined(ENV_IS_EMBEDDED)
static void use_default()
{
- puts (*** Warning - bad CRC or MMC, using default environment\n\n);
- set_default_env();
+ set_default_env(*** Warning - bad CRC or MMC, using default
environment\n\n);
}
#endif
--
1.6.3.3
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2] lib/hashtable.c: add CONFIG_ENV_MIN_ENTRIES
Dear =?iso-8859-1?Q?Andreas_Bie=DFmann?=, In message f2da4aea-d25a-4355-9727-715e47ae8...@googlemail.com you wrote: lib/hashtable.c | 12 1 files changed, 8 insertions(+), 4 deletions(-) Applied, thanks. Best regards, Wolfgang Denk couldn't find this patch mainline. Where did it go? commit fc5fc76bdad14425e3743e1494c9e444570df1be Author: Andreas Bießmann andreas.de...@googlemail.com Date: Fri Oct 1 22:51:02 2010 +0200 lib/hashtable.c: add CONFIG_ENV_MIN_ENTRIES See http://git.denx.de/?p=u-boot.git;a=commit;h=fc5fc76bdad14425e3743e1494c9e444570df1be Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de Quotation, n. The act of repeating erroneously the words of another. The words erroneously repeated. - Ambrose Bierce _The Devil's Dictionary_ ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] include/compiler.h: remove uint typedef for __MACH__
Dear =?iso-8859-1?Q?Andreas_Bie=DFmann?=, In message e0a9e8c7-f2f2-40d7-a71f-40c92d2b8...@googlemail.com you wrote: include/compiler.h |1 - 1 files changed, 0 insertions(+), 1 deletions(-) Applied, thanks. Best regards, Wolfgang Denk couldn't find this patch mainline. Where did it go? commit 59336459042a5fccb2dda9cfbb592802c88f583d Author: Andreas Bießmann andreas.de...@googlemail.com Date: Sat Sep 25 17:45:59 2010 +0200 include/compiler.h: remove uint typedef for __MACH__ See http://git.denx.de/?p=u-boot.git;a=commit;h=59336459042a5fccb2dda9cfbb592802c88f583d 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 History is only a confused heap of facts. -- Philip Earl of Chesterfield ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] smc91111: add write_hwaddr
Dear Thomas Chou, In message 4caec4cd.6050...@wytron.com.tw you wrote: The retransmission wait time on my first mail server is quite long and I forgot that there is postgrey on denx mail server, so I sent the patch again using another mail server. I wondered if my first mail server changed IP. Sorry for the noise. No problem. It was informative for me, too, as I learned that we're running postgrey. I didn't know that before. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de The game of life is a game of boomerangs. Our thoughts, deeds and words return to us sooner or later with astounding accuracy. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] Kirkwood: Changes specific to ARM relocation support
Dear Albert ARIBAUD, In message 4caece3e.6020...@free.fr you wrote: BTW, Wolfgang, is your offer to provide a branch to put ELF relocation related changes still valid? Even periodically rebased against master would be perfect... Otherwise I can set one up if you prefer. Of course this is still valid, but - I'm late with updating the u-boot-arm repo because I got stuck in this little task I started to make some progress with the Makefile / boards.cfg cleanup (that turned out to burn more time than expected) - I lost a bit track of which exact version of the patches I should use. If you could please be so kind and send me a short reference to the current ones (messag-ID or similar). Thanks. Best regards, Wolfgang Denk -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de I find this a nice feature but it is not according to the documen- tation. Or is it a BUG? Let's call it an accidental feature. :-) - Larry Wall in 6...@jpl-devvax.jpl.nasa.gov ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH V2 3/3] Kirkwood: Changes specific to ARM relocation support
Le 08/10/2010 10:32, Wolfgang Denk a écrit : Dear Albert ARIBAUD, In message4caece3e.6020...@free.fr you wrote: BTW, Wolfgang, is your offer to provide a branch to put ELF relocation related changes still valid? Even periodically rebased against master would be perfect... Otherwise I can set one up if you prefer. Of course this is still valid, but - I'm late with updating the u-boot-arm repo because I got stuck in this little task I started to make some progress with the Makefile / boards.cfg cleanup (that turned out to burn more time than expected) - I lost a bit track of which exact version of the patches I should use. If you could please be so kind and send me a short reference to the current ones (messag-ID or similar). Actually I'd sent out a first [PATCH] set but have to do a couple of fixes based on comments to it; later today I'll send a [PATCH V2] version which I'll tag [ELF RELOC] to differenciate it from master patches. Thanks. Thanks to you. Best regards, Wolfgang Denk Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch/arm/include/asm/sizes.h: cleanups
Am 24.09.2010 23:31, schrieb Andreas Bießmann: Merge several sizes.h in asm/arch subdirectories into a single asm/sizes.h file. Fixup usage of asm/arch/sizes.h in some files to use the merged file. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com Any comment on that patch? Should I resend, is any action required from my side? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] arch/arm/include/asm/sizes.h: cleanups
Am 24.09.2010 23:31, schrieb Andreas Bießmann: Merge several sizes.h in asm/arch subdirectories into a single asm/sizes.h file. Fixup usage of asm/arch/sizes.h in some files to use the merged file. Signed-off-by: Andreas Bießmann andreas.de...@googlemail.com --- These changes where submitted in 2008 but never applied. See http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/44229 It is not necessary to have several copies of files with nearly the same content. arch/arm/include/asm/arch-arm925t/sizes.h | 50 arch/arm/include/asm/arch-arm926ejs/sizes.h | 51 arch/arm/include/asm/arch-omap/sizes.h| 52 - arch/arm/include/asm/arch-omap24xx/omap2420.h |2 +- arch/arm/include/asm/arch-omap24xx/sizes.h| 49 --- arch/arm/include/asm/sizes.h |5 +- include/configs/h2_p2_dbg_board.h |2 +- include/configs/omap1510.h|2 +- include/configs/omap730.h |2 +- 9 files changed, 6 insertions(+), 209 deletions(-) delete mode 100644 arch/arm/include/asm/arch-arm925t/sizes.h delete mode 100644 arch/arm/include/asm/arch-arm926ejs/sizes.h delete mode 100644 arch/arm/include/asm/arch-omap/sizes.h delete mode 100644 arch/arm/include/asm/arch-omap24xx/sizes.h Any comment on that patch? Is any action from my side required? I'd only get attraction on this patch cause some changes needed for my at91rm9200ek transition to new at91 code which will arrive in some days. regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] u-boot vs. Cavium 5010 pci init
Who debuged u-boot on the board based on Cavium CN5010? Thanks! Shuyou -Original Message- From: Wolfgang Denk [mailto:w...@denx.de] Sent: 2010年9月26日 16:56 To: Graeme Russ Cc: sywang; u-boot@lists.denx.de Subject: Re: [U-Boot] u-boot vs. Cavium 5010 pci init Dear Graeme Russ, In message 4c9f087d.3010...@gmail.com you wrote: Cavium never provided free access to their code, nor did they ever attempt to push their changes upstream. Would they not, therefore, be in breach of the GPL? According to the GPL, you don't have to provide free access to everybody. It is sufficient to accompany the delivery of U-Boot to each of their customers with a written offer to provide any third party a copy of the corresponding source code. Of course, each of Cavium's customers could request that code, and then put it on a public server - but it seems nobody ever did. 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 Was heißt Windows auf Indianisch? - Weißer Mann, der auf Sanduhr wartet! ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Crash in env_relocate_spec() of env_mmc.c
Hello. On 08-10-2010 12:03, Stefano Babic wrote: mmc_initialize is not called at the startup if the relocation takes place and the environment is stored into a MMC card. Signed-off-by: Stefano Babicsba...@denx.de [...] diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c index 5f2dfd0..704ddcb 100644 --- a/arch/arm/lib/board.c +++ b/arch/arm/lib/board.c @@ -775,6 +775,11 @@ void board_init_r (gd_t *id, ulong dest_addr) nand_init();/* go init the NAND */ #endif +#ifdef CONFIG_GENERIC_MMC + puts (MMC: ); + mmc_initialize (bd); This wouldn't pass checkpatch.pl. Spaces before ( are not allowed. WBR, Sergei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ELF_RELOC] [PATCH V2 2/2] edminiv2: add support for ELF relocations
Signed-off-by: Albert Aribaud albert.arib...@free.fr --- board/LaCie/edminiv2/config.mk |4 ++-- include/configs/edminiv2.h |5 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/board/LaCie/edminiv2/config.mk b/board/LaCie/edminiv2/config.mk index 3dec1aa..942c4e5 100644 --- a/board/LaCie/edminiv2/config.mk +++ b/board/LaCie/edminiv2/config.mk @@ -23,5 +23,5 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301 USA # - -TEXT_BASE = 0x0010 +# TEXT_BASE must equal the intended FLASH location of u-boot. +TEXT_BASE = 0xfff9 \ No newline at end of file diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index ccfc660..43e5e87 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -223,4 +223,9 @@ #define CONFIG_SYS_RESET_ADDRESS 0x #define CONFIG_SYS_MAXARGS 16 +/* additions for new relocation code, must be added to all boards */ +#define CONFIG_SYS_SDRAM_BASE 0 +#define CONFIG_SYS_INIT_SP_ADDR\ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) + #endif /* _CONFIG_EDMINIV2_H */ -- 1.7.0.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [ELF_RELOC] [PATCH V2 1/2] arm: implement ELF relocations
ELF relocation tables generated with linker option -pie can be used to fixup code and data in a single loop at relocation, removing the need for manual fixups anywhere else in the code. Signed-off-by: Albert Aribaud albert.arib...@free.fr --- This patch set is intended for the ELF relocation branch, not for master or next! V1 Initial submission after RFC V2 Removed useless datarel references and sections Defined CONFIG_RELOC_FIXUP_WORKS for all ARMs Removed useless define of CONFIG_RELOC_FIXUP_WORKS and undefine of CONFIG_SYS_ARM_WITHOUT_RELOC from edminiv2 board arch/arm/config.mk| 10 +- arch/arm/cpu/arm926ejs/start.S| 164 ++- arch/arm/cpu/arm926ejs/u-boot.lds | 26 +++-- arch/arm/include/asm/config.h |2 - arch/arm/include/asm/u-boot-arm.h | 14 +- arch/arm/lib/board.c |8 +- doc/README.arm-relocation | 222 +++-- 7 files changed, 156 insertions(+), 290 deletions(-) diff --git a/arch/arm/config.mk b/arch/arm/config.mk index 6923f6d..0be47d3 100644 --- a/arch/arm/config.mk +++ b/arch/arm/config.mk @@ -33,11 +33,6 @@ STANDALONE_LOAD_ADDR = 0xc10 endif endif -ifndef CONFIG_SYS_ARM_WITHOUT_RELOC -# needed for relocation -PLATFORM_RELFLAGS += -fPIC -endif - ifdef CONFIG_SYS_ARM_WITHOUT_RELOC PLATFORM_CPPFLAGS += -DCONFIG_SYS_ARM_WITHOUT_RELOC endif @@ -72,3 +67,8 @@ PLATFORM_LIBS += $(OBJTREE)/arch/arm/lib/eabi_compat.o endif endif LDSCRIPT := $(SRCTREE)/$(CPUDIR)/u-boot.lds + +ifndef CONFIG_SYS_ARM_WITHOUT_RELOC +# needed for relocation +PLATFORM_LDFLAGS += -pie +endif diff --git a/arch/arm/cpu/arm926ejs/start.S b/arch/arm/cpu/arm926ejs/start.S index 16ee972..e5099d0 100644 --- a/arch/arm/cpu/arm926ejs/start.S +++ b/arch/arm/cpu/arm926ejs/start.S @@ -10,6 +10,7 @@ * Copyright (c) 2002 Gary Jennejohn ga...@denx.de * Copyright (c) 2003 Richard Woodruff r-woodru...@ti.com * Copyright (c) 2003 Kshitij kshi...@ti.com + * Copyright (c) 2010 Albert Aribaud albert.arib...@free.fr * * See file CREDITS for list of people who contributed to this * project. @@ -118,22 +119,19 @@ _fiq: _TEXT_BASE: .word TEXT_BASE -#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC) -.globl _armboot_start -_armboot_start: - .word _start -#endif - /* * 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_start_ofs +_bss_start_ofs: + .word __bss_start - _start -.globl _bss_end -_bss_end: - .word _end +.globl _bss_end_ofs +_bss_end_ofs: + .word _end - _start #ifdef CONFIG_USE_IRQ /* IRQ stack memory (calculated at run-time) */ @@ -153,30 +151,6 @@ FIQ_STACK_START: IRQ_STACK_START_IN: .word 0x0badc0de -.globl _datarel_start -_datarel_start: - .word __datarel_start - -.globl _datarelrolocal_start -_datarelrolocal_start: - .word __datarelrolocal_start - -.globl _datarellocal_start -_datarellocal_start: - .word __datarellocal_start - -.globl _datarelro_start -_datarelro_start: - .word __datarelro_start - -.globl _got_start -_got_start: - .word __got_start - -.globl _got_end -_got_end: - .word __got_end - /* * the actual reset code */ @@ -226,9 +200,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 @@ -240,36 +213,54 @@ copy_loop: ble 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] -
Re: [U-Boot] [PATCH] Crash in env_relocate_spec() of env_mmc.c
Sergei Shtylyov wrote: Hello. Hello Sergei, This wouldn't pass checkpatch.pl. Spaces before ( are not allowed. Agree, thanks. I will wait until Steve's feedback to understand if the problem is really solved. Best regards, Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ELF_RELOC] [PATCH V2 2/2] edminiv2: add support for ELF relocations
-Original Message- From: u-boot-boun...@lists.denx.de [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Albert Aribaud Sent: Friday, October 08, 2010 4:54 PM To: u-boot@lists.denx.de Subject: [U-Boot] [ELF_RELOC] [PATCH V2 2/2] edminiv2: add support for ELF relocations Signed-off-by: Albert Aribaud albert.arib...@free.fr --- board/LaCie/edminiv2/config.mk |4 ++-- include/configs/edminiv2.h |5 + 2 files changed, 7 insertions(+), 2 deletions(-) diff --git a/board/LaCie/edminiv2/config.mk b/board/LaCie/edminiv2/config.mk index 3dec1aa..942c4e5 100644 --- a/board/LaCie/edminiv2/config.mk +++ b/board/LaCie/edminiv2/config.mk @@ -23,5 +23,5 @@ # Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, # MA 02110-1301 USA # - -TEXT_BASE = 0x0010 +# TEXT_BASE must equal the intended FLASH location of u-boot. +TEXT_BASE = 0xfff9 \ No newline at end of file ??? diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index ccfc660..43e5e87 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -223,4 +223,9 @@ #define CONFIG_SYS_RESET_ADDRESS 0x #define CONFIG_SYS_MAXARGS 16 +/* additions for new relocation code, must be added to all boards */ +#define CONFIG_SYS_SDRAM_BASE0 +#define CONFIG_SYS_INIT_SP_ADDR \ + (CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) + Orion5182 does have internal Securiy SRAM, you can use it here instead of using SDRAM Regards.. Prafulla . . ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [ELF_RELOC] [PATCH V2 2/2] edminiv2: add support for ELF relocations
Le 08/10/2010 13:33, Prafulla Wadaskar a écrit : -TEXT_BASE = 0x0010 +# TEXT_BASE must equal the intended FLASH location of u-boot. +TEXT_BASE = 0xfff9 \ No newline at end of file ??? Oops. Missed that -- actually, forgot to checkpatch so maybe other errors/warnings may creep up that I will fix in V3. diff --git a/include/configs/edminiv2.h b/include/configs/edminiv2.h index ccfc660..43e5e87 100644 --- a/include/configs/edminiv2.h +++ b/include/configs/edminiv2.h @@ -223,4 +223,9 @@ #define CONFIG_SYS_RESET_ADDRESS 0x #define CONFIG_SYS_MAXARGS 16 +/* additions for new relocation code, must be added to all boards */ +#define CONFIG_SYS_SDRAM_BASE 0 +#define CONFIG_SYS_INIT_SP_ADDR \ +(CONFIG_SYS_SDRAM_BASE + 0x1000 - CONFIG_SYS_GBL_DATA_SIZE) + Orion5182 does have internal Securiy SRAM, you can use it here instead of using SDRAM Thanks for the reminder. I'll give it a try later today. Regards.. Prafulla . . Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Question about PCIe configuration
Em Qui, 2010-10-07 às 09:33 -0500, Swarthout Edward L-SWARTHOU escreveu: The LTSSM value of 8 indicates the problem. See: Table 18-111. PEX_LTSSM_STAT Status Codes 8 - Polling compliance This shows the 8536 is fine and detects the device's receivers on the bus, but the device has not responded with a correct training sequence. There are many potential causes for the device not responding: 1. device powered on? 2. have correct clocks? 3. if an fpga, is it loaded? 4. is it out of reset? I am considering a hardware design issue too, the hardware team is working on that. What is the device? Can you query it with a jtag probe? PCIE1 on bus 01 - 01 I was expecting to find a peripherical on PCIE1 bus. I have a switch chip connected to Serdes 1 lane A. I see. What switch? Is it on a card or directly on the board? Can you probe reset, power, and clocks? A broadcom switch. It is directly on the board. I tried to probe SD1_PLL_TPD (PLL test point Digital, pin V28 on MPC8536 E), there is no signal there. What Should I observe in this pin? I was expecting to observe the internal serdes clock signal. Thanks Carlos R. Moratelli ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Crash in env_relocate_spec() of env_mmc.c
On Fri, Oct 8, 2010 at 12:53 AM, Stefano Babic sba...@denx.de wrote:
Steve Sakoman wrote:
Hi Steve,
I've been attempting to get the OMAP4 boards working post the ARM
relocation changes.
Panda was simple. The OMAP4430SDP is proving to be more challenging,
as it freezes after printing the DRAM size message.
Adding a few printfs revealed that the crash occurs in env_mmc.c's
env_relocate_spec() routine.
Has anyone else run into this issue? Any advice?
I tested, I can see the same issue. The main problem is that
mmc_initialize is not called before mmc_init() in arch/arm/lib/board.c
if relocation is active. In start_armboot it is called before.
The second problem I see is that env_relocate_spec should call
env_import() as already done by other environment (I checked with env_nand).
Heh, great minds! I found the same issues just before going to sleep
last night and put together a quite similar patch.
I tested my version of the patch this morning and it did fix the
issue. I didn't test last night because I feared that if it didn't
work I would stay up too late trying the next thing :-)
I have a few differences in my patch -- I'll comment in a response to
your patch.
My patch is below.
Steve
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 5f2dfd0..0e2f129 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -779,6 +779,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
onenand_init();
#endif
+#ifdef CONFIG_GENERIC_MMC
+ puts (MMC: );
+ mmc_initialize (bd);
+#endif
+
#ifdef CONFIG_HAS_DATAFLASH
AT91F_DataflashInit();
dataflash_print_info();
@@ -854,11 +859,6 @@ extern void davinci_eth_set_mac_addr (const
u_int8_t *addr);
board_late_init ();
#endif
-#ifdef CONFIG_GENERIC_MMC
- puts (MMC: );
- mmc_initialize (gd-bd);
-#endif
-
#ifdef CONFIG_BITBANGMII
bb_miiphy_init();
#endif
diff --git a/common/env_mmc.c b/common/env_mmc.c
index cc288d4..d443ff5 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -129,18 +129,21 @@ inline int read_env(struct mmc *mmc, unsigned long size,
void env_relocate_spec(void)
{
#if !defined(ENV_IS_EMBEDDED)
+ char buf[CONFIG_ENV_SIZE];
+
struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV);
- if (init_mmc_for_env(mmc))
+ if (init_mmc_for_env(mmc)) {
+ use_default();
return;
+ }
- if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, env_ptr))
- return use_default();
-
- if (crc32(0, env_ptr-data, ENV_SIZE) != env_ptr-crc)
- return use_default();
+ if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, buf)) {
+ use_default();
+ return;
+ }
- gd-env_valid = 1;
+ env_import(buf, 1);
#endif
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Crash in env_relocate_spec() of env_mmc.c
On Fri, Oct 8, 2010 at 6:39 AM, Steve Sakoman sako...@gmail.com wrote:
On Fri, Oct 8, 2010 at 1:03 AM, Stefano Babic sba...@denx.de wrote:
mmc_initialize is not called at the startup if the
relocation takes place and the environment is stored
into a MMC card.
Signed-off-by: Stefano Babic sba...@denx.de
---
arch/arm/lib/board.c | 10 +-
common/env_mmc.c | 11 +--
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 5f2dfd0..704ddcb 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -775,6 +775,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
nand_init(); /* go init the NAND */
#endif
+#ifdef CONFIG_GENERIC_MMC
+ puts (MMC: );
+ mmc_initialize (bd);
+#endif
+
#if defined(CONFIG_CMD_ONENAND)
onenand_init();
#endif
@@ -854,11 +859,6 @@ extern void davinci_eth_set_mac_addr (const u_int8_t
*addr);
board_late_init ();
#endif
-#ifdef CONFIG_GENERIC_MMC
- puts (MMC: );
- mmc_initialize (gd-bd);
-#endif
-
#ifdef CONFIG_BITBANGMII
bb_miiphy_init();
#endif
I think it might make more sense to put the MMC ifdef after the
onenand code so that it doesn't split the nand/onenand grouping.
Otherwise it matches what I did.
diff --git a/common/env_mmc.c b/common/env_mmc.c
index 14203b6..cb7c448 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -130,24 +130,23 @@ void env_relocate_spec(void)
{
#if !defined(ENV_IS_EMBEDDED)
struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV);
+ char buf[CONFIG_ENV_SIZE];
if (init_mmc_for_env(mmc))
return;
- if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, env_ptr))
- return use_default();
-
- if (crc32(0, env_ptr-data, ENV_SIZE) != env_ptr-crc)
+ if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, buf))
return use_default();
This is a void function and shouldn't have a return value. I fixed
this in my version.
gd-env_valid = 1;
I removed this in my version, probably an error to do that though :-)
+
+ env_import(buf, 1);
#endif
}
#if !defined(ENV_IS_EMBEDDED)
static void use_default()
{
- puts (*** Warning - bad CRC or MMC, using default environment\n\n);
- set_default_env();
+ set_default_env(*** Warning - bad CRC or MMC, using default
environment\n\n);
I previously submitted a patch to fix this and Wolfgang sent an email
saying that it had been applied.
}
#endif
--
1.6.3.3
I'll revise my patch to add the missing gd-env_valid = 1; and re-test.
Hmm . . . looking at env_nand.c I see that it doesn't do gd-env_valid
= 1 either, which is probably why I removed it last night.
Any idea whether it is actually required? Seems to work fine without it!
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Adding fixed sdram setting for cornet_ds board
On Oct 7, 2010, at 9:59 AM, York Sun wrote:
800, 900, 1000, 1200MT/s data rate parameters are added for fixed sdram
setting. SPD based parameters and fixed parameters can be toggled by hwconfig.
To use fixed parameters,
hwconfig=fsl_ddr:sdram=fixed
To use SPD parameters,
hwconfig=fsl_ddr:ctlr_intlv=cacheline,bank_intlv=cs0_cs1
Signed-off-by: York Sun york...@freescale.com
---
board/freescale/corenet_ds/corenet_ds.c | 15 --
board/freescale/corenet_ds/ddr.c| 315 ++-
include/configs/corenet_ds.h| 57 --
3 files changed, 314 insertions(+), 73 deletions(-)
diff --git a/board/freescale/corenet_ds/corenet_ds.c
b/board/freescale/corenet_ds/corenet_ds.c
index 1107743..b5a1332 100644
--- a/board/freescale/corenet_ds/corenet_ds.c
+++ b/board/freescale/corenet_ds/corenet_ds.c
@@ -29,7 +29,6 @@
#include asm/cache.h
#include asm/immap_85xx.h
#include asm/fsl_law.h
-#include asm/fsl_ddr_sdram.h
#include asm/fsl_serdes.h
#include asm/fsl_portals.h
#include asm/fsl_liodn.h
@@ -239,20 +238,6 @@ int misc_init_r(void)
return 0;
}
-phys_size_t initdram(int board_type)
-{
- phys_size_t dram_size;
-
- puts(Initializing\n);
-
- dram_size = fsl_ddr_sdram();
-
- setup_ddr_tlbs(dram_size / 0x10);
-
- puts(DDR: );
- return dram_size;
-}
-
#ifdef CONFIG_MP
void board_lmb_reserve(struct lmb *lmb)
{
diff --git a/board/freescale/corenet_ds/ddr.c
b/board/freescale/corenet_ds/ddr.c
index ce87b56..d387a92 100644
--- a/board/freescale/corenet_ds/ddr.c
+++ b/board/freescale/corenet_ds/ddr.c
@@ -8,9 +8,289 @@
#include common.h
#include i2c.h
-
+#include hwconfig.h
+#include asm/mmu.h
#include asm/fsl_ddr_sdram.h
#include asm/fsl_ddr_dimm_params.h
+#include asm/fsl_law.h
+
+DECLARE_GLOBAL_DATA_PTR;
+
+extern void fsl_ddr_set_memctl_regs(const fsl_ddr_cfg_regs_t *regs,
+unsigned int ctrl_num);
+
+#define CONFIG_SYS_SDRAM_SIZE4096
+
+#define DATARATE_800MHZ 8
+#define DATARATE_900MHZ 9
+#define DATARATE_1000MHZ 10
+#define DATARATE_1200MHZ 12
+
+#define CONFIG_SYS_DDR_TIMING_3_1200 0x0103
+#define CONFIG_SYS_DDR_TIMING_0_1200 0xCC550104
+#define CONFIG_SYS_DDR_TIMING_1_1200 0x868FAA45
+#define CONFIG_SYS_DDR_TIMING_2_1200 0x0FB8A912
+#define CONFIG_SYS_DDR_MODE_1_1200 0x00441A40
+#define CONFIG_SYS_DDR_MODE_2_1200 0x0010
+#define CONFIG_SYS_DDR_INTERVAL_1200 0x12480100
+#define CONFIG_SYS_DDR_CLK_CTRL_1200 0x0280
+
+#define CONFIG_SYS_DDR_TIMING_3_1000 0x0002
+#define CONFIG_SYS_DDR_TIMING_0_1000 0xCC440104
+#define CONFIG_SYS_DDR_TIMING_1_1000 0x727DF944
+#define CONFIG_SYS_DDR_TIMING_2_1000 0x0FB088CF
+#define CONFIG_SYS_DDR_MODE_1_1000 0x00441830
+#define CONFIG_SYS_DDR_MODE_2_1000 0x0008
+#define CONFIG_SYS_DDR_INTERVAL_1000 0x0F3C0100
+#define CONFIG_SYS_DDR_CLK_CTRL_1000 0x0280
+
+#define CONFIG_SYS_DDR_TIMING_3_900 0x0002
+#define CONFIG_SYS_DDR_TIMING_0_900 0xCC440104
+#define CONFIG_SYS_DDR_TIMING_1_900 0x616ba844
+#define CONFIG_SYS_DDR_TIMING_2_900 0x0fb088ce
+#define CONFIG_SYS_DDR_MODE_1_9000x00441620
+#define CONFIG_SYS_DDR_MODE_2_9000x0008
+#define CONFIG_SYS_DDR_INTERVAL_900 0x0db60100
+#define CONFIG_SYS_DDR_CLK_CTRL_900 0x0280
+
+#define CONFIG_SYS_DDR_TIMING_3_800 0x0002
+#define CONFIG_SYS_DDR_TIMING_0_800 0xcc330104
+#define CONFIG_SYS_DDR_TIMING_1_800 0x6f6b4744
+#define CONFIG_SYS_DDR_TIMING_2_800 0x0fa888cc
+#define CONFIG_SYS_DDR_MODE_1_8000x00441420
+#define CONFIG_SYS_DDR_MODE_2_8000x
+#define CONFIG_SYS_DDR_INTERVAL_800 0x0c300100
+#define CONFIG_SYS_DDR_CLK_CTRL_800 0x0280
+
+#define CONFIG_SYS_DDR_CS0_BNDS 0x00FF
+#define CONFIG_SYS_DDR_CS1_BNDS 0x
+#define CONFIG_SYS_DDR_CS2_BNDS 0x00FF
+#define CONFIG_SYS_DDR_CS3_BNDS 0x00FF
+#define CONFIG_SYS_DDR2_CS0_BNDS 0x00FF
+#define CONFIG_SYS_DDR2_CS1_BNDS 0x
+#define CONFIG_SYS_DDR2_CS2_BNDS 0x00FF
+#define CONFIG_SYS_DDR2_CS3_BNDS 0x00FF
+#define CONFIG_SYS_DDR_CS0_CONFIG0xA0044202
+#define CONFIG_SYS_DDR_CS0_CONFIG_2 0x
+#define CONFIG_SYS_DDR_CS1_CONFIG0x80004202
+#define CONFIG_SYS_DDR_CS2_CONFIG0x
+#define CONFIG_SYS_DDR_CS3_CONFIG0x
+#define CONFIG_SYS_DDR2_CS0_CONFIG 0x80044202
+#define CONFIG_SYS_DDR2_CS1_CONFIG 0x80004202
+#define CONFIG_SYS_DDR2_CS2_CONFIG 0x
+#define CONFIG_SYS_DDR2_CS3_CONFIG 0x
+#define CONFIG_SYS_DDR_INIT_ADDR 0x
+#define CONFIG_SYS_DDR_INIT_EXT_ADDR 0x
+#define CONFIG_SYS_DDR_CS1_CONFIG0x80004202
+#define CONFIG_SYS_DDR_DATA_INIT 0xdeadbeef
+#define
Re: [U-Boot] [PATCH] Crash in env_relocate_spec() of env_mmc.c
On Fri, Oct 8, 2010 at 1:03 AM, Stefano Babic sba...@denx.de wrote:
mmc_initialize is not called at the startup if the
relocation takes place and the environment is stored
into a MMC card.
Signed-off-by: Stefano Babic sba...@denx.de
---
arch/arm/lib/board.c | 10 +-
common/env_mmc.c | 11 +--
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 5f2dfd0..704ddcb 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -775,6 +775,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
nand_init(); /* go init the NAND */
#endif
+#ifdef CONFIG_GENERIC_MMC
+ puts (MMC: );
+ mmc_initialize (bd);
+#endif
+
#if defined(CONFIG_CMD_ONENAND)
onenand_init();
#endif
@@ -854,11 +859,6 @@ extern void davinci_eth_set_mac_addr (const u_int8_t
*addr);
board_late_init ();
#endif
-#ifdef CONFIG_GENERIC_MMC
- puts (MMC: );
- mmc_initialize (gd-bd);
-#endif
-
#ifdef CONFIG_BITBANGMII
bb_miiphy_init();
#endif
I think it might make more sense to put the MMC ifdef after the
onenand code so that it doesn't split the nand/onenand grouping.
Otherwise it matches what I did.
diff --git a/common/env_mmc.c b/common/env_mmc.c
index 14203b6..cb7c448 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -130,24 +130,23 @@ void env_relocate_spec(void)
{
#if !defined(ENV_IS_EMBEDDED)
struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV);
+ char buf[CONFIG_ENV_SIZE];
if (init_mmc_for_env(mmc))
return;
- if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, env_ptr))
- return use_default();
-
- if (crc32(0, env_ptr-data, ENV_SIZE) != env_ptr-crc)
+ if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, buf))
return use_default();
This is a void function and shouldn't have a return value. I fixed
this in my version.
gd-env_valid = 1;
I removed this in my version, probably an error to do that though :-)
+
+ env_import(buf, 1);
#endif
}
#if !defined(ENV_IS_EMBEDDED)
static void use_default()
{
- puts (*** Warning - bad CRC or MMC, using default environment\n\n);
- set_default_env();
+ set_default_env(*** Warning - bad CRC or MMC, using default
environment\n\n);
I previously submitted a patch to fix this and Wolfgang sent an email
saying that it had been applied.
}
#endif
--
1.6.3.3
I'll revise my patch to add the missing gd-env_valid = 1; and re-test.
Steve
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Crash in env_relocate_spec() of env_mmc.c
Steve Sakoman wrote: On Fri, Oct 8, 2010 at 1:03 AM, Stefano Babic sba...@denx.de wrote: mmc_initialize is not called at the startup if the relocation takes place and the environment is stored into a MMC card. Hallo Steve, I think it might make more sense to put the MMC ifdef after the onenand code so that it doesn't split the nand/onenand grouping. Otherwise it matches what I did. Yes, it makes more sens - and I do not see any problem to move it This is a void function and shouldn't have a return value. I fixed this in my version. Agree. gd-env_valid = 1; I removed this in my version, probably an error to do that though :-) Or probably not...env_valid should signalize if the checksum is correct, and now the checksum is verified by the env_import function, as I have understood. I previously submitted a patch to fix this and Wolfgang sent an email saying that it had been applied. Ah, ok, I have missed it ;-) I'll revise my patch to add the missing gd-env_valid = 1; and re-test. Ok, thanks Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Crash in env_relocate_spec() of env_mmc.c
Steve Sakoman wrote: I'll revise my patch to add the missing gd-env_valid = 1; and re-test. Hmm . . . looking at env_nand.c I see that it doesn't do gd-env_valid = 1 either, which is probably why I removed it last night. Any idea whether it is actually required? Seems to work fine without it! I have understood, it is not required if we call env_import and we require to verify the checksum. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Crash in env_relocate_spec() of env_mmc.c
On Fri, Oct 8, 2010 at 9:05 AM, Stefano Babic sba...@denx.de wrote: Steve Sakoman wrote: I'll revise my patch to add the missing gd-env_valid = 1; and re-test. Hmm . . . looking at env_nand.c I see that it doesn't do gd-env_valid = 1 either, which is probably why I removed it last night. Any idea whether it is actually required? Seems to work fine without it! I have understood, it is not required if we call env_import and we require to verify the checksum. OK, thanks! Would you like me to submit the patch or would you like to revise resubmit? Steve ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] MPC8377 system bring up
Kim, Timur, we got a new board out of production these days. It's a MPC8377 based system with PCI/PCIe peripherals and Nor+Nand-Flash on LocalBus ... nothing special. Nevertheless I need a little help. No basic errors so far, i.e. power, clocks and reset are working fine. Made a new Board definition (U-Boot top-of-tree) by copying the MPC837xERDB.h config file. Changes I've done : - completely removed VSC7385 stuff (also at BAT3). - removed PCISLAVE stuff since this is host only. - removed TSEC2 from HRCWH since there's only TSEC1. - CONFIG_SYS_FLASH_BASE = 0xFC00 since we have 64MiB Nor (S29GL512 in 16-Bit mode). - Adjusted TEXT_BASE to 0xFC00 - BAT4 size changed to BATU_BL_64M. - removed Date and RTC stuff. Compilation works fine and HRCW generation yields 0xa0606002 0x2504 which looks sane to me. I'm working with bdi2000 and started with MPC8377E-RDB.cfg ... my mods are : - changed LBLAWBAR0 to 0xfc00 and size 64MiB. - changed OR0/BRO to also match 0xfc00. - HRCW override ti above values. - Flash size and IP stuff. I can access RAM and whole 64MiB flash without problems. Programming U-Boot @ 0xfc00 works fine as well as a verification after power cycling the board. Removing the bdi2000, connecting RS-232 and restarting the board yields nothing. No activities ... not even an assertion of ~LCS0. Of course the CFG_RESET_SOURCE is 0b which indicates Boot from Nor. I'd at least expect a few cycles for HRCW fetch ... hmmm. Are there any obvious issues I have missed so far ? Reagrds, 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] Crash in env_relocate_spec() of env_mmc.c
Steve Sakoman wrote: On Fri, Oct 8, 2010 at 9:05 AM, Stefano Babic sba...@denx.de wrote: Steve Sakoman wrote: I'll revise my patch to add the missing gd-env_valid = 1; and re-test. Hmm . . . looking at env_nand.c I see that it doesn't do gd-env_valid = 1 either, which is probably why I removed it last night. Any idea whether it is actually required? Seems to work fine without it! I have understood, it is not required if we call env_import and we require to verify the checksum. OK, thanks! Would you like me to submit the patch or would you like to revise resubmit? No problem at all - you can submit your patch, as it seems to me more complete as mine. Stefano -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MPC8377 system bring up
Timur, Are there any obvious issues I have missed so far ? Nothing obvious to me. I haven't done much work at this level of U-Boot bring-up, but I would think that failure to assert LCS0 points to a LAWBAR problem. Perhaps you have overlapping LAWs? Actually I'm pretty sure that the HRCW doesn't get loaded from Nor Flash, i.e. no U-Boot code involved yet. Are you using HRCW from Nor on your MPC837x based systems or are you actually using Nand, SPI or I2C PROM ? 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] MPC8377 system bring up
André Schwarz wrote: Are you using HRCW from Nor on your MPC837x based systems or are you actually using Nand, SPI or I2C PROM ? I've only worked on boards that load the RCW from NOR flash, but some of our BSPs support loading the RCW from other sources, like NAND flash or I2C. -- Timur Tabi Linux kernel developer at Freescale ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] framebuffer and video on mx51 babbage
T.J. Staley wrote: Hello, Hi, I'm trying to enable framebuffer support to produce a splash image in u-boot for a custom image I want displayed. The idea, for now, is to simply display the splash image to a monitor running off the DVI port on the babbage. I'm fairly new to all things u-boot, just started digging through the docs and source as of yesterday, so I was hoping someone could point me in the right direction. Looking at the README it seems I can enable splash screen and video support with a define in /include/configs/mx51_bbg.h (working with Freescale's BSP). There is at the moment no video driver for the MX.51 on the u-boot mainline. I am not sure about the Freescale's BSP, but as far as I know there is no support for the MX51's IPUv3. But I could be wrong, ask Freescale for confirm. However, on this ML you can find issues regarding the u-boot mainline. The babbage board is renamed on u-boot mainline as imx51evk, because this is the name you find now for this board on the Freescale's website. If you have developed something that is not yet provided, feel free to send patches and to contribute to the project. Related to the MX.51 framebuffer support, I am working on the same issue. I have ported the Freescale's Linux driver to u-boot, and at least it is working, but I am not yet ready to send patches. I am still cleaning up code and reducing functionalities, as the IPU supports much more as only a framebuffer. Of course, providing patches is on my TODO list, and I hope I can send them soon... It builds with with the '#define CONFIG_SPLASH_SCREEN', but when I include CONFIG_VIDEO it bombs due to an undefined reference (drv_video_init) which I'm not backtracking. I think there is no support for i.MX51's framebuffer at all, as well as in u-boot mainline;-( Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] env_mmc: Fix crashing bug encountered after enabling ARM relocation
The crash was occuring in env_relocate because it was being called prior
to mmc_initialize. This patch moves the MMC initialization earlier in
the init process.
This patch also cleans up the env_relocate_spec code in env_mmc.c
Developed jointly with Stefano Babic
Signed-off-by: Steve Sakoman steve.sako...@linaro.org
---
diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 5f2dfd0..0e2f129 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -779,6 +779,11 @@ void board_init_r (gd_t *id, ulong dest_addr)
onenand_init();
#endif
+#ifdef CONFIG_GENERIC_MMC
+ puts (MMC: );
+ mmc_initialize (bd);
+#endif
+
#ifdef CONFIG_HAS_DATAFLASH
AT91F_DataflashInit();
dataflash_print_info();
@@ -854,11 +859,6 @@ extern void davinci_eth_set_mac_addr (const u_int8_t
*addr);
board_late_init ();
#endif
-#ifdef CONFIG_GENERIC_MMC
- puts (MMC: );
- mmc_initialize (gd-bd);
-#endif
-
#ifdef CONFIG_BITBANGMII
bb_miiphy_init();
#endif
diff --git a/common/env_mmc.c b/common/env_mmc.c
index cc288d4..d443ff5 100644
--- a/common/env_mmc.c
+++ b/common/env_mmc.c
@@ -129,18 +129,21 @@ inline int read_env(struct mmc *mmc, unsigned long size,
void env_relocate_spec(void)
{
#if !defined(ENV_IS_EMBEDDED)
+ char buf[CONFIG_ENV_SIZE];
+
struct mmc *mmc = find_mmc_device(CONFIG_SYS_MMC_ENV_DEV);
- if (init_mmc_for_env(mmc))
+ if (init_mmc_for_env(mmc)) {
+ use_default();
return;
+ }
- if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, env_ptr))
- return use_default();
-
- if (crc32(0, env_ptr-data, ENV_SIZE) != env_ptr-crc)
- return use_default();
+ if (read_env(mmc, CONFIG_ENV_SIZE, CONFIG_ENV_OFFSET, buf)) {
+ use_default();
+ return;
+ }
- gd-env_valid = 1;
+ env_import(buf, 1);
#endif
}
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] ARMV7: OMAP4: Implement relocation for Panda and OMAP4430SDP
This patch fixes the build breakage introduced by the recent relocation
changes for ARMV7
Signed-off-by: Steve Sakoman st...@sakoman.com
---
diff --git a/arch/arm/cpu/armv7/omap4/board.c b/arch/arm/cpu/armv7/omap4/board.c
index 8c1f395..24a66f5 100644
--- a/arch/arm/cpu/armv7/omap4/board.c
+++ b/arch/arm/cpu/armv7/omap4/board.c
@@ -102,8 +102,13 @@ int dram_init(void)
{
DECLARE_GLOBAL_DATA_PTR;
+#if defined(CONFIG_SYS_ARM_WITHOUT_RELOC)
gd-bd-bi_dram[0].start = 0x8000;
gd-bd-bi_dram[0].size = sdram_size();
+#else
+ gd-ram_size = sdram_size();
+#endif
+
return 0;
}
diff --git a/board/ti/panda/config.mk b/board/ti/panda/config.mk
index 7382263..7176c14 100644
--- a/board/ti/panda/config.mk
+++ b/board/ti/panda/config.mk
@@ -27,6 +27,4 @@
# 8000' - 9fff' (512 MB)
# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
# (mem base + reserved)
-
-# Let's place u-boot 1MB before the end of SDRAM.
-TEXT_BASE = 0x9ff0
+TEXT_BASE = 0x80e8
diff --git a/board/ti/sdp4430/config.mk b/board/ti/sdp4430/config.mk
index 7382263..7bb9473 100644
--- a/board/ti/sdp4430/config.mk
+++ b/board/ti/sdp4430/config.mk
@@ -28,5 +28,4 @@
# Linux-Kernel is expected to be at 8000'8000, entry 8000'8000
# (mem base + reserved)
-# Let's place u-boot 1MB before the end of SDRAM.
-TEXT_BASE = 0x9ff0
+TEXT_BASE = 0x80e8
diff --git a/include/configs/omap4_panda.h b/include/configs/omap4_panda.h
index 2618f7d..b52ca19 100644
--- a/include/configs/omap4_panda.h
+++ b/include/configs/omap4_panda.h
@@ -139,12 +139,6 @@
#undef CONFIG_CMD_IMLS /* List all found images*/
/*
- * Enabling relocation of u-boot by default
- * Relocation can be skipped if u-boot is copied to the TEXT_BASE
- */
-#undef CONFIG_SKIP_RELOCATE_UBOOT
-
-/*
* Environment setup
*/
@@ -233,4 +227,7 @@
*/
#define CONFIG_NR_DRAM_BANKS 1
+#define CONFIG_SYS_SDRAM_BASE 0x8000
+#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK -
CONFIG_SYS_GBL_DATA_SIZE)
+
#endif /* __CONFIG_H */
diff --git a/include/configs/omap4_sdp4430.h b/include/configs/omap4_sdp4430.h
index 8274577..174d73f 100644
--- a/include/configs/omap4_sdp4430.h
+++ b/include/configs/omap4_sdp4430.h
@@ -144,12 +144,6 @@
#undef CONFIG_CMD_IMLS /* List all found images*/
/*
- * Enabling relocation of u-boot by default
- * Relocation can be skipped if u-boot is copied to the TEXT_BASE
- */
-#undef CONFIG_SKIP_RELOCATE_UBOOT
-
-/*
* Environment setup
*/
@@ -238,4 +232,7 @@
*/
#define CONFIG_NR_DRAM_BANKS 1
+#define CONFIG_SYS_SDRAM_BASE 0x8000
+#define CONFIG_SYS_INIT_SP_ADDR(LOW_LEVEL_SRAM_STACK -
CONFIG_SYS_GBL_DATA_SIZE)
+
#endif /* __CONFIG_H */
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] NAND on AVR32
Apologies if this is a double -post - I didn't get it back in my feed from the mailing list maybe it is awaiting approval or something. But I'm off on holiday, and I'd really like it to be out there - 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 Smile 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 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 have found some stuff in support for other Atmel devices, which seems relevant. Plus of course the Linux sources. 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 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! so far I've no clue how this file gets included in the make of u-boot. Any and all advice welcome - especially if someone HAS got there first. TVM David ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on AVR32
On Fri, 8 Oct 2010 23:54:00 +0100 David Collier from_denx_ub...@dexdyne.com wrote: Apologies if this is a double -post - I didn't get it back in my feed from the mailing list maybe it is awaiting approval or something. But I'm off on holiday, and I'd really like it to be out there - 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. It improves the odds, but there's never a guarantee... 4 in target.h #undef CONFIG_NAND_LEGACY What version of U-Boot are you using? There should be no references to CONFIG_NAND_LEGACY left. CONFIG_MTD_NAND_VERIFY_WRITE CONFIG_MTD_PARTITIONS 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 There is no nand.c in the at91sam9261ek directory in current U-Boot. The NAND driver is in drivers/mtd/nand/atmel_nand.c. Please try the latest code first, and use it as a base to build upon if it doesn't have what you need. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] NAND on AVR32
On 09.10.2010 00:54, David Collier wrote: Apologies if this is a double -post - I didn't get it back in my feed from the mailing list maybe it is awaiting approval or something. But I'm off on holiday, and I'd really like it to be out there - Posted in the AVR32 forum already... 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. Sure. If everyone thought like that, nothing would exist... 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!!! Blame it on the fact that no Atmel board for AVR32 uses NAND and that while the data sheet of the AP7k was still in preliminary state, the part went NRFND (not recommended for new designs). I have found some stuff in support for other Atmel devices, which seems relevant. Plus of course the Linux sources. Probably look at drivers/mtd/nand/atmel_nand.c. Compare datasheets of AT91SAM9 and AP7k. Probably there is little to do except at places where AT91 is referenced. And as Scott just now mentioned: always use most recent u-boot as a base. And if you succeed, make sure you send proper patches, so the next one can use work someone else did already... Any and all advice welcome - especially if someone HAS got there first. Unlikely that someone else is going to add NAND support for that chip. Maybe ditch not only the SD, but the AP7k as well ;) Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] framebuffer and video on mx51 babbage
Hi Stefano, Thanks for the feedback. I'll contact Freescale to see if there is anything in the pipeline as far as the support I was looking for. Judging by your response you seem to be significantly further in the endeavor of bringing this functionality to the mx51evk (thanks for the correction). I'm just starting to get my head around u-boot and the board, but if I can lend a helping hand please let me know. I would hate to reinvent a wheel that just needs some final touches, and of course anything I might contribute would be released. I'm very interested in those patches, regardless of their state. If there is anyway you can get those out that would be very appreciated. Regards, Jacob On Fri, Oct 8, 2010 at 3:57 PM, Stefano Babic sba...@denx.de wrote: T.J. Staley wrote: Hello, Hi, I'm trying to enable framebuffer support to produce a splash image in u-boot for a custom image I want displayed. The idea, for now, is to simply display the splash image to a monitor running off the DVI port on the babbage. I'm fairly new to all things u-boot, just started digging through the docs and source as of yesterday, so I was hoping someone could point me in the right direction. Looking at the README it seems I can enable splash screen and video support with a define in /include/configs/mx51_bbg.h (working with Freescale's BSP). There is at the moment no video driver for the MX.51 on the u-boot mainline. I am not sure about the Freescale's BSP, but as far as I know there is no support for the MX51's IPUv3. But I could be wrong, ask Freescale for confirm. However, on this ML you can find issues regarding the u-boot mainline. The babbage board is renamed on u-boot mainline as imx51evk, because this is the name you find now for this board on the Freescale's website. If you have developed something that is not yet provided, feel free to send patches and to contribute to the project. Related to the MX.51 framebuffer support, I am working on the same issue. I have ported the Freescale's Linux driver to u-boot, and at least it is working, but I am not yet ready to send patches. I am still cleaning up code and reducing functionalities, as the IPU supports much more as only a framebuffer. Of course, providing patches is on my TODO list, and I hope I can send them soon... It builds with with the '#define CONFIG_SPLASH_SCREEN', but when I include CONFIG_VIDEO it bombs due to an undefined reference (drv_video_init) which I'm not backtracking. I think there is no support for i.MX51's framebuffer at all, as well as in u-boot mainline;-( Best regards, Stefano Babic -- = DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] new uboot with relocation change cannot boot when download the bin file to different address than TEXT_BASE
Hi, I recently try to port our board code to new uboot, which has been changed to use new relocation scheme. But I found a very strange thing, that is if the uboot is loaded to the TEXT_BASE address, it could run without problem. But if it is loaded to a different place, it fail to boot up... I check the code, and found that in the board_init_f, it calls the init_sequence which is stored as a data sector in the u-boot.bin file. While the new scheme use the fPIC, the code could locate the GOT table correctly, and it seem to forgot what the GOT table stores is context that is meaningful in TEXT_BASE, not the loaded base. That is to say, if the TEXT_BASE is 0xf0, and loaded base is 0x50, I found the GOT table also filled with 0xf0, not the 0x50. This leads the cpu loading wrong function address in the init_sequence table, and cause pc become invalid... Am I missing something to switch to the new relocation scheme? Thanks, Lei ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
