<br><br><div class="gmail_quote">---------- Forwarded message ----------<br>From: <b class="gmail_sendername">Camilo, Alex</b> <span dir="ltr"><<a href="mailto:acamilo@neuronrobotics.com">acamilo@neuronrobotics.com</a>></span><br>
Date: Tue, Dec 8, 2009 at 11:54 AM<br>Subject: Re: [mc1322x] Fwd: contiki compilation error<br>To: Mariano Alvira <<a href="mailto:mar@devl.org">mar@devl.org</a>><br><br><br>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.<div>
<br></div><div>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.</div><div><br></div><div><div>blink.mc1322x: file format elf32-littlearm</div>
<div><br></div><div><br></div><div>Disassembly of section .text:</div><div><br></div><div>00400000 <__chameleon_output_from_thumb>:</div><div> 400000: 4778 bx pc</div><div> 400002: 46c0 nop (mov r8, r8)</div>
<div> 400004: ea000997 b 402668 <chameleon_output></div><div><br></div><div>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. </div>
<div><br></div><div><div>00402668 <chameleon_output>:</div><div> 402668: e38fc001 orr ip, pc, #1 ; 0x1</div><div> 40266c: e12fff1c bx ip</div><div><br></div><div>which then switches to THUMB mode and continues executing here. does some processing and then jumps somewhare.</div>
<div>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?</div><div><br></div><div>
<div>00402670 <.real_start_ofchameleon_output>:</div><div> 402670: b530 push {r4, r5, lr}</div><div> 402672: 4b0b ldr r3, [pc, #44] (4026a0 <.real_start_ofchameleon_output+0x30>)</div>
<div> 402674: 681b ldr r3, [r3, #0]</div><div> 402676: 1c04 adds r4, r0, #0</div><div> 402678: 2b00 cmp r3, #0</div><div> 40267a: d00d beq.n 402698 <.real_start_ofchameleon_output+0x28></div>
<div> 40267c: 685b ldr r3, [r3, #4]</div><div> 40267e: f000 f83b bl 4026f8 <.real_start_ofchameleon_init+0x14></div><div> 402682: 88a1 ldrh r1, [r4, #4]</div>
<div> 402684: 1c05 adds r5, r0, #0</div><div> 402686: 2001 movs r0, #1</div><div> 402688: f7fd fd4a bl 400120 <__packetbuf_set_attr_from_thumb></div><div>
40268c: 2d00 cmp r5, #0</div>
<div> 40268e: d003 beq.n 402698 <.real_start_ofchameleon_output+0x28></div><div> 402690: f7fd fcca bl 400028 <__rime_output_from_thumb></div><div> 402694: 2001 movs r0, #1</div>
<div> 402696: e000 b.n 40269a <.real_start_ofchameleon_output+0x2a></div><div> 402698: 2000 movs r0, #0</div><div> 40269a: bc30 pop {r4, r5}</div><div>
40269c: bc02 pop {r1}</div><div> 40269e: 4708 bx r1</div><div> 4026a0: 00407d28 .word 0x00407d28</div><div><br></div><div><br></div><div> 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.</div>
<div><br></div><div><div>00400000 <_start>:</div><div> 400000: ea0001ff b 400804 <_begin></div><div> 400004: e59ff844 ldr pc, [pc, #2116] ; 400850 <_undefined_instruction></div>
<div> 400008: e59ff844 ldr pc, [pc, #2116] ; 400854 <_software_interrupt></div><div> 40000c: e59ff844 ldr pc, [pc, #2116] ; 400858 <_prefetch_abort></div><div> 400010: e59ff844 ldr pc, [pc, #2116] ; 40085c <_data_abort></div>
<div> 400014: e59ff844 ldr pc, [pc, #2116] ; 400860 <_not_used></div><div> 400018: e59ff844 ldr pc, [pc, #2116] ; 400864 <_irq></div><div> 40001c: e59ff844 ldr pc, [pc, #2116] ; 400868 <_fiq></div>
<div><br></div><div>which is exactly what i would expect. </div></div></div></div><div><div></div><div class="h5"><br><div class="gmail_quote">On Tue, Dec 8, 2009 at 9:58 AM, Mariano Alvira <span dir="ltr"><<a href="mailto:mar@devl.org" target="_blank">mar@devl.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ah, ok.<br>
<br>
make hello-world.bin<br>
<br>
the .bin is the actual image that gets loaded on to the mc1322x. That<br>
shouldn't include the debug symbols.<br>
<br>
32k sounds about right for basic contiki and the resevered space for<br>
the ROM variables.<br>
<br>
-Mar.<br>
<div><div></div><div><br>
On Tue, Dec 08, 2009 at 08:44:47AM -0500, Camilo, Alex wrote:<br>
> Wait a minute, i think i had a brain fart, i'm sorry. the final tally is<br>
> On Tue, Dec 8, 2009 at 8:34 AM, Camilo, Alex <<a href="mailto:acamilo@neuronrobotics.com" target="_blank">acamilo@neuronrobotics.com</a>><br>
> wrote:<br>
><br>
> After reading the linked posts and doing some poking I don't think i'm<br>
> running into half of glibc bieng pulled in.<br>
> after looking at the sizes of the included components i see executable code<br>
> and data in the region where i would expect it to be and when i add up the<br>
> size of all of the segments in that region it comes out to approx 32k which<br>
> is good enough for me. The stuff that doesn't make sense is all the .debug_<br>
> data at address 0.<br>
><br>
> ubuntu@ubuntu-desktop:~/contiki-mc1322x/examples/hello-world$ arm-elf-size<br>
> -A -x hello-world.mc1322x<br>
> hello-world.mc1322x :<br>
> section size addr<br>
> .text 0x663c 0x400000<br>
> .stack 0x720 0x40663c<br>
> .rodata 0xa24 0x406d5c<br>
> .data 0x4fc 0x407780<br>
> .bss 0x1154 0x407c7c<br>
> .heap 0x400 0x408dd0<br>
> .stab 0x18c 0x0<br>
> .stabstr 0x2f 0x0<br>
> .comment 0x396 0x0<br>
> .debug_aranges 0x620 0x0<br>
> .debug_pubnames 0x1628 0x0<br>
> .debug_info 0xc730 0x0<br>
> .debug_abbrev 0x4866 0x0<br>
> .debug_line 0x372d 0x0<br>
> .debug_frame 0x1a04 0x0<br>
> .debug_str 0x2fb6 0x0<br>
> .debug_loc 0x5bed 0x0<br>
> .debug_ranges 0x528 0x0<br>
> .ARM.attributes 0x10 0x0<br>
> Total 0x2a50b<br>
><br>
><br>
> On Mon, Dec 7, 2009 at 12:05 PM, Mariano Alvira <<a href="mailto:mar@devl.org" target="_blank">mar@devl.org</a>> wrote:<br>
><br>
> On Mon, Dec 07, 2009 at 11:15:50AM -0500, Camilo, Alex wrote:<br>
> > I'l try installing a gnu-arm tool-chain from source and compiling my<br>
> libraries.<br>
> > I'm running into other problems such as the finished contiki binary<br>
> being about<br>
> > 250k.<br>
><br>
> This can happen when something links to a giant call tree from glibc<br>
> --- contiki calls exit in many places at that has been a<br>
> problem. There are others. EABI has also been a problem. Here are<br>
> some links to previous posts on the mailing list that might help:<br>
><br>
> <a href="http://devl.org/pipermail/mc1322x/2009-October/000039.html" target="_blank">http://devl.org/pipermail/mc1322x/2009-October/000039.html</a><br>
><br>
> and this post includes a perl script that will generate graph of what<br>
> is linking in what. This is useful for narrowing down to the exact<br>
> reason why giant portions of glibc are getting linked in:<br>
><br>
> <a href="http://devl.org/pipermail/mc1322x/2009-October/000040.html" target="_blank">http://devl.org/pipermail/mc1322x/2009-October/000040.html</a><br>
><br>
> -Mar.<br>
><br>
><br>
><br>
><br>
> --<br>
> Alex Camilo<br>
> 1-877-474-6038 ext#703<br>
> Head of Research and Design at Neuron Robotics, LLC.<br>
> <a href="http://www.neuronrobotics.com" target="_blank">www.neuronrobotics.com</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Alex Camilo<br>
> 1-877-474-6038 ext#703<br>
> Head of Research and Design at Neuron Robotics, LLC.<br>
> <a href="http://www.neuronrobotics.com" target="_blank">www.neuronrobotics.com</a><br>
<br>
</div></div>> _______________________________________________<br>
> mc1322x mailing list<br>
> <a href="mailto:mc1322x@devl.org" target="_blank">mc1322x@devl.org</a><br>
> <a href="http://devl.org/cgi-bin/mailman/listinfo/mc1322x" target="_blank">http://devl.org/cgi-bin/mailman/listinfo/mc1322x</a><br>
<br>
</blockquote></div><br>
</div></div></div>
</div><br><br clear="all"><br>-- <br>Alex Camilo<br>1-877-474-6038 ext#703<br>Head of Research and Design at Neuron Robotics, LLC.<br><a href="http://www.neuronrobotics.com">www.neuronrobotics.com</a><br>