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.

Wzrost współpracy – aktualizacja maj 2020

Ilustracja Gerd Altmann z Pixabay

W ostatnim poście wspomnieliśmy, że nowa wersja schematów elektrycznych jest w przygotowaniu. Po kilku rundach wewnętrznych recenzji i zmian ta nowa wersja jest już w końcu gotowa do publicznego udostępniania.

Publikujemy wersję PDF schematów wyeksportowanych z oprogramowania ORCAD, z którego korzysta projektant. Możesz poruszać się po dokumencie i badać każdy składnik, ale niestety, ze względu na złożoność dokumentu, niektóre przeglądarki plików PDF mogą nie być w stanie poprawnie wizualizować swojej zawartości, jeśli tak się stanie, po prostu zmień przeglądarkę, której używasz.

Po otrzymaniu tych nowych schematów poprosiliśmy już o nową rundę zmian dla projektanta, w szczególności chcielibyśmy zwiększyć zużycie energii płyty głównej do 90 W, aby obsługiwać karty graficzne MXM 3 wyższej klasy, które zużywają maksymalnie 55 W. Jako przykład, AMD Radeon E9174 (GCN 4.0) ma TDP 50W. Chodzi o to, aby uzyskać nową wersję schematów elektrycznych przed końcem maja.

Jeśli uważasz, że TPD o mocy 90 W to za dużo dla laptopa, mogę powiedzieć, że pisząc ten post na moim laptopie (DELL XPS 15 9570, wydany w 2018 r.), podłączyłem miernik mocy do zasilacza i zużycie energii waha się między 40 W a 90 W (nie wiem dlaczego idzie w górę i w dół, mam tylko włączoną przeglądarkę). Próbowałem też grać w niektóre gry 3D na moim laptopie, a pobór mocy sięga wartości 110W, a czasem nawet wyższych, aż do granicy mocy zasilacza, która wynosi 130W.

W obecnej wersji płyty głównej, jak możesz zobaczyć na schemacie elektrycznym na stronach 3 i 4 w PDF, są dwa gniazda SO-DIMM DDR3L, które mogą obsługiwać DDR3L bez ECC (maks. 1866 MT / s, PC3-14900) . Zdecydowaliśmy się na moduły inne niż ECC, ponieważ są one znacznie łatwiejsze do znalezienia na rynku i są tańsze niż moduły ECC, więc łatwo będzie mieć 32 GB pamięci RAM (2×16 GB), aż do limitu 64 GB pamięci RAM, jeśli uda ci się trafić 32 GB moduły SO-DIMM.

PowerPC Notebook Block Diagram May 2020

Na schemacie blokowym i w dokumentacji można znaleźć rozszerzenie GPIO. Ten element będzie niezwykle przydatny do debugowania tylko prototypów i zostanie usunięty z jednostek produkcyjnych.

Dzięki wspierającym projekt  (tutaj lista darczyńców) i pomimo obecnych trudnych czasów z powodu wpływu koronawirusa na życie każdego człowieka, osiągnęliśmy 60% celu obecnego etapu, co daje nam pewność, że możliwe będzie uzyskać projekt płytki drukowanej w rozsądnym terminie.

Nadal jednak musimy zebrać pozostałe 40% (7600 EUR / 8400 USD), aby osiągnąć obecny cel, i uprzejmie prosimy każdego z was o dalsze wspieranie kampanii darowizn.

Zapraszamy również każdego, kto jest w stanie pomóc nam w przeglądzie technicznym schematów sprzętowych, aby skontaktował się z nami, ponieważ pomogłoby nam to przyspieszyć proces projektowania, a także poprawić ogólną jakość finalnej płyty głównej.

W końcu chcielibyśmy podkreślić, że stowarzyszenie PowerProgressCommunity stojące za tym projektem ma długoterminowy cel, aby zmniejszyć istniejące bariery w dostępie i dzieleniu się wiedzą technologiczną. Możliwość swobodnego udostępniania schematów płyty głównej laptopa znacznie poprawi obecną sytuację, w której dostęp do tego rodzaju danych jest utrudniony dla osób pracujących w terenie, wyobraźmy sobie, jak trudno jest komuś, kto właśnie podchodzi do tematu, jak studenci i hobbystów. Ponadto, kładąc nacisk na alternatywne technologie nie będące głównym nurtem, pomoże szerzyć kulturę różnorodności, tak ważną w spłaszczonym świecie, w którym młodsze pokolenia nawet nie wyobrażają sobie istnienia innej architektury niż x86 lub ARM.

Praca nad U-Bootem

This image has an empty alt attribute; its file name is 780px-U-Boot_Logo.svg_.png

Nasz zestaw deweloperski NXP T2080RDB uruchamia się z kartami graficznymi AMD RadeonHD korzystającymi z dystrybucji GNU / Linux PPC. Do tej pory z powodzeniem przetestowaliśmy Debian 10, OpenSuse, VoidLinux i Fienix. Jednak ze względu na brak zaangażowanych ekspertów ds. U-Boot, wciąż brakuje nam wsparcia dla wyjścia wideo podczas procesu rozruchu, tuż przed uruchomieniem jądra Linux. Niedawno skontaktowało się z nami kilku ekspertów wspierających w tej dziedzinie i dołączył do grupy. Dzięki ich pomocy z pewnością rozwiążemy bieżącą sytuację, a nawet zaktualizujemy U-Boot z najnowszych źródeł. Mamy nadzieję, że w niedalekiej przyszłości będziemy w stanie opublikować nowy post z dobrymi wiadomościami.

Praca nad Unreal Engine PPC64 (big endian) w VoidLinux

Dzięki JT z grupy VoidLinux obsługującej PowerPC zrozumieliśmy, że obecny problem ABI z którym mamy do czynienia podczas próby zbudowania UnrealEngine 4.23 na naszym systemie Debian SID PPC64, polega na tym, że w debianie PPC64 kompilator clang obsługuje abiv1, linker lld nie. Ponieważ było to po prostu za mało, JT powiedział nam, że biblioteka Mesa na big endian obsługuje OpenGL 3.2, ale niestety wydaje się, że Unreal wymaga nowszej wersji OpenGL.

Ten problem kompilacji ABI można rozwiązać tylko poprzez uzyskanie w jakiś sposób abiv2 przestrzeni użytkownika lub przez zastąpienie używanego linkera (np. Ld.bfd). Obecnie trudno powiedzieć, czy UE faktycznie tego wymaga. Stare abi v1 i tak nie jest zbyt dobre, ponieważ ma kilka okropnych dziwactw, takich jak deskryptory funkcji, które spowalniają wywołania bibliotek i sprawiają, że wskaźniki funkcji są większe niż 8 bajtów, co wymaga podwójnej pośredniczenia, podczas gdy nowa ABI v2 jest znacznie lepsza z założenia i działa nawet na systemach big endian, nawet jeśli został zaprojektowana w 2013 roku z myślą o little endian.

VoidLinux obsługuje nowy ABI v2, więc naszym celem jest zainstalowanie VoidLinux na naszej maszynie wirtualnej Power9 na OSU, zastępując obecny system oparty na Debianie. Tylko rozwiązując problemy ABI, będziemy mogli w końcu zbudować Unreal na dużej maszynie endian PPC64.

Ponieważ maszyna Power9, której używamy na OSU, opiera się na OpenStack, musimy teraz stworzyć obraz VoidLinux dla OpenStack. W chwili, gdy VoidLinux przegapił pakiet inicjujący chmurę wymagany przez OpenStack, zaczęliśmy pracować nad nim, podążając za cloud-init documentations.

This image has an empty alt attribute; its file name is VoidLinux_PPC64_KVMG5.png
Uruchamianie testu integracji z chmurą na VoidLinuxPPC64 działającego na QEMU na G5 Host

Będziemy wdzięczni za wszelką pomoc od was, aby wesprzeć nas w tym ważnym wysiłku, szczególnie od tych z was, którzy mają pewną wiedzę na temat konfigurowania chmurowej inicjacji. Dodatkowym problemem, przed którym obecnie stoimy, jest to, że nasz członek, który pracuje nad tym zadaniem, nie ma sprzętu PPC64 i polega wyłącznie na wolno emulowanym VoidLinux PPC64 przy użyciu QEMU w wersji 4.2.0 na sprzęcie X86.

This image has an empty alt attribute; its file name is VoidLinux_PPC64_QEMU_PPC_onX86.png
VoidLinux PPC64 running on QEMU under X86 host

W poszukiwaniu dodatkowych systemów obsługujących ABI v2 zbadaliśmy również system Adelié Linux który niedawno wydał wersję 1.0RC1 w lutym 2020 r. dla PPC64. Niestety nie ma wbudowanego żadnego pakietu inicjującego chmurę.

Współpraca z Libre-SOC

Bardzo lubimy pracę, które obecnie wykonują nasi przyjaciele z Libre-SOC a nasze dwa projekty wydają się mieć wiele punktów kontaktowych, dlatego podeszliśmy do nich w celu nawiązania dobrych relacji mających na celu wsparcie wspólnego wysiłku Open Hardware .

This image has an empty alt attribute; its file name is lsoclogo400.png

Libre-SOC to projekt Libre Hardware-Software, który ma na celu dostarczenie fizycznego SOC zgodnego z POWER, w komplecie z procesorem, GPU, VPU i kontrolerem DDR. Całe oprogramowanie i sprzęt, od sterowników po komórki RTL i VLSI, są objęte licencją libre. Libre-SOC zapewnia również niezbędne sterowniki, w tym Kazana (sterownik Vulkan 3D) i pełne wbudowane źródło oprogramowania ROM do rozruchu, a także metodę pełnego rozruchu bez pamięci ROM dla dodatkowego zaufania.

Rynek docelowy obejmuje klientów, którzy chcą przyspieszenia w przestrzeni wbudowanej bez polegania na ARM lub zastrzeżonych sterownikach innych firm, o których wiadomo, że w przeszłości się psują.

Pierwsza iteracja Libre-SOC jest ukierunkowana na pojedynczy rdzeń na 180 nm. Kolejne generacje celują w rdzenie SMP przy mniejszym rozmiarze węzła, do typowego zastosowania w projektach SBC.

Wywiad Robertem Innocentim o naszym projekcie dzięki Charbax z ARMDevices

Pod koniec kwietnia, dzięki Charbaxowi z Armdevices.net, przeprowadzono wywiad z Robertem Innocentim, pierwszym twórcą pomysłu budowy laptopa PowerPC i współzałożycielem PowerProgressCommunity. Wywiad dotyczył projektu laptopa i innych działań prowadzonych przez stowarzyszenie non-profit. Poniżej znajdziesz tematy poruszone w wywiadzie. Uważamy, że wywiad jest interesujący i zawiera wiele wskazówek na temat stosowanego przez nas podejścia, nawet jeśli mówienie po angielsku Roberto jest czasem trudne do zrozumienia. Podczas wywiadu jedna osoba zapytała o dystrybucję Manjaro dla PowerPC, a po pewnym sprawdzeniu wydaje się, że takiej dystrybucji brakuje wsparcia dla PowerPC.

0.13 Przedstawienie się Roberto Innocenti
0,45 Stowarzyszenie non-profit Power Progress Community
1.34 Projekt notebooka PowerPC
3.15 Historia architektury PowerPC
6.13 Fundacja OpenPOWER
7.11 Dlaczego procesor NXP, a nie IBM
9.40 PowerPC w systemie Linux
11.35 Dystrybucje Linuksa uruchamiane na PowerPC
13:36 Przyszłość wbudowanego PowerPC
15:21 Ciekawe fakty dotyczące procesora Cell
18:27 Schematy i diagramy projektu notebooka PowerPC
19:31 Specyfikacja procesora NXP
20:13 Możliwa do aktualizacji karta graficzna AMD Radeon MXM
21:02 Wkład Power Progress Community i ACube Systems Srl
22:24 TDP, wykorzystanie komercyjne i możliwości procesora NXP
27:40 Obsługiwane rodzaje pamięci
28:28 Więcej informacji o procesorze graficznym AMD Radeon MXM
30:14 Wydajność starego MacBooka PowerPC w porównaniu z zestawem programistycznym do notebooków PowerPC
31:41 Czy Roberto Innocenti jest lepszy niż Steve Jobs? 😉
32:25 Ludzie stojący za projektem notebooka PowerPC
34:07 PowerPC w porównaniu do ARM
37:35 Więcej o Fundacji OpenPOWER
40:43 Szczegóły kampanii darowizn
43:52 Obudowa Slimbook Eclipse
46:50 Co z urządzeniem typu small-desktop / NUC?
48:44 Szacowana cena notebooka PowerPC
51:55 Produkcja komponentów
52:50 Sytuacja COVID-19
56:23 Młodzi ludzie zaangażowani w projekt notebooka PowerPC
57:11 Różnorodność projektowania, produkcji i dystrybucji sprzętu
1:04:50 Przejrzystość procesora NXP
1:06:13 Więcej o produkcji komponentów i uzależnieniu od Chin
1:09:21 Ubuntu i Debian na PowerPC
1:11:03 Manjaro i inne dystrybucje Linuksa na PowerPC
1:12:30 Aktualna faza kampanii darowizn
1:14:00 Potencjalny następca procesora NXP

Educational Activities

W tych skomplikowanych czasach z powodu wielu ograniczeń narzuconych przez szkoły koronawirusa, szkoły są zamknięte, przynajmniej we Włoszech. W rezultacie uczniowie w dużej mierze polegają na cyfrowych urządzeniach peryferyjnych, aby nadążać za lekcjami i starając się utrzymać życie towarzyskie z przyjaciółmi. Nie wszystkie rodziny mogą sobie pozwolić na komputer lub tablet dla każdego dziecka, a czasami studenci są zmuszeni do studiowania długich dokumentów na swoich telefonach komórkowych, jeśli mają taki telefon. Wspieramy system edukacji online prowadzony przez szkoły, dostarczając notebooki z recyklingu i nazwaliśmy ten projekt “Relive with Scratch” (po włosku “Rivivo con Scratch”).

This image has an empty alt attribute; its file name is aula_1.jpeg
W szkołach dzięki naszemu projektowi „Relive With Scratch”

Regenerowane notebooki to te, które zebraliśmy w 2019 i 2020 r. (wszystkie oparte na mniej lub bardziej starych procesorach x86) i początkowo przeznaczone do kursów kodowania przy użyciu oprogramowania Scratch oraz do nauki matematyki w Gcompris. Aby lepiej dostosować się do działań uczniów, zdecydowaliśmy się na dostarczenie systemu Linux wyposażonego w ChromiumOS, które jest odpowiednie dla naszych starych zregenerowanych notebooków, a ponadto dobrze współpracuje z Google Gsuite, który jest intensywnie używany w klasach, szczególnie w szkołach podstawowych, będących głównym celem naszego projektu.