Hello everyone, we know it’s been quite some time since our last update on November 21, 2024.

We really appreciate your patience! Despite the silence on our end, we’ve seen that our incredible community – both old friends and new supporters – have continued to donate continuously. An infinite thanks to all of you, our amazing current, past, and future donors! Your unwavering support truly fuels our efforts and keeps the dream alive.

Short story

As we shared in our last post, the work with the previous designer hit a significant hurdle: we just couldn’t get the board to reach the crucial boot stage.

This led us on a search for a new designer, someone with specific skills and experience with PowerPC architecture. We were really pleased to find a talented new designer who was available from the beginning of 2025, who can even rely on an additional person who is an expert in firmware programming. Following our plan, we used January and February to make the big move, getting all the equipment transferred over to this new designer’s team.

We held off on publishing updates because, honestly, we were waiting for that breakthrough moment – the good news we could finally share with all of you. As things were showing quite promising (e.g. improved CPU signals outputs), we had high hopes that this new collaboration would quickly move us past the booting issues. In parallel, we also tried improving U-Boot and led an additional T2080RDB, the development board that was kindly provided by NXP, to one of our collaborators, but due to personal health problems, he can no longer contribute to the project.

Our work with the new designer has been focused on rigorous testing. On April 9th, we saw that the board’s behavior was frustratingly similar to the devkit – it still wasn’t booting. This prompted a dedicated session on April 14th for one last intensive attempt to find the root cause. As part of this deep dive, we de-soldered the Marvell chip, which is the SATA3 controller.

Removing this component was actually something we had already planned to do for the upcoming prototype version as we streamline the design. To help isolate the issue even further, we also de-soldered the Pericom chip.

The overall outcome? Despite taking these significant steps, the board still did not boot. It exhibited exactly the same behavior. We were, frankly, quite upset and left without words.

It’s incredibly challenging when you put in the effort, try to simplify things, and the core problem persists. So far, we have spent around 6000 Euros with the newly hired hardware designer, and even if things have improved, showing the expected NXP documented behaviors of the NXP reference development board, after two years with the prototype motherboards in our hands, we still are not able to boot it.

So what’s next?

This difficult moment, however, has reinforced our resolve and led to a strategic adjustment, as the title suggests. We remain absolutely committed to making an Open-Hardware Notebook-based PowerPC machine a reality.

By the end of 2025, we are determined to do whatever it takes to have at least a stripped-down functional desktop version of our Powerboard Tyche up and running.

We change tactics

Focusing on a desktop board first allows us to concentrate on getting the core computing platform stable and functional, tackling the complexities of a laptop form factor (like power management, screen integration, etc.) in a later stage if needed. We even plan to revert to the NXP original CPLD used in their development board, not the version we previously selected for the notebook prototypes. This is a pragmatic step to ensure we achieve a tangible outcome by our 2025 target.

The path forward still has its challenges. We need to understand precisely why the notebook prototype board isn’t booting and what electronic redesign might be required, and for this, we are in contact with experts directly at NXP. Once we reached the point of a fully working desktop version, we will still have to design the heat pipes, work on the chassis and most probably adjusting the board mechanical design, and finally, test the MXM video card, but for this we hope that the desktop version will provide a suitable testing bed.

With the expertise of our new designer and the continued incredible support from our community, we are pushing ahead with the hope of providing a fertile environment supporting the growth of the PowerPC as a viable alternative architecture. In this respect, we extend our sincere congratulations to Dave ‘Skateman’ Koelman and Harald ‘Geennaam’ Kanning for successfully bringing their PowerPC NXP T1042/T2081 CPU-based micro-ATX desktop board, ‘Mirari’, to a working state.

Open Hardware, your time, your commitment and spreading hardware knowledge is what matters most

Let’s go all the way in realizing our Open Hardware PowerPC board from the bottom up, together as hobbyists, enthusiasts, and volunteers; it makes sense for us to have designed it as a community effort to spread hardware knowledge.

We value the experience of making our Open Hardware Powerboard Tyche based on PowerPC from scratch; this is possible thanks to the support of all donors and supporters, and the time and creativity of the activists who have been involved in this project over the years.

For us, it is of fundamental importance that our board is Open Hardware ,( we will certificate as Open Hardware with OSWHA when it will be completely functional) and the prototypes are realized thanks to your support and donations. Designing a notebook motherboard is a challenging objective, and while we like challenging goals, we knew from the start that experimenting at this level of complexity would not always go as initially planned. But we persist; we must finish to reward all the effort we have made.

Be an Association Member to improve ourself

To enhance our collective knowledge, the best way is to join the association NOW (link to join our association). By becoming a member, you can participate in the next meeting, which will be held before May 9th. In these meetings, we delve deeper into the next steps. Association members have a voice in the decision-making process and in solving complex situations together. The more members we have, the stronger we are and the wiser the decisions we can make.

You could be the protagonist of the crucial 2025 milestones

Thank you again for being with us on this journey, as we work towards making our Open Hardware Powerboard Tyche based on PowerPC a reality.

Your support is invaluable, whether through generous donations, contributing your skills as volunteers, or helping us spread the word. This collective effort allows us to continue making progress. We are committed to keeping you informed with the utmost transparency as we strive towards the crucial 2025 milestones. Stay tuned for more updates!

Tax Returns for donations ( Italy)

For people that pay Italian taxes (they must have an Italian fiscal code) the donations to our association are deductible in tax returns, what’s more from your income tax return you can donate “5 per mille” specify our association Power Progress Community OdV Fiscal code: 97757160151

The Long Story

Until November 2024 : The problem was precisely the different behaviour of the two boards; on the motherboard I only managed to run a little test program from SRAM and that writes cyclically to serial, but the output was with unrecognisable characters, because the baud-rate was wrong (while on the devkit the little program runs perfectly), so I think the problem is precisely in the management of the various signals of the CPLD that do not respect what is written in the datasheet of the CPU

History of the activities carried out by the new designer’s team

You can see here the report produced by the new hardware designer team.

They managed to collect some sequences on our prototype, then the complete screen print of the evk was found to solder the threads in the right places.

They managed to get a mirror-image behaviour between the two systems (devkit and our prototype) as little as possible: route SYSCLK to CLK_OUT via uSD (via pbi)

Platform clock is 400MHz (SYSCLK * 6 from hardcoded rcw)

Also rcw is read fine from sd (or rather, the pll configuration works, I expect it to pull up all 512 bits correctly)

Performance of reset signals between the two systems,

PORESET_B (channel 1 yellow), under OVdd = 1.8V, is driven by 3.3V

HRESET is open-drain while PORESET_B is still push-pull

only HRESET is open-drain, PORESET was also put in open-drain, to see if anything changes

Other inconsistency… JTAG_TRST_N shoots 3v3 on a 1v8 port

The output type of PORESET has been fixed but nothing has changed.. In the traces above you can see a clear difference between channel 1 (PORESET) and channel 2 (HRESET). The RDB does a much more limited reset sequence (see zoom) and waits about 400ms before raising HRESET, while our prototype, in addition to the more relaxed toggle sequence, only waits ~150ms before raising HRESET. A quick test was made by increasing the time between PORESET and HRESET, but nothing changed.

The hw modification (HRESET and PORESET in open-drain) did not bring the expected benefits, there are still 3 resistors (R375, R377, R379) that should not be mounted, since the documentation clearly states that these pins (PROG_MTR, PROG_SFP and FA_VL) must be grounded (as on the devkit) there was a small increase in current consumption from 12V after this modification now pulls just over 1A from 12V

A few doubts remained, one is as follows: why is it that if the CPU is running at the right frequency, the output on the serial port is with an incorrect baud rate much lower than the set one? what could this depend on?

The frequencies fed to the various plls and peripherals are controlled by the RCWs. of the two hardcoded RCWs, only 0b01001110x is good for us (partially) because it provides a SYS_REFCLK of 66.7MHz. Partially because it predicts a DDR_REFCLK of 66.7MHz, while the prototype has 133MHz. I don’t think it’s a problem in this case though. when you connect with codewarrior there is a possibility to change the rcw.

Removing the resistors that didn’t need to be fitted didn’t change anything.

Tests done in the past with the fw in sdram was done both on our prototype and on T2080RDB

This was the trace on our prototype serial output, as you can see the frequency was not 115200 baud

Summary as of 8/4/2025

• We have confirmation that at least RCW and PBI are read and applied by the PBL
• Several errors were found and fixed in the assembly plan

The changes on CPLD are divided into 2:

• Fix of PORESET drive type (push-pull -> open-drain)
• Alignment with NXP schematic
  For the second point, there were no improvements, so not necessarily useful

u-boot developments there are none, since it does not start yet, which is why the debugger attachment fails in our opinion

14/04/2025 Sata3 and Pericom desoldering activity