This month’s big news isn’t a piece of hardware or software but rather an upcoming platform aimed at community developers called the PINE64 DevZone. But fret not, I also have a number of hardware news to report – including a new LoRa device called PineDio Stack – as well as an overview of the software progress on our flagship devices.
Let’s get to it.
You can watch the synopsis of this month’s community update on YouTube (embedded below) as well as on Odysee and PeerTube. To stay up-to-date with PINE64 news make sure to subscribe to this blog (subscription widget at the bottom of the webpage), follow PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.
I’d like to thank JF, Alex (clover), Danct12, Peter (pgwipeout), Martijn Braam, Brian (33YN2) and PizzaLovingNerd for their contributions to this community update.
N.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.
Community update video summary by PizzaLovingNerd
TL;DR
This month’s housekeeping focuses on one sole topic – the PINE64 developers portal called PINE64 DevZone. In recent months the community of active developers has grown significantly; I suspect that the number of active community developers has more than quadrupled since 2019, which is obviously great. This growth has, however, resulted in a side-effect of sorts – we (I in particular) have lost track of who is working on what. Moreover, with development taking place across various communication protocols and platforms, newcomers to the community willing to contribute code are forced to spend a long time looking through chat logs, finding relevant repositories, gathering resources and figuring out who-is-who in the community. We wish to help streamline this process, improve cooperation and build a system to disseminate development resources in an efficient way.
Registration for the DevZone is now open and anyone with an interest and experience in software development is welcome to apply. The portal is primarily aimed at developers unassociated with our partner projects (partner project developers will be granted a developer’s status automatically) and industry partners who want to contribute code or share their insights, but we’ll happily review any submitted applications.
DevZone sign-ups are now live
Let’s talk specifics. So then, what do we get out of it? We get an overview of active and prospectus community developers, their interests, experience and contribution history (to both PINE64 and other projects). This will help us better understand our community development pool and the available talent. We frequently find ourselves with a handful of early prototype devices and spend countless hours figuring out who would be the right fit for them. Development units sometimes end up in the hands of people who do not have the right skillset, are already working on a different device or are otherwise occupied. At the same time we overlook developers who would be an ideal fit. We have a backlog of ideas stalled due to the component shortages, and would like to get the show back on the road as soon as the world reverts to normal. We believe the DevZone will be principal in getting the wheels spinning once production of new devices is viable once again.
And what do you get out of it? If you’re granted developer’s status you’ll receive access to a knowledge and information sharing platform with early prototype data, pre-release schematics, development resources and an overview of ongoing development. Information disseminated on the platform will include things we don’t usually share publicly (not because they are secret per se, but rather because prototype details can create disinformation or give false impressions of the end-product). The system will give an overview of who’s working on what, provide a direct line to other developers and a guarantee that we see your feedback. You may also be invited to work closer with us on upcoming devices by reviewing prototypes; we’ll be choosing from this pool only. Lastly, we’ll label you as a developer on our platforms (where applicable), thereby making it easy for end-users and other developers to identify you. In time the DevZone will grow to encompass additional functionality, be it additional cooperation tools, an internal chat or something completely different. We’ll settle on what further features are needed together.
As I already mentioned, the portal is currently under construction and we presently don’t have a timeframe for launch. But if you are interested in participating in development on PINE64 hardware then I encourage you to register today – we’ll get back to you once the system is live.
Let me start with really good news for those of you waiting (im)patiently to get their hands on a PineTime: I’ve just learned that the production of the new batch of PineTime is going well and, if everything goes according to plan, then single sealed PineTime units should be available when this post goes live! These PineTimes are flashed with the latest versions of the bootloader of and InfiniTime, so that you’ll be able to get the most out of your watch the moment you receive it.
As we announced last month, the factory was waiting for this release to start the production of the new batch of PineTimes. As a reminder: the ongoing component shortage forced PINE64 to use a slightly different accelerometer for this new batch, since the original one was not available anymore, and InfiniTime needed to add support for this new chip to ensure features like step counting and wake on wrist rotation would work as expected.
The 1.2.0 version of the firmware includes a new metronome application, improves the stopwatch app and brings about many improvements and bug fixes. We’ve also worked on memory optimizations which freed up quite a lot of space in both RAM and ROM memories. This will allow us to ensure that we’ll be able to add more features to the firmware in the future. As always, InfiniTime developers didn’t stop at this, and we are already working on the next release that will bring, among other things, a new stylish watchface!
Left: metronome // Right: stopwatch
In other PineTime news, WaspOS has seen a few improvements merged recently in the form of an early sports app which currently lacks polish cosmetically, a watch face chooser which shows a full screen preview of various watch faces to let the user decide which one to use, new icons, and bug fixes. Further, of note recently a pull request has been created that aims to add an advanced alarm application (much more featureful than the existing alarm app).
This month, I’m really happy to highlight a newcomer to the world of PineTime firmwares: Malila by Maarten de Jong (Arteeh). Maarten have previously been working on UI designs, a flasher app and a GTK companion app for WaspOS. His latest project, Malila, is no less than a fully-featured firmware for the PineTime based on RIOT OS. Here’s the announcement he made earlier in the chat rooms:
Hi community, I wanted to share something I’m working on: https://github.com/arteeh/malila
It’s a simple firmware for the Pinetime, based on RIOT. It doesn’t have any functionality, and it doesn’t support the bootloader yet, so as an end user don’t expect anything from it just yet 🙂
I started working on this to experiment with ways to fight the 8hz refresh rate bottleneck on the display. What I have right now is the following: A grayscale (2 bits per pixel) graphics system with two buffers, which we can use to only send a color over SPI when the pixel we’re writing to isn’t already that color.
It’s grayscale because a full 16 bit (65536 colors) buffer would be 115kb of RAM, which won’t fit. 8 bit (256 colors) using 57kb might theoretically fit, but would not leave room for any other software.
Anyway, I just started doing some initial work on getting a font converter (.ttf file to c array) working, and next up I want to write the code that writes letters to the buffer.
Long shot, but eventually I would like my project to have the following features:
– A nice looking Gnome-style (Cantarell font, Gnome icons and symbols) UI
– Micropython support
– Support for all the hardware (touch, hearbeat, etc.) and a way for Python programs to interact with it
– 6LoWPAN networking over BLE (RIOT seems to support this, and Linux has a kernel module for it)
Check out the repo if you want 🙂
The project is still in its early stages, but it looks really ambitious and promising. For now, Maarten is focusing on the display driver and font rendering. Ultimately, Malila should look like the designs Maarten is working on in his PinetimeOS project:
Render of Malila PineTime firmware
Let’s wish Maarten best of luck!
The first topic of the month’s agenda is the PinePhone keyboard, which I know many of you are eagerly awaiting. Those of you who read previous community update blog entries will already know that we created two prototype iterations and have been ironing out existing issues these past 3 months. We’re now at a stage where we incorporated most, if not all, developer feedback concerning the keyboard’s electronics, chassis (including fit and finish refinements) and fine-tuned the membrane responsible for the feel of keystrokes. There is now also a fully open firmware for the keyboard thanks to Megi, which I am happy to report will ship with the keyboard by default. As you can probably tell from the above, we’re very close to being production-ready. However, since we recognize the importance of this peripheral, we therefore also want to get it right from the get-go, and have decided to create a final set of pre-production review units (they ought to ship out in less than 2 weeks time).This will allow for any last-minute tweaks ot the end product if need be. Granted everything goes according to plan and no issues are found with these final pre-production units, we will start production immediately after receiving a green light from developers.
Left: final (hopefully) revision of the keyboard membrane // Right: keyboard testing at factory
In other hardware news, final pre-production back cases for the PinePhone have just arrived from the factory. The fingerprint reader and wireless charging modules will be fitted into the cases and undergo functionality and physical endurance testing in the next few days. If it turns out that the cases fit well, function as expected and we can source the necessary components to produce them in scale, then you can expect production to commence shortly. The LoRa back case will have to wait a little longer as we still need a developer to bring up the LoRa chip’s functionality over the I2C protocol. If you’re someone who’s keen on having a go at it then make sure to reach out to us in the comments section. Given current progress, we may see the back cases introduced at the same time as the PinePhone keyboard. I’ll write a dedicated post about the back cases once production starts – stay tuned.
Left: LoRa back case electronics // Right: PinePhone unlocked using fingerprint reader
The big software news of this month is that the PinePhone is now capable of accelerated video playback. The device has, at least technically, long had the possibility of doing hardware accelerated video playback using the mainline Cedrus media driver (demonstrated last year by Megi) which renders video using the Allwinner A64’s onboard Video Processing Unit (not to be confused with the GPU). Shown once again this year by Brian Daniels, not only is it possible to get smooth hardware accelerated video playback using gstreamer in the command line, but it is also possible to write applications that can utilize gstreamer and it’s hardware decoding, such as the case with the new Clapper video player. The PinePhone can output 1080p at 30fps with ease using acceleration, exceeding the native resolution; this is, however, something that may prove useful for those seeking to dock their PinePhone for convergence. In order to get video decoding working, at least for now, you must build GStreamer manually; however once this work comes to stable releases of GStreamer you can expect distributions to start utilizing hardware video decoding out of the box.
Hardware accelerated video in Clapper – by Brian Daniels
In other news, there is now an Arch Linux ARM OS image featuring Plasma Mobile; this is something that many users have been interested in seeing for quite some time. The image features the newest Plasma Mobile UI (5.22) and joins the existing selection of Phosh and barebones installations – it can be downloaded from here!
The update schedule for the Plasma Mobile image is based on Plasma 5’s update schedule set out by the KDE team, which means that aside from bug fixes, there won’t be any new features added until the next major release is out. Aside from the addition of Plasma Mobile to the Arch roster, dni has made a pull request to the repository which adds SXMO as a UI option. We hope to see SXMO up and running soon, and a new OS image featuring this UI will be released by the end of July. Lastly, the community build of Arch Linux Arm has fixed a high priority security vulnerability last month – so make sure to update your installation if you have not done so recently.
Arch Linux with Plasma Mobile – by Danct12
Lastly, the postmarketOS build for the PinePhone has seen a number of improvements. The biggest one being the recent v21.06 stable release, which brought updated software for users on the stable branches of postmarketOS with Phosh 0.11 (and Phosh 0.12 in edge). The postmarketOS build also received quick suspend/resume support for the modem for those running the edge branch; this should increase the reliability of calls and mobile data on the phone. If you wish to give postmarketOS a go, the newest OS images can be downloaded from their website; you get a choice of three UI options: Phosh, Plasma Mobile and SXMO.
With Quartz64 now available in the Pine Store and shipping to early adopters, I will focus on the software progress this month. Those of you who wish to learn more about the hardware, please read last month’s community update, in which I outlined, in considerable detail, the current and future Quartz-line offerings. Earlier this week I spoke with pgwipeout who laid the foundations for mainline Linux on the RK3566 SoC used in Quartz64, and he briefed me on the progress made. The official device tree has now landed in mainline Linux alongside a number of nodes. Presently a method for handling the RK3566 and RK3568 split is being devised – once a solution is found, developers will be submitting a number of RK3566-specific patches upstream. Among them will be the basic device tree for the Quartz64 model-A as well as the supported, but missing in mainline, nodes enabling various additional functionality. One key bit presently missing, but in development, is the VOP-V2 display driver that will eventually allow for display output.
One of the first Quartz64 model-A boards in the wild – also, we will hold you to your word Chris 😉
Other key missing components are: the audio driver, e-ink and battery charging support. The audio and battery charging functionality will take time but are likely to be incorporated into the Linux kernel in a timely fashion. E-ink display functionality, on the other hand, is likely to prove a major challenge. From an end-user’s perspective, the display and audio drivers are obviously the most important in terms of basic usability, and there is a good indication that both will be the first missing pieces to be added. Rockchip is also actively working on preparing u-boot support for the RK3566 and has pushed downstream patches to RAM init as well as added RK3566 support in mkimage program. A complete overview of the development status can be found on Quartz64 Wiki page. Given how young the SoC is, and the short amount of time the Quartz64 model-A has been available, I think it is fair to say that development is progressing at a blistering speed.
Manjaro running on the Quartz64 model-A – by Spikerguy
For those of you who wish to contribute to development at this early stage, there are now multiple operating systems to toy around with. Pgwipeout made a buildroot recovery image and a Debian installer, both of which pack all currently available functionality and the newest commits. Since earlier this month the Quartz64 is also able to boot Manjaro Linux, which features the same kernel and patches as buildroot and Debian, and therefore also all currently available functionality. The Manjaro Linux OS image is plug-and-play, which means that you flash it to a SD card (or eMMC) and it’ll boot up just as you’d expect. Given current software maturity of the Quartz64, I suspect it may take a little longer to see other partner projects port their operating systems to the platform, but once baseline functionality is fleshed out I am sure we’ll see wide-range support for the platform.
We are happy to announce that another device will be joining the PineDio family on launch day: the PineDio Stack. The Stack is effectively an all-in-one development platform, featuring the Buffalo BL604 RISC-V SoC (which is effectively identical to the BL602 that is currently undergoing open-sourcing as part of the nutcracker challenge, but with more available GPIO) and a SX1262 LoRa module by our friends at RAKWireless. The Stack will allow you to connect peripherals via exposed GPIO, will connect to a small LCD panel, and the entire PCB can be housed inside a small sleek plastic case. It will also be possible to operate the PineDio Stack solely from battery – it shares the PineTime’s battery charging circuit.
PineDio Stack assembled PCBs
While we envisioned the PineDio Stack as a development platform for the BL602/4 and SX1262, it can also be used for a variety of other purposes. It will obviously be up to developers’ and end-users’ imagination what the device is best suited for, but we have already started experimenting with a number of different applications that use the Stack as a LoRa end-node and use of voltaic solar panels in conjunction with batteries. We know that wireless solar-powered operation for LoRa end-nodes is a highly desirable feature and therefore also exploring an in-house solution for such a setup. I am including some of our tests below – please consider them very early tests; we will likely have a default voltaic solar panel available in the Pine Store for you to pick up once the Stack enters production. Developer units will be available late this month.
Left: Stack powered by solar energy // Right: Stack inside voltaic panel case fitted with a 18650 battery
In other LoRa news: the PineDio gateway is still awaiting certification as we’re missing a part, which we’re told will be delivered in 5 weeks time. As soon as the part (a crypto chip) is delivered we’ll move to certify the gateway and proceed with its production. As for the PinePhone LoRa back case – the electronics and the back case itself are completed and, at least in theory, ready to go. That said, we’re missing the I2C driver that would make the LoRa back case work with the PinePhone. We are currently talking to a handful of prospectus developers who could be up to the challenge to bring up the required driver – if you’re someone interested in this, make sure to let us know in the comments section below.
That is it for this month. I hope you’re somewhere nice and warm and enjoying the weather!
26 responses to “July update: community developers portal”
I’m eager to try Clapper. I never understood the point of a full-ish keyboard too small to touchtype on, but ok. I have a Ferris 34-key split columnar keyboard to use with my Pine64 devices in a beautiful marriage of ARM hardware, switches soldered on with my pinecil. To me a small staggered qwerty keyboard is about as useful and relevant as a morse code tapper, but you all have fun. the other forthcoming back cover is something I might buy. PBP & PP continue to be my daily drivers and breadwinners.
If you want to try the accelerated Clapper, one way to do so is the flatpak manifest I created:
https://framagit.org/1peter10/flatpaks
Is there any information about the availability of Pinebook Pro and Pinetab?
There is a dedicated page for shipment, stock and availability info: https://www.pine64.org/availability-and-shipping-status/
I would love to see the process for building gstreamer. I have attempted it quite a few times over the past few days, but haven’t (yet) been able to get meson to play nice.
SXMO has potential depending on the eyes that look at it, of course it would be good to add some changes to that system keyboard
No news about sleep/resume functionality on pinebook pro?
I find this the one issue which prevents pinebook being a good product.
I do not understand why this doesn’t get any attention, and stops me from wanting to purchase any future products. Forums have been helpful on some issues, but if there is a current fix for s3 sleep, I cannot find it.
which distribution?
Any, I think. If you know of any current distribution in which s3 sleep and resume works, please let me know. I am sure many people would like to know.
FYI I am running Manjaro arm XFCE
There has actually been some progress by a dedicated volunteer that happens to work at ARM. There is a patch submitted to TF-A, but it has taken a while to get reviewed.
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/9616/1..5
Once that patch lands and a new version of TF-A is release, I think all you will need to do is rebuild U-Boot with the new TF-A and flash it.
I have been meaning to try it, but have not had much of a chance lately.
Clear clean instructions on “how to rebuild U-Boot with the new TF-A and flash it” would be great, because I have not understood how to do this yet.
PineDio is great idea.PineDio is a great project and I can see it starting to look like something already. Unfortunately there is still no decent connector for an external antenna. The wavelength is over 60cm.
To get such an antenna to sync properly you need tools that usually have different connectors. If we would like the antenna to be in a slightly different place than the device, which is normal in installations on buildings, this is also a problem.
But you are sensational in your approach to power. Please think about people living in Poland. Not everywhere are tropical heat and the battery does not work well below 20 degrees Celsius. Plus cooling (heat sinks in summer). So some installations will need 3 cells and some half.
———–
PineDio to świetny projekt i widzę, że zaczyna to już jakoś wyglądać. Niestety nadal nie ma porządnego złącza do zewnętrznej anteny. Długość fali to ponad 60cm.
Aby taka antena była dobrze zsynchronizowana potrzeba narzędzi, które mają zazwyczaj inne wtyki. Jeśli chcielibyśmy by antena była trochę w innym miejscu niż urządzenie co jest normalne w instalacjach na budynkach też jest to problem.
Za to rewelacyjnie podchodzicie do kwestii zasilania. prosze pomyślcie o ludziach mieszkających w Polsce. Nie wszędzie są tropikalne upały, a akumulator słabo działa poniżej 20 stopni Celsiusza. Do tego chłodzenie (radiatory w lecie). Zatem niektóre instalacje będą potrzebować 3 ogniw a niektóre połowy.
Any plans on implementing the EU’s IOSS (Import One-Stop Shop)?
I found information about that on the EU portal and thought to link it here too:
“ALL YOU NEED TO KNOW ABOUT THE IMPORT ONE-STOP SHOP (IOSS)”
https://ec.europa.eu/taxation_customs/ioss_en
“What is the IOSS for?
The IOSS allows suppliers and electronic interfaces selling imported goods to buyers in the EU to collect, declare and pay the VAT to the tax authorities, instead of making the buyer pay the VAT at the moment the goods are imported into the EU as it was previously the case (for products over 22 EUR).”
There is a limitation in using IOSS: the value of goods shipped must be under 150 EUR (probably including the transport costs).
Maybe with working e-ink on Quartz64, the next phone could be a Linux replacement to the now bankrupt Yotaphone: LCD primary display and e-ink backside display for clock/notifications, turn-by-turn navigation and countless other ideas.
I would very much like a phone with only an e-ink display. For me, the PinePhone is a useful information accessing mobile tool. I use it seldom as an entertainment tool. So I don’t need high video refresh rates or even colors, but I need easily readability. An e-ink display works great outdoors with plenty of light, and it must have a frontlight (I think it is called) to be usable in the dark. E-ink is perfect for a mobile device since it is so energy efficient.
The idea of a PinePhone with an eInk-Display is exactly what I am craving for!! The advantages are of course the battery and eye-friendly use (believe me, frontlight is so much better as nothing flashes your eyes). It would marry well with the slow(er) performance of the PinePhone, as eInk ePaper displays have a slow refresh rate. The community could adapt Linux to work well with this kind of display. Btw, there are even color displays, e.g. DES slurry or eInk Kaleido.
e-ink is not good for phone, better way is mirasol or oil technology
it looks like sxmo on Arch is stalled because Arch and Alpine are drastically different. Arch uses coreutils, and Alpine uses busybox for one, which presents some problems, but furthermore, the buttons aren’t working correctly from what I’ve read. the power button isn’t working at all, and needs to be disabled at present, and the other buttons seem to be logging everyone out whenever they’re pushed.
it’s too bad, I love sxmo, and I prefer pacman/auracle to apk which seems to be a poorly implemented apt clone. the only strength apk has over apt is that you can pass -U while upgrading to upgrade in one command. aside from that, it’s really cumbersome, and a lot of useful functions aren’t documented. other functions that are required don’t even appear to be written into it. it’s sort of a mess.
So much awesome news!
I can’t wait for the pinedio gateway
and I too !
nice cluster with rpi , meybe anyone show better 1U with pine?
https://hackaday.com/2021/07/21/raspberry-pi-server-cluster-in-1u-rack-mount-case/
Looking forward to working on the bugs in a Quartz build or two. I accidentally bought 2 so I guess I can work on a couple at a time.
The PineDio should be a lot of fun. Maybe I can find a fellow geek who lives close enough to test this. Any idea on practical distance ranges yet? I can mess with it at work but it’d be cool to test them at a distance, maybe hiking or similar.
Will pick up a sealed pinetime soon, can fiddle with the older one and use the newer firmware and more mature procedures to use more regularly. Is there an approximate IPX rating? good in the rain, but not submerged, maybe. I have bought almost everything else so I may wait for something new on the store before picking up a time, which I assume will be a regular item unless there is a shortage or supply chain issue. I have seen about 3 days runtime on a charge on my dev version, not used to wearing watched but I really would like to contribute to testing or if I can figure out something simple, contribute to the software.
where update?
You were a little early 😉
https://www.pine64.org/2021/08/15/introducing-the-pinenote/
I’m about to get into SX126x development and I’m putting together a little project using one over plain SPI via Linux’s devspi stack and some Python in userspace. What kind of “driver” exactly are you looking for here? Do you want the kernel to run the chip and expose some kind of LoRa API to userspace instead of just an SPI device? Is the Linux LoRa subsystem done and in the Pinephone kernels? Because if I can drive the chip from Python over SPI I’m sure I can drive it from Python over I2C.