Hey everyone,
I’ve been a long-time lurker here and a huge fan of the Pine64 ecosystem for a few years now. My journey started with a Pinebook Pro that I used as a dedicated "distro-hopping" machine, and more recently, I’ve been experimenting with a small cluster of Quartz64 boards for some home automation and a localized private cloud.
One thing that’s been on my mind lately, especially as I start pushing more containerized workloads and heavier database tasks, is the "memory ceiling" we often hit with SBCs. I’ve noticed a specific point in a few recent dev threads discussing how we can better optimize swap and zram, but it really makes me wonder about the hardware side of things.
I recently did a refresh on my main desktop/home server, moving it up to a 16GB kit of DDR5-4800MHz memory. It’s that PC5-38400 spec, and honestly, seeing the jump in raw bandwidth compared to my older DDR4 rig was a bit of a wake-up call. It’s not just about the capacity; it’s how quickly the system can move data for multitasking and heavy I/O. It made me realize how much I’ve grown accustomed to the snappiness of higher-frequency RAM in the x86 world, and it left me wishing for a bit of that "oomph" in my ARM projects.
I know we’re dealing with completely different power envelopes and thermal constraints here, but as we see more powerful SoCs coming down the pipeline, I can't help but dream of a Pine64 board that supports something like the PC5-38400 standard. Even if it was soldered LPDDR5 to save on space, that extra bandwidth would be a game-changer for things like local LLMs or high-speed data processing at the edge.
I’ve been trying to find ways to squeeze more life out of my current 4GB and 8GB LPDDR4 setups, but there’s only so much software tuning can do when you're physically limited by the bus speed.
Does anyone here have insight into the current SoC roadmaps—are we likely to see DDR5 support in the next generation of boards, or do the power requirements and complexity of routing those high-frequency traces make it a "no-go" for affordable hobbyist hardware for the time being?

Hardware Feature Suggestion: SPI Flash Hardware Write-Protect & Factory-Flashed Secure Boot

First of all, thank you for providing amazing open-source hardware to the community. I am a developer, privacy enthusiast, and independent researcher, and I would like to propose a simple yet high-value hardware revision for future batches of the Quartz64 or upcoming single-board computers. Currently, the board relies on DIP switches for boot priority, which is firmware-based and does not physically cut the power line for the SPI Flash write operations.

For users focused on sovereign security, physical containment, and preventing persistent firmware implants (rootkits), having a Hardware Write-Protect (WP# linked to GND via a physical Jumper or a Screw mechanism)—similar to the Chromebook write-protect screw—is crucial. Adding small exposed copper jumper pads (open pads) between Pin 3 (WP#) and Pin 4 (GND) on the PCB layout would allow advanced privacy users to bridge them and achieve true physical, air-gapped read-only isolation for the Tow-Boot/SPI flash.

Furthermore, for PINE64 boards that come with a pre-soldered SPI Flash from the factory, we strongly suggest shipping them with a clean, verified, and officially signed open-source bootloader (like Tow-Boot) pre-flashed out of the box. Many security-conscious buyers operate in highly compromised, untrusted, or heavily monitored network environments where flashing a clean image locally from scratch is incredibly risky or nearly impossible without immediate interception. Shipping the hardware with a factory-guaranteed clean bootloader would provide a secure and immutable root of trust immediately upon unboxing.

I highly recommend offering these as design standards in your upcoming revisions, or even as an optional manufacturing configuration toggle for a small extra fee. It would make PINE64 the ultimate choice for the global privacy and secure-boot developer community.

Looking forward to hearing your thoughts on this hardware implementation.

So, I’m running my Star64 headless for crypto mining, but lately I’ve been wondering—why not give it a co-processor that’s a little more… interactive? Has anyone ever tried to cohabitate with an SBC in a way that’s more about shared leisure than silent computation?




MeetAgree.com
Your city's hottest girls are here

So, if you're already soldering tiny boards and debugging firmware at 3 AM, why not repurpose that Pinecil as a social debugging tool—like a playful way to "hotwire" connections with fellow tinkerers at meetups? Ever tried turning a soldering iron into an icebreaker?



MeetPrettyGirls.com
Find a girl to share the night with

Hi all, I've pushed some more updates for SlateOS and its companion app, mostly to improve the battery life:

- Vibration toggle
- Optimisation of app to watch comms
- A fix for the launcher not being available after reconnecting
- The companion app now finds the app after it was away from the phone

I would really like your feedback! I'm also curious for more sub-app ideas, and if anyone has tried writing their own.

Hello, I am a new member of the forum. I want to actively share content, ask questions, and learn; I hope this turns out to be a beneficial forum.

With RAM prices and availability becoming a problem, why not make SBCs without onboard RAM and use a standard laptop SO-DIMM slot instead?

This could have several advantages:

- Much lower base price

- No need for separate 4/8/16/32 GB SKUs

- Users can choose the amount of RAM they need

- RAM could be upgraded later

- Less dependency on onboard RAM availability

Any thoughts?

Just received my PineTab2 but cannot log on with user=alarm and password=123456 as it says in the docs

The username alarm is the one it wants me to log in to but none of the passwords I've tried have worked

Hi, I've actually pushed quite a few SlateOS fixes and updates to Github:

• Fix for accelerometer.
  
• Fix for overlapping buttons on the watch.
  
• Fix for recurring notification vibrations.
  
• Companion app UI reworked.
  
• Shake-to-wake in addition to raise to wake.
  
• Sensitivity settings for both accel-based wake methods.
  
• Deactivation of face diagnostics.
  
• Notification on the watch.
  
• Watch screen navigation indicators.
  
• Watch face, button and text colours!
  
• Media control sub-app (tested with Spotify).
  
• Weather sub-app with tides (I live near the sea) (uses phone GPS).
  
• Turn-by-turn Navigation sub-app for OsmAnd Free and Pro (no affiliation there!). Start navigation in OsmAnd and open the Vavigtation sub-app on the watch.
  
• RSS news reader sub app (configure via its settings in the companion app sub-app repository).
  
• Companion app sub-app connectors for http, calendar, alarms, HealthConnect, Home Assistant.
  

Hello all

             i'm Mike from Australia and am considering buying a PineTime watch.

      i would prefer to sync/connect it directly to my linux compter. if necessary, through a 
Samsung  s21

        i get the watch in the post. i open the box. i charge it.

      What do i need to do after that ?   Their website is anything but clear.

     Are there any fitness apps that work with PineTime ?

        Does PineTime count calories burned ?

                                                                       Mike