[mc1322x] Fwd: Fwd: contiki compilation error
Camilo, Alex
acamilo at neuronrobotics.com
Tue Dec 8 12:00:40 EST 2009
---------- Forwarded message ----------
From: Camilo, Alex <acamilo at neuronrobotics.com>
Date: Tue, Dec 8, 2009 at 11:54 AM
Subject: Re: [mc1322x] Fwd: contiki compilation error
To: Mariano Alvira <mar at devl.org>
Sorry about that, for some reason I kept thinking that the
hello-world.mc1322x was the binary. I was getting confused when
arm-elf-objdump was working on it but since i haven't used gcc in some time
I assumed that some shenanigans that i didn't understand where working their
magic. I got the code to compile however it doesn't do anything. I used
objdump -D to take a look at what was going on under the hood and comparing
an example with the contiki binary and i'm a but confused.
in the contiki object file (before make runs objdump to make the binary) i
noticed this chunk of code at the execution-start-vector in ram.
blink.mc1322x: file format elf32-littlearm
Disassembly of section .text:
00400000 <__chameleon_output_from_thumb>:
400000: 4778 bx pc
400002: 46c0 nop (mov r8, r8)
400004: ea000997 b 402668 <chameleon_output>
The arm comes out of the bootloader in ARM mode so the first two
instructions would trigger an unidentified instruction fault causing the
address 0x4 to be called which is in rom. This code jumps to 40000004 and
executes the arm branch instruction taking us to.
00402668 <chameleon_output>:
402668: e38fc001 orr ip, pc, #1 ; 0x1
40266c: e12fff1c bx ip
which then switches to THUMB mode and continues executing here. does some
processing and then jumps somewhare.
so the CPU is doing something. but why do we need to do this? isnt the CPU
usually in arm mode at this stage in the boot process? does it have to do
with one of the hibernation or sleep modes?
00402670 <.real_start_ofchameleon_output>:
402670: b530 push {r4, r5, lr}
402672: 4b0b ldr r3, [pc, #44] (4026a0
<.real_start_ofchameleon_output+0x30>)
402674: 681b ldr r3, [r3, #0]
402676: 1c04 adds r4, r0, #0
402678: 2b00 cmp r3, #0
40267a: d00d beq.n 402698
<.real_start_ofchameleon_output+0x28>
40267c: 685b ldr r3, [r3, #4]
40267e: f000 f83b bl 4026f8
<.real_start_ofchameleon_init+0x14>
402682: 88a1 ldrh r1, [r4, #4]
402684: 1c05 adds r5, r0, #0
402686: 2001 movs r0, #1
402688: f7fd fd4a bl 400120
<__packetbuf_set_attr_from_thumb>
40268c: 2d00 cmp r5, #0
40268e: d003 beq.n 402698
<.real_start_ofchameleon_output+0x28>
402690: f7fd fcca bl 400028 <__rime_output_from_thumb>
402694: 2001 movs r0, #1
402696: e000 b.n 40269a
<.real_start_ofchameleon_output+0x2a>
402698: 2000 movs r0, #0
40269a: bc30 pop {r4, r5}
40269c: bc02 pop {r1}
40269e: 4708 bx r1
4026a0: 00407d28 .word 0x00407d28
The thing that confuses me is why are we in chameleon code? shouldn't we be
doing something like setting up stack frames and initializing hardware? and
shouldn't we be branching to exception handling functions? and If i recall
correctly isn't chameleon a packet processing library? Do you think my
toolchain is borked? thats what I would conclude, however when taking a look
at the blink-red disassembly i see this.
00400000 <_start>:
400000: ea0001ff b 400804 <_begin>
400004: e59ff844 ldr pc, [pc, #2116] ; 400850
<_undefined_instruction>
400008: e59ff844 ldr pc, [pc, #2116] ; 400854
<_software_interrupt>
40000c: e59ff844 ldr pc, [pc, #2116] ; 400858
<_prefetch_abort>
400010: e59ff844 ldr pc, [pc, #2116] ; 40085c
<_data_abort>
400014: e59ff844 ldr pc, [pc, #2116] ; 400860 <_not_used>
400018: e59ff844 ldr pc, [pc, #2116] ; 400864 <_irq>
40001c: e59ff844 ldr pc, [pc, #2116] ; 400868 <_fiq>
which is exactly what i would expect.
On Tue, Dec 8, 2009 at 9:58 AM, Mariano Alvira <mar at devl.org> wrote:
> Ah, ok.
>
> make hello-world.bin
>
> the .bin is the actual image that gets loaded on to the mc1322x. That
> shouldn't include the debug symbols.
>
> 32k sounds about right for basic contiki and the resevered space for
> the ROM variables.
>
> -Mar.
>
> On Tue, Dec 08, 2009 at 08:44:47AM -0500, Camilo, Alex wrote:
> > Wait a minute, i think i had a brain fart, i'm sorry. the final tally is
> > On Tue, Dec 8, 2009 at 8:34 AM, Camilo, Alex <acamilo at neuronrobotics.com
> >
> > wrote:
> >
> > After reading the linked posts and doing some poking I don't think
> i'm
> > running into half of glibc bieng pulled in.
> > after looking at the sizes of the included components i see
> executable code
> > and data in the region where i would expect it to be and when i add
> up the
> > size of all of the segments in that region it comes out to approx 32k
> which
> > is good enough for me. The stuff that doesn't make sense is all the
> .debug_
> > data at address 0.
> >
> > ubuntu at ubuntu-desktop:~/contiki-mc1322x/examples/hello-world$
> arm-elf-size
> > -A -x hello-world.mc1322x
> > hello-world.mc1322x :
> > section size addr
> > .text 0x663c 0x400000
> > .stack 0x720 0x40663c
> > .rodata 0xa24 0x406d5c
> > .data 0x4fc 0x407780
> > .bss 0x1154 0x407c7c
> > .heap 0x400 0x408dd0
> > .stab 0x18c 0x0
> > .stabstr 0x2f 0x0
> > .comment 0x396 0x0
> > .debug_aranges 0x620 0x0
> > .debug_pubnames 0x1628 0x0
> > .debug_info 0xc730 0x0
> > .debug_abbrev 0x4866 0x0
> > .debug_line 0x372d 0x0
> > .debug_frame 0x1a04 0x0
> > .debug_str 0x2fb6 0x0
> > .debug_loc 0x5bed 0x0
> > .debug_ranges 0x528 0x0
> > .ARM.attributes 0x10 0x0
> > Total 0x2a50b
> >
> >
> > On Mon, Dec 7, 2009 at 12:05 PM, Mariano Alvira <mar at devl.org>
> wrote:
> >
> > On Mon, Dec 07, 2009 at 11:15:50AM -0500, Camilo, Alex wrote:
> > > I'l try installing a gnu-arm tool-chain from source and
> compiling my
> > libraries.
> > > I'm running into other problems such as the finished contiki
> binary
> > being about
> > > 250k.
> >
> > This can happen when something links to a giant call tree from
> glibc
> > --- contiki calls exit in many places at that has been a
> > problem. There are others. EABI has also been a problem. Here are
> > some links to previous posts on the mailing list that might help:
> >
> > http://devl.org/pipermail/mc1322x/2009-October/000039.html
> >
> > and this post includes a perl script that will generate graph of
> what
> > is linking in what. This is useful for narrowing down to the
> exact
> > reason why giant portions of glibc are getting linked in:
> >
> > http://devl.org/pipermail/mc1322x/2009-October/000040.html
> >
> > -Mar.
> >
> >
> >
> >
> > --
> > Alex Camilo
> > 1-877-474-6038 ext#703
> > Head of Research and Design at Neuron Robotics, LLC.
> > www.neuronrobotics.com
> >
> >
> >
> >
> > --
> > Alex Camilo
> > 1-877-474-6038 ext#703
> > Head of Research and Design at Neuron Robotics, LLC.
> > www.neuronrobotics.com
>
> > _______________________________________________
> > mc1322x mailing list
> > mc1322x at devl.org
> > http://devl.org/cgi-bin/mailman/listinfo/mc1322x
>
>
--
Alex Camilo
1-877-474-6038 ext#703
Head of Research and Design at Neuron Robotics, LLC.
www.neuronrobotics.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://devl.org/pipermail/mc1322x/attachments/20091208/e28359d3/attachment.htm>
More information about the mc1322x
mailing list