[ECOS] problem with __CTOR_END and __CTOR_LIST

[ECOS] problem with __CTOR_END and __CTOR_LIST

[Claudio Di Vittorio]

hi everyone.
I'm currently developing a project on a custom ixp460
based board; this board has been designed following
the
scheme of ixdp465 (with some differences); now i have
to
prepare a working image of redboot, running from
flash,
to powerup and bootup the board; redboot must only
work as a bootloader.

I've already modified some .h, entering the correct
memory layout, flash size ecc.
My board is not equipped with FPGA,LED  and with CPLD,
so i disabled that part of code.

I'm not equipped with a JTAG emulator; i'm just
programming ever time the flash memory....

when i bootup the board i see that hardware init
sequence seems to be succesful. After that the board
print out (on serial port) a long string and then
everything freeze; the string is:

$O5B53696D322068616C5F6D6973635D20496E766F6B65640A#CD

Following the assembly code in vectors.S, and adding
some debug messages (using  diag_printf ) i've seen
that the bootup stops BEFORE calling cyg_start;
the problem occurs in call to:

cyg_hal_invoke_constructors

following that function i see that when the program
tries to access __CTOR_END_ and __CTOR_LIST_
everything
stops working.

I'm using configtool 2.11 and the GNU utils given by
Intel in their web site.

Does anybody can give me some help about this?
Or can someone explain me something better on that 
error? 

thanks

claudio



__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

-- 
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] problem with __CTOR_END and __CTOR_LIST

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 1989 bytes --]

Claudio Di Vittorio wrote:
> hi everyone.
> I'm currently developing a project on a custom ixp460
> based board; this board has been designed following
> the
> scheme of ixdp465 (with some differences); now i have
> to
> prepare a working image of redboot, running from
> flash,
> to powerup and bootup the board; redboot must only
> work as a bootloader.
> 
> I've already modified some .h, entering the correct
> memory layout, flash size ecc.
> My board is not equipped with FPGA,LED  and with CPLD,
> so i disabled that part of code.
> 
> I'm not equipped with a JTAG emulator; i'm just
> programming ever time the flash memory....
> 
> when i bootup the board i see that hardware init
> sequence seems to be succesful. After that the board
> print out (on serial port) a long string and then
> everything freeze; the string is:
> 
> $O5B53696D322068616C5F6D6973635D20496E766F6B65640A#CD
> 
> Following the assembly code in vectors.S, and adding
> some debug messages (using  diag_printf ) i've seen
> that the bootup stops BEFORE calling cyg_start;
> the problem occurs in call to:
> 
> cyg_hal_invoke_constructors
> 
> following that function i see that when the program
> tries to access __CTOR_END_ and __CTOR_LIST_
> everything
> stops working.
> 
> I'm using configtool 2.11 and the GNU utils given by
> Intel in their web site.
> 
> Does anybody can give me some help about this?
> Or can someone explain me something better on that 
> error? 

It's not an error, just a message that got printed using the
GDB protocol.  It says:
   '[Sim2 hal_misc] Invoked'

BTW, the attached program will decode these strings for you.
I use it all the time :-)  Just run it like this:
   % python decode_gdb.py '$O5B53696D322068616C5F6D6973635D20496E766F6B65640A#CD'

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

[-- Attachment #2: decode_gdb.py --]
[-- Type: text/x-python, Size: 895 bytes --]

#! /usr/bin/env python

import sys

def hex_chr(ch):
    if ((ch >= '0') & (ch <= '9')):
        return ord(ch) - ord('0')
    if ((ch >= 'a') & (ch <= 'f')):
        return ord(ch) - ord('a') + 0x0a
    if ((ch >= 'A') & (ch <= 'F')):
        return ord(ch) - ord('A') + 0x0A
    
def gdb_char(str):
    _hex = (hex_chr(str[0]) << 4) | hex_chr(str[1])
    return chr(_hex)

if len(sys.argv) == 1:
    gdb_string = "$O5B6379675F6E65745F696E69745D20496E69743A206D62696E69742830783030303030303030290A#60"
    gdb_string = "$O464C4153482049443A2030312032323765203232313320323230310A#98"
    gdb_string = "$O68616C5F6D7063383378785F6932635F7075745F62797465732E3333370A#33"
else:
    gdb_string = sys.argv[1]
    
human_string = ""

gdb_string = gdb_string[2:] # Strip $O

while gdb_string[0] != '#':
    human_string += gdb_char(gdb_string[0:2])
    gdb_string = gdb_string[2:]

print human_string


[-- Attachment #3: Type: text/plain, Size: 148 bytes --]

-- 
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] problem with __CTOR_END and __CTOR_LIST

[Gary Thomas]

Gary Thomas wrote:
> Claudio Di Vittorio wrote:
>> hi everyone.
>> I'm currently developing a project on a custom ixp460
>> based board; this board has been designed following
>> the
>> scheme of ixdp465 (with some differences); now i have
>> to
>> prepare a working image of redboot, running from
>> flash,
>> to powerup and bootup the board; redboot must only
>> work as a bootloader.
>>
>> I've already modified some .h, entering the correct
>> memory layout, flash size ecc.
>> My board is not equipped with FPGA,LED  and with CPLD,
>> so i disabled that part of code.
>>
>> I'm not equipped with a JTAG emulator; i'm just
>> programming ever time the flash memory....
>>
>> when i bootup the board i see that hardware init
>> sequence seems to be succesful. After that the board
>> print out (on serial port) a long string and then
>> everything freeze; the string is:
>>
>> $O5B53696D322068616C5F6D6973635D20496E766F6B65640A#CD
>>
>> Following the assembly code in vectors.S, and adding
>> some debug messages (using  diag_printf ) i've seen
>> that the bootup stops BEFORE calling cyg_start;
>> the problem occurs in call to:
>>
>> cyg_hal_invoke_constructors
>>
>> following that function i see that when the program
>> tries to access __CTOR_END_ and __CTOR_LIST_
>> everything
>> stops working.
>>
>> I'm using configtool 2.11 and the GNU utils given by
>> Intel in their web site.
>>
>> Does anybody can give me some help about this?
>> Or can someone explain me something better on that error? 
> 
> It's not an error, just a message that got printed using the
> GDB protocol.  It says:
>   '[Sim2 hal_misc] Invoked'
> 
> BTW, the attached program will decode these strings for you.
> I use it all the time :-)  Just run it like this:
>   % python decode_gdb.py 
> '$O5B53696D322068616C5F6D6973635D20496E766F6B65640A#CD'
> 

Hint: if you want to carry on after seeing the message, just
type '+' on the terminal.  This completes the GDB protocol
handshake and your code will continue.

-- 
------------------------------------------------------------
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: [ECOS] problem with __CTOR_END and __CTOR_LIST

[Paul D. DeRocco]

> From: Gary Thomas
>
> Hint: if you want to carry on after seeing the message, just
> type '+' on the terminal.  This completes the GDB protocol
> handshake and your code will continue.

Wouldn't it make more sense just to talk to it through GDB, instead of a
terminal program?

--

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco@ix.netcom.com


-- 
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] problem with __CTOR_END and __CTOR_LIST

[Gary Thomas]

Paul D. DeRocco wrote:
>> From: Gary Thomas
>>
>> Hint: if you want to carry on after seeing the message, just
>> type '+' on the terminal.  This completes the GDB protocol
>> handshake and your code will continue.
> 
> Wouldn't it make more sense just to talk to it through GDB, instead of a
> terminal program?

Except that he's trying to bring up RedBoot which [when it
works] will shortly stop talking GDB and he'd then be lost.

-- 
------------------------------------------------------------
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: [ECOS] problem with __CTOR_END and __CTOR_LIST

[Claudio Di Vittorio]

Thanks everyone!
Now with the '+' it's working!
thanks again!
 
claudio


__________________________________________________
Do You Yahoo!?
Poco spazio e tanto spam? Yahoo! Mail ti protegge dallo spam e ti da tanto spazio gratuito per i tuoi file e i messaggi 
http://mail.yahoo.it 

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

[ECOS] Redboot heap utilisation

[Gernot Zankl]

Hi !

How does redboot handle it's heap ?
Is there a limit for the RAM, which is reserved for redboot ?

My current problem is, that an application (approx. 2MB elf-format) does
not start
if it is loaded from the jffs2 into RAM at its starting address
(0x80000). 
But if the same application is loaded into RAM at a "higher"
offset (e.g. 0x300000) and then copied down to its starting address the
same 
application works perfectly.

Is it possible that handling of jffs2 and loading an application may
allocate
memory on the heap which may overlap with the starting address of the
application ?

Thanks in advance.

Regards, 
Gernot


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