Good evening,
my interest in Power architecture got started when I read in February 2020 about the new open license model on a well-known German news ticker [1]. I attended the OpenPOWER Virtual Summit 2020 North America [2] in September and heard there the first time about Libre-SOC [3], previously also known as Libre-RISCV SoC [4] before they switched from RISC-V to Power. During FOSDEM 2021, I noticed their LibreSOC Project stand [5] and asked multiple beginner questions, which Luke Kenneth Casson Leighton (on Cc) nicely took care of (thank you!).
Given an idea is a Power-based SBC [6], I wondered whether I could just run a Fedora for ppc64le (which seems to currently target POWER8 LE and later), on it. Unfortunately Luke's answer was no, because LibreSOC won't support VSX [7], which are IBM's SIMD (six hundred?) instructions, but the LibreSOC Project plans to have Simple-V Vectorisation according to their FOSDEM talk [8]. Note, the A2O POWER processor core [9] doesn't support VSX, too (same seems to apply to A2I and Microwatt, but they're either POWER7 or likely not powerful enough for typical PC usage anyway -> outside of Fedora's target?).
Trying to follow the path on how to get Fedora for ppc64le to a "POWER-Pi", I had to learn that glibc developers seem to treat IBM POWER9 strictly equal to ABI rules rather handling the different features more fine granulated. My understanding here might be imprecise or wrong, this is what I understood and I'm no expert at this topic. Nevertheless I'm trying to precise it a bit more:
The IBM Power ISA Version 3.1 [10] specifies on page 8 compliancy subsets, where the Linux Compliancy Subset (LCS) is explained on page 10 ff. Page 11 refers specifically to the "Scalar Float Optional Features" and mentions in the first row of the table VSX. However what seems to be implemented e.g. in glibc is something like "#ifdef POWER9" rather "#ifdef HARDWAREFEATURE", which effectively makes VSX support mandatory rather optional.
Given the only publicly known modern implementor of VSX right now, not on an EOL schedule, seems to be IBM's POWER9, it would from my point of view be helpful that VSX support in at least glibc is made optional.
When asking whether the new glibc-hwcaps [11] could be a solution, Luke's answer read for me like a conditional "yes", because at least VSX should be covered by glibc-hwcaps then (again, same as above...my understanding, I'm still no expert here). But this is why I'm Cc-ing here Florian Weimer, who implemented [12] this new glibc feature. I'm not sure if Florian is the right person for this topic at all, but maybe he knows the right people? :)
Finally, to close the circle to the subject of my mail: (how) can we reach Power support for Fedora (and other mainstream Linux distributions) beyond IBM POWER (e.g. Libre-SOC)?
[1] https://www.heise.de/newsticker/meldung/Prozessor-ISA-Power-OpenPower-Founda... [2] https://openpowerfoundation.org/events/openpower-summit-2020-north-america/ [3] https://libre-soc.org/ [4] http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-October/thread.h... [5] https://stands.fosdem.org/stands/the_libresoc_project__a_hybrid_3d_cpu_vpu_g... [6] https://libre-soc.org/22nm_PowerPI/ [7] https://en.wikipedia.org/wiki/AltiVec#VSX_.28Vector_Scalar_Extension.29 [8] https://fosdem.org/2021/schedule/event/the_libresoc_project_simple_v_vectori... [9] https://openpowerfoundation.org/a-deep-dive-into-a2i-and-a2o/ [10] https://ibm.ent.box.com/s/hhjfw0x0lrbtyzmiaffnbxh2fuo0fog0 [11] https://sourceware.org/pipermail/libc-announce/2021/000030.html [12] https://sourceware.org/pipermail/libc-alpha/2020-June/115250.html
Regards, Robert
hi Robert nice to hear from you. cutting below to relevant context....
On Sunday, February 7, 2021, Robert Scheck robert@fedoraproject.org wrote:
switched from RISC-V to Power. During FOSDEM 2021, I noticed their LibreSOC Project stand [5] and asked multiple beginner questions, which Luke Kenneth Casson Leighton (on Cc) nicely took care of (thank you!).
:)
Given an idea is a Power-based SBC [6], I wondered whether I could just run a Fedora for ppc64le (which seems to currently target POWER8 LE and later), on it. Unfortunately Luke's answer was no, because LibreSOC won't support VSX [7], which are IBM's SIMD (six hundred?) instructions,
with the Optional VSX cut out we can comply with the "Embedded Floating Point Compliancy" subset, and under the Compliancy rules add a RADIX4 MMU, XICS and other features to fully run a standard linux kernel.
and this may be achieved in a sane amount of time and resources.
OpenPOWER v3.0B integer is only around 150 instructions. FP is around 30 more. VSX which was great in 2003 is SIX HUNDRED and does not even have predication which is critically important for modern 3D GPU Shader Applications.
but the LibreSOC Project plans to have Simple-V Vectorisation according to their FOSDEM talk [8]. Note, the A2O POWER processor core [9] doesn't support VSX, too (same seems to apply to A2I and Microwatt, but they're either POWER7 or likely not powerful enough for typical PC usage anyway -> outside of Fedora's target?).
A2O and A2I are v2.07 / v2.08, microwatt is v3.0B with no legacy.
A common misunderstanding is to conflate IBM proprietary ASIC product numbers with OpenPOWER ISA numbers.
this assumption then turns into, "well it is in IBM's proprietary implementation therefore obviously all other implementations MUST have all the same features because POWER9===v3.0B"
and that unfortunately is a misunderstanding that is causing huge problems.
Trying to follow the path on how to get Fedora for ppc64le to a "POWER-Pi", I had to learn that glibc developers seem to treat IBM POWER9 strictly equal to ABI rules rather handling the different features more fine granulated.
#ifdef POWER9 rather than #ifdef VSX, or #ifdef NE_OTHER_HW_FEATURE, yes.
in speaking with Mendy from the OpenPOWER Foundation I learned that this practice is a misunderstanding of the intention behind the Compliancy Subsets
My understanding here might be imprecise or wrong, this is what I understood and I'm no expert at this topic. Nevertheless I'm trying to precise it a bit more:
The IBM Power ISA Version 3.1 [10] specifies on page 8 compliancy subsets, where the Linux Compliancy Subset (LCS) is explained on page 10 ff. Page 11 refers specifically to the "Scalar Float Optional Features" and mentions in the first row of the table VSX. However what seems to be implemented e.g. in glibc is something like "#ifdef POWER9" rather "#ifdef HARDWAREFEATURE", which effectively makes VSX support mandatory rather optional.
exactly.
this therefore effectively and accidentally discriminates against *all* Libre / Open Hardware implementations of OpenPOWER.
* A2O and A2I: prevented and prohibited due to no VSX (and unlikely to add it due to the high development cost) * Libre-SOC: likewise * Microwatt: Paul is making an effort to add experimental bare minimum VSX, it is a losing battle with every new #ifdef POWER9 patch accepted in glibc6.
Given the only publicly known modern implementor of VSX right now, not on an EOL schedule,
(the NXP Quorl is going EOL).
going through the Compliancy Levels I notice and confirm what you spotted, Robert: *VSX is OPTIONAL*, it is *NOT* mandatory.
thus, glibc6 is not compliant with the v3.1B spec (or the v3.0C Spec).
the features below, copied from v3.1B, basically define what ppc HWCAPS should contain, in effect, although some of these are kernelspace many of them (VSX/SIMD, QFP, SIMD, OV, LSM) are definitely candidates for HWCAPS.
Linux Optional Features
The following features are **OPTIONAL** for the Linux Compliancy Subset, the Scalar Fixed-Point + Floating-Point Compliancy Subset, and the Scalar Fixed-Point Compliancy Subset.
AIL/HAIL programmability (AIL) Atomic Memory Operations (AMO) Big Endian (BE) (LE is required for LCS) Branch History Rolling Buffer (BHRB) Event-Based Branching (EBB) SLB / HPT translation (HPT) Load/Store Multiple instructions (LM) Processor Compatibility Register (PCR) Quad-precision floating-point (QFP) Broadcast TLB shootdown (TLBIE) (tlbiel not optional) SMT (SMT) visor/ultravior messaging not optional)
Scalar Float Optional Features
The following features are **OPTIONAL** for the Scalar Fixed-Point + Floating-Point Compliancy Subset and the Scalar Fixed-Point Compliancy Subset.
SIMD (SIMD) (VMX and VSX) SF=1 (64-bit) Little Endian (LE) Fixed-point instructions that modify OV indicate whether overflow occurred (OV) Nested radix translation (ROR) (single-level radix translation not optional)
* Robert Scheck:
Trying to follow the path on how to get Fedora for ppc64le to a "POWER-Pi", I had to learn that glibc developers seem to treat IBM POWER9 strictly equal to ABI rules rather handling the different features more fine granulated. My understanding here might be imprecise or wrong, this is what I understood and I'm no expert at this topic. Nevertheless I'm trying to precise it a bit more:
The IBM Power ISA Version 3.1 [10] specifies on page 8 compliancy subsets, where the Linux Compliancy Subset (LCS) is explained on page 10 ff. Page 11 refers specifically to the "Scalar Float Optional Features" and mentions in the first row of the table VSX. However what seems to be implemented e.g. in glibc is something like "#ifdef POWER9" rather "#ifdef HARDWAREFEATURE", which effectively makes VSX support mandatory rather optional.
The OpenPOWER 64-Bit ELF V2 ABI Specification makes VSX support non-optional, as far as I can tell. If it does not, that would be a bug in the document because it's definitely the intent.
It is possible to define a different ABI without VSX support, but it would have a different GNU triplet (not powerpc64le-*-linux-gnu) and a different RPM architecture (not ppc64le).
The first step would be to work with the OpenPOWER Foundation to define that new ABI. Then port the GNU and LLVM toolchains to it. Afterwards, a new Fedora architecture can be brought up if the Fedora project supports adding the architecture.
Thanks, Florian
On Monday, February 8, 2021, Florian Weimer fweimer@redhat.com wrote:
- Robert Scheck:
Trying to follow the path on how to get Fedora for ppc64le to a
"POWER-Pi",
I had to learn that glibc developers seem to treat IBM POWER9 strictly
equal
to ABI rules rather handling the different features more fine
granulated. My
understanding here might be imprecise or wrong, this is what I understood and I'm no expert at this topic. Nevertheless I'm trying to precise it a
bit
more:
The IBM Power ISA Version 3.1 [10] specifies on page 8 compliancy
subsets,
where the Linux Compliancy Subset (LCS) is explained on page 10 ff. Page
11
refers specifically to the "Scalar Float Optional Features" and mentions
in
the first row of the table VSX. However what seems to be implemented e.g. in glibc is something like "#ifdef POWER9" rather "#ifdef
HARDWAREFEATURE",
which effectively makes VSX support mandatory rather optional.
The OpenPOWER 64-Bit ELF V2 ABI Specification makes VSX support non-optional, as far as I can tell. If it does not, that would be a bug in the document because it's definitely the intent.
'scuse my language, i have to say it... arse.
i checked the ELF v2 PDF, it specifically mentions VSX.
It is possible to define a different ABI without VSX support, but it would have a different GNU triplet (not powerpc64le-*-linux-gnu) and a different RPM architecture (not ppc64le).
i found this:
https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html
which appears to be a supplemental of the old PowerPC 64 bit ELF V1 ABI.
no mention of VSX is made in that document.
do you (or anyone) happen to know the history here?
The first step would be to work with the OpenPOWER Foundation to define that new ABI.
if ELFV1 64 bit was preexisting that may not be necessary to define (which would be a huge relief)
Then port the GNU and LLVM toolchains to it.
joy :)
Afterwards, a new Fedora architecture can be brought up if the Fedora project supports adding the architecture.
and every other distro on the planet.
deep breath.
ok. thank you Florian for the insights.
l.
Thanks, Florian -- Red Hat GmbH, https://de.redhat.com/ , Registered seat: Grasbrunn, Commercial register: Amtsgericht Muenchen, HRB 153243, Managing Directors: Charles Cachera, Brian Klemm, Laurie Krebs, Michael
O'Neill
ppc mailing list -- ppc@lists.fedoraproject.org To unsubscribe send an email to ppc-leave@lists.fedoraproject.org Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives:
https://lists.fedoraproject.org/archives/list/ppc@lists.fedoraproject.org
* Luke Kenneth Casson Leighton:
i checked the ELF v2 PDF, it specifically mentions VSX.
It's also implicit in the function calling convention for quadwords, which are passed in registers, and perhaps in other places. That's why it's non-trivial to change.
It is possible to define a different ABI without VSX support, but it would have a different GNU triplet (not powerpc64le-*-linux-gnu) and a different RPM architecture (not ppc64le).
i found this:
https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html
which appears to be a supplemental of the old PowerPC 64 bit ELF V1 ABI.
Isn't this the V1 ABI, with function descriptors and all?
https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES
The V1 ABI does not require VSX. But it's also restricted to big-endian in the GNU/Linux implementation.
Thanks, Florian
On Monday, February 8, 2021, Florian Weimer fweimer@redhat.com wrote:
- Luke Kenneth Casson Leighton:
i checked the ELF v2 PDF, it specifically mentions VSX.
It's also implicit in the function calling convention for quadwords, which are passed in registers, and perhaps in other places. That's why it's non-trivial to change.
understood.
It is possible to define a different ABI without VSX support, but it would have a different GNU triplet (not powerpc64le-*-linux-gnu) and a different RPM architecture (not ppc64le).
i found this:
https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html
which appears to be a supplemental of the old PowerPC 64 bit ELF V1 ABI.
Isn't this the V1 ABI, with function descriptors and all?
that would make sense [as a supplement]
<https://refspecs.linuxfoundation.org/ELF/ppc64/PPC-elf64abi.html#FUNC-DES
The V1 ABI does not require VSX. But it's also restricted to big-endian in the GNU/Linux implementation.
ahh this explains why Roberto from PPCNotebook is advocating a ppc64 BE distro.
the ELFv1 supplemental mentions that LE and BE are permitted: i am guessing it would have been an arbitrary choice at the time to choose BE.
this is very helpful Florian, despite appearances.
i have since found the OPF ELF mailing list, will reach out there http://lists.mailinglist.openpowerfoundation.org/mailman/listinfo/syssw-elfv...
l.
Hello Florian,
On Mon, 08 Feb 2021, Florian Weimer wrote:
The OpenPOWER 64-Bit ELF V2 ABI Specification makes VSX support non-optional, as far as I can tell. If it does not, that would be a bug in the document because it's definitely the intent.
https://openpowerfoundation.org/?resource_lib=64-bit-elf-v2-abi-specificatio... is what you are referring to, right? Could you give me a pointer where this specification makes VSX support non-optional?
It is possible to define a different ABI without VSX support, but it would have a different GNU triplet (not powerpc64le-*-linux-gnu) and a different RPM architecture (not ppc64le).
And why can't VSX support be optional, because introducing another GNU triplet and a different RPM architecture (and same for DEB etc.) seems to be much work. My comparison might be wrong, but for e.g. x86_64 lots of CPU features are optional, and we just have one x86_64 RPM architecture. The question is not about "because the specification says so", but about the technical reason why it can't be made optional (as you figured out, I am not an expert here, but I would like to actually understand it).
Regards, Robert
On 07/02/2021 22:44, Robert Scheck wrote:
Finally, to close the circle to the subject of my mail: (how) can we reach Power support for Fedora (and other mainstream Linux distributions) beyond IBM POWER (e.g. Libre-SOC)?
I acquired a Talos II (dual POWER9) system in 2020. I've tried to share feedback (e.g. the 4k page size change[1]) that will help other people become productive ex-x86.
I've indicated that I would be willing to put more time into non-x86 architectures if there is funding and hardware available.
I could probably contribute 10% to 20% of my time to these efforts, both on ppc64le and aarch64. At the moment, I only do what is essential for my own projects.
Regards,
Daniel
1. https://fedoraproject.org/wiki/Changes/Power4kPageSizeF34
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Feb 8, 2021 at 10:58 PM Daniel Pocock daniel@pocock.pro wrote:
I acquired a Talos II (dual POWER9) system in 2020. I've tried to share feedback (e.g. the 4k page size change[1]) that will help other people become productive ex-x86.
interesting: void linux OpenPOWER FOSDEM talk they said they compile for 4k pages.
I've indicated that I would be willing to put more time into non-x86 architectures if there is funding and hardware available.
well there are five teams all cut off from modern distros at the moment, if you count the PPC Notebook effort (using Quorl v2.08 which also does not have VSX). Roberto's team *might* be able to use https://www.powerel.org/
to be honest i wasn't expecting (hadn't planned) a task of this magnitude (gcc triplet, libc6 port, linux kernel port) into the various budgets i'd applied for NLnet Grants for. i'm going to have to think how to work that out. in the meantime we might be able to use this https://wiki.debian.org/PPC64 which is 64-bit BE and ELF v1.
daniel, let's talk off the ppc fedora list, can you possibly join freenode #libre-soc?
l.
On 09/02/2021 00:29, Luke Kenneth Casson Leighton wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Mon, Feb 8, 2021 at 10:58 PM Daniel Pocock daniel@pocock.pro wrote:
I acquired a Talos II (dual POWER9) system in 2020. I've tried to share feedback (e.g. the 4k page size change[1]) that will help other people become productive ex-x86.
interesting: void linux OpenPOWER FOSDEM talk they said they compile for 4k pages.
I sincerely hope we can allow people to try both page sizes and gradually eliminate bugs on 64k
But I suspect that many people will simply refuse to even start using these systems if so many things are broken on day one so the main distributions need 4k.
I've indicated that I would be willing to put more time into non-x86 architectures if there is funding and hardware available.
well there are five teams all cut off from modern distros at the moment, if you count the PPC Notebook effort (using Quorl v2.08 which also does not have VSX). Roberto's team *might* be able to use https://www.powerel.org/
At the moment I only have one workstation which I use for a range of different things. It would be hard for me to change the OS but I can run other OSs in a VM.
I'd like to work up to 4 or 5 of these systems so I will have one that is stable and others for testing, then I can reboot them at will using different Linux and OpenBSD environments.
to be honest i wasn't expecting (hadn't planned) a task of this magnitude (gcc triplet, libc6 port, linux kernel port) into the various budgets i'd applied for NLnet Grants for. i'm going to have to think how to work that out. in the meantime we might be able to use this https://wiki.debian.org/PPC64 which is 64-bit BE and ELF v1.
daniel, let's talk off the ppc fedora list, can you possibly join freenode #libre-soc?
It is easier for me to schedule a call in Jitsi Meet, maybe late next week, I try to avoid logging in to IRC, too many people appear with questions each time I log in now.
Robert Scheck robert@fedoraproject.org writes:
Trying to follow the path on how to get Fedora for ppc64le to a "POWER-Pi", I had to learn that glibc developers seem to treat IBM POWER9 strictly equal to ABI rules rather handling the different features more fine granulated. My understanding here might be imprecise or wrong, this is what I understood and I'm no expert at this topic.
There are indeed a couple of bad assumptions in glibc code that go beyond what Florian mentioned about the ELFv2 ABI. These include fixed cache line size and assuming that VSX is available POWER ISA 2.06 or later.
Even though we can't change the ELFv2 ABI, I've been (slowly) working to remove these assumptions and make it easier to use an ELFv2 glibc build on processors that do not implement VSX.
If you find any other issues, please let me know. I'll be glad to fix them.
The IBM Power ISA Version 3.1 [10] specifies on page 8 compliancy subsets, where the Linux Compliancy Subset (LCS) is explained on page 10 ff.
Notice that SIMD is not a Linux Optional feature in this page. ;-)
--- crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Feb 9, 2021 at 7:43 PM Tulio Magno Quites Machado Filho tuliom@ascii.art.br wrote:
Robert Scheck robert@fedoraproject.org writes:
Trying to follow the path on how to get Fedora for ppc64le to a "POWER-Pi", I had to learn that glibc developers seem to treat IBM POWER9 strictly equal to ABI rules rather handling the different features more fine granulated. My understanding here might be imprecise or wrong, this is what I understood and I'm no expert at this topic.
There are indeed a couple of bad assumptions in glibc code that go beyond what Florian mentioned about the ELFv2 ABI. These include fixed cache line size and assuming that VSX is available POWER ISA 2.06 or later.
Even though we can't change the ELFv2 ABI, I've been (slowly) working to remove these assumptions and make it easier to use an ELFv2 glibc build on processors that do not implement VSX.
Tulio this is absolutely fantastic to hear. i have reached out to bill schmidt and there will be some discussion and ideas thrown back and forth, here. if you're actively working on fixing the various #defines this is a huge relief.
If you find any other issues, please let me know. I'll be glad to fix them.
The IBM Power ISA Version 3.1 [10] specifies on page 8 compliancy subsets, where the Linux Compliancy Subset (LCS) is explained on page 10 ff.
Notice that SIMD is not a Linux Optional feature in this page. ;-)
ahh you may mean that the other way round? so as not to spam people with attachments, allow me to post screenshot links instead: http://hands.com/~lkcl/2021-02-09_19-50.png http://hands.com/~lkcl/2021-02-09_19-52.png
it distinctly says "optional" for the Linux Compliancy Subset at the top of the page. i initially completely missed this.
now, if you want to have Quad-precision Floating-point (QFP) then SIMD *is* required (highlighted by the green arrows). likewise if you want SIMD, you must also have FP.
so this defines the dependency-chain:
* QFP depends on SIMD * SIMD depends on FP
all these things - including LSM, LS, PCR AMO, they really should all be in a ppc glibc6 HWCAPS.
l.
Hi Folks, this is Bill Buck from genesi. We are looking at a potential development around PowerPC. You may know of genesi's involvement in the community some years ago. This is a very interesting application. No promises. Is there still a community? Best regards, Bill
On Tue, Feb 9, 2021 at 3:03 PM Luke Kenneth Casson Leighton lkcl@lkcl.net wrote:
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68
On Tue, Feb 9, 2021 at 7:43 PM Tulio Magno Quites Machado Filho tuliom@ascii.art.br wrote:
Robert Scheck robert@fedoraproject.org writes:
Trying to follow the path on how to get Fedora for ppc64le to a
"POWER-Pi",
I had to learn that glibc developers seem to treat IBM POWER9 strictly
equal
to ABI rules rather handling the different features more fine
granulated. My
understanding here might be imprecise or wrong, this is what I
understood
and I'm no expert at this topic.
There are indeed a couple of bad assumptions in glibc code that go beyond what Florian mentioned about the ELFv2 ABI. These include fixed cache line size and assuming that VSX is available POWER ISA 2.06 or later.
Even though we can't change the ELFv2 ABI, I've been (slowly) working to
remove
these assumptions and make it easier to use an ELFv2 glibc build on
processors
that do not implement VSX.
Tulio this is absolutely fantastic to hear. i have reached out to bill schmidt and there will be some discussion and ideas thrown back and forth, here. if you're actively working on fixing the various #defines this is a huge relief.
If you find any other issues, please let me know. I'll be glad to fix
them.
The IBM Power ISA Version 3.1 [10] specifies on page 8 compliancy
subsets,
where the Linux Compliancy Subset (LCS) is explained on page 10 ff.
Notice that SIMD is not a Linux Optional feature in this page. ;-)
ahh you may mean that the other way round? so as not to spam people with attachments, allow me to post screenshot links instead: http://hands.com/~lkcl/2021-02-09_19-50.png http://hands.com/~lkcl/2021-02-09_19-52.png
it distinctly says "optional" for the Linux Compliancy Subset at the top of the page. i initially completely missed this.
now, if you want to have Quad-precision Floating-point (QFP) then SIMD *is* required (highlighted by the green arrows). likewise if you want SIMD, you must also have FP.
so this defines the dependency-chain:
- QFP depends on SIMD
- SIMD depends on FP
all these things - including LSM, LS, PCR AMO, they really should all be in a ppc glibc6 HWCAPS.
l. _______________________________________________ ppc mailing list -- ppc@lists.fedoraproject.org To unsubscribe send an email to ppc-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/ppc@lists.fedoraproject.org
On Fri, 2021-12-10 at 07:07 -0500, Raquel and Bill wrote:
Hi Folks, this is Bill Buck from genesi. We are looking at a potential development around PowerPC. You may know of genesi's involvement in the community some years ago. This is a very interesting application. No promises. Is there still a community? Best regards, Bill
Hi Bill, it's good to hear from you again!
Yes, I think the community is fairly small but it does still exist.
I think if there is interesting hardware that it makes sense for Fedora to support, we should definitely try to do so.
Although I can't promise to put as much of my time into it as I did in the days of getting Fedora Core runninginstalling nicely on Pegasos and Efika :)
Hi David, thanks for the quick response. I added Konstantinos Margaritis (Debian-roots) and Peter Czanick (SUSE-roots) to the discussion. What does Power Architecture have to offer today? Would you still go for an NXP core processor or IBM. We worked with IBM for a number of years on Watson Projects so we are still connected in both domains. Bill
On Fri, Dec 10, 2021 at 7:13 AM David Woodhouse dwmw2@infradead.org wrote:
On Fri, 2021-12-10 at 07:07 -0500, Raquel and Bill wrote:
Hi Folks, this is Bill Buck from genesi. We are looking at a potential development around PowerPC. You may know of genesi's involvement in the community some years ago. This is a very interesting application. No promises. Is there still a community? Best regards, Bill
Hi Bill, it's good to hear from you again!
Yes, I think the community is fairly small but it does still exist.
I think if there is interesting hardware that it makes sense for Fedora to support, we should definitely try to do so.
Although I can't promise to put as much of my time into it as I did in the days of getting Fedora Core runninginstalling nicely on Pegasos and Efika :)
...whoops. Added Peter..
On Fri, Dec 10, 2021 at 7:18 AM Raquel and Bill bbrv@genesi-usa.com wrote:
Hi David, thanks for the quick response. I added Konstantinos Margaritis (Debian-roots) and Peter Czanick (SUSE-roots) to the discussion. What does Power Architecture have to offer today? Would you still go for an NXP core processor or IBM. We worked with IBM for a number of years on Watson Projects so we are still connected in both domains. Bill
On Fri, Dec 10, 2021 at 7:13 AM David Woodhouse dwmw2@infradead.org wrote:
On Fri, 2021-12-10 at 07:07 -0500, Raquel and Bill wrote:
Hi Folks, this is Bill Buck from genesi. We are looking at a potential development around PowerPC. You may know of genesi's involvement in the community some years ago. This is a very interesting application. No promises. Is there still a community? Best regards, Bill
Hi Bill, it's good to hear from you again!
Yes, I think the community is fairly small but it does still exist.
I think if there is interesting hardware that it makes sense for Fedora to support, we should definitely try to do so.
Although I can't promise to put as much of my time into it as I did in the days of getting Fedora Core runninginstalling nicely on Pegasos and Efika :)
-
Daniel Pocock -
David Woodhouse -
Florian Weimer -
Luke Kenneth Casson Leighton -
Raquel and Bill -
Robert Scheck -
Tulio Magno Quites Machado Filho