[mc1322x] Building mc1322x contiki

[Jon Smirl]

On Tue, Oct 6, 2009 at 3:07 PM, Umberto Manzoli <ruytenburch at gmail.com> wrote:
> Hi Jon,
>   I had some similar problems some time ago, and I found out it was a
> misplacement of (re)locations directives into the linker script.
> Would be so kind to check your linker script  and see if all needed code
> (and/or included by libraries) is assembled and relocated within 0x0040000
> and
> 0x00400000 + 96K? Which is the output of a size command  (with -A -x
> switches) on the produced elf executable?


It's just bringing in a bunch of unneeded code. Something isn't build
right in my cross tool. I'm in the process of building the OE version.

jonsmirl at terra:/home/apps/contiki-mc1322x/examples/hello-world$
arm-v4t-linux-gnueabi-size hello-world.mc1322x
   text	   data	    bss	    dec	    hex	filename
 490072	   2360	  12436	 504868	  7b424	hello-world.mc1322x
jonsmirl at terra:/home/apps/contiki-mc1322x/examples/hello-world$
arm-v4t-linux-gnueabi-size -A -x hello-world.mc1322x
hello-world.mc1322x  :
section                   size       addr
.text                  0x61380   0x400000
__libc_freeres_fn        0xcd8   0x461380
.stack                   0x720   0x462058
.rodata                0x14ee0   0x462778
.ARM.extab               0x2fc   0x477658
__libc_atexit              0x4   0x477954
__libc_subfreeres         0x2c   0x477958
.eh_frame                 0x7c   0x477984
.tdata                    0x10   0x477a00
.tbss                     0x18   0x477a10
.fini_array                0x4   0x477a10
.data.rel.ro              0x28   0x477a14
.got                      0x6c   0x477a3c
.data                    0x890   0x477aa8
.bss                    0x2548   0x478338
__libc_freeres_ptrs       0x14   0x47a880
.heap                    0x400   0x47a894
.stab                    0x18c        0x0
.stabstr                  0x2f        0x0
.comment                0x3206        0x0
.debug_aranges          0x2720        0x0
.debug_pubnames         0x673e        0x0
.debug_info            0xdf228        0x0
.debug_abbrev          0x21f44        0x0
.debug_line            0x2d062        0x0
.debug_frame            0x8004        0x0
.debug_str             0x12a07        0x0
.debug_loc             0x6c2f8        0x0
.debug_ranges          0x11798        0x0
ROM                      0x778        0x0
.ARM.attributes           0x32        0x0
Total                 0x24dcde


>
> Bye,
>   UM
>
> 2009/10/6 Jon Smirl <jonsmirl at gmail.com>
>>
>> On Tue, Oct 6, 2009 at 1:53 PM, Mariano Alvira <mar at devl.org> wrote:
>> > On Tue, Oct 06, 2009 at 01:45:25PM -0400, Mariano Alvira wrote:
>> >> On Tue, Oct 06, 2009 at 01:39:37PM -0400, Jon Smirl wrote:
>> >> >
>> >> > The problem is rooted at unwind-arm.o which calls abort.o It looks
>> >> > like uldivmod can trigger an exception, the exception handling pulls
>> >> > in 500K of run-time.
>> >> >
>> >> > So I need to figure out how to rebuild my libc with exceptions
>> >> > handling turned off?
>> >>
>> >> Maybe we should look at how the oe toolchain is built
>> >> w.r.t. exceptions first before trying to rebuild yours...
>> >>
>> >> -Mar.
>> >
>> > It looks like my cross is built with
>> > "--disable-libunwind-exceptions". It sounds to me like this could be
>> > the problem.
>>
>> That didn't fix it. -fno-exceptions didn't do it either. I've asked
>> the Phytec people how to fix it but they are gone for the day.
>>
>> I'll try building the OE toolchain. I like the Phytec one, it is so
>> much simpler to build.
>>
>> http://www.pengutronix.de/oselas/toolchain/index_en.html
>>
>>
>> >
>> > I've attached the gcc-cross_4.3.2.bb that I used for my toolchain.
>> >
>> > -Mar.
>> >
>> >
>> >
>>
>>
>>
>> --
>> Jon Smirl
>> jonsmirl at gmail.com
>>
>> _______________________________________________
>> mc1322x mailing list
>> mc1322x at devl.org
>> http://devl.org/cgi-bin/mailman/listinfo/mc1322x
>
>



-- 
Jon Smirl
jonsmirl at gmail.com