An Open Hardware project for everyone, a PowerPC Notebook for you. Join now!
Ready to switch to Open Hardware GNU/Linux PowerPC notebooks.
The game has changed, now GNU/Linux is everywhere running on every CPU architectures and devices. It's the right time to make new choices, an Open Hardware PowerPC Notebook designed around GNU/Linux, make it happen!
We are searching people that really like innovation for passion and want to realize this project. Join and strengthen the PowerPC Open Hardware Notebook Team! Subscribe to the newsletter and fill the participation survey.
Our passion on innovation and for our Open Source project have already motivated and joined Acube Systems for the design of the mobo and future production and Slimbook for the notebook body.
Your participation make the difference to complete the design and production.
We are making Donation Campaigns to pay the design of our Open Hardware PowerPC Notebook motherboard designed around GNU/Linux.
We will build a solidarity based purchasing group, with a fair price for everyone (manufacturer and customer).
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.
Prototype delays due to electronic components shortages
As already stated a few times, we are still victims of the electronics industry supply-chain difficulties. Back in July, we informed you that “98% of more than 2000 components are now secured and will be delivered on time. The hunt is still ongoing for the remaining forty components left, and finding them is crucial not to miss the October deadline.”Some of the power management components are currently unavailable, so the electronic designer had to search for their replacements. Soon we will publish the resulting updated PCB design reporting all new components. The production factory has not yet received all the required components that we already ordered, and there are still that so far cannot be found anywhere on the market. In particular, we are facing problems getting the HDMI connector (part number 2041481-1) that could fit inside the Eclipse notebook chassis. If you are able to help us find such a connector, please contact us. We are urgently looking for 3 pieces of this connector for the 3 prototypes. Additionally, we are also looking for a solution for the larger batch production.
Unexpected increase of 1000 euros for the prototypes
We are very happy about the generous participation of all donors that allowed the prototype campaign to exceed 90% of the final goal. Thank you very much!
As a result, every prototype increased its final cost by around 300-320 euro including 22% local VAT, for a total amount of 1000 euros including PayPal fees for the three prototypes. Long story short, we have to increase the campaign goal from 12500 to 13500 euros.
We currently cannot tell if the market prices will go back to lower prices, and, moreover, when the current electronic components shortages will be finally over. We all hope that the situation will get better by the time the full batch production starts.
Now, the bright side of the overall situation is that being forced to wait for electronic components is quite compatible with the slow pace of our donation campaign, so please, continue donating!!
MXM Video Cards
You may get an idea of the current electronic shortages by the fact that we ordered an AMD Radeon E9172 MXM GPU (approximately 295 EUR with VAT) and an AMD Radeon E9174 MXM GPU (approximately 380 EUR with VAT) back in May 2021. Well, the expected delivery date is 27th of November 2021!
At the moment, the cost of the three MXM cards needed for the prototypes are not covered by the donation campaign, but we ask your financial support for those cards also.
In the meantime, we had the chance to buy an ATI Radeon HD4650 1GB DRR3 MXM 3.0 card and, thanks to the kind donation by Stefano, a new collaborator from Italy, we have now two AMD FirePro M4000 GDDR5 1GB MXM 3.0A cards.
ACube Systems, our partner taking care of building the prototypes, has also purchased a PCI to MXM adapter. The adapter will allow us to test MXM cards before we have the prototype ready, as it will be used in conjunction with the motherboard “Sam460ex” made by ACube Systems. Tests will be performed under AmigaOS 4.1, a native PowerPC operating system.
Switch to the Cern 2.0 License under evaluation
We are currently evaluating the possibility to upgrade our Open Hardware license from Cern 1.2 to 2.0.
The first thing we noticed was that the second version is split into three variants called Strongly Reciprocal (S), Weakly Reciprocal (W) and Permissive (P). Basically, all three documents are structured in the same manner and, indeed, some sections are identical. The main differences are found in sections 3 Copying, Modifying and Conveying Covered Source, 4 Making and Conveying Products and 5 Research and Development (which does not exist in the Permissive license). The changes that can be found comparing one document to another also imply different concepts to be explained in section 1 Definitions. Most terms that appear on more than one document have the same definition. Important exceptions to this are 1.1 “License” which refers to the exact variant of the license on each document and 1.7 Available Component which is not exactly the same on R and W (and can’t be found on S)
As we understand, the variant should be chosen depending on the restrictions related to the components (Available Components) and additional parts that could be added by the Licensee (External Materials). OHL-S specifies that all “the Complete Source is the Covered Source” and any modification should be distributed using the same license. On the other hand, OHL-W allows the inclusion of External Materials, which means that you can add some parts to the design using a different license. Finally, the Permissive license does not mention anything about Available Components and External Materials but allows to make or publish a Product only including all the Notices of the Licensor.
To better understand the differences, the examples provided in the Open Hardware repository FAQ page are quite explanatory:
In the software domain, there are three generally acknowledged licensing regimes for free and open source software: permissive, weak copyleft and strong copyleft. There are tastes and use cases for each option, and the same happens in hardware. We use the word “reciprocal” instead of “copyleft” because the underlying rights in our case are not restricted to copyright. So, when you use the licence, you need to add a Notice to your designs with one of the three following suffixes: S, W or P:
CERN-OHL-S is a strongly reciprocal licence. For example, if you release HDL files under CERN-OHL-S and then somebody uses those files in their FPGA, when they distribute the bitstream (either putting it online or shipping a product with it) they need to make the rest of the HDL design available under CERN-OHL-S as well.
CERN-OHL-W is a weakly reciprocal licence. For the example above, if you release your part of the design under CERN-OHL-W, somebody who distributes a bitstream which includes your part does not need to distribute the rest of the design files as well.
CERN-OHL-P is a permissive licence. It allows people to take your code, relicense it and use it without any obligation to distribute the sources when they ship a product.
Compared to this second version, OSHL v1.2 does not include “Available Components” and “External Materials” terms, making it difficult to establish a direct relation with any of these variants. This makes us think that it is probably more similar to OHL-S.
Regarding the Disclaimer section, which is the one that protects the Licensor from legal issues and warns the Licensee about his responsibility, both versions have a very similar writing. Version 2 is slightly more detailed specifying that “The Licensor shall, to the maximum extent permitted by law, have no liability for […]” while the previous version did not mention the limits created by law. In any case, we think these limits are oblivious and the meaning of the Disclaimer section is equivalent.
Again, to compare OSHL v1.2 and OHL v2 we can make use of one question in theFAQ section:
Version 2 of the CERN OHL improves on version 1.2 in various respects:
The new version comes in three variants: strongly reciprocal, weakly reciprocal and permissive. Reciprocal licences stipulate that changes to a design must be fed back to the community, for everybody to benefit from them. Permissive licences do not impose this condition. In this way, CERN OHL v2 caters for the different collaborative models currently used in Open Source Hardware projects.
In the reciprocal variants, it is very important to clarify the scope of reciprocal obligations. By introducing the concepts of “Available Component” and “External Material”, plus the already-existing concept of “Product”, the new version makes a special effort to clarify what sources should be shared in both the -S and -W variants.
CERN OHL version 1.2 included a patent licence, i.e. a promise by the licensor that (s)he will not sue a licensee for patent infringement as regards the design licensed under CERN OHL. Version 2 adds a reciprocal clause for this patent licence: if a licensee sues a licensor for patent infringement, (s)he loses all the rights granted by the licence.
In licence 1.2 we did not make a special effort to cater for Hardware Description Language (HDL) development as used in Field Programmable Gate Array (FPGA) and Application-Specific Integrated Circuit (ASIC) design. As we became convinced that there was no appropriate reciprocal licensing regime for HDL, we made sure that CERN-OHL-S and CERN-OHL-W can provide a good solution for FPGA and ASIC designers with a reciprocal mindset.
Version 2 makes a special effort to maximise the chances that the recipient of a physical product will get access to the design files for that product. It does this by granting the licensor the possibility of embedding a URL or another reference in the object itself, and establishing that downstream licensees should respect that notice and update it as applicable if the design is changed.
The new version provides a grace period of 30 days for licensees which infringe in terms. If they come into compliance within 30 days after receiving a notification from the licensor, their rights are reinstated. This is meant to help with cases in which a licensee infringes the terms of the licence inadvertently.
We are still studying which alternative is better from OHL-S, OHL-W and OHL-P. The decision should take into account how free we want the licensees to be when producing or modifying our design.
Join our Talks at OpenPower Summit 2021, Linux Day Online Italy 2021 and the Sfscon 2021
For more news and updates about our project and future plans, join our talks during:
As of the 22th of October 2021, we’ve reached 987 votes out of the 1000 required to take a final decision on the motherboard name. We would like to close the pools as soon as we have reached that number to start working on the drafting of logos and other communication materials.
Freedesktop-sdk merge requests to support PPC64 Big Endian
Thanks to Charles and Manuel, members of our software team, we have submitted a merge request to Freedesktp-sdk with a patch to allow the compilation on PPC64 Big Endian. That was a major achievement and an enormous effort by our volunteers. A very good job guys! Thank you!!
Freedesktop-sdk was going to stop supporting the PowerPC architecture due to the lack of a builder . The situation has now changed, and we are now very happy to inform that even thanks to help from OpenPower members ( from OSUOSL), in terms of updates and improvements to the ppc64le branch of freedesktop-sdk.
15.07.2021 An evening on the theme of POWER & PowerPC
In less than 3 days, Roberto Innocenti, president of the PowerProgressCommunity, will speak at the Open Source Specialist Group’s July Virtual Event on the POWER ISA and PowerPC based hardware, discussing details of our project. The talk will be co-hosted by Ganesan Narayanasamy, one of the leading figures in OpenPOWER and IBM researcher, and by Arjun Nag, who will comment on the concept of Silicon Tape out using OpenPOWER cores.
The event is scheduled to take place between 6:30pm and 9:00pm, CEDT, on the 15th of July. No registration is required. You can join the event using this link.
For more information, please consult the event web page.
It’s time to vote on the name of our motherboard!
We’ve reached 259 and more votes ( 12-07-2021) out of our target of 1000. Your contribution to the future of open computing is very important! Let your friends know and join our warm and welcoming community. Everyone can contribute to our multidisciplinary teams.
This poll is no longer accepting votes
For more information on the origin of the current candidates, go to our previous post.
Prototypes available in October 2021
Thanks to 72 donors we just reached 64% of the current donation campaign for the prototypes that corresponds to about 8000 euros, and we still have to collect 4500 euros to reach the final goal of 12500 euros.
ACube Systems have selected the assembly line for the production of the prototypes.
We have more than 2000 electronic components in our motherboard, and due to the current global shortages of electronic components it was quite a difficult task to order all of them so that they could be delivered in time for production of the prototypes that is fixed for October 2021. After tireless work of the guys at ACube the 98% of the components is now secured and will be delivered on time. The hunting is still ongoing for the remaining forty components left, and finding them is crucial not to miss the October deadline.
Design new Heatsink pipes
We have started to address the design and production of the new modified heatsink pipes which are different from the original pipes provided with the Slimbook Eclipse. A proper passive heat exchanger is vital as our PowerPC Motherboard is mounting an MXM video card that is quite different in shape from the original x86 motherboard that had the video chips mounted directly on the board.
Three AMD MXM-A video card needed for prototypes
We are still investigating how we could collect the additional funding required to pay for three MXM-A 3.0 type A (82 mm x 70 mm) that have a maximum power consumption of 55W. These video cards are fundamentals and we must get them by October as we must carry out the mechanical tests to check to find out that they properly fit inside the prototypes.
FabMaster PCB export for Kicad
As suggested by the guys at KiCad, we requested the PCB Designer to export the PCB design from the native Mentor Expedition format to the FabMaster format, as such a format should be supported natively by KiCad.
This is an alternative approach with respect to the previous process we followed to generate the KiCad files that we published in our repository, a process that consisted in a double passage conversion, first loading and exporting the files in Altium, and then loading and exporting them using Kicad.
In fact, KiCad has an importer module dedicated to FabMaster meant for the board only, and the result of this module is quite important as it should be useful to analyze and check the level of the import accuracy and reliability of the Altium importer module. We are being told by the KiCad developers that the result produced by the Altium import module should generate better results with respect to the FabMaster importer as it is a more recently developed component.
The PCB Designer is currently carefully checking the FabMaster export generated by Mentor Expedition and as soon as he provides us this format, we will publish it and then proceed to import it in Kicad and publish the final result in our repository.
PCB Dummy board for exposition
We produced three dummy versions of the PCB motherboard in order to perform an extensive check of the PCB design. These boards were fundamental as they allowed us to identify a few minor issues that are now solved and were related to the positions of the holes in the PCB used for the screws for attaching the board on the chassis. Now that all mechanical aspects are solved, we asked to get one of these PCB dummy boards so that we can show it on various occasions, hopefully during a physical event, if the pandemic gives us a break.
Are you willing to help?
Being part of a challenging project like this one for building an open hardware motherboard for a laptop is an amazing experience, you understand the underlying complexity of every step, you will meet new people, volunteers from other projects, and discover how much passion people working in companies devoted to open source ar putting in the effort, and everyone involved is willing to help to progress the work. You may consider joining too and contribute your actual skills and may focus on those activities that interest you the most.
Diego Asturias, from pcwdld.com, posted an article on the best Linux distros for the PowerPC, covering everything from old Debian releases to MintPPC and Fienix, and bits and pieces of history. The list is very extensive and will surely help you keep your old (and new, for the lucky ones) PowerPC workstations and laptops productive and useful until our laptop is out.
Check also the linked interview with Casey Cullen, the developer of Fienix and a very active supporter of our community.
Troubleshooting QEMU on Book3e e6500
Nowadays virtualization is key in multiple activities both in a development and a production working and hobbyist environment. QEMU is one of the most widely adopted tools when it comes to emulating a completely different architecture, and moreover, it does support the PowerPC architecture.
We wanted to test QEMU in order to recreate a system having precisely the same CPU as the one selected for our PowerPC notebook, the NXP T2080.
Before diving on the issues we encountered with QEMU, we should first explain that the PowerPC architecture is subdivided in two families: Book3s, where the “s” stands for “server”, and Book3e, where the “e” stands for “embedded”. IBM and Freescale (now NXP) made their own lines of Book3s and Book3e chips, but each company introduced some peculiar characteristics, so our CPU falls in the Freescale branch of the Book3e implementation.
To make things even more complicated, each company built multiple generations of these chips, and introduced new features in each new generation. As a reference, Apple used in all of their PowerPC line of computers Book3s CPUs only, whereas Book3e were mostly used by embedded manufacturers, as these CPUS were especially good for networking and avionics appliances. Despite Book3e being meant for the embedded market, some personal computers ended up on the market based on these CPUs and some of the computers are still made today and you can actually buy these systems now. There are two companies making these computers, A-Eon that sells the AmigaOne X5000 which is based on the Cyrus+ motherboard mounting the NXP P5020, and the other company is ACube Systems that sells the AmigaOne 500, a system based on the Sam460ex motherboard mounting the AMCC 460ex.
The NXP T2080 contains the last and most advanced Book3e core ever designed by Freescale, a 64bit CPU based on the Power ISA v.2.07 specifications. The core was named “e6500” by Freescale and with respect to the previous generation named “e5500”, it introduced the multithread, so that each physical core corresponds to two logical cores, and re-introduced Altivec, a single-precision floating point and integer SIMD instruction, that was lacking in their previous generations.
As the T2080 has 4 of these e6500 multithreaded cores, there is a total number of 8 logical cores, so to create a similar configuration using QEMU with 1GB of RAM, no graphical output and the provided already compiled kernel we launched QEMU with the following command
QEMU doesn’t go very far, and is unable to end up with a usable system.
In order to investigate if the situation could be solved we submitted the problem to the QEMU-PowerPC development mailing list, and thanks to the kind support of Zoltan BALATON (https://lists.gnu.org/archive/html/qemu-ppc/2021-06/msg00222.html) we did had an answer explaining the problems that must be solved and that someone has to implement in QEMU.
Thanks to other contributors to that mailing list the issues were later on more investigated. Sadly there is no company left actively (financially) supporting programmers developing and fixing software for these PowerPC CPUs, so we are in the hands of volunteers that kindly spend their spare time to support the platform, very much like what we actually do with the hardware parts.
In addition, we explored the possibility to enable KVM emulation on a real e6500 CPU using our NXP T2080RDB, as this could lead to a nearly native emulation speed. Sadly, once QEMU is launched in KVM mode, it ends up hanging and eating up all CPU in an endless loop of kernel exceptions, making the entire system unresponsive, and forcing the user to physically reset the system. After contacting the QEMU PowerC mailing list again, we were told that such a behaviour comes as no surprise, as KVM on Book3e is poorly and only partially implemented (source Zoltan BALATON). Luckily enough, after posting this other issue on the QEMU PowerPC development mailing list (https://lists.gnu.org/archive/html/qemu-ppc/2021-07/msg00012.html) Fabiano Rosas answered trying to explain what could be wrong in QEMU, and offered to post on the KVM PowerPC development list (https://www.spinics.net/lists/kvm-ppc/) the issue.
We really hope that a viable solution enabling both full emulation (slow) and KVM emulation (much faster) could be found soon, so please, if you are able to provide some help on the matter do not hesitate contributing to the above mentioned mailing list.
Thanks to the generous support of our community, we’ve passed the 50% threshold required to start the required actions to produce our 3 prototype PCBs.
During this phase, most of the costs are related to purchasing electronic components, printing the PCBs and starting up the machinery for the assembly line.
ACube is currently selecting the right assembly line for the production of the prototypes, currently quite a difficult task due to the current global shortages of electronic components that makes it difficult to find the right time to order all components. Once all components will be collected, we will be able to work on a tentative timeline for the production of the prototypes. We plan to publish the estimated times as soon as we can. We are very grateful to all our donors, particularly Jeff Moe, who donated 2048 EUR for the prototypes.
Thanks to the already produced Dummy Board, the hardware designer has fixed a few mechanical aspects of the PCB design to better accommodate the motherboard. The updated design sources of the PCB will be published soon in our repository.
Public Vote for the Motherboard name
In October 2020, we started asking the community to suggest a name for the notebook motherboard. People could suggest names via the powerprogress forum and from Twitter. We collected all names and we had an internal round of vote among the core group in order to identify the best possible candidates for launching a public vote. So now you can vote on your favourite name!
It’s the third brightest star of the constellation Orion (x86, ARM… Power is _the_ third architecture, isn’t it?). The name also means “female warrior”, because you have to have some Am*ga references…
The antique signaling horn, used by heroes like Roland and Charlemagne, thus conceiving the concept of exotic which gives a strong signal
“Introduced on July 23, 1985, during a star-studded gala featuring Andy Warhol and Debbie Harry held at the Vivian Beaumont Theater at Lincoln Center in New York City Debian
A space ship imagined by Asimov in its book “Foundation’s Edge”, a “gravitic” ship with a sophisticated computer interface for controlling its movements through space that responds to the driver’s thoughts
The mythical sword of Roland/Orlando, conveices the expession of myth and power, but also the difficulty of our project with PPC. Furthermore the name assonates with several wors. “Dur”, “Durare” (=to last in Italian), “Duro” =(hard, hard to beat, resilient)
my catty dog, do you remember Jay Miner dog on Amiga1000? Also it’s a girl name as the Amiga custom chips.
It’s commonly a term used in symphonies, so it really gives a feel of power and elegance, which are potential benefits of this project.
It even gives you a whole registry of follow-up terms centered around music, if subsequent models are produced
Our desire is to collect around 1000 votes before decide the final name on the PCB.
Our PowerPC Notebook in Amigawave
At the end of February 2021, Guillermo, one of our founding members, was interviewed by Amigawave. For our Spanish speaking readers, you might be interested in listening to a brief overview of the entire history of the Power Progress Community association and its open hardware projects, the interview is available in this recorded live stream on YouTube. In addition to the entire history of our project, you will be able to understand the underlying complexity of a project aiming at building a feature-rich laptop from scratch considering heat dissipation and other design principles.
Amigawave is a YouTube channel very well known by the Spanish retrocomputing lovers. The channel is mainly focused on all flavours of Amiga, but also covers many other retrocomputing platforms. We are fond of that period in computing history. Our followers surely know that, during the 80s and 90s, there was a vibrant diversity of computers and architectures and diversity is one of our objectives.
July 15 – Our upcoming presentation at the British Computing Society
On July 15, 2021 @ 6:30 pm – 9:00 pm (BST) The British Computing Society organize an evening on the theme of POWER & PowerPC, July’s event will be on the theme of IBM’s POWER ISA and PowerPC based hardware. Featuring talks from PowerPC Notebook project and IBM on OpenPOWER.
The title of our upcoming presentation is “Prepare yourself for the Open Hardware GNU/Linux PowerPC Laptop”, the abstract: We expect before the end of 2021 to see the life of the first three prototypes of Open Hardware GNU/Linux PowerPC Laptop. The project started in late 2014, after a brief summary of the previous episodes, we try to describe the scenarios of the immediate future of the project and how each person animated by a certain passion for both progress for all and the sharing of knowledge can be a protagonist in this project.
It is with great joy that we present you the first tangible result after years of spending time on planning, ideas, projects and schematics. Below you see pictures of the dummy board, a non-working prototype that was printed with a two-layers PCB that was paid thanks to the ongoing donation campaign.
The primary use of this dummy board is to perform mechanical checks in conjunction with the Slimbook notebook chassis. The board is not finished yet, the PCB designer still has to mount additional mechanical components such as connectors to ensure the final working prototypes will fit perfectly in the Slimbook Eclipse chassis.
The PCB designer in charge of the job is carefully working to fine tune the gerber design files and already adjusted some minor details, proving that a preliminary dummy board was very much needed.
We would like to thank Gerard Schneider that kindly offered us a ATI Radeon 7970 MXM card, it will surely help us testing the working prototypes that will be produced later on. We welcome anybody else willing to send us other Radeon MXM cards that may lay unused in a corner, we would like to start as soon as possible to test various GPUs in the upcoming working hardware. [UPDATE 2021-04-22]Unfortunately our notebook board is set to work exclusively with MXM-A 3.0 (type A) with a size of 82mm x 70 mm and with a maximum power consumption of 55W, whereas the MXM card provided by that Gerard Schneider is an MXM-B (type B) with a size of 82mm x 105mm and a maximum power of 200W. Thank you anyway Gerard, your card will be useful to check and eventually fix the video drivers but it will not be used inside the prototypes.
Even if it is “just” a dummy board, this is a great milestone, and we are really happy about it because we can finally touch something with our hands. We would like to thank all the people that made it possible to reach this point, and we really hope that the donation campaign financing the final prototypes will speed up because now we all want to see more!!
Are you willing to help?
Being part of a project like this could be an amazing experience, you meet new people, volunteers of other projects, companies devoted to open source and everyone is willing to help. We are continuously giving examples of this in our blog posts but, in the last weeks, we are especially grateful about the support received from KiCad developers and Slimbook.
Slimbook is a company making a huge effort in promoting an Open Source environment. They produce notebooks, mini-PCs and desktop computers targeting mainly Linux users. As an example of their commitment to the open source community, they have a very have a good relationship with the KDE project and together they collaborate on the creation of laptops meant to use primarily KDE. Despite being a small company, they are having success selling their products worldwide and these are very appreciated by the Linux community. As you may know, we started our collaboration with Slimbook more than two years ago and they have been always quite helpful promptly responding to our requests and providing information about the enclosure design or the related components that will be also used in our notebook (screen, keyboard, dissipation devices, etc.). All their support and time was kindly offered for free. Besides that support, we have received two Slimbook Eclipse enclosures to continue our tests. This will make possible to assemble three prototypes of our PPC Notebook. Again, they did it for free. We have no words.
Export our PCB to KiCad, a difficult journey
At the very beginning of this adventure, we were trying to find hardware experts to design the motherboard but the level of expertise required for such type of hardware made this challenge unachievable for us. Of course, we have experts on that field but the complexity of this design demands quite a lot of time, impossible to carry out solely using the volunteers spare time. So we opted to look for a company experienced in motherboard design and even more difficult, a company that was experienced with the PowerPC architecture.
We were lucky enough to meet ACube Systems and its circle of collaborators. However, as most for-profit companies do, the ACube System subcontractor company had its own proprietary software tools which generates file encoded using non-open outputs formats. In our case we end up with files created using Mentor Xpedition, a software that cannot exporting to KiCad. To convert our Mentor Xpedition source files we were told to import them into Altium, and import the converted Altium files into KiCad.
Unfortunately, the KiCad importer for Altium files is still heavily under development, and it is far from being complete. We contacted the KiCad developers and they kindly accepted to perform some testing with our Altium PCB files and that helped spotting various errors in the conversion procedure. These error were identified by the developer in charge of the Altium import module for KiCad and he is currently addressing the encountered issues. Regarding the BOM (Bill Of Materials) the guys at KiCad recommended to import the Altium schematics to KiCad, and generate the BOM from there.
Obtaining an open source format for publishing our motherboard PCB is very important for us, as it allow anyone to easily access the result of our efforts to deliver a truly and fully compliant Open Hardware design.
After a few attempts, the guys at KiCad suggested another option: instead of converting the original Mentor Xpedition files to Altium, they suggested to load them using FabMaster. In fact, KiCad has another importer dedicated to FabMaster (for the board only) and the result of this import module should be useful to understand the level of accuracy of the Altium importer. In theory, the Altium import should produce better results with respects to the FabMaster importer as it is a newer. We are currently investigating if we can follow this path, as it seems to require a full Xpedition license, therefore we are in the process of contacting the subcontractor engineer to explore this solution.
An AmigaOS4 AHI driver for our sound chipset
Our notebook motherboard is open to any operating system supporting PowerPC. Among the operating system that could possibly work, there is AmigaOS 4, a closed-source system that already works on the E-AON AmigaOne X5000 that mount either a NXP P5020 or a P5040, which are both PowerPC Book3e e5500 CPUs. These CPUs can be considered the previous generation CPUs with respect to our T2080 (PowerPC Book3e e6500), one of the main differences is that they lack the Altivec unit, which the T2080 has.
On the April 1st the Dutch developer H. Kanning (nickname “geen_naam”) announced the availability of an AHI sound driver supporting HD Audio compliant chips, and explicitly supporting the C-MEDIA C8828 that we selected for our motherboard. At first we though it was an April fool, but then it was confirmed to actually exists and work, meaning that another operating system is one step closer to being supported. Great job!
At the beginning of March the consultant engineer paid using the donation campaign provided us with the Mentor Xpedition source files of our PCB. Providing source files created with a proprietary software is not ideal, therefore we have worked to convert the sources to the Open Source KiCad format.
To achieve the porting of the sources, we first tried loading the Mentor Xpedition sources using the PCB Design Software Altium, and from there, export the sources to KiCad.
We were pleasantly surprised by members of the KiCad team that promptly answered our call for volunteers able to help us in the source translation process, thank you guys, it was really much appreciated!
In our task, we found a very useful post on the KiCad blog that explains how to import an Altium PCB design file in Kicad.
Apparently the Altium Importer is not available if you start PCB window from the KiCad project manager window, you have to start it from the command line as pcbnew-nightly to get the KiCad import feature for loading alien formats.
KiCad eeschema-nightly currently does not support importing Altium schematics. There is an ongoing discussion, so perhaps there are some alpha/beta-testers of it.
For BOM – we are finding information in the Altium database as well as KiCad. The KiCad export info we obtained in our first attempt is simplistic, and it does miss instance identifiers (c43, u17, r9 sorts of designators, which are present in Altium info). We do not see anything yet about enabling/disabling details types from the KiCad BOM export, so we are unsure whether more detailed columns can be obtained.
You may find the original Mentor Expedition sources in our GitLab repository. We were unable to run the visECAD Viewer as even the provided free license version doesn’t seem to work. In fact, visECAD Viewer appears to be withdrawn from the market and it not anymore available to download, and we did not not receive any answer to our requests of support from the Siemens team.
We were able to view the Altium import with the Altium online viewer thanks to the support of the Altium team.
After all our attempts, we are now pleased to announce that it is now possible to load the source files of the notebook motherboard PCB in KiCad using its kicad-nightly version.
Another recent news about the PowerPC notebook project, is that Slimbook will kindly provide us with two additional Slimbook Eclipse empty chassis. These will be used to test that our prototypes will correctly fit. At the same time, the guys at ACube Systems are investigating suitable MXM video cards mounting AMD chips that could be used in the prototypes. We are investigating how we could collect the additional funding required to pay for the various MXM video cards that will be used for testing and for the two additional Slimbook Eclipse chassis.Thanks to the kind contribution of the donors, the preparation of all components for the prototypes is progressing well.
We would like to reach the 50% of the final goal of the current campaign as soon as possible to avoid slowdowns in the current prototypes production phase. We currently need your financial support more than ever!
We have published the first version of the gerber files of the notebook motherboard PCB on our GitLab repository!
The engineers in charge of the design used the software Mentor Xpedition to carry out the design, and in a couple of weeks we will publish their original sources of the PCB from which the gerber files were exported. The cause of the delay in the publication of the sources is because the PCB simulations still are being performed, and until then the sources -and consequently the gerber files- might change. The simulation of the PCB that was successfully financed with the previous donation campaign is currently being finalized. As nobody in our association has the required tools, ACube Systems is taking care of supervising the entire review process for us.
We are perfectly aware that providing source files created with proprietary software is not ideal, therefore we are investigating how we could provide the PCB sources for the Open Source KiCad software. A first attempt we are testing is to load the Mentor Xpedition sources using the PCB Design Software Altium, and from there, convert the source to Kicad. We are looking for volunteers that could help us in the source translation process.
While interacting with ACube on the simulation process, we were faced with the fact that the verbal agreement we made on the prototyping costs dated back to mid-2017 and the world went through great changes. Back then, they estimated a total cost of €10.500, consisting of a first € 3000 for the initial equipment, and € 1500 for each prototype motherboard, multiplied by 5 motherboards. However, after detailing and updating all involved costs using today’s market quotations, it appears clear that most of the components costs have increased since then, maybe because of the pandemic, who knows. Take for example the NXP T2080 CPU, since 2017 its price has simply dubled, and most of the other components have increased their price too. We discussed extensively with ACube Systems, the initial equipment is still € 3000, but the final cost of each prototype motherboard has increased to € 3000, doubling the initially estimated price of 4 years ago.
Because of this dramatic increase in the production cost we decided to make 3 working prototypes only, that makes € 9000. On top of these we add another € 500 to make a dummy board (not working board), printed with a two layers PCB and all mechanical components correctly mounted. The scope of such a dummy board is to ensure that the working prototypes that will be produced later will mechanically fit in the Slimbook Eclipse. As a result, the ongoing campaign goal will be increased to € 12.500.
We are currently investigating the impact of the increased production costs to the final product, but we do not have an answer so far. We will keep you informed as soon as we have a reliable estimation.
It is a well-known fact that a strong software library is a key factor to the viability of any platform – as could attest any unwilling user of a specific operating system 😉.
Our team is aware of that. Our contributors are strongly focused on compiling and optimizing a broad array of games and productivity applications to the PPC64 Big Endian platform, and you will find all of it in our repo.
Super Mario 64
The timeless sm64 is making its way to our portfolio, delivering countless hours of challenging courses and brilliant colors in a package loved by children and adults alike. Jump around, fly, dive, explore dungeons, lakes, mountains and collect coins and stars to make it to the top.
Super Tux Kart
Super Tux Kart is inspired by the most popular arcade racer in the world. It will keep you busy while you master every turn and try to overtake your opponents. As the developers of the Mascot Kingdom say: “In Story mode, you must face the evil Nolok, and defeat him in order to make the Mascot Kingdom safe once again! You can race by yourself against the computer, compete in several Grand Prix cups, or try to beat your fastest time in Time Trial mode. You can also race or battle with up to eight friends on a single computer, play on a local network or play online with other players all over the world.”
H-Craft Championship is a sci-fi racer with more than 28 tracks and unique driving physics. Get the Championship trophy or push your limits with two time attack modes. You will also enjoy a good time with your family and friends with 4 players sharing the same PC.
Unfortunately, we’ve had to halt work on porting the Unreal Engine. It is a huge task and we’ve faced roadblocks. We are planning to resume the task once we’ve completed the MRs of our port to the mainline of Freedesktop-SDK, required to compile flatpak packages on PPC64 Big Endian.
When it’s business time, beyond the usual Linux productivity suites, we are also offering a PPC64 Big Endian optimised version of FreeCAD, so you can make come true your next breakthrough using the best laptop in the world. FreeCAD is a modeller for CAD, MCAD, CAx, CAE and PLM fitting a broad range of uses in engineering and architecture, and runs the same way in all major platforms, ensuring the full portability of your work.
If you don’t believe source code, I am sure you will believe your own eyes. Visit our YouTube channel and enjoy a bit of PowerPC glory! We are online at (link to youtube)
If you have the chance and skills to help, our warm and friendly community invites you to leave your mark on the future of open computing with your contribution and, as a bonus, you will become a better and more versatile developer. Why?
We live in an increasingly little endian world. With the near-monopoly of x86/amd64 in the desktop/laptop/server computing world, the culture of writing portable and performant multi-platform software has declined. We favour a multicultural world. An environment where multiple platforms have an opportunity to thrive gives us new perspectives to solve computing problems, instead of relying only on the old and tried, leading to a world of opener, safer and better software overall.
When developer to our platform, you must keep in mind that you are targeting a Big Endian platform. Manual endianness swapping must be avoided. If you are careful enough, you may be able to extract a bit of performance here and there, but you always must maintain specific use cases and ensure proper architecture detection throughout your code, otherwise the code won’t be architecture-independent.
With automatic swapping, the code is easier to maintain and port. POSIX offers tools for automatic endianness conversion. For more details, please check our guidelines.
Our talk at the FOSDEM 21
FOSDEM is a free event for software developers to meet, share ideas and collaborate. In 2021, the gathering will be online. Be part of the best FOSS conference in Europe – it is for free and registration is required.
We will, of course, mark our presence, with our own Roberto Innocenti hosting a talk and showcasing that now it is the time to switch to Open Hardware and raise again the profile of the Power Architecture.
Roberto’s presentation will happen on Saturday, 6th of February, 2021, starting at 12:15 CET and ending at 13:00. We will be seeing you there!
Thanks to the kind contribution of the donors, we just reached the goal of the campaign for financing Phase 1B “Fast simulation bus”.
The PCB (Printed Circuit Board) design is currently being finalized, as soon as we have reviewed it, we will publish it in our GitLab repository. This last phase was of fundamental importance as we could test the correctness of the design, paving the way for the next campaign.
We got through the hardest parts with regards to the Research and Development choices. We past the uncertain ground with its many open challenges and many solutions have been explored. We also past the economical goal of previous campaigns that were quite heavy, and thanks to many people we have managed to get this far, again, thank you all!
We are now ready to launch Phase 2 “Production and delivery of five working prototypes” with a goal of 10500 Euros (around 12720 USD).
Our target is to complete this new campaign by Spring 2021, and we are working again with the patient guys at ACube Systems that will assist us in making the five prototypes.
These prototypes will be very important as they will be used to
So far, we worked with U-Boot on the NXP T2080 RDB Devkit but that is quite different to our motherboard, which is quite more complex. We have to fine-tune U-Boot directly on the final hardware, and the prototypes will be essential for this. In addition, work on U-Uoot is still required even with the Devkit in order to correctly set up the framebuffer. Right now we can access the U-Boot console in serial mode only. ACube Systems will assist us on this task.
The motherboard is designed (screw and ports positions) to fit inside the Eclipse Notebook body that the prototypes should be mounted on.
Moreover, we need to redesign the dissipation heat pipes that will be slightly different from what was originally in place for the Eclipse Notebook.
Maybe some of you didn’t even think it was possible but we are progressing. The journey is still not finished. We need you to tell about this project all around you as we need more interested people, more donations.
2021 is our year! Let’s make this project a reality!
Strictly Necessary Cookies
Strictly Necessary Cookie should be enabled at all times so that we can save your preferences for cookie settings.
If you disable this cookie, we will not be able to save your preferences. This means that every time you visit this website you will need to enable or disable cookies again.