[ECOS] Re: Gary, could you give me some suggestions?

[ECOS] Re: Gary, could you give me some suggestions?

[Gary Thomas]

fisher.zhu@gmail.com wrote:
> Gary, I am doing the same work with taiyun mentioned in the below link.
> http://www.nabble.com/Re%3A-eCos-with-arm-eabi-compiler-p12628387.html
> But there is no more detailed information about how to solve the problem. Could you help me?
> I did the following work:
> 
> I use arm-none-eabi-ld --verbose and arm-elf-ld --verbose to print the detailed link script for comparison, and I also read the arm.ld of redboot in \src\hal\arm\arch\current\src. 
> I found after compiling with arm eabi tool chain, there is no ARM.exidex and ARM.extab in the generated target.ld. I edited target.ld and then make again. I get a redboot.elf. However, after I dumped the info of redboot.elf generated by arm-eabi. I found that __CTOR_LIST__ ,__CTOR_END__, __DTOR_LIST__, and __DTOR_END__ have the same pointer. It means that the constructors and destructors of redboot don't be compiled correctly. 
> 
> could you give me more suggestions? I am a newbie in embedded linux. 

First of all, this email should go to the eCos lists [CC'd] so that
all benefit - I only reply to private emails to those customers
that have a support contract [contact me if you want one!]

The fact that the CTOR and DTOR lists are empty is not surprising
since these are for C++ constructors and RedBoot does not use
any C++ classes/functions.

If you want to use the arm-eabi compiler (not recommended - why
not just use the arm-elf tool? choose the right tool for the job!),
I think there have been more discussions after the message you
quoted (and indeed, my reply only told the original poster how
to carry on, I did not actually address any of these issues)

-- 
------------------------------------------------------------
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] Re: Gary, could you give me some suggestions?

[Chris Zimman]

> > I use arm-none-eabi-ld --verbose and arm-elf-ld --verbose to print
> the detailed link script for comparison, and I also read the arm.ld of
> redboot in \src\hal\arm\arch\current\src.
> > I found after compiling with arm eabi tool chain, there is no
> ARM.exidex and ARM.extab in the generated target.ld. I edited target.ld
> and then make again. I get a redboot.elf. However, after I dumped the
> info of redboot.elf generated by arm-eabi. I found that __CTOR_LIST__
> ,__CTOR_END__, __DTOR_LIST__, and __DTOR_END__ have the same pointer.
> It means that the constructors and destructors of redboot don't be
> compiled correctly.
> >
> > could you give me more suggestions? I am a newbie in embedded linux.

There are a few things here if you're trying to get it to work with EABI.

(1)  Constructors are in a new section called .init_array -- they get created
in the opposite order that they are done under arm-elf, so you would need to
modify arm/arch/hal_misc.c as well as arm/arch/arm.ld

(2)  You need to provide .ARM.extab and .ARM.exidx as they are required by
EABI.  They need to be added in arm/arch/arm.ld

I have a working port of eCos w/ ARM EABI support that I've given to
eCosCentric.  I believe they are adding this to eCosPro (someone from
eCosCentric please correct me if I'm wrong here).

--Chris

--
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] Re: Gary, could you give me some suggestions?

[Fisher ZHU]

Dear Chris,

Thanks for your valuable help.

Yesterday, I made a little progress.
What have been done are listed below:
1) modify target.ld by replacing .ctors with .init_array as below,
__CTOR_LIST__ = ABSOLUTE(.) ;
KEEP(*(SORT(.init_array*)))
__CTOR_END__= ABSOLUTE(.) ;
2) add libc.a into GROUP(..) in target.ld and remove -nostdlib linker flag
3) make.

After done, the info of redboot.elf was dumped to check the
constructor list, and __CTOR_LIST and __CTOR_END  have different
addresses.

The above work removed the malloc() error encountered during flash
initialization, then after these work, no malloc() error occurs , but
redboot will fell in the state of waiting for BOOTP feedback after
ethernet controller initialization.

You mentioned that hal_misc.c needs to be modified.
Would you like to describe your work more detailedly or send me the
related modified files in your work package?

Thanks a lot.
--
br,
Fisher

On 5/13/08, Chris Zimman <czimman@bloomberg.com> wrote:
> > > I use arm-none-eabi-ld --verbose and arm-elf-ld --verbose to print
> > the detailed link script for comparison, and I also read the arm.ld of
> > redboot in \src\hal\arm\arch\current\src.
> > > I found after compiling with arm eabi tool chain, there is no
> > ARM.exidex and ARM.extab in the generated target.ld. I edited target.ld
> > and then make again. I get a redboot.elf. However, after I dumped the
> > info of redboot.elf generated by arm-eabi. I found that __CTOR_LIST__
> > ,__CTOR_END__, __DTOR_LIST__, and __DTOR_END__ have the same pointer.
> > It means that the constructors and destructors of redboot don't be
> > compiled correctly.
> > >
> > > could you give me more suggestions? I am a newbie in embedded linux.
>
> There are a few things here if you're trying to get it to work with EABI.
>
> (1)  Constructors are in a new section called .init_array -- they get created
> in the opposite order that they are done under arm-elf, so you would need to
> modify arm/arch/hal_misc.c as well as arm/arch/arm.ld
>
> (2)  You need to provide .ARM.extab and .ARM.exidx as they are required by
> EABI.  They need to be added in arm/arch/arm.ld
>
> I have a working port of eCos w/ ARM EABI support that I've given to
> eCosCentric.  I believe they are adding this to eCosPro (someone from
> eCosCentric please correct me if I'm wrong here).
>
> --Chris
>

-- 
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] Re: Gary, could you give me some suggestions?

[Chris Zimman]

Hi Fisher,

__CTOR_LIST__ and __CTOR_END__ are not used under EABI.  That's what
__init_array_start and __init_array_end replace respectively.

If you are using the CodeSourcery toolchain, there's a bug in the linker
that's waiting to be fixed.  ld -r is used to combine the .o's, and it
reorders the __init_array sections incorrectly.  There is an easy workaround
though, you need to add '-T /dev/null' to the 'ld -r' step so it doesn't use
the default linker script.

The reason that malloc() etc is probably failing is because the init steps
aren't running in the right order.

--Chris

> -----Original Message-----
> From: Fisher ZHU [mailto:fisher.zhu@gmail.com]
> Sent: 14 May 2008 10:28
> To: Chris Zimman
> Cc: eCos Discussion
> Subject: Re: [ECOS] Re: Gary, could you give me some suggestions?
> 
> Dear Chris,
> 
> Thanks for your valuable help.
> 
> Yesterday, I made a little progress.
> What have been done are listed below:
> 1) modify target.ld by replacing .ctors with .init_array as below,
> __CTOR_LIST__ = ABSOLUTE(.) ;
> KEEP(*(SORT(.init_array*)))
> __CTOR_END__= ABSOLUTE(.) ;
> 2) add libc.a into GROUP(..) in target.ld and remove -nostdlib linker
> flag
> 3) make.
> 
> After done, the info of redboot.elf was dumped to check the
> constructor list, and __CTOR_LIST and __CTOR_END  have different
> addresses.
> 
> The above work removed the malloc() error encountered during flash
> initialization, then after these work, no malloc() error occurs , but
> redboot will fell in the state of waiting for BOOTP feedback after
> ethernet controller initialization.
> 
> You mentioned that hal_misc.c needs to be modified.
> Would you like to describe your work more detailedly or send me the
> related modified files in your work package?
> 
> Thanks a lot.
> --
> br,
> Fisher
> 
> On 5/13/08, Chris Zimman <czimman@bloomberg.com> wrote:
> > > > I use arm-none-eabi-ld --verbose and arm-elf-ld --verbose to
> print
> > > the detailed link script for comparison, and I also read the arm.ld
> of
> > > redboot in \src\hal\arm\arch\current\src.
> > > > I found after compiling with arm eabi tool chain, there is no
> > > ARM.exidex and ARM.extab in the generated target.ld. I edited
> target.ld
> > > and then make again. I get a redboot.elf. However, after I dumped
> the
> > > info of redboot.elf generated by arm-eabi. I found that
> __CTOR_LIST__
> > > ,__CTOR_END__, __DTOR_LIST__, and __DTOR_END__ have the same
> pointer.
> > > It means that the constructors and destructors of redboot don't be
> > > compiled correctly.
> > > >
> > > > could you give me more suggestions? I am a newbie in embedded
> linux.
> >
> > There are a few things here if you're trying to get it to work with
> EABI.
> >
> > (1)  Constructors are in a new section called .init_array -- they get
> created
> > in the opposite order that they are done under arm-elf, so you would
> need to
> > modify arm/arch/hal_misc.c as well as arm/arch/arm.ld
> >
> > (2)  You need to provide .ARM.extab and .ARM.exidx as they are
> required by
> > EABI.  They need to be added in arm/arch/arm.ld
> >
> > I have a working port of eCos w/ ARM EABI support that I've given to
> > eCosCentric.  I believe they are adding this to eCosPro (someone from
> > eCosCentric please correct me if I'm wrong here).
> >
> > --Chris
> >

--
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] IDE configuration/identity

[Frank Pagliughi]

Hey All,

I'm looking to get a PC/104 platform going, using FAT/IDE on a 
CompactFlash device, and am having some trouble deciphering the 
configuration value. It looks like there was some debate when the code 
was originally posted, but I'm unsure of the resolution. The code 
(ide_disk.c) contains the check of the 16-bit configuration word with this:

        if (((ide_idData->general_conf>>8)&0x1f)!=2) {
            diag_printf("IDE device %d:%d is not a hard disk!\n",
                        info->port, info->chan);
            return false;
        }

The only reference I can find to this value is from the book, "The SCSI 
Bus and IDE Interface" by Friedhelm Schmidt, which claims this bit 
pattern for the configuration word:

    0  Reserved
    1  Hard-sectored drive
    2  Soft-sectored drive
    3  Encoding other than MFM
    4  Head switching time 15us
    5  Spindle motor control implemented
    6  Hard Drive
    7  Changeable medium
    8  Data rate to 5MHz
    9  Data rate between 5 and 10 MHz
    10 Data rate above 10 MHz
    11 Motor Speed tolerance above 0.5%
    12 Data clock offset available
    13 Track offset available
    14 Speed tolerance gap necessary
    15 Reserved

So, my questions...   Am I looking at the right values?  Can anyone 
confirm these bits?  And if so, why is the driver rejecting devices 
based on these values?

Thanks,
Frank



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