[U-Boot] [Coldfire] Crash when writing into memory (mtest, tftpboot, ...)
Hi, I have a custom board, based on Freescale M5271EVB, use codesourcery toolchains 2010.09-41. Board code are almost same as the evb board: - include/configs/M5271EVB.h - board/freescale/m5271evb/ - arch/m68k/cpu/mcf52x2/
$ export CROSS_COMPILE=... $ make M5271EVB_config $ make 1. I got linking error in version 2010-09 and later: libgcc.o not found. It is just fine in 2010-06, which use libgcc.a from the toolchains. How to change back the build rules to link to libgcc.a in the latest version of u-boot?
2. I have u-boot 2010-06 booted on my board. Everything seems ok (uart, ethernet, ram, flash,...) * 0x00000000 - 0x00FFFFFF SDRAM 16M * 0x20000000 - 0x2000FFFF Int SRAM 64k * 0xFF800000 - 0xFFFFFFFF Flash 8M
========== U-Boot 2010.06-svn8 (Jan 26 2011 - 10:08:06) CPU: Freescale ColdFire MCF5271 rev. 1, at 100 MHz Board: TEST DRAM: 16 MiB Top of RAM usable for U-Boot at: 01000000 Reserving 132k for U-Boot at: 00fde000 Reserving 264k for malloc() at: 00f9c000 Reserving 58 Bytes for Board Info at: 00f9bfc6 Reserving 48 Bytes for Global Data at: 00f9bf96 Reserving 64k for boot parameters at: 00f8bf96 Stack Pointer at: 00f8bf78 Start relocate of code from ff800400 to 00fde000 Now running in RAM - U-Boot at: 00fde000 FLASH: Manufacturer ID: 0001 Manufacturer: AMD (Spansion) Device ID: 227E Mirror Bit flash: addr[14] = 00002210 addr[15] = 00002200 Chip: S29GL064N flash_protect ON: from 0xFF800400 to 0xFF81AAFF protect on 0 protect on 1 protect on 2 protect on 3 protect on 4 protect on 5 protect on 6 protect on 7 protect on 8 8 MiB *** Warning - bad CRC, using default environment
In: serial Out: serial Err: serial U-Boot relocated to 00fde000 Net: FEC0 ### main_loop entered: bootdelay=5
### main_loop: bootcmd="<UNDEFINED>"
==========
But if I run mtest (0x400 - 0x380000), it crashed:
mtest
========== Pattern 00000000 Writing... Reading...
*** Unexpected exception *** Vector Number: 3 Format: 04 Fault Status: 4
PC: 00fe73a2 SR: 00002019 SP: 00f8bd8c D0: 00018a9f D1: 0000000a D2: ffffffff D3: 00000000 D4: 00000000 D5: ffffffff D6: 00018aa0 D7: 00f9bf96 A0: 00062e7d A1: 00fe54ca A2: 00062e80 A3: 00000002 A4: 00000400 A5: 00ff6300 A6: 00f8bdfc
*** Please Reset Board! *** ========== Vector #3 is Invalid Address. PC is at do_mem_mtest() @ 0x176 ========== #else /* The original, quickie test */ incr = 1; for (;;) { if (ctrlc()) { 16e: 2d48 fff8 movel %a0,%fp@(-8) 172: 206e fff8 moveal %fp@(-8),%a0 176: 4e90 jsr %a0@ 178: 4a80 tstl %d0 17a: 6600 0088 bnew 204 <do_mem_mtest+0x122> putc ('\n'); return 1; } ========== I remove calling ctrlc(), then it is only fine if I run mtest 0x400 0x190a00 Memory dump: ==========
md 190cd0 64
00190cd0: ....md.190cd0.64 00190ce0: ...&..|....(.... ... 00190dc0: .......D...J.... 00190dd0: ....md 190cd0 64 00190de0: ...........l.... ... 00190e00: .....### main_lo 00190e10: op: bootcmd="<UN 00190e20: DEFINED>"....... ========== I have no idea why the command i just typed is in this address. The problem seems u-boot memory is overwritten, But I think it must be in the preserved range (> 00f8bf96) after relocating.
Thanks in advance.
Dear Metalod,
In message AANLkTikLqw49RAM38aTwzyYaLD=2_h3ETt2RxkxhSRBo@mail.gmail.com you wrote:
I have a custom board, based on Freescale M5271EVB, use codesourcery toolchains 2010.09-41. Board code are almost same as the evb board:
Almost the same, but different. And not in mainline.
How can we comment on code thatis completely unknown to us?
- I got linking error in version 2010-09 and later: libgcc.o not found.
It is just fine in 2010-06, which use libgcc.a from the toolchains. How to change back the build rules to link to libgcc.a in the latest version of u-boot?
Fix your Makefiles.
But if I run mtest (0x400 - 0x380000), it crashed:
...
I remove calling ctrlc(), then it is only fine if I run mtest 0x400 0x190a00 Memory dump: ==========
md 190cd0 64
00190cd0: ....md.190cd0.64 00190ce0: ...&..|....(.... ... 00190dc0: .......D...J.... 00190dd0: ....md 190cd0 64 00190de0: ...........l.... ... 00190e00: .....### main_lo 00190e10: op: bootcmd="<UN 00190e20: DEFINED>"....... ========== I have no idea why the command i just typed is in this address.
It was _you_ who defined the memory map for your board, so only you can knw that. We cannot even look at your code to tell you what you done wrong.
Best regards,
Wolfgang Denk
Dear Wolfgang, I am sorry that did not provide enough information. Please find attached the configuration for my board.
Best regards, --
On Wed, Jan 26, 2011 at 2:57 PM, Wolfgang Denk wd@denx.de wrote:
Almost the same, but different. And not in mainline.
How can we comment on code thatis completely unknown to us?
Dear Metalod,
In message AANLkTimtcLE63BpBf-gy2pb-zUzRuvO5f9nK_LY2A5G7@mail.gmail.com you wrote:
I am sorry that did not provide enough information. Please find attached the configuration for my board.
Sorry, but this is not how it works.
If you are looking for free help from the community, you can try submitting your patches for inclusion into mainline. The resulting review process may (or may not) catch some of your errors.
But we have little interest to analyse some tarball that somebody throws at us.
If you are looking for someone to fix your out-of-tree port for you then please hire an expert.
Best regards,
Wolfgang Denk
Dear Wolfgang,
When asking the question, I just hope that someone can give me a _hint_ to what I did wrong or misunderstanding from his/her experience. My point is asking in what case that stack pointer is at 00f8bf78 (printed in debug), but console command is wrote to 190cd0.
Thank you anyway.
On Wed, Jan 26, 2011 at 4:38 PM, Wolfgang Denk wd@denx.de wrote:
Dear Metalod,
In message AANLkTimtcLE63BpBf-gy2pb-zUzRuvO5f9nK_LY2A5G7@mail.gmail.com you wrote:
I am sorry that did not provide enough information. Please find attached the configuration for my board.
Sorry, but this is not how it works.
If you are looking for free help from the community, you can try submitting your patches for inclusion into mainline. The resulting review process may (or may not) catch some of your errors.
But we have little interest to analyse some tarball that somebody throws at us.
If you are looking for someone to fix your out-of-tree port for you then please hire an expert.
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: wd@denx.de Physician: One upon whom we set our hopes when ill and our dogs when well. - Ambrose Bierce
Dear Metalod,
In message AANLkTinv06Skn315Uon2H3P6e_Xkgq48rN6aHhoaAkef@mail.gmail.com you wrote:
When asking the question, I just hope that someone can give me a _hint_ to what I did wrong or misunderstanding from his/her experience. My point is asking in what case that stack pointer is at 00f8bf78 (printed in debug), but console command is wrote to 190cd0.
We don't know how you defined your memory map, or why.
Best regards,
Wolfgang Denk
participants (2)
-
Metalod -
Wolfgang Denk