AW: [ECOS] Huge memory footprint for a simple "hello world"

AW: [ECOS] Huge memory footprint for a simple "hello world"

[Ram Sudhir Tadavarthi]

> > 1.Instead of using gdb, can you try to load the image through redboot
> using
> > "load" command and test?
> ~/work/atmel/020606-ARM/install/bin$ arm-elf-gdb redboot.elf
> GNU gdb 5.3 (eCosCentric)
> Copyright 2002 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you
> are
> welcome to change it and/or distribute copies of it under certain
> conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for
> details.
> This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
> (gdb) tar rdi /dev/ttyS0
> Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.5) for
> AT91EB40 (2.00)
> Angel Debug Monitor rebuilt on Apr 07 2000 at 12:40:31
> Serial Rate:   9600
> Connected to ARM RDI target.
> (gdb) set $cpsr=0xd3
> (gdb) load
> Loading section .rom_vectors, size 0x40 lma 0x2020000
> Loading section .text, size 0xb1bc lma 0x2020040
> Loading section .rodata, size 0x1c37 lma 0x202b1fc
> Loading section .data, size 0x404 lma 0x202ce34
> Start address 0x2020040, load size 53815
> Transfer rate: 6331 bits/sec, 498 bytes/write.
> (gdb) cont
> Continuing.
> 
> [1]+  Stopped                 arm-elf-gdb redboot.elf
> ~/work/atmel/020606-ARM/install/bin$ minicom
> RedBoot> AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0
> 
> ** Error: Illegal command: "AT"
> RedBoot> load -m xmodem
> C*** Abort! Attempt to load ELF data to address: 0x02020000 which is not
> in RAM
> xyzModem - CRC mode, 257(SOH)/0(STX)/0(CAN) packets, 3 retries
> RedBoot>
> 


[Ram ] Well!!! This suggests that you might have memory layout problems/
linker script problems. 

1. What is the memory layout of your platform? 

2. Does your linker script correctly reflect the memory layout of your
platform?




> > 2.Can you check if there is any signal movement on your serial port
> using an
> > oscilloscope or similar ?
> I've no access to an oscilloscope

[Ram ] Well!!! If your company doesn't provide you proper tools to debug,
you will take lot of unnecessary time to bring up the board which might be
expensive than the oscilloscope itself. Anyway try to get access to it.

If you can see any signal movement, then most probably, it might be a wrong
baud rate generation or related.

> 
> >
> > 3.Can you verify your virtual vectors configuration?
> I am new to this, so I would not know which is correct or not.
> 
[Ram ] Yep!!! Try to read the documentation and post here what exactly you
don't understand. Maybe someone would help you if they some time.


Warm regards,
ram



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: AW: [ECOS] Huge memory footprint for a simple "hello world"

[Gary Thomas]

On Fri, 2006-06-09 at 16:23 +0200, Ram Sudhir Tadavarthi wrote:
> > > 1.Instead of using gdb, can you try to load the image through redboot
> > using
> > > "load" command and test?
> > ~/work/atmel/020606-ARM/install/bin$ arm-elf-gdb redboot.elf
> > GNU gdb 5.3 (eCosCentric)
> > Copyright 2002 Free Software Foundation, Inc.
> > GDB is free software, covered by the GNU General Public License, and you
> > are
> > welcome to change it and/or distribute copies of it under certain
> > conditions.
> > Type "show copying" to see the conditions.
> > There is absolutely no warranty for GDB.  Type "show warranty" for
> > details.
> > This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
> > (gdb) tar rdi /dev/ttyS0
> > Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.5) for
> > AT91EB40 (2.00)
> > Angel Debug Monitor rebuilt on Apr 07 2000 at 12:40:31
> > Serial Rate:   9600
> > Connected to ARM RDI target.
> > (gdb) set $cpsr=0xd3
> > (gdb) load
> > Loading section .rom_vectors, size 0x40 lma 0x2020000
> > Loading section .text, size 0xb1bc lma 0x2020040
> > Loading section .rodata, size 0x1c37 lma 0x202b1fc
> > Loading section .data, size 0x404 lma 0x202ce34
> > Start address 0x2020040, load size 53815
> > Transfer rate: 6331 bits/sec, 498 bytes/write.
> > (gdb) cont
> > Continuing.
> > 
> > [1]+  Stopped                 arm-elf-gdb redboot.elf
> > ~/work/atmel/020606-ARM/install/bin$ minicom
> > RedBoot> AT S7=45 S0=0 L1 V1 X4 &c1 E1 Q0
> > 
> > ** Error: Illegal command: "AT"
> > RedBoot> load -m xmodem
> > C*** Abort! Attempt to load ELF data to address: 0x02020000 which is not
> > in RAM
> > xyzModem - CRC mode, 257(SOH)/0(STX)/0(CAN) packets, 3 retries
> > RedBoot>

You can't use a RAM RedBoot to load a RAM program - they end up trying
to load in the same memory space.

This is probably your problem - your eCos applications will assume that
they were loaded by RedBoot (or at least RedBoot is present on the board
even if you are using GDB to load the application).  If this isn't the 
case, you need to configure your applications to not "USE_ROM_MONITOR"

Query: why don't you load RedBoot into the board's FLASH?  If you do,
things will probably start working much better for you.

Hint: use 'minicom -o' to prevent the "AT..." modem garbage.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: AW: [ECOS] Huge memory footprint for a simple "hello world"

[Gary Thomas]

On Mon, 2006-06-12 at 13:12 +0200, Socrates Socrates wrote:
> > Query: why don't you load RedBoot into the board's FLASH?  If you do,
> > things will probably start working much better for you.
> I've been trying to load and write the redboot.srec file into FLASH.
> But when I select SW1 to UPPER_MEM (on EB40), redboot does not
> startup, infact there's no ouput at all.

Please keep your replies on the list so that all may benefit (and help).

There are explicit instructions for how to do this in the eCos 
documentation - have you followed them completely?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: AW: [ECOS] Huge memory footprint for a simple "hello world"

[Socrates Socrates]

> Please keep your replies on the list so that all may benefit (and help).
Being newbie and all...thanks for that advice.

> There are explicit instructions for how to do this in the eCos
> documentation - have you followed them completely?
I am following the instructions
(http://ecos.sourceware.org/docs-latest/redboot/at91.html) to the word
with no sucess. Here are my steps:

1. arm-elf-gdb redboot.elf
~/work/atmel/020606-ARM/install/bin$ arm-elf-gdb redboot.elf
GNU gdb 5.3 (eCosCentric)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "--host=i686-pc-linux-gnu --target=arm-elf"...
(gdb) tar rdi /dev/ttyS0
Angel Debug Monitor (serial) 1.04 (Advanced RISC Machines SDT 2.5) for
AT91EB40 (2.00)
Angel Debug Monitor rebuilt on Apr 07 2000 at 12:40:31
Serial Rate:   9600
Connected to ARM RDI target.
(gdb) set $cpsr=0xd3
(gdb) load
Loading section .rom_vectors, size 0x40 lma 0x2020000
Loading section .text, size 0xb1bc lma 0x2020040
Loading section .rodata, size 0x1c37 lma 0x202b1fc
Loading section .data, size 0x404 lma 0x202ce34
Start address 0x2020040, load size 53815
Transfer rate: 6425 bits/sec, 498 bytes/write.
(gdb) cont
Continuing.

[3]+  Stopped                 arm-elf-gdb redboot.elf

Here I start minicom so I can load redboot.srec (I even desperately
tried redboot.img/bin)
~/work/atmel/020606-ARM/install/bin$ minicom -o

Welcome to minicom 2.1

OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n
Compiled on Nov  4 2005, 18:10:30.

Press CTRL-A Z for help on special keys

RedBoot> ver

RedBoot(tm) bootstrap and debug environment [RAM]
Non-certified release, version v2_0 - built 13:29:20, Jun  5 2006

Platform: Atmel AT91/EB40 (ARM7TDMI)
Copyright (C) 2000, 2001, 2002, Red Hat, Inc.

RAM: 0x02000000-0x02080000, 0x02033428-0x0207f000 available
FLASH: 0x01010000 - 0x01020000, 256 blocks of 0x00000100 bytes each.

RedBoot> load -m xmodem -b %{FREEMEMLO}

Address offset = 0x00013800
Entry point: 0x02033840, address range: 0x02033800-0x02040a38
xyzModem - CRC mode, 1264(SOH)/0(STX)/0(CAN) packets, 3 retries

RedBoot> fis wr -f 0x01010000 -b %{FREEMEMLO} -l 0xd238

* CAUTION * about to program FLASH

            at 0x01010000..0x0101d2ff from 0x02033800 - continue (y/n)? y

... Erase from 0x01010000-0x0101d300:
............................................................................................................
................................................................................
... Program from 0x02033800-0x02040b00 at 0x01010000:
............................................................................................
................................................................................
RedBoot>

After this step I set SW1 (on the EB40 board) to UPPER MEM then press
restart and nothing happens, meaning no output.


Thanks.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

AW: [ECOS] Huge memory footprint for a simple "hello world"

[Ram Sudhir Tadavarthi]

> Hi Ram;
> 
> I checked on Port B there's nothing coming out. The setup is :I have
> Port A connected to one machine from which I upload the application
> (bin_sim0) and port B connected to some other machine to see if
> anything comes out. From both machines nothing comes out. But if the
> application is redboot.elf I do see output on Port A only.

[Ram ] ok!!! 

1.Instead of using gdb, can you try to load the image through redboot using
"load" command and test?

2.Can you check if there is any signal movement on your serial port using an
oscilloscope or similar ?

3.Can you verify your virtual vectors configuration? 

Do these tests and post the results here if you still have problem.

Hope it helps,
ram







-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Huge memory footprint for a simple "hello world"

[Socrates Socrates]

Sorry about that.

Well the eb40 also has 2 serial ports. Since redboot is uploaded runs
runs (on RAM) well using port A, I imagine the tests applications will
also use the same port. If I recall (from Atmel's docs) well port A is
the one to be used for debugging.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

AW: [ECOS] Huge memory footprint for a simple "hello world"

[Ram Sudhir Tadavarthi]

> If I recall (from Atmel's docs) well port A is the one to be used for 
> debugging.

[Ram ]Just verify if there is output on the other port as it takes very
little time to check it practically.

Warms Regards,
Ram



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss