Re: [Stretch] Status for architecture qualification

2016-06-20 Thread Lennart Sorensen 
On Mon, Jun 20, 2016 at 10:35:20PM +0200, Geert Uytterhoeven wrote:
> Yeah, apparently it's cheaper to bootstrap a complete new little endian
> platform than to fix portability issues in existing software...

I believe a big reason is that Nvidia cards expect little endian data,
and the overhead of converting between the host and the nvidia cards is
big enough to matter.

power8+ and power9 will have nvlink connections on the CPU for a reason
after all.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

2016-06-20 Thread Geert Uytterhoeven 
On Mon, Jun 20, 2016 at 8:32 PM, Nelson H. F. Beebe  wrote:
> Recent traffic on this list has discussed Debian on PowerPC and
> big-endian vs little-endian.
>
> The next-generation US national laboratory facilities are to be based
> on PowerPC, and one source that I read mentioned little-endian, likely
> for binary file compatibility with files produced on Intel x86 and
> x86-64 CPUs: see

Yeah, apparently it's cheaper to bootstrap a complete new little endian
platform than to fix portability issues in existing software...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds

Re: [Stretch] Status for architecture qualification

2016-06-20 Thread Nelson H. F. Beebe 
Recent traffic on this list has discussed Debian on PowerPC and
big-endian vs little-endian.

The next-generation US national laboratory facilities are to be based
on PowerPC, and one source that I read mentioned little-endian, likely
for binary file compatibility with files produced on Intel x86 and
x86-64 CPUs: see

CORAL/Sierra
https://asc.llnl.gov/coral-info

The size, and budget, for such facilities suggests that there may be
financial support for Linux operating-system work on them.


---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

Re: [Stretch] Status for architecture qualification

2016-06-20 Thread alexmcwhirter 

On 2016-06-20 10:29, John Paul Adrian Glaubitz wrote:

On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz 
wrote:

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?


Well it is getting there.


The archive rebuild is done and around 11200 packages are up-to-date. 
It's
just the installer that needs work and someone needs to convince the 
release

team that ppc64 is something we want as a release architecture.

Adrian


Just out of curiosity, what's the stipulation with ppc64? Access to 
hardware shouldn't be a problem if ppc64el is a release arch. Maybe i'm 
just weird, but i would pick ppc64 over ppc64el any day. Other than my 
personal affinity for big endian cpu's, ppc64el only has support for one 
generation of cpu's whereas ppc64 should be able to run on everything 
from power4 / ppc970 and up without too much trouble.

Re: [Stretch] Status for architecture qualification

2016-06-20 Thread John Paul Adrian Glaubitz 
On 06/20/2016 04:15 PM, Lennart Sorensen wrote:
> On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
>> Well, we just did a full archive rebuild of "ppc64" to be able to
>> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?
> 
> Well it is getting there.

The archive rebuild is done and around 11200 packages are up-to-date. It's
just the installer that needs work and someone needs to convince the release
team that ppc64 is something we want as a release architecture.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

2016-06-20 Thread Lennart Sorensen 
On Mon, Jun 20, 2016 at 04:11:32PM +0200, John Paul Adrian Glaubitz wrote:
> Well, we just did a full archive rebuild of "ppc64" to be able to
> support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Well it is getting there.

-- 
Len Sorensen

Re: [Stretch] Status for architecture qualification

2016-06-20 Thread John Paul Adrian Glaubitz 
On 06/20/2016 04:05 PM, Lennart Sorensen wrote:
> Also I suspect many users of 64 bit capable freescale chips
> (e5500 and e6500 cores) are running 32 bit powerpc since they
> don't have enough ram to actually really gain anything
> from going to 64 bit, and the ppc64 port isn't done yet.

Well, we just did a full archive rebuild of "ppc64" to be able to
support ppc64 on the e5500 cores by disabling AltiVec, didn't we?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer - glaub...@debian.org
`. `'   Freie Universitaet Berlin - glaub...@physik.fu-berlin.de
  `-GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: [Stretch] Status for architecture qualification

2016-06-20 Thread Lennart Sorensen 
On Sun, Jun 19, 2016 at 08:35:02PM +0200, Florian Weimer wrote:
> Do they implement the ISA required by the existing Debian port?

Yes.

The only ones that don't are the Freescale 85xx and P10[12]x chips,
which are powerpcspe due to using the e500 core.

All the 83xx and 82xx chips which are still shipping in many current
products are plain old 32bit powerpc.  Also I suspect many users of 64
bit capable freescale chips (e5500 and e6500 cores) are running 32 bit
powerpc since they don't have enough ram to actually really gain anything
from going to 64 bit, and the ppc64 port isn't done yet.  But those
would be a case of running 32 bit on 64 bit.

-- 
Len Sorensen

Re: Radeon driver not works on PPC with X800

2016-06-20 Thread Mathieu Malaterre 
On Thu, Jun 16, 2016 at 1:15 AM, TCH  wrote:
> Hi!
>
> I have an old G4 MDD, with an X800 card. I've just installed Debian Jessie
> and tried to breathe life into the 2d acceleration, but without success. If
> i install "firmware-linux-nonfree", then it loads the "r420_cp.bin", but
> then i only got a black screen after boot and the machine freezes
> completely.

Sorry to hear your troubles. Really in a case of complete
installation, I would like to invite you to report a proper bug
report:

https://www.debian.org/releases/jessie/powerpc/ch05s04.html.en#submit-bug

If you have never configured an MTA before, you can simply configure
reportbug using the simple gmail example:

https://wiki.debian.org/reportbug#Using_GMail.27s_SMTP_Server

Let us know the bug number.

-M

Re: Debian "Jessie" on Apple eMac 1.25 GHz PowerPC G4 (7447A) with ATI Radeon 9200 gives "Black Screen of Death"

2016-06-20 Thread Mathieu Malaterre 
Hi Francesco,

On Fri, Jun 17, 2016 at 9:30 AM, aggaz  wrote:
> Dear list,
>
> I have an Apple eMac 1.25 GHz PowerPC G4 (7447A) with ATI Radeon 9200.
>
> For several years I used Debian "Wheezy" on it without issues.
>
> Some day ago I upgraded to "Jessie" and graphics stopped working.
>
> I also tried to make a fresh install of Jessie that later I upgraded to
> "testing", but I always have the same problem.
>
> The problem is that after boot I have the so called "Black Screen of
> Death", which means that the monitor goes black and this is not related
> to Xorg, in fact I can not even see a shell prompt.
>
> I read everithing I could to fix it.
>
> I my understanding the problem is that new radeon drivers require KMS
> but KMS is for some reason not compatible with my machine.
>
> The only way to have an almost working screen is to disable radeon-kms
> either by adding to yaboot.conf the line:
>
> append="nomodeset"
>
> or in /etc/modprobe.d/radeon-kms.conf the line:
>
> options radeon modeset=0
>
> In both cases, I get a working console, but a messed up X.
>
> I see weird colors and X is ot usable.
>
> Now I read that I could fix it as described here by disabling
> open-firmware frame-buffer and using the driver fbdev, which is slow.
>
> So, my solution is to go back to wheezy.
>
> My questions:
>
> 1. Am I missing something? Is there a way to use Jessie with radeon drivers?

Sorry to hear your trouble. Just to put things in order, when you say
"I get a working console", could you please dump the output of:

$ cat /proc/fb

to your email. Also for real complete bug report you could run
"/usr/share/bug/xorg/script 3>/tmp/script.log" and attach it here.
Finally what is the status of the firmware, just send:

$ apt-cache policy firmware-linux-nonfree


> 2. Where can I find a downloadable iso for Debian Wheezy PPC? It seems I
> can download only "Jessie" and testing.

https://www.debian.org/releases/wheezy/debian-installer/

-M