So first of all, stellar job on the PineTab-V. For an experimental device targeting developers, it hasn't been much of a hassle setting it up as a regular machine in my fleet. My PBP was recently stolen which is a major bummer, as the hardware was kinda crumbling but the compute was running solid and I had even gotten it working with the PBP dock.

Anywho, wanted to make a topic concerning the PineTab-V as I've been tinkering pretty heavily with bootstrapping a ground-up GNU/Linux system on it using as much upstream as possible, relying only on the kernel and Imagination GPU firmware additions here: https://github.com/starfive-tech/pinetab-v

First off, a word of warning to anyone playing with the GPU. It appears that the current upstream Mesa3D expects to be hitting the GPU specifically with firmware 1.17. I've found that I get some oddball error when I attempt to use firmware 1.17, but firmware 1.19 results in a proper bootstrap of the pvr driver. Unfortunately this then clashes with the expected version in Mesa and it still doesn't allow full utilization of the GPU. I've tried fudging the expected value in Mesa to 1.19, but that then simply fails with some buffer problem, presumably an interface change in the firmware. In any case, just detailing this for folks interested in the 3D acceleration situation. If anyone has gotten this working with firmware 1.17, I'd certainly appreciate some assistance, otherwise, probably just means waiting until Mesa rebases support on 1.19.

Another bit is the display brightness. Various sources point to a PWM-based brightness control, and indeed installing the generic PWM brightness driver in the kernel results in /sys/class/backlight/backlight being populated with various files. However, writing various values to /sys/class/backlight/backlight/brightness does update the reported actual brightness, but the display itself seems unchanged. I haven't dug further into this, but I am currently getting a failed firmware load on the Goodix firmware, not sure if the touchscreen controller has anything to do with brightness but I intend to address missing firmware BLOBs in the coming days.

For the record the firmware BLOBs that don't appear to be upstream include: rgx.fw.36.50.54.182, rgx.sh.36.50.54.182, goodix_991_cfg.bin, regulatory.db, and wave511_dec_fw.bin.

In addition to all of this with the vendor 6.6.20 kernel, I also tried my hand at minimally moving to a 7.2.x upstream kernel. Starting with the same .config, give or take a make menuconfig to refresh a few things, the kernel built just fine. Installed it, updated extlinux, and just got stuck on the bootloader splash. I tried again copying over the relevant dts and build instructions, built the pinetab-v dts, and it managed to get past the splash, but still a black screen with nothing else going on. I haven't really dug into the other 2000+ differences between stock 6.6.20 and the PineTab-V kernel, but I intend to dig around in there just to see if anything obvious sticks out in the display stack.

Anywho, thought I'd share a few of these experiences in case anyone else is seriously invested in the PineTab-V and wants to tinker with a few things. I'll also be sharing here anything else I stumble across while tuning this up. One bit of praise I can lump on is that, like the PBP, I appreciate how easy it is to just flash a new SD card and bootstrap a new system or repair the existing one in-situ with some chroot shenanigans. I've been waiting for that in the cheaper RISC-V sphere for a while. When I first loaded a bungled kernel while tinkering, I hadn't yet verified I know how to boot a repair system...so got kinda nervous that I had bricked it. Nope, nice and simple, grabbed an SD card image, laid a Gentoo stage3 down over it, and frankly I could just run from this card but it has saved me on numerous occasions while hacking the factory system to pieces.

I even accidentally "rm *" in /usr/lib...you can imagine how that went, but luckily Gentoo'd it back into existence.

So yeah, great piece of hardware, for the weird esoteric stuff I do it honestly could be a daily driver. I'm going to be working towards that end on these and other issues. Glad to have gotten it and I look forward to future members of Pine's RISC-V hardware line.

I have a PinePhone Manjaro Edition and it's working alright with PostmarketOS, but I do have some issues with SMS, particularly larger messages getting "jammed" and not receiving, until I manually delete them from the queue, wait some amount of time (sometimes even a day) and it will start working again. I thought this might be some modem firmware issue as I am running a very old version.

The original modem firmware was EG25GGBR07A08M2G_01.001.01.001

I tried updating to 01.002.01.002 with the fastboot command, but it only seems to have half worked, or something.
I used the information here: https://github.com/the-modem-distro/pine...LASHING.md

I got a message like this with a warning:

This thing has been a pineintheass for many years now, I been dragging this brick around since when it screamed at me (literal bird chirping noise) while charging it with usb c in my car and got mad at me wouldnt turn on. So I bought a barrel charger usb connect it to my phone charger and that seemed to make it happy because now the red LED turns on for barrel and USB C again, and power button turns on the poweron LED. But the screen wouldnt turn on. 

Years later again I got some time to work on it again, charging led good, power ON LED good, no display, cracked open the lid (10 SCREWS   ) and noticed the LCD connector was disconnected (why) so I reconnected that and flicked the emmc switch towards the hinge... NOW IT WONT TURN ON THE POWER LED WHEN I PRESS THE POWER BUTTON 

After reading some trouble shooting it said to pull out the power connector and reattach the display socket, I did so and that thing was like pulling a pinecone out of ur ass it was so tight the corner of the white thing snapped off ;_;.. After connecting all of that it still wont power on where it just was before I reattached the display connector, and flicked the emmc switch.. Idk if the power connector is totalled now, photos attached. I tried pressing the power button for like 15 seconds doesnt work with or without charging (charging LED is still working).  Armbian was nice while it worked..

Attached Files

Thumbnail(s)
                   

Hello! I am alarmed that several apps I rely on will possibly stop working in 2027 on Android, and I heard about PinePhone from Ecosia's AI chatbot. It says the newest model of PinePhone is the PinePhone2, which supports microSD cards which is important to me because I have a large music collection. But it couldn't find any info about whether PinePhone2 supports Cricket Wireless, which is important for me because I'm on a very tight budget. I'm honestly not even sure I can afford a PinePhone2, but I'm terrified of Google's new restrictions so I figure it's best to do research.

Also, do VLC Media Player and Brave Browser work with PinePhone2? I can switch to Firefox if I need to, I just found that Firefox was slow last time I tried to use it on my phone.

Also, I've been using Alarm Clock Xtreme from AVG for years, but I'm not sure it will be supported through 2027. I like that it lets me set daily and weekly alarms and appointment reminders with music from my collection. Are there alternatives to that app available for PinePhone2? It's OK if I have to use two separate apps, one for alarms and one for reminders. Really I should be using a calendar instead of one-off reminders but I don't like Google's calendar app. 

Lastly, how is the battery life? Can I replace the battery on a PinePhone 2? I know most phones don't let you do that but I wonder if this more open alternative bucks that trend. That would be cool.

I'm sorry for asking so many questions in one thread. I don't really know if it's best to split it up or not. I'm kinda scared right now and I'm just looking for some hope in an increasingly scary world. FOSS software always made me happy.

Having my Rock64 card for over 8 years running  ayufan's Android TV (thanks a lot for this perfect job!) i tried to migrate to Android 10. Here is a patch set that can be applied to Firefly SDK. Not sure it makes sense still...
https://github.com/vtsick/rock64-android10-tv

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.