I dislike the coupling between binutils and mspgcc that has gcc
decoding section names and changing the flags on the sections it
generates. Especially since with addition of infoa-infod we have six
such sections that would need to be special-cased instead of two
(.noinit is the other). It's cruel to the poor maintainer who's
trying to figure out what's going on, and to any user who wants to
create a similar section and can't see where the magic happens.
What I propose to do is instead add an attribute like "section" but
titled "nobits" which will change the .section pseudo-op in the
generated assembly code to use @nobits instead of @progbits for
whatever declaration it's attached to.
I'll probably make any occurrence of:
__attribute__((section(".infomemnobits")))
equivalent to:
__attribute__((section(".infomem"),nobits))
which will be almost the same as what it does now. But the new
sections for INFOA through INFOD will not have explicit nobits
variants, and the .infomemnobits section will be deprecated.
This approach should also eliminate the confusion that results if you
use both sections in one application. Currently, the declarations are
independent and therefore overlay each other.
What'll happen with this change is, if you do that in one translation
unit, you'll get an section type error from the compiler. If you do
this across object files, the section will be initialized but the
regions corresponding to nobits data will not be written. (That is,
the object file will include space but no data for those bytes.
Whatever actually programs the mcu may still wipe the entire flash
block, but I can't do anything about that.)
Comments?
Peter
On Thu, Jun 3, 2010 at 9:58 AM, Hans Nieuwenhuis <vz...@xs4all.nl> wrote:
> Cool! I'll check it out later.
>
> >From what I have read in the GCC sources it will flag the infomemnobits
> section as belonging to SECTION_BSS and therefore will not emit any
> code to the linker if I understood correctly. I think the best strategy
> is to let GCC do the same for infomemnobits[AD].
>
> Regards,
> Hans
>
> On Thu, 3 Jun 2010 09:15:34 -0500
> Peter Bigot <p...@peoplepowerco.com> wrote:
>
>> The patch for the basic problem (bad address for infomem on newer chips) has
>> been submitted to mspgcc4. Once the moderator approves it it'll go in. In
>> the meantime, it's integrated into the "next" branch of the git repository
>> for mspgcc4.
>>
>> This patch also corrects the use of cc430x5123 which should have been
>> cc430x5133; that affects both binutils and mspgcc4.
>>
>> I started work on splitting out infoa through infod, but stalled: there are
>> 47 data sheets to check, and it was only after the first pass through them
>> that I realized that some chips with a 256b info section split it into two
>> 128-byte chunks, and some into four 64-byte chunks. I need to revisit this,
>> and verify that nobits actually does what it's supposed to, before that can
>> be fixed. I expect "infomem" to be an alias section that overlays the info*
>> sections available on the chip.
>>
>> Peter
>>
>> On Fri, May 28, 2010 at 5:39 AM, JMGross <msp...@grossibaer.de> wrote:
>>
>> >
>> > All MSPs have at least InfoA and InfoB, most have InfoA..InfoD. Many have
>> > calibration data on InfoA, the 1x series has not and the 5x series and
>> > others have the data in the TLV structure in a separate segment which is
>> > (normally) read-only (but maybe writable in an undeocumented way). This is
>> > the latest TI invention.
>> > Also, on the 5x series and some others, the InfoA segment has a separate
>> > write protection bit in the flash controller and is not erased by a mass
>> > erase if this bit is set. This protection would have been very useful for
>> > those devices with calibration data in InfoA, but there there is no
>> > protection adn the 5x series has no data to protect.
>> > And then TI has made another not-so-smart move, as this bit is toggled by
>> > writing a '1', so a read-modify-write of the register for setting a
>> > different bit, will write back this bit as '1' and disable protection, and
>> > subsequent
>> > changes will read it as '0' and write it as '0', leaving protection off,
>> > making it pretty useless as protection scheme.
>> >
>> > We should provide all, infoX, infoXnobits (what a telling name!) as well as
>> > infomem/infomemnobits. Maybe for those devices with protected InfoA,
>> > infomem
>> > should not include this area.
>> >
>> > Also, on some devices, such as the 54xxA series (not the ones without A)
>> > the bootloader sector is writable. It also contains a software flash fuse
>> > area which will disable JTAG access if not all ff or 00, but leave JTAG
>> > messaging still intact. No more fuse burning with overvoltage, and it is
>> > reversable by the running software. So more and different sections.
>> >
>> > I do not really understand how the infomemnobits works. On my linker
>> > scripts, its script code looks 100% identical to the infomem section. So
>> > how
>> > does the linker know not to put out code for one of them.
>> >
>> > I have no idea of the template script, so I don't know what to do and how,
>> > or not.
>> >
>> > JMGross
>> >
>> > ----- Ursprüngliche Nachricht -----
>> > Von: Peter Bigot
>> > An: mspgcc-users@lists.sourceforge.net
>> > Gesendet am: 27 Mai 2010 18:25:39
>> > Betreff: Re: [Mspgcc-users] Linker script for msp430x54xx
>> >
>> > I'll get the basic patch for this into the queue for mspgcc4.
>> >
>> > Jens-Michael, would you say that for chips that have INFOA through INFOD,
>> > the sections should be named infoa (etc) and that infomem should be dropped
>> > on those chips? Do we need infoanobits (etc) for each of those as well?
>> >
>> > If the elf32msp430.sc template script is updated to make the bootloader,
>> > individual info, and combined infomem sections all optional driven by
>> > presence of the corresponding variable in the msp430all.sh script, just
>> > lik=
>> > e
>> > the fartext section is, is there any motivation to keep the forked
>> > elf32msp430_3 script?
>> >
>> > Peter
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> >
>> > _______________________________________________
>> > Mspgcc-users mailing list
>> > Mspgcc-users@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>> >
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit. See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Mspgcc-users mailing list
> Mspgcc-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
>
