Lup Yuen writes hands-on embedded tutorials for PinePhone, PineTime and BL602 RISC-V boards, using Rust, Zig, NuttX and LVGL.
HN commenters cite the NuttX, LVGL and Zig series as useful guides, and link it as a source of detailed board write-ups.
> This product family will never run Linux, as developers will need to develop a new firmware from scratch. This is obviously not a problem for the earbuds, but a big limitation for the player
Perhaps not Linux, but I suspect there would be a place here for a Unix-like platform that feels familiar. If for example we could get wide-adoption of something like the JVM or wasm3 [0] on these platforms, code could become quite portable, despite wildly different architectures.
For example, Apache's NuttX [1] (that I first learned from Lupyuen [2], a guy making great progress working with Pine64 products).
> Processing wise, this chip is well sufficient for TWS headphones, but very inadequate for an audio player. It will not drive a good screen, it nor run high-resolution flacs or (probably?) support a high-quality, high-bandwidth codec. In fact, a first generation iPod Nano (retailing for $149 in 2006) had 16MB RAM, so over 16 times what the PinePod would offer. In fact, even the features of any custom firmware are limited from so little memory
I wouldn't call it time just yet. Displays can be interacted with intelligently (to reduce pixel bandwidth) and ultra high quality audio codecs offer diminishing returns, especially when you don't have a DAC or headphones to make the most of them.
My advice to Pine64 would be this:
1. Consolidate your product lines. The Pinebook is just a slower Pinebook Pro, just go with the Pinebook Pro. The PineTab is just a Pinebook without the…
Most popular modern SoCs are not fully documented - one part that usually lacks any documentation is the GPU. For most ARM-based SoCs, it's either one of ARM's Mali series or an Imagination Technologies product, most RISC-V based SoCs (e.g. the JH7110) also use Imagination Technologies GPUs.
Additional components also have documentation that's hard to find, especially those based on Synopsys' DesignWare IP. These are sometimes at least... strange (or should I say buggy?) effects such as with their "standard" 16550-compatible UART: https://lupyuen.github.io/articles/plic
The Vivante GPU in Freescale's i.MX8 SoCs was reverse engineered and is probably the closest you can find to a somewhat documented GPU (STM32MP SoCs also have a Vivante GPU). In general, the i.MX8 is well documented - one of the reasons why it is used in Purism's Librem 5 phone.
You can "cheat" and improve the GPU situation a bit by using a RISC-V board with a PCIe slot and an old AMD GPU.
When there's no documentation available, all you can do is reverse engineer the functionality of existing open source drivers. Linux drivers are often quite complex, I recommend looking at Net/OpenBSD and Plan9 drivers instead. For some RISC-V SoCs (SiFive Freedom U740 on the Unmatched board and JH7110), Haiku is also worth looking at.
An alternative which provides documented hardware is to use an FPGA-based SoC builder, e.g. LiteX: https://github.com/enjoy-digital/litex
Of course, this results in a significant…
I was using LVGL (8.3.3) some time ago with Zig/WASM/PinePhone, following these great NuttX series of articles by Lup Yuen:
https://lupyuen.github.io/pinephone-lvgl-zig/
I just recently returned to Zig, and started porting the build file (zig cc calls) to latest Zig (build.zig), but struggling to compile the C LVGL to WASM I suspect because LVGL has a few dependencies on standard C bits n bobs, and I cant find a way to reference the C header files needed.
Anyway, just to say that I found the simplicity of LVGL a breath of fresh air. When I first looked at the PinePhone I was struggling to work out how to access the Mali GPU, thinking I'd be doing UI via OpenGL ES. But seeing how well LVGL and the simple frame-buffer approach works, I abandoned that approach all together. Thanks lupyuen!
It is also nice having the UI in WASM for iterative development without the slow deploy to phone hardware.
I was also able to simply extend an LVGL widget to show a 32bit register contents for debugging my SoC work. A huge time saver.
So a big thanks to the LVGL team on the library, and especially the detailed documentation and examples.
From the places I have lurked in so far, a lot of effort goes into reverse engineering the drivers etc... on these SOCs. If you were to spend weeks/months trying to figure out those details, it kind of makes sense to get mainline linux to run on these devices as opposed to a custom OS with no existing software.
If truly custom OS/Kernel is what you want, someone was trying to run NuttX RTOS on Pinephone:
1) Booting NuttX: https://lupyuen.github.io/articles/uboot
2) Writing an LCD Driver: https://lupyuen.github.io/articles/dsi2
3) Getting a basic terminal running using LVGL: https://lupyuen.github.io/articles/terminal
I'd still recommend trying to port PostmarketOS/Ubuntu touch/Sailfish OS etc.. to your phone first. That can be a good beginner friendly way to understand what happens on your smart phone: the boot process, software stack etc.. and then you can go deeper by either customizing the software (Boot into a little web browser and call it a web phone etc..)/drivers to your liking (Adding features like double tap to wake)/trying to port mainline kernel to them.
On one hand, it's disappointing. On the other hand, most of the PinePhone software has been developed, adapted, and patched by enthusiasts. Many applications were never intended to work on mobile devices in the first place. And no top-down direction. Android and iOS have been around for 10+ years, and it would be interesting to compare early Android to PinePhone now.
I believe PinePhones ship with Manjaro and Plasma Mobile, which is notoriously slow and unstable, and is part of the reason why I went with Phosh.
For a more feature-phone experience, there is an ongoing project to put NuttX RTOS on PinePhone [0].
For a very performant and customizable but unusual (button navigation, terminal-based) experience, there is SXMO [1]
0: https://lupyuen.github.io/articles/pinephone2
1:https://sxmo.org/
More info, from the same author:
https://lupyuen.github.io/articles/pinecone
Aside:
This is another interesting example of the "convenience" of centralisation of source code control around a single website: github.com.
The author seemingly never has to search competing source code control websites or hardware manufacturer websites. Most everything he references is found on github.com
Pine64 required all nutcracker entries to use github.com
Is it worth pondering that a company founded on the idea of not releasing source code to software users, instead copyrighting it and enforcing copyright through the courts and law enforcement, as a means for selling software (licenses), is now in control of accesss to all this open, freely avaialble source code.