Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Lev Serebryakov-2
Hello, DJ.

 $subj?

 I want to pack new toolchain for FreeBSD, is here any specific
instructions? Build order? LD scripts sources? Which vercion of libc should
I use?

 As far as I remember, there was strong "embedded world want toolchian, not
separate binutils/compiler/libc/system headers" message when we discussed
MSP430 transition to RedHat/TI-ported gcc. Should I build such complete
package (As I do for gcc-arm-embedded) or separate packages are Ok?

 And build order still bother me, as, as far as I understand, "official" gcc
should be built twice, one for building libc and other with this libc
support, which doesn't fit good to "everything is separate package" model.

--
// Black Lion AKA Lev Serebryakov <[hidden email]>


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

DJ Delorie

There's nothing special about the msp430-elf tools; you cross-build
them just like any other embedded toolchain.  If you can, use the
latest versions of gcc, binutils, gdb, and newlib (which is typically
the development head if there hasn't been a recent release).  If you
download the TI build of the tools, you'll get one cohesive package,
so yeah, it's probably what people want.  The only exception would be,
for example, if you were packaging for a distro and you want to
support upgrading.  In those cases, it's better for the packaging if
the package version numbers match the upstream version numbers, which
means separate packages.

As for the two-stepping of gcc, note that modern gcc releases have
separate host and target parts of the build.  You do "make all-host;
make install-host" at first, which gives you the compiler but not the
runtime, then you build the libraries, then go back to gcc and do
"make all; make install" to do the rest.  This is needed regardless of
which runtime you use.

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Lev Serebryakov-2
Hello, DJ.
You wrote 18 мая 2014 г., 23:55:28:

DD> so yeah, it's probably what people want.  The only exception would be,
DD> for example, if you were packaging for a distro and you want to
DD> support upgrading.  In those cases, it's better for the packaging if
DD> the package version numbers match the upstream version numbers, which
DD> means separate packages.
  So, there is contradiction between requirements :)

DD> As for the two-stepping of gcc, note that modern gcc releases have
DD> separate host and target parts of the build.  You do "make all-host;
DD> make install-host" at first, which gives you the compiler but not the
DD> runtime, then you build the libraries, then go back to gcc and do
DD> "make all; make install" to do the rest.  This is needed regardless of
DD> which runtime you use.
  And it contradicts to building separate packages too, because you could
 not build and install half of a package ("make all-host install-host"), build other package
 (runtime) and build & install second part of a package ("make all
 install"), it is completely insane. Or you should break gcc package into
 two but, again, it is impossible in most packaging systems to do "make all
 install" from SAME directory you did "make all-host install-host" for other
 package!

  So, it will be one package.

--
// Black Lion AKA Lev Serebryakov <[hidden email]>


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

DJ Delorie

> DD> so yeah, it's probably what people want.  The only exception would be,
> DD> for example, if you were packaging for a distro and you want to
> DD> support upgrading.  In those cases, it's better for the packaging if
> DD> the package version numbers match the upstream version numbers, which
> DD> means separate packages.
>   So, there is contradiction between requirements :)

Not quite.  For distros, you have a separate package which is the
"collector" for all the other packages.  For example, if you installed
"mspgcc" then that package would automatically pull in all the
sub-packages like gcc, binutils, etc, and let the sub-packages update
independently of the collector package.

>   And it contradicts to building separate packages too, because you
>  could not build and install half of a package

Not much I can help with here, the upstream sources are what they are.
Even porting linux to new architectures, we run into these problems.
The solution is that someone does it manually once, and after that,
you build each package using the previous version of the other package
each time.

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Lev Serebryakov-2
Hello, DJ.
You wrote 19 мая 2014 г., 0:18:17:


>>   And it contradicts to building separate packages too, because you
>>  could not build and install half of a package
DD> Not much I can help with here, the upstream sources are what they are.
DD> Even porting linux to new architectures, we run into these problems.
DD> The solution is that someone does it manually once, and after that,
DD> you build each package using the previous version of the other package
DD> each time.
 I see... Two more questions:

 (1) Is newlib-nano supported?
 (2) Is C++ supported?

--
// Black Lion AKA Lev Serebryakov <[hidden email]>


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

DJ Delorie

>  (1) Is newlib-nano supported?
>  (2) Is C++ supported?

Tricky questions.  Technically, if you don't have a support contract
with someone, the answer is "no" because, well, because ;-)

But the answers you probably want are...

I haven't tried newlib-nano but there's no reason why it wouldn't work.

The tools support C++ although getting it to work well in smaller
RAM'd chips might be tricky.  We test it internally, but our simulator
has lots of RAM.  Heck, the tools probably support other languages as
well but we haven't tested them.

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Lev Serebryakov-2
Hello, DJ.
You wrote 19 мая 2014 г., 1:15:28:

>>  (1) Is newlib-nano supported?
>>  (2) Is C++ supported?
DD> Tricky questions.  Technically, if you don't have a support contract
DD> with someone, the answer is "no" because, well, because ;-)
DD> But the answers you probably want are...
DD> I haven't tried newlib-nano but there's no reason why it wouldn't work.
DD> The tools support C++ although getting it to work well in smaller
DD> RAM'd chips might be tricky.  We test it internally, but our simulator
DD> has lots of RAM.  Heck, the tools probably support other languages as
DD> well but we haven't tested them.
 Ok, I see.

 BTW, do I need GCC_RH_20140508.zip too? Whereshould I unpack it?

 Grrr, using "latest newlib" is a problem for package system :(

--
// Black Lion AKA Lev Serebryakov <[hidden email]>


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Lev Serebryakov-2
In reply to this post by DJ Delorie
Hello, DJ.
You wrote 19 мая 2014 г., 1:15:28:

 It looks like that this toolchain is not ready for packaging :(

 binutils-2.24 could not build newlib-2.1 (known problem, according to this
 list).

 Latest binutils (2.24.51) could not be built by itself, due to errors:

cc -DHAVE_CONFIG_H -I. -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils  -I. -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils -I../bfd -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/../bfd -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/../include -DLOCALEDIR="\"/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/install/gcc-msp430-embedded-2.24.51.4.9.0.2.1.0/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -O2 -pipe -fno-strict-aliasing -Wno-error -MT bucomm.o -MD -MP -MF .deps/bucomm.Tpo -c -o bucomm.o /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c
/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c:130:1: error: variable has incomplete type 'void'
fatal VPARAMS ((const char *format, ...))
^
/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c:130:6: error: expected ';' after top level declarator
fatal VPARAMS ((const char *format, ...))
     ^
     ;
2 errors generated.
gmake[6]: *** [bucomm.o] Error 1


 And there is not "intermediate" snapshots between them!

--
// Black Lion AKA Lev Serebryakov <[hidden email]>


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Peter Bigot-4
A chain of messages related to building and packaging is available at:

http://www.mail-archive.com/mspgcc-users@.../msg12028.html

At least two of us have successfully built toolchains with those
instructions; how to convert them into packaging for a particular
distribution isn't something that's likely to come from this list.  My
recommendation is follow the distribution's standard practices for
cross-compilation toolchains and look to existing solutions like AVR
and ARM for guidance.

TI makes some material available on:
http://www.ti.com/tool/msp430-gcc-opensource

Personally I would not package a vendor-supplied fork, but that's a
policy decision for the distribution.

I notice that the most recent TI toolchain 371 (which is an update to
version 317 that comes with the CCS 6.0.0-190 release) has been posted
there in binary and source form.  The old source releases have been
removed.  I've reminded TI that the GPL licensing may require that
they remain available but am leaving any fights in that battle to
anybody who cares.

The upstream software (gcc, binutils, newlib) is incomplete: you do
need the headers and linker files from TI, which are available on TI's
page.   TI has not provided recommended integration practices for the
headers and linker scripts, nor promises related to
maintenance/compatibility/etc, so we're on our own.  In the days of
mspgcc those were carefully separated out as msp430mcu so you could
update the available MCUs without updating the toolchain; it would be
nice if new packaging solutions followed that practice.  Although I've
preferred to install those out-of-tree and add compiler flags so the
toolchain locates them, I think it's better to follow Eric's
recommendations in
http://www.mail-archive.com/mspgcc-users%40lists.sourceforge.net/msg12046.html
and overlay them into the toolchain installation directory so they're
found without special arguments.

I noticed that __delay_cycles has been pushed to gcc trunk (though not
gcc-4_9-branch) so when I finish some other projects I'll be coming
back and checking out the latest versions of everything.  newlib-nano
does work, though I'm still unhappy with the vendor-specific and
undocumented sys interface, and may fork an alternative.  C++ is
viable but using C++ runtime features is probably not practical due to
code size.

Once I've switched to using msp430-elf-gcc all pretense that mspgcc is
supported will vanish.  Unofficially, that's already occurred.

Peter


On Mon, May 19, 2014 at 3:52 AM, Lev Serebryakov <[hidden email]> wrote:

> Hello, DJ.
> You wrote 19 мая 2014 г., 1:15:28:
>
>  It looks like that this toolchain is not ready for packaging :(
>
>  binutils-2.24 could not build newlib-2.1 (known problem, according to this
>  list).
>
>  Latest binutils (2.24.51) could not be built by itself, due to errors:
>
> cc -DHAVE_CONFIG_H -I. -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils  -I. -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils -I../bfd -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/../bfd -I/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/../include -DLOCALEDIR="\"/usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/install/gcc-msp430-embedded-2.24.51.4.9.0.2.1.0/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -O2 -pipe -fno-strict-aliasing -Wno-error -MT bucomm.o -MD -MP -MF .deps/bucomm.Tpo -c -o bucomm.o /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c
> /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c:130:1: error: variable has incomplete type 'void'
> fatal VPARAMS ((const char *format, ...))
> ^
> /usr/home/lev/FreeBSD/ports/devel/gcc-msp430-embedded/work/binutils-2.24.51/binutils/bucomm.c:130:6: error: expected ';' after top level declarator
> fatal VPARAMS ((const char *format, ...))
>      ^
>      ;
> 2 errors generated.
> gmake[6]: *** [bucomm.o] Error 1
>
>
>  And there is not "intermediate" snapshots between them!
>
> --
> // Black Lion AKA Lev Serebryakov <[hidden email]>
>
>
> ------------------------------------------------------------------------------
> "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
> Instantly run your Selenium tests across 300+ browser/OS combos.
> Get unparalleled scalability from the best Selenium testing platform available
> Simple to use. Nothing to install. Get started now for free."
> http://p.sf.net/sfu/SauceLabs
> _______________________________________________
> Mspgcc-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Lev Serebryakov-2
Hello, Peter.
You wrote 19 мая 2014 г., 15:04:05:

PB> A chain of messages related to building and packaging is available at:
PB> http://www.mail-archive.com/mspgcc-users@.../msg12028.html
PB> At least two of us have successfully built toolchains with those
PB> instructions; how to convert them into packaging for a particular
PB> distribution isn't something that's likely to come from this list.  My
PB> recommendation is follow the distribution's standard practices for
PB> cross-compilation toolchains and look to existing solutions like AVR
PB> and ARM for guidance.
  Problem with this instructions starts from very beginning:

binutils git://sourceware.org/git/binutils-gdb.git master
gcc git://gcc.gnu.org/git/gcc.git gcc-4_9-branch
newlib git://sourceware.org/git/newlib.git master

 Not-released software could not be packaged! We could only refer to stable,
non-changeable, tarballs on vendor's server, not to some "git revision" or
some "${packaghename}.tar.bz2", which could be changed (re-rolled) under same
name :(

 It is not exactly "how to convert them into packaging for a particular distribution
isn't something that's likely to come from this list.", it is discussion
about status of toolchain which, as I could say now, is not ready for
distro-packaging due to absence of any suitable "releases", may be,
snapshot-quality, but "stable" in sense of content.

PB> TI makes some material available on:
PB> http://www.ti.com/tool/msp430-gcc-opensource

PB> Personally I would not package a vendor-supplied fork, but that's a
PB> policy decision for the distribution.
 Yep, but on other hand it is "stable", well-named file :)

PB> Once I've switched to using msp430-elf-gcc all pretense that mspgcc is
PB> supported will vanish.  Unofficially, that's already occurred.
 Anyway, thank you for all you work on mspgcc!

--
// Black Lion AKA Lev Serebryakov <[hidden email]>


------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
Reply | Threaded
Open this post in threaded view
|

Re: Are here any msp430-elf target full toolchain build instructions a'la gcc-arm-embedded?

Peter Bigot-4
On Mon, May 19, 2014 at 8:36 AM, Lev Serebryakov <[hidden email]> wrote:

> Hello, Peter.
> You wrote 19 мая 2014 г., 15:04:05:
>
> PB> A chain of messages related to building and packaging is available at:
> PB> http://www.mail-archive.com/mspgcc-users@.../msg12028.html
> PB> At least two of us have successfully built toolchains with those
> PB> instructions; how to convert them into packaging for a particular
> PB> distribution isn't something that's likely to come from this list.  My
> PB> recommendation is follow the distribution's standard practices for
> PB> cross-compilation toolchains and look to existing solutions like AVR
> PB> and ARM for guidance.
>   Problem with this instructions starts from very beginning:
>
> binutils git://sourceware.org/git/binutils-gdb.git master
> gcc git://gcc.gnu.org/git/gcc.git gcc-4_9-branch
> newlib git://sourceware.org/git/newlib.git master
>
>  Not-released software could not be packaged! We could only refer to stable,
> non-changeable, tarballs on vendor's server, not to some "git revision" or
> some "${packaghename}.tar.bz2", which could be changed (re-rolled) under same
> name :(

This is a distribution policy.  Most distributions have a solution for
that problem, based on an archived canonical tarball.  Some, like
Yocto, even extend that to support packaging never-released versions
through reference to a git SHA1 or SVN commit in a public repository
branch that the maintainers promise to never rebase.

There are also release branches in those repositories which you could
try (gcc-4_9-branch is one of them).

>  It is not exactly "how to convert them into packaging for a particular distribution
> isn't something that's likely to come from this list.", it is discussion
> about status of toolchain which, as I could say now, is not ready for
> distro-packaging due to absence of any suitable "releases", may be,
> snapshot-quality, but "stable" in sense of content.

If you mean that strictly, I don't think it'll be true for
msp430-elf-gcc until all the component packages have stable releases
that are known to interoperate, and possibly never unless TI promises
not to "changed (re-rolled) under same name" the pieces that are only
available from them, and makes the material compatible with those
stable releases rather than just their fork.

You may be waiting a while.

> PB> Personally I would not package a vendor-supplied fork, but that's a
> PB> policy decision for the distribution.
>  Yep, but on other hand it is "stable", well-named file :)

Perhaps.  Certainly using that instead of the upstream versions is a
choice a distribution might make.

> PB> Once I've switched to using msp430-elf-gcc all pretense that mspgcc is
> PB> supported will vanish.  Unofficially, that's already occurred.
>  Anyway, thank you for all you work on mspgcc!

You're welcome.

Peter

------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
Mspgcc-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/mspgcc-users