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-powerpc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/27eb436b9d010f4abf0dce870eaefe400dff6a6...@mchp058a.global-ad.net

Reply via email to