The laptop prototypes testing is progressing great. We tested the primary power supply stage of the CPU, one the most power hungry components in the board, and it is being fine-tuned thanks to a programming apparatus. The chip in charge to power up the CPU NXP T2080 is the Texas Instruments TPS544B20RVFT (Switching Voltage Regulators 4.5-18V 20A SWIFT) as explained at page 37 in our electrical schematics.
The start-up ramp needs to be carefully calibrated, a complex integrated circuit with a some logic that needs to be programmed to make it work properly (i.e. ramps, voltage thresholds, internal ways of making the PWM regulator work, and so on).
The other power supplies are a half a dozen voltage regulators and are meant to power elements such as the PCIe, the RAM, the internal peripheral buses, the connected devices, the Non-Volatile Memory Express (NVMe) and the clock generators the are essential to make the board work properly. The Eclipse Legacy Battery was tested and is recharging properly.
Powerboard Tyche, top side. The visible biggest gray chip is the CPU NXP T2080 Power Architecture CPU.
So far so good, the electronic design seems to work correctly, at the moment we are only fine-tuning each electronic component. If all checks continues like this, we might end all electronic debugging in the next few weeks and we can consider this very delicate phase successfully completed. After that, we plan to place the first code in the CPLD, and right after that we should be ready to load U-Boot, the first-stage and second-stage bootloader. We are trying to re-patch a recent version of U-Boot, quite some time has passed since we patched it to make it recognizing the graphic board we mounted on the PCIe port on the NXP T2080RDB board. Not just that, we must carefully customize the device tree to correctly map all peripherals available on the motherboard.
If for it concern the electronical components we can safely rely on the (paid) support of an expert engineer, for setting up U-Boot it’s up to us to make it work properly, and more importantly, to make it correctly recognize all peripherals, especially the SD card, the FLASH and, even more importantly, the two DDR3L RAM slots.
We would like to thank everyone for the continuous flow of donations, and please, continue to do so.
At the moment we still need funding to cover the extra costs we faced for the simply crazy prices we paid for the electronical components mounted on the prototypes motherboards and especially for getting our hands on two MXM graphic boards based on AMD chips.
For two MXM AMD E9174 video cards with 4GB RAM we have spent 780 dollars ( 360 each) and 185 euro of import Tax around 965 euro .Considering all chips, the cost of each prototype resulted 1200 euros higher than what was initially planned 4392euros more (1200 x 3 + 22% VAT). So we need to collect around 5357 euro more than the goal of the last donation campaign.
Donations and professional for u-boot
In addition, after an initial round of experiments, we are still struggling to successfully customize U-Boot and to properly setup the device tree. Most of us already spent quite some time on the task during our spare time (remember, we are all volunteers with a proper day job and a personal life ;), so we are seriously evaluating to assign the job to a professional to get the job done in a reasonable amount of time, and to do that we need your financial support!
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
By O.T.S.U. – http://openvirtualizationalliance.org/downloads/kvm-logo_300dpi.png, CC BY-SA 3.0, https://commons.wikimedia.org/w/index.php?curid=24109871
A different area but closely linked to the kernel, is the support to the KVM, the Kernel-based Virtual Machine that does not currently work in our tests with the T2080RDB. This is a must-have feature as it allows the user to manage virtual machines running at nearly native speed because they do not need to emulate the CPU because KVM is able to use the host computer CPU directly.
Screenshot taken by Christian Zigotzky on his AmigaOne X5000 (CPU NXP P5040, PPC64, Book3e, e5500) with a working QEMU+KVM.
We are quite confident that with a relatively small effort it could work because there are people using KVM on a very similar CPU, the NXP P5020, which is a Book3e CPU, specifically the e5500 variant, the previous generation NXP CPU. You may have a look below at the results achieved by Christian Zigotzky on his AmigaOne X5000, a computer currently being sold by A-Eon and based on the NXP P5020 or P5040.
These are the relevant mailing list about respectively QEMU and KVM on PowerPC:
Another important task that we plan to carry out while the prototypes are being made available, is to coordinate people that are able to identify and fix issues preventing Linux distributions for PPC64 (Big Endian or simply BE) such as Debian, VOID or MintPPC from working on the motherboard. Other Linux distributions such as Ubuntu (last supported version 14.04) or Fedora (last supported version 28) abandoned the PPC64 a long time ago, it would be great to have them supported again, but that is way too ambitious at the moment.
The plan is to identify which software has problems on our NXP T2080 CPU, most probably due to endianness issues, identify the required set of changes in the source code, and then submit a patch to the maintainers of the software. The problem we are facing here is that the vast majority of modern software is meant to work on Little Endian CPUs only and most of the time developers do not test their software on any Big Endian platform, also because they are becoming a quite rare piece of hardware nowadays.
As having access to one T2080RDB only could be a problem, we can say that in our experience the NXP T2080 CPU behaves quite similarly to the G5 CPU (PowerPC 970), the last commercially available 64 bit CPU with Altivec used by Apple on their line of PowerPC based Macs. If a software works well on the G5 there is a very good chance that it will work well on the T2080 too. Sure, the T2080 is quite less power hungry with respect to the G5, but the G5 would be the perfect companion for carrying out the investigation while our notebook motherboard becomes available to purchase. Another difference with respect to the G5 CPU to keep in mind, is that the T2080 belongs to the Book3e CPU family where the “e” stands for “embedded”, whereas the G5 is a Book3s (aka sPAPR) CPU, see this page for an schematic explanation of the PowerPC families (https://www.kernel.org/doc/Documentation/powerpc/cpu_families.txt). A more detailed explanation of the characterics of the Book3e CPU family is available here https://www.nxp.com/docs/en/user-guide/BOOK_EUM.pdf
We would suggest to anyone interest in helping on the job to get their hand on a PowerMac G5 possibly mounting any RadeonHD video board, and install the PPC64 big endian version of Debian (https://cdimage.debian.org/cdimage/ports/current/).
An additional expertise we are looking for is anyone with some knowledge on how to tweak software in order to enable Altivec support, a single-precision floating point and integer SIMD instruction set that would greatly improve the user experience when supported.
In the past few years we identified quite a few key software areas potentially affected by endianness issues that may heavily impact the everyday use of the platform, but three areas are in our opinion the most relevant ones.
Anything related to driving modern AMD Radeon GPUs. We selected AMD GPUs to use in conjunction with the notebook motherboard, as overall these cards seem to behave quite well when used in a big endian environment. The problem to face here is that any update on anything related to driving these video cards may cause errors preventing any video output, for example updates on the kernel, on X11, Mesa for 3D software, and more recently Wayland or Vulkan. As an example, a recent update of Debian SID for PPC64 suddently broke something and now we cannot start any X11 session on any RadeonHD we tried, the cause is under investigation.
Video hardware acceleration is also a target that must be investigated, so we would need someone able to deal with problems related to AMD Radeon specific technologies such as Unified Video Decoder (UVD), Video Code Engine (VCE) and Video Core Next (VCN). Software using these technologies that must be carefully investigated are VLC, mplayer, and the video decoding part of web browsers in order to let them play videos at full speed because the CPU is not powerful enough to decode FullHD or 4K video streams.
Web browsers. These softwares are the most used applications by any type of user and without them the notebook does not have any chance to become appealing to anyone. The most stable and performing browser in our experience is Arcticfox (https://github.com/wicknix/Arctic-Fox), a fork of an old version of Firefox, and InterWeb (https://github.com/wicknix/InterWebSnow).
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.
