At the beginning of December 2021 we received an update about the required electronic components that are still missing. We have a total number of 22 missing components, and some of them are present on the board multiple times such as the MOSFET (see https://en.wikipedia.org/wiki/MOSFET).
Below a detailed list of the missing components in more pieces:
7 per pcb MOSFET – DMN3730U-7 N 750mA 30V POWER MOS – Diodes
9 per pcb Trans MOSFET – SI4925DY P-CH 30V 5.3A 8-Pin SOIC – ON SEMICONDUCTOR
4 per pcb Field Effect Transistor –NDC7002N MOSFET 2N-CH 50V 0.51A SSOT6 – ON SEMICONDUCTOR
3 per pcb IRLML6346TRPBF – N-Channel 30 V 3.4A (Ta) 1.3W (Ta) – Infineon Technologies
While ACube Systems is looking for 22 missing components contacting various distributors, we at the Power Progress Community, are trying to help searching these components. The main problem we are facing is not finding each component, the problem is the estimated delivery we are facing that most times is six month or more. For this reason we are evaluating to replace some of the components in order to get a more reasonable delivery time. In case you want to help out carrying out this task, you can the effort and conatct us.
KVM support for PowerPC Book3e e6500 CPUs will be first introduced starting with the linux kernel 5.16+ and with the next version of QEMU, most probably v7.0. If you want to try it now, you should get the release candidate of the kernel 5.16 and compile QEMU yourself from the GIT master branch
We successfully compiled the upcoming kernel and QEMU and then tested some virtual machines running Linux for PowerPC 64 bit in Big Endian mode. Below you can see a screenshot of QEMU running three virtual machines with KVM activated. The host system is our NXP T2080RDB devkit that runs Debian SID PPC64, then there is a VM with Debian SID PPC64 (bottom-right), then OpenSUSE Tumbleweed PPC64 (bottom-left), and finally VOID Linux PPC64 (top-right).
Please note that the KVM support to the e6500 PowerPC family is still in progress, so it may need some tweaking before it may be considered reliable.
Video of our last talks – October and November 2021
Open Power Summit 2021 NA
Prepare yourself to switch computing to Open Hardware Power Architecture
The donation campaign for financing three prototypes reached its goal on Sunday the 24th of October with a surprising final rush thanks to the biggest donation ever received that made us jump on our chairs when we saw it. Thank you all, and especially many thanks to Wiktor Glowacki!!
We transferred the money collected with the campaign to ACube Systems, the company we selected in this challenging journey for making a PowerPC notebook. At the moment we are facing some delays due to the electronics industry supply-chain difficulties (see our post about it), and ACube is currently waiting on the last few electronic components in order to finally build the three boards.
We are now ready to launch the next donation campaign for financing the Hardware Tests with a target of 14000 euros.
The new campaign starts today, and the donations will be transferred to it. Our hope is to conclude this new campaign less than 10 months, but it will largely depend on your support.
Right after testing the three prototypes, we will publish an updated version of the electronic schematics on our GitLab repository so that the publicly available design will be an extensively checked version.
We are relatively confident that the donations will speed up once we will be able to publicly show the physical prototypes, as that should help people to believe more and more in the project.
We remind you that after this new campaign meant to perform the necessary hardware tests, the next campaign is for the CE hardware certification with a target of 12500 euros, and then we are finally done: ready for mass production!
A group of experts to configure U-Boot
The new donation campaign will support the work carried out by ACube Systems together with its hardware designer for the Hardware Tests.
On our side, we will strive to contribute to the development process by working on the U-Boot bootloader. This task is quite urgent, and we are currently setting up a core group of volunteers with some U-Boot knowledge and device trees required to initialize the hardware.
As stated in a post published in 2018, we have had some experience configuring U-Boot when we set up our Development Kit, the NXP T2080-RDB. Our configuration was based on the legacy U-Boot version originally provided with the Development Kit (QorIQ SDK v2.0-1703).
An example of the problems we are facing is that our current build of U-Boot does not initialize the video card, so the only way to interact with U-Boot is via a remote serial terminal. This problem must be solved to improve the overall usability of the motherboard.
You may have a look at the steps we followed while tweaking with U-Boot on our wiki, and on the comprehensive and detailed documentation from our association website.
Below you may find a commit made in 2018 to the original U-Boot that was built back in 2017 that was provided with the NXP SDK v2.0-1703
The plan is to start working on the latest U-Boot release (2021-10), we are in doubt whether to start from the U-Boot official mainline repository or, alternatively, from the U-Boot QorIQ repository. Any advice about what is the best choice is mostly welcome (please, add a comment to this post).
Below you may find a link to what we worked on back in 2018 in order to boot Linux on the NXP Development Kit T2080-RDB
Anyone willing to help in this area should test any new release of the Linux kernel to identify any changes that may prevent the use of an NXP T2080 CPU based platform such as our notebook motherboard.
Unfortunately these tasks require a direct use of a hardware mounting the very same CPU used in the notebook motherboard and we are unable to provide access to our NXP T2080RDB to anyone. While we wait for the prototypes to become available there is little we can do in this area, but nevertheless, if you are interested helping out here you may start investigating the differences between the Book3e and Book3s PowerPC families, keeping in mind the T2080 belongs to the Book3e family, and specifically to the NXP e6500 variant. The main Linux kernel developers mailing list is https://lists.ozlabs.org/pipermail/linuxppc-dev/
At the moment we successfully tested and used kernels up to 5.12.x on our NXP DevKit T2080RDB, but we are unable to run later kernels starting with version 5.13.x, the kernel simply refuse to load. The cause is currently under investigation. If you are willing to help us here, please contact us and we will try to grant you access to the T2080RDB.
This is the GitLab page where we keep track of the kernels tested on the DevKit
Work required to fix KVM for e6500 cores
A different area but closely linked to the kernel, is the support to the KVM, the Kernel-based Virtual Machine that does not currently work in our tests with the T2080RDB. This is a must-have feature as it allows the user to manage virtual machines running at nearly native speed because they do not need to emulate the CPU because KVM is able to use the host computer CPU directly.
We are quite confident that with a relatively small effort it could work because there are people using KVM on a very similar CPU, the NXP P5020, which is a Book3e CPU, specifically the e5500 variant, the previous generation NXP CPU. You may have a look below at the results achieved by Christian Zigotzky on his AmigaOne X5000, a computer currently being sold by A-Eon and based on the NXP P5020 or P5040.
These are the relevant mailing list about respectively QEMU and KVM on PowerPC:
Another important task that we plan to carry out while the prototypes are being made available, is to coordinate people that are able to identify and fix issues preventing Linux distributions for PPC64 (Big Endian or simply BE) such as Debian, VOID or MintPPC from working on the motherboard. Other Linux distributions such as Ubuntu (last supported version 14.04) or Fedora (last supported version 28) abandoned the PPC64 a long time ago, it would be great to have them supported again, but that is way too ambitious at the moment.
The plan is to identify which software has problems on our NXP T2080 CPU, most probably due to endianness issues, identify the required set of changes in the source code, and then submit a patch to the maintainers of the software. The problem we are facing here is that the vast majority of modern software is meant to work on Little Endian CPUs only and most of the time developers do not test their software on any Big Endian platform, also because they are becoming a quite rare piece of hardware nowadays.
As having access to one T2080RDB only could be a problem, we can say that in our experience the NXP T2080 CPU behaves quite similarly to the G5 CPU (PowerPC 970), the last commercially available 64 bit CPU with Altivec used by Apple on their line of PowerPC based Macs. If a software works well on the G5 there is a very good chance that it will work well on the T2080 too. Sure, the T2080 is quite less power hungry with respect to the G5, but the G5 would be the perfect companion for carrying out the investigation while our notebook motherboard becomes available to purchase. Another difference with respect to the G5 CPU to keep in mind, is that the T2080 belongs to the Book3e CPU family where the “e” stands for “embedded”, whereas the G5 is a Book3s (aka sPAPR) CPU, see this page for an schematic explanation of the PowerPC families (https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt). A more detailed explanation of the characterics of the Book3e CPU family is available here https://www.nxp.com/docs/en/user-guide/BOOK_EUM.pdf
An additional expertise we are looking for is anyone with some knowledge on how to tweak software in order to enable Altivec support, a single-precision floating point and integer SIMD instruction set that would greatly improve the user experience when supported.
In the past few years we identified quite a few key software areas potentially affected by endianness issues that may heavily impact the everyday use of the platform, but three areas are in our opinion the most relevant ones.
Anything related to driving modern AMD Radeon GPUs. We selected AMD GPUs to use in conjunction with the notebook motherboard, as overall these cards seem to behave quite well when used in a big endian environment. The problem to face here is that any update on anything related to driving these video cards may cause errors preventing any video output, for example updates on the kernel, on X11, Mesa for 3D software, and more recently Wayland or Vulkan. As an example, a recent update of Debian SID for PPC64 suddently broke something and now we cannot start any X11 session on any RadeonHD we tried, the cause is under investigation.
Video hardware acceleration is also a target that must be investigated, so we would need someone able to deal with problems related to AMD Radeon specific technologies such as Unified Video Decoder (UVD), Video Code Engine (VCE) and Video Core Next (VCN). Software using these technologies that must be carefully investigated are VLC, mplayer, and the video decoding part of web browsers in order to let them play videos at full speed because the CPU is not powerful enough to decode FullHD or 4K video streams.
For the second time we were giving a talk to the GNU/Linux Valencia Group, a local Linux group located in the city of Valencia, Spain, which is doing a great job promoting Linux and open source in general. Guillermo gave a brief explanation of the project from the beginning to the present, the objectives, technical specifications, other related projects of the Power Progress Community association, FAQs about the project and so on.
In particular the group was updated about everything that has occurred in the project since the last time we visited them. One of the key points was the collaboration with Slimbook, this collaboration started just because of last year meeting with the group as this company is located at the same city and his CEO is one of the founders of this Valencian group. The company will provide the laptop body and is supporting our team giving all specifications we need.
You can find an article covering this meeting in the GNU/Linux Valencia group page (in Spanish):
Linux Day Milano – Italy 26th October 2019
This year we have as expositor our running DIY wooden desktop case with the T2080rdb devkit, with our new Power Progress Community T-shirt, with our Posters with our “Revivo with Scratch” manifest , searching notebook to recondition.
People are quite exited using our PowerPC 64 Desktop based on the same CPU NXP T0280 of our future notebook motherboard.
Many young people reach our table and talk with us.
As you probably know, the PowerPC Notebook team had already selected Debian 9 (Stretch) OS, as it seemed to offer a lot of advantages (DFSG, Altivec, compatibility etc…). Because of this, the Debian team has recently decided to remove powerpc (Big Endian) from its release architectures for the upcoming Debian 9 (Stretch) and Debian testing (Stretch) powerpc repositories have been removed. Besides that, they will keep ppc64el (Little Endian) as a release architecture (For those of you who don’t know the difference between powerpc, ppc64el (and ppc64) – check the short summary on the end of this message).
Debian 9 is coming
One of the reasons of this decision was an apparent lack of porters/maintainers/testers – Although the powerpc Debian team includes some very competent, motivated and reactive people.
Some of us are willing to take the Debian powerpc road, but we need volunteers, people willing to give some of their time to the Debian powerpc community, to learn, test, fix bugs etc…
This does not suggest we don’t keep a “plan B” – by testing another distribution. It is just that Debian powerpc works well on current 32 bits and 64 bits machines, and we can try to keep this situation.
If you have a 32 or 64 bits PowerPC machine, and want to join us in keeping Debian powerpc alive, contact us on email@example.com.
Short summary about powerpc / ppc64 / ppc64el :
powerpc is the historical Debian PowerPC port (1997). It works on 32 and 64 bits Big Endian PowerPC (G3/G4/G5 and newer freescale/NXP chips). That’s what you would use on your PowerMac/PowerBook/Genesi/Amiga machines. Note that is supports Altivec, which accelerates greatly some applications (video, graphics, image processing).
ppc64 (Big Endian) was supposed to be used on 64 bits Big Endian PowerPC only (G5 and newer freescale/NXP chips). It has some advantages over the first but currently is not so well supported as powerpc.
ppc64el (Little Endian) started with Debian 8 Jessie. It works on newer Power chips from IBM (for servers). Despite some newer freescale/NXP chips can also be used in Little Endian mode (but without Altivec) they can not be used with ppc64el as this version is compiled with VSX (Vector Scalar eXtension) enabled.
As you can see from the updated about page you now know who are the people which are working on this project. More people are still being contacted right now and soon you will know them.
Fedora ppc64 on PowerPC Notebook
Peter Czanik talked with many people about this project at FOSDEM 2015 as he wrote on the forum and even at DevConf.cz where the Fedora/RHEL PPC team promised to help if needed to make Fedora run on our PowerPC 64 bit Notebook.