to continue the work done by VanTosh under NGI POINTER with PowerEL
porting to SFFS, gentoo and debian need a PowerPC64 "SFFS" port
as well, and PowerEL needs additional work. this will be suitable
not just for Libre-SOC but also Microwatt and also the Freescale/NXP
E5500 64-bit CPU (with emulation of v3.0 already present in linux
* DONE (thx andrey) record all IRC log conversations here as
* DONE: create a wiki page with notes on how to replicate gentoo build
such that collaboration or continuation is possible
* DONE: create a wiki page with notes on how to replicate debian build
*OR* upload the full rootfs of the build system onto libre-soc
resources, such that replication and/or collaboration and
continuation is possible
* DONE: bug #1128 find a way to test that the images work and have no
awilfox looking for doing E5500 ppc support, falls in the same
category here. edit: https://en.m.wikipedia.org/wiki/PowerPC_e5500
note that powerel.org has already been 1st-stage (cross-compile)
bootstrapped to SFFS LE. see bug #860
Created attachment 188 [details]
proposed patch for rust for isa v3.0 sffs
the patch is on top of tag 1.66.1 from https://github.com/rust-lang/rust
i built a cross compiler from x86_64 to powerpc64le with isa v3.0 sffs:
> env CFLAGS_powerpc64le-unknown-linux-gnu='-mcpu=power9 -mno-altivec -mno-crypto -mno-htm' ./configure --target=powerpc64le-unknown-linux-gnu,x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --enable-ccache --enable-ninja
> env CFLAGS_powerpc64le-unknown-linux-gnu='-mcpu=power9 -mno-altivec -mno-crypto -mno-htm' make dist
you can then find the distribution tarballs in build/dist
to use it (only needed for cross-compiler) you need to pass:
##### Older description, kept for reference. #####
Porting Gentoo Linux and Debian, to be done at multiple stages from highest priority to lowest priority:
1- Porting and testing Gentoo with Altivec and VSX disabled for code that will run on any 64-bit LE POWER chip, including libre-soc.
2- Porting and testing Gentoo 64-bit with Altivec and VSX disabled but including the patched gcc, glibc, etc. to enable SVP64 in their stead.
3- Porting and testing Debian stable 64-bit LE (at the time of start) with the same conditions as the Gentoo port with SVP64 enabled.
4- Porting and testing Gentoo 32/64-bit LE & BE with Altivec and VSX disabled for code that will run on any LE/BE POWER chip, including libre-soc.
5- Porting and testing Debian 32/64-bit LE & BE with Altivec and VSX disabled for code that will run on any LE/BE POWER chip, including libre-soc.
6- Finally, porting and testing both Gentoo and Debian 32/64-bit LE & BE with SVP64 if possible.
a) this is actually a "roll-back" to ppc64le EABI 1.5
b) the definition here is to meet the SFFS Compliancy Level of Power ISA 3.0.
it is not, "meet libre-soc requirements", it is
"meet Scalar Fixed Floating-Point Subset Compliancy Level requirements",
where libre-soc *happens* to be compatible with the SFFS Level, and
so does microwatt.
c) actually, libre-soc is strictly compatible with the *SFS* level because
FP is not yet implemented, but we'll get there.
d) qemu is the first priority test-target/platform with vsx and 128-bit
floating-point hardware disabled (not libre-soc, not microwatt)
e) debian requires a triplet defined: this shall be "powerpc64lesffs-linux-gnu-"
to indicate that it is 64-bit, Little-Endian, and SFFS Compliancy Level.
f) an actual new compiler package will be required for debian:
powerpc64lesffs-linux-gnu-gcc - which by default has "-mnovsx -mnoaltivec"
added to the (newly-defined) default triplet.
g) SVP64 will not be possible directly as it requires compiler support.
there is only binutils assembler support
h) it would be nice to update and include SVP64 binutils but this is quite
a large task on its own as it will require full backporting to the
version of debian selected by binutils. it's not practical
at the moment (binutils is updating, and so will the svp64 port)
(In reply to sadoon from comment #6)
> ##### Older description, kept for reference. #####
(future note: that wasn't necessary), the "history" has the full record
of all edits.
> a) this is actually a "roll-back" to ppc64le EABI 1.5
i spoke with steve munroe, he advised that this is a really
bad idea, instead suggested to just activate the "option to not use VRs"
already present in the v2.0 and v2.1 EABI.
reason: the changes made were done with really, REALLY good reason.?
nothing to do with VRs.
(In reply to Sadoon Albader from comment #0)
> * TODO: record all IRC log conversations here as bugtracker comments
sadoon please make this a systematic habit that does not need
prompting or asking. if you have a conversation on IRC link
the irclog here every time. this is part of bug #1126
> * TODO: find a way to test that the images work and have no VSX
i have some ideas here, but please first create two sub-bugs and move
the various "TODOs" to each. 1 for "the work", 2nd for "the testing".
testing involves using microwatt-linux-5.7 (FPGA or verilator, doesn't
matter which), or using qemu instruction tracing.
Re: testing and qemu, some IRC discussion for the plan:
(In reply to Luke Kenneth Casson Leighton from comment #8)
> (In reply to Sadoon Albader from comment #0)
> > * TODO: record all IRC log conversations here as bugtracker comments
> sadoon please make this a systematic habit that does not need
> prompting or asking. if you have a conversation on IRC link
> the irclog here every time. this is part of bug #1126
To make sure we don't forget the previous chats, I linked them here.
I apologise for dumping so many links, hopefully Sadoon can clarify what's worth summarising here.
(and I did this comment while waiting for a devscript to finish, so no time wasted).
And Sadoon already linked today's chat.
> > * TODO: find a way to test that the images work and have no VSX
> > instructions.
> i have some ideas here, but please first create two sub-bugs and move
> the various "TODOs" to each. 1 for "the work", 2nd for "the testing".
> testing involves using microwatt-linux-5.7 (FPGA or verilator, doesn't
> matter which), or using qemu instruction tracing.
Sadoon please have a look at creating these two bugs as Luke mentioned.