This is the sad announcement from the Debian mailing list:
Release Architectures for Debian 9 'Stretch'

Quote:

The only change from Jessie is the removal of powerpc as a release architecture. We discussed this at length, and eventually took the view that the least disservice to users of that port is to provide reasonable notice of its discontinuation. We recognise and acknowledge that discontinuing any port is unavoidably disruptive. The question of whether powerpc remains an architecture in the main archive or moves to ports is one for FTP masters, not the release team

This is the list of the officially supported platforms
- amd64
- arm64
- armel
- armhf
- i386
- mips
- mips64el
- mipsel
- ppc64le (PowerPC little endian, e.g. IBM Power 8)
- s390x

The problem is that Ubuntu is closely related to Debian, so we most probably will see a domino effect.

Last edited by virgolamobile on 01-Nov-2016 at 08:13 AM.
Last edited by virgolamobile on 31-Oct-2016 at 07:17 PM.
Last edited by virgolamobile on 31-Oct-2016 at 07:16 PM.

@virgolamobile

Quote:

The problem is that Ubuntu is closely related to Debian, so we most probably will see a domino effect.

not totally true, this because will be a not release but will be archive builds.
about ubuntu 17.04 is in testing and working

_________________
I love Amiga and new hope by AmigaNG
A 500 + ; CDTV; CD32;
PowerMac G5 Quad 8GB,SSD,SSHD,7800gtx,Radeon R5 230 2GB;
MacBook Pro Retina I7 2.3ghz;
#nomorea-eoninmyhome

@tlosm

Let's hope for the best,
and a great thank you to all people involved in ensuring a full Linux support to our beloved next gen Amigas!
AmigaOS is great, but having Linux too is even greater!

@virgolamobile

Ubuntu PPC has been community supported for some time.
Hardly a death kneel.

As Power includes both PowerPC and Power8/9, I don't expect to see support diminish significantly.

_________________
Amiga! "Our appeal has become more selective"

@virgolamobile

Debian has said that a while back, so it's nothing new, really.

There's still plenty of support for an unofficial PPC build.

_________________
Fred Booth
========================================
A500, A600, A1200 c/w Mediator and 030
AmigaOne and OS4.1
Mac LCII, G4 Powermac running OSX + Amigakit and MorphOS 3.0
Dell Mini 10 Netbook running IcAros and AmigaForever+Amikit+AmigaSys
2006 Macb

Not quite what it seems.

Here is more clarification from Alex Perez:

The ppc64el architecture (little endian, which is what all server-class POWER8 which are currently manufactured machines are) is not the same as powerpc. Furthermore, IBM has close relationships with both Canonical, Red Hat, and SuSE, all of which continue to support ppc64el. Additionally, ppc64 (big endian) is a different architecture than ‘powerpc’

You can read more about ppc64el as it pertains to Debian at Debian ppc64el

_________________
No, I don't need no reason, I'm just breezin'

@TrevorDick

The OCD in me couldn't refrain..... it's ppc64le, not ppc64el (little endian, not endian little).
Ironically given the (to English native speakers) backwards ordering nature of little endian, the architecture itself, given a consciousness would probably prefer "el". :)

PA6T-1682M
Produced From 2007 to 2008
Designed by P.A. Semi
Max. CPU clock rate 1.8 GHz to 2.0 GHz
Min. feature size 65 nm
Instruction set Power Architecture (Power ISA v.2.04)
Microarchitecture PA6T
Cores 2
L1 cache 64+64 KB/core
L2 cache 2 MB/core

CPU PA6T
Superscalar, out-of-order 32-bit/64-bit Power Architecture processor core
Adheres to the Power ISA v.2.04
Little endian or big endian operation
64/64 kB instruction and data L1 caches. 32 GB/s bandwidth.
Six execution units including a double precision FPU and Altivec unit
Hypervisor and virtualization support
Maximum 7 W at 2 GHz
11 million transistors, 10 mm² large @ 65 nm.

Memory system CONEXIUM
scalable cross-bar interconnect
1–8 SMP cores
1–2 L2 caches, 512 KB – 8 MB large. 16 GB/s bandwidth.
1–4 1067 MHz DDR2 memory controllers. 16 GB/s bandwidth.
64 GB/s peak bandwidth
MOESI coherency

I/O ENVOI
Centralized DMA engine, 32 GB/s bandwidth
16–64 SerDes lanes
XAUI
PCI Express
SGMII
Offload engine for cryptography, RAID, TCP

"... P.A. Semi was bought by Apple Inc. in April 2008, and closed down development of PWRficient architecture processors. ..." PWRficient

Not bad, even great ... and that's the reason, why it was stopped. Yeah, it was too good for Intel or it could soon have been. Well, perhaps of course.

see also the Espresso microprocessor

"... On December 7, 2015, NXP Semiconductors completed its merger with Freescale for about $11.8 billion in cash and stock. ..." Freescale Semiconductor

"... On October 27, 2016, it was announced that Qualcomm will buy NXP ..." NXP Semiconductors

I don't know, if A-EON is a threat for some too but some may not like that PowerPC could be revived, perhaps with a great new design starting at G4 / Power ISA v.2.04 or PA6T-1682M.

Someone could build a pretty secure PC with PowerPC and Linux, which would be more than capable for most users - just think of an improved 45 nm PA6T with 4 cores and a optimized Linux (fast, sleek and user friendly) ... and that is maybe the reason, why Qualcomm likes to buy NXP (may Qualcomm fail) and Debian will drop PowerPC - to stop PowerPC, not to improve it for a worldwide success. I think that some are trying to sabotage Linux also. Why do you think was Amiga stopped? Well, because some don't like a better Amiga. Amiga was sabotaged too. Well, perhaps of course.

You don't think so? Well perhaps you should tighten your Tin foil hat - the world out there is not exactly as they try to make you think. Just think of Microsoft Mobile - it was bought from Nokia to stop a independent EU-smartphone, not to make a big rival for Apple and Google with extra good EU-smartphones. Well, perhaps of course.

You better know this, if you you want to make AmigaOS big again (How to make AmigaOS a leading operating system?) - AmigaOS as a hobby for some loonies is nothing but a joke. If you fear politics, you could as well stop thinking. Some like to delete/exclude such thoughts, because they are on the evil side and keep you as dumb as sheep. Choose your side. (all imho)

There might still be a bit of unofficial fan support for a while, even though it will likely be harder and harder to keep it afloat, as soon as the sources will not be endian agnostic now that all remaining supported archs are le. The problem will be the same as with webkit javascript or mesa. It will become impossible to maintain. Its a clear hint that be plarforms and among them most prominently ppc are drifting further into obscurity. Nothing i would be fond about, but here goes the whole concept of keeping such platform as a semi contemporary option.

@wawa

Quote:

wawa wrote: There might still be a bit of unofficial fan support for a while, even though it will likely be harder and harder to keep it afloat, as soon as the sources will not be endian agnostic now that all remaining supported archs are le. The problem will be the same as with webkit javascript or mesa. It will become impossible to maintain. Its a clear hint that be plarforms and among them most prominently ppc are drifting further into obscurity. Nothing i would be fond about, but here goes the whole concept of keeping such platform as a semi contemporary option.

PowerPC isn't exactly disappearing; they've just decided to go with ppc64le and ditch big-endian mode support. Most PowerPC chips are bi-endian, so that's always been an option. IBM made the decision to switch to little-endian mode for Power/PowerPC Linux a while ago, and yes, eliminating the burden of making everything endian agnostic was the reason. Big-endian support in drivers has been lagging behind for a while.

I wish we could follow their lead and also switch to little-endian mode. It would definitely be a huge task, but it would help with porting software and writing drivers. Radeon cards are now little-endian only (since the Southern Islands series), so it would make my life easier.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@fishy_fis

No problem. I just did a copy and paste of Alex's text as I did not want to alter his actual message.

TrevorD

Last edited by TrevorDick on 01-Nov-2016 at 08:19 AM.

_________________
No, I don't need no reason, I'm just breezin'

@TrevorDick

Of course its not the same, PowerPC was a subset of an older Power revision that was superceded awhile ago.
BUT, Power8 would run our code.
And, outside of a shift to an alternative ISA, we don't have many options, because one day in the future NXP (or Qualcomm) will stop supplying PPCs.

Then again, that isn't likely to happen for several years. So I'm still buying one of your systems Trev.
I said I was when it was an announced, and I'm still really looking forward to it.

Oh, and on the topic of good ideas that didn't happen, Freescale's discontinued e700 core would have been pretty cool. Some of the ideas for that live on in the e5500 and e6500 cores. But things change...

Like I said, no death kneel, but like with the discontinued 68000 series, you change with the times (or you wait decades until some fanatic like Gunnar picks up development). ;)

_________________
Amiga! "Our appeal has become more selective"

This are indeed bad, but forseeable news for the current 32 bit PPC users, which IMHO still represent the biggest part of the Debian powerpc users.
Let's hope that the powerpc port at least is moved to Debian ports so that it can still benefit from the Debian infrastructure and the few developers left can continue working on it.

Last edited by Geri on 01-Nov-2016 at 10:20 AM.

_________________
A1SE: G3@600MHz, 2GB, 1GBit network card
A1XE: G4@933MHz, 2GB, refitted AC'97 codec
microA1: G3@800MHz, 1GB

- A1 Linux support -

@virgolamobile

It's almost amusing that an old 32-bit i386 CPU is supported but not 32-bit PPC. Perhaps dropping support for PPC could be "backported" ten years. You see ten year olds PCs with more support for software than ten year old Macs on an OS of the same age.

BTW how is that the other posts including mine have also dropped "big endian" from PowerPC?

Last edited by Hypex on 01-Nov-2016 at 01:43 PM.

@fishy_fis

I agree with you here. Except I might call it PPC64LE. Lower case doesn't sit well with me for acronyms. It's like using Mb to refer to megabytes. Doesn't seem right to me.

This "EL" looks like another Linux joke to me. Or some geek joke. "Hey let's reverse the endian so little endian appears in little endian order and confuses people. Hahaha."

Right...

@Hans

Quote:

I wish we could follow their lead and also switch to little-endian mode.

We might as well switch to x86[-64] then while we are at it, skipping the small talk and reaching the final desination.

Quote:

It would definitely be a huge task, but it would help with porting software and writing drivers.

I still can't beleive with all the advances in computers and high level languages or any programming language for that matter that they still haven't figured out how to create a WYSIWYG language that is endian agnostic and compiles standard code to an executable. So that it will run on any endian CPU. Be that PPC or x86-64. Without the programmer batting an eyelid.

Quote:

Radeon cards are now little-endian only (since the Southern Islands series), so it would make my life easier.

Sell outs.

This little endian should really be a novelty of C64 times by now. I see it as a legacy like supporting DOS 6.22. But no, it's an obvious sign of Intel domination. A bit of subterfuge, all the remaining CPUs are little endian, until they slowly fade into oblivion. With only Intel left. And hex dumps unreadable by humans.

Last edited by Hypex on 01-Nov-2016 at 01:38 PM.

@Hypex

Quote:

This "EL" looks like another Linux joke to me. Or some geek joke. "Hey let's reverse the endian so little endian appears in little endian order and confuses people. Hahaha." Right...

That, in fact, is exactly the case, it has been like this for a very long time.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@fishy_fis

Quote:

The OCD in me couldn't refrain..... it's ppc64le, not ppc64el (little endian, not endian little).

Trevor is actually correct to say ppc64el, your OCD may wish it was the other way around, but your OCD would be incorrect in this case.

https://wiki.debian.org/ppc64el

_________________
All glory to the Hypnotoad!

@Hypex

Quote:

Hypex wrote: @Hans Quote: I wish we could follow their lead and also switch to little-endian mode. We might as well switch to x86[-64] then while we are at it, skipping the small talk and reaching the final desination.

Who says x86/x64 (or even ARM) is the final destination? Sticking to Power/PowerPC has two advantages:
1. Can keep using our existing hardware
2. Switching endianness is likely much easier than switching architectures (unlike Linux, we care about backward compatibility). AFAIK, PowerPC allows you to have both little and big endian threads/tasks running on the same OS (via bits in the MSR). So it might be possible to keep existing software running in big-endian mode and perform endianness conversion when it accesses system libraries/devices. Yes, that's a lot of work, but it should be significantly less than writing yet another emulator.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

Who says x86/x64 (or even ARM) is the final destination?

Because it's the cheapest and fastest solution. And it's where Apple ended up who were our closest hardware comparison. Not saying I like it but PowerPC is getting rare. And desktop class PowePC even rarer. As that guy said to young Indiana Jones, "You lost today kid, but that doesn't mean you have to like it."

Quote:

1. Can keep using our existing hardware

Well that's nice but it's only useful for older hardware. Right now we only have new hardware which is very expensive that uses this obscure CPU which is lacking standard functionality found in desktop class CPUs and also in older generations of same CPU. Mind you, it's not like we need this particular CPU, we really just need hardware that can load, interpret and execute PPC codes.

I was almost shocked to hear that an early PPC chip was to include an x86 core on the die and be able to execute both PPC and x86 code. But it never made it. Now, where is the opposite chip so we can have a cheap x86 CPU that can run PPC code? Oh wait, x86 is rigid, it's nose only points to one little end.

Quote:

2. Switching endianness is likely much easier than switching architectures

Sure. But it only helps with some of the hardware issues we have. However, years ago Apple adopted USB as if it was their own. But it was created by a bunch of PC companies including Intel and guess what? The data structures used by the hardware are little endian. Another Intel invention we use, PCI, also little endian data. And as you would know, framebuffers are lacking support for big endian friendly ARGB, instead preferring BGRA as native format.

So yes I can see you point there. But I don't think we need to drag the OS kicking and screaming into the little league yet. Rather, at first, we can optimise for those data operations using little endian format. Like USB and PCI. Where native PPC instructions can read it backwards.

But how to do this is the question. It would be good if GCC supported a little endian attribute where single variables or whole structures could be declared as big or little endian. Then internally the GCC assembler would use a PPC instruction tailored for the job. We already have APICALL magic going on. Be good if endian magic could be plugged in.

EDIT:
An interim solution may be to use the GCC -mlittle-endian switch. Which can be applied to isolated code segments. Little endian data access can be made in one source that is specified as such. Data can be read and written to memory as it likes. Of course the only problem is passing arguments to it and getting them back. Since they both would be reversed. I suppose addresses and data going back and forth could be reversed. Even if that goes against the main point.

Last edited by Hypex on 05-Nov-2016 at 08:30 AM.