Finally, the three prototypes are ready as you can clearly see from the pictures below.
The resulting cost of each prototype resulted in 1200 euros (without VAT) higher than what was initially planned due to the global shortages of electronic components that have skyrocketed prices of some important chips. So, more donations are needed to fund these 4392euros more (1200 x 3 + 22% VAT).
Powerboard Tyche, bottom side.Powerboard Tyche, top side. The visible biggest gray chip is the CPU NXP T2080 Power Architecture CPU.
Now the Hardware Tests stage has started, but prior to that we still need to solder the HDMI connector that has arrived too late to be included during the production phase.
Soon, our Open Hardware motherboard called “Powerboard Tyche” will be inserted in its notebook body chassis for starting the multiple hardware tests. Below, you can see a picture of the old dummy PCB used for testing how to fit in the notebook.
POWER: on-board battery charger and power-management
Powerboard Tyche PCB source
This work was made using Mentor Expedition and it is ready and uploaded into our repository with all reported issues fixed, including issue number 5, the last one corrected . Thanks to our collaborators we are able to export this work using Altium form so the next days we will publish it and we will try to convert it to Open Source Kicad format ( and probably loosing something in the conversion process) . In our older post we have give more details regarding the PCB sources.
We were supposed to start the production of the laptop prototypes at the end of last September but we stumble upon skyrocketing prices, especially regarding four fundamental chips. We had no other choice but to pay those incredible much higher prices, the only alternative would have been to stop all our activities.
We are glad to inform you that this week the prototypes production has started and – finger crossed – we are expecting them to be ready in the beginning of November. The following are the four fundamental chips and their actual cost:
Marvell Sata 3 controller 88SE9235A1-NAA2C000, around 130 euro per piece + VAT, 1 per PCB, total 3 pieces
TPS544B20RVFT 4.5-V to 18-V, 20-A synchronous SWIFT™ buck converter with PMBus programmability and monitoring around 550 euro per piece + VAT, 1 per PCB, total 3 pieces
6-port, 12-lane, PCIe 2.0 Packet Switch PI7C9X2G612GP – Diodes around 250 euro per piece + VAT, 1 per PCB, total 3 pieces
Surge Suppressors 100V OV, UV, OC and Reverse Supply Protection Controller with -50mV Reverse Threshold LTC4368IDD-1#PBFaround 100 euro per piece + VAT, 1 per PCB, total 3 pieces
The HDMI connectors (2041481-1) were completely impossible to find on the market in a reasonable amount of time. After long research, we could finally solve the problem thanks once again to the kind support of Slimbook, they will soon send us three connectors, one for each prototype.
Considering all chips, the cost of each prototype resulted 1200 euros higher than what was initially planned, 3600 euros more ( + 22% VAT) considering all three prototypes currently in production. You may find more information about these three prototypes in the post of July 2022 and May 2022.
As already stated in our post back in July, we are still asking you to continue donating as to help us supporting the dramatic increase in the actual costs we personally anticipated to proceed with the production. You may continue use the current campaign to donate.
Our presence for October-November in Free Software and IT events
We hope to first show at least one prototype at the SFScon – Free Software Conference – on the 11th of November in Bolzano (Italy) in the occasion of our next speech.
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.
QEMU at full speed with KVM on the NXP T2080 CPU
Thanks to Fabiano Rosas, Cédric Le Goater and Zoltan Balaton (see discussion at https://lists.gnu.org/archive/html/qemu-ppc/2021-12/msg00231.html) it is now possible to launch virtual machines at nearly native speed with QEMU on our NXP T2080RDB development kit, that mount exactly the same CPU as in our laptop.
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
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!
During our surveys on the electronic markets last September, we observed a skyrocketing increase of the prices. We are a group of hobbyists that have zero power to sit down and bargain with electronic companies. Even the well established Raspberry Pi foundation was forced into increasing their prices (see https://www.raspberrypi.com/news/supply-chain-shortages-and-our-first-ever-price-increase/)
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.
ATI Radeon HD4650 1GB DRR3 MXM 3.0A and AMD FirePro M4000 GDDR5 1GB MXM 3.0A
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.
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.
The latest available QEMU version is 6.0 and it does support the emulation of the Book3e CPU family, named “ppce500 platform” in the documentation, and it does support e6500 cores as well.
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.
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.
Top side of the dummy board.Bottom side of the dummy board.
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.
ATI Radeon 7970 MXM card.
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.
A Slimbook Eclipse enclosure kindly donated by Slimbook.
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!
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!
The campaign aimed at the “Fast simulations bus” is nearly complete, and we will receive the resulting PCB design before the end of 2020. As soon as we have reviewed it, we will publish it in our GitLab repository. Here a screenshot with the PCB design currently being finalized.
our PowerPC Notebook Motherboard design screenshot from Mentor Xpedition
Similarly to what we did for the current campaign, the next donation campaign for financing the “Production of five working prototypes” will start as soon as the current campaign will reach its end. In coordination with ACube Systems, we fixed the cost of the five prototypes to 10.500 euros, and we aim at delivering them during late Spring 2021.
Freedesktop-sdk for PPC64 Big Endian Compiled!
We have patched freedeskop-sdk to compile perfectly on PPC64 so now we are preparing, according with Freedesktop-sdk teams, the merge requests to send to the mainline repository.
So we have successfully compiled 432 packages that it involves even the last version of go lang.
We thanks OSU Open Source Lab and OpenPower Foundation to provide us a Power9 VM with 8 cores and 16GB of RAM that permit us to compile Freedesktop-sdk for PPC64.
Now thanks to OpenPOWER@UNICAMP we have a Power8 VM to recompile freedesktop-sdk for PPC64 in Continuous Integration for gitlab freedesktop-sdk pipeline.
As Flatpak binary is running on Debian 10 PPC64 Big Endian and need the Freedesktop-dsk layer to prepare the flatpak packages starting from hundreds of manifests, now we are a step closer to see flatpak packages prepared for PPC64 .
This website uses cookies so that we can provide you with the best user experience possible. Cookie information is stored in your browser and performs functions such as recognising you when you return to our website and helping our team to understand which sections of the website you find most interesting and useful.
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.
