* Moffett, Kyle D | 2010-03-24 19:28:06 [-0500]:
>>> So it is my belief that "e500" is the correct and appropriate name for the
>>> architecture.
>>
>> Which brings me to the following question: There are currently two types
>> of the core: e500v1 and e500v2. The latter implements also the floating
>> point type double in hardware while the former doesn't. Which one did
>> pick? I would prefer to go for e500v2 since I don't think that there
>> much e500v1 around plus I don't belive that those are used in multimedia
>> like applications.
>> And it would be probably nice to mark this in arch name.
>
>Our hardware's built using the Freescale P2020, which appears to be an
>e500v2 core. I can't find a detailed list anywhere summarizing which parts
>are e500v1 versus e500v2.
P2020 are the new multicore and e500v2 as well. e500v1 are only found
MPC8540 or least that was the only CPU I was able to find it.
>The e500v1 was never very popular and all of the available parts today
>support double-precision floating point GPRS. With that said, I'm actually
>not sure if my current compiler is built properly to enable use of the
>double instructions. If it's not, that's going to be an essential part of
>my "rebuild the world with whatever arch name the dpkg maintainers want"
>project.
It is not enabled by default. You have to add -mfloat-gprs=double to
gcc. So it is required to patch the gcc to get this by default I thing.
I haven't look into this.
>Looking into it more, that URL actually does list that some e200 CPUs
>support single-precision floating point. On the other hand, the entire e200
>series appears targeted at automotive designers for engine management, brake
>control, etc, and as such is highly unlikely to end up with Debian on it.
The e200z6 go up to 300Mhz but I did not find anything that fast. So
there are probably glad to have everything precompiled.
I've been looking at MPC5566 and MPC5668G and they don't have anything
what coould be used as external storage (MMC/ATA/SATA and so on). They
don't seem to have a lot of flash either. So they probably run just
their application and nothing else. Unlikely that firefox mattars :)
>No offense taken! I had actually started working on my "e500" port before I
>found your bugreport; given the comments from the other DD's on the port
>naming I think "gnuspe" is unlikely to be workable long-term.
Sure. gnuspe was the first thing I came up with, then I've been going
for powerpcgspe. Now I'm undecided again. I just wanted to point you to
something that is complete so you have binaries and don't have to cross
build the whole thing. I've been there, I know what it is like.
>Oh absolutely! My problem right now is I don't have a running install on my
>dev hardware right now and to get one I have to build a lot of things by
>hand. Internally we've got automated rebuildd and reprepro servers that we
>use for testing our hardening on bog-standard x86-64 servers.
>
>Once I get an e500 board up and running I'm dropping the cross-compiler
>package and icecc on all of those systems. I'll then replace /usr/bin/gcc
>and /usr/bin/g++ on the e500 board with versions that call "icecc" or
>"distcc" or whatever as "powerpc-linux-gnuspe-{gcc,g++}". That should speed
>up my build times considerably by sending a lot of the build jobs across
>gigabit to the beefy servers.
That still looks like a cross build and you may want look at [0]. As I
said, I've been there :)
>Yeah... IMNSHO it should be either "e500" or "e500v2" just to keep it from
>being so dang hard to type. Hopefully we've provided enough information so
>the dpkg devs can pick something and we can get on with the official port?
powerpc_e500v2 would mayke it clear but it is a lot of typing. So right
now I would go e500v2 I guess.
>Cheers,
>Kyle Moffett
[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=494692
Sebastian
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
