Build of powerpcspe port
Wachholz, Ruediger
David Kuehling
I don't think that a full debian base-system can be easily build using
cross-compilation. As far as I understand, the usual way to port debian
is to setup a build system and then proceed natively building all
packages.
I don't think that you will be successful building squeeze from scratch
for powerpcspe. Some packages need patches to properly build on
powerpcspe (i think that even includes libc6). Those packages are not
even in 'unstable' but in 'unreleased'.
By the way I'm going to use debian-powerpcspe for an embedded system,
too. Already set up a pretty usable build systems on a p2020rdb, based
on debian-ports sid+unreleased.
Luckily we have quite some time until this has to be stable, so having
to use unstable is no show-stopper for now. Also debian-unstable might
as well be more complete and stable than other options.
Hopefully, now that squeeze is released, powerpcspe related patches can
migrate into sid, and hopefully we'll finally see debian 'testing' build
for powerpcspe (that would already qualify as 'stable' for me). The
main people currently working for debian-powerpc are (afaik):
Sebastian Andrzej Siewior <big...@linutronix.de>,
"Moffett, Kyle D" <Kyle.D....@boeing.com>
I usually CC them when posting about powerpcspe-specific issues. Maybe
they can shed some light on how things are stabilizing, and where help
is needed (i'd be able to spend a few days per month on ppcspe).
You know, the best way to make it more stable is to use it, report
problems, and contribute patches :)
cheers,
David
--
GnuPG public key: http://user.cs.tu-berlin.de/~dvdkhlng/dk.gpg
Fingerprint: B17A DC95 D293 657B 4205 D016 7DEF 5323 C174 7D40
Moffett, Kyle D
>> We're evaluating to build an embedded system on powerpc e500v2
>> (=powerpcspe) architecture. We made some tests using binary powerpcspe
>> sid from debian-ports (http://wiki.debian.org/PowerPCSPEPort) and
>> would like to proceed. Actually our major concern is that the actual
>> powerpcspe port is based on sid/unstable which is no good base for a
>> commercial product.
>
>> For this reason we want to try to build the a powerpcspe port from
>> source based on a stable debian release (e.g. squeeze) and i'm looking
>> for some hints to get started. Can someone please give me some hints
>> on how to (cross)build the debian packages? I'm pretty sure that there
>> exists a simple debian command which will work for most of the
>> packages.
>
>> We could assume that a properly configured cross-compiler is
>> available, e.g. we use "make ARCH=powerpc
>> CROSS_COMPILE=/opt/codesourcery/bin/powerpc-linux-gnu-" to build the
>> kernel. Otherwise any hints on dealing with cross compiling are also
>> welcome.
>
> I don't think that a full debian base-system can be easily build using
> cross-compilation. As far as I understand, the usual way to port debian
> is to setup a build system and then proceed natively building all
> packages.
Exactly right. Debian packages (at least right now) do not reliably build from a cross-compile environment, most of them *MUST* be built on a native system. The "Emdebian" project does cross compiling for some limited subset of packages on a few architectures, and even then they have thousands of patches to make it work at all.
Furthermore, you can't reasonably crossbuild *any* Debian packages with anything other than an "official" Debian-built cross-compiler. The CodeSourcery tools include their own libgcc and libc with their own set of default compiler options; they are probably not directly compatible with Debian.
Finally, it's entirely possible that the released CodeSourcery tools still have the GCC floating-point bug that was just recently fixed upstream.
> I don't think that you will be successful building squeeze from scratch
> for powerpcspe. Some packages need patches to properly build on
> powerpcspe (i think that even includes libc6). Those packages are not
> even in 'unstable' but in 'unreleased'.
This is also correct. Now that "wheezy" is opened up we plan to submit patches from "unreleased" and get them merged into "unstable" (and from there to "wheezy/testing"), but there are too many packages that will probably never be fixed in "squeeze".
For example, the GCC sources currently in squeeze have a rather severe floating point register bug on PowerPC e500v2.
> By the way I'm going to use debian-powerpcspe for an embedded system,
> too. Already set up a pretty usable build systems on a p2020rdb, based
> on debian-ports sid+unreleased.
I'm glad to know there's others who care about Debian on e500 out there :-D.
> I usually CC them when posting about powerpcspe-specific issues. Maybe
> they can shed some light on how things are stabilizing, and where help
> is needed (i'd be able to spend a few days per month on ppcspe).
>
> You know, the best way to make it more stable is to use it, report
> problems, and contribute patches :)
I'm working on the port intermittently right now; my big task at the moment is getting our kernel and U-Boot patches upstream, then I need to roll "official" Debian kernel images.
Once that is done I need to see how many other patches I can get upstreamed from "unreleased", then try to make an "official" Debian-Installer release.
Let me know if you have anything in particular you'd like to work on, I'll give what advice I can!
Cheers,
Kyle Moffett
--
To UNSUBSCRIBE, email to debian-powe...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/3A0136D3-6B3A-4E6A...@boeing.com
David Kuehling
[..]
Currently the most severe limitation of powerpcspe is that we have to
use 'unstable'. But I don't see that any of the debian-ports
architectures carries 'testing', so maybe we won't have
'testing'/'stable' unless everything is integrated into mainline debian?
Is there anything I could help with in that regard?
Other than that I'm currently trying to get live-boot working on ppcspe.
live-build is broken since it relies on debootstrap, which won't work
with sid+unreleased packages. Using multistrap for now.
I also have a sharp eye on gcc, making sure it's fully functional. Is
there anything I can do to help the gcc patches move into wheezy?
Wachholz, Ruediger
Hi David, Kyle,
thanks a lot for your explanations so far. For the moment i expect my part to contribute to use the existing port and report problems. We'll see whether i'm able to to some more.
For the moment i'd like to make use of your offer for more advice in asking some follow up questions below:
>> >> We're evaluating to build an embedded system on powerpc e500v2
>> >> (=powerpcspe) architecture. We made some tests using binary powerpcspe
>> >> sid from debian-ports (http://wiki.debian.org/PowerPCSPEPort) and
>> >> would like to proceed. Actually our major concern is that the actual
>> >> powerpcspe port is based on sid/unstable which is no good base for a
>> >> commercial product.
>> >
>> >> For this reason we want to try to build the a powerpcspe port from
>> >> source based on a stable debian release (e.g. squeeze) and i'm looking
>> >> for some hints to get started. Can someone please give me some hints
>> >> on how to (cross)build the debian packages? I'm pretty sure that there
>> >> exists a simple debian command which will work for most of the
>> >> packages.
>> >
>> >> We could assume that a properly configured cross-compiler is
>> >> available, e.g. we use "make ARCH=powerpc
>> >> CROSS_COMPILE=/opt/codesourcery/bin/powerpc-linux-gnu-" to build the
>> >> kernel. Otherwise any hints on dealing with cross compiling are also
>> >> welcome.
>> >
>> > I don't think that a full debian base-system can be easily build using
>> > cross-compilation. As far as I understand, the usual way to port debian
>> > is to setup a build system and then proceed natively building all
>> > packages.
>>
>> Exactly right. Debian packages (at least right now) do not reliably build from a cross-compile environment, most of them *MUST* be built on a native system.
>> The "Emdebian" project does cross compiling for some limited subset of packages on a few architectures, and even then they have thousands of patches to make it work at all.
>>
>> Furthermore, you can't reasonably crossbuild *any* Debian packages with anything other than an "official" Debian-built cross-compiler.
Just for better understanding: could you please outline some technical reasons why
- Debian packages do not reliably build from a cross-compile environment
- crossbuild of Debian packages requires the "official" Debian-built cross-compiler?
>> The CodeSourcery tools include their own libgcc and libc with their own set of default compiler options; they are probably not directly compatible with Debian.
>>
>> Finally, it's entirely possible that the released CodeSourcery tools still have the GCC floating-point bug that was just recently fixed upstream.
>>
>>
>> > I don't think that you will be successful building squeeze from scratch
>> > for powerpcspe. Some packages need patches to properly build on
>> > powerpcspe (i think that even includes libc6). Those packages are not
>> > even in 'unstable' but in 'unreleased'.
>>
>> This is also correct. Now that "wheezy" is opened up we plan to submit patches from "unreleased" and get them merged into "unstable" (and from there to "wheezy/testing"), but there are too many packages that will probably never be fixed in "squeeze".
>>
>> For example, the GCC sources currently in squeeze have a rather severe floating point register bug on PowerPC e500v2.
>>
>>
>> > By the way I'm going to use debian-powerpcspe for an embedded system,
>> > too. Already set up a pretty usable build systems on a p2020rdb, based
>> > on debian-ports sid+unreleased.
I'm using the p2020rdb as well. But actually i'm not successful to setup a native build system using the
debootstrap archive http://download.breakpoint.cc/debian/powerpcspe-debootstrap-root.tar.bz2 together with sources.list "deb http://ftp.de.debian.org/debian-ports/ sid main".
Even following your hint adding "deb http://ftp.de.debian.org/debian-ports/ unreleased main" installation of gcc fails as follows:
root@p2020rdb:~# apt-get install gcc-4.3
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>> gcc-4.3 : Depends: cpp-4.3 (= 4.3.4-10+powerpcspe1) but it is not going to be installed
>> E: Broken packages
root@p2020rdb:~# apt-get install gcc-4.4
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>> gcc-4.4 : Depends: cpp-4.4 (= 4.4.5-13) but it is not going to be installed
>> E: Broken packages
root@p2020rdb:~# apt-get install gcc-4.5
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Some packages could not be installed. This may mean that you have
>> requested an impossible situation or if you are using the unstable
>> distribution that some required packages have not yet been created
>> or been moved out of Incoming.
>> The following information may help to resolve the situation:
>>
>> The following packages have unmet dependencies:
>> gcc-4.5 : Depends: cpp-4.5 (= 4.5.2-5) but it is not going to be installed
>> Depends: libcloog-ppl0 (>= 0.15.9-2~) but it is not going to be installed
>> Depends: libgmp3c2 but it is not installable
>> Depends: libppl-c2 but it is not going to be installed
>> Depends: libppl7 but it is not going to be installed
>> E: Broken packages
Installation of gcc from "deb http://ftp.de.debian.org/debian-ports/ unreleased main" has been working at about december 2010 i think.
Could you please help me to overcome above problems to setup a native gcc?
>>
>> I'm glad to know there's others who care about Debian on e500 out there :-D.
>>
>>
>> > I usually CC them when posting about powerpcspe-specific issues. Maybe
>> > they can shed some light on how things are stabilizing, and where help
>> > is needed (i'd be able to spend a few days per month on ppcspe).
>> >
>> > You know, the best way to make it more stable is to use it, report
>> > problems, and contribute patches :)
>>
>> I'm working on the port intermittently right now; my big task at the moment is getting our kernel and U-Boot patches upstream, then I need to roll "official" Debian kernel images.
>>
>> Once that is done I need to see how many other patches I can get upstreamed from "unreleased", then try to make an "official" Debian-Installer release.
>>
I started using the kernel sources delivered by freescale: some linux-2.6.32 together with about 50 patches. Some colleagues will have to write drivers for our hardware, for me it would be easiest to stay with 2.6.32. What kernel sources are you using as a base?
>> Let me know if you have anything in particular you'd like to work on, I'll give what advice I can!
I'll be happy to do so, here it is :-)
As i have not much experience with hardware specifics i still have not really understood the implications of our choice for CPU p1021/p2020 from freescale.
>From http://wiki.debian.org/PowerPCSPEPort i assumed that the "exact" processor identification could be "e500v2", lacking lwsync and requiring "--with-cpu=8548 --enable-e500_double --with-long-double-128".
A colleague of mine has the opinion that codesourcerys compiler with option "-me500mc" would be best to compile our own application,
but on https://lkml.org/lkml/2011/3/8/386 i read that "e500 is referring to the SPEstuff and e500mc cores are a whole different beast with a regularFPU" (also mentioning a naming confusion which i totally share).
Could you shed some light on a CPU "identification" and required compiler switches assuming use of freescales p1021/p2020?
Regards,
Rüdiger
--
To UNSUBSCRIBE, email to debian-powe...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/27EB436B9D010F4ABF0DC...@MCHP058A.global-ad.net
David Kuehling
> Hi David, Kyle,
Many complex software packages make assumptions that are incompatible
with cross-compilation. such as: programs compiled in the build process
can be executed during the build process. Autoconf makes it even worse,
since many autoconf feature detection macros use that assumption and
fail during cross-compilatio. Most people don't test for
cross-compilation, so never see such problems (although often they are
easy to fix).
> - crossbuild of Debian packages requires the "official" Debian-built
> cross-compiler?
No, it needs an official cross-compiling version of dpkg-buildpackage.
Also, naturally it then also needs a whole bunch of target system
libraries installed at some 'sysroot' directory. Management of sysroots
for cross compilation again needs special debian cross-development tools
(apt-cross, xapt, dpkg-cross, whatever). This is currently actively
developed and redesigned, and i wouldn't consider it stable. If you can
do without cross-compilation, you should do without cross-compilation to
avoid problems.
>>>
>>> > By the way I'm going to use debian-powerpcspe for an embedded
>>> system, > too. Already set up a pretty usable build systems on a
>>> p2020rdb, based > on debian-ports sid+unreleased.
> I'm using the p2020rdb as well. But actually i'm not successful to
> setup a native build system using the debootstrap archive
> http://download.breakpoint.cc/debian/powerpcspe-debootstrap-root.tar.bz2
> together with sources.list "deb http://ftp.de.debian.org/debian-ports/
> sid main". Even following your hint adding "deb
> http://ftp.de.debian.org/debian-ports/ unreleased main" installation
> of gcc fails as follows:
[..]
Please post your contents of /etc/apt/sources.list and
/etc/apt/sources.list.d/*. I have the following lines in sources.list:
deb http://ftp.de.debian.org/debian-ports sid main
deb http://ftp.de.debian.org/debian-ports unreleased main
and make sure you type 'apt-get update'. does it help?
> Installation of gcc from "deb http://ftp.de.debian.org/debian-ports/
> unreleased main" has been working at about december 2010 i think.
> Could you please help me to overcome above problems to setup a native
> gcc?
Maybe the mirror was during an update that moved files from 'unreleased'
to sid (or vice versa) during your installation attempt? Just wildly
guessing.
Does it work currently?
> I started using the kernel sources delivered by freescale: some
> linux-2.6.32 together with about 50 patches. Some colleagues will have
> to write drivers for our hardware, for me it would be easiest to stay
> with 2.6.32. What kernel sources are you using as a base?
You shouldn't worry about kernel versions. Debian rootfs generated via
multistrap should happily boot on any modern kernel (as long as all
debian-required features are present), no need to rely on official
debian kernels.
>>> Let me know if you have anything in particular you'd like to work
>>> on, I'll give what advice I can!
> I'll be happy to do so, here it is :-)
> As i have not much experience with hardware specifics i still have not
> really understood the implications of our choice for CPU p1021/p2020
> from freescale. From http://wiki.debian.org/PowerPCSPEPort i assumed
> that the "exact" processor identification could be "e500v2", lacking
> lwsync and requiring "--with-cpu=8548 --enable-e500_double
> --with-long-double-128". A colleague of mine has the opinion that
> codesourcerys compiler with option "-me500mc" would be best to compile
> our own application, but on https://lkml.org/lkml/2011/3/8/386 i read
> that "e500 is referring to the SPEstuff and e500mc cores are a whole
> different beast with a regularFPU" (also mentioning a naming confusion
> which i totally share). Could you shed some light on a CPU
> "identification" and required compiler switches assuming use of
> freescales p1021/p2020?
If you go with debian, you should be fine using the included gcc-4.5
compiler without any additional otpions specifying cpu model. First
make it work, then make it fast.
Baurzhan Ismagulov
> > Just for better understanding: could you please outline some technical
> > reasons why - Debian packages do not reliably build from a
> > cross-compile environment
>
> Many complex software packages make assumptions that are incompatible
> with cross-compilation. such as: programs compiled in the build process
> can be executed during the build process. Autoconf makes it even worse,
> since many autoconf feature detection macros use that assumption and
> fail during cross-compilatio.
These are valid issues. It's possible to overcome them if you can read
configure (which is written in Bourne shell) and have a (kernel + libc
+) shell on the target. In my experience, there are still many packages
that have relatively complex hierarchical Makefiles and no provisions
for cross-compilation at all. Just a couple of days ago I found it
faster to move a package to autotools to get it cross-compiled, rather
than trying to hack its Makefile.
> > - crossbuild of Debian packages requires the "official" Debian-built
> > cross-compiler?
>
> No, it needs an official cross-compiling version of dpkg-buildpackage.
> Also, naturally it then also needs a whole bunch of target system
> libraries installed at some 'sysroot' directory.
You can bootstrap something with a random suitable toolchain. But you
want to build Debian packages, which have to be compatible with its
glibc, which is, AFAIK, in some way hard-coded into your toolchain.
There is some cross-compilation work done in SLIND and Crush, although I
don't know whether they are usable OOTB as provided on public web sites.
With kind regards,
Baurzhan.
--
To UNSUBSCRIBE, email to debian-powe...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Sebastian Andrzej Siewior
>> sid main". Even following your hint adding "deb
>> http://ftp.de.debian.org/debian-ports/ unreleased main" installation
>> of gcc fails as follows:
> [..]
>
> Please post your contents of /etc/apt/sources.list and
> /etc/apt/sources.list.d/*. I have the following lines in sources.list:
>
> deb http://ftp.de.debian.org/debian-ports sid main
> deb http://ftp.de.debian.org/debian-ports unreleased main
>
> and make sure you type 'apt-get update'. does it help?
>
>
>> Installation of gcc from "deb http://ftp.de.debian.org/debian-ports/
>> unreleased main" has been working at about december 2010 i think.
>> Could you please help me to overcome above problems to setup a native
>> gcc?
>
> Maybe the mirror was during an update that moved files from 'unreleased'
> to sid (or vice versa) during your installation attempt? Just wildly
> guessing.
>
> Does it work currently?
No the problem is ppl. Lets start from the beginning. gcc-4.3 should not
be used and I'm going to remove it soon. gcc-4.4 is no longer in
unreleased but in unstable. The current gcc-4.4 package is not built yet
and the old one is missing the _all.deb files. If you get them from
snapshots everything is fine. gcc-4.5 has more or less the same problem.
Using old snapshot for gcc-4.4 4.4.5-13
http://snapshot.debian.org/archive/debian-ports/20110301T101121Z/
should fix the issue for now.
As said earlier the root cause is ppl not building. The problem here (as
in the past) is the floating point test suite. The problem in particular
is that rounding is differing more than on other architectures and you
notice this after around 15 iterations.
This is what I know at the moment. I have to investigate this more until I
know how and where to fix this. Unfortunately this is not going to happen
within the next two weeks. I would be glad if nobody brute force uploads
ppl into unreleased.
> David
>
Sebastian
--
To UNSUBSCRIBE, email to debian-powe...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Wachholz, Ruediger
# cat /etc/apt/sources.list
deb http://snapshot.debian.org/archive/debian-ports/20110301T101121Z sid main
deb http://snapshot.debian.org/archive/debian-ports/20110301T101121Z unreleased main
# apt-get update
# apt-get install gcc gcc-4.4
# dpkg -l gcc*
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
||/ Name Version Description
+++-=======================================-=======================================-==============================================================================================
ii gcc 4:4.4.4-2+powerpcspe1 The GNU C compiler
ii gcc-4.4 4.4.5-13 The GNU C compiler
ii gcc-4.4-base 4.4.5-13 The GNU Compiler Collection (base package)
un gcc-4.4-doc <none> (no description available)
un gcc-4.4-locales <none> (no description available)
ii gcc-4.5-base 4.5.2-4 The GNU Compiler Collection (base package)
un gcc-doc <none> (no description available)
un gcc-multilib <none> (no description available)
So i'll continue with a local mirror of http://snapshot.debian.org/archive/debian-ports/20110301T101121Z.
Rüdiger
--
To UNSUBSCRIBE, email to debian-powe...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
Archive: http://lists.debian.org/27EB436B9D010F4ABF0DC...@MCHP058A.global-ad.net