Hardware Test Campaign Started – Let’s join the group

Thanks to our supporters we did it again!

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



A group of experts for building the kernel

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

By O.T.S.U. – http://openvirtualizationalliance.org/downloads/kvm-logo_300dpi.png,
CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=24109871

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.

Screenshot taken by Christian Zigotzky on his AmigaOne X5000 (CPU NXP P5040, PPC64, Book3e, e5500) with a working QEMU+KVM.

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:

A group of experts on endianness issues

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

We would suggest to anyone interest in helping on the job to get their hand on a PowerMac G5 possibly mounting any RadeonHD video board, and install the PPC64 big endian version of Debian (https://cdimage.debian.org/cdimage/ports/current/).

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.

Nasze przemówienie na Open Source Summit. Pozostało 15 dni na przekazanie 2600 euro.

Nasz projekt płyty głównej PPC64

Wstępny termin Fazy1B to 18 listopada, więc pozostały dwa tygodnie na przekazanie pozostałych 2600 euro. Jeśli osiągniemy cel, płytka drukowana z symulacją magistrali SI powinna być gotowa do połowy grudnia.

W tym przypadku przed końcem 2020 roku rozpoczynamy prace nad produkcją Prototypów wraz z Akcją Darowizny Prototypów.

Musimy nadać nazwę płycie głównej, sugestie pozostają otwarte jeszcze przez kilka dni na naszym forum

Nasze sugestie dotyczące licencji Open Hardware i endianness na OSS 2020

Rozmawialismy o Cern Open Hardware License i endianiźmie na konferencji Open Source Summit + Embedded Linux w Europie 27 października 2020 r.

Cern Open Hardware License

Dlaczego nie licencja na oprogramowanie, taka jak GPL?
Licencje na sprzęt są specyficzne dla sprzętu, więc są napisane przy użyciu odpowiednich słów: producent, urządzenia, narzędzie CAD…

Dlaczego wybieramy CERN Open Hardware License v1.2?
Uważamy, że zapewnia lepszą ochronę licencjodawcy w porównaniu z innymi licencjami sprzętowymi, takimi jak licencje TAPR Open Hardware

Kim więc jest licencjodawca i licencjobiorca?
– W naszym projekcie my (Power Progress Community) jesteśmy licencjodawcą
… A licencjobiorca jest producentem sprzętu.
Licencjobiorca może produkować lub dystrybuować Produkty
– Licencjobiorca może modyfikować naszą pracę, ale modyfikacja musi być dostępna na tej samej lub równoważnej licencji
Licencjodawca jest chroniony
– Jakość i odpowiedzialność za sprzęt należą do licencjobiorcy

Inne ważne uwagi
– Oprogramowanie układowe, sterowniki i inne oprogramowanie wymagałyby ich własnej licencji
– Własność intelektualna należy do licencjodawcy
– Dokumentacja musi być dostarczona w odpowiednim formacie do modyfikacji (za pomocą narzędzia CAD)

Continue reading

PCB! Un circuito Stampato per un Felice Anno Nuovo!

Pubblicati gli schemi sorgente di Orcad

Alla fine di agosto del 2019 abbiamo pubblicato la prima versione degli schemi in formato pdf. Poi, ad ottobre, abbiamo caricato la seconda versione e successivamente il 13 novembre abbiamo rilasciato la fonte Orcad, realizzando ciò che avevamo promesso.

Gli schemi sorgenti in EDIF sono stati pubblicati e pronti per essere convertiti in KiCad

Ora li abbiamo esportati anche in formato EDIF, per rendere più semplice ai nuovi volontari convertirli in formato Kicad. Per convertire da EDIF a Kicad abbiamo trovato gli strumenti di edif2kicad https://github.com/svn2github/edif2kicad ma siamo sicuri che troverai altri strumenti, o addirittura sarai in grado di crearne uno nuovo.

Creazione di OpenStack Debian 10 PPC64 Big Endian

Continue reading

PCB for a Happy New Year!

Orcad Source Schematics Published

At the end of August of 2019 we published the first version of the schematics in pdf format. Then, in October we uploaded the second version and after that the 13th of November we released the Orcad source, accomplishing what we promised.

Schematics Source in EDIF published and ready to be converted to KiCad

Now we have exported it even to EDIF format, to make easier for new volunteers to convert it to Kicad Format. To convert from EDIF to Kicad we have found edif2kicad tools  https://github.com/svn2github/edif2kicad but we are sure you will find other tools or even you will be able to create a new one

OpenStack Debian 10 PPC64 Big Endian created

Continue reading