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
