* [ECOS] RedBoot upload memory troubles @ 2004-08-12 16:48 Jakob Kjaer 2004-08-12 18:20 ` Andrew Lunn 2004-08-12 18:30 ` Andrew Lunn 0 siblings, 2 replies; 7+ messages in thread From: Jakob Kjaer @ 2004-08-12 16:48 UTC (permalink / raw) To: ecos-discuss Hello! I'm in the process of porting (debugging) RedBoot for our in-house developed computer for the SSETI-Express satellite ;) The computer is very much alike the AT91 EB40 eval.board, ie. ARM7, and has the following memory layout: ROM 0x01000000, 1MB FLASH 0x02000000, 4MB RAM 0x03000000, 2MB Timing and chip-selects etc. is setup correctly, and RedBoot has succesfully been burned to ROM, and gives me the following pleasant and well-known greeting: ---begin-output--- RedBoot(tm) bootstrap and debug environment [ROM] Non-certified release, version SSETI-Express OBC v5 - built 16:20:49, Aug 12 204 Platform: Atmel AT91/AAUOBC (ARM7TDMI) Copyright (C) 2000, 2001, 2002, Red Hat, Inc. RAM: 0x03000000-0x03200000, [0x030070e8-0x03200000] available ---end-output--- All nice so far, but... The trouble starts if I connect with gdb. It seems like the GDB protocol stub got the RAM size (workspace_end?) all wrong: ---begin-output--- Remote debugging using /dev/ttyS0 Cannot access memory at address 0xe880e880 0xe880e880 in ?? () ---end-output--- I can upload programs, but if I try to start them, I get an error. There is no memory at address 0xe880e880, I know that! :/ The dissassembled RedBoot ROM elf image does not contain any reference to the above mentioned address... Redboot also crashes if I try to upload my hello-world program via y-modem in minicom. Forcing other base-addresses for the upload doesn't help. I can use all commands in RedBoot, and there are no complaints in s-record or elf upload - but when the upload is complete, RedBoot crashes and gdb protocol stuff gets sent, same error as when using gdb uploads. I don't have access to a JTAG debugger, so I'm pretty lost on what to try next... The number of ROM chips are somewhat limited (they are on-time-programmable), so any advice is very welcome! ;) Kind regards, Jakob Kjaer Student Space Exploration and Technology Initiative European Space Agency PS: Yes, it's (or at least, going to be) eCos in space! You can find more about SSETI-Express on the not-yet-finished web-page: http://sseti.gte.tuwien.ac.at/WSW4/express1.htm -- Jakob Kjaer makob@makob.dk -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] RedBoot upload memory troubles 2004-08-12 16:48 [ECOS] RedBoot upload memory troubles Jakob Kjaer @ 2004-08-12 18:20 ` Andrew Lunn 2004-08-12 18:31 ` Jakob Kjaer 2004-08-12 18:30 ` Andrew Lunn 1 sibling, 1 reply; 7+ messages in thread From: Andrew Lunn @ 2004-08-12 18:20 UTC (permalink / raw) To: Jakob Kjaer; +Cc: ecos-discuss > I don't have access to a JTAG debugger, so I'm pretty lost on what to try > next... The number of ROM chips are somewhat limited (they are > on-time-programmable), so any advice is very welcome! ;) Try finding a flash chip that has the same pinout as the ROM. Or find an eprom you can erase with UV etc.... Having 1Mb of one time ROM is a silly idea until near the end of developlent work and you are ready to start production. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] RedBoot upload memory troubles 2004-08-12 18:20 ` Andrew Lunn @ 2004-08-12 18:31 ` Jakob Kjaer 0 siblings, 0 replies; 7+ messages in thread From: Jakob Kjaer @ 2004-08-12 18:31 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss Hello, On Thu, 12 Aug 2004, Andrew Lunn wrote: > > I don't have access to a JTAG debugger, so I'm pretty lost on what to try > > next... The number of ROM chips are somewhat limited (they are > > on-time-programmable), so any advice is very welcome! ;) > > Try finding a flash chip that has the same pinout as the ROM. Or find > an eprom you can erase with UV etc.... Having 1Mb of one time ROM is a > silly idea until near the end of developlent work and you are ready to > start production. Yes, that would have been very nice, but since the everything is going into space the requirements for chips are somewhat different. -Especially for the ROM, which has to be radiation-hardened. The only rad-hard ROM we could afford in large quantities does not have any FLASH or EPROM foorprint/pinout brother or sister :( We are (next week) going to build a footprint-adapter for some FLASH or EPROM chip to fit into the ROM-socket. /Jakob > Andrew > -- Jakob Kjaer makob@makob.dk -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] RedBoot upload memory troubles 2004-08-12 16:48 [ECOS] RedBoot upload memory troubles Jakob Kjaer 2004-08-12 18:20 ` Andrew Lunn @ 2004-08-12 18:30 ` Andrew Lunn 2004-08-12 18:50 ` Jakob Kjaer 1 sibling, 1 reply; 7+ messages in thread From: Andrew Lunn @ 2004-08-12 18:30 UTC (permalink / raw) To: Jakob Kjaer; +Cc: ecos-discuss On Thu, Aug 12, 2004 at 06:48:05PM +0200, Jakob Kjaer wrote: > Hello! > > I'm in the process of porting (debugging) RedBoot for our in-house > developed computer for the SSETI-Express satellite ;) > > The computer is very much alike the AT91 EB40 eval.board, ie. ARM7, > and has the following memory layout: > ROM 0x01000000, 1MB > FLASH 0x02000000, 4MB > RAM 0x03000000, 2MB In order that the vectors can be changed, RAM is normally mapped into address 0. To do this, the ROM must be mapped to some other location. It could be your ROM is high up in memory, at 0xe8800000. That would explain the gdb information. Having said that, 0xe8800000 is a funny number so it does not seem right somehow. > Timing and chip-selects etc. is setup correctly, and RedBoot has > succesfully been burned to ROM, and gives me the following pleasant and > well-known greeting: > > ---begin-output--- > RedBoot(tm) bootstrap and debug environment [ROM] > Non-certified release, version SSETI-Express OBC v5 - built 16:20:49, Aug > 12 204 > > Platform: Atmel AT91/AAUOBC (ARM7TDMI) > Copyright (C) 2000, 2001, 2002, Red Hat, Inc. > > RAM: 0x03000000-0x03200000, [0x030070e8-0x03200000] available > ---end-output--- > > All nice so far, but... The trouble starts if I connect with gdb. It seems > like the GDB protocol stub got the RAM size (workspace_end?) all wrong: > > ---begin-output--- > Remote debugging using /dev/ttyS0 > Cannot access memory at address 0xe880e880 > 0xe880e880 in ?? () > ---end-output--- This address is not a ram address. Its the current program counter. I would expect this to be somewhere in redboot. > Redboot also crashes if I try to upload my hello-world program via y-modem > in minicom. Forcing other base-addresses for the upload doesn't help. Nope, that won't work. eCos images are not position independant. They have to be loaded to the address they were linked to. > I can use all commands in RedBoot, and there are no complaints in s-record > or elf upload - but when the upload is complete, RedBoot crashes and gdb > protocol stuff gets sent, same error as when using gdb uploads. Try connecting with gdb, and use the redboot.elf image. It might give you a better idea of what went wrong. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] RedBoot upload memory troubles 2004-08-12 18:30 ` Andrew Lunn @ 2004-08-12 18:50 ` Jakob Kjaer 2004-08-12 18:56 ` Andrew Lunn 0 siblings, 1 reply; 7+ messages in thread From: Jakob Kjaer @ 2004-08-12 18:50 UTC (permalink / raw) To: Andrew Lunn; +Cc: ecos-discuss Hi! On Thu, 12 Aug 2004, Andrew Lunn wrote: > On Thu, Aug 12, 2004 at 06:48:05PM +0200, Jakob Kjaer wrote: > > Hello! > > > > I'm in the process of porting (debugging) RedBoot for our in-house > > developed computer for the SSETI-Express satellite ;) > > > > The computer is very much alike the AT91 EB40 eval.board, ie. ARM7, > > and has the following memory layout: > > ROM 0x01000000, 1MB > > FLASH 0x02000000, 4MB > > RAM 0x03000000, 2MB > > In order that the vectors can be changed, RAM is normally mapped into > address 0. To do this, the ROM must be mapped to some other > location. It could be your ROM is high up in memory, at > 0xe8800000. That would explain the gdb information. Having said that, > 0xe8800000 is a funny number so it does not seem right somehow. Yes, ROM is (before the REMAP) located at 0x0, which correctly starts the processor, initializes memory banks, copies the vector table into internal SRAM (which will be remapped to 0x0) and then remaps the memory to the layout described above. Then RedBoot starts. Everything up to this point seems to be just fine... > > Timing and chip-selects etc. is setup correctly, and RedBoot has > > succesfully been burned to ROM, and gives me the following pleasant and > > well-known greeting: > > > > ---begin-output--- > > RedBoot(tm) bootstrap and debug environment [ROM] > > Non-certified release, version SSETI-Express OBC v5 - built 16:20:49, Aug > > 12 204 > > > > Platform: Atmel AT91/AAUOBC (ARM7TDMI) > > Copyright (C) 2000, 2001, 2002, Red Hat, Inc. > > > > RAM: 0x03000000-0x03200000, [0x030070e8-0x03200000] available > > ---end-output--- > > > > All nice so far, but... The trouble starts if I connect with gdb. It seems > > like the GDB protocol stub got the RAM size (workspace_end?) all wrong: > > > > ---begin-output--- > > Remote debugging using /dev/ttyS0 > > Cannot access memory at address 0xe880e880 > > 0xe880e880 in ?? () > > ---end-output--- > > This address is not a ram address. Its the current program counter. I > would expect this to be somewhere in redboot. Hmm, that sound odd to me. RedBoot is only present i ROM, which is somewhere around 0x03000000... But then again, this address is excactly what I'm chasing! I just can't seem to find it anywhere in the disassembly (arm-elf-objdump -D redboot.elf). If I understand RedBoot correctly, it initiates the GDB stubs if a "$" is received? If so, it must be a problem with the GDB stubs, since I'm able to use the RedBoot console via minicom (terminal program). > > Redboot also crashes if I try to upload my hello-world program via y-modem > > in minicom. Forcing other base-addresses for the upload doesn't help. > > Nope, that won't work. eCos images are not position independant. They > have to be loaded to the address they were linked to. That's correct. But RedBoot crashes even _before_ I get the chance to start the program: After the y-modem upload "successfully completed", the RedBoot console simply goes mayhem :/ Actually, the output looks very much like the gdb protocol, but gdb refuses to connect (packet errors). > > I can use all commands in RedBoot, and there are no complaints in s-record > > or elf upload - but when the upload is complete, RedBoot crashes and gdb > > protocol stuff gets sent, same error as when using gdb uploads. > > Try connecting with gdb, and use the redboot.elf image. It might give > you a better idea of what went wrong. The output of "arm-elf-gdb redboot.elf" ... (gdb) target remote /dev/ttyS0 Remote debugging using /dev/ttyS0 Cannot access memory at address 0xe880e880 0xe880e880 in ?? () (gdb) bt #0 0xe880e880 in ?? () #1 0x00000000 in ?? () (gdb) Bugger! -But thanks for the suggestions! Hope you or someone else has (lots?) of ideas ;-) /Jakob > > Andrew > -- Jakob Kjaer makob@makob.dk -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] RedBoot upload memory troubles 2004-08-12 18:50 ` Jakob Kjaer @ 2004-08-12 18:56 ` Andrew Lunn 2004-08-19 6:54 ` Jakob Kjaer 0 siblings, 1 reply; 7+ messages in thread From: Andrew Lunn @ 2004-08-12 18:56 UTC (permalink / raw) To: Jakob Kjaer; +Cc: Andrew Lunn, ecos-discuss > > Nope, that won't work. eCos images are not position independant. They > > have to be loaded to the address they were linked to. > > That's correct. But RedBoot crashes even _before_ I get the chance to > start the program: That sounds like you are overwriting something important in redboot. Maybe its stack or its data section. What do you have where in redboot and the hello world application? Any overlap? Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [ECOS] RedBoot upload memory troubles 2004-08-12 18:56 ` Andrew Lunn @ 2004-08-19 6:54 ` Jakob Kjaer 0 siblings, 0 replies; 7+ messages in thread From: Jakob Kjaer @ 2004-08-19 6:54 UTC (permalink / raw) To: ecos-discuss Hi! Ok, we found and corrected the problem: A dangling Output Enable pin from one of the RAM-chips :( Everything works like a charm now! Cheers, Jakob On Thu, 12 Aug 2004, Andrew Lunn wrote: > > > Nope, that won't work. eCos images are not position independant. They > > > have to be loaded to the address they were linked to. > > > > That's correct. But RedBoot crashes even _before_ I get the chance to > > start the program: > > That sounds like you are overwriting something important in > redboot. Maybe its stack or its data section. What do you have where > in redboot and the hello world application? Any overlap? > > Andrew > -- Jakob Kjaer makob@makob.dk -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-08-19 6:54 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-08-12 16:48 [ECOS] RedBoot upload memory troubles Jakob Kjaer 2004-08-12 18:20 ` Andrew Lunn 2004-08-12 18:31 ` Jakob Kjaer 2004-08-12 18:30 ` Andrew Lunn 2004-08-12 18:50 ` Jakob Kjaer 2004-08-12 18:56 ` Andrew Lunn 2004-08-19 6:54 ` Jakob Kjaer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).