Power support for Fedora beyond IBM POWER (e.g. Libre-SOC)?

[Robert Scheck]

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-Fou...
[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/threa...
[5] https://stands.fosdem.org/stands/the_libresoc_project__a_hybrid_3d_cpu_vp...
[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_vect...
[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

[Luke Kenneth Casson Leighton]

hi Robert nice to hear from you.  cutting below to relevant context....

On Sunday, February 7, 2021, Robert Scheck <robert(a)fedoraproject.org&gt; 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)

[Florian Weimer]

* 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
-- 
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

[Luke Kenneth Casson Leighton]

On Monday, February 8, 2021, Florian Weimer <fweimer(a)redhat.com&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to ppc-leave(a)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/[e-mail]
>  
-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

[Florian Weimer]

* 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
-- 
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

[Luke Kenneth Casson Leighton]

On Monday, February 8, 2021, Florian Weimer <fweimer(a)redhat.com&gt; 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-e...

l.

-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

[Robert Scheck]

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-specifica...
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

[Daniel Pocock]

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

[Luke Kenneth Casson Leighton]

---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

On Mon, Feb 8, 2021 at 10:58 PM Daniel Pocock <daniel(a)pocock.pro&gt; 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.

[Daniel Pocock]

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(a)pocock.pro&gt; 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.

[Tulio Magno Quites Machado Filho]

Robert Scheck <robert(a)fedoraproject.org&gt; 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.  ;-)

-- 
Tulio Magno

[Luke Kenneth Casson Leighton]

---
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(a)ascii.art.br&gt; wrote:
>  Robert Scheck <robert(a)fedoraproject.org&gt; 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.

[Raquel and Bill]

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(a)lkcl.net&gt;
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(a)ascii.art.br&gt; wrote:
>  >
>  > Robert Scheck <robert(a)fedoraproject.org&gt; 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(a)lists.fedoraproject.org
>  To unsubscribe send an email to ppc-leave(a)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/[e-mail]
>  

-- 
*http://genesi.company/ <http://genesi.company/>*

[David Woodhouse]

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 :)

[Raquel and Bill]

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(a)infradead.org&gt; 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 :)
>
>  
-- 
*http://genesi.company/ <http://genesi.company/>*

[Raquel and Bill]

...whoops. Added Peter..

On Fri, Dec 10, 2021 at 7:18 AM Raquel and Bill <bbrv(a)genesi-usa.com&gt; 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(a)infradead.org&gt;
>  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 :)
> >
> >
>
>  --
>  *http://genesi.company/ <http://genesi.company/>*
>  

-- 
*http://genesi.company/ <http://genesi.company/>*