In fact, we just had a discussion about that in the core TinyOS group
with respect to a bug preventing the 2.1.1 release, with the
resolution being as below.

commit 7a57e99af4f24005e1634c4ca15a2f259358f416
Author: Peter A. Bigot <big...@acm.org>
Date:   Mon Jun 4 05:29:48 2012 -0500

    Update tosboot support for new mspgcc toolchain

    When --defsym=_reset_vector__=0x4000 is used, the object file from the crt0
    infrastructure that contains the weak default definition for _reset_vector__
    does not get linked in.  It's that object file that causes the rest of the
    CRT code to be included, due to its global references to the specific
    functions defined in each of the init sections.

    Add explicit references to the standard LTS-20120406 CRT functions that
    would normally be referenced due to the inclusion of the default
    _reset_vector__.

diff --git a/support/make/tosboot.extra b/support/make/tosboot.extra
index 0d330a5..e432359 100644
--- a/support/make/tosboot.extra
+++ b/support/make/tosboot.extra
@@ -14,6 +14,17 @@ ifeq ($(BOOTLOADER),tosboot)
     CFLAGS += -I$(DELUGE_EXTRA) -I$(DELUGE_EXTRA)/msp430
-I$(DELUGE_EXTRA)/telos
     ifeq ($(filter docs,$(GOALS)),)
       CFLAGS +=
-Wl,--section-start=.text=0x4a00,--defsym=_reset_vector__=0x4000
+      # Pull back in mspgcc CRT code discarded by the redefinition of
+      # _reset_vector__.
+      # NB: __watchdog_support was added in LTS-20120406 (4.6.3)
+      # All others are present in LTS-20110716 (4.5.3)
+      CFLAGS += -Wl,--undefined=__watchdog_support
+      CFLAGS += -Wl,--undefined=__init_stack
+      CFLAGS += -Wl,--undefined=__low_level_init
+      CFLAGS += -Wl,--undefined=__do_copy_data
+      CFLAGS += -Wl,--undefined=__do_clear_bss
+      CFLAGS += -Wl,--undefined=__stop_progExec__
+      CFLAGS += -Wl,--undefined=_endless_loop__
     endif
     ifeq ($(TARGETS),telosb)
        CFLAGS += -I$(DELUGE_EXTRA)/telosb




On Tue, Jun 12, 2012 at 9:04 AM, Michiel Konstapel
<m.konsta...@sownet.nl> wrote:
> While writing a simple boot loader, I ran into the following issue,
> originally posted to the tinyos-devel list:
>
> https://www.millennium.berkeley.edu/pipermail/tinyos-devel/2012-February
> /005074.html
>
>> When building an image to be installed along with TOSBoot, the linker
>> flag --defsym=_reset_vector__=0x4000 is set in
>> support/make/tosboot.extra. Unfortunately, this causes the linker to
>> conclude that the startup code from crt0 (initializing the
> stackpointer,
>> .data, and .bss sections) is unreachable and thus optimised out. I did
>> not find any obvious way to avoid this and ended up removing the
>> --defsym from tosboot.extra and afterwards hand-editing the vector
> table
>> in the resulting .ihex images of the applications.
>
> I wanted to use the same trick to move the application and still reset
> into the bootloader. Is there a recommended way to make msp430-ld keep
> the startup routines (__watchdog_support, __init_stack, __do_copy_data,
> __do_clear_bss)? In the msp430.x linker script, the init sections are
> already marked KEEP, but apparently that's not enough.
>
> Best,
> Michiel
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users

Reply via email to