[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

AW: Build of powerpcspe port



 
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
  

Reply to: