As you know, we were having troubles to find a few components in the market, not only because of their availability, but also due to the increased price. After extensive research, the designer replaced the unavailable components. Unfortunately, we were forced to buy a few components with a premium.
Changes:
from TCA6408ARGTR 8-bit translating 1.65- to 5.5-V I2C/SMBus I/O expander to PCA9539 16-bit I2 C-bus and SMBus low power I/O port with interrupt ( Page 15 pdf schematics)
from TPS56637RPAR Buck Switching Regulator IC Positive Adjustable 0.6V 1 Output 6A 10-PowerVFQFN with RT6222DHGJ6F Buck Switching Regulator IC Positive Adjustable 0.6V 1 Output 2A SOT-23-6 Thin, TSOT-23-6 ( Page 38 pdf schematics)
We remain stuck with a few overpriced components:
Marvell Sata 3 controller 88SE9235A1-NAA2C000
TPS544B20RVFT 4.5-V to 18-V, 20-A synchronous SWIFT™ buck converter with PMBus programmability and monitoring
The designer of the PCB should complete the work within the next two weeks and after that we should start producing the prototypes. Meanwhile, we have published the new schematics including the new components in our repo in pdf format and with ORCAD source.
And lastly, our AMD retailer informed us that the new MXM video cards will not be available. There are other manufacturers producing MXM cards based on AMD GPUs, we are evaluating quotes from different producers.
We are still welcome more donations!
Even after completing the current goal, we are leaving the campaign open to help reaching our next milestone.
Our upcoming goals are:
to buy a few MXM Video cards for the prototypes. We need new quotes, because AMD has stopped selling MXM cards, so we are already in contact with other manufacturers, next days we order it.
to redesign the heat pipes, as they will differ from the original specifications of the Eclipse Notebook.
Only if needed:
pay some work on u-boot configuration
Worst case scenario:
make a new version of the prototype.
any other unforeseen challenges.
We will refine the scope of the upcoming donation campaign once we have a clearer view of the situation as it develops: production of the prototypes, hardware tests, CE certifications. Meanwhile, we will leave our current donation campaign opened.
In the last post we mentioned that a new version of the electrical schematics is in the works. After a few rounds of internal reviews and changes, that new version is now finally ready to be publicly shared.
We publish a PDF version of the schematics exported from the ORCAD software that is being used by the designer. You may navigate through the document and investigate each component, but unluckily, due to the complexity of the document some PDF viewer may be unable to correctly visualize its content, if that happens just change the viewer you are using.
After receiving these new schematics, we already requested a new round of changes to the designer, in particular we would like to raise the motherboard power consumption footprint up to 90W in order to support higher ends MXM 3 video cards that consume a maximum of 55W. As an example, the AMD Radeon E9174 (GCN 4.0) has a TDP of 50W. The idea is to obtain a new version of electrical schematics before the end of May.
If you think a TDP of 90W is too much for a laptop, I can tell you that while I am typing this post on my laptop (a DELL XPS 15 9570, released in 2018) I have attached a power meter to the power brick and the power consumption bounces between 40W and 90W (dunno why is going up and down, I have only a browser turned on). I have also tried playing some 3D games on my DELL laptop, and the power consumption reaches picks of 110W, and sometimes even higher, up to the limit of the power brick, which is 130W.
The current version of the motherboard, as you can see in the electrical schematics at pages 3 and 4 of the PDF, there are two SO-DIMM DDR3L slots that can host DDR3L non-ECC (max 1866 MT/s, PC3-14900). We opted for non-ECC modules as they are way easier to find on the market and are less expensive than ECC ones, so it will be easy to have 32GB of RAM (2x16GB), up to a limit of 64GB of RAM, if you can find 32GB SO-DIMM modules.
PowerPC Notebook Block Diagram May 2020
In the block diagram and in the schematics you can find a GPIO Extender. This element will be extremely useful for debugging only the prototypes, and it will be removed in the production units.
Thanks to the project’s supporters (here a list of donors) and in spite of the current difficult times due to the coronavirus impact on everyone’s life, we reached 60% of the goal of the current step, making us confident that it will be possible to obtain the PCB design in a reasonable time frame.
Still, we still have to raise the remaining 40% (€7600 / $8400) to reach the current goal and we kindly ask any of you to continue supporting the donation campaign.
We also invite anyone that is capable of helping us in the technical review of the hardware schematics to contact us, as that would help us to speed up the design process as well as improve the overall quality of the final motherboard.
We finally would like to stress that the PowerProgressCommunity association behind this project has the long-term goal to lower the existing barriers for accessing and sharing technological knowledge. Being able to freely share a laptop motherboard schematics will dramatically improve the current situation where access to these kinds of data is difficult for who is working in the field, let’s imagine how difficult it is for who is just approaching the topic like students and hobbyists. In addition, by stressing on alternative, non-mainstream technologies, will help spread a culture of diversity, so much important in a flattening world where younger generations don’t even imagine that a different architecture from x86 or ARM exists.
Working on U-Boot
Our NXP T2080RDB devkit boots with AMD RadeonHD video cards using GNU/Linux PPC distros. So far we have successfully tested Debian 10, OpenSuse, VoidLinux, and Fienix. However, due to a lack of involved people expert on U-Boot, we are still lacking support for video output during the boot process, just before the linux kernel kicks in. Very recently, a couple of supporters experts in this field contacted us and joined the group. Thanks to their help, we are confident to solve the current situation, and even update U-Boot from the latest sources. Hopefully, we will be able to publish a new post with some good news in the not-so-distant future.
Working on Unreal Engine PPC64 (big endian) on VoidLinux
Thanks to JT from the VoidLinux group supporting PowerPC, we understood that the current problem of ABI we are facing while trying to build UnrealEngine 4.23 on our Debian SID PPC64 system, is that under debian PPC64 the clang compiler supports abiv1, the lld linker does not. As this was just not enough, JT told us that the Mesa library on big endian supports OpenGL 3.2, but unfortunately Unreal seems to require a more recent version of OpenGL.
This ABI build problem can only be solved either by obtaining somehow an abiv2 userland or by replacing the used linker (e.g. ld.bfd). It is currently difficult to say if UE actually requires it for anything. The old abi v1 is not very good anyway, as it has some awful quirks like function descriptors making library calls slower and making function pointers larger than 8 bytes, requiring a double indirection, whereas the new ABI v2 is much better by design and it works even on big endian systems even if it was designed in 2013 with little endian system in mind.
VoidLinux supports the new ABI v2, so our intention is to setup VoidLinux on our Power9 VM on OSU, replacing the current system based on Debian. Only by solving the ABI issues we will be able to finally build Unreal on a PPC64 big endian machine.
As the Power9 machine we are using on OSU relies on OpenStack, we now have to create a VoidLinux image for OpenStack.At the moment VoidLinux miss the cloud-init package that is required by OpenStack, so we started working on it by following the cloud-init documentations.
Running cloud-init integration test on VoidLinuxPPC64 running on QEMU on G5 Host
We will appreciate any help from you to support us on this important effort, particularly those of you with some knowledge on setting up cloud-init. An additional problem we are currently facing is that our member that is working on this task does not have any PPC64 hardware, and is relying solely on a slowly emulated VoidLinux PPC64 using QEMU version 4.2.0 on a X86 hardware.
VoidLinux PPC64 running on QEMU under X86 host
In search for additional systems supporting the ABI v2, we have investigated also Adelié Linux that recently released version 1.0RC1 in February 2020 for PPC64. Unfortunately, it does not have any cloud-init package built in.
Collaboration with Libre-SOC
We very very much like the works our friends at Libre-SOC are currently doing, and our two projects seems to have multiple point-of-contact, therefore we approached them in order to establish a good relationship aimed at supporting the common Open Hardware effort.
Libre-SOC is a Libre Hardware-Software project that aims to deliver a physical POWER compliant SOC that comes complete with a CPU, GPU, VPU, and DDR controller. All the software and hardware from the drivers down to the RTL and VLSI cells are libre-licensed. Libre-SOC is also providing the necessary drivers amongst which include Kazan (a Vulkan 3D driver) and the full on-board boot ROM firmware source, as well as a full zero-ROM cold-boot method for added trustability.
The intended market includes customers who desire acceleration in the embedded space without relying on ARM or 3rd party proprietary drivers that have been known to break in the past.
The first iteration of Libre-SOC targets a single-core at 180nm. Subsequent generations target SMP cores at a smaller node size, for typical use in SBC designs.
Interview to Roberto Innocenti about our project thanks to Charbax of ARMDevices
At the end of April, thanks to Charbax of Armdevices.net, there was an interview with Roberto Innocenti, the first creator of the idea of building a PowerPC laptop and co-founder of the PowerProgressCommunity. The interview was about the laptop project and other activities carried out by the not-for-profit association. Below you may find the topics touched in the interview. We think that the interview is interesting and contains many hints on the approach we are following, even if the spoken English of Roberto is sometimes difficult to follow. During the interview one person asked about the Manjaro distro for PowerPC, and after some check, it seems that such a distro lacks a PowerPC support.
https://www.youtube.com/watch?v=7kM2zqTEHa8
0.13 Self-introduction of Roberto Innocenti 0.45 Power Progress Community non-profit association 1.34 PowerPC notebook project 3.15 PowerPC architecture history 6.13 OpenPOWER Foundation 7.11 Why NXP CPU and not IBM 9.40 PowerPC on Linux 11.35 Linux distributions runnable on PowerPC 13:36 Future of embedded PowerPC 15:21 Cell processor interesting facts 18:27 Schematics and diagrams of PowerPC notebook project 19:31 NXP CPU specification 20:13 Upgradable AMD Radeon MXM GPU 21:02 Contribution of Power Progress Community and ACube Systems Srl 22:24 TDP, commercial usage and capabilities of NXP CPU 27:40 Supported kinds of storage 28:28 More about AMD Radeon MXM GPU 30:14 Old PowerPC MacBook performance compared to PowerPC notebook dev kit 31:41 Is Roberto Innocenti is better than Steve Jobs? 😉 32:25 People behind the PowerPC notebook project 34:07 PowerPC compared to ARM 37:35 More about OpenPOWER Foundation 40:43 Donation campaign details 43:52 Slimbook Eclipse chassis 46:50 What about small-desktop/NUC style device? 48:44 Estimated price of PowerPC notebook 51:55 Manufacturing of components 52:50 COVID-19 situation 56:23 Young people involved in PowerPC notebook project 57:11 Diversity of hardware designing, production and distribution 1:04:50 Transparency of NXP CPU 1:06:13 More about manufacturing of components and dependence on China 1:09:21 Ubuntu and Debian on PowerPC 1:11:03 Manjaro and other Linux distributions on PowerPC 1:12:30 Current phase of donation campaign 1:14:00 Potential successor of NXP CPU
Educational Activities
Under these complicated times due to the many restrictions imposed by coronavirus schools are closed, at least in Italy. As a consequence, students heavily rely on digital peripherals to keep up with lessons, and when trying to keep a social life with their friends. Not all families can afford a PC or a tablet for every child, and sometimes students are forced to study long documents on their mobile phones, when they have one. We are contributing to help the online education system run by Schools by providing recycled notebooks, and we named this project “Relive with Scratch” (“Rivivo con Scratch” in Italian).
At Schools with our project “Relive With Scratch”
Regenerated notebooks are those we have collected during 2019 and 2020 (all based on more or less old x86 cpus), and initially meant for the coding courses using the Scratch software and for learning math with Gcompris. To better suit the activities of the students, we opted for providing a Linux system equipped with ChromiumOS that has small footprints which is suitable for our old regenerated notebooks and moreover works well with the Google Gsuite which is heavily used in the classrooms, especially in the primary schools which is the main focus of our project.
We are near the 50% of the goal of the PCB Donation campaign, and we thank each of you that allowed reaching what many thought was impossible, “the key to what you do is in the heart of what you believe” (cit. by Mario Luis Rodriguez Cobos).
Like anybody else, most the volunteers, collaborators and donors involved in our project, we all have some very negative impact from the covid-19 that lead to a massive slow down of the donation rate.
On the other hand, many people are taking the opportunity of being in a lockdown at their homes to spend more time with their families, with their hobbies and to develop their aspirations. For many, it meant to spend more time thinking, developing and using Open Source Software, thanks to the freedom to run, copy, distribute, study, customize and improve their software. For others, it meant to have more time for developing Open-Source Hardware, Open Source Design of the mechanical aspects, and other important social, cultural, scientific activities, and eventually, to give them back for free to the community.
However, the financial impact of the situation meant to have less cash in our disposal, others are the current priorities in our lives.
After some internal discussions, we decided to postpone the deadline of the Donation Campaign to the 30th of June 2020, hoping that we all will be back soon on track, and meanwhile we will try to do our best to keep the project going.
Next round of the updated Block Diagram and Electrical Schematics
Since January, we have transferred to ACube Systems 8500 euros (roughly 9200 USD), so the design is in progress for a while now.
We have recently received from the engineers a newer revision of the Electrical Schematics that takes into account the recent developments, and it is currently under evaluation prior to its publication, most probably in a week or so.
Among a series of minor revisions, we have upgraded the Pericom PCIe Packet Switch from the previous model PI7C9X2G608GP to the more powerful PI7C9X2G612GP that offer 12 lanes instead of 8 lanes. This switch connects the motherboard to the Eclipse Expansion I/o Board via a PCIe, and allows to drive the Ethernet port based on the Realtek RTL8111F chip, the SD-card reader based on the Realtek RTS571x and to connect two USB3 ports.
The new revision of the schematics also brings an additional USB 2.0 Hub managed by the MicroChip USB2514 that will be connected to one of the T2080 USB 2.0 ports. To this USB Hub, we will connect the SK5126 Keyboard matrix and with an SD card reader controlled by the Realtek RTS571x of the Eclipse Expansion I/O Board and with the M2 WLAN and M2 LTE.
The Microchip Ethernet Transceiver KSZ9031 is still present from the previous revision, and it is connected via the RGMII0 port of the T2080 using an 8 pins header.
A MicroSD port will be connected directly to the T2080 eSDHC controller interface.
Below the new updated Block Diagram.
April 2020 Block Diagram of the Open Hardware PowerPC Notebook Motherboard
Overall, the above mentioned changes will decrease the number of components in the motherboard, will reduce the production costs, and will shorten the debug time.
Unreal Engine PowerPC64 Building progress
Recently, new collaborators joined the ongoing activities and are helping the laptop project and other side activities in our association. As an example, thanks to these recent collaborations we made progress in the compilation of the Unreal Engine on PowerPC 64 Big Endian, a great piece of software we are working on in order to have it running on our notebook.
Piece of script with download and build of clang
The first step is to get a clang toolchain needed by the Engine builder script. As a PowerPC toolchain is not available from Epic repository we have to build it by ourselves.
The main script that does all the job is build_linux_toolchain.sh located at the path Engine/Build/BatchFiles/Linux/Toolchain/DockerOnWindows/build_linux_toolchain.
Based on ppc64le branch this script downloads and builds gcc 9.2.0 through crosstool-ng and then do the same for clang. Our reference version is 8.0.1 from the official git repository https://github.com/llvm/llvm-project.git.
We have some problems during final toolchain copy, when gcc and clang libraries are moved to one common path (sysroot). After this action the binaries inside sysroot generate a segmentation fault.
Updates on Schematics are being transposed to the PCB design
In February the designer analyzed the Pericom PI7C9X2G608GP PCIe Packet Switch with the direct support of Pericom staff. Now, the Pericom PCIe Packet Switch is fully tested and all the needed setup is completed, so the designer has completed the inclusion of all required information in the updated version of the schematics and is starting to unravel the PCB.
The designer has updated the SerDes connections following our suggestions taking into account the notes we have provided, so a new version of the schematics is expected soon.
Arctic-Fox 27.10.1 PPC64 in our Repo
The main contributor to Arctic-Fox – Riccardo Mottola – member of our Power Progress Community association – has released the new version 27.10.1+b0 that we have compiled and packaged in our Debian PPC64repo. Riccardo says: “Session Store, code greatly improved compared to past releases, performance improvements in both the html engine as well as a new build system imported from Firefox. This release is definitely a great improvement compared to 27.9.19 right at start”
Arctic-Fox 27.10.1 PPC64 running on our T2080-RDB, that has the same processor as our future notebook.
Repository moved to our Power Progress Community GitLab group.
We have created a Gitlab group called Power Progress Community and we moved all our gitlab repositories under https://gitlab.com/power-progress-community. What is important to know is that all URLs have changed and any cloned repository must be rebased. If you have cloned our repositories you should update git remote origin.
Working on Unreal Engine for PowerPC64 Big Endian
We are working on a port of UnrealEngine (UE) to PowerPC 64 Big Endian. We started by forking the PowerPC64 Little Endian (PPC64le) version and we are currently trying to compile the sources. The original PPC64le port for UE 4.23 was developed by Elvis Dowson and Raptor Engineering and can be found at https://github.com/edowson/UnrealEngine/tree/4.23-ppc64le. Access to the UE4 sources requires accepting the Epic Games EULA as described in https://www.unrealengine.com/en-US/ue4-on-github.
We have modified the original scripts to compile for PPC64 Big Endian but so far, we still have to solve multiple errors leading before being able to generate a working binary. You can find our fork and ppc64 branch here https://github.com/robyinno/UnrealEngine/tree/4.23-ppc64 ( to access it you need to accept Epic Games EULA). We are building the source using both a Power9 virtual machine provided by Open OSU and OpenPower Foundation, as well as on our NXP T2080-RDB development kit using Debian PPC64 SID unstable. If you want to help us on fixing the compilation errors, you can start from our UnrealEnginePPC64 Wiki, please contact us.
A screenshot of the ongoing compilation of Unreal Engine on our NXP T2080-RDB developer kit, that has the same PPC64 Big Endian CPU of our future notebook.
Above all, one of the greatest problems preventing us from finalizing these schematics was the missing chassis required to take a series of very important design decisions. Finally, very recently, a chassis was selected and is now in our hands, paving the way to accomplish the goal.
Image from https://www.flickr.com/photos/curtiskennington/3642074604
In April we asked your opinion on either publishing an unfinished work or wait for better quality schematics. The Core Team chose to wait and “Send the information (the work in progress pdf of the schematic design) only to the 132 donors and kindly asking them to not publish”.
At the end of June there was an important meeting between Acube and the designer to discuss the suggestions from our Hardware team, and another topic was how to adapt the schematic to the new chassis. In fact we have prepared the next steps for the PCB design.
So now we have this modified block diagram that could have further few minor changes.
PowerPC Notebook Block Diagram – June 2019
Currently, the designer is working to update the schematics. This task is expected to be completed on August.
In the meantime, the Core Team we voted again in June and this time we have decided to publish the pdf of the current version of the schematic. That does not contain the updates we are expecting in August.
In other words, the schematic that we have uploaded to our repository is the same pre-release version that we have sent to the donors at the end of March 2019, and it should be noted that it is an alpha version. The only difference from the donors’ version is that it contains the recently selected Open Hardware license that is the Cern Open Hardware License v 1.2 (Cern OHL).
We have selected Cern OHL because it is specific for open hardware and it covers aspects regarding hardware production. It has the same viral effects that other open source licenses have but taking into account that there is a licensor of the hardware and another part that is manufacturing it.
The current version of the schematic is published in our repo in gitlab.
