[{"categories":null,"contents":"The PinePhone is not a regular phone and you might not get the latest and greatest hardware and this years\u0026rsquo; newest innovation. You will get a device with good mainline support with a great community behind it.\nState of the software First things first, the PinePhone is aimed solely at early adopters - more specifically, the units are solely intended to find their way into the hands of users with extensive operating system experience.\nBear in mind that the software for these smartphones is very early, with most of the software being in alpha or beta state. That’s especially also the case for scalability of applications, their availability and practicability, any hardware function implementations and the firmware. The software is provided as is. There is no warranty for the software, not even for merchantability or fitness for a particular purpose.\nIf you have any questions regarding the current state of the software or of specific features working, please don’t hesitate to ask in the community chat (see Main Page)!\nHelp and support Still have any questions regarding software, shipping, or ordering after reading this wiki? Please don’t hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See Main Page.\nPlease keep in mind that PINE64 is not like a regular company (see the PINE64 philosophy) and that support resources are limited - the best way to get support quickly is to ask in the community chat! Please only contact the PINE64 support directly if questions couldn’t be solved via the community chat or this wiki.\n","permalink":"/documentation/PinePhone/Introduction/","tags":null,"title":"Introduction"},{"categories":null,"contents":" A protection foil isolates the battery for the shipping.\nWhen shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery will not charge or boot until it is removed and the battery is connected again.\nNote To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery. The PinePhone’s SIM slot only accepts a micro-SIM, please do not insert a nano-SIM without an adapter and make sure that the nano-SIM does not get released from its adapter. The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot.\nNote Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them! The microSD belongs in the upper slot, the micro-SIM in the lower slot.\nAn adapter from a nano to a micro-SIM might be included under tape in the camera notch of the phone’s packaging. Some nano-SIMs will not fit firmly into that adapter that comes with the PinePhone and if the included adapter is used without a well-fitting nano-SIM, the contact pins might get damaged. In that case it is highly recommended to acquire a better fitting adapter.\n","permalink":"/documentation/PinePhone/Getting_started/","tags":null,"title":"Getting started"},{"categories":["community","news","pine64-community","pinephone","pinephonepro"],"contents":"\nTable of contents Full PinePhone 3D Files Released PinePhone2? JFs 3D Printed Back Cover Do you have something to share? Contact Community PineStore Full PinePhone 3D Files Released This week PineStore has released the full 3D file for the PinePhone/PinePhone Pro. This is different than the file only containing the back cover, which does not include the buttons or the internal and external frame.\nThis opens up the possibility of self repairing some PinePhone components using 3D printers along with creating custom parts.\nThis may be considered as a final hurrah for this generation of the PinePhone from PineStore. Though this does not however mark the end of the devices themselves. They are still going, still supported by many mobile Linux projects and still one of the most open mobile Linux hardware platforms you can find. Let\u0026rsquo;s keep them going for many years to come!\nThe 3D file can be found on the PineStore server and the \u0026ldquo;PinePhone board information, schematics and certifications\u0026rdquo; section of the wiki.\nhttps://files.pine64.org/doc/PinePhone/PinePhone_and_Pro_case_asm.stp (direct link) https://wiki.pine64.org/wiki/PinePhone PinePhone2? This has been said previously in another blog post but many continue to inquire about a successor to the first PinePhone line.\nIt is not off the cards, but the straight answer is not right now.\nThe founder of PineStore has discussed how the PinePhone was always meant as a development platform to help bring the at the time stagnant mobile Linux space up. He thinks that they have done their job as the focus has moved on to porting Linux to Android phones that are much cheaper and have more performance.\nIt would be a big financial risk, where PineStore would lose a lot of money developing the device and with the current market there, is no SOC that currently fits the solution.\nBut coming back to the beginning, this does not mean \u0026ldquo;no\u0026rdquo;. But when the time is right, this decision may change.\nJFs 3D Printed Back Cover Community member JF has already 3D printed a back case for their PinePhone using this 3D model release. Here are some photos he shared.\nDo you have something to share? Do you have news to share with the community? You can have your news posted on this blog by heading over to this tutorial and following the template. All community updates are written in markdown which you can learn how to write here.\nIf you get stuck, feel free to ask the folks in chat by finding your respective chat platform at https://pine64.org/community/.\nContact Community Feel free to contact me if you have any concerns about community related topics. This can be about getting project support, sharing project updates, prolonged wait times for support from PineStore (anything after 1-2 weeks) and any general feedback that could help improve the community.\nCommunity manager: camden.b@pine64.org\nPineStore If you have quality control issues with your device once you receive it, don\u0026rsquo;t wait, contact PineStore support.\nFor general queries and information from the Pine Store: info@pine64.org For queries regarding support from the Pine Store: support@pine64.org For sales/wholesale related questions: sales@pine64.org If you have hardware defects or any other hardware issues to go: https://pine64.zohodesk.com/portal/en/home ","permalink":"/2026/07/25/pinephone3dfiles_2026/","tags":null,"title":"Full PinePhone 3D File Released"},{"categories":["community","news","pine64-community"],"contents":"\nTable of contents Whats been going on recently? PineVoice PineTime/PineTime Pro LoRa? (Left-handed operational Radio authority, obviously) Important recent community updates: Do you have something to share? Contact Community PineStore Whats been going on recently? Hello everyone, we wanted to do a quick update on what\u0026rsquo;s been happening recently. Life has been pretty busy but there\u0026rsquo;s lots of nice things happening in the background that we\u0026rsquo;d like to share.\nPineVoice The PineVoice Home Assistant speaker (formally PineVox) is in its final stages. Production begins. Further on this, there will be limited bundle with this device which will include a PineVoice, Zigbee dongle, power supply and two matter modules. Pair it with a SBC of choice and run your Home Assistant instance locally!\nPineTime/PineTime Pro The current PineTime LCD is EOL and a new one is replacing it, though it is essentially the same display. These will be shipping in the next PineTime batch.\nNew PineTime Pro samples have been received by developers. Shiny!\nLoRa? (Left-handed operational Radio authority, obviously) The PineDio USB LoRa Adapter is at the focus of a new effort to begin progress on potential new LoRa devices. MeshCore is the current protocol target for the USB LoRa Adapter along with help from the pyMC_core library project.\nThe current problem with the device is that the crystal oscillator is heating up too much and can cause clock frequency drifting instability. In a nutshell that means your messages come out garbled. This may eventually be fixed with a TXCO (Temperature-Compensated Crystal Oscillator) to maintain a stable clock frequency.\nImportant recent community updates: DanctNIX PineTab2 updates (including factory image)\nAdam Piggz: PinePhone, PinePhone Pro, PineTab2 all updated to kernel 7.0, and improved USB config. Zypper ref and dup to update.\nmachaddr@mastodon.sdf.org: with their new Gentoo PineTab-V image\nDo you have something to share? Do you have news to share with the community? You can have your news posted on this blog by heading over to this tutorial and following the template. All community updates are written in markdown which you can learn how to write here.\nIf you get stuck, feel free to ask the folks in chat by finding your respective chat platform at https://pine64.org/community/.\nContact Community Feel free to contact me if you have any concerns about community related topics. This can be about getting project support, sharing project updates, prolonged wait times for support from PineStore (anything after 1-2 weeks) and any general feedback that could help improve the community.\nCommunity manager: camden.b@pine64.org\nPineStore If you have quality control issues with your device once you receive it, don\u0026rsquo;t wait, contact PineStore support.\nFor general queries and information from the Pine Store: info@pine64.org For queries regarding support from the Pine Store: support@pine64.org For sales/wholesale related questions: sales@pine64.org If you have hardware defects or any other hardware issues to go: https://pine64.zohodesk.com/portal/en/home ","permalink":"/2026/05/18/may_2026_quick/","tags":["pinetime","pinedio","pinevoice","pinephone"],"title":"Quick update: May 2026"},{"categories":["community","news","pine64-community"],"contents":"\nHey everyone, we\u0026rsquo;d like to make a public disclosure to the community about a product currently selling on the PineStore website (pine64.com).\nThe current Desktop PinePower V2 batch has an issue where in some situations the USB-C ports will report \u0026ldquo;0V\u0026rdquo; when there is obviously something attached. In reality it is actually outputting the correct voltage.\nThis has been fixed for future batches, but the current batch still has stock available. There is no fix available for affected Desktop PinePower V2 batches as the MCU can only be flashed at the factory. We have no ETA when the fixed batch will start production as this depends on the rest of the buggered batch being sold. We\u0026rsquo;ll let you all know when the fixed ones hit the store.\nAnd please don\u0026rsquo;t open your PinePower devices as they\u0026rsquo;re high voltage power supplies, which can lead to serious risks.\n","permalink":"/2026/05/12/shocking_disclosure/","tags":["pinepower"],"title":"Shocking disclosure, 20 volts to be exact"},{"categories":["community","news","pine64-community","pinetime","pinetime-pro"],"contents":"\nTable of contents Introducing the PineTime Pro Why \u0026ldquo;Pro\u0026rdquo; and not \u0026ldquo;PineTime 2\u0026rdquo; What makes it \u0026ldquo;Pro\u0026rdquo; A long road to get here Recent progress What about software? What happens next? Do you have something to share? Contact Community PineStore Introducing the PineTime Pro The PineTime Pro was officially announced at FOSDEM26 on the Pine64 stand. The demo was a bit modest (more on that later on), but we were delighted to showcase the first prototype of the \u0026ldquo;next generation PineTime\u0026rdquo; along with a demo running on a development board!\nWe also mentioned the PineTime Pro in the FOSDEM 2026 Update blog post. In this blog post, we would like to provide a more in-depth look at the PineTime Pro.\nWhy \u0026ldquo;Pro\u0026rdquo; and not \u0026ldquo;PineTime 2\u0026rdquo; The PineTime project started in October 2019, that\u0026rsquo;s more than 6 years ago! Needless to say, the PineTime has been a great success. The community has been very active in developing firmware for the device, companion apps, tools and more. And, according to PineStore, it sells very well.\nThe reason the PineTime Pro isn\u0026rsquo;t called the PineTime 2 is because it\u0026rsquo;s not meant to replace the original PineTime. The original watch still has a lot going for it: it is simple, hackable, efficient and already supported by great community projects like InfiniTime and WaspOS. It will continue production alongside this new model.\nThe PineTime Pro should be seen as a more powerful, more feature-rich sibling rather than a direct successor. If the original PineTime is a solid open smartwatch platform, the PineTime Pro is our attempt to push that idea much further with new and improved components.\nWhat makes it \u0026ldquo;Pro\u0026rdquo; Compared to the \u0026ldquo;OG\u0026rdquo; PineTime, the PineTime Pro brings a significant hardware upgrade.\nAt its core is a dual-core Cortex-M33 SoC, with one application core running at up to 200 MHz and a dedicated Bluetooth core. It also comes with 800 KB of internal SRAM and 8 MB of PSRAM.\nAround that MCU, the hardware currently includes:\nBluetooth 5.2 - Classic (BR/EDR) \u0026amp; Low Energy A 410×502 AMOLED display with touch support A digital crown that also acts as an extra button GPS A heart rate sensor with blood oxygen measurement capability Improved accelerometer -\u0026gt; full 6D Interial Measurement Unit An I²C battery charger, which can be configured and monitored by the MCU External QSPI 8MB flash memory Microphone and speaker A vibration motor A 4-pin connector for power and debug/programming, with configurable pins for serial output or SWD Yes, it\u0026rsquo;s still an embedded platform, but much more powerful. Here is a quick comparison between the PineTime and the PineTime Pro:\nOG PineTime PineTimePro MCU 1x ARM Cortex-M4 core 2x ARM Cortex-M33 cores RAM 64 KB SRAM 800KB SRAM + 8MB PSRAM Flash 512KB internal + 4MB SPI 8MB SQPI Display 240x240px, 1.3\u0026quot; 410x502px, 2.13\u0026quot; Sensors Heart rate + accelerometer heart rate + blood oxygen sensor, 6D IMU GPS No Yes Debug port Internal Available on external pin Altogether, this opens the door to much more ambitious software (like PebbleOS ;) ) and use cases than what is practical on the original PineTime: fast, smooth and rich UI, fitness tracker, localization and tracking, external apps and watch faces and more!\nA long road to get here The PineTime Pro has been in discussion for quite a while. Community members including JF, Gamiee and Ralim have been exploring the idea for a long time, and from the beginning, one thing was clear: choosing the right MCU would make or break the project.\nEarlier iterations were based on a RISC-V MCU. In fact, the demo shown at FOSDEM 2024 was based on that platform. While the idea was exciting, we ultimately ran into issues with power consumption along with the quality of the available documentation and SDK. Those limitations made it difficult to see a good long-term path forward.\nThings became much more concrete when PineStore started collaborating with a large smartwatch manufacturer in China that had developed its own chip. That collaboration has been very valuable so far: PineStore and the community have been working together on the hardware design, and documentation and SDK materials have been shared to help software development move forward. All of these resources will also be available to the community once the device enters production.\nAlong the way, we explored a few extra ideas too. For example, we looked at adding LoRa, but that introduced major challenges in terms of PCB space and RF design. A light sensor was also considered, but dropped it for similar reasons. On the other hand, adding a speaker and microphone turned out to be relatively easy, so those ended up becoming a nice bonus.\nRecent progress During FOSDEM 2025, we received the first two development boards based on the new Cortex-M33 platform. Throughout 2025, PineStore and community members, especially Gamiee and Ralim, continued reviewing the hardware design while JF was experimenting with the development board and the SDK.\nToward the end of 2025, the first two actual watch prototypes were sent to Gamiee and JF. Unfortunately, those boards had hardware issues that left the SWD port (the programming and debugging port) non-functional, which made software bring-up much more difficult than expected.\nA second batch of prototypes arrived just before FOSDEM this year. We had hoped to show them running on the Pine64 stand, but another hardware issue got in the way: the flash memory was not working properly, so the demo had to run on the development board instead of the actual watch hardware.\nThat said, progress is still very real. After several rounds of review between PineStore and the community, a third hardware revision is expected at the beginning of April. We’re optimistic that this revision will finally resolve the remaining blockers and let software development ramp up properly.\nWhat about software? Just like the original PineTime, we expect the community to enjoy this new device and develop many projects on top of it!\nThe good news is that developers from both InfiniTime and WaspOS are already involved, which gives the platform a strong starting point. The PineTime Pro is exciting not just because it is new hardware, but because it offers much more room for experimentation. Features that are extremely challenging to fit into the original PineTime due to resource constraints may become practical here.\nCan it run Doom? Most probably, and I guess someone will take the challenge and make it happen!\nOn the InfiniTime side, the original PineTime is not being abandoned. InfiniTime is already a fairly mature project, and it will continue to exist. And I guess the same is true for Wasp-OS.\nBut realistically, the PineTime Pro is likely to keep developers busy for quite some time, simply because it creates so many new possibilities.\nRight now, JF is mostly focused on low-level experiments and validation, with the goal of getting basic drivers and a demo application working as soon as possible. Gamiee is also expected to help with OpenOCD integration once he wraps up work on the PineVoice.\nWhat happens next? The next major milestone is simple: get the new hardware revision in hand, confirm that the remaining issues are solved, and continue pushing software bring-up forward.\nThere is still work ahead, and we are not pretending otherwise. But after a long period of exploration and hardware iteration, the PineTime Pro is finally starting to feel real.\nWe’re looking forward to sharing more as development continues.\nDo you have something to share? Do you have news to share with the community? You can have your news posted on this blog by heading over to this tutorial and following the template. All community updates are written in markdown which you can learn how to write here.\nIf you get stuck, feel free to ask the folks in chat by finding your respective chat platform at https://pine64.org/community/.\nContact Community Feel free to contact me if you have any concerns about community related topics. This can be about getting project support, sharing project updates, concern about prolonged wait times for support from PineStore (anything after 1-2 weeks) and any general feedback that could help improve the community.\nCommunity manager: camden.b@pine64.org\nPineStore If you have quality control issues with your device once you receive it, don\u0026rsquo;t wait, contact PineStore support.\nFor general queries and information from the Pine Store: info@pine64.org For queries regarding support from the Pine Store: support@pine64.org For sales/wholesale related questions: sales@pine64.org If you have hardware defects or any other hardware issues to go: https://pine64.zohodesk.com/portal/en/home ","permalink":"/2026/03/28/pinetime_march_2026/","tags":["pinetime-pro","pinetime"],"title":"Introduction to the PineTime Pro"},{"categories":["community","news","pine64-community"],"contents":"\nTable of contents Housekeeping What happened at FOSDEM 2026 Demos PineNote PineTab 2 DRAM shortage impact PineTime Pro Future of community editions Why can’t community editions exist for already released devices? Challenges Where is the PinePhone 2? To conclude Do you have something to share? Contact Community PineStore Housekeeping Hey everyone! So long no talk. It’s been a long time since a proper community update, but rest assured a \u0026ldquo;full size update\u0026rdquo; update is coming sometime in April (Charlie the Pinecorn returns!).\nWe are still planning to migrate to Codeberg for primary git hosting and committing to the move from mediawiki to our documentation site created by community member Funeral. We hope to make this happen sometime this year.\nAnd a message to the team over at Genode, yes I did read your book :) - Caffeine\nWhat happened at FOSDEM 2026 FOSDEM 2026 was a very productive meetup for members of the PINE64 Community, aside from the occasional shenanigans. We had the opportunity to work on the PineVoice (formally PineVox) and PineTime Pro in person which helped push forward bring-up. There were additional discussions on potential new products and the effect of the DRAM chip shortage.\nDemos PineNote The PineNote was shown off at FOSDEM with a few demos featuring hrdl’s Arch image and a pre-release image of QuillOS using hrdl’s kernel tree. With a massive thanks to Tom.K, Phantomas and hrdl for staying around and helping demo with his PineNote. Some demos included smoothly playing videos, playing doom (you had to be there to believe it!) along with its capabilities as an actual ebook reader.\nPineTab 2 Danct12 put together an image for FOSDEM with camera and support for h264 video decoding. The demo also included a copy of big buck bunny and a razor1911 demo.\nDRAM shortage impact Currently the DRAM shortage will impact the production of devices like the Pinetab2, PineNote and PinePhone. PineStore founder TL Lim has stated that he doesn’t wish to increase the price of hardware significantly so production is halted for the time being. Any remaining stock will be sold and that will be it for now.\nThis will not impact devices such as the PineTime, PineBuds, Pinecil or PineVoice.\nPineTime Pro The new device is an improvement on the original with an AMOLED display, GPS, a custom chip, a digital crown which also features an extra button and new sensors including a blood oxygen sensor. Power to individual components can be cut unlike the non pro watch which will improve battery life.\nThere has been discussion on if we do fund raising by baking in a small offset cost into the devices; or if we do a service with costs for fund raising. This decision has not been made yet.\nMore information to come!\nFuture of community editions Discussions were had concerning compensation and payment for work of developers working on PineStore devices.\nWhy can’t community editions exist for already released devices? Creating a community edition device requires PineStore to create a new SKU for a device, this means that the community needs to agree on purchasing a device at an extra cost as the price of the device will go up (which represents the portion that is going to be donated).\nDevices like the PineNote or PineTab 2 are likely not going to get community editions due to this, and we’re very much at PineStores discretion in this regard. As long as a price is organized before a new device reaches production, it is okay. But this process can be difficult if a bulk of the development happens after release hardware production begins.\nChallenges Donations are messy, sending money overseas is messy, deciding who gets how much is messy. It’s a mess.\nTax: Taxes can significantly reduce the amount of funds developers end up receiving. Which makes everyone unhappy. Donations to groups of individuals rather than projects: For the PinePhone community edition devices donations were sent to projects. In the case for some devices where the factory firmware was made possible by the contributions of a number of individuals (not under a project), the problem arises of where to send donation funds. Fund allocation: How are funds shared between individuals and who actually gets a share (the people who worked on the shipped firmware, what about the people who worked on components like the kernel that the firmware relies upon?). In this situation the individuals would have to agree on how funds are split. Where is the PinePhone 2? The PinePhone 2 is a common topic within the community and was a hot discussion at FOSDEM in 2026. Aside from the current chip shortage, PineStore has determined that it is too high of a financial risk to release another phone. This is because the interest of the mobile Linux community has shifted to porting cheaper and more powerful Android devices to mobile Linux projects such as Sailfish and PostmarketOS.\nThis will inevitably create a gap in the Linux phone space as the PinePhone is one of the few devices that a user can flash their own bootloader and modem firmware.\nHowever, potential components for another phone were discussed during the trip. A RK3572/6 as a potential SOC and a RedCap 5G modem which has an identical command set to the Quectel EG25-G modem found in the PinePhone/Pro. Though note none of these components are locked in for an actual device.\nSo to conclude, the PinePhone 2 is currently in limbo for a number of reasons (financial riskiness, DRAM shortage, old Android devices make cheaper and more powerful Linux phones). But hopefully PineStore will eventually bring out another model.\nTo conclude FOSDEM was a great turnout this year and we had a lot of fun meeting and catching up with people in the FOSS space. Thanks to everyone who came to FOSDEM and to those who came to say hi at our stand. Thanks to those who stuck around the stand with us, it made it a lot more enjoyable having you guys around. And of course, A special thanks to TL Lim from PineStore for sponsoring a group of our community members to visit FOSDEM.\nIf all things go alright (touch wood), a full community update should be out sometime in April (time/motivation permitting :P). See you in a tick!\nDo you have something to share? Do you have news to share with the community? You can have your news posted on this blog by heading over to this tutorial and following the template. All community updates are written in markdown which you can learn how to write here.\nIf you get stuck, feel free to ask the folks in chat by finding your respective chat platform at https://pine64.org/community/.\nContact Community Feel free to contact me if you have any concerns about community related topics. This can be about getting project support, sharing project updates, concern about prolonged wait times for support from PineStore (anything after 1-2 weeks) and any general feedback that could help improve the community.\nCommunity manager: camden.b@pine64.org\nPineStore If you have quality control issues with your device once you receive it, don\u0026rsquo;t wait, contact PineStore support.\nFor general queries and information from the Pine Store: info@pine64.org For queries regarding support from the Pine Store: support@pine64.org For sales/wholesale related questions: sales@pine64.org If you have hardware defects or any other hardware issues to go: https://pine64.zohodesk.com/portal/en/home ","permalink":"/2026/03/24/march_2026_fosdem/","tags":["pinenote","pinetab2","fosdem","pinetimepro"],"title":"FOSDEM 2026 Update"},{"categories":["community","news","pine64-community"],"contents":"\nTable of contents The Movuan project Installing Movuan What is Devuan? Future goals and contributing Do you have something to share? Contact Community PineStore The Movuan project The Movuan project was started by community member lxb and announced in a forum post as an alternative to mobile distributions using the systemd init system. Thanks to being forked from Mobian, the project makes use of modified Mobian debos to build it\u0026rsquo;s images.\nOne of the modifications that lxb makes is an optional script which can customize a Movuan image to install extra software like AndroidImpEx for importing contacts and sms messages from an Android phone, Ungoogled Chromium, local caching DNS (bind) tunnelled through TLS (stubby) to privacy minded servers and an inbuilt adblocker through a caching proxy (squid). These modifications are a personal preference of lxb\u0026rsquo;s but anyone is free to use them to help improve their privacy.\nInstalling Movuan Movuan offers an image based on Devuan 5.0 (Debian 12) with Phosh. Users can find Movuan images in the GitLab repository along with instructions on installing said image. As usual you can use a tool like Balena Etcher or Gnome Disks to write them to an SD Card as well.\nYou may build your own images as well using the debos recipe in the GitLab repository.\nWhat is Devuan? Devuan for users who are unaware is a fork of Debian which provides alterative init systems to Systemd such as:\nsysvinit (default) openrc runit sinit s6 shepherd The benefit of using a different init system depends on the features it offers over another. So it is highly depends on user preference. Other than this change it runs the same (at a surface level) as Debian/Mobian.\nUsers can learn more about the Devuan project here.\nFuture goals and contributing The goal of the Movuan project is to merge into Devuan as an official version, but it still requires some polishing to do before this can happen. Specifically help with packaging and testing would be appreciated! Anyone who is interested in helping with this project can contact lxb1@yahoo.com.\nDo you have something to share? Do you have news to share with the community? You can have your news posted on this blog by heading over to this tutorial and following the template. All community updates are written in markdown which you can learn how to write here.\nIf you get stuck, feel free to ask the folks in chat by finding your respective chat platform at https://pine64.org/community/.\nContact Community Feel free to contact me if you have any concerns about community related topics. This can be about getting project support, sharing project updates, concern about prolonged wait times for support from PineStore (anything after 1-2 weeks) and any general feedback that could help improve the community.\nCommunity manager: camden.b@pine64.org\nPineStore If you have quality control issues with your device once you receive it, don\u0026rsquo;t wait, contact PineStore support.\nFor general queries and information from the Pine Store: info@pine64.org For queries regarding support from the Pine Store: support@pine64.org For sales/wholesale related questions: sales@pine64.org If you have hardware defects or any other hardware issues to go: https://pine64.zohodesk.com/portal/en/home ","permalink":"/2025/08/27/august_2025_movuan/","tags":["project showcase"],"title":"Project Showcase: Movuan"},{"categories":["community","news","pine64-community"],"contents":"\nTable of contents Housekeeping PinePhone Pro discontinuation New community manager About me My goals as community manager PineNote Current status Operating Systems Arch PostmarketOS Nix WiFi Compatibility The issue Workaround #1 Workaround #2 Some words of warning with this workaround PineTab2 Kernel OS (DanctNIX\u0026rsquo;s Arch Linux ARM port) Mesa (GPU) PinePhone Pro Mainlining project FreeBSD port Contributors welcome! Blisp Want to contribute to the next community update? Housekeeping Welcome back to another community update! In this update we announce a new community manager, updates to the PineTab2 and PineNote, FreeBSD on the PinePhone Pro, a guide on upstreaming PinePhone Pro patches and a small bit for you Pinecil users.\nPinePhone Pro discontinuation Recently PineStore has also discontinued the PinePhone Pro which was talked about in the last recent blog post. TLDR, sales were low which lead to the discontinuation of the device. Spare parts will be available for purchase for up to two years depending on if they sell well. If you still want a PinePhone Pro, refurbished ones will be put up for sale on the PineStore around the end of the month, similar to how it worked for the PineBook Pro.\nFor more details, people can find it at the link below. https://pine64.org/2025/08/14/august_2025_short_update/\nNew community manager Authors: Caffeine Today I would like to formally announce that I have stepped up to take the roll as the community manager. This decision was made a few months ago as life has become a lot busier for Gamiee. We would like to thank him for the work he has done maintaining our community cluster and the countless hours spent on helping the community. Gamiee will continue maintaining the cluster for the foreseeable future.\nAbout me Hello everyone, my name is Camden, but you may also know me by my online alias CarbonatedCaffeine. I am a computing student from New Zealand (that country next to Australia) and I have been an active part of the Pine64 community since 2020, around the time the PinePhone Braveheart was launched. I enjoy playing badminton, tinkering with phones and computers, writing and hiking.\nMy goals as community manager As I step up, I aim to be a transparent and approachable community manager that community members can easily get along with. I promise to voice the concerns of community members so that important matters can be addressed as quickly as possible. We will continue to work towards bridging the communication gap between the Pine64 community and the PineStore which we hope will get smoother as time goes on.\nBringing back community editions is something that we have personally been asking PineStore to do for a while. This requires compensation to be arranged up front before a device is put up for sale. So while PineStore has continued in it\u0026rsquo;s goal to make cheap hardware that can easily get in the hands of developers, key community members who helped set up the community edition program have gone. This means that there has been nobody to help arrange compensation for those who have worked on software for recent products. If community editions return in the future it will increase the price of new devices, but this sacrifice is something we\u0026rsquo;re sure community members would be willing to pay if it meant supporting the developer(/s). We pledge to keep on PineStore\u0026rsquo;s heels about this and make sure that it will happen in the future so that developers will be paid for their effort. As of writing, PineStore is open to bringing community editions back for future products as long as proper planning and arrangements are made.\nIn terms of quality control and hardware failures I am aware that such issues exist. So to anyone, if these reports sent to Pine via email/tickets don\u0026rsquo;t get a reply for hardware replacements like some have experienced, I will get in touch directly with the PineStore founder to attempt to get the issue solved. Unfortunately I cannot do anything about fixing hardware defects other than report them, but I will do what I can.\nWe admit that both PineStore and Pine64 have dropped the ball and it has been very difficult to restart and recover after everything that has happened in the past. We will do our best to rebuild the community and we are going to start by replacing large community updates with smaller more frequent community driven project updates that anybody will be able to post onto this blog (not without moderation of course). We are doing this because it is tedious to write large community updates every month (and to keep a schedule). This will give power to project maintainers to announce important updates like new factory image releases through our community blog. I will write a tutorial on how to do so, which will be available on the Pine64 documentation website in the future.\nWe have confidence that the future is bright for the community and we hope you will join us in rebuilding our community.\n-Camden\nPineNote Authors: hrdl, Phantomas Current status The last community update featured some video demos of another major update of the display controller driver and an integration into a sway-based setup. Since then the kernel sources and integration have been published, packaged, and bundled into an image that can be extracted onto os2, giving users an Arch Linux-based setup that contains hrdl\u0026rsquo;s kernel, their sway/dbus integration, and a functional sway/waybar/gtkgreet/squeekboard setup.\nPhantomas has been improving the rust-based PineNote dbus service which has just and has been solving some long-standing firmware-related WiFi issues. The required firmware will be rolled out once there\u0026rsquo;s clarity on their license.\nhrdl has fixed an outstanding issue with multi-touch inputs. Ten finger touch support has been added by modifying the touch controllers configuration which is achieved by running a script from userspace. This issue occurs because the display controller is flashed at the factory with firmware that only supports two touch inputs at most. A single byte change to this firmware allows a maximum of ten touch inputs to be recognized. The fix will allow the support for 3-4 finger gestures on desktops to switch workspaces or bring up Gnome overview.\nDiederik made some minor contributions to the mainline kernel. They mostly remove some warnings, and unlike my work these were submitted to and accepted by upstream. He has planned some more work, so he suggested that it might make more sense to wait with mentioning his work until the next community update. dsimic has also upstreamed several patches.\nOperating Systems There are four new operating system options to choose from, just in case you need some variety.\nArch As seen in the header image for the PineNote section, hrdl has made a complete Arch installation that can be installed on the OS2 partition next to Debian. It is up to date and includes the latest software improvements.\nInstructions: https://git.sr.ht/~hrdl/pinenote-dist Image: https://files.hrdl.eu/arch.tar.zst Signature: https://files.hrdl.eu/arch.tar.zst.sig PostmarketOS Ayakael has made a functional PostmarketOS port based on hrdl\u0026rsquo;s kernel and sway setup.\nMerge request: https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/6711 Installation instructions: https://wiki.postmarketos.org/wiki/PINE64_PineNote_(pine64-pinenote) Nix Two NixOS setups by werapi (https://github.com/WeraPea/pinenote-nixos) and jzbor (https://github.com/jzbor/nixos-pinenote/blob/main/packages/fs-image/default.nix)\nWiFi Compatibility Some background, the chip inside the PineNote is an AzureWave CM256SM, which internally uses the CYW43455, which used to be the BCM43455 until Cypress bought Broadcom\u0026rsquo;s IoT division. That chip supports 5GHz WiFi, as well as the 802.11ac (WiFi 5) standard. That being said, WiFi, especially on the 5GHz band is subject to heavy regulations, since the frequency is shared with other tools (weather radar amongst other). This means 5GHz capable devices aren\u0026rsquo;t allowed to emit on most 5GHz channels, as long as they cannot ensure they respect local regulation. Linux\u0026rsquo;s way of managing this is through wireless-regdb, but drivers are allowed to disregard that information, which is exactly what brcmfmac does. Instead, that driver depend on Country Locale Matrix (CLM) blob being either baked in the firmware, or as a standalone file that the driver load.\nThe issue Broadcom/Cypress cannot ship a universal CLM blob for a given chip, because they cannot ensure the regulations will be respected by a final product (e.g. on board amplifiers, internal vs external antennae, etc.), so the one shipped in linux-firmware has a very limited set of features active. On the 2.4 GHz channels 12 \u0026amp; 13 are disabled since they aren\u0026rsquo;t allowed in the US. The 5GHz band is way worse however, being more heavily regulated. On that one, only bands 36, 40, 44 and 48 + some upper bands (\u0026gt; 149) are enabled. However bands \u0026gt; 149 are usually reserved for low emission devices (about the range bluetooth offer), so routers/APs can\u0026rsquo;t use them. The issue is that WiFi 5 compatible router/APs often select the best channel automatically, unless explicitly disallowed, meaning the PineNote could randomly lose 5GHz connectivity if the router picked a higher band. This happens more often in dense urban area, and is highly dependent on the AP/Router in use.\nWorkaround #1 A simple workaround for the user to be able to manage their access point is to disable automatic channel selection and pick one of the supported bands. This can come with a performance hit, but these bands offer the highest compatibility with most devices.\nWorkaround #2 After confirming the chip was actually able to make use of these bands (by retrieving hrdl\u0026rsquo;s blobs coming from the first batch android image), I searched for other firmware/CLM blobs compatible with the CYW43455 or the BCM43455, because while technically working, the android firmware could not be redistributed, and came with an unreasonable performance hit (better than nothing, but still). It turns out that raspberry uses a compatible chip (the AP6255 module, which internally uses the same BCM43455/CYW43455 chip), and their CLM blob are perfectly working on the PineNote. For the ArchLinux user, I made a PKGBUILD that pulls that firmware and installs it for the PineNote, as a replacement to the one shipped by linux-firmware (I consider it experimental until more people test it.)\nSome words of warning with this workaround While I can confirm the blobs to be working, I don\u0026rsquo;t have the hardware to make an EMF measurement and check that the PineNote perfectly respects local regulations. I don\u0026rsquo;t expect this to be an issue when used as a WiFi station because it will passively listen for existing AP before trying to emit, and I dout it has sufficient transmission power to cause interference once it start transmitting on an already authorized channel.\nHowever, DO NOT set it up as an Access Point. We don\u0026rsquo;t know if it can pick low power radars, so it might not be compliant with local regulations. Sometimes the driver fails to load on boot, I\u0026rsquo;m pretty sure I\u0026rsquo;ve seen it happen with the standard firmware, so it could just be some weird dependencies on my side. A reboot fixes the issue so I haven\u0026rsquo;t bothered troubleshooting that yet.\nPineTab2 Authors: Danct12 There is nothing much with the PineTab 2, but there has been more work on the BES2600 driver.\nKernel Suspend and resume bug with the BES2600 Wi-Fi driver has been mostly fixed in v6.15.2-danctnix2. There are still some bugs with the SDIO driver, but they\u0026rsquo;re considered \u0026ldquo;minor\u0026rdquo; for now.\nOn that note, a new driver for Bluetooth is currently being worked on. It is mostly working, I tried pairing a phone, a Bluetooth keyboard, I even tried BLE GATT and they\u0026rsquo;re all working. I haven\u0026rsquo;t tried out BLE audio as I don\u0026rsquo;t have any Bluetooth earbuds that uses it.\nHost wakeup is currently not supported, so Bluetooth devices cannot wake the PineTab 2 from sleep mode yet. I\u0026rsquo;m looking into how that works and I\u0026rsquo;ll implement that to the driver some day.\nUnfortunately, sometimes when the BES2600 SDIO driver does a read/write while Bluetooth is turned on, there\u0026rsquo;s a chance that it\u0026rsquo;ll timeout and bring down the WLAN driver altogether while Bluetooth (UART) is still working flawlessly. Because of that, it\u0026rsquo;ll take a while before the Bluetooth driver is ready for public testing.\nOS (DanctNIX\u0026rsquo;s Arch Linux ARM port) A new factory image for the PineTab2 (20250731) has been released: https://echo.danctnix.org:7269/factory_images/pinetab2/20250731/\nFlash the image to your SD card using dd or Win32DiskImager, boot with the SPI/eMMC disable switch (optional if the bootloader is working) and follow the instructions using the volume and power key. You may only use this if you need to reset the PineTab2 to factory defaults.\nIf you\u0026rsquo;re getting an error regarding the linux-firmware package such as:\nlinux-firmware-nvidia: /usr/lib/firmware/nvidia/ad103 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad104 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad106 exists in filesystem linux-firmware-nvidia: /usr/lib/firmware/nvidia/ad107 exists in filesystem Please read linux-firmware \u0026gt;= 20250613.12fe085f-5 upgrade requires manual intervention from Arch Linux news.\nMesa (GPU) Luigi311 (Luis Garcia) has tested a patch which rearranged texture format to BGRA meaning the GPU driver doesn\u0026rsquo;t have to do format conversion and thus, massively improved performance for certain applications. The patch has merged to upstream mesa and will be available in the next mesa release. You can check out the patch here\nPinePhone Pro Mainlining project The PinePhone Pro is currently running a near mainline kernel, but the PinePhone Pro tree currently requires a number of patches (114 commits to be specific) on top to be usable.\nIn light of this, community member LogicalErzor has created a guide on how to submit patches upstream towards the effort of making the number of patches needed to zero. The guide goes into detail on building, testing and upstreaming patches. If any community members are interested in helping out with this effort you can find the guide below.\nhttps://forum.mainlining.org/t/upstream-pinephone-pro-patches/138\nFreeBSD port There is a new FreeBSD port for the PinePhone Pro that is being developed by Toby and Stephan (@hnygd). Currently there is an image available for users to test that includes a minimal Xorg desktop environment and an on-screen keyboard. The latest update includes touchscreen driver support, limited networking support via the headphone jack, drive along with the aforementioned minimal desktop setup. In terms of what\u0026rsquo;s planned in the future, the plan is to bring a working USB and WiFi driver to FreeBSD which will make the device much easier to develop with. Pictured below is a demo of the PinePhone Pro running OS/2 Warp under QEMU on FreeBSD by Stephan (that\u0026rsquo;s a mouthful).\nContributors welcome! Toby and Stephan are looking for contributors to help with testing, feedback, upstreaming and driver development. If you\u0026rsquo;re interested in this project you can get in touch with them with the links on the repository.\nhttps://codeberg.org/Honeyguide/freebsd-pinephonepro\nBlisp Authors: Ralimtek This is a small note that blisp (used for programming the Pinecilv2 and other Bouffalo IC\u0026rsquo;s) has tagged out and released the 5th release. Version 0.0.5 has been released. There is a lot of cleaning up and improvements in there, including BL808 support and (basic) hex file support.\nWant to contribute to the next community update? Do you have a cool project that you\u0026rsquo;re working on that you\u0026rsquo;d like to be mentioned in these blog posts? Is there something you\u0026rsquo;re interested in that you\u0026rsquo;d like to write about related to Pine64? If you\u0026rsquo;re interested, please contact us!\nCamden/CarbonatedCaffeine: @carbonatedcaffeine (Discord) @endernightlord:matrix.org (Matrix) camden.b@pine64.org (email) ","permalink":"/2025/08/16/august_2025/","tags":["pinenote","pinetab2","pinephone-pro",null],"title":"August Update: Note-able Tablet Updates"},{"categories":["news","PinePhone Pro","Risc-V"],"contents":"\nHey everyone! As many have noticed, the PinePhone Pro is currently out ot stock on the Pine Store. Unfortunately we have to deliver you the following news: the PinePhone Pro is officially discontinued. We were told it didn’t sell well enough to keep production going. But the good news for current owners are that spare parts will still be made for up to two years, depending on demand. Meanwhile, the trusty PinePhone (A64) is still alive and kicking, and Pine Store plans to keep it rolling for about two more years.\nNo new PinePhone (Yet), future with RISC-V Right now, we’ve got no insider info on a brand-new PinePhone, so don’t expect any surprise announcements soon. Pine Store is steering its energy toward other projects (including RISC-V and a little bit of AI), which you’ve probably noticed with the Oz64, STAR64, StarPro64, and Alpha One launches.\nAnd one last thing: later this month there’ll be a small batch of refurbished PinePhone Pros up for grabs — your final shot at owning one of these little powerhouses.\n","permalink":"/2025/08/14/august_2025_short_update/","tags":["PinePhone Pro","Risc-V"],"title":"A Quick Community Update on PinePhone Pro and What’s Next"},{"categories":["community","news","pine64-community"],"contents":"Hello and happy April! The past few months have been relatively quiet on the surface, but there is a lot going on behind the scenes. During the past three months we have seen some improvements for the PineTab2, PineTime and PineNote, along with the announcement that the PineTab-V is back in store and the new micro soldering tip set for the Pinecil. Charlie the Pinecorn also makes his yearly appearance in the update banner, artwork made by Caffeine.\nWe have been very happy with the feedback after the launch of the PineNote Community Edition. Users coming from the developer edition with Android have been able to successfully move to the new Debian firmware without any major issues (thanks Maximilian, Diederik and hrdl!).\nWe\u0026rsquo;d also like to apologize as we had most of this written up around late February early March and things got busy. Thanks for waiting patiently! We\u0026rsquo;re making sure to focus on getting the word out than increasing the word count from now on.\nTable of contents FOSDEM 2025 PineTab-V StarPro64 PineTab2 PineNote Kernel improvements Demos PineTime Pinecil Community content PineNote Want to contribute to the next community update? FOSDEM 2025 Author: Caffeine Thank you to everyone who came past the pop-up meet-up at FOSDEM, it was fantastic to see everyone and be able to say hello. As mentioned in the previous update we weren\u0026rsquo;t allocated a table this year, but we managed to meet with community members at Bar Campouce. We hope to get a table for next years event.\nPineTab-V Author: Caffeine We are happy to announce that the PineTab-V is back in the store! Last year we reported that the PineTab-V would be going on sale in October, unfortunately this did not happen due to there being no default OS to send to the factory. Thanks to our friends over at StarFive, they have kindly built a working image to send to the factory (thank you!). The image is based on Debian with a Gnome desktop.\nMuch of the hardware is working including the cameras, WiFi and GPU acceleration. One thing to note though, when the battery is lower than 8%, some hardware (specifically WiFi) will not be able to function. We suspect this to be a hardware related issue.\nThe current status of the PineTab-V factory image from StarFive:\nBoth cameras working Lack of support for HEVC or MJPEG hardware decoding in Firefox. You can find more details about the factory image here.\nStarPro64 Author: Caffeine The StarPro64 SBC will be in the store sometime in the next two weeks. The device includes an Eswin EIC7700 SoC, 32GB of LPDDR5 memory and a 20 TOPS NPU. The device supports Deepseek 7B LLM out of the box.\nYou can find more extended detail on the device in the September 2024 community update.\nPineTab2 Author: Caffeine It has been many community updates since we have covered any software progress on the PineTab2, That cycle is broken this month as Danct12 who currently maintains the Arch based DanctNix distribution has made some improvements.\nDanct12 added U-Boot display support as well as HDMI on U-Boot. But this is yet to be upstreamed. There is also a new factory image which mainly includes package updates, the latest kernel update fixes WiFi on newer U-Boot versions.\nPineNote Authors: Caffeine, hrdl Since the last community update, there have been significant updates to the default Debian operating system. Notably a configuration to make the pressure sensitivity and eraser work in Xournal++, general user version of the Gnome extension, updated kernel and a new travel mode. The travel mode stops the PineNote from waking up when the folio case accidentally opens in a bag for example.\nFor users interested or who have just received their PineNote, Caffeine has made a series of videos detailing how to enter Rockusb mode using the magnet method, how to flash, upgrade and recover your PineNote, and a full Debian software demonstration. You can find the video playlist here.\nKernel improvements Community member hrdl has been improving the overall responsiveness of the PineNote on their Arch based operating system and improved kernel tree.\nThis means goodbye to artifacting due to mode/waveform mismatches and hello to redrawing changes on the display on a per pixel basis thanks to new bit depth and dithering behavior. hrdl has additionally written a Python script which listens for relevant sway events and updates that can be set up per application automatically.\nIf users are interested in trying the Arch based operating system (which is able to be installed on the OS2 partition) there is a tutorial on GitHub. Users can install improved kernel on Debian by searching and choosing the latest image using apt search hrdl.\nDemos Koreader, improved pen sensitivity and video playback demo Website scrolling demo Multitasking responsiveness and obligatory bad apple playback demo PineTime Author: Caffeine There has been a new update to the WaspOS reloader to add support for the BY25Q32 SPINOR flash chip found in recent batches of the PineTime. This means that the watch will no longer soft-brick. This happened when users tried to switch from Infinitime to WaspOS and back again. This is now fixed. See our previous blog post about the topic here for more information.\nUsers are able to find the new reloader artifact here at this actions page.\nPinecil Author: Ralim Continuing on the theme from launching the threaded insert tool, we are bringing a new set of tips. This time we are bringing out some micro soldering tips. Watching some of the discussions there has been demand for smaller tips that are more focused on smaller component sizes. So after working with the factory, we have made sample test units of the new design. As shown in the picture.\nThese are really focused more on SMD work. Below is the tips with 0603(Imperial) / 1608(Metric) sized resistor for a sense of scale.\nThe tips are designed to be plug \u0026amp; play with the Pinecilv2. They are the same 6.2 ohms as the short tips already available for sale. Due to the significantly smaller thermal mass, the tips heat up faster than the larger tips.\nCommunity content PineNote Community user Shom has been making some helpful and informative content on the PineNote.\nQ\u0026amp;A PineNote Review Pine64 PineNote - first impressions on MakerTube PineNote - smoothing rough edges on MakerTube A really well written review with some nice feedback. We are hoping that with the next batch the user won\u0026rsquo;t be required to run any u-boot commands after getting their PineNote. However, the main struggle I\u0026rsquo;ve encountered is from flashing the PineNote, this process can be improved in the future along with improved documentation.\nWant to contribute to the next community update? Do you have a cool project that you\u0026rsquo;re working on you\u0026rsquo;d like to be mentioned? Is there something you\u0026rsquo;re interested in that you\u0026rsquo;d like to write about related to Pine64? If you\u0026rsquo;re interested, please contact us!\nCamden/CarbonatedCaffeine: @carbonatedcaffeine (Discord) @endernightlord:matrix.org (Matrix) ","permalink":"/2025/04/13/april_2025/","tags":["pinenote","pinetab2","pinetab-v","fosdem","pinetime","pinecil"],"title":"April Update: Risc It For A Biscuit"},{"categories":["community","news","pine64-community"],"contents":"This month we report on some news concerning the PineVox, what the community have been up to with their PineNotes and the brand-new 1.15 InfiniTime update. We would like to wish our community a happy New Year and hope you all had a good end of 2024.\nBut since it\u0026rsquo;s now the beginning of 2025, we\u0026rsquo;d like to fill you in on what we have planned for the first part of the year.\nWe plan to release the PineVox to the public thanks to Gamiee\u0026rsquo;s recent progress and we plan to continue improving the software for the PineNote, thanks to Maximilian, Diederik and our testers in the community. We have some exciting devices coming as well, mentioned in previous community updates. The PineCam and StarPro64 have been sent to developers in our community, so we hope to report on these devices in the coming months.\nGamiee has also been working with a group of our friends over at Meshtastic on an independent project which will become the second version of the PineDio USB LoRa adapter. We plan to talk more about the progress of that project more in the February update.\nTable of contents FOSDEM PineVox PineNote Important - Software Update Issue Development updates PineNote Community Spotlight Inkput Pinescreen InfiniTime 1.15 Pinebook Pro Community content PineNote CE first month review Want to contribute to the next community update? FOSDEM Author: Caffeine Unfortunately, a stand at FOSDEM hasn\u0026rsquo;t been allocated for us this year. But that doesn\u0026rsquo;t mean we won\u0026rsquo;t be there to represent PINE64! Gamiee, Ralimtek, JF, TL Lim and Lukasz will be attending in person this year and will be planning a get-together. We will announce on our social-media when we have confirmed the time and place.\nOf course, our PINE64 community members will still be wandering around the event, we love talking to all our friends at other projects and meeting the members of our community! So we hope we\u0026rsquo;ll see you there!\nPineVox Author: Caffeine, Gamiee Gamiee has been working on the firmware for the PineVox recently (haha, now the title pun makes sense), he has made some significant progress on the usability of the device.\nRight now, the device can connect to home assistant, detect wake-up and process commands. Wake-up detection is currently done on the Home Assistant side, streaming audio data through Home Assistant. This will change as work is done to get wake-up detection working locally on the PineVox.\nAs for what’s next, Gamiee wants to implement a protocol for connection via Wi-Fi. This is much better for devices like smartphones, which in an ideal situation will provide coverage all throughout the home, rather than the small area that Bluetooth LE covers.\nRegarding the release of PineVox, it depends, currently this will depend on when Gamiee considers the firmware for the device to be usable. Only then will manufacturing for the device begin, which is loosely aimed at the end of February (take this with a grain of salt).\nPineNote Author: Caffeine Users have been enjoying their new PineNotes for a few months now and there has been a lot of good feedback. In fact, the device was used to write most of this community update.\nImportant - Software Update Issue \u0026ldquo;cannot proceed with upgrade\u0026rdquo; (as of Dec 11, 2024)\nUsers running the factory firmware on their PineNote Community Edition will encounter an issue updating their system. This happens because Debian has moved /lib, /lib64, etc. to /usr and because the system still includes a /lib64 symlink, attempting to update the system results in the base-files package failing to install.\nYou can fix this by removing the symlink by running sudo rm /lib64 in your terminal (via SSH, UART, etc.).\nDevelopment updates Since users have received their PineNote Community Edition devices, various bug fixes and a kernel update to Linux 6.12 have been pushed. Users can update through the command line (using APT) or through the Gnome Software application. Xournal++ has also since been updated.\nUsers wanting audio out (and other USB goodies) using the USB-C port will have to update their kernel manually currently. This can be done with this command in the terminal. Though this is completely optional, as everyone will eventually get these updates soon.\nsudo apt install linux-image-6.12.6-pinenote-202412310358-00187-g0aa6f8665258\nPineNote Community Spotlight Inkput Inkput is a proof-of-concept software written by s12wu that allows the user to enter text using handwriting. Inkput uses PellelNitram\u0026rsquo;s handwriting recognition implementation to achieve this.\nThe program Inkput works by displaying on top of the user\u0026rsquo;s desktop, then the user will write something in the box, select a text input and press predict. This will drop the written text into the text input like in the image below.\nContributions and testing is very much welcome! You can find the Inkput source code on GitHub: https://github.com/s12wu/inkput\nPinescreen Pinescreen is a software whose purpose is to implement the features found in the Gnome extension to configure the e-ink display. Pinescreen is targeted at improving use on KDE Plasma.\nIt\u0026rsquo;s currently in early development, testing and contributions welcome! You may find the software here: https://gitlab.com/Poundex/pinescreen.\nInfiniTime 1.15 Author: JF InfiniTime released InfiniTime 1.15 \u0026ldquo;Ribes rubrum\u0026rdquo; earlier this month! This release is packed with new features and improvements that we will take a look at in this section of the blog post.\nThis is the first release in almost a year and one might wonder why it took so much time to finalize this new version of InfiniTime. Remember that InfiniTime is designed, built and maintained by \u0026ldquo;normal\u0026rdquo; people working on the project with their free time. Maintainers get busy with other projects and changes in their lives. As an example, I became a father a few months ago, and as you can expect, this has had a huge impact on the time I can dedicate to the project.\nThe team also has a strong focus on reliability and stability: we decided to delay the release by a few weeks to fix a few stability issues and regressions that popped during our testing. This, together with the very limited resources of the PineTime hardware, makes the development of the firmware a bit more tedious (but it\u0026rsquo;s still a lot of fun :)).\nTalking about the team: the core developers are happy to welcome mark9064 to the core developers team. Mark has been contributing to the project for many months now and among other things, made the Always-On feature possible in InfiniTime.\nNow, let\u0026rsquo;s take a look at InfiniTime 1.15! A lot of users have been waiting for this feature for a long time now: the Always-On Display (AOD). Implementing this feature on the PineTime was quite a challenge, since the hardware is not designed for it. This is mainly because of the LCD display and its power hungry backlight. @KaffeinatedKat and @mark9064 however managed to make this possible by optimizing low-level drivers, fine-tuning some display settings and improving the state machine of the UI. Without going into too much details, the display is configured to use as little power as possible by reducing the number of colors that are displayed, by reducing its refresh rate and by driving the backlight using a PWM (Pulse Width Modulation) to its lowest visible level.\nThis was a complex feature to implement and review, but it was worth it: InfiniTime runs for 2 to 3 days in this mode! I\u0026rsquo;m honestly impressed by how comfortable the InfiniTime feels when this feature is enabled together with the Raise-to-Wake and Lower-to-Sleep features!\nYou can easily enable this feature in the settings (Settings → Display → Always On).\nA new application was also integrated in InfiniTime 1.15: the weather forecast app. As you can expect, this app shows the weather forecast for the next 5 days in a nice and colorful way. This feature was contributed by @vkareh.\nYou\u0026rsquo;ll find it in the third page of the application menu.\nThe dice rolling app by @yusufmte is another new application added in this release. This app generates random numbers according to the number of configured sides. This app will come in handy for table-top players, among others.\nIt\u0026rsquo;s available in the 2nd page of the settings\nAnother highly requested feature is the persistent alarm. Previously, your alarm setting would be lost when the watch reboots, after an update for example. Thanks to @NeroBurner, the setting is now saved in the configuration file to ensure that the alarm will be restored the next time the watch reboots!\nThe list of changes is so long that I cannot detail all of them in this blog post. Let me just mention that the header README file was redesigned, the default year (in the date/time) setting is now automatically set to the current year of the build, the color inversion bug is now fixed and that the lower to sleep algorithm has been improved by checking the wrist angle. Please check the release note to see the complete list of changes and additions!\nI would like to take the opportunity to thank everyone who contributed to this release of InfiniTime. It contains a lot of features and improvements that greatly improves the experience for many users!\nPinebook Pro Author: Caffeine The Pinebook Pro is no longer in production and will therefore no longer be stocked on the PineStore. This is due to the switch of focus to the PineTab and the PineNote line of devices.\nThere are plans to continue the Pinebook series, and it will return in the future when a suitable SOC is chosen.\nCommunity content PineNote CE first month review Author: Caffeine I recently received my PineNote at the end of November, it\u0026rsquo;s been really nice to use. This month, I wrote the blog post on the PineNote using my Logitech Bluetooth keyboard.\nI managed to get everything to work well out of the box, the pen responsiveness is very good, I have had no trouble drawing or writing using the included Xournal++ application. The 4GB of included memory is enough to have many applications open, including a web browser, music player and my document opened in LibreOffice. The included software and changes made to the system help the PineNote to be a usable device. There is a Gnome extension for controlling the display and manually refreshing the screen, along with a custom shell theme to help with visibility. One thing I also noticed is how good the battery life is. I can have it sleeping for nearly a week and I can easily get around three days of usage out of it while writing and browsing the internet.\nThe big thing for me so far is the fact there is no MicroSD Card slot included with the device. The device has a very specific partition structure right now and I\u0026rsquo;m afraid to change anything. If I brick my device I feel like I would need a lot of help compared to something with the PinePhone which is easy to flash. The part that makes it difficult is that a user must use the included magnet tool or serial adapter, then flash the device and find the waveform files for your specific PineNote batch. Both devices have different waveform files due to different displays. These are not included in the Debian images if you want to re-flash, so you\u0026rsquo;re required to download them. I\u0026rsquo;m sure things will get better in the future for PineNote recovery, but right now I\u0026rsquo;m afraid that I\u0026rsquo;ll eventually brick the device.\nOverall, I am happy with the experience of my PineNote so far. The performance is good, the screen is nice and I haven\u0026rsquo;t faced any major issues (that haven\u0026rsquo;t already been fixed ;) ). I will likely be back with a more thorough review in 6 months after I have discovered the quirks of the device and using as my primary note-taking device for a while.\nWant to contribute to the next community update? Do you have a cool project that you\u0026rsquo;re working on you\u0026rsquo;d like to be mentioned? Is there something you\u0026rsquo;re interested in that you\u0026rsquo;d like to write about related to Pine64? If you\u0026rsquo;re interested, please contact us!\nCamden/CarbonatedCaffeine: @carbonatedcaffeine (Discord) @endernightlord:matrix.org (Matrix) ","permalink":"/2025/01/11/january_2025/","tags":["pinevox","pinebook-pro","fosdem","pinenote","pinetime"],"title":"January Update: Thinking Out Of The Vox"},{"categories":null,"contents":"In July 2024, PineStore notified the community that a small hardware change was needed on the PineTime: the current flash chip was end of life (EoL) and needed to be replaced by a new one. From the software point of view, the new chip behaves exactly like the old on so very few code changes were required to support it.\nThe new chip exposes different identifiers (manufacturer ID, for example) than the previous one. Which means that if the software checks those IDs, it would need to be updated to take the new ones into account.\nNo change was needed in InfiniTime, but we however added a new field in the SystemInfo app to display the IDs of the chip. We figure this could be useful in the future.\nThe bootloader does check against those IDs so we released a new version of the bootloader (v1.0.1) as well.\nWe provided the new software to PineStore so they could test them and use them to flash the new batch of PineTimes at the factory.\nEverything went well and PineTimes equipped with the new memory chip and software are being delivered to happy users.\nEverything? Well, not really: a few users reported soft-bricked PineTimes after switching to WASP-OS and then reverting to InfiniTime again. This is a bummer: the \u0026ldquo;reloader\u0026rdquo; tool that reinstalls the InfiniTime bootloader also needed to be upgraded to support the new memory chip!\nAn issue has already been opened on the WASP-OS GitHub repo and a new reloader tool will hopefully be released soon to tackle this issue. We also added a big red warning on the documentation page that explains how to switch to and from InfiniTime and WASP-OS to ensure that users won\u0026rsquo;t try to switch OS until the issue is fixed and the documentation updated.\nWarning In the meantime, do not try to install WASP-OS on your PineTime if it\u0026rsquo;s running bootloader v1.0.1 from the factory (unless you know exactly what you are doing), this WILL brick your PineTime! Be sure that the community will try to fix this as soon as possible, but please remember that developers, like mostly everyone, are a bit less available during this period of the year. ;-)\nWe are really sorry for the inconvenience caused by this issue, and we wish everyone a happy holiday season!\n","permalink":"/2024/12/29/please-refrain-from-installing-waspos-on-new-pinetimes-for-the-moment/","tags":null,"title":"Please refrain from installing WASP-OS on new PineTimes for the moment"},{"categories":["community","news","pine64-community"],"contents":"Welcome back to a new monthly Pine64 community update! This month we are announcing a couple of new products including a SBC and a successor to the PineCube. We have updates to share about the PineNote and the PineDio USB adapter this month along with a talk by one of our community members Dsimic.\nTable of contents PineCam Yuzuki Avaota-A1 PineNote Attention to all users who have ordered/received a PineNote For general users wanting to purchase a PineNote PineNote News PineTab-V BarCamp Talk About Pine64 and Ox64 Handout PineDio Community content Monthly community updates Want to contribute to the next community update? PineCam Authors: Lukasz, Caffeine The first new device we will be introducing this update is the PineCam! The PineCam is a successor to the PineCube IP camera, but with a much more polished design, better specifications and more features. While the PineCube didn\u0026rsquo;t achieve the success the project had hoped for, we believe it wasn\u0026rsquo;t due to a lack of interest in such hardware, but rather the way it was executed. We\u0026rsquo;ve gathered feedback, learned from what went wrong, and have gone back to the drawing board. This time, the PineStore have decided to take a different approach, using a System-on-Chip (SoC) already in our hardware lineup. The device includes more RAM (compared to the PineCube\u0026rsquo;s 128MB), and utilizes a camera interface that \u0026ldquo;just works\u0026rdquo;.\nThe PineCam is based on the oz64 single board computer which is powered by the SG2000 system on a chip found in the new Oz64. The SOC includes two RISC-V cores (C906 @1Ghz + C906 @700Mhz) and one ARM core (Cortex-A53 @1Ghz). You can find more information on the specifications of the Oz64 and the SOC it\u0026rsquo;s using here. The device features 512MB of RAM, providing just enough memory to run a full Linux-based OS such as MotionEyeOS, a popular surveillance camera operating system.\nSpecific to the PineCam now, the device includes a 2MP camera module which is the same one found in the PineTab 2/-V (the GalaxyCore GC02M2), it is connected via a MIPI CSI connector. Additionally, the camera and body can be separated from each other to be used as a USB-C UVP wired camera, so it may be used as a desktop webcam. The camera’s PCB also comes equipped with IR LEDs for low-light application use-cases. The mainboard is equipped with GPIO, a microphone, speaker, and USB-C power input located on the right-hand side of the device (when viewed from the front). The GPIO pins share Oz64’s layout and can be accessed by removing a small flap at the front of the PineCam. If you don\u0026rsquo;t need to tinker with the GPIO, the flap can be reinstalled and screwed in place permanently. The PineCam comes with a convenient tripod, which can be folded or removed from the body of the device.\nThe PineCam is currently in early prototyping stages, with the plastic body and final PCB having just arrived in recent weeks. However, the hardware is taking shape quickly and the printed circuit board assembly stage is currently on track for around the end of October. The first batch will be making its way to developers soon.\nI can see the PineCam being used in countless scenarios, ranging from a truly private nanny or security camera, to a 3D print or drone camera. I’m sure you can think of your own, better use-case examples for the Pinecam. The PineStore hasn’t zeroed-in on a price point just yet, but the device will cost less than $30 upon release.\nYuzuki Avaota-A1 Author: Caffeine The second device we will be announcing this update is a collaboration between PineStore and hardware manufacturer Yuzuki, the Avaota-A1.\nThe device includes an Allwinner A527 SOC with 4 cores @ 1.8Ghz and 4 cores @ 1.42Ghz, a Mali-G57-MC1 GPU that supports the open source Panfrost driver, supports a 4K 60Hz display via HDMI as well as a 2.5K 60Hz display via DisplayPort, 802.11 B/G/N/AX WiFi (Wifi 6) and BlueTooth 5.4 connectivity.\nYou can purchase it in a 4GB of memory and 32GB of storage configuration or a 2GB of memory and 16GB of storage configuration.\nYou can find more information about this device on Yuzuki\u0026rsquo;s website for schematics and OS downloads and on Pines store listing. We plan on continuing this relationship with Yuzuki with another board in a couple of months, so stay tuned!\nPineNote Author: Caffeine, Lukasz Attention to all users who have ordered/received a PineNote The version of Debian-based Linux distribution shipped with the second PineNote batch contains some issues that prevent suspend-to-RAM from working correctly and make entering MaskROM mode using a magnet not possible. This was caused by the unfortunate timing, so the factory ended up installing version of the operating system image that contains these issues. The required fixes are already available in the shipped Linux distribution, but they need to be installed manually by the users.\nFor general users wanting to purchase a PineNote We would like to affirm that the PineNote Community Edition is still aimed at Linux developers with an extensive knowledge of embedded systems and/or experience with mobile Linux. Although the software has improved, we still want more testing done with this new batch to make sure we can start to aim this at general users. Now back to the blog post.\nPineNote News The PineNote is one of the more ambitious projects undertaken by PINE64 and the PineStore since the original PinePhone. The main goal behind developing the PineNote was to create an open-source alternative to popular e-paper readers and note-taking devices, with nearly infinite software customization, free from advertisements and subscriptions. It runs standard Linux, adapted for a grayscale display, with preinstalled tools and extensions included to help make use of the device easier. From the outset, we understood that software would be key to building a true alternative for the FOSS community, and that achieving this goal would take time. This was a project we chose not to rush.\nThe groundwork for the PineNote as well as the PineTab2 began with the Quartz64 single-board computer, followed by a three-year development period for the PineNote itself. The last thing we as a project wanted was to release a half-finished piece of hardware that might dissuade people from embracing an open e-paper reader and notepad.\nDelaying the PineNote’s broader release has proven worthwhile. The factory image is based on Debian Trixie and includes the GNOME desktop by default. While the software is still best described as a \u0026ldquo;beta,\u0026rdquo; it’s already quite impressive and will further improve with time as more people get their hands on the device. As things stand, all core functionality of the device has been implemented and enabled, with nothing missing, and each feature has been integrated thoughtfully. This includes everything from a custom grayscale GNOME theme to convenient quality-of-life features, like the ability to control both blue and yellow backlight under brightness settings, a widget that allow users to refresh the display on demand, and even a quick drop-down in the task-manager panel to adjust the drawing mode. I should also mention that there is an initial boot screen with documentation included in GNOME\u0026rsquo;s Help app, which opens upon first boot. All this, running on mainline Linux.\nMaximilian and other contributors have done an incredible job, making the PineNote feel like a true FOSS counterpart to established commercial platforms.\nThe PineNote production and flashing stages have finished and we are currently shipping to users (some are even receiving them as we speak!). The PineNote retains its initial price of $399 from the developer batch, with no major hardware changes; the only difference being a change from an active to a passive stylus, so it no longer requires charging, and yet the buttons on it remain functional (pretty cool right?).\nThe PineNote\u0026rsquo;s potential is substantial. It shows that an e-paper device running Linux and open software can meet the needs of the enthusiast community—and, in some respects, even rival or surpass more mainstream devices that often lock users into proprietary ecosystems or subscription models. More importantly, it demonstrates that existing software can be adapted to work seamlessly on a grayscale e-paper display. We’re excited for tinkerers and developers to finally get their hands on the PineNote and the e-paper technology, which offers a fantastic experience for reading, note-taking, and the benefits of better battery life thanks to the e-ink display. We will be looking forward to your feedback and are keen to see how you use, change and improve the PineNote over the coming weeks, months and years. As always, we encourage you to contribute to the development process; you don’t need to write code (although, this is also obviously welcome) as testing, writing or translating documentation or even just offering feedback to developers means a lot to all engaged in the project.\nPineTab-V Author: Caffeine Last month the PineTab-V part was completely missed on accident (whoops, sorry :\u0026lt;) and missed some important details for the new batch.\nThe hardware changes made to the PineTab2 will be trickling down the the PineTab V as well in this new batch. After listening to community feedback we added an accelerometer along with a status LED for notifications and charging (similar to the PinePhone) to the Pintab2/PineTab-V. Some fixes were also made to resolve the slow charging issue while the device is turned off and a proper PineTab-V ID was added to the EEPROM.\nThis is a great revision with fixes and new hardware features, the device is currently in production and should hopefully be available in the next month.\nBarCamp Talk About Pine64 and Ox64 Handout Author: Dsimic Almost exactly a year ago, I delivered a talk about single-board computers and Pine64 at a local BarCamp. One of the intended goals was to produce a write-up for one of the Pine64 monthly community updates, which is obviously long overdue, but better late than never.\nThe primary goals of the talk were to raise the awareness of the local people about single-board computers in general, and more specifically about the Pine64 community and products. Both areas are rather blurry to the proverbial Joe Average, so providing some kind of an introduction can only be helpful. Alas, it turned out that the things were much more blurry than expected.\nThe intended talk audience consisted of, in general, software developers of all kinds, with various levels of knowledge and skill. There were about 50 people attending the event; we\u0026rsquo;ll need this number later, while drawing some of the conclusions.\nA few weeks before the talk I reached out to TL Lim, asking if he could donate a few Ox64 128 Mbit boards, with the intent to hand them out right after the talk. To my delight, TL Lim responded with great news: a total of six Ox64 128 Mbit boards were on the way for my doorstep! Thank you once again for that, TL, I really appreciate it! It goes without saying that I was really happy to hear that, and I imagined happy people receiving the free Ox64 boards and enjoying them, while also contributing in different ways down the road. Oh, was I wrong. :(\nSix Ox64 128 Mbit boards received from TL Lim\nUnfortunately, the Ox64 boards didn\u0026rsquo;t arrive before the talk, missing it by just a few days, so I was unable to hand them out exactly at the end of the talk, as planned originally. Instead, I intended to collect the contacts of the lucky winners and deliver the boards later. I thought that would make the talk audience a bit impatient, maybe even a bit sad, but as it turned out, I was wrong once again.\nThe talk itself, whose slides in English are available for download, unfortunately went without sparking particularly strong excitement among the audience, despite even being the opening talk, and despite the clearly mentioned handout of free Pine64 hardware. I didn\u0026rsquo;t want to make some kind of a lottery out of the handout, so I just asked that anyone who wanted a free Ox64 board had to describe briefly what they would use it for. Thus, someone basically had to produce a couple of meaningful sentences, and a free Ox64 board would\u0026rsquo;ve been theirs. Such an approach seemed fair to me, because the intent was to put the donated Ox64 boards into good use, but to my surprise and despair, when it was the time to hear the use-case proposals, all that was audible were the proverbial crickets. Believe it or not, nobody proposed anything, while I expected at least a few people out of about 50 BarCamp attendees to be interested in the whole thing, and to come up with some interesting uses or projects. A couple of people asked for some more details about the Ox64, but that was it. It was satisfactory to at least see that the talk audience weren\u0026rsquo;t greedy, so they didn\u0026rsquo;t ask for something they wouldn\u0026rsquo;t actually use.\nObviously, the outcome made me rather disappointed, but as always, there\u0026rsquo;s something to learn even from the things that turn out really bad. Quite importantly, I was left with the Ox64 boards that I promised to hand out, but surprisingly, nobody wanted. Thus, I had to \u0026ldquo;force feed\u0026rdquo; the boards to a few friends of mine, who actually didn\u0026rsquo;t ask me to receive them. Luckily, one of them eventually expressed some interest in using his free Ox64 board for some project in robotics, but sadly, his enthusiasm eventually proved not to be strong enough. To my unpleasant surprise, I\u0026rsquo;ve heard back nothing about the handed-out Ox64 boards in the last year or so, which presumably means that the above-mentioned friends of mine haven\u0026rsquo;t done much with them, including the one who had some robotics project in mind. Such an unpleasant and truly unexpected outcome may make the whole talk endeavor look muck like a total waste of time, effort and money, but I think we should actually try to learn something from this failure, which is sometimes the best way to learn.\nAfter thinking a lot about the whole thing, and after talking a bit to one of my friends, who received the last of the donated Ox64 boards a few months ago (for the record, I kept one out of six boards for myself), my conclusion is that much more \u0026ldquo;built-in\u0026rdquo; user-friendliness is required to make the Pine64 products understood better and, hopefully, more widely accepted. To put it simply, we need to make blinking the proverbial LED very easy, which hopefully can we make some people interested to learn and do more. Though, we shouldn\u0026rsquo;t fool ourselves by expecting huge numbers of new people to suddenly become low-level software developers, because that\u0026rsquo;s simply not realistic. Very few people are interested in that, and out of those who show some interest, very small percentage is actually willing to put some effort into it. It\u0026rsquo;s just hard and mentally not rewarding enough to most people who are already software developers of some kind. Not to mention that most people just want to repeat some \u0026ldquo;cookie cutter\u0026rdquo; recipes found in various tutorials, which is absolutely fine, but such an approach unfortunately doesn\u0026rsquo;t bring a lot of new value to the Pine64 community and its members.\nI\u0026rsquo;ve already got some plans about how to make the Pine64 products more user-friendly, and only time (and some future community updates) will tell how much I\u0026rsquo;ll actually do about that.\nPineDio Author: Caffeine Things have been moving quickly in the PineDio space as of late. Community manager Gamiee has been working with developers over at Meshtastic to get the PineDio USB adapter working with the Meshtastic firmware. Work has been completed to port the SX1262 to RadioLib which is a requirement for the firmware.\nAt the moment, support for Meshtastic is seeming likely, but some issues could be attributed to hardware faults and it\u0026rsquo;s possible a small hardware revision could be made sometime in the future. The issue has been found to be attributed to the TXCO, this issue stops the device from sending long packets via Meshtastic.\nWe would like to personally thank the people over at Meshtastic for the work they have done for the device so far. We have interest to continue collaborating with the Meshtastic project and we hope to work together to make new devices in the future.\nCommunity content Monthly community updates Author: Caffeine As most of you know, the past two years has not been the best for community updates as nobody has been able to write consistently. I am happy to announce that I will be stepping up to continue producing community updates monthly alongside our community members and developers.\nLast months post was a bit of a doozy to write due to the 6 months of information needed to be inquired and written about, originally the update was slated for August, but unfortunately that never happened. For that I\u0026rsquo;d like to thank everybody\u0026rsquo;s patience with our updates, things should be easier now that the last update is out of the way, so expect updates every month starting from now.\nThanks again, Camden.\nWant to contribute to the next community update? Do you have a cool project that you\u0026rsquo;re working on you\u0026rsquo;d like to be mentioned? Is there something you\u0026rsquo;re interested in that you\u0026rsquo;d like to write about related to Pine64? If you\u0026rsquo;re interested, please contact us!\nCamden/CarbonatedCaffeine: @carbonatedcaffeine (Discord) @endernightlord:matrix.org (Matrix) ","permalink":"/2024/11/21/november_2024/","tags":["avaota-a1","pinetab-v","pinecam","pinenote","pinedio","ox64"],"title":"November Update: Something Borrowed Something New"},{"categories":["community","news","pine64-community"],"contents":"Hello and welcome back to another Pine64 community update! The community has been hard at work behind the scenes with development of new hardware along with bringing back some previously manufactured products. Of course, we will also go over the current state of our devices as well. And just before you ask, yes it is October. Most of the work for this update was done last month.\nWe\u0026rsquo;d also like to thank you for your patience, it\u0026rsquo;s been difficult with a most of us having limited time to work on these updates. We will continue to write and release these updates as fast as we can and continue to become more consistent again like we used to be.\nThanks!\nTable of contents Updates New products announcements StarPro64 Oz64 Quartz64-Zero PineNote Operating System Progress Mobian PostmarketOS Call For Contributors! PineTab-V PinePhone Pro PinePhone Pinecil / IronOS Stability Timer weirdness New Screen Driving / GUI Handling New from Ralim Quartz64/RK3568 PineTime PineStore announcement: small hardware change InfiniLink Blog posts about the PineTime Rework of ITD Flatpak package for Amazfish PineTime integration in MyGnuHealth The super-power of open source InfiniEmu InfiniTime Status PineDio Community Updates Infrastructure and Moderation Lomiri on PostmarketOS GTK3 inspired watchface Want to contribute to the next community update? Updates New products announcements StarPro64 Author: Lukasz The PINE64 project and PineStore have been committed to bringing more devices based on the RISC-V architecture since three years ago. Since 2021, several devices including the Pinecil — PINE64\u0026rsquo;s most popular hardware — have adopted this architecture. While the Ox64 may have been the first Linux-capable single-board computer (SBC) technically, the first full-fledged PINE64 RISC-V SBC was the Star64, which laid the foundation for the PINETAB-V tablet introduced last year alongside its ARM sibling, the PineTab2. Although significant development is still needed for the JH7110, interest in the platform and RISC-V development in general remain strong, with new releases from projects like DietPi and NuttX.\nHowever, PINE64 and PineStore\u0026rsquo;s commitment to the RISC-V platform goes far beyond existing products. As a testament to this, we are thrilled to introduce you to the newest RISC-V family member in the PINE64 hardware line-up – the StarPro64. Following the convention of more capable hardware in the PINE64 catalog, the StarPro64 boasts a more powerful system-on-chip (SoC) at its core than its non-Pro older sibling. It is based on the EIC7700X, an upgraded version of the EIC7700. The CPU speed has been increased from 1.4 GHz to 1.8 GHz, while the NPU performance has been boosted from 13.3 TOPS to 19.95 TOPS.\nThe StarPro64 uses the model-A board format, seen in earlier products such as the Pine A64, the popular ROCKPro64, and indeed also the Star64. The layout of the StarPro64 is very similar to the Star64, with all key I/O ports in the same positions. This includes the dual Ethernet ports, digital video output port, and 12V power input at the rear of the board. The front features a power button, as well as USB 2.0 and 3.0 ports, in their usual model-A positions. Additionally, the board has a full GPIO header, a 4x PCIe lane, an eMMC slot, onboard WiFi/Bluetooth, and heatsink mounting holes matching the layout of the ROCKPro64 one-for-one.\nThe StarPro64 will be available in three memory configurations: 8GB, 16GB, or 32GB of LPDDR5 RAM. While a firm availability date has not yet been provided yet, it is expected to reach the PineStore sooner rather than later. The first prototype, featuring 32GB of RAM, arrived in late September and we’re pleased with how it turned out. If the early evaluation board passes testing, developers will start receiving their units in the coming weeks. While we’re keen to get production going so you can get your hands on a unit, we’ll patiently wait for developer feedback - positive feedback from the community will lead to full-scale production.\nThe StarPro64, and more specifically the Eswin EIC7700 SoC, is an exciting platform that may become a foundation for future devices. PINE64 hopes that the development and enthusiast community will embrace this SoC and the StarPro64, as it could be a gateway to a range of affordable RISC-V devices that many of us are eager to see. For instance, you can even connect a PinePhone Pro LCD and touch panel to the StarPro64 — pretty cool, right? For those interested in a deeper dive into the SoC, I encourage you to check out a detailed article on CNX Software.\nThe StarPro64 board PCB has already been sent out for fabrication along with the prototyping board back in September.\nOz64 Author: Lukasz The StarPro64 is, however, not the only SBC introduced this month. The Oz64 is a development board based on the SG2000 MCU and equipped with OIC8800 Wi-Fi/BT chip. It\u0026rsquo;s an interesting chip that embeds multiple cores: two main cores (T-Head C906 64-bit RISC-V cores and an ARM Cortex A53 64-bit RISC CPU, only one of them can be used at a time), another T-Head C906 RTOS core and a 8051 8-bit core. They are supported by 512MB of RAM. The board also provides a microSD card slot, an eMMC connector and a USB2.0 type-A host port. It is important to note that the Oz64 is not a replacement for the Ox64, which has proven itself to be popular and will remain in PineStore’s hardware line-up for the foreseeable future. Production of the Oz64 is already completed and it is currently undergoing Q\u0026amp;A testing. Once testing will be completed the SBC will find its way into the Pine Store in the coming weeks or months. Expect an announcement on social media platforms and in the chats.\nThe Oz64 is expected to be available in the next few weeks or months.\nQuartz64-Zero Author: Lukasz Following the two RISC-V centered SBCs there is also an announcement pertaining to our Arm Quartz64 device-line. The Quartz64-Zero is a lower cost version of the Quartz64 that is based on the RK3566T (Quad A55 @1.6Gh) and comes with 1GB memory.\nAll Quartz64 software options should work right out-of-the box on this board without any major optimizations. Noteworthily, the PCIe port on the Quartz64-Zero is the same as the one on the Raspberry Pi 5. As such the PineStore sees this low-cost board as suitable for commercial project applications and guarantees the availability of the board until at least 2028. It is hence an LTS board.\nThe Quartz64-Zero is already available for $15 on the store.\nPineNote Authors: Ralim, CarbonatedCaffeine The PineNote is coming back; there are now plans formalized for a production run of these units. I do not (yet) have a launch date target as behind-the-scenes the Pine Store team are still working on all things production.\nWhat has happened behind the scenes has been a very long discussion with TL around if a new batch can happen. There has been huge amounts of work done by Maximilian tireless working away at making a stable Debian distribution to run on these devices. I\u0026rsquo;m very acutely aware of the silence that has surrounded this device, this was not by design but rather due to lack of updates to share publicly as things slowly progressed. I took my unit to FOSDEM this year to be able to show of the progress that has been made on the OS front, and to be able to talk about the product still continuing.\nThe PineNote was stuck in a chicken-and-egg situation where because of the very high cost of manufacturing the device (ePaper screens are sadly still expensive), and so the risk of manufacturing units that then didn\u0026rsquo;t have a working Linux OS and would not sell was huge. Maximilian\u0026rsquo;s work in the background has pushed the envelope on this and resulted in not only a bare-bones capable OS but a genuinely daily-usable system that \u0026ldquo;just works\u0026rdquo;.\nThis is excellent as it also moves the target audience from developers to every day users. You should be able to power on the device and drop into a working Gnome experience.\nThe hardware of the PineNote has taken some feedback from the early developer units, we are aiming to have the old pen replaced by a passive (no charging) unit that still features the same buttons.\nOperating System Progress Currently the PineNote firmware is being developed by Maximillian and is based on Debian.\nThe images are using the Gnome desktop and includes some extensions specific to playing well with e-ink displays.\nIf you currently own a PineNote, you can find these images here. If you have time, any testing and feedback on these will be valuable.\nMobian Julian Fairfax has created an initial port of Mobian for the PineNote. It currently boots, but it isn\u0026rsquo;t as usable as it could be using Phosh. It\u0026rsquo;s a good starting point.\nPostmarketOS \u0026ldquo;There were also attempts to port PostmarketOS to the Pinenote. The current state needs to be tested:\u0026rdquo; https://wiki.postmarketos.org/wiki/PINE64_PineNote_(pine64-pinenote)\nCall For Contributors! We need help getting the Debian image into best shape for the release.\nIssues: https://github.com/PNDeb/pinenote-debian-image/issues Nice videos would be very appreciated Join/ask in the PineNote chat if you are willing to help! PineTab-V The PineTab-V is returning for another production batch in October similar to the PineNote.\nIn this new batch, there are some notable hardware revision changes:\nAn accelerometer was added to the device Resolved slow charging while the device is turned off A LED status indicator light has been added to the device Added a proper ID of the PineTab-V in the EEPROM The device will be in stock around mid/late October. An announcement will be made when it drops in the store.\nPinePhone Pro Author: CarbonatedCaffeine The PinePhone Pro switched its default operating system from Manjaro at the end of 2023 to Adam Piggz\u0026rsquo;s port of Sailfish. There have been a number of updates since the PinePhone Pro was mentioned in a community update.\nDuring the end of 2023 commits were made to add functionality to wake the phone using the modems RI pin. In addition to adding the config to support usage of Waydroid. Then recently in early 2024 Adam fixed call audio routing.\nPinePhone Authors: JF, CarbonatedCaffeine Good news for PinePhone users!\nThe WiFi chip used in the PinePhone (rtl8723cs) recently got mainline support in early 2024. Dsimic added trip points for the GPU to the SOC DTSI into mainline, preventing possible but unlikely overheating damage to the A64. Another patch added a mount-matrix for the accelerometer into mainline, which fixes inverted accelerometer behavior.\nPinecil / IronOS Author: Ralim Stability Timer weirdness BLE quirks New screen driving / GUI handling Stability IronOS has had a rather slow development cycle on my side of things due to lack of time. The community around the project has been helping immensely however, which has kept things going. One aspect of this for the Pinecilv2 is that the newer release and onwards should have improved stability for the temperature regulation.\nTimer weirdness There is a bit of a trifecta of issues going on that caused some of the temperature issues; the timer hardware in the BL702 chip being used occasionally doesn\u0026rsquo;t trigger an interrupt. This causes things to go out of whack as the temperature sensing and the tip drive get out of sync. In the prior release these were occurring fairly frequently but after adjusting some of the timer settings they were reduced.\nWhen investigating this, one of the issues uncovered was that it appears to be related to BLE support, as removing BLE entirely from the firmware does prevent these issues from showing up. I can\u0026rsquo;t conclusively say that the BLE firmware is to blame as there is a fair bit of churn when that is toggled on/off when building the firmware. However its likely something to do with its hardware or software requirements that was the root cause here.\nThe newer IronOS software detects when this has occurred and recovers more gracefully, so there shouldn\u0026rsquo;t be any real impact to tip temperature.\nNew Screen Driving / GUI Handling In additional news, this will not effect any users, but the entire UI rendering code has been updated. The code is moving to being a non-blocking style of rendering to allow separating any logic around what is going on from drawing the display. The goal is that this will allow for full bluetooth remote control of the device if desired (will be Opt-In of course due to safety). This could be used for other devices to be used as a larger display, and using them to start/stop the device.\nNew from Ralim Author: Ralim While I do not have much to say about things I\u0026rsquo;ve been working on yet I do want to note that there are projects that I\u0026rsquo;m working with Pine Store to see if they are viable. Nothing concrete yet as still unsure on financial \u0026amp; technical viability yet but some things are taking shape.\nQuartz64/RK3568 A few patches from dsimic are now merged in Linus\u0026rsquo; tree:\narm64: dts: rockchip: Fix the DCDC_REG2 minimum voltage on Quartz64 Model B Correct the specified regulator-min-microvolt value for the buck DCDC_REG2 regulator, which is part of the Rockchip RK809 PMIC, in the Pine64 Quartz64 Model B board dts. According to the RK809 datasheet, version 1.01, this regulator is capable of producing voltages as low as 0.5 V on its output, instead of going down to 0.9 V only, which is additionally confirmed by the regulator-min-microvolt values found in the board dts files for the other supported boards that use the same RK809 PMIC.\narm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC dtsi Add support for voltage ranges to the GPU OPPs defined in the SoC dtsi for Rockchip RK356x. This is, for example, useful for RK356x-based boards that are designed to use the same power supply for the GPU and NPU portions of the SoC\narm64: dts: rockchip: Update GPU OPP voltages in RK356x SoC dtsi Update the values for the exact Rockchip RK356x GPU OPP voltages and the lower limits for the GPU OPP voltage ranges, using the most conservative values (i.e. the highest per-OPP voltages) found in the vendor kernel source\nPineTime Author: JF When I\u0026rsquo;m browsing the web or reading chat rooms, I often come across interesting posts and messages: a new version of a PineTime related project, a nice blog post or social media post, a new idea, etc.\nI\u0026rsquo;m happy to share in this post some of the links and information I\u0026rsquo;ve curated over the last few months!\nPineStore announcement: small hardware change TL informed us recently that the SPI flash memory chip installed in the PineTime (XTX XT25F32B) is EoL (End Of Life) and that it will be replaced by another chip (BY25Q32ESWIG) for the next production batch of the PineTime.\nThis new chip behaves exactly the same than the old one, so very few code changes are expected. The most obvious change consists in supporting the chip IDs of the new module that are different from the old one. Other than that, both the new and old chip support the same command over the SPI bus.\nWe\u0026rsquo;ve already implemented those changes in the bootloader v1.0.1 and in InfiniTime v14.0.1.\nI\u0026rsquo;ve already provided these versions to the factory so they can start producting PineTime based on this new hardware. Note that you don\u0026rsquo;t need to update your current PineTime to those patch versions since they only bring support for this new chip.\nI strongly suggest developers from other PineTime firmware to check if their code need some changes to support this new hardware revision!\nInfiniLink InfiniLink, the companion app for iOS made a lot of progress since Liam took over the project a few months ago.\nInfiniLink now provides a new improved UI and supports the external resources (that contain fonts and pictures for watch faces in InfiniTime) and the weather and also integrates with Apple Health.\nInfiniLink 1.0.2 is available on the App Store and the newest version 1.1 is available on Testflight, the platform that allows iOS developers to publish beta versions of their software. It\u0026rsquo;ll be made available in the official App Store when a few bugs and crashes will be fixed.\nLiam told me he doesn\u0026rsquo;t have specific plans in mind for the future, but definitely would like to create a macOS app that runs on both Apple Silicon and Intel Macs. To be continued !\nBlog posts about the PineTime While browsing the web, I sometimes happen to find blog posts about PineTime and its ecosystem. Here are the posts that I would like to mention.\nThe first one titled \u0026ldquo;Programmable watches\u0026rdquo; details a few smart watches that can be reprogrammed by the user. The PineTime is mentioned among other hackable smart watches like the Lilygo TTGO T-Watch and the Bangle.js. It\u0026rsquo;s great to see that there are many options when it comes to hackable and open source smart watches!\nIn second one titled \u0026ldquo;Fun with PineTime Smart Watch\u0026rdquo; Julian reflects on the idea to use the PineTime as a fun and educative way to introduce children to programming and to FOSS ideas. He also provides many ideas of customizations and applications in which children can participate.\nRework of ITD Elara applied a complete rewrite of the InfiniTime abstraction layer in ITD. It\u0026rsquo;s based on a different Bluetooth library and allowed to integrate the new weather functionality. This rewrite will also allow to make ITD cross-platform in the future.\nLet me also take the opportunity to mention that Elara accepts donations on Liberapay for their work on ITD and many other FOSS projects!\nFlatpak package for Amazfish Jozef, a great contributor to InfiniTime and Amazfish (among other projects) created a Flatpak package for Amazfish. This will make the installation of this Linux companion app much easier for many users!\nThe package is available on Flathub.\nPineTime integration in MyGnuHealth MyGNUHealth is a Personal Health Record (PHR), an application that records and stores the health data and other information related to the care of a patient. MyGNUHealth is open source (GPL) and respects the freedom and privacy of the individual.\nLuis recently announced they were working on integrating the PineTime in MyGNUHealth. Since this post on Mastodon, the pull request was merged in the development branch and released in MyGNUHealth 2.20.\nThe super-power of open source What is open source? Why does it matter? Those are easy questions, but I honestly have a hard time answering them, especially in English which is not my first language.\nJulian (the author of one of the blog post mentioned above) sent the following message in the PineTime chat room which provides a very simple yet accurate answer to them by describing the super power of open source:\n\u0026ldquo;Having the power to customize is the super-power of open source and I want to be able to demonstrate that to everyone who sees the watch. (And I think we should work on making customization easier, so everyone can do it.) Awesome to be standing on the shoulders of those who made this possible. Thank you!\u0026rdquo;\nI think this is a really nice way to define the open source philosophy: users are empowered to customize the software they are using!\nHere are the picture JulianF posted in the chatroom to demonstrate that super-power:\nIn this case, the customization consists in adding the owner name (\u0026ldquo;pine time\u0026rdquo;) to the watch faces. It\u0026rsquo;s simple but effective!\nFeel free to have a look at his repo and his website. Thanks Julian for the kind words and for reminding us why open source is important!\nInfiniEmu Felipe introduced InfiniEmu a few weeks ago. InfiniEmu emulates an ARM Cortex M4 CPU capable of running InfiniTime.\nIt basically emulates the hardware of the PineTime smartwatch (the MCU itself - the nRF52832 and its ARM Cortex M4 core and peripherals - the accelerometer, the touch screen controller, the heart rate sensor, the display and the SPI flash) to run the unmodified InfiniTime firmware on your computer and even in your browser.\nI\u0026rsquo;m really impressed by this project and, even if its description says that it isn\u0026rsquo;t production ready by any means, and the emulation almost definitely doesn\u0026rsquo;t completely match a real device, it\u0026rsquo;s already very usable.\nTo be honest, I don\u0026rsquo;t know how this project achieved such a feat! But it\u0026rsquo;s a great opportunity to learn new things!\nNow that I see it running, I can think of many use-cases for InfiniEmu: it could be used to add automatic testing, to provide more runtime information about resources (CPU and memory) usage, help with low level debugging,\u0026hellip;\nTo my knowledge, InfiniEmu is the 2nd project that allows running InfiniTime on other targets (mostly development computers) than the actual PineTime. This is really interesting because both projects follow different approaches.\nInfiniSim rebuilds most of the InfiniTime code and replaces a few parts so that it runs on a Linux desktop. It\u0026rsquo;s very easy to build and use, and allows developers to very conveniently build new applications and UI elements for InfiniTime.\nOn the other hands, InfiniEmu emulates the whole hardware so that it runs the very same binary file than the PineTime (it does not need to be rebuilt to target the x86 architecture, for example).\nInfiniTime Status Core developers of InfiniTime are quite busy with their private life, family, work on other projects right now, which is probably the main reason why InfiniTime haven\u0026rsquo;t released a new version these last few months. But don\u0026rsquo;t worry, they are still working on the project, reviewing pull-requests and fixing bugs!\nI would like to highlight the feature I (JF002, the original author of InfiniTime) am focusing on right now: the always-on display. This feature, contributed by John Crawford (KaffeinatedKat) and mark9064 implements a new always on display mode, which, as the name implies, keeps the display always on. In \u0026ldquo;sleep\u0026rdquo; mode, instead of fully switching it off, the display is kept on with a very low brightness. This allows you to have a glance at the time much more easily and reliably than when using other wake options like pushing the button or raising the wrist.\nThis feature obviously comes with a trade-off: the battery life is significantly reduced. According to Mark9064 and to my own tests, it lasts for 2 to 3 days in this mode, which is, in my opinion, quite reasonable knowing how much current the display uses when it\u0026rsquo;s powered on!\nI can\u0026rsquo;t thank Mark9064 enough for their work and patience during the review process: the always on feature is actually the tip of the iceberg. In order to make this feature possible, a few changes in low-level drivers (SPI, display, brightness management) and InfiniTime (refresh management of the UI) along with a few other improvements were needed. All those changes needed to be carefully reviewed and tested. We also experimented with multiple implementations of some changes to pick the one that would use the least power possible.\nAll those required changes are now integrated in InfiniTime. So now, all we have to do is to review the last pull-request: the one that actually adds the always-on feature!\nStay tuned for InfiniTime 1.15. ;-)\nPineDio Author: CarbonatedCaffeine Pine64 has a line of LoRa boards under the \u0026ldquo;PineDio\u0026rdquo; name which unfortunately launched at a bad time as the Meshtastic project was in it\u0026rsquo;s infancy at that point around 2020-2021. Now it has become a much bigger project and we have interest in improving support for the PineDio USB adapter on Meshtastic.\nWe are looking for people interested in Meshtastic and LoRa to help with the PineDio USB Adapter as it needs a stable driver for users to easily use the device.\nIf you\u0026rsquo;re interested please come visit the Pine64 LoRa channels or join the Meshtastic Discord server.\nCommunity Updates Infrastructure and Moderation For a while now, our community manager Gamiee has been taking on the work of keeping all of the community servers an services up and running as well as trying to moderate the online chat\u0026rsquo;s. Due to increased his day-job workload he is handing over the mantle of the community moderation to some others of the community. Namely our new community committee who are slowly transitioning to help look after the community. Gamiee will continue to look after the infrastructure of the Pine64 website and services.\nLomiri on PostmarketOS Author: CarbonatedCaffeine Community member Blume has been building PostmarketOS images with Lomiri for various devices like the PinePhone and PineTab and would appreciate feedback and testing. You can find his images here.\nGTK3 inspired watchface Author: CarbonatedCaffeine Community member M​orsMortium designed and created a series of watchfaces inspired by the GTK3 interface style. It includes widgets for the weather along with days of the week and numbered battery status among the rest.\nYou can check it out here along with instructions on installing it on your PineTime in the README. Contributors welcome!\nWant to contribute to the next community update? Do you have a cool project that you\u0026rsquo;re working on you\u0026rsquo;d like to be mentioned? Is there something you\u0026rsquo;re interested in that you\u0026rsquo;d like to write about related to Pine64? Something we\u0026rsquo;ll be doing going forward is a spotlight for projects within the Pine64 community. If you\u0026rsquo;re interested please contact us!\nCamden/CarbonatedCaffeine: @carbonatedcaffeine (Discord) @endernightlord:matrix.org (Matrix) ","permalink":"/2024/10/02/september_2024/","tags":["ironos","pinecil","pinephone-pro","pinephone","pinetime","pinenote","pinetab-v","bl702","quartz64","oz64","starpro64","quartz64-zero","pinedio"],"title":"September Update: Check Your Notes"},{"categories":["ironos","pinecil","pinetime","pinevox","cluster"],"contents":" Banner artwork: Caffeine\nNew products in development Authors: Ralim, gamiee As probably one of the most anticipated sections of the blog, we can confirm that there are more new products in the pipeline.\nThe first two were shown at the FOSDEM table in Feburary.\nPineVox - Virtual assistant The PineVox is a BL606P based home assistant smart speaker. Designed to help build a good community option for voice interactions with software such as Home Assistant.\nCurrently a small number of developer seed units have been given out. Work is ongoing by Ralim \u0026amp; Gamiee to get a minimal firmware image ready to allow for demonstration and to prove all hardware fully functional etc.\nMore information on the unit should be available soon on our new documentation page. Features of note include the hardware microphone kill switch, and the ability to debug the unit externally. The hardware microphone killswitch allows the software to mute the microphone but unmuting has to be performed using the button on the device. Muting the microphone disables the clock connection to the microphone, giving peace of mind that it really, really isnt listening to you.\nGiving users control of the smart devices in their home and allowing for you to control the security is important, and we are working on the PineVox to help enable that future.\nAnother notable aspect worth mentioning is the speaker. Designed specifically for voice applications rather than music playback, it ensures clear and high-quality voice audio reception.\nBone conduction headphones These are a set of bone conduction headphones using the same BES2300 chipset as found in the PineBuds Pro. The plan is to expand OpenPineBuds project with support for these before they enter manufacturing. Currently there is amazing work going on to sort out licencing of the BES2300 codebase; so work to support these is being done carefully to minimise impact on the code base.\nThe enclosure design is not final yet, nor is the software complete. However in the interests of being open, this is the current design.\nI am hoping that we will be able to post another update soon once the hardware in finalized, we\u0026rsquo;re really excited to show off the final project.\nWe need a name! As you might have noticed, there is no name for this product, so we\u0026rsquo;re reaching out to the community for suggestions! Share your name ideas on Reddit and Mastodon. In the next update, we\u0026rsquo;ll select the best one, and the author will receive a free unit!\nIt\u0026rsquo;s been a while\u0026hellip; Allwinner It has been a while since we have released a product with an Allwinner SoC, the last one was with the PineCube that released in 2020. But that\u0026rsquo;s going to change soon, as PINE64 is collaborating with YuzukiHD, an organization who have made several SBCs, such as the Yuzuki Chameleon (Allwinner H616) and Yuzuki Lizard (Allwinner V851S). So in the upcoming months, the Pine Store plans to manufacture and sell new YuzukiHD\u0026rsquo;s SBCs with the Allwinner H618, V851S, and a brand new SoC, the Allwinner A527, which is looking very promising. The A527 is finally using a more modern ARM CPU core Cortex-A55, in cluster 4xA55@1.8GHz + 4xA55@1.4GHz. The GPU is has also been upgraded to an ARM Mali-G57 MC2. A suprising addition is an eDisplayPort, along with a single-lane PCIe 2.1 controller, but sadly, it\u0026rsquo;s shared with the USB 3.0 controller, so we can\u0026rsquo;t have both at same time. The main down-side is that we are still limited to only 4GiB of RAM. Still, this SoC is very promising and it will find it\u0026rsquo;s usage. For more information, take look at linux-sunxi.org A523 SoC Page.\nIronOS Author: Ralim Hello,\nIronOS released 2.22 as the last majour release since the last blog posts. Work has of course started on 2.23, though this is still ongoing.\nThe two large improvements for the Pinecilv2 are improved temperature stability as well was support for boot up logos.\nThese both have been a bit long time coming but are finally here; boot up logos can now be generated using the tooling in the Meta repository using the instructions on the main docs page.\nThe blisp command line tool for flashing buffalo devices was updated to support .dfu files to enable this, as due to the way logos are programmed to the device partial flashes are required.\nA small note about the boot up logos In order to keep the code base for IronOS easier to maintain, so far I have not implemented USB support on any of the devices.\nThis was originally fueled by not having a huge amount of flash space on the first generation devices (Pinecil V2 is the exception here), however it is now largely to reduce complexity.\nThis is the root cause of the boot up logos requiring a custom conversion tool; the tool is actually converting the image you pass into the flat binary representation the device\u0026rsquo;s OLED screen uses. This means that the device does no image processing, but just pushes this binary buffer directly to the screen.\nA later edition was to support animated boot up logos as well; this expanded the logic to allow for multiple frames which are either encoded as entire images or delta encoded (which ever results in smallest code).\nThe binary blob of data that this process emits is then flashed near the end of the flash on the device. This is why blisp had to be updated to allow for partial flash operations. I added .dfu files as they are very trivial format, and simple to add handling for them into the code base.\nThe logo generation has been expanded to support the Pinecilv2 model, which will cause a .dfu file to be generated at the correct offset for the large flash fitted to the Pinecil V2.\nHuge apologies for the delay this took getting fully functional, but its here now to stay; and blisp is all the better for more support.\nThe flashing tool Pineflash by Spagett1 has already been updated to support flashing these files.\nTuning the tip temperature control After some earlier fixes to how the temperature regulation code was run on the Pinecil v2; there was the unfortunate outcome that this de-tuned the tip temperature control. After a bunch of testing different tuning profiles and none being consistent across all tips I\u0026rsquo;ve gone back to the roots of the code and pulled back in the old PID controller. This has now been tuned to work fairly well on all the tips I have here.\nThis means that 2.22 should bring us back to nice; clean temperature control of the tip. Of course if you find any instability I\u0026rsquo;d love to hear about it as an Issue or discussion on GitHub.\nDesktop \u0026amp; Mobile apps I take no credit for the awesome BLE enabled apps in our community; but huge shout out to them.\nWe have new multi-platform app (currently Android \u0026amp; iOS) made in Flutter by amazing Aguilaair, and thanks to the Pine Store providing us developer accounts for both platform stores, you can download the apps right now from App Store and Google Play.\nIf you prefer native apps, there is native app for iOS PineTool from Lachlan Bell.\nFor desktop, you can use PineSAM by Builder555, and BLE browser API by Joric.\nThese are amazing resources to use when tracking down issues, but are really aimed at giving you remote control and a second screen for viewing the status of the device.\nFor those of us (myself included) that love to integrate everything into Home Assistant, T3chguy has gone the extra step and made an integration that can be enjoyed as well.\nPineTime Author: JF002 As always, FOSDEM was a nice opportunity to meet with community members, users and contributors of the PineTime project. And just by looking at the number of people proudly wearing their PineTime on their wrist, I can safely say that the PineTime project is still very popular, more than 3 years after it was created!\nI had a lot of interesting discussions with many many visitors on the stand. People would explain how they use their PineTime (and the Navigation app) for biking, how they would like to modify InfiniTime to use it for sailing, ask question to use it on a university course and many other things. All of this is made possible by a nice hackable device and an awesome open source community\nUsers are mostly happy and thankful regarding InfiniTime : it works, it fits most of their needs, and they enjoy discovering the improvements that are added releases after releases. Regarding feature requests, I noticed 2 main trends. On one side, users want more advanced features like health and activity tracking, and on the other side, they would like to see some quality of life improvements integrated in InfiniTime.\nInfiniTime also received some fair criticism from contributors : they feel frustrated by their PR that are sitting there with no comment or review for a long time. The lack of clear roadmap was also mentionned.\nOne more thing about FOSDEM : this year, two talks about the PineTime were organized : PineTime: A Programmer\u0026rsquo;s Toy and Beyond and Smartwatch firmware\u0026hellip; in Go? On TinyGo, small displays, and building a delightful developer experience.\nAt the beginning of the year, the InfiniTime team released InfiniTime 1.14. This new version brings among other things new memory optimizations, improvements to the raise-to-wake algorithm and a new lower-to-sleep algorithm.\nThe team also worked on a new implementation of the weather feature : the Simple Weather Service.\nThis re-design of the feature was necessary to fix some issues of the original one : it would use too much memory, it would crash under certain conditions and the integration was not easy for companion app. This new implementation is the result of the collaboration between developers from InfiniTime and from companion apps. We tried to define a new BLE protocol that would fit our need and then implement it in InfiniTime and companion apps. To my knowledge, it\u0026rsquo;s currently integrated in Amazfish and Gadgetbridge, and we hope that it\u0026rsquo;ll be integrated in other companion apps soon!\nInfiniTime is a monolithic firmware : everything must be built into it at compile-time. Support for \u0026ldquo;dynamic applications\u0026rdquo; that can be installed at run-time is a long term goal, but we\u0026rsquo;re not there yet. In the meantime, we introduced the compile time configuration of applications and watchfaces. Developers can now easily specify which apps and watchfaces will be built into the final firmware image. We might use this in the future to add more appliations and watchfaces to InfiniTime, and maybe provide multiple variants of InfiniTime, each with a different set of applications and watch faces.\nOn the InfiniSim side, Victor added support for the weather feature. This feature generates random weather data and forecast in the simulator to help testing the weather integration in InfiniTime. Good job!\nInfiniLink, the iOS companion app found a new maintainer : Liamcharger took over the project and will continue its development. This is a very great news for PineTime users using Apple device. They can expect InfiniLink to receive update and new features in the near future!\nLiam has already done some work on the project. For example, he re-designed and improved the UI, added support for the weather and for the external resources.\nFinally, I would like to mention GopherWatch, the PineTime firmware written in Go. I had to chance to talk with Ayke, this author of this project, and to see the firmware running on the PineTime and it\u0026rsquo;s very nice!\nThe font rendering on the display is very nice, it features very smooth scrolling animation, supports display rotation, and allow a month long battery life, which is absolutely amazing!\nPineTab2 Author: Caffeine For this month’s community update I talked to Danct12 from the Danctnix project concerning the current state of the device.\nHardware/software status At this stage the camera is nonfunctional due to support for Rockchips ISP (Image Signal Processor) not being in mainline yet. There is no USB-PD driver yet. A new BES Wi-Fi/Bluetooth driver is now included in the kernel. H.264 video encoding/decoding driver isn’t in the kernel yet. Since the last update on the PineTab2, Danct has been planning to send a new updated Arch image to the factory along with starting work on a first-time setup screen which will allow users to set a user and password.\nAlso, for current users of Danctnix/Arch Arm, an issue has been discovered with the pacman db lock file which has been stopping users from updating their system using Discover. If you are are having trouble with using Discover to update your system, try deleting /var/lib/PackageKit/alpm/db.lck.\nWifi/Bluetooth driver BES have been working on an improved driver for Wi-Fi and Bluetooth stability. It is currently in the kernel, but is disabled by default. PLEASE NOTE: At this stage the driver is in beta, it cannot handle sleep/suspend modes and will hang if you do not turn Wi-Fi off before shutting down. Proceed with CAUTION.\nYou can enable the beta driver by typing sudo modprobe bes2600 in your terminal. If you wish to turn off the driver again you can use sudo modprobe -r bes2600.\nConclusion We are hoping that support for the Rockchip ISP and H.264 driver will land soon and we’re glad to see the situation with the Wi-Fi driver is improving. Overall, the PineTab2 is shaping up to be a solid device in the Pine64 hardware lineup.\nPineNote Author: Ralim Please note that this section is written by Ralim. I am not a staff member of Pine64, but I want to represent the state of the Pinenote as best to my knowledge.\nDuring FOSDEM the current state of the Pinenote was available for people to interact with (and also to show the device does exist).\nA huge amount of work has been done by Maximilian to bring up a working Debian/Gnome environment and continued refinement has seen this software maturing significantly. Currently a lot of work is being to track down and resolve artefacting issues that have been cropping up on the open source driver. Recent efforts have reduced these significantly however some work remains.\nThe OS image has also been updated to build upon Debian Trixie, this has improved the situation with bluetooth along with the update.\nCurrently more testing is desired to help find remaining bugs and resolve first-use bugs with the OS. If you have one of the earlier developer batch units, it would be highly appreciated if you could help out Maximilian with testing the images.\nWhat exactly happened with the cluster Author: gamiee On the 20th of January 2024 at 10:30 PM CET, most of the DB based services went down and started throwing errors when attempting to connect to the MySQL databases. After some analysis, all of the nodes in the cluster had failed, making the rootfs mount as read-only. In the current cluster setup every node has its rootfs mounted over the network, this leads to one likely culpret, that something had gone wrong with the storage node. I wasn\u0026rsquo;t able to connect to the storage node, so I went to the datacentre where the cluster is hosted. Once on site, I found that the storage node\u0026rsquo;s SSD (which hosts all of the data for the other nodes) had switched to read-only mode reporting issues about writing to SSD. Thankfully as the temporary cluster is only a small number of nodes, I took it home so I could recover the data. Before the shutdown of remaining cluster nodes, I took a moment to make a screenshot of the main node\u0026rsquo;s (gateway \u0026amp; firewall) uptime:\n2 years and 4 months of non-stop service, handling all the traffic of PINE64 community services. One of the reasons behind having a custom cluster was to show-off the stability and reliability of PINE64 SBCs, and I think the cluster fulfilled this perfectly.\nThe next morning (21st of January 2024), I prepared a new VPS and got Matterbridge running, which is the service that bridges between Telegram, Discord, Matrix and IRC. Afterwards, I wanted to have at least the main website working, and as the new website is based on the Hugo framework, which generates a static website, I deployed it on the new VPS (Thanks to Funeral for all the help). This was significantly faster to get set up for hosting than to bring up the old website. But since we also self-host IRC, the next step was to get IRC back online as soon as possible.\nAs we are rebuilding the large cluster, we are planning to use Kubernetes to manage scheduling the workload across all of the nodes. To help with the future migration of services to the new cluster, I decided that as I restored all the services, I would set them up to run in Docker containers. So 3 days later, I managed to bring the whole IRC server online with data from the latest backup (which was from December). This took longer than I expected, as I had a lot of work at my daily job. I also needed to create my own Docker image for unrealircd, as there isn\u0026rsquo;t any good one (Thankfully, anope have official Docker container).\nThe following days were all about analyzing what happened with the SSD and how to recover the data, rather than relying on stuff from backups. But this took longer than I expected, due preparations for FOSDEM and also more work at my daily job. Thankfully, I was able to restore the data from the SSD, the wiki, forums and files were then restored 31st of January 2024.\nCurrent state of services Main community website (www.pine64.org): Since the new Hugo website seems to already be in a good shape, we decided to keep it as our main website. Some things are still missing or unfinished, such as the newsletter, comments, and some pages still need more polishing, but we will work on all of this in the upcoming months. Wiki (wiki.pine64.org): After the wiki was recovered on the new machine, it started to misbehave, throwing weird errors on some actions. Because of this, we put the wiki in read only mode. The decision of what will happen to the wiki is still unknown, since we have a replacement (www.pine64.org/documentation) which is part of our statically generated Hugo website. Forums (forum.pine64.org): Thankfully, the forums weren\u0026rsquo;t problematic and work very well, although, emails are not working, but we will try to get emails up and running as soon as possible. Files: Essential files such as schematics and documents were recovered, although, big files such as images and SDKs, are still not available. We are working with the Pine Store to bring them back in following months. Chat Bridge: Bridge (Matterbridge) Works as it did before. Pinecil Verify website (pinecil.pine64.org): Works as it did before. IRC Server: With IRC it was complicated, mainly because of the flood of spam messages and Docker network misbehaving between UnrealIRCD and Anope. Anope was configured to save data into flatfile, so the IRC configuration was lost multiple times. We migrated to db_sql_live together with MySQL DB Backend, and applied a rate-limit to fight with spams (thank you Danct12!). Although, since the spammer always finds a way to bypass our limits, in every channel except main one (#pine64) you need to be registered to send messages, and registrations are manually reviewed. If your account is not confirmed within few days, please ping me (@gamiee) on any platform. CedarSentinel (Anti-Spam system): CedarSentinel is a service, which was created by (currently retired) PINE64 Sysadmin fire219 to detect and remove \u0026ldquo;casual\u0026rdquo; spam, such as crypto offers from Telegram, with the help of Machine Learning. Thanks to the community member kj7rrv, CedarSentinel is being re-trained and it\u0026rsquo;s already deployed on new VPS. By the way, CedarSentinel is open-source, and you can check it out on Github! Moment for appreciation As it was mentioned earlier, community services are now up and running on a VPS to keep everything stable until I have some time to finish getting the main cluster working again. While choosing where to purchase the new VPS from, I recalled a host that is very similar to our community, they are community driven by Linux enthusiats.\nI looked into VPSfree.org, a non-profit association located in Czechia, which provides their members virtual servers for a great price. They are using their own operating system for virtualization vpsAdminOS, together with many other tools, which are all open-source. I have been a very big fan of them for several years, and I am very thankful for the help and support that they have provided us. So, if you are looking for a cheap and good VPS, consider taking a look at their offerings.\nI want to say a huge thanks to fire219 for all the hard work he\u0026rsquo;s put into PINE64 Community Services, as he stepped down as sysadmin in August 2023. fire219 has been part of our community for many years – even before I joined in 2018! He\u0026rsquo;s been taking care of things like the Forums, Wiki, IRC, CedarSentinel, and a bunch of other stuff. Thanks you for everything, and best of luck with whatever comes next!\nAlso, I want to give a big thank you to all who have helped with our community services in the past. Special thanks to Danct12, dsimic, Funeral, kj7rrv, PaulFertser, Phiten, and Ralim for all their contributions.\nWhat\u0026rsquo;s next We still plan to host our services on the cluster, but before that, we need to fix some issues, which the previous cluster had. But for those who are only just learning about the cluster for the first time, let me start from the beginning.\nIn 2019, we received from the Pine Store a custom-built cluster, which consits of a server case, TP-Link switch, server power supply, 24x RockPro64s and 3x special PCB for node power control.\nIn September 2021, I wrote the blog post, about building the new \u0026ldquo;temporary cluster\u0026rdquo;, and exchanging it with the \u0026ldquo;final one\u0026rdquo;. I recommend reading the blog post, it explains a lot about the cluster and the reason we moved to the temporary cluster. In short, unfortunately, the cluster was deployed in a hurry, and things like power management for the nodes were not finished. For proper implementation, it would have been best to have had the cluster at my place, so a temporary cluster was built. (The temporary cluster was in the server housing until the failure)\nSadly, life got busy, and there was not a lot of progress on the cluster until 2023. Me and Ralimtek started working on a new PCB, which will serve as the \u0026ldquo;motherboard\u0026rdquo; of the cluster. This is for managing the power supply, communication with power management boards and a UART output logger for all nodes. For the first revision, this board was designed as a daughterboard for SOPine A64 Baseboard, the final version will be a PCB that will house a SOPine A64 module. A few weeks ago, I managed to assemble the daughterboard and perform some tests. Aside from some very minor issues, the board works pretty well!\nIn the following months, we will start work on the software side, which will be a buildroot filesystem with software for remote access of the cluster. We will provide more information about this effort, most likely in a separate blog post.\nFuture of community updates Author: gamiee Monthly updates were an essential part of the community for a very long time, so not having them was indeed very damaging. That\u0026rsquo;s why it was priority #1 on our topics to discuss at FOSDEM 2024. Thankfully, we have a new plan with getting updates released again. We still aren\u0026rsquo;t sure if it will still be on a monthly basis like it used to be, but it will be periodically released. Not only that, we are planning on improving community engagement and moderation. We will explain our plan further in following updates.\nLet\u0026rsquo;s do an Q\u0026amp;A As it has been a very long period without any updates, along with proper community engagement, we have decided to organize a Q\u0026amp;A! The community is free to ask any question that they may have! As in previous times, we will be using Discord Stage to host the Q\u0026amp;A, which will be streamed to YouTube and (hopefully) PeerTube. But this time, the place for asking the questions will be on Reddit and Mastodon. When we used Discord, Telegram and IRC for questions, there were many duplicates, it was hard add reply to the questions (like a link to stream with timestamp) and it was impossible to sort through. So before asking any questions, please take look if your question has been asked already, and up-vote questions you would like to be answered! So see you there at 22th March 2024 at 7:00 PM CET (10:00 AM PST, 1:00 PM EST). You can ask questions here on Reddit and Mastodon.\n","permalink":"/2024/03/17/march-update-making-waves/","tags":["ironos","pinecil","pinevox","cluster","pinetime"],"title":"March Update: Making waves"},{"categories":null,"contents":"We regret to inform you that we are currently experiencing an outage in our main cluster. We are currently actively investigating the cause of this issue. We understand the inconvenience this may cause and appreciate your patience during this time.\nIn the meantime, we have deployed a beta version of our website to ensure that information are still reachable for the community. Please note that this is a quick and temporary solution - bugs are expected and the documentation pages are not structured yet and might be outdated and not reflect the current state of the wiki, which is affected by the outage as well.\nThank you for your understanding!\n","permalink":"/2024/01/21/outage_january_21/","tags":null,"title":"Outage January 21st"},{"categories":["community","news","pine64-community"],"contents":"\nWe apologize for the lack of regular community updates during the past few months. In short, the people who usually wrote them became very busy. However, we have a new way to write and publish these updates, involving you: the community.\nLet\u0026rsquo;s talk about it, and about so much more of what\u0026rsquo;s been happening.\nThis community update consists of contributions by Caffeine, CounterPillow, Funeral, gamiee, JF002, and mpreditor.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nTL;DR Housekeeping Community updates are now written collaboratively by several members of the community The public is invited to contribute to the monthly update posts Rework of the community website and logo Newsflash megi released rk2aw: a loader for your bootloader Progress on the PineTab2 and PineTab-V A PinePhone Pro connected to a thermal imaging camera Oren Klopfer\u0026rsquo;s progress on Ubuntu Touch Quartz64 and SOQuartz U-Boot improvements thanks to Kwiboo and CounterPillow: USB, NVMe, and soon PXE Improved SOQuartz CM4 baseboard compatibility Improved PCIe devices compatibility QuartzPro64 What it means to \u0026ldquo;mainline\u0026rdquo; things, and why it takes time Things that have been mainlined: SATA, PCIe, USB, AV1, and more! Things still being worked on: cpufreq, GPU, video output InfiniTime 1.13 and other PineTime news Heart rate monitoring improvements thanks to Ceimour! Did you know that InfiniTime has a BLE weather service feature? Improved memory management Huge improvements to battery life (with help from Ayke!) InfiniSim UI update Improvements to ITD, the InfiniTime daemon Ayke is developing a brand new firmware for the PineTime Housekeeping You might have been wondering why nothing new has been posted on the PINE64.org community blog in quite a few months. As was already revealed in the opening section, the reason is that previously blogs were mainly authored and edited by one person (Lukasz) and said person is extremely busy these days.\nGoing forward, these monthly community update posts will be written collaboratively by the community for the community. To that end, there is now a Git repository through which this work happens. You don\u0026rsquo;t need to be a good writer to contribute, you can submit links or short bullet lists and the editors will take care of the rest.\nThe plan is to have a post out on the 15th of every month. Whether or not this deadline will be met each month is another question, but now you can keep an eye on what\u0026rsquo;s happening behind the curtains and help out if necessary.\nSpeaking of deadlines, this update didn\u0026rsquo;t have a very long time in the proverbial oven despite the long period of silence preceding it, so it may be a little short or not cover all developments in the community equally well. Just because something is not covered in this post doesn\u0026rsquo;t mean it hasn\u0026rsquo;t been worked on.\nRework of the community website and logo If you missed the announcement, an initial rework of the community website was announced. The announcement blog post can be read exclusively on the new beta site.\nThe overall idea of the reworked community website is to move away from a WordPress site and to open up the site to contributions from all community members. This is done by hosting the website on Git and by generating the contents using the blazing-fast framework Hugo. Large parts of the website are created from simple markdown files, which are easy to understand and to edit. Alongside the rework of the community website, there was also a challenge launched, which has the goal of improving the appearance of the community logo. The details can be read under the logo challenge. Bring in your best ideas if you haven\u0026rsquo;t done so yet. Ideas are best submitted to https://github.com/pine64/website/issues/12.\nSince the last blog post, there has been various improvements made to the beta community website. The improvements include changes to the style of various sites, improvements to the front site slider and inclusion of more slides, rewrite of pages as markdown files (such as the index page), creation of more board graphics and many more changes.\nThe documentation for all PINE64 devices is also constantly improving. While there are large construction zones left, the overall look of the documentation is already quite clean and constantly improving:\nThe changes can be viewed on the repository under https://github.com/pine64/website. Give it a try by cloning the repository and previewing the page using Hugo:\ngit clone https://github.com/pine64/website.git cd website hugo server Newsflash megi released rk2aw: a loader for your bootloader First up, long-time contributor megi has released rk2aw, a sort of bootloader for your bootloader on Rockchip-based platforms. Instead of having to deal with the default boot order of SPI to eMMC to SD, rk2aw sits in your SPI flash and changes the order to prefer the SD card for booting from first, which is more tinkerer-friendly. Additionally, a simple LED flashing and button interface allows the user to choose which storage device the bootloader should be loaded from. The software also comes with some nifty additional features, like suppressing power-on when the PinePhone Pro is plugged in.\nOf PINE64\u0026rsquo;s devices, rk2aw supports the PinePhone Pro, Pinebook Pro, PineTab2, QuartzPro64, Quartz64 Model A and ROCKPro64, though it can theoretically be made to work on any RK3399/RK3566/RK3588-based device.\nProgress on the PineTab2 and PineTab-V Since the PineTab2 and PineTab-V tablets have been shipped, the community has been tirelessly at work, propelling the software landscape forward and unveiling an array of new software and bootable images for both tablet models.\nThe software releases section of the PineTab2 already lists Arch Linux ARM, Mobian, NixOS, postmarketOS, Rhino Linux, Ubuntu Touch and others, with more to come. The software releases section of the PineTab-V lists a Gentoo overlay, as well as a KDE Plasma Yocto build from the community member Fishwaldo, with even more in the pipeline.\nThere is also progress on the WiFi driver of the PineTab2. Some releases already ship with an initial support for the on-board WiFi chip. It is however important to note that the work on the driver is ongoing and has not reached a software maturity yet.\nThese software releases are a testament to the vibrant collaboration within the PINE64 community. Developers, enthusiasts, and users alike have come together to cultivate a thriving ecosystem that empowers PineTab2 and PineTab-V users with an array of choices.\nA PinePhone Pro connected to a thermal imaging camera The user yomboprime coupled a PinePhone Pro with the thermal imaging camera Topdon TC-001. Check out their nice video here: https://www.youtube.com/watch?v=lJhgZve9xSA\nOren Klopfer\u0026rsquo;s progress on Ubuntu Touch Another mention deserves maintainer Oren Klopfer, who is working on Ubuntu Touch support on numerous devices, including the PinePhone and PinePhone Pro, the PineTab and PineTab2.\nCheck out the supported devices under https://devices.ubuntu-touch.io/.\nQuartz64 and SOQuartz The RK3566 SoC that\u0026rsquo;s on the Quartz64 and SOQuartz line of PINE64 devices hasn\u0026rsquo;t had great mainline U-Boot support for the longest time. Technically, there was some vestigial support and an EVB (evaluation board) device tree, but it was far from optimal.\nFor those not in the know: U-Boot is somewhat of a mix between platform firmware (\u0026ldquo;BIOS\u0026rdquo; on your common x86 PC) and bootloader. It initializes the device\u0026rsquo;s hardware, and loads a kernel (usually Linux, though not necessarily so) to which it then hands control off to.\nKwiboo took it upon himself to improve the situation. Over the past few months, he\u0026rsquo;s enabled U-Boot on the RK3566 and RK3568 SoCs to load kernels and device trees off USB2, USB3 and NVMe. While U-Boot itself still has to be flashed to either SPI, eMMC or SD, it can now load your kernel and device tree from a wider range of storage devices.\nHe also submitted device trees and board configurations to mainline U-Boot for, among other things, the Quartz64 Model A, Model B, and SOQuartz. This will land in U-Boot version 2023.10, meaning with the next stable U-Boot release, distributions no longer need to carry around their own forks (unless they want to.)\nMeanwhile, CounterPillow has submitted an U-Boot driver for the YT8511 ethernet PHY that\u0026rsquo;s present on the Quartz64 Model A and SOQuartz. This, together with work Kwiboo is doing on a GMAC driver for the RK3566 and RK3568 SoCs, will allow users to PXE boot operating systems over the network. U-Boot\u0026rsquo;s default boot flow for these boards already tries PXE, so provided you have an U-Boot flashed to one of the supported storage mediums with all the moving pieces (GMAC and PHY driver) in place, PXE will work out of the box.\nThere are still some small changes needed to make U-Boot initialize a random seed for KASLR on these boards. KASLR (Kernel Address Space Layout Randomization) is a security hardening technique that randomizes the locations of code in memory, making it harder for attackers to execute a successful exploit. For this to work, kernels such as Linux require that the firmware passes it an initial source of randomness. The hardware random number generator on RK3566 already has a driver in U-Boot, it just needs to be enabled for all the boards.\nIt\u0026rsquo;s also worth pointing out that there is now improved compatibility on two fronts: CounterPillow wrote about fixing SOQuartz compatibility with some CM4 boards, and furthermore finally submitted a small fix to Linux to improve the RK3566 and RK3568\u0026rsquo;s PCIe device compatibility. There is some work left to be done, but many devices should just function as expected now.\nOne of the benefits of all this work is that if you\u0026rsquo;ve got U-Boot installed on your board, you can now simply boot generic aarch64 UEFI Linux distribution installers. Consult the wiki for more information if this piques your interest.\nQuartzPro64 There hasn\u0026rsquo;t been much talk of the QuartzPro64 on update blogs since it\u0026rsquo;s been sold to developers, but that doesn\u0026rsquo;t mean developers haven\u0026rsquo;t been busy. The SoC used on the board, the RK3588, has been making waves in SBC communities for its performance; CounterPillow can say from personal experience that it compiles Linux kernels 7 times faster than the Quartz64\u0026rsquo;s RK3566 processor.\nThe entirety of the work has in fact been focused on the RK3588 SoC (and associated chips, such as the RK806 PMIC), rather than the specific board PINE64 produced for developers. One of the main drivers of development are Collabora, a contracting firm specializing in open-source development. But you might be wondering what there is to even do, surely Rockchip did all the work, right?\nNot quite. There\u0026rsquo;s two different kinds of kernels, downstream vendor kernels and the upstream mainline kernel. The mainline Linux kernel is the Linux that sits in Linus Torvalds\u0026rsquo; git tree. Patches landing in this tree need to undergo code review by the respective subsystem maintainers, and rarely is a new driver merged without a few iterations of reviews and changes. Meanwhile, a downstream vendor kernel is (usually) forked off an LTS (Long Term Support) kernel release, and the hardware vendor then piles on patches to add hardware specific drivers and hacks. These vendor kernel change sets don\u0026rsquo;t undergo the upstream kernel\u0026rsquo;s review.\nAs you might have guessed, this often leads to less-than-ideal code being present in vendor kernels, not to forget they often don\u0026rsquo;t port it to newer LTS kernel releases as they become available. So what contributors like Collabora et al do is pick up code from the vendor kernels, clean it up (or write new code entirely, as is the case with multimedia or the GPU) and submit it to mainline Linux for review and inclusion. This takes a lot of work and a lot of time, as solutions only acceptable for vendor kernels often have to be generalized into solutions that work for all sorts of systems.\nDespite the odds being stacked against mainline contributors in this, significant amounts of work have already been completed. Today a mainline Linux kernel can be booted on RK3588 hardware with all 8 CPU cores (4x Cortex-A76 + 4x Cortex-A55) working, though not at their maximum frequency. Serial output works, as does the SD card thanks to new support for the often accompanying RK806 power management chip. eMMC has been working for a while, however new additions are SATA, PCIe2, PCIe3 and USB2. USB3 support is still undergoing review as of the time of writing. Smaller but still noteworthy recent additions are support for OTP (reading of one time programmable values fused into the silicon at the factory) and ADC (analog-to-digital conversion).\nThe most high profile recent addition would be the new driver for hardware video decoding of the AV1 video codec, of which most has been merged in Linux 6.5-rc1. This is an entirely from-scratch driver, implementing the v4l2-requests userspace API. The hardware implementation on the RK3588 processor supports decoding of up to 3840x2160 pixels in resolution video for this codec at 60 frames per second. With AV1\u0026rsquo;s complexity making software decoding strenuous on CPU resources, a hardware decoder driver for this more and more widely adopted codec is essential for multimedia capabilities for future Pine products potentially based on the RK3588 System-on-Chip.\nSpeaking of such products, the reason why we haven\u0026rsquo;t seen a consumer version of the QuartzPro64, or another RK3588 based Pine Store product, has likely been all the things missing from mainline Linux still. As already mentioned, the CPU cores with mainline Linux currently don\u0026rsquo;t run at their full potential. This is because no cpufreq driver has been submitted to mainline yet, which is required for reclocking the CPU. Unlike with some green colored products however, there is no technical reason as to why reclocking wouldn\u0026rsquo;t be possible, it\u0026rsquo;s just a matter of someone having to do the required work to create a driver that\u0026rsquo;s up to mainline\u0026rsquo;s standards.\nAlso missing is support for video output. This is separate from the 3D GPU, as the video output processor is a Rockchip-specific hardware implementation. This means that for the time being, serial and networking are still the only ways to interact with the board.\nSpeaking of the 3D GPU though, the RK3588\u0026rsquo;s GPU is a licensed design from Arm. Collabora is working hard on adding support for it in an open-source driver in Linux, which includes writing a new kernel driver. You can read about this driver, called pancsf, in Collabora\u0026rsquo;s blog post on the matter. The new architecture of the Mali-G610 GPU will allow for a fully featured Vulkan driver to be written for it in the future, something older generations of Mali GPUs had to awkwardly emulate parts of.\nInfiniTime 1.13 and other PineTime news (by JF) The InfiniTime team released InfiniTime 1.13 at the end of June. If you haven\u0026rsquo;t updated your PineTime yet, I strongly suggest you do it ASAP since it brings many nice features: a new heart rate algorithm, weather integration in PineTimeStyle (PTS) watch face, new memory management, and a (much) improved battery life! Let\u0026rsquo;s dive into the details of this release!\nThe heart rate sensor is integrated in InfiniTime for quite some time now (since 0.11.0, actually). It worked but fine but\u0026hellip; we had the feeling that it could work better if someone had the opportunity to have a look at the code. Ceimour did a great job redesigning and mostly rewriting the whole heart rate processing algorithm. I\u0026rsquo;m not experienced enough in digital signal processing to explain all the internals of this new algorithm, so, if you are interested in the details, please see the explanations Ceimour provided in the PR here and here. All in all, it now takes less time to display the first measurements, and they are now updated much faster than previously.\nHere\u0026rsquo;s a video I shot when I was testing this PR. It compares the HR implementation of InfiniTime 1.11 (sealed PineTime on the left) with the new one (devkit on the right).\nDid you know that InfiniTime implements a BLE weather service since InfiniTime 1.8.0 ? This service allows companion apps to send weather forecast to the watch. Since then, all we were missing was a nice UI to display those information. Thanks to Kieran, the author of the PineTimeStyle watch face, weather forecast can now be displayed in PTS.\nThis integration currently works with Gadgetbridge and ITD. You\u0026rsquo;ll find documentation about the PTS watchface here and about the weather integration here.\nHowever, since the release, several users reported that the new weather feature might cause some instabilities in InfinITime: crash, unexpected reboot and font corruption. You can read more about this issue here. If you are impacted, I would suggest you disable the weather feature from your companion app until we implement a fix.\nMemory management is a important topic for the InfiniTime developers. The PineTime only has 64KB of RAM memory available and we have to use it wisely. We also try to optimize the memory usage of the firmware so that we can continue to add new features in InfiniTime. And the new memory management aka \u0026ldquo;the heaps unification\u0026rdquo; is one of these optimizations.\nWithout going into too much details, we figured that the RAM memory in InfiniTime was split into 4 parts: the memory that is statically allocated at build time, and 3 regions that are used to dynamically allocate memory at runtime. Those 3 regions (or heaps) are managed by LVGL (the UI library), FreeRTOS (the OS InfiniTime is based on) and the standard C++ library. The goal of this change was to unify those 3 heaps into a single one (the one managed by FreeRTOS). This allows to reduce the overhead generated by those 3 heaps and it also give us a better overview of how the memory is actually used and how much memory is still available.\nPINE64 advertise the PineTime with a \u0026ldquo;week-long battery life\u0026rdquo; and they are correct: the hardware is perfectly capable of achieving that. And InfiniTime isn\u0026rsquo;t too far off the mark: in my use case (BLE and wrist wake option enabled), I usually need to recharge my PineTime every 3 to 5 days, and the battery life can be extended by disabling wake options and BLE.\nWe were however pretty sure that we could achieve better results with some optimizations that consist mostly in disabling most of the parts of the MCU when it\u0026rsquo;s idle.\nRecently, Ayke (GitHub, Mastodon) shared their findings and measurements regarding power usage of the PineTime on the wiki and with the InfiniTime community on GitHub: they optimized their firmware to reduce the power usage down to 66µA. With such power usage, the PineTime could run for more than 3 months on a single charge! Obviously, to reach such power consumption, most of the device is put in sleep mode, but that\u0026rsquo;s a great achievement knowing that, for example InfiniTime uses 1.1mA in sleep mode with BLE enabled!\nSo we tried to apply Ayke\u0026rsquo;s suggestions in InfiniTime, and the results were also really good: we went from 890µA in sleep mode down to ~200µA with BLE enabled! And a bit less with BLE disabled!\nMost of those changes are now integrated in InfiniTime 1.13, and a many users have already reported between 10 days and nearly 20 days of battery life (depending on the features that are enabled: wake up options, BLE, display timeout,\u0026hellip;)! My PineTime worked for just over 16 days in my normal use! I\u0026rsquo;m honestly impressed by those results, and I hope you\u0026rsquo;ll also notice an nice increase in the battery life of your PineTime!\nOther news from the PineTime community Since we haven\u0026rsquo;t been able to publish a PINE64 community update for quite some time now, let me share a few other news from the PineTime community!\nInfiniSim, the InfiniTime simulator, recently got a UI update that makes the status window much easier to understand: it displays the status of the (simulated) BLE connection, display brightness, charger, battery and alarm.\nITD, the InfiniTime daemon also got a nice update in version 1.1.0 which, among other things, brings a new UI theme, an improved protocol between the daemon and the clients and the support for FUSE. This new feature is quite amazing in my opinion: it allows you to mount the file system of your PineTime into your computer file system. You can now browse the content of the 4MB external memory using your file explorer, for example!\nAyke is not only working on power optimizations : they are building a new firmware written in Go. They focus on power usage obviously, and also on fast and responsive UI. The project is at its very beginning, but it\u0026rsquo;s already very promising!\n","permalink":"/2023/08/15/august-update-kept-you-waiting-huh/","tags":["community"],"title":"August Update: Kept You Waiting, Huh?"},{"categories":["news","pine64-community"],"contents":"Welcome to our long-awaited community post, where we aim to address the most commonly asked question while also unveiling some more news. Let’s get started!\nWhy hasn’t there been a community update for the past few months? Is PINE64 dead? As you may have noticed, there haven’t been any community updates as of late, and we are sorry for the prolonged silence. This isn’t because the community hasn’t been busy, quite the opposite is true. Instead, the problem is that the usual community update authors are too busy with their daily jobs and other tasks around the community. Although thanks to some community members who have shown interest to participate, we are working on a new community update and we hope we will publish it soon!\nPine Store now accepts payments in cryptocurrency. The community has consistently expressed interest in paying on the Pine Store with cryptocurrency, and despite several previous attempts to find a suitable crypto payment service, the process has proven challenging, leading to eventual failure. However, we are happy to announce that Pine Store now facilitates payments using USD Coin cryptocurrency via Coinbase!\nTalk to us at our upcoming community meetup in Warsaw! We always attempt to meet in person at least twice a year. For reasons that ought to be obvious to everyone, this wasn’t possible these past few years, but now that travel is once again viable we’re returning to a bi-annual meetup schedule. We always meet at FOSDEM in February followed by a meeting halfway through the calendar year. While FOSDEM primarily serves the function of interacting with the broader Linux community and members of other projects as well as product announcements, the second yearly meetup aims at evaluating the project’s progress, identifying issues, and creating a roadmap for the coming months. This year we’re holding the second meetup in Warsaw. TL, Ayufan, Lukasz, and I will be having lunch in Hala Gwardii on Sunday, August 20th at noon. The place offers a wide variety of foods from around the world and is a short walk from Ratusz Arsenał metro station. You can also reach the place easily from every corner of Warsaw via all the public transport the city has to offer. So if you’re in Warsaw or can travel to see us on this date, then consider yourself invited. We’ll be keeping an eye on the #offtopic chat on the 19th so let us know when you’ve arrived and one of us will let you know where we’re sitting. Looking forward to seeing you there!\nThat’s all for this quick update about what is going on. I hope that we will see you soon on the next community update!\n(Big thanks to CounterPillow, Funeral, Lukasz, JF002, Ralimtek, CarbonatedCaffeine, and MPReDiToR for help with this and future updates!)\n","permalink":"/2023/08/12/quick-update-whats-going-on/","tags":["community"],"title":"Quick update: What’s going on?"},{"categories":["community","news","pine64-community"],"contents":"\nAs it was teased with the March update and the December blog post of last year, there is a community website redesign being worked on. Launched at beta.pine64.org we\u0026rsquo;re proud to give a very early insight of what the redesign currently looks like.\nTo give a warning in advance, in this preview of the redesign, you will find a lot of unfinished parts, run into issues and maybe there are things you liked at the old (current) page more. That\u0026rsquo;s what the beta launch is for. While the old website was run on Wordpress and maintained by a handful of people, the idea of the new community website redesign after being started as a project of a single person is, that everyone can contribute to the community website. That\u0026rsquo;s why the redesign is launched early: to gather feedback, to gather ideas and to involve everyone interested in contributing so that there will be a nicely working website available later.\nSome technical details To give an insight into some technical details:\nThe former website was running on Wordpress. While easy to use, this also means there was a lot of heavy Javascript, connections to third-party websites (like Google fonts) constantly had to be prevented by adjusting site settings and if people found typos in the blog post then admins had to be asked to fix them.\nThe redesign tries to go a different way. It uses Hugo (\u0026ldquo;The world’s fastest framework for building websites\u0026rdquo;) and it creates static html pages from content formats such as Markdown, Pandoc and AsciiDoc (see Hugo - Content Formats for the supported formats). In fact this blog post you are reading is written in Markdown - show and edit this blog post under a_new_design.md.\nThe redesign tries to avoid using Javascript as much as possible. Javascript is currently only used on the front page to click between the slider images, as well as the YouTube preview (more about this below). The slider will work just fine with disabled Javascript.\nThere are no CDNs used in the redesign. No Google Fonts, no externally hosted podcast player, no analytics, no non-sense. The author also wrote a two-click solution for YouTube embeds. This means there is no longer a YouTube iframe directly in the blog post, which connects to Google as soon as opening the blog post even without watching the video. Instead there is no connection made to Google until the user clicks on the video preview. The video preview is generated and stored locally on the server.\nTry it in the blog post \u0026ldquo;March Update: Tablet Bonanza!\u0026rdquo;.\nThe logo challenge Together with the beta redesign, there is also the logo challenge started to get input from everyone regarding a new logo. The logo you see here is a preliminary draft to show, how the logo could look like. On top is the current logo, on the bottom is the new draft.\nPlease read the thoughts in the logo challenge and bring your best thoughts and ideas.\nDocumentation There is also a documentation tab added in the navigation menu above, as you might have noticed. The documentation pages are currently all PINE64 wiki articles parsed into AsciiDoc files. AsciiDoc is used due to the greater flexibility than Markdown but both or any of the above mentioned content formats can be used and even mixed. The documentation pages are currently in early alpha.\nTo not get into the boring details too much, the Mediawiki articles from https://wiki.pine64.org are basically getting parsed and written into AsciiDoc files without too many changes. Most of the current issues in the documentation pages (wrong order of articles, non-working links, missing templates, broken tables and more) can be fixed easily. The reason why they are not fixed yet is because it is hard to maintain two documentation pages at the same time, the docs and the wiki. Especially while working alone on the redesign it was decided to dynamically parse the wiki instead for now, so that the author does not have to manually apply every change made to the wiki to the docs as well.\nTo give some numbers, the custom parser alone is curently almost 500 code lines long, the rule yaml to write the documentation targets is another 500 lines and the rule yaml for separating long articles into multiple documentation pages is over 1500 lines long. So it would be very surprising if everything works flawlessly. There are currently over 250 documentation pages written. The issues in the docs will all be ironed out before a launch.\nFor the docs there are new shiny board images created and they will be used everywhere to make explaining hardware functionality easier. Here is for example the Ox64 pinout image as created as part of the docs:\nAs part of the new documentation, the author also made a lot of changes to many wiki pages. Updating old information, simplifying old structures, writing new articles, to bring everything information in a more up-to-date and modern state. The author wants to underline that users should not be worried, the wiki doesn\u0026rsquo;t go away. In fact it is a great place for users to document their projects, bringing a strong tie between the community members, the community website and their contributions.\nContributions made easy Hugo also has one nice advantage. Changes to the website can be previewed easily on your computer, making it very easy for new contributors to find out how everything is working and if their changes work as intended. To give a short overview of the steps:\nClone the repository of the website:\ngit clone https://github.com/pine64/website.git Then change the directory into the folder:\ncd website And then preview the website using:\nhugo server It\u0026rsquo;s super simple!\nThe complete process is explained in details under https://github.com/pine64/website/ and we\u0026rsquo;re happy to help in the community chat.\nThe project is structured the following:\nwebsite/ ├── archetypes/ │ └── default.md ├── assets/ ├── config/_default/ │ └── config.toml [site configuration] ├── content/ │ │── blog/ │ │── community/ │ │── contests/ │ │── documentation/ │ └── podcast/ ├── data/ ├── layouts/ ├── public/ [contains the html files] ├── static/ └── themes/pinetheme/ │── archetypes/ | └── default.md │── layouts/ │── static/ │ │── artwork [background artwork] │ │── css [css files] │ │── img [static images] │ │── js [static javascripts] │ │── podcast [podcast episodes] │ └── podlove [podcast player] └── theme.toml [theme configuration] For an explanation of the folder structure see https://gohugo.io/getting-started/directory-structure/.\nOutlook With the upcoming redesign of the community website and the possibility for everyone to contribute to it, the community is going the next step and it ultimately becomes one step more open.\nThe Hugo framework opens us up a lot of different possibilities, including multi-language pages. If community members are interested in this any many more features we\u0026rsquo;re eager to see the ideas and your contributions!\n","permalink":"/2023/04/13/a_new_design/","tags":["community"],"title":"A new design"},{"categories":["news","pinetab"],"contents":"\nThe PineTab2 and PineTab-V pre-orders begin on April 13th. Both tablets feature a 1200x800 10.1” IPS LCD panel with wide viewing angles, a sturdy metal metal chassis, two USB-C ports (1x USB 3.0, 1x USB 2.0 with charging), a digital video out port, a front 2MPx and rear 5MPx camera as well as a 6000mAh battery. Both come bundled with a magnetically fitted detachable backlit keyboard (connecting via pogo pins using USB 2.0 protocol) that doubles up as a carry case, and are available in two hardware configurations: 4GB LPDDR4 RAM / 64GB eMMC 5.1 flash storage and 8GB LPDDR4 RAM / 128GB eMMC 5.1 flash storage. Finally the PineTab2 and PineTab-V both start at $159. On the outside the only thing that differentiates the two devices is the color of the chassis: the PineTab-V is deep matte black while PineTab2 is silver-gray. But the real difference between the two resides on the inside. The PineTab2 features the well supported RK3566 64-bit Arm SoC, which has been a part of our line-up for over a year, and the tablet ships with a build of DanctNix Arch Linux for Arm. The software can be best described as early but very serviceable, and there is little doubt that before long improvements will be made and additional functionality enabled. Like the PinePhone and PinePhone Pro before it, the PineTab2 will reach a high degree of functionality in time and make for a great work or entertainment travel companion.\nFirst image: PineTab2 PCB with RK3566. Second image: PineTab-V with JH7110\nUnlike the PineTab2, the PineTab-V is based on the JH7110 64-bit RISC-V SoC. In late 2022 we announced our plans to help grow the RISC-V hardware ecosystem alongside our existing Arm-based device line-up (see 2023 Sneak Peek section in December Community Update) – to this end the PineTab-V is to the Star64 single board computer released earlier this month what the PineTab2 is to the Quartz64. The JH7110 RISC-V SoC, and the RISC-V architecture in more general, is currently best described as having limited Linux support. The PineTab-V is therefore an experimental device, which ships without an OS and without any promises. You can think of it as a convenient development platform targeted at those of you interested in bringing Linux support to JH7110 and, by extension, the entire RISC-V ecosystem. To sum it up, the two tablets launching on April 11 look near-identical but in actuality are very different devices. The PineTab2 is Arm-based, ships with working software, has solid Linux support that will only get better with time, and has an already-established community of developers waiting for their units to arrive. The PineTab-V is built upon a RISC-V SoC and holds much promise but comes without working software. The PineTab-V is an experimental device geared towards developers and those who wish to explore the architecture. The open source community surrounding RISC-V is just taking shape and still growing, and we hope that the PineTab-V will further solidify this community and help accelerate development. Go to Pine Store\n* PineTab2 and PineTab-V pre-orders will be available under the \u0026lsquo;Tablets\u0026rsquo; category (drop-down) starting Thursday, April 13th\n","permalink":"/2023/04/10/pinetab-v-and-pinetab2-launch/","tags":["pinetab-v","pinetab2","risc-v"],"title":"PineTab-V and PineTab2 launch"},{"categories":["community"],"contents":"As everyone might have noticed, the beta website received a preliminary logo as part of the rebrand. In this challenge, everyone is invited to improve the current PINE64 community logo and to provide their ideas. The draft logo is intended to act as an inspiration for ideas in which present design can be improved.\nThe current logo of the PINE64 community is less than optimal. Here it is:\nRoom for improvement Concerns with the currently design include multiple points:\nThe heavy pinecone logo and the thin text are in a strong contrast due to the width of the different elements. Black elements are generally considered as “heavy”, which creates a tension with how thinly the text is written. The pinecone logo uses lighter colors on the top and heavier on the bottom, while the text is equally heavy throughout the text and on a fixed baseline.\nThere is also a contrast created with the coloring. On the left side there are four different blue colors used on the logo, while on the right side black is introduced. A general rule of thumb is to avoid using more than 3 colors.\nThe colors of the cone are also heavily desaturated, which is boring to look at.\nThe font choice is not great either. Straight lines, unfriendly, over-serious, no fun.\nAnd there are many more issues (such as scalability, invertibility and many more).\nAn initial idea When looking at something for a very long time, we get used to it. The old Pine64 community logo is something many people have grown accustomed to over the years. To help bring it to a new direction the logo could go, the author created a preliminary draft for how the logo could look like:\nThis draft addresses some of the above mentioned concerns. The color palette is reduced to a reasonable amount, the community aspect is added, the text is streamlined to the pinecone style and a considerably more playful font was used - Ubuntu, if you wonder. The SVG file compatible with Inkscape can be found here for download.\nWhile this preliminary version is nicer to look at than PINE64’s current logo pictured above, it isn’t the final incarnation. Everything goes. Now here comes your chance!\nThe challenge A new logo is needed. Be creative, bring in your best ideas, discuss it on all platforms! Got a fun idea, got something in a completely different direction, got a sketch on paper or got constructive feedback for the new ideas? - your input is wanted! There may just be a great prize for the winner of the contest.\nJoin the community platforms to bring your ideas in.\n","permalink":"/contests/the-logo-challenge/","tags":null,"title":"The Logo Challenge"},{"categories":["community","pinebook-pro","pinenote","pinetab","quartz64","risc-v","star64"],"contents":"\nWe end the first quarter of the year with news that Star64 will be available for purchase on April 4th and that the PineTab2 and PineTab-V(ery good!) will launch the following week on April 11th. In this month’s update we also cover PineNote development (I know many of you have been waiting for this) and discuss how software on the device has really taken off in recent months. Finally, CounterPillow - a key RK3566 community developer - sets the expectations for the PineTab2 with some real-life performance examples. Strap on your unicorn horns because there’s much ground to cover this month - let\u0026rsquo;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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank Alex (clover), CounterPillow and Maximilian Weigand and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of this month\u0026rsquo;s update\nTL;DR Housekeeping We held our 5th community Q\u0026amp;A session mid-March; thank you to all those who showed up; you can watch the recorded live-stream on Youtube, PeerTube and Odysee The PineStore has been targeted by DDOS and hacking attacks recently, which caused page time-outs and general inconvenience; rest assured nothing was compromised The reworked community site is taking shape and its looking great - help us test it starting April 15 PINE64 EU Pinecil restock on April 1st instead of March 31st Newsflash Star64 will be available on April 4th in two configurations: 4GB and 8GB LPDDR4 memory for $69.99 and $89.99 respectively Spike in demand for Quartz64 model-A led to temporary lack of stock; more is on the way NotKamui is working on some sweet looking 3D printed back cases for the PinePhone (Pro) yaky-dev has created a 3D printed Samsung Galaxy S20 ultra adapter cover for the PinePhone allowing it to be fitted with a large external battery Despite there not being a dedicated PinePhone (Pro) section this month there are some interesting PP(P) news: QT6 on the PinePhone, Lup emulates the PinePhone and Ubuntu Touch is finally available for the PinePhone Pro delipunch fitted the Pinebook Pro with a Peltier module and saw some good results Salvador showcased old-school PC games running on the Pinebook Pro in BOX86; this included UnrealTournament 1999 - one of my favorite games Jedikaal has written up instructions on how to run Klipper - a popular 3D printing firmware - on the og Pine A64 PineTab-V PineTab-V launches at the same time as the PineTab2 - on April 11th Powered by unicorns and candyfloss Unicorn syncs seamlessly with pen and features intercompatible with both PineTab2 and PineTab-V V…ery good section - must read PineTab2 PineTab2 will be available for pre-order on April 11th Ships with DanctNix Arch Linux with KDE Plasma Desktop (software for early adopters) CounterPillow talks about PineTab2’s performance: video decoding, watching Youtube, browsing the web and working with PDF documents Tested on Plebian - a vanilla Debian for RK3566 devices PineNote Linux is finally taking shape on the PineNote and flashing Linux OSes is now simpler than in the past There is now a dedicated Debian with GNOME image with tailored settings for grayscale Other OSes and desktop environments are being worked on too (SWAY and postmarketOS) The e-paper panel now performs well (still WIP) under Linux and Xournalpp has been worked on allowing for very good pen input No promises made at this time but certainly now it looks a viable Beta product for early adopters Housekeeping Earlier in March we held the fifth community Q\u0026amp;A session and I’d like to thank everyone who joined in asking questions in the chats. I felt like this was one of the best Q\u0026amp;As thus far, not in the least because we didn’t run into any major technical issues and managed to successfully stream to Peertube this time around. Following the Q\u0026amp;A, Marek and I spoke about extending the sessions up to 2 hours. As things stand, we usually end up running out of time and many questions remain unanswered. Let me know in the comments whether you’d like us to make the Q\u0026amp;A sessions longer. I am also interested in learning whether moving the Q\u0026amp;A session to the weekend - ideally a Sunday - would suit the community better. We currently don’t have a firm date for the next Q\u0026amp;A but it will likely be held at some point in June. That said, due to Marek’s and my summer vacation plans the Q\u0026amp;A may be moved to either late May or early July - we’ll let you know closer to the date. You can watch the last Q\u0026amp;A session below. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Community Q\u0026amp;A live stream recording\nThe Pine Store and community website have been targeted by DDOS and hacking attempts this past month, which resulted in the sites being placed in maintenance mode at times. A it will likely come as no surprise to the majority of you, both sites are frequent targets of malicious parties but this most recent attack has been the biggest to date. It has also shown signs of coordination, effort and skill. But you can rest assured that steps have been taken to cull the DDOS attack and that no data has been compromised. The reason why I’m mentioning this in the update is because the Wiki and forums were also affected, causing sluggish response times and server time-outs, and I’ve been told that users experienced problems accessing community services over the course of two days. Things should be working as normal from here on; we are actively monitoring both sites and cluster-based services. Speaking of the PINE64 website, in December of last year I reported that we started on a complete community website redesign. This redesign is much more than a new coat of paint - in fact it takes this website in a completely different direction. The goal is to make the site a hub that ties together all the existing community services while simultaneously exposing key community-driven elements of the project. For instance, clicking the community tab presents you with all the relevant links to chats and other communication platforms, while new blog posts, podcast episodes and news take center stage on the main page. Another part of the redesign, and one that I absolutely love, is the incorporation of all documentation on the actual website. The page is also much cleaner and significantly more light-weight - it is really snappy and a pleasure to visit. We are planning on initially launching the site for testing alongside the current webpage - those willing to help us test and offer feedback are welcome to visit the site starting April 15, here’s the page: beta.pine64.org/.\nHere\u0026rsquo;s a sneak peek at the upcoming community website\nLastly, the PINE64 EU store will be restocking the Pinecil V2 on April 1st instead of the planned March 31st. However, subsequent Pinecil V2 restocks in April will land on Fridays, with the first scheduled for April 8th. I also want to let you know that due to the upcoming Easter Holidays there won’t be any shipping from PINE64 EU between April 6th - 13th. The PinePhone BE2 has now also restocked. I also know that many of you have asked about PinePhone Pro’s availability in PINE64 EU - I currently hope to have a batch in the latter half of April. If you want to keep track of PINE64 EU’s hardware availability and restock then I invite you to follow Twitter, Mastodon and Telegram. And no, none of the above is an April fools joke :) Newsflash I come bearing great news for everyone waiting for Star64 - the SBC will be available for purchase on April 4th. Due to some last-minute logistics issues we failed to make the March launch date announced in February - our apologies for the slight delay. The boards have now finally been delivered and getting packaged and ready for dispatch. Let me just quickly reiterate the Star64 features: Quad core 64bit RISC-V, HDMI video output, 4x DSI and 4x CSI lates, i2c touch panel connector, dual Gigabit Ethernet ports, dual-band WiFi and Bluetooth, as well as 1x native USB3.0 port, 3x shared USB2.0 ports, PCIe x1 open-ended slot and GPIO bus pins (i2c, SPI and UART). The board also features 128M QSPI flash and eMMC and microSD card slots. The board will be available in two different RAM configurations - with 4GB and 8GB LPDDR4 memory for $69.99 and $89.99 respectively. The Star64 store page ought to already be live when you read this, but will be listed as out of stock until the 4th. Star64 will be available in the Pine Store on April 4th, it will be listed as \u0026lsquo;out of stock\u0026rsquo; until then\nIn other SBC news, we’ve seen an increase in Quartz64 interest recently (which is awesome!) - the model-A in particular - which caused the board to go out of stock temporarily. I wish to let you know that a new production-run is already underway and the next batch\u0026rsquo;s delivery is expected soon. Indeed, it may already be available at the time this community update goes live, but no promises. Please visit the Pine Store Quartz64 page to learn of the SBC’s availability. User NotKamui in the Matrix PinePhone chat has been working on some incredibly cool looking back cases for the PinePhone. While there have already been many community-designed replacement 3D cases made in the past, this design stands out as one of the absolute best. Not in the least because the case is transparent and features an embedded Tux. NotKamui is currently traveling (at least from what I gathered) and hasn’t had the time to complete the design nor upload the STL files, but hopefully we\u0026rsquo;ll get a chance to print our own version of the back cases soon. Once files find their way onto an online STL repository I’ll make sure to revisit this topic and offer up relevant links. These are some really awesome looking cases Staying on the subject of the PinePhone and 3D printed cases for a moment longer, user yaky-dev created a 3D printed Samsung Galaxy S20 ultra adapter cover for the PinePhone. This adapter allows you to use S20 Ultra accessories with your PinePhone or PinePhone Pro. Most notably, you can outfit the PinePhone (Pro) with the S20’s battery case, which adds a whopping 7500mAh to your device. For those interested in the case adapter here is the link to the Thingiverse website - I think this is a very cool community project.\nHas anyone ever said \u0026rsquo;no\u0026rsquo; to more battery life?\nThere is no dedicated PinePhone section in this month’s community update - instead I decided to squeeze the most noteworthy phone developments into the Newsflash section. The first piece of news relates to KDE Plasma Mobile: Seshpenguin tooted images of the PinePhone running QT6 which, at least according to them, may be the first instance of the software running on real hardware. This is obviously important news in light of KDE’s recent announcement that they’re gearing up to launch its next release with QT6 only. The second piece of PinePhone news relates to Lup’s efforts to emulate the Unicorn Emulator. His lengthy blog post on this subject provides a complete walkthrough of the process and includes very detailed information about getting started with emulating the platform. It is worth a read for those interested in alternative software development on the PinePhone, something which I touched upon last month. Last but certainly not least, we’ve received word that it is now possible to run Ubuntu Touch on the PinePhone Pro. Be warned, however, that this is an introductory build which has a number of PinePhone Pro-specific quirks, such as upgrading via apt. Some key features are missing in the build too (such as camera functionality). I am really happy to finally see Ubuntu Touch available for the PinePhone Pro and I’m sure many in the PINE64 community will be too - thank you UBports team! QT6 on the PinePhone\nReddit user delipunch shared a cool Pinebook Pro mod, in which they replaced the default passive cooling solution used in the Pinebook Pro with a Peltier module. For those who do not know, the Peltier module achieves cooling by running current through a thermocouple rather than moving air or liquid over a surface to dissipate heat. Prior to the mod, with all cores under full load, the Pinebook Pro would throttle at 75*C, but with the new cooling solution it doesn’t. This is a very cool mod and while it does look rather complex, and thus unlikely as something many of us could attempt, I’m sure there are some in the community with the technical know-how who will attempt to replicate it.\nPeltier module in the Pinebook Pro does appear to help with SoC throttling under full load\nSalvador Liébana has showcased a number of popular retro-PC games running well on the Pinebook Pro using BOX86. If you don’t know - BOX86 allows you to run x86 Linux programs on 32bit and 64bit Arm systems. Some of the games showcased by Salvador included Miami Heat, Raptor: Call of Shadows and the legendary Unreal Tournament from 1999. It is impressive how far the open source driver has gotten since the initial launch of the Pinebook Pro in 2020. I have recently gotten back into retro-gaming as a weekend activity and will surely be testing this out. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video The year 1999 gave us the Matrix, Eminem\u0026rsquo;s \u0026lsquo;My Name is\u0026rsquo; and Unreal Tournament\nLastly, Klipper - a popular 3d printing firmware - has been shown to run on the original Pine A64. The reddit user Jedikaal has written up a very comprehensive set of instructions on how to get the software running. While the instructions pertain to the Pine A64 in particular there is no indication that they wouldn’t also work on other PINE64 SBCs such as the Quartz64. I have recently seen a number of questions pertaining to PINE64 boards and 3D printing (I think I even answered one during the community Q\u0026amp;As), so I’m looking forward to seeing more contributions such as this from members of the 3D printing community. PineTab-V Here’s the big news: both the PineTab2 and PineTab-V will be available for pre-order on April 11th. ‘The PineTab-V, what?’ - I hear some of you asking, why yes, have we failed to mention that we’re working on two new PineTabs? What does the ‘V’ in ‘PineTab-V’ stand for? The ‘V’ stands for ‘very early’ or ‘vaguely functional’ and potentially even ‘Vociferously viperous’ (yeah, I bet you had to look it up even if you’re a native speaker, and no, it doesn’t make sense - I’m aware). Honestly, we haven’t decided ourselves yet. It was meant to be a surprise, but given the fact that the update goes live on April 1st and we’re only a few days away from the PineTab2’s launch, I figured I may as well just spill the beans. Those of you keenly following our project may already have guessed that we will be introducing a Linux device based on V(ery good!)-architecture at some point this year. I suppose you didn’t really have to guess, I spelled it out for you in December, so all you really needed to arrive at this conclusion was a pair of eyeballs and a rudimentary ability to read. In a nutshell, here’s what I wrote at the time: we’re very keen on creating new and innovative RISC-V devices as well as RISC-V counterparts to existing and upcoming Arm devices. Not sure if I could have written it any plainer than this.\nHere\u0026rsquo;s a picture of the PineTab-V, seriously. Picture taken on January 2025.\nSo here we are - the PineTab-V is identical to the PineTab2 in all ways but the SoC. It features the same chassis, LCD panel, memory and storage configurations and even SKU price-points. Seriously, the picture I inserted above isn’t actually the PineTab-V, it\u0026rsquo;s the PineTab2. Hadn’t I said anything you would be none the wiser. Overall, It’s really low effort and truly as lazy as it gets. If you’ve read the December and February community updates, then you already know just about everything there is to know about the physical characteristics of the PineTab-V despite never actually having read a thing about the PineTab-V. Confusing, I know. Regarding the pricing: we did consider charging more for the PineTab-V, since it actually costs more to manufacture than the PineTab2 (seriously), but given that it is effectively a glorified paperweight at this point in time it just didn’t feel right. Ok, so I suppose there is one more thing you should know about the PineTab-V after all - while it walks and quacks like PineTab2, it sure as heck isn’t an Arm machine. You are basically buying into an idea, a vision, a dream [note to self - insert more inspirational words here to motivate them to pick one up]. Indeed, unlike its Arm brethren it doesn’t even boot Linux as of today - at least not as far as I know. So if you are in the market for an open, high-quality and sexy looking tablet that doesn’t work since the software for it is a-way-of from pre-Alpha then you’ll be thrilled to know we’ve got you covered! On the plus side, it does come bundled with the unicorn with a mic stuck to its head we promised last year. The unicorn has already been confirmed to sync with the PineTab-V via BT LEL and interfaces directly with the PineNote’s pen. Top-tier stuff this, seriously. Ok, time to wrap this up - here’s what I want you to take away from this section: if you want a working Linux tablet then go with the PineTab2. However, if you already completed your Picasso collection and no longer take pleasure in neatly arranging your sports cars in the garage, but you have an interest in things ending with the letter ‘V’ and some money to burn, then I feel like the PineTab-V is a prime-candidate pick-up option for you. Go on, do it, I dare you.\nPineTab2 (By Lukasz and CounterPillow) Much of this month’s section on the PineTab2 has been written by CounterPillow who is one of the developers who tirelessly worked on the RK3566 platform since last year. I think that I have covered everything I wanted to say about the PineTab2 in the December announcement and last month’s update already, so it is for the best that someone working on the actual software gets a say now. There are, however, two bits of important information I wish to share with you before I hand this section off: firstly, the PineTab2 will ship with a build of DanctNix Arch Linux for Arm with KDE Plasma Desktop. Arch Linux is what we demoed at FOSDEM earlier this year and felt that it performed rather well for such early-state software. Obviously the build that ships with the PineTab2 will be newer than than the FOSDEM demo, but you should be warned that it won’t include any critical new functionality (at least not out-of-the-box - improvements and additional enablement are obviously possible, and even likely, between the time units get flashed at the factory and when end-users receive their units). DanctNix Arch PineTab2 build in action\nI chatted briefly with Danct12 earlier this week and he wishes for you to know that the PineTab2 software is still a work-in-progress, so you should always check for updates as things are likely to progress even quicker once people get their hands on the hardware. If you have any questions concerning the build and current status of the software then you are welcome to join the #archlinux-pinephone:kde.org channel on Matrix or @archmobile on Telegram. Danct12 also wanted me to let you know that the Wi-Fi is disabled on the PineTab2 by default due to driver stability issues, so you\u0026rsquo;ll have to run modprobe bes2600 to get it working. Now, the second, and perhaps the most important thing I wanted to write before CounterPIllow shares their insight is that the PineTab2 will be available on April 11th… bundled the unicorn with a mic on its head, of course. [Quick note: I have taken the liberty to edit CounterPillow’s contribution for style solely - none of the written contents were altered. CounterPillow’s section starts below.]\nI\u0026rsquo;ve seen some talk about how the RK3566 in the PineTab2 won\u0026rsquo;t perform well for its intended purpose. While it is true that the RK3566 system-on-chip is optimised for low power draw rather than raw performance, this does not mean it\u0026rsquo;s a bad SoC for a tablet. First off, yes, it is obviously slower than a RK3399 (Pinebook Pro, ROCKPro64) running at its full clock speed. The 4 Cortex-A55 cores in the RK3566 are in-order cores, meaning they do not reorder instructions for higher performance. This makes them comparable to the four Cortex-A53 cores found on the RK3328 (ROCK64) or A64 (PineTab1), but much faster and more efficient as it is a newer core.\nBut will it be enough for watching YouTube? Well, if we assume hardware decode is working and we\u0026rsquo;re rendering the video through hardware scalers, we can naturally reach the advertised 4K@30 video output. But on mainline kernels, i.e. kernels that are what sits in Linus Torvalds\u0026rsquo; git tree, we\u0026rsquo;re currently missing a driver for the \u0026ldquo;rkvdec2\u0026rdquo; hardware decode block, and even if we had such a driver, the support for its v4l2-request user space API (the interface between programs and the kernel) is still not great.\nSo let\u0026rsquo;s look at pure software decoding. That is, video decoding performance without fixed function hardware acceleration, just what the CPU cores can do with their vector instructions. Anyone without a PineTab2 can do this, so long as they own some other RK3566 device. I ran these tests on a Quartz64 Model A, running Plebian. For this test, I kept things simple. I decoded 1080p and 720p videos fetched from YouTube with yt-dlp at the maximum speed the CPU could muster, using an FFmpeg build from Debian Bookworm\u0026rsquo;s repositories, also built against the libdav1d from Debian Bookworm. In essence, this means FFmpeg 5.1.2-3 and dav1d 1.0.0-2. The video used for the test were the various video streams YouTube offers for https://youtu.be/Lwk8e2q4qHo, a 25 fps video. Five minutes of the video were decoded as fast as possible with the command ffmpeg -i videofile -to 5:00 -f null - -benchmark and the achieved average framerate was calculated with 300 seconds / rtime * 25.\nWe arrive at the following results:\nav1 (dav1d) h.264/avc vp9 (ffvp9) 1080p 50.50 fps 75.34 fps 63.09 fps 720p 105.74 fps 200.16 fps 146.49 fps Keep in mind that the PineTab2 comes with a 1280x800 panel, meaning you\u0026rsquo;ll be consuming 720p content unless you have an external monitor connected. For 720p content, we\u0026rsquo;re above real time speeds even for theoretical 60 fps content on the newest and most complex video codec (AV1). Even at 1080p, software decoding is still well in the realm of playable for most content, with just 60 fps AV1 not being real time. In short, from a decode perspective, the PineTab2 will play the youtubes fine, even in the absence of fixed-function hardware video decode acceleration. The performance for video rendering is another question however, and depends heavily on the indirections the buffers take before arriving at the display. From personal experience, I can attest that at 1280x720 even mpv\u0026rsquo;s gpu shading pipeline based video output will work fine for 60 fps content under kwin on Wayland. 1080p 60fps content is looking less rosy with mpv though, where the same configuration (kwin wayland, gpu shading pipeline rendering, software decode) is dropping frames. This may be avoided once we have a hardware decoder driver, as we can then pass the dmabuf buffers from the hardware decoder directly to the output with mpv\u0026rsquo;s new dmabuf-wayland video output.\nA more common use case is web browsing. For this test, I used Chromium with a few flags enabled (wayland, experimental performance stuff) on a 1080p display on a kwin wayland plasma session, again on a Quartz64 Model A, which has the same SoC as the PineTab2. You can see that we get quite a smooth web browsing experience from this video capture (Ignore the crunchy looking text rendering, that\u0026rsquo;s an artifact of my $9 HDMI capture device\u0026rsquo;s 4:2:2 downscaling.):\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Here\u0026rsquo;s a glimpse at the type of performance you can expect from the PineTab2\nFirefox will be slower as it really doesn\u0026rsquo;t want to do GPU rendering on Panfrost and its JS engine isn\u0026rsquo;t as optimised for ARM. Compared to PineTab1, this is a night-and-day difference. You can actually browse the web!\nAnother task many want to use a tablet for is to browse through documents like PDF files. One particularly heavy workload for this is tabletop gaming rule book PDFs. They\u0026rsquo;re usually richly illustrated, taking a few seconds even on x86 computers to do a page flip with some reader software. Out of curiosity, I tried the \u0026ldquo;Warhammer Fantasy Roleplay\u0026rdquo; 2nd Edition core rule book, which is my heaviest PDF file, on the Quartz64 Model A. I can\u0026rsquo;t show you an HDMI capture of the experience for copyright reasons (Games Workshop, if you wanna allow this use hit me up, I swear we\u0026rsquo;ll treat your IP with dignity, unlike some game studios), but I can describe the results in text form.\nUsing Okular to browse through the PDF was terrible. While Okular works fine for richly illustrated scientific papers and other such content, the might of Sigmar brought it to its knees, resulting in 5+ second page loads. MuPDF, a more minimalist document viewer, copes well however. Flipping to the next page takes about 1 second from key press to the next page being rendered. This is more than usable enough for quickly browsing to the right page during a sweaty tabletop gaming night.\nThe RK3566 SoC found in the Quartz64 and SOQuartz line of devices has gotten fairly good mainline support in Linux. To showcase this, me (CounterPillow) and diederik banded together to create Plebian, an installer- free Debian image for Quartz devices based on Debian Bookworm, using its unmodified kernel package.\nPineNote I know that many of you have been eagerly awaiting to hear news of the PineNote and I am happy to finally bring you an update on the device. Before I start, however, I should make it clear that everything I write regarding the software status of the device is based on information collected by Maximilian Weigand - a developer working on the PineNote, who was kind enough to detail all the information for me. Perhaps the biggest news about the PineNote is that finally, after many months of development, Linux on the device has reached a reasonably mature stage and there are even two sets of very promising and user-friendly software options being designed for it. In the words of Maximilian “the PineNote is now in pretty good shape for basic linux use; it can be flashed with only a USB connection, (\u0026hellip;) the factory test Android is not required for any of the linux installation steps (\u0026hellip;) [and] u-boot images can be flashed via rkdeveloptool with no UART debug connector required anymore (\u0026hellip;)”. From the get-go, this addresses some of the biggest problems that the PineTab2 development faced from the start - it is now possible for end-users to flash OSes of their choice on the PineNote relatively pain-free. Indeed the entire boot sequence has received major boons in recent months, making the process of powering on the device and starting an operating system much more streamlined. Originating in the downstream rockchip u-boot sources, an u-boot version is now available that displays pre-prendered images for boot entries and can be controlled using the power button, with touchscreen support for the u-boot menu in a proof-of-concept status. Importantly this u-boot version comes with an e-ink-enabled devicetree and does not require any android partitions or files anymore. So then, what can the PineNote boot? For starters, thanks to the support by, and encouragement from, diederik there is now a working linux 6.2 branch for the PineNote, which is shared by those working on complete OS images of the device. One of the options now available, and one that ships with the above-mentioned u-boot, is a refined build of Debian with GNOME. This tailored build includes some modifications to the GNOME desktop environment and a custom extension to control epd display settings looks and performs well on a grayscale screen. It uses a theme developed by user MichiMolle. This theme removes shadows and animations, adds gray-scale icons and improves the performance of GTK 3 and 4 on the PineNote. However, this isn’t the only desktop environment option being currently developed - a comprehensive collection of configurations and instructions for using Sway with the PineNote was collected by user hmpthcs. I should also mention that a dedicated postmarketOS build for the PineNote is actively worked on by Phodina. This is one of those instances where an image, or a video in this particular case, is worth a thousand words - so I invite you to marvel at the short clip showcasing Linux on the PineNote.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video This looks pretty awesome doesn\u0026rsquo;t it?\nOne of the biggest selling points of the PineNote is obviously its display. In the past I’ve reported on the iterative work that developers had to endure to reverse engineer and subsequently enable PineNote’s e-paper panel; we can now finally see what this painstaking work has resulted in. Much of the hard work on the panel was done by pgwipeout and smaeul - they did the majority of the hard upbringing and driver work, and hence it is largely thanks to them that the panel is now in a functional state. Thanks to a collective development effort the panel went from being buggy and very sluggish to really crisp, detailed and responsive. All this in just one year. Reading and browsing on the device is one thing but functional pen input is a whole different can of worms. To this end I hope you’ll be just as pleased as I am to hear that user hrdl has been continuously working on improving the drawing performance of xournalpp on the PineNote and shared a video of the pen’s input performance. While the pen’s input latency is certainly not perfect, it is nonetheless impressively fast and I could imagine myself using it without the input delay tripping me up while writing. Take a look for yourselves and let us and the developers know your impressions in the comments section. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video I don\u0026rsquo;t know about you but this looks pretty pretty smooth to me!\nSo, then, what does this mean for the future of the PineNote? - I don’t want to jump the gun and promise anything at this time. What I can say, however, is that I’ll talk to TL and Marek about these developments in the coming days and explore the viability of bringing the PineNote to more people. I also want to say that I am completely blown away by how much work has been poured into the device in the recent months. It is incredible to see all the passion and raw effort that has gone into making the vision of an e-paper device running full-fledged real Linux a reality. Thank you to all those who have worked on the PineNote for the past year, I take my hat off to you. This is it for this month’s update, I hope you all thoroughly enjoyed it. I’ll catch you next month if the unicorn doesn’t get me in my sleep.\n","permalink":"/2023/04/01/march-update-tablet-bonanza/","tags":["pinenote","pinetab-v","pinetab2","quartz64","unicorn"],"title":"March Update: Tablet Bonanza!"},{"categories":["community","pinebuds","pinecil","pinephone","pinephone-pro","pinetab","pinetime","quartz64","risc-v","rock64-2","rockpro64","soquartz","star64"],"contents":"\nLet me start by apologizing to everyone for skipping yet another monthly community update. This has largely been my fault as I was rather busy in January and following FOSDEM at the start of February I found myself occupied with things related to the EU store. I hope for things to go back to normal now; you can expect future community updates at the end of each month as per usual. Again, I apologise, mea culpa. I hope that this month’s update and the news it brings will more than make up for the wait: the Nestflash section is absolutely packed this month, we’re revealing PineTab2’s pricing and SKU variants (both of which I’m sure you’ll be pleased with), announcing that Star64 will be available in the next 6 weeks (or so) and report on all the work that has gone into PinePhone (Pros) development in the recent two months … and much more\nLet\u0026rsquo;s get to it.\nYou 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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank Alex (clover), JF, Danct12, William Starkey, Alex Horner, River-Mochi, Biktorgj and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of this month\u0026rsquo;s update\nTL;DR Housekeeping FOSDEM was great - thank you to all who came and chatted with us at the stall Pine Store is getting back to normal following CNY Next quarterly community Q\u0026amp;A on 17 March at 20:00 CET - be there or be square PINE64 EU full restock on March 1st Newsflash New release for R-Cade for Rock64, RockPro64 and Pinebook Pro is excellent - you need to try it PineSAM is a BLE app for the Pinecil V2 that allows you to change your Pencil V2 settings remotely! SOQuartz patches for PCIe2, video output, gpu, HDMI sound were merged into mainline kernel 6.2 SOQuartz is getting popular - MC Server Hosting share their experience with the module and BLADE An awesome rugged 3D printed Pinecil case Issues with ANC in PineBuds Pro’s left earbud can be fixed by reflashing firmware; work on open firmware going strong \u0026amp; offers good sound quality Significant progress on porting Linux to the 0x64 \u0026amp; video with instructions on how to flash the board The new GAN 65W PinePower PSU now in the Pine Store PineTab2 PineTab will be available in two SKUs: 4GB RAM / 64GB eMMC \u0026amp; 8GB RAM / 128 eMMC Pricing: 4GB/64GB version USD $159 \u0026amp; 8GB/128GB version $209 First impression of the PineTab2 - most refined Linux-capable hardware from PINE64; very high quality all around and a major step-up from the original PineTab2’s keyboard impressions - very good keyboard, sturdy and hefty stand and solid key backlight PineTab2 software more mature than many of you expect - thanks to the work on Quartz64 and SOQuartz by the community; only a few bits missing FOSDEM demo ran DanctNix Arch + KDE Plasma Desktop and was well received Launch window – sometime in April, but no promises Star64 We expect to have the Star64 available in March or beginning of April We had a working demo of Debian with XFCE at FOSDEM (thanks to ayufan) There is much interest in RISC-V platform and Star64 in particular The software on RISC-V is in early stages - I share my experience Star64’s significance: we believe that affordable RISC-V hardware will drive Linux development on the platform PinePhone (Pro) So many PinePhone (Pro)s at FOSDEM! Megi’s newest keyboard firmware brings a 30 fold power reduction consumption, increasing standby time from 23 days to nearly 1.8 years Megi’s 6.1 kernel brings many improvements - notably 60Hz refresh-rate on the PinePhone Pro and keyboard driver improvements allowing phone to charge directly from keyboard’s battery Libcamera on the PinePhone Pro - a really promising experience \u0026amp; can now be installed on Mobian (and potentially also other OSes) Apache NuttX is being ported to the PinePhone - for now for educational reasons but looks very interesting First glimpse of Ubuntu Touch on the PinePhone Pro - a very smooth and positive experience Many new software releases, including DanctNix Arch, postmarketOS, Mobian and Manjaro bring benefits of Megi’s newest kernel SailfishOS is really taking off and newest release brings keyboard and camera support Version 0.7.3 of biktorgj\u0026rsquo;s PinePhone Modem SDK allows modem\u0026rsquo;s userspace to connect to the Internet even when the PinePhone is suspended PineTime Many PineTime’s at FOSDEM and interest in the device is not waning more than 30 pull-requests merged since last release - you can expect better battery level monitoring and UI improvements A Windows companion app - InfiniWindows A more powerful replacement board compatible with existing firmware has been designed by community Housekeeping As you surely know we’ve attended FOSDEM in early February and had the opportunity to showcase many of our popular and upcoming devices. To me, however, the highlight was meeting members of the community and developers whom I rarely if ever get to see in person. While this FOSDEM wasn’t exactly smooth-sailing for us (Marek ended up in the hospital on day one and my kid got sick with a stomach bug the day we arrived), it was nonetheless a great experience to have the opportunity to speak with many of you. To this end I’d like to thank everyone who took the time to stop by, hang out and chat at our stall. As always our stall was bustling both days and kept us fully occupied for the duration of the conference. I always promise myself to spend more time walking around and talking to other projects and attend at least one talk - but as always I didn’t manage to find the time for either year around. Perhaps next year.\nPictures of the crowd and hardware at our stall :)\nFor the past month the Pine Store has been, for the lack of a better word, ‘recovering’ from the Chinese New Year backlog. As is the case every year, support staff have returned to a high volume of unanswered emails and the shipping department had to deal with pending shipments. This resulted in longer-than-usual response times for which I apologies; I am not aware of any delayed shipments, but if there were any then this too I am sorry for. The weeks following CNY are always somewhat chaotic, although my sense is that support and shipping have done a good job getting things back on-track quickly. February has also been a stressful period as production spools back up, factory floor time is being allocated and hardware delivery timelines are being finalized. So, what is the reason for me writing all this? - you’ve likely seen less activity on our end the past month but things should finally be returning back to normal in the coming days. Thank you for your patience.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video In case you missed it, here\u0026rsquo;s the last Q\u0026amp;A from November of last year\nWe’ll be hosting the Q\u0026amp;A on March 17 at 20:00 CET. The community Q\u0026amp;A is an opportunity for you to ask us questions and have them answered live. As always we’ll be taking questions from the chat and live-streaming to Youtube (as well as PeerTube if we finally can get it to work). You can join us and ask questions in IRC, Discord, Matrix and Telegram all of which are bridged, so there is no excuse not to participate. We’ll remind you of the Q\u0026amp;A ahead of time and once again on the day but it is probably a good idea to put the date in your diary now. The event lasts an hour following which we usually hang out for another hour in the voice chat, which you’re also more than welcome to join. For those of you who won’t be able to make it, the unedited Q\u0026amp;A session will be available for viewing on Youtube, Peertube and Odyssee. I hope to see many of you there. Lastly, PINE64 EU store has now received a complete hardware restock. As always, you can expect to see the PinePhone, Pinecil V2, PineTime, PinePower and other usual suspects available for purchase. This month the PinePhone (Pro) keyboard case is also making a return alongside the PinePhone + keyboard case bundle. The EU store will also be adding the PineBuds Pro to its assortment - these will be a permanent addition to the store’s repertoire moving forward. If you’re in the EU I encourage you to follow PINE64 EU on Twitter, Mastodon and Telegram for announcements and hardware availability information.\nNewsflash [by Lukasz, Victor TC, William Starkey, and MC Server Hosting] We’ve got a new release of R-Cade for the Rock64, RockPro64 and Pinebook Pro and the experience is downright amazing. I tested the recent build on the RockPro64 and it must be one of the most well-polished, easy to set up and feature complete retro-game emulation software out there. It also happens to be optimised for the Rock64 and RockPro64, which results in nearly flawless emulation of nearly all included systems. I tested PSP and Dreamcast on the RockPro64 and the vast majority of games ran at full speed. Needless to say, older systems won’t pose any problem on either the Rock64 or RockPro64 (I know from past experience that Nintendo64 emulation on the Rock64 is also great). This is really an incredible job by mrfixit. If you’re into retro-gaming and seek the best possible experience out there then consider R-Cade highly recommended (by me - a person a bit nuts about retro-games). https://youtu.be/N4gIxeddzNg\nA (very poor) video showcasing performance of R-Cade on the RockPro64 running Dreamcast and PSP\nPineSAM is a new Pinecil Settings And Menus BLE app for the V2 from Builder555. It works on Linux/Mac/Windows and any browser, and can work from Android, iPhone, iPad. This open source python app runs locally on your pc/laptop, to contribute to the development effort click here. It works like this: to quickly get it onto a phone on the same network, open web address http://:8080/settings.html where \u0026lt;ip-address\u0026gt; is the local ip address of the computer running the python app. It is currently actively updated so please check for the newest version. PineSAM allows changing most settings without using the Pinecil screen. A live \u0026ldquo;Work view\u0026rdquo; is coming soon which shows active live temperatures, watts, and volts to make it convenient to solder while monitoring \u0026amp; changing temperatures with a larger phone screen. For safety reasons, you have to start heating with the [+] button on the Pinecil, but after that you could work in the BLE app on a phone or PC screen. See the Readme if you have any install issues, or open a github issue ticket; Pinecil chat channel may also be able to help. It usually takes just a few minutes to get installed and running.\nThe PineSAM application looks incredibly cool\nSOQuartz patches for PCIe2, video output, gpu, HDMI sound were merged into mainline kernel 6.2. This is very good news not only for regular end-users but also corporate customers already using a SOQuartz or looking to pick up a SOQuartz for their particular use-case. We’ve seen a major increase in the interest in SOQuartz in recent months so I’m sure this piece of news will be well received. I should also mention that new releases for Quartz64 and SOQuartz are now available from Manjaro and DietPi. Unfortunately I don’t have any experience with either build, so cannot report on how well the respective OSes perform - if you’ve had experience with either then make sure to share your thoughts in the comments. Quantumworks cluster\nMC Server Hosting have been working with Kubernetes and Pine64\u0026rsquo;s Single Board Computers (SBCs) for some time. They have tested various solutions such as sigmaris\u0026rsquo;s pxe ready uboot builds, jaredmcneill\u0026rsquo;s UEFI for the Quartz \u0026amp; Soquartz, and initramfs hooks + Empourus magic for cluster booting, and are constantly impressed by the power and support of the community.\nThey write: “recently, we had the opportunity to try out the SoQuartz Blade. We were delighted to find that it includes PoE and comes with a stable Manjaro image with a kubernetes arm package, ready for testing Rook Ceph network storage. Although these devices are PCIe gen 2x1 with a gigabit port, they are more than sufficient for small home or office setups, and their low power consumption (~10 watts per blade) makes them an economical choice for lab testing. In fact, we believe that a set of these blades and two PoE switches could even handle a large cluster with the proper Crush Map. Our testing showed impressive performance, with Random and Sequential read/write speeds in an optimal range.\nReplicated x2 RBD-NDB w/ osd using all cores\nRandom Read/Write IOPS: 3077/2335. BW: 117MiB/s / 71.2MiB/s\nAverage Latency (usec) Read/Write: 3871.43/1620.43\nSequential Read/Write: 115MiB/s / 64.6MiB/s\nMixed Random Read/Write IOPS: 3500/1175\nIn addition to mounting etcd for kubeadm and mon/mgr data on the NVMe drives, it is also possible to run the entire runtime of containers on these devices for a significant performance boost. This is particularly useful for applications and libraries that would otherwise be limited by the iops of the emmc/sdcard. Overall, we have found the SoQuartz Blade to be a great choice for setting up a cluster. You can even use etcdadm to run the core of your cluster on three of these blades.”\nBrowsing the official reddit I came across a pretty awesome looking Pinecil case and I believe that it is an evolution of an already existing case that I featured in a Newsflash section a few months ago. This one, however, from what I can tell is built more rugged and holds more gear: there is space for the USB-C cable, an integrated soldering iron holder which uses a bearing (super cool), space for two additional tips and the thingy to clean the iron. If you happen to have a 3D printer and are looking for a next project this one should be high up on your list. The STL files can be found here. Rugged Pinecil case by Piotr Strog\nFor those of you who already own a pair of PineBuds Pro and have experienced issues with ANC in the left earbud - I’ve been told at FOSDEM that reflashing the stock firmware fixes the problem. This has been confirmed independently by a number of people at this point so can be considered an established fix. Instructions concerning flashing the firmware and all other pertinent information can be found on the documentation pages. As a side-note, work on the open firmware for the PineBuds Pro is steaming ahead and I’ve been told that it sounds great, so consider giving that a go if you don’t need ANC (which is still WIP on the open firmware)- it can be downloaded from here. Someone created a USB-C charger for the PineTime. While I can’t necessarily see a reason for substituting the existing cradle for one which accepts USB-C, this is certainly a very cool project from a repairability perspective. That is to say, if your cradle breaks for whatever reason there now is a proof of concept for how one would go about creating a substitute charging solution. Check out the original post and discussion here. Not sure what I make of this one - but it is undeniably cool - image by reddit user PleasentEnd7990\nThe OX64 has now been on the market for two months and it already is one of the best selling PINE64 devices. Who would have believed that an inexpensive Linux-capable RISC-V board would garner so much interest? Some early adopters have however complained that the OS flashing process is unclear and undocumented. One of the early adopters going by the handle Platima Tinkers has thankfully put in the effort to document the process in the form of a video. The 15 minute-long video is truly great and gives anyone already owning or interested in getting the Ox64 a crash-course in getting it up-and-running. I am including the video below for your benefit.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Instructions on flashing Linux on Ox64 by Platima Tinkers\nOn the subject of Ox64, there has been significant progress on porting Linux to the 0x64 since our last update. Several drivers have been added, and we’re getting closer to having the 0x64 as a viable linux device for your projects every day. A buildroot configuration has been made, enabling easy creation of images to flash to the 0x64. Linux drivers have been added for the SD card slot, removing the tight storage space limitations of the spi flash, and we have basic drivers for GPIO and parts of the hardware cryptographic acceleration. Outside of Linux, we have managed to get code running on the LP core for the first time, quite a feat since that core isn’t even properly supported by the official SDK yet. The official SDK has also been updated recently along with new documentation released, making the BL808 an even better MCU platform.\nLastly, since we’ve been asked countless times about when the 65W portable GAN PinePower will be back in stock, I\u0026rsquo;d like to point out to everyone reading that the redesigned PSU is now available in the Pine Store. It comes with adapters for all regions and fixes a key problem with the original - namely, it no longer falls off from your wall socket, which was an issue for US customers. You can pick one up here if you’re interested. PineTab2 Let’s start with the big news which many of you have been waiting for - pricing and expected availability. The PineTab2 will be available in two hardware configurations: with 4GB of LPDDR4 RAM and 64GB eMMC flash and 8GB LPDDR4 RAM and 128GB eMMC flash storage. The 4GB/64GB version will be priced at USD $159 and the 8GB/128GB version at USD $209. Aside from the RAM and storage configuration both versions are identical and come with the detachable keyboard by default. The PineTab2 hardware review finished earlier this month and we expect that both hardware versions will be available simultaneously in the Pine Store - likely sometime in April. Obviously there is much that can go wrong during production (as it has with many devices in the past) and delay the delivery date so please consider this availability window tentative at the time being. Marek or I will notify you in the event of any setbacks and obviously also once a precise launch date has been set. Here\u0026rsquo;s a picture of the PineTab2 FOSDEM demo\nI covered all core hardware specifications of the PineTab2 in the last community update of last year, so this month I’ll instead focus on sharing my impressions of the hardware, now that I’ve had some proper hands-on time with it. If you’ve missed the last community update then I encourage you to read it before continuing with this section. At the start of February I spent the better part of two days with the PineTab2 at FOSDEM demoing it for other people and showcasing its features. You’d be surprised how much you can learn something while being put in a position of showcasing it to others. This is in part because people are interested in different aspects of the device - so my attention was drawn to things I’d otherwise overlook - and partly because explaining things to others forces one to explore a device in-depth in anticipation of inbound questions. I therefore feel I’ve got a more complete picture of the device than I usually do after only having short hands-on time with it. Mandatory disclosure first: my experience is based on a pre-production prototype and anything and everything I share in the post below is subject to change. With that out of the way, here is what I can say with the PineTab2: for starters, the hardware’s construction is truly next-level. I don’t want to give you a false impression that the PineTab2 is impeccable or somehow on par with the fruit tablet for this isn’t the case, but it is certainly the most refined PINE64-branded Linux device thus far. The metal construction in conjunction with the fused tempered glass LCD panel results in a very robust and sturdy build that I cannot see anyone complaining about. There’s no creaking, no bending, no rough edges and there’s no doubt in my head that the PineTab2 could easily be passed off as a device twice the price. I should also mention that the finishing on the metal and the assembly fit is downright perfect. As for the rest of the construction - the rear camera cut-out is unobtrusive, sits flush with the case and is covered by tempered glass. The power-in USB-C and OTG USB-C ports offer a nice positive fit when a cable is inserted; there is no looseness or cable-wiggle to speak of and the ports are clearly labeled. The power and volume up and volume down buttons don’t have much travel but offer a satisfying actuation feedback when pressed. I honestly haven\u0026rsquo;t noticed the front-facing camera under the bezel so I have nothing to report about it, perhaps aside from the fact that you’re also likely not to notice it either (which is a good thing in my book). The bezels around the LCD aren’t super thin by any stretch of the imagination but they are certainly not thick or obtrusive either. I find them perfectly adequate and obviously a massive improvement over the original PineTab’s design.\nClose up picture of PineTab2 ports - via Jozef Mlich\nThe LCD panel does get both bright at the highest setting and very dim at the lowest setting, although, in the very brightly lit corridor where our stand was located, it was a bit difficult to judge the actual brightness levels. It is less bright than my 2020 Pinebook Pro at max settings (these early Pinebook Pros had very bright screens) but at 75-to-100% brightness I think you’ll get work done in very bright environments without any issue. I can’t speak to the dimmest setting because I only tested the device in very bright conditions; at 10% brightness, in a bright daylit room, the image was very dim. The LCD offers very good viewing angles and natural or perhaps even slightly muted colors. I need to once again underline that I had my hands-on prototype and that the LCD’s cool color reproduction may have been down to this particular unit\u0026rsquo;s calibration, the software settings, my objective perception or something entirely different. What I can say is that the display’s color reproduction did seem cool to my eyes. I won’t be able to tell you anything about the PineTab2’s audio because, despite getting it working on the second day of FOSDEM, the venue at the conference was so loud that even a high-end laptop would be barely audible on the premises. But what I can say is that the sound now works - I’ll speak more on software further down in the text. The other critical part of the PineTab2 is the keyboard which doubles up as a protective cover. I am happy to report that, similarly to the device itself, it is constructed really well. It is sturdy, the keys have a lot more travel than you’d think, the trackpad works well and attaching / detaching the keyboard from the PineTab2 is a seamless experience (thanks to the USB 2.0 protocol on the pogo pins). The backlight has two brightness settings and works well too - although, admittedly, I haven’t had an opportunity to test it in a dim environment. The backlight is visible in a well lit room so one stands to reason that it will be perfectly legible in the dark too. The keyboard is nearly as heavy as the actual tab, or at least so it feels. The reason for this is the construction of the stand which is a solid piece of metal attached to a solid metal hinge. When open, the PineTab2 isn’t going anywhere - the stand’s construction is rock solid. There is a cutout for the rear camera and all buttons and IO are unobstructed when the device is mounted in its case. The last things I’d like to mention about the keyboard are: it doesn’t feel particularly cramped, the material it is made of has a nice soft-touch feel to it and it holds the PineTab2 securely in place.\n**Being the genius that I am, I completely forgot to take pictures of PineTab2\u0026rsquo;s rear - you can kind-of make out from the picture above\n**\nThe other important component of the PineTab2 is obviously its software. Here too I have good news to report. At FOSDEM we demoed a custom build of Arch with KDE Plasma Desktop and I’d describe the experience as very positive, especially given that Danct12 didn’t exactly have much time to generate the demo build. To be precise, there are currently only three ‘significant’ things that do not work: USB3.0 (it is being actively investigated), cameras and Bluetooth. The USB3.0 not working is a bit of a mystery, but it will be worked out in the end, the cameras will take time to implement as they have on the PinePhone and PinePhone Pro, and finally the Bluetooth functionality will require some driver-work. I need to mention that we can thank Segfault, DieselNutJob, Danct12, Neggles, as well as many other contributors who previously worked on Quartz64 and SOQuartz for the relative maturity of the software even before launch.\nI’d describe interacting with the desktop environment as a good experience and on par with the Pinebook Pro or a higher-end Single Board Computers. It is certainly good enough for terminal tasks or running an office suite for work, browsing the web, watching local or online videos, playing FOSS or retro-games and even light photo editing in GIMP. For practical reasons we ran the OS from an SD card at FOSDEM, which resulted in slow(ish) opening of applications and it certainly also had a negative impact on application’s performance, in particular if said application requires frequently loading assets from or caching to storage. From my experience with the PinePhone (Pro) and Pinebook Pro, I expect that the performance will be greatly increased by running the OS from inbuilt flash. This is the demo build that we were running at the stall\nDespite being in use all the time, for hours on end, and being continually charged and discharged, not to mention having the LCD brightness set to 75-100% for much of the time, at no point did I experience the PineTab2 getting hot or even excessively warm. In all fairness, no one fired up a taxing application or a complicated benchmark on the demo machine but hundreds of people toyed with the PineTab2 at the booth, and a handful of applications ran open at all times. I cannot see thermals being an issue on the PineTab2. In summary, the PineTab2 is in all likelihood the most refined PINE64 Linux device yet and one that will offer a moderately mature software experience out of the box for early adopters. I suspect that the PineTab2 will prove a very popular device and I hope that the remaining software quirks will be ironed out and missing features will be added swiftly; perhaps even before it ships. I am personally very much looking forward to the PineTab2 as it is exactly the type of device I am currently in need of. I’ll make sure to keep you updated on any and all PineTab2 news in the coming weeks as we get closer to the launch window.\nStar64 We were thrilled to be able to demo the Star64 running desktop Linux at FOSDEM. Ayufan, one of our longest-standing contributors whom many of you will recognize from his work on the Pine A64(+), the Rock64, Pinebook Pro and RockPro64 (just to mention a notable few) managed to put together a demo build of Debian with XFCE for our stall. I should also mention that he put the build together in a record time, in about a week, and managed to set it up on-the-spot on the day of the first day of the conference. The demoed build was fairly rudimentary, in terms of both scope and function, but nonetheless it achieved its core goal: it showed off full-blown Linux running on the RISC-V SoC beating at the heart of the Star64. The setup was pretty cool, featuring a 1080p touch panel which worked remarkably well, as well as a more traditional keyboard and mouse input. I’d say that bar the PineTab2 and some of the very popular devices - i.e. the Pinecil V2 and PineTime - the Star64 was one of the most closely scrutinized pieces of hardware at the stall. Here\u0026rsquo;s ayufan setting up the demo live :)\nPeople were able to browse the web in Firefox (WiFi works), edit documents in LibreOffice, poke around in the terminal and do a wide-variety of simple desktop-oriented tasks. Many were impressed by the board despite some of the sluggishness caused by software rendering and running the operating system from a SD card, which resulted in long loading times. To many I spoke with, this was the first time they saw Linux running competently on a sub $100 RISC-V development board. I should also mention that the demo ran remarkably stable throughout the two days, with people opening dozens of Firefox tabs, attempting to find and install applications they use (a bit more on this later) and stressing the system. I think that the hacky and cobbled-together build only crashed twice over the course of the two days. As cool as this is, there isn’t a way to sugarcoat it, and it needs to be said the Linux experience on the platform is in its early stages. Indeed, Linux really is in its infancy on the RISC-V. And I’m not even talking about complicated things, such as driver-work or enablement of some particular kind - I am talking about Firefox not being present in the stock Debian repo and having to be installed in a round-about way or compiled from source. Alas, interacting with the Star64, as cool as it is, reminds me of running Linux on Arm in 2013-2016. It is instantly apparent that much work is still needed for parity to be achieved with other Linux-capable platforms. All this may sound like I am being negative about Star64 or RISC-V but nothing could be further from the truth - let me explain. For Linux to truly take off and grow on RISC-V there is a need for easily accessible and affordable hardware. Unlike other full-blown SBCs in our stables - most of which can be used by businesses, enthusiasts and regular end-users out-of-the-box - the Star64’s purpose, at least presently, is to lower the entry barrier to obtaining a competent RISC-V development platform. I see it as an important platform for developers already interested in RISC-V wishing to explore the architecture. No matter the product, be it a pie, pencil set or a piece of electronics hardware, there are always three fundamental conditions that need to be satisfied to drive adoption: 1) an existing customer interest or a gap in the market; 2) ability to deliver abundant availability of the product and 3) fair pricing making said product accessible. I think I don’t need to convince you that there is an existing interest in the RISC-V platform already, but what I do want to underline is that we’re committed to Star64 and will strive to make it an amazing value-proposition that anyone can pick up. Star64 running Debian with XFCE desktop at FOSDEM\nFinally, I am happy to let you all know that Star64 has finally completed its review and entered production. I do not have a firm availability date to share just yet, but you can expect units from the initial production run to become available at the end of March or beginning of April. I will, of course, make sure that those of you aching to get their hands on our first RISC-V board get notified of availability. PinePhone (Pro) [by Lukasz \u0026amp; Biktorgj] It has now been quite some time since I had a chance to report on the PinePhone and PinePhone Pro, and boy oh boy has there been much work done on both devices in the past two months. I should also mention that I learned of some developments in-person at FOSDEM. As a side-note, it was amazing to see so many people approach our stall, pull out their device and share their (overwhelmingly positive) stories of using the PinePhone or PinePhone Pro. The last time I attended FOSDEM was in 2020, when the volume of PinePhones was still relatively low and I had not been to a conference since, so it was truly a humbling experience to see so many PinePhone and PinePhone Pro owners gathered in one venue. Before I get down to reporting about the software developments on the actual PinePhone and PinePhone Pro devices, I first want to cover developments concerning the PinePhone (Pro) keyboard case. Many of you will be thrilled to learn that Megi released version 1.3 of his open firmware. The firmware brings a massive improvement to the phone\u0026rsquo;s battery life when connected to the keyboard - to be precise, the new firmware brings a 30 fold reduction of power consumption, thereby extending the theoretical standby time from 23 days to nearly 1.8 years. Megi explains that previously a bug caused the MCU to “(\u0026hellip;)never [get] to that original 9 mW powerdown mode power consumption level [\u0026hellip;] and it was just constantly consuming 20 mW. This was the cause of unexpectedly fast battery draining.” He concludes his post by writing that it is now possible to leave the phone connected to the keyboard without worrying about the phone’s battery draining - at least not in a tangible or meaningful way and under normal use. You can read the detailed post here; the post also details how to upgrade your PinePhone (Pro) keyboard with firmware 1.3. Staying with Megi’s development (b)log just for a second longer, I should also mention that Kernel 6.1, which has found its way into some of the more popular PinePhone (Pro) OSes, brought a fix to the PinePhone Pro’s LCD display. The display now runs at the correct 60Hz whilst in the past it was limited to a suboptimal 53Hz refresh-rate. Speaking from experience, the 53Hz refresh-rate caused a variety of problems including but not limited to stuttering, which was evident even in the system UI. Ultimately this made the phone feel more sluggish. Megi’s Kernel 6.1 also brought an integration of the power manager for the PinePhone (Pro) keyboard. This driver has a handful of improvements in its newest iteration, including better battery power reporting and higher power efficiency. The phone now uses the keyboard’s battery directly without needlessly having to recharge the phone’s internal battery first. Megi’s newest kernel also brings a number of other smaller improvements, which I invite and encourage you to read about on the author’s blog. In other welcome software news, the PinePhone Pro has now received support from Libcamera. While the application is certainly at an earlier stage than Megapixels on the PinePhone Pro, it does look extremely promising. With the PinePhone Pro’s camera sensor drivers now being upstreamed, and expected in mainstream kernel 6.3, support for the device has been merged in v0.0.4 of Libcamera. The application apparently features colour correction (which, to my eyes, is very evident on the rear camera) and either already has or soon will incorporate auto-focus. For those of you who wish to give it a spin you can now install the application on Mobian - I do not know whether other OSes have it already available in their repos. Ultimately, it is nice to have options, and whilst Megapixels is undeniably a great project I can see some end-users eventually settling for using Libcamera on their PinePhone Pro. In summary, Libcamera looks very promising and I am happy to see so much development happen around the PinePhone Pro’s cameras in such a short period of time. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video of Libcamera on the PinePhone Pro via Libramera\u0026rsquo;s Youtube\nAnother development worth highlighting concerns Apache NuttX being ported to the PinePhone by Lup Yuen. For those of you who may not be in-the-know, NuttX is a RTOS system - primarily used on microcontrollers - which places an emphasis on standard compliance and a small footprint. The latter of which is highly beneficial to the original PinePhone, which benefits from running light-weight OSes. I haven’t had the opportunity to try out the OS myself but from the few glimpses I caught of it I’ve been impressed by the fact that the screen and touch input seem already to work. Lup has publicly stated that, at present, NuttX isn’t an alternative to Linux on the PinePhone, since many drivers are still missing and hence the functionality of the device is very limited. He does, however, see the value of the port for educational purposes. Regardless of whether NuttX will see further development, growth and eventual adoption, I must say that it is nice to see yet another FOSS operating system on the phone. NuttX running on the PinePhone - photo from Lup Yuen\u0026rsquo;s blog\nAt FOSDEM I caught the first glimpse of Ubuntu Touch on the PinePhone Pro. Indeed, our friends from UBports borrowed a unit for the purpose of demoing the build at their stall. I had the opportunity to toy around with the demo at UBports stall and I was very impressed with what I saw. The performance of the PinePhone Pro running Ubuntu Touch is indistinguishable from other mid-to-high-tier that were on display. To say that it runs Ubuntu Touch well is an understatement: the UI is perfectly responsive, applications launch fast (running from internal flash) and all this atop of mainline with open source GPU drivers. From what I could tell WiFi, Bluetooth and even the modem were all recognized on the current build - although I don’t have a complete overview of how (in)complete the demoed build is. Speaking of the build,I should also note that presently this isn’t an official port nor is it known whether UBports expect to keep on working on the device, although I certainly hope so since what I experienced was very promising to say the least. I captured a quick video, which I am including below.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Ubuntu Touch on the PinePhone Pro - how awesome is that?\nJust in the past 2 days we’ve seen the release of a new Manjaro beta (version 29) for both the PinePhone and PinePhone Pro. Most notably, the new build brings Megi’s kernel 6.1, some of the benefits of which I described earlier in this text section. I’ve given the Beta a go on my PinePhone Pro and must say I was very impressed with the out-of-the box experience. In particular, for the first time I had no issues with plugging in the device, with the keyboard case connected to a dock and having all peripherals, including an external high-DPI monitor, just work. I feel that the PinePhone Pro has really received a lot of development in the past two months, which consequently has brought it much closer to feature parity with the original PinePhone, and Manjaro’s latest build truly manages to illustrate the scale and breadth of development. You can download the most recent Beta build here. I should also mention that, similarly to Manjaro, a number of other OSes have received updates in the past few weeks, including DanctNix’s Arch, postmarketOS as well as Mobian. I haven’t had the opportunity to test out all these builds, although I did install Mobian to try out Librecamera earlier this month, but I believe that all of them have now moved to Megi’s kernel 6.1.X which I already discussed. That is to say, most if not all the aforementioned OSes should now have a 60Hz refresh on the PinePhone Pro and the keyboard case driver optimizations. It is also worth noting that postmarketOS has received an update to SXMO, which is now on 1.13.0 release and includes a number of improvements and refinements. I would be remiss not to highlight some of the work that Adam Pigg and contributors have done on the PinePhone (Pro) SailfishOS port. I should also add that this is the nth year in the row that the PinePhone port of SaiflishOS tops the chart of unofficially supported devices - much thanks to the ongoing work which I’m about to highlight. SailfishOS now has support for both the keyboard case and both cameras. Adam demoed the camera and keyboard functionality recently and from the looks of it both are very functional on the operating system. The Pinhole camera application even offers support for different pixel formats and resolutions. Late last month I was also told that telephony on SaifishOS is now in a good state on the PinePhone - which includes receiving inbound calls when the device is suspended. Overall, I think it is fair to say that SailfishOS on the PinePhone is shaping up really well and that it may become a daily-driver candidate sooner rather than later. Wrapping up this section, I should also note that a new build of Nemo Mobile,which is based on SailfishOS, has recently become available. I do not know how much of the work on the SailfishOS port carried over to Nemo mobile, but I’d be very glad to hear about your experience with this operating system on the PinePhone. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video SailfishOS now works with the keyboard case and the camera works too! - via Adam Pigg\u0026rsquo;s Twitter\nLastly, I need to mention Biktorgj\u0026rsquo;s work on the PinePhone (Pro) modem. The recent testing release in the version 0.7.3 of biktorgj\u0026rsquo;s PinePhone Modem SDK allows the modem\u0026rsquo;s userspace to connect directly to the Internet even when the PinePhone is suspended. It is the biggest release of the PinePhone Modem SDK yet. I’ll let Biktor explain what this means in practice: “This week I released a new firmware update for the Pinephone (and Pro) modem. I\u0026rsquo;ve had a lot of fun coding this, and while it isn\u0026rsquo;t perfect (and has a small yet annoying bug that will be fixed soon), it gives new options to both users and tinkerers: 1) the ability to keep your network a bit more under control and 2) support for connecting to the internet from the modem\u0026rsquo;s userspace, and then use the modem as a router.\nTracking your network: the modem can now periodically read the current network data, save all the data provided by the baseband about it to disk (so you can later examine it, put it into a database etc.) and check that data against the OpenCellid database, and even shut itself down if it connects to a cell that it doesn\u0026rsquo;t know about. While it\u0026rsquo;s not foolproof against a modern IMSI Catcher, it can warn you and take action if it finds something out of the ordinary, which is already way more than what any other phone can provide.\nInternet on the modem itself: one of the big problems with notifications in the Pinephone is that when it suspends, the only way to wake it up again is from a call, a message or from a button press. Having the data session running directly from the modem\u0026rsquo;s userspace allows it to stay always on regardless if the Pinephone is awake or sleeping. This first version is basically a PoC to allow us to know what else we need to fix, but the idea is to try to integrate something like UnifiedPush into the firmware\u0026hellip; but that will be a story for when it\u0026rsquo;s all done and working”. These features obviously bring some incredible possibilities down-the line and I cannot wait to see how the community can make them work to the advantage of us all. Pinetime [by JF] This year, I attended both days of FOSDEM (4th and 5th of February) and it was a nice opportunity to meet TL, Lukasz and Gamie from PINE64, as well as many PINE64 community members and users. With me I brought a few Pinetimes flashed with InfiniTime 1.11 FOSDEM Special Edition (this special edition displays the FOSDEM logo as a background for the Digital and Analog watchfaces) to showcase them at the PINE64 stand.\nFOSDEM special edition watchface\nTo be honest, I did not expect the PineTime to have so much success on the stand, knowing that it was competing with other PINE64 devices shown (PinePhone, PinePhonePro, many SBCs, Pinecil, SoQuartz Blade,\u0026hellip;) and 2 great demos - the PineTab2 and Star64!\nI spent most of the time at the PINE64 stand. I had the opportunity to meet many visitors, users, community members and even some developers working on multiple projects around the PineTime and InfiniTime, most of them proudly wearing their own PineTime on their wrist! If someone had told me in 2019, when the project started, that I would see so much PineTimes in one place I wouldn\u0026rsquo;t have believed it.\nSo many PineTimes at one table!\nThe feedback was very interesting - we talked about the history of the project, use-cases I would\u0026rsquo;ve never imagined, new features that could be added to the project, how we would like to see the project evolve, and much more. In many cases, feedback was very positive, and I would like to pass all the \u0026rsquo;thank you\u0026rsquo; and \u0026lsquo;congratulations\u0026rsquo; I received those 2 days to everyone involved in working on the PineTime and InfiniTime!\nLet\u0026rsquo;s continue this update with some news related to InfiniTime and the PineTime ecosystem!\nWe haven\u0026rsquo;t released a new version of InfiniTime for some time now. This is mostly due to me having not so much time to dedicate to the project right now. We also want to focus a bit more on the maintenance of the project - to add more automations, refactor some parts of the code, optimize the memory usage and more. But that obviously doesn\u0026rsquo;t mean that nothing happens in InfiniTime. Indeed, more than 30 pull-requests have already been merged in the development branch since last release. Among other things, you can expect better battery level monitoring and a few UI improvements in the next version. We are also reviewing changes that will improve the heart rate measurement, the addition of weather information in PineTimeStyle, and many other things that might be reviewed and merged in the future!\nI\u0026rsquo;m happy to announce that we now have a Windows companion app! TailyFair started working on InfiniWindows since they couldn\u0026rsquo;t find any solution that would work for them on Windows. I really hope this project will grow and become a part of the PineTime ecosystem!\nWatchmate allows you to flash firmware onto your PineTime\nThe PineTime has always been intended to be a hackable smartwatch, and Joaquim proved to us that it\u0026rsquo;s true with this amazing project. Joaquim, who has already contributed to InfiniTime especially with a nice overhaul of the UI, designed a replacement board for the PineTime based around the NRF52840 microcontroller. It provides more performance and memory than the NRF52832 from the original board. He also developed a custom firmware that runs on this board which looks really great. Have a look at the video he published on his website!\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video PineTime with nRF52840 board running Joaquim\u0026rsquo;s firmware - pretty awesome!\nThat\u0026rsquo;s it for this month, catch you all in March!\n","permalink":"/2023/03/01/february-update-things-are-taking-shape/","tags":["pinephone-keyboard","pinephone-pro","pinetab2","quartz64","soquartz","star64"],"title":"February update: things are taking shape"},{"categories":["community","news","ox64","pine64-community","pinephone","pinephone-pro","pinetab","quartz64","quartzpro64","risc-v","star64"],"contents":"\nMerry Christmas, happy holidays and a Happy New Year to you all. This month’s update has a different formula from the usual - aside from the announcement of the PineTab2, most of this month’s content is dedicated to looking back at this year and taking a sneak peak at what\u0026rsquo;s to come in 2023. I think that if you read between the lines, even poorly, you’ll get a good idea of what we’ll be up to next year. We have a lot of ground to cover in this update so let\u0026rsquo;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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank Alex (clover), Gamiee, Danct12, Pillow, Thanos, Immy and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of the December community update\nTL;DR\nHousekeeping Thank you for 2022 everyone! November community Q\u0026amp;A is now on Youtube and Odysee if you missed it We’ve got a FOSDEM 2023 stall - we’re on the floor both days, come and see us Work on the new website is coming along PINE64 EU store restock before Christmas We’ve had an incident in #off-topic channel - we’re on it and working towards better moderation of all chats Newsflash Star64 launch delayed due to review; striving to make it available before CNY Ox64 among the fastest selling PINE64 hardware Pillow has done much work on the Quartz64, SOQuartz and QuartzPro64 in the past month; much work has gone into mainlining and critical bug fixes - significant progress Much Pinecil V2 news and showcases: new Pinecil V2’s ship with firmware v2.20, Bluetooth functionality casting telemetry to computer, transparent Pinecil mod with LEDs, a nice 3D printed carry case and more New DietPi release brings many important improvements to the Quartz64 and SOQuartz A look back at 2022 A review of the year 2022 with an explanation of its significance moving forward: launch of the PinePhone Pro and keyboard case; introduction of the QuartzPro64 for devs; launch of Pinecil V2 and PineBuds Pro; and finally our first RISC-V SBCs 2023 sneak peek A look at where PINE64 and in the year 2023 and beyond: focus on RISC-V alongside Arm with potential RISC-V based hardware in the coming year PineTab2 An explanation of what happened with the original PineTab; in a nutshell, it fell victim to pandemic and post-pandemic production issues and other project priorities Sports a metal case which is easy to disassemble for repair and hardware hacking Features the RK3566 - a great SoC for a tablet due to low power consumption and low thermals Two USB-C ports - USB 3.0 other USB 2.0 speeds and dedicated for charging; micro HDMI port for video output; microSD slot \u0026amp; headphone jack; a 2MPx and 5MPx camera Will be available in 2 configurations: 8GB RAM / 128GB flash \u0026amp; and 4GB RAM / 64GB flash storage Launch and price point not known yet - expected sometime after CNY Dev units available soon (prior to CNY) PinePhone (Pro) Major SailfishOS developments; sensors now work properly as does audio and calls work Expectation that receiving calls in suspend will be possible soon on SailfishOS Megi’s newest kernel brings countless improvements; improvements includes 60hz refresh for PinePhone Pro, complete CSI driver rewrite and DRM improvements on OG PinePhone Better support for the PinePhone (Pro) keyboard case Kali Linux launches Nethunter Pro with official support for both the PinePhone and PinePhone Pro Housekeeping I’d like to start by thanking Marek (Gamiee) for his incredible work in the past year steering this project. Marek has done an incredible job taking over from me and I see how much thought and heart he puts into this community. We also need to thank Matthew (fire219) and all the moderators for maintaining our communications channels and keeping the community orderly. We all also much acknowledge the work by contributors and our partner projects - without them and their hard work there would be no PINE64. I also want to express gratitude to those working on the community update each month - in particular PizzaLovingNerd, Alex (Clover) and JF. You’ve all done an amazing job this year. Last but certainly not least I also want to thank all of you who support us - your support for the project and, by extension, the Pine Store is what pushes us to explore new avenues, create new hardware and foster a great community. Thank you everyone for 2022. We had a great Q\u0026amp;A session in November with countless questions being asked and answered. Thank you to everyone who joined us in the chats, asked questions and listened-in on Youtube and the Discord stage. I think that the Q\u0026amp;A is a really great way for the community to come together and interact with people shaping the project. I am aware that we ran out of time and some questions remained unanswered at the end of the event. And I know this isn’t the first time it happened. This leads me to think that it may be a good idea to make the Q\u0026amp;A session a bit longer to accommodate more questions - although, there is a limit to how long Marek and I can talk aloud and provide focused answers. I am also considering allowing people to post questions in the chat a day or two prior to Q\u0026amp;A. Feedback regarding these ideas is welcome - after all, this session is meant to benefit you. So please leave your thoughts on the Q\u0026amp;A and how to make it a better event for the community in the comment section below. It is a bit early to plan the next Q\u0026amp;A right now but it will be held at some point either in late February or early March next year.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video November community Q\u0026amp;A live recording\nWe got a stall at FOSDEM! I cannot overstate how happy to once again attend the event in-person, meet members of our community and man the stall. We have a huge number of things prepared for the meetup and there is at least one important announcement we’ll be making on February 4th. Mark the date in your diary. If you are in Europe and able to travel then make sure to pop by our stall and say hello - there’ll be plenty of gear to check out and discuss. The exact location of the PINE64 stall hasn’t been made available yet on FOSDEM’s website but I suspect that by January 15th and the next community update. I have also been toying with the idea of live-streaming or recording videos from the stall so that people from the community who cannot travel can virtually ‘visit’ check out some of the things we’ll be showcasing. What do you make of this idea? - let me know in the comments. Work on the new PINE64 community website is ongoing and, while we don’t really have an ETA for the new page’s launch, it is shaping up really nicely thanks to the work by a handful of community contributors, including Vincent who’s in charge of layout and assets. I am including a few snapshots below so you get a general sense of where the redesign is heading; the new website will focus on the community, giving this blog more of an exposure and allowing quick and easy access to all available documentation as well as chats and forums. I also hope to have some sort of exposure of community projects - perhaps something to the effect of the #community-content channel or the newsflash section in this blog. I really like the direction this website rework is heading and will be bringing you more updates on it in the near future. A peek at the new website (work in progress)\nPINE64 EU is receiving restock shipments soon. I am mentioning it in this month’s update for two reasons: i) it may take time for the shipments to clear customs due to the high volume of work at both the customs and the proxy customs agencies. It usually takes 7-9 days for a shipment to clear customs (following the mandatory harmonization process) but this time it may take much longer. Regardless, I hope stock will be received before the holidays ii) Shipments during the holiday season and in the weeks following it may take longer to arrive at their destinations - just a heads up. To stay up-to-date, follow the EU store’s Mastodon, Twitter and Telegram news channels. Lastly, I want to spend a few lines explaining the situation regarding a temporary closure of the #off-topic chat, the consequences of the closure and what steps we’ll be taking in the coming weeks to deal with the situation. The #off-topic chat was temporarily closed by Matthew (fire219) due to an - apparently on-going - clash between multiple members of the community. Let’s just say that some of the topics discussed in #off-topic (which should have never been discussed in the first place) led to very heated discourse. Internally this raised a question of whether the current code of conduct is sufficient for consequential moderation and if we should create a moderation guideline for the mods. People from different walks of the internet and of various sensitivities have been employed to help craft better community guidelines and patch holes in the existing code of conduct. I want everyone to know that we’ll be taking steps to make the community free of unnecessary conflict by working towards a more active and balanced non-intrusive moderation. The #off-topic channel has now been reopened for everyone to enjoy non-PINE64 specific conversations. NewsFlash [by Lukasz and Pillow] Let me start by writing a few words about Star64. Last month I warned everyone that there is a very real possibility of delays in production of the PineBuds Pro, Ox64 and Star64. While the delays of the PineBuds Pro and Ox64 were relatively minor the delay of the Star64 may be considerably longer. To be clear, the Pine Store is still very intent on releasing the board prior to the Chinese New Year (which starts on January 22) but a firm release date isn’t known as of yet. At this point the board is undergoing an additional review process and, due to various external reasons, it is hard to predict with complete certainty when the review will be finished. I’ll update you on social media when more information is available. The Ox64 is now one of if not the fastest selling PINE64 SBC. To be fair I don’t really remember nor have direct access to the data of other other popular SBC launches, but this is certainly a really good start with strong community interest in the device. The December batch sold out very fast but rest assured that more Ox64s are on the way and a restock is currently scheduled for January of next year, before CNY. I am looking forward to hearing people’s early impressions from the first Ox64 boards. The past month Pillow has been busy mainlining some more SOQuartz devicetree bits. GPU, HDMI (including audio) and PCIe should work starting with kernel 6.2. Based on work neggles has done, Pillow also mainlined the device trees for the \u0026ldquo;Blade\u0026rdquo; and \u0026ldquo;Model A\u0026rdquo; baseboards for the SOQuartz. This work should also be in kernel 6.2, which is currently in its merge window phase. wifasoi from the PINE64 chats is working on a driver for the GP7101 PWM controller that controls the fan speed on the SOQuartz Blade. Pillow is working on a set of automatically generated Debian-based live OS images for the Quartz64 range of devices including the SOQuartz. More information about these builds will be available when they\u0026rsquo;re ready for public use. The goal is to provide a smooth out of the box experience for Quartz64 devices.\nFor the QuartzPro64\u0026rsquo;s RK3588, Pillow’s work to make audio output work on it was merged for the 6.2 release cycle. The changes needed were minimal as the I2S controller hardware is mostly the same as the RK3566 one. Attempts to get USB 2.0 to work ran into weird issues with the SoC locking up when it touched the right registers at the wrong time. There\u0026rsquo;s probably some power management or clock gating stuff missing from the mainline kernel at this stage, so it was put off for later. As for what other people have been doing, Collabora has been incredibly busy getting the mainline kernel into shape for RK3588. This includes basic SoC support, power regulators, and so forth. They\u0026rsquo;re also working on Mali G610 GPU support both in the kernel and in upstream mesa. neggles has also written a basic mainline targeted QuartzPro64 device tree that hasn\u0026rsquo;t been submitted upstream yet. As for u-boot, we\u0026rsquo;re still relying on vendor u-boot and closed-source TF-A and ram init binaries there.\nSome awesome initial work on Pinecil V2 Bluetooth has been showcased earlier this month by Joric. Joric’s video shows Pinecil V2 connecting via Bluetooth to a PC and projecting key stats in a browser. This is a much requested feature and one that holds a promise of much more functionality in the future. River has also uploaded a video - of what I imagine is a newer build of the web app - which casts the temperature on a graph alongside Wattage, Voltage and even the handle’s temperature. At present this web application serves effectively as a large display for the Pinecil V2 projecting all the telemetry on a large screen, but it doesn’t allow for any control input. This, however, may be a feature in the future.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video showcasing the Pinecil V2 connected to a PC via BT - via Joric\nThe newest batch of Pinecil V2 (now in production) will ship with firmware v2.20 and its numerous improvements. Aside from a fair collection of bug fixes it also includes Cold Junction Calibration which was reworked - it now takes place on each boot when the device is cold. Moreover, it also comes with a language pack, which covers most major European languages. If you already own a Pinecil V2 then this is a firmware to look forward to - you can read the complete release notes here. We’ll be staying on the subject of the Pinecil for just a second longer, since I want to highlight two more Pinecil-related user projects. The first of which is a highly modified Pinecil V2 - as you can tell from the attached picture, u/malimaru added two LEDs to the device - one in the front and one in the back of the transparent case. This obviously doesn’t really improve the iron’s usability - if anything, it may be quite distracting I imagine - but it sure does look pretty awesome.\n**Blink blink - via reddit\n**\nThe second Pinecil maker project that caught my attention is a carry case designed by a community member by going by the handle u/Pegor. To date I’ve seen countless carry cases crafted for the Pinecil, many of which are 3D printed, but this particular design stood out to me from the crowd due to its elegant simplicity. Unlike many cases which aim to pack as much functionality as possible into a very confined space, this carry case is just and only that - a carry case. You can pack the iron and a tip of your choice and that\u0026rsquo;s it (perhaps a cable would fit too - although I’m not sure). The lid is held in place with magnets and features a nifty PINE64 pine cone logo. I’d really like to have one to be honest - so if you have a 3D printer, some spare time and will be attending FOSDEM, then print it for me and I’ll trade you something cool in return for it. For those interested in this case, u/Pegor uploaded the STL files here. **I really like the look of this Pinecil carry case - via reddit\n**\nDietPi now offers significantly improved support for Quartz64. The most recent release of the popular SBC OS ships with Linux 6.1.0-rc1 which features support for model-B onboard WiFI. Moreover, the build comes with mainline u-boot which resolves issues with certain types of SD cards as well as eMMC modules. An issue which caused Docker to fail to start has also been resolved - the issue was caused by missing support for a BPF cgroup. If you’re already running DietPi on your Quartz64 then this is a release well worth upgrading to; you can read the complete release notes for DietPi v8.11 here. A look back at 2022 January saw the launch of both the PinePhone Pro and the PinePhone (Pro) keyboard case. As far as PINE64 devices go, there haven’t been many hardware launches that drew this much attention from the press and the Linux community as that of the Pro version of our Linux smartphone and the accompanying keyboard case. I think it will go down as one of the biggest and most well-managed launches that the Pine Store and PINE64 community executed. The PinePhone Pro and the keyboard case have become very popular and, judging from community feedback and the ongoing development (see this month’s PinePhone (Pro) section), these devices bring end-users and developers not only challenges but also joy of use. The PinePhone Pro will remain the flagship PINE64 mainline-based smartphone for a long time to come and I am thrilled to see so much work and development that gradually matures the software on the platform. I hope and trust that by the end of 2023 the PinePhone Pro will reach software parity with the original PinePhone. March saw the introduction of the QuartzPro64 development board, the first board in our lineup to feature the RK3588 SoC. As a platform the RK3588 may prove to be an important Arm SoC for PINE64 and one that, in time, will find its way into our range of devices. At present, the decision was made to release the QuartzPro64 to developers only. The rationale behind this is to take it slow and explore the silicon and its possibilities. We wanted to get a sense of the SoC and its characteristics prior to settling on a future Pro-grade SoC; while the RK3588 may seem like a natural continuation from the RK3399 nothing is written in stone as of today. We’ll keep working on and with the RK3588 while keeping our options open. As I stated at the end of last year, we wanted to make 2022 all about smaller and perhaps less ambitious undertakings than phones and laptops. As exciting as such flagship devices are, their development is a major undertaking, which in turn requires time, resources and complete commitment to this particular hardware. A major hardware project is, in a sense, all-consuming and frequently dominates the direction of the project for months or even an entire year. Therefore 2022 was meant as a way for us to reset our headspace and explore other fun side projects that have been shelved for some time. One such project are the PineBuds Pro, which were introduced as a part of this year’s April fools joke. The buds landed earlier this month and we hope to see much development around them in the coming months - as I mentioned in November we’re waiting for Ben (Ralim) to release his Linux firmware flashing tool. The PineBuds Pro holds the promise of a device similar to that of the PineTime and Pinecil - something that anyone can pick up and use while also providing tinkerers and developers with an open playground. In July we launched the Pinecil V2. In the spirit of ‘if it ain’t broke don’t fix it’ the Pinecil V2 is an iterative improvement over the original. The new silicon brings with it Bluetooth connectivity and improves the soldering iron’s performance, which has landed it the top spot on Tom’s Hardware best soldering iron list. With recent developments enabling Pinecil’s connectivity (read the Newsflash section if you haven’t done so yet), I can see the iron becoming an even better device than it already is. Pinecil’s success is also enticing us to probe what other maker devices we could create or make better versions of. I think there are many possibilities in this regard, but I’m genuinely interested in what device in the vein of the Pinecil you’d like to see us make; leave a comment under this blog - I’ll read it, I promise. August and October saw the introduction of the Star64 and Ox64 respectively - our first RISC-V Linux-capable boards. While these are our first RISC-V SBCs they certainly aren’t our last; to the contrary, they are just the beginning of a much bigger trend within the PINE64 project. I’ll write more about this in the 2023 sneak peek section of this update. As I already mentioned, the Star64 has been delayed due to a review process and is due to launch sometime in the coming weeks, but the Ox64 has been out for a few weeks now and has been met with much positivity. Indeed, the Ox64 is probably one of the fastest selling items in the Pine Store to date. This shows both an interest in RISC-V architecture and a need for inexpensive boards such as the Ox64 on the market. The SoCs powering the Star64 and Ox64 hold much potential and I would count on seeing them utilized in future PINE64 devices. As a whole, this year was dedicated to exploring and setting a course for the future. Within the PINE64 project’s structure SBCs and devices are a part of a larger whole and tightly intertwined. SBCs often act as the means for a selected SoCs initial bring up, making it accessible to the development community, to be later transformed into a development platform for future PINE64 devices. To be more precise, ideas for devices such as Pinebooks and PinePhones emerge once a SoC shows promise and core software support becomes firmly established. I think that we now have a handful of very interesting SoCs on our hands - the RK3566 and JH7110 in particular. The coming year will see much development of these platforms and I foresee great things built upon these two SoCs - the PineTab2 being one of them. 2023 sneak peek As I wrote at the end of last year, and as it should be evident from what I wrote in the previous section, we’re very interested in the RISC-V architecture. As such, the much anticipated Ox64 and Star64 are merely early manifestations of our overarching plan for years to come. I should at the same time reiterate what I wrote in December of last year; while we have a strong will to explore, innovate and drive the RISC-V hardware space, this doesn’t mean we’re saying farewell to Arm as a platform. All it means is that you can expect us paying more attention to RISC-V this coming year and in the years to follow. As we see it RISC-V holds a huge promise for the community and for the Pine Store as a hardware manufacturer - a win-win situation. We believe that a few years down the line RISC-V will be able to offer more versatility and raw power at a lower price-point than Arm counterparts. It is also likely to benefit from fewer manufacturing restrictions and a higher degree of general configuration options. But that’s the future. As things stand, Linux and other FOSS systems have much catching up to do on RISC-V. I recently spoke to an authority (who doesn’t wish to be named) in the field of benchmarking and Arm SoCs in more general. Said person benchmarked a Star64 against the Quartz64, which resulted in the Quartz64 scoring much higher than one would expect against the Star64 (approx 30% better or so). During our email exchange I was told that while the Star64’s CPU may indeed be slightly slower than the Quartz64 in certain computational tasks, the benchmarked gap in performance is due to Linux’s software (im)maturity on RISC-V and not the hardware per se. If anything, this acts as an incentive to us. To develop FOSS OSes on RISC-V we\u0026rsquo;ll need inexpensive, well built and popular devices with an established community base. This means that some existing PINE64 Arm hardware will see RISC-V counterparts in the future. Indeed, future Arm devices will also, at least in some instances, be released alongside RISC-V counterparts moving forward. For now our plans concern non-Pro devices, in part because no Pro-grade RISC-V chip has been settled on yet. Before you get too excited - no, there are no plans for a RISC-V PinePhone at this time. We do, however, have some very exciting news in the pipeline that we’ll be sharing with you in a few weeks time. But as I already mentioned, we’re not in a rush. To the contrary, the primary goal at this point is to make sure that our first entry into the RISC-V device space is a solid offering. We’re working on something that developers and the core community will appreciate. If you happen to be at FOSDEM then make sure to stop by and say hi - we’ll show you what we’re working on and your socks will be blown off. PineTab2 Before we get to discussing the new PineTab2 let me first explain what happened to its predecessor. The original PineTab was conceived alongside the PinePhone in early 2018 at a small pub in Brussels, and a little less than 2 years later the PinPhone and PineTab became available for order. At that time a global pandemic was something that could only be experienced through the medium of film. I think it is fair to say that none of us could have truly imagined what a global pandemic would entail for the entire world, let alone understood the consequences it would have for hardware production, electronics supply chains and global economics. There is no need for me to recap how the pandemic unfolded, what effect it had on production in mainland China or explain the hardships businesses had to endure as a consequence of this, but suffice to say that the original PineTab was a victim of COVID and its fallout. For those interested in the details, I encourage you to browse the blog’s PineTab tag– I did my best to keep the community updated on the original device’s status throughout 2020-2021. In all fairness I should also make it clear that PineTab’s death was, in some part, a choice on our part as decisions were made to allocate resources to secure PinePhone’s availability throughout late 2020 and early 2021.\nA look at PineTab2\u0026rsquo;s PCB\nBy the time production of the PineTab became viable again we felt that the original design could and indeed should be improved on. By late 2021 there was also a great candidate SoC for a second generation PineTab – the RK3566. I have written extensively about the RK3566 in recent months in the context of the Quartz64, but in a nutshell, it is a modern mid-range quad-core Cortex-A55 processor that integrates a Mali-G52 MP2 GPU and supports up-to 8GB of RAM. It is a dream-of-a-soc for small form-factor devices with space-constrained chassis since it runs cool, offers a wide variety of modern and fast IO, has a solid price-to-performance ratio and is genuinely future-proof. The one thing that the SoC didn’t have for a time was mature Linux support – but this is no longer the case (see Newsflash section). Software development for the RK3566 platform is booming and Linux has now reached a high level of maturity with both mainline and BSP Linux supporting nearly all core functionality of the chipset. I feel it is fair to say that it is now a prime candidate for porting mobile OSes to.\nPineTab2 prototype with metal back removed\nBut the PineTab2 is much more than a spec-bumped version of the original (more on the specs later) – it is a complete physical redesign: you’re getting a metal chassis that is very sturdy while also being easy to disassemble for upgrades, maintenance and repair. Taking the PineTab2 apart is as simple as undoing a set of snap-tabs and removing the metal back chassis. As is the case with the Pinebook Pro, the PinePhone and the PinePhone Pro, we’ll be offering replacement parts for the PineTab2 down the road. To make the device end-user serviceable we’ve made the PineTab2’s guts modular. This extends to the tiniest of parts, including the eMMC which sits on its own little PCB, like on the Pinebook Pro or our SBCs. Indeed, most parts are easy to reach and replace in a matter of minutes – the camera modules, the daughter-board, the battery and USB keyboard connector can all be replaced in under 5 minutes. I’d also like to mention that the LCD can be replaced without any specialist tools, although it will require a bit more time and effort. If you are a Pinebook Pro owner and have ever taken it apart out of curiosity or for repair, then you’ll feel right at home with the PineTab2. Speaking of the display panel, we’re still evaluating our options, but it will feature a tempered glass 10’1 IPS screen with modern and reasonably thin bezels.\nIt is looking pretty good, isn\u0026rsquo;t it?\nLet’s talk about IO, components and connectivity. The PineTab2 has two USB-C ports, one of which is USB 3.0 and the other is intended for charging. The latter port features USB 2.0 speeds when it isn’t used for juicing up the PineTab2. There is also a dedicated micro HDMI port for video output and two cameras on the V2 – a front facing 2MPx camera and a rear facing 5MPx one. We haven’t settled on a WiFi/ Bluetooth module yet but two are being tested right now - I’ll let you know which one fared better in testing and was chosen for production. PCIe is exposed on the PCB but I wouldn’t expect most NVMe SSDs to fit inside the chassis. However other peripherals may fit the 9mm-thick envelope of the PineTab2. This won’t be an advertised feature – consider it a nod to hackers who may be able to make use of it. A micro SD slot and an audio jack port are also present and can be found on the leading edges of the chassis. The current prototype has been fitted with a 6000mAh battery but this may change in the future. Indeed, I should make it clear that we’re still at a prototyping phase and all spec’s I’ve listed above may change before the PineTab2 finds its way into the Pine Store.\nOne of the things that the original PineTab had people excited about was its keyboard, which doubled up as a protective carry cover. We know that a detachable keyboard is a feature most of you want, so it is making a return with the introduction of the V2. And yes, we’re making sure that it will double-up as a protective case too. Unlike the original, all SKU variants of the PineTab2 will include the keyboard by default. Including the keyboard by default opens up the possibility of running convergent and dedicated desktop OSes – and I know a subset of the community always prefers to use a traditional desktop UI over a mobile counterpart. It is a bit early to discuss the specifics of the keyboard at this time – as we’re still exploring what is possible and feasible – but we’ll do our best to meet, and hopefully exceed, the original PineTab keyboard’s design. What it will have, however, is the same chipset as the Pinebook Pro, which means that it will be flashable with open firmware. It also features a backlight and the vendor has worked with us to reduce the reference keyboard’s weight and make it slimmer; this was achieved by using fiberglass panels.\nOn launch day there will be two PineTab2 variants available – with 8GB RAM / 128GB flash and 4GB RAM / 64GB flash storage. We’re currently hoping to bring the PineTab2 to the market sometime after the Chinese New Year, but it is too early to offer a firm date yet. A price point for either of the variants hasn’t been settled on yet either but I can promise that it will be affordable regardless of which version you’ll settle on. Developer units have just come in the other day and will be distributing them in December and January. I hope that you’re as excited about the PineTab2 as I am and you too are looking forward to seeing the PineTab vision realized in its full potential. Those of you who will be attending FOSDEM early next year - make sure to come and see us to check out the prototypes. PinePhone (Pro) [By Thanos] In the past month, SailfishOS on the Pinephone and Pinephone Pro have improved significantly, and the operating system is actually getting very close to being in a daily-driver ready state on the original Pinephone. Affecting both devices are some backend improvements made in the driver for the Pinephone modem, which should significantly reduce issues with the modem not working properly after the device wakes up from deep sleep. This improvement has been merged into the Megi kernel, so it will apply to all distros for the Pinephone that use it. Both the Pinephone and Pinephone Pro ports of SailfishOS have been updated to the latest 6.0 version of Megi’s kernel. Sailfish has the device able to wake from deep sleep on an incoming call, however the driver still has an issue preventing the call from being received. This is being worked on, and is the last major barrier from SailfishOS working extremely well on the original pinephone.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Keyboard working with SailfishOS - video via Adam Pigg on Twitter\nAs for the Pinephone Pro, all sensors are now working properly under Sailfish. An audio configuration is in progress, but not ready yet. The SailfishOS team does believe that the pinephone pro has potential to work extremely well with SailfishOS, but the port is not quite ready yet. Overall, the SailfishOS team has made some incredible progress, meaning we have another solid option for a potential daily driver OS for people wishing to make the switch to mobile linux. The SailfishOS project is looking for contributors right now, so check them out at https://github.com/sailfish-on-dontbeevil/, or in the SailfishOS porting groups on matrix and telegram.\n[edit] Since the publication there have been further developments on the SailfishOS port. SailfishOS and ofono now work much better form suspend, and could be used as a reliable phone. Both call and sms are handled from deep sleep with work done over the last week. Check out Adam\u0026rsquo;s post on Twitter.\nMegi has a new version of his Pinephone and Pinephone pro kernel coming soon, and there are some major improvements coming. The camera support patch for the original Pinephone was completely rewritten for the latest version of the CSI driver from mainline. A bug where sometimes the power button would appear to still be held down when waking up from deep sleep has been patched. The DRM driver was improved on the original Pinephone. The Pinephone Pro’s display driver has also been patched to support a full 60hz refresh rate instead of the 53 it was getting before.\nThere is some important information regarding the Pinephone keyboard accessory. For good news, the power management driver for the keyboard has been merged into the kernel and should work a lot better now. The improvements made should result in much better battery life as a result of it using an algorithm optimized for maximum efficiency using strategies that minimize charging of the pinephone’s internal battery. For the bad news, a firmware bug has been discovered on the Pinephone keyboard that causes it to draw more than twice the expected amount of power while in standby. This means that it can fully undercharge your Pinephone’s battery in about 3 weeks if left unattended. As a result of this issue, it is highly recommended that you store the phone and keyboard detached from each other if you do not plan on using the device for more than a week.\nKali Nethunter Pro on the PinePhone Pro - via Hackerfantastic on Twitter\nLastly Kali Linux released a custom build of their offsec distribution which officially supports the PinePhone and PinePhone Pro. This mobile-friendly version of Kali Linux is called Nethunter Pro - a bare metal installation of Kali Linux with Phosh desktop environment optimized for small-screen devices. As with any other PinePhone OS, you can boot it from a SD card to dual boot Kali alongside the main OS on the phone’s internal flash. This is obviously very useful in this particular case because Kali is a purpose built OS that isn’t meant to be your daily driver. That said, for those who only wish to use their PinePhone (Pro) for this one purpose, Kali Linux announced that they will soon release an alternative version with Plasma Mobile as well as installers allowing installation of Kali NetHunter Pro onto the internal flash memory. It is awesome to see non-mobile-Linux specific projects picking up the PinePhone and PinePhone Pro and using the devices in really exciting ways. You can download Kali NetHunter Pro here. That\u0026rsquo;s all for this month, I’ll catch you all in January.\n","permalink":"/2022/12/15/december-update-merry-christmas-and-happy-new-pinetab/","tags":["community","pinephone","pinephone-pro","pinetab","quartz64","quartzpro64"],"title":"December Update: Merry Christmas and Happy New PineTab"},{"categories":["community","ox64","pinebuds","pinetime","star64"],"contents":"\nWe’ve got three key hardware availability announcements this month: for the PineBuds Pro, the Ox64 and Star64, all of which ought to be available in the coming weeks. However, reading this update I’d like you to keep in mind that Chinese factories and logistics are currently experiencing significant restrictions due to the zero-COVID policy. This means that some of the predicted availability dates may change. That aside, we’ve got a great update for you this month, so tune in and 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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank Alex (clover), Gamiee, Danct12, mothenjoyer69 and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Synopsis in video format\nTL;DR\nHousekeeping Community Q\u0026amp;A November 25th 20:00 UTC; your chance to ask us questions live in the chat We’re reworking the main PINE64 website to better reflect the community aspect of the project; we can’t til you see it PINE64 EU restock of most hardware; Pinecil V2 available on Nov. 14, 19, 24, 29 an in December Newsflash Newsflash - new segment of the update focusing on shorter stories focusing on community projects, software development and smaller announcements Pinecil mod adds LED lights powered from the iron A DIY LiPo battery pack for the Pinecil (V2) An awesome PinePhone (Pro) keyboard case adds RGB backlight to the keyboard Roshambo retro-game console case with matching controllers and carts available in Pine Store soon PineDio LoRa gateway will be available in the Pine Store soon; already has a feature complete OS DSI LCD output works on the Quartz64 An article by dsimic about the Pinebook Pro PineBuds Pro Available this month for $69 [last min edit - available in Pine Store Dec 2nd] PineBuds Pro Wiki is being built up with resources - you are welcome and invited to contribute Will ‘just work’ for people people who want wireless IEMs; world of hacking opportunities for tinkerers - UART exposes both buds 3 Pieces of software: closed firmware, open firmware and open SDK; Ben (Ralim) working on Linux flashing tool - available in ‘few weeks’ Extensive tuning of the hardware for sound quality - favorable performance compared against competing products; Ben impressed by the buds Ox64 A lot of excitement for the Ox64 in the community Already in production and we expect to be delivered soon; in-store availability very soon, perhaps this month Two versions - $6 and $8 Linux booted on the Ox64 by Marek Add-on boards planned allowing connecting camera, LCD, audio out and Ethernet Star64 Available soon, likely in December before next community update Two hardware configurations: 4GB and 8GB of RAM for $69.95 and $89.95 respectively Linux at a good starting point with solid early support of most core features of the SoC Expect support announcements for the Star64 soon after the board launches PineTime InfiniTime 1.11 released; read the dedicated post if you missed it Resource package containing data is needed to enable the 2 new watch faces in InfiniTime Currently supported companion apps that can upload resource packages are Amazfish and ITD Devs already taking advantage of the new InfiniTime feature - pull request for new watch face and a gallery application to display text \u0026amp; QR codes Housekeeping Let me begin by reminding you that we’re holding the community Q\u0026amp;A this month, November 25 at 20:00 UTC. This is your chance to ask us questions live in IRC, Matrix, Telegram and Discord. We’ll be streaming the Q\u0026amp;A session on Youtube, Peertube as well as on the Discord live stage. We usually issue a reminder via social media and in the chats some 15 minutes prior to the event starting. The Q\u0026amp;A takes an hour and we do our best to answer all incoming questions during this time. Following this, however, we usually hang out in the voice chat and keep answering questions over a beverage for another hour - we encourage you to join in. In case you won’t be able to make it, the Q\u0026amp;A sessions are recorded and uploaded in an unedited state to YouTube, Odysee and PeerTube. I hope to see many of you there. You may have noticed that the PINE64 community website hasn’t received an update since early in the year. There is a reason for this, namely we’re working on a complete redesign. And this is a deeper-going redesign than just a page overhaul - we’re working towards separating out, and setting boundaries for, the PINE64 community and the Pine Store’s competences. To this end the .org website will now focus on the community aspects - the individual projects, this blog, the PineTalk podcast, in-person meetups, virtual hang-outs and everything else you can think of that is directly related to the community. In turn, anything and everything related to PINE64 hardware will be moved to the Pine Store’s website, which too will be receiving an overhaul at some point later in the year. We’re still working out the details but the new site is already starting to take shape - we can’t wait to show it with you. Pinecil stock will regularly be added throughout November and December\nPINE64 EU is having a full restock this week, with PinePhone, PinePhone Pro, Pinebook Pro PinePower, PineTime, the Pinecil V2 and various accessories available again. The reason why it took longer to restock than in the previous months is related to changes in the customs process - more specifically, the paperwork related to the Low Voltage Directive and Radio Equipment Directive is now more complex. I’ll compensate for this in the future to avoid periods where multiple items are out of stock. The good news is that the store’s stock, bar the Pinecil, should last until Christmas. As for the Pinecil, the first sub-batch will be available immediately on the day of the restock (it is difficult to provide an exact date as I am writing well in advance, but likely on November 15th) following which additional stock will be added on the following dates: November 19, November 24, November 29, December 4 and December 9 Newsflash Foreword: This is a new section of the community update and one I’m particularly happy about. Newsflash is effectively a quick descriptive summary of things happening in the project - things which would otherwise not get exposure on the monthly blog. These are often developments which are either too small to warrant their individual section, simply do not fit an existing part of the update, or are not a natural fit for housekeeping. Until now, omission of such news was effectively dictated by the scope and time-constraints of the monthly update. Writing the update takes approximately 5 evenings from start to finish, and this is all the time that can realistically be allocated to the writing process. It is simply impossible to report on everything in the PINE64 realm during such a short time span. As a result, many cool projects and information pertinent to the community was lost in the past. The contents of Newsflash will range from cool community projects and interesting software developments to small announcements by the Pine Store or partner projects. On occasion, I may also include commercial products designed for PINE64 hardware if I find them particularly interesting (as I did this month). Anything goes really, and there is no strict structure or order to this section. I should also mention that we’re really happy to accept contributions to this section - all it takes are a few short lines about what you want to report on and links to further reading. Please ping the mods to have the content spotted and delivered to Marek or me\nCommunity member Andrew, going by the handle RuShan on Twitter and @ahall#7894 on Discord, created a light attachment for the Pinecil V2 allowing you to work on projects in dim environments. The ring attachment is fitted at the base of the tip’s shaft where it meets the body of the iron. The ring features two little LEDs which are powered directly from the Pinecil V2 - more specifically from the 4.6V source on the PCB. It looks like a really fun project that could prove quite useful to many in the community - especially those who sometimes use their iron on-the-go. Andrew writes that the light will work with the V1 and V2, albeit the implementation differs on both models. If you want to make this modification yourself then head over to Andrew’s GitHub and download the KiCad file. Be warned, however, this voids your warranty. Andrew wrote a very detailed article about the process behind creating this mod, which I am linking here and I encourage you to have a read.\nCould be used as a flashlight in a pinch ;) - images via RuShan\nA Pinecil accessory I came across and think is pretty cool is a dedicated external DIY battery, the components for which are detailed and available in a small online store. What I like about this battery pack, aside from the 4 cell 14.8V LiPo 1300mAh battery with a high discharge-rate, is the custom designed holder for the Pinecil for when you travel. I don’t really have much more to say about this one as it is what it is - a DIY battery - but I find the execution and compact size of this dedicated Pinecil battery rather nifty.\nPretty cool little battery pack via - Not Your Average Shop\nAnother mod that has completely blown my mind is a custom PCB for the PinePhone (Pro)’s keyboard case. This mod comes from Adam Honse, perhaps better known to some of you as CalcProgrammer1. In short, Adam transformed the keyboard case into a per-key RGB backlit keyboard with OpenRGB compatibility. I must admit that every aspect of this modification is downright awesome - indeed, this may very well be one of the coolest PINE64 hardware hacks I’ve seen to date. It is an extensive modification which requires a new PCB and will likely need multiple parts to be replaced; I should mention that this is an in-progress project, at least from the looks of it. I am linking a video in which CalcProgrammer offers detailed information about the modification - including the custom PCB - and discusses some of the design process. I strongly encourage you to watch this one. More information can be found by following this link.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video A comprehensive overview of the mod by its creator - by CalcProgrammer1\nThe Roshambo retro-game console case capable of housing PINE64 SBCs will be making its appearance in the Pine Store in the coming weeks. If you’re into retrogaming, then the Roshambo case features fully functional on/ off and reset switches, a SATA disc connector, and IO pass-through. You can also pick up a pair or matching controllers and a 128GB SSD that imitates a cart. I can attest that these SSD carts and the controllers are really cool\nThe PineDio product-range has been long in development and pushed back on more than two occasions for a variety of internal and external reasons. I am therefore glad to announce that the first and arguably most important part of the PineDio ecosystem will be available in the Pine Store this week. The PineDio gateway will be available later this month and is now fully supported by a custom Armbian-based OS. The PineDio Gateway is based on the Pine A64 LTS V2 and a RAK5146 from RAK Wireless and the documentation for the gateway on the Pinedio documentation is already very extensive. You can also expect other PineDio hardware, such as the USB adapter with CH341 chip, to follow soon. To learn more about PineDio hardware I suggest you read the dedicated post I wrote about it last year.\nI don’t have a dedicated section on the Quartz64 this month (and for good reason, as there are some things in the works which I’m sure you’ll be excited about in December), but one development I felt needed highlighting this month is that DSI video output now works on the Quartz64 model-A. This news comes via DieselNutJob on Discord, who’s picture of the default 7” PINE64 LCD panel running on the Quartz64 I am linking below. LCD connected to the Quartz64 model-A - image via DieselNutJob in the chats\nLastly, Dragan (dsimic) whom many of you know from his work on both the PinePhone and Pinebook Pro - as well as peripherals for both of these devices - has written an article about the new production run of the Pinebook Pro for a long-standing computer magazine in Serbia. I’m attaching an automatically translated version of the article for you to read. PineBuds Pro The PineBuds Pro were first revealed in an April fools joke earlier this year - they are a pair of wireless in-ear headphones with ambient sound passthrough (sometimes also called transparency mode), environment noise cancellation and a long battery life. Each bud has a two-tone black finish, 3 microphones on each bud, a set of replaceable silicone tips and features touch controls. They also sport a small PINE64 pinecone logo on the touch-control surface, which we hope strikes a balance between being discrete and giving the buds a sense of belonging in the PINE64 product-line. The charging cradle features a two-tone finish similar to the one of the buds, a sliding cover, a LED battery status indicator as well as a USB-C port. The outer portion of the chassis is glossy while the inner part is more matte. The top of the sliding cover features PINE64 branding, while detailed product information can be found on the bottom of the cradle’s lid. I think that the pictures linked below speak for themselves. Thanks to Ralim for the pictures :)\nThe PineBuds Pro have been designed to ‘just-work’ for those who simply want a pair of wireless IEMs while, simultaneously, offering hackers and tinkerers everything they need from the get-go. The cradle has a built-in throughpass for UART used for firmware flashing. Each of the buds is exposed individually so two UARTs are present when the cradle housing both buds is connected to a computer. There will be three different SDKs available for you to play with - one of which should already be available for download. The SDKs have already been tested and I’ve been told they work - more on this later. In time, we should see community firmware that allows for altering the touch controls, buds core behaviour and possibly also allowing for inclusion of new features. Most importantly, however, custom firmware will allow you to flash custom sound signatures adjusted for your individual ear canal resonance frequencies. The BES2300 - the chips at the heart of the PineBuds Pro - was seriously considered for hearing-aids, so there is a potential that the PineBuds Pro could serve as over-the-counter (OTC) hearing-aids for people with very limited hearing impairment. I should also mention that the PineBuds Pro Wiki is already up, with datasheets and schematics. In the coming weeks the Wiki will be edited to include other pertinent documentation and resources; you are welcome to contribute content to the Wiki - indeed, you are asked to do so if you’re an early adopter of the hardware.\nContribute to the Wiki if you\u0026rsquo;re thinking of tinkering with the PineBuds Pro I managed to get hold of Ben (Ralim), known for his work on IronOS powering the Pinecil, who just received his early production PineBuds Pro units earlier this week. Ben has been a part of the project since its inception, so I reached out to learn more about the software status. There are currently three pieces of software for the PineBuds Pro: closed firmware that ships with the buds by default, open source firmware (that has some bugs at present) and an open source minimal SDK. I should make it clear that ‘open’ in this context doesn’t mean that the firmware is completely blob-free, as there are closed-source components for parts of the hardware and radio. Ben says that some of these components will be rewritten or simply removed. Ben is also actively working on a Linux programming tool, which he’ll likely also port to Windows and MacOS in the future - he found the default programming tool somewhat clunky. He hopes to have a tool ready in ‘a week or two’.\nAside from the software status information, Ben also offered up some early impressions of how the hardware actually sounds. I’ll quote much of what he wrote verbatim - “In terms of performance of the headphones, I\u0026rsquo;ve only used the shipping firmware so far, (\u0026hellip;) but performance is very good to my ears [although] I\u0026rsquo;m not a professional audio user” He adds that the “ (\u0026hellip;) the audio response feels fairly ‘normal’ without excessive EQ being used on the base.” I also had an opportunity to ask Ben about the function of the ANC and passthrough mode on the PineBuds Pro running the default firmware - “The ‘normal’ ANC is great for general use reducing most ambient noise below what I notice but not being as aggressive as some headphones where it can cause headaches. The higher powered ANC definitely blocks more noise but I find it can cause slight headaches/discomfort similar to some other ANC headphones.” This is obviously something subjective - I too am very sensitive to ANC and quickly get a sense of pressure in my ears with ANC IEMs, but I suspect that many may find the stronger ANC setting perfectly fine in noisy surroundings. Ben also writes that “the passthrough mode works noticeably better than other headphones [he has], with sound passing through without sounding like it\u0026rsquo;s a phone call”.\nI should mention that the PineBuds Pro had extensive sound tuning - the hardware was tested and molded to provide the best-possible sound. We reached out to professionals in the field to tune the plastics and the speaker to offer what we believe to be the best sound signature. I am not exactly well versed in the process nor do I have any real insight into what good frequency responses are for this type of IEMs, but for those of you who are in-the-know I am including a graph below which you are welcome to study. If you’re an audiophile, please share in the comments what this graph means to you. PineBuds Pro frequency response curve\nPineBuds Pro will be available later this month [edit confirmed date December 2nd] - likely the week following this blog post going live - and will cost $69. For the past 2 months the PineBuds Pro have been undergoing testing and were submitted for both FCC, CE, and CE RED evaluation and have now received the above-mentioned certificates (these certificates should also find their way up on the Wiki in the coming weeks). The default sound signature has been tuned for those users who are not interested in tinkering with their units or in custom firmware, and from what I hear their default sound signature is really pleasant - Marek got to experience the default tuning during Akademy last month and said he was pleased with how they turned out. I believe that the PineBuds Pro has a good chance of becoming a device similar to the Pinecil and PineTime in terms of their scope within the community - they will work well out of the box and offer an easily-accessible playground for those who wish to dig deeper. Ox64 We were really pleased to see the positive reaction to last month’s announcement of the Ox64. Those of you who missed it, I suggest you read last month’s community update for details about the hardware. In a nutshell, the Ox64 is a tiny RISC-V single board computer with 64MB of RAM capable of running either Linux or RTOS - it can effectively be used as either a microcontroller or a tiny PC. At the core of the board you’ll find a BL808 SoC with 3 cores - a 64bit RISC-V core, a 32bit RISC-V core and a low power RISC-V core. It will be available in two hardware configurations, the first of which has 16Mb flash and no microSD socket and the latter 128Mb and takes microSD cards, which can be either used for storage or to boot a Linux OS. On the heels of last month’s announcement I get to bring more good Ox64 news. I’m sure you’ll be thrilled to know the board should be available in the Pine Store in the near future - we currently expect the date to be November 25. The production is already underway and we ought to receive first units from the production-line any day now. That said, the current COVID19 situation in China makes it difficult to predict with certainty when delivery will take place - everything related to production and logistics is currently unpredictable. Please keep an eye on our social media and the chats for more information coming soon; an announcement concerning availability will be issued on Twitter, Mastodon and in the chats. On launch, two versions of the board will be available and will sell for $6 and $8. The first SKU is geared towards RTOS while the latter towards Linux development.\nLinux on Ox64 - via Marek Kraus on Twitter\nSpeaking of Linux development, the second portion of the good news I have for you is that Linux on the Ox64 has already been successfully booted. Our very own Marek Kraus managed to get the board to boot a buildroot installation. The flashing process and connecting UART is currently a bit unintuitive, but this is also something that will be greatly improved in coming weeks. Marek has already made an open source flasher which will hopefully support the Ox64 soon, and this is bound to help the process of getting the board up-and-running as easily as we’re all accustomed to. Marek adds that following some additional work it should be possible to boot Linux from a microSD card, making the process even simpler than booting from Ox64’s internal storage. Obviously we expect to see much development on this platform as developers and early adopters get their hands on units later this month or in early December. UART connected to Ox64 (a bit messy setup currently) - via Marek Kraus on Twitter\nI should also note that there are 3 add-on boards in the works for the Ox64. The first will be a camera module using either USB UVP or MiPi CSI. This will be a great addition which may allow you to transform the Ox64 into a security or nanny cam - I’m sure you can think of other uses too. The second add-on board will allow you to connect an LCD panel with a touchscreen as well as an i2s audio DAC with headphone amp and a headphone jack. A tiny retro-handheld (surely it’ll emulate NES), a small DAP, a DIY alarm-clock? - I think there’s plenty of cool things that can be achieved with such an add-on board. The last add-on currently planned will break-out the Ox64’s Ethernet - which is something I imagine many who’ll want to hack on the thing will be excited for. Stay tuned for more Ox64 news in the coming months as the add-ons take shape. Star64 We initially hoped to have Star64 available today but some last minute production issues have pushed the release date back to next month. While this is a bit of a disappointment - as it would make for an awesome surprise to have the hardware drop alongside the update - but it is ultimately good news that the issues were identified and addressed prior to any hardware shipping. We currently expect to have the Star64 available at some point in December, potentially prior to the December community update, but please note that this date may be pushed back further due to the COVID situation in China. As I’ve written in the previous section on the Ox64, things are a bit up in the air currently when it comes to hardware production and deliveries. Just as a recap, the Star64 is a RISC-V single board computer StarFive JH7110 64bit RISC-V CPU sporting quad SiFive FU740 cores clocked at 1.5GHz. The SOC is equipped with BXE-4-32 from Imagination Technologies. The IO is similar to the Quartz64 and the board’s footprint follows our model-A form-factor, with some notable differences however: the Star64 is fitted with a USB 3.0, 2X USB 2.0 ports, a PCIe slot as well as two native Gigabit Ethernet NICs. If you are interested in learning the details of the hardware spec then I invite you to read the August update in which Star64 was announced. Even more information about the board can be found on the STAR64 documentation page, to which I strongly encourage you to contribute. Front and back of the Star64 - note the double Ethernet ports next to the digital audio out\nOn launch, the Star64 will be available in two hardware configurations - with 4GB and 8GB of RAM for $69.95 and $89.95 respectively. There will be competent software on launch as a good starting-point for developers and early adopters. I wrote about how much progress has been achieved in September and October, with AOSC having been successfully booted on the board with all key features already working, and we’ve seen further developments on the software front since. I am not really in the position to make announcements for other projects but you can expect to hear declarations of software support for the Star64 coming soon. I am really excited to see Star64 launching soon and I am glad that it is highly anticipated by the community. I dare say, bar the Ox64, the Star64 is the board our base is most excited about since the launch of the RockPro64. PineTime [by JF] Last month, just a day following the October community update, InfiniTime 1.11 was released. In case you missed it, I wrote a dedicated blog post about this new version of the firmware. Feel free to have a read if you want to learn more about the new watch faces and functionalities featured in InfiniTime 1.11.\nTwo new InfiniTime watch faces\nWe received a lot of feedback since the release and been asked many questions, most of them about the new resource package. I would like to take this opportunity to answer some of them in this post.\nAs a reminder, the resource package containing data (fonts and pictures) is needed to enable the 2 new watch faces (Infineat and G7710) in InfiniTime. These watch faces make use of the external flash memory of the PineTime to store this data that would be too big for the main memory of the watch. As this data is not built into the firmware, it needs to be flashed into the watch separately. Flashing this package requires a companion app which supports this new feature. At this time, Amazfish and ITD already support this functionality, and other companion apps will hopefully follow soon. Let’s take the time to thank companion apps maintainers and contributors for their great job! So, does it mean that you cannot upgrade to InfiniTime 1.11 if you don’t use the particular companion apps? Of course not! You can still use your PineTime running InfiniTime 1.11 with any other companion app. The only thing you won’t be able to do is to upload a new resource package and enable the new watch faces. You can always temporarily switch to Amazfish or ITD to upload the packages and then continue using your favorite companion app as per usual.\nMany users also asked if the resource feature would allow them to install new applications in the PineTime without the need to flash a whole new firmware. Unfortunately, not (yet). Currently, the resource feature only supports “static assets” like fonts and pictures. Executing code coming from the resource package is obviously not impossible, but it’ll require you to take a few additional steps.\nSince this new release went live I’ve already spotted at least two pull-requests that built something new on top of the resource feature: a new watch face - Horizon, and a new gallery application that displays pictures, QR codes and text files. I’m really happy to see contributors leveraging this new feature in their contributions!\nNew Horizon watch face pull request (left) and gallery application (right) This month I would also like to highlight this tweet from @octoshrimpy, showcasing a re-design of the UI from InfiniTime based on the Catppuccin theme. And, to be honest, I think it looks very good!\nRedesign of IntiniTime elements - via Octo Jones on Twitter\nThat’s all for this month, tune in December for more PINE64 news.\n","permalink":"/2022/11/15/november-update-tuned-in/","tags":["community","ox64","pinebuds","pinetime","star64"],"title":"November Update: Tune(d) in"},{"categories":["pinetime"],"contents":"We released InfiniTime 1.11 a few days ago. The timing of the release did not align with the monthly community update, so we decided to write a small blog post to highlight a few new features and provide new about the PineTime community!\nInfiniTime 1.11 is the result of three and a half months of work from many contributors. 59 pull request have been merged with changes ranging from new watch faces to small bug fixes passing by improvements in multiples area of the project.\nI’ll highlight a few of these new changes in this post, and feel free to read the whole release note for more information!\nInfiniTime 1.11 brings 2 new watch faces!\nExternal resources As you may know, InfiniTime is currently quite constrained by the memory space available in the PineTime. Both RAM and flash memories are quite well packed, and we have to ensure that the changes we include in the project will actually fit in the remaining memory available.\nBut we are not doomed to save any byte in memory forever, and we have multiple options to give InfiniTime a bit of fresh air!\nIf you read the Pine64 monthly community updates, you may have noticed that I wrote about the usage of the external flash memory of the PineTime for some time now. Remember the blog post from December 2021 where I teased a few watch faces with custom backgrounds ? Nearly a year, that’s the time it took to put all things together to make this happen : InfiniTime can now use the external flash memory to store fonts and pictures and make them available to applications and watch faces!\nTesting custom backgrounds back in December 2021\nThis feature will bring a lot of possibilities in the future : the external memory is a 4MB flash memory. It’s really huge compared the the 512KB available in the main memory of the PineTime. In the future, we’ll be able to move more and more data from the internal to the external memory, which will free very precious space to add more and more features to InfiniTime!\nWhat did it take to build this feature? Things started with the integration of LittleFS, a file system designed for embedded systems, in InfiniTime 1.3.0. At first, this file system would only be used to store user settings and BLE bonding information, but we knew it would be the basis for other functionalities in the future.\nThen, the BLE FS API was added in InfiniTime 1.8. It provided companion apps with an access to the internal file system of the PineTime. It was not that useful at that time, but once again, we knew we would need it in the future.\nNow that we know how to store and access files from the external memory, we can focus on the next step : extending InfiniTime so that applications and watch faces can actually access to the images and fonts stored in the file system! This step took a lot of time with many trials and errors until we finally reached a point where we were satisfied by the performances of the system. Indeed, the external memory is far slower, and we wanted to provide the best user experience no matter what. Most of the work done in this step is documented in this page.\nAnd we are not done yet : we need to provide the users with an easy way to install the resources. And for this, we need the support of companion apps. ITD and InfiniSim added support for the external resources very soon in the development process. I also implemented the upload procedure in Amazfish which allowed me to test that the procedure actually worked!\nNow, everything is in place to release this new feature to the wild!\nNew watch faces Contributors to the InfiniTime project work on many great features, apps and watch faces, and keeping up with this constant stream of pull-requests is probably the most difficult part of our job as project maintainers. I’ve been eyeing the watch faces Infineat and G7710 for quite some time now, but couldn’t merge them because of their memory usage.\nIt turns out they were great candidates to be the first watch faces to leverage the resources feature in InfiniTime!\nInfineat is a very stylish, colorful and customizable watch face that displays the battery level using an animated Pine64 logo. The big font makes it very easy to read.\nThe Infineat watch face\nThe G7710 watch face is designed to mimic the interface of LCD watches. It displays the week number, day of the year, days until the end of the year, date, time, step count, battery level and heart rate.\nThe G7710 watch face\nTo enable those watch faces, you’ll need to install the resources package provided in the release note of InfiniTime 1.11. Please check the release note and the documentation for more information about this. Note that for now, only ITD and Amazfish support this feature, but I hope other companion app will integrate the upload procedure for external resource very soon!\nOther additions and improvements External resources and the new watch faces are obviously not the only changes we make to the project! On the UI side, we made many improvements in the UI to improve the consistency of the interface and make it more readable. We also created a new ‘counter’ widget to make settings like the date, time and alarm easier.\nThe new Counter widget in the time setting screen\nA new Sleep mode is available via the Quick Settings menu. This mode disables notifications, chimes and all automatic wake up options (touch and motion) and will prevent the watch from waking itself (and the user) up during the night.\nThe new sleep mode in the quick settings menu\nI would also like to mention that the Core Developers team worked on a new document that describe the vision of the project.\nYou’ll find the complete list of additions, improvements and bug fixes in the release note.\nInfiniSim InfiniSim, the InfiniTime simulator, evolves alongside InfiniTime. Its main developer NeroBurner takes a great care to make necessary changes in the simulator to adapt to changes in InfiniTime.\nInfineat running in InfiniSim. Did you know that InfiniSim provides an easy way to take screen shots?\nInfiniSim was also extended to support all the features related to the external SPI flash memory, the file system and the external resources. A new tool \u0026ldquo;littlefs-do\u0026rdquo; allows to easily manage the simulated SPI flash memory : list files, read and write files and even load the external resources package in a single command! Please check the documentation to see what littlefs-do is capable of!\nWrap up That’s it! Enjoy InfiniTime 1.11 on your PineTime! Feel free to join us in the community chat rooms if you have questions, need help or just want to talk about your favorite smart watch ever!\n","permalink":"/2022/10/18/infinitime-1-11/","tags":["pinetime"],"title":"InfiniTime 1.11"},{"categories":["community","news","ox64","pinephone","pinephone-pro","quartzpro64","star64"],"contents":"\nI hope that the good news and all the announcements of this month will make up for the much delayed publication date - which is something I sincerely apologize for. This month we’re announcing the Ox64 - a sub $10 Linux capable single board computer, we are bringing you news that both the Star64 and QuartzPro64 now boot Linux (and run it well too already!) and share all the latest PinePhone Pro development. Let\u0026rsquo;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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank Alex (clover), Gamiee, Danct12, mothenjoyer69 and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Community update video synopsis\nTL;DR\nHousekeeping Apologies for the delayed release of the update; moving forward we’re reverting to 15th of the month for updates PINE64 at KDE Akademy earlier this month - talks about Plasma Mobile and the PinePhone (Pro) We’ve applied for a stall at FOSDEM 2023; we hope to be accepted and to see you there in February 2023 Community Q\u0026amp;A next month at 8PM UTC, November 25th Star64 Star64 now boots Linux thanks to work by Icenowy Most of Star64’s IO and core functionality already works including the GPU Things to be ironed out include USB 3.0 and onboard WiFi not working, and issues with Gigabit Ethernet dropping packages More developers getting their hands on with the Star64 now Expect to see wide OS support for Star64 once the Linux base is fledged out fully Star64 will be available in November Ox64 The Ox64 is a RISC-V Linux-capable SBC for $8 Features BL808 from Bouffalo labs RISC-V SoC with 64MB RAM 3 cores: 64-bit RISC-V core, 32-bit RISC-V core and low power RISC-V core Two variants of Ox64 on day one: for RTOS and Linux development - $6 and $8 respectively Expected availability in November PinePhone (Pro) Reduced order-to-shipping times for both the PinePhone and PinePhone Pro worldwide; weekly dispatch Starting with kernel 5.19 PinePhone Pro’s cameras will work with Megapixels Improvements to standby and suspend; bringing the PinePhone Pro closer to user-parity with original PinePhone Kernel 6.x brings number of improvements; if you’re using a distro on megi’s kernel an update is advisable PinePhone Pro keyboard driver finds its way into kernel 6.1 Anbox support is getting dropped; it is suggested to migrate to Waydroid if you use Android application on the PinePhone (Pro) QuartzPro64 QuartzPro64 boots BSP Linux thanks to work by mothenjoyer69 Much of the core functionality is already available and we’re told that the board runs Debian with accelerated GNOME well QuartzPro64 was able to set the (current) world record result for an RK3588 in Geekbench 5 Outstanding issues to be ironed out include: SD card and PCIe functionality as well as WiFi, NPU, HDMI RX); getting SD booting working is priority Debian testing images will be available once SD booting works Mainline kernel boots; BSP and mainline development ongoing in parallel The board holds much potential also for prospectus future hardware Housekeeping Let me start by apologizing for missing the September update. This is, to my memory, the first time we’ve missed an update in the past 4 years. The fault is mine; life got in the way. I had a personal situation that I needed to attend to, and with Marek and TL away at KDE Akademy there wasn’t anyone to complete the writing in time. I then faced a backlog of work at the EU store, which effectively meant that we chose to skip writing the September update altogether. Again, I apologise for this situation. This also means that we’re reverting back to the 15th of the month for community updates. While publishing the community update at the end of the month is probably better for the community, the middle of the month works better for my schedule. Moving forward, please expect the updates to be shorter than in the past—unless more members of the community decide to contribute. I therefore urge you, more than ever before, to partake in writing the update. Anyone is welcome to contribute content, be it news concerning documentation, development, new findings, the community, or anything else related to PINE64. It doesn’t matter if you are a notable and long-time community member or a newcomer—we welcome contributions from anyone. All you need to do is ping a mod or admin in one of the chats to discuss your contribution.\nNow let\u0026rsquo;s get into housekeeping; as I already mentioned, TL and Marek attended KDE Akademy earlier this month. This marks the 5th time that PINE64 co-sponsored the Akademy event and someone from our project attended the conference. I unfortunately didn’t get a chance to attend this year, but from what I hear the conference was a success. It was also an opportunity to meet friends, contributors and partners from various projects. I should also mention that there were multiple references and conversations related to PINE64 hardware, and the PinePhone (Pro) in more particular, including a talk by Devin Lin and Bhushan Shah on Plasma Mobile. Indeed, there were multiple talks which included the subject of Plasma Mobile, one of which you can watch here. Needless to say, we’re looking forward to attending Akademy next year. PinePhone (Pro) at KDE Akedemy - picture via twitter\nOn the subject of conferences and meetups—we’ve applied for a stall at FOSDEM 2023, which will be the first in-person FOSDEM meetup since 2021. FOSDEM has historically been a very important event for us and one which we’ve attended since 2017. This is the event where the PinePhone and other hallmark PINE64 devices were dreamt up and eventually announced. Granted we will be offered a stall at FOSDEM 2023, we’ll make sure to bring all the newest and greatest PINE64 hardware for you to check out. We’ll also bring with us unannounced hardware prototypes and concept devices to check out and offer feedback on. Needless to say, you should also expect some exciting announcements from us during FOSDEM; we intend on keeping with the tradition of announcing hardware at the conference. FOSDEM is also an opportunity for us to meet with the community, so if you’re in Europe and can fly to Brussels to attend the conference on February 4 and 5th, then make sure to come by and say hi. On the off chance that we won’t get a stall, we’ll arrange to host our own meetup somewhere in Brussels during the conference—we’ll make sure to let you know closer to the date.\nDo you recognize this prototype from FOSDEM 2018? ;)\nLastly, the final quarterly community Q\u0026amp;A of 2023 will be held on November 25th at 8:00PM UTC. In case you missed prior Q\u0026amp;A’s, this is an opportunity for you to ask Marek and I live questions. We sometimes also have community members and developers join in to answer particular questions. The questions are picked directly from the chat and we strive to answer all of them within the time-frame of one hour. You can ask us questions on IRC, Matrix, Telegram and Discord—a full list of Q\u0026amp;A channels can be found here. Just as last time, we’ll be streaming the Q\u0026amp;A session on Youtube, Peertube as well as on the Discord live stage. Following the Q\u0026amp;A we usually take an hour and hang out in the voice chat and continue answering questions and keep the discussion going. So make sure to mark this date in your diary and join us. In case you won’t be able to make it, the Q\u0026amp;A sessions are recorded and uploaded in an unedited state to YouTube, Odysee and PeerTube. Hope to see you all there.\nStar64 In August I dedicated a significant portion of the update to the Star64—more specifically to the hardware configuration that will be entering production. Aside from the obvious reasons for describing the hardware and introducing it, the core reason for focusing solely on the hardware stemmed from the fact Linux did not run on it yet. At the time I wrote that ‘efforts to support the SoC in Linux have already begun’ and expressed hope to see the development progress quickly due to the high interest in the platform in general and the Star64 in particular. While my belief that we’d soon see support for the board was sincere, admittedly I didn’t expect this much progress to be achieved so quickly—in less than 30 days. Therefore, now I will focus on the board’s software support status. So, if you somehow missed last month’s update and want to learn about Star64’s hardware then I invite you to read the August update before reading this month’s section.\nI should start by crediting Icenowy Zheng for getting Star64 up and running. Some of you will likely know Icenowy from her participation in the Sunxi Community and work on numerous single board computers. Notably she also worked on the original Pine A64 (+) and many of our A64 devices, such as the Pinebook and PinePhone. Earlier this month a photograph taken by Icenowy was sent to me showing the Star64 sporting a handful of peripherals running AOSC Linux. AOSC is a general-purpose Debian fork, which supports single board computers and embedded devices as well as the x86 platform. As you may have already guessed, Icenowy has been one of the developers behind AOSC. The photo shows a 4GB RAM Star64 board running a full XFCE desktop environment atop kernel 5.15. For those who are wondering, I have confirmed that the GPU works; the PowerVR GPU on this RISC-V SoC is fairly capable and I’m sure will do well accelerating desktops with compositors that can take advantage of OpenGL. Since someone will ask: I haven’t been able to confirm whether VPU works at this time, but the VPU blob should be a part of (and work with) the FOSS driver.\nLinux now boots on the Star64\nAs far as the IO is concerned, it is my understanding that USB 2.0, PCIe, GPIO, SD card, eMMC and Gigabit Ethernet all already work. Things that do not work or work partly include: the USB 3.0 (development of which is being prioritized) which doesn’t work at all, the onboard WiFi, which appears to not work because of driver issues, and while the Gigabit Ethernet works it currently drops packages. I don’t know the status of MiPi and CSI ports – it may be the case that these simply haven’t been tested yet. I should also note that I am writing this section 10 days before the update goes live, so any or all of the points may have already changed. Ultimately, the goal of listing the board\u0026rsquo;s enabled functionality is privately to illustrate how much development was achieved in just a few short weeks, and only by one (very dedicated and skilled) developer. This Linux build is very important however, since it will be used to test Star64 prototypes, which will be shipped to developers shortly.\nStar64 in action with various IO being used - picture by Icenowy\nThis is only the beginning. With a handful of key developers now receiving the Star64 boards we expect to see the outstanding functionality implemented and issues ironed out; once all functionality is enabled we’ll invite partner project developers and individual contributors to port their OSes to Star64. The idea is to have very good support for the platform upon launch and so that end-users have a choice of more server and desktop oriented OS options. With people such as Kamil Trzcinski (Ayufan) and Samuel Holland (smaeul) receiving hardware soon, I expect to see more exciting Star64 developments in the coming weeks, so stay tuned for more news. Finally, the Star64 will be available for purchase to anyone who wants a unit in November. Pricing is yet to be determined. 0x64 [edit] It looks like most of the information regarding the Ox64 has already found its way online. The good news is that the coverage has been very favorable. To this end, this announcement is therefore a confirmation of what has already been written and ‘leaked’ online, with some additional details including pricing and expected availability. At the start of the year I hinted at a few things coming in 2022—one of which was that we’ll be taking a plunge into the RISC-V this year. The Star64, and any PINE64 devices that may be built upon the StarFive JH7110 SoC in the future, represent just one strand of our exploration of RISC-V architecture. For some time now, ever since the Pinecil first released, we felt that having an entry-level RISC-V single board computer, which would lower the entry-point to the architecture, would be beneficial to the community. To this end and with no further ado, say hello to Star64’s little brother (well, sort of—in architecture only), the Ox64. The Ox64 is a small form-factor single board computer powered by the BL808 RISC-V SoC—a new chipset by Bouffalo Labs. Some of you already know of this vendor, since one of their microcontrollers is used in the Pinecil V2 and PineCone. Surely you also immediately noticed that the board is named Ox64 (side note: Ox … Bouffalo … you get it right?) as opposed to PineOx which is used in the PineCone and based on the older BL602 microcontroller. This is because BL808 is not a usual microcontroller. It features three cores - a high performance 64-bit RISC-V core, a high performance 32-bit RISC-V core and low power RISC-V core. These cores are paired with 64 MiB of PSRAM, a SD card interface and MMU (Memory Management Unit), and make the SoC capable of running Linux as well as bare-metal firmware. We hence treat Ox64 as a Single Board Computer rather than a microcontroller, despite that it can be used as either.\nHere it is in all its tiny beauty\nHere are some of Ox64’s key hardware details. The BL808 contains a wide variety of really neat onboard features, such as WiFi 4 and Bluetooth 5.0, Zigbee connectivity and MIPI-CSI/DSI interfaces. It also sports a H.264 encoder, MJPEG encoder, JPEG decoder, an audio subsystem, Ethernet, USB 2.0 OTG and Neural Network unit. The Ox64 PCB with two USB ports, at the far ends of the PCB. The USB-C port features OTG and MIPI CSI for the camera module as well as an audio out/in interface. The secondary USB port is for power only. The WiFi chip antenna is soldered onboard and features a u.FL connector. The castellated header pin holes break out GPIO, SPI, I2C, I2S and UART. In the future, we plan to have adapter boards for Ethernet (using GMII interface), audio (I2C interface) and a camera module (USB).\nThe first sample units for developers and QA\nBefore we wrap this announcement up with information about pricing and availability I want to briefly touch upon software, which is pertinent to the pricing structure of the two SKUs that will be on offer later this year. As things stand, we’re awaiting this RTOS SDK, which should be available sometime next week and will be uploaded to the Ox64’s docs (which should already be up by the time you’re reading it). Getting Linux to run on the Ox64 will be a community endeavour, but with good documentation and additional external resources we expect to see initial support for the board surface soon. I should also mention that development boards have already shipped to a select group of developers, some of whom are interested in Linux and others in RTOS. I’ll be bringing you news on the progress in the months to come. Ox64 pin assignment\nFinally, the Ox64 board will be available in two configurations, one with 16Mb flash and no microSD socket, and another variant with 128Mb flash and a microSD socket. The prior configuration that is geared towards RTOS development will sell at $6, while the latter is intended for Linux development and will be available for $8. Both configurations are expected to be available at some point next month. You can find more information on the docs. Lastly, I’d like to remind you that the Wiki is editable by community members and we always welcome contributions, thank you.\nPinePhone (Pro) Before I get into the phone-related news of the month, I just want to provide you with a short update regarding shipping and availability of the PinePhone and PinePhone Pro. As some of you may have already noticed, the Pine Store has begun shipping both phones on a weekly basis from Hong Kong. This means that the time it takes for your PinePhone (Pro) to arrive at your doorstep has now been drastically reduced. Both devices are in-stock and, with current production-runs being quite substantial, we expect stock to last for the foreseeable future. Since stock is located in Hong Kong, COVID-19 related restrictions in the region are also less likely to affect shipping. As for the availability of both devices in the EU store; the PinePhone remains in stock while more PinePhone Pros are expected to arrive any day now. Across the board we strive to improve the process of ordering and delivering hardware; the weekly world-wide dispatches are just one of the many steps we’re taking to increase logistics efficiency (some of you may remember that in the past you had to wait months to receive your PinePhone). I expect to have yet more logistics news for you the following month, now let’s move onto software news.\nAnd for software news, I think this is something many of you have been waiting for: as things stand, two issues PinePhone Pro users face are battery drain in idle and a lack of camera support. There are obviously also other problems, the importance of which I do not diminish—for example voice call quality, which is something I addressed in the August update. However, the PinePhone Pro’s short battery life and a lack of photo-taking abilities are two of the things I see mentioned most frequently in online discussion on the device’s daily-drivability. While a long, or at least reasonably long, battery life is fundamentally crucial to a phone’s daily usage, the ability to take photos is merely a feature—but one which we’ve come to expect from modern mobile devices. Regardless, both issues impede a sense of the device’s software completeness, especially when compared against the original PinePhone. This, however, is about to change.\nInitial PinePhone Pro camera support has now been added to multiple OSes - Picture via Manjaro\nStarting with kernel 5.19 PinePhone Pro’s cameras will work with the Megapixels application, shipped with most available OSes. To be clear, I already reported on the PinePhone Pro taking photos and even streaming video a while back, but an implementation necessary to take pictures in Megapixels (or similar userland application) has only become available now. If you’re running Manjaro on your PinePhone Pro then you can already give this new functionality a spin by switching to the unstable software branch. This may be true for other OSes too but I haven’t had the time to check. In terms of the current functionality, the viewfinder works smoothly and switching between the front and back camera is seamless. However, the images that the cameras produce and viewfinder image still have a long way to go; there currently is no color correction nor any post-processing, causing the images to look muddy and green-tinted. As things stand, at the time of writing, the original PinePhone takes better photographs despite the much inferior sensors (a slight digression—it is crazy to think how much of the image quality depends on the software rather than hardware). But this is a first step in a much longer journey to flesh out this functionality.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Initial camera functionality showcased - video by Wolf Fur\nThe other big news concerns improvements to the PinePhone Pro’s battery life when it suspends. This, in and of its own, is obviously very important but it has also further going consequences. Recent patches to uboot based on 2022.10rc4 not only allow the PinePhone Pro to remain in suspend for a longer time but also a faster wake up time and reliable recovery on phone calls. In my (admittedly limited) testing the phone woke up reliably on incoming calls even after a prolonged suspend-time. Over a day of testing, I didn’t experience a single dropped call—even when I left the phone suspended overnight (approx. 10 hours). This is a huge development brought to us thanks to work by dsimic and megi as well as other contributors, and one which I hope will find its way into uboot used by most OSes as well as Tow-Boot. I should also mention that I experienced audio-related problems upon waking up—namely, while the phone rang reliably the phone-call audio was gone. At times, the system audio seems to temporarily also vanish. It is clear that more work will be needed to get these features ship-shape but the ongoing progress shows much promise.\nI also want to make it clear that while these steps towards software parity with the original PinePhone are very important, they are just that – steps towards parity, not parity itself. There is still a journey ahead of us before the PinePhone Pro and PinePhone’s functionality is identical or near-identical. At this point I want to acknowledge and help all those who are making this happen—the developers working on u-boot patches, the kernel as well as userspace applications. I am glad to see their work gradually coming together to make the PinePhone Pro the best possible device to experience mobile Linux.\nPinePhone Pro keyboard drivers are finding their way into kernel 6.1 Phoronix reports\nSince I originally wrote the section in September, four more important PinePhone-related things have transpired, which were pointed out to me by Danct12. For starters, megi has updated his mainline-based kernel to 6.0. This is a major Linux release, which brings about a plethora of overall improvements and fixes, as well as additional functionality (more on this in a bit); so if your distro of choice uses megi’s kernel then I strongly suggest you run an update. It should be mentioned that among the many things that kernel 6.0 brings, the next release (kernel 6.1) will incorporate the PinePhone (Pro)’s keyboard driver - Michael Larabel from Phoronix writes: “Queued via the Linux kernel input subsystem\u0026rsquo;s \u0026ldquo;next\u0026rdquo; branch is this commit introducing the PinePhone keyboard driver. An associated commit also adds the PinePhone keyboard driver for the DeviceTree. This new driver is for supporting the matrix keypad and MCU of the Pine64\u0026rsquo;s PinePhone keyboard case (\u0026hellip;)”. We’ve also seen the community built modem firmware receive a new release. This release brings an update to Yacto 4.0.4, support for GSM-7 / UCS-2 / 8-Bit data coding scheme identification in Cell Broadcast messages and raw relaying as a SMS to the host if the default coding scheme is not used, fixes a problem with emergency broadcast messages in non-latin characters (making it a very important release if you happen to live in countries that don’t use latin characters) and fixes HWIDs compatibility for PinePhone Pro (Tow-boot) and PinePhone (Tow-boot / u-boot).\nLastly, Danct12 told me that “If you\u0026rsquo;re still using Anbox on DanctNIX\u0026rsquo;s Arch Linux ARM fork, keep in mind that Anbox and the relevant packages will be removed at the beginning of 2023. It\u0026rsquo;s recommended to migrate to Waydroid ASAP.” This obviously also applies to all other distributions, most of which, to the best of my knowledge, now offer a simplified way of installing Waydroid in both Phosh and Plasma Mobile user environments. QuartzPro64 The last piece of news I come bearing this month concerns software developments on the QuartzPro64. In case you don’t know, the QuartzPro64 is a development board powered by the powerful RK3588 SOC from Rockchip. We shipped a number of QuartzPro64 boards to developers earlier this year and we’re finally starting to see some really exciting software developments on the platform. Earlier this week I had a chat with mothenjoyer69, a developer who has been working on QuartzPro64. This section will effectively be an overview of what I’ve learned from our conversation and the details mothenjoyer69 provided me with. For starters, perhaps the most important news is that Debian stable now boots on the QuartzPro64 using the BSP kernel. QuartzPro64 running Debian - picture via Mothenjoyer69\nNot only does it boot however, a lot of the core board functionality works too. When asked about it, Mothenjoyer69 wrote “The QP64 was recently shown to boot a BSP kernel, with almost all critical hardware working without issue. GNOME 3.38 boots with full acceleration, and glmark2 ran to completion without issue, and YouTube playback functions fine. With CPU frequency scaling available, the QuartzPro64 was able to set the (current) world record result for an RK3588 in Geekbench 5.” It is notable that OpenGLES already works flawlessly, including in glmark2. While Vulkan support isn’t functional yet, you can already expect some really solid performance in 3D acceleration tests. Speaking of acceleration, I’m told that the GPU was able to match a dedicated Nvidia GT750m in glmark2. I’m not sure how well this will translate to real-world 3D performance, but I certainly hope to make the QuartzPro64 the brains of a dedicated retro-game emulation machine at some point in the future.\nTo be clear, there are still a handful of missing features and outstanding issues which need to be addressed. Mothenjoyer69 explains “SD card and PCIe are currently the primary issues, with SD card fixes being worked on. WiFi and a few other parts (the NPU, HDMI RX) are also currently non-functional. SATA functions [however]. Realistically the fixes don\u0026rsquo;t appear to be that massive so right now SD card is the primary focus.” Once booting from SD will be fixed OS images will be made available for testing purposes on github. The work done by mothenjoyer64 and other contributors will, in time, serve as a basis for distributions to build their OSes atop of. As always, I hope that the early progress made on the board is indicative of the community’s interest in this powerful SoC and that eventually it will find its way into consumer-focused SBCs and future devices.\nMainline Linux booted on the QuartzPro64 - via Furkan Kardame (Manjaro)\nI would be remiss not to mention that mainlining efforts are made in parallel to the work on BSP. Indeed, as Mothenjoyer69 explains, “mainline development has been very active with some large steps being made already. With the efforts of the Pine community, and ARM SBC community at large, the QP64 can successfully boot a mainline kernel, albeit with limited hardware support. With the continuing efforts of the community, and with assistance from Collabora, this will only improve as we move into 2023 and beyond.\u0026quot; While mainline Linux is, as it always is, an end goal in an ARM SoCs development cycle, I for one am very happy that BSP and mainline are being developed simultaneously. Good BSP support and multiple feature-rich BSP OS images will help the platform grow and make the RK3588 viable for more user-oriented devices.\nI am currently awaiting mothenjoyer69’s test images to become available so I can give the board a spin, and I must admit that I am genuinely excited to see what the RK3588 chipset is capable of. In the future I can see the QuartzPro64 platform becoming the basis for an entire line of very cool, versatile and highly diverse devices. I think that the chipset has multiple and widely different applications, the range of which can equal or even surpass the A64 and RK3399. Of course, only time can tell how this chipset will pan out. Until then, I’ll make sure to keep you updated.\nThat\u0026rsquo;s all for this month!\n","permalink":"/2022/10/15/october-update-an-ox-no-bull/","tags":["ox64","pinephone-pro","quartzpro64","star64"],"title":"October update: An Ox, no bull"},{"categories":["community","news","pinebuds","pinecil","pinephone","pinephone-pro","pinepower","pinesound","pinetime","quartz64","risc-v"],"contents":"\nThis month we take a close look at the Star64, check out PineBuds (Pro) progress and discuss the Pinecil V2. I also come bearing good news concerning the PinePhone Pro, which has seen a small but significant hardware redesign and some important software updates. Let’s get into it.\nYou 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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank Alex (clover), Gamiee, JF and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of the August community update\nTL;DR\nHousekeeping We’re sponsoring Akadamy; meet us there! Community Q\u0026amp;A was held August 13, you can now watch it on YouTube A call for sticker design - looking forward to seeing what you come up with Blade hostboard for the SOQuartz is now in the PineStore The PinePower in the Pine Store and EU store is grounded - cause for confusion outdated photographs PinePhone (Pro) Spare parts for the PinePhone Pro are now in stock Small hardware redesign - the PinePhone Pro now takes nano SIM Megi’s patches bring improvements to sound on the PinePhone Pro New releases from postmarketOS, DanctNIX, OpenSUSE and Manjaro; OpenSUSE shows off Qi Wireless charging Work-around instructions for Mobian installer issues Star64 Pictures of the first Star64 prototype Overview of the final Star64 IO layout, components (WiFi 6 \u0026amp; BT 5.2among them) and features Debian and Fedora already being ported to the SoC; we trust many other OSes will follow Pinecil First batch of Pinecil V2 sold out in record time; next batch in EU store early September and Pine Store mid-September Pinecil V1 vs V2 and tip comparison by end-user - very cool video Pinecil V2 online authenticator; a walk-through of how to check whether if your unit is legit Ships with newest IronOS firmware PineTime Watchmate: new companion app for desktop and Linux phones Watchmate works with InfiniTime and incorporates key functionality InfiniLink iOS companion app transferred to PINE64 community Housekeeping We’re once again one of the sponsors of this year’s Akademy, which is taking place in Barcelona 1-7 October. For those of you who don’t know about Akademy - it is an annual non-commercial meetup organized by the KDE Community. From memory, this is the 5th time that we’re a part of and sponsoring the event. Since this year’s meetup is an in-person event we’ll be flying into Barcelona to attend. Keep an eye out for Marek, TL and myself during the weekend of 30 September and October 3rd. We’re taking this as an opportunity to meet and mingle with people, so it is unlikely that we’ll be holding any talks or the like.\nIf you live in Europe, are a fan of KDE and happen to like our products then drop-by Akademy in Barcelona this year\nWe held the quarterly Q\u0026amp;A on August 13. As usual, Marek and I answered questions from the chats and for the first time managed to answer nearly all the questions posed. This time around we also managed to stream the Q\u0026amp;A to both Youtube and Peertube, while simultaneously having people in the Discord stage. Kudos to Marek for getting it all working this time around. The recording of the full and uncut Q\u0026amp;A session is available on Youtube, and thanks to Pak0St there are chapters available so you can easily find the bits and pieces you’re particularly interested in. The next Q\u0026amp;A will be held sometime in November. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Live recording of the third community Q\u0026amp;A held on August 15, 2022\nIn other community news - we’ll be printing PINE64 stickers for upcoming community events (I am keeping my fingers crossed FOSDEM 2023 is an in-person event). While we’ll surely be printing some fairly generic PINE64 branded stickers, we also want to reach out to you for submissions. So if you’re artistic and would like to submit a PINE64-centered sticker design, then we’re more than happy to receive it. Make sure to have the sticker design include your name or handle. As for design requirements, it needs to be a grayscale and read well in a small size. If we receive multiple submissions, then we’ll run some sort of community poll and have you select the ones you feel represent the project best. Please post your submissions on the forum or, if you prefer, in the #offtopic community chat; make sure to ping the mods to make them aware of the submission. The Blade hostboard for the SOQuartz is now available in the Pine Store. In case you missed it, I wrote about the Blade and other SOQuartz hostboards back in May. This hostboard has been designed for clustering and fits inside a standard 1U server rack. You can fit 12 or more Blade hostboards into a single rack. I had the opportunity to check out a Blade prototype in May and was really quite surprised by how slim it was and how much I/O was present in the tiny space that the PCB provides. If you’ve been interested in clusters and were waiting for a spiritual successor to the Clusterboard then here it is.\nBLADE hostboard with 8GB SOQuartz installed\nLastly, I want to make it clear that the PinePower desktop currently sold in the Pine Store and EU store is grounded (and has 3 prong plug) as requested by the community. I wrote about this new hardware revision already in the April community update -I encourage you to read the blog entry in case you missed it. I am aware that the pictures in both stores were outdated for a couple of days when the new batch arrived, which led to some confusion as to whether the hardware is from the new revision. All PinePower desktop units currently on sale and produced in the future will be grounded. Apologies for the confusion caused by outdated pictures.\nPinePhone (Pro) Let’s start with some hardware news. Spare parts for the PinePhone and PinePhone Pro are now in stock. I know that many users with cracked screens or damaged back-cases have been waiting for these parts to return to the store. I am happy to let you know that spare PinePhone (Pro) keyboard PCBs are now also available for purchase. I am mentioning the availability of these parts explicitly at the start of this section because I’ve recently seen people question our commitment to creating repairable hardware. So, let me assure you that we’re as committed to making repairable hardware as we always have been. The reason why spare parts were out of stock for a period of time is simply due to them selling out from the last PinePhone (Pro) production batches - spare parts are usually only delivered with a new production run. The spare parts are basically unassembled PinePhone (Pro) units. Same goes for keyboards and other equipment. If there is a break in hardware deliveries then it is likely that spare parts will temporarily sell out too. However moving forward we’ll hold a larger stock of spare parts. In other hardware news, the most recent production run of the PinePhone Pro has seen a small but important redesign, at least for newcomers. One of the most common failure points on the PinePhone and PinePhone pro is the SIM slot. Users were required to use an adapter for their nano SIMs to fit into the micro SIM slot - some would insert the adapter without a SIM, pull it out, and damage the pins in the process. Others would insert a micro SD card into the SIM slot thereby damaging it. For this reason, the new production run of the PinePhone Pro incorporates a nano SIM slot instead. The slot has a clever design which prevents new users from accidentally inserting a micro SD inside too; to insert the SIM card you need to pull out a little tray (which doesn’t come all the way out), into which the SIM is inserted. We hope that this small improvement will result in fewer broken SIM and SD slots moving forward.\nNano SIM slot on the PinePhone Pro\nThere are a few software news I’d also like to cover this month. The most notable of which, and one which will eventually surely find its way into all OSes, concerns sound on the PinePhone Pro. Megi has recently released a set of patches that address some of the issues people have been experiencing: sound codec not working after boot (prior to an app playing audio), changing controls while headphone or speaker output is active breaks audio, sound stutter when serial console is enabled in CLI, OUTMIX and RECMIX drivers not matching the schematic and microphone quality. I invite you to read and follow megi’s development (b)log to learn of the details but, in short, the patches ought to improve the sound situation on the PinePhone Pro. I hope to see them make their way into individual OSes soon. As for the OSes, we’ve seen a few releases for the PinePhone and PinePhone Pro this past month. This includes (at least to my knowledge - there may be others) postmarketOS, Manjaro, OpenSUSE and DanctNIX (Arch). Most of the distributions shipping the Phosh mobile environment have now updated to the newest version which adds swiping motions; I haven’t had the opportunity to try the newest version of Phosh myself, but I hear very good things about it. I would also like to note that OpenSUSE shared an image of the PinePhone charging wirelessly using the Qi wireless charging case (currently out of stock), which is super cool to see. I am including a picture from the tweet below.\nWireless charging on the PinePhone running OpenSUSE - via Adrian Campos Garrido\nThere is one more thing I’d like to mention in this blog post that is distro-specific: I’ve seen reports that Mobian users have issues with the installer image. The problem it seems concerns the root partition not expanding properly during the installation process. I reached out to Mobian developers about a potential work-around and Undef was really helpful in emailing me comprehensive instructions. I should also note that Mobian’s dev team is aware of the problem and actively working to resolve it. Here\u0026rsquo;s the work-around:\nResize the primary partition using parted.\n$ sudo apt install parted Make sure to select the right storage device (exchange for x below); 2 will usually be eMMC while 0 is likely to be SD. $ sudo parted /dev/mmcblkX Inside parted run print just to make sure you are using the proper device. You should see two primary partitions:\n(parted) print Enlarge the 2nd to 100% capacity:\n(parted) resizepart 2 100% Print to see if the partition expanded correctly and then quit the program:\n(parted) print (parted) quit If you’re using an encrypted device run the following command - you will be asked for your encryption password: $ sudo cryptsetup resize calamares_crypt Then proceed to resize the ext4 filesystem:\n$ sudo resize2fs /dev/mapper/calamares_crypt Finally resize the btrfs filesystem and check results:\n$ sudo btrfs filesystem resize max / $ df -h Once again, many thanks to Undef for the detailed instructions. Star64 This month I come bearing good news about the Star64 RISC-V single board computer. Just three months after the board\u0026rsquo;s initial announcement today I get the privilege of unveiling the prototype - and I hope you’ll admit that it looks mighty cool. Star64 is the first true RISC-V SBC from us (I mean, unless you really consider the Pinecil a SBC), but as I wrote last month it certainly isn’t the last RISC-V piece of hardware you’ll be seeing from us. Just as a short recap: Star64 comes with a StarFive JH7110 64bit CPU sporting quad SiFive FU740 cores clocked at 1.5GHz. The SOC is equipped with BXE-4-32 from Imagination Technologies, which is said to be a solid mid-range GPU. Star64 will be available in two configurations - with 4Gb and 8GB of RAM, similarly to the Quartz64. Both hardware versions include USB 3.0 and a PCIe slot as well as two native Gigabit Ethernet NICs.\nStar64 IO \u0026ndash; left: dual Gigabit Ethernet, HDMI \u0026amp; power-in // right: 3X USB 2.0 \u0026amp; USB 3.0\nThe IO arrangement is very similar to what you’ve come to expect from one of our model-A type boards. Along the long leading edges you’ll find PCIe on one end and GPIO on the other. At one end of the board you’ll find a digital video output, a double-stacked Gigabit Ethernet port and a 12V barrel plug for power. On the opposite side, you’ll find 3x USB 2.0, 1x USB 3.0, an audio jack as well as a power button. There are also two U.FL ports for antennas - one for bluetooth and the other for WiFi.\nStar64 \u0026ndash; left: top view // right: bottom view\nThe onboard WiFi/BT module is RTL8852BU MIMO WiFi 6 with BT 5.2; it may already be supported in mainline Linux. The Star64 also has an MiPi display output complete with a touch panel (TP) input, a 12V power port, a CSI camera port and an eMMC slot. A micro SD card slot can be found at the bottom of the PCB. Similarly to the RockPro64 and Quartz64, the 12V port on the Star64 can be used for powering other hardware directly from the board - a popular example is powering one or multiple SSDs connected to a PCIe SATA adapter. I’ll add that, at least in theory, the Star64 would make a great NAS because of its SoCs low thermals and idle power. I am looking forward to seeing NAS-focused Linux or BSD* OSes available for the board.\nSpeaking of software, efforts to support the SoC in Linux have already begun. I’ve been told that both Debian and Fedora are already being ported to the StarFive JH7110, which is great news. We are certain that many other OSes will follow swiftly - especially once we start delivering the Star64 to interested developers. On the subject of availability: the Star64 will be available in a few weeks time, and will initially be available to developers. Given the interest in the Star64’s and the SoC powering I hope to see functional distributions available for the board soon after launch. We will obviously be monitoring the Star64’s software progress in the months to come and keep you posted on how development proceeds.\nPineBuds Pro A quick foreword about PineBuds changing name to PineBuds Pro prior to release: the hardware stays the same, it\u0026rsquo;s just naming convention - or branding if you will - changes to include the ‘Pro’ suffix. We’re doing this to indicate the additional functionality that the earbuds are capable of - ANC in particular. That’s all. I am glad to report that development of the PineBuds Pro is proceeding well. In fact, CE/FCC testing is scheduled to start early September, so a mid-Q4 release is highly likely. In July I shared pictures of the first moulded PineBuds carry case without the electronic guts - today I get to show pictures of the first moulded and working prototypes. This time around this includes the pods and the case, both of which arrived from the factory just the other day. As you can probably tell from the picture, the final mould of the carry case looks much more refined than the CNCd version shown in April. It is hard to make it out from the photos, but the case features a textured finish on the outside and a smooth finish on the inside. The buds themselves have a two-texture finish too, with the stems made out of shiny plastic and the body of the buds being matte. While none of the pictures below depict this, the case now also features a small row of LEDs on the front, used to indicate charging status and remaining battery. But let me stress this again - these are pictures of prototypes, and thus everything you see is subject to change.\nPineBuds \u0026ndash; left: buds in carry case // right: buds seen next to the casa\nSince the last post discussing the PineBuds we received much feedback regarding our initial decision not to brand the buds. This is not the first time we receive feedback concerning branding from the community; as a rule of thumb, we usually try to keep branding to a minimum on our hardware. As was the case with the Pinebook Pro, PinePhone and PineTab - we always try to incorporate the PINE64 logo in some tasteful and non-intrusive way. But this is a bit hard to achieve on something as small as a pair of wireless earphones. However, it does seem people are keen on rocking buds with a PINE64 pine cone, so we’ll run some test prints in the next few weeks and see how they turn out. I am attaching some impressions for you to take a look at below. Lastly, the Pine Store commissioned development of an alternative SDK and firmware for the PineBuds. The hope is that the new SDK will make development of community customised and user-tailored firmware easier to achieve. The custom firmware and SDK builds are about 2 weeks away I am told - once delivered we’ll have developers evaluate the efforts. If this is the first time you’re hearing about the PineBuds I invite you to read the April and May community updates in which the hardware was introduced and discussed at some length. I am sure I’ll have more information about the PineBuds to report next month, so stay tuned. Proposed PineBuds branding - let us know what you think\nPinecil [by Gamiee] The Pinecil V2 landed earlier this month and sold out almost instantly. The next production run of the ought to be available soon however - you can expect the next batch to land in PINE64 EU at the beginning of September and in the Pine Store a few weeks later. There will likely be a limit on how many units can be ordered by one person to make sure that everyone who wants one can get one (if they order within the first 72 hours or so). To be notified of availability, please follow PINE64 and PINE64 EU on Telegram, Mastodon and Twitter. We’ll make sure to give everyone a solid 24hrs heads-up before the next Pinecil batch becomes available again. Earlier this month I came across a very interesting comparison between Pinecil V1 and V2, which also includes a performance overview of the new tips. Spoiler alert, the V2 performs better when supplied enough power, but the new tips heat up much faster on both the V1 and V2. When combined with the right power source and fitted with the short 6.2 ohm tip the V2 heats up to a temperature of 300*C in under 3 seconds. It is a really interesting video by one of our community members, and I advise anyone interested in the Pinecil V2 to watch it. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video A comparison between Pinecil V1 and V2 as well as the new 6.2ohm tips - by River B.\nAs we mentioned in the previous community update, we have implemented a few anti-counterfeit measures into Pinecil V2. One of them is the possibility to verify that your Pinecil V2 is original. And you can do this on our authenticity verification page, which you can find on https://pinecil.pine64.org/. The process is quite simple: on your Pinecil enter the debug menu by holding down the minus (-) button, scroll down to the ID tab using plus (+) and enter the serial number (first row) into the online authenticator. You’ll be immediately informed whether your V2 is an authentic PINE64 product or a knock-off. Authenticity checked page\nThe Pinecil V2 is being shipped with IronOS v2.18, which is still up-to-date at the time of writing. There are no requirements to update the firmware, but if anyone wants to update their V2 then it is not currently possible. This is due to the new Bouffalo chip not using the DFU protocol for flashing and the flash tool, which supports the Bouffalo’s flashing protocol, is still a work in progress. It should, however, be available soon; stay tuned for more information in the coming weeks and months.\nPineTime [by JF] This month, we welcome a new companion app in the PineTime ecosystem: watchmate. The author announced it on Twitter and Mastodon a few days ago. Watchmate is a companion app which runs on desktop and mobile Linux and is compatible with PineTime running InfiniTime. Written in Rust and based on libadwaita and BlueR it already supports many features from InfiniTime, such as setting the time, reading battery level, recording the heart rate value, controlling media player and OTA firmware updates.\nThe UI is really nice and easy to use and a bit similar to Siglo: once connected, it displays various info, allows you to select the media player that will send info to the Music app and upgrade the firmware over the air (OTA). Watchmate will display a notification when it detects that a newer version of InfiniTime is available in the project’s repository, which is a very convenient feature!\nWatchmate functionality\nA few features like secure pairing and notifications are not implemented yet but they are already listed in the project roadmap. They waited to test watchmate and have enough time to maintain the project, and that they would transfer the project to anyone who would like to take over it. Since then the Github project has already been transferred to the InfiniTime organization and the application on the app store has been transferred to an account managed by Pine64 to ensure that it remains available on the Apple Store until it finds a new maintainer! Thanks again to xan-m for their work on InfiniLink!\nWatchmate running on the PinePhone Pro and Pinebook Pro\nThats all for this month, I\u0026rsquo;ll catch you all in September.\n","permalink":"/2022/08/28/august-update-risc-and-reward/","tags":["pinebuds","pinephone","pinepower","pinetime","risc-v","soquartz","star64"],"title":"August update: RISC and reward"},{"categories":["community","news","pine64-community"],"contents":"\nWe rarely, if ever, make responses to blog posts or articles. In fact, there is only one instance that I can think of when we did so. So then, somewhat uncharacteristically, this is a response post to Martijn Braam’s blog in which he explains why he left the PINE64 community. Let’s get one thing out of the way first: Martijn has done a lot for mobile Linux and PINE64 - he is a valued contributor and a colleague with a good insight into how PINE64 and the Pine Store Ltd operate. I should add that his opinions are welcome just as they have always been. Finally, there is no denying that his leaving is a significant loss to the project and, on a private level, a sad state of affairs for us in the community. If it wasn’t clear, we really like Martijn. But this isn’t what this blog post is about. Instead, this is a response to the points and concerns Martijn raises. A short summary first: Martijn’s blog entry alleges that following PinePhone community editions, and after settling on Manjaro with KDE’s plasma mobile as the default OS, PINE64 and the Pine Store Ltd have sidelined developers from other mobile Linux projects. The argument is made that this has hurt development. The example given in the blog post supposes that the community team and Pine Store employees were firmly intent on removing SPI on the PinePhone Pro and coerced not to ship Tow-Boot. He concludes by saying that we no longer listen to the development community.\nBut here is the thing, SPI has been included on the PinePhone Pro due to the input from developers and against our initial intent. The talks concerning SPI were tense, as Martijn mentions in the article, in part because we did approach them with a presumption that we’ll inform developers of our plan to drop SPI. I may add that the decision was made among ourselves, without the input of any third parties or partners. The reasoning behind not including SPI on the PCB wasn’t motivated by any single project or outside source - it was based on the fact that for years SPI was largely unused on PINE64 devices. In instances where it was used, it sometimes caused issues, which in turn led to a few support nightmares. I should also mention that SPI has skyrocketed in price at the time and became harder to source; all this, collectively, had us initially pretty firmly determined to drop SPI altogether. And yet, despite this, we agreed to include it on the PinePhone Pro because developers from multiple projects - postmarketOS being one of them - were adamant that it was an absolute necessity. We were also convinced to flash the SPI with Tow-Boot on the most recent batch of PinePhone Pro, which was the preferred bootloader of the majority of members in the private discussion group. Moreover, I should add that SPI is present on the Pinebook Pro and there is no need to solder one on. Pinebook Pro’s SPI doesn’t come with a pre-loaded bootloader, but the option to flash it is there for anyone who wishes to do so. As for the reason why Pinebook Pro doesn’t ship with a bootloader on SPI - it isn’t caused by favoritism for a particular group of developers or disregard for good ideas, but rather something more trivial. Namerly, a functional Tow-Boot build for the Pinebook Pro wasn’t available at the time of manufacture and shipping. We created a space for development talks to be held (as we always had), there was a lengthy exchange, there was a difference of opinion, we listened to all developers, and the outcome of the discussion changed our mind on the subject of SPI inclusion and Tow-Boot. And to be clear, we listened to different people. Differences of opinion and unwillingness to listen are two different things and cannot be equated.\nAll this shouldn’t exactly be a surprise to anyone who has ever interacted with us since, on a weekly basis, we talk to people affiliated with different projects (and to those not affiliated with any projects). Over the past month alone we talked with developers from a handful of major Linux projects regarding support for existing and future devices. We are also in constant contact with community contributors working on non-Linux devices - PineTime, PineBuds and the Pinecil V2 being examples of the latter. And, of course, we talk to our core partners too. This, however, has no impact on whether a good idea from a third party gets implemented or not. We always have been open to suggestions and we will keep on listening to input from the community. Now, surely there is more that we could have done in the past in the way of supporting development, and undoubtedly there is more we should do in the future. We haven’t delivered on a variety of ideas concerning supporting our development community - the DevZone being a prime example of a crucial system that still needs to be fully implemented (and it will). The DevZone will, among others, be a place where bounties will be offered to all contributors regardless of affiliation. Mea culpa, an argument can be made that in this regard we haven’t done enough in the past year. At the same time, I believe that our track-record of working with the community is such that listing examples of successful ongoing cooperations and of continuous support is unnecessary. To sum up this response post; Martijn has his reasons for leaving and we should all respect those. We are also thankful for all the work he, and the entire postmarketOS has, poured into the Linux smartphone space and the PinePhone in particular. That said, we don’t want to leave the claim that we do not listen to our development community unanswered - because it is unfair and demonstrably false. We are not mindless marionettes unable to make up our own minds about what course to pursue either. As a project, PINE64 is not afraid of taking responsibility or admitting to a fault, and surely there are many mistakes that the management of the project has made in the past, but blind favoritism or unwillingness to listen to our community are not on the list.\n","permalink":"/2022/08/18/a-response-to-martijns-blog/","tags":["community"],"title":"A response to Martijn's blog"},{"categories":["pinecil","pinesound","pinetime","quartz64","quartzpro64","star64"],"contents":"\nWelcome to the July community update - I hope you’re staying cool in the heatwave. This month we’re introducing the Pinecil V2 - an evolution of the original Pinecil - and taking a closer look at the Star64 RISC-V SBC. We also discuss Quartz64’s development progress, the PineBuds and receive an update on PineTime and InfiniTime from JF. Let\u0026rsquo;s get into it.\nYou 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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank Alex (clover) Ben Brown (Ralim), pillow, JF and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nhttps://www.youtube.com/watch?v=Tn4S1mdt7QQ\nJuly Update video synopsis\nTL;DR\nHousekeeping New PineTalk episode is out Quarterly Q\u0026amp;A on August 13, at 8:00PM CEST (UTC+2) Alternative payment methods available in Pine Store again The Pinebook Pro is available PINE64 EU has launched Pinecil (V2) New RISC-V SoC Adds BLE - opening potential for OTA updates \u0026amp; remote telemetry Automatic detection of tip resistance Compatible with existing peripherals and accessories, including cases Range of new, shorter 6.2ohm tips for higher power level IronOS already ported Counterfeit protection; future option for users to verify if their Pinecil V2 is legit Available very soon Star64 Congratulations to Gav for being the first to solve the riddle! Star64 is in final layout stages and we want to bring it to the market soon Uses StarFive JH7110 64bit CPU paired with BXE-2-32 GPU Available in 4 and 8GB RAM configuration Equipped with 2x Gigabit Ethernet ports (a variant with 1x GbE will be available later on for $5 less), PCIe, USB 3.0 as well as 2x USB 2.0 and GPIO Follows Quartz64 model-A pricing and footprint PineSound PineBuds plastic molding is now complete and first test molds underway Hoping to being PineBuds to the market as soon as possible - maybe in October Similarly to the Pinecil and PineTime, PineBuds have been built to deliver a great out-of-the-box experience for everyone, while also offering depth for tinkerers and those who wish to hack QuartzPro64 \u0026amp; Quartz64 QuartzPro64 dev units started shipping; we’re still accepting coupon requests from developers Quartz64 receives DietPi support; now supported by Armbian, Manjaro, DietPi as well as giving option to run Arch Linux and NetBSD Pillow submitted patches enabling PCIe and analog audio, a fix for fast SD cards has been accepted upstream, and patches enabling JPEG encoder have been merged PineTime Infinitime 1.10 released with many changes \u0026amp; improvements under the hood It is now possible to dismiss notifications Tweaks to display, colour and gamma settings - making things look better InfiniSim new features include animations \u0026amp; allows screen capture in GIF format Ongoing work to improve memory situation by leveraging additional 4MB of internal flash InfiniTime has 584 forks Housekeeping Before we get to all the news of this month there are a few housekeeping items. In case you missed it, the most recent episode of the PineTalk was released earlier this month. In this month’s episode, Zed - the show\u0026rsquo;s editor - replaces Brian as co-host and joins Justin in discussing PINE64 news, gaming on Linux and gaming-related Linux hardware. The latest episode can be found on PineTalk’s page along with all previous episodes. If you haven’t done so already I suggest you subscribe to the podcast’s RSS feedor follow it on the streaming platform of your choice. It is time for the quarterly Q\u0026amp;A. The Q\u0026amp;A is a community event which provides you with an opportunity to ask questions live in the chat and have us answer you live. In theory, we should hold the Q\u0026amp;A this month, but due to the holiday season - Marek is unavailable at the end of this month and I’m away at the beginning of the next - we’ve decided to schedule the Q\u0026amp;A for August 13th, 8:00 PM CEST (UTC+2). Just as last time, you will be able to pose questions on Discord, IRC, Telegram and Matrix and we will be live-streaming on Youtube. Many people asked us to simultaneously also live-stream the Q\u0026amp;A session to PeerTube - we will try to accommodate this request. A reminder about the Q\u0026amp;A will be released closer to the date via Telegram, Discord News channels and Social Media. Stay tuned!\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video The last community Q\u0026amp;A in case you missed it\nIn other news, it is once again possible to pay using alternative methods in the Pine Store via Stripe. For the past few months people only had the choice of PayPal at checkout, but now credit / debit card payments as well as payments via Apple and Google Pay have been reintroduced. We are well aware that people want multiple choices at check-out, and the Pine Store actively explores ways to provide an array of payment options. Speaking of the Pine Store, in case some of you missed it the Pinebook Pro is once again available for purchase. I know that many of you have been waiting for the Pinebook Pro to make a return, so if you’ve been waiting to pick up a unit then now is your chance. Dsimic is working on a write-up about the PCB of this Pinebook Pro batch, so keep an eye out for his post on this topic in the coming weeks. The ANSI variant is avaialble now. There is no schedule for the ISO variant.\nLastly, this month PINE64 EU finally launched following a delay due to various regulatory and technical hurdles. The store’s opening has been met with overwhelming positivity and I am humbled by the response. I am also thrilled to see the number of people who decided to check PINE64 EU’s website out and to pick up hardware - I never expected this much traffic. There is more stock on the way and as I stated in the past the selection of available gear will gradually grow. Early August will see the addition of the PinePower, USB-C cables and swag, as well as a restock of the PinePhone and the PineTime. I invite you to follow PINE64 EU’s Twitter, Mastodon and Telegram news channel to be notified when hardware gets restocked. Pinecil (V2) [by Ben Brown] Two years ago, the Pinecil V1 was announced, and since then has become PINE64’s most popular consumer hardware. Sadly, I\u0026rsquo;m far worse at Riddles than the great Lukasz, so to cut to the chase, today we are announcing the follow up version two, which is more of an evolution than a revolution. Featuring improved hardware and accessories it retains the same ergonomics and design as the original Pinecil, and it will work with any accessories you already have. It will obviously work with any external accessories, such as cables, but also with existing cases and tips.\nThere are more improvements than just the teal silicon grip ;)\nOn the subject of tips, as well as the new Pinecil, we are creating a new line of tips for both the Pinecil V1 and V2. These tips are optimised for a higher power level than the standard Pinecil tips. By reducing the tip resistance from 8 to 6.2 ohms, they allow 65W at 20V USB-PD standard input. These tips will ship with the Pinecil V2 by default, but if you already own an original Pinecil then you’ll be able to pick up the 6.2 ohms tips from the Pine Store and use them with your existing device. All parts are directly interchangeable and replaceable with the V1\nThe Pinecil V2 is a natural follow on from the first version, still using a RISC-V processor, but adding noticeable upgrades to the hardware. Key changes from version one:\nNew Processor (BL706) Adds Bluetooth Low Energy Higher maximum input voltage Tentative support for USB-PD EPR (28V) Support for measuring tip resistance Allows automatic detection of 6.2 vs 8 ohm tips Things staying the same:\nGPIO is broken out on USB-C for creating your own projects Same pinout as Pinecil V1 Same great feel, including the rubber grip Works with all existing tips Same DC input + USB-C input connections Same case as V1 and compatibility with the red and transparent cases A notable improvement is the new BL706 RISC-V processor from Bouffalo. It is similar to the BL602 in the Pinenut from the Nutcracker challenge. The BL706 features Bluetooth Low Energy; so future IronOS releases will work to enable exposing features over Bluetooth Low Energy. One obvious future feature making use of BLE would be OTA firmware updates. That said, while technically possible, implementing OTA updates will be a non-trivial amount of work. It is something I suspect someone will make at some point for the bl70x/bl60x chips however, and If someone makes it, I’d be happy to incorporate it into IronOS.\nPinecil V2 PCB top and PCB bottom\nThe other potential future feature that BLE offers is remote telemetry and control. I\u0026rsquo;m currently thinking about what the future use of it would be, and I am always open to community requests and suggestions. For like a year now there has been chatter in the Pinecil chat about hacking a bl60x into Pinecil V1 to add WiFi/BLE; main driver has been having a remote control screen and possibly integrating into other software to, for example, turn on the air vent automatically while soldering. I suppose one’s imagination and the sky\u0026rsquo;s the limit, but these two implementations would be legitimately useful additions rather than gimmicks. The inclusion of BLE is directly inspired by discussions that have been going on in the community chat for the Pinecil, and we are looking forward to seeing where the community takes the new feature set.\nAdditionally the hardware is designed for higher voltages to enable USB-PD EPR support (the higher voltage USB-PD standard is starting to become available). Using this new EPR standard, 28V PD chargers can be used with automatic negotiation. Pinecil V2 comes in a simpler box, more in line with the aesthetics of other PINE64 hardware\n[edit from Lukasz] The Pinecil V2 will be available shortly: it may, in fact, be already available in the Pine Store when you’re reading this. The original Pinecil is the most popular PINE64 device - not counting the industry-focused SOPine modules - and it is also the most counterfeited hardware in our lineup. The Pinecil V2 introduces some measures to combat counterfeiting, which I won’t be discussing as I’m sure you’ll understand, but Ben told me that eventually users will be able to verify the authenticity of the Pinecil V2 on their own. Countermeasures aside, you should be aware that there are no more genuine Pinecil V1 units available and there won’t be any moving forward. In other words, all Pinecils available for purchase now on popular large web-stores aren’t legitimate. Lastly, many thanks to Ben for introducing us to the Pinecil V2 and for the amazing support from IronOS. Star64 Last month I had the pleasure to announce the Star64, PINE64’s first RISC-V single board computer. If you missed it, the announcement took the form of a riddle, and I was thrilled to see so many people from the community participating and offering responses and guesses. I would also mention that I found some of the inaccurate guesses truly inspiring, and may draw on them for inspiration in the future when we’re working on new hardware. Congratulations to Gav who was the first to correctly decipher the riddle - someone will reach out to you for your shipping details closer to Star64’s release date. For those of you who are interested in the riddle, I’ll do a short run-down analysis at the end of this section. I covered a lot of the core hardware specifications last month, but just as a recap the Star64 is a single board computer comparable to the Quartz64 model-A - the notable difference being the RISC-V SoC at the heart of the SBC. The StarFive JH7110 64bit CPU features quad SiFive FU740 1.5GHz cores and comes paired with BXE-2-32 GPU from Imagination Technologies. I’d like to note that this is a different SoC to the one introduced last year, not in the least because this one includes a GPU. The board will be available in two configurations, with 4 and 8GB of RAM and we aim to match the Quartz64’s price point of the respective hardware versions. Similarly to the Quartz64 model-A, the Star64 will feature an open-ended PCIe port, USB 3.0 and GPIO. One thing I hinted at last month was that the Star64 will have 2 native Gigabit Ethernet ports. A version with only one Ethernet port will also be available at a later date, and we expect it to cost $5 less.\nA look at the final layout of the Star64\nMuch of the work on Star64 work has now finished and the board in its final layout stage. There is still some testing needed, which will help us characterize the single board computer\u0026rsquo;s qualities and performance. The initial review has yielded some very positive results, partly because the SoC runs cool without the need for passive or active heat dissipation, even under load. The SoC running cool without a heatsink is great news, as it opens the door for the platform to become a basis for future devices. In any case, the initial impressions are very good and we have high hopes for the Star64 becoming an opener for our RISC-V single board computer range. It will still take some time before Star64 finds its way into the Pine Store, but the engineers are working hard to make the launch happen sooner rather than later. I will keep you posted on Star64’s progress in the coming months.\nFinally, for those of you who are interested, here is a short breakdown of the riddle. I titled the riddle Victoria Line Station, because a station on the Victoria line underground in London is called Seven Sisters, which is the common name for Pleiades star cluster. First stanza: people who sing, act and dance and are recognizable are usually referred to as ‘stars’. The final line of the first stanza is a reference to a falling star. Second stanza: aside from the sky, stars can also be found in the sea - sea stars. I also associate stars with magic depictions in kids books. The final line of the second stanza indicates that 64 should be added at the end of the root name. Final stanza: here it would appear that I’ve made a mistake - stars first turn to blue giants, then to red giants, and only then explode. I should have gone back and double-checked my highschool knowledge. PineSound It has been a little while since the last update on the PineSound project and the PineBuds in particular. The PineBuds were first introduced in April and we have since been working hard to accelerate the pre-manufacturing process to bring production units to the market as soon as possible. I now come bearing news that the PineBuds tooling is finished and plastic molding has started. Obviously the plastic chassis of the buds and their case are just one part of the manufacturing jigsaw puzzle, but it is also a very important one. Granted the plastics turn out well, and no major changes to the mold will be necessary, then the next step is to deal with the electronics. A decision was made to go with no branding on the buds\nIt may seem a bit counter-intuitive but, in a sense, the electronics are easier to deal with than the plastic molding. The most challenging part in this day and age is perhaps selecting components that can be reliably sourced in the long term. At present, we expect the production of PineBuds’ electronic components to be fairly straightforward, especially given that the prototypes have been thoroughly tested and found to be very reliable over the course of the past 5 months. First plastic mold of the PineBuds carry case\nIf everything pans out, we hope to be able to make PineBuds available for purchase in early October. I hope that the Pinebuds will turn out interesting to a wide demographic by offering solid core functionality to those who simply want good in-ear headphones, as well as a deep and easily accessible array of options for those who wish to tinker and hack. In this sense the PineBuds are a very similar product to the PineTime and the Pinecil. Needless to say, we hope that the PineBuds will see the same level of success as the PineTime and the Pinecil have enjoyed. QuartzPro64 \u0026amp; Quartz64 Before I get into some of the Quartz64 news, I would just like to mention that the first batch of QuartzPro64 boards have gone out to developers. I was glad to learn that the first round of developers have already received their boards and began working on supporting the platform. This was the first dispatch of QuartzPro64 and many more are yet to come. We have received a good response from the development community and the boards sent out earlier this month have found their way into the hands of very skilled developers. We are, however, still actively seeking the best possible candidates for these early development boards, so if you are someone who could contribute to the bring-up process of the RK3588 then make sure to submit your application to purchase a dev unit at half the price.\nThankfully you have quite a few heatsink mounting options Sergio - got a RockPro64 or (very) old GPU heatsink laying around?\nNow, let us discuss Quartz64 developments. Earlier this month DietPi added support for both Quartz64 and SOQuartz. The Quartz64 is now officially supported by DietPi, Armbian and Manjaro, but instructions for running Arch Linux and NetBSD have also been added to the Wiki in recent weeks. We also hope to get other OSes on board supporting Quartz64 in the coming weeks. As a side-note, if you are a maintainer of a distro that added support for the Quartz64 then please reach out to one of the mods and notify them so they can add relevant entries on the Wiki. The reason why we’re seeing an increase in the number of OSes supporting the platform is the pace at which the Quartz64 matures. As I showcased last month, the current development pace has helped push the PineNote closer to a more general early-adopter release. Obviously the benefits are mutual, and development on the PineNote has also helped the Quartz64. DietPi announcing support for Quartz64 this month\nI spoke to Pillow this past week to learn what advances have been made in the past month. I was told that they submitted patches enabling PCIe and analog audio output for the Quartz64 Model-B to mainline Linux. A fix for fast SD cards not working on the Quartz64 has also been submitted upstream and will hopefully find its way into previously mentioned OSes with the next Linux installment. Last but certainly not least Pillow patches enabling the JPEG encoder on the RK3566, which benefit not only the Quartz64 but also the SOQuartz and the PineNote, have now been merged. This is a tonne of fixes in a relatively short period of time, and these are fixes that benefit the entire RK3566-based ecosystem. I am thrilled to see the platform taking a hold in the community, maturing and gradually improving. PineTime [by JF] We released InfiniTime 1.10 \u0026ldquo;Yellow Mango” shortly after last month\u0026rsquo;s community update. This new release is the result of nearly 3 months of work by the community: 54 pull-requests were merged, totalling 139 commits and 242 files changes. Thanks to everyone who participated in this new version of InfiniTime! InfiniTime 1.10 contains a lot of changes under the hood: code cleaning and refinements, improvements to the build system (automatic font generation), update of the toolchain, and more. These changes are not visible to the end users but are very important for the maintenance of the project in the long term.\nOf course, we have also added some features that will please our beloved users. A lot of them were asking for this for a long time for a possibility to dismiss notifications. This is now possible in InfiniTime - all you need to do is swipe on the notification from left to right to dismiss it.\nHere\u0026rsquo;s a video I shot when testing this new feature on my devkit using the PinePhonePro:\nSee Work in progress: testing notification dismiss.\nTesting notification dismiss from a PinePhone Pro with keyboard case\nWe\u0026rsquo;ve also tweaked the display settings and gamma to improve the color displayed by the LCD, improved the Timer app interface, and reduced the time needed for the watch to go to sleep. These are just some of the more noteworthy refinements, but this release has many other improvements and bug fixes.\nInfiniSim, the InfiniTime simulator, has also received a couple of new features: it now supports InfiniTime animations (vertical and horizontal transitions) and allows recording screen capture in GIF format. This is a very useful feature that allows us to easily do demonstrations and share progress with other people. We’ll probably also use it extensively in our documentation in the near future.\nScreen capture from InfiniSim showing animations and dismissing of notifications\nSiglo also received a few updates and released version 0.9.9 at the beginning of this month. In contrast, InfiniLink, the iOS companion app for InfiniTime, is still looking for a maintainer. Xan-m, the original author, announced a while ago that they would not be able to maintain the project and that they would transfer the project to anyone interested to take over it. In the meantime, the Github project was transferred to the InfiniTime organization on Github. We also plan on transferring the app to an Apple developer account managed by Pine64 to ensure that the app will be available on the app store when Xan-m\u0026rsquo;s account expires.\nInfiniTime is an open source project. It means that the code is publicly available and that anyone is free to do whatever they want with it as long as they comply with the license of the project (GPLv3). Therefore a lot of people contribute to the project by creating pull-requests and asking the core-developers to review and merge their contributions into the original project.\nHowever, some changes cannot always be integrated in the project, and for various reasons: they do not fit with the project vision or priorities, developers do not have the time to review them or\u0026hellip; the changes consume too much memory! I\u0026rsquo;ve already mentioned this in the past: the PineTime is based on a tiny hardware that embeds a very limited amount of memory - 512KB of flash and 64KB of RAM. InfiniTime does not fully use the memory yet, but I take great care to avoid hitting the limit as that would make the maintenance of the project very difficult.\nIn such cases, some developers decide to maintain a fork of InfiniTime with their changes. A fork is basically a copy of the project that they maintain on their own. To this day, InfiniTime counts 584 forks! Among these forks, you\u0026rsquo;ll find Sec42\u0026rsquo;s fork that adds changes to make notifications easier to read by \u0026ldquo;old\u0026rdquo; eyes and Dmlls\u0026rsquo;s fork which adds the Infineat watchface and is very well maintained. These forks are a good thing as they allow developers to make their contributions available to the public even if they cannot be merged in InfiniTime right now, and they provide more choice to the users. Everyone wins!\nSpeaking of memory usage, I\u0026rsquo;m currently working on improving the situation by leveraging the additional 4MB of external flash memory available on the PineTime hardware. My work is still in the \u0026ldquo;proof of concept\u0026rdquo; state, but shows very good results. The goal here is to store data that needs a lot of space (mainly pictures and fonts) in this external memory to free some space in the internal memory. I\u0026rsquo;ve recently demonstrated a build with the G7710 and the Infineat watchfaces where pictures and fonts are stored in the external memory. There is a slight impact on the performances and display speed, but it opens the road to many new apps and watchfaces in the future!\nSee Work in progress: test background image and font loading from external flash memory.\nTesting background image and font loading from external flash memory\nAs you can see, the community is still at work on anything related to PineTime! However, don\u0026rsquo;t worry if you notice a small drop in activity - we are just enjoying the summer and taking well-deserved holidays!\nFinally, let me remind you that you can purchase the PineTime from the new PINE64 EU store that opened at the beginning of July!\n","permalink":"/2022/07/28/july-update-a-pinecil-evolved/","tags":["pinebuds","pinecil","pinesounds","pinetime","quartz64","quartzpro64","star64"],"title":"July Update: A Pinecil Evolved"},{"categories":null,"contents":" Download audio\nZed the editor and Porky explore the world of Linux and Open Source gaming. Porky also talks about why he won’t be getting a Steam Deck afterall…\nhttps://linmob.net/weekly-update-21-2022/ https://linmob.net/weekly-update-22-2022/ https://linmob.net/weekly-update-23-2022/ https://linmob.net/weekly-update-24-2022/ https://linmob.net/weekly-update-25-2022/ https://gitlab.com/postmarketOS/pmaports/-/merge_requests/3123 Steam Deck: https://store.steampowered.com/news/app/1675200/view/3220644827954565733\nSteam Summer Sale began and boy are my arms tired: https://www.gamingonlinux.com/2022/06/steam-summer-sale-2022/\nBootlooping issues found, currently solutions being worked on: https://twitter.com/OnDeck/status/1518809743619334144?cxt=HHwWgICpncba8pMqAAAA\nSteam Deck parts now available at ifixit.com: https://twitter.com/OnDeck/status/1528783641454579712?cxt=HHwWgMCg9eenqrcqAAAA\nSteamOS 3.2 Update: https://store.steampowered.com/news/app/1675200/view/3297210455204349335\nMusic from Bensound.com and Zed (@itismezed)\nhttps://soundcould.com/kevinflynnretro\nEdited by Zed\n","permalink":"/podcast/s02e09/","tags":null,"title":"S02E09: Gaming on Pine64 is a Thing"},{"categories":["pinebook-pro","pinenote","pinephone","pinephone-pro","risc-v"],"contents":"\nThis month we reveal that we are working on a powerful and affordable RISC-V single board computer, discuss PineNote’s huge software improvements and provide updates on PinePhone, PinePhone Pro and Pinebook Pro’s availability. I am also taking the opportunity to let you know that, after 6 years of holding PINE64’s community manager post, I’ll be resigning from my position shortly, once PINE64 EU launches next week; Marek Kraus will gradually be taking over my responsibilities.\nThere is much to cover this month, so let\u0026rsquo;s get cracking.\nYou 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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank dsimic, Alex (clover) and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nTL;DR\nHousekeeping Read JF’s post about using the Quartz64 as a NAS QuartzPro64 developer coupons have started going out - devs, check your inbox New PineTalk is out Pinebook Pro available in July - a post on PCB revision coming soon PINE64 EU launching after (over) a month long delay Marek becomes community manager at PINE64 Who likes RISC-V? We’re making a powerful and affordable RISC-V model-A type SBC SBC in final layout phase Comparable specs and price point to Quartz64, but with RISC-V SoC Be the first to solve the riddle and receive our first RISC-V SBC PinePhone (Pro) PinePhone and PinePhone Pro are back in stock - shipping mid July Installing community modem firmware is now easy You can play Doom on PinePhone (Pro)’s modem! Camera developments and major improvements to Megapixels postprocessing PineNote Linux on the PineNote is now in good shape Major developments for the e-paper display - work by Smaeul on the driver detailed It is now possible to write using EMR pen on the PineNote running Linux in a standard Debian installation Showcase of smooth (quickly appearing) handwriting Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of the June Update\nHousekeeping Earlier this month JF wrote a guest post in which he showcased the Quartz64 model-A’s functionality as a NAS. The post details retrofitting a standard ATX computer case to fit a Quartz64 model-A and outfitting the setup with 6 SSDs. JF also provides general guidance to reproduce the setup and offers a handful of benchmarks of the NAS’ performance. While JF used Manjaro as the basis for his NAS, I feel this is a good time to let everyone know that Debian Armbian builds for the Quartz64 are now available for download. I know that many people are in favour of Debian’s stability when it comes to building something such as a NAS, and therefore I am thrilled to see that now it is available as an option on the Quartz64. I should also mention that I expect to see many more OS builds available for Quartz64 and SOQuartz shortly.\nJF\u0026rsquo;s NAS - via guest blog post\nStaying on the subject of single board computers, the QuartzPro64 developer edition coupons will start going out shortly. If you’ve signed up to purchase a unit, please keep an eye on your inbox. If you receive an email with a coupon code, you will have limited time to complete the purchase. The email will also include the link to the page where you can complete your QuartzPro64 purchase.\nLast month I had the pleasure of bringing the much anticipated news that Pinebook Pro is re-entering production. This month I am glad to confirm that the Pinebook Pro is already in production, and we expect units to be delivered from the factory sometime in July. We will make sure to notify you once stock is available on social media and in the news channels. Dsimic will soon be publishing a guest post about PCB changes made to this production run, so keep an eye out for his impressions in the coming days.\nA peek at the Pinebook Pro\u0026rsquo;s 2022 PCB - via dsimic\nIn case you missed it, a new PineTalk episode was released at the beginning of this month. In this month’s episode, Brian and Justin covered topics covered in the May community update and discussed their experience with open and security-focused Android ROMs. Justin also talks about an idea he pitched to me concerning a smart-speaker. The duo also promised to read and respond to the audience\u0026rsquo;s questions, so make sure to bombard them with emails, toots and tweets. I too think that the show deserves a higher degree of community engagement. If you haven’t yet added PineTalk to your RSS feed, then here is a handy link: RSS feed.\nPINE64 EU is finally ready to open its doors for business. I don’t have a specified launch day yet, but it will be next week - it largely depends on how quickly I manage transport, unpack and inventory everything. I once again wish to apologise for the delay in the store’s opening - I ran into issues with EU regulation that needed to be addressed. Suffice to say, relevant institutions take their sweet time with every piece of submitted paperwork; in my case, it took some 4 weeks for a complete review. Anyways, here is what will be available for purchase on day one: PinePhone Pro, PinePhone, the Pinecil, PinePhone (Pro) keyboard case, protective cases for the phones as well as the PineTime. As I mentioned in the past, this is just the beginning, and the aim is to have the EU store grow its selection to include other hardware in the future. I should also mention that customers will be able to select from Mobian, Manjaro and postmarketOS to be installed on their PinePhone (Pro). I also have a small surprise which will be announced on the day of the store’s launch, so make sure to follow PINE64 EU on Twitter, Mastodon and Telegram (news channel, not a chat). Lastly, at the beginning of next month, as the EU store’s launches, I will give up my position as community manager at PINE64. But fret not, I am leaving you in very capable hands - Marek Kraus will be taking on the role of steering the community in the future. Marek has been a part of the project for a long time and played a crucial role in PINE64’s success. He is highly personable, cool headed and, unlike me, also very technically skilled (including hardware and software). This means that not only is he able to communicate with contributors, engineers and partner project developers, but he is also able to speak their language. I am handing down this post to Marek with complete confidence and I know that he’ll do an incredible job. As for myself, while the PINE64 EU will be my core focus from now-on, I will remain a part of PINE64 and the community - I’m not going anywhere. I’ll also keep on writing the updates, hosting quarterly Q\u0026amp;As, engaging with the community, etc. The transition of responsibilities between Marek and I will be gradual and fluid; it will take time. Congrats Marek and take good care of my beloved project :) Who likes RISC-V? We have hinted at this for some time, and many of you knew it would become a reality eventually: we’re now in the final layout phase for a powerful, yet affordable, RISC-V single board computer. I need to be a bit cagey about what I write, partly because I want you to solve the riddle at the end of this section, and in part because not all information has been set in stone and disclosed publicly by the SoC vendor. Before I get into some of the details I’ve been allowed to disclose, here’s the spiel: the board will premiere in our signature model-A form factor, feature CPU performance which falls somewhere in the neighbourhood of the Quartz64, offer plenty of IO, and sport a price-tag similar to that of the Quartz64. In a nutshell, a Quartz64 model-A type board but with a RISC-V SoC. Sounds good? Then keep on reading.\nPCIe is important to industry clients; ROCKPro64 in RoninDojo Tanto - via RoninDojo\nThe board will be available in two configurations, with 4GB and 8GB of RAM. Similarly to the Quartz64 model-A, the RISC-V board will feature both USB 3.0 and a PCIe slot. Having an open-ended PCIe slot on a board offers it a high degree of versatility, which we know is something that developers, end-users and industry clients want. The SoC features two native Gigabit Ethernet NICs, but I am not certain if there are plans to expose both of them on the PCB - this hasn’t been determined yet. Regardless, I figured it is worth mentioning it as an available option. The SoC has Imagination Technologies’ BXE-2-32 GPU for which the source code ought to be made available soon. Imagination Technologies have recently come through on their promise of open sourcing their other GPUs, so there is no reason to believe that it will be any different in the case of the BXE-2-32. Since the formal introduction of the board to the market is still a few months away, the code may very well be available on launch day.\nThe model-A SBC form factor should be familiar to everyone (pictured: Quartz64 model-A, PINE A64(+), ROCKPro64)\nThe last thing I want to communicate is that the RISC-V platform is something we wish to pursue in parallel to our well established ARM-based hardware. While we don’t have set-in-stone plans regarding the platform, be on the lookout for more RISC-V hardware offerings from now through 2023. We have some candidate devices for a RISC-V conversion and ideas for future iterations of hardware based on the architecture, which is something I believe many of you will find exciting. In short: we have made a decision to commit to the RISC-V platform. I’ve decided to keep the name of the board out of this introductory post so that you can decipher the riddle below. As we’ve done in the past, the first person to correctly decipher the name of the board will receive the first unit that rolls off the factory floor. Your guess needs to be filed in the comments section; guesses posted elsewhere don’t count. Don’t worry if your guess doesn’t immediately show up in the comments - it needs to undergo moderation. All comments are time-stamped, so there is no chance of being leapfrogged by someone else submitting their guess after you. I’ll have more information about our RISC-V board for you next month.\nVictoria Line Station\nI sing, act and dance\ncelebrated by them all\nI never climb my stage\nbut I sometimes fall\nIn the sea I dwell\nand in every magic book By heaven!\nadding 64 is all it took\nOn my stage I shine\nand when I feel truly blue\nthen there’s nothing\nThis is the final clue\nPinePhone (Pro) Let me open with a short update on Pinephone and PinePhone Pro’s availability; we currently expect to receive the next production-run in approximately mid July at which point shipping will commence. At the time of publishing this post, both PinePhone and PinePhone Pro should now be listed as being in-stock.\nAs most of you are aware, the PinePhone (Pro)’s Quectel EG25-G modem is effectively its own single-core Arm computer running a closed Linux-based firmware. Over the past 2 years the community put in an immense effort to improve and adapt the IoT modem’s firmware to better serve the PinePhone (Pro). Work by Biktor and Konrad, as well as that of other contributors, opened the modem up to tinkering and thereby also to alterations and improvements to its software. Before I write another word, I need to underline that it is PINE64’s and Pine Store’s position that the licensed proprietary firmware on the modem should not be tampered with, and it is my duty to notify you that altering the modem’s firmware may violate your local laws, which in turn can have very real consequences. Therefore, please consider the following to be a progress report and a showcase, which I find to be fitting well with the community spirit of this blog, but it is not an enticement to use alternative firmware on your PinePhone (Pro).\nUntil recently it was very difficult to switch from the closed Quectel firmware to the much more open firmware by Biktor. This community firmware contains no binary blobs in the userspace, and significantly reduces the modem’s power consumption and heat output by running the SoC at just 100Mhz instead of the default 400Mhz/ 800Mhz. Until recently, installation of the community firmware required you to have a firm understanding of the command line and ADB. Now, however, the process has been completely streamlined and achievable via fwupd, and from a GUI no less. I decided to try the process on my own hardware running DanctNIX Arch Linux. The process is as simple as opening up the GNOME software centre, searching for “Firmware” and downloading the GUI utility. Upon launching the Firmware utility the Quectel modem is automatically listed as eligible for firmware updates. Tapping the modem provides information about the current vendor firmware, vendor ID as well as many other information. Scrolling down reveals available releases from Biktor. The installation is as simple as tapping the chosen release, reading the precaution popup, and agreeing to proceed with the installation. The installation takes approximately 10 minutes, and at the end of which the phone needs to be rebooted. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Installing modem firmware using GUI - via Martijn Braam\nI have now run Biktors firmware for a handful of days and I am very pleased with its performance. I can tell that the phone as a whole runs considerably cooler and the additional quirks it offers are fun to toy with. I also haven’t experienced any issues with LTE, GPS, making and receiving calls nor with sending or receiving SMS. If anything, on the default firmware I would sometimes experience issues with receiving calls (usually after a few days of the PinePhone running) but as of today, my PinePhone running the community modem firmware hasn’t dropped a single call - at least, not to my knowledge. But Biktor’s firmware has another tangible benefit over its closed-source counterpart: namely, it is more secure and not susceptible to the malware first distributed in December of last year. This is a major boon, especially to all those who are getting a PinePhone (Pro) strictly for privacy and security purposes.\nBut an open firmware opens an avenue for doing a wide variety of things, some of which are not necessarily related to telephony at all. Indeed, some applications may not even be useful, and only serve as an illustration of what can be achieved when running open source software. One such example is running Doom on the modem, because, ya’ know, everything needs to run Doom. Biktor put together a special (pre)release of the firmware which bundles X11, a VNC server and Chocolate Doom for those of you who wish to try this out. Below you’ll find a short video showing Doom running on the PinePhone’s modem. https://www.youtube.com/watch?v=GvLlP6BEPPk\nDoom on PinePhone\u0026rsquo;s modem - original video via Biktor on Twitter\nWhile I can neither recommend nor suggest flashing this community-built modem firmware, I privately think that it clearly serves a purpose and has an application if you reside in a region where unlicensed modem firmware is permissible. From what I can tell, the firmware offers many benefits to PinePhone (Pro) users and no obvious drawbacks. I should also mention that if you attempt flashing your PinePhone (Pro)’s modem firmware and something goes wrong, then neither we nor Biktor bear any responsibility for it. Lastly, I know that Biktor would appreciate help developing this firmware further, making it even more secure and its feature-set more robust, so if you are interested in this project then please consider donating via ko-fi or liberapay, or contribute code.\nLastly I’d also like to mention that the cameras on both the original and Pro versions of the PinePhone have received some major improvements. As I reported last month, thanks in large part to Megi’s efforts, the camera on the PinePhone Pro’s is now functional - although it will take time for it to be incorporated into an application like Megapixels. For the past month Megi has been working on a calibration application for PinePhone Pro’s cameras. In his recent blog post, Megi writes: “I started writing a GTK4 based app that connects to the Pinephone Pro over WiFi and allows to modify parameters inside the sensor and ISP, while monitoring the effects of various correction in real time, inspect histograms for various color components, and in general to experiment with the cameras and the ISP fairly painlessly. This should help with the calibration process as much as possible“. The application also allows live mjpeg streaming over HTTP to as a convenience feature. Megi also explains that he is putting a lot of time into the design of the UI controls and CPU optimisation, so that the application is both cognitively ergonomic and only utilizing a single core for a lag-free experience. Ultimately, the goal of his efforts are to make it easier for end-user applications, such as Megapixels, to properly calibrate and incorporate his code. https://www.youtube.com/embed/H-S8F5zAUAY\nStreaming video via the PinePhone Pro application app - via Megi\u0026rsquo;s blog\nOn the subject of Megapixels, Martijn Braam released a video showcasing new post-processing modes that will soon be included into Megapixels. Users will now be able to manually select from three different post-processing modes: the original mode (currently available), single and stacked. The new post-processing modes are not only much faster, but they also result in much nicer, richer and more natural photographs on the original PinePhone. Taking photographs is one of a smartphone\u0026rsquo;s core features, and the picture quality on the original PinePhone has just received a major ‘bump’. This is something all PinePhone users ought to be looking out for.\nFirst image: old camera post processing / Second image: new camera post processing - via Martijn Braam on Twitter\nPineNote It has been some time since I wrote about the PineNote. This is partly because much of the work at this point centers around the e-paper display. But let me back up a little bit. The PineNote has benefited from all the progress made on the Quartz64 platform. In case you missed it, I described Quartz64 progress back in March and in last month’s update; much work has gone into making the RK3566 platform functional, and with patches being upstreamed a sizable portion of the core functionality is now available in mainline Linux. In other words, the basis upon which the PineNote is built is in good shape. However, the PineNote is not a single board computer and it also doesn’t rely on a traditional video output. The first breakthrough for the PineNote came in January of this year, when developers managed to initiate the e-paper display under non-BSP Linux. Since January much of the work concerning the PineNote centered around making the e-paper display more usable. Whilst the PineNote could display images for some time now, the refresh rate remained very low thereby limiting its scope of usability. The other issue with a very slow refresh rate is that it makes it impossible to write on the PineNote - negating one of the devices main features and selling points. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video DOOM on PineNote - via Danct12\nBut this is about to change. Recent breakthroughs by Smaeul and Maximilian, as well as other developers, bring us much closer to realising the dream of a fully open and well supported e-paper device. The PineNote can now use the A2 waveform which allows for fast transitions between black and white on e-paper; for those who like me are uneducated in this matter, you can think of it as a very fast local refresh rate, for instance just under the tip of the stylus. But that’s not all. Smaeul has also been working on a global refresh mode (entire panel, not local), which only refreshes ‘damaged’, or altered, sections rather than the entirety of the panel. As he explained, this leads to a dramatic reduction in memory bandwidth requirements. Referring to the video I am embedding below, Smaeul writes: “ Global refreshes with diff mode turned off for clarity (\u0026hellip;) I\u0026rsquo;ve configured the window registers so only the damaged portion of the screen (the flashing part) gets read from DRAM. (\u0026hellip;) We could add some heuristic to switch to a global refresh if a large enough portion of the screen is damaged. Since global refreshes only use 2 buffers instead of 3, this would minimize the peak memory bandwidth_”._\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video showcasing the A2 waveform in Smaeul\u0026rsquo;s driver - video shared in chat\nI also had an opportunity to talk to Maximilian, who showcased his build of Debian bookworm/sid with GNOME running under Wayland. This build runs a slightly modified version of Smaeul’s e-paper ebc driver with tweaks to the system configuration. Maximilian explained that his tweaks reduce artifacts and auto refresh, and force the driver to only output black and white pixels so that the A2 waveform can be used without dealing with colors and text rendering issues. The result? Smooth pen input and, from what I can tell, near flawless writing tested for example in a default and unchanged LibreOffice, which ships with Debian. As you can see in the video from the user hrdl below, writing in a regular Linux on the PineNote (in Xournal++ with just two minor patches and configuration tweaks) does not only look viable but downright great. It is one thing to describe it and a different thing to see it, so below I am attaching the example video of handwriting using an EMR Pen in a pretty standard Linux installation on the PineNote.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video What the PineNote now needs is a default Linux distribution and user interface to ship. The OS doesn’t need to be polished, nor flawless, all it needs to be Linux with all the device’s core capabilities enabled. Marek and I will be talking to PineNote developers and partner projects in the coming weeks in a hope to work out an arrangement so that the PineNote can finally ship with Linux preinstalled. Here is the take-away from this section: we (and by \u0026lsquo;we\u0026rsquo;, I actually mean the devoted developers) are getting closer to realising the dream of an e-paper device running regular Linux, with a regular desktop, which allows you to do regular computational things on the device.\nThat is all for this month’s update, catch you all in July!\n","permalink":"/2022/06/28/june-update-who-likes-risc-v/","tags":["pinebook-pro","pinephone","pinephone-pro","risc-v"],"title":"June Update: Who likes RISC-V?"},{"categories":["news","quartz64"],"contents":"ARM SBCs have been around for a few years now. They were made popular and accessible mostly by the RaspberryPi released in 2012.\nI\u0026rsquo;ve been enjoying building countless projects around these boards : web servers, home-automation, camera recording, IM bots,…\nA new trend has recently appeared in the SBC world : the PCIe slot! The RaspberryPi 4 Compute Module exposes it via the IO board, and the Pine64 RockPro64 is equipped with a PCIe 4x open-ended slot directly on the board.\nI haven\u0026rsquo;t had the opportunity to get hold of one of these boards, but I\u0026rsquo;m lucky enough to have a Quartz64 model A on hands. The Quartz64 is based on the Rockchip RK3566 running @1.8Ghz. My board is equipped with 8GB of RAM. It also has Gigabit ethernet, 1 SATA connector, USB3, and of course, the PCIe port.\nI experimented a bit with the PCIe interface by testing a couple of PCIe boards I had on hands at that time : the SATA controller board from Pine64 and an Intel 4x GBe board : they worked out of the box! Awesome, isn\u0026rsquo;t it?\n4xGbe PCIe card installed on the Quartz64\n2 SSDs connected to the Quartz64 via the SATA controller boad\nI had an idea in the back of my mind : create a DIY low-power NAS based on a cheap SBC that can handle more than 2 drives (up to 6, preferably) without using USB. And it looks like this project is now completely possible! So… Let\u0026rsquo;s do it!\nThe prototype The first prototype was very rough : everything was laying on my desk, with all the wires dangling around. It was a bit messy, but it allowed me to check that the drives were working correctly.\nWhen I ensured that everything was working as expected, I bought a few more items : the SATA controller with 6 ports and an enclosure for 6 2.5\u0026quot; SATA drives.\nHow to properly power an SBC and 6 drives? This question haunted me for some time.\nFor now, the SBC is powered by a 12V power brick via a barrel connector. And the disks are powered by the board using those specific power cables by Pine64. If I understand correctly, this cable is connected to the 12V power supply from the board and embeds voltage s to provide 12V and 5V/3.3V to the disks.\nIt works fine with 2 drives but… I want 6 of them! And I\u0026rsquo;m not sure those voltage regulators would support more than 2 drives.\nI could probably find a PSU that outputs 12V, 5V and 3.3V, build the wires and adaptors by finding the correct connectors, etc. Buuut… That looked too difficult for me, and I doubt the result would have been elegant and safe.\nThe solution I implemented is the PicoPSU. It\u0026rsquo;s a very small yet powerful DC-DC converter that is designed to power embedded PCs. It comes in the forms of small PBC mounted on a standard ATX connector that fits directly in the ATX connector of any standard motherboard.\nIt looks good but the Quartz64 does not have that ATX power connector! Fortunately, I remember a blog post on CNX-Soft about an ATX breakout board. It has the ATX power connector on 1 side, a screw terminal for +12V, -12V, 5V and 3.3V on the other side, and a switch and a few fuses in between.\nThe following picture shows the PicoPSU on the top and the ATX breakout board in the middle. The PicoPSU receives 12V from the black and white connector on the left. The Quartz64 is powered by the red and white wires on the bottom, and the SSDs by the classic red/yellow/black wires on the right.\nAn SBC in an ATX case This setup with 2 SSDs ran for a few months. But it\u0026rsquo;s still messy and fragile. I wanted to clean that up!\nSo I wanted to find a box to secure the whole build and hide all those wires… without breaking the bank!\nThe only compatible case I could find was the NAS enclosure from Pine64 but it supports only 2 drives.\nI quickly figured I would need to tinker something based on a case that was not specifically designed to be compatible with the Quartz64! But hey! While I can do a lot of things with my 10 fingers on a keyboard, I\u0026rsquo;m not that good with my 2 hands and a screwdriver!\nSo I did not want to buy a shiny new case that I would certainly break while trying to drill a hole or something!\nLuckily, I found an old (Pentium4-era) desktop computer that was going to be thrown to the landfill. I thought I could salvage the case and probably recycle the insides of that prehistoric computer!\nSo I emptied the case, cut the I/O shield with my Dremel and cut a thin aluminum plate so that it would fit in the case.\nAnd I then drilled holes to fit the ATX breakout board, the PicoPSU and the Quartz64 with the SATA board.\nWhile it\u0026rsquo;s not finished yet, I\u0026rsquo;m already pretty happy with the result so far! I\u0026rsquo;m planning on improving this build with an I/O shield for USB and Ethernet, connect the power button, the LEDs,… but that\u0026rsquo;s a project for another day!\nThe hardware Here are more details about the hardware I used in this build:\nThe Quartz64 ARM SBC from Pine64 : the brain of the system A 6x SATAIII controller board based on the ASM1166 chipset A PicoPSU-150-XT DC-DC power supply. 150W is probably way too much, it has 2 SATA power connectors, so that will make my setup easier. An Icy Dock ExpressCage MB326SP-B. This nice enclosure fits in a 5.25\u0026quot; bay and supports up to 6x 2.5\u0026quot; SATA drives. 6 SATA SSDs An ATX break-out board, SATA cables, various connectors and wires I had on hands or bought for cheap on various web shops. Linux distro I installed the latest dev image from ManjaroARM on the eMMC flash module. Note that the support for the Quartz64 and the RK3566 is still in early development stage. So I expect a few issues and bugs, and I also expect for the support to improve very quickly in the next weeks and months!\nAs the PCIe controller is not supported yet in the default kernel (linux-rc, currently version 5.18-rc7), I switch to the kernel linux-quartz64 (version 5.17.0). Full support of PCIe should be added in kernel 5.19. Stay tuned :)\nPCIe and DTS The proof that the support for the board is still pretty new is that at first, the filesystem on the SSD would corrupt as soon as I copied big files (\u0026gt; 4GB) on the disk. This was apparently caused by an issue with the memory allocation for the SATA driver. With the help of the folks in the chat room dedicated to the Quartz64, we were able to patch the DTS/DTB files to work around this issue. Those patches are not applied yet in newer manjaro images so I\u0026rsquo;ll provide these patches here. Use them at your own risks, of course! Neither I or the original author of those patches will be responsible for any issue that could occur when using those files!\n0001-arm64-dts-rockchip-enable-rk356x-proper-msi-support-1.patch 0001-arm64-dts-rockchip-rk356x-move-to-lower-pcie-address-2.patch 0001-arm64-dts-rockchip-fix-rk356x-pcie-large-address-spa.patch Linux 5.19 should bring support for the PCIe controller on the Quartz64 and applying those patches won\u0026rsquo;t be needed anymore!\nRaid : ZFS? ZFS is very trendy right now, and I wanted to do some experiments with this very popular filesystem. Unfortunately, ZFS is not included in the Linux kernel. So you have to build the kernel module manually. ArchLinux and Manjaro provide the package in the AUR so the installation was not that difficult.\nIt worked quite well until ManjaroARM updated the kernel to a newer version that is not yet supported by the ZFS driver. As I said earlier, the support for the Quartz64 is under heavy development, and Manjaro integrates bleeding edge versions of the kernel to provide the most up-to-date experience.\nThe Linux kernel is so bleeding edge that the ZFS module was not updated yet when I installed the new kernel on my setup, and it broke my shiny new ZFS filesystem.\nI didn\u0026rsquo;t want my system to break randomly each time I ran pacman -Syu so… I decided ZFS was not the best fit for me right now.\nBTRFS in mirror mode on 2 SSDs At the beginning, I could find a good deal for only 2 SSDs. So after ZFS, I decided to test BTRFS. RAID 5 and 6 are not yet production-ready with BTRFS, but RAID 0 and 1 are completely supported. I\u0026rsquo;ve finally settled to format them in mirror mode (RAID 1).\nThis array will host the services I\u0026rsquo;ll run on this service : docker containers, my Matrix home-server and probably many others in the future!\nmdraid RAID-5 for 4 SSDs I finally found a good deal for the 4 remaining SSDs, and I decided to use mdraid RAID 5 for these 4 drives.\nI\u0026rsquo;ll use this array as data storage.\nWhat does it look like? A screenshot is better than a thousand words!\nBenchmarks As soon as I showcased my project, a lot of people asked about the performances of this setup. So here are a few numbers!\nYou\u0026rsquo;ll quickly notice that those are not the performances you were hoping for. But in my opinion, knowing that everything worked nearly out of the box, those numbers are already quite great. And we\u0026rsquo;ll probably see those performances increase as the support for the board and the CPU improves in the near future!\nBenchmarks with dd Read directly from the block device: # dd if=/dev/sdc of=/dev/null bs=4M status=progress iflag=direct 15497953280 bytes (15 GB, 14 GiB) copied, 44 s, 352 MB/s^C 3728+0 records in 3727+0 records out 15632171008 bytes (16 GB, 15 GiB) copied, 44.4116 s, 352 MB/s Read from the BTRFS mirror array: # dd if=bigfile.raw of=/dev/null bs=4M status=progress iflag=direct 31914983424 bytes (32 GB, 30 GiB) copied, 154 s, 207 MB/s 7609+1 records in 7609+1 records out 31914983424 bytes (32 GB, 30 GiB) copied, 154.001 s, 207 MB/s Write to the BTRFS mirror array: # dd if=/dev/zero of=./temp_zero bs=4M status=progress oflag=direct 6236930048 bytes (6.2 GB, 5.8 GiB) copied, 61 s, 102 MB/s^C 1497+0 records in 1497+0 records out 6278873088 bytes (6.3 GB, 5.8 GiB) copied, 61.5351 s, 102 MB/s Read from the mdraid RAID 5 array: # dd if=bigfile.raw of=/dev/null bs=4M status=progress iflag=direct 31822184448 bytes (32 GB, 30 GiB) copied, 85 s, 374 MB/s 7609+1 records in 7609+1 records out 31914983424 bytes (32 GB, 30 GiB) copied, 85.2706 s, 374 MB/s write to the mdraid RAID 5 array: # dd if=/dev/zero of=./temp_zero bs=4M status=progress oflag=direct 4123000832 bytes (4.1 GB, 3.8 GiB) copied, 40 s, 103 MB/s^C 983+0 records in 983+0 records out 4123000832 bytes (4.1 GB, 3.8 GiB) copied, 40.0076 s, 103 MB/s Samba benchmarks Read from the BTRFS mirror array : 70Mio/s Write to the BTRFS mirror array : 90Mio/s Read from the mdraid RAID 5 array : 60Mio/s Write to the mdraid RAID 5 array : 90Mio/s Power Consumption 8W (idle) - 12W (load)\nNext steps On the hardware side, I would like to improve the wiring and cabling by adding an I/O shield for the ethernet and USB ports, add a power button, a reset button, a power led, and maybe paint the case to make it prettier.\nI would also like to see how we could improve the performances of the system. There are probably configuration issues or bottlenecks that could be improved.\nAnd finally, I would like to put this new server and NAS to good use! It\u0026rsquo;s already running my Matrix home-server. I would also like to store music and movies for my home theater and probably many other things in the future!\n","permalink":"/2022/06/03/my-diy-low-power-6-ssd-nas-based-on-the-quartz64-arm-board/","tags":["nas","quartz64"],"title":"My DIY low-power 6 SSD NAS based on the Quartz64 ARM board"},{"categories":null,"contents":" Download audio\nIn this Episode Brian and Justin explore the world of Open Source Android and Open Source Nuclear Reactors. And then some real stuff.\nLinks and topics discussed:\nhttps://tuxphones.com/howto-linux-as-second-wireless-display-for-linux/\nhttps://lists.sr.ht/~mil/sxmo-announce/%3C3FV34P1BUD8B6.34I97X4SKLKHH%40yellow-orcess.my.domain%3E\nhttps://github.com/biktorgj/pinephone_modem_sdk/releases/tag/0.6.5\nhttps://gitlab.com/postmarketOS/pmaports/-/merge_requests/3123\nhttps://github.com/MadameMalady/Manjaro-Waydroid-Manager\nhttps://porkyofthepine.org/blog/rice_sxmo_sway.html\nhttps://github.com/Raezroth/Linux-ARM-Gaming-Chroot\nhttps://github.com/MadameMalady/PinePhone-Pro-Manjaro-Maui-Shell-Installer-MMSI/releases\nhttps://github.com/dreemurrs-embedded/Pine64-Arch/releases/tag/20220502\nhttps://xnux.eu/log/#067\nhttps://dylanvanassche.be/blog/2022/bluetooth-hfp-linux-mobile/\nhttps://www.cnx-software.com/2022/03/26/capyloon-mobile-web-based-os-works-on-pinephone-pro-librem-5-pixel-3a/\nMusic from Bensound.com and Zed (@itismezed)\nhttps://soundcould.com/kevinflynnretro\nEdited by Zed\n","permalink":"/podcast/s02e08/","tags":null,"title":"S02E08: So Porky Is Now a Developer..."},{"categories":["news","pinebook-pro","pinebuds","pinephone-pro","pinetime"],"contents":"\nHello everyone! This month we’re announcing production of the Pinebook Pro resuming and introduction of Quartz64 model-B. I had an opportunity to meet with TL earlier this month, and got some ear-on time with the Pinebuds, so I dedicated a section to my early impressions from the time spent with the prototype. This update also brings news of SOQuartz Blade hostboard production, camera enablement on the PinePhone Pro and a guest write-up by dsimic addressing issues some users have been experiencing with their PinePhone (Pro) keyboards. There is truly a lot to get to this month, so let’s get into 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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank JF, Dylan, dsimic, Alex (clover), Brian (33YN2), and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis\nTL;DR\nHousekeeping Update moved to 28th of the month PINE64 in-person meeting Pinebook donation to school with kids in need of laptops We’re going though QuartzPro64 dev pre-orders PINE64 EU store; addressing delay Quartz64 \u0026amp; SOQuartz Model-B released - available for $60 SOQuartz Blade hostboard enters production Pinebook Pro Pinebook Pro is making a return after months of absence Expected in Pine Store late June early July Price stays the same as do most specs Highlight of selected new released for the Pinebook Pro PinePhone (Pro) PinePhone Pro restock expected late June early July PinePhone Pro camera enablement underway; look at first pictures Mobile Linux has gained support for Bluetooth HFP User-made script to easily install Waydroid PinePhone (Pro) keyboard Dsimic writes at length about PP KB issues identified by community and developers PineSound First PineSound dev boards allocated to devs PineBuds prototype early impressions PineTime InfiniTime development progress New InfiniTime fork exposes high frequency accelerometer data; fork receives a dedicated companion app Housekeeping Let me start by addressing the delay in the publication of this month’s community update. I’ve been really busy with the EU store this past month (more on this later) and ill for the better part of last week, which left me with very little spare time to do the write-up. As a result, for the first time in years, this update is published at the end of the month rather than on the 15th. I have given some thought to the situation and arrived at the conclusion that we’ll make the 28th of the month the new update publication date. So be on the lookout for the next update on June 28th. Consider this publication tentative - in two-three months I will reevaluate if changing the publication date to the end of the month was a good decision. Earlier this month we held our first in-person meeting since FOSDEM 2020. It was a small get-together, primarily aimed at discussing the PINE64 progress and PINE64 EU’s launch. It was a pleasure to see the people who make the cogs turn in person again. Thank you guys for paying me a visit! From the left: Lukasz, Gamiee, Lynx, TL and Ayufan\nAs some of you may recall, last year we made a pledge to donate Pinebooks to a charitable cause. It may come as a surprise but, as it turns out, donating hardware is actually not simple. One would think that it is a case of establishing a suitable cause and shipping the hardware, but nothing could be further from the truth. I’ll spare you the detail of the hurdles we had to overcome, but suffice to say finding a suitable recipient of the Pinebooks proved difficult. It is therefore with great pleasure that I bring you news that the first batch of Pinebooks have found a new home at a school where kids were in need of a laptop. I would like to take this opportunity to sincerely thank One Laptop Per Child (OLPC) for helping us in finding the right recipients of the laptops. May the Pinebooks serve their new owners well. We are looking forward to dispatching more Pinebooks to schools and charities this year\nWe have started going through developer pre-orders for the QuartzPro64. Allocation of the boards was initially delayed (in part due to my absence this past month), but with units now rolling off the factory floor we’ll move swiftly to issue first coupons. We have decided to send the boards out in smaller batches rather than all at one time - this will allow us to monitor progress and developer engagement. So if you filed an application to pick up a QuartzPro64 at a reduced developer price of $150, and won’t hear from us in the coming weeks then don’t worry, we’ll send out units for the months to come. At the same time, I’d like to remind you that the developer pre-orders are still open and that there is still time to file a coupon request. To learn more about QuartzPro64, I invite you to read the March community update where I detailed the board’s specs and explain our decision to subsidize the initial production run. Final QuartzPro64 PCBA\nLastly, I wish to address the PINE64 EU store’s launch delay. For the past month I’ve been cutting through layers upon layers of red tape - as it turns out, it is one thing to ship to the EU and a whole different thing to have permanent representation here. Since the situation is ongoing I will refrain from discussing the specifics at this time - what I will say is that I have now gotten a lawyer to help the process along. I hope that all outstanding legal paperwork can be sorted out in the next 2-3 weeks. As always, I’ll keep you posted on the PINE64 EU’s Twitter and Mastodon.\nQuartz64 \u0026amp; SOQuartz Earlier this month we released the Quartz64 model-B that sports the same RK3566 SOC found on its larger sibling as well as the SOQuartz compute module. Model-B comes in a familiar form factor and is available in a 4GB LPDDR4 RAM configuration for $60. While the model-A is geared more towards the development community, the model-B is meant as an easy-to-integrate option for industry partners and regular end-users. It does offer fewer IO options than the model-A but still manages to deliver a solid connectivity selection including 2x USB, 1x USB 3.0, and Gigabit Ethernet with PoE. You also get AC WiFi, Bluetooth 5.0, MIPI CSI, and DSI as well as a mini PCIe slot.\nQuartz64 model-B top and bottom\nI had the opportunity to try out the new board earlier this month, and I was very happy with both how well it is supported and with how well it performs. I tried Manjaro with Plasma and, to my surprise, the board performed really well running at my monitor’s native 4K resolution. Running the desktop under Wayland I would describe the experience as perfectly smooth; it is clear that Plasma Desktop benefits from Panfrost (FOSS GPU driver) acceleration at 4K resolution. I will go as far as to say that the model-B would be a great candidate for a 4K kiosk running a dedicated application or a browser-based app. As someone who enjoys playing retro games, I also think it would make for a great small emulation box. I hope we’ll get a LAKKA image for it eventually. I’ve spoken briefly with pgwipeout, one of the contributors who laid the software foundations for the Quartz64 device lineup, and asked about software progress. He told me that model-A and B, as well as the SOQuartz, have found their way into kernel 5.19. He added that the VOP2 driver was accepted into kernel 5.19 for HDMI output, but the DTS changes will first find their way into kernel 5.20. Now that we’ve got a solid software foundation in place, we need the board to offer a wide diversity of OS choices. Manjaro has done a great job, and their OS images are really well maintained, but I am well aware that many need a Debian-based or specialized (e.g. LAKKA) operating system to meet their requirements. So, If you are associated with a project who would like to support the Quartz64 devices, make sure to reach out to me or one of the admins. SOQuartz and SSD in the Blade hostboard\nThe SOQuartz compute module, which is based on the same hardware configuration as the model-A and model-B, has already been released for some time, and the first pre-release OS images for the module are now available. With the software taking shape fast, the SOQuartz host boards have entered production and should be available in the Pine store soon. Aside from the model-A type host board - which is basically an IO breakout board - we will soon also be offering the Blade hostboard. The Blade has been designed for clustering, and fits inside a standard 1U server rack: 12 or more Blade hostboards can fit into a single rack. I wrote at length about the Blade in November last year, but here is a short recap of the IO the Blade exposes: Gigabit Ethernet, a micro SD card slot, 1x USB 2.0 header, digital video output, 40x GPIO header, UART output, power barrel jack port and an M.2 PCIe slot for storage. The Blade has been designed to have IO located at the short leading edges, allowing for easy access and cable management as well as tight stacking inside a server rack. More information about the Blade and SOQuartz model-A host board will be coming soon. Pinebook Pro It has been a year since we were able to ship the Pinebook Pro, and ever since the last batch sold out we have been continually asked to bring it back. Today I am pleased to let you know that the Pinebook Pro has now re-entered production and will be available for purchase at some point in late June or early July. You will surely also be happy to learn that we are re-introducing the laptop at an unchanged price of $219 - the price it sold at prior to all the disasters which at first made production difficult and eventually impossible. The hardware remains largely unchanged from the 2021 version of the laptop. This includes the PCBs, keyboards, metal and plastic parts, etc. For those who haven\u0026rsquo;t followed the Pinebook Pro production hurdles over the past months: the main reason for production stalling was our inability to acquire reasonably priced and vendor-insured high-grade IPS panels. We did, however, already have much of the remaining parts lined up and ready to go. The new panel ought to deliver identical performance to those used previously. The only other change concerns the battery - the new battery is marginally smaller at 9600mAh, which is 400mAh less than in previous iterations.\nKali Linux on Pinebook Pro - image via Kali Linux\nI feel like it is a great time to pick up a Pinebook Pro - those of you looking to get a unit should know that the laptop is now a very mature platform, with many available OS options and a thriving community. It is also a platform that benefits from developments on the PinePhone Pro. I’ve seen an array of updates to Pinebook Pro OS images over the time that the laptop was unavailable - this includes the default Manjaro with Plasma desktop, which I’ve been using for the past 3 years on my laptop. The excellent postmarketOS with GNOME build has just received an update this past week; if you are partial to the GNOME desktop and enjoy Alpine Linux then you absolutely should give it a go. One other OS I’d like to mention is Kali Linux, since a popular application for the Pinebook Pro is using it as a dedicated pen-testing device. Kali Linux has recently made it possible to use the Kali kernel and u-boot instead of compiling your own, thereby greatly simplifying the installation process. Those of you seeking Debian and Fedora installations will be happy that these are also available. All OSes and documentation for the Pinebook Pro can be found on the Pinebook Pro documentation - information relevant to the new panel and battery will be uploaded to Pinebook Pro’s Wiki next month. Keep a lookout for more information on the Pinebook Pro in the coming weeks. PinePhone (Pro) [by Lukasz, Dylan and Brian] Before we get into the software news, I want to quickly touch upon PinePhone Pro’s availability. The PinePhone Pro is currently out of stock, but it won’t be long before more units arrive. The next batch is expected to land in the Pine Store sometime in late June or early July and should last for months to come. I will notify the community as soon as more units become available, so keep an eye on our social media and news channels. Let’s dive into software. Earlier this month a breakthrough was achieved in getting the cameras to work on the PinePhone Pro. Megi brought up support for the rear (main) camera, forward-ported the BSP driver for the front-facing selfie camera, and integrated it into the kernel tree along with device tree changes. For those of you interested in the details, details of the process can be found in his recent blog post which I obviously encourage you to read. As he writes, this is just the beginning of the journey, and developers will now need to integrate userspace support of the cameras in applications such as Megapixels. For the time being, to snap a photo you’ll need to open CLI and jump through numerous hoops. While it may take some time before capturing photos on the Pro will become convenient, the recent development brings us one step closer to reaching parity with the original PinePhone’s functionality. I can only hope that implementing Megi’s work into userspace applications will proceed at a good pace and won’t get bogged down with any major obstacles. I am including pictures from both the front and rear camera below; please note that both images are completely raw without any post-processing applied. I’m not an expert in mobile photography, but those pictures look pretty darn good to me. Picture taken using PinePhone Pro’s selfie (front) camera - image from Megi\nPicture taken using PinePhone Pro\u0026rsquo;s main (rear) camera - image from Megi\nDylan:\nMobile Linux has gained support for Bluetooth HFP (Hands-Free Profile) - a Bluetooth specification that allows you to make hands-free phone calls. This specification has already existed for a decade and is supported by all kinds of phones. I submitted a series of patches to PulseAudio to support Bluetooth HFP in ModemManager, which will allow you to manage calls through\nBluetooth HFP devices. This includes accepting, rejecting, hanging up calls. Some devices can also display the current network operator, service status, phone battery level, etc. This is also implemented by this patch series. postmarketOS users will soon benefit from my patches. A detailed explanation can be found on my blog.\nSee Enhanced Bluetooth HFP support in ModemManager \u0026amp; PulseAudio.\nBluetooth HFP demo - via Dylan\nBrian:\nLastly, but certainly useful to many of you who may not know or have struggled to setup Waydroid, a community member - Cara (FOSSsingularity) - has recently created an easy to use script for configuring and managing Waydroid. This script includes the ability to set up a custom rom to run in the container, and the ability to enable or disable gapps support. In a similar vein, the same contributor has also created a Maui Shell installer script for Manjaro, for those of you who wish to test out the Alpha of the new shell without having to manually configure it to launch. Awesome stuff!\nPinePhone (Pro) Keyboard [by dsimic] [NB: _This is a community blog and we are always delighted to host content by members of the community, especially when said written material is submitted by noteworthy contributors. We never alter or edit written material submitted to us (unless necessary - e.g. for clarity, typos, composition, structure, etc). Please consider the following as an opinion piece, which does not necessarily reflect the position of the Pine Store Ltd. or PINE64 community’s management team.]\n_\nLet\u0026rsquo;s face it, there are a few well-known issues with the PinePhone (Pro) Keyboard Add-On (PPKB) that have been identified since its launch. Even more importantly, there have also been a few complaints about the lack of official transparency and openness regarding these issues, which this write-up will attempt to remedy by providing a long-overdue official summary of the issues. Perhaps this write-up will be a bit long and filled with more technical stuff than is usual in the community updates, but in this case, there is no point in oversimplifying things or in beating around the bush. If you do not have the time to read this section in its entirety, here is a TL;DR - when the PPKB is attached to a PinePhone (Pro), please treat the phone\u0026rsquo;s USB port as if it did not exist.\nIn this write-up I\u0026rsquo;ll refer to both the PinePhone and the PinePhone Pro collectively as ‘the phone’, where the same applies to both variants, for the sake of brevity. Using ‘PPKB’ as the abbreviation for ‘PinePhone (Pro) Keyboard Add-On’ has already been established. It is also good to point out that the PPKB is internally made of two independent parts, the charging part, and the keyboard part. As visible in the PPKB schematic, the former is based on the IP5209 which charges the PPKB battery and provides the 5V boost output to power the phone, and the latter is based on the EM85F684A, powered independently by the phone.\nAlright, let\u0026rsquo;s get into more details. There are three primary issues with the charging part of the PPKB, which were both identified very early during the development of the PPKB, but the issues were partially dismissed because the limited testing that was possible during the development was unable to prove that the issues are real and capable of inflicting actual damage to the equipment. However, putting the PPKB into the hands of so many people effectively resulted in lots of testing, with wildly different environments, which unfortunately resulted in two issues surfacing as real issues and capable of damaging the equipment. An unfortunate side issue is that, for a yet unknown reason, no printed manuals were included in the retail cardboard boxes in the first PPKB batch, which caused unnecessary confusion among the owners.\nThe first issue with the charging part of the PPKB comes from the fact that the PPKB is connected to the phone in a way that makes it act as some kind of an invisible USB charger that is plugged into the phone\u0026rsquo;s USB port all the time when the PPKB is attached. Of course, it does not look like that from the outside, but that is the way one of the pogo pins found under the back cover of the phone is wired internally. That pogo pin is electrically the same as the 5 V pins found inside the phone\u0026rsquo;s USB Type-C port, to which an external USB charger connects to. Thus, connecting a USB charger to the phone\u0026rsquo;s USB port while the PPKB is attached is effectively the same as splicing two USB chargers together, which usually does not result in anything bad due to the construction of the chargers, but it also sometimes causes damage to the chargers (let\u0026rsquo;s remember once again that the PPKB is an invisible charger). Unfortunately, a few PPKB owners had to discover all that on their own, and we had a few PPKBs releasing the magic smoke.\nTo be fair, it is possible to turn the PPKB\u0026rsquo;s 5 V boost output off, both in software that talks to the battery charging IC inside the PPKB and by using the physical button on the PPKB itself, but it was concluded empirically that the inactive status of the charging part of the PPKB achieved that way simply cannot be trusted, because the charging part may become active again unexpectedly. Moreover, nothing gets electrically disconnected that way, which still ends up in a USB charger plugged into the phone\u0026rsquo;s USB port feeding power into the charging part of the PPKB, which in this case may be even worse for the health of the charging part, because there is now no power coming out of the PPKB to \u0026ldquo;fight against\u0026rdquo; the power coming in from the USB charger. Not good at all.\nTo sum it up so far, you must never use the phone\u0026rsquo;s USB port for charging when a PPKB is attached to it. As we know, the official PPKB manual already says that a USB charger must never be connected to the phone\u0026rsquo;s USB port when the PPKB is hanging off its back, so it has all been about old news so far, but with the additional, hopefully helpful, descriptions of how it all works together.\nThe second issue with the charging part of the PPKB comes from the fact that the phone, among other things, acts as a 5V source for the bus-powered USB devices connected to its USB port; in the USB Power Delivery (PD) lingo, the phone can act as a PD power source. The 5V boost regulator inside the phone, which provides that 5 V power source when needed, may also be seen as another invisible USB \u0026ldquo;charger\u0026rdquo; connected to the same point where the PPKB and the external USB charger are connected \u0026ndash; the 5 V pins found inside the phone\u0026rsquo;s USB Type-C port. Of course, appropriate mechanisms exist to prevent the phone\u0026rsquo;s 5 V power source from becoming turned on while a USB charger or a self-powered USB device is plugged into the phone\u0026rsquo;s USB port, but those mechanisms are unfortunately not perfect, and the existence of the PPKB as another power source throws all that off.\nIn particular, the internal 5 V power source in the PinePhone is controlled at the hardware level by the closed-source firmware blob that runs inside the ANX7688, which handles some of the functions of the PinePhone\u0026rsquo;s USB Type-C port. As a result, relying on the ANX7688 firmware to keep the PinePhone\u0026rsquo;s internal 5 V power source turned off is simply impossible when a bus-powered USB device is plugged into the PinePhone\u0026rsquo;s USB port. Moreover, it\u0026rsquo;s possible for the battery voltage to become present as the power supply for bus-powered USB devices, instead of the boosted 5 V voltage, which may actually put the circuitry inside the PinePhone at even higher risk of damage. On the bright side, the internal 5 V power source is controlled entirely by software in the BraveHeart revision of the PinePhone, which puts BraveHeart owners in a much better position, but I\u0026rsquo;m not aware of the required software support actually being available. As the final result, we can effectively again have two ‘invisible USB chargers’ spliced together when a bus-powered USB device is plugged into the PinePhone\u0026rsquo;s USB port. Again, not good at all.\nWhen it comes to the PinePhone Pro\u0026rsquo;s internal 5 V power source, things are luckily a bit better. The internal 5 V power source is controlled by the RK818 PMIC, which according to its datasheet should react properly whenever externally supplied 5 V is detected, turning the PinePhone Pro\u0026rsquo;s internal 5 V power source off. Though, some issues may still be present, such as not knowing for sure what happens when the PPKB\u0026rsquo;s boost output is turned off while a bus-powered USB device is plugged into the PinePhone Pro\u0026rsquo;s USB port, at which point the internal 5 V power source should become turned on automatically, possibly glitching the connected USB device and effectively starting to feed power into the PPKB, etc. In a few words, things can quickly become exactly the same as having two \u0026ldquo;invisible USB chargers\u0026rdquo; spliced together, as described above. None of this has been tested or confirmed yet, which means that the PinePhone Pro is getting the same treatment as the PinePhone in this regard, at least for now. Not good, once again.\nThe third issue with the charging part of the PPKB, which is completely independent of the first two issues, is that a bus-powered USB device plugged into the phone\u0026rsquo;s USB port can draw power directly from the PPKB\u0026rsquo;s 5V boost output, with no additional current limiting in place. As a result, a misbehaving USB device can end up drawing up to 2.4 A from the PPKB, through the phone\u0026rsquo;s USB port, regardless of the actual power negotiation that took place. In general, this should not cause any permanent damage to the phone or the PPKB, because they were both designed to handle such currents during regular charging. However, it may end up causing damage to a misbehaving bus-powered USB device, because it may not be designed to withstand up to 12 W going into it in case of some failure. To be fair, this scenario with a misbehaving USB device that draws a lot of power and burns itself down should be very rare, at least in theory. These are hopefully not the famous last words. :)\nFinally, to sum it all up, it is not only that the phone\u0026rsquo;s USB port must not be used for charging, but it must also not be used to connect bus-powered USB devices. To put it differently, when a PPKB is attached to your phone, please treat the phone\u0026rsquo;s USB port as if it did not exist at all.\nI will also create a couple of new pages in the PINE64 Wiki that will provide even more details about the PPKB issues, together with the relevant excerpts from the PinePhone and PinePhone Pro schematics, etc. Those Wiki pages will provide further explanations, so please feel free to check them out once they become available.\nPineSound The first PineSound development boards have already been allocated, and I got some hands-on time with both the board and PineBuds prototype earlier this month. There isn’t much I can say about the PineSound dev board that I haven’t already said in last month’s update, but I wanted to share my experience with the PineBuds. Consider this a first look. Before I get into it, I want to make it clear that it will take (yet undetermined) time before the buds become available, and much will change between now and then. I also won’t write about the feel of the plastic, since this prototype was CNCd (yeah, I didn’t know you can CNC plastic either), and in all likelihood, the final version will end up feeling nothing like this. The buds themselves are nice, really small, and light. They are not the smallest buds I’ve ever seen, but they are certainly among the smaller ones I’ve tried (and I’ve tried quite a few - I’m a bit of a connoisseur). The default tuning sounds good, offering a pleasant V-shaped curve. I wanted to underline this because the V sound signature isn’t something I particularly enjoy. Obviously, a major draw of the PineBuds is that you’ll be able to flash the internal EQ with any sound signature, and I’m certain someone will create a ‘flat’ sound signature for the Buds. We’ve gone through a few iterations of renders, trying to figure out how we want the PineBuds to look. I am sharing some ideas below - there is no guarantee they will look like this, these are just some ideas.\nPineBuds concept renders\nThe carrying case has some way to go before it reaches a production-ready status. The prototype case we’ve shown last month has no charging or battery LED status indicators, and it is something we’ll want to change. We’ve also decided on a sliding rather than a hinged mechanism for the lid. At present the mechanism leaves much to be desired. Obviously, it is still very early and this unit is just a proof of concept, but even at this stage, it\u0026rsquo;s clear that refining will be needed to deliver a good experience of opening and closing the case. We also haven’t zeroed in on a suitable battery to use inside the case - obviously, the bigger the battery we can squeeze in the better. As I mentioned, the current prototype was CNC milled, so I can’t speak to the feel of the shell, but the shape and size of the case are good if a little bit large. I think that the larger size of the case will be justified by the battery capacity. That\u0026rsquo;s all I have for the time being - as new prototypes are created I’ll make sure to update you on this project’s progress. PineTime The InfiniTime team is still working steadily on the project! A few improvements have already been merged since the last release. I won’t go into much detail as they are not released yet, but you can see the overview of what has already been done and what we are working on for the next version by going to the next milestone page.\nFeatures and fixes already merged for the next release of InfiniTime\nAmong other things, we are actively working on leveraging the external flash memory of the watch to store pictures and fonts. This will allow us to free up quite a lot of space in the memory of the PineTime. I’ve recently done a few performance tests of various implementations. I took a lot of inspiration from PineTimeLite. In this fork of InfiniTime, Joaquim has already done a lot of experimentation with loading resources from this external memory, and I hope that we’ll be able to achieve similar results in InfiniTime soon!\nITD, the InfiniTime daemon and GUI application written in Go has recently released a new version 0.0.5. This new version adds a new whitelist feature that is very useful when you have multiple PineTimes laying on your desk. It also implements all new functionalities from InfiniTime like the filesystem and weather APIs. Even if those APIs are not usable by the end-users yet, their integrations in companion apps make the lives of the developers easier. For example, I use the filesystem functionality quite extensively right now to implement the resource loading from the external flash memory!\nFS API integration in ITD\nStarGate01, who has already contributed to InfiniTime, has created a new fork of InfiniTime specifically designed to expose high-frequency data from the accelerometer. They also built a companion app to display this data in real time. Those projects will certainly be useful to developers who want to develop advanced algorithms and signal processing based on the PineTime accelerometer!\nHigh frequency data from PineTime\u0026rsquo;s accelerometer\nThat is all for this month. Remember, next community update is scheduled for June 28th. See you then!\n","permalink":"/2022/05/31/may-update-worth-the-wait/","tags":["pinebook-pro","pinephone-keyboard","pinephone-pro","pinesound","pinetime","quartz64","soquartz"],"title":"May Update: Worth The Wait"},{"categories":null,"contents":" Download audio\nIn this episode Brian and Justin talk in length about the newly announced PINE64 line of audio products.\nLinks and topics discussed:\nhttps://forum.sailfishos.org/t/release-notes-vanha-rauma-4-4-0/10656 https://github.com/Tow-Boot/Tow-Boot/releases/tag/release-2021.10-004 https://blog.mobian.org/posts/2022/03/30/universal-images/ https://github.com/Biktorgj/pinephone_modem_sdk/releases/tag/0.6.1 https://www.youtube.com/watch?v=m_XRdHec154 https://www.youtube.com/watch?v=PQiHOjIUTiE https://box86.org/2022/03/box86-box64-vs-qemu-vs-fex-vs-rosetta2/ https://www.phoronix.com/scan.php?page=news_item\u0026px=Box86-0.2.6-Box64-0.1.8 https://nxos.org/maui/maui-shell-alpha-release/ https://www.pine64.org/2022/04/15/april-update-no-more-unicorns/ Music from Bensound.com and Zed (@itismezed), https://soundcloud.com/kevinflynnretro\nEdited by Zed\nYugen – Emotional Ethnic Music by Keys of Moon | https://soundcloud.com/keysofmoon - Attribution 4.0 International (CC BY 4.0), https://creativecommons.org/licenses/by/4.0/\nMusic promoted by https://www.chosic.com/free-music/all/\n","permalink":"/podcast/s02e07/","tags":null,"title":"S02E07: Pine in a field, on a mountain, over a river"},{"categories":["news","pinedio","pinephone","pinephone-pro","pinepower","pinesound","pinetime"],"contents":"\nThis month’s update is packed to the brink with news: the product team is negotiating restarting Pinebook Pro production, QuartzPro64 will be heavily subsidized and developer sign-ups are now open, we’re introducing the PineSound project, and PinePower power supplies will be making a return to the Pine Store soon. I cannot recall the last time I had so many positive things to report on, so let\u0026rsquo;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 the PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank JF, Peter (LinMob), Alex (clover), Brian (33YN2), and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of the April community update\nTL;DR Housekeeping Go back and read the April fool’s post prior to continuing with the update Quarterly community Q\u0026amp;A April 15th, join in and ask your question PINE64 EU launches on May 10th Product team negotiates resuming Pinebook Pro production QuartzPro64 QuartzPro64 is now in production Dev order system open for those who want to get their hands on the device early We subsidize the QuartzPro64 for devs - selling it for $150 Dev boards do not have CE or FCC PineSound Introducing the PineSound community driven project PineSound dev board soon to be allocated to devs; will be available broadly at a later point in time PineBuds are the first product based on the dev board; prototype exists and works PineBuds include many common high-end wireless earphone features and allow end-users to flash their own firmware easily PinePhone (Pro) Next production run on the PinePhone (Pro) keyboard on the way Many improvements to keyboard driver, particularly with respect to charging postmarketOS and Mobian decide to use Tow-boot Elementary OS is considering porting to the PinePhone Pro (and Pinebook Pro?) PinePhone Pro Wiki documentation gets a major overhaul thanks to multiple contributors Linuxphoneapps.org quietly launched late March; works well when using Firefox on the PinePhone Many tweaks and improvements are landing PlasmaMobile in the coming weeks and moths PineTime InfiniTime 1.9 launched with many improvements, fixes and a new watchface. InfiniSim, now a part of the project, and in sync with InfiniTime InfiniTime merge requests discussed InfiniLink for iOS is no longer maintained - someone willing to step up and maintain the project? PineDio Improvements to the USB and PinePhone PineDio LoRa case drivers InfiniTime ported to PineDio STACK - a good starting point for further exploration Documentation underway PinePower PinePower desktop and mobile will be making a return to the store shortly PinePower desktop improvement: USB grounding as requested by many Pinecil users Portable PinePower receives a substantial redesign meant to help with staying put in North American main socket Housekeeping In case you missed it, we ran a little April fool’s spoof at the beginning of the month. I must admit that I am not a fan of the April fool’s tradition and we, as a project, haven’t really dabbled in pranks before. So, then, why did we publish the post and why am I mentioning it now? - because, as with any good joke, the April fools post contained an element of truth to it. More on this later on the update, seriously. It is time for the second community quarterly Q\u0026amp;A. If you’re reading this on the day of the community update’s publication, then make sure to stick around and join in later today/ tonight on Youtube, Discord or PeerTube. We’ll be going live at 19:00 GMT/ 12:00 PT. The point of the Q\u0026amp;A is for us to take questions live and answer them then and there. I’ll be taking questions live from the chats - you have a choice of Discord, IRC and Telegram. From previous experience I know that the chat will more than likely turn into a wall of text in a matter of minutes - I therefore ask that you ‘at’ me (@lukasz) before writing your question, otherwise I will more than likely miss it. I will likely bring in developers to answer questions too - make sure to ping people you direct questions to. Once the Q\u0026amp;A is over we\u0026rsquo;ll head over to one of the casual voice chats and hang out for the rest of the evening. I hope to see you there.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video In the event you missed it, we held the first quarterly Q\u0026amp;A we held in January\nWe have upgraded the main PINE64 and PinePhone Matrix channels. Both of them previously ran version 1 of the Matrix protocol and this caused us all sorts of headaches, including moderators randomly losing their powers and people who left being forced back into the home server. Needless to say, an upgrade had to happen sooner or later. The new rooms now run version 6 of the Matrix protocol which will alleviate all the aforementioned problems. An unfortunate side-effect of the upgrade is that everyone who was part of the original channels will need to manually rejoin. An invite link is present in the original groups. As some of you noticed, there was no new PineTalk episode last month. Those involved in the production of the podcast were busy with real-life things and simply didn’t get the chance to record. I’ve spoken to Brian and Justin and they both confirmed that a new episode will be coming later this month. If you haven’t done so yet, make sure to subscribe to PineTalk’s RSS feed. The product team is in advanced talks with a factory regarding resuming production of the Pinebook Pro. As I’ve promised countless times in the past, I’ll keep you updated on the progress regarding restarting the laptop’s production. I’m told the team is etching closer to strike a deal and that the production circumstances will require some alterations to parts of the hardware - keep an eye on our social media and news channels in the coming weeks.\nYes, there will be bundles\nLastly, I am thrilled to let you know that PINE64 EU will be going live on May 10, 2022. By the time you read this, the Polish state should already have listed PINE64 EU as a registered company and all required paperwork should be in place to start sales. The website and logistics are also all ready to go. However, I am still awaiting approval from the debit/credit card payment gate, which takes a long time. I am also waiting for the hardware itself. With less than a month to go, I’ll be posting frequent updates on the store’s Twitter and the newly set-up Telegram news channel. I don’t foresee any issues at this stage, but should any problems arise (I am thinking about customs in particular) I will make sure to communicate it publicly via social media. Telegram and Twitter is where you will find all future communication from PINE64 EU.\nQuartzPro64 Last month we outlined our plans for the next generation of Pro-grade PINE64 hardware - the QuartzPro64. In case you missed the original announcement, the QuartzPro64 is a powerful development board featuring an 8 core SoC which comes paired with 16GB of RAM and 64GB of expandable eMMC flash storage as well as an impressive array of IO options. I’m not going to repeat the entire spec list below since it was covered in detail last month - if this is news to you, then I suggest you go back and read the March update and pick up reading this section after.\nUnpopulated PCB of the QuartzPro64\nToday I am happy to let you know that the QuartzPro64 will soon be available for order via our developer pre-order system. To get your hands on a unit you’ll need to fill in a short questionnaire, similar to the one PinePhone Pro developers submitted at the end of 2021. This will help us determine if you’re the right person to receive the hardware prior to software running on the new platform. Conversely, it will help keep these development boards out of the hands of end-users and application developers. More on this in a bit later. So, then, if you are a developer with an interest in the RK3588 platform, and wish to get an early start on a board that exposes nearly all of the SoC\u0026rsquo;s available IO, then please make sure to head over to the developer sign-up page to register your interest. Now let me level with you - the BOM of the QuartzPro64 is north of $300. The price is dictated not only by the (rather pricey) SoC, RAM, and eMMC flash but also by the exhaustive list of the exposed IO. As I’ve explained in last month’s post, we didn’t want to compromise on the IO due to the assumed target audience; it is hard to debug and ultimately enable a feature if said feature isn’t physically present on the PCB. But at the same time, we do have a vested interest in a good uptake of the board among the development community. I’d go as far as to say that we hope for the QuartzPro64 to become the go-to board for RK3588 development. A decision has therefore been made to heavily subsidize QuartzPro64 so that the price of the board doesn’t prevent people who wish to be a part of the development process from getting one. After some deliberation, we decided to sell QuartzPro64 for $150 to developers who file an application. Needless to say, we hope to see many applications in the coming days.\nRK3588 block diagram\nPlease note that it will take us time to review all applications and issue approvals. Once the first set of candidates has been determined we’ll then send out purchase coupons. Coupons are valid for a period of two days, then they expire. From previous experiences with the PinePhone Pro and the PineNote, I expect that we’ll send out 2-3 rounds of coupons - so if you do not receive one initially then don’t fret, there is a chance you’ll be included in the second or third round of coupon dispatches. Application rejections will be issued after all applications are reviewed and all QuartzPro64 boards have been allocated. Before I wrap this section up, I’d like to make it clear that these boards will not be FCC or CE certified. While, technically speaking, single board computers aren’t required to have such certifications in most places, we always make sure to certify our boards when moving into production. However, QuartzPro64 boards aren’t currently produced in a quantity that would warrant us to start such a certification process. They are meant for the development community and should be viewed as prototype hardware. In some countries you need to register with your local authority to receive uncertified prototypes, elsewhere there is no such registration requirement, and yet in other countries you outright cannot receive uncertified electronics equipment; please make sure to check your local regulatory guidelines prior to submitting your application. PineSound At the end of last year, in the December community update, I teased the launch of (\u0026hellip;) a cool small project into our lineup. Let me first clarify what ‘small’ means in this context: a small project is limited in scope and completely community-driven. Examples of such existing PINE64 projects include the Pinecil and PineTime“. As I’ve mentioned in the Housekeeping section, the April fool’s post from earlier this month did in fact include some real information. While we won’t be making plush unicorns with mics sticking out their heads anytime soon, we have been prototyping a set of end-user flashable wireless earbuds. But let me backup a bit. Today we’re introducing the PineSound board; a development platform for earbuds and a digital audio player, utilizing the Bestechnic BES2300 Bluetooth 5.0 audio chip. We will initially distribute the PineSound dev boards to developers whom we know are particularly interested in non-Linux projects such as this. In time, however, the PineSound dev board will be made available to anyone interested in developing on the platform or even using it in some DIY audio project. The board features 2x coaxial \u0026amp; optical input (left) and output (right), a standard 3.5mm headphone jack, 4.4mm and 2.5mm balanced jacks, an SMA connector, USB-C as well as touch and LCD ports. The PineSound dev board (v1.0)\nBefore we get into the specifics of the PineSound project I want to explain its placement in our lineup, and talk a bit about the importance of the development community’s interest in the hardware. The approach we’ll be taking is, in a sense, very similar to how we handled the PineTime and the Pinecil. This means that the success will largely depend on whether a community grows around the platform. As we did with PineTime, we will allow the development community to help set the course of the PineSound project. All important decisions, such as moving from development to production, the production itself, opening sales, etc, will be coordinated and discussed with the community. We recognize that working closely with developers and the community is critical in projects such as this - while the PineTime and Pinecil are now hallmarks of PINE64, we need to acknowledge that the PineCube has been largely a failure. The general lack of interest in the PineCube can, at least in some part, be ascribed to a failure on our part to facilitate community building around the device. We’ve learned from this experience and have done everything on our end to assure that PineSound as a whole is a success from the get-go. See, they\u0026rsquo;re real. Seriously.\nThe first device to be introduced based on the PineSound dev board will be the PineBuds wireless Bluetooth earbuds. What I wrote in the April fool’s post about the buds is accurate - they offer features found on high-end in-ear headphones, such as ambient and environment noise cancellation, and long battery life. They have 6 microphones total, 3 on each bud, as well as touch-based input situated on the external side of each bud. We designed the cradle which houses the earphones so that custom user-created firmware can be flashed. The cradle has built-in UART used for firmware flashing, which is automatically exposed when it is connected via USB to a computer. There will be a wide variety of things developers and (eventually) end-users will be able to do with the earbuds - flash custom sound signatures, determine touch controls, adjust resonance to fit the user’s ear canal resonance and even turn the PineBuds into hearing aids. The last application is particularly interesting - the BES2300 is one of just a handful of chips considered for use in ‘over the counter hearing aids’ by various regulatory bodies. A peak inside - picture of an early engineering prototype\nBen (Ralim), probably best known as the creator of IronOS, has had his hands on the prototype for some time. Here is what he had to say when I spoke to him earlier this week: “I think of the buds as (\u0026hellip;) [a] good working device, that the community can hack on and tweak, [while of] the Dev board as the experimentation setup for exploring this chip and finding out just how powerful it is. [T]here are some binary blobs in the firmware around Bluetooth [and] some for voice assistants (but I don\u0026rsquo;t know if we would ship them). But it was in a compilable and runnable state with fairly complete hardware drivers. I see it a bit like the bl602, where we have a working SDK with some blobs, but the hardware is very good for hacking on. The main MCU so far is quite powerful and battery efficient. Flashing is easy over a UART serial port [too].” It is clear that the hardware has a lot of potential from both developers’ and end-users \u0026rsquo; perspectives, and I hope that the project garners some interest from the community as a whole. More information about the PineSound will follow next month, so keep a lookout for news.\nPinePhone (Pro) [by Lukasz, Peter \u0026amp; Brian] A new production run of the PinePhone keyboard case is now underway and should be available soon. The keyboard case has proven to be a very popular accessory, and therefore the initial production run sold out quicker than other optional back cases currently offered for the PinePhone and the PinePhone Pro. We expect that the new batch will last us 2-3 months, so if you’ve been eagerly waiting to get your hands on a unit then there should be no problem in obtaining one. On the subject of the keyboard case, the IP5XXX_POWER (keyboard power) driver by the developer Samuel Holland has now been upstreamed. A handful of fixes are also coming (or have already arrived, depending on distribution) to improve battery operation and charging of the PinePhone (Pro) when paired with the keyboard case. When charging, the new algorithm will strive to charge the phone’s internal battery as fast as possible first, and only then start charging the keyboard case. During operation, the keyboard case will only start charging the phone’s internal battery when it is nearly depleted. It will try to maintain a 20% charge of the phone’s internal battery. The new driver will also provide a set of triggers to notify the user via the phone\u0026rsquo;s LEDs about the status of both batteries. I suggest you read the developer Megi’s blog post to learn all the details. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Keyboard case production - a short video from the factory floor\nPinePhone and PinePhone Pro with keyboard case charging - picture by Megi\nIn other news, postmarketOS and Mobian have made the decision to use Tow-boot as opposed to u-boot with their distributions. In the case of the PinePhone Pro, this means that end-users will be required to flash Tow-boot on their devices prior to using these OSes. I wrote at length about Tow-boot in last month’s update if you wish to learn more about it and its application on both the PinePhone and the PinePhone Pro. The Mobian team writes: “by letting users install the bootloader themselves, either on the SPI flash (\u0026hellip;) or the eMMC’s boot partitions (\u0026hellip;), we can stop embedding our own copy of the bootloader. (\u0026hellip;) Both new and existing users should install Tow-Boot or a similar system to provide updates to their boot firmware. [Using Tow-boot] will be required on new installs using images generated after 2022-04-02.” elementary OS on the PinePhone Pro? yes please!\nOn the subject of mobile Linux OSes, many of you will be happy to learn that elementaryOS are exploring the possibility of bringing their OS to the Arm platform and, in the future, also the small screen of Linux smartphones. The development is currently targeting the PinePhone Pro - a sample unit was delivered to Danielle from elementaryOS earlier this month. It is worth noting that the team already has some experience with the RK3399 SoC and our platform as they have - in the past - attempted to bring elementaryOS to the Pinebook Pro. As a side-note, elementaryOS on the Pinebook Pro is something I’d still very much like to see - fingers crossed. I spoke to Danielle this week and she had this to say: “Mobile Linux is coming and the time is now to be planning and developing. PinePhone Pro is a really compelling developer platform and I’m excited to start working with a whole new world of open source apps and operating system.” I wish Danielle and elementaryOS contributors the best of luck with this endeavor; we’ll be keeping our fingers crossed for yet another mobile Linux OS option to see the light of day. In other news, the documentation of the PinePhone Pro on the PINE64 Wiki was growing steadily in the last couple of days thanks to the relentless work of multiple community members. In summary, the \u0026ldquo;State of the Software\u0026rsquo;\u0026rsquo; section on top of the PinePhone Pro article now received a graphical overview table of the current software stability and functionality, which makes it easier for users to get an overview of the overall software state without having to collect the information from multiple locations such as bug trackers. The overview also contains notes regarding bugs or details, which might impact the functionality of a specific feature. Of course, this enumeration does not make a claim to be complete in any way but should ease the search for related information considerably. The table can be found under https://wiki.pine64.org/wiki/PinePhone_Pro#State_of_the_software.\nA functionality matrix has been added to the PinePhone Pro Wiki section\nThe software section of the PinePhone Pro article, which was extended gradually, was rewritten as well to bring a more coherent information section with all relevant information. The section should now be considerably easier to read, especially in the parts, which were causing confusion in the previous instructions. Aside from a large number of improvements, the section now also received a dedicated troubleshooting subsection and numerous new information. The section can be found under https://wiki.pine64.org/wiki/PinePhone_Pro#Software. As it is often asked where bugs can be reported and how projects can be supported, new articles regarding where to report bugs and how to contribute to projects were started as well, which will be gradually improved and extended over time. In this context it can be noted that all community projects are happy about any form of contribution. Knowledge of coding is not required, instead there are various ways to contribute to projects, for example with designs, ideas, translations, documentation, through hardware or with creative work, or by simply being a positive member of the community. On this note, I want to thank everyone for their unremitting help. Without your contributions, the community would simply not be what it is today.\nThere is one more noteworthy piece of information concerning documentation of mobile Linux software: LinuxPhoneApps.org finally quietly launched at the end of March. It lists all the apps that were (and still are) listed on LINMOBapps. The list is presented in a way that is more friendly to PinePhone\u0026rsquo;s Firefox browser, preventing it from asking whether it should kill the script that slows things down. The list now has more apps, with more being added slowly but steadily. Note that not all apps are packaged for your distribution nor are they all to be considered feature-complete. If you want to follow, join or help out the further development of the site, check out the LinuxPhoneApps FAQ.\nOn a final note, Plasma Mobile will be seeing several bug fixes, lots of optimizations, and a few new features in the coming releases. The mobile data toggle has been fixed so that the setting is remembered across reboots, a virtual keyboard toggle has been added to the quicksettings panel, the ability to reorder the quicksettings menu has been added, there have been various animation fixes, shrink and grow animations have been added to the shell buttons and homescreen, work has been done to start implementation of custom homescreens (though this is not yet finished), the media widget in the quicksettings panel now supports multiple video/audio sources by swiping left or right, the lockscreen has received a new notification widget, the APN settings menu received several UI fixes, the panel’s opacity logic has been fixed, and spacebar has received several fixes to its UI alongside some bug fixes. Most notably work is planned for a lockscreen shell overlay that would handle incoming calls and alarms, and give users a nice fullscreen overlay to interact with, although this is still in the planning stages.\nPineTime [by JF] The InfiniTime team released a new version of the open-source firmware for the PineTime at the beginning of April. The first new feature you\u0026rsquo;ll notice in InfiniTime 1.9 \u0026ldquo;Limeberry\u0026rdquo; is the new Terminal watchface! This original watchface displays the date, time, battery level, steps, heart rate, and BLE status as if they were printed on a console terminal. It\u0026rsquo;ll more than likely please the geeks among us.\nThe new terminal watchface looks great\nA new feature allowing to disable the BLE connectivity was also added. This feature was requested by many users as it saves a bit of battery and increases the privacy of the PineTime. When BLE is enabled, the watch continuously broadcasts \u0026ldquo;advertising\u0026rdquo; messages allowing devices to detect and connect to it. It also allows some kind of tracking; when BLE is disabled, those messages are not sent and the watch is then \u0026ldquo;invisible\u0026rdquo; to anyone trying to detect it.\nThose of you who use the heart rate sensor will be happy to know that we improved the accuracy of measurements of the heart rate sensor. Thanks to the wasp-os team for their help with this! The heart rate monitor now displays more sensible and reliable values - it has been tested and approved by Nico!\nThe heart rate monitor is now much more accurate\nInfiniSim, the InfiniTime simulator, is now also supported by the team and integrated into the CI. Each time a new PR is created and merged, the CI checks that the change builds in InfiniTime and also in the simulator. This will help maintain both projects in sync and ensure we don\u0026rsquo;t break anything when changing something in either InfiniTime or InfiniSim. The new InfiniTime release also brings many improvements to notifications (call notifications won\u0026rsquo;t vibrate forever when receiving a call) and to the Alarm app. The 12-hour time format is now better supported. You can read the whole release note and download the firmware on the project page.\nInfiniTime receives a lot of contributions from many users and developers, and I\u0026rsquo;m really thankful for that! Unfortunately, for various reasons we cannot merge and integrate each and every one of these features as soon as they are published by their author. One of those reasons is memory usage. As you may know, the PineTime is based on a small-ish MCU with 64KB of RAM memory and 512KB of flash memory. From my experience, this is a very comfortable amount of memory when compared to many other microcontrollers. But still, we have to be very cautious to not hit the memory limit if we want to be able to add new features and improvements in the future. That said, here\u0026rsquo;s a highlight of some of those cool features I hope we\u0026rsquo;ll be able to merge at some point in time. A feature that is often requested is the support for other languages and alphabets. New languages require a lot of memory for storing new fonts, which we cannot afford right now. But InfiniTime is completely ready to handle these, and yehoshuapw proves it by maintaining a fork of InfiniTime that integrates Hebrew. A new version of this fork was released a very short time after the release of InfiniTime 1.9. Kudos to the maintainer!\nWatchfaces also need quite a lot of memory. The Infineat watchface is one of them - it is a very neat and well-designed watchface that uses the Pine64 logo to display the battery level!\nInfineat looks really neat!\nI also like this QR Code application, which displays 4 QR codes specified by the user via a BLE API. Those QR codes can be links to web pages, online accounts, and even vaccination certificates for COVID-19! Very cool.\nAn example QR code displayed on the PineTime\nLast piece of information for this month - I\u0026rsquo;ve learned that InfiniLink, the companion app for iOS is not maintained anymore. Here\u0026rsquo;s the message its author, xan-m, wrote in the last commit ‘Added localizations and goodbye message’:\n“I\u0026rsquo;m sorry to say that this will be the last update to InfiniLink. I started a new job a couple of months ago and no longer have the spare time to continue development of this project. If anyone is interested in taking over, please let me know and I can transfer everything over. Thank you for all of your support and suggestions along the way!”\nI would like to thank xan-m for their work on InfiniLink. Xan-m created the whole app from scratch and quickly proved that a companion app for iOS is definitely needed in the community and the PineTime ecosystem. Let\u0026rsquo;s wish xan-m good luck in their new job, and I hope we\u0026rsquo;ll meet again soon! So, who will take over the project to maintain the presence of our beloved open smart watch in the iOS world?\nPineDio [by JF] Lup and I are still actively working on the PineDio STACK with a double goal: check that the hardware is working as expected and to document our development environments. Lup is really good at documenting his experiments. He\u0026rsquo;s currently writing an extensive article about running the Apache NuttX RTOS on the PineDio STACK which I encourage you to read.\nOn my end, I\u0026rsquo;m working on porting InfiniTime to the STACK. This is quite easy as the display and touch panel are exactly the same as the one on the PineTime. I think InfiniTime will be a nice starting point to experiment with the STACK hardware: the RISC-V MCU (BL604), the LoRa radio, the GPS and secure module on the add-on board, etc. As you can see on the video below, the display driver is now functional and even works a bit faster than on the PineTime. It can go even faster when more memory is dedicated to the display driver.\nSee the video here.\nInfiniTime now runs on the PineDio STACK - here\u0026rsquo;s a quick comparison to the PineTime\nI\u0026rsquo;ve also upgraded my driver for the PineDio LoRa USB adapter and LoRa PinePhone back case. Some changes were needed to support kernels \u0026gt; 5.10. Note that the driver for the CH341 chip (USB to SPI converter) also needs an update to support kernel 5.16. I forked the driver to apply the changes until they eventually become approved in the upstream repo.\nThe PineDio USB dongle\nPinePower Both the desktop and portable PinePower PSUs will be making a return to the Pine Store next month. I am glad to report that since the original units were in stock some improvements have been made to both designs. The desktop unit, often ordered alongside the Pinecil, has now grounding on the USB ports. This is a feature that many users have asked for. Otherwise the desktop power supply looks and functions just as the original iteration. The portable 65W PinePower has seen a more substantial physical redesign - the PSU itself has been shrunk slightly, making it overall more compact, and the overall physical dimensions have been altered along with internal weight distribution. The new design solves a problem that people in the US, using those tiny rectangular prongs for the mains socket; the original portable PinePower would sometimes not stay in place due to its weight distribution when plugged into a wall socket, while the new design does. I’m sure that this is a welcome redesign. The USB ports on the desktop PinePower are now grounded\nThat’s all for this month, I’ll catch you all in May.\n","permalink":"/2022/04/15/april-update-no-more-unicorns/","tags":["pinephone-keyboard","pinepower","pinesound","quartzpro64"],"title":"April update: no more unicorns"},{"categories":["news","pinebuds","pinepod"],"contents":"\nPeople are frequently asking us to create more mainstream devices such as an inkjet printer or a microwave, and for a good reason. Complex open devices such as the PinePhone are both exciting and fun, but they also aren’t for everyone. Or putting it inversely, they are for a very particular group of people. In contrast, simpler devices in our lineup such as the PineTime, PinePower, and Pinecil have all garnered a broader user base. Heck, I’d go as far as to say that the Pinecil is now a downright mainstream device with Amazon USA officially recommending it to those seeking a soldering iron. So then - we thought to ourselves - it\u0026rsquo;s time to go mainstream. See? told you \u0026hellip;\nSeeking inspiration and scrolling through lists of popular home appliances, game consoles, battery-operated toys, etc, we frequently thought to ourselves: “we could probably do it equally well, if not better, and make it open”. We figured that since we’re already going after Apple with the PinePhone, we could also take a shot at the growing internet-enabled toy market. We therefore started development on a brand new lineup of unicorn toys with microphones, with the capacity to function as an always-online child-friendly voice assistant, and optional Home Assistant integration. With this new project already underway, two even more potentially lucrative market segments presented themselves: portable digital audio players and wireless earbuds. So, with no further ado, let me introduce you to PineBuds and the PinePod. The buds offer features found on high-end in-ear headphones, such as ambient and environment noise cancellation (utilizing 3 microphones in each bud), touch-based input, and a long battery life. All in a small form factor too, of course. Unlike existing products, however, we’ve designed the PineBuds with development and open firmware in mind. You’ll be able to plug the buds cradle into your computer via USB and tailor the firmware to your own needs - changing the internal EQ settings and customizing the touch input being the obvious examples. The cradle has in-built UART, which is used for flashing firmware. I\u0026rsquo;m told that with the right tweaks, the PineBuds may actually work as over-the-counter hearing aids too. Seriously. The chipset inside the PineBuds is so versatile that it will also serve as the basis for the PinePod digital audio player. We haven’t yet gotten the design of the PinePod down, but I’ll browse Apple’s store for inspiration later today. Regardless, I just feel an open stand-alone music player belongs in 2022.\nYou’ll be pleased to know that the SDK has already been compiled and proven to work, and that a development board is incoming. Unfortunately, we had already started manufacturing the unicorn toys before deciding to switch focus. As a result, the first batch of the dev boards will arrive back from the factory next week following a slight delay, after intensive unicorn toy disassembly operations. More details about the PineBuds and the PinePod will be coming in this month’s update, and pre-orders for the development boards will be opening soon via our pre-order system. Seriously.\nOh, I almost forgot, those are the actual buds in the header picture at the top of the page, and they are already functional. The unicorn is real too. Here\u0026rsquo;s the dev board - I\u0026rsquo;m serious\n","permalink":"/2022/04/01/introducing-the-pinebuds-and-pinepod-seriously/","tags":["pinebuds","pinepod"],"title":"Introducing the PineBuds and PinePod. Seriously."},{"categories":["news","pinephone","pinephone-pro","quartz64","quartzpro64"],"contents":"\nThis month we’re announcing the QuartzPro64 - a new single-board computer based on Rockchip’s powerful RK3588 SoC. This is our first Pro-grade SBC since the introduction of the ROCKPRo64, and I believe it to be a worthy successor to the much revered Pro lineup. I am also happy to let you know that the Quartz64 model-B will be arriving at the Pine Store in the coming weeks, with all of its features supported in the most recent Manjaro OS image. We’ve got much to discuss, let\u0026rsquo;s get into 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 on Matrix, the announcements channel in Discord as well as our Twitter and Mastodon.\nI’d like to thank JF, Alex (clover), Brian (33YN2), Danct12 and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Synopsis of this month\u0026rsquo;s update in video format\nTL;DR\nHousekeeping A new episode of PineTalk is out - listen to the hosts’ suggestions for future PINE64 devices Improvements to the chats have been made over the last few weeks which should significantly reduce spam PineTab and Pinebook Pro will sadly remain unavailable for a while longer PINE64 EU is on track for May 1st launch QuartzPro64 We’re introducing the QuartzPro64 based on RK3588 - available in the coming weeks to developers It will cost North of $300 and will initially only be available to developers via a coupon system With development in mind, the QuartzPro64 exposes as much I/O as possible Equipped with 16GB RAM and 64GB of expandable eMMC Will only be available publicly when BSP releases are in good shape PinePhone (Pro) Shipment has resumed post-CNY and most if not all of the backlog has been cleared Suspend now works on the PinePhone Pro - u-boot fix applied by pgwipeout Keyboard case battery capacity reporting in UI is coming - already available in Manjaro’s OS images Tow-Boot 4th release adds official support for the PinePhone Pro adding mobile-specific elements SailfishOS and Nemo mobile get GPS support on the PinePhone and work began to start integrating the fingerprint reader back case The original PinePhone can be used to run LibreELEC - and it runs well including 1080p@60 video playback Quartz64 Quartz64 model-B is coming soon; 4GB version of the board is launching first Manjaro OS image for model-B if feature-complete, including full support for desktop and UI usage and all I/O present on the board More improvements for the RK3566 and thus also the Quartz64 and derivative devices is coming soon PineTime Active development is ongoing with many merge requests awaiting InfiniSim is an InfiniTime desktop simulator, which can be run on a PinePhone (Pro) that allows for easy InfiniTime development and testing InfiniSim is now a part of InifiniTime organization on GitHub Housekeeping I’m starting with a last-minute edit to this month\u0026rsquo;s update; Shenzhen, the city where PINE64 electronics are manufactured, has just imposed a strict COVID19 testing procedure and issued a ‘stay at home’ order until March 20th. This is due to an increase in COVID19 cases in the region. It remains to be seen how, if at all, this situation will impact our production schedule. However, for the time being, the shipping staff have been sent home, which means that only Hong Kong-based shipments (PinePhone, PinePhone Pro, and PineNote) will be sent out this and the coming week. Once I have an update on the situation I’ll make sure to relay it to the community via social media, on the forum, and in the chats.\nLeft: original text in Chinese // Right: auto-translation into English (\u0026lsquo;deep training\u0026rsquo; to be read as \u0026rsquo;thorough testing\u0026rsquo;)\nA new episode of the PineTalk is out. In this most recent entry to our community podcast, Justin and Brian discuss current PinePhone and PinePhone Pro developments, including Tow-boot and improvements to Mexapixels post-processing, as well as their own open-hardware ideas. While I do not think we’ll embark on a journey to create an open Google Glass-type device, as suggested by Brian, an open speaker with a personal assistant is actually a compelling idea (and one we discussed internally all the way back in 2020). A solid idea Justin and one perhaps worth visiting. Have a listen and let us know what you think about the show-hosts ideas for future hardware. The most recent episode can be found on PineTalk’s page; I also encourage you to subscribe to the podcast’s RSS feed. During my absence (more on this a bit later), Fire219 and Gamiee have done some solid improvements to our chat infrastructure. As I’ve reported late last year, and as many of you know from first-hand experience, spam in the chat has been an issue in recent months. A part of the problem is our cross-platform bridge: not all moderators have moderation privileges on all platforms, and those that do aren’t always there to react. Moreover, it is easier to get the moderators’ attention on some platforms than others. Earlier this year Fire219 and Gamiee laid the foundations for automatically removing spam and flagging potential malware. This reduced the number of incidents but hasn’t fully eliminated the issue. Now, however, we’ve got two new weapons at our disposal: cross-platform deletion and a sophisticated and trained AI bot with cross-platform deletion permissions. This means that even if the, rather sophisticated, bot fails to catch the spam any moderator can delete any spam message on any platform. Long story short, the spam problem should be less intrusive moving forward. I also promised you an update regarding PineTab and Pinebook Pro’s availability; as may recall, the product team has been scavenging around for a vendor who’d be willing to sell us a batch of LCD panels that are reasonably priced and come with a warranty (so that if they are faulty, do not meet the grading or fail during usage we can RMA them at the source). Unfortunately, as of today, the team has not found a vendor who would be willing to sell such a batch of panels. We’re well aware that it has been a long wait and that many of you are eager to see the production of these devices resumed, but I’m afraid we’ll all have to wait a little longer for the next production run. I’ll make sure to keep you updated if anything changes.\nPINE64 EU website is coming along\nLastly, I’ve been away these past few weeks laying the foundations for the PINE64 EU store. The last paperwork to get the EU store off the ground has now been filed, and I even have an office with (mostly) assembled IKEA office furniture. If all goes to plan, and the Polish state’s bureaucracy doesn’t take an eternity to process the application, then I hope to receive the first shipment of hardware sometime in late April. I don’t want to commit to a firm launch date at this stage, but I am currently aiming to have everything ready to go on May 1st. For those who want to learn more about the plans for the EU store, I invite you to read last month’s community update. I’ll be posting progress updates on PINE64 EU’s Twitter as we get closer to launch.\nQuartzPro64 In January I outlined our plans for the Rockchip RK3588 platform - a powerful Arm SoC with an impressive array of I/O options. Today I am pleased to introduce the QuartzPro64, our single board computer based on the RK3588. Let’s start with a quick recap: the RK3588 is an 8-core SoC, featuring 4x A55 and 4x A76 cores clocked at 1.8GHz and 2.4GHz respectively. This new SoC features the recently introduced Mali G610MC4 GPU with 4 cores, based on the Valhalla architecture. The SoC is capable of driving an 8K display and multiple 4K displays (4 total), has a 6TOPS NPU, an 8K 10-bit decoder as well as an 8K encoder. In our single board computer lineup, the RK3588 SoC is the successor to the very successful RK3399 used in the ROCKPro64. However, while this SoC is the successor to the RK3399, I want to make it clear that it will not be replacing it anytime soon. Thus, the QuartzPro64 will also not be replacing the ROCKPro64 for a very long time either. No picture due to the \u0026lsquo;stay at home\u0026rsquo; order affecting the product team, so this will have to suffice for now\nBefore I get into discussing the details of the QuartzPro64 I feel that I first need to make two things clear. Firstly, to purchase the board you will need to be a developer - at least initially. We’ll use the same coupon system we used for the first production runs of the PineNote and the PinePhone Pro once these devices launch. The software for the QuartzPro64 is yet to be developed and to say that the device is ‘not end-user ready’ would be an understatement; we both hope and expect to see BSP-based support in the initial months, with mainlining efforts running in parallel to the BSP development. Secondly, this will not be an inexpensive single-board computer. While we haven’t settled on a price-point yet, we expect it to cost North of $300. It will be sold either at cost or we will subsidize it. I think that it is necessary for me to mention the above up-front to align everyone\u0026rsquo;s expectations and tamper with unnecessary hype. Here’s the take-away: this is an amazing platform, but it will take time for it to mature.\nQuartzPro64 block diagram\nNow, with that out of the way, the QuartzPro64 will ship with 16GB of LPDDR4X RAM and 64GB of eMMC storage, which ought to be plenty for development and future implementation. With development in mind, we chose to expose as much of the available I/O as possible.\nHere’s the core I/O run-down:\nUSB-C (with video-alt mode) USB0-C (with debug mode) USB- 3.0 2x USB 2.0 HDMI in 2x HDMI out PCIe 3.0 2 SATA ports 2x Gigabit ethernet 2x SMA Antenna 2x MIPI DPHY 2x MPI DPCHY Fan header RTC battery holder An array of switches, including power on/off maskrom and system KEY eMMC socket SD card slot Power in via DC 12V The board is 180mm x 180mm in size, features heatsink mounting holes and system KEY buttons on the PCB. We hope this feature set will make QuartzPro64 interesting to its target audience - the development community. In anticipation of people asking about the general availability of the board; at present time it is unclear when the QuartzPro64 will be made available more broadly. This will depend on BSP and Mainline development. As most members of the community I too have high hopes for the QuartzPro64, and more broadly for the RK3588 platform, and I hope to see the SoC implemented in PINE64 devices in the far-off future. For the time being, we’ll be announcing QuartzPro64’s availability on our Telegram, Matrix and Discord announcement / news channels and on social media in the coming weeks. Stay tuned. PinePhone (Pro) Shipments of the PinePhone and PinePhone Pro have resumed following Chinese New Year’s end, with the first batches of both dispatched earlier this month. I haven’t followed the dispatch process in recent weeks, but I believe that much of the CNY backlog has now already been shipped (and in many cases delivered). On the subject of PinePhone and PinePhone Pro shipments - we’re working on improving the dispatch and delivery logistics. The end goal is to ship smaller batches but more frequently. For the majority of you, this means that your PinePhone and PinePhone Pro order will be delivered much quicker. We are currently trialing a service that would cut down the delivery time significantly - depending on how the trial period goes we may implement this shipping mode permanently, and even expand it to other devices. I’ll return to this topic once the trial period is over and a decision has been reached later in the year.\nPinePhone and PinePhone Pro most recent dispatch (I am intrigued by the red broom, you too?)\nOn the subject of software, there is much progress to report. Perhaps most importantly of all, suspend now works properly on the PinePhone Pro using u-boot. This enablement, or “fix” to be more accurate, comes courtesy of pgwipeout, who found a solution to this problem. I asked pgwipeout what the solution was, here is his response: “DMA transfers to SRAM always fail, no matter the source. The original fix handled disabling DMA on the SDMMC controller in SPL, but the SDHCI (eMMC) controller still was attempting DMA. I simply created a toggle for DMA in SPL for the SDHCI controller. Thus U-Boot on the eMMC now can load the SRAM bits without corrupting the data in-flight”. This fix has now found its way into Manjaro’s most recent OS image, which means you’ll be able to suspend/resume from suspend on the PinePhone Pro just like on the original PinePhone. While similar functionality can be achieved via Tow-boot (33YN2 writes more about this further down in this section), for those of you who specifically wish to use u-boot on their device I am glad to let you know that it is now a viable option. Battery capacity reporting for the keyboard case now works in the UI on the PinePhone and PinePhone Pro thanks to Megi. This means keyboard case battery levels can be read in Plasma Mobile, Phosh, and SXMO in the same way as the smartphone’s main battery. Prior to this, you needed to read the battery status from the command line, which obviously wasn’t the ideal way to keep track of battery usage. This enhancement has now made its way to Manjaro; if you’re on Arch then you can wait for kernel 5.17 or switch to linux-megi-rc package. I am confident that more distro will follow suit and implement this enablement in their OSes.\nKeyboard case\u0026rsquo;s battery charge displayed in Phosh - picture by Martijn Braam\nTow-Boot, a user-friendly version of U-Boot, has seen a release for the PinePhone and PinePhone Pro. The project page states that Tow-Boot aims to make the process of booting your device “boringly” normal and simple. The goal is to have a standardized booting experience across a variety of Arm-based devices, with no need for board or OS-specific differences in the builds. The most recent version of Tow-Boot introduced a smartphone UI, supporting both touch-input and small screens. In line with the project’s mantra, the project explains on their GitHub that this build of Tow-Boot should “(\u0026hellip;) enable users to live the dream of EBBR but on their phones.” Tow-boot also allows for a variety of additional functionality, similar to Jump Drive, exposing the smartphone’s internal eMMC memory in a way that it can be mounted and flashed from a PC. It also allows the user to select the bootable device (SD / eMMC) via a combination of button presses. To learn more, check out the project’s website.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video showcasing Tow-Boot installation to PinePhone Pro\u0026rsquo;s SPI flash - via Martijn Braam\nMegi has demoed LibreELEC running on the original PinePhone and outputting video to an external display (TV). The KODI UI is accelerated and runs smoothly as does the video playback, which appears to be rock solid. I’m told that 1080p video, including 50fps (and likely also 60fps), plays back really well on the original PinePhone running LibreELEC. There isn’t a dedicated PinePhone OS image but thankfully Megi has put together comprehensive instructions on how to make one yourself. He also included a guide detailing how to add a LibreELEC entry into his multi-OS p-boot image. I really enjoy the PinePhone being used in non-phone specific ways, and this is certainly a great showcase of the versatility that the device offers. Being a retro-gamer I already asked Megi for a guide on how to port LAKKA to the PinePhone. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video LibeELEC on the original PinePhone - original video by Megi\nLastly, an alternative X86/X86-64 emulator for ARM64 called Fex-EMU (Compared to Box86/64 it aims to be faster), has seen major improvements leading towards the goal of getting full Proton and Steam compatibility. It is great to see further work being done in this space. And although it’s being mentioned here, this obviously not only benefits the PinePhone, but any ARM64 device out there!\nQuartz64 Given QuartzPro64 introduction this month, I would be remiss not to mention all the development that Quartz64 has seen in recent months. I am also happy to announce that the Quartz64 model-B has now entered production and should become available in April (or earlier). Just to recap, the Quartz64 model-B features the same RK3566 SoC that is found on the model-A and on the PineNote. The SoC features 4x A55 cores and the Mali G52-2EE GPU. The model-B will be available in 2 configurations - with 4GB LPDDR4 and 8GBLPDDR4 RAM for $59.99 and $79.99 respectively. Unlike the model-A, model-B follows in the ROCK64’s steps and offers a small footprint. The small footprint means that some of the model-A I/O has been removed, but it retains the USB 3.0 alongside 2x USB 2.0 ports as well as DSI, CSI and RTC. This I/O selection is coupled with a full 40 GPIO pin connector and onboard Bluetooth and WiFi module. You can also outfit it with an eMMC module or a NVMe SSD (via PCIe 1x) located on the bottom of the PCB. It is a versatile little board, geared more towards end-users and industry than the bigger model-A.\nThe form factor of the Quartz64 model-B is, in all likelihood, very familiar to most of you\nThe model-B arrives at a good time; the software for the platform has matured to a point that distros and projects can develop fully fledged, functional OS images for the Quartz64. As per usual, Manjaro is the first to deliver an OS image with all core functionality enabled. The OS is built upon mainline-based kernel (5.17) and comes in five variations: minimal, with XFCE desktop, Plasma Desktop, GNOME and MATE desktops as well as Sway. The desktops (which support acceleration) are fully accelerated via the open source Panfrost GPU driver and I can attest that the desktop experience on the Quartz64 is excellent as far as SBCs are concerned. Latest pre-release Manjaro OS builds for the Quartz64 can be downloaded from here.\nQuartz64 model-A with 2x SATA SSDs attached and powered directly from the SBC - picture by JF via Twitter\nBut that\u0026rsquo;s not all. I’ve spoken to pgwipeout and he’s told me that many improvements to end-users\u0026rsquo; experience are in the works. He also updated me on the mainlining status of the various components: “Dwc3 support is pretty much ready to land in mainline, with the combophy queued up for 5.18. That also means pcie and sata are coming soon too. I\u0026rsquo;ve gotten DSI to work partially with the vop2 driver, but it still needs more work”. Moreover, the SPI controller has been confirmed to work and that SPL handling of recovery is now supported in mainline u-boot. While some I/O found on the model-A, such as the DSI, still needs some work all I/O on the model-B is already fully functional - “If you are including anything about model b, it\u0026rsquo;s pretty much good to go out of the box” pgwipeout told me. I believe that the release of the model-B will lead to a much broader adoption of the RK3566 and, in turn, a much wider range of OS choice. Indeed, I know this to be true, since we’ve already shipped a handful of dev kits to projects interested in supporting the Quartz-line of devices. PineTime [JF] Since last month, the InfiniTime community kept working on the features I wrote about in last month’s update, and some of the features being work on have already been merged in the *develop* branch of the project. These new features will be available in the next release of InfiniTime. Just to recap, the new features will include, among others, an airplane mode, the terminal watchface and improvements to the heart rate sensor management.\nThe community is very active and is creating pull-requests faster than we can possibly review, test and merge them. This is also true for the feature requests - there are currently 91 pending features requests. I’m really grateful to be surrounded by such an enthusiastic and understanding community whose people understand that we are working on the project in our spare time, and that the features will be done when someone will find the time to work on it.\nThis month, I’m happy to announce that InfiniSim, the InfiniTime simulator, is now its own dedicated project. NeroBurner, the author of InfiniSim, joined the team to develop and maintain the project under the InfiniTime organization on GitHub. We worked together to create the project and to ensure that all the InfiniTime code modifications needed were applied to support the simulator. InfiniSim allows everyone and anyone to run the whole InfiniTime UI on their computer. It even runs on the PinePhone Pro!\nSee the video here.\nInfiniSim running on the PinePhone Pro\nYou can use InfiniSim to easily design and debug new apps for InfiniTime from the confort of your powerful computer without even needing to flash it over (and over again) to the PineTime. I am also planning on using InfiniSim to take screenshots of the menus and apps of InfiniTime and add them to the project’s documentation. Take a look at this impressive mosaic!\nIf you are interested in using or contributing to InfiniSim, please check out the project page. It also provides useful information on how to build and run it.\nThat\u0026rsquo;s all for now, catch you next month!\n","permalink":"/2022/03/15/march-update-introducing-the-quartzpro64/","tags":["infinitime","pinephone","pinephone-pro","pinetime","quartz64","quartzpro64"],"title":"March Update: Introducing the QuartzPro64"},{"categories":null,"contents":" Download audio\nIn this episode Justin and Brian cover exciting community digs\nLinks and topics discussed:\nhttps://xnux.eu/log/#058 https://plasma-mobile.org/2022/02/09/plasma-mobile-gear-22-02/ https://lists.sr.ht/~mil/sxmo-announce/%3C20220205203322.w5idffuf3jiy7uxy%40worker.anaproy.lxd%3E https://postmarketos.org/blog/2022/02/11/v21.12.2-release/ https://github.com/dreemurrs-embedded/Pine64-Arch/releases https://github.com/Biktorgj/pinephone_modem_sdk/releases/tag/0.5.9 https://forum.pine64.org/showthread.php?tid=16094 https://blog.brixit.nl/pinephone-camera-pt5/ Music from Bensound.com and Zed (@itismezed), https://soundcloud.com/kevinflynnretro\nEdited by Zed\nYugen – Emotional Ethnic Music by Keys of Moon | https://soundcloud.com/keysofmoon - Attribution 4.0 International (CC BY 4.0), https://creativecommons.org/licenses/by/4.0/\nMusic promoted by https://www.chosic.com/free-music/all/\n","permalink":"/podcast/s02e06/","tags":null,"title":"S02E06: The Community has been ACTIVE!"},{"categories":["news"],"contents":"\nAs the Chinese New Year comes to an end and people return to work, production and shipping return to normal. More units of the PinePhone Explorer Edition, the PinePhone (Pro) keyboard case, the PinePhone Beta Edition and all the other popular products will be dispatching in the coming days. In the meantime, we bring you exciting news concerning PineNote development progress, LVFS and fwupd for the PinePhone and PinePhone Pro’s and instructions on how you can modify your Pinecil to increase its performance further (at your own risk, of course).\nLet\u0026rsquo;s get to it!\nYou 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.\nI’d like to thank JF, Alex (clover), Brian (33YN2), PizzaLovingNerd, biktorgj, Dylan Van Assche, William Starkey (ThanosTheTankEngine), Caleb and Samuel Holland (smaeul) for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of this month’s update\nTL;DR\nHousekeeping CNY comes to an end; give shipping and support a few days to get back to their routine First community Q\u0026amp;A was great fun; we’ll do better next time and include more chat protocols and potentially stream the event on multiple platforms Malware shared again - do not install software from unknown sources onto your device Beware of flood of counterfeit Pinecils PINE64 online store - PINE64 EU - opening in April/ May PinePhone (Pro) Many orders of PinePhone Pro \u0026amp; keyboard case over CNY - shipping will resume shortly New keyboard case driver allows to check battery levels and set PinePhone charge rate (Wattage) Plasma Mobile 5.24 released with multiple bug fixes, improvements and a new window / task switcher Chat with the machine: newest community firmware by biktorgj for the modem brings ability to issue commands to the modem via SMS and phone calls The community modem firmware can be now flashed and upgraded via fwupd thanks to work by Dylan PineNote Plasma Desktop now runs on the PineNote with a grayscale UI theme; porting of first applications has began – you are invited and encouraged to join and contribute to the effort postmarketOS has been ported to the PineNote; works well with a choice of Phosh or SXMO Although much work is yet needed, we’ve reached the point where all device hardware works (thanks to work by smaeul and pgwipeout); new driver exposes all e-paper modes and EMR pen pressure works in Linux Work yet needed to enable GPU acceleration on the e-paper display (works with other output modes) Pinecil New IronOS makes improvements to temperature regulation, so the Pinecil heats up faster and holds the temperature more precisely A new MacOS and Window update utility for the Pinecil is now available - allows safe and easy flashing Pinecil VBUS mod allows the device to use 24V input safely PineTime Work towards 1.9 release is ongoing; will include airplane mode, a new terminal-themed watchface and bug fixes Documentation is being reworked There is now a fully functional InfiniTime simulator that allows for easy experimentation and debugging on PC rather than hardware; JF is impressed by its capabilities PineDio Issues with early PineDio STACK prototypes have been identified and ironed out thanks to work by JF and Lup A new stock firmware for the STACK has been created and sent off to the product team; will not only allow end users a software platform to get started with the STACK but also allow product team to carry Q\u0026amp;A testing Housekeeping I’d like to start with a quick reminder that the Pine Store is just coming back to life following Chinese New Year. I am writing this a week prior to the update going live, and I have no insight into the support system, but from prior years experience I can make an educated guess that support has a hefty backlog to get through. I keep on getting pinged by people asking why their support tickets haven’t been answered, which leads me to think there are quite a few cases awaiting answers. I am asking you for patience - it will take time for support to work though the tickets, but they’ll get to yours eventually. Thank you for understanding. In case you missed it, we’ve held a live Q\u0026amp;A session on January 21. The session turned out to be a success with many people tuning in and asking questions. I was initially unsure how many people would be interested in participating, but it is clear to me now that there is a strong need for such a quarterly event in the community. I know that many questions remained unanswered and that more time for such as Q\u0026amp;A should be allocated next time. The next community Q\u0026amp;A is due in April, and we’ll make sure to do a better job planning the session out, making it more inclusive of other chat protocols and potentially also live-streaming it on multiple platforms. In short, we’ll make sure to be better prepared. You can watch the first community Q\u0026amp;A on Youtube, Peertube and Odysee. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video First quarterly community Q\u0026amp;A\nThroughout January we ran a survey asking people about their PinePhone use - now the results are in and published for anyone to view and dissect. Although ‘only’ 3079 people took part in the survey, I think that the results offer a glimpse into the most active portion of our community and offer an understanding of some overarching trends. The things that surprised me the most based on the responses are how many people daily drive their PinePhone, how popular SXMO is, and the relative indifference of a fourth of respondents to UI choice. If you haven’t done so yet, I suggest you head over and read the full survey report. More malware targeting the PinePhone (and other devices) was shared in our chat rooms as well as our partner project chats these past weeks. I will not dwell on this topic as an investigation is already ongoing - I would, however, like to remind everyone to never download any file or archive from unknown origins onto your device. I refer you back to the December community update for more details.\nAnother thing that transpired the past month is an avalanche of counterfeit Pinecil soldering irons on popular internet outlets and shopping sites. As with any device that receives a lot of traction, copycat products are bound to emerge eventually. This is particularly true for conceptually relatively simple devices, such as the Pinecil, which makes them easy to copy. What makes these fakes more than just copies of the original is that they bear our logo on the box and feature inscription identical to that on real Pinecils. This is obviously a trademark violation and an attempt at tricking customers. It is only recently that these counterfeit Pinecils have spread like wildfire across popular online shopping sites, and that\u0026rsquo;s why I’m addressing this issue publicly. There is a limit to how much I can say about this situation right now, but here’s a piece of important information - if you want to get an original Pinecil, make sure to look at the box (often present in online listings), since all Pinecils across all regions are sold in the same exact box as the one on the Pine Store. And no, we do not manufacture blue Pinecils. It looks like a Pinecil, it quacks like a Pinecil but its not a Pinecil\nLet us end this month’s housekeeping section on a positive note. As some of you have noticed, I’ve been around less these past two months. There are a few reasons for this, but the one of interest to you is that I am in the process of setting up an EU-based PINE64 store – called PINE64 EU. The store will offer EU-based support, mandatory compliance with EU warranty policies, repair services as well as various options, such as selection of pre-flashed OSes on the PinePhone and PinePhone Pro. This is something that has been in the pipeline for a long time but COVID and COVID-related restrictions, as well as a number of other unforeseen events, have forced me to shelve plans of opening a EU regional store until a more suitable time. That time has now come. To be clear, it will take some time for the store to become operational - I am currently planning on launching the business sometime in late April or in early May. I will, of course, let you know when the store launches. In the meantime, you can follow PINE64 EU’s progress reports on its Twitter account. Do you like the PINE64 EU logo?\nPinePhone (Pro) The PinePhone Explorer Edition (EE) launch has probably been the smoothest device roll-out we’ve had in years. We announced the PinePhone Pro in October, laid the roadmap for delivering Explorer Edition by January 2022 and made good on the promises. All phones ordered prior to January 18th have been dispatched on time and most, if not all, are now in the hands of their rightful owners. The sales and logistics teams did a mammoth job to make this happen and I’d like to publicly thank them for pulling off this feat so close to the start of the Chinese New Year. Good job, you’ve made a lot of people happy.\nPinePhone Pro picture from the production line - this is what you get in the box\nWe’ve also managed to get our initial shipment of the PinePhone (Pro) keyboard and add-on cases out the door just before the holidays. While the keyboard and add-on case’s development isn’t quite as much of a success story as that of the PinePhone Pro, I am still very happy to see the add-ons now in peoples hands. The keyboard has received further software improvements just recently and been merged into Megi’s kernel tree. The new driver, created by Samuel, makes it possible to check battery voltage that can be read from sysfs in the terminal. You can also set what Wattage your keyboard case delivers to the phone. This is particularly useful when pairing the keyboard with the PinePhone Pro, since the default charging Wattage value is too low to allow for sustained charging during use of the smartphone. People are really treating the PinePhone / Pro with the keyboard as a tiny computer - picture via terminal_junkie on Twitter\nMany PinePhone Pro, keyboard case as well as the other add-on orders have been placed over the Chinese New Year period. We’re aware many of you are eagerly anticipating your devices to ship, but please permit the product and shipping teams a few days to work through all the orders. As always you will be notified of your shipment via email. I also encourage you to check the shipping, stock and availability webpage once in a while. Plasma Mobile [by 33YN2]\nWith the release of Plasma 5.24 comes a new plasma mobile package! There\u0026rsquo;s been dozens of bug fixes and tons of UI improvements in this release. Most notably, the task switcher and the quick settings panel have both been completely revamped. Not only do they look much nicer, but they also run a lot better - and this applies to both the PinePhone Pro and the original PinePhone.\nThe app drawer has also received improvements so that it runs better and so that apps can finally be removed from it. And the mobile power settings menu has finally received fixes that now allow the phone to properly be set to not go into suspend when set to \u0026ldquo;Never\u0026rdquo;. Aside from that, you can expect a litany of bug fixes and UI improvements in the Plasma Mobile applications themselves, including a new application navigation design by Devin Lin. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video New swipe-based application / active window switcher - via KDE Plasma Mobile Currently in development is gesture based navigation support, and there are plans for redesigning the homescreen. Overall this new release is a major step forward in delivering a robust, bug-free and enjoyable UI experience. With how much things have shaped up in this release, it sure will be interesting to see what comes in the next one. Make sure to check out the Plasma Mobile Gear 22.02 release post to read the rest of the changes in store.\nChat with the machine! [by biktorgj]\n[quick foreword by Lukasz] The work done by Biktor is incredible as is the effort by Dylan to package the firmware into fwupd (read next section). I think that it is clear at this point that, objectively, this is the definitive firmware for PinePhone / PinePhone Pro’s modem - not to mention that it is also the safest. For legal reasons I need to state the following: 1) we do not encourage users to modify their modem’s firmware nor do we encourage it and 2) altering the firmware on the modem does void device warranty. This is a community blog, and the views outlined below belong to community contributors and not the Pine Store. It\u0026rsquo;s been a year and half since I started working on the custom firmware for the modem. Most of the time I\u0026rsquo;ve been just reimplementing things the stock firmware did, and trying to patch and fix the things that didn\u0026rsquo;t work so well.\nThe Pinephone and the Pinephone Pro are special devices that do not have the modem integrated in the SoC. This causes more difficulties in getting everything to work, but it also presents opportunities to make things no other phone can do. These last weeks I\u0026rsquo;ve been implementing messaging and voice calling functionality in the modem\u0026rsquo;s userspace; that is, being able to text the modem itself, calling it, or making it call you and reply to your messages.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video \u0026ldquo;Hello? Who\u0026rsquo;s this? oh, hi modem\u0026rdquo;\nAt this point it\u0026rsquo;s just a proof of concept. It only works correctly on ModemManager-based distros, and has a limited set of commands you can request via SMS (some as useless as getting a kernel log via SMS), and calls only play a sound file in a loop, but it opens up endless possibilities to develop additional functions ranging from knowing if something is using the GPS without you knowing, to having the modem call you at a predefined time so you can have an excuse to get out of a boring meeting. If you\u0026rsquo;re running the latest release, feel free to send \u0026lsquo;help\u0026rsquo; to the modem at the non-existent number +01 555 01 99 999 and it\u0026rsquo;ll reply back with a list of the currently available functions. The latest community-built firmware can be downloaded from Biktor’s GitHub\nLVFS \u0026amp; fwupd for the modem [by Dylan Van Assche]\nYou\u0026rsquo;ve been able to install Biktorgj\u0026rsquo;s firmware on your PinePhone and PinePhone Pro modem for a long time. However, installing it required you to use the command line and you had to pay attention that the battery on your PinePhone had enough charge. postmarketOS wanted to make this flashing process more user friendly, secure and easier to upgrade, therefore I have been working with Biktorgj to bring firmware updates on your device through fwupd. Fwupd is the de facto standard on Linux to deliver hardware firmware updates through the Linux Vendor Firmware Service (LVFS) used by Lenovo, DELL, and other hardware vendors.\nIt took a long time to debug the firmware update process of the modem, since it is not documented and contains various bugs. These were solved and integrated into the fwupd ModemManager and fastboot plugins. Various patches were submitted to fwupd, ModemManager, eg25-manager, etc. to make it all work. After some help from the LVFS and fwupd maintainers we now have the firmware updates available through LVFS which are signed and properly tested by me and Biktorgj. Moreover, you can now upgrade your firmware through GNOME Software, KDE Discover or the fwupd CLI after switching to the community firmware branch. Note that this branch is not supported by the original hardware vendor at all, but it provides stability improvements, enhancements, and protection against the root exploit which is being abused by malware to brick your PinePhone and PinePhone Pro modem.\nI described the whole process on my blog and invite you to have a read.\nSee Updating Pine64 PinePhone modem firmware with fwupd.\nDemo of the modem\u0026rsquo;s firmware being flashed\nPineNote The PineNote has seen a handful of important developments since last month. The initial successful e-paper enablement on mainline-based Linux, thanks to work by smaeul and pgwipeout, now allows partner project developers to start work on porting their OSes to the PineNote and adapting user interfaces for the grayscale display. Last month we got a handful of units into the hands of our friends at KDE and they’ve started work on adapting Plasma Mobile to work on the PineNote. I spoke to Aleix, KDE e.V. president, last week: he told me that aside from working on a proof of concept UI in grayscale, KDE has also started adding support for apps - “(\u0026hellip;) work to support the first apps on the device has started. At this time developers are working on getting Pikasso, a simple drawing app, to properly support the integrated drawing tablet on the device”. Plasma desktop already runs on the PineNote and, when using a modified high-contrast theme, the full desktop environment seems surprisingly viable on e-paper. If you want to join the conversation, help and contribute to the development of Plasma on e-paper or have an application you’d like supported on e-paper then please join Plasma-Ink Matrix channel. Plasma Desktop with grayscale theme on the PineNote - via KDE dev team\nBut Plasma isn’t the only UI that has graced PineNote’s display in the past month. The device now also boots postmarketOS with Phosh UI using the DRM driver display written by smaeul (with pgwipeout’s tweaks). The merge request for initial support has already been submitted so there is a good chance that we’ll see a PineNote OS image from the postmarketOS team at some point in the near future. I’ve briefly spoken to Caleb from postmarketOS and they told me that Phosh looks great in high-contrast mode. However, they also mentioned the default theme cannot be modified since various parts of the UI are hardcoded. Noteworthily, SXMO - a mobile UI that came to be on the PinePhone - has now also been ported to the PineNote; I am very much looking forward to seeing how this particular UI works in practice on the PineNote. Regardless, the more choices the better, and having a wide range of desktop and phone UIs available will help us determine the right trajectory forward for the PineNote. postmarketOS on the PineNote - via Caleb\nNot only have we seen much movement on the UI-side, but many low-level enablements have also been made in recent weeks. Indeed, the functionality of the PineNote is growing by the day and things are starting to look great. Aside from the e-paper display, Wacom and capacitive panels, we now have Bluetooth, WiFi, as well as sound output. Bluetooth was broken on the PineNote until recently but, as Samuel Holland explained to me, it was fixed by using a different firmware. He added that this effectively means all hardware components of the PineNote have now been tested and do work (to various degrees). Even EMR pen pressure sensitivity has now been enabled and works in Linux. Given how little time the PineNote has been in active development, seeing all these efforts slowly start coming together and forming a larger whole is very exciting. EMR pen pressure working in Krita on the PineNote - via Samuel Holland\nThat said, there are a number of issues that remain to be resolved and make Linux more usable on the device. As pgwipeout explained to me, GPU acceleration doesn’t work when outputting to the E-Book Controller (EBC) - the display controller for the e-paper display. This means that the UI and all its elements are currently sluggish. But enabling the GPU over EBC is only a part of the issue. There is also a need to create a standard for exposing refresh modes to userspace (different refresh modes supported). Caleb says that creating a daemon will be needed to automatically switch modes depending on what the user is doing - e.g. switch to mode A2 when scrolling or drawing on the PineNote. At present time, the A2 mode doesn’t seem to work properly, so writing on the PineNote in Linux is not viable (the input appears with a delay). Eventually desktop environments such as Plasma Desktop and Phosh as well as individual applications should support the waveform switching feature, so that the display can adapt to the user\u0026rsquo;s activity. The good news is that significant progress is being made on this front too. As Samuel Holland explained to me, the mainline-based display driver now supports all of the display controller’s modes. These modes determine the ability to independently update different parts of the screen at the cost of CPU and power usage. Samuel says that previously only the least sufficient software mode was available and that the now enabled “(\u0026hellip;) hardware LUT mode allows us to run the panel at full speed. Since the waveforms are designed for a specific refresh rate (\u0026hellip;), this means better image quality”.\nDisplaying an image isn’t everything however and there are multiple other issues that still need addressing. For instance, due to a bug, u-boot currently doesn’t detect the root filesystem automatically, and requires the user\u0026rsquo;s input over UART. Needless to say, this isn’t exactly a viable manner of booting the device into an OS, especially not for regular end-users (but surely it is also an annoying step even if you’re an enthusiast). So, while there is clearly a way to go before we can all enjoy reading and writing content on the PineNote running a traditional Linux desktop environment, let us appreciate how much progress has been made in just a few short months. With the amount of work being done on this particular device, and on the RK3566 platform in general, I am confident that early adopters will get a chance to get their hands on the PineNote late this year. Pinecil [by William Starkey] IronOS 2.17/2.16 changes: the two most recent IronOS updates, 2.16 and 2.17, bring some great new features to the Pinecil, as well as significantly improve some of the existing ones! The major improvements made in 2.16 are upgrades to the temperature regulation, so the Pinecil heats up faster and holds the temperature more precisely, and refactoring \u0026amp; bug-fixes of the USB Power Delivery (PD) stack that fix compatibility issues with some Type-C power supplies, and a myriad of other small quality-of-life improvements.\nIronOS 2.17 brings some useful new features, including the ability to check if the iron has had the VBUS mod (explained below) performed correctly, and a new debug menu entry showing raw values from a Hall effect sensor if one was added to the board. It also brings some improvements to the Russian, French, and German translations. The logo conversion tool now outputs a .dfu file directly to make it easier to add a custom logo, and the build tools are all now compatible with Alpine Linux - so you can build and flash IronOS from a PinePhone or PinePhone Pro running PostmarketOS.\nPINE64 Updater: a flashing utility designed to make the experience of updating the firmware on your PINE64 products easier is under development by Gamiee, one of the admins of the PINE64 community chat rooms. The software currently supports updating the firmware of your Pinecil and is available on MacOS and Windows. It’s planned to gain support for Linux and allow flashing more Pine64 products in the future. The PINE64 updater is currently available on github at https://github.com/pine64/pine64_updater if you want to contribute to the project or use it to flash your Pinecil more easily.\n[edit from Lukasz] A quick foreword to the following section - we always allow and encourage users to experiment and mod their devices. But, please, bear in mind any modifications to Pinecil’s hardware does void the warranty. Pinecil VBUS mod: early on in the Pinecil\u0026rsquo;s lifetime, shortly after it was announced, there was some controversy over the voltage rating of the Pinecil. It was rated for 24V, but the chip responsible for handling USB power delivery, FUSB302, was not rated for more than 21V. While the “Absolute Maximum” rating for the chip is 28V, it will still sometimes die when 24V is fed into it. The VBUS mod is a fairly easy permanent fix for this issue. As we found out, the pin on the FUSB302 that connects to the incoming power rail (VBUS) is not actually used by IronOS, and therefore doesn’t have to be connected. The mod is, thus, as simple as cutting the trace going to that pin.\nThe recommended technique is to use the corner of a razor blade and drag it across the trace highlighted on the picture - at the point between the two arrows. This position will change depending on the version of your Pinecil board, so, when you get the board out of your Pinecil (follow the disassembly instruction on the wiki at https://wiki.pine64.org/wiki/Pinecil#Disassembly_steps ), compare your board with the visual aids to find the location to cut, press the corner of a razor blade into the board slightly above the starting location, then carefully drag it through the trace, firmly applying pressure so that you cut through the copper. Make sure you do not cut any other traces!\nOnce the trace is cut, make sure it is no longer connected, using either a multimeter or IronOS’ new VBUS mod detection feature (available in IronOS 2.17). To use the IronOS mod detection feature, plug your Pinecil into any USB-PD-capable Type-C port using a C-C cable, then open the debug menu by holding down the “-” (minus) key after the screen turns on. Press the “+” key in the debug menu until you reach the section labeled “PWR”. It will say “PD No VBUS” after “PWR” if you have properly cut the trace. When you have confirmed that the mod was successful, you will be able to use your Pinecil with a 24V power supply without any risk of causing damage to the iron!\nMod illustration before (left) and after (right)\nPineTime [by JF] InfiniTime 1.8 was released last month (see the January community update for more details). According to the feedback we received, BLE connectivity seems to work much better than before thanks to the addition of the secure pairing functionality. If you haven\u0026rsquo;t done so yet, I strongly recommend you update your PineTime to this latest version. The next release is not ready yet, but many contributors and developers are working to add new functionalities and fix bugs. Infinitime keeps getting valuable feedback, interesting feature requests and many many pull requests - thanks to everyone who is contributing to the project!\nSo what have we been working on? You can get a preview of the features we plan to add to the next release by checking out the 1.9 milestone. This list includes a new airplane mode feature (to disable the BLE radio when you don’t need it), a new “terminal” watch face and a complete rewrite of the documentation.\nTerminal watchface - pictur by 13werwolf13 on Github\nAnother project I would like to highlight is the InfiniTime simulator by NeroBurner, which has been worked on for a few months now. This simulator runs the whole InfiniTime UI, allowing developers to easily design new applications and user experiences directly on their PC without needing to test and debug the changes on the actual PineTime. I recently had a look at this application and I have to say I’m genuinely impressed by the amount of work NeroBurner put in. It simulates the whole UI by reusing code from InfiniTime and it “stubs” (replaces) low level code that accesses the hardware so that it can run in a simple window on your desktop. The author opened a pull request on InfiniTime and I’m eager to review it and see how we will integrate it into the project.\nGIF of InfiniTime simulator - by NeroBurner on Github\nUpcoming weather forcast functionality in the simulator\nAs you can see in the following picture, the integration of weather information in the PineTimeStyle watchface is still ongoing thanks to the simulator!\nStay tuned for the next release and, until then, enjoy your PineTime.\nPineDio [by JF] Remember the PineDio STACK? This is a development kit based on the Bouffalo BL604 RISC-V MCU which embeds many devices like a LoRa radio, a motion sensor, a display and a touch panel. We have already talked about it in previous updates, and Lup has already written extensively about it LoRaWAN on the STACK, Rust on Apache NuttX BL602 EFlash Loader: Reverse Engineered with Ghidra and related topics.\nUnfortunately this kit is not yet available in the Pine Store as we still had a few issues with our prototypes: we were unable to make the LCD work and we had a few issues with flashing one of the boards. Fortunately, we were able to fix those issues and now can move onto the next stages of development. I’m currently working on a demo / selftest firmware that implements basic drivers for all onboard devices (LoRa radio, sensors, display,\u0026hellip;) to ensure that the firmware is able to communicate with those devices and that they are working properly. This firmware will not only allow future developers to check that their board is working correctly, but it’ll also make it possible for the PINE64 production team to test the boards at the factory before shipping starts!\nI’ve just sent the first version of the firmware to the production team. Now, I’m waiting for feedback and I’ll eventually do some changes and improvements if needed.\nHere’s a video showing that firmware in action: https://video.codingfield.com/videos/embed/ab40f429-18d0-4827-b2b3-123f74ab8d09\nOnce this firmware will be ready, PINE64 will be able to start the production of the PineDio STACK. That is all for this month’s update, if you haven’t done so yet make sure to subscribe to this blog - the subscription widget is at the bottom of this page.\n","permalink":"/2022/02/15/february-update-chat-with-the-machine/","tags":["modem","pinephone","pinephone-keyboard","pinephone-pro","pinetime"],"title":"February update: chat with the machine"},{"categories":["news","pinephone"],"contents":"\nThroughout January we ran a poll asking people about how they use their PinePhones. Some poll results are quite predictable while others yielded unexpected results. Before we start, let me put on my academic hat for just one minute. This is a small, self-reported and not representative sample. A total of 3079 respondents took part in the poll - which amounts to less than 5% of all PinePhone owners. I’d therefore hesitate to extrapolate any of the results to the entire PinePhone community. I find it more likely that this sample reflects the most active community members and people following our project. It is also worth mentioning that some questions posed in the poll weren’t exactly well phrased, and that the poll itself did not follow any established conventions. But this was never meant to be a comprehensive study - it is instead, at best, a peak at the overarching trends of the most active portion of the community. To this end, when describing the results I’ll use descriptive generalizations, such as ‘more than half’ or ‘the majority’, rather than exact numbers or percentages I feel that this is more in line with the nature of the data and the general spirit of the poll. For what it\u0026rsquo;s worth, I’ll also share some of my thoughts and insights as we review the results. Exact numbers and percentages are, however, included in the graphs.\nAs always, I encourage you to share your thoughts about the results in the comments section.\nThank you to all those who took the time to fill in the questionnaire!\nGeography\nA third of all respondents are from the United States. In Europe, Germany, the United Kingdom (UK) and France have the highest respondent counts. The number is by far the greatest in Germany - more than twice that of the United Kingdom. In terms of per capita, it would appear that we also have a large active community in the Netherlands, Sweden, Austria and Czechia. Adjusted for population size, the response counts in these countries are actually on par or larger than in the UK or France. Outside of Europe and the US, Canada and Australia have the two largest PinePhone enthusiast communities. Similarly to smaller European countries, when adjusted for population size, the response counts in Canada and Australia surpasses larger European countries. Interestingly, there is a sizable number from Russia - a country where the PinePhone isn’t shipped to.\nAs expected, the number of respondents in Africa, South America, the Middle East, India and South Asia is low, with Japan being the sole exception. We are still experiencing issues shipping to India and some South American countries (Brazil in particular), which likely accounts for the low response numbers from these geographic regions.\nThe high number of respondents in Afghanistan is clearly an error. It would appear many users overlooked the first question and left Afghanistan - alphabetically the first option - as their answer in the drop-down menu querying geographic location.\nLinux literacy\nThe vast majority of respondents report being highly Linux literate. A tenth of all respondents consider themselves true Linux wizards and nearly half identify as enthusiasts capable of writing (some) code. A sixth of all respondents reported being ‘tech-heads’ with a good understanding of Linux operating systems. Non-Linux-savvy users, and people interested in smartphones but with a limited understanding of Linux, are but a small percentage of the sample.\nWhile the PinePhone undoubtedly caters primarily to a Linux literate and technically savvy crowd, I do not believe this result to be representative of the entire community. I strongly suspect that community members with a lower Linux literacy are significantly underrepresented in this poll. Here is one plausible explanation: PinePhone owners with a lesser interest in Linux and FOSS in general do not follow our blog, forum, chats and social media, etc, and therefore haven’t had the opportunity to partake in the poll.\nThere is also something to be said about the subjective scale used to evaluate respondents\u0026rsquo; Linux literacy - more specifically, I think it likely that a portion of the respondents may have overestimated their degree of Linux knowledge. To be clear, this isn’t a snarky jab at respondents, just a known psychological bias found in nearly all self-evaluation forms.\nExperience with mobile Linux (capable) smartphones\nAlthough the majority of users reported the PinePhone being their first Linux smartphone, I was surprised to learn that just under a fourth of all respondents have previous experience with mobile Linux. This value is much higher than I expected. I suspect that this result is not representative of the entire PinePhone community.\nIt would be interesting to learn whether the majority of people with previous mobile Linux experience belong(ed) to the Ubuntu Touch, SailfishOS, Nokia N900 communities, or whether their experience stems from elsewhere.\nPoll results PinePhone usage\nI was excited to find that a fourth of all respondents daily drive their PinePhone. Over a quarter of all respondents also use their PinePhone as a secondary smartphone, while a third report using their PinePhone occasionally.\nI am very pleased to learn that the majority of respondents use their PinePhone frequently or daily. That said, I suspect that the percentage of people daily driving their PinePhone is overrepresented as compared to the entirety of the PinePhone community. Regardless, I am looking forward to the first in-person FOSS conference to see people show up with their PinePhones in hand.\nI am, however, most curious about the people who only use their PinePhones occasionally as they make up a third of the sample. Is there a particular scenario when they use the PinePhone? Do they follow development of one or more OS? Do they use it infrequently due to missing features? Are they considering daily driving it at some point? Would they consider using the PinePhone Pro or some other Linux smartphone more regularly? I’d like to know the answers to these questions - it would warrant a poll of its own.\nOS and UI choices\nMost respondents - just over a third - have Manjaro Linux installed on their PinePhone. Mobian and postmarketOS appear to be equally popular, with more than a fifth of installs each. DanctNIX (Arch) is in fourth place with approximately an eighth of all installations. Ubuntu Touch arrives in fifth place, accounting for less than a tenth of PinePhone OSes.\nMost frequently tried operating systems are: Manjaro, Ubuntu Touch, postmarketOS and Mobian - respectively and in this order. In retrospect I feel that the question inquiring about which OSes tried out was not well phrased. Presumably most people get to experience Manjaro with Plasma Mobile as it ships with the PinePhone, and this cannot be equated with actively seeking out and installing other operating systems. I therefore find it hard to interpret Manjaro’s position at the forefront of this graph.\nOne interesting observation is that many people try out Ubuntu Touch but end up settling for a different OS. I am curious as to why: is it because Ubuntu Touch is not a traditional Linux distribution? Is it because the PinePhone build lacks some core functionality? Or is it simply the case that our core user base is after a different experience?\nAs for user interfaces: about a third of all respondents have a preference for Phosh and a fifth for Plasma Mobile. One in ten respondents reports liking Lomiri best. Somewhat surprisingly one in ten respondents has a preference for either SXMO or SWMO (approx 5% each) - this is more than I’d expect given the novelty and complexity of the UI(s). I suspect that the high number of respondents using SXMO and SWMO reflects on the high degree of Linux literacy in the survey sample.\nWhat I find by far the most interesting, however, is the fact that nearly a quarter of all respondents do not have a strong UI preference (whatever works best). I admit that I expected people, many of whom identify themselves as enthusiasts, to have, how should I put it, preconceived UI preferences. Perhaps the Linux community isn’t as partisan when it comes to desktop environments as people say.\nPinePhone Pro and add-ons\nOver half of poll participants indicated that they will be purchasing a PinePhone Pro - a fifth stated they’ll be picking one up as soon as it becomes available (the survey launched prior to the PinePhone Pro becoming publicly available).\nA third remain undecided whether they’ll pick up a PinePhone Pro but only less than a tenth do not intend on picking one up.\nAs for the optional PinePhone (Pro) add-on accessories - clearly the most desirable PinePhone add-on is the keyboard case, with nearly two thirds of all respondents planning on purchasing it.\nA quarter of respondents plan on purchasing the keyboard add-on case in combination with one of the other add-ons. Aside from the keyboard, the most popular back cases for the PinePhone (Pro) are the fingerprint reader and Qi wireless charging add-ons.\nA quarter of all respondents will not be buying any add-ons for their PinePhone.\nData compilations Favorite OSes for daily driving\nThe majority of users who daily drive their PinePhone use either Mobian or Manjaro Linux - both of which account for just under a third of installs each. postmarketOS and DanctNIX (Arch) come in second and third place with a fifth and a seventh of all installations respectively.\nWhile it is undeniably true that this poll sample is not representative of the entire PinePhone community, I do find it likely that these OSes are the four most popular on the PinePhone platform. Therefore it also makes sense that they are frequently chosen for the purpose of daily usage. Conversely, other OSes are much less popular among the core PinePhone base and therefore also less frequently chosen for the purpose of daily driving.\nFavorite OSes among those who use their PinePhone as a backup/secondary smartphone\nAmong those who use their PinePhone as a backup or secondary smartphone, Manjaro Linux is the most popular OS with nearly a third of all installations. Mobian is the second most popular, with a quarter of all installations, followed by postmarketOS and DanctNIX (Arch) with approximately a fifth and a seventh of installations respectively.\nI suspect that a sizable portion of people who use their PinePhone as a secondary smartphone keep the default OS image - Manjaro with Plasma Mobile - as their default installation. Data indicates that only half of people who use their PinePhone as a backup smartphone have tried out other OSes. This stands in contrast to the vast majority of people who tried out other OSes prior to settling on one to daily drive.\nFavorite UI among people who drive their PinePhone daily\nPhosh is by far the most popular UI among those who daily drive their PinePhones with a presence on nearly 40% of all installations. This is more than likely due to Mobian - which features Phosh by default - being a popular choice for daily driving.\nInterestingly, SWMO and SXMO are collectively as popular among those who daily drive their PinePhone as Plasma Mobile, with approximately a seventh of all installations. I am surprised by how popular these UIs are among the PinePhone user base. As you’d expect those who daily drive OS installations with SWMO and SXMO identify themselves as highly Linux literate.\nA fifth of respondents in this subsample do not have a UI preference.\nFavorite UI among people who use their PinePhone as a backup/ secondary smartphone\nPhosh is the most popular UI for people who use their PinePhone as a secondary smartphone with a third of all installations, while Plasma Mobile comes in second with a fifth of all installations.\nA tenth of all respondents in this subsample chose Lomiri as their favorite UI. This is interesting, since this number is comparatively large when contrasted with Ubuntu Touch’s popularity on the PinePhone. I suspect that this indicates people like the Lomiri UI but find obstacles elsewhere in the Ubuntu Touch OS, leading them to switch to one of the four most popular OSes. In other words, they like the UI the best but don’t actually use the OS that offers it.\nA fifth of all respondents in this subsample do not have a UI preference.\nUIs on the four most popular OSes (Manjaro, Mobian, postmarketOS and DanctNIX)\nPlasma Mobile is the most popular UI among Manjaro, accounting for a third of all installations. This is quite predictable given that the default OS image installation shipping on the PinePhone offers this exact OS-UI combination. That said, Phosh is nearly as popular with just under a third of all respondents selecting it as their favorite. A quarter of Manjaro users claim that they do not have a strong preference for any UIs, as long as the UI is efficient and bug-free.\nUnsurprisingly Phosh is the UI of choice for Mobian users, half of which selected it as their preferred UI. Interestingly, a fourth reported not having a strong UI preference.\nThe most interesting results, at least in terms of UI, are to be found among respondents currently running DanctNIX (Arch) and postmarketOS. While both user bases report favoring Phosh, a significant number of users selected SXMO and SXMO as their preferred UI(s). On postmarketOS this number amounts for a whopping third of all respondents; on DanctNIX the number accounts for a seventh of respondents in this subsample. A tenth of DanctNIX users also selected Lomiri as their favorite UI, which is curious since it isn’t available on Arch. Plasma mobile has been chosen by a fifth and a tenth of postmarketOS and DanctNIX users respectively.\nThis means that SWMO and SXMO are collectively more popular among postmarketOS than Plasma Mobile and comparatively popular among DanctNIX users.\nClosing thoughts I am sure that some of you will be tempted to jump to conclusions having read the poll results and the compilation data, but I strongly recommend you refrain from doing so. I remind you that the sample consists of 3079 respondents, a number which cannot be viewed as representative of the entire PinePhone community. Moreover, due to the methodology, or rather lack thereof, it is impossible to extrapolate results from this data set in a way that would reliably reflect trends in the broader community. So, then, what is the data good for? I believe that the poll paints a couple of interesting trends among the most active and engaged members of our project. For one, it shows us that this segment of the community views themselves as highly Linux literate - and this is likely accurate (to a degree). PinePhone owners who partook in the poll are also likely to daily drive their PinePhone or use it frequently as a secondary smartphone. It is clear that among this segment of the community four operating systems are most popular: Manjaro, Mobian, postmarketOS and DanctNIX (Arch). Manjaro and Mobian being clearly preferred for daily driving the PinePhone.\nWe also learned that users of the aforementioned OSes have different UI preferences. While Phosh is clearly the most popular UI across the board, it came as a genuine surprise to me how popular SXMO and SWMO are in general and on postmarketOS more specifically. I didn’t expect such a complex and unorthodox UI to gather such a following in a relatively short period of time. But to be clear, I think this is great. We also shouldn’t overlook that a sizable portion of respondents is indifferent to which UI they use as long as the experience is solid.\nI feel we also learned that many respondents like the Lomiri UI and many of them try out Ubuntu Touch on their PinePhone but ultimately decide against using it. To me this is an important finding, with potentially very important implications. Exploring this further, however, falls outside the scope of these poll results (and would likely require a study of its own).\nI was glad to see so many respondents planning on picking up a PinePhone(Pro) keyboard to augment their mobile Linux experience. I can tell you that, indeed, the keyboard add-on is very popular and currently one of the best selling items in the Pine Store. Finally, I am glad to see so many respondents are planning on picking up a PinePhone Pro now or in the future. This is obviously good news for us, our community and the mobile Linux crowd in more general. In a year it may be worth running a similar poll inquiring about the PinePhone Pro to learn whether we met the expectations with our new device. Once again, I’d like to thank everyone who took part in this poll, I really appreciate it.\n_Found a mistake? Please let the mods know or leave a comment below\n_\n","permalink":"/2022/01/31/pinephone-community-poll-results/","tags":["community","community-edition","keyboard","pinephone","pinephone-pro"],"title":"PinePhone community poll results"},{"categories":null,"contents":" Download audio\nIn this episode Justin and Brian chat a bit about the PinePhone keyboard, Plasma Mobile Maui shell and more!\nLinks and topics discussed:\nhttps://avery.cafe/blog/a-quick-fix-for-the-pinephone-keyboards-top-row/ https://postmarketos.org/blog/2022/01/17/v21.12.1-release/ https://lists.sr.ht/~mil/sxmo-announce/%3C20220107164241.u7q5uaok5wkw37y6%40worker.anaproy.lxd%3E https://pine64.com/product-category/smartphone-accessories/ https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.8.0 https://nxos.org/maui/introducing-maui-shell/ https://forum.sailfishos.org/t/sailfish-community-news-30th-december-what-a-year/9797 Music from Bensound.com and Zed (@itismezed)\nhttps://soundcloud.com/kevinflynnretro\nEdited by Zed\n","permalink":"/podcast/s02e05/","tags":null,"title":"S02E05: Talk about a dense 15 minutes"},{"categories":["news","pinedio","pinenote","pinephone","pinephone-pro"],"contents":"\nWelcome to the first update of the year. The year just began but much has already happened. These past 2 weeks saw the release of the highly anticipated PinePhone keyboard case and the PinePhone Pro Explorer Edition. And there is more good news: the PineNote’s e-paper display now works, and is now available for purchase without the need for a coupon. We have many things to cover, so let\u0026rsquo;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.\nI’d like to thank JF, Alex (clover), Lukasz, PizzaLovingNerd, and Samuel (smaeul) for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of this month\u0026rsquo;s update\nTL;DR\nHousekeeping We’re running a PinePhone community poll - it takes 2 min to answer, please fill it in We’ll be hosting quarterly Q\u0026amp;A sessions allowing you to ask any questions related to PINE64 - first Q\u0026amp;A on Friday, January 21 at 21:00 UTC Chinese New Year starts February 1st; production, shipping and support members are off on holidays until Late February Once Chinese New Year is over, we’ll investigate Pinebook Pro and PineTab production opportunities PinePhone Pro PinePhone Pro Explorer Edition is available for pre-order for $399 PinePhone Pro orders placed before January 18th ship late January; orders placed on and after January 18th ship in late February, after Chinese New Year A quick review of PinePhone Pro’s software state - a list of things that need to be enabled or fixed before the phone is daily-drivable New OSes to choose from: Gentroo, LuneOS were already ported, while openSUSE and Fedora ports are in the works PinePhone OpenBSD now boots on the PinePhone; much work is needed to enable core functionality From Jolla’s community news blog we learn that the PinePhone port of SailfishOS accounts for more than 40% of all installs Pico 8 Raspberry Pi port works on the PinePhone - yes, it does run DOOM RK3588 Many of you have seen the announcement - the RK3588 will be made available to vendors (in bulk) later this year It is a very powerful and complex SoC - full Linux functionality will take time, likely a long time PineNote If you are a developer or an enthusiast, you can now order the PineNote without a coupon Support for PineNote’s e-paper display has now been enabled in mainline-based Linux; we now have a functioning DRM (Direct Rendering Manager) driver for the device\u0026rsquo;s e-ink controller and panel Next release of the mainline-based kernel enabled USB OTG functionality; this will make development much easier moving forward PineTime Infinitime 1.8.0 released with new features for end-users such as BLE secure pairing, and prep work for future features. New version of GadgetBridge adds step counter support Pinedio LoRa USB adapter brings LoRa connectivity to any computer or SBC equipped with a USB port LoRa addon for the PinePhone has very rudimentary software support for now Lup Yuen Lee has been experimenting with Apache NuttX on the PineDio STACK Housekeeping Let’s start with a quick reminder that we’re running a poll to learn more about the PinePhone community. If you are a PinePhone user and haven’t filled in the questionnaire yet, then I kindly ask you to do so. The more people take part, the more complete the picture we have, and the better the poll results are. It is a short, 9-question survey and it takes no more than 2 minutes to fill it in. The poll will close at the end of the 24th of this month, at which point we’ll crunch the numbers and generate a report. I initially thought we could have a report included in the next community update, but now I’m thinking it may be a better idea to spend more time on the data and to write a more substantial stand-alone report. I haven’t made up my mind yet, I need to see the numbers first. I’ll keep you posted. We’re going to be hosting quarterly Q\u0026amp;A sessions using the stage feature on our Discord server. This will give people a chance to ask questions about current and future projects, or anything else PINE64-related. I want these Q\u0026amp;A sessions to be casual, so rather than having questions submitted beforehand I’ll be picking queries from the chat and inviting people onto the stage for a talk. The first Q\u0026amp;A session will take place next Friday late evening (UTC), January 21st. As for why we’re using Discord, the answer is simply: it has the functionality we need and works flawlessly, and 2) there are now over 10,000 people on Discord, which is twice the number of the next biggest PINE64 chat protocol. The Q\u0026amp;A session will be recorded and uploaded to Youtube, Odyssey, and Peertube at a later date if you don’t make it or do not use Discord.\nChinese New Year (CNY) begins February 1st, at which point all production, shipping, and related activities will come to a halt. Pine Store sales, info, support, and product teams are off to spend time with their relatives and enjoy a well-deserved vacation. All factories will also stop production during this period. The Pine Store will keep taking orders over CNY, but shipping will first resume in the second half of February. Any queries submitted over this period will also be answered first after activity resumes in the latter part of the month. There will be a big build-up of emails and support tickets over this period, so it may take longer than usual to receive a response - thank you in advance for your patience. Do note that if you order hardware very late in January it is more than likely that it will ship in late February. Lastly, once factories start up again, one of the first things on the product team’s agenda is exploring the viability of Pinebook Pro and PineTab production. We know that many of you are waiting to get your hands on a Pinebook Pro or a PineTab; granted that prices of LCDs reach a reasonable price point after CNY, we’ll be scheduling a production run for March. I’ll make sure to update you on production-related matters closer to the date. Quarterly Q\u0026amp;A voice channel in the official PINE64 Discord\nPinePhone Pro Speaking of the PinePhone, there’s a lot to unwrap for this month. The PinePhone (Pro) keyboard case is now on sale, as many of you may have seen, and the PinePhone Pro Explorer Edition is now also available for pre-order. The first production-run of keyboard cases should have already shipped by the time this post is live, and shipping will continue right after the Chinese New Year. As for the PinePhone Pro, orders placed by January 18th will ship out this month, while orders placed after this date will be dispatched as soon as the team returns from their holidays. While the PinePhone Pro’s software is progressing extraordinarily fast, and we’re in a much better position than with the original PinePhone Braveheart and Community Editions, there is still much work needed to bring full functionality to the device, and this will take time. Please also note that while the keyboard addon will support the PinePhone Pro, it likely will not yet be functional by the time you receive your units, as software support is still being worked on.\nPinePhone Pro pre-orders are now live\nReassuringly, however, the Mobian team is confident of the PinePhone Pro being daily drivable before 2022 ends in their recent PinePhone Pro status blog post. Other partner project developers share the sentiment; the phone performs very well in all mobile environments and no hardware design flaws have been uncovered in the development batch. As things stand today, there are four major software shortcomings that prevent the PinePhone Pro from being truly daily-drivable (by end-users already acquainted with Linux smartphones). I’ll list them in the order of significance: the PinePhone Pro doesn’t wake from suspension, battery level reporting is poor, cameras do not work and, lastly, audio call quality is poor. Out of the four, the first issue directly impacts PinePhone Pro’s daily drivability, since without functional suspension the phone is limited to a short run-time. However, once waking from suspend gets sorted, we estimate that the PinePhone Pro will be able to remain dormant, while receiving SMS/MMS and calls, for as long as the original PinePhone (18-24hrs). These issues will eventually be sorted, but they are something that early adopters picking up a phone today need to be aware of. Finally, LuneOS and Gentoo have been ported to the PinePhone Pro, and ports of openSUSE and Fedora are already in the works. You can see all OSes currently available for the PinePhone Pro under the software releases section of the device documentation (although it appears the Gentoo port hasn’t been added yet - please see the original Tweet). Speaking of the Wiki, earlier this month the PinePhone Pro was granted FCC certification (which can be viewed online), which follows on the heels of the CE RED certification granted in November. Both certifications will be uploaded to the Wiki alongside production schematics and part datasheets this month. There is now also a dedicated Explorer Edition subsection on the Wiki, and it is currently void of content. Anyone is welcome to contribute to the page. The Maui Project (part of the KDE ecosystem), recently announced that they are working on a simple and unobtrusive desktop environment intended to adapt to different form factors, including desktops, tablets, and phones. While in a very early testing release simply intended for feedback, it shows quite a lot of promise thanks to its many features and clean user interface. You can expect an Alpha release in March of this year according to their current roadmap shown at the bottom of the announcement post.\nPinePhone With regards to the base PinePhone, OpenBSD has been demonstrated to boot, although much work is needed to get it to a functional state. Among the issues encountered by Crystal in his mailing list; errors flood the console, the various sensors of the device are read incorrectly, powering off the device does not fully work, and the CPU is run at the wrong clockspeed. It is however extremely promising to see this kind of progress!\nA recent Jolla community news post disclosed that the most popular SailfishOS port of the last year was for the PinePhone. This in and of itself may not be super surprising, but the fact that the PinePhone port accounts for nearly 40% of all installations and has “(\u0026hellip;) over double the installs of the other devices in the top ten list combined” is noteworthy. It is always exciting to see how our hardware impacts other communities and I cannot but think that this is a prime example of the PinePhone shaping a different community. Perhaps with sufficient interest from Jolla’s community members and contributors, we’ll see a port for the PinePhone Pro too - time will tell.\nSailfish OS port statistics - picture via Jolla\nLastly, Danct12 has tested Pico 8 on the PinePhone (running DanctNIX Phosh) with the keyboard add-on. Although his pre-production keyboard has some stuck keys (production units will not have this issue), this video of him playing a Pico 8 port of doom on the keyboard is still very cool to see. I’ll leave you with his video:\nhttps://www.youtube.com/watch?v=YHIj3mCnQZ0\nPico 8 port of Doom running on the PinePhone with a Keyboard -\nFor those of you who wish to run an open-source alternative, he has also taken a photo demonstrating Tic-80 running on the PinePhone with the keyboard addon - via Danct12\nRK3588 With the announcement of the RK3588 at the Rockchip Developer Conference of 2021, we are able to talk more freely about the RK3588 SoC. No doubt many of you have already read about this new chip, and know that it is far more potent than the current RK3399 we use in the Pinebook Pro, RockPro64, and PinePhone Pro, seeing as its GPU, in particular, is 10 times faster. With that said, we will have chips delivered to us in the second half of the year, and rest assured no one else will have them before us. It is unlikely that there will be complete mainline Linux support or working GPU drivers within at least a year from the time that the chips start being delivered. We do not have any plans currently to put these chips into our devices until after progress has been made by others in this space. Here is the takeaway: the RK3588 is a very powerful SoC, with heaps of potential, but it is also a highly complex chip. It is, therefore, more than likely that it will take a long time for all its core features to be brought up and properly supported under Linux. We’ll be watching the development of the RK3588 closely, and once all the core functionality is in place we’ll be bringing great hardware built upon the architecture. RK3588 block diagram\nPineNote Due to the progress made on the Quartz64 and PineNote platforms in recent weeks (more on this later) the PineNote can now be purchased without the need for a coupon. That said, the PineNote is still to be considered a developer and enthusiast-only device at this point in time. There is no default operating system or user interface for the PineNote and it ships with only the bootloader installed. If you intend to purchase one, at present time you’ll have to install, and likely also build from scratch, your own Linux system to run on the device. If this doesn’t scare you off and sounds like a fun challenge, then please read the Pine Store’s PineNote product page description as well as Samuel’s report below prior to picking up a unit. Much progress has been made over the past month toward getting Linux up and running on the PineNote. During December, most developers received their PineNote units, and began familiarizing themselves with the device, getting their favorite Linux distribution to run alongside the Android factory test image. Folks are running Alpine and Debian in various configurations, with a NixOS port in progress, and more distributions are on the way. Out of that effort came critical tool and documentation improvements, which helped to get later folks up to speed quite a bit faster. There were some great hardware projects as well, like irrenhaus\u0026rsquo;s sturdy 3D printed case for the PineNote\u0026rsquo;s UART Adapter:\nPineNote UART Adapter - via irrenhaus on Discord\nAfter the new year came some major kernel milestones. The largest one was the release of a functioning DRM (Direct Rendering Manager) driver for the device\u0026rsquo;s e-ink controller and panel.\nPineNote Eink panel working - via Smaeul\nThis accomplishment is important for two reasons. First, it proves the viability of the product as a mainline-first Linux e-reader. Second, it allows developers to start testing and optimizing their graphical applications for e-paper displays. Similar to how Linux apps had to be modified (or new ones had to be written) to work well on a PinePhone-sized touchscreen, applications will also need changes to function smoothly on a slow-updating, grayscale e-paper display. For example, developers will need to remove animations, maximize contrast, and avoid conveying information through color. While making these updates is no small task, it is only a matter of time now that the process has already begun.\nTo be clear, the display driver is not yet complete. Currently, it only uses the basic grayscale waveform. More work will be needed to support the optimized anti-ghosting waveforms, the fast monochrome waveform used for low-latency pen input, and the dithering waveform necessary for watching videos. Still, it is exciting to see what people are already doing with the panel. Folks have been working on several desktop environments, including GNOME and XFCE:\nXFCE on the PineNote with Arch Linux Arm - via Danct12\nThe next release of the mainline-based kernel enabled USB OTG functionality, which means development can now happen directly on the PineNote using a physical keyboard. Further updates brought support for the touch screen and audio playback. That leaves the microphone array and Bluetooth as the remaining unsupported hardware.\nThe PineNote shares most of its hardware with the Quartz64, so most of these changes benefit that board as well, just like the PineNote effort is built on top of earlier Quartz64 development [done by pgwipeout and others]. For example, the e-ink panel now works on the Quartz64 board, too:\nSo, now that developers have devices in hand, and the e-paper display and other hardware is up and running, the pace of activity should only accelerate over the next few months.\nInfiniTime [by JF] We released InfiniTime 1.8.0 a few days after New Year celebrations. This is an interesting release as it brings new features for the end-users and also prepares the ground for future functionalities.\nInfiniTime “Fuzzy Kiwi” now supports the “secure pairing with a passkey” for BLE connection contributed by James. I talked about this feature in the last community update. When enabled by the companion app, the BLE connection is protected by a passkey: a PIN code is displayed on the PineTime and is requested by the companion app. This ensures that only your phone or computer can connect to your watch. It also encrypts the communication, so that no one will be able to intercept the notifications sent from the companion app to your watch, for example. And, last but not least, the secure pairing (bonding) allows the companion app to reconnect faster and more reliably to your watch!\nThis feature is optional for now, and we hope companion apps developers will enable this feature by default, so we can remove the unsecured connection mode in a future release.\nInfiniTime 1.8.0 BLE secure pairing - via JF\nThis new release brings many other new features and improvements: Chimes by SteveAmor that notifies every hour or half-hour with a vibration, ShakeWake by Tim to wake your watch by shaking your wrist, a trip meter in the Step app by Stephanie, and more. Some features are more complex and need more time to implement than others. In that case, we often choose to split the feature into smaller steps that are more easily achievable in a reasonable timeframe. That’s what we did for the Weather service and the BLE file system API!\nUltimately, the weather service will allow InfiniTime to display weather data (temperatures, forecasts, etc) sent by the companion app. The first step to this goal was done by Avamander as the BLE API required is now implemented. We decided to merge this feature even if there’s no weather app available (yet) to give companions app developers the opportunity to integrate this API in their app while we are working on a nice weather app and/or the integration of the weather data in watchfaces. Work is already in progress as Adam has already integrated the weather service in Amazfish and Kieran is currently working on extending the PineTimeStyle watchface to display the weather data!\nInfiniTime 1.8.0 with upcoming weather widget on PineTimeStyle watchface - via JF\nAs you already know, we are very constrained by the memory available in the PineTime: 64kB of RAM and 512kB of flash memory. The available memory fills quite quickly as we are adding new features so we must take great care when allocating memory to ensure we keep its usage under control. For example, I’ve recently analyzed the RAM memory usage and managed to free no less than 9kB (14%) of RAM.\nThe flash memory contains the code of InfiniTime and also all the static assets (pictures, fonts, etc). This data takes a lot of space, and the relatively small flash memory space prevents us from adding nicer pictures, new fonts, and additional languages. Fortunately, the PineTime is also equipped with an additional flash memory of 4MB! Our long-term goal consists in using this additional memory to store all our static assets and free some space in the main flash memory.\nThe first step was taken a few months ago when we implemented a file system in this additional memory. A new step was recently taken by Tim with the implementation of a BLE API that allows companion apps to read and write files from/to this storage! This will be the channel of choice companion apps will use to send and update those fonts and bitmaps! There is still quite a lot of work to do before users are able to send custom graphics to their watch, but we are making progress! Check the last community update to see an example of custom background in InfiniTime!\nA new version of Gadgetbridge that integrates the step counter of InfiniTime was recently published. I think this is a nice addition to the companion app, that now displays the count of steps and also displays the historical data in graphs.\nScreenshots of the new Gadgetbridge version - via JF\nPineDio [by JF] Great news for the LoRa community: Pine64 announced the availability of the PineDio Lora USB adapter and of the LoRa addon case for the PinePhone!\nLoRa Add-on and Adapter found in the store\nThe LoRa USB adapter brings LoRa connectivity to any computer or SBC equipped with a USB port (a PinebookPro or a RockPro64, for example). The LoRa addon for the Pinephone is an addon case that embeds the LoRa radio and antenna, and connects to the Pinephone using the pogo pins on the back of the phone.\nSoftware support is very rudimentary for now, but I’m happy to announce that I’ve recently published the source code of my driver for both devices. This driver is still very basic and allows to send and receive raw LoRa messages. The repository contains a chat demo application ”Communicator” that allows you to send and receive text messages over LoRa. In the following video, you’ll see a simple chat between my desktop computer, the Pinephone, and a Lopy board: video:\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video LoRa communication between desktop using USB adapter and PinePhone LoRa add-on - via JF\nLup Yuen Lee continues his experiments with Apache NuttX on the PineDio STACK and wrote a very comprehensive article on running LoRaWAN on NuttX. You’ll probably be interested in this article even if the PineDio STACK is not available yet, as it contains a lot of interesting information about embedded software, NuttX, and LoRaWAN.\nThat\u0026rsquo;s it for this month!\n","permalink":"/2022/01/15/january-update-more-news/","tags":["pinenote","pinephone","pinephone-pro","pinetime"],"title":"January Update: More News"},{"categories":["pinephone-pro"],"contents":"\nWe initially hoped to open PinePhone Pro Explorer Edition pre-orders earlier this month, but the factory encountered minor problems which had to be resolved prior to production starting. Such hiccups are common and expected, and normally a ten-day delay isn’t a major problem. However, with the Chinese New Year starting on February 1st the January production and shipping windows have now shrunk to just a handful of days. We’ve therefore been impatiently awaiting the factory’s green light per our policy that “(\u0026hellip;) we [only] take pre-orders for [devices] once production is securely underway”. Thankfully the ‘go-ahead’ signal arrived earlier today. PinePhone Pro Explorer Edition pre-orders open today, January 11th (7:00PM UTC / 11AM PST) and there will be a 6 day order window for January/ early February deliveries. Pre-orders placed on or after January 18th will first ship out once the team returns from their holidays.\nThe Explorer Edition is a large production run and we don’t expect it to sell out quickly. This also means that if the Pine Store server becomes slow or unresponsive on January 11th then please don’t spam it with repeated F5 key presses - instead, come back the next day to place your order then. Your PinePhone Pro Explorer Edition will ship by the end of January as long as you place your order anytime in the January 11th - 17th window. Please note that we’re only selling 1 unit per person and that the PinePhone Pro needs to be checked-out separately to other store items. Stay tuned for more PinePhone Pro news in this month’s Community Update. Learn more:\nPinePhone Pro website Pine Store product page Documentation Currently available operating systems order now\n","permalink":"/2022/01/11/pinephone-pro-explorer-edition-pre-orders-open-january-11/","tags":["news","pinephone-pro"],"title":"PinePhone Pro Explorer Edition pre-orders open January 11"},{"categories":["pinephone","pinephone-pro"],"contents":"\nThe PinePhone \u0026amp; PinePhone Pro keyboard case and add-on cases are now available in the Pine Store!\nGo to store\nAbout the keyboard case The keyboard case works with both the PinePhone and PinePhone Pro and features a clam-shell design. It uses pogo pins located on the phone’s midsection and attaches by replacing the default back cover. When folded, the phone’s screen and the keyboard rest securely against each other. The hinge features a 180° design, which not only allows for two-hand typing on a surface but also for comfortable thumb-typing when fully extended. The etched keycaps can be easily relocated for alternate layouts such as AZERTY or QWERTZ. The keyboard case runs an open firmware, which means that anyone with the know-how can alter existing functions or add new ones. The bottom (keyboard) and top (phone) sections of the assembly are well-balanced thanks to the large, 6000mAh, internal battery capable of charging the PinePhone (Pro) during operation. The internal battery effectively triples the phone’s battery life. The internal keyboard battery can be manually toggled on/off and the keyboard’s battery charge level can be read in the supported OSes; the keyboard remains functional with the battery fully depleted.\nYou do not lose access to the PinePhone (Pro)’s USB-C port, speaker, microphone, or any external features, such as volume and lock buttons, with the keyboard attached. There is also a cut-out for the camera, torch, and headphone jack. The USB-C port on the keyboard is capable of powering both the keyboard and PinePhone (Pro) simultaneously. This means that you can plug in a USB mouse, a USB-C dongle, or some other peripheral while the phone and keyboard’s internal battery charge. Please keep in mind that the keyboard case transforms the PinePhone (Pro) into a PDA, which means that taking calls will likely prove awkward without a wired or wireless headset connected. More information\nTo learn more about the keyboard and its journey please read:\nFebruary Update: Show and Tell May Update: Connection Established September Update: Hurdles and Successes November Update: First Impressions Keyboard case core features\nWell balanced clamshell construction Unbranded and understated design; black shell with dark gray/ matte black keycaps Pogo pin-compatible with PinePhone and PinePhone Pro 180° hinge for two-hand typing on surface or thumb-typing when held Rearrangeable etched keycaps with deep travel Programmable open source firmware by Megi Accessible phone’s headphone jack, USB-C port, volume keys, and microphone 6000mAh internal battery capable of charging the PinePhone (Pro); charge levels reported in OSes that support this feature USB-C charging; capable of charging keyboard case and PinePhone (Pro) simultaneously About the add-on back cases We are simultaneously releasing the much anticipated add-on back cases for the PinePhone and PinePhone Pro. These three cases offer: PineDio (LoRa), Qi Wireless charging and fingerprint reader functionality. Similarly to the keyboard case, these add-on cases make use of the pogo pin interface found on the PinePhone and PinePhone Pro’s midsection. All three cases are made of very sturdy polished black plastic and feature a modular construction. Simple disassembly of the electronic components opens up a gateway for hacking in additional functionality, at least for those of you who are up to the challenge. It also means that the cases are just as repairable as the PinePhone itself.\nMore information\nTo learn more about the add-on back cases and their journey please read:\nApril Update: New Developments May Update: Connection Established September Update: Hurdles and Successes Fingerprint reader case core features\nUnbranded and understated design Sturdy ribbed construction High quality and fast sensor Sensor capable of accepting swipes up/down \u0026amp; left/right Uses open firmware for i2c bridge by Zachary Schroeder Modular, easy to disassemble Hackable design Wireless charging case core features\nUnbranded and understated design Sturdy ribbed construction Qi Wireless and Wireless Power Consortium protocols supported Works out of the box with the PinePhone or PinePhone Pro, no software needed Modular, easy to disassemble Hackable design PineDio LoRa case core features\nUnbranded and understated design Sturdy ribbed construction Uses Semtech SX1262 power efficient LoRa module Software enablement for the PinePhone by JF Modular, easy to disassemble Hackable design Phoptographs by Martijn Braam\n","permalink":"/2021/12/31/happy-new-year-the-keyboard-and-cases-are-here/","tags":["keyboard","pinephone","pinephone-pro"],"title":"Happy New Year, the keyboard and cases are here!"},{"categories":["pinephone","pinephone-pro"],"contents":"\nPeople pick up a PinePhone for the freedom to choose an operating system, to enjoy privacy by default, and to truly own the device they purchase. From the moment a PinePhone departs from our warehouse we no longer have any insight into what happens to it. I frequently get asked questions about PinePhone’s user base, the percentage of people daily-driving it, and the most popular operating systems on our platform. I have no real answers to offer to these questions. Today I am turning to you for help to paint a picture of the PinePhone community by volunteering answers.\nWe’ll let the survey stay up for about a month to get the largest possible sample. Once the survey gets taken down, we’ll crunch the numbers and share them with you in the February community update.\nBefore I let you get to it, PinePhone and PinePhone Pro related news will be dropping very soon, so I encourage you to subscribe to this blog - the subscription widget can be found at the bottom of the page.\nThe poll is now closed.\nThank you to everyone who participated!\nPoll results available here\n","permalink":"/2021/12/29/pinephone-community-poll/","tags":["pinephone","pinephone-pro"],"title":"PinePhone community poll"},{"categories":null,"contents":" Download audio\nIn this episode Justin and Brian recorded live on Discord with the stage feature. This episode covers updates for various mobile interfaces, the MNT reform SOQuartz module adapter, the PinePhone malware, the keyboard addon availability, and more!\nLinks and topics discussed:\nhttps://plasma-mobile.org/2021/12/07/plasma-mobile-gear-21-12/ https://sr.ht/mil/framebufferphone/ https://github.com/GloDroid/glodroid_manifest/releases/tag/v0.7.0-embed-fest-2021 https://gitlab.com/famedly/fluffychat/-/blob/main/CHANGELOG.md https://mastodon.social/@mntmn/107422486591550104 https://fosstodon.org/@danct12/107444234027433862 Music from Bensound.com and Zed (@itismezed)\nhttps://soundcloud.com/kevinflynnretro\nEdited by Zed\n","permalink":"/podcast/s02e04/","tags":null,"title":"S02E04: Behind the curtains"},{"categories":["cube","news","pine64-community","pinenote","pinephone-pro","quartz64","risc-v"],"contents":"\nSeasonal greetings from the PINE64 community team! In the last community update of 2021 we’ll take a look at progress made this year and discuss potential avenues to explore in 2022. As far as news is concerned, we are happy to let you know that the PinePhone Pro Explorer Edition and PinePhone Pro keyboard production is steaming ahead with units available soon. Let\u0026rsquo;s get into 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.\nI’d like to thank JF, Alex (clover), Brian (33YN2), PizzaLovingNerd, CounterPillow and Marek (Gamiee) for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of this month\u0026rsquo;s update\nTL;DR\nHousekeeping Merry Christmas everyone! PineTalk recorder live on December 15 - listen and join us after the show Serious incident with malware made for the PinePhone; a run-down of what happened and steps taken A look back at 2021 Component shortages, logistics hurdles and brown-outs; a difficult year to manufacture and introduce new hardware to the market Introduction of Quartz64-line of devices, including the PineNote Crucial year for laying foundations for PineDio LoRa devices and peripherals The introduction of the PinePhone Pro High LCD prices stalled Pinebook Pro and PineTab production for much of the year A sneak peak at 2022 The RK3588 will be announced at Rockchip’s event tomorrow and it\u0026rsquo;s looking great We’re pushing to bring PineDio to the Market ASAP; this is our main goal for early 2022 A small, but super cool, mystery project will be announced in Q1 We are interesting in exploring RISC-V architecture; something we may tackle in 2022, if production / component availability permits PinePhone Pro Developers have been getting their PinePhone Pro (PPP) over the past 2 weeks; positive response and good software progress means we’re proceeding With PPP Explorer Edition Explorer Edition edition available soon for $399 Great software progress: modem, voice calls, LTE data, audio output, torch and LED all work now OS images available include: postmarketOS, Manjaro, DanctNIX (Arch), Mobian and NixOS Small spec-bump since announcement - production PPPs have a higher resolution 8MP front-facing camera PinePhone (Pro) hardware Keyboard is in production and should be available in a few weeks, likely in early January PineDio LoRa back case will be in Pine Store soon; thanks to efforts from devs it now works Fingerprint back case progress made and QA OS image for factory delivered; likely release in Q1 2022 PinePhone (Pro) software KDE Plasma Mobile 21.12 release brings a change from Ofono to ModemManager Plasma Mobile’s new release includes many new UI improvements and resolves some pesky bugs Quartz64 Linux 5.15 brings Quartz64 device tree Quartz64 now outputs video via HDMI at 1080p 60hz for now; audio out via SPDIF also works out of the box GPU works using the Panforst open driver Tianocore EDK II implemented and allows for full UEFI PineTime Car game utilizes PineTime accelerometer for steering; awesome demo of the device’s hackability Many features coming to InfiniTime: BLE bonding with a PIN code to establish encrypted secure communication with the smartphone (or computer) BLE filesystem API allows access to the PineTime’s internal filesystem via BLE PineDio PinePhone PineDio LoRa back case works and can receive messages from other devices PineDio PinePhone back case is coming to the Pine Store soon Work carried out on new PineDio STACK prototypes PineCube Work on reverse engineering the H.264 encoder driver for the PineCube SoC underway A new closed-source H.264 driver works with the mainline kernel; can be used in the meantime Housekeeping Thank you to everyone who contributed to the projects in 2021. I particularly want to thank our admins, Matthew (Fire219) and Marek (Gamiee), for their work. For those who don’t know, they are the people who put out the occasional fires and make sure that the cogs of the project keep turning. And a big shout-out to the moderators, who are doing a great job keeping our communication protocols clutter-free and safe. I also want to thank all of our partner projects - Manjaro and KDE in particular - for their work on our devices and their commitment to our shared community. I cannot forget about all the contributors, whom there are too many to mention individually, that make projects such as the PinePhone (Pro), the PineTime, and PineDio possible. Lastly, I want to thank all of you in the community for actively supporting us - I hope we did right by you yet another year. My best wishes to everyone - have a great holiday season. This month’s PineTalk will be recorded live on December 15th. Brian (33YN2) and Justin (Porky) will be using the ‘stage’ feature on Discord, found at the bottom of the server’s channel list. I encourage you all to join in, ask questions and stick around afterwards for a chat with the hosts and other community members. In case you miss it, the episode will be available in an edited format a few days later on the podcast streaming platform of your choice, as per usual.\nNotification about the malware was issued in the News channels and in the chat platform - top: Telegram // bottom: Discord\nLastly, I want to address a serious issue that transpired last week. A malware was shared in the chats, with the perpetrator claiming that it is a snake-type game and asking people for feedback. The malware has been made specifically for the PinePhone, wiping the phone’s file system and targeting a known vulnerability of the vendor’s modem firmware. It is important for me to note that the malware requires you to manually download and install it using root privileges (sudo). Here is a short run-down of what we did to mitigate and investigate this situation:\nRemoved malware from chat and banned offending account(s) on more than one occasion Carried out an internal investigation of the incident Consulted Hacker Fantastic from Hacker House and received further assistance as well as a suggested course of action Secured website(s), the forum and Wiki; this includes more stringent rules for file uploads and additional screening of packages Deployed mitigating countermeasures to the chats and other communication protocols Notified our user base Having gathered the necessary information, authorities were informed of the incident - a formal investigation is underway and involves two law enforcement agencies I am not going to go into more detail at this time, but I will keep you informed once the case reaches an end. What I will say is that we have good reasons to believe we can bring this to a satisfying conclusion. Before I head onto the next section, let me state the obvious: be cautious when installing software from unknown repositories onto your device.\nA look back at 2021 This was a gratifying but difficult year. At the beginning of the year, we initially believed that the worst was already behind us. As it turned out, however, 2021 proved to be even more challenging than last year. Component shortages, price-hikes of electronic parts, shipping hurdles caused by ongoing pandemic mitigation strategies, and production difficulties caused by state-imposed power consumption limits; are just some of the things we had to tackle this year. The circumstances forced us to prioritize and focus on the things that we could actually deliver. Although this may seem like a straightforward strategy to adopt, in reality it wasn’t. Figuring out what will be available, how much it will cost, and where it can be manufactured, was a complex jigsaw to solve. Regardless of the circumstances, there was a sense that we need to press on rather than wait until things take a turn for the better. With the year 2022 looking only marginally better than 2021, I think this was a painful but good strategy, as waiting it out is clearly not an option. As if component shortages and pandemic mitigation measures weren\u0026rsquo;t enough to cripple production \u0026hellip;\nThree decisions were made early on in the year: to introduce single board computers and devices based on the RK3566, to start working on our own LoRa-based communication platform, and to bring a higher-end PinePhone to the market. The Quartz64 model-A was unveiled in February and was made available two months later. In June we introduced the SOQuartz compute module, which started shipping to developers and early adopters just recently. Both devices were met with much interest (I’d go as far as to say that the SOQuartz is very popular) and software enablement for the platform is proceeding quickly. The promising pace of software development also convinced us that now is the right time to introduce the PineNote - an e-ink device based on the Quartz64-line of single-board computers. PineNote’s announcement is something many in our community have waited years for and, with the RK3566 SoC being a perfect fit for the job, we launched production. An adapter for the MNT Reform laptop with SOQuartz installed (our best wishes to Lukas and the team) - picture via MNT Reform Twitter\nThis year we also announced our plan for a LoRa-based communication platform called PineDio, which will allow all of our devices to communicate over vast distances without the need for a GSM/CDMA modem. We have a long-term commitment to the PineDio ecosystem, and I’ll talk more about it in the following section, but suffice to say I am very impressed by the progress made this year; I am looking forward to seeing PineDio deployed across the globe. Lup Yuen Lee documents in detail PineDio development on his blog - picture via Lup\u0026rsquo;s Twitter\nLast, but certainly not least, we announced the PinePhone Pro in October this year. This is certainly one of the most anticipated devices we’ve created. We worked on the PinePhone Pro for over a year prior to making the announcement, and the process of bringing it to the market was no simple feat. We tried at least three different hardware configurations before settling on the final device design. Hardware development proved particularly difficult due to various components drifting in-and-out of availability - making it hard to determine production viability in 9 month’s time. Uncertainty was high throughout the process and the decision to proceed with production was made just a month prior to the announcement. Only once all components and factory floor-time were secured did we feel like it was safe to launch the PinePhone Pro. One benefit of these circumstances is that it has only been 2 months since the announcement, and we have already shipped units to developers, and will be shipping the Explorer Edition in just a few short weeks. One out of many PinePhone Pros in the wild - source on Twitter\nConcluding this section, and for the sake of diligence and fairness, it is also important to note that we didn’t manage to produce more than a single production run of the Pinebook Pro this year. The reason for the prolonged halt in Pinebook Pro and PineTab production is related to the elevated price-point of LCD panels. Even with the current price increase of the laptop, we could not cover the production and assembly costs with a good quality LCD (something that the Pinebook Pro is known for). The price of LCD panels has remained high throughout the year but recently we saw some indications that prices may gradually start coming down; this makes us cautiously hopeful that production can resume soon after the Chinese New Year. To this end I want to make it clear to everyone - the Pinebook Pro, in its current configuration, will keep on being produced, and production will start as soon as we can source panels at a reasonable price. I’ll write more about this in the next section.\nA sneak peek at 2022 The year 2022 will be, by and large, all about the PinePhone Pro and the Quartz-line of devices. By this time next year - granted no disaster strikes - there ought to be (tens of) thousands of active PinePhone Pro users worldwide as well as a significant number of PineNote testers and developers. We also hope to bring back the Pinebook Pro and PineTab after the Chinese New Year that is celebrated at the start of February 2022. LCD prices have been coming down in price steadily these past months and we expect to see broader availability of affordable panels soon. We are looking forward to having the Pinebook Pro and the PineTab in stock just as much as you do. Lastly, Rockchip will finally be introducing the RK3588 on December 16th (which means I can’t write about it on the day the update goes live - sorry), which will most certainly be of interest to us. What I will say is that it will bring entry-level desktop-class Arm CPU performance and plenty of IO options; keep a lookout for press coverage of Rockchip’s event.\nkeep an eye on Rockchip\u0026rsquo;s press release website\nWhile the prospect of a high-end computational device is certainly exciting, it also isn’t at the top of our to-do list. Something that is on our agenda however, is launching our LoRa range of PineDio devices. JF and Lup, as well as a handful of other developers, have been working on the PineDio gateway and device nodes for much of this year. Thanks to their efforts (most of which have been well documented in the community updates) the PineDio platform has now reached a significant degree of maturity. RTP has recently contributed a dedicated Armbian-based build for the PineDio gateway, which makes the initial setup and operation simple. I don’t currently have any firm dates for the roll-out, but we should have a preliminary timeline established by the end of next month. https://www.youtube.com/watch?v=bustSeT2QEg\nA look at the PineDio gateway OS image - via RTP Privacy Tech Tips on Youtube\nAt the start of 2022, we will also be introducing a cool small project into our lineup. Let me first clarify what ‘small’ means in this context: a small project is limited in scope and completely community-driven. Examples of such existing PINE64 projects include the Pinecil and PineTime. Small projects benefit from two things: 1) software for them can be completed to a high degree of satisfaction in a short(er) period of time; 2) and we can do them better than big brands for less. The Pinecil, in particular, has shown that we can upset a stagnant market by introducing a better and open device for half the price of existing options. This time, however, we’re hoping to bring something that can be enjoyed by enthusiasts and mainstream customers alike. It will be the first open device of its kind (to my knowledge) and we’re making it from the ground up with the help of experts. There will also be a dev board for it, which will likely be released at the same time as the device itself. This is all I can say right now, but an announcement should follow in Q1 2022. Another area we wish to explore next year is RISC-V. It shouldn’t come as a surprise that RISC-V SoCs are of interest to us, as we have already spoken about plans for an entry-level RISC-V SBC in the past. While our plans to use Allwinner’s RISC-V SoC stalled, our curiosity in the platform has not waned. We’re interested in both microcontrollers as well as much more powerful Linux-capable SoCs, and we are already drawing up plans on how each type can be used in novel and innovative ways. As is usually the case, the journey will likely begin with a development platform and eventually make its way into enthusiast-grade devices. These devices will likely not appear anytime soon, however, so don’t hold your breath. In any case, if the supply line and component shortages subside, we’ll surely be taking a close look at what RISC-V can offer the PINE64 community.\nLastly, we will be working towards improving the global shipping times of the most popular devices. I don’t want to make any promises at this point - I just wanted to let you know that we’re exploring an option that would potentially allow us to ship globally regularly. We’ll start slowly, probably with the PineNote, due to the relatively lower volume of sales compared to our smartphones and laptops. If the dispatch option turns out to work well, then we may start using it for other devices. We’ll also await your feedback. I’ll make sure to keep you posted.\nPinePhone Pro By the time this update goes live, you will likely have already seen countless developers posting photographs and videos of their PinePhone Pro units. The task of sorting, issuing and shipping developer’s orders was carried out within the time frame we initially aimed for. I am happy to report that much of the early feedback has been very positive: developers find the unit fast, easy to work with, and well-executed. It also appears there are no major flaws in the design. We are, therefore (still) aiming to open PinePhone Pro sales late this month or early the next. The price of the Explorer Edition remains unchanged - $399. The exact availability date will depend on how quickly we can establish a viable QA testing methodology at the factory; QA testing hurdles make for a boring story so I’m not going to describe the ordeal, but if you want to learn more then leave a comment below and I’ll respond with the details. The take-away is that it shouldn’t be long now. I will publish a blog post when the PinePhone Pro becomes available for purchase. The Explorer Edition launch blog entry will include detailed information about the device and software maturity so that everyone ordering a unit will know exactly what they’re getting (into). I don’t want people expecting full functionality picking up a PinePhone Pro at this time, instead, I‘d like to see well-informed early adopters who are willing to engage with the community and contribute to the development process. Porting of OSes has started - screenshot of Software Releases section on Wiki\nIf you fall into the category of a competent early adopter, then I am glad to say you’re in for a treat. Last month I listed 5 things needed to reach software parity with the original PinePhone - today we can already cross 3 of these off the list. The following are now functional: 1) USB for data and video, 2) sound output and, 3) modem including voice calls. Credit for these enablements go to A-Wai from Mobian and Megi; obviously, neither of them develops in a vacuum, and input from other developers contributed to these features now being functional. Even little things, such as the torch or notification LED now work. Mind you, these implementations are in a preliminary enablement stage, and regressions are to be expected at this development stage. More importantly, however, this means that the main outstanding missing core features are the cameras and power management improvements. The latter also includes finding a solution for the smartphone’s failure to wake from suspend. There are other, smaller, issues that need to be addressed, but from an end-user perspective, these are the major two. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Audio now works on the PinePhone Pro - via Manjaro dev team\nThere are now postmarketOS, Mobian, Manjaro, DanctNIX (Arch) as well as NixOS OS images for the PinePhone Pro. Some of these can be found on the PinePhone Pro docs, whilst others - like Mobian - are yet to be added to the list (but can already be found on the project’s repositories). I am sure that more OSes will follow shortly - indeed, some may already be available by the time you’re reading this. As was, as still is to some degree, the case with the original PinePhone, there will initially be discrepancies between functionality across distributions. Things that work on one OS will not work on another and vice versa. These differences will eventually fade and a similar experience will be available across the board. But this will take time. I have been using my PinePhone Pro daily for over a month now, mostly running Manjaro with KDE Plasma Mobile, and I can see myself dumping my Android in the future (once resuming from suspend works). Needless to say, I am very pleased with the software progress and the hardware itself. My assessment is obviously biased, but thankfully there are already plenty of hands-on accounts available for you to make your own mind up whether this is your future daily driver or not. Some devs already do really fun things with the device to showcase its raw power, as illustrated by the emulation of GameCube. Honestly, this exceeded my expectations. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video GameCube (Dolphin) emulation on the PinePhone Pro is pretty crazy - via FOSSingularity on Twitter\nThere is one more thing I’d like to touch upon - the final design of the PinePhone will feature a higher-end (8MP) front-facing camera than originally (5MP) planned. The rest of the specs remain the same, just as they were initially announced. This is a small and likely relatively insignificant spec bump, but it is also something I have to make you aware of. Information on the device page and Wiki should now also be updated to reflect the upgraded hardware. For those of you who want the specifics: the camera is an ov8858 8MP 1/4-inch sensor, known to produce good quality pictures. Anticipating the question: yes, the current dev units already have this camera module installed. I am told that it is a significant step-up from the sensor (OG PinePhone’s main camera) in every sense of the word - consider it a small bonus.\nLastly, I have put in some initial work to draft a Wiki layout for the PinePhone Pro (which I closely modeled after the original PinePhone’s Wiki), and I am happy to see people already contributing content. I would like to encourage all of you who have already received their PinePhone Pro and those who will soon be receiving one soon to fill in as many outstanding information knowledge blind spots as possible. Anyone can create a Wiki account and contribute content to any section, and if you are registered on the forum your existing credentials should work. The more of the basics we can collectively cover at this early stage, the better the experience Explorer Edition users will have with their devices. Thank you!\nPinePhone (Pro) hardware The PinePhone keyboard and LoRa PineDio back case will be available in the Pine Store shortly - likely at the very beginning of January. I already described the reasons why the keyboard was delayed at the last moment in the November update; long story short, both the developers and production team weren’t completely satisfied with the keyboard’s membrane. Consequently, the vendor was asked to improve the responsiveness and consistency of the key presses. Given how the keyboard has now already been in prototyping and testing for over 6 months, another few weeks to get it just right is a small price to pay to deliver a better piece of hardware. And we really want to get it right from the get-go rather than having to revisit design choices in the future. That said, I do apologize for the delay, and I am very aware that many of you are growing impatient. The good news is that we’re having many keyboard units manufactured, so the chance of us selling out in a very short amount of time is slim to none. In other words, everyone who wants one will be able to pick one up. DanctNIX (Arch), postmarketOS, Manjaro, and Megi’s multiboot OS images have all been updated to support the keyboard at this time - there may be others that I’m not aware of, please check with your OS maintainer.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video p-boot now has portrait mode - via Megi\nThe PineDio back case is now functional thanks to work done by JF and Lup. It will be available in the Pine Store soon, as early as next week. I won’t be writing more about the PineDio back case in this section, since I am sure JF will cover the key developments further down in this community update (you may also want to read last month’s update for more PineDio news). I am super thrilled that the back case will be available by the time the PineDio gateway hits the store. Since we’re on the topic of back cases, then I am also happy to report we’ve also made progress on the fingerprint back case. Zachary, the community developer behind the first fingerprint reader prototype, delivered a custom QA fingerprint sensor testing OS image to be used at the factory floor; if the factory finds this build sufficient for testing purposes then we may finally see the fingerprint reader back case launch in Q1, 2022. PinePhone (Pro) Software [by 33YN2] Plasma Mobile has seen some major changes that have now been released in the Plasma Mobile Gear 21.12 release. The biggest is that it now has fully switched over to using ModemManager for telephony functionality. It also now has support for MMS messages in its SMS app, and additionally the SMS application now automatically detects links and 2FA codes and gives a copy shortcut to quickly copy them to your clipboard. Aside from the telephony changes, the shell itself has seen lots of work. Not only will the buttons now move to the right-hand side of the display when the device is rotated into landscape mode, but it also now has the new list view app drawer layout. The task switcher has also seen a major redesign, with a more efficient card style similar to that which is used by Lomiri. This is far from the end, however, there are more improvements and fixes coming for the new task switcher, and more to be done to the shell too. Make sure to check out the Plasma Mobile Gear 21.12 blog post for a more detailed look!\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Showcasing performance of an early build of Manjaro with Plasma Mobile on PinePhone Pro\nQuartz64 [by** CounterPillow**] A lot has happened this past month in terms of Quartz64 software. Linux 5.16 finally has the Quartz64 Model A device tree, which describes the Quartz64 Model A\u0026rsquo;s hardware and allows the mainline kernel to actually boot on the board completely out of the box, without patching needed. But the biggest news is probably the VOP2 patch set, enabling video output on the RK356x family of SoCs, of which the Quartz64 uses the RK3566. It\u0026rsquo;s in a very rough state; its internal state tracking logic is broken, the frame presentation is buggy, and it only supports 1080p monitors at 60 Hz at the moment, but it\u0026rsquo;s great to finally see movement on this front.\nHDMI output on Quartz64 model-A\nThe patch set comes courtesy of Sascha Hauer, whose work is based on the downstream Rockchip BSP kernel\u0026rsquo;s driver. A small follow-up patch by Michael Riesch to enable it on the Quartz64 Model A has also been contributed. Both Manjaro and pgwipeout\u0026rsquo;s CI Debian installer already have the patch set applied, which allows people who are interested in the board to have a go at it without having to patch their own kernel. We still recommend you have a UART adapter such as PINE\u0026rsquo;s Woodpecker to troubleshoot any issues. It\u0026rsquo;s only $1.99. Don\u0026rsquo;t have regrets.\nIn terms of booting, Jared McNeill ported Tianocore EDK II to the Quartz64 Model A, which means that there is now full UEFI available. The port is still in an early stage, but it\u0026rsquo;s an exciting move towards getting the board ARM SystemReady certified. The port still requires Rockchip\u0026rsquo;s firmware blobs, however, as Rockchip has yet to release the ARM Trusted Firmware sources for the RK3566 and RK3568. At the same time, pgwipeout has begun tinkering with mainline u-boot. Albeit there is some manual hackery and binary blobs involved, he managed to get mainline u-boot running. This is another promising route towards a better booting experience on the board. He also experimentally ported the mkimage utility changes over to the mainline version.\nVM on the Quartz64 - via Jared McNeill on Twitter\nAs for the Linux kernel, I have been doing a bunch of small work here and there. SPDIF audio works in kernel 5.16 right out of the box on the Quartz64, if you\u0026rsquo;re into that. Analog audio works as well, thanks to the i2s-tdm audio controller driver I\u0026rsquo;ve ported. As soon as the VOP2 patch set dropped, I also got to work on HDMI audio, which works, but isn\u0026rsquo;t merged yet because the VOP2 patches aren\u0026rsquo;t merged either. We depend on the HDMI output and a video clock to get HDMI audio, so there\u0026rsquo;s a dependency on that patch set. Additionally, I submitted the SPI nodes to the RK356x device tree, which means that starting with kernel 5.17, people will be able to simply enable the SPI node in the Quartz64 device tree and add their SPI device definitions to it.\nRockchip\u0026rsquo;s engineers have been very busy with unspecified other projects, but they have submitted some patches to the Linux kernel as well. The naneng combo PHY, which handles the physical interface for SATA, USB 3, and PCIe, has been submitted for review by Yifeng Zhao and is currently in its third iteration. pgwipeout\u0026rsquo;s Quartz64 CI kernel has this patch set applied too. Sugar Zhang of Rockchip has also contributed some SPDIF driver updates to make it work with the newer Rockchip SoCs.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Slightly patched kmscube showing a shadertoy shader\nOh, did I mention yet that the GPU works? Yes, the GPU works. Alex Bee took over Ezequiel Garcia\u0026rsquo;s GPU enabling patch set, and with a recent enough version of Mesa, you\u0026rsquo;ll have working 3D acceleration. It can even thermally throttle now, in theory, but in practice, the GPU doesn\u0026rsquo;t really get hot enough. In my stress tests with a medium heatsink on the device, the GPU never got hotter than 45°C (around 25°C over ambient.) Thanks to the VOP2 patch set, a couple of bugs have been found in other drivers. Alex Bee discovered a bug in the IOMMU driver that made video output fail on 8GB boards. This was fixed during the Linux 5.16 bug fixing cycle, so now the video output will work on all Quartz64 boards, no matter the amount of RAM.\nI\u0026rsquo;ve also discovered a bug while working on the VOP2-prompted HDMI audio patch set, namely that my i2s-tdm audio controller driver wasn\u0026rsquo;t happy being loaded multiple times. Oops. I\u0026rsquo;ve fixed this in Linux 5.16. Many of these improvements will of course affect the PineNote, as it uses the same SoC: if somebody adds something to the RK356x device tree, it\u0026rsquo;ll also be available to the PineNote device tree that smaeul wrote. As always, you can track our continued progress on the Quartz64 Development Wiki page which I try to keep as accurate and up to date as possible.\nPineTime [by JF] Remember when last month I mentioned this nice demo from Petterhs, showing him controlling a 3D object using the motion sensor of the PineTime? Peter has now extended this demo which now allows him to control a car in a car racing game. I really enjoy such demos, since they showcase how hackable PineTime is and how endless the possibilities are!\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video PineTime as a game controller\nInfiniTime developers and contributors are working on a few great features for the project. I won’t go into the details right now since we are still working on them, but here is an overview of what you can expect in future releases of InfiniTime.\nFirst, the secure BLE bond. This feature, contributed by evergreen-22, enables BLE bonding with a PIN code that establishes a secured (encrypted) communication. I did check that the communication was actually encrypted using my sniffer setup. The screenshot below on the left shows a \u0026ldquo;sniffing\u0026rdquo; session from a PineTime running InfiniTime 1.7.1. As you can see, everything is visible in plain text: BLE commands, characteristic handles and notification content (\u0026ldquo;Hello world\u0026rdquo;). The screenshot to the right shows the same scenario but running on a build which includes this new feature. Now we no longer can make out of the content of the BLE messages:\nLeft: unencrypted connection // Right: encrypted connection\nThe next massive feature is the **BLE filesystem API**. Geekbozu implemented this API which allows companion apps to access the internal filesystem of InfiniTime. For now, this filesystem is only used to store user settings, but the end goal is to also store pictures, logos, fonts, translations, and much more in the memory. This feature is a major step toward reaching this goal. As a demo, I sent multiple random pictures to my developer PineTime and used them in a custom build of InfiniTime as the background of my clock:\nBackground pictures set via BLE filesystem API\nNote that those features are not stable yet, and therefore we have not released them in a public version of InfiniTime. They are however available in the develop branch of the project and everyone is free (and welcome) to test them and provide feedback!\nThat\u0026rsquo;s it for this month! I wish everyone a Merry Christmas, a happy new year, and happy unboxing for those of you who\u0026rsquo;ll receive a PineTime as a Christmas gift!\nPineDio [by JF] As you probably know, the PineDio range of devices aims to deploy LoRa (Long Range low-power wireless communication) everywhere and across all PINE64 hardware . We have already talked about the LoRa PineDio gateway, the USB adapter, and the PineDio STACK (development kit based on the BL604 microcontroller) in previous updates.\nDid you know that Pine64 is also working on a LoRa backplate for the Pinephone? This backplate will allow the Pinephone to send and receive LoRa messages thanks to the integrated LoRa module and antenna.\nPinePhone (Pro) PineDio back case disassembled - a close took at the LoRa antenna\nThese last few weeks I worked on bringing this backplate up and running, and succeeded in receiving LoRa messages from other LoRa devices. This is still mostly a work in progress, but it clearly shows that the integration of LoRa in a mobile phone running Linux is possible and, indeed, already functional! For those interested in the technical details, I documented everything in this series of 3 articles: First look at the LoRa backplate, Flashing the LoRa backplate and A driver for the LoRa backplate.\nSee the video here\nReceiving LoRa messages on the PinePhone with PineDio back case\nNote that the LoRa backplate is not available yet in the store, but Pine64 is actively working on it and even requested software to test the board in production, so they will probably be available in the near future! [edit from Lukasz] Indeed, with the software now in a functional state, we will be starting to sell the PineDio back case for the PinePhone and PinePhone Pro in the next few weeks. On a similar topic, Lup Yuen Lee is currently working on bringing NuttX to the PineDio STACK. He also documented the testing of the new prototype version of the STACK we received last month. This new prototype comes in an enclosure and is equipped with GPS and a motion sensor in addition to a display and a LoRa module.\nPineCube [by Gamiee] As we have seen in previous community updates, the PineCube is already very usable with software MJPEG encoding. But it\u0026rsquo;s still not perfect, since software MJPEG encoding uses a lot of CPU power and, but to the PineCube’s single ARM Cortex-A7 core, not much power is left to other things. Because of this, PineCube\u0026rsquo;s SoC has a hardware H.264 encoder core, which can encode video with minimal impact on the CPU. But for this core to be functional we need a driver. The current driver is closed sourced and doesn\u0026rsquo;t work with the mainline Linux kernel; it only works with ancient Linux 3.10 kernel. So I started to reverse-engineer this driver, and I\u0026rsquo;m creating an open-source implementation of it; you can track the progress of this project and learn more about it here.\nWhile I was working on this project I learned a lot about how the whole driver and encoding core works. But I also found newer drivers, which can work on the mainline kernel with some modifications. So I modified and built the latest Linux 5.15 kernel, prepared the Debian root filesystem, and tried to see if the drivers would work. And it did!\nPineCube running mainline Linux kernel\nSo in the meantime, while I work on an open-source re-implementation of the driver, the PineCube can have hardware accelerated H.264 encoder using a modified closed source driver. Since I didn\u0026rsquo;t have enough time to test it fully it remains uncertain if popular libraries like FFmpeg or GStreamer will be capable of using this driver, but it should work and I will let you know in the next community update about the progress made.\nThat\u0026rsquo;s it for this month, Happy Holidays everyone!\n","permalink":"/2021/12/15/december-update-a-year-in-review/","tags":["keyboard","pinecube","pinephone-pro","pinetime","risc-v"],"title":"December update: a year in review"},{"categories":null,"contents":" Download audio\nIn this episode Justin and Brian talk about this week’s software improvements coming to PINE64 devices, discuss the keyboard some more, and talk about the future of Mobile Linux.\nLinks:\nhttps://linuxrocks.online/@ManjaroARM/107293939046484672 https://aspiechattr.me/@ManjaroLinuxBot/107283210032486227 https://github.com/InfiniTimeOrg/InfiniTime/releases/tag/1.7.1 https://nitter.net/ManjaroLinux/status/1458102366310477837#m https://nitter.net/salva_lieb/status/1460035543983611905#m https://gitlab.com/postmarketOS/megapixels/-/tags/1.4.0 https://fosstodon.org/@tuxdevices/107291616567947744 /documentation/General/Overclocking/ Music from Bensound.com and Zed (@itismezed)\nhttps://soundcloud.com/kevinflynnretro\nEdited by Zed\n","permalink":"/podcast/s02e03/","tags":null,"title":"S02E03:  Performance, UIs, the Keyboard, Oh My!"},{"categories":["cluster","community","news","pine64-community","pinedio","pinephone-pro","pinetime","soquartz"],"contents":"\nIs it truly November already? Is it just me, or is this year flying by at warp speed? This month’s update focuses on initial impressions of the PinePhone Pro and production keyboard. We\u0026rsquo;re also going to take a look at the SOQuartz Blade hostboard and discuss InfiniTime 1.7 release. But before we get into it; next month I plan on doing a recap of the year 2021, similar to the one from last year, so make sure to stay tuned for that. 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.\nI’d like to thank JF, Alex (clover), Brian (33YN2) and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Community update video synopsis\nTL:DR Housekeeping We’ve made efforts to curb spam in the chats, you should be seeing less of it from now on We’re considering making an in-person PINE64 community meetup mid-2022, would you attend? PinePhone Pro Dedicated this month’s section to first impressions of the PinePhone Pro A look at small previously undiscussed design changes from OG PinePhone SoC does run warmer than OG PinePhone’s, but heat doesn’t transfer to person using the phone Its fast, very fast Packaging from recycled cardboard and plastic PinePhone (Pro) keyboard Available next month for $49.85 We’re fixing membranes (again) following feedback from early production units Initial impressions of hardware - quite a few things changed since prototypes Open firmware works out-of-the-box on OSes that support it SOQuartz In case you missed it, the SOQuartz launched last month Introducing the third SOQuartz hostboard - the Blade Blade hostboard to be used in 1U server racks; can be stacked for clustering PineTime Release of InfiniTime 1.7 New motion sensing allows for faster wake-on-lift New motion sensing can be used as a motion controller; someone interested in making a game? Step data now being tracked in Amazefish and other apps; and many other optimizations New members joins the team PineDio Ongoing development report - a dev update New OS image with Chirpstack LoRaWAN stack and TTN support available New PineDio STACK prototypes on the way Housekeeping Not unlike most other online communities, we’ve been waging war with spammers for some time. Spam is, and likely will always be, a part of chats and forums, and while it is always annoying (and sometimes offensive), until recently it was merely a nuisance rather than a plague. These past 8 weeks, however, the volume of spam across different chats significantly intensified, which resulted in Matthew (fire219) spending much time on dealing with the situation. We now have a fairly robust multi-faceted system on each of the platforms, which insofar seems to be doing a good job at keeping automated spam and unwanted accounts out of our community. While no system is 100% foolproof, you will see much fewer spam in the chats from now on. As most of you know, we usually make FOSDEM our yearly PINE64 community get-together. This year FOSDEM has once again made the decision to make the event virtual, which has prompted us to consider scheduling a dedicated PINE64 meetup in 2022. We’re thinking about the May-July timeframe, somewhere in the heart of Germany. How many of you would / could attend this event? Please let me know by answering this forum poll. If enough of you declare interest, then by next month I’ll try to schedule something together with TL Lim. Before anyone asks - the meetup will surely also have a virtual component for our community members in Asia, North/ South America and Oceania; I know that pancontinental travel is still difficult or outright impossible for some. Lastly, I’m aware most of you read the October update introducing the PinePhone Pro, but some of you have likely missed the follow-up I wrote late last month. I suggest you go back and read it as it contains some information that will contextualize a few of the things I write in this community update. The follow-up also included news about the PineDio, the PineNote and an announcement that the SOQuartz compute module is now available for sale - give it a read. PinePhone Pro First, a quick note for developers. We closed the PinePhone Pro pre-orders two weeks ago since the number of applications far exceeded available dev units. We’re hoping to start issuing coupons this week. The reason for the delay in issuing coupons was a mainboard layout issue with the pogo pins, which was identified during QA. A fix for this was quickly found, but all PCBs had to be returned to the factory - hand soldering on all units would be too time consuming. This should not affect our December shipping time-frame, nor the Explorer Edition. This does, however, limit your pre-order coupon validity window - from the moment you receive the coupon you’ll have 3 days to finalize your purchase. I’ll notify everyone when coupons start going out, so you know to check your email inbox regularly. Keep an eye on the Telegram/ Discord news channels and our Twitter/Mastodon accounts. This month, I have dedicated this section to my first impressions of the PinePhone Pro. At the time of writing I’ve only had the device for two days, the first of which I spent debugging an issue with the touch controller. Megi was able to patch the issue quickly however, and I haven’t been able to put the device down since. Obviously everything I am about to write is fundamentally biased, but I will stand by every word I write - no PR-speak, I promise. The device is fast, very fast when compared to the original PinePhone and other similar devices. I haven’t tried Linux on a recent mid-to-high end Android smartphone, and I am curious how the experience stacks up against something like the One Plus 6 in the UI. Judging Caleb’s videos of the OnePlus 6T, the UI’s responsiveness is indistinguishable from the PinePhone Pro. I’m sure they’ll confirm or rectify my observation once dev units ship.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video A quick look at PinePhone Pro\u0026rsquo;s performance\nUI animations are perfectly smooth, applications open nearly instantly (Firefox opens in under 4 seconds on an OS running from SD card), scrolling in the web browser or interacting with elements of an application results in an immediate input reaction. For a lack of a better word, everything feels instant on the PinePhone Pro. Something as trivial and mundane as interacting with the interface suddenly becomes fun. Since there is always someone asking about this - playing 720p Youtube videos works flawlessly and the videos load instantly (1080p will also work fine at 30FPS on an external display). Speaking of videos, there are now a handful of recordings showcasing PinePhone Pro’s performance if you want to verify what I say with your own eyes. Obviously we’re just the very beginning of development, so you can expect the experience to further improve in months to come as software matures and becomes more refined. I am also happy to report that my device doesn’t run hot. Warm, circumstantially yes (mostly in the top quarter of the LCD display), but at no point did I feel it reached uncomfortable temperatures. Indeed, it is my impression that the PinePhone Pro runs cooler than the original PinePhone. I verified this with Justine and Phillip (from Manjaro) who also received their PinePhone Pros in recent days. Justine told me that “(..) [it] does run cooler than my previous [PinePhone] even when compiling packages on it”. I also checked the internal temperature of the device after running an artificial load on all cores for 10 minutes - the SoC reached the temperature of, and remained at, approx. 68*C. The temperature dropped to 58*C after a minute of cool-down time. It then hovered at 47*C after 10 additional minutes of inactivity with just the web browser open and the screen on. It appears that ~55*C is the SoC’s average operating temperature when browsing the web, installing packages, etc. and the temperature is dissipated well by the chassis without one spot becoming exceedingly hot. So, in conclusion, the SoC does get hotter than on the A64 on PinePhone, but it doesn’t feel like it to the person using the device.\nFrom left to right: Temps under load, after one minute and after ten minutes of cool-down I am not going to write about battery life just yet, since the battery and charging kernel driver as well as various settings still need tweaking. Megi told me that the current software will “happily charge out of spec”, which also means that charging to (what the kernel thinks is…) full battery capacity isn’t a great idea. Besides, any numbers I’d provide at this point would be meaningless in 3 months time. Since I already started listing things that need work, here’s the rest of things that currently do not work fully or partially: 1) sound (which also means no…) 2) phone voice calls, 3) cameras, 4) USB for data, video or OTG 5) torch / camera flash. Some of these are already worked on and will be resolved quickly, while others may take longer. While we need to acknowledge that there is a lot of work ahead of developers, we simultaneously have to appreciate how far development on the original PinePhone has gotten us.\nPinePhone Pro with back case and battery removed\nReturning to the subject of the hardware, I have a few observations that pictures or renders cannot convey. The panel is really bright and the colours are rich; the vibration motor is much more powerful than on the original PinePhone; 5Ghz WiFi connectivity has been exceptionally good even when compared with my 2 year old flagship Android phone; and the phone has some heft to it, which is a good thing. There are also a handful of other external changes from the original PinePhone’s design. I’ll omit the big and obvious things that you can read about on the PinePhone Pro’s main page, and instead focus on some tiny details I previously omitted to mention. The thermal pad on the back case is much larger and appears to distribute the heat well. The battery is different and is labeled with the new phone model. The sim card and SD slot are slightly different as are the buttons at the leading edge of the phone (they have a more distinct actuation point). Lastly, the WiFi / BT antenna layout on the midframe has been altered for 5GHz connectivity. Before moving onto the next topic, the packaging is made out of recycled material, including all of the cardboard and most of the plastics. I know that it matters to many of you in the community, so I felt it is worth a mention. Lastly, as always, I suggest you follow Megi’s blog for software-related and other PinePhone Pro news. PinePhone Keyboard The keyboard has now been scheduled for release next month, in December. The delay is caused by a fix that will need to be applied to the keyboard’s membrane following feedback from developers who received production samples earlier this month. I know that many of you have been waiting for the keyboard for a long time, and I understand that the wait is annoying, but we want to make sure to both account for developers\u0026rsquo; feedback and to deliver the best possible PinePhone (Pro) keyboard that is possible. Notification about the keyboard going on sale will be made on Telegram/Discord news channels, the official forums news section, on our official subreddit as well as Twitter and Mastodon. The keyboard will be priced at $49.95. PinePhone (Pro) production keyboard fully extended laying flat\nI\u0026rsquo;ve now had a couple of days of hands-on time with the production version and figured I’ll share my experience with it. Despite having already written about the keyboard in the past, covering the production model in depth is warranted since surprisingly many changes have been made since the final pre-production model. This applies to both surface-level and electronic changes. The keyboard received a final layer of polish and it shows - there are no more sharp edges and I no longer can make out mold lines no matter how close I look. The production case finish is best described as semi-soft and very smooth, making it a joy to hold. On the downside, as compared to the pre-production units that featured a matte finish, it has a tendency to attract more oily fingerprints. If you wipe it down after use, however, it will look as good as new.\nOnce opened, the most obvious difference from the prototypes are the keys. The font is now thick and very legible - the key caps pop even in low light. The keys themselves have a matte black finish. The combination of the glossy case and matte keys is very nice, it really does look great. The rubber domes for the keyboards are black as opposed to white on the final prototypes, making the gaps between keys less apparent. The travel and wobbliness of the enter key has also been significantly improved. But this isn’t all, additional structural changes to the top portion of the keyboard where the PinePhone (Pro) is inserted have also been made. The pogo pin connectors have been slightly raised, assuring that connection is maintained between the keyboard and phone even as the top of the chassis flexes when opening or closing. Speaking of flexing, the top section is now firmer and, in conjunction with the well tuned hinges (they are truly great), the whole contraption feels just right.\nCan you spot the difference? Left: production keyboard / right: prototype As for electrical under-the-hood changes, a concern raised by developers following Megi frying his prototype a couple of weeks ago, resulted in a fix preventing overcharging of the battery. The chip that blew on the prototype was analysed closely and it was established that electrical over stress was to blame. As a result a low dropout regulator, acting as a current limiter, was added to the circuitry. If you didn’t understand any of the above then here is what it boils down to: there is now a counter measure in place so your keyboard or phone do not get electrically damaged. A number of other improvements suggested by the devs have also been implemented - I wrote about this at length in the September community update, so I suggest you (re)read it for more details. Finally, the keyboard’s open firmware worked out of the box on my Manjaro Plasma Mobile and Arch Phosh installations, and I found no firmware-related issues. I haven’t tried the keyboard with postmarketOS, but that should work too out-of-the-box. The keys on the keyboard needed a few minutes of break-in time. Initially some keys would require more pressure to actuate than others; it took a couple of firm presses on all keys to have the membrane settle in for a lack of a better word. Having done the above I experienced no further issues. Following this feedback, and similar experiences reported by developers, we chose to push back the release of the keyboard to improve the membrane so that end-users do not experience such issues when they receive their units. I cannot wait until you receive your PinePhone (Pro) keyboard and share your experience with it. SOQuartz I already spent much time on the SOQuartz and two of its hostboards in last month’s follow-up post, so in this section I’ll be focusing on a new hostboard for the module - the Blade. If you missed the announcement of SOQuartz’s launch, please read the previous blog entry. The Blade hostboard is designed to fit into a 1U server rack and, in a sense, brings the legacy of the SOPine and SOEdge Clusterboard to the next generation of PINE64 modules. More than a dozen Blade hostboards can be housed in a standard server rack, making any cluster compute project highly scalable depending on set requirements. Using the hostboard, new modules can also be easily added ad-hoc to the cluster setup. SOQuartz Blade hostboard (2x) prototypes (Gigabit Ethernet unpopulated in this photograph)\nThe Blade features a Gigabit Ethernet connection, a micro SD card slot, a USB 2.0 header, digital video output, 40x GPIO header, UART output, power barrel jack port and a M.2 PCIe slot for storage. All IO is located at the short leading edges of the blade, allowing for tight stacking inside the rack. Blade’s layout makes for an IO feature rich setup in a very compact form factor. We believe that the Blade, along with the model-A and small form-factor hostboards introduced last month, will offer sufficient versatility to early early adopters for their desired use case. The blade is, however, not the last Quartz board we’re working on - stay tuned. PineTime and InfiniTime (by JF) The InfiniTime team released version 1.7.0 \u0026ldquo;Jackfruit\u0026rdquo; a few days ago. This new version brings a feature many of you were asking for: the possibility to manually set the date and time without the need of a companion application. It is now possible! InfiniTime 1.7 also adds a new \u0026ldquo;motion and step\u0026rdquo; BLE service. This service allows a companion app to fetch the number of steps counted by the watch. To my knowledge, this feature has already been integrated by itd, InfiniLink (previously Infini-iOS) and Amazfish.\nStep-count synced from PineTime to Amazefish on Linux PC\nThis brand new motion service also exposes raw X/Y/Z values from the accelerometer. When I implemented this feature, I wasn\u0026rsquo;t sure how useful it would prove but Petterhs proved the potential of the feature showcasing a 3D cube moving based on PineTime’s position. Who knows, maybe someone will come up with a game that would use the PineTime as a controller?Of course, this isn’t everything that InfiniTime 1.7 has to offer, there are many other features and improvements, make sure to read the release notes for more details. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Controlling a 3D object using the PineTime\nI\u0026rsquo;m also happy to welcome Riku aka Riksu9000 to the team! Riku has already made contributions to many features in InfiniTime and I\u0026rsquo;m really happy he accepted the invitation to join us. Finally, I would like to highlight Nico\u0026rsquo;s blog; Nico writes a lot about SailfishOS as well as PineTime and InfiniTime. On his blog, you\u0026rsquo;ll find many articles about the different releases of InfiniTime, including 1.7 \u0026ldquo;Jackfruit”, as well as a nice recap of all of the project’s release history.\nPineDio by JF We are still working hard on enabling software support for the PineDio (LoRa based) devices. Lup Yuen is writing a thorough article about the PineDio Gateway. This article introduces the gateway, explains how we tested it, the setup and how to connect to TheThingsNetwork (TTN) LoRaWAN public network.\nIn the meantime, RTP provided us with a new image for the PineDio gateway. This new image comes preinstalled with Chirpstack LoRaWAN stack, supports TTN and automatically resizes the filesystem according to the SD card’s capacity. Finally, I\u0026rsquo;ve been told that new prototypes for the PineDio STACK development board were ready and will be sent to me very soon. Stay tuned!\nSneak peak at PineDio STACK cassing fitted with a PineTime display\nThat is all for this month, thank you for your attention!\n","permalink":"/2021/11/15/november-update-first-impressions/","tags":["keyboard","pinephone","pinephone-pro","soquartz"],"title":"November update: first impressions"},{"categories":["news","pinecil","pinedio","pinephone","pinephone-pro","soquartz"],"contents":"\nHappy Halloween! As promised earlier this month, here is the follow-up to the October community update. Some of the topics I’ll touch upon will be covered in more detail in November. I’ll keep this one brief. Housekeeping PineTalk discussed the PinePhone Pro in last week\u0026rsquo;s episode. At the time of writing, it is the most listened-to episode of our community-run podcast, and there is a reason for it - it is a very good episode. I encourage you to have a listen. Earlier this week we had a guest post about the creation of the Meet the PinePhone Pro announcement trailer. If you’re interested in learning how the trailer was made, and which software was used during its production, then I invite you to have a read. Logistics issues in China and the USA have caused a significant increase in parcel delivery times. The USA is particularly affected by the situation. There is nothing we can do about it, but the reason I am bringing it up is due to the increase in support tickets requesting help in tracking down packages (and sporadic claims of packages being lost). All I can do is ask you for patience - it may take a long time, but in 99.9% of cases the parcel will eventually arrive at your doorstep. Lastly, our Discord is about to reach (or already reached) 9000 members, making it the biggest chat platform out of all protocols used by our community. I think this is quite the milestone and I am very happy to see many new faces actively engaging in discussions. I know Discord is frowned upon by some in the FOSS community, so before anyone complains - there are corresponding and bridged channels in Telegram, IRC, and Matrix available for those who wish to use a different platform. Full chat list here. SOQuartz The SOquartz module will be available for purchase in the Pine Store next week. I already covered the SOQuartz in-depth in the June update, so I encourage you to read that blog entry for more information. For those who do not know, the SOQuartz is a module that is pin-compatible with the Raspberry Pi Compute Module 4 (CM4). It will work with existing CM4 baseboards but we’re also creating some of our own. We have a model-A type hostboard - primarily for the purpose of development, with all available IO exposed, but it can obviously also be deployed in different scenarios. There is also a small footprint hostboard with dual cameras, 2x USB 2.0, HDMI and GbE for embedded projects. These are just some of the hostboards we have planned for the SOQuartz, and belive me I’ve kept the best ones for future updates. We\u0026rsquo;ve got some really cool stuff coming that I think many of you will be thrilled to learn about. I\u0026rsquo;ll return to the subject of SOQuartz hostboards in November.\nsmall form-factor hostboard\nModel-A hostboard\nThe module will be available in three configurations: 2GB, 4GB, and 8GB of RAM for $35, $50, and $75 respectively. These prices are for SOQuartz with onboard WiFi/BT (there will be a version without), without soldered-on eMMC (you can install one of our standard eMMC modules). We expect that the introduction of SOQuartz will be well met by our industry partners, but we also have plans to make it an interesting platform for community projects. The hostboards are only a part of the strategy to get the community interested in the SOQuartz - something to look forward to in 2022. PinePhone Pro We have now closed the PinePhone Pro dev unit applications and will start going through purchase coupon applications next week. We have 4 times more applications than available dev units, so those of you who will not receive a coupon at this time will have to wait until the Explorer Edition becomes available later this year. As a side note, I got hands-on time with the PinePhone Pro last week. This is the first time I had an opportunity to see the PPP running Linux - Manjaro with Plasma Mobile in this particular case. As far as impressions over a pint in a pub are concerned, I can say this with confidence: it\u0026rsquo;s very fast. Despite it being an early engineering unit, I didn\u0026rsquo;t encounter any apparent heat or excessive battery drain issues, so things are already looking good. Megi and other developers have been putting in a lot of work into the PinePhone Pro these past two weeks - you can follow Megi’s work here.\nhttps://www.youtube.com/watch?v=ZBgNAbb0rFs\nI recorded a video at the pub with Kamil, but you\u0026rsquo;re probably better off watching a more coherent video by Martijn Braam\nThree more things. First, a quick correction regarding what I wrote in the October update and elsewhere: the regular PinePhone protective cases will fit the PinePhone Pro. I tried the hard case - it is a tight fit but a fit nonetheless. Secondly, I ran an AMA on /r/Linux earlier this month, you may wish to check out some of the questions I answered. Lastly, the PinePhone Pro is now undergoing CE/ FCC certification. PinePhone** **/ PinePhone Pro Keyboard The PinePhone / PinePhone Pro keyboard has entered production. I know that there has been a lot of back-and-forth on this topic these past months - as it turns out, creating a keyboard is much harder than one would think. In fact, it is almost as hard as making a stand-alone device. I wrote extensively about some of the problems we encountered in the September community update if you’re keen to learn more.\nI\u0026rsquo;ve used mine to take notes on the go recently, and it\u0026rsquo;s been a great experience - especially when thumb-typing\nSince September there have been two additional internal revisions of the keyboard. During this time the vendor addressed mechanical and electrical concerns which were raised by the design team and developers. With the fixes in place, the final design was submitted for production. We’re confident all kinks have now been ironed out.\nThe currently produced batch is a pilot run of sorts and should be available in the Pine Store in November. Minutes before posting this follow-up, I was told that the first units have been delivered. The price of the keyboard will be $49.95.\nPineNote Unlike the PinePhone Pro dev units, PineNote dev unit pre-orders will remain open for quite some time. Frankly speaking, PineNotes will likely remain behind a developer pre-order ‘wall’ until the e-paper display becomes enabled in Linux. I have written about the development progress, also in relation to enabling the PineNote’s e-paper display, in both this and the previous month’s community update. We will start going through the dev pre-order coupon requests starting next week and keep actively reviewing incoming applications on a weekly basis for the foreseeable future. We haven’t yet made the decision if units for ‘early adopters’ will also be available only via the pre-order system, but I suspect that they will. Software progress on the RK3566 platform is proceeding well, and I intend to discuss it at length in November. For those of you who are interested in following software progress, I suggest taking a look at the current mainline Linux support ‘status’ matrix and e-paper display reverse engineering effort status.\nPinecil The Pinecil remains one of the best-selling devices we have in the store. Recently, a big Youtuber made a video about the Pinecil praising it. We still have a lot of stock, but if the current sales volume continues for the next 2 days then we’re at risk of running out. I’m not sure if more Pinecil production was scheduled for this year - consider this a heads up if you want to get one. PineDio [by JF] The PineDio range of products is composed of multiple devices and is all about LoRa: a LoRa gateway, a USB LoRa adapter, a RISC-V development kit with an embedded LoRa module, and a LoRa adapter for the PinePhone (Pro). These past few weeks, Lup and I worked on writing software and firmware for these devices - all of which are based on the Semtech SX1262 LoRa module. Lup has already managed to connect the STACK to a LoRaWAN gateway running ChirpStack, and even to The Things Network (TTN is a public LoRaWAN network).\nRaw LoRa data received/ sent using PineDio USB dongle (on Pinebook Pro!)\nLoRa SX1262 Linux driver for the USB PineDio adapter - via Lup\nMeanwhile, I spent time trying to understand the low-level layer of the LoRa protocol by implementing \u0026ldquo;raw\u0026rdquo; LoRa communication between multiple devices (the USB adapter, the STACK, and other LoRa modules). I ran into some issues, but finally, thanks to Lup, communication between the devices was successfully established. I can\u0026rsquo;t wait to continue these experiments with the platform, and eventually build actual applications based on LoRa and the PineDio devices!\n","permalink":"/2021/10/29/october-update-follow-up/","tags":["pinedio","pinephone","pinephone-pro","quartz64","soquartz"],"title":"October Update Follow-up"},{"categories":["community","pinephone-pro"],"contents":"\nAs PINE64‘s flagship mainline GNU/Linux smartphone, the PinePhone Pro, was about to be announced, a trailer and some nice renderings showcasing the phone and its features had to be produced.\nThe groundwork for the trailer was started in February 2021 and took all the way up to a few days before the trailer was released at October 15th 2021. The work for the trailer included making the material and models, creating the scene and the surroundings, animating the scenes, establishing a story in the video, finding fitting music, cutting it and adding sound details, writing and recording the text and cutting the video, which took many hours of work until the following trailer was released:\nhttps://www.youtube.com/watch?v=wP2-6Z74W44\nThe trailer is almost entirely made with free and open source software – modelling, the scenes, animations and final cut including the music is all done in Blender, vector graphics and some smaller graphical edits for the screen contents are done in Inkscape and Gimp. The trailer is made by volunteers from the community.\nThe visuals The general idea of the trailer was to tell a story: visually we wanted to lead the viewer from the history of the PinePhone, to the introduction of the PinePhone Pro including its features, to the actual usage. Not only did we want to tell the story of PINE64 making shipping such a device real but also point the viewer to what was achieved so far and what the user can achieve using the phone. We selected a darker setting for the intro part of the video and we tried to go for brighter settings mixed with realistic settings for the PinePhone Pro introduction part of the video.\nFor product renderings typically Blender Cycles is used, which has the downside that the raytracing can take a very long time to achieve a fine rendering quality, unlike Blender’s Eevee architecture using rasterization instead of raytracing (especially used effects such as depth of field and other makes raytracing a must here). That means even short scenes with a duration of 3 seconds (that is 60 frames per second, making such a short scene 180 individual renderings with for example 1:30 minutes rendering time per frame) took until late at night (or overnight) to finish rendering, even with the usage of CUDA and Cycles X in the Blender alpha.\nMost scenes in the trailer went through multiple different versions, some of the scenes were numbered up to version 7 or 8 until we were happy with the storytelling and the visuals. Being able to build upon previously created scenes, ideas, model, textures and settings however helped with creating the finally used scenes considerably, so even after ideas were discarded the time used to create them was well-invested.\nFor scenes such as the privacy switches scene new techniques had to be learned to achieve visuals like floating text on top of a scene using depth of field using compositing to combine multiple scenes. All scenes also use three-point lighting. The small details make up the nice appeal of the overall trailer.\nDuring the creative process quite a lot of scenes which were not used in the final trailer were created and some of these unused scenes were reused to create nice visuals for press images at the time of the release (see PinePhone Pro Press for some examples) or interactive 360 degree views of the phone.\nThe voice The wonderful voice in the trailer is Bryan J. Olson, who absolutely love Linux! Pay him a visit under https://bryanjolson.com/\nThe face behind the voice: Bryan J. Olson\nThe long search for the music Finding the best music for the trailer turned out to be difficult. We looked into various free licenses and decided that we want to prefer using CC0-licensed material if possible. At the same time we tried producing our own music inspired by some heavy piano pieces based on various examples we listened into. In the whole process we sighted material in the low three figures, including various styles such as jazz, classical music, synthwave, lo-fi and generic ambient music. As best fit turned out the song „Motions“ by Rafael Krux, licensed under CC0, after overcoming our own concerns that the music might be too cinematic.\nThe music had to be cut in multiple places to make it fit the story: strokes of the piano were synced with the phone or with logos and texts appearing, to seemingly integrate it into the trailer. Some subliminal sound effects were also added (such as swoosh sounds), to give movements of the phone a greater force. Cutting the music and fading parts in and out could be easily done in Blender’s video cutting interface.\nWe hope you enjoyed the trailer and the community work, as well as this write-up how everything was made!\n","permalink":"/2021/10/27/how-meet-the-pinephone-pro-was-made/","tags":["community","pinephone-pro"],"title":"How \"Meet the PinePhone Pro\" was made"},{"categories":null,"contents":" Download audio\nIn this episode the PinePhone Pro is discussed in length, with other news mixed in. Listen towards the end for a in-depth discussion of the the PinePhone Pro!\n","permalink":"/podcast/s02e02/","tags":null,"title":"S02E02: The big PP"},{"categories":["news","pinenote","pinephone","pinetime"],"contents":"\nWelcome to what will likely be remembered as the most important community update of 2021. Today we’re introducing the PinePhone Pro and announcing that both PinePhone Pro and PineNote pre-orders are now open to developers. I am well aware that this announcement will overshadow everything else that I may wish to report on, so I intentionally chose not to include other exciting news in this post. I will write a follow-up piece covering other topics later this month - stay tuned. But that\u0026rsquo;s not all. All PineTime owners ought to read this month’s update concerning InfiniTime. The firmware recently received updates which significantly improve the user experience and BLE connection stability. JF also writes about the project’s growth and ongoing project management restructuring. 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.\nI’d like to thank JF, Alex (clover), Brian (33YN2) and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Community Update video synopsis\nTL;DR Housekeeping Wiki getting started and orphaned Wiki pages help needed KDE turns 25! Happy birthday! Good job on the PinePhone Pro launch team! PinePhone Pro PinePhone Pro announced - start by reading the PinePhone Pro website Features RK3399S SoC made by Rockchip for to the PinePhone Pro Ships with 4GB LPDDR4, 128GB eMMC, Gorilla Glass 4™ IPS panel, 13MP main camera, USB 3.0 via USB-C, native video out via USB-C + countless improvements Pogo pins \u0026amp; privacy switches are present: the PinePhone Pro is compatible with the keyboard and back cases Developer pre-orders and Explorer Edition coming later this year for $399 Developer units are in production due to be delivered soon The blog post focuses on the decision-making process and explaining why now is the right time to introduce the PinePhone Pro The PinePhone / PinePhone Pro keyboard enters production; keep an eye out for a follow-up post late this month PineNote PineNote developer pre-orders are now open Dev units ship with EMR pen, magnetic cover and a UART USB-C breakout board for debugging CE /FCC certification is now complete Production is underway and units are being delivered from factory now Biggest software problem relates to initialising the panel under Linux; developers have ideas how to accomplish this, but it remains untested Availability of early adopter units depending on software progress - likely later this year PineTime [by JF] InfiniTime 1.5 brings a highly requested feature - alarm clock! InfiniTime 1.6 releases just 2 days after 1.5 with a single line commit, which makes all the difference - InfiniTime has now stable BLE connection! Restructuring of the InfiniTime project, creating a Github organization and taking on contributors to help with issue triage, PR reviews and merging A word on donations to the InfiniTime project (and to other PineTime efforts) Housekeeping Before we get into the exciting news there are a few housekeeping items on our itinerary. The first of which concerns Wiki contributions. Let me start by thanking everyone who has contributed to our Wiki - I’ve seen quite a few Wikis and I think that ours is among the best out there. That said, there are a few sections that are either incomplete, neglected or simply haven’t received an update in a long time. There is a list of orphaned pages that need to be integrated into main articles, reworked or completely removed. More importantly, however, the getting started section - meant as a technical tutorial for complete novices - has not been maintained in over a year. While each device page usually offers a segment explaining how to get up and running, the global getting started section remains relevant because it contains information for less technically capable users. If someone is willing to volunteer their time to restructure this section, update it with information and give it an overhaul, then please reach out to me or one of the mods in our chats.\nYesterday our friends at KDE celebrated their 25th birthday. As many of you surely know we’re very closely partnered with KDE and have recently been made patrons by KDE e.V. KDE’s help and support over the years has been very important to us: most of our devices, including the Pinebook Pro, the PinePhone, and now also the PinePhone Pro, all ship with Plasma installed by default. I told this story publicly once already, but it\u0026rsquo;s worth repeating - the PinePhone owes its existence to the promise that Plasma Mobile held at the time of the project’s inception. Suffice to say we’re very fond of KDE and their team members, many of which we have the pleasure to call our friends. So, then, I want to say a deep-hearted happy birthday to KDE developers and their community. Please head over to their forums, social media, chat or elsewhere and make sure they know their work is important to our community and the open-source ecosystem as a whole.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video KDE\u0026rsquo;s 25 anniversary video\nFinally, I want to say thank you to our team for doing a great job on the PinePhone Pro launch. And I don’t mean the people who made the hardware possible, although they deserve a special round of applause for pulling it off under current manufacturing circumstances. To those who put together the trailer and the renders, created the website, put together and tested the pre-order system, and to all those who helped ensure we’re on track to have everything ready on October 15th - I am very grateful for your effort and help. Well done. PinePhone Pro This month I have the pleasure to introduce the newest member of the PINE64 family - the PinePhone Pro. It is a fast smartphone with premium features, built from the ground up to run mainline Linux operating systems. In anticipation of great interest in the nitty-gritty hardware details, we published a dedicated webpage complete with specifications, availability information, device renders and an extensive FAQ. I strongly suggest you go and read that prior to continuing with this section. Seriously, go read it first.\nPinePhone Pro webpage: https://pine64.org/pinephonepro\nInstead of reiterating the information on PinePhone Pro’s website, I’ll use this section of the community update to explain why we decided to introduce a more powerful smartphone and discuss some of the key design choices. Let me start by setting the stage. At the time of the original PinePhone’s introduction to the market there were only a handful of mobile Linux operating systems available, none or few of which ran regular Linux with open drivers. The goal of the project was to provide developers with an open, readily available, and inexpensive platform to drive Linux on mobile forward. The PinePhone ended up giving rise to new OSes, such as Mobian or DanctNIX (Arch), and helping existing projects such as Plasma Mobile reach new heights. The PinePhone’s introduction also attracted interest from desktop Linux OSes such as Manjaro and incentivized established mobile projects, such as UBports, to support mainline Linux. Original PinePhone developer pre-order announcement - a blast from the past :)\nFast forward to today, many of the 20+ operating systems have reached a mature-Beta status. All core functionality has been enabled and we’re seeing more complex features being added. Mobile Linux may not yet satisfy the needs of mainstream consumers, but we’re now at a point where open-source enthusiasts are willing to give a Linux smartphone a go. MMS messages, Android app support via Anbox or Waydroid, 24hrs of standby time with reliable calls and SMS, accelerated camera viewfinder, and photo post-processing are just some of the features that led people to start daily driving their PinePhones. Now that software has reached a higher degree of maturity, introducing a fast smartphone with premium features makes sense.\nHere it is - beautiful, isn\u0026rsquo;t it?\nThe announcement of the PinePhone Pro is therefore an acknowledgment that our journey with mobile Linux is entering the next stage. You could say that it denotes a shift from being ‘primarily development-focused’ to ‘technically-inclined end-users centered’. This isn’t the most elegant way of phrasing it, but you get the gist. With the PinePhone Pro we deliver hardware that will run current operating systems effortlessly and with some room to spare. But raw performance isn’t everything - attention has also been paid to the things that matter the most in a phone used daily: the screen, the camera, storage and RAM capacity, and the overall fit and finish were all central during the design phase. A lot of consideration went into each component choice, and many decisions were discussed with developers over the course of the past year. https://www.youtube.com/watch?v=pCxDcMdr_fo\nMartijn Braam, a postmarketOS developer and our friend, takes a look at the PinePhone Pro\nBefore moving on to discussing design decisions, let me clear up a few things: the PinePhone Pro is not a second-generation PinePhone, but rather a higher-end PinePhone. The original PinePhone isn’t going away anytime soon either - in fact, we have thousands of units in the pipeline. The PinePhone Pro is pogo-pin compatible with the original PinePhone, which means that peripherals, such as the keyboard and add-on back cases, will work with both devices. So if you are getting one of the add-ons for your PinePhone then don’t worry, they’ll work with the Pro if you decide to get one in the future.\nFinally, let me address some of the key design choices. We chose the RK3399 as our internal development basis for two reasons: we are well acquainted with the platform and it is nearly fully mainlined (the ROCKPro64, our RK3399 development board, recently received Arm’s SystemReady IR Certification). But we aren’t using a regular RK3399 chip in the PinePhone Pro. We worked closely with Rockchip’s engineers to tweak the original SoC to fit our use case - the result of the cooperation is the RK3399S, made specifically for the PinePhone Pro. RK3399S chips are binned and voltage-locked so that they conform to a smartphone chassis thermal and power consumption envelopes. Aside from great performance, the SoC also features a stellar feature set, including native video output via USB-C, support for high-resolution cameras and USB 3.0 data transfer speeds, just to name a notable few. But choosing such a well-supported platform also means that porting existing OSes to the PinePhone Pro will be fairly trivial. While it may take some time to achieve complete feature parity with the original PinePhone, the road to full system functionality will be relatively short.\nA look at what\u0026rsquo;s inside the PinePhone Pro (mandatory disclaimer: images of a prototype and may not reflect end product)\nAs I previously mentioned, we consulted component choices with the developers. This informed many of our decisions, such as using the main camera sensor on the original PinePhone for the PinePhone Pro’s front-facing shooter. Similarly, together with the developers we settled on the main 13MP Sony sensor which has good mainline Linux support, produces nice photographs, and has the right physical dimensions to fit the chassis. Early in the process we decided to go ‘all-out’ and outfitted the PinePhone Pro with 128GB of flash storage and 4GB of LPDDR4 RAM. Needless to say, we kept all the things our community loves about the PinePhone, such as the removable back, privacy switches and a removable battery (N.B. the battery on the PinePhone Pro has also received an upgrade). PinePhone Pro (left) next to a PinePhone (right), can you spot the subtle differences?\nLastly, let’s discuss decisions that determined the look and feel of the PinePhone Pro. Keeping backward compatibility with the original PinePhone was our priority, so from the get-go, we knew that whatever choices we made they couldn’t deviate too much from the original design. The face of the PinePhone Pro features a Corning Gorilla Glass ™ covered in-cell IPS display that produces a nice and vibrant image. It has good viewing angles and gets really bright. The decision to maintain the original PinePhone’s screen resolution of 1440x720 was made early on; higher resolution panels consume more power and increase SoC’s load, resulting in shorter battery life and higher average thermals. A few extra pixels aren’t worth it. As for the back case, it features our trademark understated matte finish. The development unit I had the pleasure to use was considerably more resilient to oily fingerprints than the original PinePhone. It is difficult to describe a tactile experience so I’ll leave it at that - I hope that photos do it justice. Finally, the entire device is slightly thicker than the original PinePhone - by 2mm to be precise. The change in thickness was made to accommodate thermal dissipation and the new display.\nPinePhone Pro (left) and PinePhone (right) thickness comparison - it\u0026rsquo;s barely noticable\nThat’s it, I think I’ve covered everything. If you have any further questions, make sure to leave them in the comments section. We currently have a small production run of the PinePhone Pro rolling off the factory floor - these units are aimed strictly at developers. The idea is to give devs time to get acquainted with the hardware so that they can start porting their operating systems to the new platform. If you are a developer and want to get your hands on the PinePhone Pro early, then I suggest you promptly place a pre-order as the number of units is very limited. Early adopters will have to wait a little longer to get their hands on the PinePhone Pro Explorer Edition. That said, it won’t be an extensive wait - we aim to start shipping the Explorer Edition late this year or very early the next (shipping will depend on production scheduling and the CE/FCC certification process).\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video I spoke to Destination Linux about the PinePhone Pro, go have a listen\nBefore I jump into the PineNote section - I know many of you are waiting for news about the PinePhone/PinePhone Pro keyboard and add-on cases. Due to the PinePhone Pro’s launch, and all the preparations which lead up to today, I’ve had very little time to keep track of hardware and software developments. All I know is that the keyboard has finally entered production. I’ll take the next week or so to catch up on everything and write a concise follow-up blog post that will hopefully answer all your questions. I\u0026rsquo;ll also make sure to query developers about any major developments that have taken place in the past month. Keep an eye out for the post around October 30th.\nPineNote It has been three months since we announced the PineNote - an open e-paper device, based on our range of Quartz64 single board computers. It features a fast quad-core SoC (RK3566), 4GB of LPDDR4 RAM, 128GB of eMMC flash storage and comes equipped with an EMR pen-capable fast refresh e-paper panel. In case you missed it, I suggest you read the August community update which I dedicated to introducing the new hardware. In time, the PineNote will run Linux (and who knows, maybe even *BSD) with an open software stack, allowing you to do a range of things that are impossible on traditional e-paper tablets. Sky\u0026rsquo;s the limit. But the path to achieving such functionality is a long one, and it will require skilled developers to get PineNote’s core functionality off the ground. Existing desktop and mobile environments, such as KDE Plasma, will also need to be altered to make a viable user experience on the unorthodox grayscale display. The bring-up process has already started and a select number of developers have received pre-production PineNotes in the past weeks - but many more contributors are needed to accelerate the development process.\nLast month I reported on PineNote\u0026rsquo;s current software status in detail, but I haven’t had much of a chance to catch up on it since. It is my understanding that the biggest hurdle to overcome remains e-paper functionality - more precisely, getting the display to initialize under Linux. Just prior to writing up this section I scrolled through the PineNote dev chat backlog, and the good news is that developers are actively working towards making this a reality. Aside from the display, development on the RK3566 is going really well and it appears that we’ll have a very well-supported SoC on our hands in a matter of months. This process will surely be propelled further by more people from the development community getting their hands on the hardware.\nA keyboard with the PineNote? sure why not - via Danct12\nSpeaking of the hardware - I am happy to let you know that the initial PineNote production run has successfully rolled off the factory floor and the device has received its CE/FCC certification earlier this month. This means that we’re now ready to start taking pre-orders from developers and contributors who are keen to help us realise the vision behind the PineNote. These units will ship without an operating system installed, with the device in a flashable mode by default. Devices aimed at developers will also ship with the EMR pen, a magnetic cover and a USB-C UART break-out board to aid with debugging. We will start shipping later this year, possibly as early as late November; keep an eye out for updates on our social media and news feeds as well as the shipping, stock and availability page. PineNote production line\nAs for early adopter units, their availability will largely depend on software development progress. Ultimately, the schedule will be dictated by when the e-paper panel gets enabled on Linux. As I already mentioned, developers have some ideas on how this can be achieved (click here to see what Caleb had to say about it), so it may be a matter of a few weeks before we reach this milestone. However, admittedly it is also perfectly conceivable that enabling the e-paper panel will prove more of a challenge, and consequently take a longer time. In a sense, the ball is now in the developers’ court and the rest of us (including the production team) have to wait for a green light to proceed. As always, I’ll keep you updated on how things are progressing in future blog posts and updates. PineTime (and InfiniTime) [by JF] In last month’s update, we announced the release of InfiniTime 1.4, which greatly improved the reliability and responsiveness of the touch panel and added a nice color picker for the PineTimeStyle watch face. Less than a month later, we published not one but two releases of InfiniTime! These 2 releases have allowed the project to reach a new milestone in terms of *daily driver readiness*. Let\u0026rsquo;s take a closer look at what these releases bring to the table.\nInfiniTime 1.5 Huckleberry If I had to guess the feature InfiniTime users missed the most, I would say it\u0026rsquo;s the alarm app. Users would often ask if an alarm app is available in the chat rooms, in response to the toots and tweets I write to announce new releases. My answer was always the same: that we\u0026rsquo;ll have an alarm app when someone will work on it. It\u0026rsquo;s as simple as that. InfiniTime is an open-source project and all contributors are volunteers working on it in their free time. There\u0026rsquo;s no priority, no roadmap and no set date for the next release. There are only people working on whatever they want whenever they want. Finally this pull-request was submitted.\nThe alarm clock app pull request\nSo, why did it take so long for this PR to be submitted? I can only offer my point of view. In my opinion, the alarm app presents 2 challenges. The first one relates to implementing the alarm in a way that it will wake the watch up and notify the user at a specified time. The other challenge is the design of the user interface. The UI needs to allow the users to specify an alarm time and the days the alarm should be triggered. Some developers are comfortable with lower-level development but are really bad at UI (I fit in this category), while others can do wonders on the UI side but struggle with low-level layers. Perhaps it is a bit of an exaggeration but it isn’t far off the truth either. I therefore really like how mruss77 approached implementing this new functionality - he created the first version with basic features (only 1 alarm, with very few options and customizations) which are already functional and left room for improvements in further releases. So, now we have our first alarm app! It allows you to specify time and days (once, every day, or weekdays), to enable/disable the alarm and to check when the next one will be triggered. And, obviously, the app will notify you when the alarm is triggered with a small vibration.\nA look at the alarm clock app - picture via Nico Cartron\nAnother important addition to this release is the rework of the BLE advertising strategy. In Bluetooth low-energy (BLE), advertising allows a device to broadcast *advertising* messages to announce itself to the other devices. These devices can then detect advertising messages when they are in scanning mode. James worked on refactoring the advertising logic in InfiniTime so that it now follows state-of-the-art recommendations, which should (and do) improve the interoperability with more BLE-capable devices as well as connectivity with the companion apps.\nLast but not least, Tim ensured that the date and time are persistent across reboots. It means that InfiniTime is now able to recover the date and time when the watch is reset (either manually or due to a bug). I think this is a nice quality of life improvement as users have (had, to be precise) to regularly reboot their watch to recover the BLE connectivity (more about this later).This was a bit tricky as the NRF52832 (the CPU that\u0026rsquo;s running the PineTime) does not provide any register or memory areas guaranteed to keep content when the CPU resets. We also cannot afford to store the time in either the internal or external flash memory, as it would wear them far too fast. Fortunately, Tim found a way to store the date and time in RAM and to ensure this location will not be erased when the watch reboots!\nInfiniTime 1.6 Ice Apple (we have a BLE fix!!!)\nOnly 2 days after the release of 1.5 I decided to publish InfiniTime 1.6. This release is really small in terms of the number of commits (only 1 commit to be precise) and changes (a single line of code was modified), but it is **huge** in terms of its impact for end-users: BLE connectivity now works a lot better than before!\nLet\u0026rsquo;s go back in time to April this year. At the time Lukasz and I felt that InfiniTime reached many milestones (with the integration of the step counter and heart-rate sensor) and deserved an official 1.0 release. The only reason why I hesitated was BLE connectivity, which was not as stable as I wanted. BLE would work for a time and then simply stop. I couldn\u0026rsquo;t figure out why that was happening, and I didn\u0026rsquo;t know if other users were experiencing this issue too. As you know, we finally decided to announce InfiniTime 1.0 knowing that we could fix the issue in future releases. This proved to be the right move. InfiniTime and the whole PineTime project gained a lot of momentum and InfiniTime 1.0 release allowed PINE64 to ship the PineTime as an ‘end-user’ product rather than a ‘developer kit’. Most importantly, the majority of users were happy with this firmware release.\nBuuuut I still noticed the BLE issue, and it was increasingly more obvious I wasn\u0026rsquo;t alone. Many users were reporting BLE connectivity issues, saying they had to reset their watch to be able to reconnect to the companion app. I\u0026rsquo;ve been chasing this issue ever since and I spent countless hours trying to understand why the BLE radio would stop emitting data after a few hours. Other developers quickly joined me on Github and in the chat rooms. They also spent a lot of time testing and debugging. In the end, we managed to prove that most of the BLE-related code is rock solid, but we still couldn\u0026rsquo;t understand why it was failing after roughly one day of usage.\nSo, why was this issue so hard to debug and fix? Debugging wireless communications can be very tricky since you cannot connect an oscilloscope or a digital analyzer using wires to figure out what is happening or what went wrong. I tried to set up a BLE debugging environment hoping to learn more about the issue\u0026hellip; with no luck. Also, the BLE stack (NimBLE) is a very complex piece of code that works very closely with the hardware. Without going into too much detail, the BLE stack needs *real-time performance* to ensure that timing constraints from BLE are met and it relies on hardware *timers*, *RTC*, and *interrupts* to control the BLE radio. This strong coupling between the hardware and software, along with strong timing constraints, makes debugging a lot harder than usual.\nDebugging - wires, wires and more wires\nIn the end, the analysis and the fix to the issue was provided by Daniel Jackson. Daniel found that a bug in the BLE stack would cause an overflow in the advertising logic which would stop advertisement messages from being sent. This fix is small and easy, but finding that specific issue in the whole code was like finding a needle in a haystack. I can\u0026rsquo;t help but be amazed by this mind-blowing collaboration between multiple developers from the open-source community. This was long-term work, it was tiring and frustrating, but we never gave up and finally understood what was going on and found a fix. Thanks to everyone who worked on this issue, and to all of you who supported us and tried to provide help and feedback - you\u0026rsquo;re awesome!\nProject organization\nSince I am the person who started InfiniTime (the project was initially just called my project and later PineTime-JF) I am the only one in charge. I have all the powers, I take all the decisions and I do whatever I want with the project. I do, of course, encourage users to provide feedback and other developers to submit pull requests, but in the end I\u0026rsquo;m the one who manages all feedback and decides which modifications make it into the codebase of InfiniTime.But with great power comes great responsibility as they say\u0026hellip; As the project gained popularity and momentum, I couldn\u0026rsquo;t help but feel overwhelmed by the quantity of feedback, issues and pull requests. Responding to questions and issues reported by the users, reviewing and merging the nice pull requests, all take a lot of time and energy, and there isn\u0026rsquo;t enough time in a day (after work and family) to manage the project in an efficient way.\nWithout knowing it, I became a benevolent dictator and, at the same time, the project’s bottleneck. Many issues were left unanswered and it often took me several weeks to look at new pull requests. And that\u0026rsquo;s fine, that\u0026rsquo;s how open source development works! But that\u0026rsquo;s not the most comfortable position for me to be in. I cannot afford to spend so much time working on InfiniTime. More importantly, I also don\u0026rsquo;t want users and contributors to become frustrated by the relative slowness of the project.\nI\u0026rsquo;ve been thinking about this situation for some time and recently decided to create a Github organization. Organizations on Github allow inviting other contributors to the project and giving them specific access and permissions. The goal is to onboard a few contributors to the new core team so that I\u0026rsquo;m not the only one allowed to triage and manage issues as well as review and merge pull requests.\nInfiniTime Github Organization\nThis is a major change in the project organization. We\u0026rsquo;ll have to learn to work together in this new way, but I\u0026rsquo;m confident that together we\u0026rsquo;ll manage to do great things. As of today I invited 2 contributors who I know from the project on Github and the chatrooms. I have known Avamander since the beginning of the PineTime project, and he has always given me a lot of useful advice on how to manage and organize InfiniTime. He also contributed nice features like the Music control app. Tim aka geekbozu aka Geekboy1011 is very active on the chat rooms and worked a lot on the BLE issue we fixed in 1.6, and made many contributions to features like the persistent clock. Thanks to both of them for accepting the challenge and joining me in the new project structure. They are the first members of the new InfiniTime organization, but we\u0026rsquo;ll probably end up inviting more members later on to help with issue triage and PR reviews.\nThe new InfiniTime project URL is now https://github.com/InfiniTimeOrg/InfiniTime. Github should take care of redirecting the old URLs to the new ones, but I recommend you update your bookmarks and git remotes to ensure you\u0026rsquo;ll always point to the right URL\nA word about donations\nI\u0026rsquo;m always shy away from talking about money and donations in the context of working on open source projects. Open-source development, in my view, is all about collaboration, contribution, sharing and most importantly of all - fun. Money should not be an important part of it. However, at the beginning of this year many people started asking me how they could donate to thank me for my work on InfiniTime. At first I was a bit reluctant but finally created an account on Liberapay. I did so promising nothing in return (except that I\u0026rsquo;ll probably invite my wife to the restaurant to make up for the time I spend working on the project) and yet, some people chose to anonymously donate money!\nI received far more donations than I anticipated and I continue to receive very generous sums. I have to admit this is a nice additional source of motivation and I thank everyone who has donated so far. But this is not a one-man show project - InfiniTime and PineTime are successful thanks to the work of many people. This includes developers working on the firmware (InfiniTime and WaspOS, for example), companion apps (Amazfish, Gadgetbridge, Siglo,etc.), users and testers who provide feedback, as well as bloggers and content creators who write and talk about the project online. If you want to donate money to the PineTime project, feel free to have a look at profiles of these people and thank them for their amazing work!\nKeep in mind that money is not the only way to motivate and encourage developers and contributors - provide feedback, share your experience and enthusiasm and thank them for their work. These little things will make any developer happy!\nThat\u0026rsquo;s if for this the community update this month. Keep an eye out for the follow-up news blog post at the end of this month.\n","permalink":"/2021/10/15/october-update-introducing-the-pinephone-pro/","tags":["infinitime","news","pinephone","pinephone-pro","pinetime"],"title":"October Update: Introducing the PinePhone Pro"},{"categories":null,"contents":" Download audio\nThe first episode of the new Pinetalk show with Brian and Justin! We go into the new structure for the show, such as the introduction of two monthly releases. We’re sure you have feedback for us, and we know there’s lots of room to improve! Stay tuned!\n","permalink":"/podcast/s02e01/","tags":null,"title":"S02E01: Season 2 Introductions"},{"categories":["community","cube","news","pinenote","pinephone","pinetime"],"contents":"\nIn this community update we’ll discuss PinePhone keyboard progress (and hurdles), add-on back cases awaiting developers approval, initial PineNote impressions and early development progress, as well as news of InfiniTime 1.4 release and a guest post about PineCubes as a part of a security system. We also have an announcement for our community developers: we will be introducing bounties to the DevZone. We’ve got some exciting things in the works that I am aching to share with you, so if you haven’t done so yet, now is the time to subscribe to this blog. 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.\nI’d like to thank JF, Alex (clover), Caleb, Martijn, Danct12, Chris (newton688), Brian (33YN2) and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of the community update\nTL;DR\nHousekeeping DevZone internal testing concluded and roll-out already started DevZone to introduce bounties in near future Hosting cluster maintenance is underway; Gamiee is writing a public log about the process PineTalk podcast is coming back this month! Permissible usage of the PINE64 logo and brand name; PINE64 merch in the works (by third party) PinePhone Two years since PinePhone dev units went on sale Keyboard production hurdles - a detailed account of why we don’t have an availability date yet Summary of the keyboard’s production firmware features and capabilities Back cases awaiting developers to green-light Waydroid is shaping up nicely [by Danct12] Megapixels 1.3 released - the PinePhone now takes much nicer-looking photos [by Martijn Braam] PineNote Detailed first impressions of the PineNote; very impressive hardware, not much to complain about, perhaps apart from the cover (which will be improved in the future) Early development status report (thanks to Caleb); once Linux boots on the PineNote, there is a good chance for much of core functionality to work PineNote production is on-track, and dev/ early adopter ought to be available late October PineCube A guest post by Chris (newton688) about using two PineCubes as a part of a security system; detailed information about the setup and functionality PineTime Release of InfiniTime 1.4 marks the 1000th project GitHub commit Huge number of infiniTime improvements and bug fixes; end-users can now also customise the look and feel of default watchface WaspOS supports new accelerometer and brings a number of improvements iOS and Ubuntu Touch companion apps compatible with InfiniTime now available; Infini-iOS app now installable via Apple’s Testflight PineDio Development progress report and debugging of PineDio Stack by FJ and Lup JF managed to get InfiniTime running on the BL604 SoC as well as used an e-paper display with the Stack; Lup successfully connected to a LoRa gateway Debugging revealed some hardware issues; a revised mainboard in the works Housekeeping Late last month we announced that the DevZone was being made ready for internal testing - over the past four weeks we’ve gathered a lot of feedback from developers and improved DevZone’s core systems. The platform has now reached a point where we feel happy to accept more participants aboard: the review process of the applications has already begun, and some developers may already have received invitations to set up their accounts by the time this post goes live. The opening up of the DevZone will be gradual, so if you don’t receive an invitation to set up an account at this time then do not worry. For those of you who don’t know of the DevZone development system platform, and wish to learn about it or are considering signing up, I invite you to read the July update’s housekeeping section for more details. But this isn’t the end of DevZone news. Once the system is populated with developer accounts, we will be introducing bounties to the platform. Only developers on the DevZone will be eligible to accept a bounty once it gets posted. There will be both global (open to all developers) and group-specific bounties. Since the vast majority of people reading the community updates aren’t developers, let me provide a two-line explanation of what bounties are: bounties are a way to incentivise development and expedite problem-solving by providing a financial incentive. Such bounties usually apply to things that are difficult to solve, hard to implement or otherwise pose a significant challenge. In short, developers receive a one-time payment for solving a problem or implementing a missing functionality. The Pine Store has committed to putting up a substantial sum of money for the bounties and we hope this will help the DevZone thrive. More information about the bounty system will follow on DevZone\u0026rsquo;s global forum.\nDevZone sign-ups will remain open indefinitely\nIn other news, PineTalk podcast is coming back after a two-month hiatus! The community-ran show that focuses on PINE64 news and related topics will resume shortly with new hosts and a reworked schedule. As it has been explained to me, the plan is to have an episode dedicated to discussion of news and the following one to community and partner-project topics. PineTalk is available on most popular streaming platforms such as Spotify as well as on our YouTube and Odysee channels. A dedicated post announcing the return of the PineTalk and introducing the new hosts will go live shortly - stay tuned to learn more. If you haven’t done so yet, make sure to subscribe to the show’s RSS MP3 feed. New PineTalk logo by Julius Guthunz\nEarlier this month Gamiee posted the first entry in a series about the maintenance of our hosting cluster. For those of you who don’t know, we self-host all our community infrastructure and services, including this website, on our own hardware - you can learn more about it from the original post about the move to the cluster. Gamiee’s first post explains the reasons for the maintenance, discusses the planned upgrades and showcases the temporary setup currently in use. It is a series I know many in the community have been waiting well over a year for, so I strongly suggest you check back regularly to follow the hosting cluster’s journey from the workbench back to its rightful place in BBXNET’s server room. Lastly, I want to touch upon a topic that I get asked about on a regular basis - namely, the use of the PINE64 logo and brand name in both community and commercial projects. We have detailed guidelines for the use of the PINE64 name and logo on the main Wiki page (which also includes a media kit with assets in .svg format; this too is something I’ve been asked about recently). As a side-note on this topic - we’ve been contacted by community members interested in creating PINE64 ‘swag’ and have agreed to grant them the opportunity to create and sell unique designs. Needless to say, neither PINE64 nor the Pine Store will be profiting in any way from this. I hope you’re as excited as we are to see the ‘swag’ - personally, I am looking forward to starting my day with a cup of coffee in a PINE64 mug. PinePhone It has now been two years since the very first PinePhones entered production. Shortly thereafter, in November of that year, we shipped PinePhone developer units fitted with the first PCB revision and began preparing for production of Braveheart units. The PinePhone has gotten us - the mobile Linux community as a whole - far in a short amount of time, and made the dream of a mobile Linux possible for tens of thousands of people. I felt this was worth a quick mention on the PinePhone’s second anniversary. If you feel as nostalgic as I do, or simply want to see a very cool transparent PinePhone prototype, then I invite you to read the September update blog entry of 2019. PinePhone Hardware\nThese past couple of weeks were effectively a race to deliver a finalized revision of the keyboard firmware and have it successfully flashed on the factory floor. The details aren’t important, but suffice to say that getting the firmware shipshape and flashed using a factory programmer proved to be a time consuming undertaking for both Megi and the product team. What is important, however, is that it all turned out well in the end, and on September 6th version 1.1 of the keyboard’s firmware was successfully installed using factory tools. When I initially started writing this text, some week ago, I expected to provide you with a timeline for production and the eventual availability date for the keyboard. However, this monday the vendor reported that the keyboard factory test image doesn’t recognize the production keyboard. As it turns out, due to last minute changes made to the firmware, the factory test software (a custom build of postmarketOS by Martijn Braam) no longer works. This temporarily stalled the production process. At the time of writing, Martijn and Megi are still trying to figure out a software work-around so that production can get back on-track. When manufacture (re)starts later this month I’ll make sure to provide you all with an update, which will hopefully include an availability date.\nDid you know that the keyboard can be fully extended for thumb-typing? - picture by Martijn Braam\nAs for the final version of the firmware that ships on PinePhone’s keyboard, I am happy to say that it is more than we could have hoped for. It allows users to customise their keys, including the modifiers, in nearly unlimited ways via supporting utilities. This effectively means that users will be able to set their prefered layouts and alter key behaviour without needing to flash a custom version of the firmware to the keyboard’s controller - how cool is that? You can also physically relocate all keys, bar return and space, to correspond to your chosen software layout. The reason I advise you to leave the return and space in their respective places is because the tiny hooks that hold onto the metal stabilizers can be finicky and easily broken if not handled properly. Besides, it\u0026rsquo;s not like you can place these keys elsewhere on the board. Lastly, the firmware is now able to report charge status of the internal battery to the PinePhone’s operating system - a critically important feature following the (correct, in my opinion) decision to remove charging status LEDs. Before moving onto discussing other topics, I’d like to thank community members who helped translate the keyboard quick start manual into German, French and Spanish. You guys rock. From the left: stock PinePhone; PinePhone with fingerprint reader; PinePhone with wireless charging; PinePhone with keyboard attached The PinePhone back cases with wireless charging and the fingerprint reader are now ready and awaiting developers approval. As soon as the cases get green-lit you’ll see them appear in the Pine Store. I finally had the opportunity for some hands-on time with both of the cases and I must say I really like how they turned out. For one, they match the PinePhone’s overall aesthetic perfectly: when mounted, they look like a natural part of the assembly. Admittedly, they do add a bit of bulk to the back of the PinePhone (but not the sides) - approximately as much as the hard protective case - but at no point during my few-day-long usage of the PinePhone with the wireless charging case fitted did I feel it was unnatural or too hefty. Something that pictures cannot convey is that the finish on these cases is really nice. They share a similar coating to that used on the PinePhone’s keyboard. What this means in practice is that not only do they feel very sturdy, perhaps due to the internal reinforcement grid, but are also significantly less likely to attract fingerprints than the default back case. The wireless charging case works fine with the desktop PinePower - I’ll likely end-up using it with my phone that isn’t fitted with the keyboard. If you’re interested in picking up a back case as soon as possible, please keep a close eye on our social accounts and news channels. PinePhone Software Waydroid by Danct12\nIn the past weeks, I\u0026rsquo;ve been working on packaging Waydroid to Arch Linux and I have released one of the test packages to the community (which also ended up in the Manjaro repository). That test package required some fiddling around with boot arguments and, even when you get it to work, it has all kinds of issues such as inverted colors and app stability. Since then the Waydroid team made a lot of progress, making app crashes to be less frequent and color formatting displaying correctly on the PinePhone. The performance is now quite comparable to Anbox - in fact, I find that Waydroid works better than Anbox! Regardless, the project is still relatively new and there is a lot of room for future improvements. Hopefully you\u0026rsquo;ll see Waydroid in our PINE64-Arch repository very soon. I leave you with a short video of the PinePhone running Subway Surfers.\nhttps://www.youtube.com/watch?v=bG0uAQqeqW4\nAndroid game running under Waydroid on the PinePhone\nMegapixels 1.3.0 by Martijn Braam\nMegapixels had a new release and is now at version 1.3.0 - the major change in this release is more contrast in the post-processing script, which results in pictures with more vivid colors and being more ‘contrasty’. Work is being done to make the amount of this processing being applied configurable through the Megapixels settings.\nPicture taken on PinePhone with Megapixels 1.3 - image via postmarketOS\nPineNote In case you live under a rock and missed last month\u0026rsquo;s announcement of the PineNote, then I invite you to read it before continuing on with this section. PineNote production is on-track, and we expect to have development and early adopter units in the Pine Store next month. I’ve now had the PineNote development unit for a little over two weeks, so I thought I’ll start this section by sharing my initial impressions of the hardware. Obviously, I am hardly impartial in my assessment, but I believe my opinions closely echo those of devs who received their units. Also, in full disclosure, I am using a factory test build on my device for testing purposes. The device itself is what most people will probably find ‘just the right size’ - at 10.3” it is plenty large for reading and writing while also being comfortable to lug around in a backpack. It is relatively light and feels natural to hold, and at no point did I feel that it is bulky or unwieldy. The construction is really sturdy and the plastic bevel and back have a good feel to them. One gripe that I have about the plastic back is that it is a fingerprint magnet, which likely won’t matter too much since you’ll likely want to use a cover. The minimalist and industrial look of the entire device makes it look more like a work tool than a gadget, which is a good thing in my book.\nSee the faint circle, right of the PINE64 logo? - placing the EMR pen (or a magnet) down there enables recovery and debugging\nThe display is downright great. The contrast is excellent, even when compared against some e-paper industry giants’ offerings. Mind you, such a crisp image is achieved despite the e-paper display being housed under two layers of digitizers (Wacom, for the EMR pen, and a regular capacitive panel for finger input). The white and amber front light is really good; it lights the entire panel evenly and is extremely bright, even to the point of being visible in broad daylight, but it can also be turned down very low for reading in dim or dark spaces. Under the factory build of Android, which I’ve been testing the device with, the EMR pen’s responsiveness is very good - I’d say close to instant. I truly hope that a similar level of pen input responsiveness can be achieved under Linux in the future. Speaking of writing, I like the default stylus - it is really well built, well balanced, has a solid heft and provides a good writing sensation. Left - PineNote inside without frontlight / right - PineNote amber frontlight in direct daylight\nWhile I am very pleased with the device, it would be unfair of me not to mention things that I am not thrilled about (thankfully there are only two things to mention). I am not a fan of the cover - it is mechanically perfectly capable, it is light, thin and does the job, but despite looking nice it doesn’t feel good in the hand. It is now too late in the manufacturing process to change the design, but in the future we’ll surely redesign the cover or at least improve the feel of the material it is built from. Secondly, if you aren’t using the cover, which has an embedded magnet corresponding to the one in the EMR pen, the pen doesn’t have a way to attach to the PineNote. Again this isn’t exactly a massive issue, because I suspect most people will always want to house their device in a cover, but I felt that it was worth mentioning regardless. I also have an update regarding the current status of Linux development for the PineNote. I’ve spoken to Caleb to get a sense of how things are going, and here is a summary of what they had to say. Work is simultaneously done on the u-boot, the e-paper panel and the Linux kernel. All the above are obviously directly interconnected, but it appears to me that there is an informal division of labour among the devs. Caleb has been looking into u-boot and the e-paper panel (more specifically, how to initiate it on Linux) because they believe that u-boot is responsible for loading the waveform data that enables panels functionality, quote “I\u0026rsquo;m currently working on porting over the parts of the e-ink drivers which are open source to mainline, then I\u0026rsquo;ll try to fill in the blanks using u-boot as a guide with the end goal of being able to get basic framebuffer support. I think the downstream u-boot is responsible for loading the waveform data and passing it to the kernel, given CounterPIllow and I have the exact same waveform data, if we can verify that other people do as well (\u0026hellip;) then we can instead put the data in /lib/firmware and have the kernel load it like it would any other firmware”.\nHowever, to test whether this will actually work, developers will first need to get Linux booting on the PineNote. As Caleb explained to me, pgwipeout’s Quartz64 kernel does work, and even boots, but gets stuck being unable to detect eMMC flash. This is likely a trivial oversight, and I am sure that it will be sorted out swiftly. If Caleb is right in their assumptions about how to initialize the e-paper panel, then there is real hope that we can get an image output soon after the device boots Linux for the first time. This, in combination with Wacom and the capacitive digitizers being already mainlined, means that there is a real chance for a lot of basic functionality being available to developers soon. The road ahead is obviously still very long, but the first steps are highly encouraging and I cannot wait to see how far the project progresses this year. I’ll make sure to bring you a steady stream of PineNote development updates on a monthly basis as I’ve done in the past for our previous devices. PineCube by Chris (newton688) For the last several weeks we\u0026rsquo;ve been busy with the latest PineCube project, which is to set up two and eventually three PineCubes as security cameras both inside and outside the house. As a starting point the first cube was imaged with the pre-built Armbian from the wiki: Linux Kernel 5.11, Motion and GStreamer capabilities. This cube connects automatically to the local WiFi and is powered using a micro USB cable and an off the shelf power supply. Anyone in the trusted local network can see the camera from a web browser through the motion tool at pinecube1:8080. Also, we can put it wherever it is needed, including monitoring the solar panel charge controller status from time to time.\nSolar monitor feed\nMotion can be configured to record short MPEG-4 video clips when it detects motion and to save a recording to a file internally. We expanded on this by posting the recordings to a private Matrix channel on a private server so that access can be controlled and notifications can go out to different people on different devices. This setup also serves as an off-site backup. This has turned out to be a versatile indoor unit that serves a variety of purposes. Attention has turned to how to support outdoor units.\nMounting the PineCube outdoors has some unique challenges. How do you get power to the unit? The WiFi may not be as reliable outdoors depending on weather conditions. Also, the weather, such as rain and moisture can affect the electronic components. Using PoE helps to solve the first two problems. Our existing networking equipment has active PoE so we went with that system, but it required an extra PoE splitter dongle to separate USB power from ethernet since the PineCube currently supports only passive PoE. To protect the device from water and humidity the unit needs to be sealed with something transparent that doesn\u0026rsquo;t distort the image. We found an acrylic dome of a large enough size to hold both the PineCube and the PoE splitter and used painted plywood as backing and shelving material. The unit will be sealed completely using a caulking compound that has yet to be sourced, likely a silicon compound. We will be testing the electronics beyond its specified limits in the next six months as the winter could bring temperatures below -30C. Fingers are crossed.\nLeft - A look at the internals // right - outside mount on wall\nThis second PineCube is accessible from the internal network in the same way as the first using Motion\u0026rsquo;s web interface. The resolution was increased to 1280x720 to provide better detail, but this increased the processing power required to capture videos making them very laggy. The tradeoff was acceptable in our case and so we disabled motion capture on this device. Also, with this device we decided to learn more about Armbian and so this one was installed directly from the official Armbian community supported image and installer, which required access to the console over UART, which can be done with the PinePhone/PineBook Pro USB headphone jack UART devices or other means described on the wiki. The kernel version is 5.10 and the version of Motion is older, but still usable until the next version of Debian brings in the newer software.\nImage from the PineCube\nThere are a number of image controls that can be adjusted using the v4l2-ctl command-line tool, such as horizontal flip, colour balance, saturation and hue. There are also some test patterns built into the sensor that may be helpful in calibrating these.\nImage adjustments examples using v4l2-ctl\nThere\u0026rsquo;s also an infrared filter for the sensor and the PineCube\u0026rsquo;s front board has a deck of four IR LED\u0026rsquo;s. They can work indoors and at close range to pick up objects, but our outdoor unit will require some adjustments before this could be effective at night. The sensor is currently set back from the acrylic dome too far and there is some glare from the LED\u0026rsquo;s. Also, the Green power LED is causing some glare too and that needs to be resolved, perhaps with removal of that one LED. Details of how to enable/disable the IR cut filter and the LED\u0026rsquo;s can be found in the Wiki.\nPineCube image with infrared\nAs we add more cameras to our network, monitoring and managing them will be more time consuming. This is why we installed Prometheus extractors on them so that we can collect all sorts of data and monitor them using Grafana dashboards along with the other machines that we have on our network. Monitoring pending upgrades to Debian will require some more work since the CPU power required to check for packages to upgrade can sometimes interfere with the video capture operation. This might be resolved with a short scheduled daily outage. Meanwhile, this is done manually from time to time.\nPineTime (by JF) The momentum around the PineTime project does not slow down, quite to the contrary, Wasp-os and InfiniTime keep on receiving much feedback from users alongside contributions from developers. Moreover, the ecosystem of companion apps is constantly growing, and now encompasses most computer and mobile operating systems. It is amazing to see so much activity around this project we started almost 2 years ago. Let\u0026rsquo;s start with InfiniTime 1.4, which was released a few days ago. This version is highly symbolic, as the very last commit of the release was exactly the 1000th commit to the project!\n1000(!) InfiniTime commit\nThe release comes with a reworked touch driver, which improves the reliability and responsiveness of the touch panel. I\u0026rsquo;m really impressed by this contribution by Riku Isokoski, which helped reduce the latency of the touch interface to nearly zero, really improved the user experience in many apps: the setting of the timer is now as fast as it should be, the Paddle and Twos games are a lot more pleasant to play, and the whole UI feels snappier and faster than before. Another nice feature of InfiniTime 1.4 Pink Grapefruit which users will surely appreciate is the color picker feature for the PineTimeStyle watchface. You can now unleash your creativity and customize your favorite Pebble-inspired watchface!\nLeft - Quick Settings menu // Right - customization options of the default InfiniTime watchface - images via Nico\u0026rsquo;s blog\nAs always this new version brings many other improvements, such as better phone call notifications and better battery level monitoring, as well as bug fixes (we\u0026rsquo;ve hopefully fixed the bootloop issue). Nico provides a nice overview of this release in his article if you’re interested for an in-depth look.\nWaspOS has also seen a few major changes since last month. Support was added for the new BMA425 accelerometer that is found in newer PineTimes, the weather app has had a fix for crashes and a bug that caused it to show incorrect values, a workaround has been made to prevent gcc-11 from building bricked WaspOS bootloaders, there is a bugfix for the wasptool OTA command, and the values for the heart rate sensor have been adjusted for more accurate readings of the heart rate.\nLast month, I announced that 2 iOS companion apps were in the works. This month, I\u0026rsquo;m happy to announce that Infini-iOS released 2 beta versions 0.8.0 and 0.8.5, which are now available for testing on iOS. This application is very new but already provides many functionalities like time synchronization, displaying the heart rate value, battery level monitoring, OTA updates and more. This version is available for installation via Apple’s Testflight - feel free to try it out and provide feedback to the author if you own an Apple device.\nGo developers will be happy to learn that a Go library and a daemon to interact with the PineTime are now available. The \u0026ldquo;itd\u0026rdquo; daemon comes with a command line interface (itctl) and a GUI frontend (itgui) which allow users to sync the time, receive notifications, control music playback, get info from the watch and many other functionalities.\nLast but not least, I came across a new PineTime companion app for Ubuntu Touch. Many UBports community members were requesting such an app, and I\u0026rsquo;m happy that jiho started working on uwatch - a smartwatch sync app for Ubuntu Touch that supports the PineTime running InfiniTime. It will work on the PinePhone as well as any other device running Ubuntu Touch. PineDio (by JF) In July I introduced you to the PineDio Stack, a development kit built around the Bouffalo BL604 RISC-V MCU, which provides many onboard features such as the SX1262 LoRa module, an SPI flash memory, a LCD and touch panel, as well as a motion and heart rate sensor. In my opinion, the Stack is a really nice board that could serve as the basis of many future projects at PINE64!\nJF\u0026rsquo;s PineDio Stack setup looks awesome! - via Twitter\nSince last month, Lup Yuen Lee and myself have done many tests on the first prototypes we received a few weeks ago with the goal to provide as much feedback as possible to the PINE64 team so they can design the best hardware for the Stack. And we have some great news to share: I was able to run an e-ink demo as well as a stripped down version of InfiniTime on that board. Lup, on the other hand, managed to connect to a LoRa gateway using the onboard Sx1262 LoRa module.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video InfiniTime running on the PineDio Stack\nAs usual in the engineering world, not everything works the first time, and we\u0026rsquo;ve noticed some issues with the JTAG debugging port and the LCD controller. If you are interested in the debugging process of this board, I encourage you to read this article by Lup Yuen Lee detailing the entire process. Lup provides many details about the techniques and tools we put in place to debug the LCD controller. As a result of this exploration the product team is now preparing a new version of the board, and I hope we\u0026rsquo;ll be able to provide more good news very soon!\nThat is all for this month!\n","permalink":"/2021/09/15/september-update-hurdles-and-successes/","tags":["devzone","pinecube","pinenote","pinephone","pinetime"],"title":"September update: Hurdles and Successes"},{"categories":["cluster","community","rockpro64"],"contents":"As promised in the last month\u0026rsquo;s community update Housekeeping section, this is the first part of the cluster\u0026rsquo;s build log! This mini-series in which I will cover everything about upcoming changes our hosting cluster, and it begins with building a temporary cluster.\nWhy build a temporary cluster? One of the latest photo of cluster\nLet\u0026rsquo;s start from beginning. When we built the current hosting cluster a year ago, it was made in quite a hurry (some of the services needed to be migrated to the cluster on a moment\u0026rsquo;s notice). Also, it was the first time I (gamiee) and Matthew (fire219) were tasked with building a cluster. Because of this, some of the cluster\u0026rsquo;s features are missing and various things don\u0026rsquo;t work quite as well as we have hoped. For example, the cluster has power management boards (PCB on right side of every row), which are used primary for power distribution to the SBCs, but also it also has a I2C GPIO Expander for rebooting and turning off the SBCs. The I2C Expansion isn\u0026rsquo;t in use yet, because the primary node wasn\u0026rsquo;t able to detect it, so this is something that needs to be checked out when the cluster is turned off. And this is exactly the main reason why we are building a temporary cluster. We need to do some changes which require us to have the whole cluster turned off and on a workbench (not in housing room where isn\u0026rsquo;t much space), and this means that it will be inaccessible for several days. Obviously a long downtime wouldn\u0026rsquo;t be good when 100% of PINE64 community services are running on it. So we are going to build a temporary small cluster, which will have the minimal number of required nodes to have all services running, so we can make all upgrades with precision and at our own pace.\nWhat do we need to make a custom cluster? There are two things each node needs: a power supply and access to the network. Access to the network can be solved by using a classic Ethernet switch, but powering multiple RockPros, which are actually pretty power hungry, is a bit problematic if we don\u0026rsquo;t want to have multiple power adapters. One of the solutions is to design a very simple power distribution board.\nWhen designing a power distribution board, we first need to calculate how much power the the whole cluster will require. According PINE64 Wiki - RockPro64 Page - Part Board Information, Schematics and Certifications, one node will need +12V and 3 - 5 Amps, supplied from 5.5mm/2.1 Barrel jack, or via JST XH connector, which is primary used for powering an external hard drive. I chose to use barrel jacks; 3 - 5 Amps is quite a lot, and that\u0026rsquo;s because it contains the current required for external PCIe device such as 3.5\u0026quot; HDD. Various benchmarks show that the typical power consumption of each board is around 7 Watts. Our temporary cluster will have 7 nodes, so we need a power supply that can supply 12V and approx. 5 Amps. Power supplies which can fulfill these requirements include those used for laptops, classical PC power supplies (ATX) and enclosed power supplies.\nI chose to use a classic ATX power supply since they are cheap and really easy to source. When sourcing a PC power supplies one needs to be certain that it can actually supply the required current. Some power supplies have two +12V rails, 12V2 which powers the CPU and 12V1 which powers everything else. Since we will use the main ATX power connector, this one uses 12V1 rail, so we need to determine if this rail can supply the voltage we need (most of those vendors don\u0026rsquo;t specify the currents for both rails, it mostly show sum of both rails for 12V). But if we will use a power supply that has a single 12V rail for everything (like I do), then finding the current for 12V is easy. Having sorted out the power supply, we can start designing the board.\nAs I mentioned before, we are going to use main ATX Power connector, which is a 20-pin or 24-pin Molex. We will use 24-pin one, since it contains additional +12 V pin. We can find this connector as Molex 39-28-1243. The pinout is here:\n(Source: Wikipedia)\nFrom this connector we will just need +12V, Ground and Power On pin. The Power On pin needs to be connected to ground by the \u0026ldquo;motherboard\u0026rdquo; to turn on the power supply. I added a 2-pin jumper header for this, so I can turn it on / off using the jumper. The last thing we need is power output for the nodes. There are several ways of doing this: we can use USB female connectors (with USB to Barrel Jack cable), barrel jack female connector (with barrel jack-to-barrel jack cable) and screw-on terminals or just holes, where you can screw / solder the wires going out from barrel jack cable. I chosen to use just the holes. Doing so I had to be careful about the size and distance between them. Since I picked a very accurate size and distance, it proved a bit problematic to solder cables into it (I will use screw terminals next time). Basically, that\u0026rsquo;s all! It\u0026rsquo;s nothing fancy, but it will do the job for the time being while the hosting cluster is in maintenance.\nYou can find the schematics and board on OSHWLab\nLayout of temporary cluster I was thinking about various layouts that can be used for this temporary cluster. I can place every node on the side, but that will be kind of big. I can also place the nodes vertically, but that would be harder to mount, or I could just stack the boards and use distance field, as Electr0Lyte did with his cluster:\n(Source: Electr0Lyte\u0026rsquo;s Twitter)\nThis inspired me and I decided to use the classic layout, which most of those small clusters use. I designed the power board so that it will be mounted vertically together with a switch. I 3D printed the holders for the switch and power board, mounted it into the plexiglass and here we go we made our own temporary cluster!\nTesting temporary cluster with 6 nodes\nThis temporary cluster will be launched on September 2, 2021 from 8:00 AM to 11:00 AM UTC, If everything goes well. After the launch, the large hosting cluster will be moved to my place so I can do all the upgrades - something that couldn\u0026rsquo;t be made on-site.\nThis is all for this first update log, please let me know if you liked the extensive description of the process, or if it should be shorter. Also I want to say thanks to Lukasz, Matthew, PizzaMartijn, Maya.b and Electr0Lyte for all their help. See you in next update log!\n","permalink":"/2021/09/01/clusters-build-log-moving-to-temporary-cluster/","tags":["cluster","community","rockpro64-2"],"title":"Cluster build log: Moving to temporary cluster"},{"categories":["pine64-community"],"contents":"\nFirst announced in the July community update, the DevZone is a project management system for PINE64 devices. It will allow us to have a better overview of ongoing software development, streamline the product prototyping processes and keep track of suggested hardware changes. It is also a way for us to get an up-to-date survey of our developer-pool, including each developer’s core competences and availability. We believe that the introduction of this system will facilitate cooperation and accelerate the process of bringing new devices to the market. Earlier this month we launched DevZone for testing in a very limited capacity. We made the decision that the best way to put the system through its paces is to actually use it in one of our ongoing projects: the pilot project chosen for this purpose is the recently introduced PineNote. But this is just the beginning. In the coming weeks and months we will be gradually opening up the DevZone to a wider number of community contributors and partner project developers. We have an extensive backlog of applications and we keep on receiving new ones, so it will take time before successful applicants get assigned to ongoing projects. We believe that the DevZone will grow to be more than just a useful tool - as we see it, the DevZone will become a staple of our development community. If you’re interested in participating in the DevZone then we urge you to read the July community update’s housekeeping section for more details and submit your application. If you are granted a recognized developer status, a password (re)set link will be emailed to you, at which point you will be able to access the system. After filling in your profile details, an admin will assign you to one or more projects.\nI am looking forward to seeing many of our active contributors on the DevZone. The DevZone can be accessed from the widget at the bottom of this page\n","permalink":"/2021/08/23/devzone-rollout/","tags":["community","devzone","pine64","pinenote"],"title":"DevZone rollout"},{"categories":["community","pinebook-pro","pinedio","pinenote","pinephone","pinetime","quartz64"],"contents":"\nThis month brings news that many of you have been waiting years for - we’re introducing the PineNote, a high-end e-ink device based on the powerful Quartz64 single board computer. But the good news doesn\u0026rsquo;t end here, the PinePhone keyboard has entered production, developers have begun work on PinePhone’s back cases, PineDio development is moving forward and we’ve seen a new firmware release for Pinebook Pro’s touchpad. There’s a lot of ground to cover this month, so let\u0026rsquo;s get to it.\nYou 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.\nI’d like to thank JF, Alex (clover), Dylan (from postmarketOS), Peter (LinMob), Alfred (from UBports), Chris (kop316), Brian (33YN2), gamiee and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Community update video summary by PizzaLovingNerd\nTL;DR\nHousekeeping: DHL sent all PinePhones to NZ, so we had to reship all orders (sorry for the delay) Housekeeping: Building a temporary cluster to complete and maintain hosting cluster; build log and updates incoming PineNote: Announcing the PineNote, one of the most powerful devices of its kind on the market PineNote: Quartz64 based; specs include - fast refresh e-ink panel with multiple frontlight settings, RK3566, 4GB LPDDR4 RAM and 128GB eMMC flash storage PineNote: Wacom panel compatible with many EMR pens: we will offer our own PineNote: Available this year for $399; early adopters batch includes EMR pen + magnetic cover (later sold separately) PinePhone Hardware: PinePhone keyboard feels great and enters production this month PinePhone Hardware: PinePhone keyboard available in September or early October PinePhone Hardware: good news re: back cases - fingerprint reader and wireless charging add-ons sorted out, and should be entering production shortly PinePhone Software: Ubuntu Touch mirclient support and trust prompts on the PinePhone; 20.04 upgrade Ubuntu Touch coming to the PinePhone PinePhone: handsfree and car kit for the PinePhone allowing to answer calls without interaction with phone; will also allow synchronising contacts PinePhone Software: LinMobApps features 300+ applications for Linux smartphones PinePhone Software: Work on MMS progressing well and work on Visual Voicemail is underway Pinebook Pro: New firmware solves many outstanding touchpad issues; majority of people now find the touchpad’s performance nearly perfect Pinebook Pro: we’ll see Vulkan support for the RK3399 in Mesa 21.2; it also includes OpenGL 3.1 Pinebook Pro: 64bit Box86 AMD64 architecture emulator now available, runs on Arm64 natively Pinebook Pro: Availability late this year looks more likely with decreasing LCD prices; good chance a large batch will be produced at end of the year PineTime: InfiniTime 1.3 release brings new watch face and LittleFS integration, paving way to accessing internal 4MB storage for additional apps \u0026amp; functionality. PineTime: WaspOS gets new alarm application and frees up 10% of memory; updated micropython PineTime: Two iOS companion apps in development for all you iPhone users PineDio: JF and Lup received PineDio Stack and PinePhone LoRa back cases; a closer look at the devices and discussion development challenges Housekeeping I know most of you want to get straight into reading about the PineNote but there are two housekeeping items that we need to address first. Gamiee and I will keep it short, we promise. Late last month DHL accidentally shipped all PinePhone orders (bar those dispatching from the EU warehouse) to New Zealand instead of their intended destinations. We initially hoped to quickly retrieve the shipping pallet and have it returned to Hong Kong, but DHL informed us that this will only be possible when an appropriate flight (allowed to carry battery-operated equipment) becomes available. Given these circumstances we made the decision to reship all orders from our Hong Kong warehouse, so you don’t have to wait until the misplaced pallet is returned to us. Those of you waiting for your PinePhones should have received tracking numbers by the time this post goes live, or shortly thereafter. We’re obviously very sorry for the situation, please accept our apologies. As always, you can follow shipping updates here. Gamiee: It is now more than a year since we moved all our services such as the official forum, Wiki and this webpage to a hosting cluster made out of 24 RockPro64s. During this time the cluster faced various challenges, such as for instance nodes freezing up - an issue which was solved by using iSCSI instead of NFS for root filesystem sharing. But except for such relatively minor issues, the cluster has now been running nonstop for 354 days! After we got the cluster up and running, we promised to write an article about it. This never happened however, as the write-up was kept being postponed until we felt the cluster was completed (in its final form). This still holds true: the cluster is still missing some things we’d like to add to it, like power cables for remote reset of the nodes, as well as other things that are hard to implement without shutting down our entire infrastructure. For this reason, we decided to build a small temporary cluster, which will house nodes with the most important services, so that we can finish our hosting cluster without a major disruption to our community services. In the coming weeks I (gamiee) will publish a community post about building this temporary cluster, and I will keep providing updates about the deployment as well as the next steps for the hosting cluster in weeks to come. More information will follow shortly, stay tuned.\nA screenshot of system uptime on one of the nodes\nPineNote You’ve been asking us to create an e-ink device for years, and indeed we actually looked to make one as early as 2017. I even remember publicly ping-ponging ideas with the community members at the time and researching which SoC would be the best fit for such a device. At the time we were looking to create an alternative to the entry-level Kindle and other such big-brand e-readers. We quickly learned, however, that big brands heavily subsidize their e-readers via book sales and even if we sold an open e-reader at cost (or a loss), we still couldn’t possibly match popular devices\u0026rsquo; price tag. Thankfully, the technology landscape and what is achievable using e-ink has significantly changed since 2017. Since the announcement of Rockchip’s RK3566 we knew our opportunity to create an open e-ink device had arrived. Early this year we made the decision to create the PineNote. The PineNote in the flesh (prototype)\nThe PineNote is one of, if not the, most powerful e-ink device available on the market. It shares in much of the Quartz64’s pedigree, sporting the same RK3566 quad-core A55 SoC paired with 4GB of LPDDR4 RAM and 128GB eMMC flash storage. The PineNote is also fitted with two microphones and two speakers, a USB-C port for fast charging and data, as well as 5Ghz AC WiFi. Suffice to say, there is more than enough power in the device to serve its intended purpose (more on that later). The inner frame - the midsection - of the PineNote is made out of a magnesium alloy (similar to the Pinebook Pros outer chassis), making for a sturdy construction, while the back features a pleasantly ‘grippy’ plastic back cover with speaker cut-outs. The e-ink panel is covered by scratch resistant and glare reducing hardened glass. The entire assembly comes in at just over 7mm thick, which is approx. 1mm thinner than the Kindle Oasis 3, if you ever held one of those.\nA closer look at the PCB (left) and internal layout (right) (images of engineering prototype)\nWith the base-specs out of the way, let’s talk about the e-ink panel, which is indisputably the most important part of the device. The 10.3 inch, 3:4 panel has a resolution of 1404x1872 (227 DPI), can display 16 levels of grayscale. It features a frontlight with cool (white) to warm (amber) light adjustment. What this means in practice is that you can illuminate the panel in dim or dark spaces to your liking. For those of you who don’t know, warm light is usually preferable in very dim spaces since it may significantly reduce eye-strain. I am also sure we’ll eventually see an automatic frontlight implementation, similar to KDE\u0026rsquo;s ‘Night Color’ or GNOME’s ‘Night Light’, which allow the OS to reduce the monitor\u0026rsquo;s (in this case the e-ink panels frontlight) blue light based on time of the day. Atop the e-ink panel sit a capacitive glass layer - for finger touch-based input - and a Wacom electromagnetic resonance layer (EMR) for EMR pen input. We will be selling a EMR pen for the PineNote, but in the event you don’t like it or already have a pen you’re accustomed to, then you can use it with the PineNote (granted it is compatible with the Wacom EMR standard).\nEdit August 16 00:09 UTC: A previous version of this post listed the e-ink panel\u0026rsquo;s refresh rate at 60Hz. This number requires much more context. It takes multiple frames to display most images on an e-ink panel. The visual performance of the panel also depends on the method of converting the screen image to data the panel understands. We will be unable to make estimates of the panel\u0026rsquo;s true performance in frames per second without much more testing and development. So we\u0026rsquo;ve removed the 60Hz figure for now. We apologize for any misunderstanding.\nWrapping up the hardware description section, the EMR pen (recommended by the vendor we’re working with) features a faint LED power on/off indicator, a previous/ next page button as well as an eraser button. I cannot say much more about the chosen pen at this time since I haven’t held it myself yet, but once I get some hands-on time with it I’ll be sure to share my initial impression. And while we can’t guarantee compatibility with any other pens on the market, we’re sure that people will test out their EMR pens and report back on the wiki so everyone can have a buyer’s guide.\nWe will be making the PineNote available for early adopters later this year for $399. The early adopter’s PineNote batch will ship with a magnetic cover (working with an on-board hall sensor, putting the device to sleep) as well as the EMR pen. Following the early adopter’s batch, both the cover and the pen will be sold separately. PineNote in the magnetic cover and the EMR pen attached\nAs far as software is concerned, much of the work to run a mainline Linux installation on the PineNote has already been completed thanks to development done on Quartz64. However, the e-ink panel driver will most likely not be functional at the time of the device’s release in mainline Linux. So initial batches will probably ship with Manjaro built atop of BSP kernel 4.19, unless devs can get the driver to work with 5.XX kernel in the next few months. Time will tell. As for the actual user interface, we’re currently talking to the good folks at KDE and trying to figure out whether Plasma Mobile or regular Plasma (with panel-specific tweaks of course) will be the best fit for this particular device. As you can probably tell, this is an uncharted territory for all parties involved, but we’ll figure it out. Needless to say, the software isn’t finished - indeed, we don’t really even know yet what will work well with this technology and what won’t. It is just the beginning of our journey with e-ink technology, and it will take a long time and much effort to make the PineNote end-user worthy. This is very much an active-development development device at this time, and you should expect it to retain this status for quite some time.\nEdit for clarity, August 15 19:38 UTC: We\u0026rsquo;re seeing a lot of excitement and \u0026ldquo;shut up and take my money, I\u0026rsquo;ll throw out my other e-ink devices tomorrow!\u0026rdquo; responses to this post, but remember that we are a community of developers first and foremost. If you\u0026rsquo;re looking to buy a PineNote in the first batch, you must expect to write software for it, not to write notes on it. The software shipping from the factory for the first batch will not be suitable for taking notes, reading e-books, or writing your dissertation. It may not even boot to a graphical environment. However, we are excited for what you\u0026rsquo;ll create with this device and we\u0026rsquo;re ready to take the journey with you. We\u0026rsquo;ll be posting more updates on software progress on this blog as they come in.\nIts alive! Pretty impressive, given that Peter (pgwipeout) has only had it for 48hrs - picture by pgwipeout\nAs I see it, the PineNote will eventually not only make for a great device to read books, comic books, sketching, taking notes and productivity in LibreOffice (as someone who does a lot of typing, I am looking forward to connecting a keyboard up to it and not having my eyes burn at the end of the night), but also for browsing the web or listening to internet radio or podcasts. I’m sure some of you lunatics will also use it for terminal work and other such applications - godspeed and have fun with it, you’ve got our blessing. But jokes aside, an open e-ink device such as this really holds a lot of potential and opens multiple avenues to explore. Don’t think of it as an e-ink notepad or an e-reader, it is much more than that. I am looking forward to seeing what people will use it for outside of its core intended purpose. Schematics and other details will be up on PINE64 Wiki sometime between now and launch. [edit 2:50 UTC, October 16] A preliminary PineNote Wiki site is now up with early schematics (v.1.0) and component list - click here.\nWhat sort of peripherals would you like to see for the PineNote? As I already mentioned, I’d personally like us to explore creating a dedicated keyboard for it, converting the PineNote into a quasi-laptop device. What else do you think would be an interesting peripheral, expansion or add-on? Please feed us some good ideas, we’ll surely consider them. You can chat about the PineNote on our forum and:\nDiscord Matrix\nTelegram\nIRC\nI talked to the good folks over at Destination Linux about the PineNote and our vision for this new hardware. During our chat we also talked about other PINE64 gear, including the PinePhone keyboard and much more. If you haven’t done so yet, follow this link to listen to the episode.\nBefore I wrap this section up let me clear one more thing up: I know that the introduction of the PineNote will lead people to think that other RK3566-based devices will follow shortly, but this isn’t the case. This isn’t the best time to introduce new devices in general, and certainly not ones based on a brand new SoC that is just undergoing a mainlining process. Just putting it out there to kill any unnecessary rumours. PinePhone: hardware This month’s good hardware news doesn\u0026rsquo;t end with the announcement of the PineNote. The PinePhone keyboard has entered production and we expect to have it available in the Pine Store in late September. I’ve now had extensive hands-on time with the latest keyboard prototype and I am thrilled to let you know that it feels amazing. You know that I am always cautious and try to avoid ‘hyping’ our devices - but my choice of words here is quite deliberate, the keyboard feels amazing. The keys are sturdy, easy to plunge and have a satisfying amount of key travel. The pressure needed to plunge the keys is also equal across the entire keyboard. The product team and vendor really deserve a pat on the back, they’ve done a great job. I have a few small form-factor devices with keyboards, and I can say with confidence that this is the best I’ve felt; thumb typing on it is pure heaven.\nI\u0026rsquo;ve been using the keyboard with Plasma Mobile for a couple of days and it has been a great experience so far\nThe keyboard has also received a lot of overall polish - the hinges have great resistance without feeling overly stiff (as was the case with previous prototypes), molding quirks have been worked out and the fit and finish is now great. The keyboard now also has a really nice matte black (and slightly textured) finish that doesn’t attract fingerprints. One notable difference from previous prototypes is the removal of LEDs in the upper right corner of the chassis. Personally I welcome this development, the LEDs were bright and given the small size of the keyboard they were quite prominent for a lack of better word. But I understand that some may feel otherwise about their removal. Under the hood the PCB has been significantly reworked: we tried to implement all the feedback we received from developers, last of which have been received hours before final PCB layout submission. I’d like to thank Megi, Martijn, smaeul, dsimic as well as others who spent time reviewing the hardware and suggesting improvements. Thanks guys!\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video A video showing the keyboard prototype in action - video by Martijn Braam\nWe have now also sent out back case samples to developers, settled on a wireless charging solution and managed to figure out a reliable way to flash the fingerprint-reader firmware at the factory. In result you can expect an introduction of the fingerprint reader and wireless charging back case in a matter of a few weeks, probably sometime in early October. The wireless charging chip is compatible with both Air Fuel and Qi Wireless charging solutions, and follows the Wireless Charging Consortium standard. This means that not only will the PinePhone charge (as you’d expect), but the chip will also allow us to have a charging rate read-out and control over the charging process itself via i2c. As for the fingerprint reader, the firmware and open software have now been sorted out, and it ought to be rather trivial to implement this functionality in existing PinePhone Linux distributions. As I mentioned in last month’s update, the LoRa back case add-on will need to wait a little bit, because we need software to work via i2c. But the good news is that both JF and Lup have received sample units to take a look at. Near final version of the wireless charging module (left) installed in the add-on back case (right)\nBefore I wrap this section up I wanted to ask: what other back cases would you like to see for the PinePhone? Any suggestions (barring NFC which we discarded for the time being) are welcome. We have some ideas of our own about what to explore once the current back case add-ons are released, but before I share with you what we’re considering I would appreciate hearing your ideas first - leave them in the comment section below.\nPinePhone: Software This section of the update was written by partner project developers and community contributors:_ Alfred (UBports), Dylan (postmarketOS), Peter (aka LinMob, the former PineTalk host and LINMOBapps maintainer), Chris (aka. kop316, working on MMS and Visual Voicemail functionality) and Brian (aka. 33YN2, PINE64 moderator and community contributor).\nImages and videos by authors / projects.\nAlfred: Let me start with Mirclient support. Ubuntu Touch on the PinePhone has always used Wayland for displaying app contents.This was quick to do for an initial bringup and the right step for future developments, but meant that certain functionality needed deep thought and reimplementation to allow the same experience across all supported types of devices and GPU driver stacks.\nDue to the fact that we wanted to bring the same experience to PinePhone users as quickly as possible, we decided to bring Mirclient support to the PinePhone as an addition to Wayland. This practically means that Ubuntu Touch based on Ubuntu 20.04 will feature support for both apps that integrate well into the overall system as well as allowing Wayland-only apps to continue functioning properly. Wayland support will not go away and going full-on Wayland will be tackled after the Ubuntu 20.04 transition. This is a short-term solution to bridge the gap between the past and the future for both users and developers.\nThe next subject I want to tackle are trust prompts. The addition of Mirclient support in Ubuntu Touch 20.04 allowed us to bring one crucial feature to PinePhone users: Trust prompts. Trust prompts are a mechanism on Ubuntu Touch to securely ask a user for permissions to certain functionality, on behalf of the application. They slide up, stick above the application and wait for user interaction. If a user doesn’t want to allow an app recording audio then they are able to decide and change it later on. Integration into certain subsystems was necessary, from adapting almost-there Mir code to applying integration patches onto PulseAudio.This means that users can have a bit more trust in the platform as well as having their applications work properly.\nExample of a trust prompt on Ubuntu Touch (left) and PinePhone running Ubuntu Touch 20.04 in convergence mode (right)\nUbuntu Touch 20.04 images should be available for the PinePhone soon and users will be able to switch to it either via the command line without losing their data or by reflashing their device.\nDylan: Almost every phone over the last two decades can be used in a car\u0026rsquo;s handsfree kit to make calls. Some of these handsfree kits also allow you to synchronize your contacts to the handsfree kit. This way, you can call your contacts through the handsfree kit without even touching your phone. However, that\u0026rsquo;s not the case with the PinePhone as it doesn\u0026rsquo;t support the required Bluetooth profile Phone Book Access Profile PBAP to achieve this. Fortunately, Bluetooth PBAP is supported by the BlueZ bluetooth stack using the OBEX daemon, but the PBAP code hasn\u0026rsquo;t been touched in almost 10 years!\nI revived the BlueZ backend in the OBEX daemon to access the Evolution Data Server phonebook of the PinePhone (Phosh UI only) and submitted some patches upstream which will be available in the next BlueZ release. After applying these patches, your PinePhone can synchronize your contacts with any Bluetooth handsfree kit which can be found in cars!\nSee Address book synchronization over Bluetooth on the Pine64 PinePhone running Phosh.\nCar handsfree working with the PinePhone, how cool is that?\nChris: While I have been steadily working to help finalize MMS support in Phosh, I am excited to show off another phone feature I have been working on: Visual Voicemail (VVM). For those not familiar with Visual Voicemail, it is a way to download and “view” voicemails instead ofdialing a number to listen to them.\nI added support with two applications: Visual Voicemail Daemon (VVMd) and Visual Voicemail Player (VVM Player). VVMd is a user daemon that retrieves/stores Visual Voicemails from your carrier. VVMd is desktop environment neutral, so it should work with the desktop environment of your choice! While VVMd only has a plugin that works with the ModemManager telephony stack, I am happy to work with someone to add a plugin to support other telephony stacks, such as oFono. VVM Player is the GTK3 front end to VVMd. You can see screenshots here and here. You can also see a video of it in action below.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video A demo of Visual Voicemail on the PinePhone\nRight now, Visual Voicemail on the Pinephone is confirmed to work on T-Mobile USA, T-Mobile USA MVNOs (Mobile Virtual Network Operator), and AT\u0026amp;T USA. If you want to keep up with the development (or help out), feel free to join the Matrix Room (#opensourcemms:matrix.org) or the IRC channel (#opensourcemms on OFTC), which is bridged to Matrix. Peter: LINMOBapps now lists more than 300 apps for Linux smartphones now. Note that not all apps are packaged for your distribution, nor are they all what you would consider feature-complete. Also, the current technical implementation of the app list does not perform particularly well on the PinePhone (the performance is actually getting worse with every additional app), which is why I am looking to replace it with another solution. You can follow, join and help out the development on GitHub or wait for an early alpha version of the new implementation, which should be out later this month on alpha.linux phone apps.org.\nMaybe its falls a bit short of the PlayStore selection, but boy is it an impressive and well documented list of Mobile Linux compatible apps\nBrian: For those of you missing a way to share recordings of your PinePhone\u0026rsquo;s interface, or a way to share a recording from your camera, user u/UJC_theguy on the official PINE64 subreddit has shared his discovered method of recording video on the Pinephone at 1280x720 resolution and 30 fps. While it\u0026rsquo;s definitely not perfect, this is an excellent step towards video-recording on the PinePhone. Click here to learn more.\nPinebook Pro Pinebook Pro owners have a reason to rejoice: a new and much improved firmware for the trackpad has been released. The Pinebook Pro’s trackpad is, or rather was, the main complaint people always voiced about the laptop. It lacked precision, there was delay between the input and the cursor movement, and at times it would act up completely - causing the cursor to skip from one part of the screen to another. All these issues are now gone, and you don’t have to take my word for it - 77% of people who performed the update on their Pinebook Pro and filled in dsimic’s questionnaire rated the firmware as “feels nearly perfect”. The new touchpad firmware is a major improvement, and don\u0026rsquo;t take our word for it\nThe update process can be performed on any OS distribution and instructions for flashing are available for both Manjaro and Debian (and derivatives). I’d like to thank dsimic for his hard work on getting the new firmware bundled with the existing tools and writing up flashing instructions. He is currently also working on making the entire process more streamlined for end-users by making an attempt to package the firmware for fwupd. This will, hopefully, make the process trivial in the future. However, the current flashing process can be performed by just about anyone who is capable of following written instructions. So if you have a Pinebook Pro, I strongly advise you to carefully read dsimics firmware flashing thread on the forum and have a go at it. In other Pinebook Pro related news, graphics on the RK3399 might be seeing some major improvements in the next few months. Merged back in June and now released in Mesa 21.2 is a new Vulkan driver for Arm Bifrost and Midgard graphics called PanVK, and the new Mesa release now also includes OpenGL ES 3.1 support for Panfrost. It should be noted that PanVK is not yet conformant, and that the work on it is still in its early stages, but it is nevertheless very promising and with it being included in Mesa it should see more contributions.\nBack in July Box64 was released as the new x86_64 emulator for ARM64. While the Pinebook Pro community did previously have Box86 for running x86 software on ARM, it only supported ARM32, meaning you had to run it within a container or on a multilib system. With Box64 however, it is now possible to run software compiled for desktops on ARM devices such as the Pinebook Pro without having to use containers or other trickery. Of course, this technology is not magic, and there is a loss of performance through such a layer, even with the technology that Microsoft (WoW64) or Apple (Rosetta 2) use in their operating systems.\nLastly, I want to give a quick update regarding Pinebook Pro availability (we know that many of you are waiting to get one): IPS panel prices have finally started to come down, but their price-point hasn’t yet reached a level where we could manufacture a new production run. That said, we’re hoping to see prices decrease further in the coming weeks, at which point we’ll start exploring the potential for producing another batch. In other words, there is a good possibility that we’ll see another large batch of Pinebook Pros produced before the end of this year. Keep your fingers crossed.\nBox64 opens up many opportunities on the Pinebook Pro, such as playing X86 games - picture via Kirfkin on Twitter\nPineTime [By** JF**] The activity around the PineTime project is still going strong: InfiniTime released version 1.3 (and many new features are awaiting review), WaspOS features a new advanced alarm application, Siglo is available on Flathub, FitoTrack supports the PineTime out of the box and we have two iOS companion apps in the work.\nLet\u0026rsquo;s start with InfiniTime. As announced in the last community update, the release of version 1.3 came with a new watch face named PineTimeStyle. It\u0026rsquo;s a nice and stylish watch face, which is directly inspired by a popular watch face from the Pebble smartwatches. Another new interesting feature from this version is the battery level notification - the watch periodically sends the battery level to the companion app. Gadgetbridge uses this feature to draw a nice graph representing the history of battery usage. Another great feature of this release is the integration of LittleFS. While not apparent to the end user, this small file system in the *huge* (4MB) external memory is the first step to new features requiring persistent storage: fitness data, more graphical content, more fonts, more languages, etc.\nNew watchface (which some of you may recognize from the Pebble) and improvements to existing applications in InfiniTime 1.3\nWhile development has been slower these past few months, WaspOS has again still seen a few big improvements. Most notably Micropython was updated to 1.16, and the merging of the previously mentioned Advanced Alarm application has finally happened. The new alarm application will allow you to set multiple alarms on specific days of the week, and it also adds a snooze option. There was also a major memory improvement that frees up 10% more RAM in applications.\nThere is also good news concerning different companion apps for PineTime. First, Siglo, the GTK app allowing InfiniTime to sync the watch with mobile or desktop Linux, is now available on Flathub. This means it\u0026rsquo;ll install and run easily on any Linux distro that supports Flatpack, such as Fedora.\nFitoTrack is a privacy oriented fitness tracker for Android in which you can log and view your workouts. It records GPS positions, speed, distance, kcal and displays nice stats and graphs about your workouts. It can also connect to BLE heart rate monitors to record your heart rate while you\u0026rsquo;re doing sports. The good news is that it implements the Heart Rate Profile standardized by the Bluetooth SIG, the very same protocol InfiniTime implements to expose heart rate data to the companion app. This allows FitoTrack and Infinitime to work together out of the box without needing any further work on either project. If you were looking for some motivation to exercise this is probably welcome news.\nFitoTrack app for Android now works with InfiniTime on the PineTime\nA couple weeks ago I posted a call for Apple/iOS developers. PineTime and InfiniTime have a growing user base, and some users would like to sync the watch with an iOS device. It seems that my call has been heard as I\u0026rsquo;ve recently learned that there are not one but two iOS applications in the works: Comosus Time by Jim and Infini-iOS by xan-m. These apps are still in early development stages but they already have features like time synchronization, battery level and heart rate monitoring and firmware update (OTA). Let’s us wish Jim and xan-m best of luck with their projects!\niOS companion apps for the PineTime are in the works - Comosus Time (left) and Xan-m (right)\nFinally, I would like to share this demo from TT-392 showing Bad Apple playing on the PineTime! I was blown away when I saw this 3 minutes and 40 seconds video playing on the limited hardware of the watch. It reminds us how limitless a hackable device can truly be.\nhttps://www.youtube.com/watch?v=RqL8V3xWmxg\nPineDio PineTime [By** JF**] Last month we announced the PineDio Stack, an all-in-one development platform based on the BL604 RISCV MCU and the SX1272 Lora module, along with a LoRa back case for the PinePhone and many other LoRa devices.\nA couple of days ago I received a nice parcel from Pine64 containing prototypes of these new LoRa devices: the PineDio Stack with a display, another PineDio Stack in a solar enclosure with a bigger battery, a LoRa USB adapter and a LoRa back case for the PinePhone. I\u0026rsquo;m sure you\u0026rsquo;re as excited as I am about these new devices, so let\u0026rsquo;s have a closer look at them!\nThe PineDio Stack is a development kit built around the Bouffalo BL604 MCU. This RISC-V processor is really similar to the BL602, except it has more I/O pins available. It runs at 192Mhz, has 2MB or flash memory, 278KB or RAM memory and supports Bluetooth Low Energy (BLE) 5.0. The PineDio Stack also provides LoRa connectivity via a SX1262 LoRa module. Finally, the stack is equipped with a display, a heart rate sensor, a motion sensor, a USB to Serial adapter, a USB-C port, a GPIO port, a JTAG port and a battery charging chip - basically all you need for your embedded and IoT project in 3.5cm2. I haven\u0026rsquo;t been able to check this board yet, but I plan on porting InfiniTime, the FOSS firmware for the PineTime on this board Soon®.\nPineDio Stack front (left) and back (right) with JTAG, a battery and a PineTime display attached\nThe next item I want to show you is the solar enclosure for the PineDio Stack. It consists of a big solar panel, a large battery and the PineDio Stack with its LoRa module. With this device, in example. you will be able to build an autonomous LoRa base station\nPineDio Stack solar panel case outside (left) and the internal component arrangement (right) (images of a prototype unit)\nLast month, we also mentioned that the LoRa back case for the PinePhone was taking shape (but we still need an I2C driver to be able to use it from the Pinephone). Here\u0026rsquo;s a closer look at the back case and the LoRa adapter itself:\nPinePhone add-on back case disassembled (left) and the PineDio LoRa add-on module (right)\nFrom what I can tell, it\u0026rsquo;s based on the SX1262 LoRa module and an ATtiny64, acting as a bridge between the I2C bus of the Pinephone and the SPI bus for the LoRa module.\nFinally, let me show you the Pine64 LoRa USB adapter. It\u0026rsquo;s also based on the SX1262 LoRa module and relies on a CH341 USB to Serial adapter to connect to a computer\nUSB PineDio LoRa adapter\nIn the next couple of weeks I\u0026rsquo;ll experiment, develop projects and provide feedback to PINE64 and to the community about these really exciting new devices.\nThat is all for this month. We\u0026rsquo;ll catch you all in September with more news, updates and announcements.\n","permalink":"/2021/08/15/introducing-the-pinenote/","tags":["pinedio","pinenote","pinephone","pinetime","quartz64"],"title":"Introducing the PineNote"},{"categories":null,"contents":" Download audio\nIn Episode 13, Peter and Ezra discuss the PINE64 July Community Update and go through more Community Questions than ever before! There’s also something fun and it ends with a bang!\nWhat have we been up to? Ezra:\nYouTube, Odysee, Elatronion.com, Fan game: Televoid: Out Of The Loop, Video: System 76 Pop!_OS 21.04 w/ COSMIC | Best Linux Distro!? Peter:\nPeter’s weekly updates Flatpak Manifest for Clapper-git App of the Episode: Image Roll Flathub: Image Roll GitHub: Image Roll Community News PINE64 July community update Housekeeping: PINE64 development portal PINE64 DevZone PineTime InfiniTime 1.2.0 WaspOS Malila Malila Design mockups PinePhone: Hardware Megi’s Blog: PinePhone keyboard’s final summary PinePhone: Software Brian Daniels: Hardware Accelerated Video Decoding on the PinePhone with Clapper Clapper Peters Flatpak recipe Arch Linux ARM by Danct12 dni’s pull request postmarketOS 21.06 announcement linmob.net: Phosh 0.12 and its app drawer refinement Quartz64! Docs: Quartz64 PineDio Make sure to read the full update\nPINE64: July Community Update: community developers portal or watch it: Video by PizzaLovingNerd: Odysee, TilVids, YouTube Community engagement 😀 Listener Questions Status of Quartz64 Model B, see here.\nRockPro64 upgrade and eDP status, see here.\nChina, Open Harmony OS and plans for PP Pro, see here.\nOpenHarmony (GiTee) FOSDEM 2021: OpenHarmony - more than an OS Current state of PinePhone distributions, see here.\nPINE64 docs: PinePhone Software Releases Hypothetical Sxmo Distributions, see here.\nSxmo.org Background of PINE64, see here.\nFoss North Podcast: #34 with Lukasz Erecinski from Pine64 Stepping downs More Feedback and Questions welcome! Remember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nCredits Intro and Outro Music Music by Bradley (PixelPaintbrush) Ames\nExclusive Intro/Outro written and edited by Ezra Hradecky Cast Ezra played by Ezra\nPeter played by Peter\nFAANG played by Peter\nFAANG’s minion played by Peter\nScore Track Artist License raising evil Oleg Makarov https://creativecommons.org/licenses/by-nc-nd/3.0/ Cybernetic Rhythm Michael-K https://creativecommons.org/licenses/by-nc-nd/3.0/ The Road Adventures 83Crutch https://creativecommons.org/licenses/by-nc-sa/3.0/ In Dark Triller soundside (royalty free music) https://creativecommons.org/licenses/by-nc-nd/3.0/ Rejuvenation - Full Length pinegroove https://creativecommons.org/licenses/by-nc-nd/3.0/ Audio Production Thank you to NerdZoom Media for being PineTalk’s audio producers!\n","permalink":"/podcast/s01e13/","tags":null,"title":"S01E13: 13th of July"},{"categories":["community","news","pinedio","pinephone","quartz64"],"contents":"\nThis month’s big news isn\u0026rsquo;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.\nI’d like to thank JF, Alex (clover), Danct12, Peter (pgwipeout), Martijn Braam, Brian (33YN2) and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Community update video summary by PizzaLovingNerd\nTL;DR\nHousekeeping: we’re creating a community developers portal called the PINE64 DevZone; sign-ups are open PineTime: sealed PineTime units with InfiniTime 1.2 \u0026amp; newest bootloader are now available in the PineStore for $26.99 PineTime: InfniTime 1.2 brings new apps, improvements to RAM and ROM memory and various bug fixes; upcoming release will feature a new watchface PineTime: WaspOS gets a sports app, a watch face chooser and a visual overhaul PineTime: New firmware announced - Malila is based on RIOT and in early stages of development PinePhone Hardware: final keyboard pre-production units now being made, production to start immediately after final review if no issues are found PinePhone Hardware: wireless charging and fingerprint reader back cases being tested and reviewed in coming days; LoRa back case awaiting I2C driver PinePhone Software: PinePhone now playing back accelerated video; app called Clapper made available PinePhone Software: Arch Linux with Plasma Mobile now available to download; a SXMO build coming later this month PinePhone Software: postmarketOS gets an update with quick suspend/resume support and number of other improvements in both stable and edge Quartz64: software progressing at a very rapid pace and upstreaming of patches is underway Quartz64: big missing functionality features include display output (worked on), audio out (worked on) and e-ink; latter will likely prove a challenge Quartz64: we now have buildroot, Debian and a plug-and-play Manjaro OS images available for the model-A PineDio Stack: a LoRa and BL602/604 development platform; allows you to plug in peripherals, has a small LCD screen and can be powered from batteries PineDio Stack: can be used with solar power and fitted with batteries for a variety of implementations; we will likely offer voltaic panels for to fit the Stack PCB into Housekeeping: PINE64 development portal 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\nLet’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\u0026rsquo;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.\nPineTime [by JF \u0026amp; 33Y2N] Let me start with really good news for those of you waiting (im)patiently to get their hands on a PineTime: I\u0026rsquo;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\u0026rsquo;ll be able to get the most out of your watch the moment you receive it.\nAs 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.\nThe 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\u0026rsquo;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\u0026rsquo;ll be able to add more features to the firmware in the future. As always, InfiniTime developers didn\u0026rsquo;t stop at this, and we are already working on the next release that will bring, among other things, a new stylish watchface!\nLeft: metronome // Right: stopwatch\nIn 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).\nThis month, I\u0026rsquo;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\u0026rsquo;s the announcement he made earlier in the chat rooms:\nHi community, I wanted to share something I\u0026rsquo;m working on: https://github.com/arteeh/malila\nIt\u0026rsquo;s a simple firmware for the Pinetime, based on RIOT. It doesn\u0026rsquo;t have any functionality, and it doesn\u0026rsquo;t support the bootloader yet, so as an end user don\u0026rsquo;t expect anything from it just yet :)\nI 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\u0026rsquo;re writing to isn\u0026rsquo;t already that color.\nIt\u0026rsquo;s grayscale because a full 16 bit (65536 colors) buffer would be 115kb of RAM, which won\u0026rsquo;t fit. 8 bit (256 colors) using 57kb might theoretically fit, but would not leave room for any other software.\nAnyway, 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.\nLong shot, but eventually I would like my project to have the following features:\n- A nice looking Gnome-style (Cantarell font, Gnome icons and symbols) UI\n- Micropython support\n- Support for all the hardware (touch, hearbeat, etc.) and a way for Python programs to interact with it\n- 6LoWPAN networking over BLE (RIOT seems to support this, and Linux has a kernel module for it)\nCheck out the repo if you want :-)\nThe 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:\nRender of Malila PineTime firmware\nLet\u0026rsquo;s wish Maarten best of luck!\nPinePhone: Hardware 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. https://youtu.be/Gnb8K80h9aU\nLeft: final (hopefully) revision of the keyboard membrane // Right: keyboard testing at factory\nIn 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.\nhttps://youtu.be/qEXv_SrD0TA\nLeft: LoRa back case electronics // Right: PinePhone unlocked using fingerprint reader\nPinePhone: Software [by 33Y2N, Danct12 \u0026amp; Martijn Braam] 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.\nhttps://www.youtube.com/watch?v=BvmRV6IIGGo\nHardware accelerated video in Clapper - by Brian Daniels\nIn 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\u0026rsquo;s update schedule set out by the KDE team, which means that aside from bug fixes, there won\u0026rsquo;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\nLastly, 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. Quartz64 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 ;)\nOther 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\nFor 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\u0026rsquo;ll see wide-range support for the platform. PineDio 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.\nPineDio Stack assembled PCBs\nWhile 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.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Left: Stack powered by solar energy // Right: Stack inside voltaic panel case fitted with a 18650 battery\nIn 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!\n","permalink":"/2021/07/15/july-update/","tags":["community","developers","pine64","pinedio","pinephone","quartz64"],"title":"July update: community developers portal"},{"categories":null,"contents":" Download audio\nIn the twelfth episode of PineTalk, Ezra and Peter are joined by RTP to talk privacy and security. They also discuss community news: Pineroot, InfiniTime 1.2.0, accelerated video playback on PinePhone and an example for a Lora communicator. The episode concludes with feedback regarding Signal Desktop on PinePhone and two hardware-centric questions.\nWhat have we been up to lately? Ezra: YouTube, Odysee Elatronion.com Fan game: Televoid: Out Of The Loop. Televoid series on YouTube Peter: Blog post on GNU/Linux on Tablets App List App of the Episode KDE Itinerary Interview with RTP Right to Privacy is a content creator that focuses on privacy and security topics.\nThe one video listeners really should watch: Securing SSH On Pinephone + Hydra Demo On Default Setup (Plus Fixes!) on YouTube, Odysee, PeerTube. And here is where you can to follow RTPs work: Blog, YouTube, Odysee, PeerTube, Fosstodon, Twitter. Thanks again to RTP for coming on!\nCommunity News pineroot See pineroot\nis a buildroot environment for PinePhone. PineRouter (see also Twitter) which turns your PinePhone into an LTE Router appliance. Follow the project on Twitter Brian Daniels: Hardware Accelerated Video Decoding on the PinePhone Brian Daniels: Hardware Accelerated Video Decoding on the PinePhone\nInfiniTime InfiniTime 1.2.0\nLora Lora communication: LORA Messenger in Nokia’s shell GitHub Project Community engagement 😀 Listener Feedback undev wrote in about Signal Desktop Builder\nSignal Desktop Builder Listener Questions New Questions\n@jokeyrhyme@mastodon.social asked about Future revisions of PinePhone and PineBook/PineBook Pro.\n@goldfinch@fosstodon.org asked about the hardware we would like to see from PINE64 in the future\nModular hardware\nMntmn EOMA68 Feedback and Questions welcome!\nRemember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nCredits Intro and Outro Music Music by Bradley (PixelPaintbrush) Ames\nThank you to NerdZoom Media for being PineTalk’s audio producers!\n","permalink":"/podcast/s01e12/","tags":null,"title":"S01E12: Privacy and Security with RTP"},{"categories":null,"contents":" Download audio\nIn this eleventh episode Ezra and Peter discuss the June Community Update and interview content creator Linux Lounge! They also discuss (your) community feedback and questions!\nWhat have we been up to lately? Ezra: is releasing a game! It’s nearly done! It should be released June 22nd if no serious issues arise. Otherwise, shortly after. The game is, of course, open source. So, you can make fun of my horrifying code. It’s a mysterious adventure filled with a handful of minigames, a short story and minimal moon logic. It’s called \u0026ldquo;Televoid: Out of The Loop\u0026rdquo; and is a fangame for a show I enjoy: Televoid, an online series staring Ian MacLeod on his YouTube Channel. To show our appreciation of this amazing series, some fans and I got together to make this game. It’s pretty much consumed my life these past few weeks… After the released, I might have some fun and see if I can’t port it to the pinephone, for the giggles. otherwise… I’ve also been back on the video making train! YouTube, Odysee. Peter: wrote a bad blog post because of having had a PinePhone for a year, GloDroid video, has written the 50th installment of LinBits, the weekly update on all things Linux Phones in between recording and publication of this episode. App of the Episode Spot Get it on Flathub! Interview with Linux Lounge Make sure to follow Linux Lounge on the following platforms:\nYouTube Odysee PeerTube.co.uk TilVids Fosstodon Linux Lounge’s Videos about PINE64 hardware Workflow:\nLinux Lounge: How I Create Videos Using Linux and FOSS Software! BTW: There’s a project that tries to recreate the Windows Phone Live Tile experience on the PinePhone: Retiled\nCommunity News PINE64: June Community Update sub-titled \u0026ldquo;new hardware and more on the way\u0026rdquo; Full blog post Video by PizzaLovingNerd YouTube, Odysee, TilVids. Housekeeping Getting started Quartz64 PINE64 store: Quartz64 Docs: Quartz64 PinePhone: Keyboard accessory news Go read Megi’s blog for more PinePhone Software Plasma Mobile’s update MMS progress by Chris/kop316 mmsd-tng Pinecil PINE64 store: Pinecil Preheater Hammerhead Tip Community engagement 😀 Listener Feedback Blort blort@tube.tchncs.de on TilVids Listener Questions Frater Michal\u0026quot; @MonsDraconis asked on Twitter Any information on kde/gs connect for pinephone distributions?, see here\nTry GNOME on Megi’s p-boot-demo image to try GSConnect KDE Connect @PitrusCitrus@mastodon.social asks Question to the both of you @talkpine. What is a project you want to see on the pinephone that can be realistically done by a beginner programmer who’s looking to get their hands dirty and expand their skillset? Be it practical, cool or just plain fun, throw us some ideas! See here\nWe crowdsourced this question on Discord, Twitter and (most successfully) Fosstodon, and came up with the following (thanks again!) Roku Remote rokugtk Nextcloud client Port GadgetBridge to Linux Siglo Amazfish Martijn Braam had four suggestions More general suggestions were also received Perhaps adding functionality to an existing application might be a good way to start? LVGL (a lightweight toolkit that could be used for a fast GUI) Lup Yuen Lee: LVGL on PinePhone Also, if this is not enough, you might want to have a look at the Mobian App Wishlist.\nFeedback and Questions welcome!\nRemember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nCredits Intro and Outro Music Music by Bradley (PixelPaintbrush) Ames\nThank you to NerdZoom Media for being PineTalk’s audio producers!\n","permalink":"/podcast/s01e11/","tags":null,"title":"S01E11: Lounging with Linux Lounge"},{"categories":["community","lora","news","pinecil","pinedio","pinephone","pinetime","quartz64"],"contents":"\nI’d like to start by giving you all a quick heads-up: next month I am away on vacation (first one since early 2020), which means that next month’s update will either be very short or split into multiple posts. If I write up a longer post then I may not publish it on the 15th but at some other point in time. I haven’t yet made up my mind how I’ll do this, so just keep an eye out. With that out of the way let us get into this month’s news - the biggest one of which is that Quartz64 model-A is now available for purchase! You can watch the synopsis of this month’s community update on YouTube (embedded below) as well as on Odysee and Peertube. Stay up-to-date with PINE64 news and 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.\nI’d like to thank JF, Alex (clover), Ondrej (Megi), Chris (kop316), Brian (33YN2) and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video June community update video summary by PizzaLovingNerd\nTL;DR for this month\u0026rsquo;s communty update:\nHousekeeping: improvements to product pages and getting started. A new shipping, stock and availability tracker added to website Housekeeping: a quick notice regarding code of conduct, moderation and just being a decent person to others Quartz64: the model-A is now available in the Pine Store! (4GB model - $59.99 // 8GB model - $79.99) Quartz64: development is proceeding quickly, but for now this is a board for developers and enthusiasts capable of contributing Quartz64: model-B, with smaller footprint, available at a later date Quartz64: introducing the SOQuartz compute module, featuring industry-standard 100 pin connectors PinePhone Hardware: keyboard coming along well, two iterations of prototypes built in past 30 days PinePhone Hardware: the keyboard now runs open firmware thanks to Megi; keyboard battery levels now reported in Linux; review of second iteration reveals some minor remaining problems need to be worked out PinePhone Hardware: delay on Wireless charging back case because TI chip not available (silicon shortages) PinePhone Software: Plasma Mobile 5.22 released; many improvements and new apps PinePhone Software: even more improvements coming in Plasma Mobile 5.23 PinePhone Software: MMS (mmsd-tng) functionality coming along; kop316 working towards a v1.0 release, already in Mobian and postmarketOS PineTime: availability of single sealed PineTime delayed due to component shortages: replacement part sourced, but needs to be verified, tested and potentially enabled in firmware PineTime: a lot of development taking place, including optimizations for RAM and flash storage; many new apps being developed, inc. weather forecast, likely to be included in InfiniTime 1.2 PineDio: It will take us a little longer to deliver PineDio gateways - component shortages, affecting Realtek PHY, forced us to create a V2 revision of PINE A64-LTS - used as based for PineDio gateways PineDio: Board bring-up takes time, but we’re committed to bringing the PineDio LoRa-range of devices to the market ASAP PineDio: work on outdoor gateway ongoing; antenna routing being done currently; outdoor gateway includes 3x18650 battery holder and PoE adapter Pinecil: The Hammerhead kit is now available in the PineStore for $24.99! Pinecil: Hammerhead kit features 2x heads, 1x custom threaded shaft/tip and a 500*C resistant mat Housekeeping A lot of work has gone into improving the Community website this past month. Product pages have been reworked to be more informative and to include additional resources. If you have any suggestions for further improvements to the product pages, make sure to leave them in the comments section. We also added a shipment, stock and availability tracker on the website, allowing users to check current stock levels, estimated availability dates for popular devices and shipping status information. The system will be further refined in the coming weeks, but I feel that this is a good starting point. If you’d like to see other devices on the webpage, leave your suggestion in the comments section. We also reworked the [getting started](https://www.pine64.org/documentation/Introduction/Getting_started/ page on the website. The new page is a significant improvement in every respect. It offers a quick overview of individual devices\u0026rsquo; software maturity, recommended operating systems, and links to further resources. We also included all the necessary links to join the community. Once again, if you have suggestions for further improvements, leave them in the comments section. I am really keen to hear your feedback. You now can check stock levels, estimated availability and shipping on this site\nThe getting started page is now much better at actually getting you started\nNext, let me touch upon chat etiquette and moderation briefly. As you know, a part of what makes PINE64 special is the direct involvement of developers from partner projects (as well as community contributors) on our chats and forums. Having developers from the different projects participate, work together and communicate with users is a major boon for us all. It is therefore alarming that in recent months we’ve seen an increase in non-constructive dissent. I don\u0026rsquo;t wish to dwell on this - but long story short, it is one thing to voice an opinion and offer feedback, and another to ridicule or be hostile towards partner project developers. Just because you don’t like a particular OS or UI doesn’t make it hate-worthy. After all, it is people’s hard work, and it is open software, so I’m sure there are other objects more deserving of contempt. Developers are people too and they have their individual sensitivities - how you communicate matters, please keep that in mind. To finish this section off on an uplifting note: I encourage everyone to listen to the latest PineTalk episode, in which Ezra and Peter interview Martijn Braam from postmarketOS and talk about how he got started with smartphone development and much more. The episode is worth listening to for the intro alone.\nLastly, a quick reminder that KDE Akademy is taking place June 18-25. This is also the fourth year in a row that PINE64 is a sponsor of the event.\nQuartz64 After months of work, the Quartz64 is now available in the Pine Store. Let me begin with a short recap: the Quartz64-line is a series of computers featuring the Rockchip RK3566 SoC. This SoC combines a quad-core, ARM Cortex-A55 CPU with a Mali-G52 2EE GPU. It is capable of driving a single 4K display at 60fps and the GPU uses the open source Panfrost driver. It also has the benefit of running very cool, even without a heatsink and under a sustained load. The Quartz64 is a powerful and versatile platform that will serve us for years to come, also as a basis for future non-Pro PINE64 devices. Quartz64 model-A viewed from top\nQuartz64 model-A front IO\nRight now, Quartz64 is only suitable for developers and advanced Linux users wishing to contribute to early software development. Both mainline and Rockchip’s BSP fork of Linux have already been booted on the platform, and development is proceeding very quickly, but it will be months before end-users and industry partners can reliably deploy it. If you need a single board computer for a private or industrial application today, we encourage you to choose a different board from our existing lineup or wait a few months until Quartz64 software reaches a sufficient degree of maturity. A matrix-style visual representation of the software development status is available on our Wiki. It will be updated as new milestones are reached. You can also follow, and contribute to, the ongoing development on GitLab. You can learn more about the Quartz64 model-A from my previous community updates written in February, March and May. The model-A footprint matches our ROCKPro64 and PINE A64-LTS boards. It can be used as a stand-alone computer as well as a development platform for future PINE64 devices. The board features an extensive I/O configuration, including:\nGigabit Ethernet Digital video and audio out Three USB 2.0 ports One USB 3.0 port One SATA 3.0 (6Gbps) port One eMMC slot One microSD slot Embedded DisplayPort (eDP) E-ink display connector MiPi DSI 4 lanes MiPi CSI 4 lanes Touch Panel port Lithium-Ion Polymer battery charger and power supply 2x10 GPIO header pins PCIe ×1 open-ended slot We are also providing an optional WiFi 802.11 AC +Bluetooth 5.0 module which interfaces with the board via SDIO 3.0. An alternate module featuring the Bouffalo 602 RISC-V 802.11n + BLE 5.0 module, currently undergoing open-sourcing, will also be available for the board in the future.\nThe Quartz64 model-A is available in two RAM configurations at launch: 4GB LPDDR4 RAM - $59.99 8GB LPDDR4 RAM - $79.99 As always, you’ll find complete specifications of the Quartz64 model-A, alongside relevant schematics and documentation on the Quartz64 sub-section of the PINE64 Wiki. In the coming months you will also see us introduce the Quartz64 model-B, a physically smaller board, sharing the same footprint of our ROCK64 computer. The smaller size means this device is great for education, tinkering, personal projects, and similar applications. However, the smaller form factor limits the available IO. For this reason, the Quartz64 model-B will not be used as a development platform for our future devices in consumer form factors. WiFi and Bluetooth are integrated on the Quartz64 model-B. Users will be given a choice of either the BL-602 RISC-V 802.11n and BLE 5.0 module, currently undergoing open-sourcing, or an AP6256 802.11ac WiFi + Bluetooth 5.0 module. I wrote about the model-B at some length in the April community update, if you want to learn more. Quartz64 model-B top / bottom (prototype)\nLastly, I am happy to introduce you to the newest member of the Quartz-line of products: the SOQuartz. The SOQuartz is a compute module that is software compatible and built on the same architecture as the Quartz64 single board computers. The module will share the Quartz64 RAM configuration and host onboard eMMC flash storage. Flash storage can be added via the eMMC socket (it accepts standard PINE64 eMMC modules) or by having it soldered on the back-side of the PCB. The option for a soldered-on eMMC adds a degree of flexibility for industry partners who may wish to standardise a hardware rollout. The SOQuartz comes equipped with an Azurewave AW-CM256SM WiFi 802.11ac Bluetooth and WiFi module with an U.FL antenna connector. On the bottom of the PCB you will find the now industry-standard 100-pin high density connectors. This means that it will be possible to use the SOQuartz as a drop-in replacement for the most popular solution on the market.\nSOQuartz top (prototype)\nSOQuartz bottom (prototype)\nI’d like to end by thanking everyone who has helped us create the Quartz64, in particular community developers who have been working on it for the past 3 months. Their feedback and insights made the Quartz64 model-A a much better device. We’re interested, what would you use Quartz64 to create? Are you getting in early to learn about the RK3566 and build the open-source drivers that will make it great? Or will it be exactly what you need to build the project you’ve always dreamed of, after some more hardware enablement? Let us know in the comments.\nPinePhone Hardware\nSince last month\u0026rsquo;s update we’ve sent out two iterations of PinePhone keyboard prototypes to developers for the purpose of internal testing and review. I\u0026rsquo;ve received the first iteration myself and offered extensive feedback to the product team. As you\u0026rsquo;d expect from a prototype device, there were some issues. Aside from some relatively minor fit and finish problems, and a few oversights (e.g. the wrong number of holes for LED lights), the biggest problem I encountered was the keyboard’s stiffness. Our first pass at the keyboard membrane resulted in very stiff domes, which made it difficult to plunge the keys. There were also a handful of issues with the electronics, which is something Megi writes about in a post on his blog. I highly encourage you to read his blog posts.\nFront view of PinePhone with keyboard next to a 3DS for scale\nSide view of PinePhone with keyboard next to a 3DS for scale\nBased on feedback from the first prototypes, the second iteration included fixes to all listed issues and improved on the feature-set. New membranes were created and installed, the chassis was improved, and the electronics circuitry significantly reworked. We now also have the source code from the keyboard vendor and will be working with Megi, Samuel and others to make it flashable. Granted no further issues are found with the electronics in testing, we may be moving to production soon - stay tuned. Last minute edit and a follow-up to the above: Megi received his keyboard just the other day, and has already managed to get open firmware running on it. I spoke to him briefly in the chat yesterday, July 13th, about his initial impressions of the keyboard; he confirmed for me that the enter and space keys are now well stabilised (an issue on the first prototype) and that keys can be plunged with ease. Moreover, the keyboard’s internal battery can now be detected by Linux, and even display battery levels separately to the PinePhones battery. That said, some issues related to electronics still remain - a short somewhere in the electronics causes dual inputs and ghost inputs. There is also some work yet to be done on the feel of the keys, as there is a degree of inconsistency between rows. Megi is currently exploring the root cause of these problems - ghost-inputs in particular.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video PinePhone keyboard running open firmware - by Megi\nOne last thing I want to mention with respect to this topic: early feedback from the community indicated that many people would be interested in incorporating additional functionality into the keyboard. As a result of this, there is now a breakout header on the keyboard’s PCB, which will allow you to add LoRa and Qi wireless charging, and potentially also other peripherals in the future. However, due to the limited internal space inside the chassis, this will require soldering and as such is more of a nod towards hardware hackers rather than an end-user feature. In other words, we\u0026rsquo;re making it easy to add the functionality for those who are up-to-the-task.\nSpeaking of additional functionality, the PinePhone back-cases are coming along but it may take a bit longer than we initially anticipated. We’ve run into some issues, related to current component shortages - the TI wireless charging chip we settled on for the charging back case is currently very difficult to source, and we\u0026rsquo;re not happy with the performance of alternative options. I know that they\u0026rsquo;ve been pushed back already a few times, but we really want for the back cases to turn out great. I am leaving you with a handful of pictures of the current progress. New prototype of back case for LoRa, fingerprint scanner and Wireless charging - electronics missing in picture\nBefore we move onto the software section, I need to shoehorn a short hardware-related notice into this part of the post. A new and improved quick start guide that will ship with future BE PinePhones is now available and has been uploaded online. Credit for the new guide’s layout and illustrations goes to Chris (Funeral). I actually do not know with certainty if PinePhones shipping this month will include this or the older quick start guide version, so if you’re waiting for your PinePhone then please read the one linked above; it is significantly better. Software\nNew release of Plasma Mobile 5.22 [by Brian (33YN2)]\nPlasma Mobile has seen tremendous progress for the current 5.22 release, and there is a lot still yet to come in Plasma 5.23. As outlined by the Plasma Mobile June blog post, a new audio overlay that allows fined tuned control of per-application audio (including the microphone input volume) has landed for next update in October, and there have also been lots of new homescreen improvements such as multiple home screen pages and the groundwork for customizable home screen support. Lots of bug fixes have also landed, with lots more to come in 5.23.\nThere has also been a lot of work that has gone into the growing list of applications for Plasma Mobile. Two new plasma mobile applications have arrived such as the Mastodon client app called Tokodon, and the new podcast app called Kasts. Also notable is that back in march a YouTube music app called AudioTube, and a YouTube app called Plasmatube were also created. Work is also being done on a Plasma Mobile email client, though that is still very early in development.\nVolume \u0026amp; output control on newest Plasma Mobile is amazing - screenshot via KDE\nMMS (mmsd-tng) functionality and development [By Chris (kop316)]\nI want to update you all on the state of Multimedia Messaging Service (MMS) on the Pinephone. If you are in a few countries where MMS is frequently used, a lack of this functionality can be a major show stopper for using the Pinephone as a daily driver. I am the author of mmsd-tng; mmsd-tng is a backend daemon to support MMS in Linux. In its current state, it completely supports MMS and is currently found in Mobian (Unstable), PostmarketOS, and Fedora repositories! Since it is a backend, any chat application can work with it, or it can run in a stand alone mode, though it isn\u0026rsquo;t terribly useful in this mode. The mmsd-tng front ends I am aware of are:\nmms2file, mms2mail ofono-matrix-puppet. As for future work, I have been working towards integrating MMS support into Chatty, to complete MMS support for the Phosh stack. Once MMS support in Chatty is integrated, I will release a 1.0~release of mmsd-tng. Modem Manager’s new release (1.18) should also allow mmsd-tng to completely support MMS on carriers that split their MMS and data APN. If you want to keep up with development (or help out), feel free to join the Matrix Room (#opensourcemms:matrix.org) or the IRC channel (#opensourcemms on OFTC), which is bridged to Matrix.\nIf you have been thinking of contributing to open source development, I highly encourage you to do it! This is my first open source contribution and my previous experience with C is minimal. I can personally attest to the inclusiveness, patience, and professionalism of the Mobian, PostmarketOS, and Purism development teams. At no point was my lack of experience/newness to open source a barrier to my contributions, as all of those development teams are fantastic mentors who want to see me succeed as an open source developer. If you want to contribute, you will find the same welcoming experience as I have.\nPineTime [by JF] Last month, we announced the availability of a new batch of PineTimes in the Store in June, but\u0026hellip; that component shortage struck again! The production is currently stopped due to the vendor being unable to provide a part needed for the PineTime - more specifically, the acceleration sensor. This sensor enables features like step counting and wake on wrist rotation, for example. The factory couldn\u0026rsquo;t find another source for this component and provided us with an alternative option - replace the BMA421 with the BMA425! Although the new component is very similar to the old one, we now need to ensure that InfiniTime is working properly with the replacement, and provide an update to support it if needed. This will unfortunately take a bit of time, but 2 units equipped with this new component have already been shipped to me and should have arrived by the time you read these lines.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Ezra (Elatronion) took a close look at the PineTime earlier this month, check out his video.\nOn the development side, a lot of work is happening behind the scenes, with many refactorings, bug fixes and optimizations, mainly related to RAM and flash memory usage. We are also working towards leveraging the external flash memory, which, with its huge size of 4MB, will allow us to store many more pictures, fonts and icons while leaving enough room to add a lot more features to the firmware down the line!\nAs the project grows, many new contributors have also joined the party - to this date, 58 contributors are working on the project. And, while I was busy debugging a nasty stack corruption issue, these contributors continued their work and created pull-requests with many interesting features: a new watchface, a metronome app, a weather app, UI improvements, and many bug fixes. InfiniTime v1.2, which we plan to release Soon(TM), is looking really good! Keep an eye out for when it drops. PineDio We are striving to bring our indoor and outdoor PineDio LoRa gateways, as well as the various end-nodes, to the Pine Store as soon as possible. I’ve devoted a lengthy section to all the PineDio gear in the works in last month’s update, so make sure to read that first in case you missed it. We initially hoped to make the hardware available this month, however it may take a little longer for us to bring the devices to the market. Let me give you a complete run-down of why it will take us a bit longer (if you’re not interested in the details, skip to the third paragraph). Just as we were preparing to submit the gateway for certification we learnt that the Realtek Gigabit PHY used on the PINE A64-LTS - that is the brains of the PineDio gateway - can no longer be sourced (if you’re unaware of ongoing global component shortages, please read the February and March updates housekeeping sections). As a result of this, we had to introduce a new revision of the PINE A64-LTS (v2.0) with the same PHY used on Quartz64 model-A. This was not the only problem we found; the gateway also uses the BL602 WiFi/BLE chipset, for which we still need a working driver in Linux.\nBecause of these issues we were unable to submit the gateway for certification, but we hope to do so in the coming weeks. Meanwhile we’ve been working on our outdoor gateway. Given how the outdoor gateway chassis are made of aluminium, all the antenna signals - not only for LoRa but also WiFi and BLE - need to be routed to the outside. While it may seem a trivial task, it is not; antenna placement, I’m told, is crucial on these kinds of devices. We are working closely with an antenna vendor to offer an optimal layout within the constraints of the chassis, and I am looking forward to showing it off soon in its final configuration. A peak inside the PineDio gateway chassis - color wires attached to 3x18650 battery holder\n3x 18650 pack (under green bracket) and PoE location (black rectangular box) on the underside\nLastly, a decision was made to include a 3X 18650 battery holder, placed on the underside of the mainboard, and separated by a metal plate (part of the chassis construction) from the PINE A64-LTS and the LoRa RAK module. Three 18650 batteries will allow the gateway to operate for hours if direct supply of electricity is cut off from the unit. Speaking of power delivery, on the underside you will also find a power over ethernet (PoE) adapter, which I am sure many people will appreciate given the convenience of only running one cable outdoors. The outdoor gateway is shaping up to be a very robust and feature-rich unit. I will have more news and announcements concerning PineDio in the coming month, so stay tuned and make sure to subscribe to this blog. Pinecil It has been a couple of months since we had a section dedicated to the Pinecil in the community update. I now finally have great news to share, which warrants allocating some real estate to the Pinecil. Hackers and tinkerers rejoice - the Pinecil hammerhead set is now available for purchase in the Pine Store. For those who do not know, the hammerhead accessory provides a large surface area for desoldering surface mounted components. The set contains a special threaded tip allowing for securely mounting either a large (20mm x 15mm x 20mm) or small (15mm x 15mm x 15mm) hammerhead. The hammerheads are made out of chromium coater pure blocks of copper, and have excellent thermal conductivity. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Hammerhead in action resting on thermal mat included in the kit\nThe purpose of the hammerhead is to provide a sizable area for easily removing surface mounted components - it is effectively a heating surface that may be used in conjunction with or instead of a hot air gun. The set also includes a thermally resistant mat rated at 500*C, which the hammerheads can be safely placed upon. I honestly feel like this is a great set for anyone who occasionally needs to remove more than a single component from a PCB and doesn’t have a hot air gun on hand. The set is available for $24.99 and if you’re interested I suggest you pick one straight away - most Pinecil accessories tend to sell out quickly. I am leaving you with two videos of the Pinecil equipped with the hammerhead tip in action above.\nContents of the Hammerhead kit\nThat is all for this month’s update, go forth and comment!\n","permalink":"/2021/06/15/june-update-new-hardware-and-more-on-the-way/","tags":["lora","pinecil","pinephone","quartz64"],"title":"June update: new hardware and more on the way"},{"categories":null,"contents":" Download audio\nIn the first 2-digit episode of PineTalk, Ezra and Peter are happy to interview Martijn Braam, whom you may know of his involvement with postmarketOS, the many apps he develops or his videos and blog posts.\nThey also present some homework and discuss community feedback and questions.\nSpecial Intro See credits at the bottom of this post.\nWhat have we been up to lately? Ezra: I’ve been working a lot on my point and click adventure game. I also have been taking some time to learn how to draw. More relevantly, I played a whole bunch with my PineCube! Check out what Ezra does on Elatronion.com, Odysee and YouTube! Peter: Wrote that Modem Firmware install guide as promised, that mainly deals with avoiding Minicom, Moved his weekly updates to Wednesday for personal reasons, made a video about GloDroid. It’s mainly a little tutorial explaining how to do it. But let’s get to it now and start with the\nApp of the Episode Web Archives Flathub Interview with Martijn Braam Links about the things we talked about, in order of appearance:\nGetting started with Linux\nKnoppix Getting involved with postmarketOS Oliver Smith’s blog: postmarketOS: Aiming for a 10 year life-cycle for smartphones postmarketOS blog: 100 days of postmarketOS Getting started with the PinePhone PINE64 docs: Project Anakin PINE64 docs: PinePhone v1.0 - Dev Martijn Braam: Putting together the PinePhone prototype App Development Martijn’s apps How to help with postmarketOS development? PinePhone issues on the postmarketOS issue tracker postmarketOS Porting Guide Upcoming PinePhone keyboard Wikipedia: I²C Martijn Braam: First look at the PinePhone Keyboard dev unit Thank’s again to Martijn for coming on!\nFollow Martijn’s work on:\nYouTube LBRY/Odysee Blog sourcehut and the postmarketOS podcast! Community News PINE64: FemtoStar: taking aim for the stars Megi’s blog: PinePHone kernel news Community engagement 😀 Homework on PineCube (Ezra) Things Ezra did:\nInstalling Armbian without a screen (sounds more impressive than it is) I simply downloaded the PineCube Armbian image. Flashed the image to an SD card. Plugged in the PineCube to power and ethernet and shabamalama! I was 99% done. An SSH server is installed by default on the image, so I simply had to find my PineCube’s IP, which I did using the following command nmap -sP 192.168.1.0/24 And logged in using the default values of: user: root pass: 1234 Install media-ctl \u0026amp;\u0026amp; ffmpeg media-ctl is a part of v4l-utils and is useful for configuring the camera. ffmpeg is… well, ffmpeg, must I really explain? It’s what I use to take the video feed of the camera and stream it via RTMP to a RTMP server, which I setup next.\nRTMP server I followed a tutorial to help me setup NGINX for RTMP streaming. It was simple enough once I wrapped my head around it. I never used NGINX or RTMP before, so it was quite the fun new experience. 🙂 Personal livestream of me cooking to my friends After getting everything setup, I though I’d actually have some fun with it, so I streamed myself making supper to my friends! 😛 The camera seems much better than that of the PinePhone, the reason for this is lens. I have a few projects in mind, I’ll definitly make a video about the PineCube. And, ofc, talk about it on the PineTalk when I get around to it. Automation using TensorFlow Lite for object recognition. (saving the past few minutes and few future minutes locally on the device) or something like that. Peter had the idea of doing a livestream on YT or some other video platform using the PineCube as a camera, could be fun for any Pine related livestream I may do in the future. Homework regarding FM radio (Peter) Last episode, we could not give a good answer to the question Deon Denis asked on Youtube: How about a FM radio back cover? So:\nHow do other devices implement this? Headset serves as antenna Sometimes implemented within the SoC (e.g. MediaTek MT6753) Sometimes within the Wifi/BT chip (e.g. Samsung Galaxy SII) Do we have support for FM radio? the Realtek RTL 8723CS chip used for WiFi and Bluetooth in the PinePhone alledgedly supports receiving FM radio according to its announcement, but it’s nowhere to be found on the spec sheet. but: We don’t have a driver that would support this, and we don’t have the hardware for it. Would the Pogopin i2c (i-squared-c bus (inter-integrated-circuit interface) offer enough bandwith for fm-radio on the PinePhone? bandwith is rather limited, but actual \u0026ldquo;hard numbers\u0026rdquo; information seems to be scarce it’s definitely enough for keyboards 😉 (see here, or thermal cameras) back to topic: There’s a tutorial for building an i2c fmradio accessory on circuitbread.com, but with this you would still have to figure out the audio side. Thankfully, there are more also ready made products that have a headphone jack, e.g the Grove - I2C FM Receiver → Looks like it is actually possible to do this! Alternatives: PinePhone RTL SDR connected to USB clunky (many cables) likely requires external power source, but: software exists, see e.g. rtl_fm_player also, easy: (Bluetooth) Headphones with FM Radio are a thing Listener Feedback @DarkeyVilkulak on Odysee wrote: PinePhone\u0026quot;LoRA is not for sending images. Kids these days are really spoiled ;D What about simple text communication and long range mesh for simple communication. It can use some kind of low bandwidth encryption. There are several projects like Meshtastic about that.\u0026quot;\nListener Questions Sebastian asked via email combability of the frameworks/distros PinePhonePinePhoneIs there a way (or some projects that try) to run apps, that where written with one desktops framework, to run those on another desktop? Like running Lomiri apps on kde-mobile?\nPinePhone Manjaro Lomiri Dev Packages Quickddit, AUR Dylan van Assche’s Convergence Components somewhat relevant LINMOB.net post about running Plasma Mobile apps on Phosh Additionally, when I see things right, quite some apps aren’t packaged for every (major) PinePhone distro (even though they use the same framework). So it would be even great, to use AUR on mobian (also it sounds somewhat strange). I just mean, it would be great, when software for a specific need, wouldn’t have to be written over and over again.\nDifferent starting points Where are good starting points (and where to find them) that would help different parts of the ecosystem?\nThere is a lot file bug reports (or help triangulating those) help with documentation help with metadata/other little things: If there’s a project you like a lot, but it does not have a desktop file or icon, maybe help with that. Or contribute AppStream Metadata via pull request. Pick what you think is up your alley, the worst thing that can happen is that your pull or merge request is being declined. helping other users: Forums, chat, … like Martijn said in our interview: Pick something (maybe there’s a rather simple app that you lack) and get started with that. Pick a framework, pick a language, and dive in. Eventually, you might come up with something, and even if it’s objectively not very good, you will have learned something, and if you keep going, you might eventually get decent at it. Feedback and Questions welcome! Remember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nCredits: Intro and Outro Music Music by Bradley (PixelPaintbrush) Ames\nThank you to NerdZoom Media for being PineTalk’s audio producers!\nSpecial Intro credits Script \u0026amp; Editing: Ezra\nCast\nEzra as himself Peter as Faang and his minion. Audio Atmosphere Calm Forest Birds BurghRecords - Sonny Fascia\nMusic Aquarium by Kevin MacLeod, License Leaving Home by Kevin MacLeod, License Waltz of Treachery by Kevin MacLeod, License\n","permalink":"/podcast/s01e10/","tags":null,"title":"S01E10: Man of Many Apps"},{"categories":["community","news"],"contents":"\nKDE is a project near and dear to our hearts. The original Pinebook, which forged the path for our current hardware lineup, was the first PINE64 device to ship with KDE Plasma Desktop. This was in early 2017. Fast forward to today, both the PinePhone and Pinebook Pro - our current flagship devices - ship with their respective Plasma user interfaces atop of the Manjaro operating system. As many of you surely also remember, earlier this year a dedicated KDE community edition of the PinePhone was sold with the intention to boost development of the Plasma Mobile user interface on the PinePhone.\nSuffice it to say, we have a long-standing and close relationship with KDE. Therefore it gives me great pleasure to announce that PINE64 has been made a patron by KDE e.V. I would like to take this opportunity to thank KDE e.V. and all the developers I’ve had the pleasure to work with over the years as well as KDE community members, who have been very supportive of what we do. This most recent development in our mutual journey will surely result in closer cooperation and a tighter integration of KDE’s technology on our hardware platforms. Many good things will come from this - stay tuned. Read the full announcement on KDE’s website.\n","permalink":"/2021/06/02/we-are-kde-patrons/","tags":["community","kde"],"title":"We are KDE patrons"},{"categories":null,"contents":" Download audio\nIn this episode nine Peter and Ezra discuss two conferences that happened recently, the May PINE64 Community Update and some more community news. They also answer four community questions and ask kindly for more!\nWhat have we been up to lately? Ezra is still working on his point and click adventure game and attended the Linux App Summit. Check out what Ezra does on Elatronion.com, Odysee and YouTube! Peter was quite busy with family matters, and only managed to write LinBits 45: Weekly Linux Phone news / media roundup (week 19), LINMOBapps: Additions in March and April 2021 and future plans. App of the Episode Agregore Browser by Ranger Mauve GitHub Dat Conference talk Topics: Linux App Summit Linux App Summit\nThank you to NerdZoom Media for being our audio producers! Full schedule YouTube channel Panel discussion: Building International Software Communities by Aniqa Khokhar et al. Video recording Forcing Hardware Vendors to care about Linux since 2015 by Richard Hughes Slides Video recording Adaptive Apps: The Future Is Now by Tobias Bernard Slides Video recording Funding Krita by Halla Rempt Slides Video recording AlpineConf 2021 AlpineConf 2021\nRecordings:\nAlpineConf - Oliver Smith - pmbootstrap: the Swiss Army knife of postmarketOS development AlpineConf - Martijn Braam - Showing off postmarketOS Sxmo: Simple X Mobile - A minimalist environment for Linux smartphones Big Blue Button room recordings We have links to the video recordings, the Big Blue Button room recordings (which contain the Q\u0026amp;As) and the conference itself in the shownotes.\nPINE64 Community Update May PINE64 Community Update May: Connection established\nVideo by PizzaLovingNerd: Tilvids YouTube Odysee PineTime Siglo 0.8.0 was released shortly before our recording, so some of these pull requests have been merged and released, yay! PinePhone See also: In Linux Smartphones we trust Martijn Braam: First look at the PinePhone Keyboard dev unit PineBook Pro Fedora Pinebook Pro: production placed on halt due to component shortages; will keep you updated. If you want a Pinebook Pro, now is the time to pick one up. LoraWAN PINE64 Pinedio Partnership with RAK Wireless: Let’s make MiRAKles happen Our Opinions On LoRaWAN Custom Firmware tryout progress? Minicom instructions at bloggerbust.ca Release page of Biktorgj’s project Megi’s website on Unlocking ADB access Peter wanted to do a good job and thus did not finish is blog post on the topic yet, but it should be on linmob.net before the next episode lands Community engagement 😀 Listener Questions Blort asked on Tilvids When are we going to hear/see more about the PineCube?\nSadly no, but Ezra commits to reporting about his successes and failures in the next episode!\nRice Cake asked on YouTube Have you guys thought about verified boot camp n pinephone? 🙂\nContent to read on the topic: Protecting Linux devices with verified boot, from ROM to Userspace.\nIf you have experimented with this on the PinePhone, please get in touch!\niNTRa asked on YouTube Do either of you have your own channels that you post on?\nEzra writes on Elatronion.com, and publishes videos on Odysee or YouTube.\nPeter writes on linmob.net and publishes Video Odysee, Peertube and YouTube.\nDeon Denis asked on Youtube How about a FM radio back cover?\nApologies for saying I-two-C, it’s I-square-C. We don’t really know beyond this: RTP’s SDR Experiments\nAgain: If you know more about this, please tell us about it!\nFeedback and Questions welcome! Remember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nThank you to NerdZoom Media for being our audio producers!\n","permalink":"/podcast/s01e09/","tags":null,"title":"S01E09: Eventful Number 9"},{"categories":["community"],"contents":"\nNetworking and communication is something that has been on our minds as of late. As many of you are surely aware, we have started developing our own solution to private and secure peer-to-peer and group text messaging based on the PineDio gateway system, available next month. While we have high hopes for this system, we are also aware of its limitations. Voice communication and higher-than LoRa® data speeds is something we all rely on in our daily lives, and nothing will change this. If there was only a way to network via a secure and open source friendly manner - enter FemtoStar.\nFemtoStar is a mobile satellite service working towards creating a satellite constellation for open and private communications around the globe. Their satellites as well as ground infrastructure run open source software atop of open hardware. The system can be accessed without needing to go through an official gateway, and anyone is welcome to review the source files as well as the code. FemtoStar\u0026rsquo;s vision is one of a privacy-respecting and net-neutral mobile satellite service that can be accessed by anyone, anywhere and at any time. Moreover, users\u0026rsquo; hardware can be used to access the satellite network without prior consent from FemtoStar. All hardware can be used both to connect directly to satellites and to operate on-the-ground services. As for payments: \u0026lsquo;credit processing takes place on-satellite, and works even when no official ground station is available\u0026rsquo;.\nWe have now been talking to the people behind the FemtoStar project for some time, and we\u0026rsquo;ve been both impressed and captivated by their vision. Their idea of a low-cost and decentralized network allowing anonymous, geolocation-resistant communications is something we believe that our community can get behind. To anyone reading this, it is probably clear that we and FemtoStar have many convergent goals. A PineDio gateway can service the neighbourhood with text messaging, while a FemtoStar gateway can service an entire continent with data speeds fast enough to make phone calls or browse the web. In the weeks and months to come we will share more information concerning our mutual engagement, but in the meantime make sure to join their Matrix channel and give their FAQ a thorough read for more insights.\n\u0026ldquo;The FemtoStar Project is excited to see PINE64 join our efforts to develop the world\u0026rsquo;s first private, truly open-infrastructure, 100-percent-free-and-open-source wide-area communications network. We expect PINE64\u0026rsquo;s experience with manufacturing and distribution of affordable, mass-market hardware to play a key role in making FemtoStar usable to the largest number of people possible, and look forward to integrating PINE64\u0026rsquo;s terrestrial LoRa network with FemtoStar\u0026rsquo;s satellite constellation.\u0026rdquo;\n~ The FemtoStar Project\n","permalink":"/2021/05/19/femtostar-taking-aim-for-the-stars/","tags":null,"title":"FemtoStar: taking aim for the stars"},{"categories":["community","lora","news","pinebook-pro","pinephone","pinetime","quartz64","soedge"],"contents":"\nLet me start by welcoming the newcomers! If you are a new Pinebook Pro or PinePhone BE owner, make sure to pop by the chat or the forum and say hello to the community. A quick note before we get into it: we have narrowed the width of the blogpost pages, thereby hopefully making entries easier to read. This caused some issues on mobile Firefox and Opera browsers. We believe the issue is now fixed, but if you run into any problems or oddities please make sure to let us know in the comments section. Thanks. You can watch the synopsis of this month’s community update on YouTube (embedded below) as well as on Odysee and Peertube. Stay up-to-date with PINE64 news and 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.\nI’d like to thank JF, Alex (clover), Peter (pgwipeout), Biktor, Martijn and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video TL;DR\nHousekeeping: shipping ongoing + ideas for shipping updates on the website Housekeeping: SOEdge AI module available in the Pine Store \u0026amp; Pinecil hammerhead tip coming soon Housekeeping: cluster hosting our services will be moved to a permanent server rack in near future; will affect chats in and forums. Housekeeping: people behind FOSS2go are building PineGuild PineTime: big interest in PineTime following 1.0 launch blog post; thrilled about the reception inside and outside community PineTime: more PineTimes available in June, will feature InfiniTime 1.0 PineTime: many pull requests waiting to be merged; new version of Siglo and improvements to Pinetime support in Gadgetbridge PinePhone: rolling production started - you can order the PinePhone any day or any month this year. PinePhone: a close look at PinePhone keyboard internal review units; minor tweaks needed but it will be available this summer PinePhone: wireless charging and LoRa back cases available in June PinePhone: Megapixels 1.0 released with many improvements, including accelerated viewfinder and horizontal mode PinePhone: ongoing work on modem update and work on VoLTE progress and findings PineDio: PineDio official name of our LoRa project; expected to launch PineDio next month inc. getaways and end-nodes PineDio: working in partnership with RAKwireless on the project, and the novel text messaging peer-to-peer \u0026amp; group application PineDio: report from RTP and JF on gateway status - fully functional Quartz64: new hardware revisions with developers; unless something unforeseen happens, available to developers in Pine Store in June Quartz64: much software progress! Pinebook Pro: many new faces in the community - welcome! Pinebook Pro: Fedora 34 and Manjaro with GNOME available for the PBP Pinebook Pro: production placed on halt due to component shortages; will keep you updated. If you want a Pinebook Pro, now is the time to pick one up. Housekeeping Shipping of Pinebook Pros and PinePhones has gone pretty smoothly and without any major hiccups. That said, PinePhone shipments destined for EU countries have seen a minor delay due to a DHL paperwork mishap, and I know that some of you are still waiting for your devices as a result of this. Everything has now been sorted out, so if you’re in the EU, and you ordered prior to April 15th, then you should be getting your PinePhone BE shortly. As always, I encourage you to follow the shipping update thread on the forum for the latest information about PinePhone BE and Pinebook Pro shipping status. Speaking of shipping updates: I am considering setting up a dedicated shipping update section on this website. For all intents and purposes it would function the same way as the forum shipping thread. I think it would look neater and the information would be more transparent to end-users, given that there is only so much one can do to edit a forum post nicely. What do you think - am I overthinking it or is this a good idea? Let me know in the comments section. The second thing I wanted to touch on is the ongoing global component shortage situation. As you might already know, manufacturing devices has been very difficult in recent months due to a lack of readily available silicon, long lead times and massive price-hikes. We will continue with the strategy I outlined in March, and only sell inventory either already delivered from the factory or guaranteed to be manufactured. In short, you’ll see SBCs and devices drift in and out of stock on a fairly regular basis. As always, I’ll do my best to keep you up-to-date on device availability on social media and in the news channels. In other news, the SOEdge is finally available for purchase! The SOEdge is our AI module based on the RK1808: it features a 3.0TOPS NPU, 4GB DDR4 RAM and two cortex-A35 cores. The pin-out is compatible with the SOPine, so you can also use the SOEdge with the clusterboard. Seeing as I currently do not have any news concerning software development, nor any additional hardware information to share, I am including the launch notification in this housekeeping section. To learn more about the SOEdge and its current software status (which is pretty solid thanks to gamiee’s work) please check out the March community update. For more information and other resources on the AI module, please make sure to check out the SOEdge documentation pages.\nSOEdge and baseboard in the Pine Store\nOn a similar note, the hammerhead tip for the Pinecil has now been delivered from the factory, and will be seeing a release on the Pine Store in the coming weeks. Keep an eye out for an announcement when it becomes available. You can learn more about the hammerhead tip reading the last month’s update.\nHammerheads delivered from factory\nI also have a notice to share regarding the PINE64 cluster hosting all our services. After nearly a year in temporary storage at BBXNET, the cluster is finally being moved to a permanent server rack where it will live out the rest of its days. This means that we will have to take it offline for a short amount of time. A temporary server, consisting of a small cluster of ROCKPro64 boards, will be used for the duration of the move. While static services such as this website or the Wiki are unlikely to be affected, I suspect that the move will cause a disturbance in the chats (the bridge will go down - and we likely won’t fix it until the move is completed), and we may also resort to temporarily locking the forum to prevent data loss. There currently is no set date for the move, but it could be as early as next month. A heads-up notification will be issued beforehand on Twitter, Mastodon, the Website, etc. I know people like this sort of stuff, so I’ll ask BBXNET folks to take some pictures for us. Lastly, I want to give a shoutout to a new website dedicated to PINE64 devices and our community - pineguild.com. The website is brought to you by the people behind FOSS2go with the intention to serve as a news and resource outlet for our community. I know that they are also actively seeking contributors, so if you’re eager to do some writing about your PINE64 device then now you’ve got yet another outlet. I like and appreciate initiatives like this, and I really hope to see this portal take off. Go subscribe to their newsletter to show them it is worth their effort. PineTime [by JF] At the end of April, we announced the release of InfiniTime 1.0 together with the disponibility of PineTime smartwatches as \u0026ldquo;enthusiast grade end user product\u0026rdquo; on the Pine64 Store. This is great news for the developers of the projects, who can be proud of the accomplished work, but also for the users who will soon be able to buy a PineTime ready to use (single sealed unit). Advanced users and developers can also buy a pack of a sealed device and a development kit!\nI cannot express how happy I am regarding the success of this announcement, which exceeded all my expectations. The article was shared, linked, tweeted and tooted all over the internet, and many popular sites covered the announcement. As a result, a lot of people joined the community chat rooms to ask questions, gave feedback and thanked us for the good work.\nTo give you an idea of the success of this announcement, here are some stats about it:\nMore than 38000 people read the article on the blog. This is the 2nd most popular article on the site. The influx of visitors put a strain on the cluster, but it handled it like a charm! More than 300 new users joined our Discord server the day of the announcement. The traffic on the Github repo of InfiniTime also quadrupled following the announcement. Thousands of units were sold in the next few hours following the publication of the article, and the PineTime sold-out in the next few days! These numbers show how much people were waiting for this release and how popular this project has become since late 2019. Thanks again to everyone who contributed to this success.\nOh and I have good news to share with everyone: a new batch of PineTime will be produced later this month, and I\u0026rsquo;ve provided the production team with new binaries so that those new units will be directly flashed with up-to-date bootloader and InifiTime versions. Finally, if you want to have an overview of what\u0026rsquo;s available in InifiniTime 1.0, I recommend you have a look at this video review by PizzaLovingNerd.\nThis new release didn\u0026rsquo;t stop the developers from working on the PineTime, in fact quite the opposite. There are already a lot of pending pull-requests that are awaiting review before they are merged into the next releases. These include new and improved features, such as a new step application, new watchfaces, new wakeup features and much more. We are also working on improving the memory usage to make it easier to add new applications and watchfaces in the future.\nDevelopers are also enjoying designing new watchfaces like this Casio inspired watchface and this 100% customized watchface by @SravanSenthiln1 (do you recognize the avatar of @PizzaLovingNerd, who produces the video versions of Pine64 community updates ?).\nCasio inspired watchface by @SravanSenthiln1\nOn the companion app side, Gadgetbridge released version 0.56.2, with many improvements regarding the support of PineTime. This version improves the notifications by sending a title (name of the application that sends the notification, name of the sender of an email,etc.) along with the message, which makes the notifications much more readable on the PineTime. The functionality \u0026ldquo;find my device\u0026rdquo; was also added, which is useful if you cannot find your PineTime while it\u0026rsquo;s in range of your phone. Finally, this upgrade displays the battery level in the UI and in the notification area of your smartphone.\nGadgetbridge now shows PineTime\u0026rsquo;s battery and includes new features\nAlex also released Siglo version 0.7, the GTK companion app running on the PinePhone and other Linux devices. This new version can now run in the background and send SMS notifications to the PineTime. It also brings many other bug fixes and improvements.\nWe talked a lot about software, but not much about hardware. This month, I would like to highlight a hardware hack by @alvarolsamudio, who managed to add wireless charging functionality to the PineTime - pretty cool!\nPineTime wireless charginig hack by Alvaro Samudio\nPinePhone: Hardware I have some good news to share. For starters, the Pine Store worked really hard to secure PinePhone production this year. All crucial components that make up the smartphone have been sourced, and a portfolio of discrete replacement parts has been built up and secured in the event of an emergency. This will not only get us through this difficult year but also permit a continued rolling production of the smartphone. What this means in practice is that you will be able to pre-order a PinePhone any day of any month in 2021. The PinePhone will, however, keep on shipping in batches due to the continued closure of the Hong Kong border with mainland China. I also presently don’t know if the time between shipments will be reduced by the rolling production or not. At any rate, the production of the next batch has already been scheduled and will likely start sometime early-next month. That said, it is obviously possible for unforeseen obstacles to cause manufacturing difficulties down the line (nothing would surprise me given current circumstances) in which case, you can count on me to let you know. In other good news, the PinePhone keyboard internal review units have been assembled and shipped out to a select lucky few, including myself. Late last month I shared a handful of pictures alongside a video of an engineering prototype, which lacked some of the polish seen on the review units. As you can see from the pictures below, the keyboard has now taken on its final form. The laser etched keycaps look great in my opinion and I\u0026rsquo;m told that the texture of the chassis has been matched to the PinePhone’s back case. As you can probably tell from the pictures, the fit and finish of the keyboard has really been tightened up and is looking great.\nInternal review unit PinePhone keyboard\nHowever, it isn\u0026rsquo;t quite perfect just yet. The production team informed me that the keyboard’s membrane will have to be redone, although they didn’t specify why. I suppose I’ll find out soon enough (at the time of writing I haven’t received my unit yet). Regarding availability - at this point it largely depends on three factors: 1) how quickly can the i2c HID driver be made to work on the PinePhone; 2) how fast will new good membranes be created, and; 3) how soon can the mandatory torture testing be completed. Rest assured, we want the keyboard available in the Pine Store as much as you do. In the meantime, keep a lookout for updates - more info will be coming soon, once review units land. Left: redesigned wireless charging PCB + coil // Right: LoRa PCB Lastly I have - and you guessed it - more good news. We are planning to start selling the wireless charging and LoRa back cases for the PinePhone next month. The fingerprint reader case will arrive somewhat later, since we’re still working out sensor firmware quirks with the vendor. The wireless charging PCB has been redesigned since you’ve seen it last and the LoRa PCBA has now been delivered. I am attaching pictures of both PCBAs for you to check out. While the wireless charging case will ‘just work’ with any PinePhone right out of the box, since it is a ‘dumb’ periperial, the LoRa case will be marketed strictly at developers. We will make it clear on the Pine Store that the LoRa implementation will require extensive input from developers. Hopefully we’ll get it functional in record time. PinePhone: Software [Martijn \u0026amp; Biktor] Megapixels 1.0 [Martijn]\nMegapixels 1.0 has been released. This version of Megapixels switches from GTK3 to GTK4, this is not for the sake of adding newer dependencies, but because this allows having working GPU acceleration in the camera preview. With the toolkit change also comes some UI changes that are now possible because we can now draw GTK widgets over the preview.\nThis means the custom rendered shutter/exposure settings are now replaced by dropdowns and the preview image now extends below the bottom row containing the camera controls. The blue tint bug has also been located and a workaround has been implemented making the camera usable without switching between the front and rear camera first.\nThe image post-processing pipeline itself hasn\u0026rsquo;t been changed in this release, but due to a smoother preview it\u0026rsquo;s now a lot easier to take sharp pictures with the PinePhone.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video showcasing the accelerated viewfinder in Megapixels 1.0\nVoLTE support [Biktor]\nLast month I started testing VoLTE HD support in the modem. Both the Pinephone and the modem support HD audio over VoLTE, and the modem can be run at 8KHz or 16KHz sampling rates for better quality audio. There\u0026rsquo;s two slight problems though, which are:\nWhatever sampling rate you use on the modem must be matched in the Pinephone\u0026rsquo;s audio subsystem, so if you set at 8K and you\u0026rsquo;re in a call, any other audio stream will have to match that sample rate, reducing sound quality. The modem doesn\u0026rsquo;t support changing the sample rate at runtime, so it is not possible to dynamically set it. Turns out 2 is a lie, the modem can actually change its settings at runtime, even during a call, the problem is stock firmware wasn\u0026rsquo;t really designed with that in mind and requires a reboot to use the new settings. Even more, the modem is capable of going up to 48K sampling rate, it\u0026rsquo;s only limited by the closed source binaries and the stock kernel. Right now, with the custom modem firmware, you can select your desired sampling rate to 8/16/48K, by issuing a simple AT command, and it\u0026rsquo;s applied at runtime.\nThat was the easy part. Now I\u0026rsquo;m looking for the best possible approach to get the Pinephone side of thing to be able to work in 8K for everyone using the stock firmware, but be able to switch it to 48K if supported by the modem firmware to get better audio quality.\nPineDio I cannot recall who suggested PineDio (get it, Pine + radio?) to us as a name for our LoRa project, but I’d like to thank whomever it was for the suggestion as it ended up being what we settled on. The PineDio is now officially the name we gave the entire PINE64 LoRA ecosystem of gateways and end-nodes. Today I am happy to announce that we\u0026rsquo;ll be fast forwarding the project with an estimated release date of late June. We will simultaneously release the PineDio indoor and outdoor gateways alongside a USB and SPI end-node, as well as the PinePhone LoRa back case. Once we have all devices built and delivered from the factory I’ll write-up an announcement post that will include pricing. If you’re interested in this project, then I strongly encourage you to sign up to our blog, follow updates on the relevant news channels as well as on our social media accounts. PineDio outdoor gateway inside\nEarlier this month we announced that we will be cooperating with RAKwireless on the PineDio. RAKwireless is an industry leading IoT solutions provider, producing high-end LoRa® gateways, sensors, kits and modules. Both our indoor and outdoor gateways, which are at the very heart of the system, will be using RAKwireless technology. We’re thrilled that we’re going to have an opportunity to work with RAKwireless and their community on this project. In both the cooperation announcement and in last month’s community update I’ve already outlined at length the goals which we will strive to achieve with the PineDio ecosystem. In summary, we are interested in traditional IoT applications as well as a novel implementation of LoRa for peer-to-peer and group text messaging. We have high hopes for bringing an alternative messaging system to all our devices. Sending and receiving messages from PineDio gateway - by JF\nDevelopers who have been working on gateway prototypes have already gotten quite far with their endeavours. JF informed me that, indeed, the gateway is already fully operational and both the RAKwireless LoRa module and GPS are already working well after some modifications to RAKwireless software. Both JF and RTP have managed to connect their gateways to The Things Network and Chirpstack, running locally on the gateways. JF also informed that he has already been able to receive messages from a LoRaWAN device on the PineDio. I also spoke to RTP about his work on the gateway. He informed me that sending beacons from the PineDio gateway works well, that the concentrator starts without any errors, and that GPS works accurately for him. As such, it would appear that the gateway code is good to go, and most of the work required at this point will concentrate around the end-nodes. We expect that the USB end-node will be made to work swiftly, in part since we’ll have a third party help out with the process. The SPI end-node and the PinePhone back case (using i2c) will, however, require input from the development community. Once all end-nodes work with PINE64 SBCs and devices we’ll start exploring LoRa’s potential for peer-to-peer and group messaging. But one thing at a time. Quartz64: Hardware Earlier this month we shipped V2 of the Quartz64 model A and B to developers. The new board revisions feature a number of minor hardware fixes as well as a new Gigabit Ethernet PHY; the Realtek PHY chips we use on all PINE64 Single Board Computers (SBCs) is presently nowhere to be found. I wrote about this at length in last month’s community update if you’re interested in learning more about the situation. As things stand, we are currently awaiting feedback from developers regarding the new board revision - granted no issues are found in the next 2 weeks then the production will finally commence. As you probably can tell by the fast pace of the hardware’s development, we’re very determined to bring the Quartz64 to the market as soon as possible and usher in a new SoC-era for PINE64 gear. Left: Quartz64 v2.0 board // Right: Quartz64 prototype\nWe are currently planning on making Quartz64 available next month. However, given the unpredictability of the manufacturing situation, please consider this a tentative time-frame. Once the production is underway, I’ll publish a dedicated post with additional information and an exact availability date. Quartz64 v2.0 model B and A\nAlthough the hardware will soon see the light of day, the software is still not ready for primetime. Indeed, despite a truly monumental effort from various parties and lightning fast development progress, Quartz64 is still in early stages of development. This is understandable given how young the SoC is and how few Quartz64 (and other RK3566 boards) are currently available to developers. We will therefore target this initial production-run at developers and technically inclined enthusiasts able to help in the bring-up process. The soon-to-be scheduled batch will be large enough to cover all developers interested in picking up a unit (and then some), but end-users will specifically be asked to wait a little longer. After all, it is in everyone’s best interest that these early boards end up in the right hands at this early stage of development.\nQuartz64: Software [By Peter] A significant amount of patches needed for the rk3568/rk3566 have been submitted to mainline, and a few have already been accepted. As things stand, the GPIO, pinctrl, iommu-v2, thermal, rk817-codec, gmac, PCIe, and power-domain patches have been submitted to mainline for the rk3568 chip series. There is also a basic rk3568 device tree in review.\nThe pace and activity levels are really high\nWe now have the V2 board in hand and have begun validating it. We have the new gmac PHY used on the v2 enabled on the new Quartz64 boards. Another piece of good news is that the SATA controller has been validated and works extremely well. The PCIe controller is in good shape, every card we have tested (except GPUs) works out of the box. We have started trying to spin up the Mali GPU using Panfrost open source driver, but the new VOP-v2 driver needs porting over. The new I2S driver will need to be ported as well to enable sound output. We are still waiting on ATF sources and the official errata for the GICv3. Work has started on mainline u-boot but depends on the ATF sources to work properly.\nPinebook Pro Many Pinebook Pro units have reached their rightful owners in the past 30 days. Just as with past production-runs, the Pinebook Pro was once again met with a lot of positivity and praise, which was great to witness. I am also happy to see so many new faces in the Pinebook Pro sub-segment of our community - welcome! At the same time, I’d like to thank the veterans among you who have been actively helping out, offering suggestions and pointing new users to resources. Great job. This is a really good time for Pinebook Pro owners. The past two months have seen a lot of development and new additions to the platform’s software portfolio. I wish to highlight two new arrivals in the Pinebook Pro’s software lineup: Fedora 34 and Manjaro GNOME. Peter Robinson, the Principal Architect for Red Hat, wrote up a complete and comprehensive guide for getting Fedora 34 workstation up and running on the laptop. Following the instructions will land you a mainline Fedora build featuring accelerated graphics on the GNOME desktop. Peter also links to an interim WiFi/BT driver in his notes, as Pinebook Pro’s WiFi/BT module hasn’t been upstreamed yet. I know many of you have waited for a simple way to run the newest Fedora on your Pinebook Pro, so make sure to let Peter know you appreciate his work on this.\nFedora 34 on the Pinebook Pro via Peter Robinson\u0026rsquo;s Twitter\nThose of you who prefer GNOME over KDE can rejoice as now you have both an Armbian Focal and a Manjaro 21.04 ready-to-go OS image featuring your favorite desktop environment (I wrote about Armbian with GNOME last month, if you want to check it out). Manjaro 21.04 with the GNOME desktop features full functionality, including working GPU acceleration in the desktop, and a custom U-boot allowing other OSes to boot from SD when Manjaro is installed to internal eMMC flash. I gave the latest release a spin just the other day, and I must say that I am very impressed by the performance - it is really snappy. Now I have some bad news. Pinebook Pro production will be placed temporarily on halt. The current component shortages make it very difficult to source the necessary parts to continue with the manufacture. The production team has done a lot of research in an effort to pump out another batch in late Q2 or early Q3, but ultimately chose against proceeding. In short, even if we resorted to work-arounds and use alternative parts and electronics, the end-result would be one of many compromises, which simply wouldn’t be fair to our community. On top of this we would have to significantly increase the asking price for the Pinebook Pro. I know that this is disappointing news but ultimately it is also the right call.\nIf you are on a fence whether you want to pick up a Pinebook Pro, then I strongly suggest you make a decision fast: the Pinebook Pro stock will last no longer than a few days. At present time I cannot say with confidence how long the Pinebook Pros hiatus will be, but I suspect it will be no less than 3 months before we can even start considering spinning up production again. Mind you, this statement is based on the current market situation. The component availability situation is presently very volatile and highly dynamic. The outlook may change at any time, quite literally. Rest assured that as soon as production becomes viable again, I\u0026rsquo;ll make sure to let everyone know.\nThat is it for this month! See you in the chats and on the forum to discuss this month’s update.\n","permalink":"/2021/05/15/may-update-connection-established/","tags":["lora","pinebook-pro","pinephone","quartz64","soedge"],"title":"May Update: Connection Established"},{"categories":null,"contents":" Download audio\nIn the eighth episode of PineTalk, Ezra and Peter discuss news on the PinePhone keyboard accessory, InfiniTime 1.0, Plasma Mobile progress, Megapixels 1.0 and answer three community questions. They also share their minty-fresh first impressions of Pine-y wrist-wear.\nThe third and final community quote of the day is by Matt Burger @matthewburger \u0026ldquo;We’re definitely hitting the same high notes; we’re just not singing the same song.\u0026rdquo;\nThank you Matt for sending it in!\nWhat have we been up to lately? Ezra: is still working on his point and click adventure game: Has received a PineTime and will definitely make some videos for his my YouTube channel Elatronion (also available on Odysee). Make sure to like comment and subscribe! Peter: LINMOB.net is now running with Zola, a static site generator written in Rust. Now working on a replacement for LINMOBapps, read this blog post for more information on that. Topics News Lukasz posted to the Forums about the upcoming PinePhone keyboard [PinePhone Keyboard update April 24/04] InfiniTime 1.0 1pack seeled PineTime was available in store, now sold out until June Plasma Mobile reports progress Plasma Mobile: More Applications and an Improved Homescreen also, since then: Podcast client called \u0026ldquo;Kasts\u0026rdquo; with a k! It was being implemented a feature of Alligator, the feed reading app, but was then branched out. It’s awesome. Megapixels 1.0.1: GTK4, accelerated view finder Release notes: 1.0.1, 1.0.0. Linux Smartphones: Megapixels 1.0 released, bringing hardware accelerated graphics to the camera app for Linux phones First impressions with PineTime InfiniTime, default OS on PineTime developed by JF Siglo Amazfish, originally a Sailfish OS app ported over to Kirigami that works with many smartwatches WASP-OS WASP-OS Installation Guide wasp-companion is a thing, but the flatpak does not build as a dependency can’t be resolved) and struggles with wasptool, that uses components that no longer come with bluez on Arch Linux. (There is, however, an Android companion app (wasp-os companion for Android that seems to be a Flutter app, so it might be possible to bring over to the PinePhone.) Casio style watch face for InfiniTime - Thanks Electr0lyte! Off-topic: Fluffychat 0.3.0 (a Matrix client) runs on the PinePhone now. Community engagement 😀 Listener Questions sleep dealer Hey @talkpine do any of the pinephone OS offerings have a voice keyboard or mycroft type assistant? #askpinetalk Mycroft Mycroft GUI: Mycroft Plasma Mobile Applet Peter’s video with a Mycroft GUI If you, dear listener, have played with speech recognition or assitant features, please get in touch! Wikipedia: Speech recognition software for Linux @Epicanis Would a hypothetical new redesigned \u0026ldquo;pinetab2\u0026rdquo; with more easily-sourced parts be more feasible than chasing unavailable parts for the current pinetab? eshep asked via email about NixOS on the PinePhone NixOS Mobile If you tried this, please get in touch! Final words How Peter noticed that PineTalk is now listed on GPodder Feedback welcome! Remember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions!\nBTW, what do you think about a \u0026ldquo;App of the Episode\u0026rdquo; segment?\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nThank you to NerdZoom Media for being our audio producers!\n","permalink":"/podcast/s01e08/","tags":null,"title":"S01E08: After √64 (O’Clock)"},{"categories":["community","lora","news"],"contents":"\nMany of you are already aware that we are very interested in LoRa®. We hope to use the technology for both traditional IoT applications as well as in less orthodox ways, such as peer-to-peer text communication and even group text-messaging. This novel application potential is of particular interest to us, and in the coming months we will encourage developers to explore LoRa\u0026rsquo;s® viability as a text communication alternative to GSM/CDMA and LTE. We’re doubling down on LoRa® even at this early stage, so you can expect to see end-nodes for our SBCs, the Pinebook Pro, PineTab and PinePhone available in the Pine Store shortly. Indeed, we hope for LoRa® to become a staple of PINE64.\nGroup messaging over LoRa® is only conceptually plausible at the moment, but thankfully we’re not walking into this blindly or alone. We’ve been talking to the good folks over at RAKwireless about our ideas, and they’ve been both interested in what we had to say and very helpful in getting us started. For those of you who do not know, RAKwireless is an industry leading IoT solutions provider, producing high-end LoRa® gateways, sensors, kits and, of course, also gateway modules. Both our indoor and outdoor gateways, which are at the very heart of the system, will be using RAKwireless technology. We\u0026rsquo;re thrilled that we\u0026rsquo;re going to have an opportunity to work with RAKwireless and their community on this project.\n\u0026ldquo;We are driven by innovation, open hardware, and community work, and that\u0026rsquo;s exactly what PINE64 brings to our company. Most members of the RAKStars community recognize LoRa as part of the development of IoT devices, however, PINE64 sees LoRa differently. With the power coming from both companies, we will enable people from all over the world to use LoRa technology in innovative ways, and most importantly, to deliver secure text communication.\u0026rdquo;\n- Maria Hernandez\nThanks to the work of RTP from Privacy \u0026amp; Tech Tips, our gateways are already fully functional, and the setup process is as simple as flashing Armbian to a SD card or eMMC module and running the script. Voila! that’s it, you’re done.\nLastly, our friends at RAKwireless do not only have a highly qualified engineering team but also a large, friendly and active community consisting of staff, contributors and end users. María Hernández from RAKwireless, whom I’d like to thank for getting me up-to-speed on everything related to LoRa®, has been both very welcoming and exceedingly helpful in getting me acquainted with their company and community. She’s awesome. If you’re interested in RAKwireless, and in applications of their technology, then I highly encourage you to pop by their Discord server (aptly named RAKStars) and say hello to their community. I’ve been in their chat for a while now, and I can say with confidence that it is a great place to get help with everything LoRa®. We too have a dedicated chat for our LoRa® project, which you can access on Discord, IRC, Matrix and Telegram. More information about our plans for using LoRa®, our cooperation with RAKwireless, and news regarding hardware peripherals will follow in the weeks and months to come. As always, to stay up to date on progress please make sure to follow PINE64 Telegram News channel, the announcements channel in Discord as well as our Twitter and Mastodon. Give RAKwireless Twitter a follow too while you’re at it. Gateway prototype front\nGateway prototype back\n","permalink":"/2021/05/06/lets-make-mirakles-happen/","tags":["lora","pine64","rakwireless"],"title":"Let's make MiRAKles happen"},{"categories":null,"contents":" Download audio\nIn the seventh episode of PineTalk, the special treat is placed at the end of the movie episode: An interview with Danct12, creator of a the Arch Linux ARM Spin for PinePhone and PineTab. Before that, Ezra and Peter discuss Feedback, two aspects of the PINE64 April Community Update, and get two answer four (!) PinePhone centric listener questions as the Beta Edition is starting to arrive in peoples hands.\nIntroduction The community quote of the day today is by Shakespeare \u0026ldquo;An SSL error has occurred and a secure connection to the server cannot be made.\u0026rdquo; Biorent Lape send it in What have they been up to lately? Ezra: played Sulphur Nimbus: Hel’s Elixir working on his point and click adventure game checkout his projects on YouTube, itch.io and Game Jolt. Peter: played with Zola for the relaunch of linmob.net after that he’ll work on LINMOBapps.frama.io. he played with his PineCube Topics Feedback Just Another Kiwi Guy Feeback Thanks to everybody else for chiming in! (Community News) News PINE64: April community update Linux App Summit PinePhone accessories Patches submitted to mainline Linux to support Rockchip’s brand new RK3566 \u0026amp; RK3568 SoCs Community engagement 😀 Listener Questions @leimon asks: What would be your top three recommendations of which OS to run on it and why? PINE64 docs: PinePhone Software Releases Anonymous (who prefers to remain private) asked via email: Is the PinePhone convergence bar meant to be used only when the phone is fully charged and without the bar plugged into a power source? Or is it okay to plug the convergence bar into a power source when the phone is docked? What is the best way to back up the PinePhone Beta? JumpDrive Pika Backup Deja-Dup Mobile-friendly Purism fork Follow up question, is PinePhone convergence okay for email/note taking or too much lag? Interview Before we sat down to record this, Peter talked to Danct12, creator of DanctNIX/Huong Tram Linux, an Arch Linux ARM based distribution for the PinePhone and PineTab.\nDanctNIX Mobile First release for PineTab Danct12’s blog VNC on PinePhone (how to) Pinebook Pro as a daily driver (after 5 months) Feedback welcome! Remember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions! And get your \u0026ldquo;Community quote of the day\u0026rdquo; in!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nThank you to NerdZoom Media for being our audio producers!\n","permalink":"/podcast/s01e07/","tags":null,"title":"S01E07: My name is 64 … PINE64"},{"categories":["pinetime"],"contents":"\nWhen we announced the PineTime in late 2019 we couldn’t have imagined how popular of a project it would end up becoming. From the very start, it was evident that this will be a project like no other in our lineup. Following 18 months of intense development, the InfiniTime has now reached a release version, and the development community has made a decision; the Pinetime will be introduced to the Pine Store as an enthusiast-grade end-user product. Future production-runs (succeeding the one currently available) will ship with InfiniTime 1.0 and will be considered ready for daily use. This is a monumental achievement not only for PINE64 and the PineTime development community, but also for the open source at large. I’d like to thank all of you who made this a reality, my mind is blown.\n~Lukasz Erecinski\nToday I\u0026rsquo;m thrilled to announce the release of InfiniTime 1.0!\nBefore we go into more details about this release, let me introduce you to the PineTime project and its history.\nA brief history of the PineTime project The PineTime was first introduced in October 2019 as a completely community driven side-project, and positioned as a complementary device to the PinePhone. PINE64 decided on a simple hardware platform - a square body and a FOSS-friendly SoC, to make the developers life a bit easier.\nAt the time, PINE64 was just tossing a bottle into the sea and waiting to see what will happen. Will the community like the idea? Will developers be interested in working on such a project?\nWell, we now know how the story unfolded; prospective users and developers turned out to be very interested in the idea of a FOSS smartwatch. I too was really excited about this project the moment I read about it in an article, and I was really happy to be one of the first developers to receive a PineTime development kit.\nIt wasn’t long before a significant community of users and developers gathered in the community chat rooms. People from all around the world joined the chat to discuss the PineTime, their projects, their experiments, their progress and their ideas.\nThe project reached its first milestone in September 2020, when PINE64 chose InfiniTime as the default firmware for sealed and development kits PineTimes. And today, 7 months later, we reached a new important milestone: InfiniTime’s first release.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video version of this post by PizzaLovingNerd\nInfiniTime origins I started InfiniTime as a personal project. I wanted to experiment with the hardware and the embedded software with the vague idea of integrating it in my home automation. However, a lot of work was needed before I could even imagine using it for switching on the lights in my house: writing low-level drivers, working on the user interface, integrating the Bluetooth Low-Energy (BLE), working on Over-The-Air updates (OTA), just to name a few things that needed to be resolved and implemented.\nInitially I called the firmware \u0026ldquo;My project\u0026rdquo;, and then \u0026ldquo;Pinetime-JF\u0026rdquo;, which quickly became popular in the PineTime community. It wasn’t long before people, users and developers alike, joined in and contributed new firmware features and bugfixes. They helped testing new releases and built the project from the ground together with me! Seeing all these people contributing, I decided I wanted my firmware to be a community project and therefore renamed it to InfiniTime.\nSoon thereafter we were joined by other projects like Gadgetbridge and Amazfish, as well as more recently Siglo. These projects deliver companion apps which run on Android and Linux smartphones respectively. They added support for the PineTime very early on, and we are still working closely together on providing more features to our common users.\nPineTime and InfiniTime 1.0: an enthusiast-grade end-user product A few weeks ago I was talking to Lukasz about the new features we just added to InfiniTime. During the conversation we both realized that InfiniTime already provides a solid set of features, and that very few are missing before the PineTime running InfiniTime could be considered an enthusiast-grade end-user product. With this realisation, the race to releasing InfiniTime 1.0 was on, and here we are today at the finish line.\nWhat did we achieve? InfiniTime is a fully-featured open source firmware for the PineTime, built for the community by the community.\nIts main features include:\n2 clock faces - digital and analog\nMultiple apps (stopwatch, music control, navigation, heart rate) and games (Paddle and 2048)\nUser settings (display timeout, time format, wake up conditions)\nOTA upgrades with the help of a FOSS bootloader based on MCUBoot\nHeart rate monitoring and step counting\n3 - 5 days of battery life\nAnd much much more!\nThe project reaching version 1.0 does not automatically mean that it\u0026rsquo;s completely bug free nor that it can compete with mainstream commercial products. I see InfiniTime 1.0 as a firmware version that enthusiasts (people who like to discover new things, use cutting-edge technology, and maybe also contribute to FOSS projects) can use as a daily driver without needing experience in software development. In result, InfiniTime 1.0 is also the first version of the firmware which allows PINE64 to sell sealed PineTimes as an enthusiast-grade end-user product!\nInfiniTime has a functional heartrate monitor app capable of displaying heartrate on the default watchface\n_There are many options to tailor your experience, including waking the display on wrist tilting or tapping the display\n_\nInfiniTime is only one of your options As any true open source project, the PineTime does not rely solely on one community or a single firmware. There are many other projects available that are currently under development and all of them deserve attention from the user base.\nThe most advanced firmware among those on the list is probably Wasp-OS - the Micropython firmware. It provides many functionalities and is really easy to use and program for thanks to the Python language.\nI would also like to highlight Pinetime-Lite, a fork of InfiniTime by Joaquimorg. Joaquim added a lot of nice features and improvements, and has already contributed a lot of his work back into InfiniTime.\nWasp-OS is a popular alternative firmware to InfiniTime, with a lot of functionality and great features\nPinetime-Lite is an InfiniTime fork with many watchfaces, advanced features and complete end-user functionality\nAcknowledgements\nI would also like to thank everyone who participated, directly or indirectly, in the development of this project. This is an open source project with a strong community emphasis, and every contribution counts. A typo correction in the documentation, a major feature to be merged into the firmware, helping others debug issues or just words of encouragement on the chat and social media - we built this together, and it is something we can be proud of.\nAnd I would also like to thank PINE64 for initiating the PineTime project and for trusting the community to build such an amazing firmware for it.\nDownload InfiniTime Buy the PineTime\n","permalink":"/2021/04/22/its-time-infinitime-1-0/","tags":["community","pinetime"],"title":"It's Time: InfiniTime 1.0"},{"categories":["community","news","pinecil","pinephone","pinetab","pinetime","quartz64"],"contents":"\nBefore we start, I’d like to acknowledge that this community update was written collaboratively, with contributions from 7 developers. I hope that moving forward we maintain this dynamic and more developers, as well as community members, partake in the write-up process. If you’d like to participate in the next update then please make sure to reach out. Now, let’s get to this month’s news. You can watch the synopsis of this month’s community update on YouTube (embedded below) as well as on Odysee and Peertube. Stay up-to-date with PINE64 news and 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.\nI’d like to thank JF, Alex (clover), Bhushan, Dalton, Peter (pgwipeout), Biktor, Konrad, Brian (33YN2) and PizzaLovingNerd for their contributions to this community update.\nN.B. Comments on the blog post need to be in English and follow our Community Rules and Code of Conduct.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of this month\u0026rsquo;s update\nTL;DR Housekeeping - PinePhone BE \u0026amp; Pinebook Pro orders prior to April 12th ship out this month \u0026amp; orders made after the 12th mid-May; follow the shipping update thread Housekeeping - we’re giving 100+ OG Pinebooks to a good cause; thank you for all the suggestions! Housekeeping - we’re Linux App Summit sponsors (again) this year. Quartz64 - a close look at Quartz64 model-B; feature run-down and more Quartz64 - model-A delayed by a month+, as GbE PHY chip cannot be sourced and will therefore be replaced Quartz64 - incredible software progress; board boots both BSP and Mainline Linux now! PinePhone Hardware - keyboard back April 16th, I’ll cover it separately later this month PinePhone Hardware - wireless charging + fingerprint reader back case in production - prototype shown PinePhone Hardware - LoRa back case entering production PinePhone Software - Plasma Mobile status \u0026amp; day 1 patch for PinePhone BE PinePhone Software - Ubuntu Touch on the PinePhone, a look at the progress made PinePhone Software - Further work on the modem; better thermals + GPS now works in custom firmware, and progress with mainline Linux on the modem PineTime - motion sensor now works in InfiniTime; wake on wrist rotate \u0026amp; pedometer PineTime - InfiniTime UI overhaul underway and new features, including CNC PineTime - working towards 1.0 release later this month - keep an eye out for blog post PineTime - WaspOS progress report Pinebook Pro and PineTab - production outlook for the year, hurdles and uncertainty Pinecil - The Hammer was an April fool’s joke, but it is actually real Pinecil - Thermal resistant USB-C cable \u0026amp; mat coming Pinecil - We hear ya’ a see-through case will be available soon LoRa - PINE64 LoRa gateways now with developers; a look at the hardware LoRa - We’ve got big plans for LoRa - a list of end-nodes and add-ons already with devs Housekeeping Let’s start with some good news. As many of you are surely aware, we have both PinePhone and Pinebook Pro production-runs currently on pre-order. We don’t expect any major delays in the production and dispatch roadmaps of either device, and by the time the next community update goes live we’ll be seeing many new faces in our community. Granted nothing happens in the final days of production, and nothing unforeseen happens during dispatch, the first round of laptops and smartphones should be departing Hong Kong late this month or early in May. Those of you who pre-ordered prior to April 12th will receive your units in early-to-mid May. The second round of shipments will start in mid-May. Under normal circumstances, reporting on production and shipment is pretty mundane, but given the current circumstances it\u0026rsquo;s something that has taken center stage. As always, I’ve opened a shipping update thread on the forum, which I’ll update regularly. I look forward to welcoming all of the new Pine64 device owners to the community.\nI’ll provide detailed production outlooks for individual devices in their respective sections, but here I wish to give you a general overview of how the silicon shortage will affect us, and consequently also you, moving forward. Frankly, we don’t expect production circumstances to improve prior to Q1 2022 - in other words, we’ve got a challenging 8 months ahead of us. Last month we explained our strategy for only taking pre-orders for the PinePhone, PineTab and Pinebook Pro once production is securely underway. We’ll maintain this strategy moving forward - likely for the rest of the year. As a result, the gaps between pre-order windows are going to be longer than they were in 2020. At the same time, due to the pre-order windows being effectively ‘squished’, I expect the time from the moment an order is placed until the device ships will be reduced. Devices which can be bought outright will frequently drift in and out of availability in the Pine Store. This is because highly popular devices, such as the Pinecil or the SOPine, will only be added to store inventory once they are physically received from the factory; given current production uncertainties, only units in physical possession of the store will be sold. I’ll do my best to keep you all updated on availability throughout this year - make sure to follow the various news sources, listed at the beginning of the update, to receive updates. The original Pinebook - my kid loves her\u0026rsquo;s\nWe also have some awesome community news to cover. As you may know, Pine64 has a commitment to giving back to society at large. To reflect this, we announced that we’ll be donating 100+ original Pinebooks to an established nonprofit (or more than one). Since the announcement earlier this month, we’ve been thrilled to see such an enthusiastic response from many community members. Thank you all for the great suggestions. We have now selected a few prospective candidate organizations, some of which I’ve already been in touch with, and will be making our final decision in the coming weeks. Once again, I would very much like to thank all of you who took the time to submit a suggestion. Via Linux App Summit Twitter\nLastly, we’re once again sponsoring this year’s Linux App Summit, taking place May 13-15. It is a virtual event co-hosted by the GNOME Foundation and KDE Community, which spans multiple time zones and features some of the industry’s and open source community’s brightest minds. The purpose of LAS is to help grow the Linux application ecosystem by bringing together people from various segments of the Linux world. The conference features talks, panels, Q\u0026amp;A sessions in which attendees share their ideas on how to build a sustainable and competitive Linux app ecosystem. Attendance is free of charge and everyone is welcome to participate; registrations are now open. I hope to see many of you there! Quartz64: Hardware Before we move onto all the good news concerning development as well as the unveiling of Quartz64 model-B, we need to get some bad news out of the way. During the model-A production we learned that the Gigabit Ethernet PHY we intended to use is completely out of stock, with a projected lead time of 12 months. Moreover, the price per unit has increased by 850% (yes, that’s right, that isn’t a typo) making it unviable. We obviously have no intention of waiting a year for the PHY to become available again, nor to pay nearly 10 times more for the chipsets, so we will be replacing the original PHY with a different chip. We are currently weighing in on our options and collecting opinions from developers. As a result, the launch of the model-A will be pushed back by a month or more. By the time the next update goes live I’ll surely have a much clearer picture of Quartz64 model-A production status, so for the time being I have to ask you to be patient and to stay tuned.\nAs you probably gathered from this and the past community updates already, all things related to production remain in a constant state of flux. Last month I wrote that the Quartz64 model-B won’t be seeing a release anytime soon, and now here I am a month later showing off the model-B and announcing that we intend to bring it to the market at around the same time as the now-delayed model-A. This roadmap is, of course, based on our current understanding of available parts and present production circumstances, and therefore subject to change. Next month, when more is known, I’ll make sure to provide a joint model-A and model-B production update. If you haven\u0026rsquo;t checked out model-A yet, then make sure to read the February community update where I showcase and discuss it at length.\nTop and bottom of the Quartz64 model-B single board computer\nNow that I’ve given you a general insight into the production schedule, let’s overview the model-B itself. The board shares the ROCK64’s footprint and features all of its I/O, so for those of you using the ROCK64 in your projects, or in an industrial setting, the Quartz64-B will surely be a nice upgrade. The engineers did, however, manage to squeeze more I/O into the model-B than the ROCK64 offers; apart from the full GPIO, Gigabit Ethernet, micro SD, eMMC slot, 2xUSB 2.0, a single USB 3.0 port, IR R/X, digital video and an audio jack, you also get DSI, CSI and an M.2 (PCIe). The Quartz64 model-B also features onboard wireless connectivity. We’ll be offering the board in two versions: with a Realtek Bluetooth/WiFI chipset and a BL602 from Bouffalo, the latter of which is undergoing open-sourcing in our very own Nutcracker Challenge. For more details, you can find the schematics for the Quartz64 model-B (and A) on the respective subsection of the PINE64 Wiki. Nice little board, isn\u0026rsquo;t it?\nClosing this section off, I have some excellent news concerning software development. Thanks to the work of many people, notably pgwipeout, gamiee and Xalius as well as ezequielg and ndufresne from Collabora, we now have the board booting both mainline and BSP Linux. The fact that they collectively achieved this in just a short month’s time is very impressive. I’ve asked Peter (pgwipeout) to write a short but detailed development-status update for you, to which he kindly agreed. Quartz64: Software [by Peter (pgwipeout)] We are currently using the public facing development branches of Rockchip’s repositories. For Quartz64, this means Rockchip’s heavily customized U-boot-2018 and Linux-4.19 customized for Android. We are presently stuck using the pre-built SPL and Trust binaries from Rockchip-Android until mainline ATF is released. The boot system has changed significantly from earlier Rockchip generations - the new system is simpler, but will require retooling the mkimage tool to compensate for the new format. Here is what works as of today: for starters, U-boot allows booting from micro SD cards as well as eMMC, although the latter hasn’t been tested. We can load kernels, device-trees and initrd images. USB-OTG works partially too. As for Linux itself, we are now able to boot both BSP Linux 4.19 as well as mainline Linux. Top: Quartz64 booted into mainline Linux / Bottom: Quartz64 booted into BSP 4.19 Linux\nLinux 4.19 boots into userspace and some core I/O is functional, including the GbE controller, USB 2.0 and serial. It is noteworthy that GbE performance is above that seen on the RK3399. USB 2.0 works, albeit it is unstable with long cables, and Serial works only though FIQ-Debugger. As for mainline Linux, as of today we’ve got working clocks, GPIO, micro SD, eMMC (although it hasn’t been tested) USB 2.0, USB 3.0 and the GbE controller. Similar to the Rockchip provided BSP, USB 2.0 only works with short cables and USB 3.0 currently doesn’t function when cables are plugged in. This is a very promising start, but much is yet to be enabled. For instance, PCIe interrupts are broken at this time. Using downstream Linux-4.19, PCIe cards are eventually detected through polling, but they are not functional; mainline detects the problem beforehand and doesn’t permit the driver to probe. It\u0026rsquo;s a mapping problem, see above. The USB3.0 problems are possibly related to the USB2.0 issues, as this appears to be a PHY problem. Lastly, reboot - which is handled through PSCI, that is provided by the ATF binary, is currently not functional. Everything else is untested as of now.\nCompiling Linux kernel on an 8GB RAM Quartz64\nThere are significant challenges still ahead of us. We are working off the rk3568 documentation, which the rk3566 is a watered down version of. Unfortunately there are differences that take a bit of trial and error to trace out. The rk3568 GIC-V3 required Rockchip to implement significant changes in the irq driver due to architectural limitations. These changes will have to be ported to mainline Linux in a way that will be accepted. The Rockchip Linux drivers are incomplete and the mainlining effort has only just begun. We also need the source code for ATF to fix the reboot bug as well as work out other issues.\nPinePhone Hardware Let me start with some good news. We have the PinePhone production under control, at least for the foreseeable future, and despite the component shortages we’ve managed to secure at least 3 more large production-runs this year. Keep in mind that each pre-order and shipping cycle takes approx. 2 months. Hopefully, by the tail-end of the year the component availability will improve somewhat, and extensive logistics gymnastics will no longer be necessary to assure product availability. There may, of course, be some hiccups along the way, but here is the take-away: there shouldn’t be any issues with getting a PinePhone this year. I’ve also got some good peripheral hardware news for you. For starters, the last parts of the PinePhone keyboard should be back from the factory tomorrow. This, obviously, means that the keyboard will not be featured in this update. But stay tuned, I will keep you informed on the keyboard later this month via another blog post or a thread on the forums - I haven’t decided yet. Regardless, we are finally going to see the keyboard fully assembled soon, and I know that many of you are very excited to see it in its completed form. In other hardware news, I have an update regarding LoRa as well as the combined fingerprint reader and wireless charging back cases. Both back cases have been shipped off to be manufactured now, which means that we’ll see the finished versions in the near future. The lead time on the chosen fingerprint sensor is currently 6 weeks, so that plus the manufacturing time means we should see the built prototype this summer. The LoRa module will enter assembly shortly after, but may become available for purchase at about the same time as the fingerprint and wireless charging back case.\nLeft: fingerprint reader / right: wireless charging coil and circuitry\nBut let me back-track slightly; the new custom back case can house the wireless charging circuitry or the fingerprint reader. Both already work with the PinePhone. The wireless charging coil works because it is a ‘dumb’ peripherial, which doesn’t reqire any code to function, while the fingerprint sensor works thanks to the work by Zachary Schroeder. As some of you may remember, Zachary is the person who built the original prototype back case featuring a fingerprint scanner. The code already works and you are able to unlock the phone using your fingerprint. I suspect that this case will prove highly popular in the community. Also, since I know someone will ask, we will likely make it possible for you to obtain both the charging coil and fingerprint reader without purchasing two separate cases. The beauty of the PinePhone is that it allows for this sort of functioning. Lastly, I can well imagine that someone will probably find a way to cram both peripherals into the single case, but we do not officially support such a combination. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video PinePhone opened using fingerprint reader\nPinePhone Software [by Bhushan, Dalton, Biktor and Konrad] Plasma Mobile - by Bhushan\nAfter the image was shipped to the factory several important changes were made in Plasma Mobile upstream. For one, Jonah Brüchert removed the workarounds added for angelfish, as a result the angelfish browser performance was improved quite a lot. Moreover, Devin Lin and Marco Martin made several changes in the user interface, like the top sliding panel that can be opened in 2 stages, and various other visual improvements.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video The performance of Angelfish is really quite impressive\nOn the low-level side, there\u0026rsquo;s an ongoing effort to improve the modem stability from the kernel side - you can read more about this in the bugtracker. There is also pending work in progress patch from NetworkManager, which allows to connect to Mobile data easily when using Ofono based systems like Plasma Mobile and Ubuntu Touch. You can now pull down the top sliding panel partly (pictured) or fully\nIf you want to stay up-to-date with Plasma Mobile news, you can follow Plasma Mobile blog, and if you would like to provide a feedback or report issues to Plasma Mobile team, the please create an issue at https://invent.kde.org/teams/plasma-mobile/issues or head to our chat rooms. Ubuntu Touch - by Dalton\nI\u0026rsquo;ve seen some sentiment in the community that Ubuntu Touch for the PinePhone is not being worked on \u0026ndash; and that could not be further from the truth!\nOur big project at the moment is updating from the pine64-org kernel that many projects maintained for 5.6 to megi\u0026rsquo;s 5.10 or 5.11 kernel. This has been months coming, but we can see the light at the end of the tunnel. We\u0026rsquo;ve almost got all of the phone\u0026rsquo;s hardware working on the new kernel as well as or better than the old kernel. There are some great improvements coming with this update:1) Improved mobile network reliability; 2) Hardware-accelerated camera viewfinder \u0026ndash; it\u0026rsquo;s no modern Android phone, but it\u0026rsquo;s much improved! 3) Call audio works much more reliably.\nThere are still some things to take care of, though. For example, it fails to boot very occasionally, instead sitting at the splash screen. This has caused many users to reflash their devices, expecting it to be broken when really they just needed to reboot. Obviously not in a releaseable state.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Performance with the updated kernel is really good\nIf you want to try out the new shiny after the more extreme issues are resolved, you should switch to the \u0026ldquo;Development\u0026rdquo; or \u0026ldquo;Release Candidate\u0026rdquo; channels in Ubuntu Touch. If you\u0026rsquo;d like to test out the absolute newest, though, join us in the \u0026ldquo;kernelupgrade\u0026rdquo; channel! You can switch update channels on your device by browsing to Settings -\u0026gt; Updates -\u0026gt; Update Settings (at the bottom of the screen or a gear in the top right corner, depending on your current Ubuntu Touch version) -\u0026gt; Channels. Select a new channel there and give your device some time as it downloads the new update. If the Settings app seems stuck, make sure the screen stays on and it stays in focus. Once the download has finished, you will be able to browse back to the Updates page and click Install on the downloaded update.\nModem part 1 - by Biktor Work on the open source user space side of the modem had led to three milestones these past few weeks: better power handling and thermals, and reliable AT interface as well as GPS.\nAs for the prior, first of all credit where it\u0026rsquo;s due, the modem is already quite optimized in terms of power consumption, but being inside of a phone wasn\u0026rsquo;t it\u0026rsquo;s primary purpose. While the modem stays in low power mode when the Pinephone is asleep, it gets out of that mode when you turn on the screen. Latest changes to the userspace and kernel turn down CPU clock to 100MHz from stock\u0026rsquo;s minimum of 400MHz, but also try to keep it at that frequency even when the phone is active. This means the modem now produces less heat and consumes less power in any scenario, while maintaining the same data transfer speeds.\nAs for the AT interface, the modem has two ways of communicating with the Pinephone - the QMI protocol and the AT interface. While the primary communication channel with the modem happens through QMI, userspace daemons also need AT commands to adjust some parameters, so this needs to be done to ensure all the different applications receive the responses they\u0026rsquo;re expecting, and to provide additional functionality in the future. At this point most of the commands only emulate the expected response from factory firmware, but work is being done to reimplement all the needed commands and add some new ones that can be helpful.\nLast but not less important, standalone GPS now works in the open source firmware, which brings feature parity with the stock firmware, allowing to direct the efforts to optimize and fix the remaining bugs.\nThe news of the modem running an open stack got media\u0026rsquo;s attention - article in screenshot\nModem part 2 - by Konrad\nMy previous work on mainlining the modem has found its way into the now released PMMS (PinePhone Modem Mainline Suite) - a set of scripts gathered from both other community members and created by myself. These scripts allow for quick deployment of the mainline kernel onto the modem. It is a non-destructive process, as the image is only \u0026ldquo;fastboot booted\u0026rdquo; and not written to the NAND. PMMS provides a set of prebuilt binaries, including a modified postmarketOS ramdisk, so that developers can quickly confirm whether it works on their devices and play around with the hardware via telnet. It\u0026rsquo;s obviously not production-grade, but should things go well, the modem will be able to run the same - if not a newer - kernel version than the PinePhone itself\u0026hellip; eventually. Presently it is only meant for development purposes and regular users should not attempt to run it.\nPinebook Pro \u0026amp; PineTab I am devoting the entirety of this section to discussing the Pinebook Pro and PineTab production outlook this year. If you’re interested in learning about Pinebook Pro software developments then please read the Pinebook Pro section in last month’s update, where I listed some of the more notable recent developments. Back to the subject on hand; as many of you are probably aware, the Pinebook Pro is currently available for pre-order on the Pine Store, with an estimated shipping window late this month. Production is currently proceeding well and, unless we encounter unforeseen issues with assembly or dispatch in the next two weeks, many of you will be receiving your Pinebook Pros around this time next month. Moving forward, following the current batch, the production of the Pinebook Pro does look quite difficult. Many of the key components we require to assemble the laptops have either skyrocketed in price or are nowhere to be found. This forces us to actively monitor and evaluate production viability, and given the constantly changing market situation it is very difficult to predict when we’ll be able to schedule the next production-run. It could be as early as in two month’s time or much later in the year, or even early next year. There simply is no saying. Moreover, further price increases may occur, although we are very aware that the Pinebook Pro makes for a less attractive option at a much higher price-point. Don\u0026rsquo;t worry, we know many of you want the PineTab back in stock\nThe good news is that the current production-run is quite sizable, and there are still many units available (which I expect will last us for quite some time). That said, If you’re on the fence, but think you may want a Pinebook Pro eventually, then I strongly suggest you get one now. As for the PineTab, we’ve made it no secret that we’re prioritizing PinePhone production at this time. With very few available components, including the A64 SoC itself currently in short supply, we are opting to produce the much more popular device. Furthermore, if we were to open PineTab pre-orders at this time, it would have to be at a much higher price-point, which I believe makes for a far less attractive proposition. With all that said, we will seek to seize a window for a production opportunity opening this summer, and we will attempt to produce another batch of PineTabs. At present time it is impossible to tell if we will succeed in securing all the necessary components, negotiate sensible pricing, and ultimately offer the PineTab at an attractive price-point. Before I close this section off, I want to make it abundantly clear that while this is the outlook as of today, April 15th 2021, and it is a subject to change. While the situation may seem less than ideal, it may change any day. The situation is so dynamic that everything I wrote above may be completely invalid in a day, week, or month’s time. Stay tuned for updates.\nPineTime [by JF \u0026amp; Brian (33YN2)] The activity on the InfiniTime project was quite intense these last couple of weeks. Firstly, we\u0026rsquo;ve finally enabled the motion sensor, which allows to add step-counting and wake up on wrist rotation functionality, both of which are long-awaited features in InfiniTime. This is a major milestone as the motion sensor was the last part of the PineTime hardware that wasn\u0026rsquo;t integrated into InfiniTime.\nPineTime waking up on wrist rotation\nOnce these features were finally enabled, we quickly realised that there is a need to allow users to enable and disable the wake up on wrist rotation, and for some kind of \u0026ldquo;Do Not Disturb\u0026rdquo; mode, where the vibrations of the notifications could be disabled. It took only a couple of days for Joaquim to contribute to these functionalities and\u0026hellip; a lot more! His pull-request named BigRewrite is basically a major rewrite of the UI, which adds a lot of functionality, settings as well as apps to InfiniTime. Here\u0026rsquo;s a summary of his work: 1) Visual changes and improvements; 2) New UI navigation - swipe up to open the notifications, swipe right to open the new \u0026ldquo;quick action\u0026rdquo; menu, swipe down to open the applications menu; 3) The quick action menu allows the user to set the display brightness, disable notification vibrations and enter into the settings menu; 4) This settings menu allows users to configure the display sleep timeout, how the device can be woken up, the time format (12/24h), the default watchface and much more; 5) The watch can be woken up by a single or double tap on the display, or by wrist rotation; 6) The settings are saved in flash memory so they can be restored every time the watch reboots\nThis pull request is pretty big, but it brings so many features and improvements that we will work to merge it as soon as possible.\nA sneak peek at the new user interface\nNow, there is no need to rush to the release page to find a new version of InfiniTime to flash on your device, as those changes have not yet been released. All these changes mean a lot of modifications to the code, and we are still in the process of fixing integration issues and bugs, as well as ensuring users will be able to install this new version without any issue on their devices. This will take some time, but we\u0026rsquo;ll do our best to release a new version by the end of the month. I’ll make sure to notify you all, here on PINE64’s blog, once our first firmware release goes live - so stay tuned for that. In the meantime, I would like to thank everyone who\u0026rsquo;s helped with these developments. Joaquim did a tremendous job with the UI refactoring, and many other people helped testing the new features, fixing I²C bugs, measuring power consumption, and also encouraging the whole team to continue their hard work - it really shows how helpful and dedicated our community is!\nCompanion apps developers were also busy these past few weeks. In the last community update, I introduced Siglo, a GTK based companion app for the PineTime which, at the time, was able to sync the time of the watch. Now, Siglo 0.6.0 supports multi-device functionality, allowing the user to choose which PineTime it should connect to (useful for people working on multiple dev kits and sealed devices). Moreover, you can now easily update your PineTime thanks to the integration of the OTA (Over-The-Air updates) and the Quick Deploy Mode, which allows users to query github releases and let them choose, pull and flash assets all from within the app!\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Siglo v0.6.0 by Alex Robinson - original video\nWe also welcome a newcomer in the PineTime ecosystem - the PinetimeFlasher is a GUI app to help flash firmware into the PineTime using OpenOCD on Windows. It\u0026rsquo;s written in Python using PyQT5. This project is at its very beginning, but I trust Electr0Lyte to continue working on this app in the near future.\nFlashing PineTime on Windows 10 - via Sravan Senthiln\nLast but not least, WaspOS has seen some recent interest from developers, with work in progress feature pull requests such as a screen timeout setting, weather application, and a new phone application for showing incoming calls. Aside from that, two notable features that managed to be merged include a new word clock application, and the ability for wasptool to read battery levels. There\u0026rsquo;s also been a few minor bug fixes and improvements.\nPinecil It is safe to say that the Pinecil has reached an unprecedented level of success - no matter how many we produce — and trust us, we produce many units — they immediately get snatched up. In terms of volume of units sold per day, the Pinecil is only second to the SOPine - and that is an industry-oriented device where orders frequently range in 10k+ units per order. To this end, we’ll strive to produce large batches of the Pinecil at regular intervals - at least for as long as the necessary components are available. The next production run of the Pinecil should be available any day, and many of you will surely be glad to hear that a number of cool accessories will be available at check-out this time around. Those of you who visited the Pine Store on April 1st were likely amused to find the Mjolnir hammerhead tip for the Pinecil in the inventory. This was obviously an April fools joke, but there is the plot twist - a Pinecil hammerhead has been in the works for some time now and will be available for purchase soon. The accessory offers a large surface area capable of heating a sizable area of a PCB. The primary function of the hammerhead is desoldering surface mounted PCB components, but I can imagine it also being used for a number of other applications. I don’t currently have an ETA for the hammerhead, but it should find its way into the Pine Store this month. See, we told you, it is real!\nMany of you will also be thrilled to learn that a transparent Pinecil case will be available once the new production-run becomes available for purchase. Many of you have requested a transparent case for some time now, and we are happy to finally make it happen. That said, we haven’t yet decided if the transparent case will become a permanent addition to the store’s offering - so if you really want one, then I suggest you get one now. The transparent silicon grip is a nice touch, don\u0026rsquo;t you think?\nLastly, we will also offer a thermal isolation mat (pictured above) and a high quality heat-resistant USB-C power cable capable of delivering 4A power. The mat and cable are both capable of withstanding exposure to a temperature of 350*C, and I personally think both are great accessories for anyone doing substantial amounts of soldering with their Pinecil. The cable is particularly interesting, as it is completely custom made to our spec and will be the first cable with such heat resistance on the market (at least to our knowledge - but we first attempted to source a cable such as this, and came up empty handed). I don’t presently know when exactly these items will be available in the Pine Store - possibly at the time of publishing or sometime soon after. LoRa As I mentioned in the February community update, and as I’ve been alluding for nearly 6 months, we’re very interested in using LoRa and LoRaWAN for connectivity in PINE64 products. I invite you to read the February update to learn about some of the things we’ve envisioned for the future. At this stage we internally already have a detailed and extensive roadmap for our LoRa implementation, which you can expect to unfold over the course of next 6 months. I’ll be sharing details as things start taking shape; there are other parties than just ourselves, so as much as I’d like to explain everything outright I also need to consider others who are involved. I trust you all understand. Above you see a picture of an open PINE64 indoors LoRa gateway. Before moving onto discussing what’s actually there in the picture, let me just quickly mention that an outdoors version will also be available with an aluminium, rugged and water resistant case. As a base for the gateway we use the PINE A64-LTS, fitted with a purpose built hat (adapter) which choses the LoRa module by RakWireless. If you’re a LoRa aficionado, you’ll be happy to hear that the chosen chipset is the modern SX1302, offering increased range and speed over its predecessors. The module interfaces with the PINE A64 LTS via the SPI interface, and as you can tell from the picture we have two leads to the outside of the casing - one for LoRa the other for GPS.\nInternals of PINE64 LoRa gateway prototype\nOver this past month we built up a handful of these prototype LoRa gateways and shipped them to (sometimes unsuspecting) developers with an interest in the field of communications. While they work on getting the gateways up-and-running, we’ll be turning our attention to the end-nodes. I have already mentioned the LoRa back case for the PinePhone earlier in this update, but we’re also working on a standalone USB dongle-type end-node adapter, a PineTab adapter as well as a SPI module, which can also be configured as a USB LoRa dongle. We will also be releasing a LoRa stick powered by a single 18650 battery. It will use the BL602 WiFi/BLE RISC-V module (currently being open sourced in the Nutcracker Challenge), and can be fitted with GPS, an low-power OLED panel and additional sensors. All the end-nodes will be using the SX1262 chip. Left: USB LoRa end-node / Right: SPI, breadboard compatible end-node\nBut this is just the beginning. We’ve got more LoRa-related products in the pipeline. In the meantime, I am attaching a video by Privacy \u0026amp; Tech Tips, who made an overview of the kit we sent him earlier this month. Lastly, Discord, Telegram and Matrix chats for LoRa on the PINE64 platform should be added at the time this community update goes live, or shortly afterwards.\nLastly, we\u0026rsquo;re looking for a name for the LoRa project and we\u0026rsquo;re open to ideas; please leave them in the comments section below.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video That\u0026rsquo;s all for this month’s update, I’ll catch you next month!\n","permalink":"/2021/04/15/april-update-new-developments/","tags":["community","lora","pinebook-pro","pinecil","pinephone","pinetab","pinetime"],"title":"April Update: New Developments"},{"categories":null,"contents":" Download audio\nIn this sixth episode, Ezra and Peter talk about the next generation ARM architecture, good news around GTK4 and postmarketOS plus PINE64 community news. They also discuss a listener question (more required!) and \u0026ldquo;Do you want Linux Phones?\u0026rdquo;\nThe community quote of the day \u0026ldquo;Burning out is only the first step to greatness\u0026rdquo; by Camden Bruce (@EnderNightLord)\nNews Industry news ArsTechnica: Arm Announces Armv9 Architecture: SVE2, Security, and the Next Decade Wider Community news GTK 4.2.0 and libadwaita GTK Development Blog: GTK 4.2.0. tweets showing off the new renderer working on the PinePhone Adrien Plazas: Introducing libadwaita LINMOBapps App List postmarketOS: Second Beta Release: v21.03 Sxmo 1.4.0 release notes postmarketOS podcast PINE64 Community News PINE64: Help us help others PINE64: The Dual-Screen Pinebook Pro Video by Category5 Technology TV recentic.net: This Blog is now hosted on a GPS/LTE modem Hacker News thread Do you want Linux Phones? Martijn Braam: Do you really want Linux phones postmarketOS Martijn’s apps PinePhone distributions Community engagement 😀 April Fools We asked for your favourite April fooleries and you replied:\n1 2 3 4 5 Listener Questions @OddHouseGames asks: Is there any chance of the @signalapp coming to the PinePhone? signal.org Axolotl Mobian Wiki on Signal options Also, we’ve run out of questions :'( Feedback welcome! Remember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions! And get your \u0026ldquo;Community quote of the day\u0026rdquo; in!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nThank you to NerdZoom Media for being our audio producers!\n","permalink":"/podcast/s01e06/","tags":null,"title":"S01E06: Pine for You"},{"categories":["community"],"contents":"\nDuring a community meetup in 2019, before the entire world got turned upside down by the COVID19 pandemic, we announced our commitment to financially support Linux and open source development as well as to promote open source software whilst contributing to closing the digital gap. I believe we’ve done good on the first portion of this commitment - over the past 12 months we made donations to 5 mobile Linux projects, financially supported a number of FOSS initiatives (most recently the upcoming Linux App Summit) and helped individual contributors in their endeavours. As a side-note, I’d like you to know that this is just the beginning - we have extensive plans pertaining to community support in the near future. Stay tuned.\nWe did, however, have to set aside our scheme to give back to society due to the chaos that the pandemic stirred up. For the past 18 months the key focus of PINE64 and the Pine Store was to keep production going while actively facilitating development. This effectively left very little space for any other activities. Now, whilst the manufacturing situation isn’t exactly great, we at least have a good idea where we stand. As a result, we also feel that there is a little more wiggle-room for extracurricular activities; it is time to do good on the second portion of our commitment made in 2019. We have 100+ original 11.6” Pinebooks which we wish to donate to a worthy cause. The Pinebooks are running an excellent mainline OS image by Manjaro, featuring an accelerated KDE Plasma desktop. While the Pinebook is no speed demon by any stretch of the imagination, this tailored build makes it rather snappy and perfectly viable for light workloads, such as: running educational software, browsing the web, using the LibreOffice suite, terminal work, etc,. It is also a sturdy laptop, one which you wouldn’t worry about handing to a child, with a long battery life and all the necessary connectivity for completing aforementioned tasks. We’re now turning to you for ideas; we’re looking for a suitable partner - a not-for-profit organization, which would get these Pinebooks into the hands of people who will benefit from them the most. Anything goes, and all ideas are welcome. There are, however, two things you need to be aware of making your suggestions: 1) the not-for-profit organization needs to be recognized by the US Internal Revenue Service (IRS) and 2) have some degree of logistical capabilities, as the laptops are in the US, State of California. We obviously would much prefer to work with an organization that shares the open source community’s values and ideals, but ultimately we’re open to working with anyone striving to better the circumstances of those in need. Any organization working towards closing the digital gap is worthy of a consideration.\nPlease, leave your suggestion in the comments. We will make sure to review all viable suggestions thoroughly. If you represent an organization which you believe fits our criteria and fulfills the cooperation requirements, please contact us directly: info@pine64.org.\nThank you in advance!\n- - -\nWant to learn more or have additional questions regarding this scheme? - you\u0026rsquo;re welcome to reach out to me directly in the chats:\nDiscord\nTelegram\nMatrix\n","permalink":"/2021/04/03/help-us-help-others/","tags":["digital-gap","nonprofit","pinebook"],"title":"Help us help others"},{"categories":null,"contents":" Download audio\nIn the fifth episode of PineTalk, Ezra and Peter discuss a few aspects of the latest Community Update, PineCube news, the component shortage and answer a few of your questions. BTW: Keep getting them in!\nWhat have we been up to lately? Ezra recently finished working on the codebase of a project: It’s a fan game, written in C from the engine to the game. Peter has re-installed his laptop with pre-release Fedora 34 Workstation and have been enjoying GNOME 40 since. Also, the LINMOBapps Game list is maintained again, thanks to Moxvallix for taking it on! Community News March Update PINE64 March Update PinePhone Beta Edition PineBook Pro availability (only ANSI keyboards) Is it possible to switch keyboards later on? Yes: See e.g. this video. PineTime (something we are both yet to receive) New bootloader InfiniTime update: InfiniTime 0.14 \u0026ldquo;Green Avocado\u0026rdquo; (actually, they have released 0.15.0 \u0026ldquo;Yellow Banana\u0026rdquo; in the meantime!) LVGL (LVGL post by LEE Lup Yuen) WaspOS 0.4 release More links GadgetBridge Amazfish Wikipedia: Demoscene PineCube as a Web Cam Chris McGee has been enabling the PineCube for use as a web cam and shared his findings on the PINE64 doc page Component Shortage Component shortage (requested by danct12 and thanosthetankengine in discord) Further reading: Ars Technica: A silicon chip shortage is causing automakers to idle their factories Bloomberg: Chip Shortage Spirals Beyond Cars to Phones and Consoles Reuters: Qualcomm struggles to meet chip demand as shortage spreads to phones: sources Recommendations for PineTab content: Linux Lounge: Odysee, PeerTube, YouTube Privacy and Tech Tips: Odysee, YouTube Peter talks about his ROCKPro64 Mastodon thread ROCKPro64 PREMIUM ALUMINUM CASING HP Elite X3 Lap Dock (ZDNet Review) Pine64 docs: ROCKPro64 Twister OS Armbian Listener Questions Anders asks whether the development of the PinePhone or any other Linux Phone will actually ever be finished, or like so many other open software things be stuck in an endless loop of development? xnux.eu: Some PinePhone updates Danny Medina asks about PineBook Pro upgradability: Upgradable ARM laptop: MNT Reform CNX Software: Rockchip RK3588 revealed Feedback welcome! Remember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions! And get your \u0026ldquo;Community quote of the day\u0026rdquo; in!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nThank you to NerdZoom Media for being our audio producers!\n","permalink":"/podcast/s01e05/","tags":null,"title":"S01E05: Marching On"},{"categories":["pinephone"],"contents":"\nI am pleased to announce that pre-orders for the PinePhone BETA Edition will open on March 24. The PinePhone BETA Edition is powered by KDE Plasma Mobile and Manjaro Linux.\nTo learn more about the BETA Edition please read the March Community Update. PinePhone BETA Edition will be made available in two hardware configurations:\n$149 — 2GB RAM; 16GB eMMC $199 — 3GB RAM; 32GB eMMC (includes a USB-C dock) Both configurations feature the newest PCBA revision (1.2b). The $199 hardware variant, called convergence package, also includes a USB-C dock equipped with 10/100 Ethernet, 2x USB type A ports, HDMI digital video output and power-in via USB-C.\nWe currently expect to start shipping the PinePhone BETA Edition in late April.\nGo to store\n","permalink":"/2021/03/19/beta-edition-pre-orders/","tags":["pinephone"],"title":"Beta Edition Pre-Orders"},{"categories":["pinebook-pro","pinecil"],"contents":"In this project, I\u0026rsquo;ll turn my Pinebook Pro into a portable multi-monitor Linux laptop and show you how to do the same.\nIntroduction In this post, I\u0026rsquo;ll share how I turned my Pinebook Pro into a dual-screen Linux laptop. It\u0026rsquo;s a rather inexpensive upgrade, and what parts I didn\u0026rsquo;t personally have on hand I was able to manufacture myself.\nThis post is not meant to be an exhaustive guide. I simply want to put the bug in your ear and show you how I did it, confirming that a dual-screen setup for the Pinebook Pro is not only possible, but entirely functional (and looks slick too).\nIt\u0026rsquo;d be nice to have a portable multi-monitor workstation. And that\u0026rsquo;s where this project comes in.\nA Quick Disclaimer I can\u0026rsquo;t promise this will work as well on every Linux distro, nor can I assure you every USB-C screen will work. So I\u0026rsquo;ll say this: The Pinebook Pro is a laptop for makers. Projects like this may or may not work, and may take troubleshooting and time to figure out. There are so many variables. But to me, the process is all part of the fun, and the risk is thrilling.\nKeep in mind as you dive into this project that drawing too much power from your Pinebook Pro could cause problems, or even damage. While I\u0026rsquo;ll cover my power requirements below, it\u0026rsquo;s important to note that you do this at your own risk. If in doubt, speak with someone who is confident about this stuff, or post your questions in the forum to request help from the community.\nDon\u0026rsquo;t miss the video at the bottom of this post! My Dual-Screen Pinebook Pro\n_Mmmmmmm_ulti-Monitors As a coder, I love multi-monitor setups. It\u0026rsquo;s not unlike me to have my IDE up on one screen and a test environment on another. Or, when working on graphics, I prefer to move the GIMP tools to one screen and the image to another, maximizing the visible canvas. When producing my videos, multiple monitors is an absolute requirement.\nGood luck fitting my usual multi-monitor setup in a carrying bag!\nMy Distro I\u0026rsquo;m not suggesting you install the same distro as me, but if you do have trouble getting up and running on your version of Linux, it might help to know that I am running a custom-compiled Debian 11 on my Pinebook Pro, pretty much stock. You can learn how I did that here: https://www.youtube.com/watch?v=8WSqcmuJjCM\nSelecting My Display The project began with selecting which external display I would buy. You can choose whichever screen you like, but for reference, here is the criteria I had for my display selection:\nMinimized Connectivity Requirements - A single USB-C cable from the Pinebook Pro to the screen should provide both video and power to the monitor. As noted by Tobias Mädel on our YouTube video about the project (below), the USB-C mode we\u0026rsquo;re looking for is called \u0026ldquo;DisplayPort Alternative Mode\u0026rdquo;, or DP-Alt-Mode, Matching Aesthetic - The color and physical dimensions of the screen should closely resemble those of the Pinebook Pro\u0026rsquo;s screen, Portable - It should fold down flat, making it easy to transport both the Pinebook Pro and the external screen in the same laptop bag without excessive bulk, Application Dimensions Match - A 16:9 aspect ratio and resolution that matches that of the Pinebook Pro screen (1920x1080) so dragging windows from one screen to the other does not result in perceptual shifting in window size, Highly Affordable - Price of the external display should be less than that of the Pinebook Pro itself. You can spend more if you like. I wanted the additional challenge of seeing if an ultra-affordable display would work. They can be hard to come by under ~$160, but I was fortunate to find one for just $100 USD \u0026hellip; which promptly sold out at that price and is no longer available (sorry). As my criteria is brand agnostic, you shouldn\u0026rsquo;t have any trouble finding something similar. Just be particularly mindful that your power requirements may differ from mine.\nMy production workspace on \u0026ldquo;The Bridge\u0026rdquo; at Category5 Technology TV. Yes, I enjoy multi-monitor setups.\nConnecting The Display Out of the box, I connected the external display to the Pinebook Pro via a single USB-C to USB-C cable which came provided with the monitor. The screen powered on showing the vendor logo, but then displayed \u0026ldquo;No Signal\u0026rdquo; and eventually went to sleep.\nI opened the Display settings on the Pinebook Pro, and it didn\u0026rsquo;t even detect the second screen. I tried the quick and obvious: Reboot the Pinebook Pro while the display was connected. It still didn\u0026rsquo;t detect.\nI didn\u0026rsquo;t want to dig too deep into the system right away, just in case my issue was a simple one that had already been dealt with. So I got onto the PINE64 Community Forum and sure enough, I quickly found a thread mentioning a similar issue. DrYak posted a reply last June suggesting the user simply unplug the USB-C cable, turn it over, and plug it back in.\nWait a minute - I thought USB-C did away with the old Superposition feature of USB-A!\nBut \u0026hellip; It worked! To my surprise and delight, the display powered on as before, but this time, my Pinebook Pro display flashed, and my desktop suddenly and instantly extended itself to the external display.\nWhen first connected, the display didn\u0026rsquo;t do anything more than this, but DrYak\u0026rsquo;s suggestion worked.\nA Note About Screen Orientation When you first connect your external display, your Pinebook Pro has no way of knowing whether you\u0026rsquo;ve placed it physically on the left or right of the built-in screen, so you may need to adjust the screen position within your Display settings. Simply drag the monitors to the correct orientation and apply the changes.\nPower Requirements The DC power supply for the Pinebook Pro is 5V 3A, so I\u0026rsquo;ll use that as my baseline. Of course, PINE64 left some room for connected peripherals, NVMe, and so-on, but it\u0026rsquo;s unlikely they intended users to power an external display.\nAlong that vein, I don\u0026rsquo;t suggest running your dual-screen setup from the Pinebook Pro\u0026rsquo;s battery. Doing so could damage the battery or other components of your Pinebook Pro.\nThe monitor you buy may be different than mine, so be sure to look at the power requirements in the documentation provided by the manufacturer. In the case of the one I purchased, the power requirements are listed as 5V 8W. The formula to find Amps is an easy one. Simplified, it is Watts / Volts = Amps. So 8 divided by 5 in my case, which gives me 1.6 Amps.\nBased on the 3A baseline for the Pinebook Pro and the 1.6A required by my display, I can see that I will want a minimum of 4.6A to power the two together. So I\u0026rsquo;ll round up and opt for a 5V 5A power supply.\nPower Supply Peripherals Here are some examples of what you might want to use to get you up and running with a single 5A power supply. The DC power supply goes to an adapter, and that goes to a USB cable that has the proper barrel connection for the Pinebook Pro on the other end. This will provide more than enough current not only for the Pinebook Pro, but the external screen as well.\n5V 5A DC Adapter\nDC 5V USB-A Male to 3.5mm x 1.35mm Barrel Plug Cable\nAdapter to Connect The Two\n(Make Sure the Barrel Jack Matches Your AC Adapter)\nIn my case, I already have the 5V 5A DC power supply on hand (a spare for LED lights), and I bought the USB to barrel plug previously for my Pinebook Pro to power it from a wall wart. But I don\u0026rsquo;t have one of those fancy adapters on hand to connect them together. Plus, I don\u0026rsquo;t really want to wait for one to arrive in the mail. So, I\u0026rsquo;ll instead fire up my 3D printer and have some extra fun!\nGetting Started: Slicing my quick and simple design.\nSoldering A Custom Adapter: Using my Pinecil for the first time to create my own 3D-printed Barrel to USB adapter.\nAfter this simple project, I officially LOVE the Pinecil!\nThe Final Result: Not as sleek as store bought, but it works, and is something I can be proud of.\nOf course, you can just buy the adapter if you\u0026rsquo;re not as nerdy as me. Granted, if you want to take a crack at it, you can download my simple design here.\nPutting It All Together By matching up my choice of monitor so closely to that of the Pinebook Pro built-in display, I get a strikingly seamless multi-monitor experience from my dual-screen Pinebook Pro. Because my custom power supply is allows me to increase the brightness of the external display, I\u0026rsquo;m able to very closely match the brightness and color as well. I now have a gorgeous dual-screen Pinebook Pro, ideal for coding, photo manipulation and design, working online through the browser, or even remotely connecting to my powerful video editor to work from home.\nIs It Really That Easy? Your experience may vary, but for me, it really was that simple to get up and going! I hope it works for you too.\nThe Pinebook Pro is a fantastic Linux Laptop for those of us who love to tinker. Don\u0026rsquo;t fret if you have trouble. The community is here to help, and I\u0026rsquo;m confident that with some patience and tinkering, you\u0026rsquo;ll get there too.\nWatch The Video There\u0026rsquo;s nothing quite like seeing it in action. Please give my short video a watch to see how I devised the project, and learn even more about my custom Pinebook Pro power supply hack. I\u0026rsquo;d also be grateful if you\u0026rsquo;d consider giving it a \u0026ldquo;thumbs up\u0026rdquo; on YouTube.\nhttps://www.youtube.com/watch?v=NOA6hWiXfAo\nFurther Improvements The next practical step for me is to simply tie-wrap the USB-C cable to the Pinebook Pro\u0026rsquo;s power cable, giving the appearance that it\u0026rsquo;s just one cable, making it look even neater. It would be fun to design and 3D print a connector to actually mount the second display to the Pinebook Pro and hide that single USB-C cable entirely within by soldering a ribbon cable directly between the two in place of the USB-C. Oh, the options are truly endless with a hackable device like the Pinebook Pro.\nConclusion I\u0026rsquo;m really happy with this setup. I reminisce about those pre-pandemic days when I could sit in my local coffee shop all afternoon with my Pinebook Pro and do my work over WiFi. I\u0026rsquo;m excited for the time to come when I can do that again, but this time I\u0026rsquo;ll pull out the second screen and look entirely 1337 as I sip my latte.\nIf you end up trying the dual-screen Pinebook Pro setup, I\u0026rsquo;d love to read your comments below!\nThanks for reading, and remember, if you\u0026rsquo;re not having fun, you\u0026rsquo;re doing it wrong.\nAbout The Author Robbie Ferguson is the host of Category5 Technology TV. He enjoys creating fun but approachable tech projects that can be accomplished by people with varying levels of skill and experience.\nSubscribe to his YouTube channel for more content.\n","permalink":"/2021/03/19/dual-screen-pinebook-pro/","tags":["category5-technology-tv","debian","dual-screen","laptop","linux","pinebook-pro"],"title":"The Dual-Screen Pinebook Pro"},{"categories":["community","pinebook-pro","pinephone","quartz64","soedge"],"contents":"\nWelcome to this month’s community update. We’re now facing one of the most challenging electronics manufacturing circumstances in years, and possibly even in all of electronics history. Despite this, I’ve got some good news to relay this month, including a Quartz64 pilot production-run, SOEdge being available next month and plenty of community news. Last minute update: looks like we will have the PinePhone and Pinebook Pro for pre-order next week too, hurrah!\nYou can watch the synopsis of this month’s community update on YouTube (embedded below) as well as on LBRY and Peertube. Stay up-to-date with PINE64 news and make sure to subscribe to this blog (subscription widget at the bottom of the webpage), follow PINE64 Telegram News channel as well as our Twitter and Mastodon.\nI’d like to acknowledge JF, Marek (Gamiee), Alex (clover), and PizzaLovingNerd for their contributions to this community update. Thank you!\nLet\u0026rsquo;s get to it.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of this month\u0026rsquo;s Community Update\nTL;DR Housekeeping pt.1: we’re facing difficult manufacturing circumstances - pre-orders for Pinebook Pro \u0026amp; PinePhone will open after production is underway. Housekeeping pt.1: stock availability of SBCs, SOMs and other devices will likely change on a weekly basis Housekeeping pt.2: we’re working on a stock and pre-order tracking system for the Pine Store Housekeeping pt.2: the PineOne riddle was solved in record time Housekeeping pt.2: I was on FOSS-North podcast talking about PINE64 Housekeeping pt.2: fourth episode of PineTalk is out; PineTalk has been listed on Podcast Index SOEdge: SOEdge AI module now fully functional thanks to Marek (Gamiee); runs BSP Linux and build is tailored to support existing PINE64 hardware / peripherals SOEdge: the SOEdge baseboard and USB 3.0 adapter are currently being produced, and will be back next month, at which point they’ll go on sale; expect availability in April Quartz64: The current situation forced our hands - we started a Quartz64 pilot production-run; available in April Quartz64: 8GB RAM Quartz64 units started shipping to developers this week Quartz64: e-ink panel now works with Quartz64, and the performance is really good from what I’m told Quartz64: model-B of the SBC placed on temporary halt, due to component shortages Pinebook Pro: we’re aiming to start production later this month, at which point pre-orders for the new Pinebook Pro batch will open [last minute edit: pre-orders likely to start next week] Pinebook Pro: a price increase forced by the market situation - $220 for current PBPs, may further increase in the future Pinebook Pro: phenomenal Armbian with GNOME desktop OS images are feature complete and utilize Panfrost FOSS GPU drivers for desktop acceleration Pinebook Pro: postmarketOS for the Pinebook Pro is now available, looks awesome, and features a neat installer utility with disk encryption Pinebook Pro: Manjaro now offers a MATE OS image alongside KDE, XFCE and tiling managers (Sway / i3) PinePhone: production hurdles at the time of writing; an explanation of the situation [last minute edit: pre-orders likely to start late this month] PinePhone: we’re still hoping to start taking pre-orders soon, however we need to wait for production to start; presently difficult to define when exactly factory can source missing component PinePhone: the upcoming production-run, and subsequent few, will be called Beta Edition to indicate software status PinePhone: the keyboard is progressing well - but we’re still waiting for the keycaps; they should be delivered later this month PinePhone: the fingerprint scanner case is coming along as is the Qi-wireless charging case, but those will first be introduced when the manufacturing situation eases PineTime: InfiniTime has seen 3 releases in a matter of a month; new firmware functionality and a new bootloader PineTime: WaspOS has also seen a new release and is now supported by Gadgetbridge PineTime: two new companion apps for the PineTime, which can be used with the PinePhone and an update to Amazfish Housekeeping pt1: production hurdles Last week we notified our user base that we will only start taking pre-orders for our popular devices like the PineBook Pro and the PinePhone, once production is securely underway. Pine Store inventory items such as the Pinecil, the PineTime dev kits, and the SOPine modules have also drifted in-and-out of Pine Store’s stock over the course of past weeks. This is the result of very severe manufacturing circumstances that have affected the entire electronics industry, and our neck of the woods is no exception. As things stand, all components, down to discrete transistors, have lead times of 40 weeks or more. RAM and eMMC memory, as well as key parts such as LCD panels, are in severe shortage and have in some instances seen their prices double since March 2020. The lead time on LCD panels, just as an example, is currently 60+ weeks, so the expected delivery date falls well into 2022. Silicon is not exempt from this: SoCs such as the A64 are also in short supply and have seen their price increase by a third. This now affects much of the electronics industry, including tech giants - via Reuters\nI am trying to find a suitable analogy, which would somehow illustrate the situation. The best I can do is this: do you remember the toilet paper and hand sanitizer shortages at the beginning of the COVID19 pandemic in the West? - it’s like that, but with transistors, PC/phone parts and silicon. Similarly to the spineless scalpers who sold hand sanitizer for $10+ on eBay to the panicked public in 2020, many component vendors are exhibiting out of character behaviour, preying on factories and businesses in distress. Quoting the words of a factory head we work with: “I haven’t seen anything like this in the 15 years that I’ve been in the business.” Worst of all, there isn’t a clear path out of this situation for factories or businesses. The situation is currently growing more severe and there is no end in sight. So, why am I writing all this? Because I want to put out the word that we at Pine64 will be more cautious with taking pre-orders for devices, as well as actively monitor Pine Store stock. With regard to devices such as the PinePhone or Pinebook Pro: we don’t want to open pre-orders today just to find out in a week or two that the factory doesn’t have the means to deliver stock for weeks or months. I’m sure that you ultimately prefer to patiently wait, and have certainty that the device will be delivered in a timely manner, rather than have us hold onto your money for an extended period of time. As for single board computers, compute/AI modules and smaller devices such as the PineTime or Pinecil: since we cannot assure a steady flow of such devices from the factory, we’ll only sell things we currently have in our inventory. We currently keep selling units whilst awaiting delivery (usually every week or two), but for the foreseeable future we’ll halt the sales until the next production-run is physically delivered. So expect to see such stock pop up every couple of days or weeks as new deliveries arrive at the warehouse.\nI hope this clarifies the situation. At the same time I ask you not to bombard info and sales with questions about availability - they don’t have up-to-date insight into the production status. Instead, please subscribe to the Telegram News Channel. It isn’t a chat, it is just a stream of announcements, and presently the best way to be notified of device availability. We’re working on an availability tracking solution (read pt.2 of the Housekeeping section for details) but it will take some time to implement. Housekeeping pt. 2: community insight We are working on a system that would allow users to track product availability and expected pre-order windows. If you read pt.1 of Housekeeping, then you already know that this wouldn’t really be of any help to us now due to production uncertainty, but it is something that end-users will benefit from in the future once the world returns to normal (whenever that may be). Frankly speaking, we also hope that this will unburden support, info, and sales teams currently spammed by questions of availability. We will be testing out the system next month, or the month after that, and we’ll likely start with one of two devices which aren’t at production risk. If you know of a company that has a good product availability system in place, then please share it in the comments section - I’ll make sure to take a look at it and show it to Matthew (fire219) and Marek (Gamiee). Last week I posted the PineOne riddle, and to my surprise it was cracked in record time. I’d like to congratulate Dalton who was the first to solve the cyphre and provided a detailed explanation of his thought process. I must say I was shocked by how fast this riddle was deciphered - I really expected it would take hours, or even days, for someone to correctly identify the solution. This is the third riddle we’ve done as a community and judging from the response I feel that people find it to be good fun. There aren\u0026rsquo;t any other announcements on the horizon currently, but once the next opportunity arises I’ll make sure to involve people with some knowledge of riddles to come up with something more challenging. I may also rethink how we select the winner(s) - time zones make it difficult for some people to participate, making the exercise a bit unfair to our friends in Asia and Oceania. I was recently on FOSS-North podcast talking about PINE64, our strategy of community engagement and our plans going forward. I encourage you all to take a listen when the episode airs. In the meantime, FOSS-North has an extensive backlog of tremendous content with some of the most insightful industry insiders. The podcast is a part of a FOSS conference taking place in Gothenburg, Sweden; they have put out a call for papers and everyone is welcome to submit written material. Check them out. On the subject of podcasts, our very own PineTalk podcast has recently been added to the Podcast Index. There is now also a PineTalk Mastodon account to make it even easier for you to interact with Peter and Ezra, ask them questions, offer feedback and suggest discussion topics. Their most recent episode aired last Friday - the guys discussed video calls on the PinePhone, RISC-V GPUs, offered their views on your suggestions for future PINE64 gear and responded to community questions. Have a listen to the latest episode here. SOEdge For those of you who do not know, or do not recall, the SOEdge is a powerful AI module in a SODIMM form-factor; you can learn more about it here. Thanks to Gamiee’s hard work, the SOEdge is finally ready for prime-time, as we can now run a fully functional BSP Linux on the AI module. The Linux build is capable of utilizing the SOEdge’s powerful NPU and includes enablement for all core functionality of the module. This includes, but is not limited to, Gigabit ethernet, USB, PCIe as well as the LCD DPI interface with touch input. I am told that, when inserted into a model-A sized SOPine or SOEdge baseboard, the SOEdge is also able to utilize either of our WiFi and Bluetooth SDIO modules. Getting the SOEdge build operational was a monumental undertaking and Gamiee did a phenomenal job not only in bringing Linux to the platform, but also in having the software support existing PINE64 hardware. As you can see in the attached video, the SOEdge Linux build has been customised to also work with existing PINE64 hardware, such as for instance the 7” Pine A64 LCD touch panel.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video SOEdge Linux test image booting with a LCD touch panel attached\nWhile the SOEdge is capable of working on the SOPine baseboard, thanks to pin-out compatibility of both the SOPine and SOEdge modules, we’re currently in the process of producing a SOEdge-specific baseboard which, among others, will expose PCIe - not present on the SOPine mainboard. Thanks to the SOEdge’s pin-out compatibility with the SOPine, it can also be inserted into the Clusterboard. You can even mix and match SOEdge and SOPine modules on the Clusterboard to achieve a very interesting computational and AI setup. Indeed, the possibilities are truly substantial. You could, for instance, also populate all Clusterboard slots with SOEdge modules, and equip each module with a USB UVC camera. I’ll come clean and say that I know very little about AI, but I can imagine that from a machine-learning enthusiast’s perspective the prospect of having 7 AI modules, paired with 7 cameras, in a compact mini-ITX enclosure is quite compelling. SOEdge and SOPine modules in the Clusterboard\nThe SOEdge baseboard should be back from the factory next month along with a USB 3.0 adapter board allowing the SOEdge to couple with any USB 3.0 enabled X86 PC or single board computer. We’re currently planning on having the SOEdge, the SOEdge baseboard and USB 3.0 adapter board available in the store mid-April. Quartz64 We decided to produce a pilot batch of Quartz64 model-A single board computers (SBCs). The current manufacturing situation has, in a sense, forced our hand. We originally planned on a much slower roll-out of the board(s), with an extensive development cycle proceeding the launch, but with the production window closing rapidly, we ultimately decided to take a leap of faith and push the ‘go’ button. As a result, the first boards will be available late next month. I cannot stress this enough - this production run is aimed strictly at developers, not end-users. If you want a fully functional SBC at present time, then I encourage you to pick up a ROCKPro64 or PINE A64-LTS (depending on how much performance you require) instead. It will take time for Quartz64 to reach its full potential, and if you’re not interested in participating in the bringup development process then you’d be wise to look elsewhere for SBCs for your computational or project needs. First 8GB RAM Quartz64 SBCs heading out to developers\nSpeaking of development, the first 8GB Quartz64 boards have just been dispatched to contributors participating in the early bringup process. With more people participating in development, I expect to have more early software progress to relay next month. As things stand, the product team managed to boot Rockchip’s Board Support Package (BSP) Linux with kernel 4.19 on Quartz64 and enabled some of the board’s basic functionality for testing. Community developers, however, haven’t been able to boot the board into Linux yet. It’s still very early days, so we’ll need to wait a little longer to see Linux running on the device. The product and engineering teams have been evaluating various e-ink displays that can be used in conjunction with the board. The e-ink display has now been brought up to work with the Rockchip SDK and the stock Android build. The performance, I’m told, is better than devices with a similar power and thermal envelopes currently available on the market. This is obviously a very exciting prospect, not only for the Quartz64 but also for the devices that it may give birth to. We have obviously seen many of you suggest we use the board as a base for an e-ink type device, and we have given this suggestion a serious thought. But it is one thing for the e-ink panel to work with the default SDK and another thing to have it work with BSP Linux. Yet another thing is mainlining this e-ink protocol. So, yes, we do share your enthusiasm for an e-ink based device built upon the Quartz64, but at the same time recognize that the road ahead of us is likely long and winding.\nQuartz64 with an e-ink display attached running stock factory Android\nAs for Quartz64 model-B, which features a smaller footprint than model-A, it will have to wait a little longer to see the light of day. We’re very happy with the model-B design. However, despite being in possession of approx. 70% of all RK3566 SoCs on the market, we don’t have enough to produce both model-A and model-B simultaneously. This, in conjunction with what I wrote in the housekeeping section, should give you an idea of how severe the silicon shortages truly are. In the end, model-A needs to take priority at this time due to its development focused nature. As a result, the model-B may be delayed for quite some time.\nPinebook Pro We are hoping to open Pinebook Pro pre-orders this month, however as I explained in Housekeeping pt. 1, this is wholly dependent on production proceeding without a hiccup. As things stand, at the time of writing, the factory plans to begin the manufacturing process the week of 22-28 March [Last minute edit: it looks like we\u0026rsquo;re on track to open pre-orders next week, however only ANSI units will be available at this time]. This gives you a general sense of when to expect Pinebook Pro pre-orders, granted everything goes according to plan. This Pinebook Pro production-run will be introduced at a revised price-point of $220, reflecting the component price-hike. As I explained in the January update, when faced with the dilemma of whether to increase Pinebook Pro’s price point or further postpone production (awaiting component prices to decrease), we will proceed by increasing the price point. At this time, our priority is to resume production, even if the price needs to be increased by 10%. I simultaneously would like to make you aware that the price will likely increase further in future batches. We don’t like increasing the price of our devices but at this point it is simply unavoidable.\nArmbian with GNOME DE runs great on the Pinebook Pro\nThe good news is that this is a great time to pick up a Pinebook Pro. Armbian has recently released new OS images featuring Panfrost acceleration. This includes a version of Armbian that ships with the GNOME desktop environment. I have now spent over a week testing out the image featuring GNOME and I have to say that it has been a very pleasant experience overall. I need to come clean at this point, and admit my preference for Manjaro and Plasma desktop, but the GNOME on Armbian runs just as fast as Plasma on Manjaro and all applications, including firefox, are just as responsive. Overall, I must say that I am highly impressed. So to those of you who have been longing for a traditional (and well supported) Ubuntu-like experience on the Pinebook Pro, I finally get to say that this is now a reality. If you already got a Pinebook Pro, then you can get the Armbian Focal with GNOME here. I should mention that Armbian also offers OS images with XFCE and MATE, as well as testing images with Cinnamon and Budgie desktops. In other Pinebook Pro software news, we now have a postmarketOS image featuring kernel 5.11.x and GNOME desktop for the Pinebook Pro. Both a ‘live’ and an ‘installer’ OS image is available. The installer OS image allows you to encrypt your filesystem, set your user name and password as well as tweak a few other variables. Although postmarketOS is primarily a mobile operating system, it is lightweight and tailored to run on ARM systems thanks to its Alpine Linux base. This makes it a natural candidate for running on the Pinebook Pro. I encourage you all to have a look at postmarketOS on the Pinebook Pro - images can be found here.\nhttps://www.youtube.com/watch?v=hjzNr7wnBpk\nInstalling postmarketOS on the Pinebook Pro by Martijn Braam\nLast but not least, I ought to mention that our friends at Manjaro recently released the Manjaro Arm 21.02 build which will ship with the new production run of the Pinebook Pro. While the Pinebook Pro ships with Plasma Desktop by default, Manjaro now also offers an officially supported MATE OS image for the Pinebook Pro. We have also seen a lot of Pinebook Pro related experimentation on the Manjaro base, most notably a build by Alex (clover) which features Lomiri (formerly Unity8). From what I’ve been told, Lomiri runs decently on the Pinebook Pro and offers a pretty unique experience on the platform. I should also mention that official Manjaro builds with tiling managers such as i3 or Sway are also available in the Manjaro repo. PinePhone [Last minute edit]: just prior to publishing the update, I got word that we will be replacing the elusive part we cannot source with an alternative; granted no other issues arise, pre-orders will begin late this week or sometime next week. Mind you, uncertainty remains high, so this is still subject to change, but things don\u0026rsquo;t look quite as dire as they did when I wrote this section. A placeholder pre-order inventory item has been published already on the PineStore. I am leaving the rest of the PinePhone section unchanged because it gives you an insight into current hurdles (and I don\u0026rsquo;t have time to rewrite it extensively).\nAs soon as we get word that production started, you\u0026rsquo;ll be able to pre-order one\nLet me start by writing extensively about the production status. If you haven’t done so yet, then please backtrack to the beginning of this month’s update and read pt.1 of Housekeeping - it will provide you with the necessary context for understanding the following section. As many of you know we were initially planning on launching PinePhone production last week and opening pre-orders this week. We had all our components (both discrete and key parts) ordered months in advance and the production floor reserved as well. In short, everything required to produce the next PinePhone batch was in place by the time we entered the Chinese New Year in February. At that time we couldn\u0026rsquo;t have predicted that vendors would not hold up their end of the agreement. I’ll spare you the details, they aren’t particularly pleasant nor interesting, but it boils down to this: components we booked in advance were sold to other parties (presumably at a much higher price). We managed to source many of the components we lost, but we’re currently short of one discrete component (usually very easy to obtain) which is nowhere to be found. The production team is continually looking for the said component, and the moment they’ll find it production will be able to begin. However, at present time, I simply cannot tell you whether that will be later today, tomorrow, in a month or in 3 months time. I’m sure you can appreciate that we want to open pre-orders for the next batch just as much as you want to place one; but, as I already explained earlier in this community update, this will only only happen once we know that the production is well underway and there are no obstacles in sight. The announcement of PinePhone pre-orders starting will likely drop quite suddenly, without a prior warning as there is no scheduling. Please subscribe to our Telegram news channel, follow us on Mastodon or Twitter to be notified. How do you like the default PinePhone presentation box?\nOn the flipside, the good news is that aside from the one missing component we’ve got everything lined-up and ready to go. The upcoming production-run, as well as the next two or three following it, will be referred to as the Beta Edition. The term “Beta” indicates the present software status. Despite huge strides made by Manjaro and KDE Plasma Mobile teams in the past 3 months, the software isn’t yet at a stage where we’d be comfortable selling the PinePhone as an end-user ready product; even if the target end-users of the PinePhone are informed Linux enthusiasts. It will be yet a couple of months before the software reaches a status where we’d be willing to pitch the PinePhone as a “completely functional smartphone for advanced Linux enthusiasts”. That said, let\u0026rsquo;s take a moment to appreciate the fact that the software has moved out of an Alpha-stage and that core smartphone functionality has now reached considerable maturity, thanks in large part to the Community Edition (CE) scheme which ran throughout 2020. The Manjaro KDE Plasma Mobile build has already been submitted to the factory, alongside the default presentation box and documentation. Below you’ll find a render of the default PinePhone presentation box - personally I think it turned out great. I am also attaching the ‘READ ME’ note that will ship in the box alongside the ‘Quickstart Guide’ for those of you who wish to read it. Since someone will surely ask: the hardware remains unchanged from the past three community editions, and will feature the 1.2b revision of the PCB. Some assembly still required, but we\u0026rsquo;re getting there\nBefore finishing the PinePhone section, I want to touch upon the status of the much anticipated keyboard accessory as well as the fingerprint back case. As for the prior, we’re still waiting for the keycap molds to come back from the factory. We were told in the latest communication to expect the keycaps in the second half of this month. The moment I get an update on the keyboard, I’ll make sure to put out a tweet alongside pictures of the PinePhone in a PDA-like configuration. Assuming no issues are found with the molding, we could see the PinePhone keyboard in the Pine Store as early as mid-May. Keep your fingers crossed! As for the fingerprint back case, I’m glad to let you know that considerable progress has been made: the PCB and case design have been submitted for manufacture. We had to make some alterations to the original design by Zachary because of availability and pricing of the chosen sensor. I don’t have an ETA for you at this time, but the case should be ready at some point in Q2 granted the manufacturing situation doesn’t worsen even further.\nPineTime (by JF) This month I have a lot of news to share about the progress of the PineTime project: we have a new bootloader, InfiniTime and WaspOS released new firmware versions, two new companion apps were created, and Amazfish and Gadgetbridge continue to improve their integration with InfiniTime. Let\u0026rsquo;s start with the bootloader and the release of the new MCUBoot bootloader for PineTime. I\u0026rsquo;ve already written about this bootloader in the January community update, and since then we performed numerous tests to ensure that it works correctly and that the upgrade procedure itself is as safe as possible!\nLet me explain. The bootloader is a very critical piece of software that is run when the watch boots up. It\u0026rsquo;s responsible for upgrading the firmware when a new version becomes available and for loading the firmware (InfiniTime, for example). We use MCUBoot as the base of the bootloader. MCUBoot ensures that the upgrade of the bootloader is 100% safe by swapping the old and new version of the firmware in memory. In the event an unexpected error occurs, it is able to revert to the old version of the firmware. Any issue with the bootloader could temporarily or permanently brick the PineTime, and that\u0026rsquo;s why we put a lot of effort into the bootloader.\nUpgrading the bootloader is also a critical operation as there is no fallback in the event an error occurs during the upgrade. From the feedback I received until now, it looks like everything is working well and that it\u0026rsquo;s fairly safe to apply the update. You just need to read and apply the instructions carefully.\nSee the video here.\nVideo of the new bootloader\nAll of this would not have been possible without Lup Yuen\u0026rsquo;s work. Lup was the first to dare work on a bootloader for the PineTime, and this new version is mostly an improved version of his original work. We fixed a few bugs and added some features like a basic UI and a recovery firmware. This recovery firmware can be loaded by keeping the button pressed while the bootloader is running and allows the user to OTA a new firmware in case the current firmware does not work correctly and/or does not provide the OTA functionality.\nSince last month 3 versions of InfiniTime were released; InfiniTime 0.12 and 0.13 improved the BLE connectivity by a lot! While it is still not perfect, BLE connection is now more reliable. Users should notice less unexpected disconnections and fewer failed OTA firmware upgrades. Version 0.13 also added vibrations on notifications and notification on call - when your phone receives a call, the companion app sends a notification to InfiniTime with the name of the caller. The notification app allows the user to accept, reject or ignore the call on the smartphone.\nInfiniTime 0.14 \u0026ldquo;Green Avocado\u0026rdquo; brought the first UI update of InfiniTime, thanks to Joaquim\u0026rsquo;s work! Joaquim did an awesome work updating LVGL, the open source graphics library we use in InfiniTime. This new version brings many features that will be useful to create nicer apps and watchfaces. Joaquim did not stop there and also improved the UI of many applications, like the notification app, which is really looking good now!\nInfiniTime 0.14 UI element redesigns look phenomenal\nWaspOS, the MicroPython based firmware also released a new 0.4 version. The main focus of this version was the integration of the watch with the phone. WaspOS worked with Gadgetbridge and the last version of the Android companion app now supports WaspOS. Version 0.4 also added a nice analog clock face, new UI widgets and a brand new theming engine.\nhttps://www.youtube.com/watch?v=nps8Kd2qPzs\nWasp-OS doesn\u0026rsquo;t just look great, it also features a tonne of functionality\nCompanion app developers did not rest this month either; clover aka Alex Robinson released Siglo, a GTK based companion app for the PineTime. It\u0026rsquo;s capable of synchronizing time with InfiniTime and I heard that Alex is working on adding the OTA flashing functionality to the app. Another new companion app (yes, a second one!) appeared in the PineTime ecosystem. WebBLEWatch is a web based application that uses WebBLE (on Chrome) to connect and set the time on InfiniTime. Martin, the developer of this app, describes it as a proof-of-concept, but I do really hope he\u0026rsquo;ll continue the development and will add the OTA functionality in the near future ;)\nYou can try this web application online if you are using the Chrome web browser.\nGadgetbridge, the Android companion app released version 0.55, which fixes the music controller app (we broke it by changing the BLE UUIDs in a recent upgrade of InfiniTime\u0026hellip;) and also adds the support of the call notifications. Finally Amazfish, the Linux companion app by Adam, also added the support for call notifications and improved the way notifications are displayed. Now, the name of the application pushing a notification and the full text message is displayed in the notification app in InfiniTime. I am attaching a video from Adam showing Amazfish in action, upgrading the bootloader and InfiniTime, displaying a text notification and a call notification.\nI\u0026rsquo;m really amazed by all the work the community achieved this month, and I look forward to seeing what we\u0026rsquo;ll accomplish next month!\nSee the video here.\nA look at PineTime InfiniTime functionality\nThat is all for this month. Make sure to subscribe to the blog and follow PINE64 Telegram News channel as well as our Twitter and Mastodon. Until next month!\n","permalink":"/2021/03/15/march-update/","tags":["pinebook-pro","pinephone","quartz64","soedge"],"title":"March Update: Status Report"},{"categories":null,"contents":" Download audio\nIn the fourth episode of PineTalk, Ezra and Peter discuss some industry and community news, go through your favourite answers to their question and answer a few of your questions, some of them (spoiler!) GPU related.\nWhat have we been up to lately? Ezra: Has been contemplating new videos that will appear on his YouTube and Odysee channels or his website: elatronion.com. Peter created a video about Sailfish OS 4.0.1.48, which you can find on YouTube, PeerTube and Odysee. (Community) News Matrix video calling on the PinePhone LinuxSmartphones: Now you can make video calls on a PinePhone (but it’s very much a work in progress) Original story: Pinephone: Breakthrou on Fedora Pinephones MIPS joins RISC-V EEjournal.com: Wait, What? MIPS Becomes RISC-V Related Hacker News thread Wikipedia: MIPS architecture Wikipedia: Loongson Connecting PineCone to a LoRaWAN transceiver LEE Lup Yuen: Connect PineCone to LoRaWan transceiver Wikipedia: LoRaWAN Community engagement 😀 A question for the Community We asked on Twitter: What device would you like to see @thepine64 make?\nWhat device would you like to see @thepine64 make?\n— PineTalkPodcast (@TalkPine) March 7, 2021\nand many of you answered. Thank you!\nCommunity Questions for us Will you guys ever talk about the PineTime? Just listened to the intro and was wondering if you are going to talk about the Pinebook Pro and various operating system such as twister is? Has the RISCV SBC an open source GPU? CNX-software story about the Xuan Tie C906 Would it be practical for Pine64 to make a FOSS GPU for the desktop, or a higher power GPU for your next laptop? Embedded.com: Open source GPU builds on RISC-V LibreSoC: Well, kind of … a dedicated GPU is not our main scope Feedback welcome! Remember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions!\nUse #pinetalk or tweet at us @talkpine, toot at us @talkpine@fosstodon.org, send email to pinetalk@pine64.org and join our Discord!\nThank you to NerdZoom Media for being our audio producers!\n","permalink":"/podcast/s01e04/","tags":null,"title":"S01E04: GPU-o-Rama"},{"categories":["community","risc-v"],"contents":"The riddle has been solved by DALTON. I\u0026rsquo;ll be contacting the winner in the coming days.\nThank you to everyone who played along!\nThe correct answer is: PINEONE\nIn the event you\u0026rsquo;re interested, you can learn more about this and previous riddles here.\nIt is time for a bit of community fun. Below you\u0026rsquo;ll find a riddle, or a cypher to be precise, pertaining to the name of our upcoming affordable RISC-V single board computer (SBC) announced in the February community update. The previous riddles were solved in a matter of hours, so I put in a bit more effort into crafting this one.\nCorrectly deciphering the riddle will reveal the name of the SBC - please enter your answer in the comments section. Only answers submitted on this blog post will count, as they are time-stamped, which makes it easy to verify who was first. You get bonus points if you explain how you arrived at your answer.\nThe person to solve the riddle first will win the RISC-V single board computer*.\nLatin slant Under the scorching sun\nAn old Roman senator sat Studying it all And slowly came to realize that\nHe bears witness to the empire’s fall\nAnd so began his intricate plan\nFor the imminent end\nSo savage and so cruel Was this strive to mend It lay waste to the Roman rule\n_*****The winner will receive the first production version of the SBC. Prototype devices destined for developers will ship first. _\nThe Pine Store cannot ship to countries under international embargo (North Korea, Iran, etc.,).\n","permalink":"/2021/03/09/risc-v-sbc-riddle/","tags":["riddle","risc-v","single-board-computer"],"title":"RISC-V SBC Riddle"},{"categories":null,"contents":" Download audio\nIn the third episode of the PineTalk, Ezra and Peter discuss the PINE64 February Community Update and answer community questions about Sxmo, RISC-V, and ARM Workstations.\nIn the third episode of PineTalk, Ezra and Peter discuss the PINE64 February Community Update and answer community questions about Sxmo, RISC-V, and ARM Workstations.\nWhat have we been up to lately? Ezra: has a new personal website: elatronion.com Peter: made a video on Manjaro Daily Dev builds: PeerTube, Odysee, YouTube, worked on LINMOBapps (for reference: KDE Apps have working appstream:// links) Topics PINE64 Community News February Community Update Read it in its full beauty, or watch PizzaLovingNerds\u0026rsquo; great video on Odysee, Tilvids, or YouTube. Quartz64: (Rockchip RK3566, up to 8GB RAM, lots of options to connect storage, displays and other hardware) runs really cool and faster than the PINE A64 (Allwinner A64) and ROCK64 (Rockchip RK3328) it’s eventually superseding MakeUseOf: Pine64 Announces a Native E-ink Single Board Computer RISC-V SBC with two RISC-V System-on-a-Chip (for less than 15 USD) Allwinner XuanTie C906-based SBC: solid I/O, including USB 2.0 and Gigabit Ethernet, no 3D accelerator = entry-level Linux-capable RISC-V platform CNX Software: XuanTie C906 based Allwinner RISC-V processor to power $12+ Linux SBC’s CNX Software: RISC-V Bases and Extensions Explained. 2nd SoC for networking: Bouffalo BL602 WiFi-BLE LEE Lup Yuen: The RISC-V BL602 Book PinePhone Keyboard accessory (includes 6000 mAh battery) Manjaro Plasma Mobile as new default OS for the post-Community Edition PinePhone. Your feedback and questions: Logenkain: What do you think about Sxmo? Related: Linux Smartphones: Sxmo 1.3.0 brings usability, performance improvements to this simple, geeky Linux phone UI. Mark: How far off is a #riscv PinePhone? 😉 Related: Android on RISC-V Liam: What do you think, should PINE64 start making workstations? Avantec Workstations SolidRun HoneyComb LX2 Workstation Risc-V Desktop: SiFive: HiFive Unmatched Remember: This is a community podcast, we need your questions, ideas to make this work! Also, please leave feedback on what we should do better!\nTweet at us @talkpine, send email to pinetalk@pine64.org and join our Discord!\nThank you to NerdZoom Media for being our audio producers!\n","permalink":"/podcast/s01e03/","tags":null,"title":"S01E03: Quartzy Keyboards"},{"categories":["news","pinebook-pro","pinephone","quartz64","risc-v"],"contents":"\nWelcome to this month\u0026rsquo;s community update. As many of you know, we have now entered the Chinese New Year (CNY) period, which means that all manufacturing and related business activities have ground to a halt. It is always a mad rush to complete ongoing work prior to CNY, but now that the festive period is upon us we get a chance to catch our breath and evaluate the progress made.\nIn this month\u0026rsquo;s update we\u0026rsquo;re going to take a close look at the Quartz64 model-A, showcase headway made on the PinePhone keyboard, discuss our first RISC-V single board computer and introduce plans for making LoRaWAN a staple of the PINE64 ecosystem.\nYou can watch the synopsis of this month’s community update on Youtube (embedded below) as well as on LBRY and Peertube. Stay up-to-date with PINE64 news and make sure to subscribe to this blog (subscription widget at the bottom of the webpage), follow PINE64 Telegram News channel as well as our Twitter and Mastodon.\nI’d like to acknowledge JF, Marek (Gamiee), Alex (clover), PizzaLovingNerd, Konrad, Biktor and Dylan for their contributions to this community update. Thank you!\nThis may just be the most news-packed update since July last year, so strap in for some PINE64-goodness and let\u0026rsquo;s get to it.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video Synopsis by PizzaLovingNerd\nTL;DR for this month’s update:\nHousekeeping: Two PineTalk episodes are out! Housekeeping: Pinecil back in stock late Feb/ early March Housekeeping: Shipping status of PinePhone Mobian CE Housekeeping: Manufacturing difficulties expected after CNY and for much of Q2/Q3 this year Quartz64: Detailed specs listed and pictures of the SBC shown Quartz64: Comparison to ROCKPro64 connectivity \u0026amp; performance Quartz64: Generic benchmarks on par with most popular SBC on market Quartz64: More than a stand-alone SBC - a dev platform for future devices Pinebook Pro: Production resumes in March; pre-orders mid-March PinePhone pt.1: End of CEs; PinePhone to ship with Plasma Mobile on Manjaro from now on. PinePhone p.1: A close look at the PP keyboard; fitted with 6000mAh battery PinePhone p.1: We decided on the keyboard layout with community - the keyboard will be programmable, for those who wish to alter keyboard functionality PinePhone p.2: Opensourcing the modem - a status report by Biktor, Konrad and Dylan PinePhone p.2: Modem - work done on kernel 5.11; running open userland on kernel 3.18; making phone calls from open firmware PinePhone p.2: Expected modem improvements using FOSS firmware PineTime: 3 versions of InfiniTime released in short succession in last 30 days PineTime: Blob-less heart rate monitoring working on InfiniTime + improvements to OTA flashing PineTime: Navigation on PineTime synced to Linux or Android Phone RISC-V PINE64 SBC: We’re entering the RISC-V SBC game RISC-V PINE64 SBC: Starting with an entry-level SoC combined with a RISC-V WiFi/BLE currently being opensourced (Nutcracker challenge) RISC-V PINE64 SBC: Goal to make RISC-V accessible to all at a reasonable price; fun SBC with multiple potential applications; sub $15 SBC RISC-V PINE64 SBC: Stay tuned for a name reveal via riddle LoRa \u0026amp; LoRaWAN PINE64 integration: we are doubling down on LoRa integration - coming to all PINE64 devices LoRa \u0026amp; LoRaWAN PINE64 integration: we will build our own base stations based on next gen technology with better range, lower power consumption \u0026amp; higher transfer-rates LoRa \u0026amp; LoRaWAN PINE64 integration: Novel use of technology - text-based communication without a middleman Housekeeping I want to start by giving Peter and Ezra - our PineTalk Podcast hosts - a huge shutout. They\u0026rsquo;ve worked really hard on the first two episodes of the podcast and, judging by the number of episode downloads, so far their style has resonated well with the community. In the last episode they spoke to Dalton Durst from UBports, discussed the recent announcement of PinePhone Community Editions coming to a close and answered some questions from the community. PineTalk is now available on all major platforms, including Spotify and Apple\u0026rsquo;s Podcast app, and I highly encourage you to subscribe to the RSS feed. Yes, of course, you can listen to PineTalk on your PinePhone too\nOver this past month we received a significant amount of feedback concerning the new PINE64 website. This included suggestions on improving the site’s responsiveness, functionality as well as a variety of various minor bugs encountered by community members. As a result, responsiveness has been significantly improved and sections of the site have been reworked to offer a better experience on mobile devices. There is now also a dedicated blog button (honestly, I was surprised to hear people had issues finding the blog on the new site) and the blog itself received some much needed tweaks to improve navigation. A number of fixes were also made to make the page less taxing. Thank you to Gamiee for his continued work on the community site and to all of you who submitted feedback and suggestions. As I mentioned in the opening bit of this blog entry, CNY is now upon us and there will be no manufacturing or shipping activity until late February. All Pine Store contractors in Malaysia, China and Hong Kong are now enjoying time off with their families and close ones (where permissible, of course, given COVID19 is still rampant). To those of you awaiting a response from the support or info teams, please be aware that you will not receive a reply until after CNY. If you have an urgent query concerning your shipping or order status, i.e., a query which cannot wait, then please reach out to me or one of the moderators in our chats.\nI\u0026rsquo;d like to quickly touch upon the Pinecil\u0026rsquo;s availability. I get bombarded with questions about when it will be back in stock, so I’m answering the query here: stock will be available again late this month or early the next. Don\u0026rsquo;t expect it to show up in the store before the end of CNY.\nI must say, the Pinecil looks good in red - picture via Dan Lien on Twitter\nBefore proceeding to the main topic of this month’s housekeeping section, I want to write a few words about the Mobian Community Edition PinePhone shipping status. As some of you are aware, we ran into issues with DHL shipments in late January and early February. Long story short, we effectively had to reship an entire palette of KDE CE PinePhones twice due to a DHL error. This threw a wrench into our schedule; the shipping team worked hard to dispatch as many phones as possible prior to CNY, but unfortunately most Mobian CE units ended up waiting at the warehouse to be shipped to their rightful owners. Only phones destined for Europe were successfully shipped before work ceased. Please follow the dedicated forum thread to stay up to date on the shipment process.\nI\u0026rsquo;d like to finish this housekeeping section by making you aware that difficult times are ahead of us manufacturing-wise. It was a year ago to the day when I first wrote about the impact the COVID19 pandemic would have on the supply chain and manufacturing process in China. I reported on the situation more than a month before any big brand even murmured a word about the severity of the electronics shortages, which we all witnessed mid-and-late last year. You see, big brands don\u0026rsquo;t really want customers to know that their devices will not be available or in short supply. So here I am, a year later, once again being a bearer of bad news (edit: since originally writing this passage, 10 days ago or so, some reporting of the issues already begun in the media). We expect severe component shortages and major component price hikes after CNY. I am writing this to prepare you for what is to come. Production-wise, we\u0026rsquo;re entering a difficult phase and compromises will be made - there is no doubt in our minds that the emerging market situation will have a significant negative impact on PINE64. However, the extent of the impact won\u0026rsquo;t be known for at least an entire month, so let\u0026rsquo;s not worry too much about the unavoidable and hope for the least disruptive outcome. Keep your fingers crossed! I will, of course, keep you up to date on how things pan out. Quartz64 It is finally time for us to take a look at Quartz64 model-A, the first installment in our \u0026lsquo;Quartz-line\u0026rsquo; of next generation single board computers (SBCs). The doc page for Quartz64 is now available for those of you who wish to study the schematics and datasheets. Keep in mind that photos of the Quartz64 depict a prototype device and some modifications to the hardware may prove necessary prior to the SBC’s release. Any changes made, however, will be very minor at this point and only implemented to remedy issues identified by developers, if such arise. In other words, although this is an engineering sample, production units will look indistinguishable from it. With the board\u0026rsquo;s layout now finalized, we\u0026rsquo;re happy to share all the details you’ve been waiting for with you.\nTop view of Quartz64 model-A\nMany of you will immediately notice the close resemblance, in terms of both the available I/O and general layout, that this board shares with the ROCKPro64. Both boards feature USB 3.0, alongside 2xUSB 2.0 ports and have an open-ended 4xPCIe slot, which can be populated by a variety of peripherals. The similarities don\u0026rsquo;t end here: the Quartz64 features un-populated IR and SDIO headers (current IR and WiFi/BT modules are compatible), has HDMI capable of 4K output at 60FPS as well as a DSI and CSI output and MiPi interface. There is also 128Mb of onboard SPI flash, just as on the ROCKPro64. The eMMC and mSD card slots too can be found in the exact same position on both boards. There are also FAN, VBAT and 12V power headers, situated in the same model-A layout locations. A RTC connector is also located on the PCB. The 12V header is capable of powering up-to two 2.5\u0026quot; SSDs or HDDs when using our 12v 5A power supply, just as on the ROCKPRo64.\nWhile the SBCs share many similarities, there are some significant differences between the two. For one, as you have likely already spotted, the Quartz64 has a native SATA 6.0 port located right behind the USB ports. The Quartz64 has one USB 3.0 port, while the ROCKPRo64 has one USB 3.0 and one USB-C port. The Quartz64 PCB also features an integrated battery charging circuitry. This means that, similarly to the PINEA64-LTS, the board can be completely battery operated. A unique feature of the Quartz64 is its native e-ink port; as I already mentioned in last month\u0026rsquo;s update, we hope to have a 10\u0026quot; e-ink panel available in the Pine Store when the SBC releases to the public. Perhaps most importantly of all, Quartz64 is capable of supporting up-to 8GB of LPDDR4 RAM.\nFront view of Quartz64 model-A\nBack view of Quartz64 model-A\nPerformance-wise, early testing indicates that the Quartz64, with its 4 cortex A55 cores clocked at 1.8Ghz, is only 15-25% slower in computational tasks than the ROCKPro64. Do keep in mind, however, that the Quartz64 isn\u0026rsquo;t a Pro-grade PINE64 single board computer. The intended purpose for it is to eventually supersede the PINE A64 and ROCK64, rather than the higher-end ROCKPro64. If anything, the fact that I am comparing a non-Pro next generation SBC to a Pro-grade current generation board should be rather exciting. Lastly, since I know that many of you are curious, the Quartz64 delivers computational performance that is very similar to the most popular single board computer on the market (based on generic benchmarks). Do keep in mind, however, that such benchmarks do not always translate well to real-life tasks, so one board may be superior to another depending on the nature of the scenario. I also ought to mention that from our initial testing, the RK3566 runs really cool - under load, without a heatsink, it rarely spiked above 60*C.\nDon\u0026rsquo;t read too much into these generic benchmarks\nDesigning the Quartz64, we envisioned that it will serve an additional purpose in the future. Aside from being a stand-alone SBC, it will also be used as a development platform for future non-Pro devices. We have been thinking about democratizing development for some time now, and we intend to start the process with the Quartz64. Creating dedicated development platforms, such as the Don\u0026rsquo;t Be Evil PinePhone kit, is expensive and time consuming. Such kits also limit the number of people who can participate in the bring-up process, as usually a very limited number of such devices are manufactured. The Quartz64, however, features all the necessary circuitry to start work on a next generation phone, tablet or laptop. Plug a display into the DSI port, a modem into the USB port and add a battery - voila, you\u0026rsquo;ve got yourself a next-gen phone dev kit. So to those who aren\u0026rsquo;t usually interested in SBCs in general - it may be worthwhile picking one up and helping the Linux bringing-up process on the RK3566.\nSpeaking of the bringing-up process, a small number of Quartz64 boards have now been shipped to low-level developers. I am looking forward to seeing how Linux takes shape on this RK3566 platform in the coming months. A major encouraging factor in the bringing-up process is that the Panfrost open source GPU driver ought to \u0026lsquo;just work\u0026rsquo; once Linux is brought-up and functional to a point where video output is possible. GPU drivers are always tricky and usually take a long time to open source, so the fact we already have a FOSS GPU for this SoC is a major boon.\nUnder high load it manages to stay cool, even without a heatsink\nIt is too early to talk about general availability at this point. A lot will depend on how quickly rudimentary Linux support can be brought to the Quartz64. That said, I place a lot of trust in the developer\u0026rsquo;s abilities. You can expect an update on Quartz64 in the next community update.\nPinebook Pro I am happy to let you know that we will be resuming production of the Pinebook Pro shortly after CNY. We were fortunate enough to secure A-grade LCD panels and the necessary RAM (currently in short supply) for the production to begin, and we already have an allocated slot at the factory for the assembly process. I presently do not have a pre-order date for you - that will be announced at a later time. But if you\u0026rsquo;re interested in picking up a unit then I strongly suggest you follow our Telegram news channel and/or social media for pre-order news (links in the opening paragraph of this post). I know, however, that many of you would appreciate a ballpark idea of when stock will be available, so to this end: based on our current schedule, pre-orders are set to open sometime mid-March 2021.\nThe Pinebook Pro is now a mature platform with a lot of fun development - image by Clover\nPinePhone Part 1 Earlier this month we announced the end of the Community Editions. The Community Edition program was a vital step not only in bringing support to the PinePhone, but also in bringing attention to mobile Linux outside of our immediate bubble. Countless people worldwide were made aware of alternatives to the duopoly of Android and iOS, and I\u0026rsquo;m sure that we can all agree this is a good thing. This exposure is obviously good for PINE64, but I\u0026rsquo;d argue that it is equally good for the entire Linux community. Promotion of the Community Edition PinePhones propelled mobile Linux development like nothing else in recent years and gave birth to multiple new projects. With tens of thousands of PinePhones in people\u0026rsquo;s hands, it is no longer an unlikely possibility that a mainline Linux smartphone will take hold, but rather an inevitable certainty. Before moving on, let me once again thank all the projects and their developers who participated in the Community Edition scheme. You all did a great job.\nWhile the Community Edition program is now closed, we\u0026rsquo;re working on a plan to actively support mobile Linux projects moving forward. Talks are held with all major projects and we already have some ideas on how to provide developers with ongoing support. Aside from projects which received a Community Edition, we are now also talking to Maemo Leste, LuneOS, openSUSE, DanctNIX and Fedora developers. While we haven\u0026rsquo;t settled on a means to achieve this type of support just yet, I hope that a part of the strategy will be an introduction of branded back-covers to the Pine Store. In short, the idea is to sell back-covers with projects logos at approx. a $15 price-point, out of which $10 would go towards the donation. I think that this is a good and fun way of supporting development, which provides end-users with a tangible benefit for submitting their donation. It will take a couple of weeks for us to figure this out, or maybe even longer, but once we do arrive at a suitable arrangement I’ll write a dedicated blog entry about it. At this stage I know many of you are wondering what the future of the PinePhone holds. A question that I frequently receive concerns the default operating system and user interface that will ship on the PinePhone. Today we are very pleased to announce that the PinePhone will ship with Plasma Mobile on a Manjaro ARM base from this point on. We have a long-standing relationship with Manjaro and KDE Community, and both projects have supported us and our efforts since the dawn of PINE64. I\u0026rsquo;m not sure if I wrote about this publicly in the past, but the promise that Plasma Mobile held in its early stages was the deciding factor for us to proceed with creating a Linux smartphone in the first place. Needless to say, we have been excited to see the UI environment mature and flourish on our platform over the past 12 months. Manjaro is our core partner, offering support for all our flagship Linux devices, including the ROCKPro64 and the Pinebook Pro. Their work on the PinePhone has been indispensable, and their current OS images are among the best and most fully-featured for the platform. Working with both projects on the PinePhone has been a pleasure and I am convinced that together we will reach new heights in the months to come.\nManjaro and Plasma Mobile is just a great combination (picture of widget on main page)\nEarlier this month we also received the PinePhone keyboard, perhaps the most anticipated accessory of them all. It literally arrived a week ago from the factory. Looking at the pictures below, those eagle-eyed of you will probably notice the missing key caps. The key caps and the keyboard\u0026rsquo;s PCB are the two outstanding parts we’re still waiting for - we expect both to be delivered shortly after CNY. The molding is completed however, and has now been submitted to us for review. I\u0026rsquo;m happy to let you know that our initial impressions are very positive and we\u0026rsquo;re convinced that you\u0026rsquo;ll be pleased with it too. Please keep in mind that the pictures are of an early preview unit, and everything you see is a subject to change before they keyboard becomes available in the Pine Store.\nPinePhone in the keyboard chassis from the front and side\nPinePhone in the keyboard chassis from the side\nPinePhone in the keyboard chassis closed top\nPinePhone in the keyboard chassis closed bottom\nFrom the very inception of the keyboard design we wanted to include a large battery in the base of the chassis. Aside from the obvious benefit of significantly extending the PinePhones operating time, a large battery also serves as a counter balance to the PinePhone placed in the top section of the keyboard’s body. We wanted to cram as much battery power as possible into the keyboard, and we were lucky to find a 22Wh 6000mAh battery which fits the bill perfectly. From my estimates, the PinePhone fitted with the keyboard will be able to remain in standby mode for nearly a week with the modem active. With the modem disabled, however, it will last you more than two weeks on a single charge when placed in deep-sleep. Due to the battery\u0026rsquo;s size taking up the bulk of the space inside the keyboard’s bottom section, the charging circuitry had to be shrunk down to a tiny PCB. But don’t be deceived by it’s tiny size, this charging circuit can simultaneously charge the keyboard and the PinePhone via the keyboard’s USB-C port. Since I know someone will ask: the USB-C port on the keyboard can only be used charging, it doesn\u0026rsquo;t support data or any alternate modes.\nPinePhone keyboard charging PCB\nLook at the size of that battery!\nThis effectively completely frees up the USB-C port on the PinePhone. You can plug a convergence dock into it or use it for any other common USB-C devices, e.g. thumbdrives. A quick web-search revealed to me that there are now a number of USB-C wireless mice available on the market (something I wasn\u0026rsquo;t aware of!). So you can pick one up and plug it into the PinePhone, thereby transforming it into a pocketable Pinebook. Many GUI environments available for the PinePhone - including Phosh, Plasma Mobile and Lomiri - already work well in a desktop mode, but I am sure that the keyboard accessory will entice people to bring MATE, XFCE, GNOME and full-fledged Plasma to the device. And why not - after all the keyboard converts the PinePhone into a PDA capable of running full-blown Linux.\nBefore moving onto discussing software, I quickly wish to touch upon the keyboard’s layout. We spent a weekend in January ping-ponging ideas about the layout with the community. After some push and pull we finally arrived at a compromise that most end-users should be happy with, given the space and design constraints. The illustration attached below depicts the layout we arrived at and submitted to the vendor. I know that not everyone will agree with every design decision made; to those of you who would prefer a different layout, or really need a CAPS key (for whatever reason), rest assured that eventually you\u0026rsquo;ll be able to flash your own firmwares to the keyboard via the i2c pins, and thereby change the keys functions. This will, however, require input from the development community - an effort similar to that made on the Pinebook Pro will be needed. The time it took to get the community\u0026rsquo;s approval of the design led to a delay in delivering the keycaps prior to CNY. But even without its keys, doesn’t it just look awesome?\nHere is they keyboard layout we agreed on with the community\nPinePhone Part 2 [by Konrad, Biktor and Dylan] We are currently working on three different fronts modem-wise: 1) porting the mainline (kernel.org) kernel; 2) open-sourcing the userspace and; 3) improving the way incoming calls and texts are handled while the phone is suspended.\nThe modem can now boot version 5.11 of the Linux kernel with minimal functionality (serial, USB and NAND). Konrad has been working hard on all the low level drivers that are needed (PMIC, clocks etc) so the rest of the devices inside the SoC can start. There\u0026rsquo;s still a lot of work to do, since the SoC has never seen an official release from Qualcomm ever since kernel 3.18.x, so even if some pieces can be adapted from other mainlined Qualcomm models, there\u0026rsquo;s a lot of code that needs to be written from scratch. Work is being done by Konrad to send his existing patches upstream, so that they can get merged and so that he can further continue the work.\nVoLTE blobless audio calls will be possible in the future. Original Twitter post By Biktor\nOn the present factory firmware, there are about 150 closed source binaries and libraries that make the modem work. Biktor is working on replacing all of them with 3 open source alternatives that will hopefully get 90% of the required functionality. At this point we can initialize the modem, establish data connections and make both CS (normal) and VoLTE calls without any binaries, although sometimes audio fails, and call reception doesn\u0026rsquo;t work yet. Stay tuned for more information about the open sourced userspace in near future.\nDylan has been tackling one of the biggest complaints concerning the modem, namely the slow recovery from suspend and its USB resets, making the PinePhone lose incoming calls and texts when using ModemManager (since it cannot reconnect to the modem fast enough after suspend). These patches, currently in a testing stage, should make the PinePhone wake up and start ringing on the first dial tone when there\u0026rsquo;s an incoming call or text, as well as fix intermittent USB resets that show up when resuming from suspend.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video We currently have: i) An open-source bootloader, allowing us to flash and boot custom software; ii) A temporary, open 3.18.140 kernel with minimal patches, that gives the same functionality as stock with less vulnerabilities and the chance of debugging drivers while moving to 5.x. iii) Open userspace options, with or without blobs, giving varying degrees of functionality, based on Yocto 3.2, or postmarketOS. iv) Modem SDK which serves as a playground for anyone who wants to build his or her own firmware based on Yocto. v) Initial support from the postmarketOS team that allows to create flashable pmOS images for the modem.\nThe end goal has always been the same, to have the modem as open source as possible. We aren\u0026rsquo;t touching the modem\u0026rsquo;s ADSP firmware, because in addition to the inherent difficulties that come with it, modifying the ADSP firmware could lead to problems with RF regulations or certifications.\nPineTime [by JF] January was a prolific month for InfiniTime: we released no less than 3 versions of InfiniTime in this short period of time. The biggest release was InfiniTime 0.11, which came with 2 major features - the long awaited integration of the heart rate sensor and a brand new navigation application from Adam.\nWhy did it take so long to integrate the heart rate sensor in InfiniTime? Well, in fact, I implemented a working demo of the HR sensor more than 6 months ago but couldn\u0026rsquo;t release it because it was based on a non-free/proprietary library. This library implements the algorithm that converts raw data coming from the sensor into human readable values (beat per minute).\nFrom the beginning of the InfiniTime project, I always wanted it to be fully open-source. That\u0026rsquo;s the reason why I chose the GPLv3 license for InfiniTime. One of the implications of this choice is that we cannot include non-free/closed source modules into the codebase. This heart rate processing library was then conflicting with the license of the project and one of its main values.\nBut still, many people were asking for the heart rate sensor in InfiniTime, and fortunately, Daniel from WaspOS implemented a brand new algorithm for WaspOS and released it under the LGPL license, which allowed me to port his code in C++ and integrate it into InfiniTime. Thanks again to Daniel for his amazing work!\nHeart rate measuring in-app (left) and displayed on watchface (right)\nI teased the Navigation app in the last community update. I\u0026rsquo;m happy to announce that it\u0026rsquo;s now released! This app, written by Adam works in conjunction with Amazfish and PureMaps, and InfiniTime displays the navigation instructions from PureMaps when it\u0026rsquo;s connected to Amazfish. Best of all, these apps run on many Linux devices, such as the Pinebook Pro and the Pinephone!\nSee the video here.\nNavigation instructions displayed on the PineTime\nSpeaking of Amazfish, Adam has also improved the integration in non-SailfishOS Linux distributions like ManjaroARM and Ubuntu.\nThe BLE connectivity has been greatly improved in InfiniTime 0.12 by updating NimBLE, the open source BLE stack integrated in InfiniTime. With this upgrade, you should expect less failed OTA and less unexpected disconnections from the companion app.\nThis month, I would also like to highlight Nico\u0026rsquo;s blog. In his blog, Nicolas writes about SailfishOS, smartwatches and\u0026hellip; the PineTime! The first article is an overview of PineTime with SailfishOS. In a second article, Nico explains how to upgrade InfiniTime using Amazfish on SailfishOS. Finally, he reviewed InfiniTime 0.11 and 0.12 in this 3rd article. I really appreciate these blog posts, they are short, easy to read and give honest and accurate opinions about the progress of the project.\nRISC-V PINE64 Single Board Computer(s) It will probably come as no surprise to anyone following our project that we\u0026rsquo;ve been watching the RISC-V space very closely in the past 18 months. Many of you correctly concluded that the Pinecil, our recently released and very popular RISC-V soldering iron, was our first foray into the world of RISC-V SoCs. Indeed, the choice of the RISC-V SoC for the Pinecil was not mere coincidence. That said, Pincil’s SoC is rather rudimentary and incapable of running an advanced operating system such as Linux. We’re now at a point where we’re willing, and indeed keen, to dip our toes in the RISC-V pond and build our first single board computer capable of running full-blown Linux (and possibly also other FOSS operating systems). I’m not sure about you, but we’re rather excited about the prospect of this decision and its importance moving forward. While we’re not quite ready to talk about the specifics of the SBC at this point in time, in part because many PCB-design decisions haven’t been set in stone yet, I do nonetheless want to give you a general sense of the sort of hardware that we’ll be delivering. Our first SBC will feature two RISC-V CPUs, the main one being a C906 64-bit SoC coupled with an auxiliary 32bit BL602 SoC for WiFi and BLE. The C906 is already capable of running Linux and, from what I understand, is completely open while the BL602 is in the process of being open sourced (including firmware) in our Nutcracker community challenge. The SoC has solid I/O, including USB 2.0 and Gigabit Ethernet, and I see it as a great entry-level Linux-capable RISC-V platform.\nThe C906 feature list for those very tech savvy of you\nI am making the specifications known well ahead of time to manage your expectations. The overarching idea behind this board is to make an inexpensive board, accessible to all who wish to explore the RISC-V architecture, and to get it into the hands of as many people as possible. We’re aiming at a sub-$15 price point. We also want it to become a gateway to more powerful RISC-V SoCs in the future. While it\u0026rsquo;s our first entry into the world of this particular architecture, it most surely isn’t our last. The board will allow you to create fun IoT, learning and DIY projects, but I won’t be surprised to see someone make Doom, Sonic the Hedgehog or MarioKart run on it in a matter of weeks. In a month or two, I\u0026rsquo;ll share more details concerning the board-design and the exposed IO. Lastly, as you noticed already I haven’t mentioned the name of the SBC - you can expect a riddle in the coming weeks.\nLoRa and LoRaWAN PINE64 Ecosystem Integration In the past 6 months I’ve mentioned LoRa and LoRaWAN on many occasions and in multiple posts. If it wasn’t clear until now, we have been quite interested in the technology and its potential for novel applications. After extensive internal considerations, we now feel ready to double-down and make LoRa an integral part of the PINE64 ecosystem. I’ll explain a bit more about the core premises of our vision further down in this section, but let me start by writing about the actual equipment we’re planning to deliver. For one, we will offer next generation modules for all our devices - this includes, but is not limited to, the PinePhone, the PineTab and Pinebook Pro. We will be using next generation LoRa chipsets in our expansion modules, which deliver better performance while consuming less power. We will simultaneously introduce LoRa modules for North America, Asia and Europe, that conform to the respective regional regulations. We will also build our own LoRaWAN base station, which too will utilize next generation LoRa technology. This chipset does not only allow for higher efficiency and lower power consumption, but also for an improved data-transfer rate when compared to presently available technology. We intend to introduce two versions of our base station, the first of which is intended for deployment indoors, while the second arrives enclosed inside an aluminum waterproof container for use outdoors. The theoretical range of the base station is measured in tens of km’s, at least in unobstructed line of sight. That said, a range of 5-6km is much more realistic in most scenarios due to terrain and other obstructions found in urban areas. As you have come to expect from us, the brains of the base-station will be running FOSS software atop of mainline Linux.\nWe aren\u0026rsquo;t the first ones to think of using LoRa for communication - source\nSo, then, why are we doubling-down on this? While LoRaWAN is usually used for a variety of IoT type deployments, we wish to use it for text-based communications. In its implementation we expect the functionality to be more akin to HAM radio rather than SMS or instant messaging. Most importantly of all, however, we see LoRaWAN as a means for communication without a middleman. To allow communication over vast distances, each base station can be connected to the internet. We hope that, in time, urban areas will see some degree of coverage and that people will be willing to join in on the fun. And yes, in the initial phase of this experiment, the purpose of LoRaWAN stations is to have a bit of fun, whilst simultaneously exploring the limits of the technology’s application for communication. Needless to say, getting developers onboard to support this novel implementation of the technology will prove crucial. Over the next months I’ll do my best to convince relevant parties that it makes sense to explore this LoRaWAN application and that it may be a first step in rethinking secure communication mediums.\nThat is all for now, I’ll catch you all in a month!\n","permalink":"/2021/02/15/february-update-show-and-tell/","tags":["pine64","pinebook-pro","pinephone","quartz64","risc-v"],"title":"February Update: Show and Tell"},{"categories":null,"contents":" Download audio\nIn the second episode of the PineTalk Ezra and Peter talk about to Dalton Durst, Development Manager at UBports, about Ubuntu Touch in general and on the PinePhone more specifically. They also discuss the announcment of the \u0026lsquo;End of Community Editions\u0026rsquo; and answer awesome community questions.\nWhat have we been up to lately? Ezra: Elatronion: YouTube, Odysee Usergames (YouTube) Peter: LINMOBapps: https://linmobapps.frama.io Peter’s blog: https://linmob.net Topics Interview with Dalton Durst (Development manager at UBports) Dalton Durst is the Development Manager of the UBports project, which picked up Ubuntu Touch when Canonical decided to discontinue it. Context: Canonicals announcement to discontinue Unity 8 development (and thus Ubuntu for Devices/Ubuntu Touch) PinePhone Prototypes and related hardware: Project Anakin Project Don’t be evil Airmouse How to help: Translations: https://docs.ubports.com/en/latest/ Contribution Section: https://docs.ubports.com/en/latest/contribute/index.html How can people get in touch: @UTonPine Telegram See also \u0026ldquo;Get help\u0026rdquo; section on the PinePhone device page PINE64 Community News PINE64: The End of Community Editions LinuxSmartphones: PinePhone Modem Firmware news New Products (if any) PINEPHONE FLEX BREAK-OUT BOARD PINEPHONE microSD EXTENDER Your feedback and questions Due to time contraints, we could only tackle a few of your questions - please keep them coming. We might answer your question in the next episode!\nOrli on the future of Linux Phones Odineee: On the impact of NVidia’s purchase of ARM on PINE64 and about future Risc-V products The Podcast is in progress of being listed in all the directories you suggested - unfortunately it’s really hard to get that done with some directories, which is why we can’t report full success yet.\nThis episode also features chapter markers, a feature that allows you to skip topics you are not that interested in.\nRemember: This is a community podcast, so please leave feedback on what we should do better, get your suggestion’s in and feel free to ask questions!\nYou can join the Discord channel \u0026ldquo;Pinetalk-Podcast\u0026rdquo; on PINE64’s discord, you can send us an email at pinetalk@pine64.org and tweet at us, we’re @talkpine.\nThank you to NerdZoom Media for being our audio producers!\n","permalink":"/podcast/s01e02/","tags":null,"title":"S01E02: New Accessories and UBports with Dalton Durst"},{"categories":["community","pinephone"],"contents":"\nToday marks the end of the PinePhone Community Edition scheme. On behalf of myself, the Pine Store crew and the entire PINE64 community I\u0026rsquo;d like to thank the UBports Foundation, the postmarketOS project, Manjaro Linux, KDE e.V as well as the Mobian project for participating in bringing the PinePhone to tens of thousands of FOSS enthusiasts worldwide. We literally couldn\u0026rsquo;t have done it without you.\nWe are also grateful to all those who believed in our vision of a Linux smartphone and purchased a Community Edition PinePhone. Over the course of the last year we - all of us - propelled mobile Linux development forward to new heights and proved that a real Linux smartphone is not only possible but also viable if done right.\nFrom the very start, the main goal of the PinePhone was to provide an affordable, open source and development-friendly platform, which would be accessible to all. A platform that would allow users to experiment with, and contribute to, the plethora of existing OSes, and for developers to build their operating systems on a native Linux platform. But the PinePhone was also meant to show our commitment to the future of Linux on mobile by promoting established Linux on mobile projects, while fostering new ideas and financially supporting our software partners.\nAlthough this is the end of the Community Edition scheme, it is just the beginning for the PinePhone as a project. Over the next 12 months you\u0026rsquo;ll see many exciting developments concerning the PinePhone as a platform. Hardware-wise, we believe that the keyboard add-on, alongside an array of planned back-covers that enable additional functionality, will change how people interact with and think about mainline Linux smartphones. As for software - it won\u0026rsquo;t be long before an OS worthy of being your daily driver becomes ready.\nI\u0026rsquo;d like to end this blog entry by letting you all know that a very small number of Mobian Community Edition PinePhones is still available in the Pine Store at the time of writing. I also expect that a handful of PinePhones will become available at the end of February from cancelled orders or failed transactions, so you\u0026rsquo;ll have a last chance to pick one up later this month.\nIn the upcoming community update I\u0026rsquo;ll be discussing our plans for a default PinePhone operating system as well as the PinePhone\u0026rsquo;s immediate future, so make sure to subscribe to the blog and follow the Telegram News channel to be notified of the post. [edit February 3] A number of KDE Community Edition PinePhones from cancelled orders or failed transactions is now available in the Pine Store.\nOnce again, I wish to thank all of those who were a part of the PinePhone Community Edition scheme - I feel we collectively made a difference to furthering the Linux on mobile cause.\n","permalink":"/2021/02/02/the-end-of-community-editions/","tags":["pinephone"],"title":"The end of Community Editions"},{"categories":null,"contents":" Download audio\nIn this introductory episode of the PineTalk, Ezra and Peter talk about how they got started with computers, PINE64 and FOSS in general.\nWhich PINE64 devices are most interesting to the hosts, how did the PinePhone grab their attention and what do they think about the upcoming Quartz64 SBC?\n","permalink":"/podcast/s01e01/","tags":null,"title":"S01E01: Introduction"},{"categories":["pinephone"],"contents":"\nMobian Community Edition (CE) PinePhones are now available for pre-order in the Pine Store. This edition of the PinePhone ships with Mobian, a Debian-based Linux distribution tailored to run on smartphones. The project came to life on our platform and has now grown to become one of the community favorites. To learn more about the Mobian please visit the project’s website. To better understand the state of the software and what to expect when you get your unit, I encourage you to read the development team’s blog post on this subject matter. This community edition will ship in a custom presentation box designed by Mobian’s team, and the PinePhone itself will feature a Debian swirl logo on the back-cover (see renders for reference).\nThis PinePhone CE will be available in two hardware configurations:\n$149 — 2GB RAM; 16GB eMMC $199 — 3GB RAM; 32GB eMMC (includes a bundled USB-C dock) Both configurations of the Mobian CE PinePhones feature rev. 1.2b of the PCBA. The $199 hardware variant, called convergence package, also includes a USB-C dock equipped with 10/100 Ethernet, 2x USB type A ports, HDMI digital video output and power-in via USB-C.\nWe will donate $10 per unit sold to Mobian. To learn more about this scheme please click here.\nTo learn more about PinePhone Mobian CE please read the original announcement.\n","permalink":"/2021/01/17/mobian-community-edition/","tags":["pinephone"],"title":"Mobian Community Edition"},{"categories":["community","news","pine64-community","pinebook-pro","pinecil","pinephone"],"contents":"\nHappy New Year everyone! Let us all hope that the difficulties brought about by the COVID-19 virus are now waning and that more aspects of our lives will return to normal soon. We start this year with announcing the last community edition of the PinePhone, an update on the Quartz64 single board computers, and with some good news regarding PineTab and Pinebook Pro production. You can watch a synopsis of this month’s community update on Youtube (embedded below) but also on LBRY and Peertube. Stay up-to-date with PINE64 news and make sure to subscribe to this blog (bottom of the webpage), follow PINE64 Telegram News channel as well as our Twitter and Mastodon.\nI’d like to acknowledge JF, Marek (gamiee), Alex (clover), 33YN2 and PizzaLovingNerd for their contributions to this community update. Thank you.\nLet\u0026rsquo;s get to it.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video January Community Update Video Synopsis by PizzaLovingNerd\nTL:DR\nNew website it up! Chats have been reworked and IRC bridged back up; more work on chat infrastructure soon Thank you to those who’ve been making documentation for Wiki PinePhone KDE CE slightly delayed but shipping soon; issues shipping to the UK PineTalk podcast starts next month! Hosted by Ezra from Elatronion and Peter from LINMOBnet Pinebook Pro and PineTab LCD panel availability looking better; production to resume after CNY Pinebook Pro OpenMandriva and AOSC Linux builds are now available Pinebook Pro FreeBSD 13 build brinds a lot of functionality to the platform Pinebook Pro alt DP display mode available in Manjaro \u0026amp; coming to other distros. Enables DockingDeck and other USB-C dongles Pinebook Pro to get Panfrost GPU driver with OpenGL 3.0 Quartz64 is the name of our next SBC line Quartz64 model-A detailed spec and availability roadmap PineTime important work done on the bootloader and release of InfiniTime 0.10.0 PineTime InfiniTime fork brings colourful icons, multiple watchfaces and additional functionality (HR + step count) PineTime GPS navigation via Amazfish App; Amazefish app has now been ported to Manjaro Linux for the PinePhone PineTime WaspOS improvements including theme engine and much more PinePhone Mobian CE available on January 18. Two hardware configurations 2GB RAM/ 16GB eMMC \u0026amp; 3GB RAM/ 32GB eMMC + USB-C dock (Convergence Package) PinePhone’s modem runs kernel 5.10; first step in open-sourcing PinePhone keyboard update and keyboard layout; projected availability April this year PinePhone major improvements to KDE Plasma Mobile improvements PinePhone - a new OS join the pack; OpenMandriva is now available for the PinePhone Pinecil - new firmware is available; Pinecil gets a dedicated update utility Pinecil - a red shell version available exclusively in China; you can get the red shell for your Pinecil from the Pine Store Pinecil - next production batch before CNY PinePower - desktop PinePower details and availability; addressing generic design PineCube - software updates and first attempts at streaming video Housekeeping As I’m sure you’ve already noticed, we’ve got a new website. Let me start by thanking Marek (gamiee), Lucia Zverkova, Chris (Funeral) for getting the page into shipshape for today. Getting it done in time over the holidays was a sprint, but the final result is a page that will serve us well for many moons to come. If you find any typos or broken links, make sure to report them to us - thanks. Over the holidays we also completed work on the chat protocol bridge. It is my understanding that all issues concerning the transfer of messages from one protocol to another should now be resolved. However, the entire chat infrastructure will see further alterations in the coming weeks, as developers requested a higher granularity of conversation options. More specifically, we’ll create separate chats for development, so that end-user support questions and general conversation don’t get in the way of dev chat. A dev-chat for PineTime has already been set up and will be bridged to other platforms shortly. More device-specific dev chats will follow shortly. I also want to take this opportunity to thank everyone who did their share in tidying up, editing information and adding resources to the Wiki in the past few weeks. Documentation is a vital part of any open source project, and I am very pleased to see many people now actively contributing to the maintenance of existing development resources. The Wiki really looks nice and tidy now\nPinePhone KDE Community Edition should start shipping shortly following a two week delay due to a component shortage. This means most of you who pre-ordered a unit should receive your smartphone at the end of this month. That said, we’re facing issues with delivering the PinePhone to the United Kingdom following Brexit. If you live in the United Kingdom and have pre-ordered a PinePhone KDE CE make sure to check your email - we have given you two options to resolve the situation, which we’ll need you to act on now. We apologize for the inconvenience.\nPineTalk Podcast Logo\nLastly, I am happy to announce that Ezra from Elatronion and Peter from LINMOBnet will be hosting the PineTalk - a PINE64 podcast by community members for the community. Episodes of the podcast will be available bi-weekly - as in, available every other week - and will be available on Youtube, Peertube, LBRY, Spotify and Apple Podcasts. Peter and Ezra are working out the details at this time, but you can expect the first episode to drop sometime in February. Make sure to check out the PineTalk page for more details. Pinebook Pro I finally have some good news to report concerning Pinebook Pro and PineTab availability. LCD availability is looking better now, and that means we’re confident that both the Pinebook Pro and PineTab will be back in store shortly after the Chinese New Year. That said, LCD prices are currently very high. Because we have always avoided increasing the price point of PINE64 devices, we will do our best to avoid a Pinebook Pro/PineTab price point increase. However, if the choice is between no stock or a slightly higher price point, the latter may be the only way out. This will likely not happen, but I want people to be aware of some choices that might be made down the line. I do not have a specific date for when the production will resume at this point in time, but I’m sure the situation will crystallize over the coming weeks. I’d like to put the spotlight on a few Pinebook Pro releases. For starters, we’re happy to announce OpenMandriva Lx 4.2, a Linux distribution using the package manager urpmi which installs .rpm binaries. This will be available for download shortly from the project’s sourceforge repository. It ships with KDE Plasma desktop environment and offers a wide range of default apps to get you going. Please visit OpenMandriva’s website for more information about the distribution. See FreeBSD on the Pinebook Pro via SleepWalker on Twitter\nI am also certain that many of you who have been waiting for a new FreeBSD OS image for the Pinebook Pro will be thrilled to hear that a recently released preview image (FreeBSD 13) fixes a keyboard issue that plagued the system on the Pinebook Pro. My knowledge about FreeBSD is highly limited, so rather than me trying to convey the current state of development I strongly suggest you read through the thread on FreeBSD’s forum prior to downloading the image. From what I gathered, the thread includes instructions on enabling audio and enabling external networking cards. The first entry in the thread includes the download link. Lastly, I’d like to bring everyone’s attention to AOSC Linux, a Debian-based distribution that supports most PINE64 single board computers and devices, including the Pinebook Pro. The reason I wish to highlight this distribution is the wide range of default desktops it offers for the Pinebook Pro, including but not limited to GNOME, Cinnamon, MATE and XFCE. Needless to say, the OS images are mainline and run open GPU drivers, just like the default Manjaro KDE image. I have actually spent some time with the Cinnamon edition of the AOSC build, and I am happy to report that it is snappy and I experienced no apparent issues. You will find the complete list of OS images featuring the various desktops in the AOSC download section on their website. AOSC on the Pinebook Pro via PizzaLovingNerd\nEnding this section of the update I’d like to notify you of two other important developments related to the Pinebook Pro. Firstly, USB-C alt DP mode has now been merged in Manjaro’s default OS image for the Pinebook Pro. This means that the Docking Deck and other USB-C docking stations and dongles should now output video, at resolution up to 4K, via USB-C. So if you’re running Manjaro KDE on the stable branch, all you need to do is upgrade your installation via terminal or the GUI package manager. If you want to try Manjaro KDE, then you’ll find up-to-date builds here. The last thing which I find worthy of reporting is that OpenGL 3.0 will be enabled on the open source Panfrost GPU driver used by most OS distributions on the Pinebook Pro. It will obviously take some time before these patches find their way into every single distribution, but you can rest assured that OpenGL 3.0 will be available on your distribution of choice in the foreseeable future.\nQuartz64 Let me start by congratulating Sundog on being the first to correctly solve the riddle I uploaded last month. He correctly deciphered that “Quartz64” will be the name of our next line of single board computers. It took him just a few minutes from the moment I posted the riddle to submit the correct answers, which tells me I need to step up my game and create more complex riddles in the future. Sundog will be receiving the first production board once those are ready. For those of you who want to learn more about PINE64 products riddles, I opened a thread on the forum to discuss the topic at length. Still can\u0026rsquo;t believe how quickly this riddle was solved\nBack to the subject on hand; Quartz64 will be the first RK3566 board on the market, and the model-A prototype of the board is already being evaluated internally. We aren’t quite ready to show it off just yet, as there are some design decisions which may need reworking before it gets shipped to devs, but we promise that the reveal is coming soon. We do, however, have some information to share - please keep in mind that all the following refers specifically to the model-A Quartz64. The board will be available in two configurations, more specifically a 4GB and 8GB RAM variant. You will be able to fit the model-A Quartz64 with one of the heatsinks designed for the ROCKPRo64, as both single board computers share both the footprint as well as IO layout. The board will feature multiple USB 3.0 and a USB-C ports, as well as: 4x PCIe, eDP and MIPI display output options alongside a standard GPIO header you’d come to expect. Some of you will surely be excited to learn that the Quartz64 model-A will also feature a dedicated e-ink panel interface capable of supporting a capacitive pen. We will have a 10” e-ink display available in the Pine Store at the time the Quartz64 boards launch. Let me say a few words about the roadmap; at present time we aim to have a limited run of both model-A and model-B versions of Quartz64 in a matter of weeks, so that developers can get their hands on the board and start the bringing-up process sometime after the Chinese New Year. We expect that both versions of the Quartz64 will be available more broadly to developers sometime in late Q1 or early Q2 2021. We are also working on a system to fast-track established developers to get their hands on a Quartz64 board. I suspect that, in short, developers interested in getting their hands on the Quartz64 SBCs early will be asked to send an application email similar to the process for acquiring PinePhone development units in November 2019. PineTime (by JF and 33YN2) In December I finally got some time to work on the bootloader. The bootloader is the first piece of the software that is run on PineTime as it boots. It is responsible for loading the application firmware (InfiniTime, for example) and also safely applying upgrades, once the OTA update transfer is finished. The current version of the bootloader was written mainly by Lup Yuen Lee. Lup is also the one who hand drew the greenish PineTime logo you see when the bootloader is running. Since last September, we also detected and fixed a few bugs and wanted to add a few additional functionality, such as recovery firmware and a more refined user interface.\nVideo of the upgrading process on JF\u0026rsquo;s PeerTube\nAs this is the most critical part of the software, we requested the help of the community to test it, and received a lot of positive feedback and reports of successful upgrades of the bootloader, which is very promising!\nEarlier this month I also released version 0.10.0 of InfiniTime. This is a special release because it is mainly composed of contributions from other developers. Additions which will be most apparent to end users are the 2 games which have been added: Paddle, a solo Pong game, and Two, a 2048 clone.\n2048 clone via JF on Twitter\nRecently, a new fork of InfiniTime appeared on GitHub. This fork, named JoaqTime by the chat community, created by joaquimorg includes a complete overhaul of the UI, which includes nice and colorful icons, multiple watchface, a step counter as well as a functional heart rate monitor. https://www.youtube.com/watch?v=TiiajWmhpfQ\nA video of \u0026ldquo;JoaqTime\u0026rdquo; in action\nWaspOS has been on a roll, having many new commits in the past few weeks. A major change is the new theming engine, which has been added to WaspOS recently, allowing you to change the colors of the different components of the UI to your liking. Moreover, something many of you will enjoy is the addition of a software toggle in the menu that lets you dynamically disable/enable applications which could make development much easier. You will also find the two new applications; a haptic alarm application, and a calculator application, which are quite the addition. Expect much more on the horizon with WaspOS, as for example there has been discussion about optimizing the display rendering for a smoother experience.\nhttps://www.youtube.com/watch?v=nps8Kd2qPzs\nShowcase of WaspOS features on the PineTime\nIn last month\u0026rsquo;s update, we talked about Amazfish, and announced that Adam has been working on making Amazfish easily portable on other Linux distros and devices. This is now done with Amazfish 1.8.5, and I really hope we\u0026rsquo;ll see Amazfish built and packaged for many Linux distro in the near future. Indeed, it has already landed in Manjaro, and will likely appear in some of the most popular PinePhone distributions in a matter of weeks. Adam did not stop there, however, and is now working on a navigation app for the PineTime, based on Amazfish and PureMaps. Here\u0026rsquo;s a picture of navigation working. PinePhone We’ve thrilled to announce that the last PinePhone Community Edition will feature the Mobian Project. Mobian is a Debian distribution tailored to work on smartphones which came into life on our platform, and has now grown to become one of the community favorites. The operating system ships with the Phosh user interface and a mainline Linux kernel with the necessary patches. This edition of the PinePhone supports all core functionality, including phone calls, 4G LTE, WiFi and Bluetooth, deep-sleep suspend state, both cameras as well as GPS. The convergence feature, which turns the PinePhone into a pocketable computer when a monitor, mouse and keyboard are connected via USB-C dongle, also works great on this distro. Lastly, it features an on-device installer, allowing you to determine your username and password, as well as the option to encrypt your installation. PinePhone running Mobian in convergence mode via LINMOB on Twitter\nDespite the relatively high level of software maturity, the shipped build should be considered pre-release grade software, with known bugs and issues. In other words, this is still very much a work-in-progress. By the time you receive your Mobian CE PinePhone a long time will have passed since the phone left the factory floor, and many improvements will have been made to the system. Make sure to update your PinePhone the moment you receive it. Pre-orders for the Mobian Community Edition PinePhone will open in three days time, on January 18, 2021. This community edition of the PinePhone will be available in two hardware configurations: $149 – 2GB RAM + 16GB eMMC\n$199 – 3GB RAM + 32GB eMMC Convergence Package with an included USB-C dock\nYou can expect a blog post entry on the day this community edition goes live, followed by information on Twitter, Mastodon, our Telegram News Channel, the PINE64 forum and elsewhere. As was the case with all previous community editions, we will be donating $10 per unit sold to the Mobian project, to support development of mobile Linux on all platforms. Now head over to Mobian’s blog and read what they’ve got to say about the state of their operating system and development for the PinePhone. I’d like to thank all projects who participated in the community edition scheme: UBports Foundation, postmarketOS, Manjaro Linux, KDE Community and the Mobian Project. Thanks to your efforts we’ve managed to breathe new life into the dream of Linux on mobile and started something completely extraordinary. We’ve on track to ship a staggering number of PinePhones, and fully appreciate that the success of the PinePhone is as much yours as it is ours. Congratulations on a job well done! For a change, I will start with discussing software news this month. There is much to write about since important progress has been made in the past 30 days, but the most important development of all (at least in my view) is that the PinePhone’s modem is now capable of running mainline Linux. Thanks to work by Biktor and Konrad Dybcio the first step in opening up the modem has begun. I spoke to Konrad, who asked me to emphasize that presently this is very much a proof of concept, but that an effort is being made to have a community-built mainline Linux which will equal the modem’s proprietary firmware in terms of functionality. This means that users will, eventually, be able to replace the modem’s firmware with a community-built one on their own. Be aware, it is unlikely that we’ll be able to ship it on the device due to various legal constraints. Some parts of the modem, such as DSP firmware, will most likely have to remain closed. Regardless, these implications are obviously massive. At the time of writing this, you can install an operating system, such as postmarketOS, on the modem and even run a Minecraft server on it! The news of the modem running mainline kernel made quite the splash\nWe also saw a new OS release for the PinePhone this month - OpenMandriva Lx 4.2 is now available for download. The OS uses a package manager called urpmi, which makes it easy to install .rpm binaries on your system. It ships with a slightly older build of KDE Plasma Mobile on kernel 5.10. I have not had an opportunity to test it myself, but it is my understanding that all core functionality found on other Plasma Mobile OS builds is also functional in OpenMandriva Lx. The release candidate image is now available for download from the project’s sourceforge repository. OpenMandriva LX 4.2 running on the PinePhone by 33YN2\nOn the subject of Plasma Mobile, we’ve seen a lot of developments of this particular user interface in the past weeks. The team behind Plasma Mobile lists all the user experience improvements in a dedicated blog post (which I highly suggest you read), so I will not reiterate platform-agnostic changes here but rather focus on PinePhone-specific improvements. Aside from the quality-of-life and usability improvements, the most important change is responsiveness. While it may not be instantly apparent at the desktop, a significant performance boost can be felt in all default applications. This includes browsing using Angelfish browser, the Discover store and, in more general, when scrolling through long lists or pages. I’ve been testing this Plasma Mobile extensively recently and it\u0026rsquo;s been a great experience all-around; even convergence now works as expected with my monitor, although I’ve heard reports that others still experience issues. If you haven’t tried Plasma Mobile in recent months, I strongly suggest you give it another go. You can download the newest Manjaro KDE development images by clicking here. https://www.youtube.com/watch?v=qkOVWh6WDww\nPerformance of KDE Plasma Mobile has been significantly improved recently - by Bhushan from Plasma Mobile team (original video on Twitter)\nBefore moving onto hardware, I also need to let you know about the excellent new Manjaro OS images with Lomiri. The Manjaro team, in cooperation with Marius Gripsgard from UBports, have released the next preview OS image, with many more functional elements as well as support for traditional X11 applications! This Lomiri UI is certainly one of the most polished experiences for the PinePhone and the new additions of GPS navigation, GPU accelerated browser, functional Bluetooth (just to name a few) on Manjaro as a base make for a compelling experience. Just yesterday Dalton Durst from UBports also announced the release of a new Ubuntu Touch RC update for the Pinephone that fixes automatic 3G call switching.\nIn terms of hardware, we’re well on our way to build the keyboard prototype. We’re currently exploring and prototyping options for including a large battery into the body of the keyboard. In short, we’re working on squeezing in as large of a battery as possible into the keyboard body. We have also finally been given a time-frame for delivery from the design-house and factory; as things stand today, the PinePhone keyboard should be available in April this year. As most of you already know, the keyboard will interface with the PinePhone using the pogo pins, which means that it will attach and replace the back case. We realized that this will be cumbersome to remove and insert SD cards, so we’ve sourced a breakout board for SD cards that will make the task easier with the keyboard attached. For the time being, I leave you with render of the keys and a suggested keyboard layout. Please let us know what you think in the comments section. Picture of the key layout (top) and render of the keys (bottom) on the PinePhone keyboard\nClosing off this section, we’ve made the decision to alter the design of the Qi charging case so that it will also be able to accommodate the fingerprint reader. Rather than making two separate back-cases - one for the fingerprint reader and another for the Qi coil, we will spare money and time creating a single mold to host both. Now, I am aware that some people will only want one and not the other additional piece of functionality, so we’re exploring a way to give you an option to choose. Regardless, working this out will take a little time. Hold tight - more information is coming in the next two months. Pinecil For Pinecil news, we have new firmware available for the Pinecil. Instructions for flashing the new firmware is available on the Pine64 Wiki page. We also now have a new red Pinecil case available in the Pine64 store for $6. The reception from early adopters has been very good, as have reviews from sites such as Hackaday, and we opened a second production run on January 6th although this second run has already sold out. This was a large production-run, and we were not prepared for it to sell out quite as quickly. As a result we’re in the process of producing an even larger production run of the Pinecil, which should be available for purchase in early February. Picture of the Pinecil update utility by Gamiee\nFor those of you who already got a Pinecil, you can now update your firmware to the newest iteration of IronOS. The newest firmware brings multiple bug fixes over the firmware which shipped from the factory, so we highly recommend you upgrade. The process of upgrading is straightforward and has been outlined on our Wiki. Moreover, thanks for the work by Marek (gamiee) the Pinecil now has its own firmware update utility, which even features multiple language options. Pretty nifty! Pinecil Chinese special edition\nWe also announced that we’ll have an exclusive version of the Pinecil for the Chinese market. The body and packaging on this version of the Pincil are red, but otherwise no different in form of function to the Pinecil available in the West. We do realise, however, that people like to tinker and personalize all their electronics, including their soldering irons, so we’re making the red shell available for everyone to buy in the Pine Store. I am including a video by Peter Feerick - a PINE64 old-timer and a professional kangaroo wrangler - in which he swaps out the Pinecil shell for the red one. https://www.youtube.com/watch?v=QXSRw1YoMSI\nPeter exchanges the default black Pinecil shell for a red one\nLastly, the break-out board is also available for purchase in the Pine Store alongside the default black shell, a small and portable stand as well as the two tip sets. Since many of you asked, we’ve also added some high-quality USB-C to USB-C cables to the store; those can be found in the Makespace section of the Pine Store, alongside the PinePower PSUs. PinePower Both the portable and desktop PinePower power supplies are now in the Pine Store. I’ve described the portable PinePower extensively in last month\u0026rsquo;s update, so this month I’ll instead focus on the desktop power supply. We made the decision that the desktop PinePower will also include Qi wireless charging, since some may wish to use that for their PinePhone in the future. The desktop PinePower contains two 65W switching power supplies, one of which serves USB-C power delivery port while the other delivers power to the 18W QC3.0 USB-A port, 3 individual 5V 3A USB-A ports as well as 10W wireless QI charging. In other words, it is capable of delivering power to all your PINE64 devices, and even capable of powering the Pinecil while charging the Pinebook Pro, PinePhone and the PineTab simultaneously. PinePower front view showing output values\nLet me also address comments that I’ve seen online inquiring whether we used existing power supply unit designs. Indeed, as I wrote last month “both PSUs are based on reference designs, but we have made significant improvements to the internals so they are more performant than existing offerings”. Despite both designs being generic, the PSUs have had improvements made to their performance and undergone certification. For instance, the generic design experiences a component failure after 2 hours of sustained full load; we’ve made significant adjustments to this PSU, and it can sustain a full load for over 12hours, based on lab testing. PineCube (by 33YN2) For the PineCube there has been some progress in the form of a new Community-made Armbian build available which has the Motion daemon preinstalled. Further, a community member has said that they were able to get Motioneye to run on the board at 1-2 FPS. While that low of a framerate is perhaps disappointing, motioneye is a heavy software. There will likely be more luck in regards to something lighter such as Moonfire-NVR or a PineCube-specific software solution that likewise can better leverage the hardware. Last thing regarding the PineCube which is small, but nevertheless interesting is that there is now wiki documentation on how to interface with it using an Arduino Uno (And other Single Board Microcontrollers) as the USB serial connection. Seeing as the Pinecone is simply a Risc-V microcontroller board, it is likely that a PineCone could also be used as a serial interface by jumping the ground and reset pins exactly like you would on an Arduino to isolate the microcontroller.\nPineCube connected to Arduino by 33YN2\nThat\u0026rsquo;s all for this month! I\u0026rsquo;ll catch you all online.\n","permalink":"/2021/01/15/january-update-happy-new-gear/","tags":["community-edition","pinebook-pro","pinecil","pinecube","pinephone","pinetime"],"title":"January Update: Happy New Gear!"},{"categories":["community"],"contents":"The riddle has been solved and we\u0026rsquo;ll be contacting the winner in the coming days. The comments section has now been locked until January. Thank you to everyone who played along!\nThe correct answer is: QUARTZ64\nIn the event you\u0026rsquo;re interested, you can learn more about the riddle here.\nIn the November Community Update I promised you a riddle concerning the naming of our upcoming range of RK3566 Single Board Computers.\nThe person to solve the riddle first will receive the first board straight from the production line. Leave your guess in the comments section.\nIf no one guesses correctly by then Monday, December 21, when the blog comments will get turned off due to the website being overhauled, then we\u0026rsquo;ll continue this community challenge on the forums. I\u0026rsquo;ll edit this post with a forum link if need be.\nGood luck!\nWistyx\nBetween a Pine and a Rock\nMy origins are to be found\nHeritage of the sun and sand\nLocked in cogs circle round\nNow here alone I stand\nIt all makes sense\nShifted one to the right\nLook down and ahead\nIn your line of sight\nThe solution can be read\n","permalink":"/2020/12/18/i-owe-you-a-riddle/","tags":null,"title":"I owe you a riddle"},{"categories":["community","cube","news","pine64-community","pinebook-pro","pinecil","pinephone","pinetime"],"contents":"\nWelcome to the last community update of the year. I want to start this month’s update by thanking everyone who helped us make this challenging year a fruitful and successful one. A special thanks goes to the core community team - our mods and admins - who keep the cogs spinning on a daily basis. Marek (gamiee) and Matthew (fire219) have done an incredible job this year reworking our community-facing infrastructure; this is something which was long overdue and is now appreciated by tens of thousands of end-users. I also want to thank our partner projects - UBports, postmarketOS, Manjaro and KDE Community in particular - for working with us tirelessly to make the PinePhone, PineTab and Pinebook Pro a success. We literally couldn’t have done it without you. Special thanks also goes out to the independent contributors whose work continuously assists partner projects in building OSes for our platforms. Finally, I want to say thank you to the Pine64 community at large. We deeply appreciate you all for being the end-users who make this project thrive. I would be remiss not to acknowledge and thank the members of Pine Store’s logistics, sales and shipping teams who delivered tens of thousands of PinePhones and Pinebook Pros throughout 2020; this was no small feat I assure you.\nYou can watch a synopsis of this month’s community update on Youtube (embedded below) but also on LBRY and Peertube. To stay up-to-date with PINE64 news make sure to subscribe to this blog (footer at the bottom of the webpage), follow PINE64 Telegram News channel as well as our Twitter and Mastodon.\nI’d like to acknowledge JF, Marek (gamiee), Alex (clover) and PizzaLovingNerd for their contributions to this community update. Thank you.\nFrom all of us at PINE64, a very Merry Christmas and a Happy New Year to you all! Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Video synopsis of the Community Update by PizzaLovingNerd\nTL;DR for this month\u0026rsquo;s update\nRK3566 boards available to developers next month; more info in January Community page (.org) getting a make-over \u0026amp; chat bridge will be worked on over the holidays. An apology to early KDE CE pre-orders who received refunds and an explanation of what happened A word about retail stores coming early next year Look back at 2020 - our shortcomings and accomplishments discussed PineTime - classy analogue watch faces available for InfiniTime PineTime - InfiniTime receives many fixes including wake-up time, battery readout and call notifications PineTime - new WaspOS version has been released PineTime - Amazefish companion app now runs on multiple distros, including KDE Plasma Mobile; you can now sync your PineTime to the PinePhone running Manjaro KDE \u0026amp; more! Pinebook Pro - production resumes after Chinese New Year, late February/ early March 2021 Pinebook Pro - is now supported by official Debian Installer (Alpha 3) Pinebook Pro - the Docking Deck receives a warm response from end-users and reviewers PinePhone - software and firmware news: Megi’s 5.10 kernel and new firmware for the modem result in improved power management + thermals PinePhone - Megapixels camera app now supports smooth 30FPS viewfinder; works on multiple mobile UIs. PinePhone - We signed a contract for a PSION5-like keyboard with a specialized vendor(!); developers will receive keyboards already in January 2021 PinePhone - Qi charging back case entered production (molding process) PinePhone - We’re working on a fingerprint reader back case with a community member who created a working prototype PinePhone - showcase of awesome PinePhone hacks and DIY projects PinePower - a range of power supplies (PSUs) for PINE64 products coming soon PinePower - portable 65W GaN PSU due in late Jan/ early Feb and a 120W desktop PSU coming later in 2021 PineCube - we now have Armbian support (Debian \u0026amp; Ubuntu) for the PineCube PineCube - we created a case for the PineCube and released STL files for it Pinecil - initial batch sold out incredibly fast, more units are being produced for January 2021 Nutcracker Challenge - more evaluation boards shipped Nutcracker Challenge - we’re getting more source code soon \u0026amp; early community developed flashing tools now available Housekeeping Just before finishing up this community update I received word that our next generation of RK3566-based single board computers will be available to developers next month. In case you’ve missed it, I wrote about our future strategy and non-Pro devices in last month’s update. You can expect more information about these boards to follow in the January community update. Work will be carried out to the pine64.org community webpage over the coming holidays. This shouldn’t have an impact on the website\u0026rsquo;s functioning, but we will likely have to disable blog comments at some point in the next two weeks. Blog comments will be reenabled once the new site goes live. I am looking forward to hearing your feedback in January when the new page design is revealed. Farewell old friend!\nIn related community news, protocol chat bridge maintenance will begin soon. We will attempt to minimize chat room downtime, but a degree of disruption is unavoidable. The current bridge will need to come down and a new one will be erected in its place. In short, expect things to break. As for the time-frame, I don’t know if the process will take an hour or an entire day; regardless, on the day of maintenance a proactive outage warning will be posted on social media and the Telegram news channel.\nDue to a database software error earlier this month, we had to refund people who pre-ordered the KDE Community Edition PinePhone within the first 18 hours of orders going live. The error applied incorrect shipping charges at checkout and affected orders #159750 to #159962. We sincerely apologise for this mishap - if you have been affected, please re-order your PinePhone now. This will not affect when your PinePhone KDE CE ships.\nLastly, earlier this month we announced that we’ll be launching regional online retail stores in 2021. These online stores will offer a more traditional purchasing and support experience to the Pine Store, and are aimed at people who are less familiar with PINE64 as a project and Linux communities in general. The Pine Store isn’t going away, however, and neither are the community oriented price-points. To learn more about this topic please read the full blog entry. 2020 Retrospective I’ve chosen a handful of shortcomings and accomplishments of PINE64 as a project for us to look back at. Much has happened in the past 12 months, and since I only have 2 pages allocated for this topic, I had to be rather selective. Feel free to let me know in the comments if I’ve overlooked some key shortcoming or achievement. This was a difficult year for everyone, and when I write ‘everyone’ I literally mean that everyone has been affected by the COVID19 virus in some way. The pandemic brought much of the world to a complete standstill - indeed the production and the supply chain in China are still reeling from the virus outbreak. Much of the present component shortages and price hikes, such as those preventing us from producing the Pinebook Pro and PineTab, can be directly linked to the January - May period, when most factories were forced to close their doors for business. Moreover, the border crossings to Hong Kong - where our most popular devices such as the PinePhone ship from - remains closed, with an expected reopening date of April, 2021. Despite these massive production and logistic challenges, the Pine Store managed to continually ship devices in 2020. Tens of thousands of phones and laptops shipped via an exceptionally difficult logistic route to reach the end-users. All this is something I wish you keep in mind as I proceed to discuss the successes and shortcomings of this year. Shortcomings: At FOSDEM 2020 we announce a sizable number of devices to hit the Pine Store this year. While all the announced devices suffered a set-back, there was one particular one which unfortunately got axed. The HardRock64 (HR64) was meant to be small in size (B-type), have fewer I/O options and serve as a complimentary board to the RockPro64. Unfortunately, by the time we were able to start production of the HR64 the increase in component price, and introduction of competition’s hardware to the market, made the HR64 a much less interesting value proposition. Simultaneously, at this time we already began investigating future SoCs - a topic I touched upon in last month’s update. In result, the decision was made to scrap the HR64 and create an A-type and B-type board based on future architecture of SoCs instead. These new boards will be available to developers next month - something to keep in mind while mourning the HR64. Picture of the unreleased HardRock64 SBC\nDespite having received a positive reception, I sadly need to list the PineTab as our second shortcoming this year. In short, the device has suffered constant delays since its inception and only saw a limited production run this year. We are currently waiting for LCD and digitizer panels to become available to rectify this situation; hopefully a sizable batch will be produced following the Chinese New Year. We know you guys want it - more PineTabs will be available in 2021.\nThird on my list of shortcomings is our failure to deliver the OG Pinebook-to-Pinebook Pro-like upgrade kit. In the end we were never able to overcome thermal management issues with the RK3399 in the plastic enclosures of the 11.6” and 14” OG Pinebooks. It also turned out that flashing the keyboard firmware, allowing the chassis to seemingly work with the Pinebook Pro mainboard, sadly isn’t a completely straight-forward process. I personally tried a number of times and never got it to work. Following these obstacles we reallocated the available time to deal with other issues we faced this year. We may come back to this topic at some point in 2021, but I can no longer promise a pro-like upgrade kit will be available for the OG Pinebook. Sorry.\nOriginal Pinebook chassis fitted with a Pinebook Pro mainboard\nLastly, I want to address the shipping difficulties we encountered with the Braveheart and UBPorts CE PinePhone batches. Following COVID19 lockdown and the border closure between Hong Kong and mainland China, we had to establish a very complex logistic process to ship out battery operated devices. We chose to ship the first two editions of the PinePhone at the height of the pandemic, which led to significant shipping problems, and in turn gave rise to frustration among a portion of our end-user base. I still maintain we had no way of foreseeing all the difficulties we encountered, nor could we remedy the situation once the devices shipped; that said, I wish to once again apologize to those who had a bad experience with initial PinePhone shipments. Thankfully, since postmarketOS CE we’ve perfected the logistics process and acquired a transition warehouse in Europe, which effectively resolved all our problems.\nAccomplishments:\nAt the end of last year, I wrote that I foresee PINE64 transitioning in 2020 from a rather niche FOSS project to a more mainstream one. And indeed I think that this has happened. For one, we were invited to become Arm\u0026rsquo;s strategic ecosystem partner - a real distinction and privilege. Our community of active participants has more-than doubled in the past 12 months. In the PinePhone chat alone we have nearly 10k participants across the different protocols. But active participation is just one measure of the project\u0026rsquo;s growth, with the other important one being official software device support. The PinePhone and Pinebook Pro - arguably our flagship devices - are now supported by all major distributions and some notable *BSD systems. We are also regularly approached by new projects interested in shipping their OSes on our platforms. This is obviously of major benefit to our community and all those who are considering PINE64 devices for industrial applications or personal use. This transition from a niche tinkering project to a mainstream FOSS one is undoubtedly our biggest accompaniment this year.\nWe are Arm\u0026rsquo;s Ecosystem Partner\nThis year we made the decision to self-host all of our community-centred services and resources. The server move included the pine64.org community website, our IRC and Matrix chats, the PINE64 Wiki as well as the community forums. As many of you know, for this purpose we’ve built a massive RockPro64 cluster that is generously hosted at BBXNET’s server farm in the heart of Europe. Despite some teething problems, this has proven to be a major success for us and all the aforementioned services have been running problem-free for months now. Truth be told, we couldn’t be happier to dogfood our own hardware. As a side-note, to our knowledge we’re the only one’s relying on our own hardware to host the core infrastructure of the project; I trust this stands as a testimony to the work we and all our contributors do.\nThis website and all our community services are running on this cluster\nAt the end of last year I publicly asked about feedback regarding what you felt we did well and where we came up short in 2019. Two of the major gripes reported by our community were the Pine Store’s website (looks and functionality) and shipping options. This year we redid the Pine Store from the ground up. Not only does the new page look good, but it is also much more functional. Two of the functions that we managed to incorporate are shipping options and an Import Tax / VAT calculator. We already had some feedback regarding the store, and are actively working on getting more features ready. A store refresh was a much needed change - one which I believe most users are grateful for. The old Pine Store wasn\u0026rsquo;t exactly easy or pleasant to browse\nIt probably will come as no surprise that the PinePhone has proven to be a huge success for us. Not only have we managed to ship an astounding number of PinePhones this year, we also had the privilege to work with and support 4 well established smartphone Linux projects. We built a community platform, from the ground-up, for developers to cooperate and share resources. We’re really proud of this. Thanks to the PinePhone efforts we now have an unrivaled cooperation framework for future devices. The PinePhone wasn’t the only success story of the year - the Pinebook Pro and other auxiliary devices (e.g., the PineCube, the Docking Deck and the Pinecil) were met with a lot of enthusiasm and widespread interest. Despite the global pandemic this year, we’ve noted a significant increase in interest in our devices by people within, and outside of, the Linux community.\nFirst 3 of the 2020 Community Editions of the PinePhone\nThe last accomplishment I wish to outline here isn’t really ours to boast about - the PineTime. Truth be told, the PineTime has significantly surpassed and exceeded our expectations. It is a completely autonomous project, largely informed by JF, Daniel Thompson and Lup and their community’s work, which has now gained a lot of traction and established its own sub-community. We’re very impressed by how far the PineTime has come this year, and that it is almost at the brink of being a fully functional smartwatch, now capable of pairing with Android and Linux smartphones. This is a success story that belongs solely to the community which is backing the PineTime project - hats off. PineTime (By JF) As always, I\u0026rsquo;m thrilled to see the work done by the PineTime community! First, I would like to highlight the work done by Electr0Lyte, who designed the gorgeous and classy analog watch faces based on InfiniTime and wrote documentation about them. This is proof that it\u0026rsquo;s possible to design a nice and clear user interface even on low powered embedded system like the PineTime. Chrono watch face for the PineTime by Electr0Lyte\nI\u0026rsquo;ve lately had less time to devote to the PineTime community and the InfiniTime, but fortunately this didn\u0026rsquo;t prevent other developers from contributing to the project! Great pull requests are now being reviewed and merged, including ones that: reduce the wake up time, fix battery level readout, add call notification as well as a new \u0026lsquo;paddle\u0026rsquo; game. Perhaps the most noticeable addition to InfiniTime is this PR from AirHamster, which adds Cyrillic alphabet support for notifications. This is not a complete translation of the firmware, but it\u0026rsquo;s a first step for the support of multiple languages in InfiniTime.\nCyrillic alphabet / Russian language support for the PineTime by AirHamster (original image)\nA new version of Wasp-OS, the micropython firmware has also seen a release in the past 30 days. This is a great release which adds cool functionalities like the heart-rate monitoring, step counting as well as notifications. Moreover, this release improves the support for over-the-air updates and adds the ability to install wasp-os from InfiniTime, which is the default firmware the PineTime ships with. I like wasp-os very much (it\u0026rsquo;s very satisfying to enter the Python REPL running on the PineTime) and everyone interested in working with Micropython on embedded systems should really have a look at the project and its extensive documentation.\nNow let\u0026rsquo;s look at the PineTime ecosystem, and more specifically at Amazfish. This companion app for smartwatches and fitness trackers was originally designed to run on SailfishOS. Adam Pigg, the creator of Amazfish, worked hard on making the application easily portable to other Linux distros and various devices. With his help, we managed to build and run Amazfish on a x86 desktop computer (running Manjaro), the PinebookPro (running ManjaroARM) and on the Pinephone (running ManjaroArm with KDE)!\nPineTime running InfiniTime paired with Manjaro running KDE Plasma Mobile (original post)\nThis is great news for the PineTime project and an achievement that opens up the PineTime ecosystem to a lot of Linux distribution and Linux devices such as the PinePhone.\nConsider this also as a call for contributions - Amazfish really needs your help to package the application for multiple Linux OSes. Wouldn\u0026rsquo;t it be nice to have Amazfish easily installable on Manjaro, PostmarketOS, UBPorts and the many other operating systems of the PinePhone?\nPinebook Pro Let me get the bad news out of the way first: we’ve been unsuccessful in securing LCD panels for the Pinebook Pro. That said, we’re still actively working on finding a reliable source of panels for both the Pinebook Pro and PineTab, however it appears that the component shortages in China are only getting worse. I don’t own a crystal ball, so I cannot predict with certainty whether or not the situation will reach a successful resolution by next month. Given the current state of affairs, we’re planning to resume production of the Pinebook Pro after the Chinese New Year in late February or early March 2021. I fully understand this information will come as a disappointment to many of those waiting to get their hands on a unit. We’re sorry, and there is very little we can do at the present time. For more details about this unforeseen extended halt in Pinebook Pro and PineTab’s production please read the September and October community updates. On a positive note, we’ve seen an important software development, namely the Pinebook Pro will be supported in the Debian Bullseye Installer. This means that you’ll soon be able to install official Debian Bullseye on your Pinebook Pro (and OG Pinebook). While the Pinebook Pro already has really solid Debian support, thanks largely due to a community built installer by Daniel Thompson, it is obviously a whole different thing to have official support directly from the Debian project. We’re looking forward to the third Alpha release of the installer. When it finally gets released make sure to give it a shot. Debian on Pinebook Pro (image from Category5 Technology TV - video link)\nLastly, I am happy to report that the Pinebook Pro Docking Deck has received a very favorable response from the community. Early reviews have painted a very optimistic view of our USB-C dock. The Docking Dock has been long in the works, so it\u0026rsquo;s a real relief to us that it has received this much praise upon its initial launch. For those of you who have experienced issues with getting the Docking Deck working with the default Manjaro OS image, please switch over to the unstable branch. This can be achieved by editing pacman-mirrors.conf and upgrading your installation: sudo nano /etc/pacman-mirrors.conf\nChange from:\narm-stable to arm-unstable\nThen run:\nsudo pacman-mirrors -f5 \u0026amp;\u0026amp; sudo pacman -Syyuu\nYou can expect Docking Deck support to be added to the stable branch of Manjaro Arm in the next major software update (to kernel 5.10). As for other OS images for the Pinebook Pro, enablement of the Docking Deck will depend largely on developers. If you are a developer and want to incorporate Docking Deck support in your Pinebook Pro OS image, then please see this merge request by ayufan. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video A review of the Docking Deck by LearningLinuxTV\nPinePhone I’ll mostly have hardware-related topics to discuss this month, but there are a few noteworthy software and firmware subjects worth reporting on, since some of the recent developments affect the phone’s core functionality. Earlier in December, Megi released his version of kernel 5.10 for the PinePhone, which is now available for testing in a handful of OSes, noteworthily in Manjaro Phosh and Manjaro KDE. The new kernel brings a number of general improvements to the modem driver, WiFi as well as USB-C dock support. Regarding the modem driver, the time to resume from deep sleep has now been significantly reduced from 1.2 seconds to 400 milliseconds. As for dock support, not only should more docks be supported now, but the power delivery via the dock itself should be more reliable. For more information please read Megi’s news log. Another piece of important software-related information concerns modem firmware. A new firmware for the Quectel EG25-G, which improves power management as well as call reliability, is now available for flashing. It significantly improves the thermal performance of the modem, reducing the operating temperature and power consumption. The new firmware also adds profiles for Sprint and Telus VoLTE and support for select German and Spanish GSM providers. Our thanks go out to Biktor, who contributed to this firmware. We initially were hoping to have the KDE CE PinePhone ship with the new modem firmware, however due some issues with the automated flashing process integrated into the factory-test OS image (and a lack of time to troubleshoot what was wrong with it) all PinePhone users will have to flash their modems manually. Martijn Braam is currently looking into creating a simple and safe utility for flashing the firmware. I expect more information about this will follow shortly. Lastly, I want to report on the progress of the Megapixels, the PinePhone-specific camera application developed by and for postmarketOS, but used by many operating systems - including Mobian, Manjaro, KDE Neon, Manjaro with Lomiri and numerous others. The newest version of the application offers autofocus, manual controls for exposure and shutter, back-and-front camera switching, and now also a smooth 30FPS viewfinder. Although the application is still in beta, it shows a lot of promise and has continually exceeded everyone’s expectations. Moreover, the camera pictures have also shown a lot of improvement in recent months, and using manual controls, you now can take pretty good looking pictures. For more details please see Martijn Braam’s Megapixels documentation. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video The viewfinder in Megapixels running at 30FPS\nNext up we have a lot of hardware topics to cover. Let me start with some good news for all of you who have been waiting for a PinePhone keyboard. After a lengthy back-and-forth and numerous design changes, we have now firmly settled on a design and signed a contract with a highly reputable and specialized keyboard vendor. Design-wise, we’ve gone a full circle and in the end decided on a PSION5-like ‘Vulcano’ key type keyboard, which will attach and interface with the PinePhone via the pogo pins. The keyboard will also feature a high-capacity (5000-6000mAh) battery. Aside from the obvious attribute of extending the device’s operating time, the battery also acts as a counter-balance for the phone when it is fitted with the keyboard and sat on a flat surface. This will be a high-quality peripheral and we expect it to be a highly desirable add-on for the PinePhone. PinePhone mounted to keyboard when open (disregard USB-C port)\nPinePhone with keyboard when shut\nOriginal PSION5 keyboard for reference - the PinePhone keyboard will be very similar in form and function\nDue to the keyboard vendor’s expertise and manufacturing capabilities, we expect preview units to already be available in January. These early production units will be shipped out to developers so that the keyboard can be enabled across most if not all operating systems. Granted this enablement goes well, I think it is reasonable to expect the keyboard to be available in the Pine Store and regional stores sometime soon after the Chinese New Year (late February or early March 2021). We expect the PinePhone keyboard to cost somewhere in the $50 range in the Pine Store. In other hardware news, the Qi wireless charging case has now entered production. While we don’t have a price-point to announce at this time, we ought to have one by next month’s update since the back case should be available prior to Chinese New Year. The back case is 2mm thicker than the stock cover and can accommodate small add-on and accessory boards, such as for instance a LoRA module. We are still thinking of other applications apart from LoRA that could fit in the extra space offered by the case, but I’m sure end-users will find many interesting ways to make use of it. Personally, I cannot wait to see what functionality people will be able to hack into this case. The wireless coil design used in the back case\nSpeaking of hacking-in functionality into the PinePhone, these past 30 days have seen some of the coolest end-user add-ons ever created for the device. There are three which I want to highlight here: a functional fingerprint reader back-case, a DIY keyboard and the PineEye thermal camera. Let me offer some information about the latter two first, as I have some exciting news concerning the fingerprint reader back case. The PineEye uses a custom breakout board and PCB designed by jnavarro. The PCB hosts a Panasonic AMG8833 sensor which interfaces with the PinePhone’s pogo pins, more specifically the I2C port. The project is open and the sensor can be interacted with on most OSes by installing i2c-tools via OS specific package managers. It is my understanding that currently the add-on board does not function with Megapixels nor any other application, and could - at least in theory - be supported by a custom application, as illustrated by Marijn Braam earlier this year. I hope this project will expand and see more adoption. It is worth mentioning that the project is open hardware, so you can get your PineEye PCB today. PineEye PCB attached via flex cable to pogo pins (picture source)\nSimilarly to the PineEye, the DIY keyboard created by James Williams is something you could replicate on your own, granted that you have the technical mastery and tools. All you need is a 3D printer, some off-the-shelf components and a fair amount of time to complete the build. Just as the official PinePhone keyboard due early next year, the DIY keyboard by James snaps into the back of the PinePhone, replacing the default back case, and utilizes the I2C protocol on the pogo pins. The keyboard features small mechanical switches, a kickstand and a really nifty hinge design allowing the entire contraption to sit flush when closed. I really admire the effort and engineering that went into making this keyboard and wish I had the skills to replicate it on my own. To learn more about the project, please read the original reddit thread. DIY PinePhone keyboard (picture source)\nLast, but certainly not least, late last month we were absolutely blown away by Zachary Schroeder’s work, which resulted in a functional (!!!) fingerprint reader back case for the PinePhone. Soon after the original reddit post appeared I reached out to Zachary. We have since established a working-group consisting of numerous parties to help bring this design to fruition. His original design, while really cool, is not something we could help with manufacturing since the original sensor used was very expensive and large; this would result in a bulky and pricey back case. We have since managed to find a suitable replacement sensor, which not only is much more affordable but also smaller, thereby much simpler to implement. Zachary is currently in the process of enabling the new fingerprint reader and making it operational in software. It may still be a couple of months before this project reaches a production-ready status, but this will happen eventually. We’re really thankful to Zachary for wanting to work with us on this - it is a truly great and fun project. Prototype fingerprint reader back case; production sensor candidate pictured atop of the case\nPinePower Early next year we’ll launch a line of PINE64 branded power supplies (PSUs). Both PSUs are based on reference designs, but we have made significant improvements to the internals so they are more performant than existing offerings. The portable version of the PinePower - the name we chose for our line of PSUs - is a 65W (total output) Gallium Nitride (GaN) design capable of delivering 5V 3A; 9V 3A; 12V 3A; 15V 3A; 20V 3.25A over two USB-C and one USB-A port. It will be able to easily simultaneously charge the Pinebook Pro, the PinePhone and PineTime at the same time. It can also be used to power the Pinecil. We currently hope to have the portable PinePower available in late January or early February 2021, with a price tag of $24.99 in the Pine Store and $29.99 in regional retail stores. The portable PinePower PSU will look like this\nThe desktop version of the PinePower, due sometime later in 2021, will be capable of 120W total output. This PSU will feature 4x power delivery USB-A ports and a USB-C port. We will incorporate a LCD panel allowing for detailed and active monitoring of the power draw of each of the ports. We are currently debating whether we should incorporate a 10W Qi charging platform, situated on top of the Deskto PinePower’s chassis, so that the PinePhone fitted with Qi charging case or an Android phone could be placed on it. I’d really like to hear your feedback about this feature - good or bad idea, what do you think? I’ll have more information about the PinePower next month when the first samples roll off the factory line. PineCube There are two pieces of PineCube information which I’d like to share with you this month. First, Armbian now offers a mainline (kernel 5.9) Linux build for the PineCube. There is an Ubuntu Focal and a Debian Buster version of the Armbian build for you to choose from. This is obviously great news, and we are very thankful to the Armbian project for supporting the PineCube so quickly after launch; a special thanks goes out to Moe Icenowy for making this happen. The support for the PineCube was added yesterday (from the time of writing) and I have not yet personally had an opportunity to test it. I am, however, very much interested in hearing people’s experiences with the PineCube running Armbian - if you’ve tried it, make sure to let us know your impressions in the comments section\nPineCube case\nSecondly, we’ve created a housing for the PineCube. We will, eventually, make it available in the Pine Store for purchase. Meanwhile, we’ve decided to release the STL files for the housing so that anyone with a 3D printer can print their own. If you would like to upload it to Thingiverse, then you’ve got my blessing to do so. You are also allowed, and indeed even encouraged, to alter and improve the default design. Pinecil The first production run of the Pinecil has sold out in under 3 days. While we knew that it would prove popular, we weren’t quite prepared for such an enthusiastic response. Mind you, this wasn’t exactly a small production run either. Taking this into account I am sure many of you will be happy to hear that the next batch is currently being manufactured, and we expect to receive the next shipment of Pinecils sometime in January. I’ll make sure to give everyone a heads up when the next shipment becomes available on PINE64 Telegram News channel as well as our Twitter and Mastodon. First Pinecils are now in the wild - photo by Mozzwald (original source)\nOver the past few weeks we’ve been closely monitoring Pinecil feedback from the community. As always, we’re thankful for the input received. We’re also glad to see that the device has been met with such good reception from end-users. We’ll keep on reviewing incoming feedback, and granted that no major issues are reported, we’ll probably have a steady Pinecil production flow post Chinese New Year. To those who already got their Pinecils, please share your experience of the device with others. Nutcracker Challenge (by gamiee) Closing out this month’s community update, here is a short update on the current state of the Nutcracker challenge - our effort to bring a fully open source firmware Bluetooth and WiFi module to current and future PINE64 devices and single board computers. Since last month’s blog post another 19 developers have received their PineCone evaluation board (EVB), and we have seen many new contributions to the project. Bouffalo, the company behind the BL602 RISC-V BT/WiFi silicon used by the PineCone, has made a promise to us that more source code related to the WiFi and Bluetooth blobs will be released shortly. While we wait for the code, the community has started exploring other parts of the SoC. More specifically the present efforts are concentrated on exploring the flashing mechanisms and internal BootROM code. This resulted in early open-source flashing tools, written in Python and Rust, being released. Moreover, we released an initial Arduino support for the BL602, with working hardware serial, GPIO, PWM and I2C peripherals - please see our PineCone GitHub for more details. Lastly, Lup Yuen - whom you may know from his excellent work on the PineTime - has been writing phenomenal articles about the PineCone. We strongly recommend you give them a read if you’re interested in the Nutcracker Challenge; the articles can be found on Lup’s Github.\nThat is all for this month’s update - catch you all in 2021!\n","permalink":"/2020/12/15/december-update-the-longest-one-yet/","tags":["community","pine64","pinebook-pro","pinecil","pinephone","pinetime"],"title":"December Update: The Longest One Yet"},{"categories":["community"],"contents":"\nIn 2021 you’ll see online retail Pine stores open in Europe, North America and possibly also worldwide at a later stage. Let me start by making one thing clear - the current Pine Store isn’t going away and the pricing in the Pine Store will remain unchanged. You’ll always be able to buy and pre-order your devices from pine64.com at a community-oriented price point. The retail stores will function alongside the Pine Store, not replace it, and offer a different customer experience. In this blog I’ll explain the rationale behind this strategy. PINE64 is not a business First things first - PINE64 is a community, not a business, and the Pine Store’s sole purpose is to serve this community by providing FOSS development-friendly hardware. Sales numbers and revenue are not, and never were, a driving force behind this project; making the next fun and often experimental device was and still is. Some devices, such as the original Pinebook, were even sold at a loss at times - simply because we knew people wanted one. Seriously.\nVictims of our own success Our strategy was always clear - work with developers to design a product, have partner projects and community developers work on the software and sell the device at a community-oriented price point. This approach has proven to be a great way forward for us, and one that, dare I say it, ultimately distinguished us from the other FOSS-vendors and manufacturers. That said, we’re slowly falling victim to our own success. News of our devices have reached people outside of our target audience, and enthusiast-grade products now frequently end up in the hands of non-technical customers. I have just been looking at the incoming support tickets these past weeks, and the majority of incoming queries are by people who are not comfortable troubleshooting software problems, have little Linux experience, and do not understand the nature of our devices. In a nutshell, they are general tech-consumers unfamiliar with the intricacies of Linux, FOSS communities and our goals.\nPine Store isn’t meant to deliver software support The Pine Store’s support structure is designed to help with lost shipments, RMAs, part-replacement and other similar queries. However, much of today’s work actually consists of software troubleshooting, detailed walkthroughs and explaining basics of how the devices operate. In other words, the Pine Store support performs tasks that our community Wiki, forums, and chats are intended for. More frequently than before, support staff also encounters customers completely unaccustomed to troubleshooting hardware issues or participating in identifying the nature of experienced problems. For reference, the Pine Store receives in excess of 3000 support emails per month - this give you an idea of the scale and volume of such support tickets. Don’t get me wrong, I don’t blame such customers. In their minds we’re no different to any other tech company, our products no different from their existing phones, laptops and PCs. It is a case of misaligned expectations and a fundamental conceptual misunderstanding.\nA suitable solution The simplest solution would be to prevent users unacquainted with Linux, FOSS communities and our strategy from purchasing devices such as the PinePhone. We could, for instance, have people explicitly agree to using community resources for software support, declare an understanding of the community-driven nature of the project and acknowledge the work-in-progress nature of the device.\nBut this would be ultimately unfair - we believe that everyone should have a go at Linux, its community as well as devices such as the Pinebook Pro and PinePhone, which are a great way for people to get involved. So the resolution we settle on instead is offering a retail experience to those who require it. Let me explain exactly what this means; devices purchased from regional online retail stores will usually ship out within a few days of the purchase date, come with region-specific warranties (inc. RMA) and a guarantee of traditional retail customer support (e.g. software troubleshooting). There may be more benefits to buying from online retail stores too - that remains to be seen. This will come at a cost - the devices will be more expensive. Devices sold in online retail stores will need to make a profit to maintain this level of support, cover RMAs and put food on people’s tables. As some of you have already noticed, the Pine Store now lists both the community price - available exclusively in the Pine Store - as well as a retail price that will be used in online retail stores (see images below). Examples of listings including both the community and retail pricing.\nConsider it a choice Ultimately we wish to offer people a choice. The Pine Store, in its current form, isn\u0026rsquo;t going anytime soon and the current community-oriented price point will not change. If you are a Linux adept with an understanding of the intricacies of enthusiast-grade devices, then the Pine Store will be there for you just as it has these past five years. However, if you are a curious bystander or simply someone keen to learn and experiment with Linux, then the retail options may prove a better choice. More information about this topic will follow in January 2021, at which point we’ll explain in more detail how the relationship between the community-oriented Pine Store and online retail stores will function in practice.\n","permalink":"/2020/12/02/pine-store-community-pricing-online-retail-stores/","tags":["pine-store","pine64"],"title":"Pine Store Community Pricing \u0026 Online Retail Stores"},{"categories":["news","pinephone"],"contents":"\nWe are pleased to announce that the KDE Community Edition (CE) PinePhone is now available for pre-order. This edition of the PinePhone ships with a tailored build of Plasma Mobile built upon Manjaro Linux, and it is the culmination of ongoing efforts to bring the popular Plasma desktop environment to the smartphone. To learn more about Plasma Mobile please visit the project’s website. To better understand your options for running Plasma Mobile on the PinePhone and the current state of development (at the time of writing) I encourage you to read the development team\u0026rsquo;s blog post on this subject matter. This community edition will ship in a custom presentation box designed by the Plasma Mobile team, and the PinePhone itself will feature a KDE logo on the back-cover (see renders for reference).\nThis PinePhone CE will be available in two hardware configurations:\n$149 — 2GB RAM; 16GB eMMC $199 — 3GB RAM; 32GB eMMC (includes a bundled USB-C dock) Both configurations of the KDE CE PinePhones feature rev. 1.2b PCBA. The $199 hardware variant, called convergence package, also features a USB-C dock equipped with 10/100 Ethernet, 2x USB type A ports, HDMI digital video output and power-in via USB-C.\nWe will donate $10 per unit sold to KDE e.V. To learn more about this scheme please click here.\nTo learn more about PinePhone KDE CE please read the original announcement.\n","permalink":"/2020/12/01/kde-community-edition-is-now-available/","tags":["community-edition","kde","pinephone"],"title":"KDE Community Edition is now available"},{"categories":["community","cube","news","pinebook-pro","pinecil","pinephone","pinetab","pinetime","soedge"],"contents":"\nWelcome to this month\u0026rsquo;s community update! We’ve got exciting news to share, but before I proceed in doing so I’d like to thank Gamiee, JF, and PizzaLovingNerd for contributing to this blog entry and Clover for the final edits and proof-reading. As the PINE64 device-family grows larger and becomes more diverse, I find myself more reliant than ever on other people\u0026rsquo;s insight and expertise when writing up these updates. To this end, I’d very much like to thank the aforementioned community members and, at the same time, invite others to take part in shaping future updates. If you’ve got something you would like to contribute to an upcoming community update, then please reach out to me in the chats. In this update we’re happy to announce the next Community Edition of the PinePhone, which will ship with KDE Plasma Mobile. We will also take a look at the Pinebook Pro dock and talk a bit about future hardware. For those of you who are averse to reading long blog entries or simply prefer receiving news in an audio-video format, then you’ll be glad to know that we now have a complimentary video edition of the monthly community update. It can also be watched on LBRY if Youtube isn’t your thing.\nhttps://www.youtube.com/watch?v=4su-YdjTYtY\u0026feature=youtu.be\nVideo synopsis of the November Community Update\nTL;DR for this month\u0026rsquo;s update:\nWe’ve donated to postmarketOS; thank you to those who supported the pmOS CE! Sub-forums and Wiki entries for PineCube and SOEdge are now up Problems with chat protocol bridge to be addressed soon(TM) Notice re. Small number of Manjaro PinePhones with postmarketOS -sorry! Nutcracker Challenge - working towards a blob-free WiFi and BT. Get your PineCone EVB now Let’s talk about the future; sneak peak at RK3566 SBCs in early 2021 Thrilled to announce PinePhone KDE Community Edition! PinePhone KDE CE pre-orders start December 1st. 2GB RAM/ 16GB eMMC and 3GB RAM/ 32GB eMMC + USB-C dock (Convergence Package) will be available. PinePhone 3GB RAM/ 32GB eMMC mainboards now available in the Pine Store; early adopters get a major discount PInePhone Qi wireless charging back case taking shape - available nearly next year Megi’s PinePhone kernel improvements are a big deal; we’re getting closer and closer to daily-driver readiness PinePhone convergence working well now Pinebook Pro ‘Docking Deck’ USB-C dock available later this month for $39.99 Armbian on the Pinebook Pro is great; if you’re in need of Ubuntu on the PBP, then give it a spin - highly recommended FydeOS for Pinebook Pro is a ChromiumOS fork capable of running Android and Linux applications; coming soon! PineTime InfiniTime updated to 0.9.0; fixes a major bug and brings new music player PineTime firmware can now be upgraded via Gadgetbridge! PineTime reloader tool to switch bootloaders, and firmware, in the works Pinecil entered production and will be available later this month or late the next; a look at the packaging and extra tips PineCube running Debian and NixOS; software progress is coming along well PineCube subforum, chat and Wiki now available - join in and contribute SOEdge will be available for “Developers only” to start with SOEdge Wiki and subforum is now live Housekeeping We have now made a donation to the postmarketOS team for their work on the Community Edition of the PinePhone. We firmly believe and trust that this sizable donation will be put to good use and benefit all Linux on mobile development to come. Working with the postmarketOS team has been nothing short of great and since their phones shipped we’ve seen significant improvements to the software. I’d like to once again thank those of you who chose to support them by purchasing a postmarketOS PinePhone.\nIn other community news, there are now PineCube and SOEDge sub-forums on the PINE64 forum. Both devices, which I’ll write about later in this month’s update, will benefit strongly from community engagement early on. A PineCube chat is also available on our Discord server, and will eventually end up bridged up to other protocols. On a similar note, the Nutcracker challenge which began this month has now also found its way onto our Discord and will, in all likelihood, also be bridged to other protocols. We’ll soon also be adding sub-forums and chats for the SOEdge and Pinecil - you can expect them to be available to the community sometime later this year, perhaps even this month. On the subject of chats, I’d quickly like to touch upon the situation with the chat-protocol bridge. For those who aren’t in the know, we currently have multiple chat protocols bridged with many thousands of users relying on it for cooperation, knowledge dissemination and software support. In recent months we’ve started to experience issues, which subsequently led to IRC being disconnected from current chat infrastructure. We have also experienced a significant increase in response delays across the bridge - likely due to the high volume of messages and people participating. In result, the entire bridge will have to be reworked in the coming months - as early as this month or as late as early January. This will obviously cause a disruption to chat communications for a day or two, so consider this a heads-up; a notice will be issued when work on the chats begins. In other community news, I am happy to report that the shipping progress for the Manjaro Community Edition PinePhones is proceeding well without any major hiccups. Indeed, Manjaro CE started shipping earlier than we anticipated, with thousands of people having already received their devices. For those of you still waiting for your unit to arrive, I encourage you to follow the shipping thread over on our forum; we still expect to have a handful of shipping updates for the Manjaro CE between now and mid-December. Lastly, a few days ago it has come to our attention that a number of Manjaro CE PinePhones have shipped with postmarketOS preinstalled. Following a brief investigation, it turned out that one out of 100 SD cards used for testing and subsequent flashing at the factory did, indeed, contain the postmarketOS image. If you Manjaro CE shipped with postmarketOS, then please see this blog post and please accept our apologies for this situation.\nNutcracker Challenge [by** Marek “Gamiee” Kraus**] The PineCone - by Martijn Braam\nAs many of you have probably already heard, we recently launched the Nutcracker Challenge - a reverse-engineering effort of WiFi and Bluetooth on the BL602 chip with a RISC-V core. The intention of the effort is to eventually have a 100% open-source WiFi and Bluetooth chip for PINE64 devices including current and future single board computers, smartphones, tablets and laptops. This is an important project for us and one which we believe will directly benefit not only our user base but also others who care about privacy. Following the announcement of the Challenge we immediately received a lot of attention, and at the time of writing this article we have received 86 pull requests, out of which 49 have already been merged. All this effort was made by 37 contributors who will be rewarded with a free PineCone Evaluation Board for their work. The first very small batch of PineCone Evaluation Boards - or EVBs - has been already shipped, and the second batch is being manufactured. We expect to ship a total of 1000 PineCone EVBs over the duration of the challenge. Despite developers and contributors not having access to the hardware, they made great progress on analyzing the blobs, improving documentation or fixing bugs in the SDK. We are also happy that the company which designed the chip - Bouffalo - have promised more documentation and low-level code, which they already provided to us alongside an improved datasheet and reference manual. There is still much to do and a long road ahead of us, but we expect to see a tremendous contribution boost once the hardware reaches its new owners. For all of you interested in participating in the Nutcracker Challenge, I invite you to read about how you can contribute and receive a free PineCone EVB. Let\u0026rsquo;s talk about the future [Part 1 of many to come] Next month’s update will include a full review of the year 2020; we will look back at how far we’ve come since December 2019. Today, I will give you a sneak-peak at the future and what’s to come. Before I proceed, I’d like to make it clear: what I am about to share with you is just a small portion of our strategy for the months to come. Consider this the first of many steps which we will begin taking in the next 6-to-12 months to further PINE64’s cause. With that out of the way, let me introduce you to the next SoC to enter the PINE64 lineup at one point early next year, the RK3566. Rockchip RK3566\nYou can think of the RK3566 in terms of a spiritual successor to the RK3328 currently used in the ROCK64 single board computer - our most popular device to date, at least in terms of units sold. It is, however, not only more powerful than the RK3328, but also considerably more flexible in terms of potential use-cases and implementations. Featuring four fast A55 cores running at 2.0 GHz, a modern G52 GPU, fast I/O (including PCIe, USB3.0, GbE and SATA) and up-to 8GB of [LP]DDR4 RAM, it is our choice for NON-Pro PINE64 devices to come. Next year you will see us introduce two single board computers based on the RK3566 - they will be available in two configurations, more specifically in the model ‘A’ and the model ‘B’ form-factor. For those that do not know, ‘A’ -sized PINE64 SBCs are larger in size, sharing the ROCKPro64’s and PINE A64-LTS footprint, while the ‘B’ form-factor SBCs are smaller, such as the ROCK64 or PINE H64. It is noteworthy that the new generation SBCs will be a part of a new line of devices, and hence not share the ‘ROCK’ naming scheme of current Rockchip boards. More on this later. We envision the two boards to serve somewhat different purposes within the PINE64 eco-system. The ‘B’ board will be just that, a stand-alone single board computer, while the ‘A’-sized board may offer the opportunity to be used as a development platform for future non-pro devices due to all of the SoC’s I/O being exposed on the larger PCBA. Both the ‘A’ and ‘B’ form-factor RK3566 single board computers will, of course, be software compatible so you may choose either for your new project. As a fun fact I’ll add that the SoC has a dedicated e-ink protocol - so the possibility for creating the most outrageously overpowered e-reader is now upon us.\nFinishing this section off, I’d like to make you aware that it will be a long time before the future RK3566-based SBCs will be useful to regular end-users or serve as a basis for next-gen PINE64 devices. Mainlining, patching, as well as exposing all interfaces (making them functional) in the Linux kernel takes time and a lot of work. In other words, don’t expect the A64 and RK3328 - both of which are well supported in Linux - to be phased out anytime soon. Indeed, I expect that this will be a long transition period, but at the same time I am excited to announce this new beginning. Later this month I\u0026rsquo;ll release a riddle pertaining to the naming of this PINE64 product-line. The person to crack the riddle first will receive one of the first boards from the production line.\nPinePhone We are thrilled to announce that we’re teaming up with KDE to bring you the next community edition (CE) of the PinePhone. We have a long-standing friendship with the KDE Community, going all the way back to the original Pinebook which shipped with KDE Neon as it’s default operating system. For more than a year now, the Pinebook Pro, which features Manjaro with KDE Plasma desktop, has been receiving widespread acclaim from the media and end-users alike. It is also because of this close relationship that the KDE team were among the very first we approached when envisioning the PinePhone. Fun Fact: during the initial conceptual stages of the PinePhone’s development, KDE were also the ones to accidentally leak that the PinePhone was in the works!)\nKDE Plasma Mobile on the PinePhone\nFor the past year now, Plasma Mobile (which, for those who don’t know, is KDE’s mobile user interface) has made major strides and achieved a new level of polish. I believe that this is, at least in part, thanks to the broad adoption of the PinePhone as the default Linux-on-mobile development platform. Just in a recent blog post on Plasma Mobile’s website, the development team mentioned major improvements to the overall user experience, ranging from significant shell and lockscreen improvements, to improved support for vital mobile apps. I strongly encourage you to read the linked blog post to learn more. We currently plan to have pre-orders for the KDE CE to go live on December 1, 2020 - you can expect an announcement blog post once the phones become available. I also encourage you to subscribe to this blog, follow us on Twitter and join the PINE64 Telegram News Channel so you do not miss the news. The PinePhone itself will be available in the same two HW configurations as the previous two editions: $149 - 2GB RAM + 16GB eMMC\n$199 - 3GB RAM + 32GB eMMC Convergence Package with an included USB-C dock\nPlease head over to KDE\u0026rsquo;s website and read the announcement to learn more about what the team got in store for this community edition of the PinePhone.\n3GB RAM / 32GB eMMC Flash PinePhone Mainboards\nWe’re happy to let you know that stand-alone 3GB RAM / 32GB eMMC flash mainboards are now available for purchase from the Pine Store. We made the decision to sell the mainboards at a significant discount to BraveHeart and UBPorts CE owners who wish to upgrade the device. Consider it a ‘thank you’ for being early adopters; we really appreciate you supporting us in our quest to bring Linux on mobile to a wider audience. For those who wish to learn more about this newest revision of the PinePhone mainboard, I point you to the schematic for details (no major change from 1.2a). Last on the PinePhone hardware discussion list for this month is the Qi wireless charging caseback for the PinePhone. The wireless charging back case is soon to enter production and we expect it to be available early next year. The Qi wireless implementation we’re using is pretty cutting edge; it incorporates all components, including the copper coil on the actual PCB itself - which, in turn, is incorporated into the back case. It is over my head, so I am including an engineering picture for you to take a look at.\nQi wireless charging coil and PCB for the PinePhone to be embedded in custom back case\nSoftware-wise, the last month has seen some of the most impressive improvements in months. Ondrej (Megi) Jirman has made substantial progress on his kernel and usability patches, which have now become adopted by the majority of PinePhone operating systems. Among other refinements and enhancements made, the PinePhone display now runs at 60Hz - 1/3x faster than before, resulting in an all-around much snappier experience. This is particularly noticeable when typing or otherwise interacting with the touchscreen. I consider this a major boon from an usability standpoint. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video KDE Plasma Mobile with Megi\u0026rsquo;s patches ~ via KDE and Manjaro dev teams\nMoreover, docking the PinePhone for desktop convergence - in OSes that support this feature and use the new kernel and relevant patches - now works like a charm. I’ve tested Manjaro with Phosh and Plasma Mobile, and both worked well in the docked mode. Docking the phone for a convergence experience now also works with just about any TV or display, and the phone will even output to a 4K@30FPS monitor (although, the convergence feature is not usable at this resolution). To be clear, when I say that ‘it works’ I mean that all of the dock’s features now work well, including power input, HDMI out, USB ports and the Ethernet connection. I found that I can genuinely be quite productive whilst using the PinePhone in this configuration - case in point, I am writing this section of the update on a docked PinePhone. But productivity obviously is just a portion of the potential - you can have some fun with this feature too, check out the video below.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Docking your phone can be used for so much more than productivity!\nLastly, I also found that the PinePhone now resumes faster from suspend on incoming calls, and that the Bluetooth adapter functions reliably. Both of these features, while relatively minor when compared to the major strides made in the past month, are actually very significant in terms of making the PinePhone viable as a daily driver. This, combined with the much improved voice call audio quality in the newest kernel, means that my SIM card now resides exclusively in the PinePhone, while I keep my Android phone for auxiliary tasks. We’ve come a long way since January 2020 and at this pace I feel the PinePhone may become a viable daily driver for many users early next year - I truly believe this.\nPinebook Pro I have some good Pinebook Pro hardware and software news to share with you this month. Let’s begin with hardware; the Pinebook Pro USB-C dock, which we have christened “The Docking Deck”, has now entered production and ought to be available in the Pine Store in a week’s time. It will be coming in at a price of $39.99. I’d like to thank ayufan for making The Docking Deck work with the mainline Linux kernel with patches - without his work we likely would have not decided to proceed with making the deck. The default Manjaro OS build that ships with the PBP will be updated to support The Docking Deck out-of-the-box in the future. Picture of Docking Deck from factory\nThe deck features a wide array of I/O including: 1) a full sized SD card slot; 2) a mSD slot; 3) 2x USB-C ports; 4) 3x USB 3.0 ports; 5) a Gigabit Ethernet port; 6) VGA out socket; 7) as well as HDMI out. It uses USB-C for power and is capable of accommodating high Wattage power supply units capable of delivering power to the Pinebook Pro as well as all peripherals attached to The Docking Deck. The picture below shows the exact layout of the entire I/O. Mind you, the picture below is of a prototype sample we received from the factory; the final production version will be perfectly color matched the Pinebook Pro and even share a near identical metal feel of the laptop’s shell. There will be a small laser etched PINE64 logo at the bottom of the deck, alongside the required certification.\nA closer look at the Docking Deck\u0026rsquo;s I/O - Picture of Prototype\nSoftware wise, there are two things I’d like to write about this month, the most recent Armbian build and FydeOS for the Pinebook Pro. Armbian now offers a well supported Ubuntu Focal OS image for the Pinebook Pro, based on a mainline kernel with patches and FOSS GPU drivers. I’ve recently spent some time with this operating system and I am happy to report that it is a phenomenal option for all those who want to run Ubuntu on their Pinebook Pro. Armbian is snappy, responsive and has a good selection of software to get you going. I had no issues with watching 1080p video content locally, playing retro games in retroarch or browsing the internet. If you’re not a fan of Manjaro and have a strong preference for Ubuntu over Debian, then I highly recommend this build - it\u0026rsquo;s very good. FydeOS on the Pinebook Pro\nThe other operating system I’ve been trying out on my Pinebook Pro is FydeOS - a ChromiumOS fork capable of running Linux and Android apps. I found the operating system to be very snappy and capable. Playing back Youtube movies, even at a 1440p, was a perfectly smooth experience and Android apps - including some popular games - ran exceedingly well. I am not suggesting it instead of Linux or BSD, but if you or your kids need a Chromebook then this OS may just be worthwhile looking into. I am presently not certain as to when a build will be publicly available, but the beta I had the privilege of trying out was already really polished, so I expect we’ll hear more news from the FydeOS development team soon. Stay tuned! PineTime [by** JF**] These last few weeks, the InfiniTime project received a lot of feedback from users (in Github, Twitter and in the chat) and contributions from fellow developers. It\u0026rsquo;s really amazing to see that people are actually using InfiniTime and even devoting their time to working on improving it!\nInfiniTime version 0.9.0 was released a few days ago. The new firmware version fixes some annoying bugs, including one that prevented the bootloader from running correctly after a reset. This bug would temporarily brick the device, and some people had to wait for the battery to drain completely before being able to get PineTime up and running again. It\u0026rsquo;s not something I like to tell to the users, so I\u0026rsquo;m glad we\u0026rsquo;ve been able to identify the underlying cause of the bug and fix it.\nVersion 0.9 also brings a new Music app. This app allows you to control the music playback on your phone (play, pause, volume up and down,\u0026hellip;). Avamander improved the previous version of the app with a new UI with a nice animation, and even added new information on the display like the song progression. This app still works nicely with Gadgetbridge and Amazfish!\nMusic app on the PineTime connected to Android smartphone\nSpeaking of Gadgetbridge - an Android companion app - has seen a release of version 0.48.0 just a few days after last month’s community update. With this version of the app, you can use InfiniTime to upgrade your PineTime over-the-air (OTA) from Gadgetbridge. To my knowledge, Gadgetbridge is the first open source companion app to provide this functionality!\nPineTime OTA firmware update via Gadgetbridge Another piece of great news in the PineTime ecosystem is that Piggz is working on porting Amazfish to Linux desktop. Amazfish is a companion app for several smartwatches and fitness trackers. It runs on SailfishOS and already supports InfiniTime. Amazfish should eventually be easily portable to multiple Linux distros and UIs (like plasma-mobile and UBPorts), and run on many devices like the PinePhone and the PinebookPro!\nNow, what\u0026rsquo;s next? I\u0026rsquo;m working with Daniel from wasp-os on a tool that upgrades/switches the bootloader of the PineTime. The bootloader is a critical piece of code that initialises the device and starts the firmware. It can also provide interesting functionalities like firmware upgrade and OTA. Since the beginning of the PineTime project 2 bootloaders have coexisted - the one based on the NRF Softdevice (NRF is the manufacturer of the microcontroller at the heart of the PineTime, the NRF52832) and the one based on MCUBoot, mainly written by [Lup Yuen Lee](https://twitter.com/MisterTechBlog). Both bootloaders have their characteristics, their functionalities, pros and cons, and they are not compatible with each other. You cannot install a firmware built around the NRF SoftDevice on a PineTime running the MCUBoot bootloader, and vice-versa. Wasp-os and ATCWatch are running on the NRF bootloader while InfiniTime, Klok, and Hypnos use the MCUBoot one.\nThis reloader tool Daniel and I are working on (and honestly, Daniel is doing most of the work :)) will allow users not only to upgrade the bootloader they are using, but also to switch from NRF to MCUBoot and from MCUBoot to NRF. This will give more choices to the users and allow both communities to work together, which is, in my opinion, a really great thing.\nDaniel shot a video that demonstrates a complete OTA roundtrip (wasp-os -\u0026gt; InfiniTime -\u0026gt; wasp-os) that will give you a better understanding on the subject!\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Installing Wasp-OS from InfiniTime ~ by Daniel Thompson\nFor those who don\u0026rsquo;t know it yet, wasp-os is a \u0026ldquo;MicroPython based development environment for smart watches\u0026rdquo;. It provides many Python applications such as a clock, stopwatch, step counter and heart rate monitor. Anyone interested in extremely geeky timepieces should be sure to check out the Fibonacci watch face that was recently contributed to wasp-os by Johannes Wache.\nPinecil The Pinecil has entered production a couple of weeks ago and will be available for purchase late this month or early next month. Much work has gone into polishing the tooling for the soldering iron’s molding, and we trust that the final version of the Pinecil will not only function but also look great. Check out last month\u0026rsquo;s update, in which I shared a couple of prototype pictures as well as a render of the final device. Aside from getting the Pinecil into production, time has also been spent on getting relevant certifications, figuring the least intrusive way of branding it, and deciding on the device’s packaging. Below you’ll find renders of the Pinecil’s packaging and the 4 complementary soldering tips which will be sold separately in the Pine Store. As you’ll notice, we decided to place branding and all required certifications along one side of the device - I subjectively feel this looks quite nice. Pincil presentation box (top) and 4-tip presentation box (bottom)\nAs soon as the Pinecil starts rolling out of the factory we’ll make sure to let you know when it is available for purchase. I’ll make sure to post a blog post, tweet / toot it and share it on our Telegram News Channel. If you’re interested in picking up a Pinecil, then make sure to follow us on your platform of choice to be notified when sales go live. PineCube I’m happy to report that PineCube’s early software efforts are progressing well. We already have an internal Debian build running mainline kernel with patches, which shows a lot of potential. This isn’t to say that it is ready for use - to the contrary, considerable effort on developers part will be required to get all core functionality working. It is my understanding that this build will be released soon; massive thanks to Gamiee for making strides on the PineCube.\nThere is now also a NixOS build available for the PineCube thanks to Daniel Fullmer. A quick look at his GitHub reveals that this OS build is quite far along, with many core functions of the device already working. This includes: Booting from SPI, enabling the IR LEDs, Ethernet, WiFi as well as USB. Perhaps most importantly, it appears that video streaming and recording from the camera already works, and if I am reading the documentation correctly then even the microphone is already functional. NixOS booted on the PineCube\nI am also told that Elimo Engineering has integrated support for the PineCube into Buildroot. Their GitHub account contains build instructions in the board support directory readme if you’re interested. It provides support for the S3\u0026rsquo;s DDR3 in u-boot, which is an important development for the device. This means that the system is capable of booting really fast - apparently in under 1.5 seconds from cold boot to login prompt. These are all very significant developments, and the software will take shape over the next few months until we have a handful of usable operating systems for the PineCube. As I already mentioned in the Housekeeping section, a PineCube subforum has been created earlier this month, and development discussions are already taking place on the PineCube Discord chat. So if you pick up an early unit, you know where to direct questions and contributions. Speaking of contributions, you are also encouraged to submit entries to the PineCube documentation; we’d appreciate that. SOEdge We’ll soon be getting ready to make the SOEdge available in the Pine Store. When it launches, it will be advertised as “strictly for developers”, since the software has a very long way to go before it can be considered as viable for end-user’s implementations. To speed up the development process, we’ve now created an information-rich SOEdge documentation, which includes not only the BSP Linux SDK alongside core software documentation, but also a complete datasheet of the SOM, the baseboard and other components. Late last month Gamiee managed to get the module up and running using the Rockchip-provided BSP kernel. It is my understanding that this is an internal build - meant as a tool to determine the SOM’s and baseboard’s functionality, rather than an OS that will be shared publicly. It is my experience that information-exchange at such an early stage of development is crucial to a project’s success; to this end, we now have a SOEdge subforum, a Wiki page (please contribute) and there will soon be dev-chats set up to accommodate participating devs.\nI cannot wait to see what the community manages to do with the SOEdge SOM in the coming months. SOEdge slotted in it\u0026rsquo;s baseboard\nThat\u0026rsquo;s all for this month. Make sure to subscribe to this blog (at the bottom of the page), follow us on Twitter and Mastodon and stay up-to-date with PINE64 News on the Telegram News Channel.\n","permalink":"/2020/11/15/november-update-kde-pinephone-ce-and-a-peek-into-the-future/","tags":["kde","pinebook-pro","pinecube","pinephone","pinetime","rk3566","soedge"],"title":"November Update: KDE PinePhone CE And A Peek Into The Future"},{"categories":["community"],"contents":"Nutcracker challenge: Working towards blob-free WiFi and BLE. Get your EVB now free.\nAlthough it\u0026rsquo;s the end of Hacktoberfest, it\u0026rsquo;s not too late for an open source nut cracking challenge. This is a challenge that will benefit not only our current and future devices but also the community moving forward.\nSo, what is the challenge then? To achieve blob-free BL602 for the open source community so that we all can enjoy blob-free FOSS Bluetooth and WiFi on PINE64 devices. If you want to get in on the action and to receive a BL602 evaluation board (EVB) - which we have codenamed PineCone - with the BL602 shipped to you, here are the steps to follow: Unfortunately, the challenge already ended.\nAnyone can participate in this Nutcracker campaign but we only have a limited amount (approx 1000 pcs) of EVBs available, so if many people choose to take part then we’ll have to prioritise the kits based on a common-sense first-come-first-served basis. Let’s do this!\n","permalink":"/contests/nutcracker-challenge-blob-free-wifi-ble/","tags":null,"title":"Nutcracker Challenge: Blob-Free WiFi \u0026 BLE"},{"categories":["community","cube","news","pinecil","pinephone","pinetime","soedge"],"contents":"\nLet me begin this month’s community update by teasing the November update, in which I’ll talk about the next generation of SoCs and our plans for the future. If you haven’t done so yet, then now is the right time to subscribe to our blog and follow the news on the PINE64 Telegram news channel. I’ll be mostly focusing on hardware in this month\u0026rsquo;s update, I’ve been out of the software development loop for much of the month due to personal reasons. This, however, gives me an opportunity to talk to you at more length about the PineCube, Pinecil and SOEdge as well as some community-centric things. As always, massive thanks to JF for contributing the PineTime section of the update! Much has happened in the past month so let\u0026rsquo;s get to it. TL;DR\nNew store and its features; store move to .com domain I’ve been working towards setting up an EU store Community-created content for PINE64 Youtube and LBRY channels Pinebook Pro and PineTab LCD shortages continue; hopefully panels become available in December Manjaro PinePhone CE OS build is finished \u0026amp; sent to factory yesterday Manjaro’s build closest to end-user ready yet; ships with Phosh Work on PinePhone back-covers adding functionality started First two back-covers will add: wireless Qi charging (already works) and NFC PinePhone keyboard design green-lit and started; clam-shell design with large battery SOEdge modules are ready! Chicken-and-the-egg problem, the SOEdge needs Linux devs PineCube is available for purchase; software development is coming along PineCube lens selection coming to the Pine Store Pinecil firmware is coming together very well Pinecil will ship with a B2 tip, but two packages with four tips each will be available ($24.99 each) We created a breakout board for the Pinecil … it is now an SBC (sort of anyways) PineTime with InifiniTime FOSS firmware is now available and shipping! PineTime music control in Android with gadgetbridge and playing games on the watch PineCom - a small PDA-style device relying on alternative communication protocols Addressing the PineCom push-back from the community (thank you for your feedback) Housekeeping There are a handful of important housekeeping topics to discuss this month. For starters, let’s talk a little about the new Pine Store. We hope that the new store not only improves the browsing experience but also addresses much of the feedback that we received from our community. Feature-wise, you are now also able to pay using credit cards (as well Apple Pay and similar services) and calculate shipping and import-related costs, such as VAT, for various items. We have also implemented a system to notify customers about DHL’s Remote Area Surcharge (RAS) payments if their geographical location is deemed as ‘remote’ by DHL. Massive thanks to Marek (Gamiee) for getting this working - it was a difficult feature to incorporate. A quick word of caution about the RAS notification feature; our implementation of the RAS notification is based on a location list we received from DHL. The list includes thousands of entries and we cannot guarantee that it will always be up-to-date at all times despite our best attempts. Checkout and payment options in the new Pine store\nSeeing as I know someone will ask about this; we are still working towards a cryptocurrency payment arrangement that would work well for us and our community members. We are talking to multiple parties and trying to find some sustainable arrangement - I hope that one can be reached in the coming weeks. As many of you have noticed, the Pine Store has also moved to a dedicated .com domain - pine64.com - from its previous subdomain at store.pine64.org. The purpose of moving the store to a commercial domain is to denote its separation from all community-run services and subdomains at pine64.org. We hope that this will help distinguish the two sides of PINE64 - that of a business and a community run project. I’ve also been working towards setting up a dedicated European Pine Store for a couple of months. Under normal circumstances the process would be relatively trivial, but unfortunately current travel restrictions are making it difficult to complete all formalities involved with getting this off the ground. Without getting into unnecessary detail - the store will be registered in a different EU country to where I reside, and physical presence is required to complete portions of the paperwork submissions. Given current travel restrictions in Europe, I think it will be a couple of months before I get everything sorted - I’ll make sure you know when it is all ready to go.\nBefore I head off and talk about another topic, there is one more thing I’d like to mention with regards to the store. Apart from upgrading the store front-end, we also did a lot of work on the store’s backend. You should now reliably receive store order and shipping notifications in your mailbox; if you do not, however, please make sure to reach out to myself, Marek (Gamiee) or Matthew (fire219) in the chats. Lastly, I have been in talks with a handful of community content creators for the past couple of months regarding our existing Youtube and newly started LBRY channels. I have now reached an agreement with PizzaLovingNerd, who will create monthly videos to compliment the written monthly community updates. I also hope to develop a show-and-tell Youtube/ LBRY series - perhaps one that would actively engage with the community and involve the developers. If you’re interested in creating content for the PINE64 Youtube/ LBRY channels and have other ideas, then please make sure to reach out to me in the chats or elsewhere. Pinebook Pro and PineTab availability status I feel like a paragraph concerning the Pinebook Pro and PineTab is in order given the frequent questions about pre-order availability. As things stand, we have all the bits and pieces - bodies, mainboards, other electronics, etc - to manufacture PineTabs and Pinebook Pros, but we’re still missing the much needed LCD panels. As I mentioned in last month’s update, back-to-school programs run by large companies created a severe LCD shortage on the market. The market, which already suffered from low panel volumes (caused by the COVID-19 pandemic), has now been practically drained of grade-A LCD panels within the target price-range. As I explained last month, purchasing from the open market isn’t an option. Open market LCD panels come without warranty or reliable quality assurance that vendors always offer.\nAccording to some projections LCD panels ought to be available again in December. Granted this projection is accurate, we may see new batches available prior to the Chinese New Year (February 2021). I will, of course, keep you updated on the situation in future community updates.\nPinePhone Manjaro CE presentation box design\nThe Manjaro PinePhone CE OS image, which will ship with the upcoming PinePhones, was sent to the factory just the other day (congrats Manjaro team!). Personally, I feel that this is the most end-user ready OS image to ship on the PinePhone thus far. This isn’t exactly surprising given that the Manjaro team has had the most time to create an OS image and benefited from the overarching development on the platform. The OS image ships with Phosh and is probably the smoothest experience on the PinePhone to date. Moreover, to my knowledge - and I’ve tested the software extensively - all major features of the phone work with Manjaro. It also features a solid variety of well-tuned applications to get you started, including Firefox, GNOME Maps and Megapixels camera application, just to mention a few. Don’t get me wrong, the software will still require a layer of polish to be considered ‘daily-driver’ worthy by a broader audience, but I have been running it exclusively on my phone for weeks and it has been a great experience.\nBefore moving onto talking about hardware, let me quickly mention the awesome work Martijn Braam from postmarketOS has been doing with the camera. His Megapixels application now supports both the front and back cameras, a smooth viewfinder (at 720p), manual ISO and shutter user-facing controls, autofocus (!!) as well as various forms of post processing. This application has greatly benefited the community as a whole, including the upcoming Manjaro CE. Frankly speaking, I’ve been blown away by the camera’s performance. Please read Martijn’s blog for more technical details; I am attaching two pictures taken on the Manjaro CE device for you to check out.\nNo one wanted to pose for pictures, so its my kid\u0026rsquo;s dinosaur (main camera, picture down-scaled) and me (front-facing camera). Higher quality main camera picture here\nI have a handful of exciting hardware-related topics to discuss, including news about back covers with additional functionality and the physical keyboard for the phone. Let\u0026rsquo;s start by talking about the custom back-covers. As we said from the start of the PinePhone project, we’re planning on adding functionality to the phone via custom back-covers that will communicate with the phone via the pogo pins. The first two covers will introduce Qi wireless charging and NFC to the PinePhone. Qi wireless charging already works since it doesn’t require software, but NFC implementations will obviously require software enablement. The Qi charging back-case has been ready to go for some time, but as it turned out the coil and electronics couldn’t fit into our current cover design. The back-cover design had to be retooled slightly to accommodate the new functionality - the physical space was increased to accommodate the additional electronics - and you’ll be happy to know that we’ll release the new STL file on the Wiki so you can experiment with creating your own add-ons. This is just the start, we have more ideas for future add-ons which I’ll be sharing with you in the coming months. Here is the Qi wireless charging coil we\u0026rsquo;ll be using\nI’m also happy to let you all know that 3GB/ 32GB PinePhone mainboards will be available in the Pine Store in November. If you already have a PinePhone and want to upgrade to the higher capacity and RAM variant, you don’t have to buy a new unit - just the mainboard. We also have a little token of appreciation in store for early adopters (Braveheart and UBports CE) owners who wish to upgrade their mainboards, but I won’t spoil the surprise in this post.\nLastly, we have given a hardware vendor the green light to start preparing a prototype of the keyboard for the PinePhone, and the vendor has informed us that they’ll strive to have the prototype ready by the end of this year. We find this schedule for delivering the prototype difficult to achieve, but at the same time we (all of us) are looking forward to being pleasantly surprised if they manage to pull it off. I am including the renders for you to check out below.\nPinePhone keyboard render\nAfter some consideration we have opted to go with a clamshell design for the keyboard. The PinePhone is large and heavy enough to be unwieldy when held by a thin slab of plastic such as that of a slide-out keyboard. This clamshell design can, however, be folded practically flat so it is comfortably used without placing the device on a surface. The keyboard section also holds a large (probably 5000mAh) battery, which not only more-than-doubles the phone’s stand-by time but also acts as a weighty counterbalance. Many of you will also recognize that we decided to use the keyboard layout we proposed and discussed with the community in August. From a mechanical standpoint, the keyboard clamps onto the phone (for which you need to remove the back-cover) and interfaces with the device using the pogo pins. I’m sure this news will get many of you excited, but please keep in mind that presently it is impossible for me to guarantee that this particular plan for the keyboard will pan out and that the vendor will come through on their promises. But I think there is a good chance it will happen, so I decided to share it with you.\nSOEdge The SOEdge AI modules and the accompanying model-A baseboards have now been delivered to us from the factory. However, the SOEdge currently suffers from a chicken-and-the-egg problem: there is no Linux software running on the device. This, in turn, means that it cannot be sold to end-users (even enthusiasts). What the SOEdge needs at this point in time is a group of developers keen to lay the foundations for getting the module up and running. I took a look at the BSP offered by Rockchip and it seems like a good starting point (unless there is already an ongoing mainlining effort I am not aware of).\nConsider this a call to action; if you’re interested in working on the SOEdge make sure to reach me in the chats or the forum (start a public thread). Needless to say, the device has a lot of potential and not only in the realm of AI but also more traditional computational applications. The SOEdge offers fast IO, including PCIe 2x and USB-3.0 as well as Gigabit Ethernet, making it ideal for a variety of high-throughput and low-power applications. Aside from its powerful NPU, the device also features 2GB of PC-2133 RAM and a dual-core cortex A35 running at 1.6Ghz.\nSOEdge socketed in model-A baseboard\nThe development model-A baseboard features all key connectors and I/O, including USB 3.0 and PCIe 2x (either PCIe or USB 3.0 can be used at the same time), Gigabit Ethernet, MIPI DSI, MIPI CSI, SDIO (compatible with current WiFi/ BT modules) as well as touch panel input and CSI. You also get a full GPIO header, RTC, SPK and bootable SD card slot (there is also an eMMC mount on the SOEdge module). As you can see, the range of possibilities the module offers is quite extensive and I trust that a group of interested developers will pick it up.\nPineCube In the event you’ve missed it, the PineCube is now available for purchase in the Pine Store. If you’re interested in helping to get this little FOSS IP camera off the ground, here is your chance. I am told that software progress on the PineCube is coming along well but it\u0026rsquo;s all in very early stages. From a development standpoint, the goal at this point is to build a mainline Linux (Debian) OS image. Marek (Gamiee), who is currently working towards making such an image, is currently waiting for some u-boot patches that will allow the PineCube boot from SD card as well as writing a video encoding library for the mainline kernel. The PineCube\nBy the time this post goes live the PineCube chat and forum infrastructure should be available, and I highly encourage you to engage with others at this early stage of bringing the PineCube up. I’d also like to point out that the PineCube Wiki page is now up with some very rudimentary information to get you started. Anyone can create a Wiki account and contribute to any of the existing device subsections; as per usual, it will take a community effort to get this project up and running.\nPineCube compatible m12 lenses\nWe will soon also offer a wider range of m12 mount lenses. We’ll make sure to provide a wide selection of lenses for a variety of applications, including a long range zoom and a fisheye 185 degree lens. I’m not exactly sure when these will become available in the store, but it shouldn’t be long until you can pick up a set alongside the PineCube itself. Pinecil The Pinecil is proceeding well and, thanks to the hard work of Ben Brown on porting the firmware to RISC-V, for the most part operational. The firmware will still need some degree of tuning, but the all features of the soldering iron have now been enabled and are working which means it will be available for purchase soon. Hardware-wise, the molding for the Pinecil is now finished and the pre-production units feel great in the hand. I am attaching a picture and a render below: the picture shows the Pinecil prototype running (powered via USB-C in this particular picture) while the render shows the final look of the iron that we settled on, with a PINE64 blue accent on the rubber grip. Fully functional Pinecil prototype\nRender showing final look of the Pinecil, with the blue rubber handle\nThe Pinecil will ship with a B2 tip, but two additional tip sets will be available for purchase on launch day - each priced at $24.99, the same price as the Pinecil itself. I am attaching a picture of both tip sets below so you can check them out. If you already have a TS100 iron and an accompanying set of tips, then you’ll be happy to learn that your existing tips will work with the Pinecil. Set 1 (left) and Set 2 (right) of soldering tips for Pinecil\nLastly, something admittedly a bit crazy - we have created a Pinecil breakout board which exposes all of the SoCs available pinouts and protocols. To be precise the breakout board exposes ADC/DAC, SPI, UART. SPI, USB and JTAG. The board attaches to the USB-C port on the Pinecil, allowing the device to be fully operational and fully assembled when tinkering. So yes, the breakout board converts the Pinecil into a single board computer of sorts… or, at the very least, a tinkering device. I am sure that many of you will find some type of valid application for this breakout board and come up with innovative applications for the device. I am attaching a picture of Pinecil mainboards and the breakout board below. Pinecil mainboard PCB (top) and break-out board PCB (bottom)\nPineTime This month, the PineTime project reached a new milestone - the new PineTime development kit is (finally) available in the Pine Store. This new batch of PineTime development kits now ships preloaded with InfiniTime, the very first FOSS firmware to be programmed at the factory into the smartwatch! I\u0026rsquo;ve already seen many people have received their new PineTime devkit and quickly began to test InfiniTime, flash new firmwares and even develop new functionalities and projects.\nPineTime running InfiniTime - picture by JF\nAs the maintainer of InfiniTime, I noticed this new crowd of PineTimers by the number of bug reports, questions, suggestions as well as pull-requests the project received this last couple of weeks. I\u0026rsquo;m really happy to receive all this feedback from people all around the world, and I am proud that people actually help me build and improve the project I started nearly 1 year ago! I would like to thank anyone who has already contributed to the project, and I\u0026rsquo;m sure that this is just the beginning of a great journey.\nAround the same time as the devkits became available in the store I released a new version of InfiniTime. This version has been tested by many members of the community, so it should be safe to upgrade (OTA via BLE) your development kit. This new version of the firmware brings many improvements and a music control application. That\u0026rsquo;s right, InfiniTime paired with the new version of Gadgetbridge adds support for the music and playback control on your Android phone directly from the PineTime. I\u0026rsquo;ve also heard that even more new features like OTA are in the works thanks to @Avamander.\nAvamander is also working on improving the music application of InfiniTime by adding a nice animation, song progression and support for touch gestures. PineTime music control on Android smarphone\nI was also amazed to see people writing games for the PineTime! Here is a Pong game by @Electr0Lyte https://twitter.com/SravanSenthiln1/status/1312961476580175873?s=20 and a breakout game by @TT_392 https://www.youtube.com/watch?v=5rt6C1FeglM. This last video also introduced you to Lupyuen\u0026rsquo;s new innovation - the remote pinetime. Lup wrote a Telegram bot that allows people who haven\u0026rsquo;t received their devkit yet to flash their firmware into his own PineTime. This development kit is streamed H24 on Youtube: https://www.youtube.com/watch?v=U4EhPuKqEG8. Crazy idea, but it works!\nOne last project I would like to highlight this month is the test framework of @maiden. This test framework will ultimately run automatic test sequences on new versions of the firmwares for the PineTime while measuring the power consumption of the device. This tool will be invaluable to ensure that new versions of our firmware work correctly prior to release.\nThe PineTime community is literally boiling with activity and new ideas pop out every day, it’s really exciting!\nPineCom Abstract PineCom illustration\nEarlier this month we asked what you’d like to see in a small PDA-style IoT device, which will rely on LoRaWAN, WiFi and other alternative protocols for communication. We envision the device to be small in size - with a 5” or smaller LCD panel - and possibly quite modular. The PineCom would also be based on the same underlying architecture as the PinePhone, sharing many of its core features and making it pin-for-pin software compatible. As the name of the device indicates, the idea behind the PineCom is to explore alternative communication methods, but I can also see it being used for a variety of IoT applications, as a portable media player as well as a Point Of Sales device. I’m sure that you can think of other applications too. I also need to note that the idea for the PineCom has been met with a fair bit of push-back from the community. Browsing the comments, those who oppose the introduction of a new device appear to think that it may detract from PinePhone development. There is also another group of people, lobbying for having PineCom’s features implemented into the PinePhone via custom back-covers and the i2c protocol. Let me address both points. The PineCom will not detract from PinePhone development because the new device will be compatible with existing PinePhone OS images. If anything, PineCom may bring new developers into the our ecosystem; but even if not, I cannot see it being a hindrance or draining existing resources. Secondly, having LoRaWAN and other alternative protocols enabled and working in Linux on the PineCom may actually convince us to create custom back-covers with these protocols for the PinePhone. At any rate, I am really happy to have received so much feedback regarding this device. We will monitor the thread for weeks and will, most certainly, take all reasonable feedback under advisement. On a personal level, I don’t find the fears grounded in reality, and I’ll do my best to persuade you about it in the months to come. Ultimately however, if the community decides that the arguments are unconvincing and remains adamantly against the device then we won’t make it.\nThat\u0026rsquo;s all for this month, make sure to subscribe for some really exciting news the next month!\n","permalink":"/2020/10/15/update-new-hacktober-gear/","tags":["pinecil","pinecube","pinephone","pinetime","soedge"],"title":"Update: new hacktober gear"},{"categories":["news"],"contents":"PINE64 (both the business and the community around it) prides itself on transparency. Often, this transparency is used to give you a behind the scenes look into our operations. But today, we\u0026rsquo;re afraid we must be transparent about something else.\nAs of approximately 4:30am GMT on 2020/09/17, we discovered an intrusion to our Pine Store web instance. This took on the form of spam/scam pages hidden on our web server, with scripting to only be visible to crawler bots. After discovering this, we immediately shutdown the web server and began investigation. To our knowledge, this happened via an exploit in one of the Wordpress plugins on the Pine Store, with initial attempts logged as early as 2020/09/05. It appears this was not an active malicious attack on our server, but merely automated bots tasked with placing scam store pages. Needless to say, we remedied the situation and took extensive steps to prevent similar incidents from occurring in the future. Due to the nature of the attacks we’ve reviewed, we do not suspect that customer information was a target, nor we expect any was exfiltrated. We can guarantee that, without a doubt, no credit card or other financial information was placed at any risk of being exposed. We hope that this event does not damage your trust in us beyond repair, as we work to recover from this event.\n-- Lukasz Erecinski, Community Manager\n","permalink":"/2020/09/17/psa-vulnerability-disclosure-2020-09-17/","tags":null,"title":"PSA: Vulnerability Disclosure 2020/09/17"},{"categories":["community","cube","news","pinebook-pro","pinephone","pinetab","pinetime"],"contents":"\nWe have been fortunate to welcome many new members into our ranks over the past 30 days. This is in large part due to the continued interest in the Pinebook Pro and PineTab, which have just shipped, as well as the ongoing massive demand for the PinePhone. By my estimate, come December we will have shipped more PinePhones than OpenMoko and the original Ubuntu Touch smartphones … combined. Let this sink in for a minute. I’d also like to thank JF for once again providing this month’s PineTime community update.\nThere is plenty of stuff to get to, so let\u0026rsquo;s get to it!\nThis month’s TL;DR: Shipping is coming along quite well; stay tuned to shipping updates on the forum New Pine Store in the works; not only will it look better but will also support more payment options We’re an Arm ecosystem partner now; Pinebook Pro laptops will be give-aways at this year’s Arm Dev Summit Pinebook Pro: production halted temporarily due to LCD panel shortages (hopefully will resume in 2 months time) Pinebook Pro: check out the Fedora 32 community build with a choice of multiple DEs PineTabs are being delivered; positive initial reception Mobian and Arch Linux builds are now also available for the PineTab PineTime dev kits with InfiniTime ought to be available in Pine Store September 20 PineTime Hypnos - a Zephyr based firmware spotlight PinePhone Manjaro CE available for pre-order September 17 PinePhone software development: 13 OSes, multi-boot, and the p-boot bootloader is awesome PinePhone camera implementations on Ubuntu Touch; 30FPS viewfinder and Qt 5.12 updates PinePhone Megapixels camera postmarketOS app; both main and front cameras working, and taking higher-resolution pictures PineCubes are awaiting assembly; should be available in the store later this month Housekeeping The first topic on the housekeeping agenda concerns shipping. Generally speaking, this round of shipping is proceeding pretty well. Most DHL shipments have already been dispatched and delivered, as have regular shipments for most destinations bar Europe. For those of you waiting for your device to show up, please make sure to follow the forum shipping thread; I’ll keep posting updates until the dispatch process comes to an end. In summary, I think that the grand majority of devices will be shipped and delivered before the month is up. If you have any questions concerning shipping, make sure to post your question in the aforementioned forum thread. Second subject I’d like to touch on in this segment is the announcement that we’re actively working on a new store. It will be a couple of weeks yet before it goes live since we’re redoing everything, including the store database, which means adding all entries and accompanying descriptions manually. Apart from a facelift, the store will also feature alternative payment methods. At this point we’re happy to announce that Stripe will be available when the new store launches. Other services may also be available at the time of launch or shortly thereafter. We’re also working on implementing crypto currency payments - however, for reasons I will not get into, at this time we’re experiencing issues with implementing coin payments. More information concerning the store and available payments will be made available prior to the store’s launch sometime next month. New Pine Store sneak peek\nAnother major piece of news is that last month we became an Arm ecosystem partner. This is obviously huge for us, and we are both honoured and thrilled to be invited by Arm to take part in this program. Just this past week additional information about PINE64 has been added on Arm’s website, with annotations to the Pinebook and Pinebook Pro laptops, as well as an entire dedicated sub-section concerning our hardware solutions, project’s philosophy and the community. But this isn’t all. For the past month we’ve been working with Arm Software Developers representatives to make Pinebook Pro laptops this year\u0026rsquo;s give-aways at the Arm Dev Summit 2020. Up-to ten lucky developers being part of the Arm Innovator Program will receive a Pinebook Pro as recognition for their ongoing efforts on the Arm platform. Speaking of the Arm Dev Summit, I suggest you sign up for the event and attend the Linux AArch64 Laptops BoF talk scheduled for October 6, 11:00AM PDT. Lastly I want to give Robert Wolff from Arm a huge shout-out for being so helpful, accommodating and easy to work with - cheers!\nPINE64 on Arm\u0026rsquo;s website\nLastly, we’ve been making upgrades to the PINE64 cluster which now powers most of our infrastructure. The most recent upgrade to the cluster will, on the one hand, significantly increase individual nodes’ stability (iSCSI implementation) while, on the other, improve our ability to remotely control and reboot individual ROCKPro64 nodes. This is a significant step forward as we hope to get more services added to our infrastructure in the coming months. I’d like to give Marek (gamiee) a huge shout-out for the time that he put into getting the cluster setup at the datacenter - well done! Pinebook Pro I am afraid I have some bad news. Back-to-school programs of large laptop manufacturers, in conjunction with the pandemic-induced production freeze earlier this year, resulted in LCD panel shortages. This in turn has now led us to halt production of the Pinebook Pro for a month or two. We have the laptop chassis, all the components and the PCBAs, but we do not have the LCD panels. To continue production at this time, we would have to buy LCD panels from the open market, and we’re not keen on doing that. Let me explain. When we buy panels directly from a vendor, then we receive a quality assurance that the batch we purchased measures up against standard LCD panel rating. Quality assurance of this sort is impossible when buying from the open market rather than from the vendor directly. Not only would we be paying more for the panels, but we would also be taking a considerable risk that the LCDs will be of a poor or varying quality. We suspect that it will take a month or two for the LCD manufacturers to replenish their stock, at which point we’ll acquire suitable panels and Pinebook Pro production will resume. We currently hope to offer pre-orders for at least two batches prior to the Chinese New Year, which begins early February 2021. There is still a sizable amount of ANSI Pinebook Pros available in the Pine Store, which I suspect will last until the end of September; ISO units will, however, remain unavailable for the next two months or so. I will make sure to keep you up-to-date on how the LCD situation looks in the upcoming community update. Were the situation to change suddenly - which is unlikely but not impossible - then I’ll make a separate short post on the subject. In other news, I am still waiting for information from developers on whether they can successfully enable HDMI output on the Pinebook Pro’s dock. The HDMI output has been confirmed to work on the BSP kernel, so it is just a question of the mainline kernel supporting the dock’s hardware. It is my understanding that currently, in the newest Manjaro release (which I highly suggest you check out or upgrade to), the DP alt mode is broken (to fix it - manually install linux-pinebookpro via pacman), which may further slow things down. Regardless, we will not release the dock until we know that it works well with the default software. Simply put, we fear people emailing support or requesting RMA for what they would view as dysfunctional hardware. Fedora 32 with GNOME - image via Radek Pawlinski\nSoftware wise, we keep looking forward to the release of elementary OS 6, which was announced in last month’s update. If you want to support the elementary project and get your hands on daily builds of elementary OS for the Pinebook Pro, then consider entering their early access scheme. The OS has now been added to the Wiki and will be made available once elementary OS 6 rolls out. In other software news, I\u0026rsquo;d like to talk about Fedora for the Pinebook Pro. It has now been 5 months since Fedora’s announcement of support for PINE64 devices, but an official Pinebook Pro build has not been made available to date. Thankfully there is now an excellent community build, which features all core functionality of the Pinebook Pro and uses (from what I can tell) very few patches to achieve this. You also get a choice of desktop environments - including XFCE, GNOME, KDE Plasma and Cinnamon, all of which performed really well in my testing. So, If you are a Fedora fan, then I recommend you give this community a go. PineTab Earlier this month PineTabs were sent and, in most instances, delivered to early adopters. Let me begin by apologizing once again for the 2 week delay in delivering the PineTabs; shipping from Hong Kong remains a burdensome arrangement under the current regulatory regime. The process is a real jigsaw puzzle, where the variables of time, quantity and weight all need to be precisely synced for shipment. With that out of the way, let’s talk about the device itself. For starters, we’ll be monitoring hardware-related feedback over the coming weeks so that if any unforeseen issues are found we’ll have the head-room to apply alterations to the design. Thankfully it appears that there are no major issues - as these would have surely already been documented and brought to our attention. As things stand, all the issues I’ve seen reported are directly related to the work-in-progress status of the available software.\nSpeaking of PineTab software, we’ve seen a lot of development in the past two weeks. For starters, Mobian - one of the most popular and fastest growing OSes on the PinePhone - announced support of the PineTab earlier this month. I am told (seeing as I don’t have a PineTab myself at this time) that the operating system works really well in both stand-alone tablet mode and when paired with the keyboard. Nightly Mobian releases are available for download and can be booted from either the onboard eMMC flash or a SD card. But there is more; we have also received a great community build of Arch thanks to Danct12. For those of you who do not know, Danct12 is a community developer who brought Arch to the PinePhone. The Arch image is - as you’d probably expect - very cutting edge, and includes much of the quality-of-life improvements present in the PinePhone image. You can find the latest pre-release of Arch for the PineTab by clicking this link. Mobian on the PineTab - image via devrtz from Mobian Project\nWhile we’re already on the topic of software, let me squeeze in a quick PSA and offer some advice pertaining to the Ubuntu Touch build with which the PineTab ships. As many of you have noticed, the build only reports ~15GB of free flash storage. The reason for this is that the development tablets only feature 16GB of eMMC, as opposed to the 64GB found on the production PineTab units. If you switch over to the Release Candidate channel in the system menu, and apply the update, you’ll have the User Data partition resized to take up all remaining unallocated disk space. Thanks to Dalton from UBports for getting this day-one fix out quickly!\nArch Linux on PineTab - image via Danct12\nLastly, I currently do not have a date for when we’ll resume production of the PineTab. As I already wrote, we want to gather users\u0026rsquo; feedback and wait until the current LCD shortage passes (see Pinebook Pro section for details). Since I know many will ask for an approximation - let me tentatively say that the next pre-order round will start no earlier than in one month’s time. In the meantime, I encourage you to sign up to this blog and follow us on our social media accounts to stay up-to-date on the PineTabs software development. PineTime The PineTime dev kits have been out of stock for quite a long time, and many of you have been waiting for the new batch for a long time. Here is some good news: the wait is almost over!\nLast month, I explained that we had encountered some difficulties with the programming of InfiniTime on the PineTime at the factory. These issues have now been solved, and the factory sent a sample to Lup and myself to check them out in the picture below.\nNew PineTime dev kit - image via Lup Yuen Lee\nAnd it turns out that the result is nearly perfect - the PineTime running InfiniTime works as expected, all the devices are working correctly and the upgrade to a new version of the firmware was also successful!\nThe only issue encountered involved the memory protection, which was still enabled. This feature is enabled in production devices so that people can’t snoop into an nRF52 gadget and tamper with the ROM, but it is absolutely not relevant in the context of open source software. So we wanted to take this opportunity to disable it at the factory, so that future developers do not need to buy expensive equipment to disable it themselves.\nA new sample is en route to Lup\u0026rsquo;s. He should receive it one of these days and hopefully confirm that everything is now alright, and that the memory protection has been removed.\nIf all goes well, PineTime dev kits should be in stock on September 20 along with the new pogo pins, a new tool that eases the connection to the SWD pads on the mainboard of the watch.\nNew pogo pin programming tool\nThis month, I would like to showcase Hypnos, a Zephyr based firmware for the PineTime by endian-albin. He made a lot of progress these last few weeks and the first version of the firmware was released a few days ago. The most interesting feature of Hypnos is that it supports the same bootloader and OTA procedure as that used in InfiniTime. It means that it is now possible to switch from InfiniTime to Hypnos and vice-versa using BLE. In the future, PineTime users will be able to choose the firmware they want to use and even easily switch from one to another as easily as Pinephone users distro hop between many Linux distributions!\nHypnos running on the PineTime\nPinePhone Let’s get the piece of information everyone is waiting for out of the way first: the Manjaro Community Edition PinePhone will be available for pre-order this Thursday, September 17. In the event you didn’t catch the announcement, here is a quick recap: the Manjaro community edition will ship in a custom presentation box designed by Manjaro’s development team, and the PinePhone itself will feature a sleek-looking Manjaro logo on the back-cover (see renders for reference). The device will also ship with the newest PCB revision (1.2a) and be available for pre-order in two hardware configurations: $149 standard version — featuring 2GB RAM and 16GB eMMC internal flash storage. $199 convergence package — equipped with 3GB RAM and 32GB eMMC flash storage as well as a bundled USB-C dock. Our friends at Manjaro currently offer three different flavours of their mobile OS for the PinePhone - with Lomiri, Phosh and Plasma Mobile. While it remains to be seen which the Manjaro team will settle for, all images are great and if you are a fan of the project you probably will want to try all three, regardless of which build ends up shipping with the device. For those of you who already have a PinePhone, I strongly suggest giving all these builds a go - click here to head over to Manjaro’s PinePhone CDN. Now, onto other software news. There is currently so much ongoing software development that I will not be able to cover all the important strides made in the past month. There is simply too much stuff happening across many projects on a nearly daily basis. So, instead, I will focus on the three things I found the most interesting. To this end, hands-down the coolest of all recent developments is Ondrej (megi) Jirman’s multiboot image, which allows one to boot multiple phone distros from one installation (eMMC flash or SD card). It features a very snappy, intuitive and surprisingly polished bootloader - called the p-boot - that appears instantaneously after you power on the PinePhone. All installed distros share the newest kernel (5.9), modem power management and latest Crust firmware. Needless to say, I feel that this a very valuable tool, especially at this early development phase of bringing the software up, as it allows users to check out numerous popular OS builds; moreover it exposes users to builds they would otherwise likely omit, such as Lune OS or Maemo Leste. It currently only supports PinePhones with PCB revisions 1.2 and 1.2a, but megi has publicly stated that future iterations of the image will also support Braveheart (1.1) PinePhones soon. I strongly suggest you give it a go. p-boot details - screenshot of megi\u0026rsquo;s website\nThe second thing I’d like to bring to your attention is the array of improvements made to the camera. In this respect there are two OSes that truly stand out right now - Ubuntu Touch and postmarketOS. While many distributions already have the camera enabled, the viewfinder experience and picture quality remain suboptimal. This, however, is about to change thanks to the awesome work from the UBports development team, which demonstrated the viewfinder running at steady 30FPS and taking better-looking pictures. Moreover, Ubuntu Touch - which already received an incremental performance improvement patch recently - will be seeing a move to QT 5.12 in the foreseeable future. This will result in a major performance improvement of the operating system; this is something I can vouch for, since I got a chance to experience Ubuntu Touch with QT 5.12 just the other week. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Viewfinder on Ubuntu Touch - via Marius Gripsgard\nGoing back to the ongoing camera enablement efforts - Martijn from postmarketOS has been working on a camera application that supports both the main shooter as well as the forward-facing selfie camera. But there is more, not only does the front and main shooters work, the app allows the main camera to take higher resolution pictures (1080p) by default. You can also change the camera settings by editing /etc/megapixels.ini t_o your liking,_ which also includes altering the front camera’s setting, allowing it to capture 1600x1200 still images. The application, which Martijn called Megapixels, should be making an appearance on postmarketOS today, and I suspect that other distributions will be porting it to their builds soon enough. Front and back camera on the PinePhone - images via postmarketOS\nLastly, I want to give a shoutout to Adam Pigg, who has been working on a port of SailfishOS for the PinePhone (Yes, I know, it’s not fully FOSS - put the pitchfork down and keep on reading). I have recently given SailfishOS a try and I must say that I am very impressed with both how smooth, functional and all-around polished the PinePhone build is. Opening applications, swiping between active panels, pulling up and down the application and task drawers all feel very smooth. Same goes for browsing the web (including LTE) or watching local video playback. It is clear to me that a lot of work has gone into this community port of SailfishOS, and I think more people ought to give it a proper go. The latest build of SailfishOS can be easily flashed using a special script to a SD card or Jumpdrive-mounted PinePhone. PineCube A large stack of PineCube PCBAs is currently awaiting assembly. All that is currently missing is a delivery of the plastic frames, which keep the three PCB elements in their respective positions and give the device its cube-like appearance. This last piece of the puzzle should be arriving this week, which means that PineCubes should be available in the store next week! As is the case with many of our devices - especially ones that need to build up a community around them - the PineCube will initially be sold with a disclosure that it is strictly meant for developers and enthusiasts, willing to work on software enablement for the device. To learn more about the PineCube and its features I invite you to read last month’s update, where I went into details listing the device’s specifications and planned add-on peripherals. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video PineCube presentation box\nI leave you with a short movie showing off the packaging box the PineCube will ship in. I trust you’ll enjoy it.\nThat is it for this month!\n","permalink":"/2020/09/15/september-update-let-it-sink-in/","tags":["pinebook-pro","pinephone","pinetab","pinetime"],"title":"September Update: Let it sink in..."},{"categories":["news","pinephone"],"contents":"\nI am thrilled to announce that the next Community Edition (CE) of the PinePhone will feature Manjaro. For those of you who do not know, Manjaro is an Arch-based Linux operating system designed with user-friendliness in mind. But Manjaro is more than just an operating system, it is also a large and vibrant community of contributors and end-users, which I highly encourage you to join.\nManjaro has offered support for PINE64 devices since the very beginning - with high-quality OS builds now available for nearly all our SBCs and devices - and the PinePhone is no exception in this regard. There are currently three Manjaro PinePhone build variants (Lomiri, Phosh and Plasma Mobile) for users to try out - all available for download from Manjaro’s downloads repository.\nTo learn more about Manjaro\u0026rsquo;s plans for their edition of the PinePhone, please read the complimentary announcement post on their forum.\nThis community edition will ship in a custom presentation box designed by Manjaro’s development team, and the PinePhone itself will feature a sleek-looking Manjaro logo on the back-cover (see renders for reference).\nThis PinePhone CE will be available in two hardware configurations:\n$149 \u0026ndash; 2GB RAM; 16GB eMMC\n$199 \u0026ndash; 3GB RAM; 32GB eMMC (includes a bundled USB-C dock)\nBoth configurations of the Manjaro CE PinePhones feature rev. 1.2a PCBA, introduced with postmarketOS CE that is currently shipping. The $199 hardware variant, called convergence package, also features a USB-C dock equipped with 10/100 Ethernet, 2x USB type A ports, HDMI digital video output and power-in via USB-C.\nWe will donate $10 per unit sold to the Manjaro development team. To learn more about this scheme please click here.\nPre-orders for the Manjaro Community Edition PinePhone open mid-September. To be notified when pre-orders go live make sure to subscribe to this blog, the Telegram PINE64 News Channel (not chat) and follow us on Twitter and Mastodon.\n","permalink":"/2020/08/31/pinephone-manjaro-community-edition/","tags":["convergence","linux","manjaro","pinephone","smartphone"],"title":"PinePhone Manjaro Community Edition"},{"categories":["news","pinebook-pro","pinecil","pinephone","pinetab","pinetime"],"contents":"\nelementary OS 6 Odin on Pinebook Pro - image via Alan Pope\nI am currently traveling and have a limited amount of time to write, so I’d like to apologize in advance for not covering all topics and not answering outstanding answering questions that some of you are waiting to hear about. I also had less time to review chat backlogs, tweets, the forum and other information sources, and in result it is possible that I missed some information which ought to be covered.\nI’d also like to thank JF for covering the PineTime progress leading up to the early adopters edition of the PineTime, which will be available for purchase in the coming weeks. TL;DR for this month\nNew and clear rules of community engagement are coming PINE64 logo and brand-name infringements Pinebook Pro production is on schedule; factory will deliver PBPs to us on 24 August Pinebook Pro is getting elementary OS 6 Odin support! A look at the Pinebook Pro USB-C docking station; waiting for software support PineTab delayed one week; volume button flex cable mistake A look at RTL-SDR and LoRa expansion expansion boards for the PineTab PineTab pre-orders reopen late this month Last chance to get the postmarketOS CE - sold out any day now. PinePhone: we’re on a roll and we’re not slowing down (until CNY) PinePhone community hardware mods and awesome projects We’re exploring keyboard options for the PinePhone Notable PinePhone software developments Pinecil coming in September; a tipset will be available at launch PineCube positive response; available in September/ early October PineCube accessories - LCD panel and battery Housekeeping A recent series of events led me to rethink our formal rules of community engagement. As the community grows - and at a rapid pace at that - moderators and community members need to have clear guidelines to reference concerning the type of engagements we, as a community, are willing to accept. Before I write anything else, let me start by saying I am not a fan of heavy-handed moderation; I believe that just as in everyday life you’ll eventually run into a jerk in any community. This is just how life is, and I don’t believe that it\u0026rsquo;s the role of moderators to educate people about civil conduct. But there are certainly some new and worrying trends that need to be addressed, so I’ll be writing up a new code of conduct / community rules in the coming weeks. The reason why I am mentioning it in this section, is because I’ll be posting the draft of the new rules on the forum so that we can debate various aspects of the rules and (hopefully) agree on some of the more nuanced points I intend to make. The second topic I wanted to touch upon in this section concerns the use of the PINE64 logo and brand-name. We have recently experienced three types of infringements: 1) online resellers selling PINE64 hardware pretending to be Pine Store Ltd.; 2) merchandise sellers using our logo on swag without consent and; 2) our logo being used and misused without our consent in undesired contexts. In result, we are currently working on precise guidelines pertaining to the use of our logo and brand-name. This will arm PINE64 community and Pine Store Ltd., with the necessary documentation to tackle instances of infringements (e.g. when sending out Cease and Desist notices to parties at fault) and when seeking legal recourse. This documentation will be available on the PINE64 Wiki next month. For those of you who wonder, here are the general rules concerning the use of the PINE64 logo and brand-name. You are allowed to use, alter and replicate both the logo and brand-name for non-commercial use without any prior consent. This extends to both software and non-software material. If you are one of our partner projects you’re welcome to use our logo alongside your own in commercial software or in promotional materials. For small-scale commercial use benefiting the community - such as, for instance swag, hardware add-ons or embellishments (e.g. protective vinyls) - you’ll receive consent after contacting us. All other use of the PINE64 logo or brand-name in a commercial context requires consent which can only be granted by Pine Store Ltd., in a legally binding document. Lastly, if you haven’t done so yet I’d like to invite you to watch Matthew (fire219) Petry’s talk on Matrix’s Youtube channel. Matthew spoke about the PINE64 community, the separation of competences between the community and Pine Store Ltd., as well as his hurdles with getting the ROCKPro64 cluster fully functional. https://www.youtube.com/watch?v=tJ8tthkVAOQ\u0026t=1s\nOpen Tech Will Save US Meetup #5\nPineBook Pro Let me start by assuring you that the current Pinebook Pro batch is still on schedule and will be delivered to us, from the factory, on August 24. This is yet another large batch of Pinebook Pros, and it will surely bring in new developers to the existing talent pool as well as draw the attention of prospectus partner projects. As you will find out further on in this section, this is also arguably the best time to be getting your unit as support for the device is growing. As for the hardware itself; for this batch of Pinebook Pros - as well as for all future production-runs - we are using a third-party QA service to give the laptops a thorough check prior to shipments going out. This is an arrangement which we reached via a mutual understanding with the new Pinebook Pro factory. We trust this will further reduce reports of DOA units and other types of hardware failures.\nThe big news of this month is that elementary is currently testing a pre-release of elementary OS 6 Odin for the Pinebook Pro. For those of you unfamiliar with elementary OS, it is a sleek distribution built on Ubuntu LTS, which ships with a (subjectively) beautiful and simple GTK desktop environment called Pantheon and a tailored store - the AppCenter. When the build becomes publicly available, it will offer a tailored experience for the Pinebook Pro, featuring countless tweaks to make Pantheon run well on the hardware. I also feel it is worth mentioning that the Pinebook Pro is the first Arm device to receive support from elementary. Needless to say, we are thrilled to see another highly requested OS land on our platform, and we’re thankful to the devs for all their effort in making this happen. I have now been running elementary OS on my Pinebook Pro for the past couple of weeks and I am happy to report that the experience is already very solid. I highly encourage you to visit elementary’s website and join their friendly community. If you can’t wait to try the build out, then please consider supporting elementary via GitHub sponsors - builds.elementary.io - as this will grant you early access to the OS image.\nDocked Pinebook Pro running elementary OS pre-release\nLastly, I know many of you are waiting for an update on the Pinebook Pro dock. Let me premise this section with an explanation that we’re ready to pull the trigger on production for the dock literally any day now. Developers have, however, been struggling with making the digital and analog (VGA) video outputs work properly and this has held back our decision to start the manufacturing process. That said, this past Tuesday I met with ayufan over a pint of beer in Warsaw and asked him to help the current efforts to make the dock fully functional. I hope and trust that his input will speed the enablement process along. As mentioned in previous community updates, I have been internally torn whether to show the dock or not because there is still an uncertainty whether we’ll proceed to manufacture this design, but ultimately I feel that the community waited long enough to see what we’re contemplating. I am including a picture of a docked Pinebook Pro below, with all the ports of the dock exposed. Please keep in mind that until we know we can have all of the functionality worked out this is still just a tentative design which may change.\nProposed Pinebook Pro Docking Station\nPineTab Let me get the bad news out of the way first - PineTab has suffered a 7 day production delay. The delay is caused by a mistake, which caused the volume buttons to be swapped around (vol - and vol +) on the flex cable. This is something which could easily be remedied is software, but we decided to do it properly from the get-go. In result the small cable hosting the volume buttons had to be scrapped and redone from scratch. Based on the present production schedule, the PineTabs will be delivered to us on August 21, and we will see to it that they are shipped out as soon as possible. We apologise for this slight delay.\nOn a positive note, I have a handful of good hardware news to cover. We have now received the RTL-SDR and LoRa expansion board samples for the PineTab. The RTL-SDR expansion board comes from a highly reputable vendor and uses 0.5ppm TCXO as well as tantalum capacitors. The LoRa expansion boards can either be fitted internally or attached to a USB port. We hope that the addition of a USB header on the expansion board will broaden its development opportunities as all of our hardware, and just any other computer with USB, can interface with this module.\nPineTab RTL-SDR expansion board\nThe LTE expansion board is still under development, but when completed it will feature the same LTE EG-25G modem found on the PinePhone. We’re also happy to announce that GPS functionality will work on this interface board just as it does on the PinePhone. In fact, we expect modem features which work on the PinePhone will function on the PineTab fitted with the LTE expansion board.\nLoRa expansion board/ USB dongle\nThe last bit of news I wish to cover concerns the Ubuntu Touch OS build that will ship with the PineTab. The build is still very much a work-in-progress piece of software, but it has benefited greatly from all the PinePhone development as both devices share core components. That said, a handful of quirks remain to be worked out; notably, PineTab’s trackpad doesn’t currently work - at least not well - with the Ubuntu Touch build. In short, the trackpad behaves erratically making the cursor ‘jump around’ instead of tracking as it should. Rest assured this is not a hardware issue - we checked and confirmed this already. We hope that one of you early adopters will help in solving this mystery. Lastly, for those of you who did not pre-order an early adopter’s units and hoping to get their hands on a PineTab, you’ll be glad to know that we will reopen pre-orders later this month. Before proceeding to production we will, however, want to hear back from early adopters so that their testing and experience can be accounted for prior to commissioning the next production-run. Please stay tuned to this blog and follow us on Twitter or Mastodon to be notified when the pre-orders go live.\nPinePhone I feel like we have finally gotten into a good production rhythm; it was only last month we announced the postmarketOS Community Edition of the PinePhone, and this month I am here to tell you that the factory will deliver the phones to us at the end of this month. Moreover, the presentation boxes featuring the (top secret) postmarketOS artwork and USB-C docks have all been delivered. I don’t know about you, but I think that this is a rather good production pace. At the time of writing, and based on current sale rates, the postmarketOS production-run will sell out in a matter of days - so if you’re on the fence whether to pick one up, then this is your last chance to make a decision. While I have no further announcements at this time, what I will say is that we have no intention of slowing down the pace now until February 2021 (when Chinese New Year begins). So if you’re interested in the PinePhone, then I strongly suggest you subscribe to this blog for any future hardware announcements. Some really awesome projects related to the PInePhone have surfaced this month. We have literally seen a boat-load of cool and innovative things people have attempted at tackling, but three stand out as particularly ambitious - at least to me. The first of which is a fingerprint scanner for the PinePhone, which will interface with the phone via pogo pins. I know very little about how far along this project is, however the person working on it assured the community on our subreddit that the software is coming along but the hardware is still a way off. If his implementation works well, then we may see a custom PinePhone back-cover with a fingerprint scanner in the future.\nPicture showing fingerprint scanner icon on PinePhone - image source\nThe second project that caught my attention was Martijn Braam’s video showcasing the addition of hacking a thermal camera into the PinePhone. To be precise he added a MLX90640 thermal camera module, with a 32x24 pixel resolution, making use of the standard Linux i2c driver. The module, Martijn writes, is similar to the Flir lepton module you can get commercially to attach to your existing Android or iPhone smartphone. While this mod will never become an official add-on (since I cannot see any broad demand for this in the community) it is yet really quite awesome. Also, both the PinePhone and Pinebook Pro in the video are running postmarketOS - pretty cool right? https://www.youtube.com/watch?v=lFsQpd0bLTY\nMartijn Braam’s video adding a thermal camera to PinePhone\nLastly, via a community effort (I have been specifically asked not to credit one particular person), numerous users have begun creating their own PinePhone cases. I have now seen numerous people who replaced their PinePhone mid-sections and back-covers with their own 3D printed versions. I hope that in the future we’ll see many community-made variations of the PinePhone body, and I truly hope that some of them will be capable of housing new hardware additions.\nPinePhone 3D printed mid-section\nIn other hardware news, you’ll be happy to hear we have three solid candidate options for a PinePhone keyboard. We’re currently investigating which out of the three choices are something we could invest in and move forward with. All the options can be configured as a slide-out or clam-shell design and they all offer different functionality. There are many pros and cons to weigh in on so the process of selecting the right reference design may take another month or two. In the meantime, we’re looking forward to hearing and seeing what you can come up with. We’re always waiting for community submissions, so if you come up with a design that is both innovative and holds the potential for mass-produce then make sure to let us know - we’re all years. As a closer for this section, here is a quick run-down of some (not all! - apologies to devs if I left something out) notable software developments in the past month. For starters Ondrej (Megi) Jirman has been working on power consumption optimisations which include the modem and the LCD panel. I believe that work on the LCD is still very much still a work-in-progress, but modem’s power management has already been published. In Ondrej’s own words, power management of the modem comprises “letting the modem sleep when it\u0026rsquo;s not in use, and waking it up when it\u0026rsquo;s needed for something, and letting the host sleep, and configure the modem to wake the host up, when some important event happens (incoming call, sms, …)” This is a development, which we expect will push the PinePhone well beyond a 24hrs battery standby time soon. In other exciting news, postmarketOS developers have released and shared a mobile configuration for Firefox 78, which allows all projects that allow installation of Firefox to scale the browser properly on the PinePhone. Until this point in time, projects had to rely on Firefox ESR 68, because scaling on newer software versions presented the user with tiny UX elements. This config comes just-in-time as Firefox 68 is about to reach EOL. Ubuntu Touch fans should rejoice as UBports developers have managed to enable both GPS and the camera. These features are currently available in the development channel, which can be switched to in the Software Update settings panel. Moreover, I have been told that GPU acceleration for the Morph browser is coming to the PinePhone soon. Earlier this month Marius from UBports tweeted a video showcasing the browser smoothly scrolling through a lengthy section of search results, rendering a webGL demo and playback of youtube videos. These changes will surely make the next stable OTA update for the PinePhone. https://www.youtube.com/watch?v=OARRK6bEgiE\u0026feature=youtu.be\nAccelerated Morph Browser on Ubuntu Touch - via Marius Gripsgard (UBports)\nManjaro have released new alpha builds featuring both Phosh and KDE Plasma Mobile. The Phosh build is really far along and offers all core functionality, including telephony, GPS, LTE, BT and even the camera. It is also, subjectively, one of the snappiest experiences on the platform. That said, the Manjaro team is also planning to release a Lomiri (formerly Unity8) build for the PinePhone, which is said to run spectacularly well. To me, however, the most important aspect of this build version concerns the cooperation between UBports and Manjaro, which started on our community platform.\nManjaro Running Lomiri UI - via Spikerguy (Manjaro)\nLastly, I feel like it is worth mentioning that multiple operating systems now support Anbox. If I understand the technology correctly, Anbox is basically Android running inside a container on the PinePhone. This will, in time, allow users to access some native Android applications unavailable on Linux. I suspect that this will become a common solution for those who need their city transport, shopping, banking or other Android applications available on the go. I do not have an up-to-date list of all distributions that currently support Anbox, but some of the favorites including Mobian, postmarketOS and the community built Arch Linux now all have the capacity to run Anbox. https://www.youtube.com/watch?v=v06KUrfs69k\nAnbox on PinePhone running Mobian - via LINMOBnet\nPineTime [****authored by** JF**] In the last community update, we announced that the next batch of Pinetime devkits will be programmed at the factory with my project (now renamed InfiniTime, more about this further in this post). Since then, the devkits are not yet available on the shop, what happened?\nWell, I sent the binaries from the latest release to the factory. Many people from the chat rooms installed this release on their device and checked that it was working correctly, with positive results, yay!\nBut\u0026hellip; It was not working so well at the factory. One important thing to know is that we are all working as hobbyists, amateur embedded software developers using hobbyist hardware and setup. To give you an idea, here is a picture of my desk with my Pinetime devkit and its debugging wires on the left, and my NRF52-DK board hooked on my small digital logic analyzer on the right.\nI didn\u0026rsquo;t visit the factory, but I\u0026rsquo;m quite sure that the production line does not look like my desk, and they most certainly use other tools and softwares that are more appropriate for mass production than mine.\nA good example is the external flash memory. Yes, the Pinetime has 2 flash memories : one integrated in the MCU (512KB) and one external (a huge 4MB) connected to the MCU via a SPI bus. For me, the only way to program this external memory is by writing a special firmware that writes data to the flash memory. This is time consuming, and not practical at all, but that\u0026rsquo;s all I have. At the factory, they use another hardware to program this SPI memory: a SPI programmer. This tool, connected to test points on the PCB, is able to program the SPI memory easily and at high speed. So I had to convert my little firmware that writes data to the external memory into a file that this SPI flash programmer understands… without having the means to check that this file is actually working!\nAnd this is just an example of the difficulties we encountered. We also had to find the correct file format for the firmware, merge the bootloader and the firmware into a single file so that they can actually use the files on their setup and use their procedure.\nLast but not least: time zones and language barriers did not help this process. The factory is located literally on the other side of the planet and when I sent screenshots of my software setup in French, they would answer me with screenshots in Chinese. We needed some time to understand each other :) There is good news however: David, the production manager, told me yesterday morning : \u0026ldquo;It looks like it\u0026rsquo;s working again. I will test a few more times\u0026rdquo;. Let\u0026rsquo;s hope it will work correctly with many pinetimes so that they can start the production of the new devkit!\nAside from production issues, here are other news.\nI have (finally) decided to release Pinetime-JF under the GPL3 license, and to rename it \u0026ldquo;InfiniTime\u0026rdquo;. I want this project to be a community endeavour and not just \u0026ldquo;JF\u0026rsquo;s firmware\u0026rdquo; and I think it was the right move to achieve that goal! We are investigating solutions to reconcile our MCUBoot based bootloader with SoftDevice based firmwares which could make the OTA from one to another possible. Without going into details, for now, it is not possible to go from ATCWatch or Wasp-os to InfiniTime and vice-versa. In the end, our goal is to be able to switch between completely different platforms.\nNew people keep on coming in the community chat and they start working on new features. For example, some of them designed shiny new boot logo and new watch faces.\nPineTime boot logo and watchface - via Lup Yuen Lee\nWasp-os found a way to implement step counting and heart rate monitoring using free software/open source drivers and Hypnos, a Zephyr-based firmware is making great progress and is looking to implement the OTA functionality.\nFinally, as long as I have the floor, I take this opportunity to encourage all developers who are interested in developing an open-source firmware for an open source smartwatch to join us in the chat rooms or forums! There are many projects to join, and a lot of work to do to change the world and create a complete ecosystem around the Pinetime and the Pinephone!\nPinecil We’re well on track to start production of the Pinecil at the end of September. We have already received the PCBs and assembled a small number of (PCBA) units for testing and development purposes. In my last community update I mentioned that the Pinecil is a truly open platform, and for those of you up to a challenge, it can be made into a completely different device. To this end, we’re happy to report that the Pinecil’s memory has been doubled for the production version, which further increases its versatility; given the ease with which you can program the device, you can truly think of the Pinecil as something much more than just a soldering iron. Pinecil PCBA\nPresently we’re waiting for the factory to deliver the first samples of the Pinecil body to us. Many of you have correctly identified that the Pinecil will be quite different to the TS100 in terms of overall layout and ergonomics. The buttons on the device will be located on each side of the display; we found that users tend to hold the iron horizontally when accessing settings, so this button placement makes it more sense from a UX perspective. The device will also be slightly longer - to accommodate the USB-C and power jack - and feature a rounder and rubberised segment where you rest your fingers. These are small tweaks in the grander scheme of things, so the iron should feel familiar to those who use a TS100, but we think they will go a long way to improving the overall experience of using the device. We will also be selling a high quality 4 tip set for the Pinecil upon release. At this point I need to come clean and say that I know very little about soldering irons and tips in general, so you’ll have to wait a little longer to hear exactly what variety of tips the kit will include. That said, I have been told these will be high quality tips which, as you have come to expect from us at this point, will be priced lower than anything else on the market.\nPineCube We were really surprised by how many of you showed an interest in the PineCube when I initially announced that the device is making a return from a two-year-long hiatus. Since the PineCube is really the first (that we know of) dedicated FOSS IP camera, we had no idea that there were so many of you awaiting this type of device. Today we’re happy to let you know that the PineCube has successfully passed CE/FCC certification tests and production of the device has already begun. We presently expect first units to roll off the factory line at the end of September or early in October and be available for purchase soon thereafter. With so much interest in the PineCube we already started preparing peripherals and add-ons for the device. The first two things that ‘just work’ with the current Linux build are a 40 pin LCD panel and a 1350mAh battery. Combined with the PineCubes GPIO pins and networking, these two accessories really extend the device\u0026rsquo;s versatility. I can well imagine people using the PineCube in conjunction with the battery to make an ‘action cam’ for a quadcopter or a scientific experiment, such as a weather balloon. Batteries sold in the PINE Store will likely only be available to community members in the US, but similar batteries are already available from reputable tinkering or hardware online shops. PineCube with battery in chassis\nAs the name entails the PineCube comes assembled into a small cube. But the device is actually constructed out of 3 PCBA pieces connected via flex cables: the front PCBA (with sensors and IR LEDs), the camera module in the middle and back PCBA (with networking, SoC and GPIO). If required these can be detached from the plastic frame; this is something we imagine can be useful when embedding the device, especially in an industrial or project scenario. I am including a picture of the PineCube pieces detached from the frame and a LCD displaying camera feed and debugging information attached. PineCube disassembled and LCD attached\nWe do not have any announcements concerning LCD panel and battery pricing but as I am sure most of you have come to expect the pricing of both items will be more than fair. More information about the LCD panel will be available closer to the date as we reach an agreement with the vendor. This is all for this month, hope you too are somewhere nice and sunny!\n","permalink":"/2020/08/15/august-update-getting-into-a-rhythm-and-not-slowing-down/","tags":["pinebook-pro","pinecil","pinecube","pinephone","pinetab","pinetime"],"title":"August update: getting into a rhythm and not slowing down"},{"categories":["pinephone"],"contents":"\nImage from: Дмитрий Куртуков - Keyboard for PinePhone\nWe are currently in talks with a number of hardware vendors regarding a Nokia N900-style, slide-out-design keyboard for the PinePhone. They’ll have to produce mock-ups or prototypes for us to consider in the next few weeks. The requirements specify that the new device needs to:\nInterface with the PinePhone’s rear pogo pin expansion connector Fit the PinePhone’s form factor Seamlessly replace the current back cover and snap onto the phone Be similar, mechanically and functionally, to the Nokia N900 keyboard We are simultaneously also exploring a gamepad for the PinePhone. The criteria we’re seeking in a gamepad are much vaguer than those of the keyboard:\nThe gamepad must use the PinePhone’s pogo pins (at least for power) It must attach mechanically to the phone. Preferably in an elegant way \u0026ndash; velcro or adhesive are not an option. This add-on project is at an earlier exploratory stage than the keyboard, and therefore there is also some leeway regarding the general direction and shape it can take. Now, we’d like to invite you to play along. While we’re waiting to see what the commissioned vendors will come up with, we’d also like to give you a chance to go at it. For the keyboard, we have settled on a 5-row key-arrangement design - a STP of the layout can be downloaded here. If you’ll have a go at creating a keyboard then do keep in mind the general guiding points outlined above, but at the same time do not take them as commandments carved in stone. I guess what I am trying to say is - don’t let the criteria restrict your creative vision.\nSuggested keyboard layout (filled in by hand)\nRegarding the game controller; since we’re at a very early exploratory stage, you’re welcome to explore a variety of approaches to creating such an add-on for the PinePhone. In other words, ‘anything goes’ as far as the controller’s design is concerned. Functionality wise, the controller will have to be powered via the pogo pins but I think it\u0026rsquo;s just fair to investigate the feasibility of alternative interfaces (BT/ USB) for the actual input.\nIn terms of other restrictions - keep in mind that this is something we’d potentially want to manufacture, so it has to have a sensible mechanical and electrical design, which cannot be a plagiarized copy of an existing device. If you decide to have a go at it then be aware of the following: there is a very cool reward for the project - or projects - which will be chosen, but there is no financial compensation for the design(s). If you submit your design to us then you automatically acknowledge that we may choose to proceed and manufacture it. You will be fully credited on the Wiki and elsewhere (where appropriate) for your design and we will - as we always do with our community - work with you to deliver the end product. We are most keen on functional prototypes, so that it will be possible to evaluate the feasibility of the design. Something may look cool but be unergonomic or simply dysfunctional when applied to reality, not to mention that certain designs may cost too much to mold and manufacture. I’ve been thinking about the best way for submissions and after some asking around I’ve been advised to just use the forum for this purpose. This way people can also discuss and offer feedback to others. Forum Thread If you have any further questions then do not hesitate to ask in the comments section or on the forum. Lastly, while there is a cool reward involved in this challenge to entice you to give this a go, please consider this a fun community hacking activity.\n","permalink":"/2020/07/29/invitation-to-play-along/","tags":["pine64","pinephone"],"title":"Invitation to Play Along"},{"categories":["news","pinetab"],"contents":"\nThis is a supplementary post to this month’s Community Update - if you haven’t read this month’s news, then I suggest you go back and have a read since we’ve had a handful of interesting announcements. Regarding the PineTab, I am happy to let you know that production is well under way and we are mostly on schedule with the manufacturing and shipping processes. To be precise, we are just a week behind the original schedule; the cause of the delay is our decision to change the LCD panel driver (or perhaps more accurately, we were convinced to exchange the panel driver by the vendor) as the driver we originally chose is reaching end of life (EoL). We ultimately decided that a week’s delay is worth it. The alternative scenario would likely result in developers supporting multiple LCD drivers in their operating systems, which is not ideal.\nHere are the details of the current timeline. Finished PCBAs will be released to us from the factory on the 27th and, granted we’re happy with them, fully assembled tablets should be dispatched from the production line on August 6th or 7th. The PineTabs will make their way to Hong Kong soon after and I expect that shipping will commence the week of August 17-21. Closer to the shipping date, sometime early next month, I’ll open a shipping thread on the forum which you’ll be able to follow.\nI am also pleased to announce that CE, FCC and RoHS certifications for the PineTab have already been finalized and the reports are now being written up. All reports will be completed in time for shipping and relevant certificates will be submitted to Wiki as soon as they are made available to us. As I mentioned in the past, we have significantly improved the battery from earlier hardware iterations. The PineTab ships with a 6000mAh Cobalt in lithium-ion battery, which not only provides a long battery life for the tablet but also superior discharge-cycle battery longevity. Investing into core components such as the battery is part of our commitment to seeing it adopted in both private and corporate (e.g. point of sale) environments, where it will be used for multiple years. We have also received PineTab m.2 LTE/SSD and LoRa adapter samples from vendor partners. Before these become available in the PINE Store we want developers to give them a proper spin so that all necessary functionality these adapters provide can be enabled in software. I presently cannot tell you when they will be available for purchase in the PINE Store, but I suspect that the m.2 LTE/SSD adapter will be the first to become available in the next 2-3 months time. Lastly, UBports developers have been working hard on getting the Ubuntu Touch build for the PineTab ready. Software progress made on the PinePhone has also directly contributed many features to PineTab’s functionality. Among others, the operating system now supports Over the Air (OTA) updates and real convergence, which allows you to switch between tablet and desktop mode on the fly when the keyboard is attached. Despite the software still being a work-in-progress, the experience of transitioning between one input state and the other already feels very good, and it will only get better from here. I hope that many of you who will be getting these early units will want to contribute to the development process by submitting reports, testing and helping resolve issues. Previous Next\n","permalink":"/2020/07/24/all-about-the-pinetab-update/","tags":["news","pine64","pinetab","ubports"],"title":"All about the PineTab (Update)"},{"categories":["news","pinebook-pro"],"contents":"\nHello everyone,\nI\u0026rsquo;m sure many of you will be happy to hear that the next round of Pinebook Pro pre-orders have now opened. This production-run is expected to ship in late August, 2020. Both ISO and ANSI keyboards are available. If the Pinebook Pro is something you\u0026rsquo;ve been waiting for, then click the button below.\nIn case you missed it, we\u0026rsquo;ve had some big announcements earlier this month.\nHave a lovely day and a great start to the week!\nGo to store\n","permalink":"/2020/07/20/pinebook-pro-pre-orders-open-with-shipping-in-august-2020/","tags":["pinebook-pro"],"title":"Pinebook Pro pre-orders open with shipping in August 2020."},{"categories":["cube","news","pinebook-pro","pinecil","pinephone"],"contents":"\nI cannot remember the last time I had this much to report. With so many announcements and highlights, I ran out of time and didn’t cover a handful of topics that happened this month. If I find the time, I’ll make a complimentary post later this month to cover the outstanding topics. Before we get into it, I’d also like to thank JF for his contribution to the text.\nThe big announcement of the month is that we’re introducing the PinePhone Convergence Package and that postmarketOS Community Edition (CE) pre-orders open today. The Convergence Package features a PinePhone with 3GB of RAM and 32GB of eMMC flash storage as well as a USB-C dock tailored for the PinePhone. This month we’re also unveiling the Pinecil RISC-V soldering iron and reintroducing the PineCube (formerly CUBE) FOSS IP camera into our product line.\nThere’s plenty of ground to cover, so let’s get to it.\nTL;DR for this month We’re trying out a new shipping arrangement to EU with postmarketOS CE; expect it to benefit end-users in Europe We are presently unable to ship any devices to Russia or India (doesn’t apply to SBCs \u0026amp; peripherals) PinePhone postmarketOS CE pre-orders open today! Introducing PinePhone Convergence Package with postmarketOS CE featuring 3GB RAM/ 32GB eMMC and a USB-C dock for $199; available alongside regular PinePhone postmarketOS CE for $149 PinePhone spare battery charger and protective tempered glass are now in PINE Store The PinePhone can now achieve 100hrs standby time without modem; over 24hrs with modem enabled (!) PinePhone state of software, including postmarketOS, Manjaro, and Mobian Pinebook Pro - finally good news from *BSD community; FreeBSD is coming together Lomiri (formerly Unity8) running on Manjaro on Pinebook Pro No (OG) Pinebooks being produced right now; we’ll wait for component prices to come down Next round of Pinebook Pro pre-orders at the end of July/ beginning of August Pinebook Pro dock is being evaluated by developers; it will be a little longer before we show it Pinebook -to- Pinebook Pro-esque upgrade kit is finally coming soon PineTime software and development status; working towards an early adopters edition [authored by JF] Pinecil is a TS100 compatible RISC-V soldering iron. Improved device ergonomics and firmware from original TS100 firmware creator Ben Brown; coming late September for $24.99 PineCube (formerly CUBE) going into production soon, with improved hardware specs; available in 6-8 weeks for ~$24.99 Personal note: I’ll start getting back to your emails now that I’ve got some spare time. Housekeeping Let’s start with a handful of shipping notices. With the upcoming postmarketOS CE we’ll introduce a new shipping arrangement for the EU (please see the PinePhone section of this post for details), which we hope will result in significantly reduced shipping costs for end-users. We’re always looking for the best arrangements and new ways to deliver our hardware, and we hope that this route will eventually grow to encompass other devices. We will have more news concerning servicing EU end-users in coming months, so please stay tuned and subscribe to this blog for further updates. On the subject of shipping, we also have bad news for our end-users in Russia and India. We are currently not able to fulfil postmarketOS CE PinePhone nor upcoming Pinebook Pro orders to said destinations since there currently aren’t any available shipping routes for these devices at our disposal. In anticipation of someone writing “but I can get product X into Russia/India using service Y”, let me elaborate on the situation a little further. We have been informed that we’re not allowed to ship devices with the encryption capabilities of the PineTab, PinePhone and Pinebook Pro into the Russian Federation. Shipping these devices could (and has multiple times in the past) lead to confiscation of the devices at the border by customs and even to being outright banned or barred from entering the country. There are avenues for us to explore in this regard, however, and we will do so in the coming weeks. Once a suitable shipping option is found, shipping to Russia and India will be reinstated immediately. I’ll make sure you’ll be notified of this as it happens.\nLastly, we will be looking into improving the PINE Store layout and shopping experience in the coming weeks. While we’re considering the store’s potential layout and structure, we’d appreciate hearing your views and ideas on how we can improve its front-end. I deem the comments section of the blog not the best place for this discussion, so I have opened a thread in the community section of the forum where we can exchange ideas. I am really looking forward to hearing from you.\nPinePhone The PinePhone UBports Community Edition campaign has now come to an end. Earlier this month we donated our financial contribution to the UBports Foundation and became listed as one of the Premium Sponsors. We would like to thank the entire UBports community - and especially Marius, Dalton and Ricardo - for their work and cooperation during the past couple of months (Editor’s note: Thank you to PINE64 and the community for making this possible! - Dalton).\nI must admit that despite the difficult circumstances that surrounded this campaign - everything from manufacturing to shipping - this has been a valuable exercise for us as a project. We have learnt a lot from the problems we encountered, and as a result of this we will be trying out new shipping strategies as well as altering how we tackle shipping periods. As I already mentioned earlier in this blog entry, we are setting up a warehouse in the EU (Poland), which will service European customers. This warehouse will, at least presently, only be used for PinePhones. If this setup proves to be as convenient and beneficial to the community as we think, it may end up hosting our remaining devices in the future. Using this new shipping arrangement, EU customers will not be asked to pay import tax, but rather the PinePhone price, $20 shipping charge as well as local VAT. Please note that this is a trial - something we’re testing out with this Community Edition production-run - and we may choose to fall back on previously established shipping arrangements in the future. Shipping arrangements for users in the US and rest of the world remain unchanged. Before moving to this month’s big announcements, I’d like to thank all of you for your patience - I know that it has been a long wait for some of you (and that many of you are still waiting). If you are just getting your UBports CE PinePhone now, then please consider joining the dedicated Ubuntu Touch on PinePhone telegram group.\nCleverly reworked box for the PinePhone Convergence Package\nPre-orders for postmarketOS CE open today and I am happy to announce that alongside the standard PinePhone CE hardware configuration priced at $149, we are launching the PinePhone Convergence Package. The PinePhone Convergence Package features a PinePhone with 3GB of RAM and 32GB of eMMC storage as well as a compatible USB-C dock. The dock that is included with the Convergence Package is capable of delivering power to the phone via USB-C power-in (3A 5V), outputting digital video via HDMI, 10/100 Ethernet connectivity and two USB 2.0 ports (for e.g. external storage / mouse and keyboard). The spec bump and inclusion of the dock comes at the price of $199. We presently do not know whether the Convergence Package will become a permanent option, something we’ll do on occasion or simply a one-off (although the last option is unlikely). It obviously largely depends on people\u0026rsquo;s response to this PinePhone variant and how much demand we see for it.\nBoth the regular (2GB RAM/16GB eMMC) and Convergence Package (3GB RAM/32GB eMMC) postmarketOS CE PinePhone versions will ship with a mainboard designated 1.2a. The ‘a’ in the mainboard’s designation refers to a minor alteration, allowing for better power delivery negotiation (which will result in improved charging performance under some circumstances), as well as the possibility to connect USB devices to the phone and output video to an external monitor.\nHead over to the PINE Store to pre-order your postmarketOS CE PinePhone.\nhttps://www.youtube.com/watch?v=yBeza4UNOm8\nPinePhone running postmarketOS docked by Martijn Braam\nWhile we’re discussing this topic, let me tackle the elephant in the room and acknowledge that a design flaw in PCBA rev. 1.1 and 1.2 prevents this functionality (please see relevant documentation related to CC pin) on Braveheart and UBports CE phones. This issue was originally identified, and the fix for it was found, by Ondřej (megi) Jirman. His work on the anx7688 makes USB-C features, such as PD charging, video output or other functions of the docking station work. Thankfully the fix to the problem - the removal of two small components from the PCBA - is relatively simple to perform for someone with good soldering skills. At the same time I recognize that many community members, myself included, are not capable of completing this operation. To this end, we will set up a chain of local (in your geographic area) workshops, makerspaces or individual technicians capable of performing this fix, so you can send your 1.1 / 1.2 phone to them to complete the repair. https://www.youtube.com/watch?v=xf8OJtjNWUM\u0026feature=youtu.be\nQuick Look at the required CC fix on PCBA 1.1 / 1.2. By Mozzwald\nWhen we sold Braveheart PinePhones we made a promise to the early adopters that we won’t leave them behind, so I’d like to extend the offer for fixing the CC pin issue to all Braveheart owners too. More information will follow about the process later this month - I have to figure out the smartest way to set up the infrastructure about it first. In my dedicated post on this topic, there will be a sign-up for individuals and shops who would like to make their services available. So, if you’re handy with a soldering iron then please subscribe to the blog and watch for a post later this month. In other hardware news, there are now two new PinePhone items available in the PINE Store. We have a tempered glass screen protector (it\u0026rsquo;s very good, I use it on my phone) and an external PinePhone battery charger. The charger makes it possible for you to charge a PinePhone battery externally, so you do not need to disassemble your phone to charge a spare battery unit. Both items come in at $4.99 and I suggest you at least pick up the glass screen protector alongside one of the phone cases for your phone. Both items can be found in the PinePhone spare parts section. One last little bit of hardware news I’d like to let you know about is that now, with access to vendors in China becoming easier, we have resumed exploring the creation of an external keyboard for the PinePhone. To be precise, we have approached a vendor and began exploring our options for a slide-out keyboard akin to those used on the Nokia N900. If the talks come to fruition then I’ll make sure to ask for your opinions - as I did with the Pinebook Pro - regarding the keyboard layout and features (no, there won’t be multiple layouts).\nBattery charger and tempered glass protector\nI have already used up all the time and space reserved for the PinePhone section in this blog, but I feel strongly compelled to cover some software updates. For starters, I know many of you are curious about the software status of the postmarketOS build that will ship with the postmarketOS CE PinePhone. The build will include a phenomenal out-of-the-box user setup and installer, which will not only allow you to fully encrypt your eMMC storage but also enable services, such as SSH. Our friends from postmarketOS have posted a very detailed post detailing the state of software. I strongly suggest to head over to their blog and have a read. Previous Next\npostmarketOS initial user setup. By Martijn Braam\nThe other big software news of the month concerns the amazing work of Samuel Holland on Crust advanced power management; the PinePhone is now able to idle for ~100hrs (that\u0026rsquo;s not a typo, I wrote 100) using as little as 110mW in deep sleep. This is, of course, with the modem switched off. With the modem ON, you can expect the PinePhone to achieve an idle run-time of approximately 24hrs, which we feel brings the device firmly into the realm of what we’d consider a daily-driver smartphone being capable of. The second bit of software news I’d like to cover is Mobian’s implementation of camera functionality on the PinePhone. This implementation builds on work by Ondřej (megi) Jirman, who has been working on both the ov5640 rear and gc2145 front cameras. For those of you who do not know, Mobian is a dedicated Debian distribution for the PinePhone which I happen to be a fan of. The camera implementation is rather slow and the photos aren’t the best quality, but what is important is that we’ve seen this goal being achieved in a relatively short period of time. Somewhat noteworthily, I’d also like to note that I’ve had no problems using GPS on Mobian, and even did some navigating on foot with phone-in-hand finding my desired destinations and best routes. I’m really impressed.\nCamera now works on Mobian\nLastly, I want to give a shout-out to the Manjaro team and their work on the PinePhone over this past month. Manjaro are such an integral part of our community and one of the main driving forces behind end-user facing development. That said, perhaps because of their dedication to the Pinebook Pro hardware and the time they put into it, their Alpha OS images for the PinePhone were lacking in comparison to some of the dedicated cutting-edge distributions. This, however, is a thing of the past. It appears Manjaro have now settled on Phosh as their default UI (as opposed to Plasma Mobile) and achieved a lot of software parity with other distributions. Their most recent OS image, at the time of writing, has LTE functionality, places phone calls, has the newest Phosh features (including auto-scaling) and even apparently the newly released Crust power management improvements. I know there are many fans of Manjaro in the community, so I suggest you give their most recent pre-release a go.\nPinebook Pro We know that many of you are waiting for the next Pinebook Pro batch to open. I currently cannot offer you a precise date for when the next batch will become available, but we’re working towards starting pre-orders at the end of this month. The next production run will be produced by a new factory, which we are still in talks with. Therefore, it’s taking a little longer than usual. Regardless, we’re set to start producing Pinebook Pros in August, so you will not have to wait for much longer to get into the queue for your unit.\nThe Pinebook Pro has seen quite a few software developments over the past month. For starters, we finally have some progress coming from the *BSD communities. Although the Pinebook Pro has already been shown running *BSD months ago - and NetBSD has been available for install for some time - there haven’t been any guides or tutorials on how to get Open or FreeBSD working until now. In fact, very little information about Open and FreeBSD has been made available on our forum or Wiki. I believe this is about to change, however, as nrgmilk - a FreeBSD developer (who also booted FreeBSD on the PinePhone!!!!) - tweeted that FreeBSD 13.0 now boots on the Pinebook Pro with LCD output. Just a few days later, Vincent Milum Jr. shared information that he successfully implemented big.LITTLE support for the Pinebook Pro on FreeBSD 13.0. I have been told that while there is still a lot of work to be done on FreeBSD, and indeed all *BSDs, the movement we saw this month may be the breaking point which will propel work on our platform forward.\nFreeBSD booted on Pinebook Pro by nrgymilk\nIn other software news, we saw Manjaro booted with Lomiri (formerly Unity8) on the Pinebook Pro. While this is fun to see from a technological standpoint, I am mostly glad to see PINE64 as a platform facilitating the growth and cooperation of projects. Ubuntu Touch and Manjaro are fairly distant relatives of the Linux family tree, and yet they found a common (and innovative) ground to work on within the premises of our community. I am told that you can already install Lomiri alongside KDE Plasma on the Pinebook Pro if you switch to the unstable repos.\nLomiri on Manjaro via Manjaro Linux\nThis month we’ve also seen the first proper graphical U-Boot implementation on the Pinebook Pro thanks to the work of Samuel Dionne-Riel from NixOS. Samuel writes that this version of U-Boot still has some issues with booting the most current mainline kernels (5.6+) - including Manjaro’s Pinebook Pro kernel (5.7) - but this is surely something that can and will be fixed in nearby future. This is an important step in Pinebook Pro software evolution, as it makes booting and installing alternative OSes from SD, USB 2.0, USB 3.0 and NVMe trivial. I am including Samuel’s quick video showcasing the U-Boot video init working below. https://www.youtube.com/watch?v=rdosT2yyA4g\nU-Boot visual output via Samuel Dionne-Riel\nWe have sent the Pinebook Pro dock to a handful of partner project developers for evaluation. The process of enabling all of the dock’s functionality on the Pinebook Pro is ongoing, and we’re still missing video output implementation. We also want to redesign some minor bits and pieces before showing it off, so you’ll need to wait a little longer before I post a picture of a prototype we’re happy showing off publicly. I also have some news regarding the redesigned OG Pinebook. At present component prices - especially prices of LCD displays - the BOM cost of the Pinebook significantly exceeds our asking price. In other words, we’d have to significantly subsidize it, which is not something we’re willing to do with all the cost-inducing activities we engage in. Once the post-COVID19 market stabilizes and prices come down, I assure you that we will resume production of the Pinebook. Finishing on a positive note, we’re now moving forward with the OG Pinebook-to-Pinebook Pro-esque upgrade. The upgrade will require you to be moderately handy with a screwdriver and the command line. It involves removing the A64 board, applying the heat-dissipation material to the case bottom and lastly installing the RK3399 mainboard in the chassis. On the software side, you will have to flash new firmware to your keyboard and trackpad (similarly to how it is done on the Pinebook Pro). I’d also like to make you aware that thermal performance of the upgraded OG Pinebook - even when using a graphene layer - will be poorer than the Pinebook Pro. That said, this doesn’t entail that the thermals are bad, and kernel 5.7 and allegedly also the upcoming 5.8, improve the RK3399’s thermal profiles, so you don’t have to worry about heat-related issues under regular load. Here is a thermal test using the graphene heat-pad used in an upgraded Pinebook; please disregard the 18*C read-out and focus on the core frequencies - all you need to know is that the SOC throttles at 72*C. We aim to have the upgrade kit available in a few weeks time in the PINE Store. OG pinebook with the upgrade installed\nPineTime [****authored by** JF**] Here is the latest news from the Pinetime community!\nFirst, a big announcement: PINE64 has decided to move towards an early adopter edition of the PineTime, and I\u0026rsquo;m really excited that the community chose my project as the first FOSS firmware to be flashed at the factory for this early adopter edition! Until now, the Pinetime dev kits were programmed at the factory with what we call the stock firmware - it implements most of the features of the watch but it is closed source. Moreover, the flash memory is read-protected to prevent anyone from reading the binary file from the memory.\nWhen this early adopter edition is available, you\u0026rsquo;ll enjoy the result of months of work by the PineTime community (I\u0026rsquo;m not the only one working on this firmware, but I still have to find a better name for it\u0026hellip;), and you\u0026rsquo;ll be able to hack, debug and flash your watch more easily than before because you won\u0026rsquo;t have to disable the memory protection.\nThe firmware is still under development but it already integrates basic features like displaying the time, synchronizing the date and time with a companion application on a smartphone, and receiving notifications. Right now we are in the process of testing and debugging this firmware as much as we can, and everyone is welcome to come and help us in this exciting task!\nAnother great achievement for the project is the development of Over The Air (OTA) update capability. Not only are we now able to update the firmware running on the Pinetime over BLE, but we can also switch from one firmware to another! We\u0026rsquo;ve successfully ran a demo showing an update from my firmware to Lup Yuen\u0026rsquo;s.The OTA feature is still experimental, but it gives really promising results!\nhttps://www.youtube.com/watch?v=tFm_cGP3AHw\u0026amp;feature=youtu.be\nPineTime OTA update via Bluetooth\nIn a previous community update, Lukasz announced that Amazfish - a companion app running on SailfishOS and on the PinePhone - was able to communicate with the PineTime. Since then, Gadgetbridge (Android) joined the team. And, last but not least, Lup is also working on a companion app and one of his goals is to make it run on the Pinephone.\nhttps://www.youtube.com/watch?v=myMUNepyB5I\u0026feature=youtu.be\nPineTime receiving notifications via Gadgetbridge\nWhat else happened in the community? A lot of work has been done on the heart-rate sensor and the accelerometer and power consumption, with very good results from ATCWatch. I\u0026rsquo;ve seen interesting discussions about the design of a dev cradle that would make it easier to connect the pinetime to the SWD debugger. There are also a lot of people interested in Python development thanks to WaspOS, and the community keeps on welcoming new developers that are excited to learn and work on Pinetime.\nPinecil Let me start by thanking all those who played along last month and took a shot at my riddle. I must admit I was quite surprised how quickly people correctly identified what the Pinecil is. I was also blown away by the accuracy with which the clues were deciphered. Next time I’ll know to make my riddles more cryptic and difficult to decipher. Before we proceed to talk about the device itself, let me just list the names of the three winners (first to correctly identify device type; first to accurately identify SOC type; first to correctly identify all clues). If your name/ handle is on this list then please email me directly (l.erecinski@pine64.org) using the email registered on this blog. The first three production Pinecils are going to: Andrew Stoehr Jonas Ignas Kiela The Pinecil is a RISC-V based soldering iron - it is inspired and compatible with the widely acclaimed TS100, which is used by tinkerers and makers worldwide. The Pinecil maintains compatibility with TS100 tips and delivers performance identical to its muse, but at a community friendly price of $24.99. Having spoken to, and gathered feedback from, people who are experts in the field, we have made a handful of improvements to the general design and functionality of the soldering iron. In terms of ergonomics, compared to the original TS100 design, the Pinecil is more comfortable to hold and features a grippy rubberised texture where you place your fingers. It is also slightly longer and can be powered via either USB-C or a barrel jack. This makes the soldering iron more versatile, especially if you intend to use it for in-field repairs. The USB-C connection also includes embedded UART, i2c, SPI, and USB signals for ease of development. We know some of you want to play Tetris on your soldering irons … for everyone else, yes, it\u0026rsquo;s actually a thing. Speaking more seriously however, this means you can use the Pinecil as a platform to create something completely different based on this platform, such as a drill or a multimeter.\nPrevious Next\nPinecil renders and mockup\nObviously the one crucial bit of having the Pinecil actually functional is having software support for the device. This effectively means porting an existing firmware to the RISC-V platform. Thankfully we’ve been able to interest Ben Brown - the person behind the original TS100 firmware - to take a look at the Pinecil. Sending him a prototype just a little over a month ago, all we hoped for was for him to take a look at it and evaluate the design\u0026rsquo;s feasibility. Suffice to say Ben exceeded our expectations by practically porting all essential functions to RISC-V, thereby making the Pinecil functional. As of today, the following is working: PWM tip drive OLED Accelerometer (ish - needs work somewhere) FreeRTOS Basics of all of the code Still needs work:\nTune PWM timings FLASH for saving settings DMA for I2C (to make screen updates smoother) Pinecil hardware running (prototype)\nWe hope that you guys are as excited about the Pinecil as we are. We are currently aiming to make the Pinecil available for purchase sometime in the next 3 months. I will make sure to keep you up-to-date on how the project is progressing until then.\nPineCube This will likely come as a bit of a surprise to many of you, but production of the PineCube (originally CUBE) open source IP camera will be starting soon. Some of you may recognise this project as it has been well over a year in the making - we first announced it at FOSDEM 2019. The thing that originally held the PineCube back was a lack of camera integration in the software. Other projects took priority and, eventually, the project was shelved until we had the time and free resources to tackle it again. With all major disasters now behind us for this year (*knocks on wood 3 times*), and with all the big devices shipping, we feel the time has come to revisit the much anticipated PineCube.\nThe PineCube is a compact and completely custom built IP camera that runs mainline Linux. It features an m12 mount, which accommodates various lenses for different use-cases (wide-angle, zoom, fisheye, etc.,), and it comes equipped with IR LEDs for night vision. The small device also bundles a microphone, GPIO, USB 2.0, 10/100 Ethernet, Bluetooth and WiFi. It\u0026rsquo;s worth mentioning that the PineCube can be passively powered over Ethernet. All these features allow for a high degree of versatility, making the PineCube suitable for a wide array of use-cases, ranging from a baby or security camera to a drone or robot camera.\nPrevious Next\nA look at the new PineCube\nSince its original announcement in 2019, a number of changes have been made to PineCube’s core hardware. The original camera module has been switched out for the OV5640 5MPixel sensor used in the PinePhone and PineTab. Progress made on the OV5640 on the big devices will hence directly translate to the PineCube. The IR LED array has also been altered to allow for better and further-reaching night vision. Perhaps most importantly, however, the SoC has been upgraded to the S3 (up from S3L), which is paired with 128MB of DDR2 RAM. The upgraded RAM as well as the Cortex-A9 running at up-to 1Ghz make for quite a powerful platform. In the coming weeks I’ll be reaching out to developers and project maintainers to get early PineCube units into their hands. We have commissioned the factory to start production and been informed that the lead-time is approximately 6-8 weeks. We expect to be able to offer the PineCube for $24.99.Let me know if you’re planning to get a PineCube and what you’ll use it for in the comments section. I expect to have more updates for you about this project in a month’s time. Personal note This has been a busy period for us - and I’ve also been working on my own PINE64-related project that I’ll be unveiling soon (shameless plug) - and my inbox is literally filled with queries from community members, media and potential partner projects. I’d like to apologize to you all for being so unresponsive and at the same time promise to start going through the pile of correspondence starting today. That concludes this month’s update - I am looking forward to your comments!\n","permalink":"/2020/07/15/july-updatepmos-ce-pre-orders-and-new-pinephone-version/","tags":["pinebook-pro","pinecil","pinecube","pinephone","postmarketos"],"title":"July Update: biggest update in months!"},{"categories":["community","news","pinephone","pinetab","pinetime"],"contents":"\nHello everyone! It has been a really busy time for us here at PINE64 as we’re working hard to deliver outstanding PinePhone UBports Community Edition and Pinebook Pro shipments. The big news of this month is that we’re excited to announce that a postmarketOS Community Edition PinePhone will be available for pre-order early next month. There are a lot of topics to cover this month, so let\u0026rsquo;s get to it.\nThis month’s TL;DR\nAll PINE64 services on our own hardware; the cluster move report Shipping delays and Pinebook Pro QA issues addressed Shipping status update \u0026amp; where to find up-to-date information An apology for PineTab pre-orders delay \u0026amp; no heads-up on blog PineTab pre-orders sold out in under 72 hours PineTab to ship late July 2020; more batches coming PineTab add-on board reengineered for LoRa and RTL-SDR modules; available for next pre-order batch PinePhone postmarketOS Community Edition announcement; pre-orders start early July Check out postmarketOS announcement blog post! PinePhone CRUST advanced power management status A community initiative; a PinePhone pogo pin breakout board PineTime; Lup Yuen Lee will write a series of PineTime articles for our blog! Solve the riddle! Housekeeping We’re proud to announce that starting this month all our community services, including this very website you’re currently visiting, are all running on our PINE64 cluster of 24x ROCKPro64 single board computers. The process of migrating services to the cluster began on June 5 and finished on the 10th without any major dowtimes or hiccups. As of right now the cluster hosts the main PINE64 website, the Wiki, forum, IRC server (and chat bridge) as well as all our Matrix channels. To our knowledge we’re the only organization in this neck of the woods to dogfood hardware in this way. I like when things speak for themselves, and so I hope and trust that this is a testimony to our faith in our own hardware. I know many of you are very keen to learn more about the cluster, so I already have asked Matthew (fire219) and Marek (gamiee) to write a technical blog post about it once the dust settles. I know that there are at least two other services that the guys want to host on the server, and once that\u0026rsquo;s done you can expect a progress report directly from the people involved in making it happen. What I can tell you is that the cluster is running mainline Debian and the nodes are network booted from a 1TB NVMe SSD. All databases are backed up and mirrored to another 1TB SSD. We’re currently using 8 of the 24 nodes at our disposal so there is plenty of room to grow in the future. We’re also aware that not everything is working 100% flawlessly just yet, but we’re going though the bugs list and hope that the minor issues will not detract from our systems’ overall usability.\nNetwork boot node with 1TB storage via Gamiee\nShipping Status and Pinebook Pro QA As many of you are already aware, we ran into shipping problems which resulted in delays. We are presently approximately 2 weeks behind our original schedule (NB. this only relates to some shipments, since a fourth of all PinePhones UBports CE and half of Pinebook Pro laptops already went out). It is important to note that the reasons for the shipping delays are different for the two devices, so I’ll take a minute to explain the situation. The Pinebook Pro shipments have been put on halt since additional and more stringent QA of the devices is now underway. This follows an abnormal amount of issues reported from the first two shipments. I feel like I owe you an explanation, so here it goes: the higher-than-normal number of Pinebook Pro issues reported is, by and large, a case of the factory not doing their job properly. A cascading number of events underpin this situation, and I won’t get into all the details, but the starting point of these issues is the COVID19 pandemic, which effectively prevented us overseeing the work done at the factory.\nWe have now taken steps to make sure this doesn’t happen again. Factory workers have been better instructed on how to perform some of the error-prone tasks, the factory has agreed to improve their QA protocols and we’ve set up an independent review of the laptops as they leave the factory. Regardless, I am now happy to let you all know that the remaining Pinebook Pro laptops will clear our warehouse this week and that shipping resumes today. This means that the grand majority of those still waiting for their Pinebook Pro will have their units by late-next week. I’d like to apologize once more to everyone who received a faulty unit - we’re working as fast as we can to resolve reported problems. As for PinePhone shipments, the cause of the delay is Asendia’s inability to fulfill shipment at this time. Unlike DHL - which has a fleet of aircraft and local couriers at its disposal throughout the world - Asendia relies on third-party logistics and national postal services to fulfill orders. Seeing as many borders are still closed and, at times, carriers or postal services Asendia cooperates with have not returned to normal operation, it is simply impossible to accept our shipment. Earlier this month we gave everyone the option to change their shipping from Asendia to DHL, and we have now reached the required number of orders to commence a DHL ‘upgrade’ shipment in a matter of days. Those who have not yet changed their Asendia shipment orders to DHL still have the optionto do so via pine64.com. If you want to receive your PinePhone UBports CE this month then I strongly recommend you switch your Asendia shipping to DHL. However, if you’re not in a rush then you are welcome to stick to Asendia - borders around the world are slowly opening up and logistics chains are slowly returning to normal. Just today the service resumed operation to two more countries - Brazil and Australia. In result, I suspect that the more Asendia shipments will commence in a matter of 3-4 weeks, as more shipping destinations become available. If you wish to stay up-to-date on PinePhone and Pinebook Pro shipping, you can find a shipping update thread on the forum, where I post new information as it becomes available to me. PineTab Pre-orders for the PineTab pilot batch went live on June 10th - 12 days later than we initially planned. We apologize for this delay. The delay in launching pre-orders was caused by two factors: the PinePhone and Pinebook Pro shipping situation, as well as migration of our services to the PINE64 cluster. We initially planned for the pre-orders to go live well before the migration of services, but with aforementioned shipping problems the date slipped and we deemed a pre-order launch right in the middle of moving services to our cluster too risky. I’d also like to personally apologize to all those who waited for a heads-up post on the forums and the blog; I know this is something I promised, but forgot about it due to high workload. If you missed out on placing a pre-order rest assured - this is just the beginning. Once we receive feedback from early adopters, we’ll produce a much larger PineTab batch and everyone who wants a PineTab will surely be able to get one.\nPrevious Next\nProduction PineTab and keyboard (not renders)\nSpeaking of sales, the pilot batch sold out in under 72 hours, which means that multiple hundred units were sold daily. I’m not going to lie, I am surprised by the sheer volume of traffic and general level of interest in the PineTab, and I am curious if the fast sale rate is a result of the extensive media exposure that the PineTab received or a genuine need for this type of device (or a combination of both). Feel free to share your thoughts about this - I am really interested to hear what you make of it. Regardless, it was a real pleasure to see so much positivity and excitement around the PineTab online at the time the pre-orders dropped. The numbers speak for themselves, the PineTab video Marius recorded last month has now received 26k. https://www.youtube.com/watch?v=Ii6lAjgfW3c\nIf you missed the video last month - here\u0026rsquo;s the PineTab Running Ubuntu Touch\nSeeing as PineTab pre-orders sold as well as they did, we’re now looking into ways to extend this production run or start another one in the immediate future. We cannot promise that this will happen for certain, but if our production request will be accepted by the factory then I will make sure to let you all know on Twitter, Mastodon, the forum, the chats and also on this blog. I promise I’ll remember about making a blog entry this time.\nThe shipping date for the PineTab is late July, which means that we’re internally aiming to start sending out units in the latter half of July. As the shipping date draws nearer we keep on improving and polishing the device so it will be the best it can be when it lands in early-adopters hands. I have already written at length about some improvements already made to the device in April’s community update, so I won’t be repeating myself here, but just because we addressed all known issues doesn’t mean we stopped researching our options to improve the PineTab yet further while preserving the $99 price-tag. In example, we just managed to secure a higher quality battery for the PineTab; something that will be a major benefit 2 or 3 years after your Pinetab purchase.\nLastly, I see a lot of questions concerning the PineTab add-on adapter announced last month. In its original inception, the adapter only allowed for LTE and SSD storage, while now it will also have to accommodate LoRa and RTL-SDR modules. Seeing as we already have our hands full with other equipment and the abnormally difficult shipping situation, the process of re-engineering the adapter will take a few weeks longer. In result, the adapter will first be available in the PINE Store when the second production-run of PineTabs becomes available for pre-order. I’ll make sure to keep you up-to-date on this topic in future updates. PinePhone We’re happy to announce that the next Community Edition of the PinePhone will ship with postmarketOS. The pre-orders will start in early July and we currently aim to have the pre-order window open for at least a month and a half. I am sure that many of you are thrilled to see another Community Edition of the PinePhone available so soon and branded with one of PinePhone’s flagship OSes. Similarly to our friends at UBports, postmarketOS developers have been with us since the very start of the PinePhone project and their OS has been instrumental to our hardware production process. For those who don’t know, the factory test image used for handset QA at the factory runs postmarketOS with a custom UI. It will therefore, in a sense, be the second time we ship postmarketOS on the PinePhone - as some of you will recall, Braveheart Edition PinePhones shipped with the aforementioned factory test image. It is probably evident but I’ll write it anyways; unlike the factory test image that shipped with Braveheart phones, the postmarketOS Community Edition will feature a fully fledged postmarketOS mobile system.\nRender of postmarketOS Community Edition PinePhone\nI expect you will also be glad to learn that production of this Community Edition has already been scheduled at the factory, and we’re hoping for record turn-around time for this production-run. In general, I feel like we’re just getting into the manufacturing stride after the long downtime which began in January with the Chinese New Year and was followed by the now dwindling COVID-19 pandemic. This is obviously good news for you, the end-users, but it is also good news for postmarketOS developers who will benefit from the donation we’ll be making on your behalf to their project. I have already stated this many times in the past but I’ll write it again - the principal goal of the PinePhone as a project is to give Linux on mobile a chance to grow and prosper. Early on we recognized that donating to our partner-projects was a key component in helping Linux on mobile flourish. The team behind postmarketOS has just recently set up a financial back-end to their project. The donation we’ll be making - for those who don’t know - will come in the sum of USD $10 for each unit sold during this PinePhone campaign. You can learn more about our partner-project donation scheme by clicking here. I am sure many are curious to find out more about the hardware and software that will accompany the postmarketOS edition of the PinePhone. More information will be available in the coming days, but in the meantime I strongly encourage you to head over to postmarketOS announcement on their blog, which offers a detailed look at the software set to ship with this edition of the phone. As for the hardware, we will be making an announcement closer to date; presently we are working on the assumption that the PCB to ship with this edition will still be version 1.2. We may, however, decide to make some further tweaks to this PCB design. We will, of course, document and inform you of any changes to PCB 1.2 there may be in the future. Lastly, as you have surely already spotted, the postmarketOS edition of the PinePhone will feature the project’s branding on the phone’s caseback. Subjectively, I must say I love the render of the caseback and think it will turn out looking fantastic. PinePhone running Ubuntu Touch with GPS and CRUST enabled\nIn other PinePhone news, we’re seeing a lot of progress across all software distributions. So much in fact, it would be impossible for me to cover it all. The one thing that the various PinePhone projects are working towards collectively, however, is implementing CRUST advanced power management in such a way that modem events, e.g. as phone calls and SMS messages, would wake the phone up from the deep sleep state. Just recently, Marius from UBports has managed to achieve just this in Ubuntu Touch. Perhaps most importantly, his implementation allows both Community Edition and Braveheart PinePhones to wake up from deep sleep. This is something others have speculated may prove very difficult on Braveheart phones due to GPIO assignment, so I figured it is important to underline - once again - that if you have a Braveheart phone, you shouldn’t feel like you’re missing out on upcoming software features. CRUST on the PinePhone, at least in its current state when coupled with an active LTE modem connection, allows for approximately 14 hours stand-by time. For most people, this will be just enough to get you through a work-day. This number will eventually be extended by another 10 hours as developers tweak the modem to enter a lower power mode. I know that developers from other projects are already looking into how they can implement this solution in their distributions, but for now you can try it out on Ubuntu Touch by switching over to the Developer channel under system settings. I have started a thread on the forum with instructions on how to enable some of the more experimental features on Ubuntu Touch. In the coming weeks you can see this feature, as well as many others, to be incorporated into what was meant to be the day-one OTA update. As is customary in software development, the day-one OTA has been delayed by a few weeks, due to bugs which need to be worked about before a new stable build is deployed. If you’re not one to tinker or keen on experimenting with work-in-progress features, then stay on the Stable Ubuntu Touch branch and wait for the update to drop. pogo pins breakout board for the PinePhone via SMR404 GitHub\nLastly, I’d like to showcase a community hardware initiative I found quite ingenious, namely a breakout board for the PinePhone’s pogo pins. The board makes it easy to access I2C pins and to interface with the protocol in a convenient manner. I hope and trust that someone will create a caseback for the PinePhone which could also house this breakout board. The STL for this project is available on SMR404’s GitHub, and I’d like to encourage others interested in hacking and tinkering with the PinePhone to actively contribute. PineTime It feels to me that the PineTime, as a project, has greatly matured in the past couple of months and is now entering a new stage. As I have mentioned on many occasions in the past already, I am not the best person to bring you coverage of the PineTime seeing as I do not fully understand the complexities of its software and development process. To this end, I’ve asked Lup Yuen Lee to post PineTime development updates on this blog on a need-be basis, and I am happy to report that he agreed to do so. I’d also like to point you to his Medium blog, which is a treasure trove of PineTime articles. I am more than certain that having Lup Yuen cover the PineTime from now on is for the better, and I cannot wait for his first post on PINE64’s blog. The Riddle\nBefore we start, consider the following just a bit of fun. Let me give you the border context first however; I have been tasked with teasing an upcoming device due to be announced next month. I have been thinking for some time how to make this a fun community exercise and came up with a rhyming riddle for you to solve. The first person to solve this riddle will be rewarded with the mystery device. Just to make it clear - even if you solve the riddle correctly, I will not acknowledge the answer until July 15th when the official announcement will be made. You get bonus points (which translate to beer if I meet you at a convention) if you correctly identify clues embedded in the poem. Lastly, I have not written a word of poetry since highschool, so please spare my fragile ego. And yes, I’m aware it breaks at least one convention of writing Quintets.\nPinecil\nWith the Pinecil we take a risk Spelling the latter with the letter c Breaking with current conventions\nAnd having the device run hot As hot as it will ever be\nThis may be too perplexing So for the sake of simplicity What does 82 and 26 have in common\nAs defined by a man Born North-East of Caspian Sea?\n","permalink":"/2020/06/15/june-update-postmarketos-ce-pinephone-shipping-pine64-cluster/","tags":["pine64","pinephone","pinetab","pinetime"],"title":"June Update: postmarketOS CE PinePhone, Shipping \u0026 PINE64 Cluster"},{"categories":["community","news"],"contents":"\nThe process of moving our end-user services to the ROCKPro64 cluster will be taking place in the coming days (5-10 June). I am not going to pretend like this is the best time for the move to be taking place, since it is not. Many users are relying on our infrastructure for information and community support, particular now that people are receiving their devices and many more are waiting for their units to ship. But things are what they are, and we have a strict deadline we need to adhere to.\nIn practice, this means that at different times during this move key parts of the infrastructure will be down. This includes: the forum, the Wiki, the chats bridge and IRC, portions of the support system, PINE Installer mirrors as well as this website. It is not possible for me to say with certainty when exactly each of these community-facing services will be moved nor how long it will be down for. Obviously we\u0026rsquo;ll aim to complete the process as quickly and painlessly as possible but unpredictable things can, and likely will, happen.\nI\u0026rsquo;ll do my best to give you a heads-up when portions of the system are scheduled to go down for maintenance on Twitter and Mastodon. I\u0026rsquo;ll also issue notices in the news section of the forums.\nLastly, I\u0026rsquo;d like to note that the PINE store and ticket filing system, as well as our info and support emails will remain operational though the entire server move.\nThank you in advance for your patience.\n[edit June 11, 2020] All key community based infrastructure has now been moved to the cluster. Moreover, the move went went surprisingly well and without any major hiccup.\nIn the coming weeks and months we\u0026rsquo;ll be adding more services to the cluster. I have already spoken to FireTwoOneNine about writing a short blog post about the cluster, its present utilization and future applications in the project.\nLastly, I\u0026rsquo;d like to thank all those who offered advise and were directly involved in this project.\n","permalink":"/2020/06/05/rockpro64-cluster-move-june-5-10/","tags":["cluster","community","pine64"],"title":"ROCKPro64 Cluster Move June 5-10"},{"categories":["community","pinebook-pro","pinephone"],"contents":"\nWith thousands of Pinebook Pro laptops and PinePhone smartphones shipping in the next days and weeks, I felt that a short introductory blog post aimed at newcomers was in order. To this end, the primary purpose of this entry is to give you an overview of all the resources at your disposal. Shipping Information and Updates You can follow the shipping progress of both devices in a dedicated PINE64 forum thread. I will update the thread on a need-be basis as new information becomes available. Support and Info teams receive the same status updates that I post on the forum, so there is no need to email them for general shipping queries.\nIf your device ships using DHL Express, then you’ll most likely be notified of shipment via SMS and/or email immediately as your order gets scanned into the DHL database. You will also receive a shipping confirmation email from us in days following the DHL shipping notification. If your PinePhone ships via Asendia then you’ll receive your tracking number directly from us. Due to the high volume of shipments, it may take a couple of days before the dispatch team emails you your shipping number. Please be patient. The Pinebook Pro With Manjaro KDE Plasma A quick PSA first**:** the factory left the WiFi privacy switch (as well as potentially also other privacy switches) turned ON during testing on some Pinebook Pro laptops, so you may have to disable the switch to re-enable WiFi**.** We apologize for the inconvenience this may cause. The Pinebook Pro ships with Manjaro which features the KDE Plasma desktop. Manjaro is a phenomenal Linux distribution with an equally great and thriving community. The developers are our friends and colleagues, and they can be reached on their and our forums as well as in our chats. To learn more about the Manjaro build which ships with your Pinebook Pro please see the following: PINE64 Manjaro forum thread Manjaro PInebook Pro Tips \u0026amp; Tricks forum thread For more general information about Manjaro Linux distribution please see: The official website Manjaro Wiki User Guide Manjaro is just one of many options at your disposal. The Pinebook Pro is able to run a vast number of other Linux and BSD operating systems, which can be booted from a SD card or installed to internal flash storage instead of Manjaro. For instance, you can boot Recalbox from SD (or USB) for recreation and retro gaming while keeping your full operating system on the Pinebook Pro’s internal flash storage. You can find an up-to-date list of available operating systems on PINE64 Docs. The Pinebook Pro sub-section of the PINE64 Docs also contains a wide variety of information concerning the laptop’s hardware, including: Schematics \u0026amp; certifications Datasheets of components Software and Operating System directory Troubleshooting procedures The greatest resource we have to offer, however, is our community. There are literally thousands of community members willing to help you out with getting started at any given time. Regardless of if you’re just interested in asking a quick question or wish to engage in testing and development on a daily basis, there are numerous ways to get in touch. Here are your options:\n[Forum](- Forum ) Official Reddit IRC Webchat Telegram Discord Matrix The PinePhone UBports CE This Community Edition of the PinePhone ships with Ubuntu Touch, a popular Linux community maintained smartphone operating system. While still a work in progress, Ubuntu Touch is one of the fastest progressing operating systems on our platform. We’re very good friends with the developers, and you can direct your questions to them both on their and our forums and chats (listed further down). To learn more about the UBports Foundation and its history:\nUBports Foundation UBports Wiki entry For general news and to follow ongoing development:\nUBports PinePhone Gitlab branch Ubports forum thread about the PinePhone UBports section on PINE64 forum Although this Community Edition ships with Ubuntu Touch, you can use many different mobile OSes on your device. Most if not all well established Linux-based systems are represented on the PinePhone so there are plenty of options to choose from. You can give any - or all - of them a risk-free spin by booting from a SD card. You can find an up-to-date list of operating systems on PINE64 Wiki\nThe PinePhone sub-section of the Wiki is a valuable community maintained information hub which, amongst others, includes:\nHardware Specifications Certifications and Schematics OS flashing instructions Components and peripherals datasheets The most important resource at your disposal, however, is the PinePhone community. We have fostered a sizable social platform that spans across multiple mobile Linux projects and is composed of developers, enthusiasts and end-users. Everyone is welcome to join in, be it to ask a quick support question or to actively engage with the project. Here are the community platforms: PinePhone PINE64 subforum PinePhone thread at UBports forum Official Reddit IRC Webchat Discord Martix Telegram Support and Queries All software support queries should be asked on the forums or in the chats listed above. Usually, hardware related problems and questions are also handled quickest by the community. There are, of course, instances where the community will be unable to provide support; for shipping related queries please email: info@pine64.org. For hardware support, please file a support ticket at https://support.pine64.org.\nLastly, I encourage you to subscribe to this blog to keep up-to-date on everything PINE64. Every 15th day of each month I publish a community update detailing what we have been up to in the past ~30 days and what we have in store for the coming weeks and months. I usually also take a look at the development status of the various devices and throw out ideas for you to comment on. Once again - Welcome into the community! I hope you found this post useful.\n","permalink":"/2020/05/28/welcome-new-community-members/","tags":["community","pinebook-pro","pinephone"],"title":"Welcome New Community Members!"},{"categories":["news","pinebook-pro","pinephone","pinetab","pinetime"],"contents":"\nWith the PinePhone and Pinebook Pro production well under way and shipping in just a few days time, we’ll now be turning our attention to the other projects we have in the pipeline. There is a fair bit of material to cover this month - the main piece of news, however, is that we’ll be taking pre-orders for the PineTab at the end of this month! This may be the longest blog entry in some time, so let\u0026rsquo;s get to it.\nTL;DR of this month’s community update:\nMoving to PINE64 cluster will be completed by this time next month; expect community services outages Shipping Pinebook Pros and PinePhones this month; don’t spam support/ info emails please We’ll be accepting payments in cryptocurrencies soon PineTab pre-orders start this month and ships with UBports’ Ubuntu Touch; please subscribe to blog for info when pre-orders go live PineTab adapters for individual and industry users; LTE, SSD, LoRa and RTL-SDR available soon PinePhone Ubuntu Touch OTA and factory image - a quick chat about the software PinePhone multi-OS bootloader is coming; many OSes showing signs of maturing Wireless charging coming to the PinePhone via add-on / using pogo pins A large (5000mAh) battery case for the PinePhone is being explored You will be able to support smaller PinePhone projects soon by buying their project branded case-backs Pinebook Pro - one week shipping delay explained Pinebook Pro you can now watch Netflix on Manjaro; many OS releases become available including official Debian support! Pinebook Pro USB-C dock details locked in; spare parts are now in the PINE Store Pinebook (original) gets a facelift; we’re committed to the $99 price-tag PineTime can now sync on Sailfish OS; app will be ported to Ubuntu Touch Housekeeping Moving community services over to the PINE64 cluster has hit a couple of roadblocks. As a result the process has been much slower than originally anticipated. While our IRC has already been moved to the cluster (thank you fire219 and Gamiee!) all the heavy lifting is still ahead of us. The good news is that we’ve now ironed out many of the core issues and expect to have everything moved in a little under a month from now. Since this will be a big undertaking, you should expect disruptions to various community services as the process begins. I’ll make sure there is a sufficient heads-up for when the next part of the move takes place. Keep an eye out for updates in the news section on the forum.\nOne of the PINE64 Cluster nodes with a 1TB NVMe SSD mounted in the PCIe slot\nThe next topic on the housekeeping agenda concerns shipping of the current PinePhone and Pinebook Pro production batches. Both devices are currently being assembled and should be ready for shipping in a matter of days. We are currently expecting Pinebook Pros with Manjaro to start shipping after May 22 and UBports CE PinePhones after May 26. However, with the Hong Kong border opening first on 7 June (at the very earliest) we had to pull off some magic to make shipping happen in the first place. This means there is a completely different logistics process in place for current shipments; on a purely human level, this will be a stressful time for the logistics and shipping teams, and therefore it would be greatly appreciated if you’d turn to us in the chat, forums or social media for updates rather than bombard info or support emails requesting updates. Thanks!\nPinePhone UBports CE being assembled\nIn other news, we recently ran a poll on Mastodon and Twitter asking whether you’d be interested in using cryptocurrency for PINE Store payments. On the whole, approximately a quarter of all respondents expressed interest in using such payment options. We\u0026rsquo;re now happy to announce that we’ll be accepting cryptocurrency payments (BTC, BCH, ETH and XRP) in the very near future. The payment infrastructure is currently being set up, and should be available as an option at checkout starting next month. [edit] We no longer intend to support cryptocurrency payments at this time.\nLastly, a quick word about our Wiki. If someone would find the time for tidying and adding information to the relevant sections then I’d be very thankful (as I do not currently have time for that). More specifically, the ROCK64, PINE A64 and SOPine sections need a fair bit of editing and their OS release lists need to be cleared of ancient software and new OS’ should be added. Apart from this, I’d also appreciate it if someone would review the release sections for the Pinebook Pro and ROCKPro64 - many new OS options are still missing. Anyone can do the above using their forum login and password. Thanks in advance! PineTab pre-orders With the PinePhone UBports Community Edition and Manjaro Pinebook Pro batches now shipping, we turn our attention to the PineTab. If you follow this blog regularly, then you already know that the tablet has been stuck in a production limbo since summer last year. The decision to postpone PineTab production was made with the purpose to prioritize assembly and shipment of Pinebook Pro and PinePhone batches - as these are PINE64 flagship devices. In light of the global events, which caused subsequent logistics turmoil, production was pushed back nearly 9 months. With the COVID19 pandemic subsiding in China, and factory lines reopening for business, we’re now happy to announce that we’ll be taking orders for the PineTab later this month.\nAlthough we’re skipping any formal naming of this PineTab batch, I need to underline that this is a limited-quantity pilot-production run. In other words, these PineTabs are similar in nature to Braveheart PinePhones - they are aimed at early adopters who understand the implications of purchasing an early production-run device. I have written a lot over the past 9 months about the PineTab, and about the gradual improvements we made to it and its keyboard while we waited for a suitable moment to start production. I suggest you go back and read the relevant posts for more details (https://www.pine64.org/tags/pinetab/). PineTab With keyboard attached\nHere is a quick run-down of the device\u0026rsquo;s specs; the PineTab has a 10” 720p IPS LCD panel and features the same quad-core A64 SoC and 2GB LPDDR3 RAM used in the PinePhone. It also features the same 2Mpx front-facing and 5Mpx rear cameras that the phone uses. It ships with 64GB eMMC flash storage, and capacity can be expanded using a SD card (which can also be bootable) or a SSD via an optional M.2 adapter. You also get a full-sized USB 2.0, a USB-OTG and digital video output. This is paired with a large 6000mAh battery that can be charged via Micro USB or the barrel plug. The tablet can be used in conjunction with a magnetically attached backlit keyboard that also doubles-up as a cover and stand. Pricing Details:\nThe PineTab - $99.99 The magnetic backlit keyboard - $19.99 PineTab keyboard doubles-up as a cover case\nSoftware-wise the PineTab is convergent with both PinePhone and Pinebook software releases. It will therefore, in time, run most mobile operating systems developed for our platform as well as popular desktop OS options. I am also certain that the number of choices will explode after the first batch gets into early adopters’ hands, and that we will see more desktop-oriented releases with touch input capabilities very soon. For this first batch however, we have decided to ship the PineTab with UBports’ Ubuntu Touch. The reason for this choice being that Ubuntu Touch works well for a traditional tablet use-case and, at the same time, converts into a more traditional desktop experience when the magnetic keyboard is attached. The transition is quite seamless and, frankly speaking, rather magical when you see it happen for the first time; check out the video Marius Gripsgard from UBports sent over showcasing this.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video UBports Ubuntu Touch runs so well on the PineTab - you need to watch this\nWe are also making an adapter board for the PineTab that will broaden its use-case application potential significantly. The adapter allows expansions to be mounted inside the PineTab chassis. Each module can be easily installed and swapped out by the end-user - all it takes is removing the tablet\u0026rsquo;s back cover and undoing a single screw. To make it clear, you can only add one type of additional functionality to the PineTab at a time. That said, multiple expansions can be installed onto the adapter board simultaneously - for instance, a SSD and LTE module can be simultaneously mounted, but only one or the other can be used at a time. Here are the expansion options we have in store for the PineTab:\nM.2 SATA SSD add-on M.2 LTE (and GPS) add-on LoRa module add-on RTL-SDR module add-on The PineTab expansion adapter board\nWe hope that this selection of expansion modules will make the PineTab not only interesting to private end-users but also commercial and industrial customers. Especially when paired with LTE or LoRa functionality, I can easily imagine the PineTab being used as a point-of-sales terminal or an in-field device. With its large capacity battery, and thanks to all the optimizations done for the PinePhone, the PineTab can easily last a full work day. You can expect the SSD and LTE adapter functionality to already work on the PineTab, granted you use the same LTE modem already supported by PinePhone software. Implementations of the LoRa and RTL-SDR modules into existing OSes will, as always, depend on developers from the different partner-projects. Pairing all this functionality with an accessible asking price, we cannot wait to see how end-users will employ this multifunctional device. More information about the PineTab will be coming very soon, so please subscribe to this blog so you’ll be alerted when pre-orders go live later this month. PineTab with LTE installed in the adapter PinePhone Let me begin by acknowledging the amazing work that the UBports team poured into delivering a great OS image to the factory. They really put a lot of effort into shipping a polished build. The most important feature of the OS image is the inclusion of OTA update capability. The PinePhone now officially supports OTA updates on Ubuntu Touch, which means that users will be able to update their devices without ever having to reflash the OS. All you’ll ever have to do is navigate to settings menu -\u0026gt; update and fetch the newest build. Moreover, if you decide to connect the PinePhone to WiFi on initial boot-up, then you’ll be prompted to update your Ubuntu Touch installation once you complete the setup wizard.\nI’ll go into more details about Ubuntu Touch on the PinePhone closer to delivery date and in a separate post, or better yet I may ask a UBports developer to write the post; what I will say at this time is, devs expect the day-one update to include most if not all key features bar the camera functionality (which will take a little longer to implement properly). I have a strong sense that many of you will be very impressed with the quality and performance of this build. For those of you who have Braveheart PinePhones - you can download the newest Ubuntu Touch image for the PinePhone here.\nhttps://www.youtube.com/watch?v=-MXOgb-U2jI\nMartijn Braam from postmarketOS showcases UBports CE edition factory image\nSince we’re already on the subject of software, I’d also like to give a huge shout-out to Martijn Braam from postmarketOS, who has put together the factory test OS image. For those who do not know, the factory test image runs a custom build of postmarket OS with the newest Linux kernel. It is now a feature complete and comprehensive test suite, which includes all radio connectivity, all sensors and inputs as well as both cameras. In other words, it tests all aspects of the device before it flashes the OS internal flash memory. If you want to check it out, and I know many of you Linux geeks love this sort of stuff, then here is the link. In other notable software news, Danct12 shared a photo of a multi-boot menu on the PinePhone. While this isn’t the first solution of this kind shown-off on the PinePhone, this one comes from the devs behind Jumpdrive, and therefore I find it likely this project will be brought to fruition and well maintained. The multi-boot implementation is said to also support both eMMC and SD. Multi-booting is a piece of functionality that many users have been asking for some time, and I expect that once DanctNIX folks make this available it will be universally used by most PinePhone owners. We may even choose to install it on the factory floor in the future for general (non-CE) PinePhones. Let me know what you think in the comment section. PinePhone multi-OS bootloader via Danct12\nWe have also seen a lot of progress, including significant performance improvements, on a number of OSes. It would take me too long to list every single improvement made across all the available builds, so instead I’ll focus on some of the highlights: Sailfish OS and Nemo Mobile can now make phone calls and feature a working web-browser (and run remarkably well!); postmarketOS’ makes it now possible to boot X86 PCs (and theoretically also the Pinebook Pro) from a virtual drive on the PinePhone; a-wai, the developer behind the popular Debian+Phosh build, has christened the project Mobian - the recent Mobian build implements crust deep-sleep allowing the PinePhone to run for upwards of 12 hours with radio (WiFi and LTE) connectivity enabled; lastly, Jolla is asking you to let them know if you’d like official SailfishOS support for our platform - I gently suggest you do so if you’re remotely interested in running Sailfish OS on your PinePhone. In PinePhone hardware news, we’re happy to announce that Qi wireless charging is coming to the PinePhone in the very near future. We’re currently working out the exact details of the charging coil implementation and making a series of related decisions, such as for instance whether we should bundle a charging plate with the add-on. If you have a suggestion then make sure to leave a comment in the section below. What is certain, however, is that this will be a universal Qi wireless charging implementation utilizing the PinePhone’s pogo pins. This also means that if you already have a Qi charging surface or station for your current phone then this implementation will, in all likelihood, ‘just work’ with the PinePhone. I should have more details regarding this subject in next month’s community update; we are currently expecting the wireless charging add-on kit to be available in approximately July this year. Here\u0026rsquo;s the Qi charging coil we\u0026rsquo;ll be using\nWe have also begun exploring creating a battery case for the PinePhone. Although we’re confident that the PinePhone will eventually be capable of providing end-users with a full workday battery life, the reality of it is that - especially under heavy usage scenarios - battery life on the PinePhone may never match flagship Android devices. We understand that some users may require to use their PinePhone for hours at a time (on-screen time), and one way to remedy this situation is by adding a larger battery to the phone. To be precise, we’re currently exploring creating a 5000mAh battery case that would more than double the devices on-screen time. Keeping in mind that we will, eventually, reach ~16-20 hours standby time on the PinePhone via software improvements - let me know in the comments if such a battery case is something you’d be interested in. One other hardware-related topic I wish to briefly touch on concerns the optional PinePhone keyboard, which we announced a couple months ago. Long story short, presently isn’t the right time for us to take on this challenge - molding for the keyboard is very expensive and face-to-face communication with the vendor is currently impossible due to the closed borders. Investing effort and money into this endeavour at present time, when we cannot evaluate the hardware’s progress remotely, would be a risk that we’re not willing to take. So instead we’ll focus on other hardware and peripherals, and revisit the PinePhone keyboard concept when these uncertain times come to an end. It will happen, I assure you, but not now. The last topic in this section I wish to discuss regards support for individual PinePhone developers and smaller projects. We have been thinking about this internally over the past couple of months and arrived at the conclusion that it will be very difficult for us to run full-blown campaigns, such as the current one for UBports, for smaller projects. Here is our solution: we will sell custom back-covers for smaller projects featuring their logos in the store. We will charge $15 for such a cover, out of which we will donate $10 to the project. The regular plain cover, already available in the store for $5, will obviously remain an option to those who just want a replacement back for their phone. We hope that this will help smaller projects have a chance to grow and thrive. Pinebook Pro The Pinebook Pro production-run featuring the Manjaro KDE Plasma build will soon be heading out to end-users. We had to delay shipping by a week due to an unforeseen complication at the factory. If you’re interested in the details of the delay then read on, if you’re not the skip to the next paragraph; the factory testing image, which is built on a custom Android image booted from a SD card, failed to load up using the u-boot included with the Manjaro OS image which has already been flashed to eMMC. Prior to shipping the build out to the factory a couple of weeks ago, the developers and I diligently tested booting OS images from SD and encountered no issues. We did not, however, account for booting any Android images (this is my fault - I should have thought about it). Regardless, all Pinebook Pros now need to be disassembled so that their eMMC disable switches can be flipped for testing purposes. As you can well imagine, with many thousand units required to undergo the tests, this will require time and hence the shipping delay. Apart from this short delay in shipping, I have nothing but good news for all of you waiting for your Pinebook Pros to arrive. Thanks to the work of Spikerguy and Strit from the Manjaro ARM team you are now able to watch Netflix, Amazon and other Widevine DRM protected content on Manjaro KDE Plasma in Chromium. I am happy to report that playback of both Netflix and Amazon content is smooth even when viewed at full HD resolution, and the process of installing the custom 32bit Chromium build running in a docker container has now been streamlined for end-users. This is a welcome addition to the already incredibly polished Manjaro OS image, which I wrote at length about last month. I can now say with complete confidence that the Pinebook Pro has become a daily driver for light-to-moderate workloads.\nNetflix played back on the Pinebook Pro - via Strit from Manjaro ARM Team\nOn the subject of software, the single most important release for the Pinebook Pro this month is Debian. Yes, that’s right, the Pinebook Pro - alongside other PINE64 devices - now has official Debian support. This is obviously great news, but I still strongly suggest opting to use the Debian Installer for the Pinebook Pro created by Daniel Thompson instead. The installer allows you to build and run a feature-complete mainline Linux Debian OS image in no time without hassle. In other software news, ayufan has now a series of mainline Linux pre-release OS images available for the Pinebook Pro and other PINE64 devices. The notable addition to the Pinebook Pros line-up of available software is Ubuntu 20.04 with GNOME desktop. Please keep in mind that, at the time of writing, these images are in a pre-release state, which means that some (or all!) aspects of the software may not be functional. Lastly, since I am asked at least twice a week about Kali Linux on the Pinebook Pro, I am happy to report that new OS images have just been released and are bootable from both eMMC and SD. From the little time I’ve spent using Kali on the Pinebook Pro, I am happy to report that it runs well and smoothly and - from what I can tell - all the tools you expect this distribution to offer work as intended. Both ANSI and ISO keyboards are available in the Pinebook Pro spare parts section\nIn hardware news, we’ve now settled on our Pinebook Pro USB-C docking station I/O connectivity and the general form-factor of the dock. I’d like to thank all of you for offering your suggestions and feedback in the comment section regarding the dock - we’ve taken your suggestions onboard. The dock will be attached to - or slid under - the bottom of the Pinebook Pro chassis, with all I/O facing towards the back of the laptop. The docking station will offer 3x full size (A) USB 3.0 ports, a Gigabit Ethernet port, full-sized and micro SD card slots, as well as both a digital video and a VGA output. The dock will also be capable of delivering power to the Pinebook Pro via the USB-C connection and it itself will be powered using a USB-C PD cable. We are currently waiting for the final design of the dock, and I hope to be able to show you photos of it next month. Lastly, spare parts for the Pinebook Pro are now also available in the PINE Store. Both ANSI and ISO keyboard segments are available for backorder as we await for these spare units to arrive to us from the Pinebook Pro factory. Pinebook As I already wrote in last month’s post, the original Pinebook 11.6” will soon be making a return to the PINE Store. I do not have a firm date just yet, but it should be soon after the upcoming pre-orders of the PineTab come to an end. We’ll also be making a couple of aesthetic changes to it - both to freshen is up as well as bring its looks in-line with our remaining products. The Pinebook will now come in a sleek all-black chassis and, similarly to its big brother, feature no branding on the case except a PINE64 logo on the SUPER key. We’ll also be tweaking the keyboard layout slightly to bring it closer in-line with the one used on the Pinebook Pro. In terms of other changes, future Pinebooks will ship with an IPS 768p LCD panel and Manjaro with XFCE. We feel that the 1336x768 resolution is a better fit for both the small Pinebook screen as well as the A64 SoC. This is a good quality 768p IPS panel and, when paired with the excellent mainline Linux build of Manjaro XFCE, it makes the Pinebook feel snappy and responsive. There is, of course, also a financial aspect to this decision - namely, component pricing has gone up significantly in recent months, and the $99 price-tag (which is already subsidized by the PINE Store) would be impossible to maintain with a higher resolution panel. The $100 price-tag is important for us to maintain because we have already begun on building up a portion of upcoming OG Pinebooks for charity. More information on the Pinebook and how we will start on our project to help close the digital divide coming next month - stay tuned.\nPineTime I’ve written about the PineTime software progress at length in the past two months, showcasing the smartwatch’s OSes and the amazing community driving them. In March I wrote that we’ll be looking to have the PineTime supported across both Linux mobile OS and Android; two months later, the PineTime is able to communicate with both mobile and desktop Linux as well as Android. Pretty amazing, isn’t it? Adam Pigg, one of the developers working on the Sailfish OS port for the PinePhone, worked together with JF and other PineTime developers to include core smartwatch functionality into an existing Sailfish OS application called Amazefish. The PineTime can now sync time as well as receive notifications from any Sailfish OS phone, which includes the PinePhone of course.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video PinePhone and PineTime chatting away! - via Adam Pigg\nThis Sailfish OS application will be ported to Ubuntu Touch and, in time, maybe also other Linux mobile operating systems. I suspect that while it may be possible to port this application to other Qt based systems - such as KDE Neon, Manjaro or even NEMO Mobile - we’ll need something else for systems using Phosh and GNOME as front-ends. In a recent tweet Lup Yuen Lee implied that he will be using gotk3 to build a GTK3 companion app for the PineTime. In the end, I am certain that a number of solutions will be available to sync the PineTime with your PinePhone or Android phone. As for the latter, I’ve now reached out to the Gadgetbridge developers and they\u0026rsquo;ll be supporting PineTime on the Android platform. That will be all for this month’s update - comment away!\n","permalink":"/2020/05/15/may-update-pinetab-pre-orders-pinephone-qi-charging-more/","tags":["pinebook","pinebook-pro","pinephone","pinetab","pinetime"],"title":"May Update: PineTab pre-orders, PinePhone Qi charging \u0026 more!"},{"categories":["news","pine64-community","pinebook-pro","pinephone","pinetab","pinetime","rockpro64"],"contents":"\nI hope and trust this update finds everyone well. Production in China is picking up pace and we expect to start shipping the Pinebook Pro with Manjaro and PinePhone UBports Community edition next month. I am happy to report that, for the time being, everything is proceeding smoothly and we’re on track to ship devices in accordance with our original plans. Still, I encourage you to sign up to this blog to stay up-to-date on shipping information since anything can happen in the next 30 days. Here is the TL:DR for this month’s community update:\nROCKPro64 cluster is up and running; IRC and Matrix will be moved over to it soon We’re shipping surgical masks to those in need in your local community PinePhone UBports edition gets CE, FCC and RED certifications UBports Ubuntu Touch shaping up nicely; major development milestones reached Other PinePhone OSes begin maturing; state of development + new phone OS CRUST suspend on the PinePhone; 15 hours battery now possible Schematics for PCBA v1.2 available after testing; v1.2 will be available in the store for BH users eventually Pinebook Pro Manjaro KDE build is very polished; development report Docking your Pinebook Pro using USB-C; using Manjaro mainline kernel We’re making our own USB-C dock; better ergonomics than most OEM options RK3399 OG Pinebook upgrade kit testing and challenges; we’ll likely use graphene for cooling PineTab delayed until pandemic over; ready for fabrication and report of improvements + tablet keyboard is ready The PineTime is now a smartwatch; BLE notifications support; we need a Linux + Android companion app OpenWRT on ROCKPro64; what do you think about a ROCKPro64-based router? Housekeeping The PINE64 ROCKPro64 cluster has finally made it to its location at BBXNET and the process of setting it up began. For those who don’t know, in November last year we announced that we’ll be moving our services over to a custom 24-node ROCKPro64 cluster. At the time of writing the cluster is already up and running but not quite ready for having services moved to it just yet. The set-up process was interrupted by stricter social-distancing restrictions in the country where it is hosted, but we expect that in a week or two the process will resume. Once we have access to the server farm again we’ll slowly start transferring services. IRC and Matrix chats will be the first to be moved over, followed by other community-centric services such as the Wiki and forums. I’ll have more for you on this subject as it happens; in the meantime I invite you to enjoy the pictures of the cluster below.\nROCKPRo64 PINE64 cluster\nPCB detailed look\nThis month we also announced that we will be contributing to COVID-19 relief efforts by donating surgical masks to where they are needed. This has been met with a phenomenal response from the community resulting in tens of thousands masks shipped. We still have some mask cartons left, so if you know of an institution in need of gear to protect their staff or dependants then make sure to contact me. The masks will be delivered in your name to a dedicated address charge free if you have been actively engaged with our community. Details can be found here. Mask boxes\nDepiction of masks on the box\nLastly, I’d like to point your attention to a PSA I was recently compelled to release, in which I ask community members to stay away from the r/pinephone subreddit. Unlike all other community run subreddits concerning PINE64 equipment, we find this particular subreddit to be run in bad faith and potentially for malicious reasons. I’d like to take this opportunity to also shut down the notion that we’re ‘after’ this subreddit because it encourages those subscribed to sell and buy second-hand PinePhones. Your PinePhone is yours to do what as you please - keep it, sell it, throw it into a lake or make it into a dollhouse dining table, we have no say in it either way. PinePhone As I’m sure you’re all probably already aware, the UBports Community Edition (CE) PinePhone is now up for pre-order with an expected shipping window of late May. We’re very excited for this first CE of the PinePhone - our cooperation with the UBports developers has been a cornerstone of the project from the very start and we’re happy to call them our friends. I won’t reiterate everything that has already been said and written about this edition in the past two weeks, and instead refer you to the official announcement on this blog. This CE ships with Ubuntu Touch preinstalled and addresses some of the issues identified in Braveheart PinePhones. It also comes packaged in a box with custom artwork from the UBports team (I’ll keep a secret - I don’t want to spoil the surprise for you), includes UBports Yumi mascot etched on the back of the phone and includes a multilingual user manual and a charging cable. I’d like to give a huge shout-out to all those who helped in translating the user manual to their mother tongue; it never ceases to amaze me how people step-up in this community to make things happen and help us out. You guys are awesome.\nPerhaps most important of all, this PinePhone edition includes CE, RED and FCC certification. Getting this certification ‘done’ has been a major undertaking and I’d like to thank all those who have helped in its completion. For those who are unaware, CE, RED and FCC the PinePhone is in compliance with regulatory requirements in all our key markets.\nLabel with FCC and CE markings\nDevelopment on the build that will ship with the UBports CE is coming along at a very rapid pace. Just in the past few weeks we’ve seen implementation of the proximity sensor (which activates when you’re on a call), a wake-up trigger for the screen on an incoming call, notification LED, Bluetooth integration, the vibration motor as well as audio auto-routing. The OS will also run much smoother with a newer mesa version (not in current image at time of writing), making the device feel considerably snappier. In a video I published on a whim, I also showcased the camera working on Ubuntu Touch; it is my understanding that the implementation I showcased is quite hacky, so it may not be present in the build that ships.\nCurrently the development is focused on improving battery life, proper camera implementation and OTA updates. I’d also like to assure everyone that OSes, including this one, will be supported by all revisions of the PinePhone - this obviously also extends to BH PinePhones. Developers are now starting to incorporate more advanced battery preservation methods, notably CRUST (suspend), into their OS images. Upcoming Ubuntu Touch and KDE Neon images will ship with CRUST, extending the PinePhone’s battery life past 15 hours with the LTE modem and BT/WiFi module on. This feature is currently in early stages of testing but it is already working very well overall; I expect you’ll start seeing OS images with CRUST suspend available in a matter of days. This is obviously an important development, as an improved battery life brings the PinePhone closer to achieving daily driver status for those who want to use it as their only smartphone. https://www.youtube.com/watch?v=3Ne6G0-hn9g\nA quick and crude look at Ubuntu Touch on the PinePhone\nIn other software news, we’ve seen a lot of improvement to popular OS choices as well as introductions of new ones. In the past few days I have used KDE Neon, Postmarket OS and Debian with Phosh. I found all of these OSes performing exceptionally well nowadays, especially in terms of UI fluidity. Let me start with KDE; I was very impressed with both its new features as well as how it performs even when running from an SD card. The most recent KDE Neon image supports autororation, incoming and outgoing calls, auto-brightness and all key functionality of the modem. Installing most common applications, such as Telegram, was a breeze and I was pleased to see the phone responding snappily to the power button being pressed to lock the screen. Little things, such as volume keys working and a power-dialogue showing when the power button is held down, have also been implemented since I tried the image last. The latest image has a significantly improved battery life, a reduction in battery consumption of 30-35% from previous OS iterations, thanks to Sameul’s work on suspend. It is a real pleasure to see Plasma Mobile mature, and I hope and trust the PinePhone has contributed to the maturing process in no insignificant way.\nThe two popular OSes using Phosh as the front-end are Postmarket OS and Debian with Phosh; despite sharing a common front-end, the two systems differ somewhat in terms of bundled applications and some features and functions. Postmarket OS exposes - for a lack of a better word - more options in the settings menu and ships with a cutting-edge kernel (5.6). Debian, on the other hand, has a couple more features implemented - such as auto-brightness and the proximity sensor. Both have functional GPS, incoming/outgoing calls (with great sound quality), SMS support and well as LTE - all initiated on boot. Both also ship with Firefox alongside the default GNOME browser; Firefox works really well on both and scales nicely to the screen-size of the PinePhone. I am including a short video from an end-user, showcasing the most recent build of postmarket OS on the PinePhone. In terms of New releases, NixOS is now available for the PinePhone for those who wish to try it out. I have not yet had the chance to run it but it is my understanding that all NixOS core functionality works well out-of-the-box on the PinePhone.\nIt\u0026rsquo;s all about choice\nBefore moving on to the next segment, I’d also like to mention that the revised schematics for the v1.2 PCBA in the UBports CE PinePhones will be available in the Wiki once the new boards pass all required tests later this month. I know a lot of Braveheart owners also ask about availability of the v1.2 PCBA revision in the store - the answer to this is ‘yes’, it will eventually be available in the spare-parts store section, but we really do not see a point in getting a newer PCBA as v1.1 will be supported forever.\nPinebook Pro The Pinebook Pro production is underway and it presently looks like shipments will go out at the same time or prior to the UBports CE PinePhones. Obviously the most important fact about this upcoming production-run is the preinstalled OS. I wrote about this at length in last month’s community update, so rather than reiterating what I already wrote I’ll offer a closer look at the state of Manjaro on the Pinebook Pro. The Manjaro team has been working on delivering the most polished and tailored build of KDE yet. I am now confident that this effort will result in a true daily-driver device for light-to-medium tasks. I cannot overstate the level of testing and polish that has gone into this build; it extends to custom backgrounds for the Pinebook Pro, optimised trackpad settings, additional popular applications such as KODI and the right amount of opacity for the panel and menu. On first boot you’ll also be asked to complete an OEM setup, selecting your username and password, your keyboard layout, locale and language preferences.\nThe Pinebook Pro Manjaro wallpaper is pretty stunning in my opinion\nI often use the Pinebook Pro for writing on-the-go and then revert to using my stationary computer at home. With the pandemic lockdown now in place, I figured that I’d try docking the laptop and seeing how it will hold up as a desktop replacement. To my surprise, even at 1440p, it worked extremely well. Apart from the obvious benefits of having a device that is mobile on the one hand and can perform the task of a low-load workstation when docked on the other, it\u0026rsquo;s worth pointing out that the Pinebook Pro can be powered from a 15W power supply - while my stationary PC requires a 650W power supply. So, for light tasks, I’ll keep using my Pinebook Pro from now on, as it\u0026rsquo;s better for the energy bill and the environment.\nPinebook Pro docked\nWe are currently in the process of making a custom USB-C dock for the Pinebook Pro, which will include all of the key features we expect everyone wants while delivering better ergonomics than most existing third-party docks lack. In short, after testing a number of common OEM USB-C docks, we arrived at the conclusion that we really don’t like how they handle cable management. Our dock will have all inputs and outputs stacked on one leading edge, so that you can have it sit nicely on your desk with the cables facing in one direction. As for functionality, you can expect power-in, HDMI out, USB 3.0 as well as a Gigabit Ethernet connection. These specs are not final, so if there is something you’d very much like to see added then make sure to let me know in the comments section. Pinebook Pro-ish\nLastly, work on the upgrade RK3399 kits for the original Pinebook is underway. We already did a fair bit of testing to determine the best way to cool the SOC in the plastic chassis. Our initial ideas to cool the RK3399 using a thin sheet of copper fell through, as the SOC ran hot and throttled quickly under moderate load. We’ve now moved onto testing using a graphene cooling system, which we believe will deliver much better thermal dissipation performance. One issue I’ve encountered insofar is with getting the keyboard firmware to play nice with the Pinebook Pro board - as a result, I expect this is likely something developers will have to get their hands on prior to end-users.\nPineTab I wish I had some good news for you regarding the PineTab, but we’ve made the decision not to ship the device during the pandemic. With the two major devices - the PinePhone and Pinebook Pro - already proving difficult to arrange shipments for at this point in time, taking on additional burden is something we consider unwise. At the same time I’d like to assure you that the tablet is very much still in the works and something we sell this year, hopefully as soon as COVID-19 loosens its hold on the globe.\nMuch of the PineTab PCBA and body-work are, in fact, already at a fabrication stage. Even the backlit keyboard has now been customised to our spec and is ready for manufacturing. Speaking of the keyboard, we’ve made a number of improvements to it and its attachment mechanism based on feedback from developers. The keyboard has a white multi-level backlight and is branded with a PINE64 logo on the SUPER key in a similar fashion to the Pinebook Pro. The magnets that hold the keyboard attached to the PineTab have been considerably beefed up, so you can even lift the tablet up with the keyboard attached without it falling off (not that I advise or recommend doing so).\nNew and improved PineTab keyboard - look how many magnets!\nWe’ll treat this delay as an opportunity to further review existing OS images for the PineTab to determine which of the existing options would best suit an early-adopters edition. Earlier this year at FOSDEM I saw Ubuntu Touch running on the PineTab and I was very impressed at how well it performed. This was over 2 months ago and since then development has made significant strides in terms of both performance and overall functionality. Admittedly these advancements have been made on the phone, but I expect that all improvements are directly transferable to the tablet. There are, of course, other options including more traditional desktop OSes such as Manjaro to consider too. Regardless of what we decide on in the end, the delay - while unfortunate and unplanned for - can turn out to be good for the PineTab project, as we’ll be able to ship a better performing and more polished OS on it from the very start. If you’re interested in the PineTab then I encourage you to subscribe to this blog. I’ll make sure to keep you updates as more information becomes available.\nPineTime Last month I reported on PineTime development in which I focused on JF’s incredible work. We currently feel that this firmware stands the best chance of becoming the first to ship with an end-user PineTime production-run later this year or early in 2021. Since last month’s update we saw another major milestone in PineTime development, namely BLE notification support. This effectively turns the PineTime from a ‘dumb’ watch capable of syncing with an Android or Linux phone, into an actual smartwatch capable of displaying notifications on your wrist.\nHowever, for this functionality to actually work we need a companion app for the PinePhone and Android. I’ll be reaching out to relevant people whom I know of, asking if they’d be willing to work together with JF and other PineTime developers on porting an app to mobile operating systems. But consider this a ‘call for development’ - perhaps you’re interested in taking on the challenge? If yes, please reach out to me or JF and have a chat about what you’ve got in mind.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video JF showcases early work on notifications on the PineTime\nROCKPro64 I rarely focus on SBCs in my community updates because, well, I assume that most people who pick up a SBC know more-or-less exactly what the capabilities of a particular board are and what they want to use it for. Moreover, unlike the PinePhone, PineTime or Pinebook Pro, which are ultimately built to serve a particular purpose, SBCs are development platforms and deployed in a wide array of projects and scenarios. Covering all applications of a SBC, however interesting that may be, lies outside of the scope of community updates on the blog; that said, if someone wants to run a dedicated SBC segment on the blog then I’d be happy to accomodate this, as I think it\u0026rsquo;s a great idea. You know where to find me. One recent project sparked my personal interest however, so I want to report on it here. Tobias (Manawyrm) from Manjaro managed to build OpenWRT for the ROCKPro64 and have it play nice with a PCIe GbE expansion board. The ROCKPro64 could even be used with a 10GbE card thanks to the PCIe connection. Tobias has already issued a pull request for his work on the ROCKPro64, and when accepted I can see us exploring this concept further. I have already voiced my interest in making a router in the past, and with reports of the ROCKPro64 performing well in this role, I will be asking TL to brainstorm this notion further. I am thinking of a special router-oriented enclosure and a 4xGbE expansion board, as well as u.fl cutouts in the case to mount high gain antennas for the AC module. What do you think, should we explore this further? Would you be interested in building your own ROCKPro64-based router? Let me know in the comments.\nPhoto via Tobia\u0026rsquo;s Twitter\n","permalink":"/2020/04/15/april-update-ce-fcc-software-update-and-diy-router/","tags":["pinebook-pro","pinephone","pinetab","pinetime","rockpro64-2"],"title":"April Update: CE \u0026 FCC, Software Update and DIY Router?"},{"categories":["community","news","pinephone"],"contents":"\nPinePhone UBports Community Edition mock-up; final product may differ in appearance.\nI am proud to announce that the PinePhone UBports Community Edition is now available for pre-order with an estimated shipping date of late-May, 2020. Community editions are meant to bring exposure to partner-projects operating systems and communities, as well as help finance ongoing development. UBports were some of the very first to embrace our initiative and to offer support for the PinePhone. Together with their friends and colleagues from other projects, UBports developers have now become an integral part of PINE64, actively shaping our goals and aspirations. It is therefore fitting that UBports Foundation will be the first partner in our Community Edition scheme, in which we will ship a customized PinePhone with UBports’ operating system and donate all profit from sales to the foundation (more information on the scheme here). The PinePhone UBports Community Edition ships with a customized case (etched with the project’s mascot - Yumi), a revised PCB (v1.2) featuring improvements based on feedback from Braveheart developers and testers, as well as CE and FCC certification. To learn about the state of the software and to pre-order this community edition the PinePhone, please click the button below - you will be redirected to UBports blog.\nUBPorts Blog Entry https://www.youtube.com/watch?v=3Ne6G0-hn9g\n","permalink":"/2020/04/02/pinephone-ubports-community-edition-pre-orders-now-open/","tags":["community","pine64","pinephone","ubports"],"title":"PinePhone UBports Community Edition Pre-Orders Now Open"},{"categories":["digital-divide","pinebook-pro","pinephone","pinetime"],"contents":"\nCOVID-19 recovery in China is underway and factory work is slowly returning back to normal. This is good news, and we hope to have a constant stream of updates for you in the coming weeks. That said, we’re taking it one step at a time, since factories are still at 20% of the normal manufacturing capacity and it\u0026rsquo;s hard to predict the recovery pace. So rather than offering you my guesstimates for particular device availability, we will make announcements once all stages of production are secured for each device. Frankly speaking, this also means that announcements will likely drop suddenly; so If you haven’t done so yet, this is probably the time to subscribe to this blog and be notified when it happens. The big news of this community update is that Pinebook Pros are about to re-enter production and will be shipping with Manjaro KDE as the default operating system! Pre-orders for the new production run starts on Wednesday (March 18th) and shipping is planned for early May. TL;DR for this month\nMoving PINE64 services to the PINE64 cluster Spare parts for the PinePhone and Pinebook Pro OG Pinebook entering production for charity; closing the digital gap PINE A64-LTS will be produced until 2025 Pinebook Pro pre-orders start March 18th; expected shipping date early May Manjaro KDE is the new default OS for the Pinebook Pro! mainline kernel 5.7 mainline Pinebook Pro support Minor Pinebook Pro refinements and tweaks PinePhone development is steaming ahead; new OSes and features PinePhone soft and hard protective cases available soon PineTime OSes start coming together; first glimpse at a fully fledged FOSS OS Housekeeping We’re getting ready to move PINE64 community services to our ROCKpro64 cluster. The IRC and Matrix are the first services on our list, which means disruptions to all chats are expected at some point this month. We obviously hope that the downtime will be minimal, but given the complexity of our communications setup - which spans across multiple chat protocols bridged together - we cannot rule out that things may be a bit iffy for a few days before kinks are ironed out. I’ll make sure to give everyone a few hours heads-up when we’ll commit to the move so as not to disrupt ongoing workflow in the chats without a notice. With IRC and Matrix successfully migrated over to the cluster, we’ll be looking at moving the forums and Wiki next. This, however, will likely first be happening mid-April. The second piece of important housekeeping information concerns the availability of spare parts for the Pinebook Pro and the PinePhone. I recognize that this has been some time coming, but unexpected events - such as social unrests in Hong Kong and the COVID-19 outbreak - have made it hard for us to stick to initial production schedules. At any rate, spare parts for the PinePhone will be available in the PINE store within two weeks time, closely followed by parts for the Pinebook Pro later this month or in early April. Spare PINE64-branded batteries for the PinePhone will also be available but only in the USA. Further information about the parts and shipping options will be announced as items appear in the PINE Store. We are also starting to look into resuming production of the original Pinebook. Last summer we announced that we will be contributing to closing the digital gap by producing subsidized Pinebooks and distributing them to groups of people in need of a simple, reliable and easily repairable laptop. These Pinebooks will be subsidized from sales of the soft silicone cases for the PinePhone (more on this later). In short, 10 PinePhone transparent silicone cases sold amounts to one subsidized Pinebook produced. Once production resumes and everything returns to normal at the factories I’ll be setting up a committee and installing some democratic process allowing us to collectively decide on who should receive these Pinebooks. I’ll have more information on this topic as we get closer to production date. Noteworthily, a sizable portion of the Pinebook production-run will also be available for purchase by end-users. The last point on our housekeeping list is primarily aimed at our industry end-users; we’re happy to announce that the PINE A64-LTS production has been extended by 3 years. We recognize that the PINE A64-LTS is utilised in a wide variety of industrial and commercial applications, and that a sizable number of businesses rely on it to complete a job or deliver a service. We therefore commit to deliver the PINE A64-LTS until the year 2025 (N.B. the product page is yet to reflect this change). This date will, however, in all likelihood be extended further into the future if end-users decide to remain on the platform. Pinebook Pro As many of you know we have developed and fostered a truly special relationship with the Manjaro team over the course of past 3 years. Their OS images for our single board computers and the original Pinebook were and remain some of the best supported software options to date. It is therefore no surprise that Manjaro builds for the Pinebook Pro have also proven to be highly popular among our community members. Manjaro currently offers a KDE, XFCE and i3 variant of their OS image for the Pinebook Pro, each of which provides a highly tailored experience. These builds feature a cutting edge Linux kernel (5.6 at the time of writing), which supports all key Pinebook Pro functionality including USB-C charging, USB-C video out and are compatible with a number of USB-C docks. Out of the three, KDE version is arguably the most end-user friendly and polished, not in the least because Plasma makes use of the Panfrost open source GPU driver for desktop and application acceleration. Original Pinebook showcased at Manjaro booth, Linux-Tage 2019\nWe’re excited and proud to announce that future Pinebook Pros will ship with Manjaro KDE as the default operating system. Pre-orders for the next production run of Pinebook Pros starts on March 18, 2020 with an estimated shipping date of early May, 2020 (once Hong Kong border opens to our shipping staff). The image that ships with the upcoming Pinebook Pro batch features an additional layer of polish, which extends to a custom set of wallpapers and tweaks to the default application list to include popular software. If you are a Manjaro enthusiast, then I probably don’t need to convince you any further, and if you haven’t gotten a chance to try Manjaro yet then I suspect you’ll really enjoy the out-of-the-box experience. Speaking of the out of the box experience, Manjaro ships with an OEM setup / installer that allows you to set your username and password as well as choose your keyboard layout and system locale on initial boot. ANSI (left) and ISO (right) Pinebook Pros running Manjaro with KDE Plasma\nIf Manjaro isn’t your OS of choice, then you’re of course welcome to try any of the many options available for the Pinebook Pro. Nearly all available OSes can be booted from a SD card and, once you find what you’re looking for, the chosen distribution or *BSC can be installed to eMMC flash memory. The list of available software is continually growing with new, novel and interesting releases becoming available weekly. Two notable releases from the past couple of weeks include Recalbox (pre-release) by the one and only MrFixIt, as well as postmarketOS and Slackware. So if you’re keen on trying something different (and yet familiar - since posmarketOS is built on Alpine Linux), or experience Slack nostalgia, then here’s your chance. I am also sure that retrogaming enthusiasts will be happy to see a dedicated Recalbox image for the Pinebook Pro; the Pinebook Pro is able to run Dreamcast and PSP games at upscaled resolutions at full speed, making it a great on-the-go gaming system. One of the cool features of Recalbox is that if you boot with either an USB-C-to-HDMI dongle or a USB-C dock connected, then the output will automatically switch to the external monitor. Recalbox on the Pinebook Pro via Vercas\nI almost forgot to mention that there is now also a dedicated Kali Linux OS image (which happens to be something many of you have been asking about) so you no longer have to rely on the build script to generate your own image - all you need to do is DD the provided Kali image to a SD card and try it out for yourself. Kali Linux on the Pinebook Pro\nThe OS choice for the Pinebook Pro will expand even further in the coming months since - thanks to efforts by Tobias from Manjaro and other developers - the RK3399, and many of the core Pinebook Pro features, will be included in the mainline kernel 5.7. This means that you’ll be able to download any generic ARM64 OS image provided by a distro and use it on the Pinebook Pro (!). I suspect that the generic builds will not be as feature complete or functional as those tailored for the Pinebook Pro (as well as ROCKPro64 and HardROCK64), but this is a very important step nonetheless as it significantly simplief OS porting to our platform. The last bit I want to touch upon in this section concerns minor structural tweaks to the Pinebook Pro construction. I’ll write up a more complete list of these improvements this coming week and post them on the Wiki - here I’ll focus on the more significant changes: 1) stand-off height for pillars holding the keyboard and bottom of the chassis together has been improved; 2) kapton tape is used in places where electrical shorts can introduce interference to audio devices; 3) soft non-conductive standoffs are used around various parts inside the case preventing shorts and making it more sturdy; 4) screen bezels are now not only pressure-fitted but also held in place using adhesive tape - this prevents dust from entering the crevices between the LCD and the bezel; 5) the plastic formula was tweaked to make the plastic less brittle. In all likelihood, none of you would notice these changes unless explicitly told about them; I have a reason to believe so, since the ANSI batch already included most, if not all, of these changes. PinePhone Before I proceed to write about the current state of PinePhone software, I first want to write a few words about the PinePhone itself. Undoubtedly many of you are anxiously waiting to hear news concerning PinePhone production resuming following the novel coronavirus recovery. I want to assure you that the PinePhone is at the top of our out ‘to-do’ list, however there are yet a number of things we need to work out before the next production-run gets commissioned. In short, we’re working on it. On a topic somewhat related to hardware, I’d also like to mention that both the hard (black) and soft (transparent) protective PinePhone cases should be available in the PINE Store within two weeks time. I have written about the cases in the past so I won’t repeat myself, but the one noteworthy piece of information that I wish to underline is that revenue from sales of soft cases goes to manufacturing the Pinebooks aimed at efforts to close the digital divide (please see Housekeeping section).\nTransparent silicone case (left) and hard black case (right)\nSoftware-wise things are moving quickly and starting to look good. As always, in a project that has so much depth and breadth as the PinePhone, it will be difficult for me to cover all aspects of development that have taken place in the past 30 days. Instead, I’ll focus on the key developments and some of the more interesting things that transpired recently. Let me start with what is undoubtedly most interesting to existing and prospective PinePhone owners, namely outgoing and incoming phone calls. The key development here, as I understand it, is that megi and smaeul - along with other developers - managed to get automatic audio-routing working in late February. This effectively means that the audio output can change dynamically when making or receiving phone calls. In other words, you can watch a video or listen to music with audio coming from the speaker and then make a phone call and have the audio automatically routed to the earpiece. This has now been implemented in most OSes. As for phone call capability itself, from the OSes that I’ve seen and tested in the past 30 days, nearly all systems can receive and make phone calls. I have also noticed a quality improvement in audio quality on the receiving end in KDE Neon (after sudo apt update \u0026amp;\u0026amp; sudo apt upgrade) as well as in the newest Debian+Phosh image. I also know that various developers, from different projects, are currently attempting to enable the notification LED, vibration motor and to make the phone ring when the phone receives a call. These are obviously important features to make you notified of incoming calls as well as received SMSs or other messages. By the time I publish the next community update I expect some OSes will have these features either implemented or in the process of testing. Speaking of sensors, Marius from UBports and Bhushan, who\u0026rsquo;s working on KDE Neon, have demonstrated auto-rotation using PinePhone’s accelerometer on Ubuntu Touch and Plasma mobile respectively. Noteworthily, auto-rotation now also works on LuneOS, which remains a well performing and interesting alternative to more popular OS propositions. I expect to see the auto-rotate feature to also find its way into the next releases of the aforementioned OS images in the coming weeks.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Auto-rotate on Ubuntu Touch, originally posted by Marius\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Auto-rotate on KDE Neon, originally posted by Bhushan\nA major development task currently concerns improving battery life in idle state. This is something which is something I already touched upon in last month’s community update. There are a number of different attempts at making the PinePhone last a day on battery, but perhaps the most impressive to date can be seen in the newest KDE Neon build. Running KDE Neon, with WiFi and the LTE modem turned on, the PinePhone can now last approx 10 hours on the battery alone. Now, I recognize that this may seem underwhelming compared to our Android or iPhone smartphones, but keep in mind that this device is nothing like your ordinary phone. Moreover, there are also many known areas that can be improved upon in this regard. I think that it\u0026rsquo;s fair to say that, given the length of time in development, a 10 hour stand-by time with connectivity enabled is very good improvement over the previous 4-6 hours. Another topic I wish to touch upon is growing OS availability. Software options literally exploded in the past 30 days as Braveheart brought many new developers who began porting a variety of OSes, some of which have previously not been seen on a small form-factor device such as a phone. Among others, we’ve now seen an early port of Android 10 - running kernel 5.6 no less - as well as the much anticipated NixOS (much anticipated by me that is - not sure of its overall popularity). I have, sadly, not had any hand-on time with either of these systems, but from what I’ve gathered NixOS already works well, while Android 10 is mostly unusable at present time. As for the Arch Linux OS image, this one is clearly aimed at tinkerers and experienced enthusiasts; it comes with no desktop environment nor UI, and clearly invites you to build your own custom experience atop the bare Arch OS image. Last, but certainly not least, we’ve seen an impressive amount of work done on the PinePhone Fedora port. The port already runs great and has much, if not all, of the functionality that other OSes offer. This includes phone call functionality, SMS, LTE, GPU acceleration, etc., I’d like to give a shoutout to Peter Robinson from Red Hat, who actively helps and mentors the dedicated group of enthusiasts porting Fedora over to the PinePhone. Fedora on PinePhone, picture via Tor.sh\nAndroid 10 on PinePhone by Moe Icenowy\nLastly, across the board we’ve seen improvements in UI performance. For instance, the recently pushed Ubuntu Touch OS image runs much smoother than in the past and features a number of stability improvements. I also subjectively feel that Phosh and KDE front-ends have benefited significantly from recent development. That said, I have also experienced new bugs - such as stuttering in Angelfish on KDE Plasma - previously absent on the same OS images or front-ends. There is no denying that it’s all still very much a work in progress; with so much changing on a bi-weekly basis, testing new builds and providing structured feedback is important. So, if you happen to have a PinePhone Braveheart edition, I strongly suggest you visit the (well maintained) PinePhone software releases page on our Wiki and try out recent OS images.\nPineTime I usually pay the PineTime less attention in my updates than the other devices. This isn’t because I care less for it - quite to the contrary, I was the one who pitched the idea of making it in the first place - but rather because I have little to no knowledge regarding the software it is running. Besides, my posts simply could not measure up the publications by Lup Yuen Lee on the PineTime, which I encourage you all to read. Regardless, I do feel that the project is underexposed by us and that it deserves a bit more love. To give the project and the devs hard work a bit more spotlight we have now placed a large PineTime widget on the main page. I trust this will help in showing off the device and the work that has gone into it to prospectus users browsing our website. And there truly is plenty to marvel at and appreciate. This month I want to take a look at the first piece of software that resembles a full FOSS OS for the PineTime created by JF, whose work I previously featured in community updates. Until recently all PineTime software developed by the community, while highly impressive, amounted to the functionality of a “dumb” watch capable of syncing with a smartphone. JF’s current work offers a first glimpse at what may become the first full OS for the device built by the community. In the video posted earlier this month, we see JF flip though (smoothly I may add) the various functional demonstration elements of his PineTime front-end. Among the demonstration applications shown are an information widget, a timer of sorts and an analogue watch counting down seconds. There are also other demo applications registering user input - finger taps specifically - and other such functions. All this functionality is accessible via a pull down drawer which appears over the watchface. JF\u0026rsquo;s OS on the PineTime - different demo apps shown\nThe hardware limitations of the PineTime also invite some interesting work-arounds and implementations. For instance, due to the slow refresh rate, JF implemented a scrolling transition when the screen needs to be fully refreshed. It provides a perfect illusion of a fast and smooth transition when the app drawer is pulled down by the user. The experience is very reminiscent of what you may see on much more complex smartwatches from big brands. The OS itself is written in C++ and uses FreeRTOS as well as LittleVGL - a free and open-source graphics library - to provide the UI graphical elements. If you are interested in the project then please check out JF’s github and, if you’re able, contribute to his work - I’m sure he’d appreciate input. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Demo apps in action, originally posted by JF\nI’d also like to mention that this is only one out of many ongoing efforts to build a fully functional OS for the PineTime. Many other developers are actively working on their own front-ends and/or applications. If you are interested in the PineTime, and wish to learn more about it from someone more competent than me, then I suggest you take the plunge and join the PineTime chat available via Discord, IRC, Telegram and Matrix (all bridged together), accessible from Forums And Chats tab on this website. The community there is very welcoming and will gladly help you with getting started. In the spirit of community development, the PineTime dev kits have now been available to all those who are interested in it for some time, so anyone can have a go at testing and contributing to the project.\nThat will be all for this month. We have a lot more news coming in the next few weeks, so subscribe to the blog and stay tuned!\n","permalink":"/2020/03/15/march-update-manjaro-on-pinebook-pro-pinephone-software/","tags":["manjaro","pinebook-pro","pinephone","pinetime"],"title":"March Update: Manjaro on Pinebook Pro \u0026 PinePhone Software"},{"categories":["community","hardrock64","news","pinebook-pro","pinephone","pinetab"],"contents":"\nNemo Mobile and Ubuntu Touch on the PinePhone at FOSDEM 2020\nA lot has happened in the past month. PinePhones have finally begun arriving in the hands of their owners, we had a great showing at FOSDEM, and new hardware was announced. If you haven’t yet read my post about our trip to FOSDEM and the new devices, then I encourage you to do so. Behind the scenes, much work is currently being poured into consolidating and evolving current projects as well as exploring new ones. There are some really exciting months ahead of us! In the meantime, we have plenty to discuss. Here is this month’s TL:DR\nWant to write something for the blog? - contact me Production is at a standstill; hard to estimate how things unfold CNY shipping backlog of SBCs \u0026amp; PineTime; HardROCK64 \u0026amp; SOEdge release dates Expect production / order delay for Pinebook Pro, PinePhone and PineTab Pinebook Pro NVMe adapter fix; new adapter manufactured Pinebook Pro OS choice is growing rapidly; custom keyboard firmware Pinebook-to-pro upgrade kit delayed (again) PinePhone software status - 4 key areas discussed PinePhone FCC/CE certification \u0026amp; hardware changes for production units PineTab is coming; factory under lockdown, no insight how far along production is Write something for the blog I’d like to quickly remind everyone that this blog is open to everyone to publish on. If you are working on something exciting and wish to share it with the community then get in touch with me - I’ll set up an account for you. As an enticement I’ll add that this blog gets a lot of traffic, so it is a great way for get exposure for whatever you’re working on. It also provides you with an opportunity to receive detailed feedback on your work or even get people to join your efforts.\nHousekeeping Part 1: 2019-nCov Pandemic There were a couple of things I initially wanted to discuss in this section, but the situation warrants me to focus on the most important topic. And so the main topic on the housekeeping agenda relates to the outbreak of the 2019-nCov Coronavirus and the impact it has on the Guangdong province as well as Hong Kong. For those who do not know, PINE64 devices are produced in the city of Shenzhen located in the Guangdong province, and all equipment with batteries - such as the Pinebook Pro or PinePhone - ships out from Hong Kong. As some of you may already know from my post on the forums, earlier this month Guangdong issued a restrictive order prohibiting work from resuming until February 10th. While, in theory, companies are now allowed to resume business, in practice everything remains at a complete standstill. In other words, our operations and those of our partners as well as factories have not resumed as of today. For a variety of reasons, there is also a limit to how much work our staff can do at the moment. Factories producing the PinePhone, PineTab and Pinebook Pro remain closed because they need to undergo a long and complicated procedure that will allow them to resume operation. However, due to the huge volume of such government sanctioned procedures required province-wide, it may yet some time before people can even enter the factory. It\u0026rsquo;s worth pointing out that this issue can also be felt up the entire supply chain - manufacturers of components are also affected by this, and shortages are expected.\nSadly, this isn’t the entire extent of the problem; as I’ve already mentioned, all devices which contain batteries ship from Hong Kong. Earlier this month Hong Kong closed many key crossings to the region from mainland China, including the one which we rely on, and now there is a 2-week long quarantine for anyone arriving from mainland China to Hong Kong. This means that our shipping staff can’t reach the Hong Kong warehouse. So, then, what does all this mean in practice? It means that we cannot produce anything this month and, even if we could, there is no way for us to ship any devices with batteries. I will refrain from speculating as to when things will return to normal. Expect shipping dates to slip considerably. I have a suspicion that the extent of this disturbance will be felt across the entire electronics industry for the rest of the year. I will keep you updated the best I can in the previously linked thread; the moment I know something I’ll make sure to create a new post and update the original entry.\nHousekeeping Part 2: Chinese New Year Shipping Backlog We’re currently catching up on the Chinese New Year shipping backlog. While we’re unable to produce more devices at this time, we can ship existing single board computers as well as the PineTime dev kit from mainland China. Despite the shipping team being severely crippled by current circumstances and the resulting lack of available staff, I expect parcels to keep on steadily going out throughout next week. As I understand it, the process of clearing out the backlog has already begun a few days ago and should be completed shortly. If you’ve ordered a PINE64 single board computer or PineTime dev kit after January 20th then your order should be en route shortly. As for the production and availability of the HardROCK64 and SOEdge AI module announced at this year’s FOSDEM - we already accounted for the disruption caused by the pandemic. We also purposefully provided approximate availability dates as it is literally impossible to predict how the situation will unfold. Regardless, the tentative availability dates of April/May 2020 are unaltered at this time. Pinebook Pro There is plenty of good news, but let us start with the bad. The bad news is that we need to postpone the production of the RK3399 upgrade kit for the original Pinebook once again. Don’t worry, we’re not shelving it, we’re just prioritizing other things - such as the newly announced HardROCK64 and SOEdge - due to the limited manufacturing capacity (caused by the aforementioned pandemic in China). Having already postponed the release of the upgrade kit thrice now, I rather not promise something for a fourth time. Instead I’ll say: it\u0026rsquo;s in the works, and as soon as I know something with a high degree of certainty I’ll make sure to let you all know. On to better news. We now have a solution to the original NVMe adapter problems, where the adapter with an NVMe SSD would not fit properly in the laptop chassis. The solution was surprisingly simple, but required us to manufacture a custom holder for the SSD. I apologize for not keeping you up-to-date on the status of this solution; I didn’t post anything on the subject because I had no insight into the process. If you have the original NVMe adapter for the Pinebook Pro, please send an email to info@pine64.org with the following in the subject field: Subject: New PBP NVMe adapter holder [original order number]\nWe have now also created a new optional NVMe adapter that will ship with all future Pinebook Pro orders. The new adapter is a little longer, but has a lower profile, and is perfectly aligned with the mounting holes inside the Pinebook Pro chassis. I am told that it has been fitted with a variety of popular NVMe SSDs and no issues were encountered. New NVMe PCIe adapter top / old NVMe PCIe adapter bottom\nThe other piece of good news is that the past 30 days have seen many OS releases. We now also have a choice to run Kali Linux, Gentoo, OpenSUSE, Fedora, NetBSD and postmarketOS (Alpine Linux) on the Pinebook Pro. Most of these OSes have been added to the Pinebook Pro Software Releases subsection on our Wiki. I highly suspect that the coming days will see yet more software releases for the Pinebook Pro, including other *BSD systems. This is obviously good and welcome news, since broad support for the Pinebook Pro means more people interested in the project. Personally, I have been running Manjaro with KDE desktop in the recent weeks and the experience has been nothing short of great. If you’re considering running Manjaro KDE edition, I suggest you enable OpenGL desktop acceleration via the Panfrost FOSS GPU driver, it makes the installation fly. This can be achieved using this script. Growing Pinebook Pro OS List\nLastly, I’d like to give a huge shoutout to Jack Humbert for his work on the Pinebook Pro’s keyboard firmware. Jack made it possible to create your own custom keymaps for the keyboard, significantly enhancing the potential functionality of the laptop. Just as an example, one user has created and shared theirs ANSI Dvorak layout that supposedly can be used without any problems. It is always exciting to see community members embrace and improve upon implementations which we have given considerable thought to. If you have any questions regarding the process of creating your own custom keymap then I redirect you to the dedicated forum thread discussing the custom firmware implementation. Before I move onto the next section let me quickly address the elephant in the room; many of you are asking when the next production-run of the Pinebook Pro will commence. We initially intended for new Pinebook Pros to be produced this month, with pre-orders opening now(ish). As I already explained in the housekeeping section, this will not happen. I can only offer you my guess at this point - and that is that the next pre-order window will open mid-March.\nPinePhone Many Brave Heart edition PinePhones, with the exception of those slated for Germany, have already reached their destination. So far the reception from end-users has been very positive, which admittedly makes me rather thrilled. I’d also like to thank those of you who post previews, reviews, quick-looks, etc. online; every single written or recorded piece of content that I’ve seen insofar has rightfully included a mention that the PinePhone is a work-in-progress. This is important since, as I see it, the most important aspect of the project currently is showcasing progress while accurately depicting the current state of the software options. Speaking of PinePhone software options and development status, there is so much information to cover that it would require an entire separate post. Not to mention that I am not the most competent person to cover the subject of software development in the first place. So, instead, what I will do in this section is highlight some of the vital developments of the past couple of weeks. I want to address 4 main topics: 1) battery life; 2) voice calls; 3) camera implementation; 4) performance. Let’s go down the list one-by-one. There are many things pertaining to battery life that are currently being ironed out. On the one hand, a fair bit of work on the AXP803 power management controller and kernel behaviour. I only understand the latter, so I’ll comment on that. Marius from UBports has started experimenting with having the kernel downclock the core frequency, drop the CPU voltage and turn off 3 cores when the phone’s display is off (in its idle state). This early experimentation has resulted in a stand-by time of approximately 12hrs, which is rather impressive for a first battery-preserving attempt. This will only get better with time, as it becomes paired with more advanced power management. Another developer, Megi, has also managed to dramatically lower the WiFi module’s power consumption, which can buy users as much as another hour of runtime during active use.\nPicture showing battery drain over ~11 hrs on the PinePhone running Ubuntu Touch\nMegi has also demoed voice calls and camera implementation in the past few weeks. While voice calls already work, they also require manual audio routing (for those interested, here are the details). Getting voice calls functional with the individual OSes is being worked on, of course, but there is no telling when the functionality will be available. It could be soon or in a few weeks or months. The story is very similar for both the front and back camera. We have seen a successful demo of the cameras being used from the userspace, but this functionality remains to be implemented into the existing OSes. Out of the two highly desirable features, it is my understanding that voice calls will be easier to implement within a short-to-medium amount of time. https://www.youtube.com/watch?v=12bsEtUEWbg\u0026t=1s\nPhone call from Arch Linux on PinePhone ~ Megi\nhttps://www.youtube.com/watch?v=l-Vt8-npTjc\nCamera Test application on the PinePhone ~ Megi\nLast on the PinePhone software agenda is the subject of performance. To be precise, the end-user experience of using the phone - the responsiveness of the UI. This is one area where you can expect a lot of changes from one week to another. As an example, KDE Neon from early February suffered from poor performance, making it borderline unusable. Less than two weeks later, the newest KDE Neon OS image is one of the fastest out there (despite it being highly unstable). Similarly, Ubuntu Touch suffers from a significant amount of slow-down in the main UI. This is caused, funny enough, by the wallpaper; replace the wallpaper (for the one with puppies as an example) and watch the performance significantly improve. Such performance issues are very much expected at this point in time, but I expect that their root causes will be found and ironed out relatively soon.\nMany users have asked why there is little to no dev dialogue in the #PinePhone chat. For those who don’t know, the #PinePhone channel is very active. There are ~2400 users in Discord, ~100 (concurrent) users in IRC, ~800 users in Telegram and ~500 users in Matrix. This makes for an environment where it’s very difficult to hold a frequently complex and technical conversation. Development-related chat is very much ongoing, but it’s mostly taking place elsewhere. This does not mean, however, that you can’t ask devs questions or engage with them - they are still in the main channel if you need them. https://www.youtube.com/watch?v=xI6AUFkQJU0\npostmarketOS with Phosh performing rather well in newest OS image ~ Alexmitter\nThe last bit of information related to the PinePhone I wish to discuss before proceeding to the next section concerns consumer-grade PinePhone changes and CE/ FCC certification. We expect to have the certifications in place later this month, which means that all future PinePhones will ship as certified devices. This is good news, since some places such as Germany require this type of certification on consumer products. As for changes to the hardware, there is a list of errata on the Wiki. To be clear, most of these issues are imperfect hardware implementations rather than major problems. We’ll work though as many of these errata for the final phone as possible while striving to maintain complete software compatibility with Braveheart phones. Similarly to the Pinebook Pro, we initially intended to start the production of the phones this month. As I’ve already explained in previous sections, it is much more likely that production will first begin in March. On the positive side, we have some super exciting things in stock for the PinePhone which we will be sharing with you shortly; we trust that this will more than make up for the pandemic-related manufacturing delays. PineTab This section of the update will be rather short since not much has changed since last month. Production of the PineTab early adopter units started prior to Chinese New Year, but due to the factory currently being locked-down and staff unable to access it, we do not know how far along the production process got in January. If we can resume PineTab manufacturing next month alongside the PinePhone and Pinebook Pro, then pre-orders may go live in March. I’ll make sure to amend this post with an edit once we know the state of production. The good news is that we have now internally narrowed down OS choice for this early batch to two OSes. We’re in talks with the projects in question to determine which of the two will be the most viable for the first PineTab batch. I expect that we should be announcing what we agreed on next month, so if you’re interested in the PineTab now is probably the right time to subscribe to this blog. At any rate, there are now two good options for us to choose from with sufficient software maturity that early adopters have something to start with when they receive their unit.\nThis wraps it up for this month’s community update. I hope to be back with better news next month. In the meantime, we have some important and exciting things coming in the next couple of weeks, so make sure to subscribe to the blog and stay tuned for the upcoming announcements!\n","permalink":"/2020/02/15/february-update-post-cny-and-fosdem-status-report/","tags":["community","pinebook-pro","pinephone","pinetab"],"title":"February Update: Post CNY and FOSDEM Status Report"},{"categories":["community","cube","hardrock64","soedge"],"contents":"\nPINE64 get-together with community devs and partner-projects at FOSDEM 2020\nSorry for the delay in delivering FOSDEM news and announcements to you - I was too occupied with great company, splendid beer and shouting at hundreds of people across our stall table. It was awesome to see so many familiar faces, meet new ones and socialise with projects we usually don’t get an opportunity to talk with. Some of you may have already seen pictures or videos of our stall at FOSDEM overflowing with people; I am happy to say that we were one of the most - if not the most - besieged stall at FOSDEM this year. There literally was a wall of people at the stall at all times, and if not for our community members and partner-project devs we’d probably not cope. This also had the effect of being as much our booth as that of Manjaro, UBports, Nemo mobile, KDE, postmarketOS, Aurora, Meamo Leste and others :)\nCrowd at the PINE64 stall FOSDEM 2020\nIn the January community update we announced that if you are attending FOSDEM, and already had a PinePhone on order or with you, then we’d have a surprise piece of swag for you. As some of you already know, the swag in question was a choice of a hard or soft PinePhone case. Over the course of ~8 hours that we were at the stall we gave well over 100 cases. It was really exciting to see so many PinePhone early adopters at FOSDEM.\nSoft (silicone) case left, hard case right\nApart from our cramp little corner of FOSDEM, you could also check out PINE64 devices at the KDE and OpenHAB stalls. There was also a talk by Merlijn Wajer and Bart Ribbers (youtube video linked) concerning Linux phones as well as a joint BOF with Purism (my thanks go out to Dalton and Bhushan for taking the lead on this), where a significant portion of the time was dedicated to the PinePhone in particular. In other words, there were many PINE64 accents all over FOSDEM, which made me realise how much we’ve grown in the past two years. KDE stall FOSDEM 2020\nHowever, to us, FOSDEM means getting together, talking about how our current projects are coming along, nagging Bhushan about the KDE Neon image, and meeting with all the amazing developers making all this happen. But it is also the time of the year when we announce new devices. This year we’ve decided to tackle announcements slightly differently. What we’re announcing now relates only to our plans for Q1 and Q2 of 2020 and not the entirety of this year. That is to say, we have more exciting things coming in the second half this year, but we’re holding off from announcing these things at this time. Let me explain. We’ve learned a lot from last year’s experience with Pinebook Pro and PinePhone production delays, which effectively means we understood that it is better to tackle fewer things at a time. In Q1 and Q2 we are yet to review PinePhone and PineTime status, release the PineTab early adopter edition and make good on our promises to deliver the upgrade-kit for the original Pinebook. That is a lot of work left over from last year. So at this point we’re only announcing things we’re confident we can deliver by early May. Once we clear everything we currently have on our table, we’ll be announcing plans we’ve got for Q3 and Q4. This is the pace of announcements will likely follow in the future too.\nWith that out of the way, let us talk about what we’ve got coming soon.\nThe HardROCK64 HardROCK64 (top)\nIt has been a little while since we did a single board computer (SBC). For the past year I kept on telling people that whilst we have now a wide range of devices (that you guys are clearly both excited and happy about) we’re still going to make SBCs, since that is our bread and butter. Therefore I am super happy to announce the HardROCK64 - a small form-factor SBC with a lot of umph. The board features:\nThe RK3399 hexa-core SOC found in the Pinebook Pro and on the ROCKPro64\n2xUSB 3.0\n2xUSB 2.0 WiFi AC and BT 5.0\nGigabit Ethernet\nFull GPIO pins SPI flash\neMMC socket mSD card slot\nFan \u0026amp; RTC headers\nHeatsink mount\nCSI connector\nDSI connector\nIR receiver 5V barrel jack for power\nDigital video out The board will ship in 3 LPDDR4 RAM configurations (tentative $ pricing): 1GB ~ $35 2GB ~ $45 4GB ~ $55 Tentative release date: April 2020\nHardROCK64 (bottom)\nThe board will run all ROCKPro64 OS images with little or no tweaks (we checked) and probably most Pinebook Pro OS with a ‘simple’ device tree tweak. In other words, if you don’t need all of the ROCKPro64’s functionality - e.g. PCIe or USB-C - then this may just be the board for you.\nThe board does run hot so a heatsink is pretty much mandatory. A couple different options will be sold by us to match your needs and expected the SOC load. SOEdge AI Module SOEdge in USB 3.0 Adapter\nThe other thing we’ve been known for in enthusiast, industry and custom embedded device circles are our SOPine compute modules. The SOEdge is a 3TOPS compute module that can be paired with the SOPine base board or USB 3.0 and PCIe adapters for development. It can connect to a SBC, such as the ROCKPro64 or a regular PC. We initially planned the release of the SOEdge module last year, but Pinebook Pro and PinePhone delays pushed it back to this year. Features:\nRockchip RK1808 dual-core Cortex-A35 processor with a 3.0 TOPS Neural Processing Unit 2GB DDR4 PC-2133 RAM 16GB eMMC flash PMIC – Rockchip RK809-2 204-pin SO-DIMM connector (same as the SOPine modules) Tentative price: ~ $30\nTentative release date: ~ April/May 2020\nSOEdge in PCIe Adapter\nClusterboard with 4 SOEdge and 3 SOPine modules\nThe SOEdge can be used in a variety of scenarios and is compatible with current and future SOPine boards, including the clusterboard which can host up-to 7 modules clustered via Gigabit Ethernet. I can imagine that mixing SOPine and SOEdge modules in the Clusterboard can yield results in various applications. I’ll leave it up to your imagination :)\nCUBE IP Camera It was a year ago, pretty much to the day (except then I was more diligent and released information on time), that we announced that we’re working on the CUBE FOSS IP camera. We then encountered issues with the SONY camera implementation, and with the big devices such as the Pinebook Pro and PinePhone in the works, the project got shelved until further notice. So, here is the notice, we’re working on the CUBE again. I’ll have more news regarding the CUBE, including what necessary changes were made to the camera, in the February community update on February 15. That\u0026rsquo;s it … for now. As I’ve already stated, these are the new devices that we will strive to get in the PINE Store by May. But there many other product ideas that we have in the pipeline, and you’ll be hearing about them once all the PinePhones, early adopter PineTabs, HardROCK64s and SOEdges start shipping. Hope you’ll agree this is a better approach for this year. Thanks once again to everyone who made it out to see us at FOSDEM and, of course, FOSDEM organisers and volunteers. Original CUBE IP camera prototype (image from 2019)\nN.B. All pictures of devices depict product prototypes; final version of device may, and likely will, differ in appearance or / and functionality.\n","permalink":"/2020/02/03/fosdem-2020-and-hardware-announcements/","tags":["cube","hardrock64","soedge"],"title":"FOSDEM 2020 and Hardware Announcements"},{"categories":["pinephone"],"contents":"\nI take no pleasure in writing this blog post. In fact, even as I am writing these words I am internally torn on whether this is the right approach to addressing the problem on hand. Whether I’ve chosen the right approach remains to be seen, but regardless, I now feel it’s time to confront misconceptions about the PinePhone. What’s the misconception? The misconception concerns the openness of the PinePhone. On numerous occasions I\u0026rsquo;ve seen the PinePhone being refereed to as closed-source on one level or another. I don’t know the origin of this misconception nor do I understand the reason why it has become propagated throughout the internet. What I do know, however, is that it has been repeatedly quoted in online articles covering the PinePhone or other Linux devices for over a year now.\nSo let\u0026rsquo;s set the record straight: the PinePhone is not ‘full of closed-source firmware’ and, moreover, is one of the most open devices out there. Here’s what’s open Let\u0026rsquo;s start with the Allwinner A64 SoC, which is the brains of the PinePhone; it runs mainline Linux, uses mainline ATF and u-boot and there are open source drivers for all main SoC components. This openness extends to the Lima GPU driver introduced in kernel 5.2.\nLinux 5.6 will contain drivers for all major components of the SoC. The parts which still need to be upstreamed to mainline are HDMI audio and msgbox - both drivers are in the works. For more information on mainlining efforts, please refer to the A64 column at https://linux-sunxi.org/Linux_mainlining_effort#Status_Matrix\nIt’s worth mentioning that LPDDR3 initialization is done by u-boot SPL, which is also open source. There are no blobs in there either.\nNeedless to say, the PinePhone itself is an open platform for any OS to run on. The grand majority of the OSes developed for the PinePhone are, in and of themselves, completely open too.\nSo, where are the blobs? The non-FOSS parts of the phone are as follows: WiFi and Bluetooth firmware must be uploaded to the Realtek RTL8723cs on initialization, an optional auto-focus firmware (currently not used in any PinePhone OSes) can be uploaded to the rear OmniVision OV5640 camera, and the Quectel EG25-G LTE modem runs its own closed-source OS.\nThe WiFi module communicates with the CPU over SDIO and BT is over UART - neither of these connections provide direct access to CPU memory.\nThe LTE modem on the PinePhone is a ‘black box’, and runs its own Linux system internally. This includes all the proprietary modules (blobs) needed to run the actual cellular radios. However, this system is almost entirely isolated from the main system running on the A64 SoC. The only data contacts between A64 and modem are USB connection for data and I2S connection for audio. All data going in or out of the modem must go over these connections. There is no RAM or flash storage shared between the systems. In short, unless you explicitly send data to the modem, it is never in contact with the blobs running inside it. The modem cannot send any data to the phone unless phone is willing to receive it (that’s the basics of USB).\nClosing statement I do not think that this misconception arose online as a result of someone\u0026rsquo;s ill intention or a conspiracy. I really don’t. I do, however, feel that if I were to leave this unanswered for much longer then this misconception would be further propagated.\n","permalink":"/2020/01/24/setting-the-record-straight-pinephone-misconceptions/","tags":["pinephone"],"title":"Setting the Record Straight:  PinePhone Misconceptions"},{"categories":["pinebook-pro","pinephone","pinetab","pinetime"],"contents":"\nWelcome to 2020. I expect this will be a productive year and one of exponential growth for our community. It was a busy beginning to the year and I expect that the pace will remain high with shipments of the Pinebook Pro and PinePhone Braveheart edition as well as FOSDEM announcements. Following this period there will be downtime due to the Chinese New Year. The past 12 months have been so intense that I am genuinely looking forward to this period of relative calm, which will allow everyone to catch their breath and review how things are going. I find that at times a forced downtime is one of the most productive things there can be.\nSince I last wrote a lot of developments have taken place, so let\u0026rsquo;s get to it. TL;DR for this month:\nCommunity Updates released on the 15th this year We’re at FOSDEM - come chat with us; something special for PinePhone BH owners FOSDEM talk on Linux phones by Merlijn Wajer (Maemo Leste) and Bart Ribbers (pmOS) New HW announcements at FOSDEM; watch out for blog post on Jan 31st Pinebook Pro (ISO/ANSI) shipping; patience please - units still going out Pinebook Pro OS variety grows; *BSD options incoming OG Pinebook RK3399 upgrade kit coming after Chinese New Year Pinebook Pro fun and games! PinePhone Braveheart edition start shipping January 17th Details on what you’ll find in the box; details on what software comes preloaded A lengthy list of improvements \u0026amp; changes from dev phones to Braveheart Important info regarding PinePhone shipping \u0026amp; tracking Little or no staff over CNY; use the community for help and support The PineTab early adopters edition production started ; where do we go from here? PineTime development update; actual timepiece OSs /UIs emerge Housekeeping I have made the decision to post community updates mid-month from now on - on the 15th of each month to be precise. If you think this is a bad idea or have some other objections please let me know in the comments. Personally, to me it just seems like a more natural period to post an update than at the beginning of each month. As usual, I’ll also post shorter and more casual community updates when need be (especially when shipments go out) in the news section on the forums too. Onto the core topic of this month’s housekeeping; we’re at FOSDEM 2020 and we’ll have a stall on Sunday. We’ll also have all sorts of swag for you to grab at our stall - including stickers of course - but if you happen to be rocking a Braveheart PinePhone at FOSDEM, then we’ll have something special for you. All you have to do to get the ‘special’ PinePhone accessory is show us your phone or the order confirmation (in the event yours arrives after the conference). We\u0026rsquo;ll be showing off our not-yet-announced gear and the devices you already know about: the PineBook Pro, PinePhone, PineTime, and PineTab. If you’re on the fence about any of these devices, this will be your chance to get hands-on with them. I hope many of you will manage to make the trip and that I will get a chance to talk to you in person. Manjaro and UBports guys, along with many other developers from partner-projects, will be hanging out at our stall so make sure to talk to them too. Speaking of our friends from various projects, Merlijn B. W. Wajer from Maemo Leste and Bart Ribbers from postmarketOS will be giving a talk about Linux phones, which I highly recommend you go and see. If you won’t be attending then a video from the talk will eventually be available on FOSDEM’s website. FOSDEM 2019: PINE64, Manjaro and UBports\nIn the past 2 years I only had time to take a quick walk around the event, so on Saturday I intend to just walk around and, for once, actually see something at FOSDEM. You’re more than welcome to say hi when you see me and I am always keen on company. Last year I also found a great food place nearby if you’re interested to join me for lunch. Later that evening we’ll be heading out to Tavernier with the rest of PINE64 folks, and we’d be happy to have you join us for beer (or soft-drinks if that\u0026rsquo;s your thing). As we do each year, we’ll be making announcements regarding upcoming hardware at FOSDEM. We’ve got some really cool and exciting gear in the pipeline and I cannot wait to share it with you. You can expect a post regarding the announcements on January 31st. You can scroll down to the bottom of this page and sign up to this blog to get a notification once the announcement goes live. Last on the housekeeping list is the PINE64 cluster, which will host all our community services. The cluster has arrived at BBXNET’s datacenter and is now undergoing assembly. We’ll gradually be migrating all services to the cluster; I’ll make sure to keep you up-to-date on how things are coming along with it. I expect that the first things to be moved are the chats - I must admit that I am looking forward to a self-hosted Matrix instance. Some assembly required ;)\nPinebook Pro The majority of ISO and ANSI Pinebook Pros pre-ordered in the past months have either been delivered or are en route to their new owners. Many more are to be shipped, so if you haven’t gotten your tracking number yet please do not worry. Pinebook Pros that will not make this shipping window - mostly units ordered in December - will be shipped out in February, after PinePhones go out to end-users. Shipping at this time of the year is difficult due to the upcoming Chinese New Year. There are various abnormal logistics issues that need to be overcome, including a shortage of staff. We’re doing our best to ship everything in a timely manner and hope for your understanding. You’ll have your Pinebook Pro soon one way or another. With that out of the way - we’re blown away by the sheer amount of positive feedback we’re getting regarding the ISO and ANSI versions. Thank you - it\u0026rsquo;s equally important to hear words of encouragement as it is to get constructive criticism. I too have recently received an ANSI Pinebook Pro for testing from the last production run and I admit that the keyboard (despite ANSI not being my thing) turned out rather nicely. I also find that the fit-and-finish has been perfected at this point, and the unit feels very polished. The one thing that end-users will need to do however, is update their keyboard and trackpad firmware - the factory failed to apply the necessary fixes in this production run. Moreover, ANSI users will have to change the keyboard layout to ANSI in the default OS (en_US) as the default OS layout is ISO (en_UK). We’ll see to it that this is the last time end-users need to do the firmware update on their end. As promised, upgrade kits that convert the original Pinebook into a Pro-esque version are in the works, but we won’t be able to have them ready this month. We know that many OG Pinebook owners are waiting for this upgrade to drop and we’ll make sure that it is ready for production when factories resume operation after Chinese New Year. We apologize for the delay in delivering the pro upgrade kit, but there are still some aspects of this that need to be ironed out and we didn’t want to rush it. Onto the subject of upcoming software.\nhttps://www.youtube.com/watch?v=DqmFDCZcxM0\u0026t=1s\nDorianDotSlash takes a look at 3 different OSs on the Pinebook Pro (40min)\nWith so many Pinebook Pros now in the wild and in the hands of developers, software development has really picked up pace and we’ve seen images posted of numerous builds on forums, social media or elsewhere. Here is a list of OSs - that I am aware of - which are either already out or will be available for the Pinebook Pro in the next weeks and months:\nArch Linux\nUbuntu 20.04 w KDE\nUbuntu MATE\nGentoo\nAlpine Linux\nNetBSD\nOpenBSD\nArmbian\nRISC OS\nNixOS\nDebian Mainline\nDebian w MATE Recalbox\nUbuntu 18.04 w MATE\nManjaro XFCE\nManjaro KDE\nQ4OS\nFedora 31\nVoid Linux\nLAKKA\nA kind request to developers - we’d appreciate if you could post your builds on the PINE64 forum in the form of an announcements as well as add your builds to our wiki so it’s easy for end-users to find them. You can alternatively ping me or one of the moderators and we’ll do the above on your behalf. Thanks!\nNetBSD via Jared McNeil @jmcwhatever Twitter\nNix OS via @fadenb (Twitter)\nGentoo via Jannik2099 (Chats)\nRISC OS via @RISCOSbits (Twitter)\nPrevious Next\nI don’t have the time to cover every and each upcoming OS in detail, nor do I find it necessary—a simple internet search will tell you all you need to know about most of the Linux distributions—so instead I’ll focus on BSD. From the very start we said that the Pinebook Pro a Linux and BSD laptop, but until now I haven’t had much of a chance to talk about the latter. In the July 2019 update I acknowledged that a segment of our community is made up of dedicated *BSD users and I’ll let you all know when I hear of *BSD developments; so I expect that this will come as a welcome surprise that development is now coming along. Indeed, this month we’ve had our first glimpse at NetBSD booting and running on the Pinebook Pro. It is my understanding that NetBSD is coming along nicely, and while it’s early days for the OS on the Pinebook Pro, this platform is known to the developers; the ROCKPro64 is already well supported by NetBSD. I’ve even seen screenshots of 1080p youtube content being watched in NetBSD on the Pinebook Pro and the WiFi adapter working (the latter being something *BSD lacks drivers for).\nNetBSD Youtube playback on the Pinebook Pro via Matthew Green (@mrgtwentythree)\nYet another popular *BSD is OpenBSD. Whilst I have not yet seen the OS running on the laptop, I am happy to report that development has already started on an OpenBSD port. I have written to the developers, asking for a progress-report and an ETA, and hope to get a response shortly. When I do, I’ll surely edit it into this post or include it in the next community update. I too would really like to see OpenBSD on the Pinebook Pro this year as it\u0026rsquo;s certainly one of the more recognizable (due to its long-running heritage) *BSDs out there. As you can surely tell, we’ll soon have quite a selection of FOSS OSs to choose from: multiple Linux distros, *BSDs as well as Chromium OS and Android. The current growth of the PINE64 community, combined with a very positive reception of the Pinebook Pro, is also an assurance that solid and prolonged support of the device is inbound. I suspect that partner-project developers feel the same way - for instance, the number of Manjaro ARM 19.12 Pinebook Pro download link clicks is twice that of the next popular device. The download rates for all community builds for the Pinebook Pro are through the roof. Lastly, I am genuinely happy to see that people are having fun with their Pinebook Pro - and by fun, I specifically mean playing FOSS and retro games. Being an old school gamer myself, I am particularly excited to see Recalbox on the Pinebook Pro; I have tested the alpha build together with a handful of community members and it’s coming together really well. Just as any other OS for the Pinebook Pro, Recalbox can be easily booted from an SD card, so that it can be easily dual-booted with your full-desktop OS on the eMMC. A release is currently scheduled for mid-February, so be on the lookout for that if you enjoy retrogames. If a dedicated gaming distro isn’t your thing, then Astr0baby is putting together a detailed list of games that you can run on your Pinebook Pro complete with build instructions. As a side-note, and related to games, he also has an awesome guide on virtualisation on the Pinebook Pro, which I suggest you read if you’re interested in this subject matter. Getting back to the topic of games, we have set up our own Open Arena server, you’re welcome to follow instructions I posted to join for some casual fragging this weekend :)\nPinePhone As I’ve mentioned in my Casual late December community update, Braveheart shipments have been pushed back a couple of days so that Pinebook Pro ANSI units could clear from the Hong Kong warehouse. Not that it matters, but in the name of transparency, I believe that the shipping team decided to dispatch Pinebook Pros first simply because they take up more space in the warehouse than the phone pallets. The reason I am including this information in the first place is to put at rest question regarding production status (more on this later). As things stand, we’re now ready and I am happy to confirm that PinePhones will begin shipping in two days time - on January 17th 2020. The dispatch process will take a couple of days, however, so your unit may ship anytime between the 17th and 25th. At any rate, you’ll have your PinePhone soon.\nSo many PinePhones!\nLet’s talk shipping. As I already mentioned in the past, the PinePhone will ship using Asendia. They offer a balance of solid shipping times (approx. 10-14 days to Northern Hemisphere + Australia and New Zealand), security and shipping cost. Unlike other carriers they also do not file import tax on your behalf, so it will be up to your customs to determine whether the PinePhone needs taxed or not. Without dwelling too much on this subject matter, I can confidently write that there are greater chances you won’t be asked to pay anything extra than with other carriers capable of transporting goods with Lithium Ion batteries. One key downside of shipping using Asendia is parcel tracking. Simply put - from my experience and that of developers (sample of ~100) - the tracking isn’t particularly good. Having left Hong Kong, my parcel’s position wasn’t updated until it reached the destination airport and was logged for pickup by the local courier company. From this point, however, I was able to track the parcel in my local delivery service’s system and 17Track. This has, by and large, also been the experience of other people. So what does that mean? It means a few things: for starters, don’t worry if you won’t receive shipping updates for a prolonged period of time - this is to be expected. Therefore it also means that you shouldn’t email support, sales or info - it won’t make the shipping any faster and will just make the response times - to people to people we can actually assist - considerably longer. Speaking of support, PinePhones ship out just days before the Chinese New Year starts. This means that there will be very few, if any, staff to answer your questions during this holiday. Therefore, more than ever, we will rely on our community members and partner project developers for support during this period. So if you experience problems with your Braveheart PinePhone, regardless of if it’s a software or hardware query, then before you decide to email support please make sure to join the chats or post your question on PINE64 forums and see if there is someone who can offer help. Unless your unit is DOA or damaged, you stand a much better chance of getting answers to your questions from community members in the coming weeks. Community forums and chat options available from the drop-down menu on this site\nWith all the formalities out of the way, let me talk a bit about the PinePhone Braveheart itself. Inside the box you’ll find the PinePhone, a high quality USB-C charging cable and an introductory leaflet in letter form (written by yours truly with the help of the community). We assume that most, if not all, of you already have a 5V 15W PD charger, and we have no intention of adding more rubbish to the landfill than necessary. The PinePhone will charge just fine at a lower wattage but the charging process will obviously take much longer. If you don’t have a 15W rated PD charger yet, then use whatever charger you have in the meantime, and I suggest you wait for end-user reports regarding what chargers work best for the PinePhone. Lastly, the packaging which the PinePhone arrives in (as is the case for all our products) is made entirely out of recycled materials. We strongly encourage you to recycle the packaging according to your local standards if you do not intend to keep the box. PinePhone Packaging Box\nThe PinePhone itself arrives with a polymer (a nice way of saying plastic) screen protector applied at the factory. I’d suggest you keep it on your phone, but I understand that there are some who distinctly dislike plastic screen protectors - if you’re one of those people, then you can peel it off without worrying, the PinePhone features hardened glass. In the future we may partner with some company to deliver a glass screen protector for the PinePhone - stay tuned for more information in the coming months. There are a great many aspects of the phone that have been changed, improved upon and polished since the dev phones, which you’ve probably seen have shipped. This includes engineering things, such as tweaks to the antenna layout or PCB improvements and known errata corrections. To most people, however, it\u0026rsquo;s the aesthetical changes that will stand out the most. There are a few things which you may immediately identify as different when compared to a dev phone - especially some of the earlier dev units. The LCD and digitizer are sealed, so there is virtually no gap between the glass and the screen. The LCD used is also pitch black when the device is turned off as opposed to grey-ish or silver. The Lithium battery has now been branded and the back of it facing the PCB contains all necessary warnings and regulatory messages. Braveheart PinePhone with back cover taken off (modem blurred)\nPerhaps most importantly, however, the back of the phone has been significantly improved upon. Both the plastic molding and the applied coating have been considerably refined. I haven’t held a Braveheart phone in hand myself, so I cannot provide a first-hand account of how the coating turned out; that said, those on the team who held one of these PinePhones seem very pleased with the end-result. Lastly, similarly to how we chose to only brand a single key on the Pinebook Pro, we chose to sneak in a small PINE64 logo between the camera and the flash LED. The logo is placed behind glass, so won’t be scratched or eroded from regular wear and tear, and is pretty small in size. This was my idea, and I hope that it is unintrusive enough to satisfy those who hate branding yet prominent enough to make this an unmistakable PINE64 product. It also opens the entire back of the case to partner-project branding; something I expect we\u0026rsquo;ll see in the future as we ship OS-specific PinePhone production-runs ( information on this topic here). Let me know what you think about the little PINE64 logo in the comments.\nPlacement of the PINE64 logo As for software, the phone arrives preloaded with a factory test image rather than an end-user operating system. This preloaded factory test suite is running on Linux - postmarketOS to be precise - which allows you to test various features of the phone and run an automated test. The automated test runs through all key sensors, inputs, outputs and the modem (if you have a SIM card inserted - otherwise it will return a modem failure error). The manual tests include the touch panel, modem, speakers, vibrating motor, LED notification light and more. It also includes an option that allows the factory to write the image to eMMC (which has already been done, since the image is running from eMMC). Factory OS - postmarketOS with custom factory UI\nAt this point I assume that everyone getting a Braveheart PinePhone understand that it\u0026rsquo;s up to them to find the operating system build they are interested in, flash it and take part in the community discussion and ongoing development. Most builds are available on the PinePhone Wiki - which you can and should contribute to (use your PINE64 forum credentials to log in). Some OS builds have to be sought out however; for example, this is the case for Manjaro and Nemo mobile. These builds will, in time, be added to the wiki too, but for the time being the Wiki knowledge base is just getting built up. You will likely want to run the OS you’re interested in from the SD card for now. New builds show up every couple of days - I am currently waiting for Maemo Leste and Nemo mobile for demo purposes - which requires you to reflash the storage medium. It just isn’t very convenient to test new builds from eMMC. Finally I wish to briefly discuss future PinePhone production-runs. We will actively monitor and evaluate software development progress over the Chinese New Year period. This period is quite vital to furthering progress as partner-project developers will shortly have an entire dedicated audience of contributors and testers to work with. Admittedly we expect a lot of progress to be made in the coming two months thanks to community contributions. We have previously stated that larger scale production of PinePhones is scheduled for March 2020, and this is still what we’re aiming for. If production commences in March then I’d expect the next production-run on PinePhones to reach their new owners in late April. But if no Linux phone OS reaches sufficient maturity by that point in time we may decide to hold back a month or two before starting the manufacturing process. After all, we want it to be the best Linux on mobile experience possible, so as not to discourage people from the idea of Linux as a viable alternative to Android and iOS. Production this year may start with entering into a cooperation with a partner-project that will be able to deliver a daily-driver OS. I have previously described the nature of such a relationship in a dedicated blog post, which I encourage you to read. Presently there are a number of candidate OS for this undertaking, and we’ll be talking to them in the coming weeks to determine how much progress can be achieved. I’ll make sure to update you on this topic as development progresses. https://www.youtube.com/watch?v=11eObhH8MKA\u0026t=1s\nA quick look at 4 different PinePhone OS\nPineTab With the Pinebook Pros and PinePhones now manufactured and shipping, our attention has turned to the PineTab. Early adopter PineTabs have entered production earlier this month and will likely be delivered to us prior to the Chinese New Year. This does not, however, mean that we feel ready to open pre-orders just yet. We need to test and review the units before making them available for order and need to determine the right OS to pair it with for shipping. As things stand, there are only two viable OS for the PineTab at this point in time - Arch Linux and postmarketOS (XFCE / Plasma mobile). There are other OSs too, but those are PinePhone ports and more of an afterthought rather than a dedicated build. All OS options have their strengths and drawbacks, but I feel like there isn’t a single one that stands out as particularly complete. PineTab dev unit running Arch Linux via @RealDanct12\nThis may very well be a chicken-and-egg situation. The lack of PineTabs in enthusiasts’ hands, in conjunction with developers’ focus on the PinePhone and shelving the project until phones and laptops ship, may be the root cause for no viable software. I am happy to entertain this possibility and in fact find this quite likely. So then, my question to you is: would you rather have us ship the PineTabs to enthusiasts with a clear notice that basically no usable software exists for the platform or wait and see if we manage to build up some support? There is nothing else I have to to report regarding the PineTab at this point in time which I haven’t reported before in my December community update post, so if you haven’t read it yet, I suggest you do. We really hope to hear from you regarding what route you think we should pursue with the PineTab. At this point your arguments may be the key deciding factor whether we decide to proceed with the PineTab in the next 2 months or if we decide to hold off, explore our software options with developers further, and release it with a more feature-complete OS build later this year. I am looking forward to hearing from you.\nPineTime The PineTime has quickly built up a dedicated development community. from the project’s inception, I’ve expressed how impressed I am by the work done on the device. Each month new FOSS OSs and front-ends become available for the PineTime, and I am now looking forward to showing them off at our FOSDEM stall. Last month I dedicated a portion of the community update to explaining how we interact with the PineTime development community and featured some of the early work. A lot of the software and the development process seen insofar can be vaguely classified as either experimentation and proof-of-theory development (as well as pure fun). It\u0026rsquo;s great to see that developers enjoy working with this device, but at the end of the day the majority of end-users are keen to see UIs that resemble and function as smart timepieces. After all this device is what we all hope to be wearing on our wrists at one point in the future. To this end, this month I want to highlight two front-ends that are really starting to take shape as actual timepieces. From what I’ve gathered, both of the two OSs offer similar functionality, synchronizing and keeping time as well as displaying connectivity status. But presently more advanced smartwatch-type functionality, such as pushing phone notifications, is yet to be implemented. My knowledge about PineTime back-ends is, to say the least, highly limited - so I reached out to the developers of the two OSs directly for details. Below are their explanations of what code their PineTimes run and what the front-end can do in the current state.\nPineTime Running Koen\u0026rsquo;s Front-End (via Koen in chats)\nThe first of the two UIs has been developed by Koen Zandberg: \u0026ldquo;The application as of now can be used to make the PineTime into a simple timepiece. Bluetooth LE with a GATT current time service client is used for time synchronization with a[n Android] Phone companion app. Energy is conserved by only turning the screen on when the button is pressed, it automatically turns off after a few seconds. The display shows the current time and date, the bluetooth connection status and the battery status.\nThe system is based on RIOT as embedded operating system, providing the threading infrastructure, drivers and power management. Nimble is used to provide an open source Bluetooth LE stack. Finally LittlevGL provides the high level graphics on the display supporting partial updates for fast and efficient updates.\u0026rdquo; ~ Koen Zandberg (@bergzand)\nhttps://www.youtube.com/watch?v=_ZrsH783ZLI\u0026amp;feature=youtu.be\nPineTime syncing with Android phone originally posted by JF\nThe second front-end is developed by JF (whose work I already featured in previous updates): \u0026ldquo;The firmware provides drivers for the display, battery measurement and touch panel. It also supports BLE connection and implements a CTS client that retrieves the current date and time from the device it is connected to.\nThe application built on this firmware provides some simple functionalities : it displays the date and time, the battery level and the status of the BLE connection. The display can be switched on and off using the button and the touch screen. As a demo of the touch panel, a colorful square is drawn when it detects a touch event.\nThe project is written in C and C++ and is mostly built around the NRF52 SDK and FreeRTOS.\u0026rdquo; ~ @codingfield / jf002\nMy thanks go out to both JF and Koen for taking the time to answer my questions. I am excited to see the PineTime software progress over the course of this year and beyond. I appreciate that much work still needs to be done to make this a viable smartwatch - especially since at one point it will have to pair to the PinePhone. This means that PineTime developers will eventually have to cooperate with and receive help from mobile OS developers in getting the PineTime syncing with their Linux systems. I hope that once Braveheart PinePhones ship someone from our community, or partner-project communities, will take it upon themselves to start developing a companion app for the PineTime. Regardless of what the future holds, the PineTime is already a success-story in my book. That\u0026rsquo;s all for this month’s update. Remember to sign up for the blog (scroll to the bottom of the page to submit your email address) to receive a notification once we publish our FOSDEM announcements. Many thanks to Dalton (UBports) for proofreading this blog entry.\n","permalink":"/2020/01/15/pinephones-start-shipping-all-you-want-to-know/","tags":["pinebook-pro","pinephone","pinetab","pinetime"],"title":"PinePhones Start Shipping - All You Need To Know"},{"categories":["news","pine64-community","pinebook-pro","pinephone","pinetab","pinetime"],"contents":"\nWelcome to the last community update of the year. I think that 2019 will be remembered as the year PINE64 transitioned from being a relatively niche FOSS hardware project to a mainstream one. This transition is an exciting prospect for all of us involved with PINE64, and we cannot wait to see how the project develops over the next 12 months. Let me take this opportunity to thank those of you whom have been with us thus far: the partner-project developers, community contributors, mods and admins, shipping and assembly teams, and - above all else - the end-users who make this project possible. Thank you for actively shaping PINE64 and making it one of the most vibrant and welcoming communities in the FOSS space. The amount of progress we’ve made in just one year is incredible and the success is truly collectively ours. Thank you! Here’s the TL;DR:\nNext Community Update January 12th ; Give us some feedback The PineTime is now in the PINE Store ; Great development PineTab early adopter pre-orders likely in January ; New keyboard ; LTE/ SSD adapter Brave Heart PinePhones worked on ; shipping early January ; PinePhone cases ; First phone call ; PinePhone keyboard Continual good reception ; Keyboard / TP firmware update available ; A lot of OSs coming ; regional keyboards ; OG Pinebook upgrade kit likely in January 2020. New announcements at FOSDEM 2020 ; teaser of what\u0026rsquo;s to come next year Happy New Year! Housekeeping I’ll try to keep this section short. It’s unlikely that I’ll be able to publish the next Community Update on 05/01/2020 seeing as I’ll be traveling during the Holiday and New Year’s period. In other words, I won’t have an opportunity to sit down and write the blog until I am back home on January 7th. I feel like the earliest date I can commit to for an update blog entry is 12/01/2020. In the meantime, if some noteworthy or urgent information surface then I’ll post ad-hoc updates in the forum news section. Make sure to check it once in a while during the holiday period and in early January. I’d also appreciate if you could fill in this short poll/ questionnaire concerning your satisfaction with various aspects of PINE64 as a project. Please feel free to share any thoughts you may have in this forum thread. It’s important for us to get feedback on which cogs of the project are turning well and which ones are grinding. Over the past year we completely redid key aspects of our community infrastructure - the website, forums, Wiki, the chats, etc., These changes are somewhat obvious, since many of you interact with them daily, but what you may not be aware of is that the ‘back-end’, so to speak, has received a lot of attention; namely, we have taken steps to improve PINE Store support, which includes timely responses to your order queries and up-to-date information on your order status. Lastly, I would also like to mention that it’s now easy to sign up for the blog. If you scroll down to the bottom of the page you’ll find a small widget with an email sign-up field appropriately titled “Subscribe to the PINE64 Blog”. Enter your email address and go through the motions to confirm that you actually wish to follow the blog.\nPineTime I have the distinct pleasure of beginning this section by announcing that a limited production-run of the PineTime development kit is now available in the PINE Store. You can pick up a kit with a (really nice) set of silicone straps and a charging dock for $24.99. You also have a choice of two shipping methods to choose from. If it turns out that the PineTime kit proves to be a popular PINE Store item then we’ll make sure to build more units at the earliest possible date. I don’t want to promise anything at this point, but it is possible that the PineTime development kit will be available permanently available in the store alongside the watch in the future. We just feel like it’s in line with the community spirit of this project. Indeed, the PineTime has insofar proven a fantastic side-project for us. I am literally in awe of the effort, creativity and experimentation in the PineTime development group, which I make sure to check into at least weekly to catch up on progress. I couldn’t write this community update and omit Lup Yuen Lee’s phenomenal article on the PineTime titled “Sneak Peek of PineTime Smart Watch… And why it’s perfect for teaching IoT” which discusses the PineTime, it’s potential real-world applications and strengths as an educational device. I highly recommend you read it even if you’re not interested in the PineTime - its that good. As I’ve mentioned in the past, and on more than one occasion, we consider the PineTime a side-project that is solely dependent on community efforts. What I mean by this is; there are no dates to be met and no ETA to speak of. We literally sit on the sidelines and watch how the project evolve in an organic way. This also means that the development process is much more relaxed and it accommodates experimentation and out-of-the-box thinking. In light of this I feel that everyone should have the opportunity to take a shot at developing for this platform, because only good things can come out of more people having a kit to toy with.\nTinyGo on the PineTime by @_CONEJO\nPicture via @codingfield\nPineTab We’ve heard you, you want an early adopters edition of the PineTab. For those of you who do not follow this blog on a regular basis, let me explain; last month I asked if you want us to gear up for an early production run of the PineTab, and the answer was a resounding ‘yes!’. I’d like to thank all of you for the encouraging responses in the comments section, on the forum and chats, which ultimately convincing me (and more importantly TL) that an early adopters PineTab batch is viable. As things stand, we’re currently planning on making pre-orders for the PineTab available sometime in January of 2020. Mind you, this is a tentative time-frame however, as it is largely dependent on how PinePhone shipping progresses in the coming month. In short, we do not wish to find ourselves in a situation where we have to divide our attention between two important and highly anticipated projects. Tackling one thing at a time is usually the wisest thing to do. Last time I wrote about the PineTab I mentioned that we’re doing research on a new and improved keyboard for it. We realise that whilst some of you will gravitate towards using touch-input based mobile OSs, there are also many users who will prefer to use a more traditional Linux desktop on the PineTab. To this end I am now happy to report that we have settled on the type of keyboard we will be selling for the PineTab. The core mechanics of the keyboard - that is to say the way it attaches magnetically to the PineTab and the way it folds - remains pretty much identical to the original concept, that we have been showcasing for nearly a year. That said, the material of the cover and the keyboard keycap styles have significantly changed for the better. The new cover material is made out of durable synthetic leather and the keyboard has a familiar chiclet layout. I am also happy to announce that the PineTab keyboard is backlit with 3-step brightness control. Another accessory for the PineTab that you’ll also be able to order is a M.2 storage and LTE modem adapter. This adapter makes it possible to install any M.2 SATA SSD or LTE modem into the PineTab, further improving its core functionality. I am including a picture of the adapter below. To learn more about the PineTab please read my Community Update from August this year.\nPineTab M.2 LTE Modem/ SSD SATA adapter\nThe PineTab will use this type of keyboard (not identical)\nPinePhone There is currently a lot happening in the PinePhone development space. Both hardware and software is shaping up well and coming along very fast. Developers have been steadily getting their development units over the past two weeks and I myself got a PinePhone just a couple days ago. While there will be a handful of improvements and minor aesthetic changes made to Brave Heart PinePhones (aesthetically, most notably the texture on the back-cover of the phone) the current dev phones already feel very polished and sturdy. I must admit that every time I pick it up there is also something completely surreal about it and the fact that it’s a device dreamed up by a handful of guys over a beer rather than executives in a boardroom. I made a short video showcasing the PinePhone developer edition the other day - I am linking it below for you to check out. In the video I discuss the phone hardware itself, and I intend to follow it up with a video looking at the software next week. With so much happening with software development I want to give developers a week or two with their phones before making a video on their work.\nhttps://www.youtube.com/watch?v=lwkcr3CvyCM\nA close look at the PinePhone Hardware\nSpeaking of developers, thanks to their dedication we have identified a few minor hardware issues with the current development phones. Most of the issues have already been addressed, but there is one outstanding problem - namely reception of the WiFi antenna. In short, the antenna needs to be retuned and this will take a week or two. As a result, Brave Heart PinePhones will first ship in early January rather than late December as we originally planned. We’re sorry for this delay, but we don’t want to cut corners on the Brave Heart batch and shove it out the door just to make the originally announced 2019 release schedule. After all, Brave Heart backers are some of our most enthusiastic end-users, and we want to deliver the best early adopter phone we possibly can. At the same time we also promise that there will be no further major delays, as all phones need to ship before Chinese New Year, no matter what. About shipping; we’re currently experimenting with new shipping methods. While DHL Express is great, at least for the most part, it is also expensive and in some geographic areas more “problematic” (*wink wink*) than in others. We know that many of you have been asking for us to consider other shipping methods so we figured that now is as good of a time as ever. I can tell you my experience with the shipping method destined for the EU: tracking was poor, but the parcel was delivered relatively fast (14 days) and I was not asked to pay tax. This experience appears to also be the case for most other developers. Regarding the tracking, there were no updates from the moment the parcel left Hong Kong until it reached the destination country, but once it arrived I received up-to-date tracking from the local parcel delivery services. Overall, I feel this is a good compromise and - granted we get positive feedback from you guys and gals - we’re stick to it for mass production phones in 2020. Let’s talk about upcoming accessories for the PinePhone. I can already tell you that there are third parties actively looking into making their own accessories - including some that utilize the I2C pogo pins - for the PinePhone, and we simply cannot wait to see what they come up with. We’re very happy to see people make use of the released case-back panel file to design their own peripherals! For now, however, all I can only write about accessories that we have in the pipeline. The first type of which are cases - this is something I previously mentioned in a post about our commitment to give back to the community and society. PInePhone Soft Case Render\nPInePhone Hard Case Render\nThe see-through case is made of soft silicone and we’ve gone to great lengths to make sure that it is nicely molded. You know that I never try to ‘sell you stuff’ - but it would be nice if you’d pick one of these up cases; all proceeds from the soft cases will be relayed to a fund, independently chaired, and aimed at doing our share to close the digital gap. The hard case is made out of resin and is black in colour. There is potential to have the cases in different colours in the future; leave a comment below telling me what colours you’d like to see. As for the case itself, it is very resilient and really well molded. Both of the cases will be available in March of 2020 for the official PinePhone launch or sooner. We’re well aware that an accessory that many of you want for your PinePhone is a keyboard. We have a good understanding how important a keyboard can be to a Linux phone, effectively turning it from a smartphone into a Linux PDA. We are therefore not cutting any corners and, instead of reinventing the wheel, we’ll be making a keyboard heavily inspired by PSION Series 5 keyboards from the 1990’s. We hope to not only replicated the usability of the PSION Series 5 keyboard but also the tactile feel it is known for. The keyboard will use the I2C connection on the back of the phone, which will allow it to open and close identically to the Series 5 PDAs. Due to the compatibility with the existing original Pinebook and the development for the PineTab, as well as the ability of the PinePhone to dual boot from SD, I expect that you’ll eventually be able to run a fully fledged Linux OS with the keyboard attached. Many probably want to know the availability of the keyboard, which is understandable, but for now we’re talking to companies so we can get the molding process going. So, for now, I can only vaguely say that it will be available sometime in 2020. Original PSION Series 5 keyboard - inspiration for the PinePhone keyboard\nThe last but certainly not the least important subject I wish to discuss is software status. The different OSs are making great progress and I am happy to report that, as of today, all key features of the phone work. That\u0026rsquo;s right, over the past week the two missing pieces - the driver for the front facing camera and much of the modem routing for voice call capability - have been sorted out. Below you can find a video showcasing the front camera FOSS driver in action (same camera on a different device) as well as a recording of a quick voice-call I had with Marius from UBPorts who called me from his PinePhone. On the subject of placing phone calls, work on VoLTE is proceeding well and we’re getting help directly from the modem manufacturer to have the functionality operation as soon a possible. Stay tuned for more information on VoLTE in next month’s update. Lastly, the ANX7688 driver which is responsible for power on the PinePhone is now working correctly and capable of performing a power delivery (PD) handshake with compatible chargers to deliver the optimal wattage (15W). Before I wrap this section up I feel it necessary to underline that despite the truly excellent software progress in recent weeks, the PinePhone is not yet ready to be a daily driver. I am writing this in the hope of preventing people from developing a false impression that the Brave Heart phones can run feature-complete OSs at this point in time. This is still very much a work-in-progress project as of December 2019, and various aspects of the software needs time to be properly implemented into the respective OSs. The fact that all key functionality has been worked out doesn’t automatically mean that each and single OS will be able to implement these features on-the-fly into their systems in a matter of weeks. Such implementations takes time and effort. In other words, if you’re getting a Brave Heart edition phone \u0026ndash; have the mindset of a tester and contributor rather than an end-user. This should already be apparent to you from previous blog-posts, but I just wanted to spell it out. In turn, by March 2020 you will be the first to have a fully functional mainline Linux phone that you’ll be happy to show off to others. Happy family ;)\nPinebook Pro The Pinebook Pro has continually been met with a positive reception from developers, end-users as well as the media. If you haven’t done so yet, I highly encourage you to read Pinebook Pro reviews by LINUX Unplugged and POCKETNOW, which offer fair and balanced overview of the device. Below, I’m also linking two video reviews which I suggest you check out. As things stand, the Pinebook Pro is currently on track to become the most popular PINE64 device of all time (bar the ROCK64 single board computer), and this is very good news for all of us. For end-users this effectively means that the Pinebook Pro is very likely to develop a solid and wide software support-range, whilst for developers it means that there is an eager Linux and *BSD audience to use the OS they work on. We are truly happy that we managed to deliver what people wanted and welcome new and enthusiastic members into our fold. https://www.youtube.com/watch?v=dgNYQsdxlMw\nDASGEEK\u0026rsquo;s Pinebook Pro Video Review\nhttps://www.youtube.com/watch?v=EoIfSnFCs84Roger Clark\u0026rsquo;s Pinebook Pro Video Review\nSpeaking of OSs available for the Pinebook Pro, their number is steadily growing and new options available for download. The recent month saw the release of Q4OS as well as multiple Manjaro Preview images which run on the mainline kernel. There are also builds of Fedora 31, Kali Linux, Arch and many other OS in the works, that we know you’ll be excited to see running on the Pinebook Pro. I will also mention that over the past month the default Debian with MATE build has seen a lot of improvements, including: boosted performance, new web browsers, increased Firefox performance, significantly enhanced suspend (power consumption in suspend is now 1/10 of original value) and many kernel fixes. You can follow the developments of the default OS build here. The Mainline Linux development is coming along very well and if you are dead set on running a mainline build with Panfrost (FOSS) GPU drivers then I suggest you follow this thread by tsys, which highlights the steady progress of 5.X kernel that is bound to be the basis for all future Linux OSs. Arch Linux on the Pinebook Pro via Screenshot via @AndreVallestero https://github.com/AndreVallestero\nThe past month has also seen a very important development on the hardware front. Namely, problems with missing keypresses and an unwieldy trackpad have now been resolved and are a thing of the past. The firmware fix for both inputs has been delivered thanks to the hard work of a dedicated group of people: TL Lim, anarsoul, Xalius and ayufan. Everyone who has already gotten their Pinebook Pro should install the new trackpad and keyboard firmware. The firmware update can be performed from any Linux OS and process itself is very simple only requiring running two scripts between reboots. Please reference the forum thread that describes the process in detail for more information. Future Pinebook Pros, starting with units shipped in December of 2019, will arrive with the new firmware pre-flashed. This brings me to the units currently on pre-order. The final pre-Chinese New Year Pinebook Pro production-run is now well underway. Let me reiterate what I wrote last month; if you want to get your hands on a Pinebook Pro prior to late March / early April 2020, then this is your last chance. Currently, the ISO-keyboard variants are scheduled to ship out in late December, closely followed by ANSI-keyboard variants in January. It is possible that due to the high volume of shipments from China in this period (Christmas in the West and upcoming Chinese New Year) the shipment process may be longer than usual.\nPinebook Pro ANSI layout\nWe have extensive plans for the Pinebok Pro in the future. Presently, we’re looking into ways to deliver various regional keyboard options to end-users - something we know many of you want. We still haven’t decided on if this is something we can realistically eventually offer, however, but rest assured that we will surely try. One of the concepts we’re currently exploring is offering regional keyboard caps sets, which end-users can install into an unpopulated ISO or ANSI keyboard on their own. These regional keysets would be accompanied by a corresponding keyboard firmware utility, which has now been open sourced (MIT License) and is executable from any Pinebook Pro Linux OS.\nAs I have written in the past, we are also planning on offering an upgrade kit for the original 11.6” and 14” Pinebooks. This kit would effectively convert an existing Pinebook into a Pinebook Pro-like device, and offer most of the functionality and compatibility of the flagship laptop. If all goes well, these kits will be available in the store sometime next month. I’ll have more information on these kits as they become available, so stay tuned and check the News section of the forum in early January. Lastly, I want to give a shout-out to an awesome community Initiative that have sprung up around the Pinebook Pro. A group of people want to design protective ‘skins’ for the laptop. We have now provided users with the .dwg file with the exact Pinebook pro case specifications and are eagerly awaiting for the first designs to arrive. Needless to say, once a couple of designs have been completed, I am sure we’ll be able to help in promoting them or even including them in the store eventually. What a great and fun initiative guys!\nCarbon \u0026lsquo;skin\u0026rsquo; concept for the Pinebook Pro by tophneal\nHappy New Year! We always make product announcements at FOSDEM and this coming year we have some really awesome projects that we cannot wait to share with you. As a bit of a teaser I’ll write that next year you can expect announcements of new single board computers, compute and AI modules and at least one pro-grade device. We also hope that our other side-project - the CUBE FOSS IP camera announced this year - will finally enter production at some point in 2020. I think that it will be a great year for PINE64 and I am looking forward to seeing how our plans all pan out. In the meantime, I wish you all a joyful holiday season and a Happy New Year! See you all in 2020.\n","permalink":"/2019/12/05/december-update-thank-you-for-2019/","tags":["community","pinebook-pro","pinephone","pinetab","pinetime"],"title":"December Update: Thank You For 2019!"},{"categories":["community","news","pinebook-pro","pinephone","pinetab","pinetime","rockpro64"],"contents":"\nOur core focus for the past month was on getting the manufacturing process and shipping of the Pinebook Pro, PinePhone and PineTime development kits back on track. I will not reiterate the events that led to the delays of those devices in this post, but if you’re interested then read the detailed account of what happened in last month’s community update. With the Pinebook Pros and PineTime development kits now shipped, and with the PinePhone developer edition now shipping, I feel that we’ve done a good job in handling the situation. The big news for this month is that we will start taking pre-orders for the PinePhone Brave Heart edition on November 15 and that the next Pinebook Pro production-run pre-orders, offering a choice of ANSI or ISO keyboard, starts today. Let\u0026rsquo;s get to it.\n[update 19/11/2019] I have now posted a follow-up to this community update on the forum; mostly containing information about the PineTime dev kits and PineTab availability based on your feedback. It can be read here. Here’s the TL;DR:\nOur monster clusters; core community services will migrate to our own hardware in 2020 Pinebook Pros shipped; Last pre-orders for ~3 months start today (ANSI +ISO) We’re aware of NVMe adapter \u0026amp; Trackpad issues, expect fixes soon OG Pinebook upgrade to Pro-esque setup in Q1 2020 PinePhones for developers (finally) ship November 5-18th PinePhone Brave Heart Pre-Orders start November 15th; delivery December 2019 / January 2020 PineTab production conundrum; state of software PineTime dev kits shipped; development proceeding exceptionally well Housekeeping Earlier this year we announced that we’ve built two monster ROCKPro64 clusters with the intention to host our website, Wiki, forums, CDN, Matrix instance, IRC, etc., as well as provide the community with an efficient OS images build server. We’ve have since been looking for a reliable host that would meet our criteria in terms of support, bandwidth, services and access that could house the server. Thanks to Gamiee - a community member, contributor and moderator - we were able to get in touch with BBXNET, who agreed the host the cluster for us at their datacenter and provide us with exactly the service we were looking for. BBXNET are located in central Europe, Slovakia, and offer a wide range of services including Internet and Television to their customer base. I feel compelled to let you know that they are helping us out of their own accord for no financial gain, a rare type of generosity, and in exchange for their help we’ll host a banner with their company logo on the website. It is the least we can do. As the setup process gets underway, Gamiee (who has a high degree of access to the server farm) will be taking pictures of the installation process. These pictures will be featured in future community updates. The transition of services to the cluster will be gradual, as we do not intend to compromise stability of our community services. I expect that Matrix and CDN will already be operating on the cluster in early 2020. If you live in Slovakia and in BBXNET’s service region, be sure to consider them when choosing your next ISP. 48x ROCKPro64 cluster\n[edit 8/11/2019] It turns out that the smaller of the two clusters, featuring 24x ROCKPro64 will be installed at BBXNET. I apologize for the confusion. I am including a picture of the smaller cluster below. Gamiee has already tweeted a picture of the server case and will be rebuilding and installing it at the final destination this month. More information to follow.\n24x ROCKPro64 cluster\nPinebook Pro Thanks to the amazing efforts of the factory and shipping teams, the Pinebook Pros from both community production-runs and a large portion of the ‘public batch’ have now shipped. I expect that the majority of the ‘public batch’ will be at some stage of delivery processing from Hong Kong by the time this post goes live, or shortly thereafter. In short, if you haven’t gotten your Pinebook Pro yet, don’t worry, you should be receiving your shipping notification soon. As things currently stand, we are approximately two weeks behind the original shipping schedule for the remainder of the public batch. This means we’ve got just enough time to launch one more round of pre-orders for another large production-run before the Chinese New Year. Unlike the first batches (which have already shipped), this production-run will feature the much-requested choice of ANSI (US) or ISO (UK) keyboards. So if you have been holding out on buying a Pinebook Pro because you wanted to get an ANSI keyboard version, now is you chance.\nIt is important to emphasize that this will be the last production-run until after the Chinese New Year (which comes to an end in February 2020). During the holiday, production ceases completely at Chinese factories, and there are often production challenges immediately after people return to work after CNY. Here is what you need to know: if you do not pre-order a Pinebook Pro from this next batch before CNY, you probably won’t get your hands on one until late March or early April 2020.\nLet’s talk about user feedback, initial reactions and community engagement. Reported and known issues aside (I’ll get to that), the reception of the laptop has been very good and it appears that we have delivered on our promises in the eyes of end-users. I\u0026rsquo;ve now seen a number of Youtube videos and it appears that they echo the positive sentiments end-users share on the forum and elsewhere. DASGeek even ran a live unboxing of the Pinebook Pro stream the other night, which I feature below. We’ve felt good about the physical build quality and software maturity of the Pinebook Pro from the very start, but it is a relief to get an affirmation from the community. Speaking of the community, we’re also very glad to see a high degree of engagement from people who continually contribute to testing, identifying and debugging software issues. Your efforts are much appreciated!\nhttps://www.youtube.com/watch?v=b-XikeQDKOw\u0026t=1s\nDASGeek live unboxing and Pinebook Pro showcase\nFor those of you looking to have more choice of operating systems, you’re in luck as many partner-project OS developers are now starting to receive their Pinebook Pros. It will obviously take them some time to bring support to the platform - this doesn’t just happen overnight - but I am happy to say that we expect to see Manjaro, Kali Linux, Q4OS (Debian), Fedora, KDE Neon as well as (hopefully) Ubuntu MATE OS images on the Pinebook Pro in the foreseeable future. The same is true for *BSD OS images, but I have a much less knowledge regarding the *BSD communities and their development cycles, so I cannot comment on a prospective roadmap. Regardless of how things pan out for the individual projects, I expect there to be considerably more OS choices available in January of 2020. As a teaser I attach an image of Manjaro running mainline kernel and Panfrost FOSS GPU drivers on the Pinebook Pro - pretty cool huh?\nPicture from Manjaro devs (thanks for sharing!)\nLast but not least, we are aware of the problems with the NVMe adapter and trackpad issues - both of which I discussed in last month’s update. Let me start with the trackpad: we’re working closely with the vendor to resolve this as soon as possible and we’ve already successfully compiled the keyboard firmware utility from source and applied the correct license (huge shout-out to Ayufan for offering help getting this code functional in record time). The underlying issue itself has now been identified and a firmware patch is incoming soon. As soon as the trackpad issue is resolved the updater will be compiled into a binary and bundled with the necessary firmware; all that will be needed to apply the fix is hitting a big ‘START’ button and restarting the Pinebook Pro.\nAs for the NVMe adapter it looks like we got it wrong twice (whoops, sorry! Let\u0026rsquo;s hope the third time\u0026rsquo;s the charm). We’ll make it right, so don’t worry; the engineering team needs to sit down and do a bit of thinking as to how this can be best addressed in the shortest time-span and in the most efficient way. I’ll make sure to get back to you when I hear something from people in the know. We really appreciate your patience. There is one more thing I’d like to mention before heading on to the next section. When we first announced the Pinebook Pro we made a commitment to those of you with the original Pinebook (featuring the Allwinner A64) that it will be possible to upgrade existing Pinebooks to Pro-esque versions. We have since struggled with two engineering issues to make this a reality, the most important of which is heat-dissipation of the RK3399 in a plastic shell. It now looks like we’ve cracked this issue by using heat dissipating metal foil and a thermal pad. Provided that this solution holds up under testing, you can expect the upgrade kit in Q1 2020. We hope that by providing this kit we not only cater to our community but also do our part in reducing the number of OG Pinebooks ending up in landfills. PinePhone The road to deliver the PinePhone has been a bumpy one for us in the recent months. If you haven’t done so yet, I encourage you to read last month’s update, in which I explain some of the difficulties we encountered in the process of manufacturing developer units. I usually don’t like shifting blame onto others for delays - it just feels like a cheap excuse - but frankly, the current PinePhone delay is caused solely by third parties. More specifically, it is caused by part vendors that failed to deliver the necessary components to us on time. We usually plan for these situations, and we did in this instance too, but we were stood up by more than one vendor and on more than one occasion, resulting in the production stalling each time. I am not going to go into details here, mostly because I don’t want to waste time on it, but for what it\u0026rsquo;s worth - it all boils down to reliably sourcing quality digitizers. To date, we had to reschedule assembly thrice because of this. What can I say, you live - you learn - you get over it and move forward. The good news is that we’re now moving forward and full steam ahead with a reliable supply of components. Here is the PinePhone road-map for the foreseeable future:\nPre-release PinePhones are currently shipping and we should have them all out by November 15th. Once shipped, delivery should be between 7 and 14 days. Brave Heart edition PinePhone pre-orders start 8:00AM, November 15th (GMT+0). Brave Heart edition will be delivered December 2019 / January 2020. Mass production begins after Chinese New Year, likely in early March 2020. Let me address each of the points above, because I feel there are a few subtleties the community needs to be made aware of. The developer PinePhones will start going out this week and we expect that shipments will be concluded by November 15th. Ironically, the delay in production of PinePhones for developers has brought about a number of key benefits to these units. For one, based on internal testing and feedback from partner-project developers with existing prototypes, we managed to address all known hardware issues as well as implement proper antenna arrays. Prior to the delay, we were planning on shipping PinePhones for developers with off-the-shelf u.FL antennas. Such antennas, while not ideal, would have served the development purposes just fine. The delay, however, granted us the additional time to properly implement the antennas into the phone’s body and tune them according to requirements for end-users. We were able to complete the tuning process of 3G, 4G, and GPS antennas . We’ve made progress tuning the 2G antenna but haven’t finalized it yet.\nThis effectively means that developers will be receiving a well-rounded, complete and (to our knowledge) problem-free platform to build their OS releases and applications. These units are much closer to those that end-users will be receiving this and next year. We were hoping to have developers give us one last bit of feedback on the hardware before it enters production and ends up in enthusiasts’ hands. But it is too late for that. The window for PinePhone Brave Heart production is closing very fast due to the upcoming Holidays in the West and, more importantly, the Chinese New Year in January 2020 which shuts down Chinese production lines for over a month. This effectively means that if we didn’t start Brave Heart edition production now, we would find ourselves in no position to deliver any PinePhones until March 2020. Suffice to say, we don’t want to do that. As a result, Brave Heart circuit board assembly is already underway, the molds are pumping out PinePhone chassis and the necessary components have been sourced and are en route to the designated factories. [edit 06/11/19] Here is a picture of the infused antennas used in the Brave Heart batch\nPrototype - photo by Martjin Braam\nI don’t want to give you an impression that the Brave Heart PinePhone edition is a rushed or incomplete product - that is not the case. We have carried out extensive in-house testing of prototypes and sent prototype phones to a number of key developers from partner projects. Youtube videos show these prototypes in action - you can search for them online or check out last month’s community update, where I feature some of them. We have addressed all known issues with the hardware and tested software compatibility extensively, both in-house and with our partner-projects. Indeed, this is more testing than we usually do on any other hardware, including flagship devices such as the Pinebook Pro. The extensive testing carried out on the PinePhone is a result of both the complexity of the device as well as our understanding of its importance, which spans far beyond our community.\nWith that out of the way, I’m happy to announce that the Brave Heart production run of PinePhones will be available for pre-order in 10 days time from the day of publishing this blog entry, on November 15, 2019 at 8:00AM (GMT+0).\nTimer on main page counting down to pre-orders opening\nSo, what can Brave Heart adopters look forward to and what should they be aware of? Let’s talk about the hardware first: the Brave Heart PinePhones will, by and large, be identical to PinePhones produced in 2020 and onwards. This applies to the case molding, PCB, LCD assembly, cooling, as well as various other components making up the phones, including aesthetic ones. These are effectively considered ‘final’. That said, as I already mentioned, we will likely be further tweaking 2G antennas to improve reception of the respective bands and we reserve the right to fix any issues that may be uncovered in the hardware. We do not, however, deem it likely that any major issues will transpire or affect end-users. Still, keep in mind that this batch is called Brave heart for a reason - we’re looking for those brave enough to be the first adopters of this hardware. If bravery is not in your nature, or this isn’t something you’re willing to take a risk on, then please sit this one out and wait until March 2020 to get your production unit. As for the software, I have nothing but good news to relay. It is my understanding that, with the exception of the front-facing ‘selfie’ camera, all core features of the phone are now functional. Developers still have a lot of software optimisation to do, including voice calls (which are a work-in-progress) and camera functionality, as well as other kernel and userspace parts. To give you a vague sense of where software is at using traditional computer terminology, which most of us can intuitively understand; you can think of the main flagship OSs as first stable ‘beta OS images’. Not everything works, bugs are to be expected, but overall things are really shaping up nicely. In a similar vein to what I wrote regarding the PinePhone Brave Heart hardware - if trying out beta builds isn’t something you enjoy, then please wait until polished OS images become available in Q1 2020. I expect that this is something most users who want an early PinePhone already expect and understand, nonetheless I felt it necessary to underline this so that only those with the right mindset get one of those units. Finishing off this already lengthy PinePhone section, I completely forgot to mention that Brave Heart schematics and other associated documents have now been made available. I am linking them below for you to view and comment on: PinePhone Brave Heart Schematic PinePhone Brave Heart Changes (vs prototype units) PinePhone Exploded Diagram of Brave Heart edition PinePhones PineTab [edit 8/11/2019] Vox Populi, Vox Dei. Looks like there is a lot of interest in an early-adopter production run of the PineTab. Subsequently we have decided to make it happen. We still need an suitable OS to emerge however; we hope that news of the production now being underway will help in making this happen.\nWe’ve made no secret of the fact that the PineTab is currently taking a backseat to the Pinebook Pro and the PinePhone production schedules. That said, we constantly get asked about the PineTab status on the forum, Twitter, Mastodon and elsewhere (even by podcast hosts). Hence, I felt it necessary to provide the community with some general sense of the hardware and software development stages, as well as share our thoughts on a suitable time for starting production. Spoiler alert, we aren’t quite sure as to the latter. As I mentioned in last month’s community update, we are currently waiting for a suitable OS image to emerge so that we can ship the tablet with it. We also need to make a couple of minor improvements to the hardware itself - we’ve gotten feedback from partner-project developers that the keyboard pogo-pin connector needs to be strengthened and the speaker replaced with a better one. To date, no other major issues have been reported with the prototypes, and so - as I’ve already stated in the past - we can theoretically start production of the PineTab relatively soon. With the Holiday season and Chinese New Year now looming over our production schedules, we’re at the brink of making a decision on whether now is a viable time to start an early adopter production-run. The next couple of days will determine if we find this time feasible or not. I’ll make sure to update this entry when a decision on this subject is reached. As things stand, we have already settled on the keyboard design that we’ll use for the tablet. It is a really nice chiclet keyboard - at least as far as small form-factor keyboards go - and features sturdy illuminated keys. Similarly to the keyboard you may have seen used with prototypes, it doubles up as complete tablet cover and features a really pu leather (fake leather) finish. We’re really pleased with how it turned out and I am confident in saying that most of you will like it too. As far as the software is concerned, we’ve got a couple of options available to us. The PineTab has benefited greatly from the amount of development that has gone into the PinePhone. But there is more than mobile OS devs in the development pool. Indeed, there are a number of original Pinebook developers and projects that have taken on the task of developing for the PineTab too. There are a handful of very promising OS images from big and small projects alike, but to my knowledge none that could be defined as ready for prime-time. Some of the OS images feature a traditional desktop environment and are, to a greater or lesser degree, tweaked ports of OS images for the original Pinebook. One such example is Manjaro with KDE - probably the most popular distro on the original Pinebook. From the phone lineage of OSs, there are already builds of Aurora, SaifishOS, Ubuntu Touch and PostmarketOS for the PineTab. I have not tested all of the aforementioned builds and so I cannot speak to their ‘completeness’. Danct12 from PostmarketOS has great showcases of the PineTab development progress, as well as various novelty items related to the tablet, uploaded on his youtube channel. I link some of his videos below.\nWhat do you think, should we run an early adopters batch before the Chinese New Year? I am really eager to hear what you think, so leave a comment under this post with your thoughts on this. Thanks!\nAurora on the PineTab - by Sergey Chupligin (neochapay)\nhttps://www.youtube.com/watch?v=ahONNYFLjK4\nOpenGL demo on the PineTab - by Danct12\nPineTime Despite development being in its infancy, the PineTime is already running FOSS software. Developers working on the watch deserve a huge shoutout for making so much progress in so little time - it hasn’t even been a month since they received the development kits. There are only so many things that I can keep track of when it comes to development, especially when there are so many things that have to be actively dealt with, so I am not going to pretend I have any real insight into how far devs have gotten. That said, the development process has taken on a striking resemblance to what I’ve seen with the PinePhone, where developers from different backgrounds and walks of life work together in getting the project off the ground. It\u0026rsquo;s probably corny to write this, but it\u0026rsquo;s genuinely quite heartwarming to see people bundle around what is effectively a proof-of-concept idea at this time. Since this is a community driven side-project, we have started considering making the dev-kits available to everyone in the store. In contrast to the PinePhone, which requires expensive and sophisticated development kits, a PineTime development kit is effectively an open watch with a debugger. Therefore, producing more of such kits is relatively simple. At the time of writing, a decision has not been reached yet whether we’ll proceed with making more kits available or not. But there is no denying that there is a lot of interest in this project also from people who want to use the PineTime in novel, interesting and important ways. For instance, we’ve been contacted by researchers from a reputable institution who wish to use the PineTime in a health-related capacity rather than a smartwatch. I’ll make sure to let you all know how the PineTime project evolves in the coming weeks and months. In the meantime, I leave you with a picture of the PineTime running its first FOSS watchface (and OS).\nThe PineTime\u0026rsquo;s first watchface running TinyGo - photo by Ayke van Laethem\nThis is all for this month, thanks for reading!\n","permalink":"/2019/11/05/brave-heart-edition-pinephones/","tags":["rockpro64","cluster","pinebook-pro","pinephone","pinetime"],"title":"November Update: Brave Heart, Pinebook Pro reception and more"},{"categories":["pinebook-pro","pinephone","pinetime"],"contents":"\nThis month’s update will be slightly shorter than usual - I have been dealing with some health issues recently, which significantly reduced my time to actively engage with the community. Hopefully I’ll make it up to you in November. September has been a bitter-sweet month for us. On the one hand, we’ve seen a lot of great developments: the first Pinebook Pros have reached their owners, and the reception has so far been great; core developers have started receiving their PinePhone prototype handsets and dev pre-order coupons have started going out; and we’ve announced the PineTime smartwatch - a companion for the PinePhone and other Linux phones. On the other hand, (and I have no intention of sugar-coating the situation) things haven’t gone exactly according to plan regarding shipments of developers’ PinePhones and Pinebook Pros for end-users. A series of miscommunications, factory errors as well as just good ‘ol bad luck resulted in dates slipping by a few weeks. To those of you who had to wait for your units and to those whom are still waiting - we apologize for the delay, we’re very sorry. Read on to find out what happened. [EDIT 18/10/2019] Since writing this blog entry I provided an update on the situation (Pinebook Pro, PinePhone and PineTime dev kits shipping) on the forum. Click here.\nBullet Points:\nPinebook Pro first batch shipping delay causes explained ; we’re sorry Future shipments 2 weeks delay ; we won’t put shipping staff at risk Pinebook Pro early adopter feedback very positive ; issues noted and worked on PinePhone Dev edition delay explained ; prototypes run great The PineTime ; a side-project with a lot of potential ; community driven Closing thoughts - are we being stretched thin? Pinebook Pro shipping delay detailed explanation Let me give you a run-down of the events that caused the delay in the shipment of Pinebook Pros to customers. The delay was caused by a series of intertwined events, so it\u0026rsquo;s just appropriate that I list them in chronological order. The first issue we encountered during production was that the Pinebook Pro doesn’t power on with the battery disconnected. This isn’t an issue that will affect the majority of users, but it had to be addressed nonetheless. Finding and implementing a solution (a bypass cable - please see the engineering notice) set us back a few days. However, the majority of time was lost on the second issue. To understand the problem you first need a little technical background; the RK3399, which is the SOC used in the Pinebook Pro, has a hardwired boot sequence that prioritizes eMMC over SD. This means that, unless the bootloader on the eMMC is altered to seek out bootable SD or USB 2.0/3.0 flash (such as uboot on the Debian + MATE build), the OS residing on eMMC will always boot prior to bootable micro SD or USB 2.0/3.0 flash.\nNow here is the problem - the factory we work with is accustomed to carrying out hardware and QC test using a custom Android build. They always flash this build to eMMC modules before completely assembling the devices. This Android build doesn’t have the necessary uboot alterations to prioritize SD or USB bootable storage; as a result, we found ourselves in a position where all the fully assembled Pinebook Pros were running factory Android and there was literally no way to reflash them with Linux without disassembling all the laptops and reflashing them manually. Moreover, the factory uses a proprietary Rockchip utility to install the Android image and is completely unaccustomed to flashing ‘normal’ DD images. Needless to say, solving all problems related to this situation took a very, very long time - over a week in total. For those interested, I am including our solution to the problem that will be used in future batches. Our offices in China will deliver pre-flashed Debian MATE eMMC modules (since the build features uboot that prioritises SD and USB storage over eMMC) to the factory, and the factory will carry out its tests on the custom Android running from SD. This effectively means that we’ve taken on a part of the production process, which is a burden to our staff but the simplest way to resolve this issue. The third, and last, technical issue was first found after all units were assembled and moved out of the factory. Someone from the shipping team realised that the laptop emits an annoyingly high pitched noise when charging. This did not affect the operation of the Pinebook Pro, but we were certain that users would be displeased with this imperfection. So, the laptops were brought back to the factory over the weekend and the tiny component making the noise was removed and replaced. The reason for this issue being caught this late is quite simple - the high pitched noise isn’t loud enough to be heard on a factory floor with all sorts of machinery operating. It’s only noticeable at ambient noise levels; e.g. at home with the TV off. At this point in time we missed our shipping date by weeks, but it was now September 27 and geopolitical events - which I will not discuss or debate here - caused further setbacks. The Pinebook Pros are produced in Shenzhen, mainland China, but ship out from Hong Kong via DHL. This means that our shipping staff needs to make the trip to the Hong Kong storage bay where the Pinebook Pros get picked up for delivery. If you follow global news, then in all likelihood you’re aware that the situation in the region is volatile at the moment. As a result of the situation in China and Hong Kong, only half of the original first production run shipped out. The remaining portion of the first batch will be shipped in the next couple of days, after the week-long national holiday comes to an end, and (hopefully) things calm down slightly. Before I wrap this section up let me assure you that we will not expose our shipping staff to situations where their life or wellbeing could be jeopardised. I hope this decision is self-evident, and that we can all agree this it is the only sensible course of action. This also means that if the situation in the region will remain unstable, then future shipping dates may slip too. Future Pinebook Pro shipments, early reception and feedback The current delay in delivering early Pinebook Pros has pushed our dispatch dates for the second (community) and third (public) batch slightly forward. Granted that production and shipping processes are not impacted by the unrest in the region, we will be shipping these two batches collectively at the end of October or in early November. With most issues ironed out during the production of the first batch, I trust it should be relatively smooth sailing from this point on. Famous last words, I know. Based on feedback from early adapters, it seems that there are no glaring or core experience hampering issues we need to address at this point in time, and the minor things users have found should all be fixed swiftly. As always, I’ll keep you posted on how things progress on the forums and chats, as well as on Twitter and Mastodon. Right now we are aiming to open up the next round of pre-orders on the day that the second and third batch ship out to end-users. I can currently only offer a guess as to when this will be - likely sometime between October 25 and November 4. Before wrapping this section up, let me discuss end-user reception and feedback. I am happy to say that Pinebook Pro reception has been overwhelmingly positive. There is an entire thread dedicated to people’s early impressions of the Pinebook Pro, which I encourage all of you to read - especially if you’re on the fence if you want one for yourself. Let me add that I am impressed with the quality of the feedback thus far - it has been on-point and constructive. I am actively monitoring the information flooding in on the forums and chats, and from what I’ve gathered the grand majority of users are impressed with the hardware and happy with the default software. This is obviously a huge relief to us. A number of people have already posted pictures and youtube videos of their Pinebook Pro running and showcasing its various features, so I am posting them below for all of you to check out. User submitted pictures (by Mrfixit2001 \u0026amp; kunger)\nhttps://www.youtube.com/watch?v=Sm4DEGP-qIE\nQuick unboxing video\nThat said, there appear to be some minor problems with additional hardware and the keyboard firmware. Let\u0026rsquo;s start with hardware: reports indicated that the optional PCIe-NVMe adapter can push the trackpad up-and-out of the chassis if a NVMe SSD is too thick or the adapter is installed incorrectly. It will take us some time to replicate this and figure out what can be done; I don’t have a solution for this from the top of my head. My guess is that it is caused by the thickness of particular NVMe drives, in which case we’ll have to compile a list of drives that fit inside the Pinebook Pro chassis. We’ll try things out on our end and let you know. Onto trackpad/keyboard firmware: we’re aware that under particular circumstances the trackpad/keyboard firmware can misbehave causing delayed input. From my testing, it seems to be a relatively rare occurrence, but when it happens it is indeed quite annoying. Thankfully, we have the source code for the utility used to alter and patch the keyboard firmware - it was open sourced to us by the keyboard vendor. We’re in the process of building and testing this utility on ARM. Rest assured that this is an issue that we’ll solve in the future, and it should be a relatively painless process for end-users to get the firmware patched. The utility has a simple GUI, all you need to do is press ‘START’ and wait for the software to run its course installing the keyboard/ trackpad firmware binary.\nPinePhone prototypes and developer pre-orders Last month we opened PinePhone pre-orders for developers intention to have them shipped by now. However, right before assembling complete prototypes we received word from partner-project developers who already had core PinePhone components, that the digitizer has issues with registering swipe-motions. Based on this information we were forced to hold off on starting production and turned to another vendor for a suitable digitizer replacement for the PinePhone. Sadly, the time it took to deliver and test the new part was long enough that we were unable to complete prototype production before the current Chinese National week-long holiday, which is ending on Monday October 8th. This is another case of bad luck we ran into last month. Despite the unfortunate delay in assembling the phones, we are happy that this flaw was found prior to the devices being shipped out.\nBut it is hardly all doom and gloom. We’ve tested the hardware last week and are now positive that the new digitizers work well. This means that the PinePhones for developers can be built once the aforementioned holiday finishes next week. The pre-order coupons for approved developers have now started going out and will keep on being dispatched until the end of next week, and possibly even further into the future. I’ve seen numerous reports that people have gotten their coupons already. Some of you who follow us on social media may have also already seen that a handful of key developers, whom we’ve been working with since the very start of the project, have gotten their prototypes ahead of the holidays. In fact, Martijn from PostmarketOS even built his unit on camera for all of you to enjoy. Check out the video below.\nhttps://www.youtube.com/watch?v=VyeD1sfQNoM\u0026t=1s\nBuilding a PinePhone Prototype and running PostmarketOS\nThe initial feedback from those who got their hands on the PinePhone prototypes has been great. Marius from UBPorts shared a video showing that the prototype with the new digitizer not only looks great but also runs Ubuntu Touch very well. It’s noteworthy that both PostmarketOS shown in Martijn’s video, and Ubuntu Touch in Marius’ video run the open-source Lima driver. This means that UI performance will only improve with time as the Lima driver gets polished and improved upon. From the videos circulating online you can also see that most of the core features now work flawlessly on many available OSs. Even browsing the web and watching youtube already works very well on most systems; I recently tested a recent build of LuneOS, and I was completely blown away by how much of the core functionality is already in a mature state. The prototype isn’t completely problem-free however, and the remaining bits and bobs will need to be addressed before production of the Brave Heart editions starts in late October. I’ll keep you posted. Note: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Ubuntu Touch running smooth on the PinePhone\nUbuntu Touch on the PinePhone\nThe PineTime Finally some truly good news - the PineTime. I’ll immodestly take the credit for the start of this project, since I pushed for us to explore the potential for creating a FOSS smartwatch for some time now. After initial talks, we quickly agreed that the PineTime should be a side-project (like the CUBE FOSS camera), completely community driven and positioned as a complementary device to the PinePhone. Therefore, rather than looking into creating a complex device (which would be cool too! - it’s something we may look into in the future), we opted to make a simple and inexpensive smartwatch based on a FOSS friendly SOC. To this end, we quickly determined that the core functionality of the watch should be similar to that of the Pebble, but with some modern functionality, such as a colour LCD touch screen and a heart rate monitor. Early on in the planning process we also decided on using a square watch chassis for the PineTime. We had a choice of a few form factors, including a round-one, but decided to proceed with an unassuming and simple design. The main reason for the choice of square chassis, however, is not the looks but rather ease of development. Simply put, it\u0026rsquo;s easier to develop an OS using a square display. It was a safer choice from a development standpoint, especially when taking into account that entire OSs need to be built, or ported to, the PineTime watch. Apart from the display and SOC choices, we also had a few other criteria in mind: the watch had to have multi-day battery (a week at minimum), feature a touch panel, be waterproof and lightweight. We have started writing up the Wiki for the PineTime, so if you want to learn more technical details of the watch you know where to find them. I’m including some prototype pictures below. Prototype on wrist\nDevelopment kit\nCharging dock\nInternals exposed\nThe core idea behind the PineTime is to have a simple and open-source watch that connects to your Linux smartphone. It will push notifications from your phone to your wrist, inform you of incoming calls, help you keep track of your activity, but it won’t attempt to replace your smartphone. Not to mention that it will not need to be recharged every day - we currently aim at a 10 day battery life. I trust that many of you feel that this is the correct approach to creating a wearable device, and I hope that developers will offer an interesting range of systems and front-ends to run on it. We have now assigned all dev kits to developers who contacted us and will start production of the kits this month. We cannot wait to see what people and the community will be able to do with the little device. There is one last bit worth touching upon in relation to the PineTime. A smartwatch of this type requires a companion app on the smartphone. This effectively means that PineTime developers will have to work together with - or at the very least get help from - Linux-on-Phone developers to bring apps to the different OS platforms. Then there is the question of creating a companion app for Android phones, since I am sure many users relying on open variants of Android will be interested in the PineTime too. As I’ve already mentioned, this is a project which we’ll leave with the community - it will be ready when it\u0026rsquo;s ready, be it in 3 or 6 months, or even a year. On our end, we’re ready to start production of the watch as early as January 2020. As for pricing, we are presently aiming for a price point of approx. $20. The price includes the watch and a charging dock. We decided on selling the 20mm watch-straps separately, since most people have their own preferences of style, and hope to carry a wide selection at launch. These straps will vary in price, starting at approx $3 for regular silicone sports straps. You can obviously pick up any standard 20mm watch straps on your own, they will most likely fit the PineTime. Closing thoughts We’ve heard community members as well as podcast hosts express a concern that ‘we’re stretching ourselves thin’ with respect to all the projects that we have in the pipeline. This is not completely accurate, please let me explain. We’re not stretched thin from a production, manufacturing or financial standpoint. The Pinebook Pro, the PinePhone and the PineTime are all produced by different factories and the work on these devices is carried out by separate engineering teams. Hence, it is not true that a delay in the shipping of one device will necessitate the delay of another device; to use the events of last month as an example, the delay in Pinebook Pro production and shipment last month had nothing to do with the delay in shipping out PinePhones to developers. As I have outlined in earlier sections of this community update, these situations were purely an unfortunate coincidence. That said, we - the people end-users and factory representatives have contact with on a daily basis, as well as the people behind logistics - are indeed stretched thin due to the workload brought about by manufacturing delays. I think I have some 30 emails still sitting unanswered in my mailbox, not because I didn’t want to answer them but rather because I’ve been busy doing other things that are more urgent. When everything runs smoothly, productiontion and shipments are timely, the number of devices produced doesn’t impact our workload. Its first when things go South that we get overwhelmed. With Murphy’s law in full effect last month, we did ‘get stretched thin’ because we had to deal with multiple issues at the same time. We’ve now placed some of the secondary projects on temporary hold - at least until we ship the PinePhone Brave Heart and October Pinebook Pro batches. This clears out a little bit of space for us to deal with any unforeseen events related to these projects. At the same time, don’t worry, we’ve got a lot of cool stuff coming in early 2020 - including the PineTab. That wraps it up for this month. Thanks to all of you guys who are there cheering us on, it really makes a difference.\n","permalink":"/2019/10/05/october-update-pinetime-delays-and-shipping-news/","tags":["pinebook-pro","pinephone","pinetime"],"title":"October Update: PineTime, Delays and Shipping News"},{"categories":["news","pinebook-pro","pinephone"],"contents":"\nPicture of a PinePhone prototype running Plasma Mobile Let’s start with a quick recap of last month’s events: the Pinebook Pro went into production, software development on the PineTab started, we announced the SOEdge AI module and introduced our initiative for giving back to PinePhone Linux developers during the community meetup in London. This, however, is hardly everything. Let me segue into the core topic of this month’s update, namely the PinePhone. Behind the scenes prototype PinePhone PCBs and chassis have been produced and undergone extensive testing. With the testing now completed, we made the decision to manufacture a small batch of PinePhones for developers. We have also scheduled two larger production-runs, which will be open to early adopters later this year.\nSo, without further ado, I am hereby happy to announce that the first PinePhones have now entered production and will start shipping to developers this month. As you probably already gathered from this brief introduction there is a lot to cover, so let\u0026rsquo;s get started. Bullet Points Donating to PinePhone devs ; contributing to solving digital divide Pinebook Pro shipping schedule ; engineering notice ; privacy switches \u0026amp; ‘PINE64’ logo key PinePhone prototypes ship to developers this month ; 8 months since announcement, years in planning PinePhone shipping timeline for 2019 \u0026amp; beyond ; “Brave Heart” editions ; 2020 large-scale production PinePhone hardware overview ; PinePhone vs dev kit; new LCD+ TP ; aluminium alloy infusion ; quick charge PinePhone software status \u0026amp; progress report Housekeeping We recently announced that we\u0026rsquo;ll be donating $10 from each PinePhone sold to Linux-on-Phone projects working with us. If you haven’t done so yet, I strongly suggest you read the original announcement. In short, we intend to have OS-specific campaigns - complete production-runs with a particular OS pre-installed as well as stylised phones - but also a permanent system allowing users to select directly which project we should donate to. We wish for the donation process to be both transparent and, in the spirit of our community, also completely open. This means having the donations software hosted on GitHub/ GitLab for anyone to view, review and contribute to. If you’re interested in helping out in making this happen then please reach out to fire219 on the forum or in the chats. During the meetup we also announced that we’ll do our share to contribute to closing the digital divide. Let me give you a short run-down of how it will work: money from the sales of soft cases for the PinePhone will be funneled into production of original 11.6” Pinebooks for those in need of a computer. I’ll be speaking to people in the community as well as notable persons in the broader Linux universe in the coming months to set up a panel that will put forth proposals, discuss them and subsequently vote on where the Pinebooks should be donated to. This initiative will start with the first public production-run of PinePhones; more information will follow once I have members of the panel lined up. I’d like to note this is a community initiative and therefore also completely open for all to participate in by sending in proposals, interacting with the panel as well as having insight into the panel\u0026rsquo;s workings.\nCommunity meetup - sunny day in London 18 August, 2019\nPinebook Pro: Shipping dates, ‘PINE64’ logo key and software updates Before proceeding to discuss the PinePhone there are some Pinebook Pro news, which I think ought to be covered first. Let’s start with the shipping dates; the first community pre-orders will start shipping mid-September, followed by the public pre-orders in October. Please note that these dates are subject to change - if something changes you’ll be notified ASAP. A wide range of things can affect production at this early stage - as an example, we recently discovered that the Pinebook Pro does not power on from mains with the battery disconnected from the mainboard. Whilst this will not affect the great majority of users, a suitable workaround still had to be determined and implemented to mitigate the issue. Working out such things takes time and results in shipping dates slipping - thankfully, in the case described above, everything got sorted in a matter of a couple of days. A bypass cable, disconnected by default, has been added to the mainboard. In the event the laptop is required to run on mains power with the battery disconnected the cable needs to be joined; please read the engineering notice. Onto the ‘PINE64’ logo key and its functionality. Before the community pre-orders began in July we announced that the Pinebook Pro will include privacy switches. In the same post I discussed the feedback we received regarding our decision not to brand the laptop, which prompted us to include a subtle touch in the form of a ‘PINE64’ logo key on the keyboard. Since then there was a lot of back-and-forth discussion regarding the functionality of the key. Eventually we put 2 and 2 together and reached a logical decision - the ‘PINE64’ logo key now functions as a regular Super key unless pressed down with F10, F11 and F12 key for 3 seconds. Pressing the combinations above will disable/ re-enable the laptop’s microphones, the WiFi/BT module and the webcam. We feel that this is a natural fit for the ‘PINE64’ logo key and its function, and we hope you feel the same way. Since we’re already talking about changes to hardware, and I have nowhere else to fit this piece of information, I am happy to let you know that the Pinebook Pro’s webcam has been updated to a 1080p cam; I’m sure that some of you will appreciate this. Lastly, I want to discuss software related things. In the recent weeks ayufan has pushed a number of OS images for the RockPro64, the Rock64 and also the Pinebook Pro, which includes a very long list of improvements that result in great functionality and performance. A choice of Ubuntu with MATE desktop or LXDE as well as a great-performing build of Chromium OS will be available for you to try on day one. The default Debian with MATE desktop, which ships with the Pinebook Pro has also received a lot of development hours since the OS image was shipped to the factory. The list of improvements is quite lengthy so if you\u0026rsquo;re interested make sure to read the update-log here. The one truly vital improvement made is a patched U-Boot (pending feedback from early adopters), which alters the Pinebook Pro’s default boot sequence. This means that now the Pinebook Pro will boot OS images on the SD card and USB 2.0 / USB 3.0 ports prior to the onboard eMMC. It’s a simple way to try out other OS’, such as those offered by ayufan, without committing to wiping your current installation. To get this and the numerous other features please make sure to update your system using the included utility on first boot (please reference the update-log).\nThe \u0026lsquo;PINE64\u0026rsquo; logo key and privacy F-row keys\nThe PinePhone now exists It has only been 8 months since we announced the PinePhone at FOSDEM 2019, but the idea of creating a FOSS Linux phone has been with us for years. Indeed the phone topic was first discussed in 2017 over a pint of beer at a pub in Brussels during FOSDEM of that year. I remember TL brought with him a tablet chassis and talked about how we could have an A64-based device ecosystem: a SBC, a SODIMM module, a laptop, a tablet and a phone, all of which would run mainline Linux on a common platform. Soon after, however, the creation of a phone was deemed too complex and expensive. Looking back I think we felt it would be an undertaking that would deplete all of our energy and resources, which at the time were being pumped into Rock64 and RockPro64 development. The phone discussion resumed last year once all SBCs that were in the pipeline hit the market. Having done some research on mobile Linux operating systems, on October 2018 I joined UBPorts and started talks with the project developers. It wasn’t long after that I wrote to TL: “These guys seems really friendly and (\u0026hellip;) I think they are up for it”. We have since established contact and welcomed into the fold all major Linux-on-phone projects, whom are now collectively working towards making the PinePhone the best device it can be. Only 11 months after committing to creating a mobile phone, the first PinePhones are now being assembled at the factory. I dare say, this is no small feat for a reasonably small and community driven project. Developer pre-orders are now live and it won’t be long before core enthusiasts get their hands on the PinePhone too. This is just the start of our journey with the PinePhone, but with both software and hardware progressing at Warp 10 speed I am confident that in early 2020 everyone interested in a Linux phone will be able to purchase one.\nPinePhone with battery inserted\nPinePhone without battery + back cover off\nDeveloper pre-orders September 2019 These PinePhones are prototypes and are aimed solely at developers. More specifically, we intend for these early units to find their way into the hands of developers with extensive Linux experience and an interest in Linux-on-phone. Sorry app developers, tinkerers and end-users, you will have to wait a little longer. Due to the very limited number of these prototype phones available at this time, the pre-orders will be made on a bespoke basis. In this way we can ensure that each and single unit goes out to someone who can contribute to the project at its current stage and help us deliver the software for the first public production-runs. Regarding the actual hardware; the phones are nearly identical to units that will ship later this year and in early 2020. I write ‘nearly identical since the antenna calibration hasn’t been completed as of yet and there may be additional tweaks to the PCB design based on the feedback we’ll receive in the coming weeks. As for the software, this edition of the PinePhone will ship with a custom OS built for debugging hardware on the PinePhone. It is meant as a reference point which can be used during development. All relevant information pertaining to the build will, of course, also be available for those interested. The greatest resource of all, the developers themselves, are readily available in the chats and we expect to see the owners of these early PinePhones joining them in the near future. Main page dev pre-order widget at the time of writing\n“Brave Heart” editions in October 2019 and beyond We are planning on having two early adopter production-runs this year. We chose to call these two batches the “Brave Heart” editions, since no complete OS images will be available at the time of shipping. So, in other words, these production-runs are only for those of you whom are brave enough to buy a device without a fully functional OS. Rest assured that we will make sure information about the state of software is front-and-center at the time of shipping. These two production runs will be geared towards the bleeding edge enthusiasts who also wish to contribute to development by debugging, testing builds and offering feedback. These phones will ship without an OS preinstalled - we expect that people who will pick up a Brave Heart edition will want to hold off from flashing any OS to the eMMC in favor of trying out weekly or daily builds on SD cards. A pre-flashed OS would be significantly outdated by the time it would end up in users hands anyways. The turn-over time for builds is presently quite fast and I expect this pace will keep up for quite some time, especially with detailed bug reports from early adopters pouring in. We are planning on starting the production line on mid-October, just over a month from now. Pre-orders for the Brave Heart edition will start around the same time and will be open to all. This batch of PinePhones is scheduled to be delivered in November. The second batch will be built the following month, on 15 November, and will be delivered to end-users some time before Christmas. Please keep in mind that these dates are tentative and we may instead opt to pool together the two production-runs into a larger batch in early-to-mid October. This schedule depends on the feedback we receive from developers and their experience with pre-production units. A commercial-scale production of PinePhones has currently been scheduled for March 2020. By this point in time we expect to have - at the very least - one end-user ready OS image with all core functionality. PinePhone Hardware I’ll divide this section into a discussion on the PCB and the body of the phone. I’ll also touch on the notable differences between the development kits and the PinePhone. Let me get the differences between the phone and the dev kit out of the way first. The things that I’ll list may seem obvious to many of you, but I will go over them anyways, since I’ve recently been made aware they aren’t immediately apparent to everyone interested in the project. As I already mentioned, the form factor of the kit and phone PCBs is different as the design had to be shrunk down to something that would fit inside a phone chassis. The dev kit is also modular, with the individual parts being detachable from the mainboard, while the phone has most of the key components permanently soldered onto the PCB. While a modular phone is conceptually very cool, it is rather impractical and significantly increases the manufacturing complexity, and thus also the cost of the device. Lastly there is the question of physical space that components take up; phone chassis are rather cramped, so having a modular design effectively means having a thick phone. For the same reason, the full-sized Ethernet and HDMI ports found on the dev kits didn’t find their way into the actual handset either. I’d like to note, however, that both video-out and Ethernet functionality is achievable via the USB-C port on the phone. The last and most important difference is the touchscreen used on the actual phone. The LCD display is slightly larger at 6” and the touch panel includes a drastically better high-precision driver.\nLeft PinePhone // Right development kit (v1.2)\nWe have also made some significant improvements to the phone’s chassis since the original design was publicly unveiled. The inner section of the plastic body has since been infused with an aluminum alloy and tooled to be compatible with an existing 3000mAh big-brand battery. Having the body infused with an aluminum alloy serves two purposes: it significantly strengthens the core structure of the phone and improves component heat dissipation. With metal now being an integral part of the assembly, the PinePhone also feels considerably more sturdy in the hand. The entire inner construction of the phone, and most of the components, are held in place using standard Phillips-head screws. Very little adhesive is used on components that are not soldered onto the main PCB such as the cameras, so removing these parts is also pretty straightforward. The detachable back panel - which covers the privacy switches, pogo pins and the removable battery - is made of a durable soft-touch plastic. Subjectively speaking, it\u0026rsquo;s nice to the touch and attract fewer greasy fingerprints than glass or metal. Taking the phone apart is achievable by anyone and should take no longer than 5 minutes from start to finish. This time estimate excludes the LCD+touch panel, which I suggest end-users do not attempt to disassemble; it is possible, but requires some finesse.\nCase with aluminum alloy infusion (prototype)\nPinePhone mainboard + daughterboard (prototype)\nOnto the last point on my list, namely the PCBs used in the phone. The mainboard is an 8-layer Blind Via PCB, and it is the most complex PINE64 design to date. There is also a smaller daughterboard, which is connected to the mainboard using a ribbon cable, that houses the microphone and USB-C port. The USB-C port on the PinePhone does not only support alternate mode video out and data, but also 3A 5V quick charge (follows USB PD spec) when using a compatible charger. The Allwinner A64 SOC, powering the PinePhone, and Quectel EG25-G modem are placed on opposite sides of the mainboard, with the A64 facing inwards. The A64 makes contact with metal on the LCD back-plate via a thermal pad. This solution provides ample heat dissipation, even under load. All components on the mainboard are covered by a removable metal shroud (not in picture above), which is similar to those found on the Pinebook and Pinebook Pro. The mainboard is covered and held in place using the internal structure of the phone’s body, but leaves the following components and ports exposed: I2C pogo pins, privacy switches, SIM card as well as micro SD card sockets. Access to all the above is fast and easy, and only requires you to pull off the back cover of the PinePhone, which pops easily using a fingernail or the edge of a credit card.\nCompared to modern big-brand smartphones the PinePhone is remarkably simple, and we trust this is a good thing. Repairing and maintaining the phone is straightforward and achievable by anyone with a screwdriver and patience. Batteries for the phone can be had for under $10 online throughout the world and we’ll be stocking replacement parts as soon as larger-scale production starts next year. Before we move onto software, let me say that this isn’t the end of updates to PinePhone hardware; as it has always been the case with PINE64, we’re continually looking to improve currently listed specs. More surprises are in the store for this device so make sure to check the PinePhone spec-sheet closer to public-release date.\nPinePhone Software I am happy to report that a tremendous amount of progress has been made on the PinePhone software in the past month. Most notably perhaps we’ve got our first glimpse at the Ubuntu Touch build on the PinePhone, which I know many of you have been looking forward to seeing. As I’ve mentioned in the past - and on more than one occasion - I am not the most competent person to assess software. That said, even I can tell when something is running well; and yes, the Ubuntu Touch build that I’ve gotten to experiment with runs really quite smoothly. The animations are fluid, applications now launch and the overall experience is massively improved over my past experiences. Moreover, mobile and wireless connectivity are now also functional. Below is a clip from Marius (UBPorts) showing the UI running snappily as he toggles between the different GUI elements. That isn’t to say that the build is production ready, but it\u0026rsquo;s coming along very quickly and will likely be one of the launch OSs. I will wait for another month or so, and give Marius and Nikita a bit more time with the build before I showcase it on the PINE64 youtube channel. It will, however, be the first thing I load up on my pre-production PinePhone when I get it next month.\nhttps://vimeo.com/357951065\nVideo by Marius Gripsgard from UBPorts\nSimilarly, the PostmarketOS Plasma Mobile build also works quite well. Animations are smooth, applications start as they should and even little things such as the brightness slider are functional. Sadly the build currently suffers from an issue allowing it to only run properly on the first boot - on subsequent reboots the UI errors out and only displays a black screen. I am told this is a problem which is not isolated to the PinePhone dev kit, but affect all supported devices. Apart from this error, there are also a few lesser issues, most of which are related to the Lima GPU driver. This build too has undergone very significant improvements over the course of last two months. Until very recently, many of the UI elements were incorrectly rendered as transparent and applications did not launch. If you are interested in seeing Plasma run on the PinePhone then please make sure to check out Martijn Braam’s youtube channel, where he demos WIP builds.\nhttps://www.youtube.com/watch?v=8V711Iordo4\nPostmarketOS running Plasma Mobile by Martijn Braam\nI also had a chance to get my first hands-on experience with SailfishOS this month, and I was very positively surprised by how well it runs. My surprise stems from the fact that the UI has always appeared to me to be quite intricate and complex, which had me believe that it was more resource hungry than other OSs. It also uses experimental Lima drivers as opposed to the (currently faster) mali blob. Thankfully when swiping between tabs, opening applications and scrolling through the settings menu I was greeted by smooth OS functions. Adam and Dylan have posted videos showing the performance of the OS that I am including in this post for you to check out. It is my understanding that most of the functionality already available in other OS builds is also present in SailfishOS. I now have high hopes for SailfishOS on our platform, and I hope that the large and thriving community behind this OS will appreciate the unique feature set that the PinePhone brings to the table. https://vimeo.com/357952216https://vimeo.com/357952026\nVideos by Adam Pigg and Dylan Van Assche from SailfishOS\nI did not try out LuneOS this month, in part because I’ve already done so recently and know that it runs very well on our hardware. I spoke to Tofe, the LuneOS developer behind the builds, and he told me that a lot of progress has been made recently. LuneOS currently expects to have an early release available within a month’s time. Functionality of this early release will have to be confirmed on the developer PinePhone, but LuneOS ran well on the dev kit hardware and so any negative performance changes are unlikely. I also reached out to Wizzup from Maemo Leste asking for a development progress report. Maemo Leste has been working on their phone and cellular support in recent months. Below is a screenshot showing off their cellular status applet (showing signal strength and access technology) and operator name applet (showing the operator name - KPN). Setting up a cellular data connection, which is automatically provisioned is now also possible. Sending and receiving SMSes also works using Empathy and Telepathy-ring - the attached screenshot shows the PinePhone-side of the affairs with Maemo Leste receiving SMS messages. Maemo Leste also have a (long) update post of the various software improvements I suggest you read here.\n](/blog/images/es/MaemoLeste2.png)\nScreenshots by Merlijn (Wizzup) Wajer. Left UI with visible networking // Right SMS on PinePhone development kit I get the sense that everything is coming together in a rather fast and orderly fashion. Modem functionality is also coming along very well. Developers are planning on debugging remaining modem-related issues - some of which prevent phone calls from working properly - this month and they are positive that everything will be working soon. Phone calls aside, both GPS and LTE data already work, and SMS messages have already been sent and received from the development kit on most OSs. I have tested WiFi myself on more than one build and it functions properly, as do a number of sensors on the development kit, including the gyro and ambient light sensor. For those keen to learn of all the details, you can check the PMOS bug tracker that details what has already been implemented and confirmed as working. I am not certain if this bug tracker is representative of the majority of PinePhone OS images, it may very well not be, but it certainly gives you an idea about overall progress and state of software. In a nutshell, software is getting close but it still has some way to go. That’s all for now, stay tuned to this blog as well as Twitter + Mastodon for more news in the coming weeks!\n","permalink":"/2019/09/05/september-update-the-pinephone-is-real-shipping-soon/","tags":["pinebook-pro","pinephone","release"],"title":"September Update: The PinePhone is real \u0026 shipping soon"},{"categories":["community","digital-divide","sustainable-foss"],"contents":"\nPINE64\u0026rsquo;s commitment to giving back to the community, partner projects and the society has been outlined by TL Lim during our community meetup in Hyde Park, London on 18 August, 2018. No one has ever become poor by giving ~ Anne Frank Free as in a bird, not as a beer. Libre and not gratis. We all understand this concept while simultaneously appreciating that open source software is, for the most part, also free of charge to regular end-users. By relying on donations and sponsorships to make revenue and keep the light on, most projects maintain a low barrier to entry for new and prospectus users. Anyone with a computer and an internet connection can readily use just about any Linux or *BSD operating system, as well as any open software these OS\u0026rsquo; run. Not to mention that anyone is welcome to study, contribute to and alter the said software. I know that I am preaching to the choir but FOSS is amazing. That said, these are hardly the only reasons for using open source software. For a sizable number of people, the payment-free model also means access to good and viable alternatives to proprietary software, which may be financially out of reach. I myself, as an undergrad student in the early 2000\u0026rsquo;s, resorted to using OpenOffice - not for ideological reasons, but rather because I couldn\u0026rsquo;t afford the MS Office Suite.\nThat said, projects need money to sustain the development process and, ultimately, the software they deliver free of charge to end-users. Much has already been written on the subject of sustainability of FOSS projects by people more knowledgeable than myself, so if you\u0026rsquo;re interested in the subject matter then search for FOSS financial sustainability. In a nutshell, keeping a FOSS project financially sustainable is very difficult; In the words of Andre Staltz, data shows \u0026ldquo;(\u0026hellip;) that open source creators and maintainers are receiving low income\u0026rdquo; and \u0026ldquo;[t]his is not the first time [in history] hard-working honest people are giving their all, for unfair compensation\u0026rdquo;. The statistics vary vastly, but it is estimated that only a marginal fraction (approx 0.0001%) of people who ever, at any point in their life, used open source software have donated any amount of money to a project. It comes as no surprise then that even very large projects, such as Linux Mint, receive monthly donations that average $13K ($24k max / 7k min) from their user-base.\nThe question then arises, how can we do our share for the projects we work with? (by \u0026lsquo;we\u0026rsquo; I mean both Pine Microsystems and PINE64 community). All of PINE64 hardware relies on community software and third-party projects, but the one piece of hardware that is solely supported by third-party projects is the PinePhone. Since the PinePhone is an experimental project in its own right, we decided to also make it a testing ground for an idea we\u0026rsquo;ve had for some time now. From the very start of the PinePhone project we were clear that we wish to work with existing and well established Linux-on-phone projects. This decision stemmed from a firm belief in these projects competences and our ability to deliver a true FOSS phone. To this end, we have now made the decision to relay all revenue from PinePhone sales to the development community and third-party Linux-on-phone projects. In doing so we hope that, on the one hand, this will help Linux-on-phone projects grow and prosper, and on the other, entice developers to commit their time to PinePhone development.\nBefore proceeding let me just state the following: if this model works, and all parties involved are happy with it, then it is likely to be implemented for other similar devices in the future.\nHow it\u0026rsquo;ll work Unlike many of PINE64 products that bring in no revenue (for instance, the Pinebook and Pinebook Pro) the PinePhone has an \u0026lsquo;in-built\u0026rsquo; profit of ~$10 per unit. I provide the USD value as an approximation due to fluctuations of component prices and other market variables which there is no control over. It is exactly the $10 sum, per unit sold, that we wish to donate to the partner projects working on the PinePhone. Just to make it clear, the $149 will always be the final price for end-users and no-one will be asked donate money. As it were, we\u0026rsquo;re making the donation on your behalf.\nWe seek to make financial contributions in two ways. Please note, that only PinePhones sold in the PINE Store will be subject to the points below:\n1) Via OS promotion campaigns (large).\n2) Allowing users to indicate directly which project they wish the money to go to (small).\nLets start with the first of the two options. Once a partner project decides that an OS build for the PinePhone has been completed, and we too are satisfied with the OS image, then an entire PinePhone production run will be flashed with the OS build in question. We may also end up customizing the PinePhone for each campaign with project-specific phone\u0026rsquo;s covers, as well as include the project\u0026rsquo;s stickers, etc., so as to make each campaign truly feels OS-specific. Lets say, to make the math simple, we produce a batch of 1000 PinePhones for one of the projects. So, with 1000 units sold, the donation made to the project will amount to USD $10,000. Depending on the project size, its existing install-base of users, as well as general level of interest in the PinePhone, these batches may be significantly larger or smaller. Let me also assure you that we will ensure that the entire process, from start to finish, is both clear and transparent to the end-users making the purchase during the campaign period.\nThe second way in which we wish to contribute to partner projects is by giving you - the end-users - the option to indicate which Linux-on-phone project should receive the $10 from your PinePhone purchase in the PINE Store. Each partner project will be assigned a code that you\u0026rsquo;ll be asked to key in (if you so choose) when completing your PinePhone purchase. To make the process completely transparent, and so that there are no speculations about how the system works, we will likely list the help of community developers to build it. The source for the system will, subsequently, also be uploaded to github or gitlab for anyone to view, study and alter (if need be). But what happens with the $10 if no project is indicated at check-out? - the answer is that the money will go to a PINE64 community fund. This will allow us to help send community members to conferences, support community initiatives and activities, and much, much more. There is more: contributing to closing the digital gap But wait! there is more. We are also making our contribution to closing the digital gap - a term used to describe the inequality of access to a computer, internet and technology of underprivileged individuals or groups. It may be inconceivable to many of you, but access to a computer, to secure and sophisticated software, as well as the Internet remains a privilege of less than half of humanity. And the number of children with regular access to a computer worldwide is just a measly 19%. While not as important as access to fresh water, food, shelter or electricity, access to a computer has a substantially positive effect on individuals and thus also the communities they inhabit. A recent UN report has outlined that providing school-age children with a computer correlated directly with improved literacy rates, access to further education, financial independence (particularly important in the case of girls and young women) and perhaps most importantly safety (in many less economically developed countries, children access the internet and do homework at internet cafes. Travel to-and-from the internet cafes, as well as the cafes themselves, frequently exposes children to potential danger).\nEnter the Pinebook - an ideal laptop for distribution as an aid in closing the digital divide. It is inexpensive, sturdy and durable as well as simple in design, which effectively means that it can be repaired by anyone with limited resources. All that is needed to access the Pinebook\u0026rsquo;s internals is a Philips screwdriver, and in the event of a component failure spare parts can be had for a very small fee. Moreover, despite its low cost, the Pinebook has all the basic networking and connectivity one would require for basic tasks, allows for a wide array of software to run on it, has a very long battery-life as well as reaps all the benefits of running open source software.\nHow will this be achieved? Our commitment to closing the digital gap will start with the PinePhone launch. There will be two types of covers available for the PinePhone in the PINE Store - a soft rubber cover (likely transparent) and a hard plastic one. The following refers to the soft covers sold in the PINE Store only. The final pricing for the cover isn\u0026rsquo;t set in stone yet, but I expect that it should be in the $10 range. All revenue from this soft cover will go to a only sole purpose: funding Pinebooks used in our initiative to help close the digital gap. The math is simple, but let me outline it anyways; 10 soft PinePhone covers sold in the PINE Store \u0026lsquo;buys\u0026rsquo; one Pinebook for someone in need. You get your PinPhone cover and someone in need gets a Pinebook, what\u0026rsquo;s not to like?\nHow will you decide whom to send the Pinebooks to? We intend to make this a community process. Details are still being worked out, but I envision having community members submit suggestions for people and places, charities and institutions, existing projects dealing with the digital divide, etc., that would either directly benefit from using Pinebooks or help with their distribution. In time there may be an advisory body consisting of PINE64 community members as well as notable people from the broader Linux community, whom will be tasked with weighing in on the proposals and put them to a vote. We\u0026rsquo;ll see how it goes. If you have any suggestions regarding this subject matter then please make sure to share your thoughts in the comments section. Lastly, if you are a developer or represent an existing education-focused project, and would like to tailor an OS build for the Pinebook then make sure to get in touch with me.\n","permalink":"/2019/08/19/its-time-to-start-giving-back/","tags":["community","digital-gap","sustainable-foss"],"title":"Its time to start giving back"},{"categories":["news","pinephone","pinetab","soedge"],"contents":"\nPineTab development prototype\nJuly has been a busy month for all members of the PINE64 project. Between the updates to various systems, preparation of Pinebook Pro pre-orders and the subsequent launch, shipping of PineTab development kits as well as production of the PinePhone prototype, there has been little to no downtime. To this end I wish to publicly thank fireTwoOneNine for doing a hell of a job helping out, troubleshooting problems and setting up the systems necessary to keep the wheels turning. An awesome job and a huge thank you. Here is what is on this month’s update agenda: We’re meeting up in London - join us! Just the Wiki left to do - help wanted PineTab is up and running! ; getting an illuminated keyboard Pinebook Pro pre-orders sum-up ; public pre-orders 25 August PinePhone prototype this month ; software coming along SOEdge AI module Meetup in London We’re having a casual meetup in London on August 18, noon (12:00) at Serpentine Bar \u0026amp; Kitchen located in Hyde Park. We’ll have a few things with us (including a Pinebook Pro prototype) to show and toy around with. We will also share information about new and upcoming devices at the meetup - as always we’re very keen to hear your feedback regarding what we’re doing. If the weather is good then we can sit outside in the sun; it not, well, then we can sit inside and later head out to the closest pub. So if you live in London, or otherwise able to make the journey, then we’re looking forward to meeting you in person. Everyone is welcome. Housekeeping In June I wrote that the next things on our community to-do agenda are the chats and Wiki. Let\u0026rsquo;s start with the prior - we have now improved the way in which the various chat protocols are bridged and, after a few hiccups, everything seems to be running smoothly *knocks on wood*. There are now also Telegram groups for Pine64, Rock64, PinePhone and Pinebook (Pro) that have been linked to their Discord, IRC and Matrix counterparts. They’ve been added the the community tab on the website. In a nutshell, you now have more ways to communicate with each-other and it\u0026rsquo;s all interlinked in a neater way. If you haven’t joined in as of yet, then consider doing so as much information shared in the chat never reaches the forum. Onto the subject of the Wiki. This is the last item on our community ‘fix-and-improve’ itinerary, and something that has been in the back of my mind for well over a year. Similarly to many other things in the PINE64 project, the idea behind the Wiki is that the community runs and maintains it. Whilst handing over control of much of the project to the community - the website, forum, chats, etc., - has been a great idea and success, this approach has not worked equally well for the Wiki. This isn’t to say that people have not contributed, because there have been numerous contributions, but it has become evident that a long-term and sustainable strategy needs to be put in place. A community member - zaius - has taken it upon himself to organise a group of a few people to accomplish just this. If you’re interested in helping out then make sure to reach out to him directly on the forum (and CC me in PMs please). The PineTab is up and running! Let’s talk about the PineTab, which I feel is the one device that hasn’t gotten the exposure it deserves thus far. In this update I will make an attempt to rectify this, especially since I thankfully have nothing but good news to convey. This month developers from partner projects received their PineTab kits and it didn’t take long before the first demo images became available for testing and showcasing functionality. As is always the case, we have already gotten a lot of valuable feedback from developers in regards to both electrical and mechanical issues with the dev-kits. We will collect and convey all the reported feedback to the factory so that everything is ironed out before the PineTab ships to end-users. Speaking of shipping, apart from the handful of reported shortcomings, the hardware is coming together nicely and we’ve already locked in the key specs weeks ago. At this point production could start any moment granted a suitable OS image becomes available; I’m discussing software progress further down in this post. As we announced in June, a number of upgrades have been made to the PineTab since the February unveiling - this includes a larger 64GB eMMC capacity (voted on by the community) as well as an optional M.2 key adapter that can be used for LTE or storage. I expect that the potential to mount a LTE module is of particular interest to many users on-the-go. I am including pictures of the PineTab with a M.2 SATA drive and LTE module mounted in the case. LTE\nM.2 SATA\nBut this isn’t the end of improvements made to the device and peripherals. We’re pleased to announce that the keyboard (which you probably should get) - that also doubles up as a cover for the tab - will ship with a backlit ANSI-layout. We’re still figuring out the details, but it will likely be customised in accordance with the feedback we received for the Pinebook Pro. The quality of the fabric on the keyboard/ cover has been improved as has the key spacing, making it both more durable in transport and comfortable to type on. I trust that this is a welcome upgrade for those eagerly awaiting the PineTab since input quality is clearly at the very top of the priority-list of PINE64 user-base. PineTab New Keyboard\nAnother yet unannounced PineTab upgrade that we’ve recently made is a spec bump of the battery. The PineTab page currently lists a 4500mAh battery but we’ll be shipping the PineTab with a 6000mAh battery. This is the maximum size of a single slab (cell) produced, and using more than one slab is out of the question as we need to keep some space inside the case free for those who will be mounting M.2 storage or LTE inside. As you can see from the pictures above, there isn’t much space left inside the case with LTE or storage mounted. While the PineTab may not reach the 10 hour battery life of the original Pinebook, with its lower screen resolution and smaller display size I still expect that the battery-life to be in excess of 6 hours of continuous run-time. The battery can be charged in two different ways: via the standard barrel connector or the micro USB port. While charging via micro USB is not ideal under normal circumstances, since it is relatively slow, it is a major bonus because it makes it possible to charge the device from a powerbank. These features combined with the small size and versatility of the device will make it a good travel companion - something you may wish to take with you on long flights or treks in the wild. On to the software; there are quite a few images already available and, thanks to all the development that has gone into the Pinebook and the PinePhone, they are already very functional. There are already postmarketOS, AOSC, Manjaro, Ubuntu Touch, KDE Neon and numerous other OS images being worked on - many of which are being developed alongside Pinebook or PinePhone OS images. As a result, I expect that software support for this device will be solid on launch day, and it will benefit from both the Pinebook (desktop-oriented) and Pinephone (touchscreen oriented) OS and front-ends. The ultimate goal is to have many options for the PineTab, so that those who primarily wish to use it as an ultra-portable laptop and those who actually want a ‘tablet-first’ device have a range of options. That said, we’re currently still waiting for one feature-complete OS image that the PineTab can ship with. Different OS images and front-ends\nI was really excited to see Martijn Braam from postmarketOS demo the PineTab running a build with the Sway window manager. Watching the video gives you a sense of the sort of interesting experiments that such a laptop-tablet hybrid device opens up. You can see Martijn use the trackpad and keyboard for the usual window manager and terminal stuff, and then switch to the touchscreen to interact with web pages in the browser. Obviously the Sway WM may not be a natural nor a perfect fit for the device, but the option is there for those who only occasionally need the touchscreen functionality and love tiling managers. Moreover, looks like Sway will be getting touch navigation buttons on the top bar, gesture navigation and a virtual keyboard in the foreseeable future - making is a real option. Let’s face it, if tiling WM experience can be enriched by the touchscreen then every other scenario I can think of - perhaps with the exception of running a raw Bash shell - is almost certainly viable. Martijn also has a video showcasing Phosh shell running on postmarketOS. It is very cool to see a work-in-progress front-end crossover from another great FOSS project. I have also seen KDE Plasma and plasma mobile running on the device; I am linking the relevant media below. https://www.youtube.com/watch?v=-ZG0eBRzSBc\u0026t=1shttps://www.youtube.com/watch?v=FFgKjJYHfas\nPinebook Pro pre-order launch I spent all of last month’s update on the Pinebook Pro so I’ll keep this section short. Although the pre-order launch was not exactly problem-free, I feel that it went pretty well overall. Initially a bug in the database prevented people who either signed up to the forum or changed their password since late May 2019 from being accepted for a pre-order. This issue was quickly traced down and rectified (it took 40 minutes from the first report of issues to system being fixed) and, to the best of my knowledge, everyone who wanted to receive a pre-order confirmation eventually received an acceptance email. I’ve also received reports that some users, who already received their purchase-coupons, ran into issues with completing their order after selecting additional accessories such as the NVMe adapter - this has now been resolved.\nI understand that the various little problems have proven frustrating to some of you, and I appreciate that it made the process less than perfect. What I will say, however, is that one of the reasons we chose to open pre-orders to the community first is so that our system could be properly tested on a smaller scale first. We’ve now learned from the launch and have ideas to further improve, streamline and simplify the pre-order system in the future. Since a similar system will likely be used for future products too, this pre-order launch effectively made for a test-run of long-term system viability. To this end, I thank those of you who signed up for pre-orders - knowingly or not, you’ve helped improve the experience for others in the future.\nI sincerely hope those of you who receive the Pinebook Pro next month will take the time to actively offer feedback and help us address any potential shortcomings. Meanwhile, we’ll be opening pre-orders to everyone outside of the forum on August 25th. We expect that there is a fair amount of interest in the Pinebook Pro outside our core community and cannot wait to welcome new members into our ranks. To those community members still on the fence, deciding on whether you want a unit with 128GB eMMC: please be aware that the community member pre-orders close on August 24th. This means that from this point on only 64GB eMMC Pinebook Pro models will be built. (Note: For those wondering about when their coupons will be emailed-out and units will be shipped, keep up to date with this thread.)\nPinePhone - here is what\u0026rsquo;s happening I expect there to be a lot of news about the PinePhone in coming weeks. If all goes well then in the next news update we’ll be taking a look at the PinePhone prototype and, granted its functional *knocks on wood*, we’ll be seeing it boot for the first time. But since my crystal ball has been malfunctioning as of late, instead of talking about the future, let’s instead focus on the things that are happening now. For starters, some developers have now received revision (2.0) of the PinePhone development kit. It fixes all of the issues that were present in previous iterations of the kit and aligns the functionality with the actual phone. We expect this to be the final revision of the board, but we will likely be replacing the touch panel on the kits and the actual phone, since the current one is giving developers grief. To consolidate things, and make development easier, we will use the same touch panel driver as the one implemented on the PineTab; we haven’t heard any complaints about the driver from developers and it clearly is superior to the one currently used on the PinePhone dev kit. To the layman, the most important feature of the dev kit 2.0 is its capability to output video via USB-C, but there are many other tweaks that improved the operational stability of the setup. For all intents and purposes, this is just an evolution and not a revolution, and developers can happily keep on using the older development iterations until the actual phone ships. I’ve already mentioned that the prototype is being built and this is progressing well without any major setbacks. We were initially hoping to get a chance to show it off during the London meetup and get some live feedback from attendees, but due to a relatively minor delay (we’re some ~2 weeks behind schedule) it\u0026rsquo;s unlikely that we’ll have it with us. Regardless, the production of the prototype is a crucial milestone and you can take a closer look at how all the bits-and-pieces will be jigsawed together in the pictures below. PinePhone Jigsaw\nOnce the Prototype is done it will have to undergo proper testing, which will take some time. Once all the testing has concluded we’ll have a better idea of when the first batches - aimed at developers and enthusiasts - will start shipping. We’re confident that it will be in early-to-mid Q4 this year. We’re currently evaluating and thinking about how to best launch the device so it only gets into the hands of those who are completely aware that they will need to deal with numerous OS teething pains until the software matures. Before someone points it out, I understand that this means we’re going back on what we initially said, namely that “(\u0026hellip;) the PinePhone will first ship when software is ready (\u0026hellip;)”. The reality of the situation, however, is that advanced users want to get their hands the PinePhone, and we don’t want it sitting in a warehouse until end-user level performance is achieved. I am still hoping that we can have at least one solid OS on day-one, and seeing how fast progress is made in recent weeks, I think that there is a possibility for at least an image or two achieve core functionality by production time.\nAs I have said in the past, I am not the best person to evaluate or report on software progress, but even with my limited understanding of the development complexities, I can tell that much is happening and progress is made. For those who do not follow the chats on a regular basis here is a quick run-down of what has been happening with the PinePhone for the past few weeks: There is now a relatively error-free postmarketOS plasma mobile build for the PinePhone. In the past, applications would not run and many of the UI elements that ought to be opaque were transparent. There are still performance issues with the build - the UI, despite being accelerated, is slow to respond (potentially something to do with shaders) and the touch screen is somewhat laggy. But as you can see below in the linked video, this is starting to look pretty good. We’ve also had our first look at Sailfish OS running on the PinePhone. The short demo shows the UI being quite responsive when entering and exiting the settings app, and scrolling though the different options seems very smooth as well. From what I can tell a lot has been done in the graphics driver driver, in this case Lima, to make this possible on mainline. I can only report on these information snippets due to time constraints and my insight. You can follow development live in the chats.\nOne last thing - as promised, we will have all the documentation about the PinePhone available just before the launch. Since we announced that we’ll be exposing I2C via pogo pins on the PCB (refer back to the blow-up diagram) many have expressed interest in 3D printing and otherwise making back-covers to use the interface. To this end, we’re releasing the back cover .stp file for you start planning or creating your add-ons for the PinePhone.\nPlasma Mobile (pmOS)\nUbuntu Touch\nPhosh (pmOS)\nSOEdge AI Module This is more of a teaser than a full blown announcement. As I have hinted in the June community news update, we have been toying with the idea of an AI module for some time. In fact, we initially intended for an AI variant of the RockPro64 but decided against it due to delays of the RK3399Pro SOC. Since we initially set out to create a RockPro64 AI a more feasible alternative arose, namely the option of creating a stand-alone AI module that can work independently or in conjunction with an existing SBC via fast I/O. The SOEdge neural module is based on the RK1808 and comes in a standard SODIMM form factor that it shares with the SOPine. It features 2GB of DDR4 SDRAM, 128Mb of SPI-NOR Flash as well support for eMMC. We have taken great care to ensure a high degree of compatibility between the SOEdge and SOPine peripheral/ baseboard compatibility. In result, the new module can be used with the SOPine baseboard (N.B. the SOEdge doesn’t have digital video out functionality, so the digital video out port on the baseboard will not function) as well as the Clusterboard. We also intend to create a SOEdge-specific baseboard as well as PCIe and USB 3.0 adapters for it, so that it can be paired with the ROCK64 via USB 3.0 or the ROCKkPro64 using PCIe. We have spoken and worked closely with Rockchip and they’ll be open-sourcing all the relevant source code and documentation related to the SOEdge. I will be returning to look at the SOEdge, as well as other things we’ve been working on behind the scenes, at a later date when the software is up and running and there is something to showcase. SOEdge in SOPine Baseboard\nSOEdge AI module\nThere is a lot more news coming and I cannot wait to share it all with you next month. That’s all for now - you know where to find me if you want to have a chat.\n","permalink":"/2019/08/05/august-update-london-meetup-pinetab-news-soedge-and-more/","tags":["ai","pinephone","pinetab"],"title":"August Update: London Meetup, PineTab News, SOEdge and More!"},{"categories":["news","pinebook-pro"],"contents":"\nAs I’ve mentioned in last month’s update post, the PinePhone prototypes are currently being manufactured (due in August) and the PineTab dev kits are rolling off the factory line to be shipped out to developers. With both the PinePhone and PineTab currently in-transition to their respective next development stages, I’ll devote this month’s update solely to the Pinebook Pro pre-order announcement, the last unannounced feature of the laptop as well as a hardware and software status update. There is plenty to get to so let\u0026rsquo;s run though the points. Bullet points: Pinebook Pro pre-orders start July 25 Pinebook Pro gets privacy switches Pinebook Pro OS builds Battery life \u0026amp; ‘magical’ kernel PINE64 key cap Pinebook Pro pre-orders start July 25 [edit] 26/07/2019\nThose asking about the pre-order system, coupons and shipping timeline please read the following forum threads:\nhttps://forum.pine64.org/showthread.php?tid=7725\nhttps://forum.pine64.org/showthread.php?tid=7752\nThank you!\nThis is the announcement many of you have been waiting for. The Pinebook Pro production has been green-lit and pilot batches have been scheduled for production. With the remaining hardware issues identified and resolved (side-note, huge thanks to the the key devs - ayufan and MrFixit - as well as the community for all the help sorting things out!), we’re now feeling confident that we can to proceed full steam ahead. A countdown for Pinebook Pro is now live and ticking away, so no one PM or email me saying they didn\u0026rsquo;t know or hear about it - this is plenty of heads-up time. If you follow us on Twitter, Mastodon, are a member of the forum, check the web-page or read the Linux press regularly, then you’re unlikely to miss the moment the pre-order system become accessible.\nAs we’ve promised from the very start, community members who registered on the forum prior to July 1, 2019 are eligible for a 128GB eMMC upgrade as well as pre-order priority. The eMMC capacity upgrade is a limited-time offer, available only for the first batch of Pinebook Pro laptops. I’d also like to include a quick word of caution; pilot batches are aimed at enthusiasts. We do diligent testing of the hardware and create numerous prototype iterations to make sure that we deliver the best possible product on launch day. However, we cannot emulate thousands of people using the device, it is simply not possible, and as a result minor issues (usually fixable with some tinkering) may be present in the pilot batch. If you’re not the sort of person who likes to actively engage in development or issue-solving, or simply is not willing to take the risk, then it may be a good idea to wait for the second or third batch. I am not saying that issues are expected, but it\u0026rsquo;s the nature of pilot batches that they are effectively a chance for us to get feedback on the hardware from a large sample of users. I thought I\u0026rsquo;d get this out there are there is a lot of interest in this device.\nLastly, I realize that making a purchase decision is often dependent on what reviewers and notable individuals from the Linux world say about the product. Since reviewers will be getting their Pinebook Pros at the same time as end-users or even later, I figured I’ll reach out to the relevant people in my neck of the woods and give them hands-on time with the prototype. Now, I obviously cannot make anyone cover the Pinebook Pro, nor do I want to make it sound like it is an expectation on my end, so I am leaving the names of the people and their shows out of this post if they choose not to talk about it. But keep an eye out (and an ear out - is that even an expression?), since some of them may decide to discuss their experience with the prototype online.\nPinebook Pro Privacy Switches Privacy switches on the Pinebook Pro are the last unannounced feature I was dying to talk about for some time now. I had to hold back my excitement and keep my mouth shut because we first had to make sure that our implementation of the switches would work reliably and as intended. The reason we kept this information back wasn’t to be secretive, but rather not to disappoint you if the implementation wouldn’t pan out and the Pinebook Pro would ship without this feature. With that out of the way; we’re very pleased that the implementation worked out because we’re very well aware that a part of the draw of the Pinebook Pro is its core FOSS nature, which means respect for both users’ choice as well as privacy.\nBack to the subject at hand. There are three privacy switches mapped to the F1, F2 and F3 keys on the Pinebook Pro keyboard. They deactivate the following: 1) the BT/WiFi module; 2) the webcam; and 3) the microphones. I’ll give you a broad overview of how the switches work and answer the inevitable questions about their security. The keyboard has a special firmware that lives on, and operates separately of, the operating system. In a nutshell, it detects if F1, F2 and F3 keys are pressed for 10s. Once one of the keys get pressed for the set duration, the keyboard firmware cuts power to the chosen aforementioned peripheral. The implementation is no different to cutting a peripheral power mechanically via a physical switch, and the power state settings for each is stored across reboots.\nThis is privacy switch implementation is highly secure since the firmware that dictates if peripherals get powered is not a part of the Pinebook Pro’s operating system. The power state value for each peripheral also cannot be overridden from the operating system. In fact, the keyboard firmware itself cannot be accessed from the operating system. I have been told by a hardware engineer that, under particular circumstances, this particular privacy switch implementation may be safer than mechanical switches. If you’re really tech-savvy, and want to know how the firmware works, then I am afraid you’ll have to ask someone smarter than me (which means pretty much everyone in our IRC / Discord); I may get someone technical to write up a short piece about the privacy switch implementation if many of you request it specifically. So there you have it, the Pinebook Pro is a FOSS laptop with privacy switches built from premium components that now also features privacy switches for peripherals relevant to security and privacy. Freedom of choice and openness has always been a core tenet of our projects, and now with the Pinebook Pro and PinePhone we’re starting to tackle the other vital component that the community cares about - the privacy and security hardware features. Pinebook Pro OS choices on launch day I expect that there will be three OS types available for device on day one: 1) different flavours / distros of Linux (discussed in past month’s update); 2) Chromium OS; and lastly 3) Android 9. Two quick notes before we proceed, firstly I’ll skip discussing Android in this update as I expect few people care about or/and want Android on a Laptop. I just wanted to let people know that there is a build for it and it works. Secondly, you probably already spotted the notable absence of *BSD on this list. This is largely our fault, stemming from the philosophy we adopted for building up early software support for the Pinebook Pro. That said, we cannot wait to see *BSDs on the Pro once it gets into developers hands. Linux Let’s talk a bit about the state of Linux for the Pinebook Pro. As far as Linux on ARM development goes, I can say with confidence that we’re in what I like to call the luxury territory. What I mean by this is that everything works - some things better than others, but it’s all there - and there are no deal-breaking issues in any of the builds. Developers have effectively moved from ‘making things work’ to ‘making things work better’ in the past two months. Improvements are literally done daily, if not hourly, and everything from desktop acceleration to trackpad settings and battery-life is being continually tweaked. Regarding the custom Debian build that will ship with the Pinebook Pro - at the time of writing we still have about two weeks to continue tweaking things so they work their best. You will, of course, likely want to hit the update icon when you get your laptop, which will update the kernel and numerous other things, as well as run your regular apt updates and upgrades. Let me reiterate very quickly on the state of the Debian build that will ship with the Pinebook Pro. It features an accelerated Mate desktop, allows for 3D applications and you can play back videos locally up-to 4K at 30fps. Youtube as well as Netflix and Amazon playback work well at 1080p resolutions in the Chromium browser. Video out via USB-C works flawlessly too, so you’ll be able to use the Pinebook Pro for presentations, media, etc., For the record, the very same functionality is available in ayufan’s Ubuntu with Mate image, which also runs on the RockPro64, and can be downloaded directly from his github. At the risk of repeating myself, by the time you receive your Pinebook Pro there may already be other alternatives from partner projects; if not at launch then soon thereafter you’ll surely see the Pinebook Pro supported by the usual suspects (and newcomers to PINE64 hardware realm we’ve been talking to as well!). The one piece of functionality that we’re still working on is charging via USB-C - it works, but requires a very specific mode of charging at this time. We hope to improve this by the time the first units ship to end-users. I’ll make sure to update everyone on the state of this matter in due time.\nLet’s talk battery-life. Developers are currently working at getting the optimal values for the battery into the device tree. In result we will need to wait a little bit longer to have a full picture of how well the battery performs during daily usage. That said, cool things have been done to improve battery life on the kernel level. MrFixit2001 has managed to make the governor monitor activity, so that not only does it set the frequency of the cores but also automatically turns the cores on and off on a need-be basis. We expect that this will see a significant improvement to battery life as well as thermals whilst having a relatively small impact on performance. From my testing, relative to all cores being active and the default interactive governor settings being applied, running webGL demos and playing simple games the observable performance difference is really negligible (for reference, 5 FPS difference running Aquarium WebGL demo). This is a very cool trick and one will be further improved upon and find its way into the majority, if not all, OS’ for the Pinebook Pro. Lastly, I think its worth noting that you can also turn individual cores on and off manually from the userspace for cores cpu0-5 (exchange value for X), which comes in handy if all you\u0026rsquo;re doing is terminal work or taking notes in class: echo 0 \u0026gt; /sys/devices/system/cpu/cpu0/online. This applies to all current Linux builds.\nChromium OS Some of you will probably write Chromium OS off as a daily-driver option, whilst others will be excited about it. Regardless of your personal views on the subject matter, there is no denying that having the choice to run it on the Pinebook Pro is a great option to have. Speaking of running Chromium OS, I cannot stress enough that the OS runs absolutely great on the Pinebook Pro. Even this early release is exceptionally smooth. There is no denying that ayufan has done a heck of a job, in a short amount of time, getting this build shipshape. For those of you who have a RockPro64 - you can already download and try it out. For the most part everything in Chromium OS seems to ‘just work’ on the Pinebook Pro; movies (online and local) play perfectly smoothly, 3D applications are perfectly responsive and the few web-apps I tested ran as they are supposed to. The build also comes with at Linux VM, which can be enabled under the settings menu. This allows you to install and run regular Linux applications on Chromium OS pretty much as if they were native Linux applications. So if you don’t want to use Google Docs, you can always install LibreOffice as you’d do on any Linux laptop. Apart from occasional and very minor glitches the build is highly usable and exceptionally polished. If you have kids in school in Europe (or US/Australia), or other places were a lot of schools use Chromebooks as default teaching devices, then the Pinebook Pro may just be something to consider. For starters, it’s sturdy enough to be tossed carelessly into a school backpack and even slammed down on a desk now and then … not that I recommend it. Secondly, once your child outgrows Chromium OS and will want to explore a bit more, you can just load up a Linux distro for them. Not to mention that you’d be supporting a small FOSS company rather than one of the many large Chromebook manufacturers. I trust this comes across as a genuine idea to consider and not a sales pitch, for it is not. A quick note on *BSDs So I said I won’t be talking about the BSDs, but I feel like I should at the very least give you a general overview of the RK3399 *BSD functionality. I’ll make it quick. I’ve spoken to *BSD devs whom worked on the RockPro64 and from what I’ve gathered (despite the different *BSDs having varying degree of support for the RK3399 SOC) many of the core features are already supported, which bodes well for *BSD on the Pro. That said, some of the things you’d require on a functional laptop - such as the LCD (using eDP) for instance - will not work on the Pinebook Pro using *BSD as of today. So clearly a degree of work is yet needed for a BSD to run on the device. However, keep in mind that *BSD developers will be receiving their units soon and by the time you receive yours some basic functionality may be available. PINE64 logo on Pinebook Pro key cap It never ceases to amaze me how passionate people can be about the stuff were doing. Before I get to the meat of this (admittedly very minor) story, let me give you some background. There are two factors that underpin it and explain its origin; the first of which is that I genuinely do not like the hamburger (three horizontal lines) menu icon on the regular Pinebook. Sure, it\u0026rsquo;s better than having a Windows key cap, but it just seems very impersonal to me. The second factor stems from feedback in a recent OMG! Ubuntu! Article relating to our choice to not brand the Pinebook pro, that I’ll quote here:\n“Although this is a nice move [not to brand the Pinebook Pro] on Pine64’s part, it’s also a little sad. The company is busting their posteriors on all this tech, so it’d be nice to see their efforts rewarded with a bit of awareness.” Now to the meat of the story. With the two aforementioned factors in mind, I threw out a question in the chat the other day asking people if they think that a PINE64 pine-cone logo would be a good substitute for the current menu icon. My thought behind this was to see if we could have this tiny piece of branding on the device and at the same time potentially improve the functionality of the key. I tossed the question out and went to make myself a cup of coffee. When I returned to my computer screen I was greeted with backlog of dozens of replies. As it turns out, people really do care about how their keys look and what they do. The overwhelming majority of people welcomed the idea of the little PINE64 pine-cone logo on the key cap and, as is the case when you ask a thousand people about their opinions, offered up many different ideas as to what the key cap can do. As things stand, I am happy to say that the menu logo will be substituted by the PINE64 logo, but it will take us some time to figure out its final functionality. If you have ideas of your own, make sure to post them below or on the forum.\nThat wraps it up for this month’s update! [edit July 16, 2019] Finally had some time to sit down and give a short, unstructured, overview of the build that will ship with the Pinebook Pro. I know that many of you have asked for another video detailing how the Pinebook Pro performs in a real-life scenario, and I feel this is a pretty fair representation of what you can expect.\nhttps://www.youtube.com/watch?v=F-Yh8uiA2TY\u0026t=0s\n","permalink":"/2019/07/05/july-update-all-about-the-pinebook-pro/","tags":["news","pinebook-pro"],"title":"July Update: All about the Pinebook Pro"},{"categories":["entertainment","sopine"],"contents":"\nThe higher end alternative to the PRIMO, the MOTIVO, will catch your eye and ear. It is powered by the FOSS audiophile Linux distribution - Volumio - that is aviable for many Single Board computers, including the PINE A64-LTS and the ROCK64.\nFrom our point of view, the technology inside the MOTIVO is what makes it stand out, although, we can\u0026rsquo;t argue with its great looks. Powered by a SOPine module, the Volumio Motivo is a true fusion of form and fucntion, and a brainchild of a Joint Venture between world-class industrial design firm Design Narratives and R\u0026amp;D and audio design Company Yottamusic.\nYottamusic has been working for 10 years on their the core-technology which is now in the Motivo: METACLOCK.\nThis Technology has 3 core principles:\nDo not use a generic SOC (which handles communication with the DAC) Use an interface that, other than USB and I2S allows faster data transfer Use a dedicated FPGA to handle communication with the DAC. Therefore emancipating the Audio Quality outcome from the OSCPU combination. It works this way:\nThe audio stream is sent from the A64 SOC via a high-speed BUS (SDIO) to a dedicated FPGA Here the stream is reclocked via a double buffer and stored on a high-speed memory It’s then sent, at the right moment to the DAC The results that it brings:\n104dB THD+N 110dB SNR Jitter: 200ps Maximum Network data correction This means that with Metaclock technology, Volumio Motivo is able to achieve outstanding sound quality performances without the need of esoteric (and expensive) designs, following Volumio\u0026rsquo;s core principle: the best possible sound quality with an unbeatable priceperformance ratio.\nIntegrating Metaclock technology is being probably the biggest challenge Volumio Team has faced so far: since this technology has never been done before, in this way, there is no standard to follow nor any HOWTO nor literature. Work is currently being done to implement the very complex software integration to take the most out of this technology, without compromising on usability.\nBack of the Motivo showcasing the wide IO array\nMotivo front featuring an 8\u0026quot; EPS Touch Panel and control knob\nFor those of you craving for technical specifications, here they are:\n8” EPS touch panel allowing for great viewing angles without glare. Mounted digital volume control knob that also dubs as on/off. All Winner A64 chip optimized for audio with low noise carrier band. Wide bandwidth SDIO bus ideal for media transfer. On board FPGA for noise and jitter elimination. On board ESS Sabre 9038Q2M DAC. Bluetooth 4.2 PCM and DSP 1024 compatible. Audio Outputs:\nRCA Balanced XLR Optical Coaxial HDMI I2S USB 2.0 Peripherals:\nGigabit ethernet Dual USB 2.0 (input/output) HDMI 1.4 video for user interface display 9V/3A barrel power jack To learn more about Volumio Motivo make sure to subscribe to the Volumio Blog\nVolumio Motivo was unveiled at High-End in Munich, Germany last month.\n","permalink":"/2019/06/10/volumio-motivo-a-foss-audiophile-experience/","tags":["audioplayer","motivo","volumio"],"title":"Volumio Motivo: a FOSS Audiophile Experience"},{"categories":["news","pinebook-pro","pinephone","pinetab"],"contents":"\nBullet Points: Forum is done, next up: chats and Wiki PinePhone prototype in August ; software coming along ANSI keyboard for Pinebook Pro ; new features / upgrades ; pre-orders this summer PineTab M.2 optional adapter ; 64GB eMMC ; pre-orders this summer New boards in the pipeline ; AI SBC/SOM of interest to us Housekeeping As many of you have probably noticed the forum has gotten an update. We’re still tweaking things now that the new layout and features are live, and we’ll continue to monitor your feedback and update things on a need-be basis. With the webpage and forum done, the chats and Wiki are next on our agenda. Both of these undertakings present their own set of challenges, hence may take some time to complete. If any of you wish to volunteer your time, especially with regards to improving the Wiki, then please let me know in the comments section below or the forum. Thanks!\nPinePhone Last month I began with (and spent most time on) the Pinebook Pro, so it\u0026rsquo;s just fair that I open this month’s update with the PinePhone news section. A lot has happened in the short period of one month, so the best I can do is to try to summarize the most important aspects pertaining to hardware and software progress. I’ll pay more attention to hardware developments in this post, simply because I am not competent in providing an up-to-date report on every projects’ software status (you can reach all the devs in the chat and follow the progress live using the chat log if you wish to stay up-to-date). For what it\u0026rsquo;s worth, I am happy to give you a short resume of my experience with the few OS images I’ve tested at the end of this section.\nLet’s start with the end-user PinePhone developments. With the case selected and approved, the phone’s PCB was commissioned a couple of weeks ago and submitted to the design house with detailed instructions on the required feature set. The first of the things we settled on was the battery capacity and physical dimensions; the battery will be the same capacity as the Samsung J7 SM-J700H/ BJ700BU (3000-3400 mAh), which can be had for under $10 from amazon and eBay. So in the event you need replacement or spare batteries, getting hold of them will be easy and affordable. We also settled on the number, and the implementation of, privacy switches on the phone - there will be 4 switches in total: for the i) BT/Wifi module, ii) the modem, iii) cameras (front/back) and iv) lastly for the microphone. They will be located on the PCB, under the back-cover, to prevent them from being toggled by accident, e.g. in your pocket or purse.\nAfter a chat with developers, we also came up with a way to expose I2C using 6 pogo pins. These pogo pins will be located directly on the PCB. The idea behind this implementation is that entire back-covers with add-on components can be created (even 3D-printed) with additional functionality to enrich the phone’s functionality. The implementation only requires that the custom back-cover with additional hardware has the same dimensions and position of plastic latches as the original - and obviously that the component in question uses I2C (contact pads). I expect that a back-cover with a keyboard - perhaps one similar to that found on the Nokia N900 - will be something a considerable number of people may be interested in creating. To this end, we’ll make sure to have detailed documentation on this feature. I really hope that the hackers and tinkerers among you will embrace and make use of I2C for new cool implementations.\nMainboard Front\nMainboard PCB Back\nSlaveboard PCB\nRounding off the hardware-side of things - I don’t want to jinx it, but as you can probably tell from what I’ve already written, the PinePhone project is coming together really nicely. As things stand today, we expect a fully functional prototype in August. Once we have the prototype, it will then have to undergo functionality and durability testing before production of a pilot batch can commence. More on this in future updates. I’ll also note that the final dev kit (2.0), which incorporates fixes for all the issues found in dev kits 1.0, 1.1 and 1.2 as well as alignes all functionality (e.g. HDMI out via USB-C) with the production PinePhone, will be produced at the same time as the prototype.\nThings are also progressing well on the software-front. The core phone functionality - calling and sending messages - has now been enabled in a number of OS’. It took a little while to get the mobile networking working due to an error with SIM slot wiring on dev kits 1.1 and 1.2; that has now been fixed using an adapter, and the aforementioned dev kit 2.0 will no longer require the adapter. I’ve tried PostmarketOS (Plasma mobile / XFCE / Weston demos), Maemo Leste and LuneOS in recent weeks and they’ve all made significant progress in a very short amount of time. The functionality highlights for each OS differ - which makes for interesting testing of these early OS images. For instance, Maemo Leste has messaging etc., enabled, while PostmarketOS has managed to get the camera working (Martijn from PMOS even ran a ~2hrs stream live from the dev kit), and LuneOS offers an extremely smooth UI experience with many applications working, including browsing the web. Morover, all sensors and even the speakers now work too, so things are really comming together at a rapid pace. As I’ve already mentioned in the May news update, developers from all the different OS’ work together, and so all the newly enabled functionality quickly finds its way into all OS images. I am still waiting to try a number of the OS’, including Ubuntu Touch and Sailfish OS; once I get my hands on these builds I’ll make sure to record a compilation demo, showcasing functionality and performance. https://www.youtube.com/watch?v=3SyqbI24qu0https://www.youtube.com/watch?v=UlrIqAwHRXY Pinebook Pro We listen to your feedback and take it to heart. For those of you who have not read my edit to last month’s post: there will be both an ISO and ANSI keyboard available for the Pinebook Pro. I do not have more information about when the ANSI keyboard will be available at this time - but I am getting an evaluation unit with the ANSI keyboard soon - I’ll edit this update accordingly to let you all know how I find this candidate keyboard. Wrapping up the keyboard discussion, I’d just like to make it clear - the first Pinebook Pro batches will most likely only ship with the ISO keyboard. Let me also address all those of you who are asking about regionalised layouts - there is currently no plan to support any other layouts except for standard ISO and ANSI.\nANSI and ISO Keyboard Variants\nThe choice of keyboards isn’t the only update to the Pinebook Pro since its announcement. In fact, there are some really awesome features coming that we haven’t talked about yet - largely since they need to be properly tested first - which I expect to discuss in next month’s update. I think many of you will be thrilled. That said, there are another two small updates to the Pinebook Pro that deserve some spotlight too. The first of these is that Pinebook Pro has been upgraded with a BT/WiFi module that supports Bluetooth to 5.0 (vs announced BT 4.1) and secondly we’ve asked for improvements to the firmware of the trackpad. As with many things in life, the devil is in the details, and on a laptop that means the input methods, which really makes or breaks the experience. The trackpad on the current prototypes is already very solid, but we are talking to the hardware vendor to further improve precision and reduce accidental inputs of the trackpad. Lastly, we decided not to have any branding on the Pinebook Pro, since it seems this is what users prefer. So you get to decorate it yourself using stickers or keep it smooth and black - up to you.\nI also have good news for all developers hoping to get their hands on the Pinebook Pro. If the aforementioned Pinebook Pro unit I’ll be receiving soon addresses all, or at least most, of my initial feedback I submitted to TL to be forwarded to the factory, then the manufacturing process for a developers batch will start shortly. This means that by the time end-users get their hands on the Pinebook Pro there will be a number of Linux, and possibly even *BSD, options to choose from.\nSpeaking of software, I am also happy to say that the state of software tailored for the Pinebook Pro is already superb. The last major outstanding issue with the Linux test builds (PCIe locking up in desktop use) has been resolved as of May 27th and all other features required for laptop functionality now work. Just for the sake of diligence, let me list some of the key components for desktop use that ayufan and mrfixit2001 got working in their builds over the past few months: BT/WiFi; PCIe (M.2) ; LCD panel including brightness ; suspend/ resume from suspend ; sound (speakers+headphone jack) ; USB-C (data, charging + video out) ; accelerated desktop (xorg glamor or armsoc) ; 4K video acceleration of local media ; 3D and video acceleration in browser (including: webgl 2.0 \u0026amp; widevine) ; support for a number of peripherals. More info on the respective builds can be found here and here.\nMany of you have been asking about Pinebook Pro availability and when pre-orders will start. The answer is “this summer”, as we still need to evaluate the pre-production units for fit-and-finish and functionality. I trust you can appreciate that this is an important step and cannot be rushed. If it turns out that everything is OK with these units, then right after the pilot batch for developers regular production will start. Regarding when and how you find out about the Pinebook Pro pre-orders - chat and forum members will be alerted slightly ahead of time since we want our core users to get a small heads-up. Then we’ll send out notifications via social media (Twitter and Mastodon) and make an announcement on the website. This will likely be picked up by relevant media outlets too. In the future, there will be a newsletter sign-up that will alert you to new Pinebook Pro batches being available.\nHere is a peek under the hood of the pre-production (post-prototype) Pinebook Pro\nPineTab I know that the PineTab news are well overdue, but once you’re done reading this section I hope you’ll agree that the wait well worth it. Long story short, the delay in PineTab production was due to us being unsatisfied with the digitizer panel; this has now been sorted and evaluation units of the tablet are now being built.\nThis delay was, however, not a waste of time. The extra time gave us space to think and consider what else can be improved on, and added to, the current design. We ran a poll some time back asking about the desired storage capacity for the PineTab, and the majority of users showed a strong preference for increasing the eMMC storage capacity to 64GB. After some considerations, we decided to honour the community vote and we’ll be including this larger eMMC with the PineTab.\nWe have also decided to include an option for a M.2 adapter on the PineTab. This will allow a number of expansion options that users and developers can explore - the most obvious applications being LTE and storage, but I am sure that you can think of other ones too. We hope that you’ll agree that the time it took us to bring the PineTab to fruition, since its announcement earlier this year at FOSDEM 19, has not been wasted despite the delay in selecting a suitable digitizer panel.\nGranted we’ll be happy with pre-production units delivered to us and developers, then you can expect the PineTab to be available late this summer. More information on the PineTab and its new pricing will follow soon.\nFuture Single Board Computers As I’ve already written in the May update, SBCs are and will remain PINE64’s bread-and-butter. They will always be the basis for any new devices - such as laptops or phones - that PINE64 will develop. It’s a part of us striving for software compatibility between the different types of hardware, reducing the workload of developers porting their OS’ to a new devices. To this end, I’d like to assure everyone that new (and exciting) boards will be coming in the future. It is too soon to talk about these boards however, since some of them are in concept or layout stages whilst others are still in our heads. What I will say, however, is that one field we wish to explore is AI, and we hope to bring both AI-focused boards and modules to the Pine Store in the future.\nThat\u0026rsquo;s it for this month’s update, chat away below or on the forum / in the chats.\n","permalink":"/2019/06/06/june-2019-news-pinephone-pinebook-pro-and-pinetab/","tags":["pinebook-pro","pinephone","pinetab"],"title":"June 2019 News: PinePhone, Pinebook Pro and PineTab"},{"categories":["community","news"],"contents":"The forum update is scheduled to go live at the end of May (likely over the weekend May 25-26th). You can expect the forum to be down for a couple of hours as work is being carried out. We hope that the process will be relatively painless, but if unexpected issues arise then this will extend the downtime. The forum upgrade is a part of our ongoing process of improving PINE64 services, which you can expect to carry over to the month of June with future updates to the Wiki and the chats.\nUpdating the forum is something that has been on our bucket list for a long time, but there have always been multiple other more pressing things that have taken priority. Frankly speaking, not much though has been given to the state of the forum, its structure and usability until earlier this year. The server move this month has given us the opportunity to update, change and most importantly improve all the PINE64 community services; the webpage was the first to receive an update and now its the forum\u0026rsquo;s turn for a make-over.\nGDPR Compliance The current forum is in need of more than quality-of-life improvements - more specifically, we need to make the forum complient with regulation (GDPR). On your first login you will be presented with the privacy policy, which you need to accept before proceeding to using the forum services as per usual. Scroll to the bottom of the policy and click accept. Accepting the privacy policy (identical to the one on this website) is required for both new and existing members and applies to everyone, including moderators and developers.\nNew Look and Feel The general layout of the forum has been simplified and designed to expose the bits and pieces that regular and new users access frequently. The side tab has quick access to the PINE64 chats - the Discord and IRC Webchat for the time being- while the top bar features links to the Wiki, this News blog, Forum Portal as well as other relevant information. At the bottom of the forum page you\u0026rsquo;ll find a footer with all the social links as well as some helpful information.\nNew Features Apart from overhauling the look of the forum we\u0026rsquo;ve also added new features that will hopefully improve the forum experience. The most notable omission on the current forum is probably the \u0026lsquo;Alerts\u0026rsquo; function, that notifies you if someone responds in your thread, quotes you in a post, rates your response or writes in a thread you\u0026rsquo;re subscribed to. This feature has now been added to the forum and can be accessed by clicking the bell icon next to your User CP icon. You can tweak the Alerts settings from the User CP if you aren\u0026rsquo;t happy with the defaults.\nIf you wish to mention someone, and have them be alerted of this, you can use the @ symbol in conjunction with their username. Mentions have an autocomplete feature (pictured below) so all you need to do is start typing and select the user in question from the drop-down menu. Mentions trigger alerts, so they are useful if you want to get someones\u0026rsquo; attention.\nThe other improvement, which I truly hope users will embrace, is the \u0026lsquo;Mark as solved!\u0026rsquo; button. I think this one doesn\u0026rsquo;t really need any explanation - if your forum query was resolved, clicking it will mark it as solved. This really simplifies looking for answers on the forum, and is likely to limit the number of reoccurring threads concerning the same subject matter.\nThat\u0026rsquo;s all for now. Huge thanks to ItsDave and FireTwoOneNine for putting in the time and effort to update and set the new forum up. As always, your feedback is welcome!\n","permalink":"/2019/05/22/forum-update/","tags":["community","forum","pine64","update"],"title":"Forum Update"},{"categories":["rock64","gaming","news","rockpro64"],"contents":"Retro Emulation is all the rage these days. What\u0026rsquo;s old is now new again. Game Emulation has been around for awhile, but the recent resurgance into making mini consoles spearheaded by the release of the NES Classic has opened up new possibilities for making our own NES or SNES classic\u0026rsquo;s.\nNow Roshambo has released their own Gaming Case to compliment a few Single Board Computers, including the powerful RockPro64!\nThere are two separate models, one with compatibility for the rock64 and raspberry pi, and a Pro version specifically designed for the RockPro64.\nIn this review, I used the model for the RockPro64.\nThe RoshamboPro Retro Gaming Case First off, the case is quite well built. It feels solid sturdy, and everything fits in as it should. If you get the case designed for the RockPro64, you will be getting a heatsink and fan included that can be controlled via software.\nThere is a recalbox image specifically for the RockPro64 that also enables the unique capabilities of this case. To start, let\u0026rsquo;s go over those features:\nIt has a reset option, as well as a power-on/power-off mode. It has two usb ports in the front where the controllers go, as well as a separate usb port in the back of the case, and an extra usb type-c adapter. The most unique feature of all, the SATA adapter at the top where you can install a ssd that will allow you to load up all the games you\u0026rsquo;d like. You can get these special SSD\u0026rsquo;s in 120gb, 256gb, and 512gb which look like little SNES carts. You can purchase them here. A picture of the SSD.\nThe RockPro64 The RockPro64 is the star of the show.\nIt\u0026rsquo;s more powerful than a Rock64, and far more powerful than a Raspberry Pi 3B+. You can buy one here at pine64.com\nThe RockPro64 comes in two flavors, a 2gb and 4gb version. The RoshamboPro Gaming kit for $99 will include the 2gb version, which should be all that\u0026rsquo;s required.\nGaming performance wise, the RockPro64 just decimates the Raspberry Pi in raw-power. Games that were not playable on the Raspberry Pi will play on the RockPro64.\nFor example, the RockPro64 will play arcade games like Primal Rage (which is a fun fighting game with dinosaurs and huge gorillas) which the Pi3b will struggle with. The RockPro64 will even play PSP games! The RockPro64 should have no issues with Playstation or N64 games either, something that the Raspberry Pi will struggle with (especially with N64 emulation.)\nYou will need the included Fan though, as the RockPro64 can and will run pretty hot, especially in that case.\nThe RockPro64 includes a USB-Type C adapter, as well as a USB 3.0 port, and two USB 2.0 ports. You can use a MicroSD Card or a optional EMMC card for booting as well.\nGaming on the RockPro64 The RockPro64 (and Rock64) both currently support the following distro\u0026rsquo;s dedicated to gaming.\nRecalbox\nBatocera Linux\nLakka\nIn this review, I used Recalbox, which combines Retroarch along with Emulationstation in a very easy to use Distro where you can do practically everything you need straight from the GUI.\nBatocera is also very similar to Recalbox with some minor changes in UI.\nWhile Lakka is different in that while it uses Retroarch, but does not use Emulationstation as a frontend.\nWhen using the RockPro64, you will need to add in a Wifi Adapter. You can get a Wifi/Bluetooth module, or use a usb wifi adapter. I myself used my old trusty Linksys Wireless G usb adapter. You can load roms by mounting the SMB Share via Windows.\nClick Start \u0026gt; This PC \u0026gt; Right click \u0026ldquo;This PC\u0026rdquo; and click on \u0026ldquo;Map Network Drive\u0026rdquo; \u0026gt; Type in the IP address of the rockpro64 like \\\\192.168.x.x or \\\\RECALBOX\nYou should be able to then find the ROMS share and just drag and drop the roms.\nAfter you\u0026rsquo;re done, open up the Recalbox menu and select Ui Settings \u0026gt; update games list.\nAnd your games should show up on Recalbox.\nIf you want to add in pictures and data about the games, you can use the built in scraping tool or you can use a tool on your PC called Skraper.\nIf you want to learn more about RetroGaming on a RockPro64, Rock64, or even other Single Board Computers, please join us at the /r/sbcgaming subreddit and discord.\nUseful Links and Resources Subreddit: /r/sbcgaming\n/r/sbcgaming Discord\n(Use these to talk about RetroGaming on the RockPro64, the Rock64, or any other Single Board Computer! We\u0026rsquo;ll be glad to have you there! And please stop in and say hi!)\nPine64 Discord\n(Talk about the Rock64, Pine64, or RockPro64 here!)\n","permalink":"/2019/05/13/taking-retoemulation-to-the-next-level-with-rockpro64-and-roshambo/","tags":["gaming","rockpro64","rock64"],"title":"Taking RetroEmulation to the next level with RockPro64 and Roshambo"},{"categories":["news","pinebook-pro","pinephone"],"contents":"\nThe new website is finally online and it is now easier to deliver news to people within and outside the community. Unlike the forum, information in this blog won\u0026rsquo;t easily get lost among the countless other day-to-day threads concerning troubleshooting, new builds and similar topics. In the long run, I trust this will make it easier to find, reference and share information.\nAnd so, with no further ado \u0026hellip;\nNews for May 2019 Run-Down: Forum updates incoming BTO is going away (for all devices) PinePhone Status Report Pinebook Pro Roadmap Forum Updates Incoming One of the reasons for moving the community services to a new infrastructure was to make it easier to update and improve stuff on the fly and when it suits us. One of the issues we were facing with the previous server setup was the inability to keep the forum up-to-date (as to why that was the case \u0026hellip; it is a long story and not interesting). This is now an thing of the past, and so this week we will clone the forum database, update myBB to a recent version, add services we think / feel the forum deserves and migrate over. We do not expect any major or lengthy blackout because of this but be prepared for some potential forum disturbances this and the next week as we\u0026rsquo;re working on it. BTO is Going Away (for all devices) BTO is going away and is being replaced with a pre-order system. This change has already been reflected on the Pinebook store page. All those of you currently waiting in the BTO queue will be serviced, so don\u0026rsquo;t worry - you are not waiting in vain. Initially, when the BTO system was implemented, it was intended to determine interest levels in the Pinebook. In practice however, it failed to work as a reliable indicator of how many people actually want a unit and hence, how many Pinebooks need to be built. It also proved to be very demanding on the shipping team and those who dealt with the system put in place to reissue BTOs when customers decided against purchasing their unit. We also realised that you guys aren\u0026rsquo;t exactly huge fans of the system - BTO tickets lost in spam folders, people forgetting their BTOs, high volume of \u0026lsquo;when will it ship?\u0026rsquo; emails \u0026hellip; are all an indication that a different system had to substitute BTO. So, for the Pinebook, Pinebook Pro and PinePhone (and potentially other similar devices in the future) a pre-order system will be used instead. There will be a set quota of available units in each batch and the system will work on a first-come first-served basis. You will be notified about the availability of the device via an email; there will also be notifications on social media, such as Twitter and Mastodon. Forum and chat members will always get a short heads-up that the sales are going live. Consider it a nod to those actively taking part in the community. The pre-order page will list the expected shipping date and any other relevant information, which we trust will lessen the degree of confusion of when and what ships. There isn\u0026rsquo;t much else to be said - the functioning of the system will be pretty straight forward. PinePhone Status Report Development for the PinePhone is progressing nicely. Before I jump into some of the details, let me say that it is a real treat to see developers from all major Linux on-phone projects working together to achieve support for the PinePhone. The developers also collectively contribute to one repo, which means that they can benefit from each others work and do not have to re-do something that has already been solved or implemented. As things stand, new features and functionality are literally added daily. I hope to have some builds later this month so I can showcase them on youtube and make a post about the progress.That said, I fully understand and appreciate that developers want to take their time so as to have their early work reflect the effort they\u0026rsquo;ve put in, so this showcasing timeline may slip a little. Stay tuned. On the hardware front, the design of the PinePhone case is now complete (I\u0026rsquo;ll make a video showing the mockup at the same time as I\u0026rsquo;ll be recording the videos of early dev builds) and work on dev kits 2.0 with numerous fixes as well as the actual phone PCB will begin concurrently and very shortly. We expect to have a working prototype, as well as dev kits v2.0 (expected to be final) which will be fully aligned with hardware in the prototype(s), sometime mid-to-late summer. I dare say, unless something really unexpected happens - we will likely have the PinePhone ready before the end of this year. As we\u0026rsquo;ve said numerous times, this does not mean that we will start selling PinePhones the day we get them from factory; we will wait for at least one fully functioning OS build prior to sales commencing. More PinePhone news will follow late this month or early in June. Front of the PinePhone Mockup\nBack of the PinePhone Mockup\nPinebook Pro Roadmap The Pinebook Pro software and hardware is coming together both quickly and well. In terms of software, community developers have all key functionality already working in their respective builds, and partner projects will be getting their hands on dev units sometime this Summer. As of today, there are two builds that have full functionality from the two developers whom have worked to get their kernels ship-shape for partner projects; these two builds are, Ubuntu (with Mate/ LXDE) from ayufan and Debian Stretch from mrfixit2001. In terms of hardware, the Pinebook Pro demoed in a recent (and poorly recorded - sorry about that!) video is probably nearly identical to what you\u0026rsquo;ll be getting when you order your unit. There are still a few outstanding PCB hardware issues in the unit I showed off in the video, which have now been identified and successfully resolved. The new PCBs should be back from the factory shortly, and granted that the PCB has no issues and test well, a pilot production of Pinebook Pros\u0026rsquo; will commence shortly after. I am assuming that since you are reading this blog, then you must at the very least have an idea about what hardware is in the Pinebook, and what sort of materials it uses (if not, click here). In light of this, here I will focus on the two things that are rarely discussed but probably of vital importance to most users: the keyboard and trackpad. You will be happy to hear that the new ISO keyboard has a nice feel to it, has a soild click-y tactile plunge, the keys have a relatively long key-travel, and in my testing the keyboard has not exhibited any issues - indeed, I am writing this blog entry on the Pinebook Pro as a part of my testing. The trackpad is also a major improvement over the one found on the original Pinebook. For one, it is an actual point-to-point trackpad (and not an emulated mouse) and the coating / material that it is made out of is smooth and feels almost metallic to the touch. Now, if you\u0026rsquo;re coming from a high-end laptop, such as the Macbook or Dell XPS, then the trackpad will probably not going to blow you away; that said, I have compared the trackpad on my prototype up against similarly priced laptops as well as laptops twice the price, and frankly speaking it is on par with just about everything that is out there. More information about the Pinebook Pro will follow next month. The ISO keyboard layout that will be used on Pinebook Pro production models.\nEDIT: Here is a video where I showcase the software functionality on the current prototype. In this video I also discuss some of the design choices made - such as the ISO keyboard.\nhttps://www.youtube.com/watch?v=mj3_jMBlbxA\n[Edit 13/05/2019] Future ANSI Keyboard Option Right, ok, we get it - many of you want an ANSI keyboard layout as an option. Understood. We will eventually offer a EU/US keyboard layout option at store check-out.\nThis may take some time as we need to find a suitable keyboard first, put it though its paces to make sure that its good quality, and also make sure that no extensive retooling needs to be done on the Pinebook Pro case. This means that you can expect the first end-user batch (or two) to ship with the pictured ISO keyboard only, as its unlikely we will find a candidate ANSI keyboard, test it and implement in into the production schedule on-the-fly. I trust everyone understands that these things need to be properly tested and evaluated before going into production.\nMore Pinebook Pro updates are coming soon - I\u0026rsquo;ll keep you posted.\n","permalink":"/2019/05/06/may-2019-news/","tags":["bto","news","pinebook","pinebook-pro","pinephone"],"title":"May 2019 News"},{"categories":["news","pine64-community"],"contents":"Welcome to the new PINE64 website. In time, this blog will be filled with updates and news as well as posts from developers and contributors. The website will be maintained and ran by the community; everything, with the exception of the store, will be accessible to be shaped and molded to suit the PINE64 community of developers and end-users. More information will follow shortly.\nFor now, have fun exploring the new site. If you have any suggestions for improvements, or want to help maintain this website, or contribute something for the blog - let us know.\n","permalink":"/2019/04/30/new-community-ran-website/","tags":["community","pine64","website"],"title":"New Community Ran Website!"},{"categories":null,"contents":" A Quartz64-A mounted in an ITX case using 3D printed brackets\nAllows mounting a ROCKPro64-A or Quartz64-A board inside a regular PC case that conforms to the ITX standard, using 3D printed brackets:\nAMF/STL/STEP files plus the original FreeCAD file used to create the models https://wiki.pine64.org/wiki/File:RP64-A_Q64-A_to_ITX_mounting_brackets.zip Make sure to flip the two brackets by 180 degrees on one of the horizontal axes (X/Y) in your slicer of choice before printing to avoid unnecessary supports To allow enough clearance between the board and the bracket you either need to print four copies of the washer model or add nut(s) between the board and the bracket If using nuts for the clearance between the board and the brackets, make sure it creates at least 3.2mm of spacing in between Depending on the accuracy and calibration of a 3D printer, slight deviation can occur and you likely need to manually widen some of the holes to allow screws to fit ","permalink":"/documentation/ROCKPro64/Hardware/3D_printable_ITX_mounting_brackets/","tags":null,"title":"3D printable ITX mounting brackets"},{"categories":null,"contents":"Although most accessibility support for the PinePhone and PinePhone Pro is implemented in software, the underlying hardware is still relevant. This page discusses some issues and options.\nInput Braille Various portable devices, such as Apple’s iPhone, support braille input. This uses multi-touch capability on the device’s capacitative touch screen. The gating factors for this input mode are the dimensions of the screen and the number of contact points that can be distinguished.\nThe PinePhone screen has 1440 × 720 pixel resolution and measures 5.95\u0026quot; diagonally. Assuming that the pixels are square, the screen dimensions should be about 2.68\u0026quot; by 5.37\u0026quot;. This should provide plenty of room for four fingertips on each of the long sides. Indeed, there is a bit of space left over for control functions, etc.\nKeyboard The PinePhone can support either Bluetooth or USB keyboards. So, a device such as the Jelly Comb Foldable Bluetooth Keyboard B003 might be a reasonable input device.\nSpeech The PinePhone should be able to accept speech input using either Bluetooth or its built-in microphone. According to this page, Mozilla’s DeepSpeech ASR (automatic speech recognition) engine works pretty well on a Raspberry Pi 4, using only a single core. Assuming that the PinePhone’s more limited (2 or 3 GB) RAM isn’t a constraint, the phone should be able to produce similar results.\nOutput Speech The PinePhone’s processor should have plenty of capacity to generate clear speech. This can be output using either the 3.5 mm audio jack or a Bluetooth connection.\nSee also postmarketOS wiki: Accessibility ","permalink":"/documentation/PinePhone/Further_information/Accessibility/","tags":null,"title":"Accessibility"},{"categories":null,"contents":" To operate this board you will need a power supply, Pine advises a \u0026ldquo;5V 15A power supply with 6.3mm OD/3.0mm ID barrel type DC Jack\u0026rdquo; which is also available in the store (EU / US versions). There are other ways to power this board, but they are not described here yet. The board works best when it is protected by a (mITX)case, and has some airflow provided by a fan. Each SOPINE module can use cooling, both by a case fan, and by using heatsinks on the individual modules. At least the A64 could use some cooling. The first slot can use a eMMC module, which are in the store in 16GB / 32GB / 64GB / 128GB sizes. The modules can be used as a USB stick using a USB adapter. (The eMMC is also readable with the Hardkernel eMMC to microSD converter.) Two AA batteries, to allow the SOPINE nodes to retain the RTC (Real Time Clock) time and date information when the power is disconnected. ","permalink":"/documentation/Clusterboard/Accessories/","tags":null,"title":"Accessories"},{"categories":null,"contents":"Please see Accessories Step by Step Guides for a list of guides for Pine A64 accessories; there you can find instructions and guides about the following:\nEnclosures Bluetooth and WiFi module Real Time Clock (RTC) battery Real Time Clock (RTC) battery holder First and third party cases Featured 3D printed cases (and more) ","permalink":"/documentation/Pine_A64-LTS/Accessories/","tags":null,"title":"Accessories"},{"categories":null,"contents":"Under Accessories Step by Step Guides you can find instructions and guides pertaining to:\nEnclosures Bluetooth and WiFi module Real Time Clock (RTC) battery Real Time Clock (RTC) battery holder First and third party cases Featured 3D printed cases (and more). ","permalink":"/documentation/Pine_A64/Accessories/","tags":null,"title":"Accessories"},{"categories":null,"contents":" Accessories (Single Page)\nAccessories Step by Step Guides\nCases\nPOT\nWifi Remote I2c\nAccessories Step by Step Guides Accessories Step by Step Guides\nWi-Fi/Bluetooth module: Step by Step Installation Guide Acrylic Open Enclosure: Step by Step Installation Guide If you wish to stack two or more of these enclosures, the screws that serve as feet can be replaced by M8-1.25x16mm grub screws.\n1.25mm is the pitch between threads, and for the M8 (8mm outer diameter) that\u0026#39;s the default pitch, and most are advertised as M8x16mm screws. 16mm is really the minimum workable length to catch both the bottom and top aluminum standoffs, with both washers and the acrylic sheet in between. It\u0026#39;s workable, but if you can get 20mm it\u0026#39;s probably for the best. Images: https://imgur.com/a/Zka1qfb\nSimple 3D Printed Case by Harlandraka 3D printing schematics Sliding 3D Printed Case by Harlandraka 3D printing schematics C4 Labs Case for the Pine Forum thread including instructions 7\u0026quot; LCD Touch Screen Panel: Step by Step Installation Guide Real Time Clock (RTC) battery holder (AAA battery type): Step by Step Installation Guide Real Time Clock (RTC) battery holder (CR-2032 Coin Cell battery type): Step by Step Installation Guide Cases Model A Acrylic Open Enclosure\nModel B Acrylic Open Enclosure\nNASCase\nModel A Acrylic Open Enclosure The \u0026ldquo;Model A\u0026rdquo; Acrylic Open Enclosure is a case for \u0026ldquo;Model A\u0026rdquo; sized single-board computers (Pine A64, ROCKPro64, Quartz64 Model A) sold by PINE64, available from the official store.\nA Pine A64 mounted in the \u0026quot;Model A\u0026quot; Acrylic Open Enclosure. The text on the top is \u0026quot;PINE64\u0026quot; nowadays.\nInstallation Please refer to the official instructions for assembling the case.\nFor the Quartz64 Model A, you may need to file down the inner corner of one of the mounting posts for the little mic connector on the bottom of the board to clear it.\nMods 3D-Printable Top With Fan and PCIe Cutout Non-artist’s impression of the replacement top plate\nUser:CounterPillow has created an alternate 3D-printable top plate which allows for the mounting of a 40mmx40mmx10mm fan, as well as allowing for PCIe cards to be mounted while the case is assembled. The STL and STEP files are available under https://wiki.pine64.org/wiki/File:Model_A_acrylic_case_top_plate_with_fan_cutout.zip free of charge, licensed as CC-BY 4.0.\nA fan is mounted to it using self-tapping fan screws usually shipped with computer fans; put the fan on the underside of the plate, and screw in the self-tapping screws from the top side. You can either have the fan exhaust air through the top, or blow it onto the SoC’s heatsink. The latter configuration appears to work better, but precise measurements haven’t been made yet.\nRecommended printing material is PETG for its structural rigidity. However, PLA will likely work fine as well, and is easier to print. A 0.6mm nozzle was used for test prints, but any nozzle should work. Depending on the layer height you choose, your print may come out slightly thicker or thinner; this is no problem though. It’s recommended to enable the advanced \u0026ldquo;Detect Thin Walls\u0026rdquo; option in slic3r to get a cleaner g-code result around the fan holes.\nModel B Acrylic Open Enclosure The \u0026ldquo;Model B\u0026rdquo; Acrylic Open Enclosure is a case for \u0026ldquo;Model B\u0026rdquo; sized single-board computers sold by PINE64, available from the official store.\nA_ROCK64_mounted_in_the_case,_the_correct_way.\nInstallation To install the SBC inside the case, stick the long screws into the SBC mounting holes from below, place the board such that the screws sit in its mounting holes, and screw on the brass fasteners on top of the SBC.\nMods 3D-Printable Top With Fan Cutout Top_view_of_the_plate\nThe assembled modified case with a Noctua NF-A4x10 5V PWM mounted to it. The SBC is mounted in the enclosure upside-down.\nUser:CounterPillow has created an alternate 3D-printable top plate which allows for the mounting of a 40mmx40mmx10mm fan. The STL and STEP files are available free of charge under https://wiki.pine64.org/wiki/File:Model_B_acrylic_case_top_plate_with_fan_cutout.zip, licensed as CC-BY 4.0.\nA fan is mounted to it using self-tapping fan screws usually shipped with computer fans; put the fan on the underside of the plate, and screw in the self-tapping screws from the top side. You can either have the fan exhaust air through the top, or blow it onto the SoC’s heatsink. The latter configuration appears to work better, but precise measurements haven’t been made yet.\nRecommended printing material is PETG for its structural rigidity. However, PLA will likely work fine as well, and is easier to print. A 0.6mm nozzle was used for test prints, but any nozzle should work. Depending on the layer height you choose, your print may come out slightly thicker or thinner; this is no problem though. It’s recommended to enable the advanced \u0026ldquo;Detect Thin Walls\u0026rdquo; option in slic3r to get a cleaner g-code result around the fan holes.\nThe print will take approximately 7.8 metres of filament, and take in the order of one hour, though this depends on slicer settings and printer model.\nThe cooling performance with a Noctua NF-A4x10 5V PWM is enough to no longer throttle after a few minutes of cpuburn, but comfortably sitting at below 75°C instead. The memory has no temperature sensor, but will likely be cooled quite a bit as well.\nRough wiring diagram of how to PWM control the fan from a ROCK64 with a helper Arduino\nSince the ROCK64 has no PWM pins available to control the fan, a slight workaround can be done; with the gpio-fan device tree binding, an Arduino can be controlled to soft-PWM a suitable 25 kHz signal for the fan. The ROCK64 uses 3.3V on the GPIO pins, so you’ll need to logic level convert it to 5V if you’re using a 5V Arduino, and if you’re using a 3.3V microcontroller, you’ll need to logic level shift the output PWM signal as the 5V fan will be expecting 5V PWM on the PWM pin.\nThe device tree changes and the Arduino sketch which User:CounterPillow created for this can be used for any purpose by anyone. It is recommended to play around with the device tree though, to add more trip points for better control over when the fan actually ramps up, and adding more hysteresis as the temperature reading from the ROCK64 is quite jumpy.\nNASCase The PINE64 NAS Case is intended for either a Network Attached Storage (NAS) or Desktop application, but it can also be used in a number of other server capacities. It is built from precision-cut and powder-coated aluminum. The physical dimensions are 232.4mm (Width) x 105.0mm (Height) x 145.2mm (Depth).\nAn exploded view of the NAS Case, illustrating how all the components come together, can be found here. Please refer back to this PDF document during assembly to verify correct orientation of individual components.\nFront View of the PINE64 NAS Case for the ROCKPro64\nWhat does the NAS Case house? Internal Layout of the NAS Case\nThe NAS Case can house the following components:\nA ROCKPro64 Single Board Computer (SBC) with a tall, mid-size or slim/ no heatsink A PCIe to dual SATA adapter or a different low-profile PCIe card, e.g. an NVMe adapter Either two 3.5 inches OR t incheso 2.5 inches HDDs / SSDs; combination of any two sized drives is accepted A 80mm fan with a Ph 2-Pin connector Up to three SMA antennas, two of which can be attached to the WiFi/ BT module What comes in the box? When you purchase the NAS Case from the PINE store the following items are shipped to you:\nThe NAS Case itself, which consists of a top and a bottom half as well as an internal HDD SSD mount. Two SATA cables A custom power cable capable of powering two 2.5 inches inchesr 3.5 inches HDDs /SSDs The required screws, fittings and a LED relay What other bare-minimum things do I need for a NAS build? You will need the PCIe to SATA adapter from the PINE64 store to connect your disks to your ROCKPro64 board. https://forum.pine64.org/showthread.php?tid=6932. WARNING: this adapter does not work well with two HDDs, see https://forum.pine64.org/showthread.php?tid=6511:\nTo assemble a functional NAS in the NAS Case you will require a number of additional parts.\nWith the exception of HDDs/SSDs, everything you need for a complete build can be purchased from the PINE store:\nA ROCKPro64 2GB or 4GB board A 12V 5A power supply A PCIe to dual SATA adapter: WARNING, the SATA adapter from PINE64 store is low-quality and will not function well with two SATA HDD. One or two 2.5 inche inches/ 3.5 inches HDDs (not sold in the PINE store). A class 10 micro SD card and/or eMMC module. You can purchase all the aforementioned items in the PINE64 store\nWhat other things should I consider buying for a NAS build in the NAS Case? There are a few other things which you may wish to consider purchasing for your NAS. These peripherals, while not necessary from an operational standpoint, may contribute to the longevity and stability of your NAS’ operation OR expand it with additional functionality:\nAn eMMC to USB 2.0 adapter A tall heatsink (N.B. Any of the three available heatsinks will fit in the NAS Case) An 80mm fan The WiFi / BT module (The fan and heatsink are highly recommended)\nWhich software should I use? The OMV WebGUI is easy to understand but also very robust. It offers easy installation of plugins, system administration and overview of available services\nIf you are intending to build a home or small company NAS, then we strongly recommend you use Open Media Vault (OMV). OMV is an open source NAS solution that makes setting up user accounts, network shares and services a breeze. It also simplifies installing additional features (called plugins), such as: PLEX media server; Remote Desktop; Encryption; RSync; etc.\nIts worth noting that Nextcloud, or other similar Cloud storage solutions, can also be easily installed alongside the OMV OS Image.\nAdministration and monitoring of OMV is done via an advanced WebGUI, which also allows for updating and upgrading the ROCKPro64. To learn more about OMV please visit their website.\nTo download the latest OMV build OR one of the numerous available Linux Distribution OS Images please visit the ROCKPro64 OS download section.\nStep-by-Step Assembly Instructions If you prefer a video tutorial or just want an overview of the process before you start check out this instructional video.\nStep 1. Preparation of the NAS Case for Installation Remove the top of the NAS Case. It is held together by two screws on either side with the exception of the bottom (left, right, top and back). Once done, the top of the case should lift right off without any resistance.\nThe next step is to remove the HDD/SSD holding bracket, which is screwed into the bottom of the case. Flip the bottom over and undo the screws which hold the bracket in place.\nYou should now be left with a bare case ready for installation of the necessary components.\nStep 2. Installing the ROCKPro64 into the NAS Case Correct Placement of the ROCKPro64 in the empty case, with Ethernet; Power; and HDMI at the back of the NAS Case\nFront IO with IR and LED relay installed\nMake sure nothing is plugged into your ROCKPro64 - including a micro SD card. If you intend to use a heatsink with your board then please install it now before proceeding. If you bought the heatsink from the Pine64 store it comes with thermal paste and/or a thermal pad. You can use one or the other (not both!). The thermal pad is easier to apply but the thermal paste should be better at cooling if properly applied.\nPlace your ROCKPro64 into the case with USB 2.0 and 3.0/C ports facing the front of the case. It should fit snugly and align with the port cut-outs in the case. Do not attempt at installing the board at an angle; insert it while holding it level and lowering it into the case.\nSecure the board with 4x screws included in the see-through bag. Make sure that the board is held firmly in the case but do not overtighten the screws.\nIn the see-through bag you will also find a small semi-opaque plastic cylinder. This is the LED light lead and it should be installed from the outside of the case into the hole right over the reset (RST) switch. Simply press it into the hole until it sits tight.\nIf you wish to install an IRx receiver into your case then you should also place it into the IR socket at this stage. It should align with the cutout right above the power (PWR) switch.\nStep 3 PCIe to SATA adapter and Cabling DC header on the ROCKPro64 for the power cable\nPCIe to SATA installed. Note the SATA connection orientation\nWith the board in place it’s time to set up the PCIe to SATA adapter and do the cabling necessary to attach HDDs / SSDs.\nPlace the SATA Adapter into the PCIe slot on the ROCKPro64 board so that the holding bracket of the adapter faces the back of the case. In the back of the case there is a cutout for the PCIe adapter; some variants of the PCIe dual SATA adapter can be configured for eSATA if need be, and the eSATA ports are accessible in the back of the case. By default, the internal SATA connectors are active on the adapter.\nSecure the PCIe dual SATA Adapter with a single screw at the top of the bracket, in the back of the NAS Case.\nThis is the right time to plug in the SATA and custom power cable. The SATA cables plug into the ports on the top or front of the adapter while the power cable plugs into DC header located on the board - just below the power jack, to the left of the Ethernet port (when viewed from front).\nHave the cables hang outside the case or to the side for now so that they do not get in the way until they are needed.\nStep 4. Installing HDDs / SSDs into the Holding Bracket Bracket Orientation in the NAS Case\nThe next step is to install HDDs/ SSDs into their holding bracket; 2.5 inches drives need to be installed at the very bottom of the bracket whi inchese 3.5 inches drives are at the top of the the bracket.\nFor 2.5 inches drives make sure that the drives are oriented up and their SATA and power ports face the front of the NAS Case.\nFor 3.5 inches HDDs, make sure they are oriented up and their SATA and power ports face the right side of the NAS Case (towards the fan mounting location).\nEach drive you mount in the holding bracket requires 4x screws which come supplied in the see-through bag. Make sure the drives are held in place firmly but do not over-tighten the screws.\nOnce the holding bracket is assembled and you have your drives mounted, please set it aside and proceed to the next step.\nStep 5. Installing Extras (eMMC; WiFi BT module + SMA Antennas; 80mm Fan) The 80mm fan is a worthwhile addition to the NAS Case build\nIf you have additional peripherals, such as an eMMC or WiFi/BT module as well as the 80mm fan, then now is the right time to install them. If you have none of the above, please proceed to step 6 of this guide.\nThe eMMC and WiFi/BT modules are fitted into their respective placements on the ROCKPro64 board - please consult the diagram for their correct installation.\nIf you intend to use external u.FL to SMA antennas in the NAS Case then this is also the time to install them into the case. In the back section of the case at the very top you will find three cut-outs where the SMA antennas can be fitted. Don’t plug the u.FL leads antenna leads into the WiFi/BT module just yet - instead wait until after the disk holding bracket is installed into the case (step 6).\nThe fan should be mounted on the right-hand side of the case. We suggest that the fan is oriented for negative pressure, blowing air out of the case rather than taking air in. (User:AlephNull disagrees and recommends a positive pressure configuration both to allow a filter to be placed over the intake to prevent dust ingress and because the cage on the outlet side of the fan helps keep the wiring for 3.5\u0026quot; disks away from the fan blades). For best cable management results, have the fan power lead face the front of the case so that it can easily be routed to its header located next to GPIO pins on the ROCKPro64. The fan should be secured using 4x long screws (that fasten into bolts) which can be found in the see-through bag supplied with the NAS Case. Plug in the fan at this stage of the installation and route the cable at the bottom of the front of the case.\nStep 6. Installing the HDD / SSD Bracket and Routing Cables Complete assembly of the NAS Case\nTop view of a complete NAS Case Assembly\nInstalling the HDD/SSD bracket into the case and wiring it up is the last step before closing up the case.\nPlace the bracket with the disks installed (from step 4) into the case. The bracket should line up with the guiding bolts and screw holes at the bottom of the case. The section of the bracket that holds 3.5 inches HDDs needs to face the left side of the case (when viewed from front) and should overhang the ROCKPro64 board slightly. T inchese 3.5 inches SATA and power ports should face the right side of the case - where the fan mount inches, while 2.5 inches SATA and power ports should face the front of the case.\nWith the bracket aligned, flip the bottom of the case over while holding the bracket in place. Screw it into place using 4x Phillips head screws that came included with the NAS Case.\nThe last thing remaining before the NAS Case can be screwed shut is routing SATA and power cables:\nFor 3.5 inches HDDs we suggest routing power and SATA cables underneath the drives, whe inchese 2.5 inches HDDs/SSDs would otherwise reside.\nFor 2.5 inches disks you have plenty of routing options as there is much space available. The most obvious route is straight over the disks, where t inchese 3.5 inches HDDs would reside.\nStep 7. Closing the NAS Case and Powering On your NAS Almost there. All that’s left to do is to screw together the NAS Case. Screw in the top front screws first followed by screws on either side of the case. Do the back screws last. There, you are done.\nTo power on your new NAS Case and HDDs all you need to do is to plug in power and Ethernet (This is obviously assuming that you are intending to use it as a NAS or a headless server).\nIO accessibility when the NAS Case is assembled When the NAS Case is assembled and screwed shut these ROCKPro64 IO ports remain accessible:\nMicro SD slot USB 2.0 USB 3.0 and USB type C Power and Reset switches The headphone and microphone jack Gigabit Ethernet port HDMI POT Peripheral On Top (POT)\nPOT Board Recommended PCB Dimension POT board dimension for Pine A64 in DXF format POT board dimension for Pine A64 in PDF format USB/UART Programming/Console Adapter (PMPROG01) Feature Base on Silicon Libs CP2102 Support Virtual COM Port Device Drivers Support USBXpress™ Direct Driver Support With XH 5 pin 2.54mm pitch connector for UART connection Voltage Output on the connection is selectable to either 5V,3.3V or off On board USB-B Connector Receptor Connector J3 can direct insert into Pine A64 Exp-Bus to provide console access to Pine A64 board I/O pin are protected with ESD protector IC. On board 5x2pin connector can direct insert into Pine A64 Exp Bus for UART0 Console access Can use for programming and debugging for Wifi Remote I/O board Related Specification and Document CP2102 Datasheet\nVirtual COM Port Driver\nUSBXpress Driver\nPOT: Veroboard (PMVRB01) Feature Sit on top of Pine A64 board All the header receptor will have extended length pin to allow other POT board to insert on top of it Allow easy access to all the I/O pin on the Pine A64 header On board 4pcs of LED with current limiting resistor all direct connect to I/O pin for status indicator On board 4pcs of Tact switch On board XH5 2.54mm pitch connector for UART0 allow easy connection to USB/UART adapter for console access POT Veroboard on Pine A64\nPOT Veroboard 2 board stack on top of Pine A64\nPOT: Multi I2C Bus (PMI2C01) Feature Sit on top of Pine A64 board All the header receptor will have extended length pin to allow other POT board to insert on top of it Allow easy access to all the I/O pin on the Pine A64 header 2 channel of I2C bus is wire out for easy access I2C bus repeater IC (PCA9517A) are included in each I2C bus to allow connection of more devices on each bus Support 3.3V and 5V I2C bus for each channel separately On Board separated 3.3V supply regulator for 3.3V I2C Bus Each I2C bus pin are protected with ESD protector devices Each channel consist of 4 pcs of XH 4 pin 2.54mm pitch connector and 2 pcs of XH 5 pin 2.54mm pitch connector For the XH 4 pin connector, will consist of GND,SCL,SDA,5V pin For the XH 5 pin connector, will consist of GND,nINT,SCL,SDA,5V pin 5V supplier is direct connect from Pine A64 adapter’s supply thus prevent over loading Pine A64 board The nINT pin will allow peripheral with interrupt pin link back to the Pine A64 I/O pin Related Specification and Document NXP PCA9517A Datasheet\nNXP AN10658 Sending I2C-bus signal via long communication cables\nNXP AN11075 Driving I2C-bus signals over twisted pair cables with PCA9605\nProgram to Enable I2c Port internal pull with full source code\nMulti I2c Bus Schematic\nPOT: Shield Adapter (PMARD01) Adapter for Arduino Shield Separate on board LM1117 3.3V LDO for the Shield Base on Maxim MAX11609 on ADC input. Allow up to 5V analog signal Extra 5V input DC jack socket (suitable for 4.0mm X 1.7mm DC Jack) for extra input power Related Specification and Document https:/ / MAX11609 10bit I2C ADC\nI2C Device: Humidity and Temperature Sensor (PMSDP01) Feature Based on Silicon Labs Si7021 I2C Humidity and Temperature Sensor High Accuracy Temperature Sensor ±0.4 °C (max), –10 to 85 °C 0 to 100% RH operating range Up to –40 to +125 °C operating range On board 3.3V regulator 2pcs of XH 4pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor Related Specification and Document Si7021-A20 Datasheet\nI2C Device: Ambient Light Sensor (PMSAL01) Feature Based on TAOS/AMS TSL2561T I2C Light Sensor Approximates Human Eye Response Programmable Interrupt Function allow user defined upper/lower limit trigger threshold Automatically rejects 50/60Hz lighting ripple Build with 2 channel of photodiode/ADC to allow more accurate calculation of light intensity (in Lux) Can support up to 3pcs of sensor in the same I2C channel On board 3.3V regulator 2pcs of XH 5pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor Related Specification and Document TSL2561T Datasheet\nWiFi Remote I2C (PMWF01A) Feature Based on ESP8266 Wifi chipset Connect to Wifi AP On board chip antenna or U-FL connector for external antenna On board relay contact (TE PCJ-105D3M with 3A 275Vac Contact) with screw type terminal contact to support AC Line On/Off On board 1pc Tact-switch XH 5 2.54mm pitch connector connecting I2C device XH 6 2.54mm pitch connector for GPIO/SPI/PWM output XH 2 2.54mm pitch connector for system power 5V input or output DC Jack socket (suitable for 4.0mm X 1.7mm DC Jack) for system power input UART Port connector ready for on chip programming using USB/UART Programming/Console Adapter (PMPROG01) 2pcs of XH 5pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor Further Detail info on the module can be found at WiFi Remote I2c Quick Start Guide wiki page\nRelated Specification and Document TE PCJ-105D3M Relay Datasheet\nESP8266 Datasheet\nESP8266 forum\nInter Connection Wire Wifi Remote I2c PMWF01A: Wifi Remote I2c Module\nQuick Start Guide Hardware Setup Hardware Setup\nMake sure that the driver for USB/UART Programming/Console Adapter (PMPROG01) is properly install and the PC is detected it as Comm Port. The USB/UART Bridge is base on Silicon Lab CP2012 chipset. USB/UART Programming/Console Adapter (PMPROG01) driver can be Download here Connect the USB/UART Programming/Console Adapter (PMPROG01) to the Wifi Remote I2c Device. You can power-up the WiFI Remote I2c module through the USB Bus for configuration and programming. Place the jumper J2 on USB/UART Programming/Console Adapter (PMPROG01) to 5V output selection.\nSetting Configuration Termite Setup Screen\nHelp Command\nFor windows system, you can use terminal emulator program Termite to configure the device. Make sure the \u0026lsquo;Port\u0026rsquo; setting is refer to the USB/UART Programming/Console Adapter (PMPROG01)\u0026rsquo;s Virtual Comm Port. Follow the setting according to the setup screen capture. (57600Baud 8-N-1) Once Termite configuration is done, press \u0026lsquo;OK\u0026rsquo; to save the setting. On the Wifi Remote I2c Device, Press the configuration button to allow the device to go into configuration mode. Press Config Mode button to go into configuration mode Type \u0026lsquo;help\u0026rsquo; to show the command available for configuration. Type \u0026lsquo;show\u0026rsquo; to list out current configuration. We will use PineA64 as our Wifi Remote I2c module’s server. To Set the PineA64’s IP address in to the device, enter (we will be using IP address 192.168.0.230 as example) server 192.168.0.230 To configure the Wifi AP SSID and Password, (eg SSID=TestingWifi and Password=12345 ) wifi TestingWifi 12345 The SSID and password are case sensitive. Please make sure it is input correctly. Once configuration is done, type \u0026rsquo;exit\u0026rsquo; to exit configuration mode and allow the device to reboot. Please make sure your network is has DHCP server. The WiFi Remote i2c module will be running on DHCP mode and will requesting a IP address from your network’s DHCP server. After reboot, the Red LED indicator will start to blink in fast blinking mode. Once the WiFi Remote I2c module connected to the WiFi Access Point, the LED indicator will go into slow blinking mode. The hardware configuration is done. The next step will be configure the PineWifiServer into your PineA64 board. Setup the PineWifiServer Download the PineWifiServer from the Download Section Copy PineWifiServer xxxxxxxx.gz into your PineA64 with linux on it. (where xxxxxxxx is the version number) Unzip the file using gunzip. Add Execution flag on both of the file by chmod +x PineWifiServer Start the PineWifiServer by ./PineWifiServer Once the server is started, you will notice that the LED indicator on the Wifi Remote I2c Hardware will change from slow blinking to always on. To login into the server, telnet into localhost port 10000 telnet localhost 10000 PineWifiServer Login Screen\nTo show current connect Wifi Remote I2c type \u0026rsquo;list\u0026rsquo; in small capital letter. To see all available command, type \u0026lsquo;help\u0026rsquo;. To exit the console, type \u0026rsquo;exit\u0026rsquo;. Please take note that you are only allow one login simultaneously. The second telnet login will be rejected. Running the WifiAppDemo Download the PineWifiServer from the Download Section Copy WifiAppDemo xxxxxxxx.gz into your same PineA64 board that currently running with PineWifiServer. (where xxxxxxxx is the version number) Unzip both of the file using gunzip. Add Execution flag on both of the file by chmod +x WifiAppDemo before start running the demo application, please logout any telnet session to the PineWifiServer. The demo application will telnet into the PineWifiServer and start polling all the available Wifi Remote I2c device currently connected to the server. The demo application will also poll the I2c port of the hardware for the Ambient Light Sensor and the Temperature/Humidity Sensor if the sensor is connected to the Wifi Remote I2c module. To start the WifiAppDemo, type ./WifiAppDemo The Application will connect the PineWifiServer currently running in the localhost. Example of screen shot with WifiAppDemo polling multiple Wifi Remote I2c with Ambient Light Sensor and Humidity/Temperature Sensor connected on it. The speed for each round of polling is 1 second per poll.\nFirmware Upgrade Hardware Setup Short Jumper S2 on the WiFI Remote I2c module (before power up the board) to allow the board to go in to firmware programming mode.\nHardware Setup\nMake sure that the driver for USB/UART Programming/Console Adapter (PMPROG01) is properly install and the PC is detected it as Comm Port. The USB/UART Bridge is base on Silicon Lab CP2012 chipset. USB/UART Programming/Console Adapter (PMPROG01) driver can be Download here Connect the USB/UART Programming/Console Adapter (PMPROG01) to the Wifi Remote I2c Device. You can power-up the WiFI Remote I2c module through the USB Bus for configuration and programming. Place the jumper J2 on USB/UART Programming/Console Adapter (PMPROG01) to 5V output selection.\nSoftware Setup Download the firmware from the download section and unzip the file. Download the windows Python base Flash Download Tools by Espressif from Espressif website. Setup the ESP Flash Download tools according to the screen short. Make sure that the firmware address is set correctly. Baud rate is set to 115200baud and Com Port is set according to the Virtual Com Port of your PC. Once the ESP Flash Download tool and hardware is setup properly, press the \u0026lsquo;Start\u0026rsquo; button to start the firmware uploading process. After uploading is done, power off and on again the WiFi Remote I2c module to restart the system. Technical Specification Dimension: 47.00mm x 34.00mm Input Voltage: 5V Max. Input Current: 200mA Operating Frequency: 2412MHz-2484MHz Output power of PA for 802.11b: 19.5dBm-21.5dBm Receiver Sensitivity at DSSS, 1Mbps: -98dBm I/O Pin Out Download Program/Driver Termite a simple RS232 terminal Flash Download Tools v2.4 Under Tools Section Silicon Lab CP2102 Virtual COM Port Driver WifiAppDemo.gz PineWifiServer.gz PMWF01A Firmware PMWF01A Firmware Source PineWifiRemoteI2c Server Source.tar.gz Datasheet/Related Information TE PCJ-105D3M Relay Datasheet ESP8266 Datasheet ESP8266 forum ESP8266 Flash Download Tools, Please refer to the Tools section ESP8266 Resources CP2102 Datasheet ","permalink":"/documentation/Accessories/_full/","tags":null,"title":"Accessories (Single Page)"},{"categories":null,"contents":"Accessories Step by Step Guides\nWi-Fi/Bluetooth module: Step by Step Installation Guide Acrylic Open Enclosure: Step by Step Installation Guide If you wish to stack two or more of these enclosures, the screws that serve as feet can be replaced by M8-1.25x16mm grub screws.\n1.25mm is the pitch between threads, and for the M8 (8mm outer diameter) that\u0026#39;s the default pitch, and most are advertised as M8x16mm screws. 16mm is really the minimum workable length to catch both the bottom and top aluminum standoffs, with both washers and the acrylic sheet in between. It\u0026#39;s workable, but if you can get 20mm it\u0026#39;s probably for the best. Images: https://imgur.com/a/Zka1qfb\nSimple 3D Printed Case by Harlandraka 3D printing schematics Sliding 3D Printed Case by Harlandraka 3D printing schematics C4 Labs Case for the Pine Forum thread including instructions 7\u0026quot; LCD Touch Screen Panel: Step by Step Installation Guide Real Time Clock (RTC) battery holder (AAA battery type): Step by Step Installation Guide Real Time Clock (RTC) battery holder (CR-2032 Coin Cell battery type): Step by Step Installation Guide ","permalink":"/documentation/Accessories/Accessories_Step_by_Step_Guides/","tags":null,"title":"Accessories Step by Step Guides"},{"categories":null,"contents":" Add-ons The PinePhone (and PinePhone Pro) is compatible with the official add-on cases, such as the keyboard, the LoRa add-on, the Qi wireless charging add-on and the fingerprint reader add-on. Details can be found under:\nAccessories Keyboard USB The USB-C can be used to power the device, and offers USB2 host and OTG capabilities, and also can make use of the USB-C capability to integrate HDMI signals. Some USB-C hubs are available that offer power throughput, USB connection, an HDMI port and Ethernet connection.\nPogo pins The pogo pins, as visible under the back cover.\nThe PinePhone has six pogo pins on the back allowing for custom hardware extensions such as wireless charging, an IR blaster, a keyboard extension or extended battery case. The pogo pins provide access to an interrupt line, power inputs/outputs and an I2C interface.\nInterrupt SDA SCL DCIN USB-5V GND DCIN and USB-5V are the names used in the schematics. The actual behavior of these pogo pins is not obvious based on their names. DCIN is connected both to the VBUS line of the USB Type-C connector and to the ACIN/VBUS inputs on the PMIC. This means that, depending on a number of factors, DCIN may be at 0 V or 5 V. USB-5V is connected at the output of an LP6226 DC/DC boost converter (5 V), which in turn is fed by the PS output of the PMIC. The boost converter is enabled or disabled by a GPIO output from the A64 SoC, controlled by software (e.g. the Linux kernel). Depending on inputs and decision made by the PMIC, PS may be at the battery voltage (fed \u0026ldquo;directly\u0026rdquo; by the battery through a transistor controlled by the PMIC), or at the \u0026ldquo;USB\u0026rdquo; voltage (fed by the PMIC’s ACIN/VBUS inputs). This means that depending on a number of factors, USB-5V may be at battery voltage (between 3.0 V and 4.3 V), or at 5 V.\nBecause the PinePhone may act as a USB host (providing 5 V at the USB Type-C connector’s VBUS to a connected device) or as a USB device (drawing from a 5 V source on the USB Type-C connector’s VBUS), DCIN is actually not strictly an input nor an output. Some community analysis of the PinePhone schematic (and some testing) indicates that you can connect a 5 V power supply to DCIN in order to power the phone at the PMIC’s ACIN/VBUS inputs (and, as a side effect, charge the battery). This may not be safe to do in all conditions, e.g., when the phone is acting as a USB host to a connected USB device. It should also be safe to use DCIN as a power output from the PinePhone, e.g., when a USB Type-C charger is connected, you can draw current directly from the USB Type-C port’s VBUS, which is provided by the charger. Please note that, when using DCIN as an output from the PinePhone, DCIN isn’t \u0026ldquo;always on\u0026rdquo;; it may be 0 V. It is currently not documented on how much current can be safely drawn.\nUSB-5V should be safe to use as an \u0026ldquo;always on\u0026rdquo; power output from the PinePhone. Depending on a number of factors, voltage may be from 3 V to 5 V; thus, if you are using USB-5V to power your pogo-pins expansion board, you will probably need to use DC/DC converters/regulators as appropriate. USB-5V is on even while the A64 SoC is powered down.\nThe I2C and interrupt lines have pull-ups on the phone side. The I2C lines are pulled up to 3v3 by the phone.\nFor a breakout board see here. For an example project see Martijn’s blog post \u0026ldquo;Making a backcover extension for the PinePhone\u0026rdquo;.\nPINE64 store currently sells the PinePhone Flex Breakout Board. With the pitch being 2.54 mm, this Flex Breakout Board may have leads soldered directly to the contacts for use in a solderless board. A non-soldered solution would be to use a TE AMP Connector that will accept a Flat Flexible Cable 2.54 mm pitch.\nBack cover A step file for the back cover for creating custom cases is freely available here.\nSerial console Pinout of the serial adapter.\nThe PinePhone has a serial port in the headphone connector, it’s activated by the 6th contact on the dipswitch. If the switch is set to \u0026ldquo;on\u0026rdquo;, the headphone connector is in audio mode, if it is set to \u0026ldquo;off\u0026rdquo; it’s in UART mode. The UART serial connection can also be used for communication with other devices from the PinePhone.\nThe UART is 115200n8.\nThe pinout for the serial connector is:\nTip: RX Ring: TX Sleeve: GND You can buy a serial debug cable from the PINE64 Store. The store cable uses a 4 ring plug, as seen in the here, but a 3 ring plug works just as well. The cable uses a CH340 chipset based serial to USB converter, but any 3.3v serial connection can be used. Because it is a \u0026ldquo;host\u0026rdquo;/DTE it means that you need a cross modem cable (Null Modem) with TX on Tip to be connected to RX. A cable like e.g. FTDI TTL-232R-3V3-AJ which has TX on Tip and RX on Ring fits perfectly.\n","permalink":"/documentation/PinePhone/Accessory/","tags":null,"title":"Accessory"},{"categories":null,"contents":"Hardware that is not part of the SoC.\nBattery Lithium Polymer Battery (10,000 mAh; 9,600 mAh in later batches) Monitored by CW2015 which only measures the current voltage; reported state (charging/discharging), capacity (State-Of-Charge), remaining runtime and current are (poor) estimates Display 14.0\u0026quot; 1920x1080 IPS LCD panel Lid closed magnet There is a magnet to detect when the laptop lid is closed, so action can be taken like sleep. This meets up with the Hall sensor on the daughter / small board to detect lid closed.\nThe magnet is located on the LCD panel right side, around 1.5 inches up measure from bottom edge. Webcam Internal USB attached Webcam Audio 3.5mm stereo earphone/microphone plug Built-in microphone Built-in stereo speakers: Oval in design 3 mm high x 20 mm x 30 mm Network WiFi: 802.11 b/g/n/ac Dual band: 2.4Ghz \u0026amp; 5Ghz Single antenna Bluetooth 5.0 Optional NVMe adapter PCIe 1.1, 2.5 GT/s per lane Note that due to errata, PCIe is limited to Gen1. See this commit. Four PCIe lanes, which can not be bifurcated, but can be used with one- or two-lane NVMe cards M keyed, though M+B keyed devices will work too Maximum length for M.2 card is 80mm (M.2 2280). The following sizes will also work: 2230, 2242, 2260 Power: 2.5 W (continuous) Does not support SATA M.2 cards Does not support USB M.2 cards ","permalink":"/documentation/Pinebook_Pro/Features/Additional_hardware/","tags":null,"title":"Additional hardware"},{"categories":null,"contents":"Affiliates of the Pine Store:\nName of shop Country AFK Teknik Sweden (ships worldwide) AmeriDroid Ships to USA/Global/Brazil bitcompact Canada Blinky Parts Germany (ships worldwide) Botland.store Poland (ships to EU) Breadstick Innovations Canada (ships worldwide) Copacetic Design (Pty) Ltd Southern-Africa Datakonsulten Sweden (ships to DK/NO/FI) DREMC Australia (ships AUS/NZ) Droneit Sweden Eleshop.eu Netherlands (Ships to EU) Eleshop.de Germany / Austria Eleshop.nl Netherlands / Belgium Handheld Legend USA (ships worldwide) KeebSupply Germany (ships worldwide) KEEBD.com Australia (ships worldwide) Keycapsss Germany (ships to EU/AUS/Global) Laskakit Czechia (ships to EU) MOKB Store Vietnam Oomipood Estonia (ships to EU) Platima Tinkers Shop Australia (ships worldwide) Testclips Great Britain Typeractive.xyz USA (ships worldwide) URS Electronics USA ","permalink":"/affiliates/","tags":null,"title":"Affiliates"},{"categories":["AI"],"contents":" Generative AI Agent The ALPHA-One is a Generative 7b LLM AI Agent based on StarPro64 board RISC-V based Single Board Computer with 20TOPS(int 8) NPU capability, and preinstalled 64G eMMC module contains 7b Deepseek/Owen LLM build in docker form.\nStores Global Affiliates Documentation ALPHA-One Specifications ","permalink":"/devices/alpha-one/","tags":null,"title":"ALPHA-One"},{"categories":null,"contents":" The ALPHA-One is a Generative 7b LLM AI Agent based on StarPro64 board RISC-V based Single Board Computer with 20TOPS(int 8) NPU capability, and preinstalled 64G eMMC module contains 7b Deepseek/Owen LLM build in docker form.\nThe ALPHA-One\nSoftware Releases Production release build 20250627 Image for 64GB eMMC module This build contains 7b QWen2 LLM. To access the web UI, open http://alpha-one.local:8000/\nDownload:\nDirect download from PINE64 file server File information:\nMD5 (GZip file): d62eeb1645c7b496a0815c4590f798c7 File Size: 18.10 GB User Password eswin eswin Image for 32GB eMMC module and above This is the early test build that contains both 7b Deepseek and QWen2 LLM build, OS is based on ROCKOS. For larger than 32GB eMMC, please use gpart to extend the file partition.\nDownload:\nDirect download from PINE64 file server File information:\nMD5 (GZip file): 6669a436104e97e2ad90679e06f62d78 File Size: 18.21 GB User Password eswin eswin Usage To explore LLM, use terminal program and execute below command lines:\nDeepSeek 7b LLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/deepseek_r1_distill_qwen_7b/config.json Qwen2 7bLLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/qwen2_7b/config.json Qwen2 0.5bLLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/qwen2_0_5b/config.json SDKs The SDK documents can be found under https://files.pine64.org/SDK/StarPro64/docs.7z (some are in Chinese).\nFile information:\nMD5 (7-Zip file): 8ee9b660c336d9979191d212e9826226 File Size: 34 MB SDK Release:\n20250228: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250228.7z (1.932 GB. MD5 checksum of the 7-Zip file is f9171ec8b30e5d4d8eda1185f72af5e4.) 20250330: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250330.7z (1.946 GB. MD5 checksum of the 7-Zip file is 8ddc861755ed26785e67674aad8db87c.) LLM and tools release:\nLLM 20250228: https://files.pine64.org/SDK/StarPro64/deepseek\u0026qwen-v0228.7z (722 MB. MD5 checksum of the 7-Zip file is b8ee72ee6a8912afefac3fa43a18be87) Tools 20250228: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250228.7z (6.625 GB. MD5 checksum of the 7-Zip file is 868434b274412e173c3e264118dcb336) Specifications Main Board and SoC Specification Based on StarPro64 Single Board Computer wiki page Based on ESWIN EIC7700X SoC EIC7700X block diagram\nFeatures System Memory 32GB 64bits LPDDR5@6400MHz RAM Memory. 64GB eMMC preinstalled with 7b Deepseek/Qwen LLM Case CNC from single Aluminum block Passive cooling, built-in heat pipe that directly contact with SoC Network Dual 10/100/1000 Mbps Ethernet 2.4GHz/5GHz MIMO WiFi 802.11 b/g/n/ac/ax with Bluetooth 5.3 Expansion Ports 2× USB3.0 Dedicated Host port 2× USB2.0 Shared Host port Digital Video output up to 4K@60Hz 3.5mm audio Jack with mic in Certifications Not yet available Potential Improvement Current 7bLLM throughput is around 3.5 tokens/second using docker form, potential improve up to 10 tokens/second when operates LLM in native mode. Potential increase LLM capability from 7b to 15b with system software optimization If ALPHA-One proven its potential, consider release ALPHA-Two which can host up to 30b LLM ","permalink":"/documentation/ALPHA-One/_full/","tags":null,"title":"ALPHA-One (Single Page)"},{"categories":null,"contents":"Android Pie 9.0 SDK version 1.0\nDirect download from pine64.org (29.14GB, MD5 of the TAR-XZ file 734B4DBB03CAF82A4E955F7E83DE0C65) ","permalink":"/documentation/PINE_H64_Model_B/Software/Android_SDK/","tags":null,"title":"Android SDK"},{"categories":null,"contents":" Android 11 SDK for Quartz64 model A SBC Download:\nDirect Download from pine64.org Notes:\nMD5 (TAR-GZip file): 77c2ff57ea3372fb04da7fb49e17d12b File size: 79.00 GB Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz ","permalink":"/documentation/SOQuartz/Software/Android_SDK/","tags":null,"title":"Android SDK"},{"categories":null,"contents":"Two Android SDKs are available from Pine64 for RK3566 devices:\nQUARTZ64_SDK_android11 Android 11 SDK For Quartz64 model A SBC and SOQuartz\nDirect Download from pine64.org MD5 (TAR-GZip file): 77c2ff57ea3372fb04da7fb49e17d12b File Size: 79.00GB Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz Android build version: QUARTZ64-model-A_eink.android11_SDK Android 11 eink SDK For PineNote and Quart64 model A SBC\nDirect Download from pine64.org MD5 (TAR-GZip file): 293a550584298de4fb95ceae18103672 File Size: 72.88GB Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz Android build version: Compiling Build machine 64 bit Linux (Manjaro tested) At least 16G RAM At least 250G free storage, preferably SSD based Use a POSIX compliant shell such as bash, not zsh (in Manjaro \u0026ldquo;chsh -s /bin/bash username\u0026rdquo;) Manjaro packages The following packages are needed (install with \u0026ldquo;sudo pacman -S packagename\u0026rdquo;):-\nmake gcc python-pip dtc bison flex cpio unzip zip Once this is done run\npip install pyelftools sudo isn’t needed You will also need libncurses.so.5. The easiest way to install this appears to be using an Arch AUR package.\nEnable AUR pamac install ncurses5-compat-libs don’t use sudo Patches QUARTZ64-model-A_eink.android11_SDK For QUARTZ64-model-A_eink.android11_SDK the following files will need to be updated:-\nrk3566_ebook/u-boot/arch/arm/mach-rockchip/decode_bl31.py rk3566_ebook/u-boot/arch/arm/dts/Makefile rk3566_ebook/u-boot/scripts/dtc/dtc-lexer.l rk3566_ebook/u-boot/scripts/dtc/dtc-lexer.lex.c rk3566_ebook/u-boot/scripts/dtc/dtc-lexer.lex.c_shipped Download link QUARTZ64-model-A_eink.android11_SDK.patches.04112021.tar Only the PineNote target has been tested at this time. Compilation process cd rk3566 (for non eink) cd rk3566_ebook (for eink) source build/envsetup.sh lunch ./build.sh -UCKAu ","permalink":"/documentation/General/Android_SDK_for_RK3566/","tags":null,"title":"Android SDK for RK3566"},{"categories":null,"contents":"The APN setting is the gateway between your carrier’s cellular network and the public Internet. The APN setting - if not set automatically by the user’s OS - has to be set by the user to enable the use of the mobile Internet on the phone.\nSetting the APN The location of the APN setting depend on the user interface the distribution is using.\nGnome One of the biggest actively maintained open (Creative Commons Public Domain) database of mobile broadband service providers and their APN settings is maintained by the Gnome project, and is available in their serviceproviders.xml. It is a rare case, when you don’t find your own provider in that list, but if it happens, then please consider contributing to it upstream. If your provider is in that database, then for setting up the APN, you only have to select your provider from the list under Settings \u0026gt; Network \u0026gt; Network Dropdown \u0026gt; Add new connection.\nFurther details are described by the Gnome help.\nPhosh The APN settings are either located under Settings \u0026gt; Mobile \u0026gt; Access Point Names or Settings \u0026gt; Network \u0026gt; Network Dropdown \u0026gt; Add new connection.\nPlasma Mobile The APN settings are located under Settings \u0026gt; Cellular Networks \u0026gt; SIM 0 \u0026gt; Modify APNs. While this is an auto-detect button, some cell providers may be detected incorrectly. Additionally, the settings for MMS are located under Spacebar \u0026gt; Settings \u0026gt; Multimedia Messages (MMS).\n","permalink":"/documentation/PinePhone/Modem/APN_settings/","tags":null,"title":"APN settings"},{"categories":null,"contents":"This page lists applications and tweaks for the PineNote.\nDevelopment Here are some resources you may find helpful in learning to develop on embedded Linux devices:\nGreat YouTube series introducing you to the kernel and lower-level components of Linux: https://www.youtube.com/watch?v=WiZ05pnHZqM https://embetronicx.com/ https://bootlin.com/training/ https://www.nand2tetris.org Emulator recommendation for developing and testing PineNote apps: https://github.com/michaelshiel/picom-epaper\nThe PineNote is a specialized device, mainly due to the e-ink display having unique display and refresh characteristics. Finding and configuring apps that work well sometimes requires a lot of tweaking and a lot exploring, especially for applications containing fast screen updates and animations, as well as depend on a lot of colors.\nHere is a video showing the performance of a few applications.\nDesktop Environments Sway WinkShell \u0026ldquo;Collected applications, configurations and scripts for using a wlroots-based compositor with an EPD (aka e-ink display). Currently supports Sway only.\u0026rdquo; 0cc4m’s config Getting touch + pen working on sway If you notice that touching the screen works, but when you use the pen the mouse coordinates are inverted, don’t worry! We can fix it! Set rockchip_ebc.panel_reflection=0 on boot (see this page for more info). Add the following line to your sway config:\n# This line rotates the mouse input by 180 degrees. See https://wayland.freedesktop.org/libinput/doc/1.11.3/absolute_axes.html input \u0026#34;type:table_tool\u0026#34; calibration_matrix -1 0 1 0 -1 1 Gnome Gnome on wayland runs nicely on the PineNote. However, a slightly patched version of mutter is required at the moment.\nSee this repository for .deb packages and patch/compile files: Patched Debian Mutter for Bookworm The ready-to-use Debian image provides a pre-configured GNOME environment], with specific GNOME configurations found here A GNOME extension is being developed that provides access to some of the ebc-specific driver options. PNEink is a GNOME Theme for use with the PineNote GTK3 High contrast style for e-ink-devices can be found here.\nGTK4 High contrast style for e-ink-devices can be found here.\nApplication support on the PineNote System-Control A rust-based dbus service is being developed to enable easy, system-wide control over some of the PineNote-specific settings by users and programs (e.g., triggering global screen refreshes, changing waveforms, enabling/disabling dithering). Requires this kernel.\nNotetaking Xournal++ Works well. Version 1.2 version offers repainting-related optimizations and supports PDF highlighting as well as links. To remove artifacts from the eraser set the eraser cursor’s visibility to Never via Preferences -\u0026gt; Stylus -\u0026gt; Eraser Visibility. Also, disable GTK3 intertial scroll via Preferences -\u0026gt; Touchscreen -\u0026gt; Touch Scrolling -\u0026gt; Disable GTK’s built-in intertial scroll, as this interferes with Xournal++\u0026rsquo;s internal touch event handling.\nXournal++ uses anti-aliasing and interpolation, which do not work well for the A1 waveform. Mitigations include using either dithering or black-and-white mode in the ebc driver. https://gitlab.com/hrdl/pinenote-shared/-/blob/main/patches/xournalpp/0001-Disable-anti-aliasing-and-use-NEAREST-interpolation-.patch is an outdated patch that used to work well without changing the bw mode.\nPre-compiled Debian packages with some of the PineNote-related modifications and support for triggering global refreshes after scrolling using the dbus service (see above) can be found here\nObsidian Works well, EInk-Theme can be found here.\nReading Foliate Foliate is an ebook reader written in GTK4. It works well with the default Debian Gnome experience. You can bookmark pages and annotate selections of words/sentences. Foliate supports \u0026ldquo;Open EPUB, Mobipocket, Kindle, FB2, CBZ, and PDF files\u0026rdquo;.\nKOReader KOReader is a document viewer made for e-ink devices. It is a feature packed application, a user can highlight text, bookmark pages, use gesture navigation and change font and page size/margins/spacing among many things. KOReader can also be used as a full screen UI with battery information reporting while reading books. KOReader supports \u0026ldquo;EPUB, PDF, DjVu, XPS, CBT, CBZ, FB2, PDB, TXT, HTML, RTF, CHM, DOC, MOBI and ZIP files\u0026rdquo;.\nWeb Browsing Firefox Pretty good experience! Enabling GPU acceleration is helpful.\nGPU Acceleration in Firefox See 0ccam’s notes here.\nCloud syncthing High contrast theme can be found here.\nGames Generating crosswords There are some scripts here for generating crosswords for the Pinenote from IPUZ files.\n","permalink":"/documentation/PineNote/Development/Apps/","tags":null,"title":"Apps"},{"categories":null,"contents":"Guide on how to get the camera and the LCD working on the SOPINE on Armbian.\nLCD DD the Armbian SOPINE image to the microSD Card and run on the board Login through the terminal vi /boot/armbianEnv.txt (Change off to on): pine64_lcd=on vi /etc/modules (Add following line): gt9xxf_ts reboot Then the display will be on LCD and not HDMI\nCamera DD the Armbian SOPINE image to the microSD Card and run on the board\nLogin through the terminal\nInstall Ubuntu Xenial Mate with ayufan’s script\ncd ~ wget https://github.com/longsleep/build-pine64-image/raw/master/simpleimage/platform-scripts/install_desktop.sh chmod +x install_desktop.sh ./install_desktop.sh mate vi /boot/armbianEnv.txt (Set to \u0026ldquo;s5k4ec\u0026rdquo; or \u0026ldquo;ov5640\u0026rdquo; depending on your camera module)\ncamera_type=s5k4ec vi /etc/modules (Add the following depending on your camera_type \u0026ldquo;s5k4ec\u0026rdquo; or \u0026ldquo;ov5640\u0026rdquo; above. Note that \u0026ldquo;vfe_v4l2\u0026rdquo; has a small letter \u0026lsquo;L'2 not 12)\ns5k4ec vfe_v4l2 reboot\nFollowing https://github.com/avafinger/pine64_camera (Change \u0026ldquo;s5k4ec\u0026rdquo; to \u0026ldquo;ov5640\u0026rdquo; depending on your camera module)\napt-get update apt-get upgrade apt-get remove --purge guvcview apt-get remove --purge libguvcview-1.1-1 modprobe -r -f vfe_v4l2 modprobe -r -f s5k4ec modprobe s5k4ec modprobe vfe_v4l2 ls /dev/video0 dmesg | grep OK sudo apt-get install libmp3lame-dev libx264-dev libpulse-dev libv4l-dev libsdl1.2-dev libgtk-3-dev portaudio19-dev libpng12-dev libavcodec-dev libavutil-dev libudev-dev libusb-1.0-0-dev libpulse-dev libgsl0-dev libv4l-dev cd ~ wget https://raw.githubusercontent.com/avafinger/pine64_camera/master/libguvcview-1.2-1_2.0.3%2Bdebian-1_arm64.deb wget https://raw.githubusercontent.com/avafinger/pine64_camera/master/guvcview_2.0.3%2Bdebian-1_arm64.deb dpkg -i libguvcview-1.2-1_2.0.3+debian-1_arm64.deb dpkg -i guvcview_2.0.3+debian-1_arm64.deb For testing, use Xenial Mate -\u0026gt; Applications -\u0026gt; Sound \u0026amp; Video -\u0026gt; guvcview OR command line\nguvcview -d /dev/video0 -x 640x480 -r sdl -f yu12 guvcview -d /dev/video0 -x 640x480 -r sdl -f nv12 ","permalink":"/documentation/SOPINE/Software/Armbian_LCD_and_camera/","tags":null,"title":"Armbian LCD and Camera"},{"categories":null,"contents":"This article contains notes regarding Armbian on the PineCube.\nGeneral notes GitHub gist for the user patch which pre-installs and configures the motion (detection) package.\nA serial console can be established with 1152008N1 (no hardware flow control). Login credentials are as usual in Armbian (login: root, password: 1234).\nMotion daemon can be enabled using systemctl (With root) systemctl enable motion. Set the video settings in /etc/motion/motion.conf to 640x480 15fps YU12. Then just reboot. Note that motion currently takes considerable resources on the PineCube, so you’ll want to stop it when doing things like apt upgrade and apt update with systemctl stop motion and then systemctl start motion\nSerial connection using screen and the Woodpecker USB serial device First set the Woodpecker’s S1 jumper to 3V3. Then connect the Woodpecker USB serial device to the PineCube. Pin 1 on the PineCube has a small white dot on the PCB - this should be directly next to the micro-USB power connection. Attach the GND pin on the Woodpecker to pin 6 (GND) on the PineCube, TXD from the Woodpecker to pin 10 (UART_RXD) on the PineCube, and RXD from the Woodpecker to pin 8 (UART_TXD) on the PineCube.\nOn the host system which has the Woodpecker USB serial device attached, it is possible to run screen and to communicate directly with the PineCube:\nscreen /dev/ttyUSB0 115200\nSerial connection using screen and Arduino Uno You can use the Arduino Uno or other Arduino boards as a USB serial device.\nFirst you must either remove the microcontroller from it’s socket, or if your Arduino board does not allow this, then you can use wires to jump RESET (RST) and GND to isolate the SOC.\nAfter this you can either use the Arduino IDE and it’s Serial monitor after selecting your /dev/ttyACMx Arduino device, or screen:\nscreen /dev/ttyACM0 115200\nSerial connection using pinephone/pinebook pro serial debugging cable You can use the serial console USB cable for PinePhones and Pinebook Pros at the store. With a female terminal block wire using breadboard wire into the GPIO block at the following locations in a \u0026ldquo;null modem\u0026rdquo; configuration with transmit and receive crossed between your computer and the PineCube:\nS - Ground (to pin 9) R - Transmit (to pin 8) T - Receive (to pin 10) From Linux you can access the console of the PineCube using the screen command:\nscreen /dev/ttyUSB0 115200\nBasic bandwidth tests with iperf3 Install armbian-config:\napt install armbian-config\nEnable iperf3 through the menu in armbian-config:\narmbian-config\nOn a test computer on the same network segment run iperf3 as a client:\niperf3 -c pinecube -t 60\nThe same test computer, run iperf3 in the reverse direction:\niperf3 -c pinecube -t 60 -R\n","permalink":"/documentation/PineCube/Software/Armbian_notes/","tags":null,"title":"Armbian Notes"},{"categories":null,"contents":" Quick Peek of PineCone BL602 RISC-V Evaluation Board by Lup Yuen Documenting the BouffaloLab BL602 firmware image format by MK Connect PineCone BL602 to OpenOCD by Lup Yuen Debug Rust on PineCone BL602 with VSCode and GDB by Lup Yuen Porting Mynewt to PineCone BL602 by Lup Yuen Flashing Firmware to PineCone BL602 by Lup Yuen Control PineCone BL602 RGB LED with GPIO and PWM by Lup Yuen Mynewt GPIO ported to PineCone BL602 RISC-V Board by Lup Yuen PineCone BL602 talks to I2C Sensors by Lup Yuen PineCone BL602 talks SPI too! by Lup Yuen PineCone BL602 Blasting Pixels to ST7789 Display with LVGL Library by Lup Yuen PineCone BL602 Talks UART to Grove E-Ink Display by Lup Yuen The RISC-V BL602 Book by Lup Yuen Connect PineCone BL602 to LoRa Transceiver by Lup Yuen RAKwireless WisBlock talks LoRa with PineCone BL602 RISC-V Board by Lup Yuen PineCone BL602 RISC-V Board Receives LoRa Packets by Lup Yuen Run Rust RISC-V Firmware with BL602 IoT SDK by Lup Yuen PineCone BL602 Talks LoRaWAN by Lup Yuen uLisp and Blockly on PineCone BL602 RISC-V Board by Lup Yuen Simulate RISC-V BL602 with WebAssembly, uLisp and Blockly by Lup Yuen BL602 Bootloader by Lup Yuen Machine Learning on RISC-V BL602 with TensorFlow Lite by Lup Yuen Reverse Engineering WiFi on RISC-V BL602 by Lup Yuen Rust on RISC-V BL602: Is It Sunny? by Lup Yuen Rust on RISC-V BL602: Simulated with WebAssembly by Lup Yuen PineDio Stack BL604 RISC-V Board: Testing The Prototype by Lup Yuen Rust on RISC-V BL602: Rhai Scripting by Lup Yuen LoRaWAN on PineDio Stack BL604 RISC-V Board by Lup Yuen The Things Network on PineDio Stack BL604 RISC-V Board by Lup Yuen Encode Sensor Data with CBOR on BL602 by Lup Yuen IoT Digital Twin with Roblox and The Things Network by Lup Yuen Internal Temperature Sensor on BL602 by Lup Yuen CBOR Payload Formatter for The Things Network by Lup Yuen Monitor IoT Devices in The Things Network with Prometheus and Grafana by Lup Yuen Apache NuttX OS on RISC-V BL602 and BL604 by Lup Yuen SPI on Apache NuttX OS by Lup Yuen LoRa SX1262 on Apache NuttX OS by Lup Yuen LoRaWAN on Apache NuttX OS by Lup Yuen Rust on Apache NuttX OS by Lup Yuen Auto Flash and Test NuttX on RISC-V BL602 by Lup Yuen BL602 EFlash Loader: Reverse Engineered with Ghidra by Lup Yuen Connect IKEA Air Quality Sensor to Apache NuttX OS by Lup Yuen Apache NuttX Driver for BME280 Sensor: Ported from Zephyr OS by Lup Yuen Rust talks I2C on Apache NuttX RTOS by Lup Yuen ST7789 Display with LVGL Graphics on Apache NuttX RTOS by Lup Yuen PineDio Stack BL604 runs Apache NuttX RTOS by Lup Yuen NuttX Touch Panel Driver for PineDio Stack BL604 by Lup Yuen Buttons on BL602 NuttX NuttX GPIO Expander for PineDio Stack BL604 by Lup Yuen (Mostly) Automated Testing of Apache NuttX RTOS on PineDio Stack BL604 RISC-V Board by Lup Yuen Zig on RISC-V BL602: Quick Peek with Apache NuttX RTOS by Lup Yuen Build an IoT App with Zig and LoRaWAN by Lup Yuen Build an LVGL Touchscreen App with Zig by Lup Yuen Read NuttX Sensor Data with Zig by Lup Yuen Visual Programming with Zig and NuttX Sensors by Lup Yuen Visual Programming with Zig and Apache NuttX Sensors (Video) ","permalink":"/documentation/PineCone/Further_information/Articles_and_blogs/","tags":null,"title":"Articles and blogs"},{"categories":null,"contents":" Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. The Pinebook Pro keyboard comes as a pre-assembled unit built into the main shell of the device, a damaged shell had the keyboard removed from it to be studied. Note that removing the keyboard from the shell is technically irreversible since it’s held in with melted plastic rivets. If these ever happen to break then you could likely hold the keyboard in with adhesives or drill small holes and use screws instead.\nThe keyboard is sandwiched between a thick (likely 0.7mm) steel plate and the plastic shell, this steel plate serves as a mounting point for some of the components inside the laptop as well as adding a significant amount of structural rigidity to the device. The actual keyboard is made of a very thin metal backplate, a clear flexible plastic PCB, and a black flexible plastic layer that appears to be removable but more research will need to be done.\nThe key mechanism is a relatively modern style of scissor switch, the upside to this mechanism is that the keys have a very nice feel to them and don’t fall apart easily, the downside is that if the plastic scissor mechanism gets damaged the whole key assembly will start to fall off due to slipping out from under the metal arms in the keyboard backplate. The only known fix is to replace the key assembly, or more likely the entire keyboard mechanism, more research should be done into this.\nOlder style scissor switches allowed you to just pull the keycap straight off the mechanism and snap it back into place by pressing down on it. Do not do this for newer mechanisms like the Pinebook Pro keyboard, all that will do is damage the mechanism.\nRemoving Keys Warning Do not attempt this unless you know what you’re doing, there will be very few cases where this works Keys can be relatively safely removed (however the mechanism can easily be damaged by someone who doesn’t know what they’re doing) when the keyboard assembly has been removed from the shell, however with the shell in place it blocks movement of the keys that is required to unhook the mechanism from the metal backplate.\nTip The keys might be removable without taking the keyboard out of the frame, this needs more research To remove a key, first push it all the way in, slide it upwards slightly, and lift the top half of the key, this should dislodge the upper half of the scissor mechanism, this step can be tricky, the keys were designed to be assembled once and never removed again.\nNext you can just slide the key down slightly, this will dislodge the lower half of the scissor mechanism and the key should come completely off the keyboard.\nRe-attaching a key can be quite fiddly since the mechanism stays attached to the key rather than the keyboard like older scissor designs.\nThe assembly process is the same as disassembly, just reversed, but you have to be careful with horizontal alignment, otherwise the lower half of the mechanism won’t lodge in place.\nNote that if a key mechanism is damaged, pressing in the upper corners of the key will cause it to dislodge and fall off the keyboard.\nDamaged keys might look like this, note that the pin on the lower right side of the mechanism is slightly deformed and the latch on the upper half of the mechanism is bowed out slightly and cracked. This is enough damage to cause the key to pop out when pressed in the upper corners.\n","permalink":"/documentation/Pinebook_Pro/Keyboard/Assembly/","tags":null,"title":"Assembly"},{"categories":null,"contents":"Be very careful here. It is not a \u0026lsquo;pop off\u0026rsquo; cover design. Special care should be directed to AVOID anything that may appear to cause a \u0026ldquo;bend\u0026rdquo; in screen.\nGently use fingernails (or if you have one, plastic pry), starting in the very middle location for each side (saving keyboard connector latch over area (bottom side) for the very last removal step).\nWork your way from the inner middle on each side, slowly. Slide gently towards the direction of each corner (saving the lifting of actual corners themselves for the second to last step). Careful not to break thin speaker wires that line the outside of the inner case.\nThe very last opening piece should be the \u0026ldquo;latch over\u0026rdquo; (where the keyboard pins connect).\nKEEP IN MIND: The main key here is to avoid any potential \u0026ldquo;bend\u0026rdquo; of the screen. We save the corners until after working on the middle of each side to reduce pressure on the screen.\nDo not force anything. If it is not coming off with gentle effort, you are likely doing something wrong (try another side middle).\n","permalink":"/documentation/PineTab/Assembly_and_disassembly/","tags":null,"title":"Assembly and disassembly"},{"categories":null,"contents":"PineVoice implements the open-source Wyoming protocol for voice assistants. Any assistance application supporting this protocol can communicate with PineVoice.\nBefore starting Complete WiFi Setup first. After PineVoice has joined the Wi-Fi network, the center ring LED should slowly breathe in a dim magenta color. This means that PineVoice is connected to Wi-Fi and is waiting for an assistance application to connect through the Wyoming protocol.\nAdding PineVoice to Home Assistant Home Assistant supports Wyoming Protocol devices through the Wyoming Protocol integration. Home Assistant must also have a working Assist voice pipeline. Follow the Home Assistant Assist documentation if Assist has not been configured yet.\nAutomatic setup PineVoice supports mDNS auto-discovery. If Home Assistant can see mDNS announcements on the same network, PineVoice should appear automatically as a discovered Wyoming Protocol device.\nOpen Home Assistant. Go to Settings -\u0026gt; Devices \u0026amp; services. Look for a discovered Wyoming Protocol device. Select Configure. Follow the on-screen instructions to finish adding PineVoice. After setup completes, PineVoice should be available as an Assist satellite in Home Assistant.\nManual setup If PineVoice does not appear automatically, add it manually through the Wyoming Protocol integration.\nFind the IP address of PineVoice in the client list of your Wi-Fi router or access point. Open Home Assistant. Go to Settings -\u0026gt; Devices \u0026amp; services. Select Add integration. Search for and select Wyoming Protocol. Enter the PineVoice IP address as the host. Enter 10700 as the port. Follow the on-screen instructions to finish adding PineVoice. Troubleshooting Important If following bugs occurs:\nPineVoice is stuck in listening state or Home Assistant does not react to start of Assist - restart PineVoice. Device add failed - press Retry / Try Again, or try to add the PineVoice again. Following bugs are being investigated and will be fixed in update of PineVoice firmware or Home Assistant Core.\nIf Home Assistant cannot connect to PineVoice, check the following:\nPineVoice and Home Assistant are on the same network or VLAN. The center ring LED is breathing in dim magenta. The IP address entered in Home Assistant is the current IP address of PineVoice. TCP port 10700 is reachable from the Home Assistant system. mDNS is allowed on the network if using automatic discovery. For more information, see the Home Assistant Wyoming Protocol integration documentation.\nTesting After PineVoice is properly added to an assistance application, assist can be triggered in the following ways:\nSay the wake word: \u0026ldquo;Hey Jarvis\u0026rdquo; Press the center button in the LED ring After triggering assist, say a command supported by the assistance application. The assistance application should then reply accordingly.\n","permalink":"/documentation/PineVoice/Assistance_Setup/","tags":null,"title":"Assistance Setup"},{"categories":null,"contents":" ALSA configuration If you do not have the integrated sound card selected as the default, create /etc/asound.conf with the following contents:\ndefaults.pcm.!card rockchipes8316c defaults.ctl.!card rockchipes8316c If you want to enable software mixing (dmix) by default for all ALSA apps (works without Pipewire or PulseAudio), make /usr/share/alsa/cards/simple-card.conf file contain this:\n# default with dmix/dsnoop simple-card.pcm.default { @args [ CARD ] @args.CARD { type string } type asym playback.pcm { type plug slave.pcm { @func concat strings [ \u0026#34;dmix:CARD=\u0026#34; $CARD \u0026#34;,RATE=44100\u0026#34; ] } } capture.pcm { type plug slave.pcm { @func concat strings [ \u0026#34;dsnoop:CARD=\u0026#34; $CARD \u0026#34;,RATE=44100\u0026#34; ] } } } Pop/click suppression workaround If you’re annoyed by loud popping and clicking sounds, which occur a few seconds after the sound playback stops as a result of the components of the audio chain being turned on and off automatically by the Linux kernel, you can execute the following command manually, or automatically on boot using the tmpfiles.d systemd feature, for example:\necho 50 \u0026gt; /sys/kernel/debug/asoc/rockchip,es8316-codec/dapm_pop_time This is a workaround because it effectively (ab)uses a built-in debugging feature of the Linux kernel’s audio subsystem, and one of the downsides is that a lot of messages are produced in the kernel log whenever the components of the audio chain are turned on and off automatically by the kernel.\nSpeaker polarity workaround On newer Pinebook Pro batches, the inverted built-in speaker polarity issue has been fixed. On these units, the speaker polarity can be made reversed again by the alsa-ucm-conf package, which configures ALSA devices continuously. One workaround would be to remove the package, and the speaker polarity will no longer be set incorrectly. However, this also prevents the built-in speakers from being muted when an output device is plugged into the aux port. Another workaround is to edit file /usr/share/alsa/ucm2/Rockchip/es8316/HiFi.conf and change all instances of R Invert to Normal. This is a workaround because it’s likely to be overwritten and lost if the alsa-ucm-conf package is updated.\n","permalink":"/documentation/Pinebook_Pro/Features/Audio/","tags":null,"title":"Audio"},{"categories":null,"contents":"There are no PINE64 Pinecils sold on AliExpress. They are not made by PINE64. There are no authorized resellers on AliExpress. Some manufacturer has copied the PINE64 company name, trademark and Pinecone logo and is selling a product made to look like Pinecil through many store fronts, but it is not an authentic. They use a different type of box, i.e., a blue or red box. They are fake copies and do not go through the same quality control as PINE64. It is unclear what type of chips or poor quality cloned chips are used in them. They are not recommended. Genuine new PINE64 Pinecil only comes in a black handle color with a green silicone thumb grip. The original V1 always came in a black box. This model was discontinued and has not been made or sold by PINE64 or authorized resellers since July 2022.\nThe current official Pinecil (a.k.a. V2 model) comes in a white box (see Pictures), it has a black color handle with a green silicone thumb grip. If you receive anything that has the PINE64 brand name and Pinecone and does not look like described, it is a fake copy that was not made or authorized by PINE64 or the Pine Store Ltd (see Authenticity Checker below, all real PINE64 Pinecils purchased after Aug. 2, 2022 should pass the checker if they are genuine).\nPinecil V2 Authenticity Checker Pinecil V2 comes with a unique internal ID/Serial number. This allows people to check if the Pinecil V2 is Authentic. To be more sure, update to the newest stable Ralim’s IronOS and check again, see Firmware.\nImportant The Authenticity Checker can be found here. ","permalink":"/documentation/Pinecil/Authenticity/","tags":null,"title":"Authenticity"},{"categories":null,"contents":" Project Homepage Project Source PineTime Implementations FreeRTOS https://www.freertos.org https://sourceforge.net/projects/freertos/ InfiniTime (GitHub: JF002/Pinetime)+ kaythe/pinetime-os Zephyr https://www.zephyrproject.org https://github.com/zephyrproject-rtos/zephyr najnesnaj/pinetime-zephyr\nSuperPrower/pinetime_zephyr_sample_fw\nDejvino/pinetime-hermes-firmware\nendian-albin/pinetime-hypnos\nomegatime watchface mynewt https://mynewt.apache.org/about/ https://github.com/apache/mynewt-core lupyuen/pinetime-rust-mynewt(Discontinued by Creator)\ncaspermeijn/klok MbedOS https://os.mbed.com https://github.com/ARMmbed/mbed-os sethitow/mbed-pinetime\ngeoffrey.vl/mbed-pinetime RIOT http://riot-os.org/ https://github.com/RIOT-OS/RIOT/ bosmoment/PineTime-apps TinyGo https://tinygo.org https://github.com/tinygo-org/tinygo aykevl/go-smartwatch wasp-os (MicroPython) https://wasp-os.readthedocs.io/ https://github.com/daniel-thompson/wasp-os WaspOS PineTime install guide Rust + RTFM https://rtfm.rs/ rtfm-rs/cortex-m-rtfm https://github.com/dbrgn/pinetime-rtfm/ Bare Metal https://github.com/xriss/timecake\nhttps://github.com/Arc13/Pyrus xriss/timecake\nArc13/Pyrus AdaFruit bootloader https://github.com/adafruit/Adafruit_nRF52_Bootloader daniel-thompson/wasp-bootloader Useful drivers https://github.com/sethitow/mbed-pinetime https://github.com/sethitow/mbed-pinetime watchful (rust) https://github.com/lulf/watchful https://github.com/lulf/watchful Project Homepage Project Source PineTime Implementations Gadgetbridge (Android companion app) https://gadgetbridge.org/ https://codeberg.org/Freeyourgadget/Gadgetbridge InfiniTime support in mainline Arduino https://youtu.be/4aFDjymXjOw https://github.com/atc1441/ATCwatch https://github.com/atc1441/ATCwatch OTA Update Flasher / DaFlasher https://youtu.be/gUVEz-pxhgg https://github.com/atc1441/DaFlasherFiles https://github.com/atc1441/DaFlasherFiles InfiniTime companion app for Linux alexr4535/siglo Wasp-os companion app for Linux Siroj42/wasp-companion UI design proposal arteeh/pinetime Flashing app for Linux arteeh/pinetime-flasher Flashing app for Windows ZephyrLabs/PinetimeFlasher ESP32 / ESP8266 SWD WebFlasher https://youtu.be/Iu6RoXRZxOk https://github.com/atc1441/ESP32_nRF52_SWD InfiniTime companion daemon for Linux Elara6331/ITD ","permalink":"/documentation/PineTime/Development/Available_firmware_and_projects/","tags":null,"title":"Available firmware and projects"},{"categories":null,"contents":"The phone ships with a protective plastic sticker between the battery and the phone to protect the device from turning on during shipping. You need to gently open the back cover, then remove the battery and finally remove the sticker and check that the pins aren’t bent. Note: If the battery is stuck inside the phone, the mid screw in the lower part of the midframe needs to be slightly loosened, see here.\nNote The EG25-G modem and the RTL8723CS WiFi and Bluetooth do not work without a battery and with a drained battery, even when enough power is supplied to the PinePhone via the USB Type-C port. Most operating systems won’t boot without a battery or with a drained battery. The supplied battery is meant to be compatible with Samsung part number EB-BJ700BBC / BBE / CBE from the 2015 J7 phone. The extended life aftermarket BBU does fit, although it is a tight fit.\nWarning Using an aftermarket battery with a higher capacity is done at own risk. Batteries with a higher capacity especially in combination with an external charger can lead to overvoltage, which fries the modem and/or the Bluetooth and WiFi chip. The battery terminals, from the nearest to the battery edge to the nearest to the middle of battery, are as follows:\n+ve thermistor -ve not connected The battery includes a protection circuit that isolates it in a number of fault conditions, including if it is discharged too far. The fully discharged battery can be recharged by connecting the phone to a charger with a sufficient output. Once it has charged sufficiently you will be able to boot the phone.\n","permalink":"/documentation/PinePhone/Battery/","tags":null,"title":"Battery"},{"categories":null,"contents":" Note Please note that this Android build solely for PinePhone Pro hardware checking purpose and solely used by support team. This is NOT a general release build. Download:\nDirect download from pine64.org (722MB, for 8GB microSD cards or bigger, MD5 of the GZip file 214e063c8205c1a98d44b2015a21bb5d) Instructions:\nDownload the build, extract the image and dd it to a 8 GB or larger microSD card, takes out the PinePhone Pro Explorer Edition then insert it into microSD slot (upper slot). Insert battery, press RE button (bypass SPI and eMMC boot) while plug in USB-C power. After 3 seconds release RE button. When power up, below battery icon screen show up and battery will start charging. The battery icon display for few seconds and then LCD panel turn off while charging. To check charging status, just quick press power button (about 0.5 second) and battery icon will display progress. ","permalink":"/documentation/PinePhone_Pro/Factory_tests/Battery_charging/","tags":null,"title":"Battery charging"},{"categories":null,"contents":"The PINE64 community chat is connected across multiple platforms: IRC, Telegram, Discord, and Matrix. Each platform has its own unique user base and interface, however they interact with each other through the bot account bridging all platforms.\nThe software to bring all platforms together is called Matterbridge. It acts as the bridge that connects these platforms. It facilitates seamless communication by relaying messages between them. When a user sends a message on any platform (such as IRC), the bot account picks it up. The bot then relays the message to all other connected platforms (such as Telegram, Discord, Matrix). This ensures that users on different platforms can communicate with each other.\nUsers can choose their preferred platform while staying connected to the community.\nA short explanation on how to read the messages The following example can be used to illustrate the use of the bridged community chat:\n[D] \u0026lt;Dave\u0026gt; Hey everyone! Just got my new PinePhone. Loving it so far! 📱 [T] \u0026lt;Eve\u0026gt; Welcome, Dave! We’re discussing the upcoming application updates. [M] \u0026lt;Frank\u0026gt; Hey folks! I’m here from Matrix. Any tips on optimizing battery life? [I] \u0026lt;Ingrid\u0026gt; Greetings! 🌲 I wonder about the same, Frank. [I] \u0026lt;Ingrid\u0026gt; Also, kudos to the PINE64 community for the software progress so far! In this example, the part in the square brackets at the beginning shows the platform, from which each user is writing, [D]iscord, [I]RC, [M]atrix and [T]elegram. The part in the angle brackets contains the name of each user: in this example, Dave, Eve, Frank and Ingrid are chatting with each other.\nThe bot account relaying the message can have a name such as Pine64 Protocol Droid. Mind that this is not the name of the user, who wrote the message.\nThings to consider when using the bridged community chat In the bridged community chat that spans across Discord, Matrix, Element, and IRC, there are several important considerations to keep in mind. These guidelines help ensure smooth communication and prevent unintended issues.\nAvoid editing messages Editing messages may lead to repeated broadcasts across platforms. To maintain clarity and prevent confusion, refrain from editing your messages after they have been sent.\nBe cautious with the Discord and Matrix reply function While Discord and Matrix allows users to reply directly to specific messages, this feature does not translate to other platforms. When responding to messages, avoid using Discord and Matrix reply function, as it does not display properly on the other platforms.\nInstead mention the name of the user you are replying to in your message.\nUse paste services for code and log data Code snippets and log data may not display correctly due to formatting limitations on the bridged community platforms. To share code or logs effectively, consider using paste services (such as Pastebin or GitHub Gists) and provide a link to the content.\nBy adhering to these best practices, you can contribute to a seamless and harmonious experience within the bridged community chat. Happy chatting!\nTelegram images do not appear in IRC When sending images via Telegram, be aware that they do not appear in the IRC channel. If visual content is crucial, consider alternative methods of sharing, such as providing a link to an image hosting service.\nMind file size limits for uploaded files Keep in mind that uploaded files, especially videos, have maximum size limits. If sharing files, verify that they fall within the acceptable size range to ensure successful transmission across all platforms.\nAvoid manual line breaks and long messages Messages with manual line breaks (hard returns) are interpreted as separate messages. To prevent fragmentation, avoid lengthy messages with excessive line breaks.\nLong messages get cut off. To ensure complete communication, keep your messages concise and within reasonable length.\nUnderscores can cause formatting issues Underscores (_) in texts (for example as part of web links) can cause formatting issues due to being interpreted as command to write a text in italic. This sometimes causes links to not properly display and work across the bridge.\n","permalink":"/community/bridged_chat_notes/","tags":null,"title":"Best practices for navigating the bridged community chat"},{"categories":null,"contents":" CPU:\n32-bit RV32IMAFC RISC-V \u0026ldquo;SiFive E24 Core\u0026rdquo; SiFive E24 Core information Memory:\n128KB ROM 276KB SRAM 1Kb eFuse 2MB Embedded Flash Security:\nSecure boot Secure debug AES 128/192/256 SHA-1/224/256 TRNG (True Random Number Generator) PKA (Public Key Accelerator) Wireless:\nWi-Fi 802.11 b/g/n Bluetooth® Low Energy 5.0 Wi-Fi Fast connection with BLE assistance Wi-Fi and BLE coexistence Wi-Fi Security WPS/WEP/WPA/WPA2/WPA3 STA, SoftAP and sniffer modes Multi-Cloud connectivity 2.4 GHz RF transceiver Integrated RF balun, PA/LNA Package Type:\n32 pin QFN 4mm x 4mm JTAG support:\nSee below for BL602 impact ","permalink":"/documentation/PineCone/Further_information/BL602_specifications/","tags":null,"title":"BL602 specifications"},{"categories":null,"contents":"This page is under construction, but aims to get you more familiar with Bluetooth and how the PineTime utilizes it\nPineTime Bluetooth LE agreements These are aimed for firmware developers primarily, and should describe how to design your firmware to be interoperable with the rest.\nFirmware versioning for companion apps External references Uncovering Privacy Leakage in BLE Network Traffic of Wearable Fitness Trackers - http://phpathak.com/files/hotmobile-fitness.pdf Protecting Privacy of BLE Device Users - https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_fawaz.pdf Bluetooth: With Low Energy Comes Low Security - https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan Introduction to Bluetooth Low Energy development - https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/introduction-to-bluetooth-low-energy-and-ble-devel ","permalink":"/documentation/PineTime/Software/Bluetooth/","tags":null,"title":"Bluetooth"},{"categories":null,"contents":" The Pinebook Pro’s AP6256 wireless module\nHardware Overview The Pinebook Pro contains an AMPAK AP6256 wireless module to provide Wi-Fi (compliant to IEEE 802.11ac) and Bluetooth (compliant to Bluetooth SIG revision 5.0). The module contains a Broadcom transceiver IC, believed to be the BCM43456, as well as the support electronics needed to allow the Wi-Fi and Bluetooth modes to share a single antenna.\nThe wireless module interfaces with the Pinebook Pro’s system-on-chip using a combination of three interfaces: Bluetooth functionality is operated by serial UART and PCM, while the Wi-Fi component uses SDIO. It is unknown if the module’s Bluetooth capabilities are usable under operating systems that do not support SDIO.\nThe module’s RF antenna pin is exposed on the mainboard via a standard Hirose U.FL connector, where a coaxial feedline links it to a flexible adhesive antenna situated near the upper right corner of the Pinebook Pro’s battery. As the RF connector is fragile and easily damaged, it should be handled carefully during connection and disconnection, and should not be reconnected frequently.\nIssues Problems have been reported with the Wi-Fi transceiver’s reliability during extended periods of high throughput, especially on the 2.4 GHz band. While the cause of this has yet to be determined, switching to the 5 GHz band may improve stability.\nSince the Bluetooth transceiver shares both its spectrum and antenna with 2.4 GHz Wi-Fi, simultaneous use of these modes may cause interference, especially when listening to audio over Bluetooth. If Bluetooth audio cuts out frequently, switching to the 5 GHz band – or deactivating Wi-Fi – may help.\nWi-Fi Capabilities Wi-Fi on the Pinebook Pro is capable of reaching a maximum data transfer rate of approximately 433 megabits per second, using one spatial stream. The transceiver does not support multiple spatial streams or 160-MHz channel bandwidths.\nThe Wi-Fi transceiver supports the lower thirteen standard channels on the 2.4 GHz band, using a bandwidth of 20 MHz. At least twenty-four channels are supported on the 5 GHz band, spanning frequencies from 5180 to 5320 MHz, 5500 to 5720 MHz, and 5745 to 5825 MHz, with bandwidths of 20, 40, or 80 MHz. This might vary depending on the country you specify in the wireless settings, see iw reg get; iw list.\nMaximum reception sensitivity for both bands is approximately -92 dBm. The receiver can tolerate input intensities of no more than -20 dBm on the 2.4 GHz band, and no more than -30 dBm on the 5 GHz band. Maximum transmission power is approximately +15 dBm for either band, falling further to approximately +10 dBm at higher data transfer rates on the 5 GHz band.\nWith current available drivers and firmware, the Wi-Fi interface supports infrastructure, ad-hoc, and access-point modes with satisfactory reliability. Monitor mode is not presently supported. Wi-Fi Direct features may be available, but it is unclear how to make use of them under Linux.\nBe aware that Linux userspace utilities, such as iw, may report inaccurate information about the capabilities of wireless devices. Parameter values derived from vendor datasheets, or direct testing, should be preferred to the outputs of hardware-querying tools. That said, if a certain feature is not reported by iw it means the currently running kernel driver plus firmware combination doesn’t support it, even when the hardware is capable.\nWPA3 PSK support should be possible with iwd but not wpa_supplicant, see this ticket for details.\nBluetooth Capabilities Bluetooth data transfer speeds have an indicated maximum of 3 megabits per second, but it is unclear what practical data rates can be expected. Audio streaming over Bluetooth is functioning normally, as is networking. Bluetooth Low-Energy functions, such as interacting with Bluetooth beacons, have not yet been tested conclusively.\nThe Bluetooth transceiver supports all 79 channel allocations, spanning frequencies from 2402 MHz to 2480 MHz. Reception sensitivity is approximately -85 dBm, with a maximum tolerable reception intensity of -20 dBm. Bluetooth transmission power is limited to +10 dBm.\nDisabling Bluetooth To disable Bluetooth under Linux once:\nsudo rfkill block bluetooth To confirm if Bluetooth under Linux is disabled:\nrfkill To disable Bluetooth on boot (NOTE: for distributions such as Manjaro XFCE see the step below):\nsudo systemctl enable rfkill-block@bluetooth To disable Bluetooth on certain distributions, such as Manjaro XFCE, right click on the Bluetooth panel icon, select plugins, then PowerManager, then configuration and then deselect the auto power on option\n","permalink":"/documentation/Pinebook_Pro/Features/Bluetooth_and_WiFi/","tags":null,"title":"Bluetooth and WiFi"},{"categories":null,"contents":" Layout Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm\nVideo Digital Video (Type A - full) Audio 3.5mm stereo earphone/microphone plug Network 10/100/1000Mbps Ethernet(PINE A64+ version), 10/100Mbps Ethernet(PINE A64 version) WiFi 802.11 b/g/n with Bluetooth 4.0 (optional) Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t2 USB2.0 Host port Expansion ports DSI - Display Serial Interface, 4 lanes MiPi, up to 1080P CSI - CMOS Camera Interface up to 5 mega pixel TP - Touch Panel Port, SPI with interrupt RTC - Real Time Clock Battery Connector VBAT - Lithium Battery Connector with temperature sensor input Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 2x17 pins \u0026ldquo;Euler\u0026rdquo; GPIO Header 2x5 pins \u0026ldquo;EXP\u0026rdquo; Console Header Power Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, 3.5OD/1.35ID Barrel DC Jack connector, Euler connector\n","permalink":"/documentation/Pine_A64-LTS/Board_features/","tags":null,"title":"Board features"},{"categories":null,"contents":" Layout Board Dimensions: 133mm x 80mm x 19mm\nBoard layout\nLabel Description 1 Touch panel connector 2 Camera port connector 3 PI 2 bus 4 3 pin connector for Lithium battery 5 2 pin RTC battery port 6 2x USB 2.0 Host Port 7 for Reset button 8 for Power OFF/ON button 9 Wi-Fi / Bluetooth port 10 IR receiver 11 Headphone jack (with microphone) 12 microSD card slot 13 Exp bus 14 Euler \u0026ldquo;e\u0026rdquo; bus 15 DSI connector 16 +5V microUSB DC power jack 17 Ethernet port 18 Digital Video Type A port Video Digital Video Port (Type A - full) Audio 3.5mm stereo earphone/microphone plug Network 10/100/1000 Mbps Ethernet (PINE A64+ version), 10/100 Mbps Ethernet (PINE A64 version) WiFi 802.11 b/g/n with Bluetooth 4.0 (optional) Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t2 USB2.0 Host port Expansion Ports DSI - Display Serial Interface, 4 lanes MiPi, up to 1080P CSI - CMOS Camera Interface up to 5 mega pixel TP - Touch Panel Port, SPI with interrupt RTC - Real Time Clock Battery Connector VBAT - Lithium Battery Connector with temperature sensor input Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 2x17 pins \u0026ldquo;Euler\u0026rdquo; GPIO Header 2x5 pins \u0026ldquo;EXP\u0026rdquo; Console Header Power Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, microUSB connector, Euler connector\n","permalink":"/documentation/Pine_A64/Board_features/","tags":null,"title":"Board features"},{"categories":null,"contents":" The ROCK64 and a size comparison\nVideo Digital Video output up to 4K@60Hz 4K HDR @ 60fps H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4Kx2K @ 60fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4Kx2K @ 60fps VP9, up to 4Kx2K @ 60fps MPEG-1, ISO/IEC 11172-2, up to 1080P @ 60fps MPEG-2, ISO/IEC 13818-2, SP@ML, MP@HL, up to 1080P @ 60fps MPEG-4, ISO/IEC 14496-2, SP@L0-3, ASP@L0-5, up to 1080P @ 60fps VC-1, SP@ML, MP@HL, AP@L0-3, up to 1080P @ 60fps MVC is supported based on H.264 or H.265, up to 1080P @ 60fps Audio 3.5mm A/V Jack (Composite Video Output and RCA Stereo support using conversion cable) Network 10/100/1000Mbps Ethernet WiFi 802.11 b/g/n with Bluetooth 4.0 (optional USB dongle) Storage microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable (optional eMMC Module) 128Mbit (16MB) on-board SPI flash memory (empty by default) - bootable? Usually accessible as a Linux MTD device at /dev/mtd0 1 USB3.0 Dedicated Host port 2 USB2.0 Dedicated Host port (top one is USB-OTG) Position of the two-pin header for disabling the optionally installed eMMC module (highlighted in red)\nPosition of the two-pin header for disabling the optionally installed eMMC module (highlighted in red)\nOptionally installed eMMC module can be disabled by placing a jumper onto the two pins on the separate two-pin header, located near one of the mounting holes and two side-mounted buttons. See the picture in this section, in which this two-pin header is highlighted in red.\nExpansion Ports All GPIO pins, including UART, operate at 3.3V. (See VCCIO5 in the schematics.)\n2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 2x11 pins \u0026ldquo;Pi P5+\u0026rdquo; GPIO Header (with 2nd 10/100Mbps Ethernet pins) ","permalink":"/documentation/ROCK64/Board_features/","tags":null,"title":"Board features"},{"categories":null,"contents":" Board layout Board map of connectors with schematic v1.1 identifiers:\nSTAR64 board layout\nFeatures The STAR64 board\nVideo Digital Video output up to 4K@30Hz 4K HDR @ 60fps H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4K×2K @ 60fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4K×2K @ 60fps Audio 3.5mm audio Jack Network Single or Dual 10/100/1000 bps Ethernet 2.4GHz/5Ghz MIMO WiFi 802.11 b/g/n/ac with Bluetooth 5.2 Storage on-board 128Mbit (16MByte) XSPI NOR flash memory - bootable microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable (optional eMMC Module) 1× USB3.0 Dedicated Host port 3× USB2.0 Host port Expansion Ports PCIe 2.0 ×1 lane 2×20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header The JH7110 SoC supports full multiplexing of its GPIO pins. This means any non-power/ground pin can be configured to any function outlined in Table 4-2 of the SoC datasheet. 4 lane MiPi DSI port for LCD panel 4 lane MiPi CSI port for camera module ","permalink":"/documentation/STAR64/Board_features/","tags":null,"title":"Board features"},{"categories":null,"contents":" Dimensions Board dimensions: 133mm x 80mm x 19mm\nPower Input power: DC 5V @ 3A, 3.5mm OD/ 1.35mm ID DC jack connector, Euler connector\nVideo Digital Video 4KP60 (Type A - full) Audio 3.5mm stereo earphone/microphone plug Network 10/100/1000 Mbps Ethernet WiFi 802.11 b/g/n/ac with Bluetooth 4.0/4.1 (optional) Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t1 USB3.0 Host port and 2 USB2.0 Host port Expansion Ports RTC - Real Time Clock Battery Connector Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header mini PCIe connector SoC and memory specifications The PINE H64 Model A is based on the Allwinner H6.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1488Mhz footnote:[see Cortex-A53 on arm.com] A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Trustzone technology supported Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions (LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali T-720MP2 Dual-core GPU footnote:[see Mali-T720 on arm.com] Supports OpenGL ES 3.1/3.0/2.0/1.1, OpenCL 1.2/1.1 Supports ATSC (Adaptive Scalable Texture Compression) Supports FAST (4x) FSAA, IO Coherency Floating point operation greater than 70 GFLOPS System Memory RAM Memory Variants: 1GB, 2GB, and 3GB LPDDR3. Storage Memory: PINE H64 boards have a built-in 128Mb SPI Flash memory and can use bootable eMMC modules, bootable microSD cards or USB-attached storage. ","permalink":"/documentation/PINE_H64_Model_A/Board_Features/","tags":null,"title":"Board Features"},{"categories":null,"contents":" Dimensions Board dimensions: 85mm x 56mm x 18.8mm\nPower Input power: DC 5V @ 3A, 3.5mm OD/ 1.35mm ID DC jack connector\nVideo Digital Video 4KP60 (Type A - full) Audio 3.5mm stereo earphone/microphone plug Network 10/100/1000 Mbps Ethernet WiFi 802.11 b/g/n/ac with Bluetooth 4.0/4.1 MHF1 RF coaxial connector for external BT/wifi antenna Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t1 USB3.0 Host port and 2 USB2.0 Host port Expansion Ports RTC - Real Time Clock Battery Connector Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 3x3 pins \u0026ldquo;EXT\u0026rdquo; Header giving console, power switch and reset switch access Console The console UART is available on the 6-pin header connector between the HDMI and headphone jacks. The pins are on the front row, closer to the board’s edge: TX, RX, GND, from left (HDMI) to right (headphone). The default standard is 8,n,1 at 115200bps. SoC and memory specifications The PINE H64 Model B is based on the Allwinner H6.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1488Mhz footnote:[see Cortex-A53 on arm.com] A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Trustzone technology supported Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions (LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali T-720MP2 Dual-core GPU footnote:[see Mali-T720 on arm.com] Supports OpenGL ES 3.1/3.0/2.0/1.1, OpenCL 1.2/1.1 Supports ATSC (Adaptive Scalable Texture Compression) Supports FAST (4x) FSAA, IO Coherency Floating point operation greater than 70 GFLOPS System Memory RAM Memory Variants: 1GB, 2GB, and 3GB LPDDR3. Storage Memory: PINE H64 boards have a built-in 128Mb SPI Flash memory and can use bootable eMMC modules, bootable microSD cards or USB-attached storage. ","permalink":"/documentation/PINE_H64_Model_B/Board_Features/","tags":null,"title":"Board Features"},{"categories":null,"contents":"The board can boot from the following interfaces:\nSPI eMMC SD/MMC TODO: in which priority / order are those boot options tried ?\nTODO: Add unbricking informations (for example: can the SPI be rewritten with rkdeveloptool)\n","permalink":"/documentation/QuartzPro64/Boot/","tags":null,"title":"Boot"},{"categories":null,"contents":"The RK3399S processor in the PinePhone Pro searches for the bootloader (such as U-Boot or Tow-Boot) in the following order:\nSPI flash eMMC (the internal memory) MicroSD card Boot from microSD card temporarily To temporarily boot from an inserted microSD card do the following:\nOn the Explorer Edition ordered after November 2023 the microSD card is first in boot order due to using rk2aw instead of Tow-Boot, see here. A boot menu can be opened by holding power at boot for not too long. On the Explorer Edition ordered after July 2022 hold the volume down key while powering on the device. The batches bought after July 2022 come with Tow-Boot flashed to the SPI, which offers additional functionality over U-Boot as bootloader. On the Explorer Edition ordered between January and July 2022 hold the RE button underneath the cover for a few seconds, while powering on the device. If the button is labeled RESET instead of RE please verify if the device is a regular PinePhone (or the Developer Edition). This is required because older batches don’t ship with Tow-Boot on the SPI. Flashing Tow-Boot can be caught up by following this instruction. Note: If Tow-Boot is flashed later, the microSD card can be selected at boot with the volume down key as well. On the Developer Edition (sold to selected developers only) the SPI and the eMMC can be bypassed by shorting the bypass test points while booting. The process is explained in the article PinePhone Pro Developer Edition. Please join the community chat for any questions regarding the process. The RE button disables the SPI and the eMMC at the hardware level while the button is held and the PinePhone Pro will try to boot from the next available boot medium, which is the microSD card. Note: When holding the RE button (or when shorting the contact points in case of the Developer Edition) for a longer time at boot the operating system will not initialize the SPI and eMMC and it will not be possible to write to these storage mediums until the next reboot.\nNote The bootloader uses its own boot order for loading the kernel and other core operating system components at boot, which for example may result in the boot loader residing on the eMMC loading and booting the kernel from a microSD card. Boot from microSD card permanently The bootloader (such as U-Boot) resides in the free space in front of the first partition. Wiping the bootloader from the eMMC to make the PinePhone Pro boot from microSD card can be done using sudo dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=400 conv=fsync. Formatting the drive or deleting the partition table is not sufficient to wipe the bootloader.\n","permalink":"/documentation/PinePhone_Pro/Software/Boot_order/","tags":null,"title":"Boot order"},{"categories":null,"contents":"The PinePhone always boots from the microSD card first. It is therefore recommended to have a microSD card handy. It is not possible to lock themself out of the phone when the installation on the internal storage (the eMMC) fails, as a correctly flashed microSD card will always boot. Note: Booting from USB is not supported by the hardware, a live USB stick will not boot.\nThe phone will also try to boot from microSD cards, which were previously flashed with an OS and formatted later, causing the phone to fail to boot. See reuse microSD card on how to format the microSD card properly, including wiping the residues of u-boot.\n","permalink":"/documentation/PinePhone/Installation/Boot_priority/","tags":null,"title":"Boot priority"},{"categories":null,"contents":" The PineBook Pro eMMC module and switch, shown in \u0026rsquo;enabled\u0026rsquo; position\nBoot sequence details The RK3399’s mask 32KB ROM boot code looks for the next stage of code at byte off-set 32768, (sector 64 if using 512 byte sectors). This is where U-Boot code would reside on any media that is bootable, RK3399 boot sequence\nBoot devices The Pinebook Pro is capable of booting from eMMC, USB 2.0, USB 3.0, or an SD card. It cannot boot from USB-C. The boot order of the hard-coded ROM of its RK3399 SoC is: SPI NOR, eMMC, SD, USB OTG.\nAt this time, the Pinebook Pro ships with a Manjaro + KDE build with u-boot on the eMMC. Its boot order is: SD, USB, then eMMC.\n(An update has been pushed for the older Debian + MATE build that improves compatibility with booting other operating systems from an SD card. In order to update, fully charge the battery, establish an internet connection, click the update icon in the toolbar, and then reboot your Pinebook Pro. Please see this log for details.)\nPlease note that PCIe, the interface used for NVMe SSD on the Pinebook Pro, is not bootable on the RK3399 and therefore is not a part of the boot hierarchy. It is possible to run the desired OS from NVMe by pointing extlinux on the eMMC to rootfs on the SSD. This requires U-Boot, the Kernel image, DTB, and extlinux.conf in a /boot partition on the eMMC.\neMMC information The eMMC appears to be hot-pluggable. This can be useful if trying to recover data or a broken install. Best practice is probably to turn the eMMC switch to off position before changing modules. Note that the enable/disable label on the silkscreen is incorrect on some board revisions (known bad on v2.1).\nThe eMMC storage will show up as multiple block devices:\nmmcblk1boot0 - eMMC standard boot0 partition, may be 4MB mmcblk1boot1 - eMMC standard boot1 partition, may be 4MB mmcblk1rpmb - eMMC standard secure data partition, may be 16MB mmcblk1 - This block contains the user areas Only the last is usable as regular storage device in the Pinebook Pro. The device number of \u0026ldquo;1\u0026rdquo; shown above may vary, depending on kernel.\nIf the eMMC module is enabled after boot from an SD card, you can detect this change with the following commands as user \u0026ldquo;root\u0026rdquo;:\necho fe330000.mmc \u0026gt;/sys/bus/platform/drivers/sdhci-arasan/unbind echo fe330000.mmc \u0026gt;/sys/bus/platform/drivers/sdhci-arasan/bind (Note: with the device trees coming with older kernels (Linux \u0026lt; 5.11), the device name may be fe330000.sdhci instead of fe330000.mmc)\n","permalink":"/documentation/Pinebook_Pro/Features/Bootable_storage/","tags":null,"title":"Bootable storage"},{"categories":null,"contents":" Warning This page is only relevant for the first batch of PineNotes (December 2021)! The second batch of PineNotes (October 2024) come with Linux pre-installed! To boot Linux, the stock U-Boot has to be patched.\nHere the method from charasyn is used, based of work from Dorian as credited in the script. We’ll use the script to pull the U-Boot environment out of the stock U-Boot partition. We’ll then apply the patch, recreate the image, add a configuration file, and flash the new image to the PineNote.\nSteps to patch U-Boot Get the patch and the Python tool:\n$ mkdir pinenote-uboot \u0026amp;\u0026amp; cd pinenote-uboot $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/boot-menu.patch -o boot-menu.patch $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/pinenote-uboot-envtool.py -o pinenote-uboot-envtool.py $ chmod o+x pinenote-uboot-envtool.py Write your U-Boot partition to an image file: dd if=/dev/mmcblk0p1 of=~/uboot.img\nExtract the environment: ./pinenote-uboot-envtool.py extract uboot.img uboot.env\nPoke around the files (or skip this if you don’t like to learn):\nOpen uboot.env \u0026ndash; see, it’s just text at this point!\nOpen boot-menu.patch to get a feel for how that works\nThe boot-menu.patch makes assumptions about where your Linux partition lives. Specifically, it will look at partition 0x11 (which is 17 in decimal). Change this in boot-menu.patch to reflect where your Linux boot partition lives.\nApply boot-menu.patch: patch uboot.env boot-menu.patch\nNote Note: Might fail with the following error: \u0026ldquo;patch: ****** unexpected end of file in patch at line 27\u0026rdquo;. In that case applying the patch manually is the solution. Rewrite the new environment to the image: ./pinenote-uboot-envtool.py insert uboot.img uboot.env uboot-patched.img Write the image to the boot partition from the PineNote: dd if=~/uboot-patched.img of=/dev/mmcblk0p1 At this point, restarting your system will boot into Android \u0026ndash; this is because the patched U-Boot we’ve just created looks for /boot/which_os.txt to determine whether to boot Android or Linux, and since it can’t find this file (we haven’t made it yet), the bootloader defaults to Android. Create that file on the same boot partition you specified in the boot-menu.patch file, placing an l in the file for Linux. Reboot into Linux Sources and further reading U-boot with rockchip docs Helpful stack overflow to learn a bit about the boot process/terminology This conversation in matrix between pgwipeout, vveapon, and pinenewb about flashing U-Boot. ","permalink":"/documentation/PineNote/Development/Booting_Linux/","tags":null,"title":"Booting Linux"},{"categories":null,"contents":"Discussion by the user JF:\nRequest for comments In this page, I explain the changes and improvements I would like to implement to the MCUBoot bootloader to make it more reliable, and to allow bootloader upgrade and switch (mcuboot \u0026lt;-\u0026gt; wasp-bootloader, for example). I try to explain why I made these choices too.\nDo not hesitate to edit this page and add a new section if you want to add any comment to these points (if you agree, disagree, want to try something else).\nIntroduction This pages describes the improvements I propose to make to the bootloader and OTA to make the whole process more reliable.\nMy goals are:\nKISS: Keep It Stupid Simple. Simple code contains less bugs than complicated/complex code. As reliable as possible. 100% reliability is not feasible with the current hardware (no physical reset button, no bootloader in ROM code), but let’s try to reach 99.9% reliability Provide a read-only factory image we’ll be able to restore in case of unrecoverable errors during OTA Provide a way to upgrade the bootloader Provide a way to switch from MCUBoot to NRF bootloaders Current memory map Pinetime Devkit0 is using a nRF52832-QFAA MCU with 512kB flash and a XT25F32B SPI NOR external flash with 4096kB.\nInternal flash (512Kb):\nPage size is 4Kb. Bootloader contains the MCUBoot bootloader. Boot log is currently not used. Can be use to provide reboot logs to the application App is the PRIMARY SLOT for MCUBoot: the firmware that is currently running. Scratch is used by MCUBoot as temporary storage for swap operation External flash (4096Kb):\nPage size is 256 bytes. Bootloader assets: boot logo OTA: SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored. FS: space available for the application firmware. This memory map allows a strong boundary between the bootloader and the application :\nThe bootloader is ran by the MCU at reset time and loads its boot logo from the SPI flash The bootloader (MCUBoot) swaps images from primary and secondary slots if necessary The bootloader starts the watchdog The bootloader jumps to 0x8000 to run the application The application don’t know anything about the bootloader except that:\nit must be linked @0x8000 it must refresh the watchdog periodically it must store the image for OTA at a specific location in the external SPI flash memory In this configuration, the boot logo is part of the bootloader, not of the application: the same logo will be displayed whatever application firmware will be loaded.\nChanges Factory image The factory image is a \u0026rsquo;light\u0026rsquo; build of InfiniTime that contains the bare minimum code to provide OTA to the user: basic UI, BLE and OTA. No apps, no fancy functionalities.\nThis factory image will be stored in the \u0026ldquo;bootloader assets\u0026rdquo; area of the external flash memory.\nThis factory image will be restored either automatically, when the bootloader detect it cannot boot from primary slot (App in internal memory) and secondary slot (OTA from exeternal). The user can also request to restore this factory image if necessary (using the button?).\nBootloader assets Graphics can be compressed using a simple RLE encoding. RLE encoding on 1 bits (2 colors images) is very efficient (115200KB -\u0026gt; 1-5KB).\nIn order to simplify the code, the graphics will be stored into the bootloader code instead of storing them into the external flash:\nLess code. Easier to document: 1 specific logo = bootloader mode Do not have to worry about the dynamic size of the logo (the binary size of the graphics will vary with the content when they are RLE encoded). Bootloader Display the bootloader version on the screen and expose the version to the application firmware Provide a way to revert the firmware to the last working version AND to the factory firmware Display status and progression (progress bar similar to wasp-reloader, color code) Test as much as possible Bootloader workflow Upgrade \u0026amp; Reloader The reloader is a tool that allows to upgrade the current version of the bootloader AND to switch from MCUBoot to NRF and vice versa.\nHow does it work? Upgrade The reloader is first OTAed like any firmware upgrade. When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader upgrade the current bootloader and resets the system. It does NOT flag the image as validated. It resets the MCU. The new version of MCUBoot notice that the last upgrade is not validated and reverts to the firmware that was running just before. Voilà, you’re running your firmware and a new version of the bootloader Switch bootloader The reloader is first OTAed like any firmware upgrade. When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader overwrite the current bootloader with a new one and reset. The new bootloader is running. Switch From InfiniTime to wasp-os: the reloader contains the NRF Bootloader and Softdevice. This bootloader provides the OTA mecanism out of the box. Wasp-os is downloaded when the NRF bootloader is running From wasp-os to InfiniTime: the reloader contains the factory image (infinitime-factory). The complete version of InfiniTime will be OTAed when this factory image is running. Discussions Boot Logo: embedded into the bootloader binary vs stored in the external SPI flash Embedding (and compressing) the boot logo inside the bootloader binary brings many advantages:\nAll the data are available in memory at runtime. No need to load them \u0026amp; check them, and no need to handle errors and invalid corrupted data. The data is available and can be sent directly to the display controller 1 unique logo for the bootloader: easier to document and explain to the user that this specific logo is the logo from the bootloader mode. But it also has some disadvantages:\n1-Bit RLE encoding (very effective compression) allows only 2 colors (background/foreground) The boot logo cannot be customized (unless you recompile and flash this new build of the bootloader) The size of the boot logo is limited (depending on the compression ratio) My (JF) point is that the bootloader must be as reliable as possible. I would like to remove all part of the code than can fail. If we read the boot logo from the SPI flash, we will write something like this:\nint ret; boot_logo_info info; ret = SpiNor_read(infoOffset, \u0026amp;info, sizeof(boot_logo_info)); if(ret != 0) { // Something went wrong while reading image info panic(); // ? reset ? } if(check_boot_logo_info(info) == false) { // image info are invalid (ex: size \u0026gt; 240*240), we cannot use them panic(); // ? reset ? Display nothing? } We could find invalid image info if a firmware did not respect the memory map and erased/overwrote the external memory map. In this case, the bootloader couldn’t run properly. Of course, we can implement something smart in panic() (retry, use failover values), but again, this adds complexity and bug probability.\nAll these if’s that call panic() can be avoided by using hard-coded values at build-time.\nIf the image is hard-coded, you won’t be able to easily (not that easy, actually) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA).\nWhy not add OTA functionality to the bootloader? This is exactly how the NRF bootloader/SoftDevice works: the bootloader is a standalone firmware that provides OTA functionality thanks to the SoftDevice. The downside is that the BLE stack needed to provide OTA is quite big and uses a lot of space in flash memory (~124kB according to the documentation). This is roughly 1/4 of the available space in the internal flash memory.\nFirmware based on the NRF SoftDevice share the BLE stack with the bootloader, it is mutualised between both entities. The downside of this design is that firmwares developers are somewhat forced to use the NRF BLE stack. If they want to integrate another BLE stacak (NimBLE for example), these 120kB used by the SoftDevice would be wasted.\nThat’s why we decided to make the MCUBoot bootloader a simple bootloader without OTA functionality. It’s very lighweight (less than 20kB) and leaves the developers the right to choose the BLE stack they want.\nFixed vs dynamic memory map A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes and use the memory for efficiently.\nBut it has the downside to add complexity and code that could fail.\nSee External flash partitioning proposal.\n","permalink":"/documentation/PineTime/Discussions/Bootloader_improvements/","tags":null,"title":"Bootloader improvements"},{"categories":null,"contents":"The following section contains notes regarding compatible bootloaders with the PinePhone Pro.\nrk2aw The rk2aw loader program is designed for modern Rockchip SoCs. It modifies the boot ROM bootloader load order from the original and rigid “SPI NOR flash -\u0026gt; eMMC -\u0026gt; SD card” to a more flexible “SD card -\u0026gt; eMMC -\u0026gt; SPI NOR flash”. Additionally, it enables robust A/B bootloader updates in SPI NOR flash, allowing users to choose fallback options via a pre-boot menu. For details see the rk2aw page.\nU-Boot U-Boot is an open-source bootloader commonly used in embedded operating systems and is often pre-installed on device images.\nTow-Boot Tow-Boot is an opinionated distribution of U-Boot and brings numerous advantages over stock U-Boot, such as the possibility to choose from booting the eMMC or microSD card using the volume buttons during boot, as well as a USB Mass Storage mode, where the device can be written to by connecting the device to a computer via USB.\nThe user can flash Tow-Boot to the PinePhone Pro using the instructions on the Tow-Boot website.\nlevinboot The levinboot bootloader is another option for the PinePhone Pro. The project repository can be found here. (Pinephone Pro supporting fork is here.)\n","permalink":"/documentation/PinePhone_Pro/Software/Bootloaders/","tags":null,"title":"Bootloaders"},{"categories":null,"contents":"The Pinecil Break out board has these features:\nConnect to JTAG port or ADC/DAC, I2C, UART, SPI Independent power regulator circuit Allows pass through power from USB-C charger to Pinecil. Get the Breakout Board here. Pinecil breakout board schematic ver 1.0 20201005 Pinecil breakout board PCB layout ver 1.0 Photos:\nTop_view\nBottom_view\nUART Debugging\n","permalink":"/documentation/Pinecil/Breakout_board/","tags":null,"title":"Breakout board"},{"categories":null,"contents":" The USB over-current protection is not wired up correctly to the USB ports on Star64. The default Starfive Kernel will disable USB on boot as it believes the ports are overcurrent. This ugly hack works around it: https://github.com/Fishwaldo/Star64_linux/commit/2634a13ecfa1fa5c232ec2b9f6a6b6b0d9d66898 The Wifi Chip (RTL8852BU) is not supported in the kernel. There is a Vendor Driver that is imported in the kernel at https://github.com/Fishwaldo/Star64_linux/tree/Star64_devel/drivers/staging/rtl8852bu but it really needs a cleanup. It does BUG_ON at boot, but wifi is confirmed working. HDMI can be finicky. 4K Monitors are known to have a issue. This is also relevant for VisionFive2 Some kernels/distributions do not detect the total memory correctly. This is due to the way u-boot is configured. Currently, u-boot reads the memory from the eeprom on the Star64, and updates the dtb file before booting the kernel. Distributions that boot differently may not get the updated dtb file with the correct memory entry. You can work around this by recompiling the DTB with the correct memory for your board VisionFive2 Kernels will only offer limited functionality on the Star64 - Mainly USB, Wifi and PCI will not work. The 4-pin 12 volt JST-XH-4A connector found on the Star64 is incompatible with the dual SATA power adapter intended for the ROCKPro64. The connector on the Star64 is rotated 180 degrees to the one on the ROCKPro64, resulting in the cable receiving +12V where GND is expected and vice versa. The cable’s internal circuitry ends up shorting in this configuration. Booting from uSD: Component S1804 is adjacent to the 40pin GPIO Bus; ignore the printed text on S1804 that says \u0026ldquo;ON\u0026rdquo; or \u0026ldquo;ONKE\u0026rdquo;. Do pay attention to the \u0026lsquo;1\u0026rsquo; and \u0026lsquo;2\u0026rsquo; printed on S1804. Also pay attention to the \u0026lsquo;L\u0026rsquo; and \u0026lsquo;H\u0026rsquo; text on the board next to S1804. The \u0026lsquo;L\u0026rsquo; stand for \u0026lsquo;0\u0026rsquo; and the \u0026lsquo;H\u0026rsquo; stands for \u0026lsquo;1\u0026rsquo;. You will need to flip switch \u0026lsquo;1\u0026rsquo; (GPIO_1) on S1804 to the \u0026lsquo;L\u0026rsquo; position and switch \u0026lsquo;2\u0026rsquo; (GPIO_0) on S1804 to the \u0026lsquo;H\u0026rsquo; position. S1804 maps to the table next to S1804 that has text [ [GPIO_1 | GPIO_0], [0|0] Flash, [0|1] SD, [1|0] EMMC, [1|1] UART ]; Helpful links: https://mrrcode979.github.io/blog/post/star64-guide/, https://www.bortzmeyer.org/star64-first-boot.html TTL use notes: Ground is on pin 6, RXD is on pin 8, and TXD is on pin 10. Prototype Bringup Notes Note This section is relevant to the original prototype (v1.0) that a few developers received. The schematic has several discrepancies with actual board labels.\nThe serial console can be found with TXD on pin 8 and RXD on pin 10; a convention common to Pi-style boards. Use the 40pin header pinouts in color on page one and not the schematic prose.\nIf you have only a single core running and no PCI card present, it appears to power up via the +5V/GND lines from the USB serial adapter pins.\nIt will not boot from a VisionFive R1 uSD card.\nThe boot device switch labels and the silk screen are inverted. \u0026ldquo;0\u0026rdquo; means \u0026ldquo;On\u0026rdquo;.\n2021.10-00001-gdbdaad919b will attempt to boot from SPI, but it appears blank. If you let it for many minutes, the device will eventually time out and boot OpenSBI v1.0 from (SPI?). This will fail, but only after self-identifying as a VisionFive R2, complete with five cores and 4 GB of RAM, before failing. A \u0026ldquo;press any key\u0026rdquo; timeout is offered, but I’ve been unable to make it stop. It will eventually crash with:\nLoading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment Not a StarFive EEPROM data format - magic error ","permalink":"/documentation/STAR64/Development/Bringup_notes/","tags":null,"title":"Bringup notes"},{"categories":null,"contents":" BSP Linux SDK ver 4.19 for Quartz64 model A SBC Download:\nDirect Download from pine64.org Notes:\nMD5 (TAR-GZip file): 24554419aec29700add97167a3a4c9ed File size: 32.67 GB ","permalink":"/documentation/SOQuartz/Software/BSP_Linux_SDK/","tags":null,"title":"BSP Linux SDK"},{"categories":null,"contents":"","permalink":"/buildinfo/","tags":null,"title":"Build Info"},{"categories":null,"contents":"Start the building process cloning both the upstream Buildroot repository and the Buildroot Bouffalo overlay repository:\n$ mkdir -p ~/ox64 $ cd ~/ox64 $ git clone https://github.com/buildroot/buildroot $ git clone https://github.com/openbouffalo/buildroot_bouffalo Define an environment variable for the Buildroot Bouffalo overlay path:\n$ export BR_BOUFFALO_OVERLAY_PATH=$(pwd)/buildroot_bouffalo Change directory into the cloned Buildroot folder:\n$ cd ~/ox64/buildroot Apply the default configuration for Pine64 Ox64:\n$ make BR2_EXTERNAL=$BR_BOUFFALO_OVERLAY_PATH pine64_ox64_defconfig Use the menuconfig tool to adjust the build settings:\n$ make menuconfig Within menuconfig, configure the following:\nSelect Target Options Enable Integer Multiplication and Division (M) Enable Atomic Instructions (A) using space key Enable Single-precision Floating-point (F) Enable Double-precision Floating-point (D) Select Target ABI, set it to lp64d and press Exit Select Toolchain, enable Fortran support, enable OpenMP support, and Save \u0026amp; Exit Initiate the build process, but first make sure that your PATH variable contains no spaces. For Arch Linux distribution you may also need to install extra-packages with sudo pacman -S cpio rsync bc.\n$ make Buildroot will output the needed files to the ~/ox64/buildroot/output/images directory in about 1 hour, according to your computer processing resources and internet connection speed.\n","permalink":"/documentation/Ox64/Software/Building/","tags":null,"title":"Building"},{"categories":null,"contents":"See Nuttx Build by Lup Yuen\n","permalink":"/documentation/Oz64/Building/","tags":null,"title":"Building"},{"categories":null,"contents":"This page contains information on how to build a linux kernel for the PineNote.\nAvailable Kernel Repositories The following PineNote-specific kernel repositories are available:\nhttps://github.com/m-weigand/linux/ (based mainly on the repository from smaeul, with additional patches pulled in from other sources, Debian packages available) https://git.sr.ht/~hrdl/linux (based on Maximilian\u0026rsquo;s kernel tree, which improves display responsiveness with per pixel scheduling and the automatic redraw of pixels among other improvements) Building the kernel There are currently a couple of up to date trees to choose from.\nMaximilian\u0026rsquo;s kernel is found on the default Debian based operating system shipped with the community edition devices. Currently the most stable option. hrdl\u0026rsquo;s tree is more experimental with new features such as per pixel scheduling and the automatic redrawing of pixels. Prerequisites Building on Debian: Building on device (or another 64bit arm device) will require you to install build-essential. If you are wanting to cross compile you are required to install gcc-12-aarch64-linux-gnu-base (or equivalent) and build-essential. m-weigand kernel Found at https://github.com/m-weigand/linux/\n# Clone the kernel repository and set up the working environment. $ git clone --depth 1 --branch branch_pinenote_6-6-30 https://github.com/m-weigand/linux $ cd linux # Set the PineNote defconfig and compile the kernel. # Remember to pick the commands that reflect your compilation environment below. # For cross compilation $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- pinenote_defconfig $ make -j 2 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION=-pinenote-`date +%Y%m%d%H%M` KBUILD_IMAGE=arch/arm64/boot/Image # For aarch64 host compilation $ make pinenote_defconfig $ make -j 2 LOCALVERSION=-pinenote-`date +%Y%m%d%H%M` KBUILD_IMAGE=arch/arm64/boot/Image Once finished you will have your Image and vmlinux files. To install your modules and dtbs:\n# Make a folder to store these files $ mkdir pack # For cross compilation $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_MOD_PATH=${PWD}/pack modules_install $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_PATH=${PWD}/pack dtbs_install # For aarch64 host compilation $ make INSTALL_MOD_PATH=${PWD}/pack modules_install $ make INSTALL_PATH=${PWD}/pack dtbs_install # Copy these to store them in our pack folder. $ cp ./arch/arm64/boot/dts/rockchip/rk3566-pinenote-v1.2.dtb pack/ $ cp ./arch/arm64/boot/Image pack/ hrdl kernel Found at https://git.sr.ht/~hrdl/linux/\n# Clone the kernel repository $ git clone --depth 1 https://git.sr.ht/~hrdl/linux hrdl-linux $ cd hrdl-linux # Set the PineNote defconfig and compile the kernel. # Remember to pick the commands that reflect your compilation environment below. # For cross compilation $ make ARCH=arm64 pinenote_defconfig $ make ARCH=arm64 -j$(($(nproc)-1)) $ make ARCH=arm64 INSTALL_PATH=pack INSTALL_MOD_PATH=pack modules_install dtbs_install # For aarch64 host compilation $ make pinenote_defconfig $ make LLVM=1 -j$(($(nproc)-1)) $ make INSTALL_PATH=pack INSTALL_MOD_PATH=pack modules_install dtbs_install Next steps Configuring the driver The driver has several options that can improve performance. These can be read about here.\nUsers should edit the /etc/modprobe.d/rockchip_ebc.conf to configure their driver.\nFor m-weigand kernel options rockchip_ebc direct_mode=0 auto_refresh=1 refresh_threshold=60 split_area_limit=0 panel_reflection=1 prepare_prev_before_a2=0 dclk_select=0\nFor hrdl kernel 6.15rc3 options rockchip_ebc dithering_method=2 default_hint=0x80 early_cancellation_addition=2 redraw_delay=200\nFixing suspend If you’re using a logind system, edit your /etc/systemd/logind.conf config. More information on what to do in Arch’s documentation.\nConfiguring your apps See Apps.\nBooting Linux instead of Android PineNote Development/Booting Linux\nFixing Bluetooth See PineNote Development/Software Tweaks\n","permalink":"/documentation/PineNote/Development/Building_kernel/","tags":null,"title":"Building Kernel"},{"categories":null,"contents":"This article guides you through compiling U-Boot for a Quartz64 and SOQuartz device.\nPrerequisites You will need either an x86 machine with an aarch64 cross-compiler installed, or an existing aarch64 system. You will also need the device tree compiler dtc, python3 (including setuptools and pyelftools), swig, GNU make and git.\nArch Linux On an x86_64 Arch Linux system, you can install the required dependencies with:\npacman -S --needed base-devel aarch64-linux-gnu-gcc aarch64-linux-gnu-binutils git dtc python-setuptools swig python-pyelftools Debian On an x86_64 Debian (or derivates such as Ubuntu) system, you can install the required dependencies with:\napt install device-tree-compiler build-essential gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu make python3 python3-dev libssl-dev python3-pyelftools python3-setuptools swig git bison libgnutls28-dev Fetching the repositories Use git to clone the mainline U-Boot repository into the directory u-boot:\ngit clone https://source.denx.de/u-boot/u-boot.git You can use git checkout _tagname_ inside the u-boot directory to check out a specific git tag (release), you can list all of them with git tag -l (but do keep in mind we only have device support since v2023.10).\nThen, also use git to clone the rockchip firmware binaries repository into the directory rkbin:\ngit clone https://github.com/rockchip-linux/rkbin.git Setting up your environment Next, we need to set two environment variables: ROCKCHIP_TPL for the DRAM init binary, and BL31 for the ARM Trusted Firmware binary.\ncd u-boot export ROCKCHIP_TPL=\u0026#34;$(ls ../rkbin/bin/rk35/rk3566_ddr_1056MHz_v*.bin | sort | tail -n1)\u0026#34; export BL31=\u0026#34;$(ls ../rkbin/bin/rk35/rk3568_bl31_v*.elf | sort | tail -n1)\u0026#34; Configuring U-Boot First, we need to use the right default config for our device. Please choose defconfig from the following table depending on your device:\nBoard defconfig Quartz64 Model A quartz64-a-rk3566_defconfig Quartz64 Model B quartz64-b-rk3566_defconfig SOQuartz on Model A soquartz-model-a-rk3566_defconfig SOQuartz on Blade soquartz-blade-rk3566_defconfig SOQuartz on CM4 I/O Board soquartz-cm4-rk3566_defconfig In the u-boot directory with your environment variables set, run:\nmake CROSS_COMPILE=aarch64-linux-gnu- [defconfig] with [defconfig] being the value from the previous table.\nBuilding U-Boot In the u-boot directory, after configuring, and with your environment variables set, run:\nmake CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) This will output a u-boot-rockchip.bin, which is your freshly built SPL+U-Boot combined image.\nFlashing the U-boot Run as root or using sudo:\ndd if=u-boot-rockchip.bin of=/dev/\u0026lt;device, eg:mmcblk0\u0026gt; bs=32k seek=1 conv=fsync ","permalink":"/documentation/Quartz64/Software/Building_U-Boot/","tags":null,"title":"Building U-Boot"},{"categories":null,"contents":"PineCube is supported in Buildroot since version 2023.11. See the file board/pine64/pinecube/readme.txt in the Buildroot repository for details how to build it.\nThere is also available Buildroot fork by Elimo Engineering, you can find the repository on Elimo’s GitHub account and build instructions in the board support directory readme.\nThe most important thing that this provides is support for the S3’s DDR3 in u-boot. Unfortunately mainline u-boot does not have that yet, but the u-boot patches from Daniel Fullmer’s NixOS repo were easy enough to use on buildroot.\nThis should get you a functional system that boots to a console on UART0. It’s pretty fast too, getting there in 1.5 seconds from u-boot to login prompt.\n","permalink":"/documentation/PineCube/Software/Buildroot/","tags":null,"title":"Buildroot"},{"categories":null,"contents":" Focus The focus of the lens can be manually adjusted through rotation. Note that initially, the lens could be tight.\nLow light mode To get imagery in low-light conditions you can turn on the infrared LED’s to light up the dark area and also enable the IR cut filter using the commands below. Note that these were performed on Armbian using the instructions from here [https://github.com/danielfullmer/pinecube-nixos#enablingdisabling-ir-cut-filter].\n# Run these as root # Turn on the IR LED lights (note that you can see a faint red glow from them when it’s low light) # Turn them off with echo 1 instead (this may be inverted depending on the version of the kernel you have) echo 0 \u0026gt; /sys/class/leds/pine64\\:ir\\:led1/brightness echo 0 \u0026gt; /sys/class/leds/pine64\\:ir\\:led2/brightness # Export gpio, set direction echo 45 \u0026gt; /sys/class/gpio/export echo out \u0026gt; /sys/class/gpio/gpio45/direction # Enable IR cut filter (note that you can hear the switching noise) # Disable with echo 0 instead echo 1 \u0026gt; /sys/class/gpio/gpio45/value Camera controls It is possible to adjust the camera using certain internal camera controls, such as contrast, brightness, saturation and more. These controls can be accessed using the v4l2-ctl tool that is part of the v4l-utils package.\n# List the current values of the controls v4l2-ctl -d /dev/v4l-subdev* --list-ctrls User Controls contrast 0x00980901 (int) : min=0 max=255 step=1 default=0 value=0 flags=slider turation 0x00980902 (int) : min=0 max=255 step=1 default=64 value=64 flags=slider hue 0x00980903 (int) : min=0 max=359 step=1 default=0 value=0 flags=slider utomatic 0x0098090c (bool) : default=1 value=1 flags=update _balance 0x0098090e (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider _balance 0x0098090f (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider exposure 0x00980911 (int) : min=0 max=65535 step=1 default=0 value=4 flags=inactive, volatile utomatic 0x00980912 (bool) : default=1 value=1 flags=update gain 0x00980913 (int) : min=0 max=1023 step=1 default=0 value=20 flags=inactive, volatile tal_flip 0x00980914 (bool) : default=0 value=0 cal_flip 0x00980915 (bool) : default=0 value=0 requency 0x00980918 (menu) : min=0 max=3 default=1 value=1 Camera Controls auto_exposure 0x009a0901 (menu) : min=0 max=1 default=0 value=0 flags=update Image Processing Controls pixel_rate 0x009f0902 (int64) : min=0 max=2147483647 step=1 default=61430400 value=21001200 flags=read-only st_pattern 0x009f0903 (menu) : min=0 max=4 default=0 value=0 # Set the contrast controls to the maximum value v4l2-ctl -d /dev/v4l-subdev* --set-ctrl contrast=255 You can see which flags can be changed and which ones cannot by looking at the flags. The inactive flag indicates that it is currently disabled. Some of these flags are disabled when other flags are turned on. For example, the gain flag above is inactive because gain_automatic is enabled with a value of \u0026ldquo;1\u0026rdquo;.\nNote At the current time the auto_exposure flag is inverted, so a value of \u0026ldquo;0\u0026rdquo; means on, while \u0026ldquo;1\u0026rdquo; means off. Maybe the auto_exposure flag will get changed someday. You’ll need to turn off auto_exposure (value=1) if you want to manually set the exposure flag. ","permalink":"/documentation/PineCube/Tuning/Camera/","tags":null,"title":"Camera"},{"categories":null,"contents":"The PinePhone has two cameras, OmniVision OV5640 with 5MP (up to 2592 x 1944 pixels) as rear camera and GalaxyCore GC2145 with 2MP (up to 1600 x 1200 pixels) as front camera.\nExample picture taken on the PinePhone’s rear camera by Martijn Braam using his app Megapixels.\nFurther details regarding the camera and the Megapixels camera app can be found on Martijn’s blog.\n","permalink":"/documentation/PinePhone/Camera/","tags":null,"title":"Camera"},{"categories":null,"contents":"The PinePhone Pro has two cameras, Sony IMX258 with 13MP as rear camera and OmniVision OV8858 with 8MP as front-facing camera.\nExample picture taken on the PinePhone’s (not Pro) rear camera by Martijn Braam using his app Megapixels.\nAs mentioned in Software State, the cameras are work-in-progress, including a required DTS fix, userspace still needs to do some catching up and there is a green image tint. This article explains how to fix camera sofware on your PinePhone Pro. The work is on progress and will be available soon for different distributions. Make sure your PinePhone Pro is connected to the web to download needed software.\nArch Linux ARM + Phosh Installation Open terminal and update your system:\n$ sudo pacman -Syyuu Remove original Megapixels app:\n$ sudo pacman -Rns megapixels Install camera dependencies:\n$ sudo pacman -Syu gst-plugin-libcamera libcamera-tools pipewire-libcamera Install flatpak software manager:\n$ sudo pacman -S flatpak Install Megapixels2 app:\n$ flatpak install https://flatpak.brixit.nl/megapixels2.flatpakref --user You will be prompted to some options\nShould the remote be kept for future installations? [Y/n]: n Configure this as new remote \u0026lsquo;flathub\u0026rsquo; [Y/n]: y Required runtime for me.gapixels.Megapixels/aarch64/master (runtime/org.gnome.Platform/aarch64/47) found in remote flathub. Do you want to install it? [Y/n]: y To launch camera app you can both click on Megapixels icon on your desktop or enter into terminal following command\n$ flatpak run me.gapixels.Megapixels In case you need to reinstall Megapixels2\n$ flatpak list $ flatpak uninstall --delete-data me.gapixels.Megapixels $ flatpak uninstall --unused $ flatpak repair Green Tint Issue To fix the green tint issue during post processing of your pictures, add \u0026ldquo;-a\u0026rdquo; and \u0026ldquo;-f\u0026rdquo; to dcraw line (about #82) into postprocess.sh file\nFirst look for postprocess.sh file:\n$ cd ../.. $ sudo find / -type f -name postprocess.sh Goto the postprocess.sh directory you found using the above command. Here the example /var/lib/flatpak/app/me.gapixels.Megapixels/aarch64/master/[\u0026hellip;]/files/share/megapixels/postprocess.sh is used:\n$ cd /var/lib/flatpak/app/me.gapixels.Megapixels/aarch64/master/[...]/files/share/megapixels Backup original file and add \u0026ldquo;-a\u0026rdquo; and \u0026ldquo;-f\u0026rdquo; to dcraw line, using replace command:\n$ sudo cp postprocess.sh postprocess.sh.bk $ sudo sed -i \u0026#39;s/$DCRAW +M -H 4 -o 1 -q 3 -T \u0026#34;$@\u0026#34; \u0026#34;$MAIN_PICTURE.dng\u0026#34;/$DCRAW +M -H 4 -o 1 -q 3 -T -a -f \u0026#34;$@\u0026#34; \u0026#34;$MAIN_PICTURE.dng\u0026#34;/\u0026#39; postprocess.sh If you want to patch automatically the file, just copy and paste following code into CLI:\n$ BASE=\u0026#34;/home/alarm/.local/share/flatpak/app/me.gapixels.Megapixels/aarch64/master\u0026#34; $ find \u0026#34;$BASE\u0026#34; -type f -path \u0026#34;*/files/share/megapixels/postprocess.sh\u0026#34; | while read -r f; do $ [ -z \u0026#34;$f\u0026#34; ] \u0026amp;\u0026amp; continue $ cp \u0026#34;$f\u0026#34; \u0026#34;$f.bk\u0026#34; $ if grep -Fq \u0026#39;$DCRAW +M -H 4 -o 1 -q 3 -T -a -f \u0026#34;$@\u0026#34; \u0026#34;$MAIN_PICTURE.dng\u0026#34;\u0026#39; \u0026#34;$f\u0026#34;; then $ echo \u0026#34;string already patched\u0026#34; $ elif grep -Fq \u0026#39;$DCRAW +M -H 4 -o 1 -q 3 -T \u0026#34;$@\u0026#34; \u0026#34;$MAIN_PICTURE.dng\u0026#34;\u0026#39; \u0026#34;$f\u0026#34;; then $ sed -i \u0026#39;s#\\$DCRAW +M -H 4 -o 1 -q 3 -T \u0026#34;\\$@\u0026#34; \u0026#34;\\$MAIN_PICTURE\\.dng\u0026#34;#\\$DCRAW +M -H 4 -o 1 -q 3 -T -a -f \u0026#34;\\$@\u0026#34; \u0026#34;\\$MAIN_PICTURE.dng\u0026#34;#g\u0026#39; \u0026#34;$f\u0026#34; $ echo \u0026#34;patch done\u0026#34; $ else $ echo \u0026#34;string not found\u0026#34; $ fi $ done Further details regarding the camera and the Megapixels camera app can be found on Martijn’s blog.\n","permalink":"/documentation/PinePhone_Pro/Camera/","tags":null,"title":"Camera"},{"categories":null,"contents":" Bypass Cables Warning Do not connect the bypass cables with the battery connected. Using the bypass cables with the battery connected can permanently damage your Pinebook Pro. After you’re done with using the bypass cables and want to return to the default setup, make sure to affix the bypass cables to the main body of the laptop using adhesive tape, in the same way as it was done in the factory. This ensures that the exposed leads in the connectors on the bypass cables don’t touch any conductive surface inside the laptop, which may cause a short. The mainboard features two bypass cables that are to be used only with the battery disconnected. The two bypass cables are disconnected by default. The female (10) male (6) ends of the bypass cables can be connected to provide power to the mainboard if you need to run your Pinebook Pro with no battery. Please refer to this engineering notice for more details.\nConnecting the bypass cables together effectively connects the charger input where the battery output is, which also bypasses the charging circuit inside the Pinebook Pro. Thus, with the bypass cables connected together, the charger powers the Pinebook Pro directly, just like the battery does it when the laptop is running on battery power. This also means that no input current limiting is any longer in place, making it possible to draw more than 3 A from the charger, and to trigger its overcurrent protection, which may cause operating system instability and crashes.\nDespite the bypass cables having two conductors, they are used as a single conductor. Having both wires soldered together on either side of the bypass cables is normal, and such load-sharing design allows use of a compact connector on the bypass cables.\nWhen removing the large RF shield found on the mainboard, for example when shorting the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back.\nGuides These are self-service instruction guides for the disassembly of the 14-inch Pinebook, but they still almost directly apply to the Pinebook Pro:\nLithium Battery Pack Removal Guide LCD Panel Screen Removal Guide eMMC Module Removal Removal Guide Assembling it back requires the described steps to be performed in the reverse order.\n","permalink":"/documentation/Pinebook_Pro/Guides/Caring/","tags":null,"title":"Caring"},{"categories":null,"contents":" Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. This page contains hints on setting up cellular network connectivity for specific carriers. For more general information, see the carrier support section of PinePhone. For the APN settings see APN settings.\nCheck compatibility To check if the PinePhone is supported on your carrier:\nSearch for your carrier on frequencycheck.com and compare the carrier’s LTE/GSM/WCDMA frequencies to the PinePhone’s supported frequencies (listed in the https://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf modem specification sheet).\nIt is likely that there will be a few frequencies that your carrier uses which are not supported by the PinePhone. Not all of the carrier’s frequencies need to be supported by the PinePhone for it to work - as long as most of them are supported, you will still get good coverage.\nNote Some providers may allow only certain known devices identified by their Type Allocation Code. MMS workarounds These scripts allow partial MMS support on a PinePhone in distributions without working MMS support:\nJMMS: https://git.sr.ht/~amindfv/jmms silvermms: https://gitlab.com/5ilver/silvermms MMS via Matrix with mmmpuppet: MMS with Matrix There is a Haskel MMS client. MMS can also be manually composed with mmsd on the command line.\n","permalink":"/documentation/PinePhone/Modem/Carrier_support/","tags":null,"title":"Carrier support"},{"categories":null,"contents":" Dimensions: 329 mm x 220 mm x 12 mm (W x D x H) Weight: 1.26 kg Screws on the bottom lid Philips-head type screws M2 flat-head machine screws 4 x short screw (used along the front edge): head diameter - 3.44 mm, thread diameter - 1.97 mm, thread length - 2.1 mm, overall length - 3.05 mm 6 x long screw (used elsewhere): head diameter - 3.44 mm, thread diameter - 1.97 mm, thread length - 4.41 mm, overall length - 5.85 mm Rubber feet 18 mm diameter 3 mm height Dome shaped ","permalink":"/documentation/Pinebook_Pro/Further_information/Case_dimensions_and_data/","tags":null,"title":"Case dimensions and data"},{"categories":null,"contents":"The Pine store has official cases:\nPinePhone Hard Protective Case PinePhone Soft TPU Protective Case Tight-fit cases of other phones can’t be used with the PinePhone because most times the proportions and/or camera notch won’t fit. The phone can however be used with most \u0026ldquo;phone sleeves\u0026rdquo;, such as those from fitBAG. The sleeve from fitBAG for the Xiaomi Redmi Note 8 Pro fits the PinePhone tightly.\nThe OtterBox uniVERSE Case for Samsung Galaxy XCover Pro is reported to fit the PinePhone well without much modification.\nThe following accessory is made by the community:\nPinePhone Hard Case by The3DmaN at Thingverse PinePhone TPU Case by The3DmaN at Thingverse PinePhone Hard Case by blitzaxt at Thingverse ","permalink":"/documentation/Phone_Accessories/Cases/","tags":null,"title":"Cases"},{"categories":null,"contents":" Model:\nPineCube (proprietary) 3D file User models:\nQuick and dirty STL conversion (beta) by doodlebro. Prints and fits at 0.25mm layer height. New model with removable front cover and mounting plate with hole for strong magnet and adjustable rotation angle. See README for more details. Available FreeCAD source models, STL, G-code and 3mf data. Also available at printables.com ","permalink":"/documentation/PineCube/Cases/","tags":null,"title":"Cases"},{"categories":null,"contents":"There are no cases for PineTime yet, but some cases for Fitbit are suitable for it. Cases for Fitbit have one microphone hole, which is unnecessary for the PineTime, but otherwise they fit perfectly (such as the Soft TPU case for Fitbit Versa 2/Versa Lite).\nThe community designed the following cases:\nPineTime Smart Watch case by dara0s at thingiverse PineTime Flexible Cover by AmbiSpace at thingiverse PineTime dev kit back fix by joaquimorg at thingiverse PineTime dev kit charging holder v4 by zevix81 at thingiverse PineTime Charger Travel Case by brett at PrusaPrinters ","permalink":"/documentation/PineTime/Accessory/Cases/","tags":null,"title":"Cases"},{"categories":null,"contents":" Acrylic Open Enclosure Acrylic enclosure NAS case Front View of the PINE64 NAS Case for the ROCKPro64\nPlease follow this this link for detailed instructions on how to assemble the ROCKPro64 NAS Case.\nThe NAS Case instructions also contains detailed information about:\nwhat the NAS Case ships with What additional things you need to purchase for your NAS Case What optional things you can consider purchasing for your NAS build What OS Image we recommend you use for your NAS build IO accessibility after installing the ROCKPro64 into the NAS Case NAS Case Exploded View NAS Case Drawing ","permalink":"/documentation/ROCKPro64/Hardware/Cases/","tags":null,"title":"Cases"},{"categories":null,"contents":"The table below collect known information about casing and enclosure compatibility for the StarPro64 SBC:\nCase Compatible Notes ROCKPro64 PREMIUM ALUMINUM CASING No StarPro64 has two stacked ethernet ports, making it too tall. Model A Acrylic Open Enclosure Partial The screw closer to the LEDs and the one closer to the dip switches touch some components, potentially shorting or damaging them. Screw with a smaller head might work. ","permalink":"/documentation/StarPro64/Cases/","tags":null,"title":"Cases"},{"categories":null,"contents":" Disclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. Not yet available ","permalink":"/documentation/Oz64/Certifications/","tags":null,"title":"Certifications"},{"categories":null,"contents":"Pinecil V2 Certifications:\nPinecil V2 CE Certificate Pinecil V2 FCC Certificate Pinecil V2 ROHS Report Pinecil V1 Certifications:\nPinecil CE RED Certificate Pinecil FCC Certificate Pinecil ROHS Certificate ","permalink":"/documentation/Pinecil/Further_information/Certifications/","tags":null,"title":"Certifications"},{"categories":null,"contents":"PineTab-V certifications:\nPineTab-V FCC Certificate PineTab-V CE RED Certificate PineTab-V CE EMC Certificate PineTab-V ROHS Test Report PineTab2/PineTab-V Detached Keyboard CE EMMC Certificate ","permalink":"/documentation/PineTab-V/Further_information/Certifications/","tags":null,"title":"Certifications"},{"categories":null,"contents":"PineTab2 certifications:\nPineTab2 FCC Certificate PineTab2 CE RED Certificate PineTab2 CE EMC Certificate PineTab2 ROHS Test Report PineTab2/PineTab-V Detached Keyboard CE EMMC Certificate ","permalink":"/documentation/PineTab2/Further_information/Certifications/","tags":null,"title":"Certifications"},{"categories":null,"contents":"Certifications:\nROCK64 FCC Certificate ROCK64 CE Certificate ROCK64 RoHS Certificate ","permalink":"/documentation/ROCK64/Further_information/Certifications/","tags":null,"title":"Certifications"},{"categories":null,"contents":"The goal of the challenge is to achieve a blob-free BL602 for the open source community to achieve a blob-free FOSS Bluetooth and WiFi on PINE64 devices, see Nutcracker Challenge: Blob-Free WiFi \u0026amp; BLE.\n","permalink":"/documentation/PineCone/Challenge/","tags":null,"title":"Challenge"},{"categories":null,"contents":"Prep tasks:\nClean new cartridges/tips with 99% isopropyl alcohol (IPA) to remove factory residue before installing (avoid strange behavior from poor electric contact). If you have none, try to at least wipe down the new cartridge with a clean towel especially the 2 contacts at the rear white end (do not use water, as it could get into the small white seam line). Do not bend the two tiny internal contacts, they are thin spring metal and may break. Only use one port, USB-C or the DC barrel, but Never both at the same time. Damage will occur to PC/Laptop/Pinecil! If using a DC barrel brick for power, do not use more than 24V for Pinecil V2 and not more than 21V for Pinecil V1 (a special end-user modification is possible for V1 which allows it to use up to 24V safely). Upon receipt, or buying a used Pinecil, one may want to check the following:\nThe display turns on when 5-21V is supplied (V2 models can do 24V). Use a USB type C cable or a DC 5525 center positive barrel (how to check polarity) Use the video linked to make sure the DC barrel charger is Center Positive before plugging it into Pinecil. Several users have accidentally plugged incorrect center-negative chargers into Pinecil which immediately breaks it because it is the wrong type of charger (this is sometimes repairable, see live community chat). Note that 5v shows DC low and is not high enough to run Pinecil. 5V is only enough for firmware update and to see the menu. It gets full power. 20V from a 20V capable USB-C PD charger or power from DC barrel charger that is the appropriate specifications. The screen displays the voltage from the charger. Check both orientations of the USB-C cable (try to flip it if one way doesn’t work). Check for new firmware updates, see the firmware section. Note: do not connect the DC barrel at the same time as a USB-C cable. Pinecil was designed to only have one cable plugged in at a time. You could damage/break the PC and Pinecil doing this. V1 and V2 used different flasher apps to load firmware onto the Pinecil, see the Firmware section. Updating firmware requires a data capable USB cable connected to a PC/laptop. Check that both buttons work [-] to enter menu or decrease temperature, long press [-] to get the software version info or to turn off heating [+] to turn on heating or select a menu item The displayed text rotates according to gravity when orientation is set to Automatic User interface -\u0026gt; Display orientation -\u0026gt; Automatic More menu options listed on IronOS documents Check that all 3 external screws are present One near the back of the screen (ground screw for optional ground wire) One at the front on top (to hold the tip in) One at the front on the bottom (to hold the case together, does not touch the tip) Check that the tip is clean \u0026amp; wipe it down with a dry towel or IPA (uniformly silver at the front, with no pitting or texture). Some tips come pre-dipped in solder for protection and may look odd. Heat them up then wipe clean on a soldering sponge or brass wool and inspect. Heat up the tips a few times to 350°C for a couple minutes to check that they are working and melting solder. See Pinecil Tips and Guides to Soldering \u0026amp; Maintenance for soldering advice. Re-tin the tip before storing is advised to prevent oxidation. Check that it heats up with an installed tip, and stops increasing when it reaches the set point. This may draw up to ~3A, make sure the power supply can provide a minimum of 3amps or more. Minor overshoot may occur, but, disconnect power if the temperature keeps going up higher without user input and check with the live volunteer Pinecil channel. Do a simple test is to see if the iron will melt solder at approximately the expected temperature for the alloy of solder being tested. If no direct measurement is possible, set it to ~230°C and see if it just about melts SAC (lead-free) solder (~190°C for leaded). This may be more if the room is cold. If there are multiple tips, wipe all of them with isopropyl alcohol (IPA) or a dry clean towel and check that they all heat up. If the tip moves a little while using it, try to hold Pinecil with the screen facing the side or screen downwards. Members found that if the screen is up and the screw loosens during use, then the tip wobbles a little. Changing holding angles helps the tip press against the solid barrel instead of wobbling on the stub of the small screw. ","permalink":"/documentation/Pinecil/Checklist/","tags":null,"title":"Checklist"},{"categories":null,"contents":"PineBuds Pro only have IPX4 rating, so they are only splash-proof and cannot withstand immersion in water. Clean the charging case inside and out with a damp microfiber cloth. Inside, be careful near the pogo pins! The cloth easily sticks to them and may tear them. You can use a microfiber cloth at the end of a stick to immerse of the buds, but a cleaning tool made for this can help. When cleaning the buds, carefully remove the tips, place the buds on a damp microfiber cloth and one by one wipe it from all sides. Be careful with the protective mesh. If there is dirt in the mesh, you can carefully clean it with the brush of the previously mentioned tool. Wash the tips with soap and water, but be careful, they easily drip from your hand to drain. After drying them, carefully put them back to the buds.\nYou need:\nA microfiber cloth A cleaning tool ","permalink":"/documentation/PineBuds_Pro/Further_information/Cleaning/","tags":null,"title":"Cleaning"},{"categories":null,"contents":"Closed case debugging was brought up during a week of community schematic review of the PineNote. This page documents the discussion of this proposed issue and its resolution.\nDates on this page are relative to UTC-5.\nBackground When debugging bootloader and kernel initialization on a new hardware platform, a hardware UART is indispensable. The PineNote 1.1 required taking the device apart to access a hardware UART broken out on the motherboard. This did not seem tenable long-term, as developers usually don’t like taking their devices apart to debug bootloaders. Therefore, it is important to provide resources to debug the PineNote’s boot process such as a hardware UART.\nRecent PINE64 devices have included a hardware UART connected to their 3.5mm TRRS jacks through a hardware switch. However, the PineNote doesn’t have an audio jack. It also doesn’t have a convenient place to put a hardware switch which is accessible without taking the device apart. The case only has the affordance for a single USB-C port.\nDiscussion August 15, 2021 We decided to ask the PineNote product team to explore USB-C Debug Accessory Mode, where the product changes the USB-C port’s personality when both CC1 and CC2 are pulled high. In normal usage, either CC1 or CC2 will be floating since these are the connector rotation pins. When both are detected, there is a very good chance that a debug harness is connected.\nThis decision requires the PineNote motherboard to be able to detect an AND condition between CC1 and CC2 and connect one of the SOC’s UARTs to pins on the USB-C connector. In all other cases, the UART should be disconnected. It also requires the PINE64 Store ship a simple one-sided (no magical flipping here, sorry) connector board which breaks out USB 2.0 and UART.\nAugust 16-18, 2021 There were concerns that cheap USB-C cables have both CC1 and CC2 shorted together to save a wire. This may cause the PineNote to output 3.3v UART to a device that isn’t expecting it, assuming the two are plugged together with a nonstandard cable. This seems unfounded (or not enough of a problem to worry about on a large scale), since the USB-C specification states in section B.2.3.1, \u0026ldquo;The general concept for setting up a valid connection between a DTS and TS is based on being able to detect the typical USB Type-C termination resistances. However, detecting a Debug Accessory Mode connection requires that both CC pins must detect a pull-up (Rp) or pull-down (Rd) termination. A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection cannot be detected.\u0026rdquo;\nThere were concerns that checking CC1 and CC2 being pulled high was not strictly to USB-C standard, as detecting them being pulled low is mentioned in the standard. However, detecting a pull-up condition is all that is required. According to the USB-C spec, \u0026lsquo;B.2.4.1.5.1 (\u0026ldquo;UnattachedDeb.SRC Requirements\u0026rdquo;), a Debug and Test System (DTS) that is a power source must pull CC1/CC2 up, while the Target System (TS) in Unattached.SNK is supposed to pull them low.\u0026rsquo; In English, this means that we’d only need to detect a pull-up condition on CC1 and CC2, meaning a logical AND between them is a sane solution.\nIt should be possible to make the UART connection and breakout cable magically flippable by connecting the UART multiple times to the USB-C port.\nResolution This proposed circuitry is added to the PineNote v1.1 schematic\nOn August 19, 2021, TL posted the results of the hardware team’s efforts. This includes \u0026ldquo;PineNote USB-C DAM Schematic Addition.png\u0026rdquo;, shown on this page, as well as the following additional documentation:\nDatasheet for ON Semiconductor NS5S1153 USB-C USB 2.0 and Audio Switch. Additionally, the hardware team proposed designing a breakout board with pull-up resistors on CC1 and CC2 and the appropriate UART signals routed to headers on the board. Then a developer can bring their own USB TTL adapter. They almost definitely have at least one, or could access one for a low price.\ndsimic commented that this proposed layout meant that a Google-designed SuzyQable would not work for debugging the PineNote. This was deemed acceptable, as long as it is clear to developers that the combination of PineNote and SuzyQable will not result in any useful debugging abilities.\nCaleb commented that the Google Pixel series of devices bring out UART over the SB1 and SB2 pins on the USB-C connector. It was surmised that copying this layout would allow reusing hardware that developers already have, however there are no harnesses on the market that directly break out this interface. Instead, it seems that most developers use a USB-C breakout board and stuff wires in the appropriate place when needed[https://github.com/Peter-Easton/android-debug-cable-howto]. A similar approach could be taken with the proposed PineNote solution if someone did not wish to purchase the breakout board.\n","permalink":"/documentation/PineNote/Further_information/Closed_Case_UART/","tags":null,"title":"Closed case UART"},{"categories":["Clusters"],"contents":" Clusterboard The Clusterboard is a gateway into the world of clusters in a tidy and compact package. The SOPINE Custerboard can host up-to 7 SOPINE modules. The Clusterboard can be powered either using a +5V 15A power supply with 6.3mm OD/3.0mm ID barrel type DC Jack or an ATX power supply*. Each of the SOPINE cluster nodes is able to interface with the entire system via the onboard Ethernet switch. Each node has a USB 2.0 host port and 20 GPIO pins exposed.\n*please note that some ATX power supplies may required load to power up the board\nFeatures and Specifications Standard mITX form-factor Built-In unmanned Gigabit Ethernet switch eMMC module slot 7x USB 2.0 (one for each module) GPIO pins exposed for each module including UART NIC LEDs for each SOPINE module 2x 1.5V “AA” size battery holder for Real Time Clock port (RTC) +5V 15A power supply with 6.3mm OD/3.0mm ID barrel type DC jack ATX power supply header Micro ITX Form-Factor The SOPINE Clusterboard uses a Micro ITX Form-Factor\nPlenty Of USB Each module added to the Clusterboard exposes one USB 2.0 port\nATX Power Header ATX power supply header\nGPIO Pins GPIO pins are exposed for each module including UART\nStores Global Global: Accessories Affiliates Documentation Clusterboard Schematics ","permalink":"/devices/sopine_clusterboard/","tags":null,"title":"Clusterboard"},{"categories":null,"contents":" Front view of the Clusterboard (revision 2.2)\nThe Clusterboard is a PINE64 board that makes it possible to set up a compact cluster of headless ARM-based single-board computers. It can hold up to a total of seven SOPINE or SOEDGE modules. The Clusterboard is an open-hardware project, but please note that it does not mean this project is \u0026ldquo;OSH\u0026rdquo; compliant.\nAlthough there is a separate page that describes SOPINE modules, this page will describe both the Clusterboard and, to a certain extent, the SOPINE modules. There is a user guide for the Clusterboard in this forum thread.\nLayout The Clusterboard with labels\nLabel Description 1 Barrel-type DC jack (6.3 mm outer diameter, 3.0 mm inner diameter) for a +5 V, 15 A power supply 2 Gigabit Ethernet port 3 Reset button, for all seven modules 4 Holder for two non-rechargeable 1.5 V AA-size batteries, providing backup for the real-time clock (RTC) on all modules 5 Connector for an eMMC module, for the first SOPINE or SOEDGE module 6 Slot for a SOPINE or SOEDGE module 7 USB 2.0 Type-A socket 8 MicroUSB Type-B USB 2.0 socket 9 Activity LED 10 20-pin expansion connector 11 Three-pin connector for a lithium battery 12 RTL8211E Gigabit Ethernet PHY, with two status LEDs 13 Gigabit Ethernet Switch (RTL8370N) 14 24-pin ATX Power Connector 15 Two-pin connector for a switch/button that turns on connected ATX power supply 16 5 V power output for hard disk drives (optional) 17 Places for soldering two resistors (optional, for use with an ATX power supply that requires dummy load on 3.3 V and 12 V rails) For the part 4, please see the important note in the specifications page. For the part 11, please see the notes in the hardware revisions page. Parts 6 to 12 exist separately for each of all seven SOPINE or SOEDGE modules.\n20-pin Expansion Connector The 20-pin expansion connector is the part 10 described in the section above, available for each SOPINE or SOEDGE module. There is an unofficial description of the pinout in this forum thread. The unofficial pinout is also visible directly in this picture.\nSOPINE Module Front view of the SOPINE module with labels\nRear view of the SOPINE module with labels\nLabel Description 1 A64 SoC 2 2 GB of DDR3 RAM 3 AXP803 PMIC 4 Edge connector, the same as on SO-DIMM modules 5 Power LED 6 microSD card slot 7 SPI flash memory Operating systems Armbian To get the cluster running, start off with a basic Armbian SOPINE install on the first module or directly on all the modules. Armbian offers Debian and Ubuntu as options for download.\nThere is an issue recognizing the network that needs you to make a change to the base image described here, and a PXE issue. If you have a good description, please add it here. The network issue has been resolved in Armbian builds post December 2020 - as described here.\nAs of February 2021 the current Armbian image is not working (see the post on the Armbian forum). The latest working version is 21.02.1. To update the system, the package \u0026rsquo;linux-dtb-current-sunxi64\u0026rsquo; needs to be held back by running\necho \u0026quot;linux-dtb-current-sunxi64 hold\u0026quot; | sudo dpkg --set-selections\nThere are a number of possible basic installation methods.\nFull install on each module’s mSD card. eMMC install on the first module. PXE boot for all modules, from the first module, or an external host. Others The current version of NetBSD may have the networking issue solved in Armbian, as described above.\nInstallation To install a cluster it is important to know the IP addresses of each module, so the remote login sessions do not get mixed up.\nEach module may be plugged into the Clusterboard individually or consecutively, which makes it easy to assign a hostname to each module separately. It is also possible to manually edit the hostname in the OS image of each module before the first boot.\nTip The board has no hotplug functionality, so make sure you only plug/unplug the modules while the power is disconnected from the Clusterboard. Tip No management features are available on the switch ship, so there is no VLAN support. Serial console To boot use the serial console connect the pins to UART0 on the GPIO header and connect using baud 115200\nPin 6: GND Pin 7: RTX Pin 8: TXD The pinouts are available in this forum thread.\nTip Do not connect the GND connector until the power is on as it can provide power and prevent the board from booting. Accessories To operate this board you will need a power supply, Pine advises a \u0026ldquo;5V 15A power supply with 6.3mm OD/3.0mm ID barrel type DC Jack\u0026rdquo; which is also available in the store (EU / US versions). There are other ways to power this board, but they are not described here yet. The board works best when it is protected by a (mITX)case, and has some airflow provided by a fan. Each SOPINE module can use cooling, both by a case fan, and by using heatsinks on the individual modules. At least the A64 could use some cooling. The first slot can use a eMMC module, which are in the store in 16GB / 32GB / 64GB / 128GB sizes. The modules can be used as a USB stick using a USB adapter. (The eMMC is also readable with the Hardkernel eMMC to microSD converter.) Two AA batteries, to allow the SOPINE nodes to retain the RTC (Real Time Clock) time and date information when the power is disconnected. Further information Revisions\nFAQ\nSpecifications\nRevisions As of April 2021, current revision of the Clusterboard is 2.3. Compared with the previous revision, 2.2, it removes the PCB components required for using lithium-polymer batteries for powering each of the modules.\nBesides the 2.2 revision, there was also an early revision (TODO: which exactly?) that required a hardware fix for the eMMC module to work properly.\nFAQ Q: Are the individual MAC addresses linked to the PHY chips, or the module?\nA: The MAC address is specific to the SOPINE module; swapping modules within the Clusterboard does not change the MAC address of the module.\nQ: Why will SOPINE modules not reboot when installed on a Clusterboard, but will when installed on a SOPINE Baseboard?\nA: The cause has been determined to be back-EMF, and can be resolved with some relatively easy hardware modifications, thanks to excellent troubleshooting performed by Eric. Please, have a look at the extensive article he wrote to find out how to resolve this issue. See also this forum thread for further information.\nQ: Do I need heatsinks on any of the components on the Clusterboard?\nA: According to the datasheets for the RTL8370N switch ASIC and the RTL8211E PHYs, they consume and thus dissipate up to about 3 W each. As a result, it would be advisable to properly affix passive aluminum heatsinks onto each of these components. Please note that this explanation does not cover the SOPINE and SOEDGE modules.\nSpecifications These are the Clusterboard specifications:\nStandard mITX form-factor (167 mm x 170 mm) Built-in eight-port Gigabit Ethernet switch, using RTL8370N ASIC; the switch is unmanaged although the ASIC provides management functions, see this forum thread for further information Seven internal Gigabit Ethernet ports, one for each SOPINE module, connected to the built-in switch using RTL8211E PHYs One connector for an eMMC module, for the first SOPINE module Seven USB 2.0 ports, one for each SOPINE module GPIO pins exposed for each SOPINE module, including the UARTs Gigabit Ethernet port activity LEDs, one for each SOPINE module Battery holder for two standard non-rechargeable AA-size 1.5 V batteries, for the real time clock (RTC) backup on all SOPINE modules Barrel-style jack as a power input, 6.3 mm outer diameter and 3.0 mm inner diameter, for a 5 V, 15 A DC power supply Standard 24-pin ATX header as a power input, for an ATX power supply capable of providing at least 15 A at its 5 V output Please note than only one power input may be used at once. The barrel-style jack is additionally protected by a built-in 15 A polyfuse.\nNote No batteries for RTC backup should be installed unless certain hardware modifications are applied to the Clusterboard. Internal circuitry of the Clusterboard and SOPINE modules will eventually attempt to charge the batteries, which will result in damage to the batteries and the Clusterboard. Keep in mind that rechargeable batteries cannot be used because there is no charging circuitry for them on the Clusterboard. Please see this forum thread and this article for further information. Schematics Clusterboard version 2.2 Schematic Capture source file Clusterboard version 2.2 Schematic Capture PDF file Clusterboard version 2.2 PCB Job source file Clusterboard version 2.2 PCB Gerber file Clusterboard version 2.2 PCB Layout PDF file Clusterboard 20pins header definition Clusterboard 3D drawing in Fusion360 Clusterboard PDF drawing ","permalink":"/documentation/Clusterboard/_full/","tags":null,"title":"Clusterboard (Single Page)"},{"categories":null,"contents":"PineTime/InfiniTime needs a companion app to e.g. upload a firmware, get notifications from a phone, or just get the date/time. Here are some companion apps:\nGadgetbridge (Android \u0026gt;= 4.4) - Companion mobile app, supports updating firmware/bootloader, send notifications, etc. Amazfish (SailfishOS, Ubuntu Touch and Linux) - Companion mobile and desktop app, supports updating firmware/bootloader, send notifications, etc. Watchmate (Linux) Siglo (Linux) - Companion desktop app. PinetimeFlasher (Windows) - Companion desktop app, only supports flashing firmware. nRFConnect (iOS) - Only supports flashing firmware. The app is closed source and versions after 4.24.3 don’t work for the PineTime anymore InfiniLink (iOS) - Companion mobile app in development. Supports updating firmware/bootloader, setting date and time, Apple Music controls, and battery and heart rate data. ITD (Linux) ","permalink":"/documentation/PineTime/Software/Companion_apps/","tags":null,"title":"Companion apps"},{"categories":null,"contents":" Compatibility with other projects Different firmware running using different bootloaders and Bluetooth stacks on the nRF52832 have different requirements on how they should be initialised and what should be placed where in the internal flash.\nTo keep track of what, how and why things work like they do across the different projects, check out the PineTime SoftDevice and MCUBoot compatibility article.\nCompatibility with companions apps and Bluetooth communication There are a lot of different firmware running on the Pinetime that implement different BLE APIs (for example for time synchronization and notifications). Companion apps must be able to differentiate between different firmware and forks of the same firmware. See Bluetooth.\n","permalink":"/documentation/PineTime/Development/Compatibility/","tags":null,"title":"Compatibility"},{"categories":null,"contents":"When the Ox64 is in bootloader mode, some UARTs are unable to communicate with it. When this is the case, utilities such as BLDevCube are unable to actually program the device. If you see \u0026ldquo;Shake hand fail\u0026rdquo; and an empty ack, and your device is in bootloader mode, then it is likely an incompatible UART.\nThe below devices have been tested and verified as working:\nRaspberry Pi Pico - running the following UART firmware (GP4 and GP5 are used for port 0, GP12 and GP13 for port 1) Compiled binary for Pi Pico and connectivity diagram is here ESP32 with CP210x - bridge the EN pin to ground to disable the ESP32 itself, and then connect the TX on the esp32 to 14 on the Ox64 and RX to pin 15. Note that only baud rate 115200 works, and this doesn’t seem to work for everyone) Stand-alone CP2102 dongle works at 115200 baud. Brand used was HiLetgo. STM32F401 BlackPill - running the Black Magic Debug firmware STM32F103C8T6 BluePill - running Black Magic Debug. STM32F103C8T6 BluePill - running BluePill Serial Monster Some UART adapters based on the FT232H (note that the FT232RL does not work, and neither does the Pine 64 JTAG) Some CH340G based adapters work and some don’t. ","permalink":"/documentation/Ox64/Further_information/Compatible_UARTs/","tags":null,"title":"Compatible UARTs"},{"categories":null,"contents":" Component Model Touchscreen Goodix GT917S Rear camera OmniVision OV5640 Camera flash SGMICRO SGM3140 Front camera GalaxyCore GC2145 LCD Xingbangda XBD599 WiFi Realtek RTL8723CS Bluetooth Realtek RTL8723CS Modem Quectel EG25-G GNSS/GPS Quectel EG25-G Magnetometer ST LIS3MDL Ambient light / Proximity SensorTek STK3335 Accelerometer / Gyroscope InvenSense MPU-6050 Vibration motor Unknown model Notification LED LED0603RGB Volume buttons Buttons connected to the KEYADC Power button X-Powers AXP803 Battery fuel gauge X-Powers AXP803 Components list The following list of components are found in the schematic for the PinePhone 1.2b.\nAbreviations used in schematic The following abbreviations are used as the starting letter(s) to identify the components in the PinePhone schematics:\nANT: antenna C: capacitor D: diode DU: Only used in the \u0026ldquo;DU1\u0026rdquo;, which is an integrated circuit for memory ED: Zener diode to protect against electrostatic discharge FB: ferrite bead J: wire link (i.e. a connector) R: resistor L: inductor NC/: not connected (i.e. the part probably isn’t placed on the board, but there are circuits in the PCB for it) Q: transistor SW: switch T: test point U: integrated circuit (i.e. a silicon chip) X: crystal oscillator (used for clocks) P.4 LPDDR3 FPGA178 Note: The title of this schematic page should be changed from \u0026ldquo;LPDDR3 FPGA178\u0026rdquo; to \u0026ldquo;LPDDR3 FBGA178\u0026rdquo;, because the RAM chip is a 178-pin fine pitch ball grid array (FBGA), not a field-programmable gate array (FPGA).\nDU1:\nArtmem ATL3A1632H12A 2GB 800MHz LPDDR3-1600 SDRAM, FBGA-178 11.0x11.5x0.93 mm Note: RAM will be clocked slower, since the Allwinner A64 only supports up to 3GB DDR3-1333 (666.5MHz) and doesn’t specify the top supported LPDDR3 speed. P.5 CPU U1:\nAllwinner A64 1.2Ghz 4x Cortex-A53, 64-bit, superscalar, 32KB instruction \u0026amp; 32KB data L1 cache per core, 512KB L2 shared cache, ARM Mali-400 MP2 (Utgard) GPU, HDMI 1.4 (up to 4K@30), USB 2.0 with OTG, MIPI CSI, 4 channels in/out, 24-bit, 8-48 KHz audio, video encode: H.264 1080p@60, video decode: H.265 4K@30, H.265 1080p@120, H.264, MPEG1/2/4 / VP8 / AVS / AVS+ 1080p@60, FBGA-396 15x15 mm Note: Clocked at 1.152Ghz on the PinePhone. X501:\nAxtal AXX3225 24MHz ±10ppm quartz crystal oscillator in SMD package, 3.2x2.5 mm D500:\nWill Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. X500:\nSeiko Instruments Inc. (SII) SC32S 32.768KHz crystal oscillator Note: Not clear if using the SC32S-12.5PF20PPM or the SC32S-7PF20PPM P.6 POWER ED600:\nWill Semiconductor (WILLSEMI) ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. Note: This part is marked as optional in the schematic and may not be included. U600:\nX-Powers AXP803 power management integrated circuit (PMIC) optimized for multi-core systems, li-ion battery fuel gauge, USB charger (up to 2.8A), QFN 68-pin, 8x8 mm Q600:\nWill Semiconductor WPM1481 single P-channel, -12V, -5.5A, power MOSFET J600:\nBA5924211-R battery connector Note: Picture shows this part as having 8 pins, but the schematic shows 6 pins. One page says that it is made by LateralPressure, but another says it is made by ROHM. L606:\nIND_252010 2.2uH-2A inductor Note: Maybe this is the TDK VLS252010HBU. U601:\nLowPowerSemi LP6226CB6F high efficiency boost DC/DC converter with 33V, 1.5A power MOSFET, SOT23-6 package D600:\nOn semiconductor SS24 Schottky power rectifier, SOD123 package P.7 NAND/eMMC U700:\nKimtigo KM110SS0016GxA-DDD00WT 16GB eMMC 5.1 TLC NAND Flash memory, FBGA-153 11.5×13.0×1.0 mm. Note 1: The schematic says the package is BGA-169, but the Kimtigo documentation says it is FBGA-153. Note 2: The A64 only supports up to eMMC 5.0. Note 3: The schematic lists the part as KM110SS0016GxA-DDD00WT, but these photos show that its variant, the KM111SS0016GxA-DDD00WT, is being used in the 16GB PinePhone. P.8 AUDIO ED800, ED801, ED802, ED803, ED804, ED805, ED806:\nWill Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. U801:\nBroadchip BCT4717ETB-TR 4.0Ω, 300MHz bandwidth, dual bi-directional SPDT (single-pole/double-throw) analog switch J800:\nEAROUTN-A64 receiver J801:\nJA-3606-001AA 3.5mm audio jack Q801:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type U800:\nShanghai awinic technology AW8737SCSR high efficiency (80%), low noise (53μV), ultra-low distortion (0.008%), constant large volume, 7th generation class K audio amplifier, 1.6×1.68 mm CSP-14 package, 0.4mm pitch datasheet FB800, FB801:\n600ohm at 100MHz ferrite bead in a 0402 package (examples) P.9 T-CADD/USB Q901, Q902, Q903:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type ED900, ED901, ED902:\nWill Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. J901:\nSA-2202-112 25-pin Micro-SIM and TF slot P.10 CAMERA J1000:\nT03-1025-FG01 27-pin connector to the rear camera. Note: The schematic says \u0026ldquo;GC2035-200W\u0026rdquo;, which is a mistake because the rear camera is the OmniVision OV6540. J1001:\nT03-1025-FG01 27-pin connector to the front camera. Note: The schematic says \u0026ldquo;GC2035-200W\u0026rdquo;, which is a mistake because the rear camera is the GalaxyCore GC2145, not the GalaxyCore GC2035. U1000:\nShanghai awinic technology AW3641EDNR flash LED driver with programmable timer and PWM dimming torch mode, 1A, 8 current levels. P.11 LCM/CTP Note: \u0026ldquo;LCM/CTP\u0026rdquo; means \u0026ldquo;liquid crystal display monitor/capacitive touch panel\u0026rdquo;. An LCM generally includes an LCD screen + LED backlight + PCB with the LCD controller + frame.\nJ1100:\nFPC24-PT05B, OK-24F-04 28-pin connector to the MIPI-DSI LCD LED2:\nRGB LED J1101:\nCON6-0.5, TP_6PIN-ZQ01 8-pin connector to the capacitive touch panel controller Note: The label says that the connector has 6-pins, but the schematic shows 8-pins. ED1100, ED1101, ED1102, ED1103:\nWill Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. U1100:\nChipown AP3127B025 step-up DC/DC converter series, white LED backlight driver, 6-pin SOT-23-6L package. P.12 SENSORS/MT/KEY J1200:\n8-pin connector to test points ED1200, ED1201: Will Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. U1200:\nSTmicroelectronics LIS3MDL ultra-low-power three-axis magnetometer, LGA-12 2.0x2.0x1.0 mm datasheet Note: The LIS3MDL is currently unavailable, so it has been replaced in the PinePhone Beta Edition with the Voltafield AF8133L e-Compass, which is unlisted on the Voltafield web site, but the AF8133J is listed. Presumably U1200 will be unpopulated and U1203 will be populated in the Beta Edition, since they appear to be alternatives. U1201:\nSensorTek https://web.archive.org/web/20190601120915 / STK3311-A proximity and ambient light sensor (large gap) with built-in infrared LED, DFN-8 3.94x2.36x1.35 mm datasheet U1202:\nTDK InvenSense MPU6050 six-axis, low-power MEMS gyroscope and accelerometer, QFN-24 4x4x0.9 mm datasheet U1203:\nAsahi Kasei Microdevices (AKM) AK09911 3-axis electronic compass IC with Hall sensor, 8-pin WL-CSP (BGA), 1.2×1.2×0.5 mm or Voltafield Technology Corp. (VTC) AF8133J 3-axis electronic compass with proprietary anisotropic magneto resistive (AMR) technology, 8-pin WLCSP 1.2x1.2x0.5 mm Note: These parts appear to be alternatives to be used if the LIS3MDL is unavailable, so U1203 was probably unpopulated in BraveHeart and the Community Editions, but will be populated in the Beta Edition. U1204:\nBosch Sensortek BMI120 3-axis gyroscope and accelerometer, LGA-14 2.5x3.0x0.83 mm Note: Listed as \u0026ldquo;NC/BMI120\u0026rdquo;, where \u0026ldquo;NC\u0026rdquo; probably means \u0026ldquo;not connected\u0026rdquo;, so there may be circuits in the PCB for the part, but it is not placed on the board. This is probably an alternative to the TDK InvenSense MPU6050, in case it isn’t available or costs too much. Q1200:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type D1200:\nTorex XBS104S14 Schottky barrier diode, 1A, 40V, SOD-123A package J1201:\n2-pin connector to a motor, 1x1.8 mm Note: Presumably this is a vibration motor. P.13 DIGITAL VIDEO J1300:\nOK-50F-04 40-pin connector Note: This part is probably produced by Shenzhen Yaqi Technology Co., which is part of OCN in Taiwan, and uses the Archie brand name.\u0026lt; U1304:\nAnalogix ANX7688 HDMI to USB-C bridge with MUX, converts HDMI 2.0 to DisplayPort Alternate Mode, USB-C Power Delivery (PD), BGA-64. Note 1: The schematic lists this part as \u0026ldquo;ANX7688S\u0026rdquo;, but it is unclear what the \u0026ldquo;S\u0026rdquo; at the end stands for. Note 2: xnux.eu provides more info on the ANX7688, including flashing the firmware. U1300:\nAmerica Techcode Semiconductor TD6817 1.5MHz 2A synchronous step-down regulator dropout, SOT23-5 package or Diodes Incorporated AP3406K-ADJTRG1 buck switching regulator IC positive adjustable 0.6V 650mA datasheet U1302:\nLowPowerSemi LPW5206H USB power loading switch, N-channel MOSFET, SOT23-5 package U1303:\nTexas Instruments TXB0104YZT 4-bit bidirectional voltage-level translator with automatic direction sensing and ±15-kV ESD protection, 12-pin DSBGA 1.40×1.90 mm Q1300, Q1301, Q1302, Q1304, Q1305:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type U1305, U1309:\nWill Semiconductor WS4621C-1X1 2A, 38 mΩ, 290nA quiescent current and 70nA standby current load switch, CSP-4L 1x1 mm. U1308:\nShanghai awinic technology AW3632 high efficiency, low profile, fixed 5V output pump power supply, QFN-8 package X1300:\nMercury United Electronics X3225 27.000 MHz crystal oscillator P.14 WIFI+BT U1400:\nRealtek RTL8723CS 802.11 b/g/n, single-band (2.4 GHz), Bluetooth 4.0, with SDIO for WiFi and UART for Bluetooth, LGA-40 12x12x1.6 mm. X1400:\n24Mhz ±10ppm crystal oscillator D1400:\nSXSEMI AU0511P1 low capacitance ESD protection diode, SOD-882 ANT1400\nAntenna P.15 MODEM-4G U1500:\nQuectel EG25-G https://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf GSM/UMTS/LTE cellular modem and GNSS (GPS/Galileo/GLONASS/BeiDou/QZSS, with A-GPS), LGA-144 9.0x32.0x2.4 mm U1502, 1503, 1504:\nTexas Instruments TXB0104YZT 4-bit bidirectional voltage-level translator with automatic direction sensing and ±15-kV ESD protection, 12-pin DSBGA 1.40×1.90 mm Q1501, Q1503, Q1504, Q1505:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type J1500, J1502:\nMRF004-P01A 4-pin connector Q1500:\nWill Semiconductor WPM1481 single P-channel, -12V, -5.5A, power MOSFET Note: The documentation shows 6 pins, but the schematic shows 8 pins. Component Counts Type of component Main PCB USB PCB Antenna connectors (ANT_xxx_) 6 4 Capacitors (C_xxx_) 296 16 Diodes (D_xxx_) 5 0 Zener diodes (ED_xxx_) 17 0 Ferrite beads (FB_xxx_) 6 0 Wire links / connectors (J_xxx_) 14 4 Resistors (R_xxx_) 222 0 Inductors (L_xxx_) 15 0 Transistors (Q_xxx_) 16 19* Switches (SW_xxx_) 1 0 Test points (T_xxx_) 27 3 Integrated circuits (U/DU_xxx_) 24† 2 Crystal oscillators (X_xxx_) 5 0 Total without test points 627 45 Total with test points 654 48 Here is how the PinePhone compares with the Librem 5 in terms of components:\nType of component Librem 5 main Librem 5 USB PinePhone main PinePhone USB Antenna connectors (ANT_xxx_) 3 2 6 4 Capacitors (C_xxx_) 521 11 296 16 Diodes (D/TVS/ED_xxx_) 59 1 22 0 Connectors (J/CON_xxx_) 26 10 14 4 Resistors (R/F_xxx_) 348 8 222 0 Inductors (L/FB_xxx_) 79 7 21 0 Transistors (Q_xxx_) 17 0 16 19* Switches (SW_xxx_) 5 0 1 0 Test points (T/TC/TP/TS/TV_xxx_) 126 4 27 3 Integrated circuits (U/DU_xxx_) 65 2 24† 2 Crystal oscillators (Y/X_xxx_) 10 0 5 0 Total without test points 1133 41 627 45 Total with test points 1259 45 654 48 18 parts for the PinePhone USB-C port are labeled as T_xxx_ in the schematic with the image of transistors, but it is possible that these are resistors and capacitors. † There are 26 U/DU_xxx_ listed in the PinePhone schematic, but the two extra are for an alternative magnetometer (U1200 / U1203) and an alternative gyroscope and accelerometer (U1202 / U1204) which are unpopulated.\nSource: Amos Batto\nOther components not in the schematics SGMICRO SGM3140 500mA buck/boost charge pump LED driver for camera flash and torch, TDFN-10 3x3x0.75 mm Note: The PinePhone page lists the SGM3140, but the schematics contain the U1000: awinic AW3641EDNR, so it is unclear why the SGM3140 is needed. Goodix GT917S touch controller Sitronix ST7703 MIPI LCD driver Xingbangda XBD599 5.99″ IPS LCD, 720x1440 pixels, 16.7M colors, hardened glass ","permalink":"/documentation/PinePhone/Further_information/Components/","tags":null,"title":"Components"},{"categories":null,"contents":"The Quartz64 single-board computers (both Model A and Model B) come with MIPI-DSI ports for connecting a MIPI-DSI compatible display.\nThis article will go into how to connect the official PINE64 7\u0026quot; LCD Touch Screen Panel and setting up the software. Since this requires a panel driver for each panel, other displays generally are not interchangeable, as they won’t use the same driver compatible (or even have a mainline driver at all!)\nConnecting the hardware When connecting the display, please make sure the board is powered off and unplugged. Failure to do so could make you short out the pins while connecting it!\nModel A To connect the hardware, lift up the dark flap of the part marked with \u0026ldquo;DSI\u0026rdquo; in red in the above picture. Then, insert the flat flex cable with the contacts pointing down (and the blue backing pointing up). In the same fashion, connect the thinner touch panel controller cable to the port marked with \u0026ldquo;TP\u0026rdquo; in blue.\nFor the DSI cable, connect the other end to the small green joiner/adapter board, which you can first connect to the display’s DSI connector, again with the contacts facing down.\nFor the touch cable, connect the other end to the small green PCB attached to the back of the panel, again paying attention to have the contacts facing downwards (and the blue backing facing upwards).\nModel B Important Note: There’s no port for the touch panel input on Model B. TODO: Write this section. Adapter cable is needed.\nSetting up the software For the display to be used, you need to tell the kernel about it by modifying the device tree. The easiest way to go about this is to use device tree overlays.\nThe kernel needs to be built with CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D turned on (either as module or built-in), as that is the driver for this panel.\nOn Plebian Important Note: Currently Debian’s kernel doesn’t have the panel driver built as part of its configuration. We’ll get that sorted soon. Use git clone to clone the overlay-examples repository by CounterPillow. Then, grab a copy of the Linux kernel source from kernel.org if you don’t already have one. To build the device tree overlays, run make INCLUDE_DIR=path/to/linux/include in the overlay-examples directory, substituting path/to/linux/include with your path of course.\nFor Quartz64 Model A, copy build/quartz64a/pine64-lcd-panel.dtbo into your /boot/dtbo/ directory (create it if it doesn’t already exist) and run sudo u-boot-update.\nThat’s all there is to it, the panel should light up on your next reboot.\n","permalink":"/documentation/Quartz64/How-Tos/Connecting_a_MIPI-DSI_display/","tags":null,"title":"Connecting a MIPI-DSI display"},{"categories":null,"contents":" Get in touch with the community If you need assistance with setting up your PINE64 device or have questions about the community resources (such as the software, the community website and the documentation) and general questions, you can contact the community by joining the community:\nWelcome to the PINE64 community! The community is happy to help you set up your device and to answer any questions you have regarding the hardware and software, as well as regarding the development. Many of the devices produced by the Pine Store ship with software and other resources created by us, the community. That means that getting in touch with the community if you have any question regarding the devices and how to use them will get you in contact with the technical experts directly.\nCome join us! You can get in touch via Discord, IRC, Matrix and Telegram under the above link. There are also Subreddits and a forum.\nPine Store contact For all inquiries regarding sales, shipping, warranty and returns please contact the relevant Pine Store ltd. e-mail or use the online support system.\nFor general queries and information from the Pine Store: info@pine64.org For queries regarding support from the Pine Store: support@pine64.org For sales/wholesale related questions: sales@pine64.org Note: the Pine Store e-mail addresses are on the pine64.org (community) domain due to historical reasons.\n","permalink":"/contact/","tags":null,"title":"Contact"},{"categories":null,"contents":"The Pinephone’s triple for cross-compiling is aarch64-unknown-linux-gnu.\nC/++ Installing the Toolchain Important Please add instructions for other distributions to this section if you know them! First, you’ll need to install the gcc cross-compilation toolchain.\nOn Arch Linux $ sudo pacman -S aarch64-linux-gnu-gcc On Ubuntu/Debian $ sudo apt install gcc-aarch64-linux-gnu On Void Linux $ sudo xbps-install cross-aarch64-linux-gnu Using the Toolchain Note If you are trying to build an Arch Linux package with makepkg, also make sure to export CARCH=aarch64. GNU Make Kernel Makefile For each invocation of make, be sure to pass the options ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- like this:\n$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Other If you are using a handwritten Makefile (not autogenerated by a meta-buildsystem such as meson, automake, etc.) then simply override CC and LD as you need.\nautomake $ ./configure --host=aarch64-linux-gnu meson See the official meson documentation on the topic. In general, the introduction is a good read for any cross-compiling novice.\nRust In order to cross-compile Rust applications for the PinePhone, you need to have a gcc cross-compiler installed and the Rust dependencies, usually the std crate, cross compiled for the target system. A more extensive explanation can be found on https://github.com/japaric/rust-cross. This instruction is based on it’s description.\nInstalling a GCC Cross-Compiler The cross-compiler might have a different name depending on the operating system. Further along this instruction the name for the gcc cross-compiler will be used. Replace all occurrences of $gcc_name with the name on your distribution.\nFor how to install the gcc cross-compilation toolchain on your distribution, please see Cross-compiling\nInstalling Rust Dependencies The necessary dependencies can easily be installed with rustup:\n$ rustup target add aarch64-unknown-linux-gnu OR it can be installed with multirust [Is this still accurate???]:\n$ multirust add-target nightly aarch64-unknown-linux-gnu Compiling rustc When using rustc just add the two flags \u0026ndash;target=aarch64-unknown-linux-gnu and -C linker=$gcc_name. Under Arch, this would look like:\n$ rustc --target=aarch64-unknown-linux-gnu -C linker=aarch64-linux-gnu-gcc main.rs To test it, run the program on your PinePhone\n$ scp main user@ipadress:/home/user/Downloads $ ssh user@ipadress /home/user/Downloads/main Hello, world! cargo To cross-compile a project with cargo, open the folder of the project in a terminal. Then create a new folder and a file for cargo.\n$ mkdir .cargo $ cat \u0026gt;.cargo/config \u0026lt;\u0026lt;EOF \u0026gt; [target.aarch64-unknown-linux-gnu] \u0026gt; linker = \u0026#34;$gcc_name\u0026#34; \u0026gt; EOF Then you can compile it with\n$ cargo build --target=aarch64-unknown-linux-gnu To test it, copy the file on your PinePhone\n$ scp target/aarch64-unknown-linux-gnu/debug/main user@ipadress:/home/user/Downloads Then you can execute it by\n$ ssh user@ipadress ./main -h Hello, world! Possible Errors If you encounter an error saying\nCross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override just add that variable in front of your command e.g.\nPKG_CONFIG_ALLOW_CROSS=1 cargo build --target=aarch64-unknown-linux-gnu ","permalink":"/documentation/General/Cross-compiling/","tags":null,"title":"Cross-compiling"},{"categories":null,"contents":"As per the README.md on the crust github:\nCrust improves battery life and thermal performance by implementing a deep sleep state. During deep sleep, the CPU cores, the DRAM controller, and most onboard peripherals are powered down, reducing power consumption by 80% or more compared to an idle device.\nFor this to work, Crust runs outside the main CPU and DRAM, on a dedicated always-on microprocessor called a System Control Processor (SCP). Crust is designed to run on a specific SCP implementation, Allwinner’s AR100.\nTo build crust manually with U-Boot you can find instructions Here.\nRTC wakeups It is possible to set the device to wakeup at a specific time or after a certain number of seconds using rtcwake: rtcwake -m mem -s 10\nThis example will put the device to sleep for 10 seconds and then wake it up. More information on the rtcwake command can be found in the man pages\nManual suspend For manually suspending the device on distributions with Systemd you can use the following command with super user permissions: systemctl suspend\nOn non-systemd distributions you can directly echo: echo mem \u0026gt; /sys/power/state\n","permalink":"/documentation/PinePhone/Software_tricks/Crust/","tags":null,"title":"Crust"},{"categories":null,"contents":"This is a tutorial to help new users create custom watchfaces based on the InfiniTime Firmware for PineTime made by user JF002, thanks to him for its development.\nWe will explain some of the things we went through while creating some custom Watchfaces, so consider this as a log of experiments of sorts..\nSo stay tuned to it as it will be dynamically updated.\nWhat you need to start The entire building process will be done by GitHub, so all you need is a device which can give you a GitHub Web Client, a PC, or tablet to give you enough screen space to review your code and a steady internet connection.\nSince the compiling and file management is done by GitHub online, you have nothing else to worry about other than working with the files that display the watch face.\nSo with those things settled, let’s start with the basics of a watchface.\nPlease remember that this is a public documentation, so you can make an account and help us improve this page.\nPlease make sure not to unilaterally remove info though, but offer an alternative. If it is indeed a better way, in time your alternative will grow into the main text, and the latter info will be pruned.\nOverview The Firmware (also called InfiniTime) we will be working with is made with a programming language named C++.\nBasic knowledge of C/{cpp} is required to understand the advanced watch faces as that requires more complex code, but you can still do a some cool things without much knowledge of {cpp} programming, just some small edits to existing programs.\nInfiniTime uses the LVGL graphics library to provide users with a simple and clean UI without overpowering the Nordic nRF52832 microcontroller, which is the brain of the watch.\nTo get the watchface to work, there are these basic steps. We will go over each step separately, so don’t be daunted, all will become clear soon.\nFor now, we will modify the existing watchface, change the positioning of the text labels, add an icon to an existing watchface and later on, we will do a full watchface.\nThe main file we need to focus on is the WatchFaceDigital.cpp file, which contains most of the data attributed to what we see on the watchface, including The time/day characters, the battery, and Bluetooth icons, and also pedometer count.\nSo, everything we will be doing in the basic modifications is purely messing with this single file.\nLabels What are labels? Labels are considered as \u0026ldquo;elemental\u0026rdquo; parts that make up a screen’s Text-based UI by the LVGL library. Each label is also considered as an \u0026ldquo;object\u0026rdquo; or \u0026ldquo;obj\u0026rdquo; and can be manipulated. By changing the data attributed with the \u0026ldquo;obj\u0026rdquo;, for example, position, internal data like the strings/text etc. we can change what the label shows and where it shows it.\nModifying label data let’s observe something small like the word \u0026ldquo;BPM\u0026rdquo; near the bottom of the watch face.\nIf we take a look at the source file of the watchface, (a.k.a. the clock.cpp file) we can observe that these particular lines are what attributes to the word \u0026ldquo;BPM\u0026rdquo; being displayed.\nheartbeatBpm = lv_label_create(lv_scr_act(), NULL); lv_label_set_text(heartbeatBpm, \u0026#34;BPM\u0026#34;); We can modify the text inside the quotes and replace the word \u0026lsquo;BPM\u0026rsquo; between those quotes to something like \u0026lsquo;LOVE\u0026rsquo; and the result after compiling the firmware again with the changes and flashing it to the watch would be that the text changes on the watch face and displays \u0026lsquo;LOVE\u0026rsquo; in place of \u0026lsquo;BPM\u0026rsquo;.\nIf this happened correctly, then you have successfully made a custom new watchface|Now we can do something a bit more complex.\nNow take for in instance the days of the week that we have on the bottom line with the date.\nthey are stored a \u0026ldquo;C array\u0026rdquo; which is basically multiple words separated by commas.. the date is in a format of which in the source file is expressed as,\nsprintf(dateStr, \u0026#34;%s %d %s %d\u0026#34;, DayOfWeekToString(dayOfWeek), day, MonthToString(month), year); lv_label_set_text(label_date, dateStr); here,\n%s %d %s %d stores the print format of the variables, and\nDayOfWeekToString(dayOfWeek), day, MonthToString(month), year are the variables themselves\nNow, if the date was a Saturday 11/7/2020, you can observe that the date looks like\nSATURDAY 11 JUL 2020 as seen in the above image (the one where we changed BPM to LOVE)\nby modifying the format of the variables, we can change how those words are arranged, and add some extra characters if we like (there is a catch to the list of characters you can use however, but it will be discussed later)\nFor example,\nIf we modify the format by adding a comma \u0026ldquo;,\u0026rdquo; in between the second \u0026ldquo;%s\u0026rdquo; and \u0026ldquo;%d\u0026rdquo; like this,\n\u0026#34;%s %d %s, %d\u0026#34; and changing that in the line\nsprintf(dateStr, \u0026#34;%s %d %s, %d\u0026#34;, DayOfWeekToString(dayOfWeek), day, MonthToString(month), year); we can make the date become\nSATURDAY 11 JUL, 2020 which means we now were able to modify how the text got displayed to make it a bit more nice\nbut if you haven’t noticed, the line containing the date is already full, meaning we will get some problems while displaying the date and causing it to wrap around, making a single character go to the next line and look more like,\nSATURDAY 11 JUL, 202 0 So, why don’t we shorten the characters present in the date from being \u0026ldquo;SATURDAY\u0026rdquo; to simply just \u0026ldquo;sat.\u0026rdquo; (It will have the small period at the end, and is only 3 characters long). I will also convert the months of the year from Capital to small letters.\nFor that look into the part where the days of the week of are stored as text, and also while looking at it, we can solve another question, why was there two variables in the date format that looked like, DayOfWeekToString(dayOfWeek), and MonthToString(month) ?\nIt is because the system gives the date/ time as numbers (Monday-1, Tuesday-2 Wednesday-3 for the days, and 1-January, 2-February, 3-March ), and so, a function along with a C array is used to assign these numbers to Days/Months in text form as it is easier to read.\nthis is the Array containing the day of the week, (as text)\nchar const *Clock::DaysString[] = { \u0026#34;\u0026#34;, \u0026#34;MONDAY\u0026#34;, \u0026#34;TUESDAY\u0026#34;, \u0026#34;WEDNESDAY\u0026#34;, \u0026#34;THURSDAY\u0026#34;, \u0026#34;FRIDAY\u0026#34;, \u0026#34;SATURDAY\u0026#34;, \u0026#34;SUNDAY\u0026#34; }; and this Array stores the months of the year, (as text)\nchar const *Clock::MonthsString[] = { \u0026#34;\u0026#34;, \u0026#34;JAN\u0026#34;, \u0026#34;FEB\u0026#34;, \u0026#34;MAR\u0026#34;, \u0026#34;APR\u0026#34;, \u0026#34;MAY\u0026#34;, \u0026#34;JUN\u0026#34;, \u0026#34;JUL\u0026#34;, \u0026#34;AUG\u0026#34;, \u0026#34;SEP\u0026#34;, \u0026#34;OCT\u0026#34;, \u0026#34;NOV\u0026#34;, \u0026#34;DEC\u0026#34; }; Here we can see that the days are stored in a full format as \u0026ldquo;SUNDAY\u0026rdquo;, \u0026ldquo;MONDAY\u0026rdquo;, \u0026ldquo;TUESDAY\u0026rdquo; etc. We can change all of them to a shorter format like \u0026ldquo;sun.\u0026rdquo;, \u0026ldquo;mon.\u0026rdquo;, \u0026ldquo;tue.\u0026rdquo;, to make it short and nice. While doing so, we can even make the months use small letters, as said before.\nso the source file (clock.cpp) becomes,\n(for the days of the week)\nchar const *Clock::DaysString[] = { \u0026#34;\u0026#34;, \u0026#34;mon.\u0026#34;, \u0026#34;tue.\u0026#34;, \u0026#34;wed.\u0026#34;, \u0026#34;thu.\u0026#34;, \u0026#34;fri.\u0026#34;, \u0026#34;sat.\u0026#34;, \u0026#34;sun.\u0026#34; }; and\n(for the months of the year)\nchar const *Clock::MonthsString[] = { \u0026#34;\u0026#34;, \u0026#34;jan\u0026#34;, \u0026#34;feb\u0026#34;, \u0026#34;mar\u0026#34;, \u0026#34;apr\u0026#34;, \u0026#34;may\u0026#34;, \u0026#34;jun\u0026#34;, \u0026#34;jul\u0026#34;, \u0026#34;aug\u0026#34;, \u0026#34;sep\u0026#34;, \u0026#34;oct\u0026#34;, \u0026#34;nov\u0026#34;, \u0026#34;dec\u0026#34; }; which means now our original date, Saturday 11/7/2020 will become\nsat. 11 Jul, 2020 you now know how to change the data present in a label object, and the format of it..,\nHere is a fun idea you can try: you can even replace the days with whatever thing that tells you (or) reminds you the day of the week (like the food served in the café, Monday/taco, Tuesday/burger, Wednesday/pasta etc.)\nNote When making the custom array, don’t forget to leave an empty \u0026quot;\u0026quot; as the first element of the array, This is because the date is given by the system in a natural numbers format (1,2,3, and so on) rather than a zero-starting format (0,1,2,3, and so on), which the C array uses to index. So the C array indexes the days as \u0026ldquo;\u0026quot;-0, \u0026ldquo;Monday\u0026rdquo;-1, \u0026ldquo;Tuesday\u0026rdquo;-2 etc. and the months as \u0026ldquo;\u0026quot;-0, \u0026ldquo;January\u0026rdquo;-1, \u0026ldquo;February\u0026rdquo;-2 and so on. Label positioning The locational placement in LVGL is done on a Cartesian plane, where each object can have dynamic origin placement, and the Y-axis is inverted. So going down is done with a positive Y-axis value and not negative as it is by default.\nLVGL coord system\nThe position of the various objects in WatchFaceDigital.cpp are set by the line,\nlv_obj_set_pos(\u0026lt;obj\u0026gt;, \u0026lt;new_x\u0026gt;, \u0026lt;new_y\u0026gt;) and the top-left corner is the Cartesian origin, aka coordinates (0,0)\nthis image can show you how to decide label placement for lv_obj_set_pos(\u0026hellip;)\nWe use another function, that is more advanced, that gives the positional alignment based on preset locations\nlv_obj_align(obj, obj_ref, LV_ALIGN_..., x_ofs, y_ofs); obj is your text label\nobj_ref is a reference object to which obj will be aligned. If obj_ref = NULL , then the parent of obj will be used. If obj_ref = lv_scr_act(), then the whole screen will be used.\nLV_ALIGN_\u0026hellip; is the type of alignment; inside another object or next to the reference, for example IN_TOP_LEFT, OUT_BOTTOM_MID, \u0026hellip;\nx_ofs, y_ofs allow you to shift the object by a specified number of pixels after aligning it\nLabel positioning based on alignment is both a simple and complicated thing to understand, so here I have given something you can refer to while modifying the position of the various labels and objects.\nYou can also refer here to LVGL’s documentation of coordinate system https://docs.lvgl.io/master/overview/coords.html\nList of the possible alignments: https://docs.lvgl.io/latest/en/html/widgets/obj.html#alignment\nIt is however recommended that you use the first method to set the location\nlv_obj_set_pos(\u0026lt;obj\u0026gt;, \u0026lt;new_x\u0026gt;, \u0026lt;new_y\u0026gt;) as it is simple and easier for beginners\nHere is a small example.\nTake the Label that tells the date, In the Digital Clock source file (WatchFaceDigital.cpp) it is this line,\nlv_obj_align(label_date, lv_scr_act(), LV_ALIGN_CENTER, 0, 60); by increasing the Value of the Y coordinate (60) to a higher value, we can bring the position of the Date downwards a bit away from the Time, and toward the Heartbeat count in the bottom row here I will increase it to 80, so it becomes..\nlv_obj_align(label_date, lv_scr_act(), LV_ALIGN_CENTER, 0, 80); and now we have made some space up top..\nnow let’s try something a bit complex,\nTake the position argument for the label that tells you time. Here, in the source file (WatchFaceDigital.cpp),\nlv_obj_align(label_time, lv_scr_act(), LV_ALIGN_IN_RIGHT_MID, 0, 0); this line determines the position of the Label telling time, as seen in the image\nwe’re modifying this, by changing the origin alignment parameter (here it is LV_ALIGN_IN_RIGHT_MID) to LV_ALIGN_IN_TOP_LEFT\nyou can alternatively swap the whole line to:\nlv_obj_set_pos(label_time, 0, 0); this makes the Time label/obj. to go to the top-left corner\nbut I will do something a little extra, I will modify the label that store the data and Time format, i.e this line,\nsprintf(timeStr, \u0026#34;%c%c:%c%c\u0026#34;, hoursChar[0],hoursChar[1],minutesChar[0], minutesChar[1]); by removing the \u0026ldquo;:\u0026rdquo; colon in between the numbers, and replacing it with a Newline symbol \u0026ldquo;\\n\u0026rdquo; I change it to become,\nsprintf(timeStr, \u0026#34;%c%c\\n%c%c\u0026#34;, hoursChar[0],hoursChar[1],minutesChar[0], minutesChar[1]); this gives it a nice wrapped text format in the top corner, and gives us some space to play with in the side, for things like Pictures and icons, which we will do next..\nIf you have been able to do these things, you now have completed the 2nd part of the tutorial, and now know how to change and modify the position of labels.\nUsing icons The LVGL library allows for the use of widgets known as \u0026ldquo;Images\u0026rdquo;, In short it allows you to use small Icons like pictures with a small dedicated function, However, when this was attempted the first time we stumbled on some problems as LVGL v6 (used on the PineTime) is not much documented as the latest release (v7 as of August 2020) but also the existing code was only documented for C not {cpp}, after some painful attempts we were able to translate it into {cpp},\nTo bring images into Clock.cpp you will need to do the following,\nHave a small image that cannot exceed a maximum size of 240px x 240px (PineTime max resolution) Use this Image converter (Thanks to LVGL) https://lvgl.io/tools/imageconverter to convert your image to a C array and having the Color format as \u0026ldquo;True color\u0026rdquo; and the output format as \u0026ldquo;C array\u0026rdquo;. Make sure to use something simple as the name we will be using \u0026ldquo;bitmap\u0026rdquo; as the name, but will also be referred as for simplicity Note for example we shall use = bitmap, but any simple word can be used, as long as it does not cause problems with system variables Image size considerations since the image will be using the flash directly, we need to be considerate about flash memory usage.\n\u0026lt;picture_X\u0026gt; x \u0026lt;picture_Y\u0026gt; x 2 gives you the number of KB the image used in storage\nwhere, \u0026lt;picture_X\u0026gt; \u0026lt;picture_Y\u0026gt; are the dimensions of the image horizontally and vertically\nfor example,\nif \u0026lt;picture_X\u0026gt;=80px \u0026lt;picture_Y\u0026gt;=64px then,\ntotal storage used = 80 x 60 x 2 = 10.24KB Please use the flash storage with consideration, when using other apps as well, excess usage of storage might mean the Firmware will not compile. The limit to storage to about 400Kb for the user, the firmware size must not exceed that.\nPreparing the image for inclusion as an icon Once you have obtained your C array from the LVGL converter, you can take a look inside it to see all the different formats of your image, try using something like Notepad++ or any of your favorite text editors to peek inside it,\nthere will be 4 sets of Arrays inside it that look like,\n#if LV_COLOR_DEPTH == 1 || LV_COLOR_DEPTH == 8 /*Pixel format: Red: 3 bit, Green: 3 bit, Blue: 2 bit*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00, #endif #if LV_COLOR_DEPTH == 16 \u0026amp;\u0026amp; LV_COLOR_16_SWAP == 0 /*Pixel format: Red: 5 bit, Green: 6 bit, Blue: 5 bit*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00, #endif #if LV_COLOR_DEPTH == 16 \u0026amp;\u0026amp; LV_COLOR_16_SWAP != 0 /*Pixel format: Red: 5 bit, Green: 6 bit, Blue: 5 bit BUT the 2 bytes are swapped*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00, #endif #if LV_COLOR_DEPTH == 32 /*Pixel format: Fix 0xFF: 8 bit, Red: 8 bit, Green: 8 bit, Blue: 8 bit*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0xff, #endif }; And another small bit of info we will need for later that looks like,\nconst lv_img_dsc_t bitmap = { .header.always_zero = 0, .header.w = 40, .header.h = 40, .data_size = 1600 * LV_COLOR_SIZE / 8, .header.cf = LV_IMG_CF_TRUE_COLOR, .data = bitmap_map, }; Note There are some header files at the top, which we can ignore. RGB565 image format The PineTime uses a display that uses a 16 bit color space, also known as RGB565.\nThese 16 bit are assigned to RGB as 5 bits each for Red and Blue and 6 bits for Green, so 5+6+5=16 bits are required, so each pixel’s color occupies 2 bytes of data, and since 2^16^ is equal to 65,536 it allows us to view 65,536 or 65k colors\nThe way it packs these bits is by converting the bits into 2x 4+4 bit hex-code, so for example,\nif the color of a pixel in Binary is 10110100 01011111 (this color is approximately Lavender purple)\nIt is split as 1011 \u0026amp; 0100 for the first byte and 0101 \u0026amp; 1111 for the second byte and so, converting the binary into Hex-code,\nthe two parts are 0xB4 and 0xF5\nThese two parts in conjunction are used for determining the color of one pixel.\nalso from the binary, it is observed that,\nThe bits 10110 is used for Red, 100010 is used for green, and 11111 is used for blue.\nFlipping the bytes The LVGL library has a feature that allows you to flip the two bytes of the pixel, so if the two parts were, \u0026hellip;0xB4,0xF5,\u0026hellip; ,it will change it to become, \u0026hellip;0xF5,0xB4,\u0026hellip;\nThe reason for this is to allow the use of 8-bit SPI interfaces, but we do not require it, and if set with wrong parameter we could get problems with the color\u0026hellip;\nTo make sure you are ready for the next step, make sure that inside your LVGL configuration file (located at src/libs/lv_conf.h)\nthis parameter,\n#define LV_COLOR_16_SWAP 1 is set to \u0026ldquo;1\u0026rdquo; as seen.\nNote If you haven’t modified it or tampered with it with your GitHub fork, you shouldn’t have a problem as it is correct by default, and you can skip these steps Creating an Object from the Array To include the Icon, first Identify the Array you need to copy to the source (clock.cpp)\nThe one we require from it is the data below the tag that looks like:\n#if LV_COLOR_DEPTH == 16 \u0026amp;\u0026amp; LV_COLOR_16_SWAP != 0 /*Pixel format: Red: 5 bit, Green: 6 bit, Blue: 5 bit BUT the 2 bytes are swapped*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00, #endif from this copy the Data from the array alone\u0026hellip; I.e this part,\n0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00 (Make sure to not include the comma at the end or the #endif as the entire part is going to substitute a new array)\nIn clock.cpp, just below the header files and the Task creation part (I.e event_handler\u0026hellip;),\nstatic void event_handler(lv_obj_t * obj, lv_event_t event) { Clock* screen = static_cast\u0026lt;Clock *\u0026gt;(obj-\u0026gt;user_data); screen-\u0026gt;OnObjectEvent(obj, event); } create a name for the label with,\nstatic lv_img_dsc_t \u0026lt;name\u0026gt;; // remember to replace \u0026lt;name\u0026gt; with the actual name you gave to your image while converting! then below it create a array to hold the data with,\nconst uint8_t \u0026lt;name\u0026gt;_map[] = {}; // paste the array you copied from the conversion file we specified above... so your array is something like,\nconst uint8_t \u0026lt;name\u0026gt;_map[] = {0x00,0x00,0x00... ...0x00,0x00,0x00}; so your Entire top region of declaration looks like,\n#include \u0026lt;cstdio\u0026gt; #include \u0026lt;libs/date/includes/date/date.h\u0026gt; ... using namespace Pinetime::Applications::Screens; extern lv_font_t jetbrains_mono_extrabold_compressed; extern lv_font_t jetbrains_mono_bold_20; extern lv_style_t* LabelBigStyle; static void event_handler(lv_obj_t * obj, lv_event_t event) { Clock* screen = static_cast\u0026lt;Clock *\u0026gt;(obj-\u0026gt;user_data); screen-\u0026gt;OnObjectEvent(obj, event); } //Declare the descriptor here static lv_img_dsc_t \u0026lt;name\u0026gt;; //place the Image data here const uint8_t \u0026lt;name\u0026gt;_map[] = {0x00,0x00,0x00... ...0x00,0x00,0x00 }; Note Declaring variables outside a function like we did above is known as global scope declaration, this means the variable can be used by not just one function but the Entire code. Then inside the\nClock::Clock(DisplayApp* app,...){... region (the watchface function), you need to place a particular set of lines which LVGL uses to define the object to declare the array as an Icon/Image, You can place this set of lines above label_time.\n\u0026lt;name\u0026gt;.header.always_zero = 0; //Initialization \u0026lt;name\u0026gt;.header.w = \u0026lt;picture_X\u0026gt;; // Setting the Width (or) Horizontal length of the image (number of px) \u0026lt;name\u0026gt;.header.h = \u0026lt;picture_Y\u0026gt;; // Setting the Height (or) vertical length of the image (number of px) \u0026lt;name\u0026gt;.data_size = \u0026lt;Hr_length\u0026gt; * \u0026lt;Vr_length\u0026gt; * LV_COLOR_SIZE / 8; //Allocation of memory for the image \u0026lt;name\u0026gt;.header.cf = LV_IMG_CF_TRUE_COLOR; // Sets the color scheme for the image \u0026lt;name\u0026gt;.data = \u0026lt;name\u0026gt;_map; // Maps the Image data to the Array lv_obj_t *img_src = lv_img_create(lv_scr_act(), NULL); // Create an image object lv_img_set_src(img_src, \u0026amp;\u0026lt;name\u0026gt;); // Set the created file as image (\u0026lt;name\u0026gt;) again, make sure to replace with the name you gave it during conversion!\nNow that we have bought in the image data, we need to set the position, you can place this just below the lines we wrote for bringing in the image, It can be done with either,\nlv_obj_set_pos(img_src, \u0026lt;x_pos, \u0026lt;y_pos\u0026gt;); // \u0026lt;x_pos\u0026gt;, \u0026lt;y_pos\u0026gt; are the coordinates of the Cartesian plane or,\nlv_obj_align(img_src, lv_scr_act(), LV_ALIGN_\u0026lt;parameter\u0026gt;, \u0026lt;x_pos, \u0026lt;y_pos\u0026gt;); If done correctly, you will now have a beautiful little Icon/Image in your Watch face, make sure that your Watch face can accommodate the image by pushing the other labels farther away, creating space for it.\nWe have provided a small template you can use for adding even a large image comfortably\nIf you have succeeded with this, you have completed part 3 of the tutorial.\nCreating an entirely new watchface The instructions above describe how to modify the existing default watchface, if you would like to create a new watchface instead you will need to complete some additional steps. We will refer to the new watchface as WatchFaceName in these instructions.\nCreate the watchface files The watchface is composed of 2 files, WatchFaceName.cpp and WatchFaceName.h. You can copy them from one of the existing watchfaces and give it a new name to provide a basic layout to start from. It is important to increment the ClockFace number near the top of WatchFaceName.cpp otherwise the wrong watchface will be displayed when leaving the menu.\nsettingsController.SetClockFace(0); Add the watchface to Clock.cpp and Clock.h Clock.cpp now provides the ability to switch between multiple watchfaces by long-pressing the screen. You will need to make 3 modifications in Clock.cpp and 2 modifications in Clock.h.\nsrc/displayapp/screens/Clock.cpp\n#include \u0026#34;WatchFaceDigital.h\u0026#34; #include \u0026#34;WatchFaceAnalog.h\u0026#34; #include \u0026#34;WatchFaceName.h\u0026#34; [this]() -\u0026gt; std::unique_ptr\u0026lt;Screen\u0026gt; { return WatchFaceDigitalScreen(); }, [this]() -\u0026gt; std::unique_ptr\u0026lt;Screen\u0026gt; { return WatchFaceAnalogScreen(); }, [this]() -\u0026gt; std::unique_ptr\u0026lt;Screen\u0026gt; { return WatchFaceNameScreen(); }, std::unique_ptr\u0026lt;Screen\u0026gt; Clock::WatchFaceAnalogScreen() { return std::make_unique\u0026lt;Screens::WatchFaceAnalog\u0026gt;(app, dateTimeController, batteryController, bleController, notificatioManager, settingsController); } std::unique_ptr\u0026lt;Screen\u0026gt; Clock::WatchFaceNameScreen() { return std::make_unique\u0026lt;Screens::WatchFaceName\u0026gt;(app, dateTimeController, batteryController, bleController, notificatioManager, settingsController, heartRateController); } src/displayapp/screens/Clock.h\nScreenList\u0026lt;3\u0026gt; screens; std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceDigitalScreen(); std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceAnalogScreen(); std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceNameScreen(); Be sure to increment the number of screens.\nAdd the watchface to CMakeLists.txt src/CMakeLists.txt\n## Watch faces displayapp/icons/bg_clock.c displayapp/screens/WatchFaceAnalog.cpp displayapp/screens/WatchFaceDigital.cpp displayapp/screens/WatchFaceName.cpp Creating an entirely new watchface (Updated Alternative) The previous method may not work with the current version of Infinitime as of (2023 Jan 28). Therefore, here I will tell you a method of creating watch faces on the current build.\nCreate the watch face files The watch face is composed of 2 files, WatchFaceName.cpp and WatchFaceName.h. You can copy them from one of the existing watch faces and give it a new name to provide a basic layout to start from.\nImportant do not forget to rename the class names to reflect the new filenames.\nAdd the watchface to Clock.cpp and Clock.h Clock.cpp now provides the ability to switch between multiple watchfaces by long-pressing the screen. You will need to make 3 modifications in Clock.cpp, 1 modification in Clock.h and two modifications in SettingsWatchFace.h which will allow us to select the newly created watch face.\nsrc/displayapp/screens/Clock.cpp\n#include \u0026#34;displayapp/screens/WatchFaceDigital.h\u0026#34; #include \u0026#34;displayapp/screens/WatchFaceAnalog.h\u0026#34; #include \u0026#34;displayapp/screens/WatchFaceName.h\u0026#34; switch (settingsController.GetClockFace()) { case 0: return WatchFaceDigitalScreen(); break; case 1: return WatchFaceAnalogScreen(); break; case 2: return WatchFacePineTimeStyleScreen(); break; case 3: return WatchFaceTerminalScreen(); break; case 4: return WatchFaceInfineatScreen(); break; case 5: return WatchFaceCasioStyleG7710(); break; case 6: return WatchFaceNameScreen(); break; } return WatchFaceDigitalScreen(); } std::unique_ptr\u0026lt;Screen\u0026gt; Clock::WatchFaceAnalogScreen() { return std::make_unique\u0026lt;Screens::WatchFaceAnalog\u0026gt;(app, dateTimeController, batteryController, bleController, notificatioManager, settingsController); } std::unique_ptr\u0026lt;Screen\u0026gt; Clock::WatchFaceNameScreen() { return std::make_unique\u0026lt;Screens::WatchFaceName\u0026gt;(app, dateTimeController, batteryController, bleController, notificatioManager, settingsController, heartRateController); } src/displayapp/screens/Clock.h\nstd::unique_ptr\u0026lt;Screen\u0026gt; screen; std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceDigitalScreen(); std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceAnalogScreen(); std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceNameScreen(); Since I have set WatchFaceName to case 6 in a switch statement beforehand it will take sixth position in a list.\nsrc/displayapp/screens/settings/SettingWatchFace.h\n#include \u0026#34;displayapp/screens/WatchFaceInfineat.h\u0026#34; #include \u0026#34;displayapp/screens/WatchFaceCasioStyleG7710.h\u0026#34; #include \u0026#34;displayapp/screens/WatchFaceName.h\u0026#34; std::array\u0026lt;Screens::CheckboxList::Item, settingsPerScreen * nScreens\u0026gt; watchfaces { {{\u0026#34;Digital face\u0026#34;, true}, {\u0026#34;Analog face\u0026#34;, true}, {\u0026#34;PineTimeStyle\u0026#34;, true}, {\u0026#34;Terminal\u0026#34;, true}, {\u0026#34;Infineat face\u0026#34;, Applications::Screens::WatchFaceInfineat::IsAvailable(filesystem)}, {\u0026#34;Casio G7710\u0026#34;, Applications::Screens::WatchFaceCasioStyleG7710::IsAvailable(filesystem)}, {\u0026#34;Name Face\u0026#34;, true}, {\u0026#34;\u0026#34;, false}}}; ScreenList\u0026lt;nScreens\u0026gt; screens; Add the watchface to CMakeLists.txt src/CMakeLists.txt\n## Watch faces displayapp/icons/bg_clock.c displayapp/screens/WatchFaceAnalog.cpp displayapp/screens/WatchFaceDigital.cpp displayapp/screens/WatchFaceName.cpp Using git to work on the firmware Cloning the repository Instructions for cloning the repository are available on the Building and programming page on github.\nChanging the code to add the image Use the editor of your choice to modify the source files. Please read the coding conventions before you start.\nCompiling the firmware Information about how to compile the firmware is included on the Building and programming page on github.\nTesting the firmware Installing the new firmware A holistic guide on how to install different firmware using various hardware programmers is available here: Reprogramming the PineTime.\nIf you would like to install the firmware by OTA/DFU, you can follow these steps:\ncmake -DARM_NONE_EABI_TOOLCHAIN_PATH=/path/to/gcc-arm-none-eabi-9-2020-q2-update -DNRF5_SDK_PATH=/path/to/nRF5_SDK_15.3.0_59ac345 -DUSE_OPENOCD=1 -DBUILD_DFU=1 ../ make -j pinetime-mcuboot-app Be aware the paths for the cmake command must be absolute. The -DBUILD_DFU argument will generate a zip file which can be flashed using nRF Connect (not recommended) or Gadgetbridge on Android. You must have adafruit-nrfutil installed in your $PATH for this to work.\n","permalink":"/documentation/PineTime/Watchfaces/Custom_watchface/","tags":null,"title":"Custom watchface"},{"categories":null,"contents":"Bouffalo BL808 SoC information:\nBouffalo Lab BL808 SoC Datasheet Bouffalo Lab BL808 SoC Reference Manual SPI NOR Flash information:\nGigaDevice 16Mb XSPI-Flash Datasheet GigaDevice 128Mb XSPI-Flash Datasheet Winbond 128Mb QSPI-Flash Datasheet (W25Q128JWSQ) Power Regulator information:\nInnovation Analog Tech IA2014 Step_down Converter Datasheet MicroSD socket information:\nPush type microSD socket specification ","permalink":"/documentation/Ox64/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":" Datasheets for Components and Peripherals Sophgo SG2000 SoC information:\nSophgo SG2000 SoC Technical Reference Manual Wi-Fi and Bluetooth information:\nAIC Semi AIC8800DC Datasheet Power Regulator information:\nEmpower ETA3414 1.5A 3MHz Step_down Converter Datasheet Empower ETA3418 2.5A 3MHz Step_down Converter Datasheet Empower ETA5050 500mA Low Noise, High PSRR, Fast Transient Response LDO Datasheet MicroSD socket information:\nPush type microSD socket specification ","permalink":"/documentation/Oz64/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner A64/R18 SoC information:\nAllwinner A64 SoC Brief Introduction Allwinner R18 SoC Brief Introduction Allwinner A64/R18 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64/R18 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC Datasheet LPDDR3 information:\nAllwinner LPDDR3 Datasheet Foresee LPDDR3 Datasheet Samsung LPDDR3 Datasheet Hynix LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Related to the PINE A64-LTS 5MPixel CMOS Camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) S5K4EC 5MP CMOS Image Sensor SoC Module Datasheet S5K4EC 5MP CMOS Image Sensor SoC Chip Datasheet S5K4EC 5MP CMOS Image Sensor Driver Source Code in C language Early version Camera module information:\nBonsen Kexin V118-A64-GC2145-HM5065 CMOS Image Sensor Module HiMax 5MP CMOS Image Sensor SoC LCD Touch Screen Panel information:\n7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Lithium Battery information:\n8000mAH Lithium Battery Specification Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64-LTS Board and SOPINE Baseboard Wifi/BT module information:\nPINE A64 Wifi/BT Module Schematic Realtek RTL8723BS WiFi with BT SDIO Enclosure information:\nPlaybox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port Remote control button mapping:\nOfficial Remote Control for the PINE A64 Button Mapping ","permalink":"/documentation/Pine_A64-LTS/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner A64 SoC information:\nAllwinner A64 SoC Brief Introduction Allwinner A64 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC Datasheet Related to the PINE A64 5MPixel CMOS Camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) S5K4EC 5MP CMOS Image Sensor SoC Module Datasheet S5K4EC 5MP CMOS Image Sensor SoC Chip Datasheet S5K4EC 5MP CMOS Image Sensor Driver Source Code in C language Early version Camera module information:\nBonsen Kexin V118-A64-GC2145-HM5065 CMOS Image Sensor Module HiMax 5MP CMOS Image Sensor SoC LCD Touch Screen Panel information:\n7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Lithium Battery information:\n8000mAH Lithium Battery Specification Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64+ Board Realtek RTL8201 10/100M Ethernet Transceiver for PINE A64 Board Wifi/BT module information:\nPINE A64 Wifi/BT Module Schematic Realtek RTL8723BS WiFi with BT SDIO Enclosure information:\nPlaybox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port Remote control button mapping:\nOfficial Remote Control for the PINE A64 Button Mapping ","permalink":"/documentation/Pine_A64/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner H6 SoC information:\nAllwinner H6 SoC Brief Introduction Allwinner H6 SoC Data Sheet V1.1 (Official Released Version) Allwinner H6 SoC User Manual V1.0 (Official Release Version) X-Powers AXP805 PMU (Power Management Unit) information:\nX-Powers AXP805 Data Sheet V1.0 (Official Release Version) LPDDR3 (178 Balls) SDRAM:\nHynix LPDDR3 Datasheet V1.2 Samsung LPDDR3 Datasheet V1.00.00 Spectek LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG SanDisk eMMC Datasheet Hynix eMMC Datasheet Foresee eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE H64 Board Wifi/BT module information:\nAMPAK AP6356 2x2WiFi with BT 4.1 SDIO Realtek RTL8723BS 1x1 WiFi with BT 4.0 SDIO miniPCIe SATA module information:\nMolex miniPCie Socket information ASmedia ASM1061 2x2WiFi with BT 4.1 SDIO Enclosure information:\nABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Remote control button mapping\nOfficial Remote Control for the PINE H64 Button Mapping ","permalink":"/documentation/PINE_H64_Model_A/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner H6 SoC information:\nAllwinner H6 SoC Brief Introduction Allwinner H6 SoC Data Sheet V1.1 (Official Released Version) Allwinner H6 SoC User Manual V1.0 (Official Release Version) X-Powers AXP805 PMU (Power Management Unit) information:\nX-Powers AXP805 Data Sheet V1.0 (Official Release Version) LPDDR3 (178 Balls) SDRAM:\nHynix LPDDR3 Datasheet V1.2 Samsung LPDDR3 Datasheet V1.00.00 Spectek LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE H64 Board Wifi/BT module information:\nRealtek RTL8723BS WiFi with BT SDIO Remote control button mapping:\nOfficial Remote Control for the PINE H64 Button Mapping ","permalink":"/documentation/PINE_H64_Model_B/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner A64 SoC:\nAllwinner A64 SoC Brief Introduction Allwinner A64 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit):\nAXP803 PMIC Datasheet LPDDR3:\nAllwinner LPDDR3 Datasheet Foresee LPDDR3 Datasheet Samsung LPDDR3 Datasheet Hynix LPDDR3 Datasheet eMMC:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR flash:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet WiFi/BT module:\nRealtek RTL8723BS WiFi with BT SDIO LCD Panel:\n1920x1080 1080P 11.6″ IPS LCD Panel datasheet 1366x768 11.6″ TFT LCD Panel datasheet 1366x768 14″ TFT LCD Panel datasheet Touchpad:\nTouchpad Specification for 11.6″ model Touchpad Specification for 14″ model Camera sensor:\nVGA Camera module specification VGA Camera Sensor Data Sheet Lithium battery:\n10000 mAH Lithium Battery Specification for 11.6″ model 10000 mAH Lithium Battery Specification for 14″ model ","permalink":"/documentation/Pinebook/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Rockchip RK3399 SoC information:\nRockchip RK3399 SoC Brief Rockchip RK3399 Datasheet v2.1 Rockchip RK3399 Technical Reference Manual v1.4, part 1 Rockchip RK3399 Technical Reference Manual v1.3, part 1 and part 2 Rockchip RK808 Datasheet v1.6 LPDDR4 SDRAM (366-pin BGA):\nMicron 366 balls Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet (updated) Wireless and Bluetooth information:\nAMPAK AP6256 11AC Wi-Fi + Bluetooth5 Datasheet Audio codec:\nEverest ES8316 Audio Codec Datasheet Everest ES8316 User Guide with register-level description LCD panel:\n14\u0026quot; 1920x1080 IPS LCD Panel datasheet USB-related information:\nInternal USB 2.0 hub: GL850G USB Hub Datasheet USB Type-C Controller: ON Semiconductor FUSB302 Datasheet Touchpad information:\nPineBook Pro Touchpad Specification Keyboard information:\nSinowealth SH68F83 Datasheet US ANSI: XK-HS002 MB27716023 Full HD camera sensor:\nFull HD Camera module specification (in Chinese) GalaxyCore GC2145 Full HD Camera Sensor Datasheet Battery-related information:\nBattery charging IC: Texas Instruments BQ24171 Datasheet Battery monitoring IC: Cellwise CW2015 Datasheet 10000 mAH Lithium Battery Specification Later batches 9600 mAh / 36.48 Wh model WYC40110175P Lithium Battery Specification Power path device:\nN-MOS / MOSFET NVMe adapter:\nFH26-35S-0.3SHW flat flex connector (compatible, not OEM) ","permalink":"/documentation/Pinebook_Pro/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"BES 2300YP SoC information:\nBES 2300-YP Datasheet V1.0 Charging case:\nThinkPlus Semi SY8821 Datasheet in Chinese WCH Tech CH342DS USB to Dual Serial ports chip Datasheet COPO CP2021 2.5W Qi Wire Power Receiver Datasheet (Unpopulated) EarBuds:\nChiPower Tech CE3156 Single Cell Charger Datasheet LowPower Semi LP3992 LDO Regulator Datasheet HLW Semi HLW-YHX190 OTP micro Datasheet in Chinese (noted: for power-on and reset control) Tontek TTP-233D one key touch pad detect IC Datasheet ","permalink":"/documentation/PineBuds_Pro/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Bouffalo BL-602 SoC information:\nBouffalo Lab’s official bl_docs repository: should always contain the latest SoC documentation available, in PDF, HTML, and reStructuredText source forms. PINE64’s bl602-docs repository: contains an archive of all historical datasheets and reference manual PDFs but may lag behind Bouffalo’s official repository. If you notice that it is, please submit a pull request! USB/Serial adapter:\nCH340 serial converter ","permalink":"/documentation/PineCone/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner (Sochip) S3 SoC information:\nSochip S3 SoC Data Sheet V1.1 X-Powers AXP209 PMU (Power Management Unit) information:\nAXP209 PMIC datasheet CMOS camera module information:\nPineCube Camera Module Specification OV5640 5MP CMOS Image Sensor SoC datasheet LCD touch screen panel information:\nLithium battery information:\nWiFi/BT module information:\nRTL8189ES specification ","permalink":"/documentation/PineCube/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Rockchip RK3566 SoC information:\nRockchip RK3566 ver 1.0 datasheet, release permission from Rockchip Rockchip RK817 PMU (Power Management Unit) Information:\nRockchip RK817 version 1.01 datasheet LPDDR4 (200 Balls) SDRAM:\neMMC information:\nBiwin 128GB eMMC model: BWCTASC41P128G E-ink Panel information:\nE-Ink 10.3\u0026quot; 1872x1404 ED103TC2 Glass Panel Specification TPS65185x PMIC for E-Ink Enabled Electronic Paper Display Datasheet Touch Screen information:\nCypress CYTMA448 multi-Point Capacitive Touch Controller Datasheet Wacom Pen Digitizer Unit Model: SUDE-10S15MI-01X for 10.3\u0026quot; Display Module WiFi/BT module information:\nAzurewave CM256SM 11AC WiFi + Bluetooth5.0 Datasheet] G Sensor information:\nSilan SC7A20 3-Axis MEMS Accelerometer Audio Amplifier information:\nAwinic AW87318 Class-K Audio Amp Datasheet ","permalink":"/documentation/PineNote/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner A64 SoC information:\nAllwinner A64 SoC brief introduction Allwinner A64 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMIC (Power Management IC) information:\nAXP803 PMIC datasheet LPDDR3 (178 Balls) SDRAM:\nArtmem LPDDR3 datasheet eMMC information:\nKimtigo eMMC datasheet CMOS camera module information:\nPinePhone 5M Pixel Real CMOS Image Sensor Module OV5640 5MP CMOS Image Sensor SoC for Rear Module datasheet OV5640 Embedded Firmware User Guide – VCM AF Module PinePhone 2M Pixel Front CMOS Image Sensor Module GC2145 2MP CMOS Image Sensor SoC for Front Module datasheet LCD touch screen panel information:\n5.99\u0026quot; 1440x720 LCD IPS Panel specification ST7703 LCD Controller datasheet GOODiX GT917S Capacitive Touch Controller datasheet Lithium battery information:\nPinePhone Lithium Battery specification PinePhone Lithium Battery ZCV curve chart PinePhone Lithium Battery 3D onshape drawing WiFi/BT module information:\nRTL8723BS/RTL8723CS specification LTE module information:\nhttps://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf https://wiki.pine64.org/wiki/File:Quectel_EG25-G_Hardware_Design_V1.4.pdf https://wiki.pine64.org/wiki/File:Quectel_EC2x\u0026EG9x\u0026EG2x-G\u0026EM05_Series_AT_Commands_Manual_V2.0.pdf https://wiki.pine64.org/wiki/File:Quectel_EC2xEG25-GEG9xEM05_FILE_AT_Commands_Manual_V1.0.pdf https://wiki.pine64.org/wiki/File:Quectel_EC2x\u0026EG9x\u0026EG2x-G\u0026EM05_Series_GNSS_Application_Note_V1.3.pdf Sensors:\nST LIS3MDL 3-axis Magnetometer Datasheet InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS datasheet SensorTek STK3335 Ambient Light Sensor and Proximity Sensor Digital video to USB-C bridge:\nANX7688 product brief Case information:\nPinePhone case exploded diagram PinePhone back cover 3D file Other components:\nSee the Component List ","permalink":"/documentation/PinePhone/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner A64 SoC information:\nAllwinner A64 SoC brief introduction Allwinner A64 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC datasheet LPDDR3 (178 Balls) SDRAM:\nArtmem LPDDR3 datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 64GB SanDisk eMMC Datasheet CMOS camera module information:\nOV5640 5MP CMOS Image Sensor SoC for Rear Module datasheet GC2145 2MP CMOS Image Sensor SoC for Front Module datasheet LCD touch screen panel information:\nGOODiX GT9271 Capacitive Touch Controller datasheet PineTab GT9271 Capacitive Touch Controller configuration file Lithium battery information:\nN/A WiFi/BT module information:\nRTL8723BS/RTL8723CS specification ","permalink":"/documentation/PineTab/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Rockchip RK3566 SoC information:\nRockchip RK3566 ver 1.0 datasheet Rockchip RK3566 and RK3568 TRM (Technical Reference Manual) ","permalink":"/documentation/PineTab2/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Rockchip RK3566 SoC information:\nRockchip RK3566 ver 1.0 datasheet, already got release permission from Rockchip Rockchip RK3566 and RK3568 TRM (Technical Reference Manual) Rockchip PMU (Power Management Unit) Information:\nRockchip RK817 ver 1.01 datasheet for Quartz64 model A Rockchip RK809 ver 1.01 datasheet for Quartz64 model B and SOQuartz LPDDR4 (200 Balls) SDRAM:\nMicron LPDDR4 Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet E-ink Panel information:\nEink 10.3\u0026quot; 1872x1404 ES103TC1 Flex Panel Specification Eink 10.3\u0026quot; 1872x1404 ES103TC1 Glass Panel Specification TPS65185x PMIC for E-Ink Enabled Electronic Paper Display Datasheet LCD Touch Screen Panel information:\n7.0\u0026quot; 1024x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver Wi-Fi/BT module info:\nAzurewave CM256SM 11AC Wi-Fi + Bluetooth 5.0 datasheet for model A and B AICSemi AIC8800DC 11AX Wi-Fi + Bluetooth 5.2 datasheet for model \u0026ldquo;Zero\u0026rdquo; IR LED:\nIRM-3638 Datasheet Enclosure information:\nPlaybox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing 3D Printable Enclosure for Model A Open Frame for Model A Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port (Model A) 1.25mm Picoblade Type connector specification used in RTC Battery port (Model B) 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port ","permalink":"/documentation/Quartz64/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Rockchip RK3328 SoC information:\nRockchip RK3328 SoC Brief Rockchip RK3328 Datasheet V1.2 Rockchip RK3328 Technical Reference Manual part 1 Rockchip RK805 Datasheet V1.1 LPDDR3 (178 Balls) SDRAM:\nHynix LPDDR3 Datasheet V1.2 Samsung LPDDR3 Datasheet V1.00.00 Spectek LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32Gb/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Ethernet related info:\nRealtek RTL8211F 10/100/1000M Ethernet Transceiver Datasheet 10/100Mbps MegJack on Audio DAC POT board Datasheet Peripheral related info:\nJMicron JMS578 to SATA Datasheet Enclosure information:\nOutdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Remote control button mapping:\nOfficial Remote Control for the PINE A64 Button Mapping ","permalink":"/documentation/ROCK64/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Rockchip RK3399 SoC information:\nRockchip RK3399 SoC Brief Rockchip RK3399 Datasheet V2.1 Rockchip RK3399 Technical Reference Manual part 1 Rockchip RK808 Datasheet V0.8 LPDDR4 (200 Balls) SDRAM:\nMicron LPDDR4 Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Heatsink related info:\nROCKPro64 Passive Heatsink Dimension Drawing Heatsink Thermal Pad Specification Wireless related info:\nAMPAK AP6256 11AC WiFi + Bluetooth5.0 Datasheet (v. 1.3) (v. 1.7) Ethernet related info:\nRealtek RTL8211F 10/100/1000M Ethernet Transceiver Datasheet Peripheral related info:\nasmedia ASM1061 PCIe SATA 2.0 Datasheet Remote control button mapping:\nOfficial Remote Control for the PINE64 Button Mapping Audio Codec (ES8316) (under board):\nEverest ES8316 Audio Codec PWM controlled fan, SPDIF, and RTC Battery Backup headers:\nJST-PH connector ","permalink":"/documentation/ROCKPro64/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Rockchip RK1808 SoC information:\nRockchip RK1808 ver 1.2 datasheet Rockchip TK1808 Technical Reference Manual Part 1 Rockchip RK809 PMU (Power Management Unit) information:\nRockchip RK809 PMIC Datasheet DDR4 information:\nMicron DDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet SOEDGE Related:\nLCD Touch Screen Panel information: 7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Ethernet PHY information: Realtek RTL8211 10/100/1000M Ethernet Transceiver for SOEDGE model A baseboard Wifi/BT module information: SOEDGE/SOPINE/PINE A64 Wifi/BT Module Schematic Realtek RTL8723BS WiFi with BT SDIO Enclosure information: Playbox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Connector information: 2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port ","permalink":"/documentation/SOEDGE/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Rockchip RK3566 SoC information:\nRockchip RK3566 ver 1.0 datasheet, already got release permission from Rockchip Rockchip PMU (Power Management Unit) Information:\nRockchip RK809 ver 1.01 datasheet for SOQuartz PMU DDR4 information:\nMicron LPDDR4 Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver WiFi/BT module info:\nAzurewave CM256SM 11AC WiFi + Bluetooth5.0 Datasheet i2C to PWM Controller user in BLADE info:\nGP7101 i2c to PWM Controller Datasheet in Chinese GP7101 i2c to PWM Controller Datasheet translated to English by neggles https://wiki.pine64.org/wiki/File:GP7101 cn V1 qsxn en.pdf I^2^C address is 0x58 despite what datasheet says PoE DC/DC Controller user in BLADE info:\nSilan SD4954B PD and DC/DC Controller compatible with IEEE 802.3AF standard Datasheet ","permalink":"/documentation/SOQuartz/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Star64 JH7110 SoC information:\nStarFive JH7110 SoC Product Brief StarFive JH7110 SoC Datasheet StarFive JH7110 SoC Technical Reference Manual X-Power PMU information:\nX-Power AXP15060 Datasheet V0.1 LPDDR4 (200 Balls) SDRAM:\nMicron LPDDR4 Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nGigaDevice 128Mb XSPI-Flash Datasheet Ethernet related info:\nTBA WiFi/BT module info:\nFn-Link 6252B 11AC Dual Band 2T2R WiFi + Bluetooth5.2 Datasheet ","permalink":"/documentation/STAR64/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":"Allwinner A527 SoC information:\nAllwinner A527 SoC Product Brief Allwinner A527 SoC Datasheet Allwinner SoC User Reference Manual X-Power PMU information:\nAllwinner AXP717 PMU Product Brief Allwinner AXP717 PMU Datasheet LPDDR4 (200 Balls) SDRAM:\nRaysonLPDDR4 Datasheet eMMC information:\nKingston eMMC Datasheet Ethernet related info:\nRealtek RTL8211F 10/100/1000M Ethernet Transceiver Datasheet WiFi/BT module info:\nAICSemi 8800D40 module 11AC Dual Band 2T2R WiFi + Bluetooth5.2 Datasheet AICSemi AIC8800DC 11AX Wi-Fi + Bluetooth5.2 Datasheet ","permalink":"/documentation/Yuzuki_Avaota-A1/Further_information/Datasheets/","tags":null,"title":"Datasheets"},{"categories":null,"contents":" Gateway SX1303 datasheets and resources RAK5146 datasheets and resources Pine64 LoRa Gateway module adapter schematic End nodes SX1262 datasheets and resources Pinephone backplate https://wiki.pine64.org/wiki/File:Pinephone_LoRa_BackPanel_Schematic-v1.0-20210402.pdf https://wiki.pine64.org/wiki/File:CA-S01_LoRa_Chip_Antenna_in_Chinese.pdf I2C SPI Bridge code running on ATtiny84 USB LoRa adapter https://wiki.pine64.org/wiki/File:USB_LoRa_adapter-PINE64_RFM90_SCH_2021_04_26.pdf CH341 datasheet: https://wiki.pine64.org/wiki/File:CH341DS1.pdf Semtech SX1262 datasheet: File on Semtech website (file is too big for the wiki) PineDio Stack Schematic: https://wiki.pine64.org/wiki/File:PINEDIO_STACK_V1_0-2021_05_24C.pdf ","permalink":"/documentation/Pinedio/Datasheets_and_schematics/","tags":null,"title":"Datasheets and schematics"},{"categories":null,"contents":"PinePhone Pro mainboard schematic:\nPinePhone Pro mainboard Explorer Edition Released Schematic ver 1.0 20211127 PinePhone Pro mainboard Explorer Edition component top placement ver 1.0 20211127 PinePhone Pro mainboard Explorer Edition component bottom placement ver 1.0 20211127 PinePhone Pro USB-C small board schematic:\nTBD Certifications:\nPinePhone Pro FCC Certificate PinePhone Pro SAR Evaluation Report PinePhone Pro CE RED Certificate PinePhone Pro ROHS Test Report ","permalink":"/documentation/PinePhone_Pro/Further_information/Datasheets_schematics_and_certifications/","tags":null,"title":"Datasheets, schematics and certifications"},{"categories":null,"contents":" Schematics PineTime Schematic ver1.0a PineTime GPIO Port Assignment ver1.0 Note The part number for the SPI FLASH in the schematic diagram is not correct, the PineTime features a larger external FLASH device, see below. Chip Datasheets NORDIC nRF52832 information:\nnRF52832 Product Brief nRF52832 Product Specification v1.4 ARMv7-M information:\nARMv7-M Architecture Reference Manual Component Datasheets PMU (Power Management Unit) information:\nSGMicro SGM40561 Single Cell Charger Datasheet SGMicro SGM2036 3.3V Low Power Low Dropout RF Linear Regulator Datasheet SPI Flash information:\nXTX XT25F32B 32Mb(4MB) SPI NOR Flash (data sheets for this part are hard to find but it acts similar to other QuadSPI SPI NOR Flash such as Macronix 32Mb(4MB) SPI NOR Flash) XTX XT25F32B IDs for XT25F32B are: manufacturer (0x0b), device (0x15), memory type (0x40), density (0x16) LCD Panel:\n1.3\u0026quot; 240x240 IPS LCD Panel Specification for PineTime 11.6\u0026quot; Sitronix LCD Driver/Controller Datasheet Display controller:\nST7789V2 (used in PineTimes produced before May 2026) ST7789P3 (used in PineTimes produced from May 2026) Touchpad information:\nTouchpad Specification for PineTimel 11.6\u0026quot; Hynitron CST816S Capacitive Touch Controller Datasheet in Chinese Touch Controller Datasheet en Sensor:\nBOSCH BMA425 Triaxial Acceleration Sensor Datasheet on current PineTime device BOSCH BMA421 Triaxial Acceleration Sensor Product Brief on early PineTime device TianYiHeXin HRS3300 PPG Heart Rate Sensor Data Sheet Certificates PineTime FCC Certificate PineTime CE Certificate Manuals PineTime Quick Start Guide ","permalink":"/documentation/PineTime/Further_information/Datasheets_schematics_and_certifications/","tags":null,"title":"Datasheets, schematics and certifications"},{"categories":null,"contents":" This is an image creator and Debian installer that runs from an existing Linux OS and installs Debian Bullseye Installer can configure an encrypted rootfs and provides a choice of desktops, including the default Debian desktop based on Gnome 3 Strict adoption of upstream Debian packages (with exception of kernel and bootloaders) in order to provide a clean upgrade path as Bullseye matures Download at: https://github.com/daniel-thompson/pinebook-pro-debian-installer/ Pull requests welcome but for discussion and support please use the forum topic. Features Feature Status Notes Install to micro SD card Works Automatically expands to use all available space Install to eMMC Works Automatically adapts for 64GB and 128GB models Full disk encryption Works Run installer with CRYPT=yes. Requires kernel support and this support is missing in the original factory kernel so it it not possible to install a LUKS filesystem from the factory distro. You can make a temporary unencrypted install with this installer and then use the temporary OS to perform a full encypted install. Wifi Works Issues have been reported with WPA2 networks [https://forum.pine64.org/showthread.php?tid=8822] Firefox Works VLC Works Fn+ keys Work After updating mesa to 20.0.7-1 Current issues Issue Category Status Workaround Notes cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2 Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857054 If having FDE, it fails to load at boot as the firmware is not included in initramfs Include the dptx.bin firmware in the initramfs See https://forum.pine64.org/showthread.php?tid=8487\u0026pid=57202#pid57202 Bluetooth doesn’t work bluetooth hci1: Direct firmware load for brcm/BCM4345C5.hcd failed with error -2 Copy those firmware https://gitlab.manjaro.org/manjaro-arm/packages/community/ap6256-firmware to /lib/firmware/brcm/. After that, Bluetooth works fine. It seems some firmware is missing. See https://forum.pine64.org/showthread.php?tid=8731\u0026pid=57525#pid57525 Suspend doesn’t work properly, when lid is closed, the laptops gets hot and dramatically dry the battery Install is preconfigured to use suspend-to-idle instead. This offers some power savings compared to normal running but suspend should only be used for short periods. # echo deep \u0026gt; /sys/power/mem_sleep PBP simply doesn’t wake up after \u0026lsquo;deep\u0026rsquo; sleep. Often very slow to wake from suspend: 30-60 seconds. Forum thread https://forum.pine64.org/showthread.php?tid=8822 Sometimes pressing the power key helps wake it up. Set this key to not trigger sleep/shutdown in the Desktop Environment config. ","permalink":"/documentation/Pinebook_Pro/Software/Debian_installer/","tags":null,"title":"Debian Installer"},{"categories":null,"contents":"Camera issues can be debugged with the gstreamer pipeline. If the camera does not appear to work, it is possible to change the v4l2src to videotestsrc and the gstreamer pipeline will produce a synthetic test image without using the camera hardware.\nIf the camera is only sensor noise lines over a black or white image, the camera may be in a broken state. When in that state, the following kernel messages were observed:\n[ 1703.577304] alloc_contig_range: [46100, 464f5) PFNs busy [ 1703.578570] alloc_contig_range: [46200, 465f5) PFNs busy [ 1703.596924] alloc_contig_range: [46300, 466f5) PFNs busy [ 1703.598060] alloc_contig_range: [46400, 467f5) PFNs busy [ 1703.600480] alloc_contig_range: [46400, 468f5) PFNs busy [ 1703.601654] alloc_contig_range: [46600, 469f5) PFNs busy [ 1703.619165] alloc_contig_range: [46100, 464f5) PFNs busy [ 1703.619528] alloc_contig_range: [46200, 465f5) PFNs busy [ 1703.619857] alloc_contig_range: [46300, 466f5) PFNs busy [ 1703.641156] alloc_contig_range: [46100, 464f5) PFNs busy ","permalink":"/documentation/PineCube/Debugging/","tags":null,"title":"Debugging"},{"categories":null,"contents":" Serial Console System Serial is located on PI-5 bus (11x2 GPIO header).\nTXD: Pin 6 (Yellow cable) (Connect to RXD on Serial adapter) RXD: Pin 8 (Orange cable) (Connect to TXD on Serial adapter) GND: Pin 10 (Black cable) (Connect to GND on Serial adapter) The default baudrate is 1500000, note that not all serial adapters support this high baudrate.\n","permalink":"/documentation/SOEDGE/Debugging/","tags":null,"title":"Debugging"},{"categories":null,"contents":"The current default operating system on the PineTime is called InfiniTime, you can find more information about the firmware on its GitHub page. First devkits shipped with a proprietary custom firmware.\nYou can find a list of available firmware and other software here: Development\n","permalink":"/documentation/PineTime/Software/Default_OS/","tags":null,"title":"Default OS"},{"categories":null,"contents":"The Developer Edition was the first edition of the PinePhone Pro, shipped to developers in December 2021. The aim of the the Developer Edition was to give development community access to the hardware prior to end-users, boost development efforts and allow for porting of existing mobile Linux operating systems to the new hardware. It featured a factory test installation of AOSP as pre-installed operating system and was shipped with the packaging and manual of the succeeding Explorer Edition.\nGetting started This documentation page is strictly aimed at developers receiving their PinePhone Pro dev units. Please note that the following instructions do not apply to Explorer Edition or other future editions of the PinePhone Pro - everything below is only pertinent to the dev phones.\nConsider this a crash course rather than a comprehensive overview; you are also welcome to participate in documenting the process (and everything else related to the PinePhone Pro) on the documentation.\nGetting the hardware ready After unpacking the PinePhone Pro from its box, detach the back cover (looking at the back of the phone, there is a fingernail notch on the left leading edge) and remove the plastic tab between the battery and mainboard. You can also flip the headphone jack privacy switch at this point - this enables UART output via the headphone jack. Serial console works the same way as on the original PinePhone.\nFactory hardware test image The PinePhone Pro developer edition ships with a BSP AOSP factory image flashed to the eMMC. This image includes a number of factory applications meant to validate operation of the sensors, the modem, cameras, LCD \u0026amp; touch panel, etc. You’ll have to nuke the AOSP build to run a Linux installation on the PinePhone Pro. Booting from SD with the AOSP factory build present on eMMC is not possible due to the SoCs native boot order.\nChanging the language of factory AOSP This is optional and only if you want to test out the AOSP test image.\nSwipe up from the bottom of the screen. Tap on the Gear icon. Tap on the 2nd from last option that has an i inside of a circle icon. Tap on the first choice with the globe icon. Tap on the first choice with the language icon. Tap on the second choice to add another language. Tap on your language in the list. If there is a secondary choice required, tap on the preferred country. Tap the four horizontal bars icon to the right of the new second language and drag to the top of the list to set the new language as the default. Backing up the factory AOSP It may be a good idea to create an image of the eMMC in case you want to flash it back. Free up at least 117GB of disk space. Install adb.\nadb root \u0026amp;\u0026amp; adb pull /dev/block/mmcblk1 ~/pinephonepro-factory-AOSP.img\nNuking the factory AOSP installation To be able to boot from the microSD card easily it is recommend to wipe the bootloader from the pre-installed operating system on the eMMC due to the eMMC being higher in the boot priority than the microSD card.\nMethod 1: Via ADB In the factory test image, navigate to setting (gear icon) \u0026gt; at the very bottom of the settings list you will find a phone icon with rk3999mid written underneath it \u0026gt; tap the last (bottom) setting 7 times in quick succession. Following this, you may need to do the following: open the Settings application and enable USB debugging in Settings \u0026gt; System \u0026gt; Developer Options \u0026gt; USB debugging. Then connect the PinePhone Pro to your PC with the supplied USB-C cable.\nPlease note: It is recommended to charge the device to at least 50% before proceeding with wiping the eMMC.\nTip Note: You may have gotten a Chinese factory image; in the settings menu you can change the language to English by selecting the gray info icon (系统, one from bottom), then the first option (语言..), and again the first option (also 语言), then press +, English and drag it to the top of the list). Connect the phone to your computer and check adb devices in the terminal. The phone should be registered as attached. If the device doesn’t show you may want to try a different port or cable. Then enter adb shell followed by su to gain root access. At this point you can erase the eMMC installation:\ncat /dev/zero \u0026gt; /dev/block/mmcblk1\nThe phone will freeze and then the screen will go blank. Let it sit for no less than 10 minutes and then power it off by holding down the power button. You’ll know the phone is powered down when the notification LED turns off.\nMethod 2: Via serial cable Another method of erasing the image is to connect serial console, break into U-Boot when it says to press Ctrl-C, and then the \u0026ldquo;mmc erase\u0026rdquo; command can be used to zero blocks on the eMMC. For example, \u0026ldquo;mmc erase 0 16384\u0026rdquo; will zero the first 8MB, and is enough to stop it from being bootable. The baud rate for the serial console is 1500000.\nFlashing Linux You will want to do all your testing and development on a SD card; you DO NOT want to flash an OS to eMMC at this time. Builds frequently break at this early development stage and recovering from a corrupted eMMC installation is presently time consuming and tedious. A fast 16-64GB micro SD card for $15 will work just fine.\nThere are a handful of OS builds available for the PinePhone Pro already. These can be found under the Software Releases section.\nIf you are a developer porting your own distribution to the PinePhone Pro, please make sure to make an entry for it in the Software Releases section on the documentation. If you want / need help with entering your build onto the documentation please ping one of the mods or admins in the chats (see Forums and Chats drop-down menu).\nResources Aside from the PINE64 documentation there are also other useful resources scattered across different Wikis, repositories and blogs. In time these will be gathered into one place - the DevZone - which will help to streamline the development process.\nAt the time of publishing, these are some of the notable resource, listed in no particular order:\npostmarketOS Wiki Megi’s (b)log DanctNIX repository Manjaro repository Development ","permalink":"/documentation/PinePhone_Pro/Revisions/Developer_Edition/","tags":null,"title":"Developer Edition"},{"categories":null,"contents":" PineCone BL602 GitHub Page (PINE64 fork) has compilers, linkers, and all the code to build on Windows, Linux (x86_64), and MacOS. Bouffalo Lab GitHub Page BL602 Developer organize documentation GitHub Page BL602 Developer organize tool GitHub Page Programming tool for Bouffalo Labs BL602/BL604 chips BL602 reverse engineering working group Linux kernel module BL602 Documentation BL602 serial flasher Awesome Bouffalo ","permalink":"/documentation/PineCone/Development/","tags":null,"title":"Development"},{"categories":null,"contents":"This page documents development processes and provides links to resources to help prospective contributors get started. For an overview of the current software state see software state.\nUpstreaming status Function Status Component Notes Bootloader (u-boot) Working. Not upstreamed. https://github.com/dreemurrs-embedded/Pine64-Arch/tree/master/PKGBUILDS/pine64/uboot-pinephonepro uses https://git.sr.ht/~martijnbraam/u-boot. Modem Working. Not upstreamed. Support in https://gitlab.com/mobian1/devices/eg25-manager and Megi’s kernel. Levinboot-based kernel development image This guide will help you get a comfortable environment for testing your kernel builds on Pinephone Pro. It assumes you either already know how to build or cross-build a Linux kernel for arm64, or if you have a way to get a pre-built kernel from somewhere. For a quick test that your setup works, you can use megi’s pre-built kernels.\nQuick and easy way to get started with kernel development and testing is to use CrystalGamma’s Levinboot patched with support for Pinephone Pro and 3-option boot selection using volume keys. You will be able to switch between kernels quickly without swapping uSD cards, which is necessary for painless kernel development experience.\nCreate a following partitioning scheme on a uSD card using sfdisk: label: gpt first-lba: 64 table-length: 8 start=64, size=8128, type=D7B1F817-AA75-2F4F-830D-84818A145370, name=\u0026#34;sd-lboot\u0026#34; size=60M, type=E5AB07A0-8E5E-46F6-9CE8-41A518929B7C, name=\u0026#34;sd-lpayload1\u0026#34; size=60M, type=5f04b556-c920-4b6d-bd77-804efe6fae01, name=\u0026#34;sd-lpayload2\u0026#34; size=60M, type=c195cc59-d766-4b78-813f-a0e1519099d8, name=\u0026#34;sd-lpayload3\u0026#34; size=14G name=\u0026#34;sd-rootfs1\u0026#34; name=\u0026#34;sd-rootfs2\u0026#34; This can either be done interactively, or by saving the above to a file, like format.txt, and running sfdisk /dev/\u0026lt;sdcard\u0026gt; \u0026lt; format.txt\nWrite Levinboot to sd-lboot partition using dd. You can get a pre-built and tested version here There are two options levinboot-sd.img and levinboot-emmc.img you can use either one of them for your sd-lboot partition. They differ in where they load the payloads from (either from SD or eMMC) and not in where they can be flashed to. For uSD card only workflow, you’ll want levinboot-sd.img.\nPrepare payloads for Levinboot and copy them to appropriate partitions. Partition sd-lpayload1 is used by default, sd-lpayload2 when you hold a volume down key during powerup, and sd-lpayload3 when you hold the volume up key.\nPreparing a payload involves getting a TF-A bl31.elf build, kernel Image build, DTB file for Pinephone Pro, and optionally an initramfs archive, modifying DTB to include kernel boot arguments, and compressing these using lz4 in specific order, as shown below.\nBOOTOPTS=( console=tty1 earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8 root=PARTLABEL=emmc-rootfs1 rootfstype=f2fs rootflags=fastboot rootwait rw loglevel=7 ) BOOTOPTS=\u0026#34;${BOOTOPTS[@]}\u0026#34; ALGO=\u0026#34;lz4 -zc\u0026#34; cp -f rk3399-pinephone-pro.dtb board-cfg.dtb fdtput -pt s board-cfg.dtb /chosen bootargs \u0026#34;$BOOTOPTS\u0026#34; ( $ALGO bl31.elf $ALGO board-cfg.dtb $ALGO Image . $ALGO initramfs.img ) \u0026gt; payload.img dd if=payload.img of=/dev/disk/by-partlabel/sd-lpayload1 bs=4M oflag=direct Prepare root filesystem. You can use any Linux distribution for aarch64 for development. For example if you want to use Arch Linux ARM, you would need to format the sd-rootfs1 partition with f2fs filesystem and extract the Arch Linux ARM rootfs tarball there. That will give you a bootable SD card image for Pinephone Pro.\nRepeat steps 3 and 4 if you want either more kernel payloads, or more Linux distributions on the same uSD card. I recommend having at least some module-less working kernel in sd-payload3 and perhaps a small userspace in sd-rootfs1 with a pre-configured WiFi connection, that will allow you to always quickly recover if your development kernel fails to boot, just by pressing volume up key during boot and updating the the kernel in one of the primary payload partitions over WiFi.\nResources See megi’s PinePhone Development Log ","permalink":"/documentation/PinePhone_Pro/Development/","tags":null,"title":"Development"},{"categories":null,"contents":" Ox64 boots Linux successfully Brennan Ashton is porting Apache NuttX RTOS and OpenAMP (Asymmetric Multiprocessing) to BL808 Phone Concept for BL808 ","permalink":"/documentation/Ox64/Development_Efforts/","tags":null,"title":"Development Efforts"},{"categories":null,"contents":" Author Project Homepage Description Supported Ben Brown (ralimtek) Ralim’s IronOS Official Pinecil firmware BL706, GD32VF103TB, Stm32f103 Marek Kraus gamiee/gamelaster Blisp V2 Flasher CLI Updater for Pinecil V2, BL70x MCU Windows, Linux, Mac Marek Kraus gamiee/gamelaster Pinecil V1 Flasher Pinecil V1 GUI Updater Windows, Mac Arkaitz Goni Hedger spagett1 PineFlash Pinecil V1 GUI Updater Linux, Mac Builder555 BLE PineSAM Bluetooth LE Settings \u0026amp; temperature control from any browser Cross-platform, runs local script to control Pinecil from PC or phone. Joric (iamjoric) BLE browser API Bluetooth LE Graph Windows, Linux, Android browsers that support BLE GATT Tom W (TomW1605) \u0026amp; ithinkido BLE V2 + ESP32 Bluetooth LE V2 data =\u0026gt; ESP32 BLE+Wifi =\u0026gt; Home Assist display Cross Platform Bouffalo Lab B-Lab Dev Cube MCU vendor GUI for Dev BL70x, BL60x, others (does not work for Pinecil V2) Alvin Wong Rust code on GD32VF103 Rust code demos for Pinecil V1 GD32VF103TB tr4nt0r pynecil Python library to communicate with Pinecil V2 via Bluetooth Cross-platform, Python \u0026gt;= 3.11 tr4nt0r Home Assistant Monitor and control Pinecil V2 from Home Assistant IronOS integration introduced in HA 2024.8 Note Bluetooth (BLE) apps require upgrading Pinecil V2 to IronOS 2.21 or newer firmware here. ","permalink":"/documentation/Pinecil/Development_projects/","tags":null,"title":"Development projects"},{"categories":null,"contents":"If your U-Boot has been compiled with CONFIG_OF_LIBFDT_OVERLAY (which Manjaro’s is), adding device tree overlays the mainline way is very simple and easy.\nWriting Your Device Tree Overlay First off, you’ll have to write a device tree overlay. In this example, we’ll enable the ROCKPro64’s I2C bus that’s exposed to the pin headers, and declare that a PCF8574 GPIO extender is hanging off it.\n/dts-v1/; /plugin/; \u0026amp;i2c8 { status = \u0026#34;okay\u0026#34;; #address-cells = \u0026lt;1\u0026gt;; #size-cells = \u0026lt;0\u0026gt;; pcf8574: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; ; We’ll go through this file line by line.\n/dts-v1/; specifies that this file is a DTS file. /plugin/; specifies that this is not just a regular device tree source file, but an overlay. \u0026amp;i2c8 { references the i2c8 node in the device tree we’re applying on top of, meaning we’re going to modify this specific part of it. status = \u0026quot;okay\u0026quot;; enables the i2c8 node. It’s set to \u0026ldquo;disabled\u0026rdquo; in the tree we’re applying on top of, specifying the property like this overrides it. #address-cells = \u0026lt;1\u0026gt;; is already set in the base tree, but since the compiler doesn’t know what the base tree is, it’ll yell at us if we don’t set this. #size-cells = \u0026lt;0\u0026gt;; same as above. pcf8574: pcf8574@20 { adds a child node labelled pcf8574 to the i2c8 node, which is a PCF8574 controller at address 0x20. compatible = \u0026quot;nxp,pcf8574\u0026quot;; the compatible string of the node, letting the kernel know what driver it needs to load for it. reg = \u0026lt;0x20\u0026gt;; the I2C address the device is listening on, in hexadecimal. gpio-controller; declares that this node is a GPIO controller. #gpio-cells = \u0026lt;2\u0026gt;; required for GPIO controllers. Assuming we’ve saved this as pcf8574.dts, we can compile it as follows:\ndtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts This creates a compiled pcf8574.dtbo from the pcf8574.dts input file, and with -@ we preserve the labels of nodes, which in turn allows something to more easily overlay onto this overlay.\nLoading It Next, copy your compiled device tree overlay file—in the previous example pcf8574.dtbo*—somewhere into your /boot, for example */boot/dtbs/overlays/.\nThen we modify /boot/extlinux/extlinux.conf and add the line emphasised in bold to it:\nLABEL Manjaro ARM KERNEL /Image FDT /dtbs/rockchip/rk3399-rockpro64.dtb *FDTOVERLAYS /dtbs/overlays/pcf8574.dtbo* APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 root=LABEL=ROOT_MNJRO rw rootwait quiet splash plymouth.ignore-serial-consoles To specify multiple overlays, simply separate them with space on the same line.\nNow after a reboot, the device tree overlay file should be applied, and your kernel will see the new device. You can confirm this by dumping the device tree the kernel uses, and grepping it for whatever you added:\ndtc -I fs /sys/firmware/devicetree/base | grep -A4 \u0026#39;pcf8574\u0026#39; Further Reading Linux Kernel Documentation - Devicetree Overlay Notes Embedded Linux Wiki - Device Tree Usage CounterPillow’s overlay-examples repository ","permalink":"/documentation/ROCKPro64/Software/Device_Tree_Overlays_on_Mainline/","tags":null,"title":"Device Tree Overlays on Mainline"},{"categories":null,"contents":"The device can be easily disassembled by removing the four rubber feet and by unscrewing the four screws underneath them. The board is held in place by additional two black screws. Note: The board is connected to the main body with a cable.\n","permalink":"/documentation/RockBox/Development/Disassembly/","tags":null,"title":"Disassembly"},{"categories":null,"contents":"Disassembling the charging case:\nFirst open the lid and then try to press the case from the front edge with a plectrum or a thin card. There are two clips on each side. Soon the case will snap open. Carefully unscrew and remove the PCB from the case. Assembling the charging case:\nScrew the PCB back into the place. There is plenty of space, glue the coil to the bottom of the case. Close the charging case. External resources A video regarding the assembly and disassembly of the PineBuds Pro can be watched from Linux Lounge here. ","permalink":"/documentation/PineBuds_Pro/Further_information/Disassembly_and_assembly/","tags":null,"title":"Disassembly and assembly"},{"categories":null,"contents":" Battery replacement See writeup on the wiki: https://wiki.pine64.org/wiki/PineNote/Battery_Replacement\nUSB-C Sideboard replacement The USB-C Sideboard is one of the few replacement parts available from the Pine64 Store: https://pine64.com/product/pinepmote-usb-c-side-board/\nStarting at the top of the device, and continuing around the top corners and down the sides, pry the back case away from the face of the device. A pry tool may be useful, though it has been reported possible to do with bare fingers. Like any plastic-clipped case, it requires gentleness while at other times significant force to remove the back panel. See Battery Replacement guide above for another description. Flip the device over and locate the USB-C Sideboard on the very bottom. It looks just like the replacement! It is connected by a small ribbon, gently lift the retaining flap on the connector to release the ribbon cable, and slide the cable out. Two shallow phillips screws secure the sideboard, unscrew them, replace the sideboard with new one, screw the replacement in place. Note a very pointy screwdriver will not work, the screw does not have much depth to it and requires a relatively blunt screwdriver head. Gently replace the ribbon and press retaining flap down to secure the ribbon. Test the new USB-C by connecting a cable to power or data and make sure the tablet responds before replacing the back case. Without putting any pressure on the new USB-C connection, line it up with the bottom of the device and firmly press in bottom edge and corners of the device back into the casing with audible click. Firm pinching with your whole hand up the edge of the case should easily click the entire case back into place. Test that the power/sleep button functions and the case is flush everywhere. ","permalink":"/documentation/PineNote/Further_information/Disassembly_and_parts_replacement/","tags":null,"title":"Disassembly and Parts Replacement"},{"categories":null,"contents":" Pinebook Screw stand-offs correct placement and location\nHinge_area_of_the_Pinebook_Pro_lid_with the cover removed\nClose-up of a Pinebook Pro lid hinge\nThere are a few mandatory precautions to be taken:\nDo not open the laptop by lifting the lid while the Pinebook Pro bottom cover is removed - this can cause structural damage to the hinges and/or other plastic components of the chassis such as the IO port cut-outs. When removing the back cover plate, do not, under any circumstances, slide your fingertips between the metal shell and the plastic frame! The back cover plate edges are sharp, and when combined with the pressure and movement generated from, specifically, attempting to slide the tips of your fingers along the bottom edge of the plate along the lid-hinge, they will slice open the tips of your fingers like a knife. When removing the back cover plate, use care to avoid damaging the speakers. They can be stuck to the back cover with double-sided tape, and the thin wires are very delicate. Newer Pinebook Pro laptops (as of the May 2021 batch, and perhaps earlier) seem to lack the double-sided tape to the rear cover, instead opting for tape or glue that makes them stick to the front cover. Nevertheless, be gentle when removing the back cover. Pinebook Pro external screws (this particular unit has suffered damage on screw (4)L)\nWhen disassembling the laptop make sure that it is powered off and folded closed. To remove the bottom cover of the Pinebook Pro, first remove the ten (10) Phillips head screws that hold the bottom section of the laptop in place. There are four (4) short screws along the front edge, and six (6) long screws along the 3 remaining sides. Remove the cover from the back where the hinges are situated by lifting it up and away from the rest of the chassis. The aluminum case is held on only by screws. There are no plastic snaps, and the shell should pull away without any effort. If you experience any resistance at all stop and ensure all ten (10) screws are accounted for.\nDuring reassembly, make sure that the back-screw standoffs are in place and seated correctly. Before replacing the aluminum back-plate, ensure that the speakers are properly seated by pressing gently on the hard plastic edge of the speaker module. Slide the bottom section into place so it meets the front lip of the keyboard section. Secure the front section (where the touchpad is located) in place using the short screws in the front left and right corners. Then proceed to pop in the bottom panel into place. Secure the bottom section (where hinges are located) by screwing in the left and right corners. Then screw in the remaining screws and run your finger though the rim on the chassis to make sure its fitted correctly. Note that the front uses the remaining 4 short screws.\nThe screws are small and should only be finger tight. Too much force will strip the threads. If after installing screws the back cover plate has not seated properly on one side (which may be caused by the aforementioned misseating of the speakers), open the display and hold the base on either side of the keyboard and gently flex the base with both hands in opposing directions. Once the side pops further in, then recheck the screws on that side. If it does not pop back in, re-open the machine and check for misseated components.\nA basic 3D model to print replacement standoffs for the back cover screws is available on Thingiverse, until the official drawings or 3D models are made available.\nMany units come with the hinges too stiff from the factory. You can tell if it affects your device by carefully observing if operating the lid on a fully assembled notebook flexes the case. This repeated flexing can lead to plastic and metal fatigue and eventually broken parts. Consider carefully using a flat screwdriver or similar object to unbend the hinges a bit by wedging it into the slot (requires the display part to be fully detached from the main body).\nDisplay disassembly It is not recommended to adjust the position of the lid when the bottom cover is removed, because the bottom cover provides structural strength, so the lid should be open fully as the first step, before starting any disassembly of the laptop. After opening the lid, remove the bottom cover by following the instruction found in the section above. Alternatively, you can keep the lid closed and remove the screws that hold the hinges to the main laptop body, as described in Pinebook Service Step by Step Guides.\nParts of the hinge mechanism, as well as the screws that hold the hinges to the lid, are hidden behind an elongated plastic U-shaped cover that snaps in place using latches. Use a dedicated plastic prying tool or a guitar pick to gently pry the cover and remove it, starting from the outer edge. Once you pry the cover to a certain extent, it should be possible to remove it fully using only your hands. The U-shaped cover is rather sturdy, but still be careful not to break or bend it.\nThere are two small screws hidden underneath the two small rubber nubs on the upper part of the screen bezel, so first gently remove the nubs and then remove the screws. The screen bezel is held in place with a combination of latches and some adhesive tape, which is there to prevent dust ingress. The adhesive isn’t very strong, and the bezel is capable of flexing back into shape after being twisted to a certain extent. There is more adhesive on the bottom part of the screen bezel, so be more careful while prying that section apart. Use the same prying tool that you used for the U-shaped cover, and work it around the outer edges of the screen bezel.\n","permalink":"/documentation/Pinebook_Pro/Guides/Disassembly_and_Reassembly/","tags":null,"title":"Disassembly and Reassembly"},{"categories":null,"contents":"PineTab2 disassembly guide:\nFile:PineTab2 display panel disassembly guide.pdf Note: this is a very delicate operation, especially around the corners of the screen. Several even experienced users damaged their screen when disassembling the device. ","permalink":"/documentation/PineTab2/Further_information/Disassembly_guide/","tags":null,"title":"Disassembly guide"},{"categories":null,"contents":"The Pinebook Pro USB-C Docking Deck can be used to extend the Pinebook Pro with additional functionality. It is custom designed for both, physical dimensions and ports, to compliment the Pinebook Pro laptop. It has been tested on several disparate platforms and seems to be fully compatible with Android, Windows, ChromeOS, and GNU/Linux. It may be compatible with Apple systems, but this has yet to be documented.\nPorts List of ports available on docking station:\nUSB-C Charging Port x1 USB 3.0 Ports x3 USB-C 2.0 Ports x2 4K @ 30fps HDMI x1 1080P VGA x1 Gigabit Ethernet networking port x 1 Card readers: micro SD x 1 \u0026amp; SD x 1, supports: SD, SDHC and SDXC Audio Jack: 3.5mm Earphone Jack with mic x1 Hardware Tests Acer Aspire e15\nNote that machine lacks USB-C video. Tested with both Windows 10 and Gentoo GNU/Linux. Every device functions properly with the exception of the microphone jack. In Linux, the jack will only function with its volume set at or above 98 in alsamixer. This is uncomfortably loud. 8/10 for compatibility.\niPad Air (4th generation)\nUSB dock functions for fast charging and input from USB keyboard and mouse peripherals. Audio jack does not function under any tested circumstances. Bluetooth audio disabled when dock in use. Other devices not tested. 8/10\nSamsung Chromebook Plus V2\nEverything functions perfectly, with the exception of Ethernet, which was not tested. 9/10.\nGoogle Pixel 4a\nNote that the machine lacks USB-C video. Using android version 11. Video and Ethernet were not tested. Everything else functioned properly. 8/10.\nPineBook Pro\nUsing Manjaro ARM minimal with dwm. Video out, USB, and SD card readers all work. Did not test Ethernet or audio jack. 8/10.\nUsing devuan ARM \u0026amp; debian ARM, xfce4. Did not test Video out. USB and SD card readers work. Ethernet is working at full speed. The Docking Deck is able to negotiate USB-C 9V 1.6A and convert to 5V 2.5A for the PBP. No charging issues; the PBP makes some noise, but that isn’t the docking deck’s fault. Audio out is working. Note that adding another audio device obviates the need for the audio device default to be restored on reboot, which did not work on xfce4. 9/10.\nPinePhone Pro Explorer Edition\nWith Mobian: jack, Ethernet, SD-card readers, USB-A and -C, VGA fully works, HDMI lacks sound output. Video-out works fully on Mobian. 9/10\nKnown Bugs Audio Volume on Linux Currently, the audio output from this dock\nOn some Linux systems, and possibly all of them, the volume range for headphones from audible to loud is from 64562-64575 to 65000. That’s absolute, not percentages. This is an extremely tiny range \u0026ndash; completely impossible to navigate with percentages, and dangerous as well. For the time being, this audio output should be treated as unsafe for human health, as well as the health of your speakers. To ensure safe audio levels, users can switch to the digital output to lower the volume to a safe level.\nPinebook Pro does not charge when connected to USB-C dock It has been observed in the past that the Pinebook Pro is somewhat temperamental when used with the USB-C dock. Sometimes it will not charge when connected to its dock, even if the dock is powered from the official Pinepower power supply (i.e., even when it is provided with sufficient power). The more astute may have surmised that the Pinebook Pro was powering the dock, rather than being powered itself. The solution, luckily, is quite simple. The following command should always work:\necho \u0026quot;sink\u0026quot; | sudo tee /sys/class/typec/port0/power_role Please note:\nThis command cannot be run with sudo, you must be the root user. If this command still fails with the message \u0026ldquo;bash: /sys/class/typec/port0/power_role: No such file or directory\u0026rdquo; Please ensure that the file actually exists. The most likely cultprits are that either /sys/class/typec does not exist or /sys/class/typec/port0 has a different name on your machine. Unable to output to external display Unplug the dock cable turn 180 degrees reinsert in new orientation. (Sometimes works for charging the laptop too.)\nComponents List of chips used in the docking station:\nPD Negotiation chip - PDFL7102 HDMI/VGA chip - IT6564 GbE Ethernet chip - RTL8153B USB 3.0 Hub chip - VL817 SD card reader chip - GL823K Audio CODEC chip - HZD100 External Links The Pinebook Pro Docking Deck at the Pine64 store The \u0026ldquo;Pinebook Pro Hardware and Accessories\u0026rdquo; section of the Pine64 forum ","permalink":"/documentation/Pinebook_Pro/Dock/","tags":null,"title":"Dock"},{"categories":null,"contents":"The Early Adopter Edition was the first hardware revision of the PineTab which shipped to customers. Shipping began on September 6, 2020.\nSoftware The device shipped with a beta build of Ubuntu Touch by UBports. This build is available to download at https://ci.ubports.com/job/rootfs/job/rootfs-pinetab-systemimage/18/. It has the following problems which are software, not hardware, issues:\nThe mouse fails to move around the entire screen. It is stuck in an 800px horizontal box. It is not possible to enable Bluetooth Cameras do not function Portrait mode does not function The external keyboard is not always detected There is a faint crackling noise on startup Pasting an item on File Manager after Copy/Cut reboots the operating system GUI apps with Libertine are not working, because of missing bits between wayland and Libertine Cannot add accounts (Google, Evernote and other) in System Settings The first-time setup wizard advises the user to unplug the keyboard dock (avoiding the mouse issues) and update the system. Unfortunately, as of this update to this page (September 8, 2020) this will not fix any of the issues above.\n16GB/64GB storage software error The image installed on the device was sized for a 16GB (~14GiB) eMMC, but the PineTab shipped with a 64GB (~58GiB) eMMC chip installed. This means that the \u0026ldquo;Storage\u0026rdquo; page in the \u0026ldquo;About\u0026rdquo; section of Ubuntu Touch System Settings will show total storage as 14.0GiB until the partition table on the device is edited.\nThis is fixed by an update to Ubuntu Touch released to the Stable channel on September 15, 2020. The image’s tag is \u0026ldquo;2020-09-12\u0026rdquo;, visible in Settings -\u0026gt; About -\u0026gt; OS.\nInstalling using apt Installing software on the read-only root filesystem is unsupported on Ubuntu Touch. You should be able to find updates in System Settings -\u0026gt; Updates and new applications in the OpenStore. If you would like to install and use terminal software from the Ubuntu repositories, see Run desktop applications in the UBports Documentation to set up a Libertine container. Unfortunately, graphical software does not yet work through Libertine. This issue is tracked as ubports/libertine#68\nEnabling ssh Naturally, you should be wary of enabling ssh for security reasons but everything is there. Almost.\nEdit /etc/ssh/sshd_config and change the following:\nPasswordAuthentication yes ChallengeResponseAuthentication yes Then run:\n/etc/init.d/sshd start Use user phablet along with your password or PIN to log in.\nWifi Wifi disappears If wifi stopped working, first try usual means:\nswitching wifi off and on again reboot PineTab If it still doesn’t work, open terminal and type this:\nnmcli radio If output is two lines with red word disabled under word WIFI - rejoice, since this issue is known (although it’s not yet investigated well enough to figure out when it happens, so clues to developers are likely welcome). To fix it, just type this in the terminal:\nnmcli radio wifi on Wi-Fi missing if started with keyboard attached Operating system: Ubuntu Touch (OS version: RC#6 (2020-W37))\nSymptom: if you started with keyboard attached wifi will not come up\nReason: the service urfkill is not running\nFix:\nsudo service urfkill restart Wifi radio reception is very weak This needs a tweak! How to open the PineTab?\nTested with UT, Mobian and Archlinux: sitting right beside the router gives a connection (ca. 60% level). No reception in a distance of 7 meters, no wall, just an opened door, some edges, router not directly visible. Pinephone right beside the Pinetab has an absolutly stable wifi connection.\nIn the event that WiFi fails to connect using Ubuntu Touch, the USB port can be used with an appropriate dongle to connect for internet using ethernet cable.\nKeyboard The keyboard attaches magnetically and will correctly link only one way: so screen faces the keyboard.\nThe keyboard backlight automatically comes on when keyboard is attached, but the light can be turned off/on by holding down the Pine (super) key and tapping the right CTRL key which also shows a bulb icon. The keyboard draws its power from the PineTab battery.\nHolding down the Pine key for two seconds and holding it down reveals a popup window of keyboard shortcuts.\nTo access the icon features on the function keys, hold down the Fn key and tap the appropriate key. Ex: F5 and F6 activate volume control (which also has a rocker button on the tablet edge).\n","permalink":"/documentation/PineTab/Revisions/Early_adopter_edition/","tags":null,"title":"Early Adopter Edition"},{"categories":null,"contents":"See Quartz64 Development\nInformation and resources of the ongoing development effort for the Quartz64 can be found on the Development page, where the current status of various board functions can be found, and whether they have landed in upstream.\nQuartz64 BSP Gitlab Page ","permalink":"/documentation/Quartz64/Development/Efforts/","tags":null,"title":"Efforts"},{"categories":null,"contents":"Note: Please expand this section with more cases known to work.\nModel \u0026ldquo;A\u0026rdquo; All enclosures that fit the ROCKPro64 should fit the Quartz64 Model \u0026ldquo;A\u0026rdquo;, as the I/O has been laid out the same on purpose.\nModel A Acrylic Open Enclosure - but see the troubleshooting section below. RockPro64 Premium Aluminium Case ROCKPro64 (Not an enclosure but allows to mount the board in an ATX/ITX case) Model \u0026ldquo;B\u0026rdquo; Model B Acrylic Open Enclosure the ROCK64 aluminium enclosure does not work, as the DC input jack is placed differently ","permalink":"/documentation/Quartz64/Enclosures/","tags":null,"title":"Enclosures"},{"categories":null,"contents":" DSI - Display Serial Interface, 4 lanes MiPi, up to 1080P TP - Touch Panel Port, SPI with interrupt RTC - Real Time Clock Battery Connector VBAT - Lithium Battery Connector with temperature sensor input Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header PCIe 2x open ended slot Schematics and certifications Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm Input Power: DC 12V @ 3A 5.5OD/2.1ID Barrel DC Jack connector SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard schematics and PCB board resources:\nSOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic 20210223 PDF file SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard 20210223 PCB Component Placement Top PDF file SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard 20210223 PCB Component Placement Bottom PDF file SOEDGE module together with the baseboard certification:\nDisclaimer: Please note that SOEDGE module is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, SOEDGE module still submits the mpdel A baseboard for FCC, CE, and ROHS certifications and obtain the certificates to prove that can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for SOEDGE model A baseboard ","permalink":"/documentation/SOEDGE_Baseboard/Features/Expansion_ports/","tags":null,"title":"Expansion ports"},{"categories":null,"contents":"Once you’ve flashed the OS to your microSD card or eMMC storage, you may also need to expand the partition to fill all the available space.\nNote Many operating systems already include a script, which is resizing the partition on first boot, where this step is not required. Resize SD card\u0026rsquo;s partition using computer For microSD cards, insert the microSD card and resize the partitions through the computer. For eMMC, insert the phone cable and use Jumpdrive to access the eMMC directly, and resize the partition after flashing the image. To do the flashing you have two options:\nUsing Growpart Install growpart and run:\ngrowpart /dev/**mmcblkX** **Y** resize2fs /dev/**mmcblkXpY** where X is the storage device and Y is the partition number (viewable from lsblk).\nIf you get any errors about missing or unknown commands, use apt-cache search to find and install the needed software. Also don’t forget to use sudo.\nUsing Parted Parted’s interactive mode and resize work well together. Do this before you put your microSD card into the PinePhone for the first time for best results.\nsudo parted /dev/*\u0026lt;your_sd_card_device\u0026gt;* (parted) resizepart 2 100% (parted) quit sudo resize2fs /dev/*\u0026lt;the_second_sd_card_PARTITION\u0026gt;* Resize from within the PinePhone eMMC: you would need to resize the partition on eMMC (flashed with the operating system) by booting another image from the microSD card: that way, the eMMC will be unmounted. It is not recommended to resize eMMC while booted from eMMC! Resizing a currently mounted partition can have weird results. If you booted from the microSD card, you can follow the above guidelines on how to resize from a computer.\nMicroSD card: It is generally not possible to boot from eMMC to partition the unmounted microSD card, because of the boot order - you would have to write the image to the empty microSD card first, then resize partition, all without rebooting. It is also not recommended to resize the microSD card while booted from microSD card! Resizing a currently mounted partition can have weird results.\n","permalink":"/documentation/PinePhone/Installation/Extend_partition/","tags":null,"title":"Extend partition"},{"categories":null,"contents":" The partition table Partitions on a storage (disk of flash memory) have different sizes depending on the type of data they contain. Size and location for those partitions could vary along the time, specially if the operating systems (\u0026ldquo;firmware\u0026rdquo; on embedded systems) are changed or the same OS is upgraded and it has the need of reestructuring the partitions. In any case, an index has to describe the partition structure somewhere.\nWhat is the basic info to know about a storage partitions?\nThe offset address: indicates where the partion starts on the storage. The partition size: how long is the partition from its offset address. The partition type: identifies what is the usage of the data contents. Where to store the partition entries To put that index of partitions hardcoded with the firmware is a bad idea. How to know if those partitions are initialized with the expected data type? What if the user decides to try another OS and it initializes the the partitions just like the developer has decided to do so? Installed OS has to check the rightness of the storage on every boot? Definitely, the index of partitions must be out of the own OS code in order to keep organized the data on the flash memory.\nPC Nowadays, personal computers use partition tables on every disk (see GPT and MBR). This partitions tables are located very close to the beginning of the disk (reserving some initial sector of bytes for old bootloaders). However, this partition tables are designed for very large disks and they have some complexity related to PC and its computer history, not really needed for flash memories.\nSBC Single board computers and embedded systems with the U-Boot bootloader store the partition index as parameters in the mtdparts environment variable and it is passed to the OS as argument. This environment is hardcoded or stored in a defined partition as text. More recently, they use Device tree but this is also stored in a partition.\nESP32 ESP32 is a MCU managing partitions without hardcoded information and it is a good example to examine. It defines a partition table of 3Kb length at a fixed position with capacity to define 95 partitions. Maybe some excessive but the interesting thing is that partition table follow the pattern \u0026ldquo;offset-size-type\u0026rdquo; as basic information.\nThe summing-up is that every system using partition index and not hardcoded stores the partition entries in some storage space and, this partition table, can be considered a little partition too. It is located in a well-know offset address of the flash storage.\nPaper PineTime is a device under open development and it offers undreamed possibilities to develop and to flash several firmwares by users. It might be convenient that external storage (SPI flash) can be accessed by using a partition table so, different firmwares will be able to share partitions with user information, settings, bluetooth bindings, calibration parameters.\nFor example, it is possible to organize the flash to save a logo shown by the bootloader. And it doesn’t mean a mandatory requirement at the moment but bootloader or application can be changed and they will be able to found the logo to show or save a customized one.\nWhat is the cost of managing a partition table? In this case, community (developers) should be discuss and publish a paper with a proposal for the partition table structures and implement in their firmware for the PineTime. It must be simple and suitable in order to organize the flash storage in partitions without more overhead than read the partition table, look for the partitions those are interested in and use them.\nPartition table draft-#0 Location of partition table: first page of external flash (256 bytes).\nC structures C code:\n#define OFFSET_T uint32_t #define SIZE_T uint32_t /* bits 0-7 is type, bits 8-15 is subtype, bits 16-31 are flags */ #define TYPE_T uint32_t struct partition_entry_t { OFFSET_T offset; SIZE_T size; TYPE_T type; }; struct partition_table_t { uint32_t magic_bytes; /* always 0x50494e45 (\u0026#34;PINE\u0026#34;) */ uint32_t reserved[2]; /* reserved, do not use */ partition_entry_t entries[20]; /* 20*sizeof(partition_entry_t) == 240 */ uint32_t checksum; /* CRC-32 MPEG2 variant (used by MCU bootloader) */ }; #define PARTITION_TYPE_NOT_USED\t0x00 #define PARTITION_TYPE_BOOT_LOGO 0x01 #define PARTITION_TYPE_FACTORY_IMG 0x02 #define PARTITION_TYPE_LITTLE_FS 0x03 ","permalink":"/documentation/PineTime/Flashing/External_flash_partitioning/","tags":null,"title":"External flash partitioning"},{"categories":null,"contents":" Pine blog, containing news about the PinePower products PinePower 65W on the official Pine store PinePower 120W EU version on the official Pine store PinePower 120W US version on the official Pine store ","permalink":"/documentation/PinePower/External_links/","tags":null,"title":"External links"},{"categories":null,"contents":" The PineTab on the Pine64 store The PineTab section of the Pine64 forums Comments on back cover removal on forums Demonstration Video: Pinetab back cover removal on forums ","permalink":"/documentation/PineTab/Further_information/External_Links/","tags":null,"title":"External Links"},{"categories":null,"contents":"Here are a list of the external ports. See Technical Reference - Expansion Ports for port specifications.\nLeft side Barrel jack for power, (with LED) USB 3, Type A USB 3, Type C Right side USB 2, Type A Standard headset jack MicroSD card slot ","permalink":"/documentation/Pinebook_Pro/Features/External_ports_list/","tags":null,"title":"External ports list"},{"categories":null,"contents":" Retro Center online store R-Cade software detail PINE64 forum ","permalink":"/documentation/RockBox/External_resources/","tags":null,"title":"External resources"},{"categories":null,"contents":"Q: Are the individual MAC addresses linked to the PHY chips, or the module?\nA: The MAC address is specific to the SOPINE module; swapping modules within the Clusterboard does not change the MAC address of the module.\nQ: Why will SOPINE modules not reboot when installed on a Clusterboard, but will when installed on a SOPINE Baseboard?\nA: The cause has been determined to be back-EMF, and can be resolved with some relatively easy hardware modifications, thanks to excellent troubleshooting performed by Eric. Please, have a look at the extensive article he wrote to find out how to resolve this issue. See also this forum thread for further information.\nQ: Do I need heatsinks on any of the components on the Clusterboard?\nA: According to the datasheets for the RTL8370N switch ASIC and the RTL8211E PHYs, they consume and thus dissipate up to about 3 W each. As a result, it would be advisable to properly affix passive aluminum heatsinks onto each of these components. Please note that this explanation does not cover the SOPINE and SOEDGE modules.\n","permalink":"/documentation/Clusterboard/Further_information/FAQ/","tags":null,"title":"FAQ"},{"categories":null,"contents":"A list of frequently asked question.\nHardware Revisions What are Community Editions? Community Editions of the PinePhone were versions of the PinePhone which came preinstalled with the operating system of a partner project and featured the logo of the project on the back panel. The Community Edition was intended to help partner projects developing these systems: \u0026ldquo;Community editions are meant to bring exposure to partner-projects operating systems and communities, as well as help finance ongoing development.\u0026rdquo;, source.\nIs the Community Edition hardware the latest revision? The Community Edition program (featuring the mainboard numbers 1.2 through 1.2b and branded back covers) which provided the branded PinePhones has since ended, and a Beta Edition has since been released. The only difference between each Community Edition is the inclusion of crucial bug fixes, with the last issue being fixed with the 1.2b motherboard shipping with the Manjaro CE PinePhones. The 1.2b motherboard is also currently used in the Beta Edition PinePhones, however the Beta Edition units do not ship with any back cover branding. There are currently no plans for further hardware revisions.\nAside from the back cover, the only other difference between each Community Edition is that starting with the postmarketOS PinePhone, a convergence package option was released that adds another gigabyte of ram to the phone and a 32GB eMMC instead of a 16GB eMMC. Convergence packages also included a dock for plugging in USB peripherals and connecting to an HDMI monitor, however you can purchase a generic USB-C dock to use with a 2GB PinePhone.\nThe predecessor to the Convergence Edition PinePhones was the Braveheart Edition intended for developers to bring up the platform, which had the version number 1.1. For more details about the topic see PinePhone.\nWill there be other Community Editions? Five Community Editions have been announced: UBports, postmarketOS, Manjaro, KDE, and Mobian. Since the release of the Mobian edition, the Beta Edition PinePhones have been released and the Community Edition Program has ended.\nIn simple terms, what are the differences between Braveheart and the new Community Edition? The Braveheart PinePhone was the first public revision of the PinePhone which was intended solely for developers and Linux enthusiasts. The UBports Community Edition was the next revision of the PinePhone with an updated mainboard based on feedback from the Braveheart Edition, see PinePhone. All current revisions of the PinePhone continue to be intended for developers and enthusiasts, however, PINE64 will be starting to offer partnered retail units of the PinePhone which will have a better warranty and technical support (keep in mind even then it is not intended for a broader audience at this time, as the software still needs work and the hardware does not hold up well to modern consumer standards).\nWill there be a newer revision after the Community Editions? Starting with the UBports Community Edition the PinePhone has gotten CE and FCC certifications, repeating the certification process due to changes in the hardware design is very expensive, so the 1.2b motherboard is viewed as the final revision. The PinePhone (and parts for them) will be produced and sold for at least 5 years.\nWill there be hardware differences between the Community Editions? Besides the varied back covers, starting with the launch of the PostmarketOS CE there has been the release of a convergence package option for the PinePhone which includes more ram and storage, and an included dock for convenience. There has also been minor hardware changes with the UBports CE (mainboard 1.2) and the Manjaro CE (mainboard revision 1.2b).\nGeneral How powerful is the PinePhone\u0026rsquo;s hardware? The PinePhone is about on par with a Raspberry Pi 3 in terms of CPU performance, however it’s Mali 400 MP2 is much weaker than the Pi 3’s VideoCore IV. The Mali 400 was the first mobile OpenGL ES 2.0 GPU on the market back in 2008 when it was released, compared to the much newer Videocore IV released in 2010. The PinePhone has been shown to handle smooth H.264 1440p30 video playback using Cedrus and gstreamer as documented here. The device should be more than capable of a smooth phone experience when used in conjunction with well optimized software that makes use of its hardware features. It is also capable of running many light games (including 3D ones such as SuperTuxKart), and retro gaming. Expect further speed improvements over time as the drivers are improved, and in the meanwhile you can look into slightly Overclocking the device (at your own risk).\nSound The default ringtone for Mobian Phosh can be found at /usr/share/sounds/freedesktop/stereo/phone-incoming-call.oga\nBluetooth For some reason, using pipewire-pulse with bluetooth headphones (In my case, Sony WH1000X-M3) using the default LDAC codec causes the headphones to constantly connect and disconnect until they eventually give up pairing. A work around I’ve found is to quickly go into Sound settings and switch the codec to \u0026ldquo;SBC\u0026rdquo;.\nModem The modem isn\u0026rsquo;t working In order to use the modem and Wi-Fi/Bluetooth, you need to ensure the battery is inside the device and has a sufficient charge. Even when supplying the phone with enough power, the modem and Wi-Fi chip will not work without a connected battery. Further, double check that you have not put the SD card into the sim card slot, or vice versa.\nDoes the PinePhone only wake up from sleep for calls and texts? Yes. Unless the PinePhone is configured to wake up every few minutes from deep sleep in Crust (At the cost of battery life. However, in the future there may be other solutions), then there is not any way to get any notifications for applications. The modem on the PinePhone will wake the device for incoming calls and texts however, and the real-time clock is also capable of waking the device for alarms.\nBattery The battery is stuck inside the phone The battery can be stuck in the phone if the screws of the frame are overtightened.\nFirst, try loosening the screws to the left and right of the battery compartment and remove the battery, it should go much easier now. These screws may be the culprit as they seem to make the sides of the midframe grip the battery. Do not tighten them fully and the problem should go away.\nIf your battery is still stuck inside the PinePhone, completely unscrew all the screws of the midframe. Then pull out the battery (you may have to fully take off the midframe in some cases to get it out). And then rescrew the midframe, but only tighten the screws to the point where they are just barely tight to hold. This should allow you to remove the battery easily.\nThe battery is discharging while the phone is powered off (Braveheart Edition) The issue is not present on the Community Edition. Due to a hardware bug, after power off, the phone still consumes 20–30mA which drains the battery in 3-4 days. A manual procedure to fix the hardware bug is described here.\nThe battery only charges to ~84% Some pre-made operating systems using megi’s kernel limit the maximum amount of charge to roughly ~84% in the hope of prolonging the battery life, as repeatedly reaching the upper level of battery charge reduces the battery’s lifetime (this is not a safety feature!). The same effect however also applies when repeatedly draining the battery to a low level - users are therefore advised to consider if that setting is reasonable depending on their usage. The setting can be overwritten via Sysfs, to let the battery fully charge (this can lower the replaceable battery’s lifetime considerably depending on the charging behavior!):\nWarning The following instructions are directed towards expert-level users and developers! echo 4350000 \u0026gt; /sys/class/power_supply/axp20x-battery/voltage_max_design\nPrivacy Switches What are the privacy switches doing? Number Name Explanation Description 1 Modem Pulls Q1501 gate up (FET disabling modem power) \u0026ldquo;On\u0026rdquo; enables cellular communication and GNSS hardware, \u0026ldquo;off\u0026rdquo; disables it. 2 Wi-Fi / Bluetooth Pulls up CHIP_EN \u0026ldquo;On\u0026rdquo; enables Wi-Fi and Bluetooth communication hardware, \u0026ldquo;off\u0026rdquo; disables it. 3 Microphone Breaks microphone bias voltage from the SoC \u0026ldquo;On\u0026rdquo; enables audio input from on-board microphones (not 3.5mm jack), \u0026ldquo;off\u0026rdquo; disables it. 4 Rear camera Pulls up PWDN on OV5640 \u0026ldquo;On\u0026rdquo; enables the rear camera, \u0026ldquo;off\u0026rdquo; disables it. 5 Front camera Pulls up PWDN on GC2145 \u0026ldquo;On\u0026rdquo; enables the front camera, \u0026ldquo;off\u0026rdquo; disables it. 6 Headphone Pulls up IN2 on analog switch BCT4717ETB \u0026ldquo;On\u0026rdquo; enables audio input and output via the 3.5mm audio jack, \u0026ldquo;off\u0026rdquo; switches the jack to hardware UART mode. Memory What\u0026rsquo;s the speed difference between the eMMC and SD cards? Maximum transfer speed of the eMMC is around 85 MB/s, while SD cards are limited to approximately 23 MB/s (even with faster cards).\nGPS GPS doesn\u0026rsquo;t work Like almost all smartphones, the PinePhone GPS antenna is small and can only get a first fix unassisted if the GPS signal is very strong. To make first fix faster and more reliable, phones download assistance data either from the phone network or from the internet. The GPS in the PinePhone modem supports the internet based assistance method, as detailed in the modem documentation, but this is currently only supported by a few distributions, and a proof of concept script that shows it can work.\nUntil aGPS support becomes standard you’ll have to make some manual changes - see for example Mobian wiki\nGPS can\u0026rsquo;t determine direction Currently, due to the magnetometer not being hooked up in software at this time, it is not possible for GPS software to use the phone’s compass functionality. This means while you are walking it will not be possible to determine the direction of travel. This is not as much of an issue for vehicles as the faster speeds mean that it is possible to estimate the direction of travel, however it will still be an issue should the vehicle travel through a tunnel and lose GPS signal.\nSoftware Installation How can I install an operating system on the SD card / eMMC? See Installation instructions.\nBooting What\u0026rsquo;s the boot order for SD cards and eMMC? The PinePhone will automatically boot from microSD if a bootable card is inserted. If no (bootable) microSD is found, it will boot from eMMC.\nHow can I select different operating systems at boot? There was a project by Danct12 which allowed the user to select different operating systems at boot, but the repository has since been archived: https://github.com/dreemurrs-embedded/Pineloader.\nI turned on my Manjaro CE PinePhone. The red LED and screen backlight are briefly lit, then both are not and it will not boot. This can be the result of at least one situation:\nThe eMMC installation became corrupt or otherwise unbootable An SD card is present but not bootable (consider PinePhone Troubleshooting) If there is an installation of Manjaro on both the eMMC \u0026amp; an SD card, the SD card will always boot first on the device. Try taking the SD card out and booting the installation that is on the eMMC. If the problem persists, it is likely there is an issue with both installations and you will need to reinstall your distribution. You may also want to check with your distribution’s maintainers if boot issues are a common problem in a recent update.\nI did not install an update in Ubuntu Touch and I\u0026rsquo;m stuck on the PINE64 logo after rebooting. Use a USB A-C cable to plug your phone into your PC Hold the PinePhone’s power button for 4 seconds or more to power it off. Wait 5 seconds Hold the Volume Up and Power buttons on the PinePhone to boot into recovery. You should see the LED light red, then yellow, then green. The \u0026ldquo;Installing update\u0026rdquo; screen will appear, but a progress bar to indicate update progress will not. Ignore the \u0026ldquo;Installing update\u0026rdquo; part. Your PC may automatically mount the PinePhone’s partitions. If it does, Safely Remove or Eject all of them. Open a terminal on your PC. Type telnet 172.16.42.1 You should receive the text \u0026lsquo;Welcome to Rescue SD Shell|\u0026rsquo; In the new Rescue SD shell, type umount /dev/mmcblk2p10; e2fsck -fy /dev/mmcblk2p10 \u0026amp;\u0026amp; sync Once this command pipeline finishes, type sync \u0026amp;\u0026amp; reboot -f Your PinePhone should reboot into Ubuntu Touch. Now head to Settings - Updates and install the new update!\nIf these steps did not solve your issue, please create a new thread here on the PINE64 forums, note what the problem looks like, then say that you’ve tried these steps already.\nThis is caused by corruption on the userdata partition. Normally this should be fixed by \u0026rsquo;e2fsck\u0026rsquo; in the initramfs, however, an error in image creation means that that version of e2fsck is unable to correct the corruption. This has been fixed in all new PinePhone updates, so if you update from the factory image to any other image available to the PinePhone now, you will not experience this issue any longer.\nThe PinePhone does not boot Most operating systems on the PinePhone do not boot if the battery is not connected or if it is fully drained. If you received a new PinePhone make sure to remove the battery isolator as explained under PinePhone Getting started.\nIf you removed the battery isolator and the battery contacts are intact, the battery is either fully drained or there is no valid OS (or a corrupted OS or bootloader) installed on the eMMC or the SD card. Make sure to charge the phone with a compatible charger (500 mAh is not enough for modern phones), as well as the installation instruction under Installation instructions. If the OS got corrupted it is highly recommend to simply reflash.\nIf nothing works please don’t hesitate to contact the community, they are eager to help and booting issues are usually very easy to solve (as they are typically either battery or installation related). The phones itself are all tested individually at the factory. Do not contact PINE64’s support for booting issues.\nA protection foil isolates the battery for the shipping.\nThe microSD belongs in the upper slot, the micro SIM in the lower slot.\nCan I install a different OS on my Community Edition? Yes. While all the Community Edition PinePhones come with an OS preinstalled, you are free to use any OS on the integrated storage (the eMMC) or an SD card, see Installation instructions and Operating systems on how to install them.\nOther How can I enable SSH? In Ubuntu Touch you can run \u0026ldquo;sudo start ssh\u0026rdquo; to get a one-time start, or edit /etc/init/ssh.override and remove the manual line to make it auto-start.\nIn other distributions you may have to install SSH through its package manager and then proceed to use its init system to enable it. For Manjaro, Arch, and Mobian you can use \u0026ldquo;systemctl enable sshd\u0026rdquo; and \u0026ldquo;systemctl start sshd\u0026rdquo; command to enable and start the ssh daemon.\nWhat works, what doesn\u0026rsquo;t? For Ubuntu Touch see https://gitlab.com/ubports/community-ports/pinephone#what-works-what-doesnt.\nOther distributions will have different levels of functionality. Please refer to the release page of your chosen distribution for further information.\nI can\u0026rsquo;t connect to a 2.4Ghz Wi-Fi network in Ubuntu Touch. Reboot your device by holding the power button until the \u0026ldquo;Power\u0026rdquo; dialog appears, then pressing \u0026ldquo;Restart\u0026rdquo;.\nIf that does not fix the issue, note that all the following conditions must be met to use Wi-Fi on the PinePhone:\nThe plastic tab between the battery and the device’s battery contacts has been removed The battery is installed The Wi-Fi privacy switch (switch number two) on the rear of the device is switched \u0026ldquo;ON\u0026rdquo; Wi-Fi in the PinePhone only seems stable after a warm reboot like this.\nWhat\u0026rsquo;s the status of Android for the PinePhone? Currently, there isn’t any major push to get Android running well on the PinePhone. The developer Icenowy did get a partially working Android image, but it was slow and buggy, lacking some major functions. As of now, use Anbox as an alternative for your android apps, which is currently not included in Ubuntu Touch. In other distributions your millage may vary on what applications will run and how well.\nWhy are my apps loading slower than on my Android phone? Android has multiple techniques in place to speed up launching applications after the first launch, such as the \u0026ldquo;Dalvik cache\u0026rdquo;.\nUsing an alternative filesystem such as F2FS on the eMMC (which is considerably faster than running software on the SD card) may help improve performance slightly. Over time you can expect further optimizations and improvements in various distributions that will help speed up the PinePhone.\nHow can I turn on the backlight? On some devices the default calibration of the backlight is not sufficient and the minimum setting of the brightness of the used OS can be too low, causing the backlight to completely shut down. In that case it is recommended to connect the phone to a charger and/or to shine a flashlight at the screen to adjust the brightness to a higher setting again.\nOn many Linux distributions the brightness setting is an integer between 0 and 1000 and available at runtime in /sys/class/backlight/backlight/brightness and stored at shutdown and loaded at boot from /var/lib/systemd/backlight/platform-backlight:backlight:backlight by systemd-backlight@backlight:backlight.service. Changing the brightness setting can be done at runtime, for example over SSH, by executing as root echo 500 \u0026gt; /sys/class/backlight/backlight/brightness. The stored brightness setting can be modified using another system, by mounting the root filesystem of the system you want to fix and by executing echo 500 \u0026gt; [MOUNT LOCATION]/var/lib/systemd/backlight/platform-backlight\\:backlight\\:backlight.\nHow can I contribute regarding the WiFi and Bluetooth firmware? The PinePhone uses Realtek RTL8723CS for its Wi-Fi and Bluetooth connectivity. Unfortunately, just like the other Realtek wireless chipsets (see more info) - the RTL8723CS chipset requires proprietary firmware for Wi-Fi and Bluetooth functionality. For those who want to create replacement free software firmware, resources like this and this (different chipsets, but still Realtek) could be a great starting point for further research.\nSMS The phone does not receive SMS Sometimes incoming SMS messages are not being received, but outgoing ones, phone calls and data are working fine. One cause of this is if ModemManager fails to receive messages from the modem and they build up. These messages are not cleared by either rebooting reflashing the phone.\nNew versions of the (mostly) foss community firmware implement a workaround that helps ModemManager receive stuck messages.\nMost UIs (at least phosh, plasma, and sxmo) use ModemManager to communicate with the modem including for phone calls, cellular data, GPS and SMS.\nYou can check for stuck sms messages using the mmcli command:\n$ mmcli -m any --messaging-list-sms Found 10 SMS messages: /org/freedesktop/ModemManager1/SMS/0 (received)\nAny messages that are listed have gotten stuck, they can be deleted like this:\n$ mmcli -m any --messaging-delete-sms=77 (Repeat with all listed messages)\nFor more information on the messaging related actions available in mmcli you can check the help with mmcli --help-messaging. This article is also helpful in learning: https://electronproton.com/mmcli-command-examples/.\nShipping I did not receive an order confirmation Check your \u0026ldquo;spam\u0026rdquo; folder. It was reported that some users did not receive an order confirmation. You will also still get a shipping notification when the device ships out, even if you didn’t get an order confirmation email.\nWhen does the phone ship? For up-to-date information when the phone’s shipping date is estimated, see the edits in the corresponding forum thread.\nIt is shipping day but I did not receive a shipping notification For shipments with DHL the shipping notification is sent out as soon as the packet reached DHL’s warehouse and scanned (it can take up to 24 hours after scanning after the shipment is added to DHL’s database). For all other shipments (via Ascendia) the notification is sent out sometime after shipment.\nWhen does my phone ship if I order now? Orders made after Friday, 22nd May 2020 are shipped after the first bulk of pre-orders has been shipped. The exact date is not known yet due to various reasons, it may be a few weeks after the first bulk shipped. The forum will be edited with updated information and you will receive a shipping notification when the device was shipped.\nWhat about import taxes? Import taxes have to be paid by the buyer depending on the jurisdiction of the country of the buyer. Please check with your local laws if there are import taxes to pay and if so how to do the tax filing.\nAccessories Protection Which screen protector should I use? Protecting your screen is important, especially for devices like the PinePhone that doesn’t have access to the newest glass technology. The Braveheart and Community Editions of the PinePhone comes with a plastic film screen protector installed, and PINE64 sells a tempered glass screen protector in their store.\nYou can also buy a third-party screen protector, as the screen protectors for the iPhone 11 Pro Max/XS Max fit the PinePhone pretty well based on this forum post.\nBatteries I want a replacement battery, which one should I buy? Replacement batteries for US customers are available in the store.\nCurrently the PinePhone battery is known to be compatible with replacement batteries for the Samsung J700. Specifically, models \u0026ldquo;EB-BJ700BBC\u0026rdquo; and \u0026ldquo;EB-BJ700BBE\u0026rdquo; are compatible with all PinePhone models, and \u0026ldquo;EB-BJ700CBE\u0026rdquo; is compatible with Community Editions after UBPorts (due to plastic tabs on its bottom which only the newer phones have tolerance for).\nExternal hardware Will PINE64 sell other add-ons made for the PinePhone? Yes, currently there is a keyboard case with similarities to the Psion 5 which includes an internal battery, and a Qi wireless charging add-on planned, both of which PINE64 intends to directly sell. There is the potential for future add-ons such as a game pad, however that is currently just an idea and not in any way planned.\n","permalink":"/documentation/PinePhone/FAQ/","tags":null,"title":"FAQ"},{"categories":null,"contents":" Does PineTime run Linux? No. Please read this forum article for information about Linux on PineTime. Also check out the article \u0026ldquo;PineTime doesn’t run Linux\u0026hellip; But that’s OK!\u0026rdquo;\nWhy are there two versions of the PineTime in the store? See the below question and answer.\nWhy can I only buy the closed version in a 3-pack, and the open version per one? TL:DR: The unsealed PineTime is for development, the sealed one is for production use, because of firmware uploads. That is also why they were initially sold three in a pack.\nIn the current situation in development there are some reasons to want to be sure you only experiment with an open device. If you install the wrong firmware, your device could be bricked, until you find a way to open it, which will likely damage the device. The idea is that if you want to develop an application for the PineTime, you will be testing it out first, and only after you know for sure your new firmware is well tested, you will install it on sealed devices. If you are in the beta stage, having more than one PineTime is probably a good idea. So to prevent people from locking themselves out at the first test, it was decided to sell the closed version only as a pack of 3. Development can be done on an open device, so any issues can be easily handled.\nHow long does it take to ship my PineTime? That depends on whether you chose for Standard or Express shipping. Standard shipping for the dev kit may take up to a few weeks.\nHow do I install new software on PineTime? If you have a Sealed PineTime, flash only tested PineTime Firmware to your PineTime. If you flash unknown PineTime Firmware, your sealed PineTime may be bricked relatively permanently.\nThere is a lot of different software for flashing. Check out Development page for a list of companion software.\nAlso see this page to see various methods of reprogramming the devkit PineTime the wired way.\nRemember to validate the firmware after flashing: Swipe up to show the menu, tap the checkmark icon, tap \u0026ldquo;Validate\u0026rdquo;.\nMy PineTime arrived, now what? You should start by testing out all the features of the watch, to make sure everything works. Power it on and check the display.\nPineTime is shipped with InfiniTime firmware. Press the watch button to show the clock, then swipe up on the touchscreen to reveal the menu.\nYou probably now wish to update the bootloader and firmware.\nWhat\u0026rsquo;s the OS that\u0026rsquo;s preinstalled on the PineTime by default? PineTime ships with the open source InfiniTime firmware.\nTo support firmware update and rollback, PineTime includes the open source MCUBoot Bootloader.\nCan we use this OS or its source code? Yes, InfiniTime and the MCUBoot Bootloader are open source.\nWhy is the back exposed? Is it supposed to snap on? The back cover of the PineTime devkit is exposed so that you can flash and debug the device with the SWD pins. The main unit and cover does not snap (lock) together. If you want to attach the back cover anyway, you can use glue or tape.\nWhat hardware should I use to flash code to the PineTime? There are several ways you can do this, check out Reprogramming the PineTime\nHow do I connect the PineTime to a programmer? Here’s how: Devkit wiring\nHow do I set the time on PineTime? In recent versions of the firmware, you can set it directly from settings.\nYou can also use either GadgetBridge or the closed-source nRF Connect and Da Fit apps. See \u0026ldquo;Set PineTime Date and Time with nRF Connect\u0026rdquo;\nYou can also set the time using your PinePhone or other Linux-based Bluetooth LE capable device with the Bluez software installed. Install the bluez package and make sure your PineTime is running and awake with InfiniTime 0.7.1 or later.\n$ bluetoothctl [ bluetooth ]# scan on ... [NEW] Device D7:03:FB:6E:31:B2 Pinetime-JF ... [bluetooth]# pair D7:03:FB:6E:31:B2 Attempting to pair with D7:03:FB:6E:31:B2 ... [NEW] Characteristic (Handle 0xfd80) /org/bluez/hci0/dev_D7_03_FB_6E_31_B2/service0015/char0016 00002a2b-0000-1000-8000-00805f9b34fb Current Time ... [Pinetime-JF]# menu gatt ... [Pinetime-JF]# select-attribute /org/bluez/hci0/dev_D7_03_FB_6E_31_B2/service0015/char0016 [Pinetime-JF:/service0015/char0016]# read Attempting to read /org/bluez/hci0/dev_D7_03_FB_6E_31_B2/service0015/char0016 [CHG] Attribute /org/bluez/hci0/dev_D7_03_FB_6E_31_B2/service0015/char0016 Value: b2 07 01 01 00 04 15 00 00 ......... b2 07 01 01 00 04 15 00 00 ......... [Pinetime-JF:/service0015/char0016]# write \u0026#34;0xe4 0x07 0x0c 0x1f 0x0e 0x02 0x00 0x00 0x00\u0026#34; Use the list-attributes command to find the correct path. Look for the characteristic named \u0026lsquo;Current Time\u0026rsquo;\nThis is the format for the current time as hex bytes:\n\u0026lt;lsb of year\u0026gt; \u0026lt;msb of year\u0026gt; \u0026lt;month (1-12)\u0026gt; \u0026lt;day (1-31)\u0026gt; \u0026lt;hour (0-23)\u0026gt; \u0026lt;minute (0-59)\u0026gt; \u0026lt;seconds (0-59)\u0026gt; \u0026lt;weekday (1-7 where Monday)\u0026gt; \u0026lt;fractions (1/256th of second)\u0026gt; Is there a standard agreed method of pushing OTA updates so that one could seal the PineTime dev kit nicely? InfiniTime supports firmware updates over Bluetooth LE with the nRF Connect mobile app. See \u0026ldquo;Download and Test Our PineTime Firmware\u0026rdquo;\nMy PineTime\u0026rsquo;s screen shows garbage, how do I fix it? This is usually caused by unplugging the device after it has booted, it needs to be reinitialised. To do so just restart the watch by removing power to it.\nI have experience developing on Arduino. How does the PineTime compare? To learn programming on PineTime, check out this article\nArduino provides the Arduino IDE (or you use the avr-gcc and avrdude command-line tools) which you can use to compile and upload code to an Arduino board. The PineTime and its ARM processor doesn’t have this, so you’ll have to familiarize yourself with tools like GCC for ARM, and OpenOCD. Some experience with Arduino does translate over to the PineTime, especially if you’ve worked with LCD’s, or SPI. The PineTime is at least four times faster than an Arduino Uno (even faster at certain specific workloads due to hardware acceleration), and it has 32 times more RAM and 16 times more flash storage.\nLup Yuen Lee (just call him Lup, rhymes with \u0026ldquo;Up\u0026rdquo;) has written many articles on PineTime programming. Check out the articles here\nCan I code firmware for PineTime without an actual PineTime? Yes, you may code PineTime Watch Faces and preview them in a web browser (thanks to WebAssembly).\nPineTime Simulator\nThen flash your firmware remotely to a real PineTime via Telegram, and watch your firmware run in a live video stream.\nRemote PineTime\nWhat do I need for building PineTime firmware locally on my computer? Most flavours of PineTime firmware (InfiniTime, Hypnos, Klok, wasp-os) will build fine on Linux (x64, Arm32, Arm64) and macOS. Just follow the instructions provided.\nDownload version 9-2020-q2-update of the Arm Embedded Toolchain arm-none-eabi-gcc. Other versions of gcc may have problems building the firmware correctly.\nOn Windows, install Windows Subsystem for Linux (WSL) and execute the build steps inside the WSL Terminal (instead of the Windows Command Prompt). USB Programmers (like ST-Link and JLink) are not supported in WSL, so use the Windows Command Prompt to flash your built firmware to PineTime.\npinetime-rust-mynewt firmware for PineTime supports building and flashing via the Windows Command Prompt (no need for MinGW and Docker).\nCan I use Pinebook Pro for developing PineTime? Yes, use version 9-2020-q2-update of the Arm Embedded Toolchain arm-none-eabi-gcc. Other versions of gcc may have problems building the firmware correctly.\nWhat is ARM Semihosting? We use the SWD (Single Wire Debug) protocol created by ARM for flashing and debugging PineTime’s nRF52832 microcontroller, which contains an ARM CPU. (SWD is derived from standard JTAG, but with fewer wires) With ARM CPUs you can trigger a software breakpoint, and allow the debugger (OpenOCD) to do something really nifty: Display a message, read console input, dump out a file, even read a file. That’s called ARM Semihosting. More about ARM Semihosting\nWhat is OpenOCD? OpenOCD is Open On-Chip Debugger. It’s the software that drives your microcontroller debugger/flasher. We need it for running any kind of flashing and debugging with Pi or ST-Link. gdb talks to OpenOCD for debugging firmware. gdb also works with VSCode for debugging firmware visually. More about OpenOCD\nPlease use xPack OpenOCD with PineTime. Other versions of OpenOCD seem to have problems with PineTime.\nHow do I remove flash protection? PineTime watches shipped before 20 Sep 2020 have flash protection enabled.\nThe flash protection can be removed using multiple different methods. If you don’t have anything except the PineTime, not even a Raspberry Pi, then you have to order a programmer online: you can use a J-Link, CMSIS-DAP dongle and various other programmers. See this page to see various methods of reprogramming the PineTime.\nIf your PineTime was shipped after 20 Sep 2020, you don’t need to remove flash protection. They are shipped with flash protection disabled. You can flash and debug PineTime right away with ST-Link, JLink and Raspberry Pi.\nWhy can\u0026rsquo;t you use ST-Link to remove nRF52 Flash Protection? Because ST-Link is a High Level Adapter. It doesn’t really implement all SWD functions, just a subset (probably to keep the price low). More details in the section \u0026ldquo;Why Visual Studio Code with ST-Link (instead of nRFgo Studio with J-LINK)\u0026rdquo; in the article \u0026ldquo;Coding nRF52 with Rust and Apache Mynewt on Visual Studio Code\u0026rdquo;.\nSince we need a low level SWD adapter like Raspberry Pi anyway, can we do everything on a Pi instead of ST-Link + Windows? Yes, Raspberry Pi works for flashing and debugging PineTime, even for removing flash protection. We have a special version of OpenOCD called OpenOCD SPI that talks to PineTime’s SWD port over SPI (without bit-banging). See PineTime Updater\nIs there a 3D model of PineTime available somewhere? Not yet. Someone did design a cover you can snap on to keep the back shut. More details\nAre there any alternatives to the wrist band provided with the PineTime? No, but PineTime accepts standard 20mm wrist band that is widely available by a third party.\nNote that some sellers have a different point of view on what standard is. So you should always check the fitting to make sure it looks like the one used by PineTime.\nTroubleshooting PineTime\u0026rsquo;s Bluetooth (InfiniTime firmware) Old (pre 1.4) InfiniTime firmware had an issue where Bluetooth connectivity sometimes gets lost/fails.\nThe fix was to soft-reset the watch, by holding the PineTime button for ~8 seconds until the PineCone logo appears.\nDoes PineTime have an audible beeper or speaker? No, but in practice the vibration component is a substitute for use with alerts.\n","permalink":"/documentation/PineTime/FAQ/","tags":null,"title":"FAQ"},{"categories":null,"contents":" Key left of Z ( \\ | ) How to map the key next to Z to the symbols on \\ and | (rather than \u0026lt;\u0026gt;) ?\nChoose the alternative international US keyboard layout and variant. The name will depend on you desktop environment:\nEnglish (US, alt. intl.) English (US, international AltGr Unicode combining, alternative) English (US, alternative international) Note keyboard variants with similar names as the ones above change the upper left key for ` and ~. You have to press that key twice to get the desired char. This happens with the alt-intl variant. Choose the altgr-intl variant (or however it is called in your desktop environment) and it should work as expected. To set the keyboard layout and variant in the terminal for X-Windows use:\nsetxkbmap -layout us -variant altgr-intl The Archlinux Wiki has some good help if you need to tweak your layout further [https://wiki.archlinux.org/index.php/Xorg/Keyboard_configuration#Setting_keyboard_layout]\nKey between Fn and Alt (Menu) How to map the key between Fn and Alt to SUPER / META ?\nThe initial setup in many desktop environments maps the key between Fn and Alt to MENU. Although the menu key can be useful as well (e.g. spell correction in the browser) many desktop environments and window manager use the Super key for many other useful functions. And users are probably more used to have the META key near Ctrl and Alt.\nIn X-windows the following command maps the key between Fn and Alt to META and the Caps-Lock key to MENU.\nsetxkbmap -option caps:menu,altwin:alt_super_win Set display brightness in the terminal To set the display brightness in the terminal use xbacklight (if available in your distro):\nxbacklight -setXX XX is the percentage (%) of brightness. E.g. for 70% brightness\nxbacklight -set70 If you use LXQt you can also use:\npkexec lxqt-backlight_backend --inc pkexec lxqt-backlight_backend --dec For an alternative solution please see the scripts discussed in this thread: [https://forum.pine64.org/showthread.php?tid=5062]\nGet battery % in CLI As ACPI is not compatible with ARM, to gather the % battery this can be used:\ncat /sys/class/power_supply/battery/capacity Firefox font size How to get a useful font size with firefox ?\nTo have every web page displayed in a larger more readable font size type about:config in the search bar and confirm on the first page that you want to make changes. Then search for this parameter:\nlayout.css.devPixelsPerPx and modify the value (right click) to something between 1.2 to 1.5 depending on your preferences.\nIn addition to that you can set in Preferences -\u0026gt; General -\u0026gt; Fonts \u0026amp; Color -\u0026gt; Advanced Minimum font size to 16\nDisable wireless power management If having issues with wifi connectivity, try to disable power management in the 8723cs module options, adding rtw_power_mgnt=0 in /etc/modprobe.d/8723cs.conf\noptions 8723cs rtw_initmac=00:ba:ch:16:85:46 rtw_power_mgnt=0 Touchpad acceleration and scroll direction To set touchpad parameters from the cli you can use the command xinput. To use it correctly you first need to determine the device id / name for your touchpad. To do so, use:\nxinput list You are looking for a line like this:\nHAILUCK CO.,LTD USB KEYBOARD Mouse id=7\t[slave pointer (2)] With the device id = 7 found you can list the parameters that can be set with xinput.\nxinput list-props 7 The result looks similar to this:\ndevice \u0026#39;HAILUCK CO.,LTD USB KEYBOARD Mouse\u0026#39;: ... libinput Natural Scrolling Enabled (256):\t0 ... libinput Accel Speed (265):\t0.000000 ... To change the parameter use xinput set-prop\nTo set reverse scrolling for the touchpad use this command\nxinput set-prop 7 \u0026#39;libinput Natural Scrolling Enabled\u0026#39; 1 To set mouse speed\nxinput set-prop 7 \u0026#39;libinput Accel Speed\u0026#39; 0.95 Check different numbers for 0.95 to meet your needs.\nFor more details on xinput and mouse speed also see the Archlinux Wiki [https://wiki.archlinux.org/index.php/Mouse_acceleration#Using_xinput]\nProlong battery life How to reduce the max voltage the battery is charged to:\n$ cd /sys/class/power_supply/axp20x-battery Note The voltage_max_design is writable by root, values are in microvolts. The factory value is 4200000 or 4.2V on my device. This charges to 100% capacity. $ cat voltage_max_design 4200000 Check the factory value on your device, and record it if it is different. The value depends on the battery installed. You can reduce it to 4.1 V by running the following Linux command as root:\n$ echo 4100000 \u0026gt; voltage_max_design If you are fully charged and on AC, the battery will start discharging until it reaches 4.1 V. This will be about 98% capacity on my device. This prolongs the battery life when you don’t need the extra few minutes of offline power. The Linux driver will not let you set the maximum voltage to a value smaller than 4.1V (as of Linux kernel 6.3.8).\nThe setting seems to be retained across reboots.\n","permalink":"/documentation/Pinebook/FAQ_and_tips/","tags":null,"title":"FAQ and tips"},{"categories":null,"contents":" Network 2.4 GHz 1T1R WiFi 802.11 b/g/n Bluetooth 5.2 Zigbee 10/100 Mbit/s Ethernet (optional, on expansion board) Storage On-board 16 Mbit (2 MB) or 128 Mbit (16 MB) XSPI NOR flash memory MicroSD - supports SDHC and SDXC (only on the 128 Mb version) Expansion Ports USB 2.0 OTG port 26 GPIO pins, including SPI, I2C and UART functionality, possible I2S and GMII expansion Dual-lane MiPi CSI port, located at USB-C port, for camera module Audio Microphone (optional, on the camera module) Speaker (optional, on the camera module) ","permalink":"/documentation/Ox64/Features/","tags":null,"title":"Features"},{"categories":null,"contents":" Board dimension Board Dimensions: 85mm x 56mm x 18.8mm, see the model-B board dimension drawing\nThe Oz64 3D model\nNetwork 2.4 GHz 1T1R Wi-Fi 6 Bluetooth 5.2 10/100 Mbit/s Ethernet with optional PoE capability Storage On-board eMMC module socket MicroSD, supports SDHC and SDXC Expansion ports USB 2.0 Host port 26 GPIO pins, including SPI, I^2^C and UART functionality 2x Dual-lane MiPi CSI port Optional dual-lane MiPi DSI port Input power Input Power: +5V @2A with 3.5mm/1.35mm Type H Barrel type DC connector (@1.5A will work if there is no heavy load on the USB 2.0 port)\nSoC and Memory Specification Based on the Sophgo SG-200x\nSG2000 block diagram\nCPU Architecture T-Head C906 1GHz MHz 64-bit RISC-V CPU:\nSupports RISC-V RV64IMAFCV instruction architecture Five-stage single-issue sequentially executed pipeline Level-1 instruction and data cache of Harvard architecture, with a size of 32 KB and a cache line of 64KB Level-2 128KB cache Sv39 memory management unit, realizing the conversion of virtual and real addresses and memory management jTLB that supports 128 entries Supports AXI 4.0 128-bit master interface Supports core local interrupt (CLINT) and platform-level interrupt controller (PLIC) With 80 external interrupt sources, 3 bits for configuring interrupt priority Supports BHT (8K) and BTB Compatible with RISC-V PMP, 8 configurable areas Supports hardware performance monitor (HPM) units See here T-Head C906 700Mhz MHz 64-bit RISC-V CPU:\nSupports RISC-V RV64IMAFCV instruction architecture Five-stage single-issue sequentially executed pipeline Level-1 instruction and data cache of Harvard architecture, with a size of 16 KB and a cache line of 16KB Sv39 memory management unit, realizing the conversion of virtual and real addresses and memory management jTLB that supports 128 entries Supports AXI 4.0 128-bit master interface Supports core local interrupt (CLINT) and platform-level interrupt controller (PLIC) With 80 external interrupt sources, 3 bits for configuring interrupt priority Supports BHT (8K) and BTB Compatible with RISC-V PMP, 8 configurable areas Supports hardware performance monitor (HPM) units See here ARM Cortex-A53 1GHz 64-bit RISC CPU:\nQuad-core Cortex-A53 up to 1.0GHz CPU Full implementation of the ARM architecture v8-A instruction set ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation ARMv8 Cryptography Extensions In-order pipeline with symmetric dual-issue of most instructions Unified system L2 128KB cache Includes VFP v3 hardware to support single and double-precision operations Integrated 32KB L1 instruction cache, 32KB 4-way set associative L1 data cache TrustZone technology support PD_A53: Cortex-A53 + Neon + FPU + L1 I/D Cache of core 2/3 8051 25-300MHz 8-bit CPU:\nIntegrated 8K SRAM System Memory SIP DRAM 512MB ","permalink":"/documentation/Oz64/Features/","tags":null,"title":"Features"},{"categories":null,"contents":"The PineBuds Pro’s buds are based on the BES 2300YP.\nCPU Features:\nDual-core ARM Cortex-M4F Processor Processor up to 300MHz CPU CMOS Single-chip Fully-integrated RF, PMU, Audio CODEC and Cortex-M4F CPU Memory Features:\n4MB Serial Flash On-chip for Custom Program Internal ROM 448KB for critical constants and code Internal SRAM 992KB for critical data and code BT Features:\nBluetooth 5.2 dual-mode compliant Profiles: A2DP, AVRCP, HFP Audio Codecs: SBC, AAC Audio Features:\nSupport BES Intelligent Bluetooth Retransmission (IBRT) Support FF/Hybrid ANC Dual MICs noise reduction Echo Cancellation Support low power voice activity detection Multi-band EQ and Bass enhancement Support Active Crossover Support TWS HiFi Stereo Audio DAC: 120dB SNR, 110dB DNR HiFi Stereo Audio ADC: 100dB SNR Sample rates from 8 kHz to 384 kHz Support dual/single Mic noise suppression -45dB attenuation nominal 50-200Hz -55dB max attenuation @150Hz Support ambient awareness Support talk through 24-bit audio processing PMU Features\n3.1V-5.5V Input for VBAT Internal LPO for low power mode. DCXO with internal oscillator circuit Internal temperature sensor Buttons/touch sensors Buds One capacitive touch sensor is located on the outward facing surface of each bud near the logo.\nCharging case Charging case have a reset button in center under the lid which is hooked to ThinkPlus Semi SY8821 integrated circuit and that button reset it from the safety off mode.\nSpecifications Dimensions:\nEarbud: Unknown Charging case: 70 x 50 x 35mm (unconfirmed) Weight:\nEarbud: 5g Charging case: 65g IP Rating of Earbuds: IPX4\nDynamic transducer (speaker): 6mm\nMicrophone: 3 – FeedForward, FeedBack, Talk\nSystem on Chip (in each earbud): BES 2300YP\nCPU: Dual-core 300MHz ARM Cortex-M4F ROM: 448KB SRAM: 992KB BT shared SRAM: 64KB Flash: 4MB (Endurance erase cycles: \u0026gt;500) Communication:\nBluetooth: Bluetooth 5.2 dual-mode compliant USB: USB to dual UARTs at charging case Battery:\nEarbud: Built-in LiPo 3.7V 40mAh Charging case: Built-in LiPo 3.7V 800mAh Ports earbud:\n4 pins Ports charging case:\n4 pogo pins USB type-C port 5V 500mA Power The charging case’s input power is DC 5V @ 0.5A USB Type-C.\n","permalink":"/documentation/PineBuds_Pro/Features/","tags":null,"title":"Features"},{"categories":null,"contents":" Portability and Temperature control Soldering tips: Replaceable and low cost Many styles: currently sold as 4-packs, one fine set, the other larger. Compatible with other ts100 tips. Multiple power sources will work for more flexibility: USB-C PD (power delivery), minimum 3 Amps, 12V. DC 5525 Barrel jack charger, minimum 3 Amps, 12V. Battery: connect to 18V-21V Lithium-ion tool batteries or 3S/4S/5S LiPo batteries. Pinecil V2 has a BL706 chip, see history of changes below. Board schematics are open. Software is open. Create your own! Pinecil breakout board lets you use JTAG, GPIO, A2D, SPI, and more. Additional features (useful for devkit):\nProgrammable Risc-V BL706 embedded processor V2 model allows BLE Bluetooth control because of the switch to the Bouffalo BL706 MCU. 0.69\u0026quot; Monochrome Display that can render text or graphics Support for Idle detection, sleep mode of tip, automatic shut-down Programmable with tools from Bouffalo Labs, HomeBrew or Linux RISC-V. ","permalink":"/documentation/Pinecil/Features/","tags":null,"title":"Features"},{"categories":null,"contents":" Front- and backside of the PineTab-V\nBackside of the PineTab-V\nChassis:\nDimensions: 242mm x 161mm x 9mm Weight: 520 grams (without keyboard), 990 grams (includes keyboard) Build: Metal and Plastic Color: Matte Black Display:\nType: HD IPS capacitive touchscreen, 16.7M colors Size: 10.1 inches Resolution: 1280×800 pixels, 16:10 ratio Platform:\nChipset: StarFive JH7110 CPU: 64-bit Quad-core 1.5 GHz SiFive U74 RISC-V GPU: Imagination Technology BXE-4-32 Memory:\nInternal Flash Memory: 64GB (variant 1) or 128GB (variant 2) eMMC module System Memory: 4GB (variant 1) or 8GB (variant 2) LPDDR4 SDRAM Expansion: micro SD Card support SDHC and SDXC, up to 2TB Camera:\nMain Camera: Single 5MP, LED Flash (chipset: Omnivision OV5648) Selfie Camera: Single 2MP (chipset: Galaxycore GC02M2) Sound:\nLoudspeaker: Yes, stereo 3.5mm jack with mic: Yes, stereo Sound IC: ES8316 Wireless:\nChipset: Realtek RTL8852BU WLAN: Wi-Fi 802.11 ax/ac/b/g/n, dual-band, hotspot Bluetooth: 5.2, A2DP I/O:\n1x USB 3.0 Type-C port (front side 3.0, rear side 2.0) 1x USB 2.0 Type-C port (also use as charging and debug port) 1x USB 2.0 Pogo keyboard port 1x microHDMI HD Video output Battery:\nRemovable Li-Po 6000mAh battery Charging: 15W – 5V 3A Model 30100140 from zgszjjy Charge IC: BQ25890H Fuel Guage: CW2015CHBD ","permalink":"/documentation/PineTab-V/Features/","tags":null,"title":"Features"},{"categories":null,"contents":"This section outlines the most important characteristics of the board and its components.\nSoC and Memory Specification The ROCKPro64 is based on the Rockchip RK3399.\nCPU Architecture Dual-core Cortex-A72 up to 2.0GHz CPU Quad-core Cortex-A53 up to 1.5GHz CPU big.LITTLE architecture: Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU Cortex-A72: 1-4x Symmetrical Multiprocessing (SMP) within a single processor cluster, and multiple coherent SMP processor clusters through AMBA 5 CHI or AMBA 4 ACE technology AArch64 for 64-bit support and new architectural features L1 cache 48KB Icache and 32KB Dcache for each A72 L2 cache 1024KB for big cluster DSP \u0026amp; SIMD extensions VFPv4 floating point Hardware virtualization support Cortex-A53: L1 cache 32KB Icache and 32KB Dcache for each A53 L2 cache 512KB for little cluster Full implementation of the ARM architecture v8-A instruction set ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation ARMv8 Cryptography Extensions In-order pipeline with symmetric dual-issue of most instructions Include VFP v3 hardware to support single and double-precision operations TrustZone technology support Full CoreSight debug solution One isolated voltage domain to support DVFS GPU Architecture ARM Mali-T860MP4 Quad-core GPU The highest performance GPUs built on Arm Mali’s famous Midgard architecture, the Mali-T860 GPU is designed for complex graphics use cases and provides stunning visuals for UHD content. Frequency: 650MHz Throughput: 1300Mtri/s, 10.4Gpix/s OpenGL® ES 1.1, 1.2, 2.0, 3.1, 3.2, Vulkan 1.0*, OpenCL™ 1.1, 1.2, DirectX® 11 FL11_1, RenderScript™. System Memory LPDDR4 RAM Memory Variants: Dual Channels 2GB and 4GB. Storage Memory: 128Mb built-in SPI Flash memory (as at August 2018 only support for USB boot). Display Dual VOP: one supports resolutions up to 4096x2160 and AFBC; the other supports resolutions up to 2560x1600 Dual channel MIPI-DSI (4 lanes per channel) eDP 1.3 (4 lanes with 10.8Gbps) to support displays, with PSR Digital Video port up to 4Kp60 DisplayPort 1.2 (4 lanes, up to 4K 60Hz) Supports Rec.2020 and conversion to Rec.709 Video Digital Video output up to 4K@60Hz 4K HDR @ 30fps H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4Kx2K @ 60fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4Kx2K @ 60fps VP9, up to 4Kx2K @ 60fps MPEG-1, ISO/IEC 11172-2, up to 1080P @ 60fps MPEG-2, ISO/IEC 13818-2, SP@ML, MP@HL, up to 1080P @ 60fps MPEG-4, ISO/IEC 14496-2, SP@L0-3, ASP@L0-5, up to 1080P @ 60fps VC-1, SP@ML, MP@HL, AP@L0-3, up to 1080P @ 60fps MVC is supported based on H.264 or H.265, up to 1080P @ 60fps Audio 3.5mm Phone Jack 3-pin S/PDIF header Audio via Digital Video port Camera Dual MIPI CSI, dual ISP, maximum input resolution of 13M pixels Network 10/100/1000Mbps Ethernet - Capable of pushing 941 MBit/s in iperf3 Wi-Fi 802.11 ac/a/b/g/n with Bluetooth 4.01 (old version with 2x2) / Bluetooth 5 (new version with 1x1) (optional) Storage microSD - bootable, supports SDHC and SDXC eMMC - bootable (optional eMMC module) 1x USB 3.0 host port 1x USB Type-C OTG port with alternate mode DP output 2x USB 2.0 dedicated host port Expansion Ports 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO header PCI Express 2.1 x4 (four full-duplex lanes) open-ended port, limited to the Gen1 speed Working Features Feature/Option Android Android Version Linux Linux Version Test/Verify Steps Notes Product Link PINE64 LCD Touchscreen (Screen/Touch) Yes/Yes No/No Maybe this will help get this working? 7-inch LCD Touch Screen Panel Wireless ROCKPro64 2×2 MIMO Dual Band WiFi 802.11AC / Bluetooth 4.2 Module (old) ROCKPro64 1x1 Dual Band WiFi 802.11AC / Bluetooth 5.0 Module (new) Yes/Yes No/Yes* For the \u0026ldquo;new\u0026rdquo; ROCKPro64 WIFI module: Verified with Manjaro ARM (kernel 6.2.5). A config file (\u0026ldquo;firmware file\u0026rdquo;) is needed at /lib/firmware/brcm/brcmfmac43455-sdio.txt. In 0.7.9 Ayufan linux releases this is deliberately disabled for stability reasons. On Manjaro ARM (kernel 6.2.5), WIFI seems to be stable with the firmware file. On a 5GHz network (802.11AC), it is possible to get about 120Mbps using the \u0026ldquo;new\u0026rdquo; ROCKPro64 WIFI module. ROCKPro64 1x1 Dual Band WiFi 802.11AC / Bluetooth 5.0 Module USB OTG Configure ip on usb0: ifconfig usb0 169.169.222.222 and run iperf, you should likely see about 200-300MB/s ROCKPro64 USB Mass Storage USB2/USB3 Yes/yes Yes/Yes Dedicated Fan Power (pwm1) Yes You might want to use ATS. GPIO pins (raw or via RPI python scripts) Check out what Frank Mankel has done. MIPI CSI Camera 1 and 2 eDP HDMI Audio Yes 7.1.2 Yes 4.4.132-1083 - 4.4.138-1100 Stopped working in 4.4.154.1105. Ayufan is looking into it. This is working in Manjaro ARM (kernel 6.2.5). Select the Analog Output (Built-in Audio Stereo) option in the audio output device selection window (either use pavucontrol or the volume button in the KDE desktop). Despite the slightly misleading name, audio does go through the HDMI port. See here for details: https://forum.manjaro.org/t/no-hdmi-audio-on-rockpro64/25595/2. 3.5mm Audio/Mic USB-C Host Display via USB-C Yes 7.x and 8.x eDP via USB-C per tillim. No sound on Android 7.x. Sound does work on Android 8.x ROCKPro64 PLAYBOX ENCLOSURE N/A N/A N/A Ventilation does not exist, thus requires manual changes to add venting. Case should be modified to account power adapter not being centered in cut holes. Opening the case once close without modifying it first is nearly impossible without special tools. Graphene heatsink is included and does well for Linux but not Android. ROCKPro64 Playbox Enclosure ROCKPro64 30mm Tall Profile Heatsink N/A N/A N/A ROCKPro64 30 mm Tall-Profile Heatsink ROCKPro64 20mm Mid Profile Heatsink N/A N/A N/A ROCKPro64 20 mm Mid-Profile Heatsink Fan For ROCKPro64 20mm Mid Profile Heatsink N/A N/A N/A You might want to use fanctl to control the fan while keeping your CPU cool Fan For ROCKPro64 20 mm Mid-Profile Heatsink HDMI output 4K@60Hz PCI Express 2.1 The PCI Express interface of the RK3399 is limited to the Gen1 speed. As a result, some installed PCI Express devices may operate with degraded performance, such as M.2 SSDs that support fewer than four PCI Express lanes, installed using an adapter like this one. Real Time Clock (RTC) battery backup RTC Backup Battery Holder CR2032 Boot from USB/PXE RockChip themselves have tables of supported features at 4.4 and mainline kernel versions in their wiki here.\n","permalink":"/documentation/ROCKPro64/Board/Features/","tags":null,"title":"Features"},{"categories":null,"contents":"Store page: pine64.com\nUses the pogo pins to interface a high quality fingerprint sensor, which uses open firmware for it’s i2c bridge, and can also be used for gesture navigation thanks to it’s ability to detect directional swipes.\nImportant No PinePhone operating system has added support for the fingerprint reader yet. Credits Credit goes to the user zschroeder6212, who carried the PinePhone Fingerprint Cover project from an idea to a real product. Their progress can be followed on GitHub under https://github.com/zschroeder6212.\nSchematics and Datasheet Schematic:\nPinePhone Finger Print Back Cover Schematic ver 3.0 20210124 Datasheet:\nP2SD Personal Identity Authentication Module Datasheet ATmel ATtiny Microcontroller Datasheet I2C to SPI firmware:\nzschroeder6212’s tiny-i2c-spi Github page ","permalink":"/documentation/Phone_Accessories/Fingerprint_reader/","tags":null,"title":"Fingerprint Reader Add-on"},{"categories":null,"contents":"This document provides a step-by-step guide on how to update the firmware of the Pinecil soldering iron, applicable to both V1 and V2 models. Keeping your firmware up to date ensures that you have the latest features, improvements, and bug fixes.\nOverview Tip Pinecil is designed to use only 1 power port at any time. Only the USB-C cable should be plugged in during firmware updates. Never attempt to use both rear ports at the same time or the PC and Pinecil will be damaged. The firmware that comes with the Pinecil is open source Ralim’s IronOS. It’s a good idea to check for updates regularly as development is very active and there may be enhancements or bug fixes.\nDepending on whether you have a Pinecil V1 or V2, they are updated using different flashers since they have completely different MCU chip (brains). The V1 is any Pinecil sold up to July 2022 (has a blue thumb grip). The V2 is any Pinecil sold after Aug 1, 2022 (has a green thumb grip). If you don’t have the two models mentioned, then you might not have an authentic Pinecil. This aritcle is designed and tested on authentic Pinecils only.\nGo to the appropriate section below depending on if you have a V1 or V2 model. Long hold down [-] to see the current firmware version installed. It is very hard to brick a Pinecil doing a firmware update because of the firmware is in ROM. Usually, just re-flashing it fixes it. Even if the other firmware caused the screen to go black, one could connect, put the Pinecil into flash mode, and flash again to an older or newer version of firmware or a beta version. Pinecil V1 only uses *.hex files for both firmware and boot logo art. Pinecil V2 uses only *.bin files for firmware. Note Loading boot logo art onto the V2 (BL706 MCU chip) is not yet possible. Volunteers are looking into this on both GitHub Blisp and GitHub IronOS. If you would like to see the progress or help with the code see Boot Logo Art ticket Flash Mode Important Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Both V1 and V2 connect to the PC/laptop and enter the Flash mode the same way for updating purposes:\nPlug one end of the USB cable to the PC/laptop. Long hold the [-] button before plugging the USB-C cable into the back of the Pinecil. Keep holding down the [-] for ~10-15 seconds after plugging in the cable, then release the button. Screen should be black/empty which means Pinecil is in Flashing Mode. If you have issues, try again, do not plug the USB-C cable into Pinecil until you first press \u0026amp; hold the [-] button. Flip the cable over or try another port/cable/PC if you still have issues. Unlike irons from other brands, Pinecil will not show in the PC as a USB data drive. On Windows, you will hear a single beep when connected in flash mode. Then use one of the flasher methods below based on the OS you have in order to flash new firmware (older V1 instructions are lower down here). Update V2: Windows Important Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Option 1: PineFlash The PineFlash is a GUI updater it’s an all-in one app that downloads firmware and flashes.\nDownload the easy premade binary installer for Windows here. If PineFlash doesn’t work try the Blisp terminal app. Option 2: Blisp Blisp is a CLI (command line interface or terminal) and needs a program like the Powershell, which is already installed on most Windows PCs. For using Blisp only a couple basic terminal commands are needed, such as cd to change directories (folders). If you prefer to use \u0026ldquo;command\u0026rdquo; terminal over Powershell, see instructions for Command in Troubleshooting and then skip to #8 here Can install newest Powershell from here. Rick click and run Powershell as administrator. Enter this command C:\\\u0026gt; Set-ExecutionPolicy RemoteSigned to enable powershell permissions. It only needs to be done one time and should persist on reboots. Check that Powershell has correct permissions,enter Get-ExecutionPolicy -list LocalMachine should be RemoteSigned. For V2, download the Blisp Flasher here. Next download the newest firmware, release here. Scroll down to the bottom of the page, under Assets, get the Pinecilv2.zip. Right click on all zip files \u0026gt; properties, and check \u0026ldquo;Unblock\u0026rdquo; if present to unblock them, then extract the Blisp zip and the Pinecilv2 zip screenshot of Unblock here. If you don’t see \u0026ldquo;Unblock\u0026rdquo; then keep going. From the Pinecilv2 folder you extracted above, copy the Pinecilv2_EN.bin (English) file into the Blisp folder (same place as the Blisp.exe). Other languages are available, substitute the Pinecil_EN.bin file for the language file desired (follow 2-letter international language code). The Pinecil Zip can now be deleted, only the single BIN file in the language you want is used. Run powershell as administrator. Now, connect the Pinecil V2 to the PC: hold down the [-] Before plugging the cable to the back of Pinecil. See (Flash Mode section for details). Screen on Pinecil should be black/empty before proceeding; it means you are in the correct Flash mode. If you are curious, it will connect as a PORT COM device in Device Manager. If your screen is not black, then repeat the connect to PC above. If necessary, change cables or ports, or try a different PC/laptop. Use cd to change to the Blisp folder (location of blisp.exe and Pinecil_EN.bin). #example change to location of blisp folder PS C:\\\u0026gt; cd G:\\Users\\name\\Downloads\\blisp\\ Execute this line (can replace the EN file name with the language bin selected). Type the .\\ (dot and slash) or it will fail to find the files! .\\blisp.exe write -c bl70x --reset .\\Pinecilv2_EN.bin After update, unplug and reboot it, then hold down [-] for ~3 seconds to see the new version. See troubleshooting down below if it does not flash. Bluetooth (BLE) Apps Must have newer Pinecil V2 model (green thumb grip). First, update firmware to Ralim’s IronOS 2.21 or higher. 2.21 is the first stable release that has BLE support built-in for Pinecil V2. Get the PineSAM app here or try Joric’s BLE website here. These BLE apps are also listed in Development projects Joric’s BLE API may be the easiest to get started with as it does not require anything to be installed. It runs off Chromium based browsers (since they are capable of BLE GATT) and shows a graph of Temperature/Watts (MacOS/iPhone and firefox don’t work bc they do not have BLE GATT). Hint: some Chromium browsers like Vivaldi, may need to check chrome://flags/ and enable bluetooth options. PineSAM is BLE Settings and Menus and will run on any major OS. It allows change of all settings, and can be controlled from Mac, Linux, Windows, iPhone, Android and more; needs python script running as back end. For easy phone connection just open a browser address http://\u0026lt;ipaddress of PC running script\u0026gt;:8080/ (see PineSAM website for details) Update V2: Linux and Mac Important Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Option 1: PineFlash PineFlash is a GUI updater that downloads firmware and flashes. Download the easy premade binary for Linux here.\nFor MacOS, currently there is a 2-step script that will build PineFlash. If you have issues with Pineflash, then use Blisp below. Option 2: Blisp Flasher This is a CLI that runs in a terminal console. Get the latest zip file for Linux or Mac. The main page has background info and there are instructions if you want to build it from code instead of using the easier premade executable.\nExtract the Blisp zip, and using a terminal, cd to the blisp folder.\nDownload the latest stable Pinecilv2.zip release (scroll down to the Assets section, get the Pinecilv2.zip).\nExtract the zip file and put Pinecilv2_EN.bin (for English) into the Blisp folder (same place as the Blisp executable). Other languages are available, substitute the *EN.bin file for the language file desired (use the 2-digit international language code). If you have the Pinecil Zip, the rest could be deleted, only the single BIN file is needed. Select the appropriate two-letter code for your language. If you accidentally flash *.dfu file on your Pinecil, it will not boot or work - be sure to only use the BIN file.\nConnect the V2 to the PC and enter Flash mode: hold down the [-] before plugging the cable to the back of Pinecil. See (Flash Mode section for details). If you are curious on Linux, it will connect as a serial ttyACM USB ACM type device.\nScreen on Pinecil should be black/empty before proceeding or you are not in Flash mode.\nBlisp must have executable permission set.\ncd to the Blisp folder and ls -l to check permissions of blisp.\nMake blisp executable: chmod +x ./blisp\nThen execute:\nsudo ./blisp write -c bl70x --reset Pinecilv2_EN.bin After a successful update, unplug and reboot it, then hold down [-] for ~2 seconds to see the new version.\nSee troubleshooting down below if it does not flash.\nTo use V2 with BLE Apps, see here.\nTroubleshoot V2 Flashing Double check that the command is typed exactly, e.g., in Windows, the dot\\slash .\\ can not be skipped in Powershell.\nFor Windows, instead of PowerShell, try the cmd.exe (right click, run as administrator) and move into the blisp folder; example commands to move to folders.\nTwo different samples work when the cmd.exe is run as administrator. First move into the folder you have both blisp.exe and Pinecil_EN.bin. Then execute one of the following:\nC:\\Users\\yourName\\Downloads\\blisp1\u0026gt;blisp.exe write -c bl70x --reset Pinecilv2_EN.bin C:\\Users\\yourName\\Downloads\\blisp1\u0026gt; .\\blisp.exe write -c bl70x --reset .\\Pinecilv2_EN.bin Often, updating issues are related to the USB cable, or the port on the PC does not support a connection to Pinecil, try:\nflipping the cable over, different cables. Try both use-C to C cables and also USB-C to USB-A cables (your cable may be power-only and not able to do firmware data transfers). All working USB-C to USB-C cables can do data transfer but some USB-A cables can only do power and will not work for firmware updates because they can not do data transfers. Try other ports on the PC/laptop, or a different machine. There have been issues with some laptop USB-C ports not negotiating correctly, but the flashing worked using the USB-A port. Try a different OS if you can access one, some people who had issues on Linux for example were able to flash on Windows. Note that some virtual environments might have an issue with flashing to USB ports. Don’t use a hub, connect directly to a port, ports on the back of a PC may sometimes be better as they are directly connected to the motherboard. Follow the Flash mode instructions and make sure the [-] button is held down BEFORE plugging in the cable to the back of the Pinecil. And don’t release for ~10 seconds.\nIf that doesn’t work try holding down the [-] the whole time (don’t let go of the button).\nBlisp flashers are from Gamiee’s open source Blisp code here. It is only an updater for the BL706 MCU on the Pinecil V2. It is separate from the firmware files needed which are in located in GitHub Ralim’s IronOS. The firmware contains all the menus, functions, and languages, and the flasher is the tool to push the firmware onto the MCU chip (the brain). Different MCU’s need different flasher tools.\nIf you have issues completing the update, try joining the live Pinecil community chat to get tips from volunteers.\nIf there was any special work-around you had to do to get the Blisp Flasher to work, or could not get it to work at all, post an Issue in Github Blisp.\nIf you are running Windows in a virtual machine and the process fails, make sure you have Microsoft Visual C++ 2015-2022 installed.\nAll firmware releases and betas are located in the GitHub Ralim’s IronOS here. If you would like to add enhancements/features to the IronOS (firmware that runs the Pinecil) or have an issue, please look at the GitHub documents or submit an issue ticket. It is recommended to read through all the GitHub IronOS documents first as they may have the answers. Screen menus and troubleshooting is documented as well on IronOS and maintained by volunteers.\nBuild the Blisp Flasher from Code If there is a problem with the Blisp flasher, or you have a different Linux architecture like ARM, the Blisp can be built from code. See directions at GitHub Blisp Wiki page. Blisp will only work on Pinecil V2 or devices with Bouffalo BL70x MCU chips and does not work for older Pinecil V1 that was sold before Aug. 1, 2022. Update V1 right\nPinecil V1 uses a *.dfu file type for firmware. The newer Pinecil V2 only uses *.bin firmware type files. Pinecil V1 models were sold until July 2022 and then discontinued. Boot logo art: the same flashers used to install IronOS firmware can be used to install the art. Boot logo art will not overwrite the firmware, it resides in a separate space on the chip. Important Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. V1 Windows or Mac Follow these instructions on GitHub and download the easy GUI updater app Pine64 Updater. Install the app, and follow the screen prompts which requires connecting the Pinecil to the PC. Connect the Pinecil to the PC by holding down the [-] before plugging the cable into the back of Pinecil. Keep holding down the [-] button for about ~10 seconds even after plugging in the cable. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. Repeat the steps if needed. If that does not work, flip the cable, try a new cable, or port or different PC, then see the Troubleshooting section. The app will automatically fetch the latest stable Ralim’s IronOS firmware, pick the language desired from the drop down list. The app also allows browsing to a local folder to install a specific beta firmware file or a boot logo that you may have downloaded or created. If multiple firmware flashing is done, the app must be closed and reopened. V1 Linux or Mac Option 1 for Linux, the simple command line DFU-Util can be used per IronOS instructions. Make sure to update to the newest DFU-Util to prevent issues that some members reported with older versions of DFU-util. Option 2 works for both Linux or Mac. Download the alternative Pineflash GUI App for Linux and Mac. Connect the Pinecil to the PC by holding down the [-] before plugging the cable into the back of Pinecil. Keep holding down the [-] button for about ~10 seconds even after plugging in the cable. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. If that does not work, flip the cable, try a new cable, or port or different PC, then see the Troubleshooting section. PineFlash app will automatically fetch the latest stable Ralim’s IronOS firmware, pick the language desired from the drop down list. Pineflash app also allows browsing to a local folder to install a specific beta firmware file or a boot logo that you may have downloaded or created. General Firmware Details Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Pinecil is designed to only use one power port at a time and never both at the same time. Get the beta and release firmware from GitHub with update instructions To submit a feature request, or help Ralim enhance the code, create a ticket or start a discussion at Ralim’s IronOS Ben (ralimtek) supports IronOS out of love for the IronOS creative open community. He volunteers countless hours coding, debugging, and enhancing IronOS with all the feature requests submitted. To give some love back, donate to IronOS; buy Ralim a coffee/kofi or donate here. One advantage of Pinecil (V1/V2) over other irons (i.e., Miniware) is you can not really brick them since Pinecil’s bootloader is in ROM. If there is a problem, just flash the firmware again or a different version. This empowers people to experiment and do forks of the main IronOS firmware without as much risk. Problems with IronOS firmware? - read documents here. If the answer is not found, open a ticket here or join the live Pinecil community chat. Boot Logo Art Dog bone by River M.\nGet Art Boot logo art is art that you custom make or download from IronOS Meta. It displays when you initially power on the Pinecil (boot up). Currently only older Pinecil V1 models which use DFU files can flash boot logo art. Download and extract all the premade Boot logo art from this pinecil.zip file here. Note that for Pinecil V1, only the images with filename \u0026ldquo;dfu\u0026rdquo; will work, you can delete all other formats from the extracted zip. Sample images of premade free art. To make custom art, follow instructions here. Some art is animated: the very small file size limit for boot logos prevents too many frames from being possible. Install If you have Windows or Mac, you can use this GUI Pine64 flasher. If you have Linux or Mac, use this GUI Pineflash. Info For Pinecil V2 model, Ralim has started work on this (reference). Please watch this ticket, give Ralim support and encouragement. This is all volunteer work. ","permalink":"/documentation/Pinecil/Firmware/","tags":null,"title":"Firmware"},{"categories":null,"contents":"BLE defines a standard service (Device Information Service, DIS) that allows BLE devices to expose information about them: hardware version, software version.\nCompanion apps will use these information to detect which firmware (or fork of a firmware) is running on the Pinetime they are connected to.\nHow to use the Device Information Service to differentiate firmwares? We’ve briefly talked about this on the community chat and this proposal is the result of this discussion. This is a request for comments.\nFields from the Device Information Service:\nField Description Example value Manufacturer name Manufacturer PINE64 Model number Name of the device \u0026ldquo;PineTime\u0026rdquo;, \u0026ldquo;P8\u0026rdquo; Serial number Not needed by companion apps as they can use the BLE MAC address ? Hardware revision Version of the hardware 1.0a Software revision Project name or fork name \u0026ldquo;InfiniTime\u0026rdquo;, \u0026ldquo;InfiniTime-forkname\u0026rdquo;, \u0026ldquo;Hypnos\u0026rdquo; Firmware revision Version of the firmware \u0026ldquo;0.7.1\u0026rdquo; ","permalink":"/documentation/PineTime/Software/Firmware_versioning_for_companion_apps/","tags":null,"title":"Firmware versioning for companion apps"},{"categories":null,"contents":" A protection foil isolates the battery for the shipping.\nWhen shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery will not charge or boot until it is removed and the battery is connected again.\nNote To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery. The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot. Devices shipped after the end of July 2022 do only accept a nano-SIM, the SIM is inserted into a carriage released by slightly pulling on the handle in the lower slot (for information regarding devices shipped prior to end of July 2022 see below).\nThe microSD belongs in the upper slot, the SIM card in the lower slot.\nNote The PinePhone Pros shipped prior to the end of July 2022 come with a micro-SIM slot instead of a nano-SIM slot. Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them! ","permalink":"/documentation/PinePhone_Pro/First_time_setup/","tags":null,"title":"First time setup"},{"categories":null,"contents":"This page explains how to flash an Ox64 board and a microSD card to boot the system. You will need a Linux computer, a serial UART adapter, the Ox64 board, and a microSD card.\nPrepare images for flashing Download the Ox64 images from the latest OpenBouffalo release. You may skip this step if you built your own images as per the instructions in the Building page.\n$ mkdir -p ~/ox64/openbouffalo $ cd ~/ox64/openbouffalo $ wget https://github.com/openbouffalo/buildroot_bouffalo/releases/download/v1.0.1/bl808-linux-pine64_ox64_full_defconfig.tar.gz $ tar -xvzf bl808-linux-pine64_ox64_full_defconfig.tar.gz $ cd ~/ox64/openbouffalo/firmware $ xz -v -d -k sdcard-pine64_ox64_full_defconfig.img.xz $ mv sdcard-pine64_ox64_full_defconfig.img sdcard.img Optional: create a combined SoC image Use the following commands to combine m0_lowload_bl808_m0.bin, d0_lowload_bl808_d0.bin, and bl808-firmware.bin into a single image. This is mainly useful for troubleshooting (e. g. when using DevCube v1.8.4 or later).\n$ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images $ fallocate -l 0x800000 bl808-combined.bin $ dd conv=notrunc if=m0_lowload_bl808_m0.bin of=bl808-combined.bin $ dd conv=notrunc if=d0_lowload_bl808_d0.bin of=bl808-combined.bin seek=$((0x100000))B $ cat bl808-firmware.bin \u0026gt;\u0026gt; bl808-combined.bin Check that you have the required files for flashing $ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images $ ls -1 *808*.bin *.img Expected files:\nbl808-combined.bin \u0026ndash; If you created the combined image. bl808-firmware.bin \u0026ndash; OpenSBI and UBoot DTB files. Runs on the D0 core. d0_lowload_bl808_d0.bin \u0026ndash; Startup code for the D0 core. m0_lowload_bl808_m0.bin \u0026ndash; Startup code for the M0 core. sdcard.img \u0026ndash; Kernel and root filesystem. Runs on the D0 core. Set up your UART adapter In this section we will configure and wire up a UART adapter in order to flash the Ox64. Choose one of the options below based on the hardware available to you; the first two are the most convenient since they minimize the number of times you will need to swap electrical connections.\nOption 1: Raspberry Pi Pico First, download the Raspberry Pi Pico firmware that allows it to act as a serial UART adapter:\n$ mkdir -p ~/ox64/pico $ cd ~/ox64/pico $ wget https://github.com/Kris-Sekula/Pine64_Ox64_SBC/raw/main/uart/picoprobe.uf2 Put the Raspberry Pi Pico board into programming mode:\nPress the BootSel button Apply power by plugging the USB cable to PC Release the BootSel button Note As an alternative to pressing the BootSel button, you can also connect the probe point TP6 (located on the bottom of the Pico board) to any ground point (e. g. pin 28). The Pico will now appear as a USB mass storage device. Copy the UF2 file to program it:\n$ cp ~/ox64/pico/picoprobe.uf2 /media/\u0026lt;user\u0026gt;/RPI-RP2 Next, connect the Ox64 board to the Pico according to the following wiring diagram:\nOx64 PI PICO /dev/tty uart0_Tx_GPIO14_pin1 uart0_Rx_pin17 ACM1 for flashing uart0_Rx_GPIO15_pin2 uart0_Tx_pin16 ACM1 for flashing Rxd_GPIO17_pin31 uart1_Tx_pin6 ACM0 for serial console Txd_GPIO16_pin32 uart1_Rx_pin7 ACM0 for serial console gnd_pin38 gnd_pin38/3 vbus5v_pin40 vbus5v_pin40 With the Pico flashed and wired as per the instructions above, we have access to two of the Ox64’s UART ports at the same time. This configuration eliminates the need to switch the physical connections for flashing or testing the system.\nReconnect the Pico to your computer’s USB port and verify that we have access to all the serial ports we need:\n$ ls /dev/ttyACM* Expected result:\n/dev/ttyACM0 connects to the D0 core’s (i.e. Linux’s) serial console /dev/ttyACM1 is used for flashing (but also connects to the M0 core’s serial console) Option 2: STM32 Bluepill The Bluepill is an affordable STM32 development board, based on the STM32F103C8T6 chip. We can program it to act as a USB serial adapter, just like we did with the Raspberry Pi Pico.\nNote The one catch is that you already need a serial adapter in order to program your Bluepill board. The good news is that you serial adapter does not have to be one from from the Compatible UARTs list. These programming instructions have been tested with a FT232RL adapter (which, notably, is listed as not supported on that list).\nIf you own an SWD-capable debugger (ST-Link, J-link, etc.) you can use that for programming the Bluepill as well, although instead of stm32flash console command you would be using openocd or other suitable software.\nWarning Your serial adapter must use 3.3V logic levels. Install software to flash Bluepill. For Debian-based systems just install package from repository:\n$ sudo apt install stm32flash For Arch Linux systems, use the AUR repository:\n$ mkdir -p ~/ox64/bluepill $ cd ~/ox64/bluepill $ git clone https://aur.archlinux.org/stm32flash.git $ cd ~/ox64/bluepill/stm32flash $ makepkg -si Download the Bluepill Serial Monster firmware:\n$ mkdir -p ~/ox64/bluepill $ cd ~/ox64/bluepill $ wget https://github.com/r2axz/bluepill-serial-monster/releases/download/v2.6.4/bluepill-serial-monster.hex Put the Bluepill into programming mode:\nSet boot jumpers for booting from rom: Boot0=1, Boot1=0. Connect it to a USB-Serial adapter with A9 to Rx, A10 to Tx, GND to GND, 3v3 to Vcc. Apply power by plugging the USB cable to PC. Press the Reset button. Find your USB serial adapter’s device path with ls /dev/ttyUSB* /dev/ttyACM* (or similar); for the rest of this section we will refer to it as /dev/tty[DEVICE]. Upload the firmware:\n$ cd ~/ox64/bluepill $ sudo stm32flash -w bluepill-serial-monster.hex /dev/tty[DEVICE] After upload, set boot jumpers for boot from flash: Boot0=0, Boot1=0. Disconnect the USB serial adapter from both the PC and Bluepill board.\nNext, connect the Ox64 board to the Bluepill according to the following wiring diagram:\nOx64 Bluepill /dev/tty uart0_Tx_GPIO14_pin1 uart0_Rx_A3 ACM1 for flashing uart0_Rx_GPIO15_pin2 uart0_Tx_A2 ACM1 for flashing Rxd_GPIO17_pin31 uart1_Tx_A9 ACM0 for serial console Txd_GPIO16_pin32 uart1_Rx_A10 ACM0 for serial console gnd_pin38 GND vbus5v_pin40 5V With the Bluepill flashed and wired as per the instructions above, we have access to two of the Ox64’s UART connections at the same time. This configuration eliminates the need to switch the physical connections for flashing or testing the system.\nConnect the Bluepill to your computer’s USB port and verify that we have access to all the serial ports we need:\n$ ls /dev/ttyACM* Expected result:\n/dev/ttyACM0 connects to the D0 core’s (i.e. Linux’s) serial console /dev/ttyACM1 is used for flashing (but also connects to the M0 core’s serial console) /dev/ttyACM2 (unused) Option 3: Generic UART adapter Ox64 pinout\nCheck that your serial adapter is on the Compatible UARTs list. You will (most likely) only have one serial interface available to you; unlike the previous options you will be using this same serial interface for both flashing and testing the system.\nFind its device path with ls /dev/ttyUSB* /dev/ttyACM* (or similar); for the rest of this section we will refer to it as /dev/tty[DEVICE].\nYou will also need a way of powering your Ox64. If your serial adapter has a 5V line, you can connect it to VBUS (pin 40). Otherwise, you can connect either the micro-B or the USB-C port on the Ox64 to any 5V power supply.\nWarning Your serial adapter must use 3.3V logic levels. Refer to the pinout image below. Connect your UART adapter as follows:\nRX -\u0026gt; UART0_TX / GPIO14 / pin 1 TX -\u0026gt; UART0_RX / GPIO15 / pin 2 GND -\u0026gt; any ground (e. g. pin 3) Proceed with the instructions in the sections that follow, up to and including flashing_the_ox64 and flashing_the_microsd_card, but replace all occurrences of /dev/ttyACM1 with /dev/tty[DEVICE].\nNext, power off the Ox64 and re-connect your UART adapter as follows:\nRX -\u0026gt; TXD / GPIO16 / pin 32 TX -\u0026gt; RXD / GPIO17 / pin 31 GND -\u0026gt; any ground (e. g. pin 33) Then, follow the instructions in booting_for_the_first_time, but replace all occurrences of /dev/ttyACM0 with /dev/tty[DEVICE]. You should then have a working Linux system.\nDownload flashing tools You have a choice of flashing software:\nDevCube: Bouffalo\u0026rsquo;s GUI-based closed source flashing tool bflb-iot-tool: Bouffalo\u0026rsquo;s command line open source flashing tool Blisp: Third party command line open source flashing tool Installation: DevCube Download the latest DevCube flashing tool from BouffaloLab’s website:\n$ mkdir -p ~/ox64/devcube $ cd ~/ox64/devcube $ wget https://dev.bouffalolab.com/media/upload/download/BouffaloLabDevCube-v1.8.9.zip $ unzip BouffaloLabDevCube-v1.8.9.zip $ chmod u+x BLDevCube-ubuntu If you did not create a combined image you may need an older version of the DevCube. In that case, download v1.8.3 from one of the mirrors below:\nhttps://openbouffalo.org/static-assets/bldevcube/BouffaloLabDevCube-v1.8.3.zip https://hachyderm.io/@mkroman/110787218805897192 \u0026gt; https://pub.rwx.im/~mk/bouffalolab/BouffaloLabDevCube-v1.8.3.zip https://we.tl/t-eJWShQJ4iF Verify that your copy of BouffaloLabDevCube-v1.8.3.zip matches the hashes below:\nSHA1: 0f2619e87d946f936f63ae97b0efd674357b1166 SHA256: e6e6db316359da40d29971a1889d41c9e97d5b1ff1a8636e9e6960b6ff960913 Installation: bflb-iot-tool Install bflb-iot-tool using your preferred method of managing PIP packages. One option is to set up a Python virtual environment as follows:\n$ sudo apt install pipenv # for Debian-based systems # or $ sudo pacman -S python-pipenv # for Arch Linux systems $ cd ~/ox64/ $ pipenv install setuptools # install prerequisite of CLI flash tool $ pipenv install bflb-iot-tool # install CLI flash tool $ pipenv shell # activate virtual environment $ # bflb-iot-tool --help # return info about the tool Note Each time you open a new terminal window you will need to cd ~/ox64/ and re-run pipenv shell to reactivate the virtual environment. Installation: Blisp At the time of writing, only the development version of Blisp supports flashing the Ox64. You can compile it from source as follows:\n$ sudo apt install cmake # for Debian-based systems # or $ sudo pacman -S cmake # for Arch Linux systems $ cd ~/ox64 $ git clone --recursive https://github.com/pine64/blisp.git $ cd blisp $ git submodule update --init --recursive $ mkdir build \u0026amp;\u0026amp; cd build $ cmake -DBLISP_BUILD_CLI=ON .. $ cmake --build . $ export PATH=$HOME/ox64/blisp/build/tools/blisp:$PATH Note Each time you open a new terminal window you will need to re-run the export PATH=... command above to ensure that the blisp executable remains in your PATH. Full instructions are available in Blisp\u0026rsquo;s README.\nFlashing the Ox64 Put the Ox64 into programming mode:\nPress the BOOT button Apply power or re-plug the USB cable Release the BOOT button If you are using any of the command line flashing utilities (i.e. blisp or bflb-iot-tool), set up the following environment variables:\n$ PORT=/dev/ttyACM1 $ BAUD=230400 # safe value for macOS, set to 2000000 for faster flashing on Linux And change directory to the location of your firmware images:\n$ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images Flashing method: bflb-iot-tool Flash the Ox64. If you created a combined image then run the command below:\n$ bflb-iot-tool --chipname bl808 --interface uart --port $PORT --baudrate $BAUD \\ \u0026gt; --addr 0x0 --firmware bl808-combined.bin --single Otherwise, run the following commands:\n$ bflb-iot-tool --chipname bl808 --interface uart --port $PORT --baudrate $BAUD \\ \u0026gt; --addr 0x0 --firmware m0_lowload_bl808_m0.bin --single $ bflb-iot-tool --chipname bl808 --interface uart --port $PORT --baudrate $BAUD \\ \u0026gt; --addr 0x100000 --firmware d0_lowload_bl808_d0.bin --single $ bflb-iot-tool --chipname bl808 --interface uart --port $PORT --baudrate $BAUD \\ \u0026gt; --addr 0x800000 --firmware bl808-firmware.bin --single If you get permission errors when running any of the commands above, run ls -l /dev/tty[DEVICE], to find out which group is allowed to talk to serial ports and add your user to that group, with sudo usermod -a -G [GROUP] $USER (i.e. dialout for Debian or uucp for Arch Linux). Make sure you re-login. Running the commands as root is not recommended since this will make bflb-iot-tool create root-owned files in your home directory. You can now run exit from virtual environment.\nFlashing method: Blisp Flash the Ox64. If you created a combined image then run the command below:\n$ blisp iot --chip=bl808 --port=$PORT --baudrate=$BAUD \\ \u0026gt; --single-down-loc 0x0 --single-down bl808-combined.bin Otherwise, run the following commands:\n$ blisp iot --chip=bl808 --port=$PORT --baudrate=$BAUD \\ \u0026gt; --single-down-loc 0x0 --single-down m0_lowload_bl808_m0.bin $ blisp iot --chip=bl808 --port=$PORT --baudrate=$BAUD \\ \u0026gt; --single-down-loc 0x100000 --single-down d0_lowload_bl808_d0.bin $ blisp iot --chip=bl808 --port=$PORT --baudrate=$BAUD \\ \u0026gt; --single-down-loc 0x800000 --single-down bl808-firmware.bin Flashing method: DevCube Open a new terminal window to run the DevCube flasher:\n$ cd ~/ox64/devcube $ ./BLDevCube-ubuntu Select chip [BL808], press Finish, and configure BOTH the [MCU] and [IOT] tabs as follows. When you switch between tabs double check that they still match the settings below:\nInterface UART Port/SN /dev/ttyACM1 UART rate 230400 (safe value for macOS, set to 2000000 for faster flashing on Linux) If you created a combined image then you only need to use the [IOT] tab:\nEnable \u0026lsquo;Single Download\u0026rsquo; Image Address [0x0], [PATH to bl808-combined.bin] Click \u0026lsquo;Create \u0026amp; Download\u0026rsquo; and wait until it’s done Close DevCube Otherwise, start in the [MCU] tab:\nM0 Group[group0], Image Address [0x58000000], [PATH to m0_lowload_bl808_m0.bin] D0 Group[group0], Image Address [0x58100000], [PATH to d0_lowload_bl808_d0.bin] Click \u0026lsquo;Create \u0026amp; Download\u0026rsquo; and wait until it’s done Then, switch to the [IOT] tab:\nEnable \u0026lsquo;Single Download\u0026rsquo; Image Address [0x800000], [PATH to bl808-firmware.bin] Click \u0026lsquo;Create \u0026amp; Download\u0026rsquo; again and wait until it’s done Close DevCube Erasing the microSD card Make sure there are no signatures or partitions left, and overwrite the first sectors with zeroes. You can find the target device under lsblk command.\n$ sudo wipefs /dev/[DEVICE] $ sudo wipefs --all --force /dev/[DEVICE]* $ sudo dd if=/dev/zero of=/dev/[DEVICE] status=progress bs=32768 count=1 Optionally you can zeroes the whole device:\n$ sudo dd if=/dev/zero of=/dev/[DEVICE] status=progress bs=32768 count=$(expr $(lsblk -bno SIZE /dev/[DEVICE] | head -1) \\/ 32768) Flashing the microSD card Insert the microSD card into your PC, locate its device under lsblk and write the image:\n$ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images $ sudo dd if=sdcard.img of=/dev/[DEVICE] bs=1M status=progress conv=fsync Booting for the first time Power off your Ox64 and insert the microSD card.\nOpen a terminal window to connect to the D0 core’s (i.e. Linux’s) serial console:\n$ minicom -b 2000000 -D /dev/ttyACM0 If you are using a Pico or Bluepill as your serial adapter, open another terminal window to to monitor the M0 core’s serial console (reminder: /dev/ttyACM1 is the same port we previously used for flashing):\n$ minicom -b 2000000 -D /dev/ttyACM1 Re-apply power to the Ox64.\nOn the main/D0 console (/dev/ttyACM0) you will see Linux booting up. When prompted, log in as root with no password. In case the SD card is missing or empty, you’ll get a Card did not respond to voltage select! : -110 error.\nOn the M0 console (/dev/ttyACM1) you’ll see following messages until the sytem is fully loaded:\n[I][MBOX] Mailbox IRQ Stats: [I][MBOX] Peripheral SDH (33): 0 [I][MBOX] Peripheral GPIO (60): 0 [I][MBOX] Unhandled Interupts: 0 Unhandled Signals 0 Once the system is running, the \u0026ldquo;MBOX\u0026rdquo; logs will abruptly disappear and you’ll be able to manage the M0 multimedia core, i.e. wifi settings, etc. When prompted, type help to see available commands.\nConnecting the Ox64 to your WiFi network The simplest way to connect is to run the following command from the Linux console (i.e. /dev/ttyACM0):\n$ blctl connect_ap \u0026lt;YourSSID\u0026gt; \u0026lt;YourPassword\u0026gt; Wait for it to connect (if you’re monitoring the M0 console on /dev/ttyACM1 it should tell you when it’s done), then run the following command from the Linux console:\n$ udhcpc -i bleth0 Unfortunately the WiFi range leaves something to be desired. When you are performing the procedure above for the first time, move the Ox64 right next to your router. Once you are successfully connected, you can try experimenting with the maximum range.\nFor more information on using the blctl command, see here.\nAppendix Adding Nuttx RTOS In this section, we will set up our Ox64 to dual-boot both Linux and the NuttX real-time operating system. For more information see the official documentation.\nFirst, write the normal Linux image to the SD card if you have not done so already. You can find the correct device under lsblk:\n$ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images $ sudo dd if=/sdcard.img of=/dev/[DEVICE] bs=1M conv=fsync status=progress Run the following command to re-read the partition tables. Re-inserting the SD card works too:\n$ sudo blockdev --rereadpt /dev/[DEVICE] Download the NuttX image:\n$ mkdir -p ~/ox64/nuttx $ cd ~/ox64/nuttx $ wget -O ImageNuttx https://github.com/lupyuen2/wip-pinephone-nuttx/releases/download/bl808d-1/Image Mount the boot partition and make the required modifications:\n$ sudo mount /dev/[DEVICE]2 /mnt $ sudo cp ImageNuttx /mnt/ $ sudo tee -a /mnt/extlinux/extlinux.conf \u0026lt;\u0026lt;EOF LABEL PINE64 OX64 Nuttx KERNEL ../ImageNuttx FDT ../bl808-pine64-ox64.dtb EOF $ sudo umount /mnt Mount the rootfs and make the required modifications:\n$ sudo mount /dev/[DEVICE]3 /mnt $ sudo cp ImageNuttx /mnt/boot/ $ sudo tee -a /mnt/boot/extlinux/extlinux.conf \u0026lt;\u0026lt;EOF LABEL PINE64 OX64 Nuttx KERNEL ../ImageNuttx FDT ../bl808-pine64-ox64.dtb EOF $ sudo umount /mnt Enjoy your new Nuttx booting option!\n","permalink":"/documentation/Ox64/Software/Flashing/","tags":null,"title":"Flashing"},{"categories":null,"contents":" Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. Note These instructions are directed towards experienced developers only! This page contains information on flashing software to the PineNote.\nThe general process is as follows:\nTake a backup of all important data on the PineNote Modify the partition layout to make space for your desired Linux distribution Instantiate a root filesystem (rootfs) in the new partition space Install your Linux distribution to the boot partition Modify the boot process to boot the Linux distribution by default There are multiple possible methods of executing these steps, and this page attempts to document all of them.\nYou can use:\nrkdeveloptool, a command line utility for modifying Rockchip devices over USB The UART shell Android Debug Bridge Fastboot Getting rkdeveloptool Most flashing operations on the PineNote are done through rkdeveloptool, a command line utility built on libusb. PINE64 maintains its own fork here that you will need to get. The repo’s README contains a list of dependencies (libusb 1.0) and instructions for building the tool.\nInstalling (not just building) rkdeveloptool will configure PAM to elevate privileges where necessary on your system; you can configure this manually as follows:\nsudo cp 99-rk-rockusb.rules /etc/udev/rules.d/ sudo udevadm control --reload Entering Maskrom/Rockusb mode Interfacing with the PineNote over USB using rkdeveloptool requires first booting the PineNote into an alternative operating mode called Maskrom or Rockusb mode.\nPossible methods There are three possible methods of entering Maskrom/Rockusb mode:\nHardware magnet switch Developer Edition Connect the PineNote to your computer via USB and boot the PineNote into Android Locate \u0026amp; identify the small circular marking on the back of the PineNote, in the top right quadrant; have the PineNote pen close at hand, or any other small magnet Hold the PineNote power button to bring up the reboot/shutdown menu; select reboot, then place the PineNote face down with the \u0026ldquo;eraser\u0026rdquo; end of the pen (or your magnet) resting on the small circular marking Community Edition The community edition is shipped with Debian and a passive pen without a magnet, therefore you will need to source your own magnet.\nMake sure you have flashed the new U-Boot image after receiving your community edition PineNote. You can do this if you haven\u0026rsquo;t already by running:\n$ cd /root/uboot ... $ bash install_stable_1056mhz_uboot.sh Power off the PineNote from the Gnome quick settings menu in the top right.\nPlace the PineNote display side facing down and place the magnet on the small circle in the top right quadrant of the device.\nPlug the PineNote into your computer (you do not need to press the power button).\nU-Boot terminal Stock UART dongle The stock UART dongle does not support regular USB functions while plugged in. It must be removed after entering maskrom so the host can communicate with the device in maskrom mode.\nConnect to the PineNote via UART and USB simultaneously Interrupt the U-Boot startup using ctrl+c sent over UART In the U-Boot terminal over UART, run rockusb 0 mmc 0. The UART terminal should print RKUSB and display a spinner. Remove the UART dongle and connect directly to the PineNote. rkdeveloptool list should now list the PineNote. Non-stock UART dongle with passthrough This method requires a UART dongle with passthrough allowing simultaneous UART \u0026amp; USB connections.\nIt is nice because you can easily switch back \u0026amp; forth between U-Boot and Rockusb without having to physically manipulate the PineNote or its connectors; this is especially helpful when trying to develop U-Boot.\nConnect to the PineNote via UART and USB simultaneously Interrupt the U-Boot startup using ctrl+c sent over UART In the U-Boot terminal over UART, run rockusb 0 mmc 0 The UART terminal should print RKUSB then a spinner will appear. You can exit back to the U-Boot terminal by sending ctrl+c again.\nShorting test points If the bootloader is broken/corrupted, you cannot get to Maskrom without opening up the device (it can be opened using spudger and a bit of patience).\nOnce inside, short TP1301 (GND) and TP1302 (eMMC_D0/FLASH_D0) with a small tweezers, this is how it looks on board view (credit to Caleb):\nSuccess No matter what approach you take, you can tell whether you succeeded by running the lsusb command on your computer:\nIf you find the entry 2207:0018 Fuzhou Rockchip Electronics Company rk3566_eink in the list, the process did not succeed; reboot and retry The entry 2207:350a Fuzhou Rockchip Electronics Company will occur if you detach then reattach the USB-C cable while the PineNote is in Maskrom/Rockusb mode; rkdeveloptool won’t work and you will have to do a hard reboot (hold down power button for 30 seconds to shutdown) If you find the entry 2207:350a Fuzhou Rockchip Electronics Company USB download gadget then the process succeeded You can also look at the output of the rkdeveloptool list command:\nIf this prints out No devices in rockusb mode found the process did not succeed; reboot and retry If this prints out DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=305 Maskrom then you probably detached/reattached the USB-C cable while in Maskrom/Rockusb mode and rkdeveloptool won’t work; perform a hard reboot to fix If this prints out DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=303 Loader then the process succeeded Exiting You can boot the PineNote back into its normal mode of operation by powercycling the PineNote with its hardware power switch, or running the rkdeveloptool reboot command. If you used the magnetic switch method be sure to remove the pen/magnet before rebooting.\nBackup A backup of the content of the internal eMMC before anything gets messed up is mandatory.\nEspecially the waveform partition contains data unique to your PineNote and is a prime candidate for backup.\nOther partitions like U-Boot (need for any operation of the device) or the un-partitioned space at the beginning containing the GPT partition table (and presumably the VCOM setting for the e-ink display and maybe device mac addresses) contain data you may also wish to backup.\nDepending of your personal level of data hoarder you may want to backup more than this or even just everything (the large userdata partition is supposed to be able to be repopulated as empty space by Android)\nIn any case it is easier to restore/extract data from a backup than not having one if you need one.\nThis process was developed by Dorian Rudolph, originally described here.\nList partitions First, run rkdeveloptool list-partitions to print out your PineNote’s partitions to get an idea of what you’re dealing with.\nCommunity Edition Stock partition layout of the Community Edition:\nNumber Name Size Purpose 0 uboot 64 MB The U-Boot embedded systems bootloader 1 waveform 2 MB Important files controlling the e-ink screen’s state changes 2 uboot_env 1 MB U-Boot environment partition 3 logo 64 MB Splash image displayed during boot 4 os1 14.65 GB Default OS slot where Debian is stored 5 os2 14.65 GB An alternative operating system can be flashed here such as PostmarketOS or Arch Linux 6 data 85.82 GB /home partition for user files Developer Edition The stock Developer Edition has a fairly standard Android partition setup:\nNumber Name Size Purpose 0 uboot 4 MB The U-Boot embedded systems bootloader 1 trust 4 MB Secrets that can be encrypted with a key stored in the TPM 2 waveform 2 MB Important files controlling the e-ink screen’s state changes 3 misc 4 MB Data used by the recovery partition 4 dtbo 4 MB Device Tree Blob for Overlay, files describing the PineNote’s hardware configuration 5 vbmeta 1 MB Data required for verified boot 6 boot 42 MB The kernel image \u0026amp; ramdisk to boot 7 security 4 MB 8 recovery 134 MB The recovery image, booted during Android updates 9 backup 400 MB 10 cache 1 GB Stores temporary data; can be used to install a minimal Linux distribution! 11 metadata 17 MB Used for disk encryption 12 super 3.25 GB Android itself is installed here 13 logo 17 MB Splash image displayed during boot 14 device 67 MB 15 userdata 119 GB The big one; user-installed Android apps and files live here Patch U-Boot Note This applies only to Developer Edition. Community Edition devices are shipped with fixed U-Boot. Do not flash the uboot_patched.img if the output of rkdeveloptool list-partitions doesn\u0026rsquo;t match Developer Edition above. Before we can back up our partitions, we have a problem to solve. The version of U-Boot installed on the stock PineNote contains a bug where it can’t dump partitions beyond 32 MB (above that limit all bytes in the dump are just 0xCC), meaning the PineNote must be flashed with a fixed version of U-Boot before it is possible to take a backup of the larger partitions. It is possible to extract and modify the U-Boot image from your PineNote if you’re interested in some light reverse-engineering (following Dorian’s notes), or you can simply download a patched U-Boot image directly here.\nOnce you’ve acquired a patched U-Boot image, run:\nrkdeveloptool read-partition uboot uboot_backup.img rkdeveloptool write-partition uboot uboot_patched.img rkdeveloptool reboot Taking the backup With U-Boot patched, you can back up every partition except for super and userdata; run:\nrkdeveloptool read-partition partition_name partition_name_backup.img\nUnfortunately the super and userdata partitions run into a second limitation preventing dumping partitions larger than 2 GB, this time originating in rkdeveloptool itself. This means if you have a large number of documents in the Android userdata partition they might not all make it into the backup. If you don’t have many documents (or don’t care about losing them) this should not be a problem. If you do have a lot of documents, workarounds include:\nA possible patch written by Thomas exists here but has not yet been upstreamed; consider investigating how to get the patch tested \u0026amp; upstreamed, or just apply it to your own local copy of rkdeveloptool Use this Python script written by Visti Andresen (talpadk) to automatically backup your entire partition by splitting reads into 2 GB chunks See instructions on this artifact. It will instruct you on extracting the rootfs into an empty ext4 partition. This can be done from Linux or Android. Further instructions on building your own rootfs can be found here.\nUsing a user installed Linux A Linux installed to the cache partition should be able to easily backup everything over WiFi or to a USB stick/disk using dd.\nHowever the user would need to backup the cache partition (if they want that).\nAnd more importantly they would only be getting the backup after they started playing with the content of the eMMC.\nSide-by-side setup It is possible to set up a partition for mainline development without disturbing the factory Android installation. This allows updating a mainline kernel, DTB, and initramfs over Wi-Fi until WiFi or USB OTG is working in mainline Linux.\nWithout Repartitioning The recommended partition for this is mmcblk0p11 aka /cache. It is large and already formatted as ext4, so it is readable from U-Boot. Here are some general steps:\nFrom the UART or adb shell, set up your chroot in /cache. I used the Alpine Linux rootfs tarball. Copy in your kernel and DTB, using for example scp or wget inside the chroot. Finally, create and boot an extlinux.conf as described below. With Repartitioning It is possible to shrink the userdata partition, and create a new partition at the end for use with mainline Linux. This provides much more space than cache. However, because userdata is formatted with f2fs, and that filesystem cannot be shrunk, resizing the partition requires wiping userdata.\nBack up any necessary files from userdata Boot to a mainline kernel from mmcblk0p11, either using that partition as rootfs (see above), or using an initramfs with repartitioning tools Modify the partition table with your favorite tool, e.g. fdisk, gdisk, or parted Reboot into fastboot and wipe userdata. Reboot into Android, where you can now chroot in and install your favorite distribution to the new partition. Using rkdeveloptool Building Downstream U-Boot While in maskrom mode, we need to have a u-boot to download onto the device for any of the other commands to work. To build you’ll also need to install device-tree-compiler.\nYou also need to install Python and pyelftools.\nNote The rkbin is a \u0026gt;5GB download! This will take some time to clone and process the deltas. git clone -b quartz64 https://gitlab.com/pgwipeout/u-boot-rockchip.git git clone -b rkbin https://github.com/JeffyCN/rockchip_mirrors.git rkbin cd u-boot-rockchip # If using Arch Linux, export CROSS_COMPILE=aarch64-linux-gnu- export CROSS_COMPILE=aarch64-none-linux-gnu- make rk3566-quartz64_defconfig ./make.sh In the current version (current as of 2022-01-02), there might have to be made a change to one line to get a clean compilation:\ndiff --git a/lib/avb/libavb/avb_slot_verify.c b/lib/avb/libavb/avb_slot_verify.c index 123701fc3b..64a1ce6450 100644 --- a/lib/avb/libavb/avb_slot_verify.c +++ b/lib/avb/libavb/avb_slot_verify.c @@ -296,7 +296,7 @@ static AvbSlotVerifyResult load_and_verify_hash_partition( bool image_preloaded = false; uint8_t* digest; size_t digest_len; - const char* found; + const char* found = NULL; uint64_t image_size; size_t expected_digest_len = 0; uint8_t expected_digest_buf[AVB_SHA512_DIGEST_SIZE]; For systems where the global python executable points to python2, compilation fails with an error related to pyelftools not being installed (even if it is). To fix this:\ndiff --git a/make.sh b/make.sh index 2bba05b4e4..cfe5b0afd5 100755 --- a/make.sh +++ b/make.sh @@ -758,7 +758,7 @@ function pack_fit_image() fi if [ \u0026#34;${ARM64_TRUSTZONE}\u0026#34; == \u0026#34;y\u0026#34; ]; then - if ! python -c \u0026#34;import elftools\u0026#34; ; then + if ! python3 -c \u0026#34;import elftools\u0026#34; ; then echo \u0026#34;ERROR: No python \u0026#39;pyelftools\u0026#39;, please: pip install pyelftools\u0026#34; exit 1 fi You can now download u-boot onto the PineNote:\n./rkdeveloptool boot ../u-boot-rockchip/rk356x_spl_loader_v1.08.111.bin This should output \u0026ldquo;Downloading bootloader succeeded\u0026rdquo;.\nWe can now verify that this worked using e.g. the \u0026ldquo;read flash info\u0026rdquo; command:\n./rkdeveloptool read-flash-info Note Section needs to be finished Creating a mainline boot image You can create a filesystem image that replaces the Android boot or recovery partition by doing roughly the following:\nErase boot and dtbo with rkdeveloptool or fastboot (back them up first!!!) Create an ext2 partition image and mount it (fallocate, mkfs.ext2) Build your mainline kernel Copy the kernel, dtb and an initramfs to the root of the mounted image (use any old postmarketOS initramfs) Create a file in the root of the mounted image called extlinux.conf as described below Unmount the image and then use rkdeveloptool to flash it to the \u0026ldquo;recovery\u0026rdquo; partition on the pinenote (it’s about the right size until we get around to replacing the partition layout). Using fastboot Follow the steps for Creating a mainline boot image, but instead of flashing it with rkdeveloptool, use fastboot. You can enter fastboot in either of two ways:\nUse \u0026ldquo;reboot bootloader\u0026rdquo; from adb or a UART console or get a U-Boot prompt and run fastboot usb 0. ","permalink":"/documentation/PineNote/Development/Flashing/","tags":null,"title":"Flashing"},{"categories":null,"contents":"What is the Performance of the PineTab2 compared to the PineTab-V?\nThe PineTab2 is notably faster than the PineTab-V. You can see this by comparing the Quartz64 sbc-bench results to the Star64 ones. Performance should not be a factor of consideration when purchasing a PineTab-V.\n","permalink":"/documentation/PineTab-V/Frequently_asked_questions/","tags":null,"title":"Frequently asked questions"},{"categories":null,"contents":" Do I Need A Fan/What Heatsink Do I Need? You don’t need a fan. The 20mm medium heatsink for Model A is plenty enough. For Model B, the fan type heatsink will do fine.\nCan This Run A Minecraft Server? Yes! Sort of. Testing on an 8GB Model A with PaperMC, User:CounterPillow was able to out-row world generation in a boat with just one player online, but aside from the slow world gen (which can be pre-generated) the server handled things like TNT explosions and mobs fine. It’ll probably do okay with 1-3 players.\nDo I Need The 5A Power Supply For Model A? You only need the 5A power supply for Model A if you plan on connecting hard disk drives to the 12V header on the board.\nHow Much Power Does It Consume? For Model B, it’s \u0026lt;2W in idle (powertop tunables not set), and \u0026lt;5W under full CPU load (stress-ng -c4). Model A will be similar as it’s the same SoC.\n","permalink":"/documentation/Quartz64/Frequently_Asked_Questions/","tags":null,"title":"Frequently Asked Questions"},{"categories":null,"contents":"The gateway will be available in two variants - indoor and outdoor. All that is known about the outdoor unit is that it will have \u0026ldquo;an aluminum, rugged and water resistant case\u0026rdquo;. The indoor unit consists of a PINE A64-LTS, fitted with a purpose built hat (adapter) which uses a LoRa module by RakWireless. The chipset used is the SX1303, and the module via the SPI interface. There are two external connections on the enclosure for the GPS and loRa antenna.\nConnections GPS is connected to UART2 on the A64 board SX1303 on SPI0 RAK5146 module PI-2 connector PINE A64-LTS SX1303 SPI Pin 19 = MOSI / PC0\nPin 21 = MISO/PC1\nPin23 = CLK/PC2\nPin24 = CS/PC3 SPI0 (/dev/spidev0.0) SX1303 RESET Pin 11 = GPIO17/PC7 GPIO71 (/sys/class/gpio/gpio71) GPS UART Pin 8 = TX/\nPin 10 = RX UART2 (/dev/ttyS2) GPS RESET Pin 33 = GPIO13/PC5 GPIO69 (/sys/class/gpio/gpio69) GPS Standby Pin 35 = GPIO19/PC9 GPIO73 (/sys/class/gpio/gpio73) Pictures Operating systems The Pinedio Gateway carries the A64-LTS board. The SOPINE releases are also compatible based on the RAM specifications.\n","permalink":"/documentation/Pinedio/Gateway/","tags":null,"title":"Gateway"},{"categories":null,"contents":" Android SDK for RK3566\nCross-compiling\nGeneral (Single Page)\nMainline Hardware Decoding\nMainline Hardware Encoding\nMali Driver\nOverclocking\nPineModems\nRK3399 boot sequence\nRK3566 EBC Reverse-Engineering\nU-Boot\nAndroid SDK for RK3566 Two Android SDKs are available from Pine64 for RK3566 devices:\nQUARTZ64_SDK_android11 Android 11 SDK For Quartz64 model A SBC and SOQuartz\nDirect Download from pine64.org MD5 (TAR-GZip file): 77c2ff57ea3372fb04da7fb49e17d12b File Size: 79.00GB Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz Android build version: QUARTZ64-model-A_eink.android11_SDK Android 11 eink SDK For PineNote and Quart64 model A SBC\nDirect Download from pine64.org MD5 (TAR-GZip file): 293a550584298de4fb95ceae18103672 File Size: 72.88GB Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz Android build version: Compiling Build machine 64 bit Linux (Manjaro tested) At least 16G RAM At least 250G free storage, preferably SSD based Use a POSIX compliant shell such as bash, not zsh (in Manjaro \u0026ldquo;chsh -s /bin/bash username\u0026rdquo;) Manjaro packages The following packages are needed (install with \u0026ldquo;sudo pacman -S packagename\u0026rdquo;):-\nmake gcc python-pip dtc bison flex cpio unzip zip Once this is done run\npip install pyelftools sudo isn’t needed You will also need libncurses.so.5. The easiest way to install this appears to be using an Arch AUR package.\nEnable AUR pamac install ncurses5-compat-libs don’t use sudo Patches QUARTZ64-model-A_eink.android11_SDK For QUARTZ64-model-A_eink.android11_SDK the following files will need to be updated:-\nrk3566_ebook/u-boot/arch/arm/mach-rockchip/decode_bl31.py rk3566_ebook/u-boot/arch/arm/dts/Makefile rk3566_ebook/u-boot/scripts/dtc/dtc-lexer.l rk3566_ebook/u-boot/scripts/dtc/dtc-lexer.lex.c rk3566_ebook/u-boot/scripts/dtc/dtc-lexer.lex.c_shipped Download link QUARTZ64-model-A_eink.android11_SDK.patches.04112021.tar Only the PineNote target has been tested at this time. Compilation process cd rk3566 (for non eink) cd rk3566_ebook (for eink) source build/envsetup.sh lunch ./build.sh -UCKAu Cross-compiling The Pinephone’s triple for cross-compiling is aarch64-unknown-linux-gnu.\nC/++ Installing the Toolchain Important Please add instructions for other distributions to this section if you know them! First, you’ll need to install the gcc cross-compilation toolchain.\nOn Arch Linux $ sudo pacman -S aarch64-linux-gnu-gcc On Ubuntu/Debian $ sudo apt install gcc-aarch64-linux-gnu On Void Linux $ sudo xbps-install cross-aarch64-linux-gnu Using the Toolchain Note If you are trying to build an Arch Linux package with makepkg, also make sure to export CARCH=aarch64. GNU Make Kernel Makefile For each invocation of make, be sure to pass the options ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- like this:\n$ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- Other If you are using a handwritten Makefile (not autogenerated by a meta-buildsystem such as meson, automake, etc.) then simply override CC and LD as you need.\nautomake $ ./configure --host=aarch64-linux-gnu meson See the official meson documentation on the topic. In general, the introduction is a good read for any cross-compiling novice.\nRust In order to cross-compile Rust applications for the PinePhone, you need to have a gcc cross-compiler installed and the Rust dependencies, usually the std crate, cross compiled for the target system. A more extensive explanation can be found on https://github.com/japaric/rust-cross. This instruction is based on it’s description.\nInstalling a GCC Cross-Compiler The cross-compiler might have a different name depending on the operating system. Further along this instruction the name for the gcc cross-compiler will be used. Replace all occurrences of $gcc_name with the name on your distribution.\nFor how to install the gcc cross-compilation toolchain on your distribution, please see Cross-compiling\nInstalling Rust Dependencies The necessary dependencies can easily be installed with rustup:\n$ rustup target add aarch64-unknown-linux-gnu OR it can be installed with multirust [Is this still accurate???]:\n$ multirust add-target nightly aarch64-unknown-linux-gnu Compiling rustc When using rustc just add the two flags \u0026ndash;target=aarch64-unknown-linux-gnu and -C linker=$gcc_name. Under Arch, this would look like:\n$ rustc --target=aarch64-unknown-linux-gnu -C linker=aarch64-linux-gnu-gcc main.rs To test it, run the program on your PinePhone\n$ scp main user@ipadress:/home/user/Downloads $ ssh user@ipadress /home/user/Downloads/main Hello, world! cargo To cross-compile a project with cargo, open the folder of the project in a terminal. Then create a new folder and a file for cargo.\n$ mkdir .cargo $ cat \u0026gt;.cargo/config \u0026lt;\u0026lt;EOF \u0026gt; [target.aarch64-unknown-linux-gnu] \u0026gt; linker = \u0026#34;$gcc_name\u0026#34; \u0026gt; EOF Then you can compile it with\n$ cargo build --target=aarch64-unknown-linux-gnu To test it, copy the file on your PinePhone\n$ scp target/aarch64-unknown-linux-gnu/debug/main user@ipadress:/home/user/Downloads Then you can execute it by\n$ ssh user@ipadress ./main -h Hello, world! Possible Errors If you encounter an error saying\nCross compilation detected. Use PKG_CONFIG_ALLOW_CROSS=1 to override just add that variable in front of your command e.g.\nPKG_CONFIG_ALLOW_CROSS=1 cargo build --target=aarch64-unknown-linux-gnu Mainline Hardware Decoding Note This page is incomplete, you\u0026rsquo;re welcome to improve it. Mainline Hardware Decoding refers to video decoding done using hardware accelerators on the mainline Linux kernel (i.e. what sits in Linus\u0026rsquo; tree).\nOn most consumer-oriented SoCs, there is what is referred to as a VPU (Video Processing Unit). The VPU is responsible for power-efficient encoding and decoding of videos. Hardware-accelerated video decoding can be useful to get smoother video playback on your devices, lower power consumption, and lower CPU utilization. Below is information regarding various hardware PINE64 uses and software that works with it.\nHardware Here\u0026rsquo;s a table of the current support for different hardware. \u0026ldquo;In review\u0026rdquo; means the patch series to enable support has been posted to the mailing lists but is undergoing review, \u0026ldquo;linux-next\u0026rdquo; means it has been accepted and staged for the next Linux merge window.\nRK3328 RK3399 RK3566 RK3588 JPEG No Yes No No MPEG-2 Yes Yes Yes No MPEG-4 Part 2/H.263 No No No No VP8 Yes Yes Yes No H.264/AVC Yes Yes Yes¹ Yes H.265/HEVC In review In review No Yes VP9 Yes Yes No No AVS2 N/A N/A N/A No AV1 N/A N/A N/A No Notes ¹ only Hantro, not rkvdec2, so with a maximum resolution of 1080p for now\nCedrus In 2018, Bootlin launched a crowdfunding campaign to bring a open source Allwinner VPU driver to mainline Linux, which came to be called Cedrus. The Cedrus media driver (For Allwinner SOCs such as A64) supported by mainline Linux supports H.264 and H.265 video decoding as of Linux 5.10, and with 5.11 came VP8 decoding support and a H.264 stateless video decoder interface. For more information refer to the Sunxi wiki.\nHantro The Hantro media driver supports Rockchip and NXP SoCs including the RK3399 used in the Pinebook Pro and RockPro64. In November 2020 it was announced that Bootlin was working on encoding support for the driver.\nrkvdec rkvdec is the video decoding hardware that\u0026rsquo;s developed by Rockchip presumably in house. It\u0026rsquo;s what Rockchip uses for decoding 4K H.264/AVC, VP9 and H.265/HEVC content. The driver in mainline linux for the first generation rkvdec (used in RK3328 and RK3399) supports VP9 and H.264, patches for HEVC support are also in the process of review.\nRK3566, RK3568 and likely RK3588 use a second generation of rkvdec called rkvdec2. No mainline driver for this exists yet. The rkvdec instance on RK3588 additionally supports the AVS2 video codec.\nrkdjpeg rkdjpeg is Rockchip\u0026rsquo;s in-house hardware accelerated JPEG decoder. It can be found on the RK3566 and RK3568 as well as the RK3588.\nNo mainline driver exists for it so far.\nSoftware GStreamer H.264 video decoding is possible when using GStreamer built from source, or an application utilizing it such as Clapper or µPlayer. µPlayer includes a indicator of when hardware acceleration is properly working and in use.\nFFmpeg Mainline FFmpeg currently lacks the necessary patches to use the v4l2-requests based API, but a fork that can utilize it exists.\nWith the patched ffmpeg, you can utilize hardware decoding using the -hwaccel drm parameter, e.g.:\nffmpeg -hwaccel drm -i input.mp4 -f null - -benchmark\nto measure how fast it decodes.\nmpv mpv v0.35 or later, built against the aforementioned FFmpeg fork, can be used to play back videos with hardware accelerated decoding. The hardware decoder path features interop with the GPU output, saving an expensive copyback operation. You can utilize the hardware decoding with e.g.:\nmpv --hwdec=drm [FILE]\nIn mpv versions prior to 0.35, you can use the copyback hwdec with:\nmpv --hwdec=drm-copy [FILE]\nMore Resources Megi\u0026rsquo;s Cedrus Information HW accelerated GStreamer playback on the PinePhone HW accelerated Clapper video player on the PinePhone Mainline Hardware Encoding Mainline Hardware Encoding of video can be achieved through the V4L2 user-space API, for which currently only GStreamer implements the required code.\nSoC Support The following table shows the current supported codecs for encoding for each SoC. Support for decoding is separate.\nRK3328 RK3399 RK3566 RK3588 JPEG N/A Yes Yes No VP8 N/A In review No No H.264/AVC No No No No H.265/HEVC No N/A No No Encoding With GStreamer With GStreamer, in general, any V4L2 control can be set using the extra-controls=foo,name=value syntax after the encode pipeline stage identifier, where foo is any name you wish which GStreamer will promptly ignore, name is the name of the V4L2 control as shown by v4l2-ctl --list-ctrls (make sure to pick the right device with -d), and value is whatever value you want to set it to.\nJPEG Encoding This example converts an input MP4 file to an output MJPEG-inside-MKV file at JPEG quality 95, without any audio.\ngst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2jpegenc extra-controls=s,compression_quality=95 ! matroskamux ! filesink location=output.mkv VP8 Encoding Tip This requires a draft GStreamer merge request and the RFC kernel patchset applied. This example converts an input MP4 file to an output VP8-inside-MKV file with a quantiser between 12 and 28, without any audio. The quantiser value goes from 0 (best quality, biggest filesize) to 63 (worst quality, smallest filesize).\ngst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2slvp8enc min-quality=12 max-quality=28 ! queue ! matroskamux ! filesink location=output.mkv Alternatively, you can encode in variable bitrate mode with a target bitrate given in bits per second. Do note that Hantro doesn’t seem to do target bitrates below 2 mbit/s. In this example, the file is transcoded at a target bitrate of 3 megabits per second.\ngst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2slvp8enc bitrate=3000000 ! queue ! matroskamux ! filesink location=output.mkv Mali Driver Here is the good DRM powerpoint presentation by Free Electron: https://free-electrons.com/pub/conferences/2017/kr/ripard-drm/ripard-drm.pdf\nHere is the DRM video presentation by Free Electron: https://www.youtube.com/watch?v=LbDOCJcDRoo\nWayland MALI Driver MALI-400 R6P2 Kernel Mode Setting binary download (1.86MB, MD5 523276872A9A11D1831ACE42F95DBBB1) MALI-400 R6P2 WAYLAND 64-bit binary driver and binary download (179KB, MD5 1698E8C54BDC6FE0804699F545FFE793) X11 MALI Driver MALI EULA document MALI-400 64-bit binary driver and binary download from pine64.org (1.7MB, MD5 4F56AE6FB793E7D946867942AF58FEAC) X11 Notice Attached are the implemented driver and library.\nlib_x11_r6p0.tar.bz2：opengles upper layer library； r6p0_kernel_driver.tar.bz2：gpu driver code； sunxi_arm_video.tar.bz2： dri2 and exa video related accelerator implementation； sunxi_drm_0622.tar.bz2：drm driver； Usage：\nUsing drm driver not able to coexist with display driver，due to utilize display relate BSP section；Drm driver able to integrate with sunxi_arm_video apply gem during cache and cache refresh，open cache able to increase performance；Drm driver utilize sunxi_tr BSP rotate section，not able to public sharing with sunxi_tr；\nKnown issue：\nDue to rotate hardware not support crop, and majority exa accelerators operate using crop，sunxi_arm_video is reference code (features already verified)，this allow familiar with X.Org hardware acceleratio.\nIf using web page and character appear vertical strip, this may not related to cache problem and may due to character library. This issue still need to further verified.\nOverclocking Warning There is the possibility of damaging your equipment by overclocking. Do so at your own risk! Note This page is incomplete, you’re welcome to improve it. Note All information regarding clock speeds, voltages and more are stored in the DTB (Device Tree Blob). You can learn more about it here. Overclocking is a way to get more performance out of the system by running it at higher clock speeds than the factory default, usually while putting out more heat and using more power (You can also downclock to possibly reduce power consumption and thermals at the cost of performance). It is highly recommended that you avoid overvolting the device, as that has a high risk of damaging the hardware, hence the warning at the beginning of this page. However, just some slight overclocks without the added voltage can not only improve performance, but not carry as much risk (Still: Do at your own risk!). It should be noted however that overclocking can cause instability, so you will need to test and see what values work best with your device (There is a silicon lottery for the PinePhone’s hardware).\nA64-based devices Important These instructions are targeting the PinePhone to simplify the explanation, however they can be used to also overclock other devices such as the Pinetab if you modify the proper DTB files. Editing the PinePhone DTS In order to overclock the PinePhone you will have to first convert the DTB file in /boot/dtbs/allwinner/ to a DTS file. You will see sun50i-a64-pinephone-1.2.dtb, and also two other files with different PinePhone mainboard revisions (1.1 and 1.0). You will want to select the correct file for your PinePhone (Only choose 1.1 if you have a Braveheart, As all other consumer PinePhones use the 1.2 DTS).\nOnce you’ve found the file, you can run the following command to convert the DTB to DTS:\ndtc -I dtb -O dts /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dtb -o /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dts Finally, modify the newly converted .dts file and change the clockspeeds you wish to modify. You can simply use a text editor to do so.\nTo convert back to DTB:\ndtc -I dts -O dtb /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dts -o /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dtb Afterwards you can simply reboot and check with sudo cat /sys/kernel/debug/clk/clk_summary to see if the changes have correctly applied.\nImportant In the future it is possible that someone may make a driver to adjust clockspeeds of the A64 from userspace (using a config file) without the need to recompile. However, currently the only way to overclock is to either compile your own kernel, or modify just the DTB (instructions above). GPU Open /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dts (You will have to find the source of the kernel used by your distribution. There is the Pine64 kernel, and Megi’s) in a text editor following the PinePhone overclocking instructions.\nLook for mali: gpu@1c4000 { and within that block search for assigned-clock-rates = \u0026lt;432000000\u0026gt;;\nThe assigned-clock-rates line should be set to 432000000, this means that the GPU is clocked at 432MHz by default. So if you want 500MHz, set the value to 500000000.\nSave the DTS file, and recompile the DTB. In order to check if the overclock was successfully applied you can run: sudo cat /sys/kernel/debug/clk/clk_summary.\nImportant The file may be slightly different and you may need to enter the values as hexadecimals Note The GPU appears to run stable overclocked to 540 Mhz, however more testing with a wider group of devices is needed. Note Remember to run a benchmark tool (such as glmark2-es2) to help check stability. CPU The stock speed of the A64 is 1.152 GHz. The A64 can be overclocked significantly, it is highly advisable not to do this unless you can also drop the voltage at the same time.\nIf the CPU is undervolted and overclocked at the same time, it is possible to reach similar thermals and power consumption to the stock configuration but with better performance.\nPower consumption at different voltages and frequencies:\nConfiguration Frequency Voltage Power (Screen 50%) Stock 1.152GHz 1.30v ~4.35w Stock + Undervolt 1.152GHz 1.18v ~3.65w Overclock + Undervolt 1.344Ghz 1.28v ~4.60w The table above contains measurements created in postmarketOS (SWMO/SXMO - postmarketOS 21.12 SP1) with the screen on (set to 50% brightness) under a threaded load.\nAXP803 PMIC voltage steps on DCDC2:\nVoltage range Step size 0.50V-1.20V 10mV 1.22V-1.30V 20mV The table above shows the valid voltages provided by the AXP803 PMIC on DCDC2 (used to power the cores). For example, setting the voltage to 0.60V is valid, but setting it to 1.23V is not. When overclocking, ensure that you only use valid voltages at each operation point (otherwise it will simply be dropped and ignored). You can use (after installing) cpupower to display all valid frequencies after boot.\nImportant The user somefoo was able to undervolt the PinePhone at each frequency operation point by at least -100mv. The A64 set to 1.152Ghz runs at 1.18v instead of the standard 1.3v, dropping the power usage by ~0.7w under full single threaded load|The silicon lottery will dictate how well you can undervolt. Note The exact voltages and frequencies that you can achieve will depend on your device. Make sure to run stress tests (such as stress-ng) to ensure stability. DRAM Warning It is not recommended to exceed 667 MHz clockspeed on the DRAM. 648MHz is likely the upper limit. Note Make sure to set your DRAM to a multiple of 24. Note The current frequency your DRAM is running at can be found using this command: cat /proc/device-tree/memory/ram_freq When overclocking the GPU, it is a good idea to also overclock the DRAM, as the main bottleneck of the A64 SOC is the memory. The A64’s maximum ram clockspeed falls just short of 667MHz. This may be unstable on your device however.\nAround 600 MHz (PC-1200) should work fine, however some people have reported instability at lower clockspeeds. Arch Linux Arm uses a default clockspeed of 552MHz, with U-Boot builds available to easily switch out for a higher (624) or lower (492) DRAM clockspeed.\nIt is possible that by reverse engineering the DRAM driver from Allwinner that auto tuning can be accomplished to get the best performance.\nSetting the DRAM clock is accomplished by modifying pinephone_defconfig in U-Boot (https://gitlab.com/pine64-org/u-boot/-/blob/crust/configs/pinephone_defconfig)\nYou can find simple instructions on doing so here: U-Boot\nVPU In order to allocate more VRAM for the GPU you can add cma=256 to your kernel (or use kconfig with CONFIG_CMA_SIZE_MBYTES=256) cmdline in boot.scr which you will have to compile using mkimage. By default the kernel allocates only 64MB, and the maximum value is 256MB.\nIn order to compile boot.scr you can run mkimage -C none -A arm64 -T script -d boot.cmd boot.scr\nImportant You may not have a boot.cmd file in your boot directory and instead you may instead have a boot.txt Cedrus Overclocking cedrus is achieved by modifying the kernel source code: https://elixir.bootlin.com/linux/latest/source/drivers/staging/media/sunxi/cedrus/cedrus.c#L507\nImportant User 33yn2 is not particularly sure if this makes any difference, or if it might in fact have a negative impact. Probably not worth messing with. RK3399-based devices The RK3399 clocks are found in arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi\nMore optimised voltages and clocks can be found in arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi These include a slight overclock and undervolt, they are intended for the OP1 CPU found in many Chromebooks but have worked fine in all recorded cases on regular RK3399 SoCs in other devices.\nGPU Any clock speeds can be added for the GPU in gpu_opp_table\nThe highest recommended voltage for the GPU is 1.2V as specified in the RK3399 schematic from Rockchip.\nSegfault has found that the RK3399 in his Pinebook Pro can reach 950MHz on the GPU while being stable.\nThe stock speed for the GPU is 800Mhz.\nNote that the GPU in the RK3399 is already bottlenecked by the memory bandwidth available to it, so overclocking generally yields no improvements.\nCPU A set of available clock speeds that can be added to the CPU clusters can be found in drivers/clk/rockchip/clk-rk3399.c under rk3399_cpuclkl_rates for the little cores and rk3399_cpuclkb_rates for the big cores.\nThese clock speeds can be added to cluster0_opp for the small cores and cluster1_opp for the big cores respectively.\nThe maximum limit is 1.8GHz on the little cores and 2.2GHz on the big cores.\nThe highest recommended voltage for the little cores is 1.2V and for the big cores is 1.25V.\nSegfault has found that the RK3399 in his Pinebook Pro can reach 1.7GHz on the little cores and 2.08GHz on the big ones.\nThe stock speed for the little cores is 1.4GHz and on the big cores it is 1.8GHz, the OP1 speeds default to 1.5GHz and 2.0GHz instead.\nROCK64 DTB is in /boot/dtbs/rockchip/rk3328-rock64.dtb. CPU clock rates are inside opp_table0 as hexadecimal numbers in the opp-hz field.\nCheck the achieved clock speed with sudo cat /sys/kernel/debug/clk/clk_summary | grep armclk.\nThanks to Ayufan\u0026rsquo;s work (with their overclocking recipe), we know we can add a 1.392GHz operating point, and a 1.512GHz operating point (you should ensure you have a large heatsink for this last one). You can do so by adding the following in the opp_table0 object, after the opp-1296000000 operating point:\nopp-1392000000 { opp-hz = \u0026lt;0x00 0x52f83c00\u0026gt;; opp-microvolt = \u0026lt;0x149970\u0026gt;; clock-latency-ns = \u0026lt;0x9c40\u0026gt;; }; opp-1512000000 { opp-hz = \u0026lt;0x00 0x5a1f4a00\u0026gt;; opp-microvolt = \u0026lt;0x162010\u0026gt;; clock-latency-ns = \u0026lt;0x9c40\u0026gt;; }; GPU needs investigating, but current mainline device tree does not try to clock up the GPU at all.\nPineModems PINE64 position on alternative firmware PINE64 ships the PinePhone with a stock version of the Quectel EG25-G modem’s firmware. Some administrative regions, in the EU and Asia in particular, require the entirety of the modem’s firmware to be licensed. Therefore, the PinePhone cannot ship with an unlicensed firmware, and the PINE64 project cannot, officially encourage its userbase to use alternative modem firmware.\nQuectel EG25-G Modem Quectel EG25-G is an LTE Cat 4 module optimized specially for M2M and IoT applications. It is used in the PinePhone.\nSpecifications: https://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf Hardware design: https://wiki.pine64.org/wiki/File:Quectel_EG25-G_Hardware_Design_V1.4.pdf AT Interface reference manual: 1.3 for EC25: https://wiki.pine64.org/wiki/File:Quectel_EC25\u0026EC21_AT_Commands_Manual_V1.3.pdf 2.0 for EC25 and EG25-G: https://wiki.pine64.org/wiki/File:Quectel_EC2x\u0026EG9x\u0026EG2x-G\u0026EM05_Series_AT_Commands_Manual_V2.0.pdf AT Interface file operations: https://wiki.pine64.org/wiki/File:Quectel_EC2xEG25-GEG9xEM05_FILE_AT_Commands_Manual_V1.0.pdf GNSS Application note: https://wiki.pine64.org/wiki/File:Quectel_EC2x\u0026EG9x\u0026EG2x-G\u0026EM05_Series_GNSS_Application_Note_V1.3.pdf Specifications Processor Family Qualcomm MDM9607 CPU Qualcomm MDM9207 Cores 1 ACPU Core, Qualcomm Hexagon DSP Total RAM 256Mb Total flash space 256Mb Available RAM for the ACPU 160Mb NAND Partition table layout Index Name Description MTD0 SBL Secondary Bootloader, called from the BootROM. Used to start the TrustZone kernel and the Application Bootloader (LK). Also used to enter Quectel’s recovery mode MTD1 mibib NAND Partition table MTD2 EFS2 IMEI and settings used by the ADSP are stored here MTD3 sys_rev Unexplored MTD4 rawdata This is where FOTA update data exists before being committed to system or recoveryfs partitions MTD5 tz TrustZone kernel MTD6 rpm Resource / Power Manager MTD7 cust_info Unexplored MTD8 aboot Application Bootloader. Uses LK (LittleKernel, LK embedded kernel) as the bootloader. By default it allows flashing unsigned images but won’t allow booting them, soft-bricking the modem until you enter EDL mode MTD9 boot OpenEmbedded boot kernel + DTB MTD10 recovery Recovery kernel (used for FOTA updates) MTD11 modem ADSP firmware blobs MTD12 misc Some settings are stored here, along with commands that need to be picked by LK on next boot (to reboot to fastboot or recovery mode) MTD13 recoveryfs Recovery filesystem image (FOTA updates) MTD14 usr_data User data partition (/data when mounted by OpenEmbedded) MTD15 sec Used to blow fuses in the mdm9207 from images generated by Qualcomm Sectools MTD16 system Linux OpenEmbedded root image, formatted in UBIFS (Unsorted Block Image File System, Wikipedia) Firmware Recovery Warning The following instructions are directed towards expert-level users and developers! The System partition is mounted as read-only mode, but the data partition is writable. It might be possible, if there’s an unexpected reset or power is lost while running, that the data partition gets corrupt and thus unable to boot.\nPinePhone USB_BOOT test points\nThe modem has 4 different boot modes:\nNormal boot Recovery mode (used by the modem usually to install a FOTA update) Fastboot mode Qualcomm EDL Mode If the modem is unable to boot, depending on the type of crash, it might:\nnot show anywhere (USB device missing) or malfunction (no radio but USB working) or enter EDL mode, if the entire flash is corrupt. Boot the device in EDL mode\nTo check if the device is booted in EDL mode, run lsusb (a part of the usbutils package) in a terminal and inspect the output. You should see the following device listed:\nBus 003 Device 003: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode) In any scenario, the modem can be triggered to enter EDL mode by shorting two test pins on the PinePhone motherboard.\nPower off the phone short the two test points boot the phone while keeping the test points shorted until fully booted up, at least until you hear the camera clicking twice (which is normally when the modem is powered). Get the Firmware Recovery Package\nThe Firmware Recovery Package is at: https://github.com/Biktorgj/quectel_eg25_recovery\nEither clone its repo with git, or download its archive \u0026amp; unzip it.\nAs you should have no access to the Internet on PinePhone when its modem need a Recovery, you can fetch it on other devices and copy it to the Pinephone.\nExecute the Quectel QFirehose utility\nOnce in EDL mode, open a terminal, navigate to the root directory of the recovery package, and run:\nIf you use an ARM64 distribution (most likely): sudo ./qfirehose -f ./ or sudo ./qfirehose_arm64 -f ./ If you use an ARMHF (32 bit) distribution: sudo ./qfirehose_armhf -f ./ It will reboot the modem after finished. After about 30 seconds, it will get back up and running. To check the firmware version after that, use an AT command AT+QGMR like at PinePhone.\nBootloader unlocking Warning The following instructions are directed towards expert-level users and developers! The Modem has a locked bootloader. It won’t allow to boot unsigned Kernel images, but will allow to flash them, making it easy to brick the modem. To fix this, you can flash an unlocked bootloader, which will then allow you to do as you please with the hardware.\nUnlocked bootloader:\nSource code: https://github.com/Biktorgj/quectel_lk Prebuilt binary releases: https://github.com/Biktorgj/quectel_lk/releases Custom Kernels and system images Warning The following instructions are directed towards expert-level users and developers! Custom kernel builds and system images can be created for the modem, though they require a couple of things to be correctly built and be bootable.\nThe source code release for the kernel provided by the manufacturer is incomplete and won’t build Common Android tools like mkbootimg and dtbtool won’t build a bootable image, even if the kernel is correctly compiled and all the DTBs attached. Further, there’s no source for the OpenEmbedded parts, so building a new system image must be done from scratch, and retrieving the mandatory binary blobs to use the ADSP part of the modem. There’s a work in progress SDK to allow creating custom kernels and system images, which can be downloaded from the following repository: https://github.com/Biktorgj/pinephone_modem_sdk\nSee its readme for infomations and instructions. Once downloaded, you should run the init.sh script, which will create all the base directories and download all the different repositories required to build. After the initial setup is complete, runmake without arguments to list the available options.\nUpgrade/switch firmware via fwupd https://fwupd.org/ is an open-source tool for managing the installation of firmware on Linux systems.\nfwupd \u0026gt;= 1.7.6 (with the ModemManager plugin) supports writing/upgrading the https://github.com/Biktorgj/pinephone_modem_sdk firmware on the Quectel EG25-G modem.\nhttps://wiki.postmarketos.org/wiki/Fwupd discusses how to use fwupd to do this.\nMore context:\nhttps://dylanvanassche.be/blog/2022/pinephone-modem-upgrade/ https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2760 https://gitlab.com/linux-mobile/tracker/-/issues/11 Modem management To allow PinePhones to receive calls while the PinePhone is suspended, the modem should be kept running. ModemManager and a eg25-specific manager must be used for the eg25-manager to work correctly.\nModemManager ModemManager \u0026ldquo;is a DBus-activated daemon which controls mobile broadband (2G/3G/4G) devices and connections\u0026rdquo;. Distributions should enable the --test-quick-suspend-resume flag, per https://gitlab.com/linux-mobile/tracker/-/issues/12.\nContext: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/321\neg25-specific manager Some functionality is not built into ModemManager, and is instead managed via eg25-specific software. There are two variants of this, but only one should be used.\neg25-manager recommended, used in most distributions. modem-power Testing When a distribution makes a significant change to their modem management setup, they should consider testing the following:\nModem is recognized by ModemManager on boot. Can make a call Can receive a call Can receive a call when asleep: systemctl suspend See also \u0026ldquo;PinePhone modem myths\u0026rdquo; by Dylan Van Assche RK3399 boot sequence This article describes the boot sequence of the RK3399, the SoC on which the ROCKPro64 single board computer, Pinebook Pro laptop and the PinePhone Pro are based.\nBoot ROM operation After a hardware reset, the SoC’s boot ROM (BROM) starts running on CPU0, one of the Cortex-A53s on the chip. This code is stored on a block of read-only memory, likely hard-wired into the chip.\nIt employs 5 strategies, in order, to load a bootloader from off-chip:\nloading from NOR flash on SPI1 loading from NAND flash on SPI1 loading from eMMC loading from SD on the SDMMC controller bringing up the OTG0 USB controller in device mode and accepting control transfers to load programs Loading a bootloader from storage is done in 4 steps:\nProbing the boot device Finding the ID block Loading the first stage of the bootloader to main SRAM and running it (if the first stage returned to BROM) Loading the second stage to low DRAM and running it ID block The ID block is a 512-byte block at one of several well-known locations (depending on boot device type) scrambled using RC4 with a well-known key, which begins with the bytes 0x3b 8c dc fc (ciphertext; plaintext: 0x55 aa f0 0f).\nIn addition to the magic number, it contains (all fields little-endian):\na flag to RC4-scramble the bootloader images too (32b at offset 8) offset (in 512 B-sectors) of the first bootloader stage (16b at offset 12) the size (in 2 KiB blocks) of the first bootloader stage (16b at offset 506) the size (in 2 KiB blocks) of the second bootloader stage (16b at offset 508) These fields can be seen in U-Boot tools/rkcommon.c.\nSPI boot The boot ROM tries to probe the device on SPI1 by issuing the SPI-NOR 0x9f (Read Identification) command.\nIf the type and capacity bytes are all-ones or all-zeroes, probe fails. If the first byte (manufacturer ID) is all-ones, the BROM uses NAND protocol, otherwise NOR protocol.\nNOR protocol uses command 0x03 (low-frequency read without turnaround cycles) to read blocks, NAND protocol uses command 0x13.\nThe ID block is searched by loading the 32 bytes at the start of flash (TODO other load offsets) and testing for the magic number at any offset within those 32 bytes.\nThe SPI code has a bug that means that the 2 KiB blocks in which the bootloader is loaded have a stride of 4KiB, leaving the 2KiB inbetween as unused padding.\neMMC/SD boot The boot ROM probes for eMMC on the eMMC controller using the normal MMC enumeration sequence (CMD0/1/2/3) at 375 kHz and runs the bus at 24 MHz, in 8-wide mode. The BROM does not support using the standard option for eMMC boot partitions.\nSD is probed on the SDMMC (not the functionally equivalent SDIO) controller, using the normal SD enumeration sequence at 375 kHz and then runs the card at 12 MHz (TODO confirm) in 4-wide mode.\nAfter initialization, eMMC and SD behave much the same. The ID block is searched by loading the blocks at sector 64 + 1024*n for n from 0 to 4 (inclusive) and checking for the magic number at the start of that sector. The BROM handles both byte- and block-addressed SD/MMC cards.\nHardware root of trust The BROM theoretically supports SHA256/RSA2048 authentication with rollback protection.\nThe relevant data is stored in Secure eFuses: an enable flag, a SHA256 hash of the public key (which is stored on the boot medium) and a range of bits that are sequentially set for rollback protection.\nIn practice, the BROM does not verify the full length of the public key against the hash in eFuses, which means that it is most likely broken (expert review would be appreciated).\nTOOD details\nFOSDEM 2023: Tomasz Żyjewski (3mdeb) - Overview of Secure Boot state in the ARM-based SoCs, 2nd edition Rockchip Developer Guide Linux4.4 Secure Boot EN.pdf (zh_CN) Artur Kowalski (3mdeb) - Enabling Secure Boot on RockChip SoCs - December 2021 RK3399 Efuse Operation Instructions V1.00 - 14 February 2019 USB gadget boot If no ID block is found on SPI, eMMC or SD, the BROM sets up the OTG0 USB controller to act as a USB high-speed (480 Mb/s) device with Vendor/Product ID of 2207:330c. In this state it supports most standard control requests, as well as 2 vendor control requests:\n0x0471\nThe code is loaded to main SRAM. When the transfer is done, it does a function call to the load address.\n0x0472\nThe code is loaded to low DRAM. When the transfer is done, USB is torn down and BROM jumps to the load address.\nTransfer is performed by doing the requests on 4 KiB blocks. BROM considers the transfer complete as soon as a request supplies a block not 4096B long. (This means images a multiple of 4096 bytes long must be padded to achieve this condition.\nU-Boot boot sequence Bootloaders based on U-Boot (including Tow-Boot) run in 4 stages on the RK3399:\nTPL, loaded by the BROM into main SRAM. Its job is to initialize DRAM (main system memory). It returns to BROM. This job can alternatively be performed by proprietary Rockchip DDR blobs. SPL, loaded by the BROM into low DRAM. It loads the respective parts of TF-A BL31 into DRAM, main and PMU SRAM, and U-Boot proper into DRAM. TF-A BL31. It sets up EL2 to run U-Boot and stays resident until system shutdown. U-Boot proper. It can load EFI binaries (Grub, systemd-boot, …) from a variety of block devices (SD, eMMC, NVMe, USB Mass Storage, …). For mainline-based U-Boots, these stages usually come in 2 images:\nidbloader.img\ncontains TPL and SPL.\nu-boot.itb\ncontains TF-A and U-Boot.\nLoad offsets Important This section applies to BSP U-Boot. Mainline-based U-Boots pack TF-A into u-boot.itb. There are 3 sections for the boot loader. They are in order, without gap, though their is no need to use all the space in each section.\nHere are the details:\nStart in sectors Size in sectors Name Description 64 16320 IDBLoader SoC initialization code 16384 8192 OS loader Generally U-Boot 24576 8192 TrustedFirmware-A General maintenance If a new U-Boot is supplied, it is generally installed similar to this:\n# dd if=/boot/idbloader.img conv=notrunc seek=64 of=/dev/mmcblkX # dd if=/boot/u-boot.itb conv=notrunc seek=16384 of=/dev/mmcblkX Different devices The RK3399 boots to multiple devices. Boot device selection is done in the following order, and it cannot be changed.\nIf a device is blank / unused, the SoC code moves on to the next device in the list.\nSPI eMMC SD card However, whence the user boot code runs, it can then give priority to other devices, if available. The following devices are not directly bootable:\nNVMe USB 3 WiFi They can be made bootable by using one of the other devices as an initial bootloader. For example, several people have gotten their NVMe drives to be bootable with \u0026ldquo;/boot\u0026rdquo; and \u0026ldquo;/\u0026rdquo; on the NMVe. This either entails using the SPI or eMMC as the initial bootloader, with code to support PCIe NVMe devices.\nGrub as the target of the bootloader It is possible to use Grub as the target of U-Boot. This would allow;\nSelecting a different boot device Choosing a partition on a boot device for booting Different kernels Changes in kernel command line options However, at present, Grub does not support the video \u0026amp; keyboard of the Pinebook Pro. So, any selection is done through the serial console.\nBoot loader development There are several projects that have their own versions of U-Boot, with different features. Here are some of the more common ones at present, 2020/06/14:\nRockchip The original default Debian Manjaro U-Boot mainline Bootloaders not based on U-Boot:\ncoreboot runs on RK3399-based Chromebooks, it has not been ported to Pine64 boards yet. levinboot is a bootloader developed by CrystalGamma in the Pine64 community. It runs on RockPro64 and Pinebook Pro. Its development is on hiatus as of April 2022, but a fork porting it to the PinePhone Pro exists. RK3566 EBC Reverse-Engineering The RK3566 SoC, used in the Quartz64 SBC by PINE64, contains an eInk interface. This is referred to as ebc by Rockchip apparently.\nUnfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it.\nSources Downstream The ebc driver source is available from the quartz-bsp repository.\nThe files of interest are ebc_dev_v8.S, which implements a DRM (Direct Rendering Manager) driver for the eInk panel, and the waveform files in the epdlut subdirectory.\nThere’s also a simple driver for u-boot: drivers/video/rk_eink at JeffyCN/rockchip_mirrors\nThese two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in \u0026ldquo;LUT mode\u0026rdquo;: it writes the waveform LUT to registers in the TCON’s MMIO space, and passes buffers of pixel data to the TCON. The Linux driver operates in \u0026ldquo;direct mode\u0026rdquo; uses the LUTs to compute waveforms in software, and passes buffers of waveform data to the TCON.\nSome reversing of the downstream Linux driver has been done here: https://github.com/Ralim/ebc-dev-reverse-engineering\nReimplementation A human-readable C reimplementation of the LUT and pixel data path is available from smaeul here. This provides everything needed to convert a framebuffer and a waveform data file into a series of \u0026ldquo;frames\u0026rdquo; for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver.\nIn-Development Driver rk356x-ebc-dev is the branch used for developing an upstreamable DRM driver based on mainline kernel sources. The driver currently functions well enough to get a virtual console and X.Org running, but it does not support features like multiple waveforms.\nDocumentation Datasheets EBC The EBC TCON is documented in part 2 of the RK356x TRM.\nTI TPS65185x This is the PMIC used to drive the e-Ink panel, for which the downstream sources also implement a driver.\nhttps://www.ti.com/lit/ds/symlink/tps65185.pdf\nWaveform The format of the waveform file is documented here:\nhttps://www.waveshare.net/w/upload/c/c4/E-paper-mode-declaration.pdf\nhttps://www.waveshare.net/w/upload/archive/c/c4/20190611032540!E-paper-mode-declaration.pdf\nUtilities The inkwave program is designed to parse waveform files. Currently it cannot fully handle the waveform files shipped with the PineNote. Adding support for this to the tool would be helpful.\nAssembly Syntax and Semantics The Syntax is GNU Assembler (GAS) syntax. This modexp article provides a good introduction to the syntax, calling convention, semantics and some often used instructions.\nThe ARM Architecture Reference Manual for ARMv8 should be used as reference for any instructions.\nAt the very least, you should read up on the registers and calling convention used.\nVarious Findings The driver isn’t really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions.\nIt’s technically a DRM subsystem driver, but doesn’t really utilize what DRM provides at all. It seems to register a new ioctl to set buffer attributes like width and height, despite DRM more than likely having a way for clients to tell a driver what size the framebuffer should be. It directly interacts with the PMIC instead of going through regulators/hwmon. However, reverse engineering to know how it works provides a good baseline from which we can rewrite it in a more sensible manner.\nDebug Information Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage.\n.file _file-number_ _file-path_ Specifies a number to reference a file by, and its path. All following code until the next .file or .loc statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available.\n.loc _file-number_ _line-number_ 0 Specifies that the following code is generated from _line-number_ stemming from file number _file-number_. See the .file directive for this file number to understand which source file it came from.\n.type _function-name_, %function This tells us that the following code belongs to function _function-name_. You’ll usually see a .cfi_startproc, which signifies the start of the function code, until the matching .cfi_endproc.\nA quick grep for %function shows that we are dealing with 30 functions in this file.\n.type _struct-name_, %object This seems to signify a definition of a C struct named _struct-name_.\nA quick grep for %object shows that we are dealing with around 27 structs in this file.\n.Ldebug_info0: TODO: This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures.\nFinding Structs and Function Signatures First, we’ll need to assemble the file:\naarch64-linux-gnu-gcc -c -o ebc_dev_v8.o ebc_dev_v8.S\nThis gives us a ebc_dev_v8.o which we can feed into analysis tools.\nFor both of these, keep in mind that we’re only interested in stuff from ebc_dev.c, or any other files for which we don’t have the source. There’s no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such.\nAlso make sure that if you are looking up known struct accesses, that you use struct definitions from the BSP kernel, not from mainline. The kernel has no internal ABI for drivers!\nFaster and Easier - Ghidra Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the \u0026ldquo;Data Type Manager\u0026rdquo; marked with an S icon. You’ll also find functions in the symbol tree.\nSlow and Painful - readelf/objdump Use this if you want to manually look up dwarf symbols for some reason.\nreadelf --debug-dump ebc_dev_v8.o\nThis will produce a lot of output, but we’re mainly concerned with the start of the dump. We’ll find things like:\n\u0026lt;2\u0026gt;\u0026lt;101f8\u0026gt;: Abbrev Number: 0 \u0026lt;1\u0026gt;\u0026lt;101f9\u0026gt;: Abbrev Number: 79 (DW_TAG_subprogram) \u0026lt;101fa\u0026gt; DW_AT_name : (indirect string, offset: 0xa2b4): ebc_open \u0026lt;101fe\u0026gt; DW_AT_decl_file : 1 \u0026lt;101ff\u0026gt; DW_AT_decl_line : 1377 \u0026lt;10201\u0026gt; DW_AT_prototyped : 1 \u0026lt;10201\u0026gt; DW_AT_type : \u0026lt;0xc6\u0026gt; \u0026lt;10205\u0026gt; DW_AT_low_pc : 0x0 \u0026lt;1020d\u0026gt; DW_AT_high_pc : 0xc \u0026lt;10215\u0026gt; DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) \u0026lt;10217\u0026gt; DW_AT_GNU_all_call_sites: 1 \u0026lt;10217\u0026gt; DW_AT_sibling : \u0026lt;0x1023a\u0026gt; \u0026lt;2\u0026gt;\u0026lt;1021b\u0026gt;: Abbrev Number: 88 (DW_TAG_formal_parameter) \u0026lt;1021c\u0026gt; DW_AT_name : (indirect string, offset: 0x1153): inode \u0026lt;10220\u0026gt; DW_AT_decl_file : 1 \u0026lt;10221\u0026gt; DW_AT_decl_line : 1377 \u0026lt;10223\u0026gt; DW_AT_type : \u0026lt;0x1c54\u0026gt; \u0026lt;10227\u0026gt; DW_AT_location : 0xd63 (location list) \u0026lt;2\u0026gt;\u0026lt;1022b\u0026gt;: Abbrev Number: 106 (DW_TAG_formal_parameter) \u0026lt;1022c\u0026gt; DW_AT_name : (indirect string, offset: 0x8b06): file \u0026lt;10230\u0026gt; DW_AT_decl_file : 1 \u0026lt;10231\u0026gt; DW_AT_decl_line : 1377 \u0026lt;10233\u0026gt; DW_AT_type : \u0026lt;0x551f\u0026gt; \u0026lt;10237\u0026gt; DW_AT_location : 1 byte block: 51 (DW_OP_reg1 (x1))\nThis essentially tells us the full function signature of ebc_open:\nDW_TAG_subprogram tells us of a function, with DW_AT_name letting us know that this is ebc_open. DW_AT_type of 0xc6 let’s us know, once we jump to \u0026lt;c6\u0026gt;, that this function’s return type is a signed 32-bit integer.\nThe DW_TAG_formal_parameter that follow tell us of each of the parameter the function takes. The first one is called inode and is of type 0x1c54. Referencing what this type is, we find:\n\u0026lt;1\u0026gt;\u0026lt;1c54\u0026gt;: Abbrev Number: 7 (DW_TAG_pointer_type) \u0026lt;1c55\u0026gt; DW_AT_byte_size : 8 \u0026lt;1c56\u0026gt; DW_AT_type : \u0026lt;0x1970\u0026gt; which in of itself goes on to reference 0x1970, and looking this one up, we’ll find a struct definition:\n\u0026lt;1\u0026gt;\u0026lt;1970\u0026gt;: Abbrev Number: 26 (DW_TAG_structure_type) \u0026lt;1971\u0026gt; DW_AT_name : (indirect string, offset: 0x1153): inode \u0026lt;1975\u0026gt; DW_AT_byte_size : 672 \u0026lt;1977\u0026gt; DW_AT_decl_file : 31 \u0026lt;1978\u0026gt; DW_AT_decl_line : 611 \u0026lt;197a\u0026gt; DW_AT_sibling : \u0026lt;0x1c4f\u0026gt; \u0026lt;2\u0026gt;\u0026lt;197e\u0026gt;: Abbrev Number: 27 (DW_TAG_member) \u0026lt;197f\u0026gt; DW_AT_name : (indirect string, offset: 0x7d00): i_mode etc.\nReverse-Engineered Stuff Structs ebc_info See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on the v1.04 BSP Linux driver.\nebc See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on the v1.04 BSP Linux driver.\nrkf_waveform Note all known waveform data files are the \u0026ldquo;PVI\u0026rdquo; variant, not the \u0026ldquo;RKF\u0026rdquo; variant. struct rkf_waveform { int length, char[16] format, char[16] version, char[16] timeandday, char[16] panel_name, char[16] panel_info, char[64] full_version, char[64] reset_temp_list, char[64] gc16_temp_list, char[64] gl16_temp_list, char[64] glr16_temp_list, char[64] gld16_temp_list, char[64] du_temp_list, char[64] a2_temp_list, uint[64] reset_list, uint[64] gc16_list, uint[64] gl16_list, uint[64] glr16_list, uint[64] gld16_list, uint[64] du_list, uint[64] a2_list } Enums rkf_waveform_type enum rkf_waveform_type { RKF_WF_RESET = 0, RKF_WF_DU = 1, RKF_WF_GC16 = 2, RKF_WF_GL16 = 3, RKF_WF_GLR16 = 4, RKF_WF_GLD16 = 5, RKF_WF_A2 = 6 } U-Boot Tip It is helpful to have a debugging serial cable for this. Building U-Boot manually Prerequisites These instructions are written with a host Arch Linux desktop system in mind.\nThis guide will be especially useful if you are looking to overclock the ram on your PinePhone following the information found here.\nYou must have these packages installed: dtc swig bc aarch64-linux-gnu-gcc\nIf you are using a different system such as Ubuntu, there are plenty of cross compilation instructions available online with which you can grab the needed package names from, however you should be able to follow these instructions with these packages installed: build-essential bison flex swig gcc-aarch64-linux-gnu\nCompilation Tip This guide is written with the PinePhone in mind. On other devices you will need to set a different platform variable and likely use a different U-Boot source with patches oriented towards your device. Note by default these instructions utilize all of your computers cores to compile thanks to the -j and $(nproc) parameters. If you wish to only use one core to compile, or change the number of cores used for example to only two cores, then you can either completely remove the -j$(nproc) parameter from the make commands, or just take off $(nproc) and add the number of threads you want used in it’s place: -j4\nFirst, You need to compile the ATF (Arm Trusted Firmware):\ngit clone https://github.com/crust-firmware/arm-trusted-firmware/ cd arm-trusted-firmware export CROSS_COMPILE=aarch64-linux-gnu- export ARCH=arm64 make PLAT=sun50i_a64 -j$(nproc) bl31 cd .. After the ATF is compiled clone u-boot and copy the bl31.bin file into the u-boot directory.\ngit clone https://gitlab.com/pine64-org/u-boot.git cd arm-trusted-firmware cp build/sun50i_a64/release/bl31.bin ../u-boot/ cd .. Tip You cannot build Crust if you do not have the or1k musl toolchain installed. This toolchain is not usually available in distribution repositories and will have to be manually installed to the system. The following text will show a simple way to install the toolchain. Download the toolchain’s archive: https://musl.cc/or1k-linux-musl-cross.tgz\nExtract the compressed archive: tar zxvf or1k-linux-musl-cross.tgz\nMove the extracted archive to wherever you would like to install the toolchain to. In these instructions it will simply be installed to the users documents folder.\nThe final step is to edit your .bashrc and add the following to the end:\n# Path for or1k toolchain export PATH=\u0026#34;$PATH:/home/USER/Documents/or1k-linux-musl-cross/bin/\u0026#34; After you’ve completed that you can close out the terminal and reopen it and proceed to the following instructions.\ngit clone https://github.com/crust-firmware/crust cd crust export CROSS_COMPILE=or1k-linux-musl- make pinephone_defconfig make -j$(nproc) scp cp build/scp/scp.bin ../u-boot/ cd .. Tip If you do not wish to have Crust in your U-Boot build, then you can skip exporting SCP cd u-boot/ git checkout crust export CROSS_COMPILE=aarch64-linux-gnu- export BL3bl31.bin export ARCH=arm64 export SCP=scp.bin make distclean make pinephone_defconfig make all -j$(nproc) U-Boot installation Once successfully compiled you can proceed to flash the device\nWarning Replace [CHANGE THIS] with the location of your SD card and make sure you are using the proper location. Failure to do so can result in data loss. sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/[CHANGE THIS] bs=1024 seek=8 Tip If you are compiling U-Boot in order to overclock your DRAM you can check if it was successful by reading the values of /sys/kernel/debug/clk/clk_summary p-boot multi-bootloader One of the smallest and fastest PinePhone bootloaders, it was developed by Ondrej Jirman with the ability of booting multiple distributions on the PinePhone in mind.\nMore information can be found here\nExternal Links Sunxi U-Boot Wiki\nU-Boot build instructions\nor1k toolchain download\n","permalink":"/documentation/General/_full/","tags":null,"title":"General (Single Page)"},{"categories":null,"contents":"This guide is for the PINE64 devices. For device-specific information please see the corresponding device pages listed on the main page.\nRequirements You will need the following to get started with using your PINE A64(+), PINE A64-LTS, Pinebook or ROCK64 board:\nA Windows / Linux PC or Mac device with a MicroSD Card Reader Internet connection / pre-downloaded OS image files Power Supply: PINE A64(+): Power Supply (PSU) and a micro USB cable. Please make sure to use a PSU rated at +5V @2A and a micro USB cable that is at least 26 AWG thick. SOPine/PINE A64-LTS: Power Supply (PSU) with 3.5mm OD/1.5mm ID barrel DC Jack. Please make sure to use a PSU rated at +5V @2A. Pinebook and ROCK64: Power Supply (PSU) with 3.5mm OD/1.5mm ID barrel DC Jack. Please make sure to use a PSU rated at +5V @3A. MicroSD card (Recommend: 8GB or higher capacity, 10MB/s or faster speed) HDMI cable (unless you wish to run headless / without a screen) For, Android and Remix OS supports 720p and 1080p, while Linux supports a wider range of resolutions. Input device(s) such as: keyboard, mouse, remote, pointer, etc. Step-by-Step Instructions for Flashing MicroSD Cards Important Caution! Handle the Pine64 Single Board Computers\u0026rsquo; PCBs with care. Always hold bare boards by the edges and make sure to wear an anti-static wrist strap. Touching components on the front and back of the boards can result in an ESD discharge that may cause damage to the electronics. Avoid placing bare boards on materials such as carpets, plastics or other surfaces prone to electrostatic build-up Begin by imaging the OS of your choice\nThe process of flashing PINE64 OS images to micro SD on your Windows, Linux or OSX device is the same for all devices. You will require a quality microSD card (8GB or greater; class 10 or faster). There are many substandard and counterfeit cards in circulation and even reputable vendors may unknowingly sell counterfeit microSD cards. Cards that do not meet the criteria outlined above are known to cause a variety of issues including, but not limited to, complete boot failure. There are ways of testing microSD cards prior to installing the operating system to make sure they are appropriate for use with your board. The main utility for checking microSD cards is H2testw 1.4; yet another alternative is F3. Yet another overview of various options Test and Detect Fake Cards\nPlease refer to the relevant section below for instructions on how to image your microSD card:\nImaging microSD on Windows 7/8/8.1/10 Imaging microSD on macOS Imaging microSD on Linux Having successfully imaged your microSD card, insert it into the microSD slot.\nPlug in the HDMI Cable, Ethernet Cable and Peripherals to your PINE64 SBC\nUnless you are planning on running your board headless (without a monitor / as a server) you should plug in all necessary peripherals, including the HDMI and Ethernet cable, prior to powering ON the board. Do note, depending on which OS image you are using, some peripherals may or may not work.\nApply Power to Your Board\nOnce you have imaged your microSD and plugged everything in, you are ready to apply power to the PINE64 Single Board Computer. You’ll need a good quality 5 Volt, 2 Amp PSU. Using a good quality PSU is very important as failing to meet the required specifications may prevent the board from booting correctly. A marginally higher PSU Voltage is acceptable (for instance, 5.1 volts - due to the nature of the micro USB connection, a 5.1v supply can help protect slightly against voltage drops which can cause undesirable results). However, a significantly higher voltage of 7 Volts or more will damage the PINE64 Single Board Computer and may render it inoperative.\nFor PINE A64(+) board, if you are using a separate micro USB cable with your PSU, make sure that the cable has a low resistance rating. Cables with high resistance will cause improper function and the unit may not boot at all or only partially. The thicker the internal cabling, the better i.e. AWG (American Wire Gauge) 20 is better than AWG 28. In General, power-only microUSB cables come with red color USB header.\nHaving completed the steps outlined above the PINE64 Single Board Computer will begin to boot. The onboard power-on LEDs will come on and Ethernet port LEDs will start to blink if you have an Ethernet cable plugged in.\nImaging microSD on Windows 7/8/8.1/10 You will need the following utilities to get started with imaging the OS of your choice onto your microSD card:\nA compression utility (used to unarchive the OS image). We recommend you use 7zip. A disk image utility (used to flash the .img to your SD card). We recommend you use either the Etcher or Win32Imager utility. Optional for Allwinner A64 SoC based boards\nPhoenix Card image utility (used ONLY for phoenix card images). Downloading and extracting OS image(s)\nYou can find OS images for the respective devices in the device section on the main page. Images designated ‘DD’ need to be flashed using Etcher or Win32imager, whilst images labelled ‘Phoenix Card Image’ require the Phoenix Card utility.\nHaving downloaded the required OS image proceed to use 7zip to unarchive it by right-clicking the archive, and selecting ‘Extract All’. Upon completion, note the destination of where the .img file was extracted (‘Downloads’ folder by default). Once the process has completed, you can proceed to imaging the .img file.\nImaging the microSD card (DD)\nInsert your microSD card into your laptop/USB card reader. You may require a SD → microSD converter, as most laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, make sure to take note of the drive it has been assigned (the drive is assigned a letter, e.g. ‘F:’). You will need to remember the ‘letter’ it has been assigned when imaging the OS. Launch Win32diskImager.exe or etcher.exe. You will be presented with a field titled ‘path’ and a drop down menu labeled ‘device’. Click the ‘path’, navigate to and select the OS image you extracted from the archive earlier. Next, from the drop-down menu select the drive your microSD has been assigned. WARNING: Pay close attention to the selected drive (remember your letter) – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. Having chosen the desired OS image and the correct driver press ‘write’. Once the image has been written to your microSD card you will receive a pop-up notification. Be sure to close the application and to eject/remove your SD card safely from Windows. Imaging using Phoenix Card (applicable only to Allwinner A64 SoC based boards)\nOn Windows, you can also use Phoenix Card (for detailed instructions click here). The Phoenix Card utility works ONLY with images designated as ‘Phoenix Card’ in the downloads section. To use Phoenix Card follow these steps:\nInsert your microSD card into your laptop/USB card reader. You may require a SD → microSD converter, as most laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, make sure to take note of the drive it has been assigned (the drive is assigned a letter, e.g. ‘F:’). You will need to remember the ‘letter’ it has been assigned when imaging the OS. Launch phoenixcard.exe. You will be presented with a ‘disk’ drop-down menu and a field denoted as ‘.img File’. Click on ‘.img File’ and navigate to and select the OS image have downloaded and unarchived. Next, make sure to select the disk that your microSD card has been assigned. WARNING: Pay close attention to the selected drive (remember your letter) – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. Make sure to select ‘Startup!’ from the ‘Write mode’ window and click Burn. Once the image has been written to your microSD card you will receive a confirmation in the ‘option’ window. Be sure to close the application and to eject/remove your SD card safely from Windows. Imaging microSD on macOS You will need the following utilities to get started with imaging the OS of your choice onto your microSD card:\nA compression utility (used to unarchive the OS image). You may use Keka. A disk image utility (used to flash the .img to your SD card in GUI). You may use ApplePi Baker v2 or Etcher. Tip Phoenix Card utility and images are NOT available on macOS. Downloading and extracting OS image(s), insert the SD card\nYou can find OS images for the respective devices in the device section of the main page.\nHaving downloaded the required OS image, proceed to use the compression utility to unarchive it and get the .img file. Once the process has completed, you can proceed to write it to your SD card.\nInsert your microSD card into your Mac laptop/USB card reader. You may require a SD → microSD converter, as Apple’s laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, it should appear in Finder / on your desktop.\nImaging the microSD card (GUI)\nLaunch the imaging utility. Upon startup, the application may ask for your password. When the application launches, you will be presented with a field titled ‘IMG file’ and a path of the mounted microSD card (it will look like this: ‘/dev/diskX 32.0Gb SD card’).\nTo choose the OS image file, click the ‘IMG file’ button, navigate to and select the .img file you extracted from the archive earlier. Then select the microSD card you want to write into.\nWarning Pay close attention to the selected device, make sure it is the right SD card – the imaging process will permanently erase and format the selected storage device. If you choose the wrong device, all the data in it will be lost. Having chosen the desired OS image and the correct device, press ‘Restore Backup’ or ‘Flash’. Once the image has been written to your microSD card, you will receive a pop-up notification. Close the application, then eject/remove your SD card from your Mac.\nImaging from Terminal\nImportant If you are not comfortable using the terminal, please use the GUI method outlined above instead. Open up your terminal and navigate to the directory where you unarchived your OS image.\nBefore you start writing to the card, you will have to identify your microSD card. Type: diskutil list and note the output. The disk number should match the size of your SD card, and will likely be using Fdisk_partition_scheme.\nHaving identified the disk number execute the following commands (substitute diskX for your disk and name of image for pine64-image-name.img):\ndiskutil unmountDisk /dev/diskX sudo dd if=pine64-image-name.img of=/dev/disk2 bs=1M Wait patiently for the process to complete, then eject/remove your SD card from your Mac.\nImaging microSD on Linux You will need the following utilities to get started with imaging the OS of your choice onto your microSD card:\nA compression Utility (used to unarchive the OS image). We recommend you use Ark. A disk image utility (used to flash the .img to your SD card in GUI). We recommend you use Etcher or the GUI Disks utility that ships with most popular distributions. Tip Phoenix Card utility and images are NOT available on Linux. Downloading and extracting OS image(s)\nYou can find OS images for the respective devices in the device section on the main page. On Linux you can only use images designated as ‘DD’.\nHaving downloaded the required OS image proceed to use 7zip to unarchive it by double clicking the archive, and selecting ‘Extract All’. Upon completion, note the destination where the .img file was extracted (‘Downloads’ folder by default). Once the process has completed, you can proceed to imaging the .img file.\nImaging the microSD card (GUI)\nInsert your microSD card into your Linux laptop/USB card reader. Once the microSD card is plugged into your computer it should appear in your File Manager / on your desktop. Launch Disks or the etcher utility (This tutorial outlines how to use Disks, if you wish to learn how to use Etcher please visit their website). Upon launching Disks, you will be presented with all volumes visible to your computer. As a rule of thumb, your microSD card should be found at the bottom of listed volumes. Verify this by checking the size and mounting of the microSD card. WARNING: Pay close attention to the selected drive – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. Having selected your microSD card, click the cog menu in top right corner and choose the ‘Restore Disk Image’ option from the drop-down list. Navigate to and select the OS image you extracted from the archive earlier. Once you select it, you will be asked to enter your password and to confirm writing to the chosen volume (microSD card). You will be given a predicted time, writing-speed and completion percentage. Once the image has been written to your microSD card you will receive a pop-up notification. Be sure to close the application and to eject/remove your SD card safely from your computer. Imaging from Terminal\nImportant If you are not comfortable using the terminal, please use the GUI method outlined above instead. Insert your microSD card into your Linux laptop/USB card reader. Once the microSD card is plugged into your computer it should appear in Finder / on your desktop. Open up your terminal and navigate to the directory where you unarchived your OS image. e.g. cd Download Before you start writing to the card, you will have to identify your microSD card. Type: lsblk and pay attention to the listed disks. Disks will appear as /dev/mmcblk0 /dev/mmcblk1 etc. Important Hint: the drive you currently have booted from has the / at the end of the line. This is the wrong drive. Look at the drive that matches your microSD card’s size. Now you are ready to write the image to the microSD card using this command: (replace the pine.img file with your image and mmcblkX with the correct device for the microSD card)\nsudo umount /dev/mmcblkX sudo dd if=pine.img of=/dev/mmcblkX bs=1M status=progress conv=fsync Wait patiently for the process to complete.\nuse the command sync to ensure everything is written to the microSD card.\nThe card is ready to boot\n(sometimes this process fails and your microSD card can’t boot, one way of fixing this is just to repeat the same thing, you can also try a different microSD card)\nInstructions for Flashing Removable eMMC Modules Many Pine64 devices support removable eMMC modules as an alternative boot and storage solution to micro SD cards. These devices include SBCs such as the Pine A64-LTS, ROCK64, ROCKPro64, PINE H64, SOPINE Baseboard, SOPINE Clusterboard, and Quartz64, and devices such as the Pinebook and Pinebook Pro.\nPlease be aware that the Pine A64 (+) does not support an eMMC module, while the Pine A64-LTS does.\nAn eMMC module can be purchased for your device(s) from the PINE64 store. The Pinebook and Pinebook Pro both come with a removable eMMC module pre-installed.\nThe available modules come in four different capacities: 16Gb, 32Gb, 64Gb and 128Gb\nThere are a few ways to flash eMMC modules with the desired OS image. The following sections are a summary of the processes involved in flashing the OS image of your choice to an eMMC module once it has been removed.\nFlashing Using the USB-to-eMMC Adapter (Preferred Way) A USB-to-eMMC adapter is available from purchase from the PINE64 Store making it easy to mount the eMMC module as a volume in your Windows, Mac OS or Linux computer. The eMMC can hence be flashed directly from your computer with any image similarly to a micro SD card.\nThis installation method works for all devices that support eMMC modules regardless of the chipset and it is therefore the preferred way of flashing OS images to eMMC. All available OS images for your device can be installed on the eMMC module this way.\n*This process of flashing an OS image to eMMC is completely identical to imaging micro SD cards, so please read Step-by-Step Instructions to Flashing Micro SD Cards before you begin.\nFor this method you will need the following:\nA Windows, Linux or Mac OS computer A PINE64 eMMC module The PINE64 USB-to-eMMC adapter Flashing eMMC using the adapter\nInsert the the eMMC module into the USB adaptor and plug it into your Windows, Linux or Mac OS computer. It should mount as a regular USB drive and show up in your file manager. If you are using Linux or Mac OS you can either use the dd terminal command or a GUI utility such as Etcher to flash the chosen OS Image to eMMC. If you are using a Windows machine use Etcher or Win32 Disk Imager to flash the OS Image to the eMMC module. Once the image has been flashed using your preferred method safely dismount the USB adapter in your system and unplug it from your computer. Your eMMC is now ready to boot and can be inserted into the eMMC socket on your PINE64 device.\nInstructions for Flashing Integral eMMC As an alternative to a removable eMMC module, some devices come with an integral chip that cannot feasibly be removed. These devices include the PinePhone, PinePhone Pro, PineTab, and PineNote. In addition, the following techniques can also be used to flash a removable eMMC when it is not desirable to open the device, when a eMMC to USB adapter is not available, when a second device is not available, or for some other reason.\nFlashing to eMMC from a SD Boot Some of the available Linux images for Allwinner A64 devices recognise eMMC modules as mounted storage when the device is booted from a micro SD card. This is true for all recent releases of ayufan’s Linux images. In result it is possible to flash an OS image to eMMC using the DD command in terminal or the Disks GUI utility included with the Mate desktop.\nThere are two ways in which an OS image can be flashed from within a micro SD boot:\nVia a script called Pine64_install_to_eMMC.sh found in /usr/local/sbin. This script will install an Ubuntu Mate OS installation (identical to the on running on the SD) to the eMMC module. To execute the script navigate to its location in the terminal and type sudo ./Pine64_install_to_eMMC.sh. Follow the instructions. By manually downloading and flashing a OS image for your device using DD or the Disk GUI. This way of flashing an OS image to the eMMC is identical to that used on a Linux computer (e.g. for flashing an OS image to a SD card). For more information on how the process works please see the detailed guide on imaging OS images to SD card on Linux. For the latter of the two methods here is a summary of the process:\nFlash an OS image which recognizes eMMC as mounted storage to a micro SD card. For details on how to flash a micro SD card see section 3 Insert both the micro SD and eMMC module into your device and power it on. Once the PINE64 device boots from micro SD, you cannot flash the contents of the micro SD card to the eMMC while you are running from the micro SD so you will actually use this session to download an OS image to flash to the eMMC. Depending on the distribution this may be the same image you just flashed to the micro SD card and booted from. Once the OS image downloads check in terminal or in Disks utility the eMMC’s mounting location and unmount all but \u0026ldquo;/\u0026rdquo;. Example command to show disks and mounts: $ lsblk Use the DD command or Disks utility to flash the downloaded image to the eMMC module. Note your output device may be mmcblk1 or mmcblk2, use the command above to verify the correct one. Example DD command: $ xzcat imagename.img.xz | sudo dd of=/dev/mmcblk1 bs=1M status=progress conv=fsync Once the flashing process is completed power down your device and remove the micro SD card. You should now be able to power your device back up and it will boot the image flashed to the eMMC module. Flashing to eMMC using FEL (Allwinner A64 Devices Only) Under particular circumstances it may prove difficult to rely on a SD card to flash an OS image to an Allwinner A64 device. In such instances OS images can be directly flashed by means of entering into FEL mode. FEL is a low-level subroutine in the BootROM, and the process of enabling FEL differs from one device to another. To learn more about FEL please refer to the SUNXI Wiki section dedicated to the subject.\nThe process of flashing via FEL is more complex than utilising a micro SD and is therefore better suited for proficient and advanced users.\nFor the process of flashing an image to the eMMC on a device in FEL mode you will need:\nA computer running Mac OS or Linux An OTG USB A-to-A cable To enter FEL you will need to:\nOn the Pinebook, power down the Pinebook and remove the PSU, unscrew the bottom of the case and press down the FEL button on the PCB (REF). Plug in the OTG USB A-to-A cord to your computer and the OTG USB port on the Pinebook (on the right facing an open case). Reinsert the PSU cord and press the power button with the FEL button pressed down. Release the FEL button after 3 seconds. On the Pine A64(+) power down the board and remove the micro SD card and power cord. Plug in the OTG USB A-to-A cord to your computer and the OTG USB port on the Pine A64 (+) and SoPine (top port). Power on the device and immediately after insert a micro SD card with FEL code. You can check if your device entered FEL mode using lsusb command in terminal. It should be listed as a device on the USB Bus.\nThe next step is to mount your device so that your computer recognizes the eMMC as mass storage (UMS). A script called boot-tools streamlining this process is available thanks to ayufan on his github. Follow his instructions and in terminal perform the following steps:\ngit clone https://github.com/ayufan-pine64/boot-tools.git cd boot-tools make pinebook_ums or\nmake pine64_ums Once your device mounts as UMS it will appear in your file manager. In CLI you can check if the storage is listed using fdisk -l.\nThis process of flashing an OS image to eMMC with the device in FEL mode and mounted as UMS is literally identical to imaging micro SD cards, so please read Step-by-Step Instructions to Flashing Micro SD Cards and follow the procedure. You can use DD or Disks/ Disk Utility to flash the OS image directly to your device’s eMMC.\nOnce the flashing process is completed, power down your device, remove the A-to-A USB OTG cable and after reapply power to boot your device from eMMC.\nFlashing to eMMC using Rockchip Tools (Rock64 Only) Rockchip has a different boot hierarchy to Allwinner’s devices making it much more difficult to flash OS images using the micro SD-to-eMMC scheme used on A64. There are, however, flashing tools that make it possible to flash directly to eMMC on a Rock64 in loader and MarkROM modes.\nTo flash to the eMMC module using these tools you will need the following:\nA Windows, Mac OS or Linux computer An A-to-A USB cable The Rock64 board with the eMMC module inserted into the socket Using Windows 7/8.1/10:\nYou will need to download the DriverAssistant aka Rockchip driver as well as the AndroidTool_Release used for flashing OS images. Having completed the downloads extract both archives.The Rockchip driver needs to be installed prior to using the AndroidTool utility.\nHaving installed the driver and flashing utility, follow these steps:\nMake sure that eMMC is inserted into the slot on the Rock64 Place a jumper / short out the eMMC pins on the board (consult this PDF document for more details. Insert one end of the A-to-A cable into your Windows PC and the other into your Rock64 OTG USB port (top) Inset the power cord into the Rock64 Start AndroidTool; make sure that it reports \u0026lsquo;Found One Maskrom Device\u0026rsquo; (if it does not recognise your device, please repeat previous steps) Select either the latest Stock Android build or ayufan’s Android TV build with the suffic -update. Download and the extract the chosen image. In AndroidTool press the firmware tab and navigate to where you extracted the OS image and select it. Press the upgrade tab. You will be prompted when the flashing process is completed. Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. Using Linux or Mac OS:\nMake sure that eMMC is inserted into the slot on the Rock64 Download latest stable or pre-release (to be used at own risk) Android TV OS image from ayufan’s github. The image you wish to download is the one without a suffix; without -update or -raw in the OS image title. In terminal, download rkflashtool following instructions on ayufan’s github Extract the folder containing partitions of the OS image and place the script listed on ayufan’s github in the folder Hold down the recovery button on the board Insert one end of the A-to-A cable into your Mac OS or Linux PC and the other into your Rock64 OTG USB port (top) Inset the power cord into the Rock64 Check that your device is in loader mode by typing in the terminal sudo rkflashtool n. If rkflashtool doesn’t detect the Rock64 please repeat last 3 steps In terminal navigate to where you extracted the Android folder containing the OS partitions and the script and type rkinstall; this will install the community Android TV build to eMMC. Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. Flashing to eMMC Android \u0026lsquo;Update\u0026rsquo; OS Images on Linux (Rock64 Only) It is possible to flash Android \u0026lsquo;update\u0026rsquo; images to the Rock64 eMMC using a Linux PC. This process requires a tool called Linux Upgrade Tool and the full documentation of its functions can be found here. Make sure that you download v1.2 or newer, as older tools do not support the RK3328 used on the Rock64.\nTo flash the eMMC module using this method you will need the following:\nA Linux computer An A-to-A USB cable The Rock64 board with the eMMC module inserted into the socket Start by downloading an Android update image for the Rock64. Both PINE64 and Ayufan provide such images for the board - and they are clearly designated as such on both this WiKi’s download section and on ayufan’s github. For the purpose of this example, I’ll use the ayufan’s ATV community build:\nDownload latest stable or pre-release (to be used at own risk) Android TV OS image from ayufan’s github. The image you wish to download is the one with update suffix. You need to rename the downloaded image to update.img. Download the Linux Upgrade Tool to your Linux PC and unarchived it. Extract the archived update Android OS image somewhere where you will remember its path Hold down the recovery button on the board Insert one end of the A-to-A cable into your Mac OS or Linux PC and the other into your Rock64 OTG USB port (top) Inset the power cord into the Rock64 In terminal, navigate to where you extracted Rockchip Update Tool and issue the following command substituting the correct path for where the Android Update OS Image is located: sudo ./upgrade_tool uf /path/to/update.img\nWait as the utility installs Android to eMMC on your Rock64. Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. Flashing u-boot to SPI Flash Some of PINE64 devices, such as the Rock64 and SOPine, are equipped with SPI Flash. This allows users to flash u-boot onto the SPI and boot from an external USB 2.0 or USB 3.0 SSD/HDD/thumb-drive, thereby forgoing use of eMMC or microSD card.\nTo find out more about which images can used in conjunction for SPI booting please see ayufan’s github.\nWriting u-boot to SPI Flash can be achieved in two ways:\nUsing a Stand-Alone Image to Write u-boot to SPI This may be the simplest method of flashing u-boot to SPI. Download a dedicated image labelled u-boot-flash-spi.img.xz from ayufan’s github and flash it to a microSD card, the same as you would with any OS image (to learn how to flash OS images to microSD please follow steps outlined in Section 3.\nHaving flashed the image follow these steps:\nInsert the SD into the ROCK64 Remove all other peripherals from the board Make sure that the eMMC module is disconnected from the board Apply power to the ROCK64 Wait (few seconds) until the the LEDs on the board will blink continually Power off the board. The board is now ready to boot from USB 2.0/3.0 storage.\nUsing a Script on Linux OS Images Most of recent (newer than 0.6.9) Linux OS images contain a script called rock64_write_spi_flash.sh, which is found in /usr/local/sbin directory. To run the script you will first need to flash a Linux OS image to a micro SD card (to learn how to flash OS images to micro SD please following steps outlined in Section 3). Before proceeding make sure that the eMMC module is disconnected from the board. Once you have booted into Linux on your PINE64 device all you have to do is run the aforementioned script using this command:\nsudo ./rock64_write_spi_flash.sh\nOnce the script finishes its operation, power off your board and remove the microSD card. The board is now ready to boot from USB 2.0/3.0 storage.\nErasing and Rewriting SPI There are two ways of removing u-boot from SPI. You can either download u-boot-flash-spi.img.xz from ayufan’s github or use a script found on Linux OS images titled:rock64_erase_spi_flash.sh. Follow the instructions in the previous sub-sections for the chosen method of removing u-boot from SPI; the instructions are are identical, as the process of erasing u-boot is the exact opposite of flashing it.\nYou can also erase SPI manually. To do so, you need to download mtd-utils. on Debian or Ubuntu follow these instructions:\nsudo apt-get install mtd-utils\nsudo flash_eraseall /dev/mtd0\nBooting an OS image from USB 2.0/3.0 Storage To boot an OS image from USB 2.0/3.0 Storage such as a SSD/HDD or a thumbdrive you first need to have u-boot written to your SPI flash. Please follow the instructions in the previous sub-sections to learn how to write u-boot to SPI on your PINE64 device.\nOnce you have u-boot on your SPI, the process of booting is very similar to booting from microSD or eMMC.\nDownload one of the supported OS images for your PINE64 device Flash the OS image to your USB 2.0/USB 3.0 storage device (to learn how to flash OS images please following steps outlined in Section 3 The instructions are identical for all types of storage, including USB 2.0/USB 3.0 HDDs and thumb-drives.) Insert the USB storage device with the flashed OS image into one of the USB ports on your PINE64 device Apply power If you have followed all the steps correctly, the board should boot from your USB 2.0/3.0 storage device.\nTroubleshooting Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. A number of things can prevent the PINE64 board from booting up properly. The most common culprits of a failed boot are: (to find out more click here)\nSubpar or counterfeit microSD card Subpar Power Supply High resistance (thin) or a very long microUSB cable Failed imaging of the microSD card or eMMC module Make sure to have the newest version of the OS image your are running. On Allwinner A64 devices running Linux you can update the kernel and U-Boot using scripts located in the following directory: /usr/local/sbin\nTo navigate to the directory type (in terminal): cd /usr/local/sbin You list all the available scripts by typing (in terminal): ls To run the script required update script run the following command: sudo ./update_script.sh (substitute the relevant update script for update_script) Troubleshooting Step by Step\nFollow these steps to determine the cause of your problem:\nCheck your PSU and microUSB cable ratings Download and image a base image of Linux Plug in power and Ethernet into your PINE64 device Watch Ethernet port LED activity Check your router for your device’s IP Attempt to ssh into your device’s from your computer If your PSU and microUSB meet the criteria, and you have correctly followed the instructions to image your card and power on the board, but you are not seeing any LED activity and cannot ssh into your device then either the imaging process failed (possibly due to a subpar microSD) OR the PSU / microUSB cable is/are faulty.\nIf your PSU and microUSB meet the criteria, and you have correctly imaged the OS to your card and power on the board and your can ssh into your PINE A64(+) but get no video feed, then it’s likely that the native resolution of your monitor/TV is not supported.\nIf neither of the above mentioned scenarios fits the problem you are facing, please consult this thread (thanks to Ghost for compiling the list): https://forum.pine64.org/showthread.php?tid=680\n","permalink":"/documentation/Introduction/Getting_started/","tags":null,"title":"Getting started"},{"categories":null,"contents":"The PineTab2 box contains two smaller boxes.\nThe first box includes:\nthe PineTab2, a short user guide, a power cable and the UART adapter. Note that the UART adapter is in the same package as the power cable in a second compartment and can be a bit hidden. The second box has the keyboard in it.\nFirst start The PineTab2 can be started by pressing and holding the power button for two seconds. The device is initialized at the first boot and will power-cycle while the partition table is populated.\nInfo If the initialization process is interrupted it might lead to a corrupted operating system installation. In that case reinstall the operating system as explained below. The PineTab2 ships with DanctNix Arch Linux and comes with a pre-set user and the default password 123456.\nDefault credentials alarm 123456 You can create a new user and set your own password after the initial boot. To do so, go to system settings -\u0026gt; users and create a new profile using your preferred name and password.\nKeyboard cover When connecting the keyboard to the Pinetab2 ensure that the camera and the golden pogo pin connectors are correctly aligned. The external keyboard has 5 connection pins (the golden pins). four are standard USB connectors and one is used to detect that the keyboard is connected.\nThe backlight can be changed with the key combination Pinekey + Ctrl (right).\n","permalink":"/documentation/PineTab2/Getting_started/","tags":null,"title":"Getting started"},{"categories":null,"contents":"Read these first:\nDevkit wiring Reprogramming the PineTime (development kit) The frequently asked question can be found in the article FAQ.\n","permalink":"/documentation/PineTime/Getting_started/","tags":null,"title":"Getting started"},{"categories":null,"contents":" Flashing the device Natively the board only supports booting the platform firmware from SPI, the eMMC or a microSD card, see boot order. The platform firmware loaded from there (U-Boot, EDK2, \u0026hellip;) may then allow loading kernels from additional storage mediums or even the network, and they will have their own boot order.\nThe board can be booted by flashing your chosen operating system to a microSD card using another device and inserting the microSD card into the Quartz64, see the article Getting started. Flashing the eMMC is possible by booting an operating system from the microSD card and overwriting the eMMC from within the booted operating system, or by using the USB eMMC adapter.\nBoot order The hardware boot order of the Quartz64 is:\nSPI NOR flash SPI NAND flash eMMC microSD card ","permalink":"/documentation/Quartz64/Getting_started/","tags":null,"title":"Getting started"},{"categories":null,"contents":"This section gives important information to get the board up and running.\nVideo Playback Hardware video acceleration is supported in recent kernels and user needs only to install the relevant Mesa packages/ports, specifically the Mesa DRI drivers for Mali GPUs (Midgard/Bifrost). One can confirm via software glxinfo, or having the library file such as \u0026hellip;/lib/dri/panfrost_dri.so.\nAyufan has some old documentation on video playback here. For your ROCKPro64 the install should be\nsudo apt-get install ffmpeg mpv libmali-rk-midgard-t86x-r14p0-gbm\n(These modules are included in the Ayufan desktop releases.) At which stage rkmpv myvideo.mp4 will play a fullscreen, hardware assisted, version of your video. rkmpv is at /usr/local/bin/rkmpv\nUsing an NVMe Disk as rootfs Forum member Bullet64 has documented how to move rootfs to an NVMe disk. This is useful until we get a full SPI option to boot from the NVMe.\nSetup a Serial Console (UART2) Warning RockPro64 is designed to use 3VDC3A (3 Volts Direct Current 3 Ampere) for the connection, using 5VDC and more might damage the board! To use Serial Console you will a need operating system that supports it on your RockPro64, by default the serial console is provided for baud 9 600 which is far too slow for rockpro64 so consider using 1 500 000 (1.5Mbps) instead IF your serial console device supports it (many doesn’t which results in their inability to use the console).\nWarning Do not connect RxD (pin 10) until the U-Boot SPL is running (see RK3399 boot sequence) or the SPL will not start.\nTo avoid this issue, a simple Serial Buffer Circuit can be installed between the RockPro64 and the serial adapter.\nIn terms of connections you need to perform the following from your serial console-capable device e.g. Pine64’s Woodpecker available in store:\nGND \u0026lt;-\u0026gt; GND (pin 6) RxD \u0026lt;-\u0026gt; TxD (pin 8) TxD \u0026lt;-\u0026gt; RxD (pin 10) After the configuration of your preferred operating system you can connect to the serial console using any of these commands:\n$ screen /dev/ttyUSB0 1500000 $ picocom /dev/ttyUSB0 -b 1500000 $ minicom -D /dev/ttyUSB0 -b 1500000 Note You might need a root permission if your user is not in the appropriate user-group e.g. dialup on GNU/Linux Alternatively there is a detailed guide on forums: https://forum.pine64.org/showthread.php?tid=6387\nGNU/Linux:\nWith GNU/Linux on your RockPro64 the built-in support for serial console can be enabled by parsing parse e.g. console=ttyS2,1500000n8 in the kernel command line, many distributions make this available by default, but consider verifying the contents of /boot/extlinux/extlinux.conf if you encounter issues. NOTE: the n8 in the kernel argument means no parity, 8 bits per character Booting from USB or PXE The default choice of boot device is first eMMC (if present) then SDcard. See ROCKPro64 under \u0026ldquo;jumpers\u0026rdquo; for details on adjusting this sequence.\nIt is possible to flash the SPI to extend the options for boot devices to USB drives or PXE. The preferred method is now the rock64_write_spi_flash.sh script (see useful scripts above).\nBackground info and historic details of this usage can be found here.\nBooting from SPI using u-boot Warning idbloader is not open-source Always be prepared to recover from a broken SPI boot BEFORE flashing or you will end up with a broken boot.\nIn general the recovery is killswitching SPI through shorting pins 23 \u0026lt;-\u0026gt; 25 together and then loading u-boot from a storage device e.g. SD-card or eMMC where majority of GNU distributions e.g. Manjaro usually have u-boot packaged with the provided images.\nFollow instructions in https://github.com/sigmaris/u-boot/wiki/Flashing-U-Boot-to-SPI#instructions-for-rockpro64\nBoot sequence The RockPro64 boot sequence has been documented here by sigmaris.\nOTG Mode You can boot your ROCKPro64 into OTG mode with the use of the Recover button (see switch 28 under Layout#Switches). Note that there are 2 OTG ports on your ROCKPro64: the type-C USB 3 socket is definitely one. From the schematic it appears the USB 3 (type A) socket is the other, but this has yet to be confirmed.\nThe method is to power off the board. Then push and hold the Recover button and push and release the Power button.\nIf you have an Ayufan bootable image in either the SD-card or eMMC then there are 4 OTG modes described here including Android fastboot, RockUSB and MaskROM modes. Releasing the Recover button as soon as the white LED lights counts as 1 blink. Keeping it pressed you will get 2 blinks of the white LED etc. Once the board enters OTG mode the red LED will be lit. In mode 1 the boot and linux-root partitions of the card with the Ayufan image (partitions 6 \u0026amp; 7 of a Linux installation) are made available as devices. In all cases the USB device made available at the host has device ID 18d1:d00d. If you do not have an Ayufan image in either the SD-card or the eMMC, then neither white nor red LEDs will light, but the board will enter MaskROM mode where the USB device made available at the host has device ID 2207:330c. NVMe Drives Please be aware that the PINE64 SSD interface card is intended for use with NVMe devices. These can be identified by the fact they have a single (Key M) notch, e. g. the WD Black devices.\nWhile M2/NGFF SATA devices (with a Key B notch, typically have Key M as well) will physically fit, they will not work. e. g. WD Blue devices.\nSATA Drives SATA drives can be connected directly via the ROCKPro64 PCIe interface card. Please note the card does not include the power cable - that is a separate item. Equally you must be aware that connecting SATA drives in this manner means they will be drawing power from your ROCKPro64 - please ensure you are using a 5A or better power supply.\nExplainingComputers did a YouTube ROCKPro64 PCIe SATA card review and tests using a Ubuntu console and OpenMediaVault.\nWi-Fi \u0026amp; Bluetooth Module If you have bought the Wi-Fi and Bluetooth module from the Pine store then instructions for connecting it can be found on the accessories page. Please note that the 0.7.9 Ayufan’s Linux releases (August 2018) have deliberately DISABLED support for this module in the search for stability. It can be tested and used with the Android image.\nIt can also be used on Manjaro by installing ap6256-firmware and wireless-regdb packages.\n7\u0026quot; LCD Touch Screen Instructions for connecting the LCD touch screen from the Pineare on the accessories page.\nNote at present (August 2018) this screen is only supported by the Android image.\nWarning When using the touchscreen ensure the cables are properly connected and tightened down and that you do not let the metal backplate touch the SBC RTC Battery Backup The Pine store has a couple of options for RTC battery backups: a AAA version here or a CR-2032 version here.. For the ROCKPro64, the backup plugs into the RTC connector, number 6 in the board layout diagram above, next to the USB3 and case screw point.\n","permalink":"/documentation/ROCKPro64/Getting_started/","tags":null,"title":"Getting started"},{"categories":null,"contents":" Important note for buyers after October 2024 Note Dear new PineNote users, you may have noticed that suspend/resume is not working on your new PineNote! You may also noticed that using rkdeveloptool is not possible because you cannot trigger maskrom mode using the magnet method.\nThese issues are caused by differences in testing procedures of the shipped Debian-based image, and factory flashing procedures. Namely, the factory used a Windows-based flashing system, and it turned out that this system does overwrite crucial parts of the u-boot bootloader with same only-partially working data. The effect is that the PineNote will boot, but not suspend.\nFixing the issue Fortunately the PineNote ships with a complete set of bootloader files and fixing the issue is a matter of a few shell commands:, which are flashing a working U-Boot to get MASKROM with magnet working on PineNote:\nLogin via UART-adapter or ssh, or use the Gnome-Terminal (found in the quick slots of the dashboard - switch to BW+Dithering mode for faster screen responses):\nusername: user password: 1234 Gain root access by executing sudo su - root (the password is: 1234).\nExecute the following (two) commands (as root):\ncd /root/uboot bash install_stable_1056mhz_uboot.sh Turn off the PineNote by executing init 0\nDone. The pinenote should now have a proper U-Boot installed, with rkdeveloptool-support and suspend.\nThe output of step 3 should read:\nroot@pinenote:~/uboot# bash install_stable_1056mhz_uboot.sh 568+0 records in 568+0 records out 290816 bytes (291 kB, 284 KiB) copied, 0.00419942 s, 69.3 MB/s 8192+0 records in 8192+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.447542 s, 9.4 MB/s If not errors were reported, then the 1056 MHz u-boot/ram-blob was installed Please reboot root@pinenote:~/uboot# init 0 What\u0026rsquo;s inside the PineNote package Included in the box are:\nPineNote Stylus USB-C to USB-A cable (only pre 2024 PineNotes) USB-C to Micro-USB cable - specifically for the stylus UART Dongle - for UART connectivity Foldable cover Installing the foldable cover The foldable cover can be applied to the PineNote in these simple steps:\nStep 1: Remove the protective plastic from the adhesive strip.\nStep 2: The black adhesive strip should now be exposed.\nStep 3: Carefully place the PineNote on top of the side with the adhesive strip, ensuring that the corners and edges are properly aligned with the device.\n","permalink":"/documentation/PineNote/Getting_started/","tags":null,"title":"Getting Started"},{"categories":null,"contents":"GPIO header pin table:\nPin Name Physical Pin (Designation) Linux GPIO Alternate Func 1 Alternate Func 2 Interrupt 1 3V3 DCDC3 2 5V PS 3 TWI1_SDA PB9 41 TWI1_SDA UART0_RX PB_EINT9 4 5V PS 5 TWI1_SCK PB8 40 TWI1_SCK UART0_TX PB_EINT8 6 GND GND 7 PWM1 PB5 37 PWM1 PB_EINT5 8 UART_TXD PB0 32 UART2_TXD PB_EINT0 9 GND GND 10 UART_RXD PB1 33 UART2_RX PB_EINT1 11 GPIO17 PC5 69 SDC2_D2 12 GPIO18 PC6 70 SDC2_D3 13 GPIO27 PC7 71 SDC2_D4 14 GND GND 15 GPIO22 PC8 72 SDC2_D5 16 GPIO23 PC9 73 SDC2_D6 17 3V3 DCDC3 18 GPIO24 PC10 74 SDC2_D7 19 SPI-MOSI PC3 67 SPI0_MOSI SDC2_D0 20 GND GND 21 SPI-MISO PC0 64 SPI0_MISO SDC2_CLK 22 PWM0 PB4 36 PWM0 PB_EINT4 23 SPI-CLK PC1 65 SPI0_CLK SDC2_CMD 24 SPI_CE0 PC2 66 SPI0_CS SDC2_RST 25 GND GND 26 SPI_CE1 PC4 68 SDC2_D1 Important notes:\nFirst ball is marked with white dot SPI is multiplexed also with SPI flash SPI_CE1 is normal GPIO pin\u0026quot; ","permalink":"/documentation/PineCube/GPIO/","tags":null,"title":"GPIO"},{"categories":null,"contents":" GPIO Pins Assigned To Pin Nr. Pin Nr. Assigned To 3.3 V 1 2 5 V GPIO1_C4 (I2C8_SDA) ^a^ 3 4 5 V GPIO1_C5 (I2C8_SCL) ^a^ 5 6 GND GPIO4_D0 (CPU_GPCLK) 7 8 GPIO4_C4 (UART2_TX) GND 9 10 GPIO4_C3 (UART2_RX) GPIO1_C6 11 12 GPIO3_D0 (I2S0_CLK) GPIO1_C2 13 14 GND GPIO1_A1 15 16 GPIO1_A4 3.3 V 17 18 GPIO4_C5 [SPDIF] [UART4_TX] GPIO1_B0 (SPI1_TXD) 19 20 GND [UART4_RX] GPIO1_A7 (SPI1_RXD) 21 22 GPIO4_D1 GPIO1_B1 (SPI1_CLK) 23 24 GPIO1_B2 (SPI1_CSN0) GND 25 26 GPIO1_B5 GPIO1_B3 (I2C4_SDA) 27 28 GPIO1_B4 (I2C4_SCL) GPIO4_D3 29 30 GND GPIO4_D4 31 32 GPIO3_D4 (I2S0_SDI1SDO3) GPIO3_D5 (I2S0_SDI2SDO2) 33 34 GND GPIO3_D2 (I2S0_LRCKTX) 35 36 GPIO3_D6 (I2S0_SDI3SDO1) GPIO3_D1 (I2S0_LRCKRX) 37 38 GPIO3_D3 (I2S0_SDI0) GND 39 40 GPIO3_D7 (I2S0_SDO0) Notes:\npulled high to 3.3V through 2.2kOhm resistor Linux /dev/gpiochip Assignments Pin Nr. Chip Line 3 1 20 5 1 21 7 4 24 8 4 20 10 4 19 11 1 22 12 3 24 13 1 18 15 1 1 16 1 4 18 4 21 19 1 8 21 1 7 22 4 25 23 1 9 24 1 10 26 1 13 27 1 11 28 1 12 29 4 27 31 4 28 32 3 28 33 3 29 35 3 26 36 3 30 37 3 25 38 3 27 40 3 31 On Linux, using the new /dev/gpiochip API, the _n_ in GPIO_n___XX_ appears to correlate to the number of the /dev/gpiochip_n_, and the _XX_ to the definition RK_P_XX_ of lines in include/dt-bindings/pinctrl/rockchip.h of the Linux kernel source. Having these named in the dts would be nice.\nYou can use libgpiod to drive them, and test them with the included tools (gpioinfo, gpioset, \u0026hellip;)\nFor example, gpioset 4 25=1 (run as root) would turn pin 22 on. Do beware that poking the wrong GPIO pin can lock up your system.\nThe conversion table at right is also available as a C header file.\n","permalink":"/documentation/ROCKPro64/Board/GPIOs/","tags":null,"title":"GPIOs"},{"categories":null,"contents":"This article is a list of convenient links to guides on soldering. Although it’s not directly related to Pinecil hardware, many PINE64 members ask for this kind of information in daily live chat. If you don’t find something here, then try an Internet search as this is just a starting point for convenience.\nGeneral soldering guides Why have different tips? Easier method to solder SMD, and a clever Cleaning method How to Solder SMD \u0026amp; Small Components - Mr. Solder Pace Basic Soldering lesson 1-9 How to Desolder/Correct mistakes Mr. Solderfix - Remove Components Ultimate soldering guide Should I switch to Lead-free solder? Beginner’s Guide to Soldering - Mr. Solder Fine SMD Soldering Comic book - Soldering Does solder type and flux matter? Does Solder quality matter? When to use Flux 63/37 or 60/40 Solder? How to keep the tip clean? Clean \u0026amp; Care for Tips How to Clean Soldering Tips Sodering Tip Maintenance What temperature should I use? General Formula: add 120°C to the melting point listed on the solder label, and adjust up/down as needed for different tasks. Example: the solder says 220°C melt point, then 220 + 120 = 340 °C\nOne could also try these common working temperatures below, start lower and increment by 5°C until you get a comfortable working temperature (thicker wires \u0026amp; situations dictate more or less).\nCommon working temperatures if direct data for the solder can not be found: # For Lead solder: 300°C - 320°C # For No-lead solder: 350°C - 365°C Another method is an Internet search to find a chart like below for your specific type of solder alloy: Alloy Temperature Chart - Kester Adding a small amount of solder to your tip before starting increases the thermal mass of the tip and could help instead of cranking the temperature super high (which causes other problems). See the soldering guides above for demonstrations of this in several articles and videos. Using the Conical tip How do I use the conical tip that comes default with Pinecil to get enough heat transfer?\nUse the side of the tip to heat the pin. Do not hold it vertically like a pen because the very end of the tip has little heat mass. See https://cdn.sparkfun.com/assets/learn_tutorials/5/8/4/SolderingAdvice_1edit.png Correct amount of solder and solder flow. See https://cdn.sparkfun.com/assets/learn_tutorials/5/8/4/SolderingAdvice_2.png ","permalink":"/documentation/Pinecil/Guides_to_soldering/","tags":null,"title":"Guides to Soldering"},{"categories":null,"contents":"Instructions to install a hall effect sensor (HES) on the Pinecil V1 and V2.\nThe Hall Effect Sensor (HES) is an optional end user installed sensor that activates to put Pinecil to sleep when it enters a holder or stand. This requires a neodymium magnet attached to the stand. The closer the HES in the Pinecil is to the magnet, the more likely the HES will activate to enter sleep mode. This adds a feature to Pinecil that is often seen in high end pro irons.\nTools and Supplies Order a Hall Effect Sensor (SI7210-B-00 here), also at Digikey and Mouser. Ordering 2-3 might be a good idea in case the first one is damaged during install (if all goes well, one could mail the extras to a friend or another Pine64 member in the community chat ;). Jeweler’s magnifying glasses or magnifying lamp or a microscope is recommended as the SOT23 chip is very small. Borrow a second soldering iron (this is when 2x Pinecils is a good idea). Get some neodymium magnets, just two 8x2.7mm at 8:00PM and 12:00PM on the stand could be enough. Experimentation is needed. Start with just one small magnet and increase the number placed around the stand until 360° sleep is activated when the Pinecil hits the stand. Reference [[Pinecil:_How_to_Repair#Schematics_and_Board_Data | Schematics are here]] (search for U14). Videos Easy trick to Open Pinecil. How to install Hall Sensor video. Installation Updating to the newest firmware before installing is recommended, see the Firmware article. These instructions are for 2.18 or newer firmware. The HES is located at the very front of the Pinecil, tip end, see PCB images here. Once it is soldered, cleaned, and assembled, check the sleep menu, a new hall sensitivity option appears. See this article on how to set up the sensitivity settings on the firmware menu (Ralim’s IronOS). Once you change the Sleep menu \u0026gt; Hall sensitivity to what you like, then scroll back to the main screen in order for the setting to be saved and persist on reboot. Note: IronOS firmware does not flash a setting change until one scrolls out of the sub-menu back to the main screen. This is to reduce the total number of flashes done as several settings might be changed in one section (number of flashes is not unlimited; most users will not encounter the maximum allowed flashes on normal use over years). Hints Try not to overheat the sensor while soldering as that could damage it and even cause a leg to fall off. This is a small SOT23 chip. Tacking one pin on the 2-pin side helps to hold it in place before soldering the rest of the sensor. It is recommended to solder this with an iron with a small tip instead of using hot air (depends on your experience with hot air). See photos below, use kapton tape to protect nearby components: the 3 via holes above the 3-pin side, and the NTC temperature sensor on the other side. If too much heat is applied, it could damage the pcb, and/or affect the I2C and cause screen corruption. Apply generous flux to the area. If lead solder is being used, it is recommended to remove some of the existing no-lead solder that is already on the U14 pads. After the HES is soldered, clean the area completely with 99% isopropyl alcohol (IPA) and a soft toothbrush or small paint brush and dry before assembly. Air/hair dryer could be used to blow out some of the wet IPA. Not cleaning it well enough could cause some I2C noise on the screen. Try to keep IPA/alcohol away from OLED screens. If the stand/holder is not metal, tape magnets near where the Pinecil enters the hole in the holder to test out good locations. Hot glue is another option. When closing the handle, inspect that the the seam line is fully snaped closed; avoid pressing the screen. Images Before installation, location at U14: After installation: Only needs small amount of solder: Kapton tape/protect the 3 Via holes above 3-pin side,title=\u0026ldquo;Kapton tape/protect the 3 Via holes above 3-pin side\u0026rdquo;: Kapton tape/protect the NTC sensor on opposite side of V2 (V1 does not have this): ","permalink":"/documentation/Pinecil/Modifications/Hall_effect_sensor/","tags":null,"title":"Hall Effect Sensor"},{"categories":null,"contents":" Display Note: The factory-default software on the PineTime does not auto-detect the display being disconnected when it has already booted. That can cause garbled output, to fix it just restart the PineTime.\nThe display is driven using the ST7789 display controller. Use the following pins to drive the screen:\nPineTime pin ST7789 pin LCD_SCK (P0.02) SPI clock LCD_SDI (P0.03) SPI MOSI LCD_RS (P0.18) Command/Data pin (CD) LCD_CS (P0.25) Chip select LCD_RESET (P0.26) Display reset LCD_BACKLIGHT_{LOW,MID,HIGH} Backlight (active low) Notes:\nChip select must be held low while driving the display. It must be high when using other SPI devices on the same bus (such as external flash storage) so that the display controller won’t respond to the wrong commands. SPI must be used in mode 3. Mode 0 (the default) won’t work. LCD_BACKLIGHT_* is used to enable the backlight. Set at least one to low to see anything on the screen. Use SPI at 8MHz (the fastest clock available on the nRF52832) because otherwise refreshing will be super slow. References:\nAdafruit ST7789 driver in cpp\nBattery measurement Reading whether the PineTime has power attached is easy: simply read the charge indication pin (P0.12). When it is high it is running on battery, when it is low it is charging.\nReading the battery voltage is a bit harder. For that you can use the battery voltage pin on P0.31 (AIN7). The returned value is 12 bits, which means it is 0..4095. You can get the measured voltage with the following formula, assuming a reference voltage of 3.3V (this is configurable in the ADC):\nadcVoltage = adcValue / (4095 / 3.3) The measured voltage is actually half of the actual battery voltage, because the ADC is connected between a voltage divider where both resistors are 1MΩ. This can be corrected by multiplying the value:\nbatteryVoltage = adcValue * 2 / (4095 / 3.3) It’s often better to avoid floating point values on embedded systems and in this case there is no reason to use float at all, we can just represent the value in millivolts. Therefore the formula can be simplified to:\nbatteryVoltage = adcValue * 2000 / (4095 / 3.3) batteryVoltage = adcValue * 2000 / 1241 Converting this voltage to an estimated capacity in percent requires a more complicated algorithm, because Lithium-ion batteries have a non-linear discharge curve.\nButton The button on the side of the PineTime is disabled by default. To enable it, drive the button out pin (P0.15) high.\nWhile enabled, the button in pin (P0.13) will be high when the button is pressed, and low when it is not pressed.\nNote the button consumes around 34µA when P0.15 is left high. To reduce current consumption, set it to low most of the time and only set it to high shortly before reading it. The button needs a short time to give good outputs though, setting P0.15 high at least four times in a row seems to result in enough delay that P0.13 has a stable output. Touch panel The touch panel is controlled by a Hynitron CST816S chips. Unfortunately, there is not much information about this chip on the internet apart from the datasheet below and a reference driver. This is enough to implement a basic driver, but crucial information needed to implement advanced functionalities are missing (I²C protocol and registers, timings, power modes).\nPins P0.10=== What do you need to know? If you followed Dorian’s guide to get here and felt semi-comfortable, you’ll be fine. This is no more complicated than that. If you are intimidated, that’s okay! I’ll still encourage you to try. You will learn a lot, just be patient and don’t put any data on your PineNote that you wouldn’t be okay losing. If you run into trouble, ask for help in the Discord / Matrix. Please try to solve problems on your own first, and then ask for help \u0026ndash; if nobody replies, please be patient and ask again soon.\nReset\nP0.28: Interrupt (signal to the CPU when a touch event is detected) P0.06: I²C SDA P0.07: I²C SCL I²C Device address: 0x15 Frequency: from 10Khz to 400Khz Note The controller goes to sleep when no event is detected. In sleep mode, the controller does not communicate on the I²C bus (it appears disconnected). So, for the communication to work, you need to tap on the screen so that the chip wakes-up. Note The I²C bus, also known as TWI bus has known issues, make sure to write your TWI driver with timeouts. Touch events Touch information is available from the 63 first registers of the controller. Remember: the device is in sleep mode when no touch event is detected. It means that you can read the register only when the touch controller detected an event. You can use the Interrupt pin to detect such event in the software.\nThese 63 bytes contain up to 10 touch point (X, Y, event type, pressure,\u0026hellip;) :\nByte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0 0 ? 1 GestureID: (Gesture code ,\n0x00: no gesture,\n0x01: Slide down,\n0x02: Slide up,\n0x03: Slide left,\n0x04: Slide right,\n0x05: Single click,\n0x0B: Double click,\n0x0C: Long press)\n2 ? Number of touch points 3 Event (0 = Down, 1 = Up, 2 = Contact) ? X (MSB) coordinate 4 X (LSB) coordinate 5 ? Touch ID Y (MSB) coordinate 6 Y (LSB) coordinate 7 Pressure (?) 8 Miscellaneous (?) Bytes 3 to 8 are repeated 10 times (10*6 + 3 = 63 bytes).\nNOTES\nThe touch controller seems to report only 1 touch point Fields X, Y, Number of touch points and touch ID are updated. The others are always 0. Registers The reference driver specifies some registers and value, but there is no information about them:\nRegister Address Description HYN_REG_INT_CNT 0x8F HYN_REG_FLOW_WORK_CNT 0x91 HYN_REG_WORKMODE 0x00 0 = WORK, 0x40 = FACTORY HYN_REG_CHIP_ID 0xA3 HYN_REG_CHIP_ID2 0x9F HYN_REG_POWER_MODE 0xA5 0x03 = SLEEP (reset the touchpanel using the reset pin before using this register: pin_low, delay 5ms, pin_high, delay 50ms then write 3 to register 0xA5) HYN_REG_FW_VER 0xA6 HYN_REG_VENDOR_ID 0xA8 HYN_REG_LCD_BUSY_NUM 0xAB HYN_REG_FACE_DEC_MODE_EN 0xB0 HYN_REG_GLOVE_MODE_EN 0xC0 HYN_REG_COVER_MODE_EN 0xC1 HYN_REG_CHARGER_MODE_EN 0x8B HYN_REG_GESTURE_EN 0xD0 HYN_REG_GESTURE_OUTPUT_ADDRESS 0xD3 HYN_REG_ESD_SATURATE 0xED 0xED Accelerometer The on board accelerometer in devices shipped before July 2021 is a Bosch BMA421, connected to the I2C bus. Devices shipped after July 2021 use a Bosch BMA425 accelerometer.\nPins P0.06: I²C SDA P0.07: I²C SCL P0.08: Interrupt I²C Device address: 0x18\nReducing power consumption The PineTime appears to be able to sleep with a current consumption of only 66µA.\nTo investigate current consumption, it’s a good idea to disable everything possible to get the lowest current consumption possible, and then re-enable things one by one. Here is one way to get a baseline current consumption of 0.60µA, as measured from the 3.3V pin with the battery disconnected:\nEnable the DC/DC regulator. This doesn’t affect the current consumption while sleeping, but almost halves the runtime current consumption. Use the low-frequency (32.768kHz) oscillator. Leave all pins in their default state, except for P0.05 (SPI CS) and P0.25 (LCD CS) which should be configured as an output and set to high. Put the heart rate sensor in sleep mode by setting the PDRIVER (0x0C) register to 0, see the HRS3300 datasheet for details. Put the SPI flash in deep power-down mode by setting flash CS high, then low, then writing the byte 0xb9 on the SPI bus, and then setting flash CS high again. Sleep in a loop, using WFE or WFI (if you’re using the Nordic SoftDevice, call sd_app_evt_wait instead). Here are some current consumption statistics (current consumed in addition to the baseline power), roughly ordered from large to small:\nSource Current Notes SWD 3.05mA Power cycle the chip after programming to avoid this, it can hide other inefficiencies. LCD 5.61mA Set the LCD to sleep mode when not used, using SLPIN. Backlight high 12.27mA Backlight mid 5.51mA Backlight low 1.83mA ADC left enabled 1.3mA Stopping SAADC brings the current back to the baseline. It seems that it doesn’t need to be disabled entirely. Edge triggered pin interrupts 0-0.47mA? It appears that under some configurations, edge triggered interrupts result in a large power drain. One way to avoid this is by using the pin sense mechanism. BUTTON_OUT left high 0.04mA See Button for how to avoid this. SPI flash sleep mode 0.014mA Sleep mode still consumes power. Put it in deep power down mode to avoid this. SPI, I2C (negligible) SPI and I2C appear to consume very little power when idle, around 1µA or less. ","permalink":"/documentation/PineTime/Hardware/","tags":null,"title":"Hardware"},{"categories":null,"contents":" The SoC and RAM packages\nGeneral RK3588 SoC (8 cores: 4x A76 at 2.4 GHz + 4x A55 at 1.8 GHz) Mali G610MC4 GPU (4x Valhalla cores) 16 GB of LPDDR4X (SK hynix) 64 GB eMMC (Foresee, soldered) 1x USB-C (with video-alt mode) 1x USB-C (FTDI debug UART, FT232RL) 1x USB 3.0 2x USB 2.0 1x HDMI in 2x HDMI out 1x PCIe 3.0 slot (open-ended) 1x SD / TF card slot 2x SATA ports 2x Gigabit Ethernet (1x from SoC, 1x on PCIe, RTL8211F, RTL8111HS) 1x Wi-Fi \u0026amp; Bluetooth module (AMPAK Tech AP6275PR3) 2x SMA Antenna 2x MIPI DPHY 1x MIPI D/C PHY 1x MIPI CSI 1x PWM Fan header (four pins) 1x RTC battery socket (CR1220, 3 V, see QuartzPro64 board schematics PDF, page 21) 1x MIC (soldered) 1x audio output 3.5 mm jack DC 12 V power input Cooler The board comes with two cooler mounts, a 4-hole mount that appears to be spaced 55x55mm apart, and the ~60mm diagonal \u0026ldquo;northbridge heatsink\u0026rdquo; mount the ROCKPro64 and Quartz64 Model A uses.\nRK3588 is slightly (\u0026lt;1mm?) taller than the DRAM chips, use a thick enough thermal pad instead of thermal compound.\nUART Plug in the USB-C port labelled \u0026ldquo;DEBUG PORT\u0026rdquo; on the QP64 board to another computer with a USB-A-to-C cable.\nIt will show up as a FT232 USB Serial adapter in lsusb:\n$ lsusb Bus 005 Device 027: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC Baud rate is 1.5 mbauds or 1500000.\nEnsure you have the driver module loaded:\n. modprobe ftdi_sio . lsmod | grep ftdi_sio ftdi_sio 61440 0 usbserial 53248 1 ftdi_sio usbcore 290816 7 ftdi_sio,usbserial,xhci_hcd,usbhid,usbkbd,usbmouse,xhci_pci If the above is not working, check the required driver is supported by your kernel, using one of the following commands:\n$ zgrep FTDI_SIO /proc/config.gz CONFIG_USB_SERIAL_FTDI_SIO=m $ grep FTDI_SIO \u0026#34;/boot/config-$(uname -r)\u0026#34; CONFIG_USB_SERIAL_FTDI_SIO=m Using the dmesg command, you should see something like the following:\n[24784.535804] usb 5-3: new full-speed USB device number 3 using xhci_hcd [24784.710714] usb 5-3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00 [24784.710723] usb 5-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [24784.710725] usb 5-3: Product: FT232R USB UART [24784.710727] usb 5-3: Manufacturer: FTDI [24784.710728] usb 5-3: SerialNumber: A10LLO86 [24784.723858] usbcore: registered new interface driver usbserial_generic [24784.723865] usbserial: USB Serial support registered for generic [24784.725286] usbcore: registered new interface driver ftdi_sio [24784.725295] usbserial: USB Serial support registered for FTDI USB Serial Device [24784.725348] ftdi_sio 5-3:1.0: FTDI USB Serial Device converter detected [24784.725368] usb 5-3: Detected FT232RL [24784.731685] usb 5-3: FTDI USB Serial Device converter now attached to ttyUSB0 Then you can get console output from the QP64 with, for example:\nscreen /dev/ttyUSB0 1500000 Mounting Holes Mounting holes are 3 mm in diameter, so standard standoffs can be used, preferably the 2.5 mm variant. See also the PCB layout PDF files, linked in the documentation section of the Resources page.\nThe height from the bottom of the PCB to the top of the USB ports as the tallest components is 18 mm, which can be used as a data point for selecting the suitable standoff length to place some acrylic top cover over the board. However, that doesn’t account for the heatsink that needs to be mounted on the RK3588 SoC, for which a suitable rectangular hole can be cut in the top cover.\nStorage The eMMC on the dev board\nSoldered 64 GB FORESEE eMMC chip, which comes pre-flashed with some Android build One microSD card slot Two SATA 3.0 ports (standard Molex power connector is not populated) Power Power switch \u0026amp; barrel connector\nYou can provide power to the board via the 12V barrel connector, it’s 5.5mm OD/2.1mm ID barrel \u0026lsquo;coaxial\u0026rsquo; type \u0026ldquo;M\u0026rdquo; centre-positive, the ROCKPro64 5A power supply from the PINE64 store will work. (TODO: add alternative ways).\nThere is a hardware flip switch to power up / down the board.\nPMU The PMU\n2x RK806-2, not RK808 compatible. It’s a dual PMU configuration where one PMU is a subordinate of the other.\nVerify this once we have access to SDK sources.\nEthernet The RGMII ethernet port (near the SDCARD socket) is working if you use neg2led’s linux-quartz64 repo.\nThe other port (near the sound jack) is hooked to the SoC via PCIe and is currently reported working (on the matrix channel) with latest neggles kernel.\n","permalink":"/documentation/QuartzPro64/Hardware/","tags":null,"title":"Hardware"},{"categories":null,"contents":" LEDs The blue LED can be controlled with via the sysfs (/sys/devices/platform/leds/leds/power/brightness):\nTo turn off the blue LED: echo 0 | sudo tee /sys/devices/platform/leds/leds/power/brightness\nTo turn on the blue LED: echo 1 | sudo tee /sys/devices/platform/leds/leds/power/brightness\nNote: the maximum brightness is defined as 255, it doesn’t support dimming however, so 0 and 1 as brightness is sufficient. Turning off the blue LED will turn on a weak red LED. Trigger can be changed via /sys/devices/platform/leds/leds/power/trigger.\n","permalink":"/documentation/RockBox/Hardware/","tags":null,"title":"Hardware"},{"categories":null,"contents":" Note Please note that this Android build solely for PinePhone Pro hardware checking purpose and solely used by the support team. This is not a general release build. Download:\nDirect download from pine64.org (722MB, for 8GB microSD cards or bigger, MD5 of the GZip file 214e063c8205c1a98d44b2015a21bb5d) Instructions:\nDownload the build, extract the image and dd it to a 8 GB or larger microSD card, take out the PinePhone Pro Explorer Edition, then insert it into microSD slot (upper slot). Insert battery, press the RE button (bypass SPI and eMMC boot) underneath the back cover while plugging in the USB-C power. After 3 seconds release the RE button. When powering up, a battery icon screen will show up. Press the power key for two seconds, then the Rockchip logo screen shows up. Wait for the home screen, double tap on the test app icon (mark red circuit) and this will bring up the factory test screen. Please note that the SD test is disabled due in this is SD boot build. After running a particular test function, please snapshot the test result and pass it back to support team Notes:\nPlease insert a functional SIM card when performing the SIM test When perform GPS test, the first result may fail and please ignore this false message. For light sensing test, please have a light shine to the PinePhone Pro when performing the test. ","permalink":"/documentation/PinePhone_Pro/Factory_tests/Hardware_checking/","tags":null,"title":"Hardware checking"},{"categories":null,"contents":"Please contribute to the hardware compatibility page, which lists hardware which has been tested with the rockpro64, whether successful or not.\nHardware compatibility PCIe devices Type Make/Model Hardware IDs Kernel Result Notes Tester NIC Intel I350 Dual Port Mainline-5.4 good SR-IOV fails NIC Intel I350 Quad Port ? NIC Intel X520 Dual Port 8086:10fb Mainline-5.6 good SR-IOV fails NIC Intel X550-T2 Dual Port 8086:1563 5.15.0-trunk-arm64 (Debian) good netperf throughput in FW mode, 20 streams: between 4136-6613mb/s across use cases. NIC Intel 82571EB Dual Port (HP NC360T) Mainline-5.6 crash kernel crash on boot NIC Intel 82575EB Dual Port (AOC-SG-I2) Mainline-5.10 crash kernel crash on boot NIC Intel 82575/82576 8086:1521 OpenWrt 21.02-rc1 ; 5.4.111-1 good opkg: kmod-igb; OpenWrt 21.02-rc1 5.4.111-1; ~92.8 KB; Kernel modules for Intel(R) 82575/82576 PCI-Express Gigabit Ethernet adapters. NIC Aquantia 10GBps AQC107 1d6a:07b1 Mainline 5.16 good Works perfectly out of the box. GPU nVidia GTX-645 Mainline-5.4 crash BAR size too small, triggers PCIe error handling bug PCIe Switch PCIE-EUX1-04 Ver.002 Mainline-5.4 good SATA Controller ASM1062 4-Port Mainline-5.6 good tested only with one disk attached SATA Controller ASM1062 (rev 02) 4-Port 1d87:0100 Ayufan-4.4.190 good tested with four disks, 3 in raid 5 SATA Controller IOCrest (Same as Syba?) SI-PEX40063 4-port, Marvell 88SE9235 chip 1b4b:9235 Debian unstable 5.7, 5.8 good Tested with two disks. SATA errors occurred with a WD Red drive in a cheap enclosure; resolved by connecting the same drive directly to the card. SATA Controller Ziyituod SATA Card ASM 1062+1093 6-Port 1b21:0625 Mainline-4.4 (armbian) good tested with 6 disks SATA Controller BEYMEI RAID 4-Port, Marvell 88SE9230 chip 1b4b:9230 Ayufan-5.6.0-1137 good Tested with 3 disks in RAID 5. I added pci=nomsi to /boot/extlinux/extlinux.conf kernel parameters and an udev rule before the disks were recognized: ACTION==\u0026ldquo;add\u0026rdquo;, SUBSYSTEM==\u0026ldquo;pci\u0026rdquo;, ATTR{vendor}==\u0026ldquo;0x1b4b\u0026rdquo;, ATTR{device}==\u0026ldquo;0x9230\u0026rdquo;, RUN+=\u0026quot;/bin/bash -c \u0026rsquo;echo %k \u0026gt; /sys/bus/pci/drivers/ahci/bind'\u0026quot; SATA Controller BEYIMEI SATA Card 6-Port, ASM1166 chip 5.10.0-16-arm64 (Debian) good Tested with 4 disks. Built 2 separate software RAID-1 arrays without errors. Performance seems good enough for a NAS on gigabit LAN. SATA Controller PCE8SAT-A02 VER006S\n2 Lanes, 8-Port, ASM1166 chip\nOdd because chip got only 6 ports? 1b21:1166 6.1.50-current-rockchip64\nArmbian 23.8.1 Bookworm unstable Tested with 3 disks in SW-RAID 5. After 10 hours of burn in test one disk dropped from system and RAID. Hotplug does not work. User:JPT SATA Controller BEYIMEI SATA Card 2-Port, ASM1062 chip 1b21:0612 5.10.0-19-arm64 (Debian) good Using with 2 SSDs in a software RAID-1 array (~190MB/sec for reading and writing) SATA Controller QNINE 4-Port, Marvell 88SE9215 chip Ayufan-5.6.0-1137 very slow Tested with 3 disks in RAID 5. Top speeds were around 50 MiB/s but quickly dropped to below 2 MiB/s due to SATA CRC errors SATA Controller YUNKOZAND-PCIE1X-SATA4-9215, Marvell 88SE9215 chip 1b4b:9215 (rev 11) Armbian 24.11.1, Kernel 6.12.12-current-rockchip64 good Kernel driver in use: ahci Tested with 2 disks in RAID 1. Top speeds were around 100 MB/s User:o1hitman1o SATA Controller DELOCK 90498, JMicron Technology Corp. JMB58x AHCI SATA controller 197b:0585 5.18.0-0.bpo.1-arm64 (Debian bullseye + backports) good, but… Tested with 3 disks, two in RAID1, one standalone. u-boot-rockchip_2023.07 cannot initialize the controller to boot off it. User:Lrissman\nUser:ChriChri SATA Controller DELOCK 90498, JMicron Technology Corp. JMB58x AHCI SATA controller 197b:0585 6.12.63+deb13 (Debian trixie), 6.17.13+deb13 (Debina trixie/backports) crash synchronous external abort @horazont Host Bus Adapter LSI SAS 9211-4i\nSAS2008 chip, 4-Port SAS/SATA, PCI 2.0, 8 lanes 1000:0070 Ayufan-4.4.197 good tested with four disks attached Host Bus Adapter Fujitsu SAS MEGARAID LSI 2008B2\nSAS2008 chip, 8-Port SAS/SATA, PCI 2.0, 8 lanes TODO 6.1.50-current-rockchip64\nArmbian 23.8.1 Bookworm TODO needs special MicroSAS cables. Must be flashed to HBA mode?\nordered, not yet received User JPT USB Controller ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller 1b21:1242 Mainline-5.15.0-rc5 good DTMB Quad Tuner TBS Technologies TSS6514 Mainline-5.10.21 good TV -\u0026gt; LAN streaming server, 7W idle, 8-10W with one FHD channel streaming DVB-T2/C Quad Tuner TBS Technologies TBS6205 5.10.0-16-arm64 (Debian) good Working well with Tvheadend DVB-S2 Dual Tuner Digital Devices Octopus CI S2 Pro 6.1.42-rockchip64 (armbian) good All features are working flawlessly with the latest drivers from Digital Devices NVMe SSD drives Type Make/Model Size Hardware IDs Kernel Result Notes Power options\nActive only Save power setting? NVMe Samsung 970 Evo 500 GB Mainline 5.6 good - defaults defaults NVMe Samsung 960 Evo 500 GB 144d:a804 Mainline 5.13-rc4 doesn’t work Likely due to 64/32 BAR mismatch issue on Linux 5.11+ defaults defaults USB hardware Type Make/Model Hardware IDs Kernel Result Notes Tester Zigbee Bridge Conbee II 1cf1:0030 6.1.50-current-rockchip64\nArmbian 23.8.1 Bookworm good seems to work fine User JPT USB C alternate mode DP Note that only USB C alternate mode Display Port will pass video. Any HDMI, DVI or VGA port must be converted internally by the device from Display Port - or the device won’t work for video.\nType Make/Model Hardware IDs Kernel Result Notes eMMC / SD drives Type Make/Model Hardware IDs Kernel Read Speed Write Speed Result Notes Other hardware Type Make/Model Hardware IDs Kernel Result Notes Limitations Older firmware overwrites actively used memory Some people get system freeze when:\nuse SATA disk with ROCKPro64 PCIe card (maybe on newer PCIe card ASM1062 vs ASM1061) or do read or write 4GB to the flash (not using PCIe) If you connect the serial console you will see a Linux kernel oops: (a)synchronous external abort.\nBoth issues are in fact the same software BUG. There is no hardware problem. Currently, most OS do use uboot with a rockpro blob FW which use memory that Linux kernel is not aware of.\nPeople are currently fixing this BUG, but it may take some time. In the mean time, you can fix it manually.\nThe latest u-boot can boot the rockpro64 without any blobs from rockchip.\nInstall first arm-none-eabi-gcc and aarch64-linux-gnu-gcc compiler, then run the following commands:\nPrerequisite packages (Debian/Ubuntu): device-tree-compiler python gcc-arm-non-eabi flex bison gcc-aarch64-linux-gnu gcc make\ngit clone https://github.com/ARM-software/arm-trusted-firmware.git atf make -C atf CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31 git clone https://gitlab.denx.de/u-boot/u-boot.git u-boot cd u-boot/ git checkout v2020.01-rc5 make rockpro64-rk3399_defconfig BL31=../atf/build/rk3399/release/bl31/bl31.elf make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- Which gives you idbloader.img and u-boot.itb. Copy them to the rockpro64, and run the following: (Or put your SD card into your PC)\nsudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 sync PCIe Controller Hardware Error Handling Bug There is an issue with the rk3399 pcie controller that is currently unmitigated:\nLKML Original Thread LKML Additional Information The rk3399 pcie controller throws either a synchronous abort or a SError when a pcie device sends an unknown message.\nThe error type is determined by which cpu cluster handles the message.\nVirtualization The PCIe controller on the rk3399 is not behind an IOMMU. This means it is not possible to safely pass through PCIe devices to a virtual machine.\n","permalink":"/documentation/ROCKPro64/Hardware/Hardware_compatibility/","tags":null,"title":"Hardware compatibility"},{"categories":null,"contents":" Enabling PCIe 2.0 Warning The downgrade to Gen1 speed came straight from Rockchip, as a result of an undisclosed RK3399 hardware errata. Thus, enabling Gen2 back may cause system instability or data corruption under certain circumstances. Also, the limitations of the RK3399’s internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains, unless using specific PCI Express hardware. By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay.\nCopy and paste the device tree overlay file below into a new file (you could name it pcie-2.0.dts):\n// Pulled from: https://forum.armbian.com/topic/23574-howto-enable-pcie-gen2-to-get-max-speed-of-nvme-rockpi-4b/ /dts-v1/; /plugin/; \u0026amp;pcie0 { max-link-speed = \u0026lt;0x03\u0026gt;; }; Compile the device tree into a binary file. Note that you will need dtc installed.\ndtc -I dts -O dtb -@ pcie-2.0.dts -o pcie-2.0.dto Copy or move the device tree from the current directory into the boot partition (in this case into the /boot/dtbs/overlay/ folder). If you haven’t yet created the /boot/dtbs/overlay/ folder, then create it with sudo mkdir /boot/dtbs/overlay/\nsudo cp pcie-2.0.dto /boot/dtbs/overlay/ Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a extlinux.conf file), then add the following line to the file /boot/extlinux/extlinux.conf:\nFDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb If you already have an FDTOVERLAYS line, then add a space at the end of the current line, then add this overlay file after that. See here for details on this process: Device Tree Overlays on Mainline\nThe resulting /boot/extlinux/extlinux.conf file might look like below after adding this dtb file:\nLABEL Manjaro ARM KERNEL /Image FDT /dtbs/rockchip/rk3399-rockpro64.dtb FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil Overclocking (and undervolting) Warning Please note that changing the maximum operating frequency or the supply voltage may cause system instability or data corruption under certain circumstances. There is even the possibility of damaging your equipment permanently. The RK3399 can be overclocked. See here for details: Overclocking/RK3399-based devices. By overclocking, you do risk damaging your hardware, however, it is possible to achieve small, but measurable improvements in performance with an overclock. The overclock can be applied with a device tree overlay file.\nBelow is an example device tree overlay for CPU overclocking on the RockPro64. It may or may not work well on your device, but some have found that these speeds are stable. The example below bumps the little cores up to 1.608GHz from 1.416GHz and bumps the big cores up to 2.088GHz from 1.8GHz.\nCopy and paste the device tree overlay file below into a new file (you could name it cpu-overclock.dts):\n// Pulled from: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi /dts-v1/; /plugin/; \u0026amp;cluster0_opp { opp00 { opp-hz = /bits/ 64 \u0026lt;408000000\u0026gt;; opp-microvolt = \u0026lt;800000\u0026gt;; clock-latency-ns = \u0026lt;40000\u0026gt;; }; opp01 { opp-hz = /bits/ 64 \u0026lt;600000000\u0026gt;; opp-microvolt = \u0026lt;825000\u0026gt;; }; opp02 { opp-hz = /bits/ 64 \u0026lt;816000000\u0026gt;; opp-microvolt = \u0026lt;850000\u0026gt;; }; opp03 { opp-hz = /bits/ 64 \u0026lt;1008000000\u0026gt;; opp-microvolt = \u0026lt;900000\u0026gt;; }; opp04 { opp-hz = /bits/ 64 \u0026lt;1200000000\u0026gt;; opp-microvolt = \u0026lt;975000\u0026gt;; }; opp05 { opp-hz = /bits/ 64 \u0026lt;1416000000\u0026gt;; opp-microvolt = \u0026lt;1100000\u0026gt;; }; opp06 { opp-hz = /bits/ 64 \u0026lt;1512000000\u0026gt;; opp-microvolt = \u0026lt;1150000\u0026gt;; }; opp07 { opp-hz = /bits/ 64 \u0026lt;1608000000\u0026gt;; opp-microvolt = \u0026lt;1200000\u0026gt;; }; }; \u0026amp;cluster1_opp { opp00 { opp-hz = /bits/ 64 \u0026lt;408000000\u0026gt;; opp-microvolt = \u0026lt;800000\u0026gt;; clock-latency-ns = \u0026lt;40000\u0026gt;; }; opp01 { opp-hz = /bits/ 64 \u0026lt;600000000\u0026gt;; opp-microvolt = \u0026lt;800000\u0026gt;; }; opp02 { opp-hz = /bits/ 64 \u0026lt;816000000\u0026gt;; opp-microvolt = \u0026lt;825000\u0026gt;; }; opp03 { opp-hz = /bits/ 64 \u0026lt;1008000000\u0026gt;; opp-microvolt = \u0026lt;850000\u0026gt;; }; opp04 { opp-hz = /bits/ 64 \u0026lt;1200000000\u0026gt;; opp-microvolt = \u0026lt;900000\u0026gt;; }; opp05 { opp-hz = /bits/ 64 \u0026lt;1416000000\u0026gt;; opp-microvolt = \u0026lt;975000\u0026gt;; }; opp06 { opp-hz = /bits/ 64 \u0026lt;1608000000\u0026gt;; opp-microvolt = \u0026lt;1050000\u0026gt;; }; opp07 { opp-hz = /bits/ 64 \u0026lt;1800000000\u0026gt;; opp-microvolt = \u0026lt;1150000\u0026gt;; }; opp08 { opp-hz = /bits/ 64 \u0026lt;2016000000\u0026gt;; opp-microvolt = \u0026lt;1250000\u0026gt;; }; opp09 { opp-hz = /bits/ 64 \u0026lt;2088000000\u0026gt;; opp-microvolt = \u0026lt;1250000\u0026gt;; }; }; Compile the device tree into a binary file. Note that you will need dtc installed.\ndtc -I dts -O dtb -@ cpu-overclock.dts -o cpu-overclock.dto Copy or move the device tree from the current directory into the boot partition (in this case into the /boot/dtbs/overlay/ folder). If you haven’t yet created the /boot/dtbs/overlay/ folder, then create it with sudo mkdir /boot/dtbs/overlay/\nsudo cp cpu-overclock.dto /boot/dtbs/overlay/ Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a extlinux.conf file), then add the following line to the file /boot/extlinux/extlinux.conf:\nFDTOVERLAYS /dtbs/overlay/cpu-overclock.dtb If you already have an FDTOVERLAYS line, then add a space at the end of the current line, then add this overlay file after that. See here for details on this process: Device Tree Overlays on Mainline\nThe resulting /boot/extlinux/extlinux.conf file might look like below after adding this dtb file:\nLABEL Manjaro ARM KERNEL /Image FDT /dtbs/rockchip/rk3399-rockpro64.dtb FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil Getting WiFi working (new WiFi module) Warning The information presented in this section may be obsolete because of this commit in the linux-firmware upstream repository Moreover, the suggested modifications to the configuration file should be resolved in the upstream repository, to fix any identified issues, instead of suggesting local changes to be performed. Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name brcmfmac43455-sdio.AW-CM256SM.txt. You can copy this file to the new name (that the driver looks for) with the following commands:\ncd /usr/lib/firmware/brcm/ sudo cp brcmfmac43455-sdio.AW-CM256SM.txt brcmfmac43455-sdio.txt Then, reboot and WiFi should start working. Details for this method are here: https://forum.pine64.org/showthread.php?tid=16635\u0026pid=117061#pid117061\nHowever, on a 5GHz network with wireless-regdb installed and the regulatory domain set to \u0026lsquo;US\u0026rsquo;, the adapter is almost unusable. Speeds are usually 0 bits per second. Sometimes a few packets can get through every few seconds, but that is it. On a 2.4GHz network, this is not an issue. This \u0026ldquo;can\u0026rdquo; be resolved by setting the regulator domain to \u0026lsquo;GB\u0026rsquo; or \u0026lsquo;CN\u0026rsquo;, but this isn’t a solution for you if you are in the USA, for instance. There are various other brcmfmac43455-sdio.txt files online that one can try. Some work better than others. Since these are text files where each line represents a property value, one can combine parts of these files to generate new firmware files for testing. One such combination yields decent results. This can be achieved by applying the patch below to the default brcmfmac43455-sdio.AW-CM256SM.txt file. With this firmware file, it is possible to get about 140Mbps up and down with this patch (with the regulatory domain set to \u0026lsquo;US\u0026rsquo;).\n--- brcmfmac43455-sdio.AW-CM256SM.txt 2023-04-27 19:16:47.000000000 -0500 +++ brcmfmac43455-sdio.txt 2023-05-21 11:42:22.058517093 -0500 @@ -21,19 +21,18 @@ ltecxpadnum=0x0504 macaddr=00:90:4c:c5:12:38 manfid=0x2d0 -maxp2ga0=64 -maxp5ga0=80,82,76,77 -mcsbw202gpo=0x99355533 -mcsbw205ghpo=0x99855000 -mcsbw205glpo=0x99755000 -mcsbw205gmpo=0x9df55000 -mcsbw405ghpo=0xd9755000 -mcsbw405glpo=0xb8555000 -mcsbw405gmpo=0xed955000 -mcsbw805ghpo=0xd9555000 -mcsbw805glpo=0xc8555000 -mcsbw805gmpo=0xe9555000 -muxenab=0x10 +maxp2ga0=70 +maxp5ga0=73,74,73,73 +mcsbw202gpo=0x99333322 +mcsbw205ghpo=0x8a875444 +mcsbw205glpo=0x8a875444 +mcsbw205gmpo=0x8a875444 +mcsbw405ghpo=0xda844333 +mcsbw405glpo=0xda844333 +mcsbw405gmpo=0xdb844333 +mcsbw805ghpo=0xda555444 +mcsbw805glpo=0xdb555444 +mcsbw805gmpo=0xda555444 nocrc=1 ofdmlrbw202gpo=0x0033 pa2ga0=-112,6296,-662 To use this patch, copy it off into a file and use the patch command. However, it might be easier to apply the patch by hand. To do this, open the file /usr/lib/firmware/brcm/brcmfmac43455-sdio.txt (after completing the copy step above), delete the line with maxp2ga0=64 through the line with muxenab=0x10.\nThen add the following in its place:\nmaxp2ga0=70 maxp5ga0=73,74,73,73 mcsbw202gpo=0x99333322 mcsbw205ghpo=0x8a875444 mcsbw205glpo=0x8a875444 mcsbw205gmpo=0x8a875444 mcsbw405ghpo=0xda844333 mcsbw405glpo=0xda844333 mcsbw405gmpo=0xdb844333 mcsbw805ghpo=0xda555444 mcsbw805glpo=0xdb555444 mcsbw805gmpo=0xda555444 Reboot and the Wi-Fi (at least for 5GHz networks) should work well. It is not exactly clear what these fields do, so the impact this has on the Wi-Fi module or your ability to operate it legally in your country is not certain. It seems that this file is passed directly to the hardware, where it is interpreted by the Wi-Fi module itself. However, given that this file is simply a combination of other existing files for similar hardware, it might be fine to use. The patch above only pulls in lines from the following firmware file: https://github.com/reMarkable/brcmfmac-firmware/blob/master/brcmfmac43455-sdio.txt. This code comes with the following license - which is not replicated here because it will fill this wiki with text - see the link here for the license: https://github.com/reMarkable/brcmfmac-firmware/blob/master/LICENCE.\nStabilizing the system (underclocking the RAM) Warning As pointed out by CrystalGamma, \u0026ldquo;normal accesses should simply work, though with higher access latency than necessary (since it uses the same number of cycles as would be necessary for a higher frequency), but I’d be slightly worried about refresh, since it also issues refresh based on number of cycles as would be used for a higher frequency, instead of actual time elapsed\u0026rdquo;. In other words, \u0026ldquo;the risk is refreshes coming to late, though it’s probably within tolerance with this little of a frequency diff\u0026rdquo;.\nTo put it simply, the suggested changes to DRAM configuration may actually cause system instability or data corruption under certain circumstances.\nBy default, it seems that the some RockPro64 devices are not stable. This seems to manifest as gcc segfaulting randomly. Usually, this can be \u0026ldquo;fixed\u0026rdquo; by starting the build again and hoping gcc doesn’t crash. If the build finishes or crashes at a different point, this is a good indicator that the system is not stable. The issue seems to be that the RAM is running a little too fast and some bits are getting randomly flipped. Other frequencies are possible, but the highest officially supported frequency below 800MHz is 666MHz, which is still a big step down from the default frequency of 800MHz provided by ManjaroARM. It is also possible to set arbitrary frequencies in u-boot. Frequencies that have been tested with this method are 702MHz and 752MHz. It seems that there is only a slight performance decrease at 752MHz compared to 800MHz.\nBy default, this PKGBUILD uses the default RAM speed of 800MHz. Uncomment the line that begins with \u0026ldquo;patch\u0026rdquo; to enable the 752MHz patch. Details are in the comments at the top of the PKGBUILD. If you would like to try out other frequencies, follow the instructions in the comments at the top of the PKGBUILD.\nAfter building and installing, the install hook will prompt you on if you want to install the new build of U-Boot to EMMC. If you want to, press Y, otherwise, hit N and then copy and paste the printed dd commands and modify them to write to the correct device (change the /dev/mmcblk part).\nAfter installing U-Boot and rebooting, U-Boot should print out that it set the RAM to 400MHz (initially). Then a few lines down, the RAM should be set to 752MHz.\n","permalink":"/documentation/ROCKPro64/Hardware/Hardware_tweaks/","tags":null,"title":"Hardware tweaks"},{"categories":null,"contents":"This page contains a list of things people wish PineTime did differently\nHardware Other display technology could be explored. E-ink Still images require no power to maintain **[//en.Wikipedia.org/wiki/Transflective_liquid-crystal_display A transflective LCD] Increased readability in bright daylight **[//en.wikipedia.org/wiki/OLED OLED] Self-emissive display (pixels emit their own light) Allows for lower power usage with mostly black screens Allows for low power visual notifications (imagine an always-on small red square in the corner to indicate a notification) Touchscreen with configurable sensitivity Ideal for gloved fingers and water droplet resistance Preferably it should remain capacitive, as a resistive touchscreen would have too many trade-offs. A slightly bigger 256×256 pixel display This resolution is preferable for its binary alignment for low-level simplicity It has the property that its X and Y coordinates are each addressable with a single byte, with no bounds checking Its total number of pixels is a power of 2 (65536), and each pixel is addressable with exactly 2 bytes. The IBNIZ (Ideally Bare Numeric Impression giZmo) virtual machine, designed for minimalist demoscene graphics, has chosen 256×256 for its virtual display specifically for code efficiency. If PineTime also chose 256×256 then it would be a target platform for unclipped IBNIZ demoscene programmes, which would be really fun to play around with on one’s wrist! Full screen refresh is very slow A full 16-bit redraw on the display takes at worst 120ms, which is 8Hz Modest optimization is possible by adopting 12-bit color A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60hz Display redraw is currently bottlenecked by the nRF52832 maximum SPI clock (8MHz). The nRF528(33/40) has one high speed SPI master which supports 32MHz, still well below the ST7789 maximum Parallel data transfer could be an option, but using more GPIOs (which don’t look available) Some sort of scroll wheel (and possibly button combination) would be nice as an additional input method Changed GPIO assignment so more functionality is available (i.e. NFC and VSYNC) Wireless charging, or Qi Charging capability Different MCU with more RAM and ROM, higher clock nRF5840 update 32MHz HS SPI, QuadSPI CryptoCell + Secure Key Storage More RAM, a coprocessor The possibility to expose USB through power pins Ox64/BL808 Open hardware RISC-V based MCU Significant jump in performance Significant jump in memory and storage, allowing for more features and better UI’s Possibly a pre-certified MCU module with a ceramic antenna Version without sensors but maybe bigger battery Pins on the programmer connector to allow UART while developing (currently there is a TX test point on PCB). (Note: There’s ARM SemiHosting, ITM and Segger RTT that fulfil this purpose for most) Connect SDO of ST7889 LCD controller to MCU Allows MCU to execute READ commands Possibility of leveraging ST7889 RAM to save MCU RAM? LCD must be centered on case. Currently is not and watchfaces seems different when clock is put on the other wrist. A NFC antenna around the case, connected to the NFC pins. Used sensors should be NDA-free and preferably also blob-free for easier development Possibly replace BMA421 accelerometer with a magnetometer + gyroscope + accelerometer combination The BMA421 doesn’t have a public datasheet Special attention should be paid to advanced features, such as step counting integration or flick detection. PineTime SoC could support USB or have a FTDI chip with the relevant pins exposed It could allow flashing a sealed device, just like Arduinos work. Alternatively, an USB-C port could be added that provides these features. A bigger pulldown resistor for the power button 100k still leaks a noticeable amount of power when the button is always on. Ceramic Bluetooth antenna for better signal reception An external RTC circuit Allows the main MCU go to deep-sleep while retaining time. Allows time retention through MCU reset. Ultra low quiescent current PMIC In theory could provide a hard reset capability based on button press Better deep sleep/shipping/storage/off lifetime A nano-power system timer IC could in theory provide a RTC, MOSFET-controlled deep sleep, watchdog timer and button-controlled reset Built-in \u0026ldquo;fuel gauge\u0026rdquo; for better estimation of battery capacity Improved haptic or audible feedback E.g. small Piezo buzzer Use case would be for very short beeps (think old-school casio watch) as notification. Of course developers can PWM other frequency to make it sing, but piezos tend to be shrill. A built-in microphone Would allow phone call functionality to be built into the watch. Could potentially allow for speech recognition for text input. Direct access to the external (flash) storage Only a small jump in price ","permalink":"/documentation/PineTime/Development/Hardware_wishlist/","tags":null,"title":"Hardware wishlist"},{"categories":null,"contents":"Overclocking requires heat sinks:\nPosition of the heat sinks\n","permalink":"/documentation/Pine_A64/Further_information/Heat_sinks/","tags":null,"title":"Heat sinks"},{"categories":null,"contents":"The SOQuartz SoM does not have a lot of copper to sink heat into. Therefore, it’s recommended you use a heatsink such as the Waveshare CM4 Heatsink, the other Waveshare CM4 Heatsink, or the PINE64 Small Fan Type Heatsink. Please be aware that the Waveshare heatsinks may interfere with any eMMC module, unless you use very thick (2-3 mm?) thermal pads. Local resellers may sell CM4 heatsinks or small stick-on heatsinks, so there’s no need to order them from abroad unless it’s cheaper.\nAlternatively, or in addition to this, a rectangle-shaped piece of 1 mm thick thermal pad can be sandwiched between the SoM and the carrier board. This allows the SoM to more efficiently sink heat into the larger mass of the base board.\n","permalink":"/documentation/SOQuartz/Heatsinks/","tags":null,"title":"Heatsinks"},{"categories":null,"contents":"Pinecil V2\nOn Aug. 2, 2022, Pinecil V2 was released with improved hardware \u0026amp; accessories. It retains the same ergonomics and design as the original Pinecil, and will work with any accessories you already have including existing handles, cases, and tips. It comes with a green color silicone grip versus the light blue finger grip from Pinecil V1. It also includes one of PINE64’s newly designed shorter 6.2 ohm tips. By reducing the tip length and resistance from 8 to 6.2 ohms, it allows greater performance and and faster heating (short tips are potentially 64W @ 20V compared to 8ohm normal tips which allow a max of 50W to Pinecil). Pinecil V2 is officially rated for 12V-24V. Key changes in V2: new processor (BL706), higher maximum input voltage (24V versus V1’s 21V rating), support for measuring tip resistance, allows automatic detection of 6.2 vs 8 ohm tips. A notable improvement is the new BL706 RISC-V processor from Bouffalo. It is similar to the BL602 in the Pinenut. The BL706 features Bluetooth Low Energy (BLE / Zigbee); future IronOS firmware releases will expose features over BLE. This is not trivial work, but as people contribute to the opensource code of GitHub/IronOS, BLE options will expand. There is also tentative support for USB-PD3.1 EPR (28V, 140W chargers), Ralim’s IronOS supports V2 running with USB-C EPR-28V. EPR/PD3.1 is not officially acknowledged yet by the Pine Store. Many brands of EPR USB-C chargers are confirmed by members to work on Pinecil V2 at 28V and this results in faster heating performance over PD 20V chargers see short test here. Things staying the same in V2: it still uses a RISC-V processor, but adds noticeable upgrades to the hardware. GPIO is broken out on USB-C for creating your own projects, same pinout as Pinecil V1, same great feel, including the rubber grip, works with all existing tips, same DC input + USB-C input connections, and compatibility with existing clear or black handles. In the V2 handle’s side label, the 88W figure comes from a 6.5ohm tip calculation. The reason for using 6.5 instead of 6.2 for the new short tips calculation is due to tolerance during manufacturing, and leaving a conservative margin of error (actual tips appear to be 6.2 ohms). V2 set max voltage is listed as 24V because this was the value used during design and component selection. Pinecil V1\nFor the first manufacture batch (October 2020, order number 158xxx) of the Pinecil, the copper ring connecting the earth screw to the tip was omitted as the engineering team found the TS100 design lacking. For the second round onward, an improved design copper ring has been included as standard, and is also included with the replacement clear and black handles. For normal operation of the iron, omission of the ring does not impact it’s operation. If you are working with ESD components, you will need it in order to ground the iron tip via the earth screw at the back of the iron. Programmable with tools from Gigadevice The first batch of Pinecils were rated 12-24v @ 65W. After some heated discussion on the discussion group, it was decided that it would be downgraded to 12-21V @ 60W, due to concern over the connection of the DC jack to the USB-PD chip, which has a recommended maximum of 21v, and absolute maximum of 28v. ","permalink":"/documentation/Pinecil/Further_information/History_of_hardware_changes/","tags":null,"title":"History of hardware changes"},{"categories":null,"contents":"The following article contains a selection of common ways to contribute to the community projects.\nReporting issues Reporting issues is a great way to contribute (if done correctly). The software projects are using bug trackers to keep track of bugs and to link patches or changes with these bug reports.\nSee the article where to report bugs to find out where you can report bugs.\nContributing code By contributing code, for example as documented in the following project pages (alphabetical order):\nelementary: Get Involved and the ARM project on GitHub KDE: see Get Involved and Help:Contribute Plasma Mobile: https://plasma-mobile.org/get-source/ (see the \u0026ldquo;Contributing\u0026rdquo; section) Donating to community projects and developers Many community projects and developers are working on the software on their free time. Donating to community projects and developers is a great way to support these projects and developers developing the software for the devices. The following list is an exemplary selection to which projects and developers can be donated to (in alphabetical order):\nTip The following list is not a comprehensive list and solely a selection of different community projects and developers, which can be supported. Any FOSS development effort is valuable and should be rewarded, please support your favorite developer(s) or project(s) even if not mentioned on the list Your name or project not on the list? Community projects Armbian: https://www.armbian.com/donate/ elementary: https://elementary.io/get-involved KDE: https://kde.org/community/donations/ LibreELEC: https://libreelec.tv/sponsor/ Manjaro ARM: Open Collective, Liberapay, Patreon (see https://manjaro.org/donate/ for an overview) Mobian: Liberapay postmarketOS: https://postmarketos.org/donate/ UBports: https://ubports.com/donate and many more!\nDevelopers Danct12: Ko-fi, Liberapay, Patreon megi: https://xnux.eu/contribute.html#toc-donations and many more!\nHelp with the documentation All projects typically require help with the documentation. That can include the wikis of the projects, help pages, tutorials, manuals and technical or informative drawings.\nOther ways to contribute Other ways to contribute to the projects might include:\nTranslations and localization Designs and creative work Ideas Supplying hardware and many more!\nBy being a positive member of the community By being a positive member of the community you can help answering common questions and help people find the correct places for their inquiries.\n","permalink":"/documentation/Introduction/How_to_contribute/","tags":null,"title":"How to Contribute"},{"categories":null,"contents":"This article explains how dismantle, test, and repair the Pinecil.\nCautions Warning while opening your Pinecil will not necessarily void your warranty, all self-repairs are done at your own risk. Read everything in this section and related or linked articles to get a good idea of the procedure, and go to the Pinecil community chat if you desire advice/support from experienced volunteers. Self-repairs or modifications might void your warranty so proceed if this is not a concern. This information is for educational purposes only. Pinecil V1 and V2 have slightly different schematics and have different MCU chips. Doing repairs often requires referencing the correct schematics or photos. The datasheets are also important to get information about the chips, and to order replacement parts. The schematics and known datasheets are all at the bottom of this article and linked in the contents table at the top. Chatting with other owners of Pinecil is encouraged as they have experience - already broke things so you don’t have to (see Pinecil volunteer chat link here).\nNote This is a new work in progress (WIP) started Feb. 18, 2023 which may be updated over time as volunteers have time to write up information. For sections that are missing, try asking in the live chat as a volunteer may have some clues to get you headed in the right path. Tools needed Digital multimeter (DMM) Philips screwdriver All schematics, datasheets for known common parts, and links to where to buy replacement parts are all in this article under Schematics and board data. Refer to the correct section for V1 or V2 parts. Which model do I have? The older V1 model has an all black handle with a blue silicone grip and was discontinued in July 2022. The new V2 model has a black handle with a green thumb grip and is the only model PINE64 and authorized resellers started selling after August 1, 2022. Magnifying lamp or jeweler’s glasses with led light and good room light. Photos/videos will help to chat with volunteers in the live Pinecil chat channel if getting clarification or troubleshooting. Optional: mobile phone to take macro photos or video. A macro lens to take phone photos is helpful; there are cheap ones that simply clip on. Possibly another soldering iron to do the repair, some flux, solder, and isopropyl alcohol (IPA) for cleaning the PCB. See [[Pinecil_Cases,_Stands,_Supplies#Soldering_supplies| this guide]] for some basic supply options. Optional: better needle size probe leads for DMM makes things easier and are nice for electronic work. Reference photos are in the images section. Dismantle steps Easy trick to open Pinecil Video of easy trick: https://www.youtube.com/watch?v=aK01V5DrrVk Handle replacement graphic Step-by-step It is recommended to take photos to help with reassembly. Loosen the top tip screw (PH1) (top is the side with the screen). Gently pull the tip out and set aside (let the tip cool down first or use protection to prevent burns). Slide the rubber thumb grip off the front. Remove the bottom-front screw (between the bottom feet (PH1)). Remove the ground screw (longer m2x4mm screw next to the screen near the (-) button (PH1)). Slightly pull the two halves of the case apart at the tip front end first, enough to get a fingernail or guitar pick between 2 parts. Move the pick down the length of the split to loosen the bottom half’s clips from the top half of the case. Once loose, remove the bottom half by sliding it a little forward (it is retained by the top half at the DC barrel side). Remove the screws retaining the copper tip contacts (PH000, M1.4 x 5). Remove the copper tip contacts (note the orientation of the contacts \u0026amp; tiny tab hole). Lift the PCB gently up from Tip end. Remove the round copper ring contact from under the PCB, near the tip end of the handle (this is installed first before the PCB because it provides ground contact from the front of the Pinecil to the rear ground screw). Remove the two small round buttons so they do not get lost. Assembly steps Place the two round buttons into the two holes in the top half of the case. Install the round copper ground ring at the tip end before installing the PCB. Place the PCB board into handle at an angle, DC barrel end goes in first. Lower the rest of the board into the case and align the PCB with the 2 contact screw holes. Install the two copper tip contacts (note the small tab on the contact and the small hole in the PCB for it). Orient the contact to align the alignment pin with the alignment hole next to the big hole on one of the big gold pads. Install and gently tighten the PH000 screw until the clip is no longer loose. Place the bottom half of the case into the top half by sliding the lip on the port side (side without the feet) of the bottom half under the arch of the port side of the top half. Gently close the case by bringing the two halves together, paying attention to each clip’s alignment and ensuring the case edges align. Install the short PH1 screw at the bottom of the tip side of the case. Install the longer PH1 screw at the ground connection point at the top side of the case (between the display and the ports). Slide the rubber sleeve on (larger ridge first). Gently insert tip. Gently tighten the top PH1 screw to retain the tip. Note For normal operation of the iron, omission of the copper ring in step #2 does not impact operation. If you are working with ESD components, you need it in order to ground the iron tip via the earth screw at the back of the iron. It is recommended to keep this installed. FAQ Common Fixes Sometimes, just updating to the newest firmware fixes issues as Ralim and team are very active in adding features and enhancements (see Firmware). Some Troubleshooting information is also on GitHub Ralim’s IronOS (which is the firmware that is on the Pinecil). There are several hidden Debug tools in the firmware that also help with diagnosis. Clean all new Tips (Cartridges) with 90%-99% IPA (Isopropyl Alcohol) especially the white end with the 2 silver contacts. If you can’t find the information here or it hasn’t been written yet; simply join the volunteer run live Pinecil chat channel. Sometimes you can get a clue to the right path. Common Questions Temperature is flickering wildly: Most likely just need to clean whole cartridge/tip with IPA (reference issue). See Poor Contact Fix here]. If it’s jumping wildly after reaching set temperature, this is also caused by using a low amp/volt charger that is below the 3amp minimum required for Pinecil (per manufacturer rating), upgrading to a 3.25amp/20V USB-C charger often fixes this (reference issue). Some people might see a random spike while idle. Solution: update firmware, there are some ADC timing adjustments in IronOS 2.21+; it’s a good idea to keep your firmware updated to newest stable release (reference issue). This fix is included in 2.21+ release. I see No Tip connected symbol randomly on new Pinecil: tip is installed and it heats up, but randomly I get no tip symbol. See #1 above, it is most likely the same reason, dirty contacts on the back of the cartridge/tip. follow the same instructions for Poor Contact Fix here. Reference ticket on Github. How do I install the optional Hall Effect Sensor? See the Hall Effect Sensor article for installation; location is U14 on the PCB \u0026amp; in the Schematics. Reference schematics section also. Help, I think I bricked Pinecil doing an update: no worries, it’s very hard to brick a Pinecil because of the way the firmware is loaded in ROM. Usually just flashing again with a newer or different version brings it back to life (see Firmware). This can be done even if you can’t see your screen anymore. My Pinecil keeps rebooting: change to a different charger or add a ground wire to your Pinecil ground screw (search for ts100 ground wire on a search engine). Also see the Power Supplies article. This could happen because of the way 2-prong no-ground chargers are made with no ground path for small current leakage. Also try to plug the charger into a surge protector strip (type that have 3-prong ground and plug the surge protector into a 3-prong grounded wall outlet). Try a different cable or flipping the cable over also. Tip is glowing red hot. Unplug immediately, you have most likely a blown MOSFET, check that out, replacement parts in Datasheets below. Tip is probably damaged too. My temperature display is way off and Pinecil is at room temerature: first, check the poor contact fix. Then enter the hidden debug menu and look for HAN C which is the internal handle temperature. This should normally be close to or slightly higher than the room temperature if the Pinecil tip is also at room temperature. Under load, the HAN C can go up a bit, otherwise when the tip is cold, the HAN C should be close to ambient. Check the hidden debug menu for HAN C or C Han depending on your version of IronOS. See IronOS Troubleshooting here, esp. about CHan and the Temperature sensor. If the reading is out of spec (very low/high), and reflowing/resoldering the Temperature sensor does not work, replacement might be needed. Screen shows X symbol (no tip installed) and I have a tip installed. Remove the Tip screw, seat the tip all the way back, reinstalled the screw. See Tips and Poor Contact repair. I see Thermal Runaway or Undervoltage messages on the screen. This is often caused by using a weak power supply that does not have a minimum of 12V-3amps and is not rated to work with Pinecil. Pinecil will stop heat to the tip and display Thermal Runaway. TL;DR get a USB-C charger 20V 3.25 amps, PD 65W (best bang for the buck for good Pinecil performance) many available between $15-$25. Detailed information on chargers can be found under Power supplies. I plugged in the wrong kind of DC barrel charger, it was a not Center-positive pin and now the Pinecil won’t turn on: see Reverse polarity damage. Usually requires replacing the MOSFET (U13) and Buck Converter/Step-down (U8). See the datasheets for links to parts. I hear a sizzling/crackle sound from my new Pinecil: this is usually fine and may disappear after a few days of use, see Hissing Crackle Sound. Screen is black: first try to update firmware. Check out the IronOS troubleshooting guide here for possible issues. See the datasheets here at the bottom of this article for links to replacement parts. Repair method would be similar to ts100 screens of which there are many guides like this video. If the tip heats up, but screen is black, the OLED may have failed/burned out. If tip does not heat up, it may be something else. Sometimes just reflow/reheat the solder for the OLED screen fixes issues. Using OLED screen at lower brightness extends the life. Solutions Hissing Crackle Sound The sizzle sound will usually go away after a few days of use and heating up the iron. After wiping the tip contacts with IPA, heat it up a few times to 350 °C. Ralim said, \u0026ldquo;there is usually a bit of noise when you first use it, and a slight hiss/pop noise from the handle and that is normal. depends a bit on exactly what batch of caps are in your unit. The Tip drive signal is AC coupled through a capacitor for safety, downside is that it means the firmware is hitting that cap with a square wave the whole time the tip is on. Once you have heated up the duty cycle, it drops off so it’s not as noticeable.\u0026rdquo; Some members reported that after they opened their new Pinecil, wiped the PCB and tips gently with IPA, let it dry, all the sizzling noise went away. They also did a break-in of the new tips, bringing the temperature to 350 C a few times. Video of similar crackle sound on the ts100 iron (don’t have example of Pinecil, but it’s similar sound). Cartridge/Tip Problems Wipe entire tip (cartridge) clean, details in Poor Contact section Using a multimeter, switch it to ohms to measure resistance. Measure the two silver bands at the rear end (white). If it measures OL or infinity, or extremely out of the spec range below, it might be bad. Normal ts100 style tips should measure ~7.8 ohms - 8.3 ohms. PINE64 brand Short tips should measure ~6.1-6.5 ohms. See the Tips for more details. Poor Contact Fix Most likely the tip (cartridge) is not making good contact (at the silver bands on the rear white end). Usually this issue goes away after a few days of use as the cartridge rubs against the internal contacts more. New cartridges could have factory residue on them that interferes with the R-tip reading. To fix this issue quicker, wipe all new tips (cartridges) with a dry towel or 90-99% IPA (isopropyl alcohol) especially the two silver contacts at the white end (do not use water to wipe as it could get into the seam line on the white end). With the Pinecil unplugged, remove and reinsert the tip a couple times and spin it a little inside against the contacts. Then plug it in and heat it up to 350 °C a few times for a couple minutes. These steps tend to resolve most new Pinecil or new cartridges causing flickering temperatures or \u0026ldquo;no-tip\u0026rdquo; icon displays randomly. Always unplug Pinecil before swapping tips. Hot swapping is not a good idea, and for the V2 this could cause strange behavior as the V2 auto-detects tip resistance only on power-up or reboot. Sometimes just disassembling and reassembling all parts back correctly and installing the 2 internal contacts with screws correctly also helps. Poor contact could happen if the tips are not clean or brand new with factory residue or not making good contact with the internal clips inside the Pinecil. The two contacts inside might need to also be removed, wiped and reinstalled with the two screws (ensure the small metal tab on the clip sits into the small hole in the PCB). See Pinecil Tips article for more details on testing. Reverse Polarity Damage Pinecil requires a center-positive DC power supply which most are, but some are reverse polarity and will destroy the electronics if used. If you plugged in a \u0026ldquo;center-negative\u0026rdquo; DC power supply, most likely the MOSFET and the buck converter are broken. This usually requires replacing the MOSFET (U13) and buck converter / step-down (U8). See the datasheets for links to replacement parts which is at the bottom of this article [[#Datasheets_for_Components| here]].\nImportant Check the polarity of the DC barrel plug before plugging in a random charger. Incorrect polarity will break the Pinecil. The video here shows how to check. Reference the article on [[Pinecil_Power_Supplies#DC_Barrel_Power| DC barrel chargers here]], (i.e., laptop bricks) for appropriate USB-C and DC chargers that will work with the Pinecil.\nImages Screen side: V2 on top, V1 below\nPinecone side: V2 on top, V1 below\nMOSFET V2\n_LDO_and_OP-Amp\nUnder the OLED screen, V2\nPinecil V1, 24V Mod Warning Do this at your own risk, read everything in this section and related/linked articles, and go to the Pinecil community chat if you desire advice. An incorrect cut of the trace could render the Pinecil non-working. Pinecil V1 has blue rubber. Newer Pinecil V2 has green rubber \u0026amp; Bluetooth LE chip\nThis modification is not for the V2 (sold after Aug 1, 2022 with green thumb grip) as the V2 already has 24V DC barrel charger capability. If you have an older V1 model, then first upgrade to the newest firmware here before starting this modification. The PD debug menu was added to the firmware in 2.17 and other important fixes came later. Access to the hidden PD debug menu is necessary to assist with this mod. See Ralim’s IronOS for how to use the hidden PD Debug here and check if your version of Pinecil V1 could benefit from the modification. If PD-Debug menu says \u0026ldquo;No VBUS\u0026rdquo;, then stop here, you do not need the modification or any cut of the trace line, it will not benefit you because there is no connection to the VBUS already. If it says \u0026ldquo;w. Vbus\u0026rdquo; then continue. If you don’t have a PD-Debug menu, then upgrade to the newest firmware first, see instructions above. Some models of V1 came with the PCB already capable of 24V as the Pine Store made modifications to the PCB (not all batches of V1 were the same). Do the PD debug test first to see if the mod is not required. See the February 2022 Community update here. The photo is incorrect in the article. It is not a before and after photo. Photo shows two separate PCBs of Pinecil V1 made at different times; therefore, the trace is cut in a slightly different location depending on which one it looks like. The PCB with 2 small via holes and is harder to cut in the correct location to avoid damaging the holes. This is called the \u0026ldquo;whalecil\u0026rdquo; in community chat (looks like a whale). PCB 1 style (left photo) is easier to cut the trace. Cut all the way across the trace and deep enough to cut the copper contact. PCB 2 style (right photo) is harder because the trace has to be cut without damaging the 2 via holes. Don’t plug in 24V until you first check with a USB-C PD charger that PD debug says No VBUS which means the mod is complete. If it still says W. Vbus, then the connection still exist. Cut a little deeper and clean the cut with some IPA (isopropyl alcohol) to remove any copper dust, dry it and check again. Taking a macro photo with a phone helps to examine the cut. If a USB-C charger is not available, often a phone with a USB-C port is a PD type, and can be used like a charger to plug in and check the PD debug messages (unfortunately, a PC port is not normally \u0026ldquo;PD\u0026rdquo; and won’t give proper PD Debug). If you want another set of eyes on it before you cut, post a photo of your PCB (near the Pinecone) on the Pinecil chat channel. Ask for a volunteer who has completed the 24V mod on a Pinecil V1 to assist. Not all chat people own a Pinecil even if they are in the Pinecil channel. ","permalink":"/documentation/Pinecil/How_to_repair/","tags":null,"title":"How to Repair"},{"categories":null,"contents":" InfiniTime InfiniTime (also known as JF’s project, FreeRTOS firmware or Pinetime-JF) is an open source (GPLv3) firmware written in {cpp} and based on FreeRTOS, LVGL and NimBLE. This firmware (version 0.7.1) is preloaded at the factory since the new batch of PineTime devkits and sealed PineTimes of end of September 2020. This page contains general information about the project. Actual project documentation and nuances are documented in the repository\nGitHub repo: https://github.com/InfiniTimeOrg/InfiniTime Official website: https://infinitime.io/ Read this first! InfiniTime and the bootloader are still in heavy development, and some features might not work as expected. Any issues should be reported on GitHub. Do not use a sealed PineTime as a development device, there is a fair amount of chances that you’ll brick it with very experimental firmware. OTA is relatively stable, but when you’re on an outdated bootloader version it can freeze which will require you to wait for the battery to run out. Known issues Warning Please read this section carefully before upgrading the firmware on your PineTime, especially if you are using a sealed device! Black screen after a reset in sleep mode Description This issue occurs if you are using the original bootloader (from InfiniTime 0.7.1), upgraded from InfiniTime 0.7.1 to 0.8.2 and the watch resets while the display is OFF: the watch is stuck on a black screen and does not respond to touch, button press or BLE.\nThe reset can be triggered by the watchdog or manually by long pressing the button. If that doesn’t work, wait for the battery to run out, it’ll reboot then.\nThis issue is caused by InfiniTime 0.8.2 that put the external SPI flash memory to sleep before switching the display off and by the bootloader that cannot wake the memory chip up. The bootloader is stuck in an infinite loop.\nMore info: https://github.com/lupyuen/pinetime-rust-mynewt/issues/24 and https://github.com/JF002/InfiniTime/issues/60\nWorkaround On a development kit, a simple reset via SWD is needed to unlock the bootloader.\nOn a sealed device, the only way to work around this issue is to wait for the battery to drain completely before trying again.\nThis issue can be avoided by ensuring that the display is ON when manually resetting the device (long push on the button).\nFixed version This issues is fixed in InfiniTime 0.8.3\nReleases In the order of oldest first.\nVersion 0.7.1 Link: Version 0.7.1\nThis is the version that ships with PineTime devkits and sealed PineTime as of September 2020.\nTime synchronization over BLE Display brightness setting Notifications over BLE Integration with AmazFish (SailFishOS) and Gadgetbridge (Android) OTA using NRFConnect Bootloader: https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v4.1.7\nVersion 0.8.2 Link: Version 0.8.2\nMusic control app Paint app Manual image validation after OTA Bootloader: https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4.\nThis new version of the bootloader fixes Black screen after a reset in sleep mode and enables the watchdog before launching the firmware.\nVersion 0.8.3 Link: Version 0.8.3\nFixes the \u0026ldquo;bootloader stuck after a reset\u0026rdquo; mentioned in 0.8.2 above Version 0.9.0 Link: Version 0.9.0\nTouch panel fixed (no more freezing) Improved music application (possibility to control both volumes and browsing, display the song progression) Notification UI rewritten: can now display up to 100 characters Improved BLE connectivity Version 0.10.0 Link: Version 0.10.0\n2 new games: Pong and 2048 Fixed display glitches and improved needed time to turn on the display Version 0.11.0 Link: Version 0.11.0\nHeart-rate sensor application: Displays the current value, and when running, this value is also displayed on the clock face Value exposed over BLE, meaning other applications can read it (e.g. companion app such as Amazfish) Navigation app: InfiNav - works e.g. with PureMaps on SailfishOS Version 0.12.0 Link: Version 0.12.0\nImproved BLE connection OTA updates much more reliable Version 0.13.0 Link: Version 0.13.0\nVibration Call notification: it is possible to accept/ignore/reject a call from the PineTime Music app got nicer icons BLE connectivity improved a bit more Version 0.14.0 \u0026ldquo;Green Avocado\u0026rdquo; Link: Version 0.14.0 \u0026ldquo;Green Avocado\u0026rdquo;\nLVGL 7 Bugfixes to the build process Version 0.14.1 Link: Version 0.14.1\nNew Recovery firmware MCUBoot based bootloader Version 0.15.0 \u0026ldquo;Yellow Banana\u0026rdquo; Link: Version 0.15.0 \u0026ldquo;Yellow Banana\u0026rdquo;\nAnalog watch face Support for switching watch faces Stopwatch app Version 1.0.0 \u0026ldquo;Red Cherry\u0026rdquo; Link: Version 1.0.0 \u0026ldquo;Red Cherry\u0026rdquo;\nMotion sensor integration Step countin UI redesign Quick action menu: Brightness setting Do not disturb mode (disable vibrations on notifications) Flash light application Settings menu allowing configuration of: Display timeout Wakeup source (button only, single tap, double tap and wrist rotation) Time format (12/24H) Watchface New navigation flow: User settings stored in flash memory and restored on reset Version 1.1.0 \u0026ldquo;Dragon Fruit\u0026rdquo; Link: Version 1.1.0 \u0026ldquo;Dragon Fruit\u0026rdquo;\nSteps application Timer application UI improvements Clang-format and clang-tidy config files Bugfixes Version 1.2.0 \u0026ldquo;Blue-purple Elderberry\u0026rdquo; Link: Version 1.2.0 \u0026ldquo;Blue-purple Elderberry\u0026rdquo;\nAdded support for alternate accelerometer part BMA425 Metronome app Memory usage optimizations Bugfixes, minor improvements and code cleanup Version 1.3.0 \u0026ldquo;Purple Fig\u0026rdquo; Link: Version 1.3.0 \u0026ldquo;Purple Fig\u0026rdquo;\nLittleFS integration New watchface, PineTimeStyle Battery level notification on BLE (supported by Gadgetbridge) Improved stopwatch app, Paddle game and call notifications Firmware update app is now more foolproof The SPI flash is put in sleep mode when the watch goes to sleep (only if the new bootloader is detected) UI improvements (better \u0026rsquo;tick\u0026rsquo; handling in LVGL, more consistent refresh rate) Various improvements and code cleaning Version 1.4.0 \u0026ldquo;Pink Grapefruit\u0026rdquo; Link: Version 1.4.0 \u0026ldquo;Pink Grapefruit\u0026rdquo;\nImproved touch driver Color customization for background, text and lateral bar of PineTimeStyle UI improvements for better use of the small screen, and screen dimming before display sleeps Call notification improvements Battery level improvements Attempts to fix bootloop issue Version 1.5.0 \u0026ldquo;Huckleberry\u0026rdquo; Link: Version 1.5.0 \u0026ldquo;Huckleberry\u0026rdquo;\nAlarm app Vibration improvements Ability to recover time after a reset BLE improvements Battery level improvements Version 1.6.0 \u0026ldquo;Ice Apple\u0026rdquo; Link: Version 1.6.0 \u0026ldquo;Ice Apple\u0026rdquo;\nA new BLE Fix Version 1.7.0 \u0026ldquo;Jackfruit\u0026rdquo; Link: Version 1.7.0 \u0026ldquo;Jackfruit\u0026rdquo;\nMore accurate battery percentage Faster wakeup (video) New touch handler Wake on notification and charge Memory usage and speed optimizations Motion service (video) Flashlight brightness changes Manual date and time setting Battery percentage reporting Disabled Touch Controller error check Paddle game bounds checking Version 1.7.1 Link: Version 1.7.1\nTouchscreen failure edge case Version 1.8.0 \u0026ldquo;Fuzzy Kiwi\u0026rdquo; Link: Version 1.8.0 \u0026ldquo;Fuzzy Kiwi\u0026rdquo;\nImproved gesture consistency Digital watchface: Changed the color of the BLE icon to the official \u0026ldquo;Bluetooth™ blue\u0026rdquo; PineTimeStyle: Integrated color picker into the watchface (long tap on the PTS watch face, and then tap on the gear icon that appears to open the color settings) * PineTimeStyle: Fixed alignment of the icons Settings: Styled checkboxes as radio buttons Paddle: Speed randomization InfiniPaint: Vibration on color change (long tap to change color when running InfiniPaint) BLE secure pairing BLE file system API Weather service (integrations are planned for the future) Trip meter in Step app Chimes: Short vibration every hour or half an hour. Settings are available in the 3rd page of settings Shake to wake: The calibration of the sensitivity is available in the 3rd page of settings Version 1.9.0 \u0026ldquo;Limeberry\u0026rdquo; Link: Version 1.9.0 \u0026ldquo;Limeberry\u0026rdquo;\nTerminal watchface Enable/Disable BLE InfiniSim, the LVGL simulator for InfiniTime Improve notification and call notification timeout Improve heart-rate measurements Improve Alarm App Better 12-hours mode integration (in settings, alarm and status bar) Code cleanup and many improvements needed by InfiniSim Fix display corruption when the timer is triggered Fix freeze in Music app when the title/album name were too long Version 1.10.0 \u0026ldquo;Yellow Mango\u0026rdquo; Link: Version 1.10.0 \u0026ldquo;Yellow Mango\u0026rdquo;\nNotifications can now be dismissed by right swiping on the notification Faster sleep New sharper battery icon Timer UI was overhauled Tweaked and improved display gamma to improve the colors displayed by the LCD Flashlight now defaults to max brightness Fixed track progress in Music app Fixed alarm sometimes not ringing Version 1.11.0 \u0026ldquo;Red Nectarine\u0026rdquo; Link: Version 1.11.0 \u0026ldquo;Red Nectarine\u0026rdquo;\nAbility to install external resources, such as watch faces, images, and fonts. Created a document to better communicate the vision of InfiniTime project to users, developers and everyone else Compatibility with LFCLK calibration and reduced the power consumption of Nimble Limit backlight brightness when flashlight is off Watch face inspired by the G7710, with day of year and week number info (+ battery level %) Infineat watch face + its external resources Added pink color for PinetimeStyle watch face PineTimeStyle watch face : make step count display configurable (full gauge for step count, half gauge with seconds and numerical display of the step count). Oneshot 1.11 - FOSDEM 2023 Edition Link: Oneshot 1.11 - FOSDEM 2023 Edition\nOneshot version, which was created for the \u0026ldquo;Free and Open source Software Developers\u0026rsquo; European Meeting\u0026rdquo; Digital and analog watchfaces with FOSDEM’s logo as the background Version 1.12.0 \u0026ldquo;Olallieberry\u0026rdquo; Link: Version 1.12.0 \u0026ldquo;Olallieberry\u0026rdquo;\nProject maintenance Added Watchmate to the list of companion apps Better battery level monitoring, and battery indicator alert Date and time settings are combined into a single setting page Updated settings list style Version 1.13.0 \u0026ldquo;Pomegranate\u0026rdquo; Link: Version 1.13.0 \u0026ldquo;Pomegranate\u0026rdquo;\nNew heart rate processing algorithm, provides more accurate and faster results New memory management (heap unification) Weather integration in PineTimeStyle watch face Major power optimizations Bug fix in shake wake ","permalink":"/documentation/PineTime/Software/InfiniTime/","tags":null,"title":"InfiniTime"},{"categories":null,"contents":"Infinitime features a weather subsystem which stores weather data on the watch in a timeline which can be queried by apps or watchfaces. It can store many different types of data (see here) and each entry includes a timestamp and an expiry time. When entries expire they are removed from the timeline automatically.\nSending weather data to the watch Weather data must be sent to the watch via a companion app. Currently, ITD and Gadgetbridge have this functionality implemented.\nITD ITD is the easiest option as the feature simply needs enabling in the config file with a location specified. It uses data from MET.no and provides one hour of data at a time.\nGadgetbridge Gadgetbridge is slightly more difficult to set up as it requires a separate app to fetch the weather data. Details are available on the Gadgetbridge website.\nDisplaying weather data Currently there are 2 ways to display weather data on the watch, a debug app which is disabled by default, and the PineTimeStyle watchface. To enable it, press and hold on the watch face, tap the settings icon and enable weather.\nThe easiest way to enable the debug app is to change the entry for the navigation app in DisplayApp.cpp to load the weather debug app instead:\ncase Apps::Navigation: //currentScreen = std::make_unique\u0026lt;Screens::Navigation\u0026gt;(this, systemTask-\u0026gt;nimble().navigation()); currentScreen = std::make_unique\u0026lt;Screens::Weather\u0026gt;(this, systemTask-\u0026gt;nimble().weather()); break; ","permalink":"/documentation/PineTime/Software/InfiniTime_weather/","tags":null,"title":"InfiniTime weather"},{"categories":null,"contents":"\nThe approximate dimensions are 26mm x 43mm.\nSchematics: PineCone BL602 EVB schematic ver 1.1\nNote: In the PineCone revision 1.1 (\u0026ldquo;BL62B_EVB V1.1\u0026rdquo; silkscreened on back of board), CC1 and CC2 share one 5.1KΩ resistor. This means the board will fail to power when you use an e-marked USB-C cable like the one that comes with Apple chargers. See this article for details of why this happens. The next schematic design will give each line its own 5.1KΩ resistor as per the USB-C specification.\nThe board uses a CH340 Serial/USB adapter. This chip is commonly used in Arduino-class development boards. It is a full speed (12Mbps) USB interface and has vendor ID 0x1a86 with product ID 0x7523.\nThe GPIO pins (11, 12, 14, 17) plus the nearby RESET, POWER, and GND pins are all located on one side of the board, on J1 to provide JTAG connection.\n","permalink":"/documentation/PineCone/Further_information/Information_and_schematics/","tags":null,"title":"Information and schematics"},{"categories":null,"contents":"To install a cluster it is important to know the IP addresses of each module, so the remote login sessions do not get mixed up.\nEach module may be plugged into the Clusterboard individually or consecutively, which makes it easy to assign a hostname to each module separately. It is also possible to manually edit the hostname in the OS image of each module before the first boot.\nTip The board has no hotplug functionality, so make sure you only plug/unplug the modules while the power is disconnected from the Clusterboard. Tip No management features are available on the switch ship, so there is no VLAN support. Serial console To boot use the serial console connect the pins to UART0 on the GPIO header and connect using baud 115200\nPin 6: GND Pin 7: RTX Pin 8: TXD The pinouts are available in this forum thread.\nTip Do not connect the GND connector until the power is on as it can provide power and prevent the board from booting. ","permalink":"/documentation/Clusterboard/Installation/","tags":null,"title":"Installation"},{"categories":null,"contents":"The software releases can be installed (the process is being referred to as flashing) to the internal memory of the PinePhone Pro (the eMMC) or to an microSD card.\nInstallation to the microSD card The images can be installed to an microSD card and be booted from it.\nThe microSD belongs in the upper slot, the SIM in the lower slot.\nNote Compared to installations to the eMMC, running operating systems from the microSD card is slower than to the eMMC due to the microSD card’s slower reading and writing speeds. To install an image to the microSD card:\nDownload a compatible image from Releases. Important: Typically the image will be compressed in an archive file to reduce the download size (such as .gz or .xz). Extract the image from its archive file to get the file with the file extension .img. Write the image to your microSD card using your favorite method, examples: Using dd: On the device you’re flashing the microSD card from, find the correct device under lsblk and then flash the image to the microSD card using sudo dd if=IMAGE.img of=/dev/[DEVICE] bs=1M status=progress conv=fsync and make sure the target is the whole microSD card and not its first partition, sdc1 or mmcblk0p1 are wrong! Using bmaptool: Make sure to select the correct device using lsblk. Then run bmaptool with the correct device: Download the IMAGE.xz and the IMAGE.bmap files, then run bmaptool copy --bmap IMAGE.bmap IMAGE.xz /dev/[DEVICE]. This takes around 2.5 minutes to flash a 4 GB file. Using a graphical tool: A graphical tool such as Gnome Disks under Linux or Etcher under Windows may also be used. Insert the microSD card into the top slot of the PinePhone Pro Boot the device using the following method: With rk2aw (as on the Explorer Edition ordered after November 2023): boot the phone without any further action if the image includes a bootloader or one is installed to the eMMC (such as in the default installation). With Tow-Boot (as on the Explorer Edition ordered after July 2022): hold the volume down key while booting. With an empty SPI (like on the Explorer Edition ordered between January and July 2022): hold the RE button underneath the back cover while booting (or use the volume down key if you flashed Tow-Boot). On the Developer Edition (sold to selected developers only) there is no RE button. Instead apply the bypass by shorting the testing pads while booting according to the datasheet. Installation to the eMMC Installing an operating system to the eMMC (the internal memory of the PinePhone Pro) can either be done by booting an operating system from the microSD and by installing to the eMMC directly from the booted microSD card operating system (recommended) or by using Tow-Boot\u0026rsquo;s USB Mass Storage mode.\nWarning Many images don’t include a bootloader. If the SPI only contains rk2aw (like phones ordered after November 2023) or is empty (like phones ordered between January and July 2022), the installation on the eMMC won’t boot. In these cases, it is required to install a bootloader (such as Tow-Boot) in order to get the phone to boot. By booting a microSD card The eMMC can be overwritten by booting an image from the microSD card and overwriting the eMMC from within that booted microSD card image.\nThis installation method is recommended.\nBoot an operating system from the microSD card. If there is already a bootloader on the eMMC installed see the section Boot order to bypass it. Download or copy the desired image to the microSD card as file Check if the eMMC appears under lsblk. If it doesn’t appear in the output of the command, the eMMC wasn’t initialized due to applying the above explained bypass method for a too long time during the boot Important: Typically the image will be compressed in an archive file to reduce the download size (such as .gz or .xz). Extract the image from its archive file to get the file with the file extension .img. Flash the image file using sudo dd if=IMAGE.img of=/dev/mmcblk2 bs=1M status=progress conv=fsync (replace IMAGE.img with the filename of the image you want to flash and make sure it has the file extension .img). Reboot the PinePhone Pro By using Tow-Boot The image can be written to the eMMC by using Tow-Boot’s USB Mass Storage mode.\nThis installation method is not recommended, as the USB connection can be unreliable and in some cases not work at all.\nPre-requirement: Tow-Boot must be installed on the SPI, eMMC or the microSD card Power off the device Power on the device and hold the volume up key before and during the second vibration The LED will turn blue if done successfully. This will only work if Tow-Boot is installed When connecting the device to a computer via USB it will behave like an USB drive now Check if the eMMC appears under lsblk, the output might look like the following:\nmmcblk2 179:0 0 115.2G 0 disk\n├─mmcblk2p1 179:1 0 122M 0 part /boot\n└─mmcblk2p2 179:2 0 115.1G 0 part /\nNote: In this example, /dev/mmcblk2 is the device, while mmcblk2p1 and mmcblk2p2 are partitions of the device. The downloaded images are images from full devices, which means that the full device (mmcblk2 in this example) needs to be flashed. Ignore the partitions! Important: Typically the image will be compressed in an archive file to reduce the download size (such as .gz or .xz). Extract the image from its archive file to get the file with the file extension .img Flash the image file using sudo dd if=IMAGE.img of=/dev/DEVICE bs=1M status=progress conv=fsync (replace IMAGE.img with the filename of the image you want to flash and make sure it has the file extension .img and replace DEVICE with the correct device from the lsblk command) Reboot the PinePhone Pro ","permalink":"/documentation/PinePhone_Pro/Software/Installation_instructions/","tags":null,"title":"Installation instructions"},{"categories":null,"contents":"For instructions on how to install the operating systems to the eMMC or microSD card see Installation instructions. The information is almost the same for the PineTab, as it is a very similar device. Do not try to use the PinePhone images though, use the PineTab images linked above.\n","permalink":"/documentation/PineTab/Installation_instructions/","tags":null,"title":"Installation instructions"},{"categories":null,"contents":"The PineTab2 is capable of running different operating systems from the internal flash memory (eMMC) and from microSD card.\nPreparing the microSD card To write an operating system to the microSD card (typically called \u0026ldquo;flashing\u0026rdquo; in the community), you need to first download a compatible image from the Releases page.\nNext you need to decompress the downloaded image. The images are typically compressed in an archive format such as xz to reduce the download size. If you are using a graphical tool such as balenaEtcher or Gnome Disks it will handle the decompression of the image in the flashing step automatically.\nFurther you need to flash the image to the microSD card. This can be done using various tools, for example balenaEtcher (recommended for new users), Gnome Disks or command-line tools such as cp and dd. Insert the microSD card in a microSD card reader connected to your computer and then choose a tool of your liking.\nGraphical applications:\nbalenaEtcher (Microsoft Windows, macOS, Linux): Click on Flash from file and select the image. Then select the microSD card target device and click on Flash!. Gnome Disks (Linux): Select the microSD card target device on the left side in the Disks list. Then select the three dot menu on the top right and click on Restore Disk Image\u0026hellip;. Select the image, verify the correct device is selected and then click on Start Restoring\u0026hellip;. Command-line tools:\ncp:\nsudo cp IMAGE.img /dev/[DEVICE]\ndd:\nsudo dd if=IMAGE.img of=/dev/[DEVICE] bs=1M status=progress conv=fsync\nNote Make sure to replace IMAGE.img and [DEVICE] with the filename of the image (double check if it is decompressed and has the file extension .img) and the device name. You can use the command lsblk to find the device name. Make sure to flash to the whole device instead of partition 1 and that you’re NOT selecting /dev/sda1 or /dev/mmcblk0p1 as target. Be very careful to select the correct device, as the tools can overwrite your data when the wrong device is selected. Then insert the microSD card into the PineTab2.\nNote The UART adapter\nUsing the USB UART adapter can be required in some cases as explained in the info box about the boot order. The adapter is shipped with the PineTab2 in the box which is also containing the charging cable. The switch to disable the eMMC and SPI is located on the top right of the image.\nNote Note regarding the boot order: The SPI and the internal memory (eMMC) have a higher boot priority than the microSD card. The pre-installed bootloader on the internal memory (eMMC) tries to boot from the microSD card first. In some cases it can be required to bypass the bootloader, for example if the bootloader is corrupted or was overwritten by a bootloader with varying settings.\nTo force the device to boot from the microSD card, the eMMC and the SPI can be disabled by using the debug UART adapter shipped with the device in the box also containing the charging cable. Set the SD BOOT MASKROM switch on the adapter to the position ON and plug it into the USB/PD charging port. Then power on the tablet and unplug the debug board or set the switch to the position OFF again when the factory image is started, otherwise the factory image won’t find the eMMC.\nPower on the device with the microSD card inserted (and optionally with the USB UART adapter inserted and the bypass switch set to ON depending on the software situation, see the info box above). It should now boot the new operating system from the microSD card.\nSomething is not working? Please join the PineTab channel in the community chat, the community is always happy to help. In the page UART adapter you can find information about how to connect the USB UART adapter and how to retrieve the boot logs if the device is not booting properly even after the above procudere.\n","permalink":"/documentation/PineTab2/Software/Installation_instructions/","tags":null,"title":"Installation instructions"},{"categories":null,"contents":"The internal memory of the PinePhone (eMMC) can be flashed using multiple different methods.\nFrom the booted microSD OS Flash an OS to the microSD card (and optionally resize the partition, see below) Insert microSD card and boot the phone Download the desired OS\u0026rsquo; image on the booted OS or transfer it to the microSD card Extract the image file if it is archived Flash the image file to eMMC using dd if=IMAGE.img of=/dev/mmcblkX bs=1M conv=fsync where X is the number label of the eMMC (of the disk, not the partition!). Use the command lsblk to check your devices: typically with the current kernel the microSD card is /dev/mmcblk0 and the eMMC is /dev/mmcblk2 but as always with dd be extremely cautious to get the devices correct. Turn off phone, remove microSD card and then turn on the phone. Using JumpDrive Note This only applies to the regular PinePhone, not the PinePhone Pro. Jumpdrive running on the PinePhone\nThe internal eMMC flash storage can be flashed using the Jumpdrive utility by Danct12 and Martijn from postmarketOS. This utility boots from micro SD and exposes the internal eMMC flash storage when the PinePhone is connected to a computer. The process of flashing an OS to the exposed and mounted eMMC is identical to that of any other storage medium - e.g. a microSD card. You can use the dd command or a utility such as Etcher or Gnome Disks, etc.\nLatest Jumpdrive can be found here.\nDownload and extract the Jumpdrive image Flash the Jumpdrive image to a microSD card Boot the PinePhone from the Jumpdrive microSD card Connect the PinePhone to your computer using USB-A -\u0026gt; USB-C cable Flash the exposed PinePhone drive (e.g. /dev/mm\u0026hellip;, check for the right device in dmesg, GNOME disks, or similar, and make sure it’s unmounted) with your chosen OS image Once the flashing process is complete, disconnect the PinePhone from your PC, power it down and remove the Jumpdrive microSD card The process is now finished, and you can boot from eMMC The Jumpdrive image is smaller than 50MB. You can keep an microSD card specifically for using Jumpdrive, and there are 64MB microSD cards sold cheaply that will suffice. Jumpdrive also acts as a rescue image in case if you messed up your installation. To do so, you can telnet to 172.16.42.1, mount rootfs and fix it!\nSD to eMMC via installer An special installer image booted from the microSD card can be used to flash the eMMC as well. Mobian and postmarketOS installer images booted from microSD card will simply ask the user if they want to install to eMMC. The feature lives in the distribution-agnostic calamares-extensions repository (see calamares-extensions#7), so other distributions might adopt this in the future.\nUsing Tow-Boot Tow-Boot is an opinionated distribution of the U-Boot bootloader. It includes an USB Mass Storage Mode, which exposes the flash drive(s) to a computer connected to the phone via USB-C. The Tow-Boot bootloader has to be installed if it is not pre-installed already. For instructions see the following links:\nPinePhone: https://tow-boot.org/devices/pine64-pinephoneA64.html PinePhone Pro: https://tow-boot.org/devices/pine64-pinephonePro.html If Tow-Boot is installed the phone can be started into USB Mass Storage Mode by holding the volume up key on startup.\nThe steps of flashing an operating system to the phone after booting Tow-Boot’s USB Mass Storage Mode and connecting the phone to a computer is identical to that of any other storage medium - e.g. a microSD card. You can use the dd command or a utility such as Etcher or Gnome Disks from the computer the phone is connected to.\n","permalink":"/documentation/PinePhone/Installation/Installation_to_the_eMMC/","tags":null,"title":"Installation to the eMMC"},{"categories":null,"contents":"For this installation method you need a microSD card, a microSD card reader and a compatible device, such as a computer or a laptop with Linux, iOS, Windows or similar (note: ChromeOS is not supported).\nTo install an image to the microSD card:\nDownload your chosen image from Releases for the regular PinePhone (not compatible with the PinePhone Pro). Extract the compressed file Write (flash) the image to your microSD card, see the instructions below Plug microSD card into phone (make sure to use the top slot, not the bottom slot) Boot up the phone The microSD belongs in the upper slot, the micro-SIM in the lower slot.\nUsing Balena Etcher Using the graphical application Balena Etcher to flash the microSD card is \u0026lsquo;recommended\u0026rsquo; for new or inexperienced users.\nDownload and install the application: https://etcher.balena.io/#download-etcher\nThen start it and click the button Flash from file:\nSelect the downloaded image and make sure that you downloaded the correct one. Images for the PinePhone and the PinePhone Pro are \u0026rsquo;not compatible\u0026rsquo; with each other. Images for the PinePhone typically have the word \u0026ldquo;PinePhone\u0026rdquo; in the filename, while images for the PinePhone Pro typically have \u0026ldquo;PinePhone Pro\u0026rdquo; in their filename.\nNote At this the image file does not have to be extracted from the archive format. Balena Etcher handles the extracting automatically. Then click on Select target:\nNote Make sure to select the correct target by comparing the name and the disk capacity with the label on the microSD card. Then click on Flash!:\nThat’s it!\nUsing dd For flashing the microSD card, the command dd can be used as well.\nMake sure to select the correct device using lsblk. Then run dd with the selected device:\nsudo dd if=IMAGE.img of=/dev/[DEVICE] bs=1M status=progress conv=fsync\nNote The image needs to be written to the whole device, not to partition 1. Make sure you’re NOT selecting /dev/sda1 or /dev/mmcblk0p1 as target. Using bmaptool Make sure to select the correct device using lsblk. Then run bmaptool with the correct device:\nDownload the IMAGE.xz and the IMAGE.bmap files, then run:\nbmaptool copy --bmap IMAGE.bmap IMAGE.xz /dev/[DEVICE]\nThis takes around 2.5 minutes to flash a 4 Gb file.\nUsing Gnome Disks The graphical application Gnome Disks can be used to flash the microSD card as well.\nTo do so, select the correct device in the left device selection, then click on the three dot menu and select Restore Disk Image\u0026hellip; and follow the on-screen instructions.\n","permalink":"/documentation/PinePhone/Installation/Installation_to_the_microSD_card/","tags":null,"title":"Installation to the microSD card"},{"categories":null,"contents":"These instructions can be followed to install Arch Linux ARM on an SD Card, USB Flash Drive, eMMC, or even NVMe if your U-Boot supports it (example Tow-Boot on SPI).\nCommands to be run as a normal user are prefixed with $, commands to be run as root (or with sudo) are prefixed with #. The target device is assumed to be /dev/sdb, adjust accordingly.\nPartitioning Flashing U-Boot Important While any build of U-Boot for the Pinebook Pro can be used, this tutorial uses Tow-Boot. The process of installing Tow-Boot is different from any other U-Boot build, so large parts of the partitioning section will need to be changed if you want to use something else. If you already have Tow-Boot installed via SPI, you can skip this step. Use fdisk to create a blank GPT partition table. /boot will be partition 1, and / will be partition 2. Download and extract the latest release of Tow-Boot for the Pinebook Pro from https://github.com/Tow-Boot/Tow-Boot/releases.\n$ wget https://github.com/Tow-Boot/Tow-Boot/releases/download/release-2021.10-004/pine64-pinebookPro-2021.10-004.tar.xz $ tar xf pine64-pinebookPro-2021.10-004.tar.xz Flash Tow-Boot to /dev/sdb (replace this with the device you actually intend to use).\n# dd if=pine64-pinebookPro-2021.10-004/shared.disk-image.img of=/dev/sdb bs=1M oflag=direct,sync This creates the partition table for the device, with the first partition serving to protect Tow-Boot. Do not move or write to this partition.\nCreating the partitions Use fdisk to add partitions to /dev/sdb.\n# fdisk /dev/sdb Create the /boot partition.\nType n to create a new partition. Press enter for partition number two. Press enter for the default start sector. Type +512M to make the new partition with 512 MB. Mark the /boot partition bootable.\nType x to enter expert mode. Type A to mark a partition bootable. Type 2 to select partition two. Type r to exit expert mode. Create the root partition.\nType n to create a new partition. Press enter for partition number three. Press enter for the default start sector. Press enter to fill the rest of the device. Write the changes to disk.\nType w to write the changes and exit. Formatting the partitions Format the /boot partition as a filesystem supported by your U-Boot. ext4 is recommended:\n# mkfs.ext4 /dev/sdb2 Format the root partition as any filesystem supported by Arch Linux ARM. btrfs for example:\n# mkfs.btrfs /dev/sdb3 Installing the root filesystem Mounting the partitions # mount /dev/sdb3 /mnt # mkdir /mnt/boot # mount /dev/sdb2 /mnt/boot Downloading and verifying the rootfs tarball Download the tarball and its PGP signature.\n$ wget http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} Import the Arch Linux ARM signing key.\n$ gpg --keyserver keyserver.ubuntu.com --recv-keys 68B3537F39A313B3E574D06777193F152BDBE6A6 Verify the tarball’s authenticity.\n$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig Verifying the authenticity of the tarball protects you in two ways:\nMakes sure the tarball came directly from Arch Linux ARM and was not tampered with Prevents you from using a corrupt tarball (for example from an interrupted download) Extracting and configuring the root filesystem Extracting the root filesystem # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt Editing fstab Find the partitions\u0026rsquo; UUIDs with blkid.\n# blkid /dev/sdb3 /dev/sdb2 Example output:\n/dev/sdb3: UUID=\u0026#34;c1ec9712-5c64-46da-852c-9d665416e8a6\u0026#34; UUID_SUB=\u0026#34;90e5b654-6967-471a-9d35-8997488b1ba8\u0026#34; BLOCK_SIZE=\u0026#34;4096\u0026#34; TYPE=\u0026#34;btrfs\u0026#34; PARTUUID=\u0026#34;885dd863-a550-2d47-89dd-f54fd6744ca5\u0026#34; /dev/sdb2: UUID=\u0026#34;21bbff3f-b82e-416e-93c8-e6d44c3daf82\u0026#34; BLOCK_SIZE=\u0026#34;4096\u0026#34; TYPE=\u0026#34;ext4\u0026#34; PARTUUID=\u0026#34;be571200-1a56-5d4c-9a5b-88a5f36a295e\u0026#34; Add the following lines to /mnt/etc/fstab, substituting the example UUIDs with those you received from blkid.\nUUID=c1ec9712-5c64-46da-852c-9d665416e8a6 / btrfs defaults 0 1 UUID=21bbff3f-b82e-416e-93c8-e6d44c3daf82 /boot ext4 defaults 0 2 Creating extlinux.conf Create a file /mnt/boot/extlinux/extlinux.conf with the following contents, replacing the example UUID with the one for /dev/sdb3 from blkid.\nDEFAULT arch MENU TITLE Boot Menu PROMPT 0 TIMEOUT 50 LABEL arch MENU LABEL Arch Linux ARM LINUX /Image INITRD /initramfs-linux.img FDT /dtbs/rockchip/rk3399-pinebook-pro.dtb APPEND root=UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 rw LABEL arch-fallback MENU LABEL Arch Linux ARM with fallback initramfs LINUX /Image INITRD /initramfs-linux-fallback.img FDT /dtbs/rockchip/rk3399-pinebook-pro.dtb APPEND root=UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 rw Booting and finishing setup Boot into Arch Linux ARM and log in as root with password root.\nInitialize the pacman keyring.\n# pacman-key --init # pacman-key --populate archlinuxarm For security, change the default passwords for root and the default user alarm.\n# passwd # passwd alarm You have now installed Arch Linux ARM on your PineBook Pro.\n","permalink":"/documentation/Pinebook_Pro/Software/Installing_Arch_Linux_ARM/","tags":null,"title":"Installing Arch Linux ARM"},{"categories":null,"contents":"The articles explains the installation of Arch Linux ARM on the Quartz64.\nCommands to be run as a normal user are prefixed with $, commands to be run as root are prefixed with #. We assume your target device is /dev/sdX, adjust accordingly.\nPartitioning The Block Device Here we assume your block device is /dev/sdX, adjust as needed.\nCreate a new partition table:\n# parted -s /dev/sdX mklabel gpt Create the partitions for loader and u-boot:\n# parted -s /dev/sdX mkpart loader 64s 8MiB # parted -s /dev/sdX mkpart uboot 8MiB 16MiB Create the partition for u-boot’s environment:\n# parted -s /dev/sdX mkpart env 16MiB 32MiB Create the \u0026ldquo;efi\u0026rdquo; boot partition and mark it as bootable:\n# parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB # parted -s /dev/sdX set 4 boot on Create the root partition:\n# parted -s /dev/sdX mkpart root ext4 544MiB 100% Creating The File Systems Now create the file systems for boot and root:\n# mkfs.vfat -n \u0026#34;efi\u0026#34; /dev/sdX4 # mkfs.ext4 -L \u0026#34;rootfs\u0026#34; /dev/sdX5 Fetching and Flashing U-Boot For this we’ll use the precompiled idblock and u-boot from pgwipeout’s CI.\nGo to https://gitlab.com/pgwipeout/quartz64_ci/-/pipelines and click the three dots, download the merge-job artifacts.\nUnzip them:\n$ unzip artifacts.zip Flash idblock.bin and uboot.img:\n# dd if=artifacts/idblock.bin of=/dev/sdX1 # dd if=artifacts/uboot.img of=/dev/sdX2 Fetching The Root File System Tarball Fetch the root filesystem tarball and the PGP signature\n$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} Fetch the gpg keys:\n$ curl \u0026#39;https://keyserver.ubuntu.com/pks/lookup?op=get\u0026amp;search=0x68b3537f39a313b3e574d06777193f152bdbe6a6\u0026#39; | gpg --import=- Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS)\nVerify the tarball’s authenticity\n$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig Important Do not skip verifying the authenticity. This is important. It also protects you from prematurely aborted transfers giving you a corrupt archive. Installing The Root File System # mount /dev/sdX5 /mnt/alarm-root # mkdir /mnt/alarm-root/boot # mount /dev/sdX4 /mnt/alarm-root/boot # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root Editing fstab Find your partition UUIDs for both partitions using lsblk:\n$ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID In /mnt/alarm-root/etc/fstab, put the lines\nPARTUUID=_root-uuid-here_ / ext4 defaults 0 1 PARTUUID=_boot-uuid-here_ /boot vfat defaults 0 2 with your UUIDs in place of the placeholder.\nWriting extlinux.conf Create a /mnt/alarm-root/boot/extlinux/extlinux.conf with these contents:\ndefault l0 menu title Quartz64 Boot Menu prompt 0 timeout 50 label l0 menu label Boot Arch Kernel linux /Image fdt /dtbs/rockchip/rk3566-quartz64-a.dtb append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xfe660000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait For Model B Kernel 5.18 and 5.19 do not yet have the Quartz64 Model B device tree, however, you can add it manually to your install and adjust extlinux.conf:\nDownload it from here: https://overviewer.org/~pillow/up/5f1fabef1b/rk3566-quartz64-b.dtb (this is just linux-next with sd card speed changed to sd-uhs-sdr50)\nCopy it to /mnt/alarm-root/boot/dtbs/rockchip/rk3566-quartz64-b.dtb\nThen adjust your /mnt/alarm-root/boot/extlinux/extlinux.conf*\u0026rsquo;s fdt* line as follows:\nfdt /dtbs/rockchip/rk3566-quartz64-*b*.dtb Finishing Up Once done, unmount the partitions:\n# umount /mnt/alarm-root/boot # umount /mnt/alarm-root Booting And Finishing Setup Hook up your UART dongle to your Quartz64, open a serial terminal at 1.5mbauds. Install the SD card or eMMC module inside the Quartz64, and plug in the power.\nOnce you hit a login shell, log in as root with password root and run:\n# pacman-key --init # pacman-key --populate archlinuxarm You are now ready to use Arch Linux ARM! Either delete or rename (and move the homedir of) the alarm user, and you’re all set. Don’t forget to install things like sudo and setting up sudo groups and such.\n","permalink":"/documentation/Quartz64/Software/Installing_Arch_Linux_ARM/","tags":null,"title":"Installing Arch Linux ARM"},{"categories":null,"contents":" Warning This page is a work in progress, use at your own risk Commands to be run as a normal user are prefixed with $, commands to be run as root are prefixed with #. We assume your target device is /dev/sdX, adjust accordingly.\nObtaining and Building U-Boot And TF-A The first step is to compile the open firmware (TF-A) and the open bootloader (u-boot).\nClone u-boot git repository:\n$ git clone https://source.denx.de/u-boot/u-boot.git Clone TF-A git repository:\n$ git clone https://github.com/ARM-software/arm-trusted-firmware.git Build TF-A (you will need aarch64-linux-gnu-gcc and arm-none-eabi-gcc for this)\n$ cd arm-trusted-firmware $ make realclean $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 Next, export the path to your compiled BL31 in the shell you’ll build u-boot in. Adjust the path as necessary.\n$ export BL3/path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf Build U-Boot (you may need to install additional packages to successfully compile, such as bc, python-pyelftools, or swig):\n$ make mrproper $ make rockpro64-rk3399_defconfig $ make CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) Preparing The Block Device Here we assume your block device is /dev/sdX, adjust as needed.\nCreate a new partition table:\n# parted -s /dev/sdX mklabel gpt Create the partitions for loader and u-boot:\n# parted -s /dev/sdX mkpart loader 64s 8MiB # parted -s /dev/sdX mkpart uboot 8MiB 16MiB Create the partition for u-boot’s environment (optional, but you’ll have to adjust the following offsets if you don’t do it):\n# parted -s /dev/sdX mkpart env 16MiB 32MiB Create the \u0026ldquo;efi\u0026rdquo; boot partition and mark it as bootable:\n# parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB # parted -s /dev/sdX set 4 boot on Create the root partition:\n# parted -s /dev/sdX mkpart root ext4 544MiB 100% Creating The File Systems Now create the file systems for boot and root:\n# mkfs.vfat -n \u0026#34;efi\u0026#34; /dev/sdX4 # mkfs.ext4 -L \u0026#34;rootfs\u0026#34; /dev/sdX5 Flashing U-Boot Flash idbloader.img and uboot.img:\n# dd if=idbloader.img of=/dev/sdX1 # dd if=u-boot.itb of=/dev/sdX2 Fetching The Root File System Tarball Fetch the root filesystem tarball and the PGP signature\n$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} Fetch the gpg keys:\n$ curl \u0026#39;https://keyserver.ubuntu.com/pks/lookup?op=get\u0026amp;search=0x68b3537f39a313b3e574d06777193f152bdbe6a6\u0026#39; | gpg --import=- Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS)\nVerify the tarball’s authenticity\n$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig Important Do not skip verifying the authenticity. This is important. It also protects you from prematurely aborted transfers giving you a corrupt archive. Installing The Root File System # mount /dev/sdX5 /mnt/alarm-root # mkdir /mnt/alarm-root/boot # mount /dev/sdX4 /mnt/alarm-root/boot # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root Editing fstab Find your partition UUIDs for both partitions using lsblk:\n$ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID In /mnt/alarm-root/etc/fstab, put the lines\nPARTUUID=_root-uuid-here_ / ext4 defaults 0 1 PARTUUID=_boot-uuid-here_ /boot vfat defaults 0 2 with your UUIDs in place of the placeholder.\nWriting extlinux.conf Create a /mnt/alarm-root/boot/extlinux/extlinux.conf with these contents:\ndefault l0 menu title ROCKPro64 Boot Menu prompt 0 timeout 50 label l0 menu label Boot Arch Kernel linux /Image fdt /dtbs/rockchip/rk3399-rockpro64.dtb append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait Once done, unmount the partitions:\n# umount /mnt/alarm-root/boot # umount /mnt/alarm-root Finishing Setup SSH in as root with password root and run\n# pacman-key --init # pacman-key --populate archlinuxarm ","permalink":"/documentation/ROCKPro64/Software/Installing_Arch_Linux_ARM/","tags":null,"title":"Installing Arch Linux ARM"},{"categories":null,"contents":"It is possible to install Debian onto eMMC of the Quartz64 from the pgewipout quartz64_ci imaged to a Micro SDcard, or vice versa.\nThis might be useful if you don’t have an eMMC to USB adapter or if the board is inside a case which doesn’t allow eMMC removal.\nDownload artifacts merge-job:archive from https://gitlab.com/pgwipeout/quartz64_ci/-/pipelines\nUnpack zip file\nImage to a Micro SDcard present in your PC as /dev/sdX:\nsudo -i; xzcat images/rk3566-quartz64-a.dtb.img.xz \u0026gt; /dev/sdX sudo sync Boot quartz64-a from microSD card\nAt boot menu select 1 (Buildroot-recovery)\nparted -s /dev/mmcblk1 mklabel gpt parted -s /dev/mmcblk1 mkpart loader 64s 8MiB parted -s /dev/mmcblk1 mkpart uboot 8MiB 16MiB parted -s /dev/mmcblk1 mkpart env 16MiB 32MiB parted -s /dev/mmcblk1 mkpart efi fat32 32MiB 544MiB parted -s /dev/mmcblk1 set 4 boot on parted -s /dev/mmcblk1 mkpart root ext4 544MiB 100% dd if=/dev/mmcblk0p1 of=/dev/mmcblk1p1 dd if=/dev/mmcblk0p2 of=/dev/mmcblk1p2 dd if=/dev/mmcblk0p3 of=/dev/mmcblk1p3 mkdosfs -F 32 -n \u0026#34;efi\u0026#34; /dev/mmcblk1p4 mke2fs -L \u0026#34;rootfs\u0026#34; /dev/mmcblk1p5 sync reboot At boot menu select 2 (Debian-Installer)\nchoose manual partitioning\nset partition #5 of mmcbkl1 to be /, format to ext4 and complete the installation\nreboot (installer will do this anyway)\nmkdir /mnt/mmcblk0p5 mkdir /mnt/mmcblk1p4 mkdir /mnt/mmcblk1p5 mount /dev/mmcblk0p5 /mnt/mmcblk0p5 mount /dev/mmcblk1p4 /mnt/mmcblk1p4 mount /dev/mmcblk1p5 /mnt/mmcblk1p5 cp -a /mnt/mmcblk0p5/dtbs /mnt/mmcblk1p4/ cp /mnt/mmcblk0p5/vmlinuz /mnt/mmcblk1p4/ mkdir /mnt/mmcblk1p4/extlinux touch /mnt/mmcblk1p4/extlinux/extlinux.conf echo \u0026#39;label Debian on eMMC\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p4/extlinux/extlinux.conf echo \u0026#39;linux /vmlinuz\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p4/extlinux/extlinux.conf echo \u0026#39;fdt /dtbs/rockchip/rk3566-quartz64-a.dtb\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p4/extlinux/extlinux.conf echo \u0026#39;append earlycon=uart8250,mmio32,0xfe660000 console=ttyS2,1500000n8 root=/dev/mmcblk1p5 rootwait\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p4/extlinux/extlinux.conf cp /mnt/mmcblk0p5/kernel-modules.tar.gz /mnt/mmcblk1p5/root/ The following lines (upto adding the boot partition to fstab) are optional. Debian will boot just fine if the boot partition isn’t in fstab and you may prefer to manually mount it when you want to change the kernel:-\nblkid /dev/mmcblk1p4\nThe output will show the UUID of your boot partition:-\n/dev/mmcblk1p4: LABEL_FATBOOT=\u0026ldquo;efi\u0026rdquo; LABEL=\u0026ldquo;efi\u0026rdquo; UUID=\u0026ldquo;5985-9C7B\u0026rdquo; BLOCK_SIZE=\u0026ldquo;512\u0026rdquo; TYPE=\u0026ldquo;vfat\u0026rdquo; PARTLABEL=\u0026ldquo;efi\u0026rdquo; PARTUUID=\u0026ldquo;93226dfa-53af-4400-8aab-239ff7900dd0\u0026rdquo;\necho \u0026#39;UUID=UUID_from_above /boot vfat defaults 0 1\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p5/etc/fstab chroot /mnt/mmcblk1p5 dpkg -l |grep image To show which kernel images Debian has installed:-\nii linux-base 4.6 all Linux image base package\nii linux-image-4.19.0-18-arm64 4.19.208-1 arm64 Linux 4.19 for 64-bit ARMv8 machines (signed)\nii linux-image-arm64 4.19+105+deb10u13 arm64 Linux for 64-bit ARMv8 machines (meta-package)\nUninstall them:\ndpkg -P linux-image-4.19.0-18-arm64 linux-image-arm64 cd /root tar -xzvf kernel-modules.tar.gz mv lib/modules /lib/ exit halt Remove MicroSD card and boot into eMMC.\n","permalink":"/documentation/Quartz64/Software/Installing_Debian/","tags":null,"title":"Installing Debian"},{"categories":null,"contents":" Warning This guide is a Work In Progress; no warranty is implied. This installation method is not officially recommended (or discouraged) by the Void Linux project. This guide is for experienced Linux users. This will not be a complete guide, as it borrows heavily on Installing Arch Linux ARM, so read it first then come back here.\nOnly the steps that are different are listed here. Be careful, the numbering of the sections is not the same.\nInstalling the root filesystem Downloading and verifying the rootfs tarball You can go to the Void Linux download page, select the \u0026ldquo;arm\u0026rdquo; tab, and choose one of the aarch64 rootfs tarballs, either glibc or musl. How to check integrity of the downloaded file is explained on the same page.\nOr use the following instructions (on Debian):\n$ wget https://repo-default.voidlinux.org/live/current/void-aarch64-musl-ROOTFS-20221001.tar.xz $ wget https://repo-default.voidlinux.org/live/current/sha256sum.{txt,sig} $ wget https://github.com/void-linux/void-packages/raw/master/srcpkgs/void-release-keys/files/void-release-20221001.pub $ signify-openbsd -V -p void-release-20221001.pub -x sha256sum.sig -m sha256sum.txt Signature Verified $ sha256sum -c --ignore-missing sha256sum.txt void-aarch64-musl-ROOTFS-20221001.tar.xz: OK Extracting and configuring the root filesystem Extracting the root filesystem tar -xpf void-aarch64-musl-ROOTFS-20221001.tar.xz -C /mnt Kernel The Void Linux rootfs tarball does not contain a kernel, however the pinebookpro-kernel package can be installed from the Void Linux repositories. Alternatively, one can (cross) build a kernel themselves. Skip this section if you would rather install the package.\nWarning If you choose the manually built kernel route, you’ll have to keep it updated yourself, the same way: manually (cross-)building and installing. Manually cross-compiling a mainline kernel suitable for the Pinebook Pro We’ll use the postmarketOS kernel configuration and boot parameters, because they are working properly, and are sufficiently up-to-date. This is done from an x86_64 computer.\nThis has been tested with postmarketOS configuration for 6.0.2 and kernel 6.1.0-rc5+. No additional initramfs was needed to boot the Void Linux OS.\n$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ cd linux $ wget -O .config \u0026#39;https://gitlab.com/postmarketOS/pmaports/-/raw/master/device/community/linux-postmarketos-rockchip/config-postmarketos-rockchip.aarch64?inline=false\u0026#39; $ sed -i \\ -e \u0026#39;s|CONFIG_ROCKCHIP_CDN_DP=.*|CONFIG_ROCKCHIP_CDN_DP=n|\u0026#39; \\ -e \u0026#39;s|CONFIG_BATTERY_CW2015=.*|CONFIG_BATTERY_CW2015=y|\u0026#39; \\ -e \u0026#39;s|CONFIG_TYPEC_FUSB302=.*|CONFIG_TYPEC_FUSB302=y|\u0026#39; \\ -e \u0026#39;s|CONFIG_TYPEC_TCPM=.*|CONFIG_TYPEC_TCPM=y|\u0026#39; \\ .config $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 oldconfig $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(grep -c \u0026#39;^processor\u0026#39; /proc/cpuinfo) Manually installing the newly built kernel, modules \u0026amp; DTB files $ KVER=\u0026#34;$(make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 kernelrelease)\u0026#34; $ sudo make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 modules_install dtbs_install \\ INSTALL_MOD_STRIP=1 \\ INSTALL_MOD_PATH=/mnt \\ INSTALL_DTBS_PATH=/mnt/boot/dtbs $ sudo cp arch/arm64/boot/Image \u0026#34;/mnt/boot/Image-${KVER}\u0026#34; Configuring a login agent on the serial console cp -R /mnt/etc/sv/agetty-ttyS0 /mnt/etc/sv/agetty-ttyS2 ln -sf /etc/sv/agetty-ttyS2 /mnt/etc/runit/runsvdir/default Creating extlinux.conf Note If using the official PBP kernel package, it is also recommended to use the u-boot-menu package, which automatically regenerates the extlinux.conf file on kernel upgrades. In that case, you will not need to follow the below instructions. The following borrows from postmarketOS u-boot configuration for the kernel command-line parameters.\nWe force the serial console to 115200 bauds (from the default 1.5M bauds), so that it is the same as tow-boot’s.\n# mkdir -p /mnt/boot/extlinux # cat \u0026lt;\u0026lt;EOF \u0026gt; /mnt/boot/extlinux/extlinux.conf default l0 menu title Pinebook Pro Boot Menu prompt 0 timeout 50 label l0 menu label Boot Kernel on SD linux /Image-${KVER} fdt /dtbs/rockchip/rk3399-pinebook-pro.dtb append console=tty0 console=ttyS2,115200n8 coherent_pool=1M pcie_aspm.policy=performance video=HDMI-A-1:1920x1080@60 video=eDP-1:1920x1080@60 rw rootwait root=/dev/mmcblk1p3 EOF Finalizing Now you can umount the partition(s) and boot the Pinebook Pro with Void Linux. The default root password is \u0026ldquo;voidlinux\u0026rdquo;.\n","permalink":"/documentation/Pinebook_Pro/Software/Installing_Void_Linux_ARM/","tags":null,"title":"Installing Void Linux ARM"},{"categories":null,"contents":" Main chips RK3399 system-on-chip (1) LPDDR4 SDRAM (21) SPI NOR flash memory (29) eMMC flash memory module (26; Note: Some datasheets indicate a low supported number of mating cycles.) WiFi/BT module (27) Mainboard Switches and Buttons There are two switches on the main board: disabling the eMMC module (24), and enabling serial console UART (9) via headphone jack.\nThe Reset and Recovery buttons (28): the reset button performs an immediate reset of the laptop. The Recovery button is used to place the device in maskrom mode. This mode allows flashing eMMC using Rockchip tools (e.g. rkflashtools).\nKey Internal Parts Number Type Descriptor 1 Component RK3399 System-On-Chip 2 Socket PCIe x4 slot for optional NVMe adapter 3 Socket Speakers socket 4 Socket Touchpad socket 5 Component Left speaker 6 Connector Power bridge connector 7 Socket Keyboard Socket 8 Component Optional NVMe SSD adapter 9 Switch UART/Audio switch - enables serial console UART via headphone jack 10 Socket Power bridge socket 11 Socket Battery socket 12 Component Touchpad 13 Component Battery 14 Component Right speaker 15 Socket MicroSD card slot 16 Socket Headphone / serial console UART jack 17 Socket USB 2.0 Type A 18 Socket Daughterboard-to-mainboard ribbon cable socket 19 Cable Daughterboard-to-mainboard ribbon cable 20 Component microphone 21 Component LPDDR4 RAM 22 Socket Mainboard-to-daughterboard ribbon cable socket 23 Socket Microphone socket 24 Switch Switch to hardware disable eMMC 25 Antenna BT/WiFI antenna 26 Component eMMC flash memory module 27 Component BT/WiFi module chip 28 Buttons Reset and recovery buttons 29 Component SPI flash storage 30 Socket eDP LCD socket 31 Socket Power in barrel socket 32 Socket USB 3.0 Type A 33 Socket USB 3.0 Type C Smallboard detailed picture ","permalink":"/documentation/Pinebook_Pro/Features/Internal_layout/","tags":null,"title":"Internal layout"},{"categories":null,"contents":" State of the software The PineNote is based on the in 2021 released Rockchip RK3566 SoC. The upstreaming status of the SoC functionality can be found on the Quartz64 development documentation page of the Quartz64 single-board computer using the same SoC. In the PineNote development documentation page you’ll find the items specific for the PineNote.\nThe community edition batch of the PineNote is aimed solely at users with extensive Linux experience. The software while it has improved is still prone to software breaking issues, so users must be prepared to get their hands dirty. This batch is suitable for taking notes, reading ebooks and documents, and general tasks such as web browsing.\nThe current default Debian firmware is available for users to download here. All core features works well out of the box (taking notes, reading ebooks and documents) but there are still some issues that arise due to updates from Debian (Trixie) testing.\nHelp and support Still have any questions regarding software, shipping, or ordering after reading the documentation? Please don’t hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See the community page.\nPlease keep in mind that PINE64 is not like a regular company (see the PINE64 philosophy) and that support resources are limited - the best way to get support quickly is to ask in the community chat. Please only contact the PINE64 support directly if questions couldn’t be solved via the community chat or the documentation.\n","permalink":"/documentation/PineNote/Introduction/","tags":null,"title":"Introduction"},{"categories":null,"contents":"The PinePhone Pro is PINE64’s second smartphone and a successor to the original PinePhone. It does not, however, replace the original PinePhone. It should also not be considered a second generation PinePhone; it is a higher-end device, with much better specs, aimed at those who wish to daily-drive a open system stack. Achieving this goal will, however, take time as the software and overall smartphone software ecosystem needs to mature.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Editions and revisions Similarly to the original PinePhone, various PinePhone Pro editions are planned, the first of which is the Developer Edition (aimed at developers, as the name entails) followed by the Explorer Edition, which is aimed at early adopters.\nDeveloper Edition Explorer Edition Help and support Still have any questions regarding software, shipping, or ordering after reading the documentation? Please don’t hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See Main Page.\nPlease keep in mind that PINE64 is not like a regular company (see the PINE64 philosophy) and that support resources are limited - the best way to get support quickly is to ask in the community chat! Please only contact the PINE64 support directly if questions couldn’t be solved via the community chat or the documentation.\n","permalink":"/documentation/PinePhone_Pro/Introduction/","tags":null,"title":"Introduction"},{"categories":null,"contents":" Getting started\nHow to Contribute\nIntroduction (Single Page)\nWhere to Report Bugs\nWriting a blog post\nGetting started This guide is for the PINE64 devices. For device-specific information please see the corresponding device pages listed on the main page.\nRequirements You will need the following to get started with using your PINE A64(+), PINE A64-LTS, Pinebook or ROCK64 board:\nA Windows / Linux PC or Mac device with a MicroSD Card Reader Internet connection / pre-downloaded OS image files Power Supply: PINE A64(+): Power Supply (PSU) and a micro USB cable. Please make sure to use a PSU rated at +5V @2A and a micro USB cable that is at least 26 AWG thick. SOPine/PINE A64-LTS: Power Supply (PSU) with 3.5mm OD/1.5mm ID barrel DC Jack. Please make sure to use a PSU rated at +5V @2A. Pinebook and ROCK64: Power Supply (PSU) with 3.5mm OD/1.5mm ID barrel DC Jack. Please make sure to use a PSU rated at +5V @3A. MicroSD card (Recommend: 8GB or higher capacity, 10MB/s or faster speed) HDMI cable (unless you wish to run headless / without a screen) For, Android and Remix OS supports 720p and 1080p, while Linux supports a wider range of resolutions. Input device(s) such as: keyboard, mouse, remote, pointer, etc. Step-by-Step Instructions for Flashing MicroSD Cards Important Caution! Handle the Pine64 Single Board Computers\u0026rsquo; PCBs with care. Always hold bare boards by the edges and make sure to wear an anti-static wrist strap. Touching components on the front and back of the boards can result in an ESD discharge that may cause damage to the electronics. Avoid placing bare boards on materials such as carpets, plastics or other surfaces prone to electrostatic build-up Begin by imaging the OS of your choice\nThe process of flashing PINE64 OS images to micro SD on your Windows, Linux or OSX device is the same for all devices. You will require a quality microSD card (8GB or greater; class 10 or faster). There are many substandard and counterfeit cards in circulation and even reputable vendors may unknowingly sell counterfeit microSD cards. Cards that do not meet the criteria outlined above are known to cause a variety of issues including, but not limited to, complete boot failure. There are ways of testing microSD cards prior to installing the operating system to make sure they are appropriate for use with your board. The main utility for checking microSD cards is H2testw 1.4; yet another alternative is F3. Yet another overview of various options Test and Detect Fake Cards\nPlease refer to the relevant section below for instructions on how to image your microSD card:\nImaging microSD on Windows 7/8/8.1/10 Imaging microSD on macOS Imaging microSD on Linux Having successfully imaged your microSD card, insert it into the microSD slot.\nPlug in the HDMI Cable, Ethernet Cable and Peripherals to your PINE64 SBC\nUnless you are planning on running your board headless (without a monitor / as a server) you should plug in all necessary peripherals, including the HDMI and Ethernet cable, prior to powering ON the board. Do note, depending on which OS image you are using, some peripherals may or may not work.\nApply Power to Your Board\nOnce you have imaged your microSD and plugged everything in, you are ready to apply power to the PINE64 Single Board Computer. You’ll need a good quality 5 Volt, 2 Amp PSU. Using a good quality PSU is very important as failing to meet the required specifications may prevent the board from booting correctly. A marginally higher PSU Voltage is acceptable (for instance, 5.1 volts - due to the nature of the micro USB connection, a 5.1v supply can help protect slightly against voltage drops which can cause undesirable results). However, a significantly higher voltage of 7 Volts or more will damage the PINE64 Single Board Computer and may render it inoperative.\nFor PINE A64(+) board, if you are using a separate micro USB cable with your PSU, make sure that the cable has a low resistance rating. Cables with high resistance will cause improper function and the unit may not boot at all or only partially. The thicker the internal cabling, the better i.e. AWG (American Wire Gauge) 20 is better than AWG 28. In General, power-only microUSB cables come with red color USB header.\nHaving completed the steps outlined above the PINE64 Single Board Computer will begin to boot. The onboard power-on LEDs will come on and Ethernet port LEDs will start to blink if you have an Ethernet cable plugged in.\nImaging microSD on Windows 7/8/8.1/10 You will need the following utilities to get started with imaging the OS of your choice onto your microSD card:\nA compression utility (used to unarchive the OS image). We recommend you use 7zip. A disk image utility (used to flash the .img to your SD card). We recommend you use either the Etcher or Win32Imager utility. Optional for Allwinner A64 SoC based boards\nPhoenix Card image utility (used ONLY for phoenix card images). Downloading and extracting OS image(s)\nYou can find OS images for the respective devices in the device section on the main page. Images designated ‘DD’ need to be flashed using Etcher or Win32imager, whilst images labelled ‘Phoenix Card Image’ require the Phoenix Card utility.\nHaving downloaded the required OS image proceed to use 7zip to unarchive it by right-clicking the archive, and selecting ‘Extract All’. Upon completion, note the destination of where the .img file was extracted (‘Downloads’ folder by default). Once the process has completed, you can proceed to imaging the .img file.\nImaging the microSD card (DD)\nInsert your microSD card into your laptop/USB card reader. You may require a SD → microSD converter, as most laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, make sure to take note of the drive it has been assigned (the drive is assigned a letter, e.g. ‘F:’). You will need to remember the ‘letter’ it has been assigned when imaging the OS. Launch Win32diskImager.exe or etcher.exe. You will be presented with a field titled ‘path’ and a drop down menu labeled ‘device’. Click the ‘path’, navigate to and select the OS image you extracted from the archive earlier. Next, from the drop-down menu select the drive your microSD has been assigned. WARNING: Pay close attention to the selected drive (remember your letter) – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. Having chosen the desired OS image and the correct driver press ‘write’. Once the image has been written to your microSD card you will receive a pop-up notification. Be sure to close the application and to eject/remove your SD card safely from Windows. Imaging using Phoenix Card (applicable only to Allwinner A64 SoC based boards)\nOn Windows, you can also use Phoenix Card (for detailed instructions click here). The Phoenix Card utility works ONLY with images designated as ‘Phoenix Card’ in the downloads section. To use Phoenix Card follow these steps:\nInsert your microSD card into your laptop/USB card reader. You may require a SD → microSD converter, as most laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, make sure to take note of the drive it has been assigned (the drive is assigned a letter, e.g. ‘F:’). You will need to remember the ‘letter’ it has been assigned when imaging the OS. Launch phoenixcard.exe. You will be presented with a ‘disk’ drop-down menu and a field denoted as ‘.img File’. Click on ‘.img File’ and navigate to and select the OS image have downloaded and unarchived. Next, make sure to select the disk that your microSD card has been assigned. WARNING: Pay close attention to the selected drive (remember your letter) – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. Make sure to select ‘Startup!’ from the ‘Write mode’ window and click Burn. Once the image has been written to your microSD card you will receive a confirmation in the ‘option’ window. Be sure to close the application and to eject/remove your SD card safely from Windows. Imaging microSD on macOS You will need the following utilities to get started with imaging the OS of your choice onto your microSD card:\nA compression utility (used to unarchive the OS image). You may use Keka. A disk image utility (used to flash the .img to your SD card in GUI). You may use ApplePi Baker v2 or Etcher. Tip Phoenix Card utility and images are NOT available on macOS. Downloading and extracting OS image(s), insert the SD card\nYou can find OS images for the respective devices in the device section of the main page.\nHaving downloaded the required OS image, proceed to use the compression utility to unarchive it and get the .img file. Once the process has completed, you can proceed to write it to your SD card.\nInsert your microSD card into your Mac laptop/USB card reader. You may require a SD → microSD converter, as Apple’s laptops and desktops only feature a full-size SD card reader. Once the microSD card is plugged into your computer, it should appear in Finder / on your desktop.\nImaging the microSD card (GUI)\nLaunch the imaging utility. Upon startup, the application may ask for your password. When the application launches, you will be presented with a field titled ‘IMG file’ and a path of the mounted microSD card (it will look like this: ‘/dev/diskX 32.0Gb SD card’).\nTo choose the OS image file, click the ‘IMG file’ button, navigate to and select the .img file you extracted from the archive earlier. Then select the microSD card you want to write into.\nWarning Pay close attention to the selected device, make sure it is the right SD card – the imaging process will permanently erase and format the selected storage device. If you choose the wrong device, all the data in it will be lost. Having chosen the desired OS image and the correct device, press ‘Restore Backup’ or ‘Flash’. Once the image has been written to your microSD card, you will receive a pop-up notification. Close the application, then eject/remove your SD card from your Mac.\nImaging from Terminal\nImportant If you are not comfortable using the terminal, please use the GUI method outlined above instead. Open up your terminal and navigate to the directory where you unarchived your OS image.\nBefore you start writing to the card, you will have to identify your microSD card. Type: diskutil list and note the output. The disk number should match the size of your SD card, and will likely be using Fdisk_partition_scheme.\nHaving identified the disk number execute the following commands (substitute diskX for your disk and name of image for pine64-image-name.img):\ndiskutil unmountDisk /dev/diskX sudo dd if=pine64-image-name.img of=/dev/disk2 bs=1M Wait patiently for the process to complete, then eject/remove your SD card from your Mac.\nImaging microSD on Linux You will need the following utilities to get started with imaging the OS of your choice onto your microSD card:\nA compression Utility (used to unarchive the OS image). We recommend you use Ark. A disk image utility (used to flash the .img to your SD card in GUI). We recommend you use Etcher or the GUI Disks utility that ships with most popular distributions. Tip Phoenix Card utility and images are NOT available on Linux. Downloading and extracting OS image(s)\nYou can find OS images for the respective devices in the device section on the main page. On Linux you can only use images designated as ‘DD’.\nHaving downloaded the required OS image proceed to use 7zip to unarchive it by double clicking the archive, and selecting ‘Extract All’. Upon completion, note the destination where the .img file was extracted (‘Downloads’ folder by default). Once the process has completed, you can proceed to imaging the .img file.\nImaging the microSD card (GUI)\nInsert your microSD card into your Linux laptop/USB card reader. Once the microSD card is plugged into your computer it should appear in your File Manager / on your desktop. Launch Disks or the etcher utility (This tutorial outlines how to use Disks, if you wish to learn how to use Etcher please visit their website). Upon launching Disks, you will be presented with all volumes visible to your computer. As a rule of thumb, your microSD card should be found at the bottom of listed volumes. Verify this by checking the size and mounting of the microSD card. WARNING: Pay close attention to the selected drive – the imaging process will permanently erase and format the selected drive. If you choose the wrong drive all your data will be lost. Having selected your microSD card, click the cog menu in top right corner and choose the ‘Restore Disk Image’ option from the drop-down list. Navigate to and select the OS image you extracted from the archive earlier. Once you select it, you will be asked to enter your password and to confirm writing to the chosen volume (microSD card). You will be given a predicted time, writing-speed and completion percentage. Once the image has been written to your microSD card you will receive a pop-up notification. Be sure to close the application and to eject/remove your SD card safely from your computer. Imaging from Terminal\nImportant If you are not comfortable using the terminal, please use the GUI method outlined above instead. Insert your microSD card into your Linux laptop/USB card reader. Once the microSD card is plugged into your computer it should appear in Finder / on your desktop. Open up your terminal and navigate to the directory where you unarchived your OS image. e.g. cd Download Before you start writing to the card, you will have to identify your microSD card. Type: lsblk and pay attention to the listed disks. Disks will appear as /dev/mmcblk0 /dev/mmcblk1 etc. Important Hint: the drive you currently have booted from has the / at the end of the line. This is the wrong drive. Look at the drive that matches your microSD card’s size. Now you are ready to write the image to the microSD card using this command: (replace the pine.img file with your image and mmcblkX with the correct device for the microSD card)\nsudo umount /dev/mmcblkX sudo dd if=pine.img of=/dev/mmcblkX bs=1M status=progress conv=fsync Wait patiently for the process to complete.\nuse the command sync to ensure everything is written to the microSD card.\nThe card is ready to boot\n(sometimes this process fails and your microSD card can’t boot, one way of fixing this is just to repeat the same thing, you can also try a different microSD card)\nInstructions for Flashing Removable eMMC Modules Many Pine64 devices support removable eMMC modules as an alternative boot and storage solution to micro SD cards. These devices include SBCs such as the Pine A64-LTS, ROCK64, ROCKPro64, PINE H64, SOPINE Baseboard, SOPINE Clusterboard, and Quartz64, and devices such as the Pinebook and Pinebook Pro.\nPlease be aware that the Pine A64 (+) does not support an eMMC module, while the Pine A64-LTS does.\nAn eMMC module can be purchased for your device(s) from the PINE64 store. The Pinebook and Pinebook Pro both come with a removable eMMC module pre-installed.\nThe available modules come in four different capacities: 16Gb, 32Gb, 64Gb and 128Gb\nThere are a few ways to flash eMMC modules with the desired OS image. The following sections are a summary of the processes involved in flashing the OS image of your choice to an eMMC module once it has been removed.\nFlashing Using the USB-to-eMMC Adapter (Preferred Way) A USB-to-eMMC adapter is available from purchase from the PINE64 Store making it easy to mount the eMMC module as a volume in your Windows, Mac OS or Linux computer. The eMMC can hence be flashed directly from your computer with any image similarly to a micro SD card.\nThis installation method works for all devices that support eMMC modules regardless of the chipset and it is therefore the preferred way of flashing OS images to eMMC. All available OS images for your device can be installed on the eMMC module this way.\n*This process of flashing an OS image to eMMC is completely identical to imaging micro SD cards, so please read Step-by-Step Instructions to Flashing Micro SD Cards before you begin.\nFor this method you will need the following:\nA Windows, Linux or Mac OS computer A PINE64 eMMC module The PINE64 USB-to-eMMC adapter Flashing eMMC using the adapter\nInsert the the eMMC module into the USB adaptor and plug it into your Windows, Linux or Mac OS computer. It should mount as a regular USB drive and show up in your file manager. If you are using Linux or Mac OS you can either use the dd terminal command or a GUI utility such as Etcher to flash the chosen OS Image to eMMC. If you are using a Windows machine use Etcher or Win32 Disk Imager to flash the OS Image to the eMMC module. Once the image has been flashed using your preferred method safely dismount the USB adapter in your system and unplug it from your computer. Your eMMC is now ready to boot and can be inserted into the eMMC socket on your PINE64 device.\nInstructions for Flashing Integral eMMC As an alternative to a removable eMMC module, some devices come with an integral chip that cannot feasibly be removed. These devices include the PinePhone, PinePhone Pro, PineTab, and PineNote. In addition, the following techniques can also be used to flash a removable eMMC when it is not desirable to open the device, when a eMMC to USB adapter is not available, when a second device is not available, or for some other reason.\nFlashing to eMMC from a SD Boot Some of the available Linux images for Allwinner A64 devices recognise eMMC modules as mounted storage when the device is booted from a micro SD card. This is true for all recent releases of ayufan’s Linux images. In result it is possible to flash an OS image to eMMC using the DD command in terminal or the Disks GUI utility included with the Mate desktop.\nThere are two ways in which an OS image can be flashed from within a micro SD boot:\nVia a script called Pine64_install_to_eMMC.sh found in /usr/local/sbin. This script will install an Ubuntu Mate OS installation (identical to the on running on the SD) to the eMMC module. To execute the script navigate to its location in the terminal and type sudo ./Pine64_install_to_eMMC.sh. Follow the instructions. By manually downloading and flashing a OS image for your device using DD or the Disk GUI. This way of flashing an OS image to the eMMC is identical to that used on a Linux computer (e.g. for flashing an OS image to a SD card). For more information on how the process works please see the detailed guide on imaging OS images to SD card on Linux. For the latter of the two methods here is a summary of the process:\nFlash an OS image which recognizes eMMC as mounted storage to a micro SD card. For details on how to flash a micro SD card see section 3 Insert both the micro SD and eMMC module into your device and power it on. Once the PINE64 device boots from micro SD, you cannot flash the contents of the micro SD card to the eMMC while you are running from the micro SD so you will actually use this session to download an OS image to flash to the eMMC. Depending on the distribution this may be the same image you just flashed to the micro SD card and booted from. Once the OS image downloads check in terminal or in Disks utility the eMMC’s mounting location and unmount all but \u0026ldquo;/\u0026rdquo;. Example command to show disks and mounts: $ lsblk Use the DD command or Disks utility to flash the downloaded image to the eMMC module. Note your output device may be mmcblk1 or mmcblk2, use the command above to verify the correct one. Example DD command: $ xzcat imagename.img.xz | sudo dd of=/dev/mmcblk1 bs=1M status=progress conv=fsync Once the flashing process is completed power down your device and remove the micro SD card. You should now be able to power your device back up and it will boot the image flashed to the eMMC module. Flashing to eMMC using FEL (Allwinner A64 Devices Only) Under particular circumstances it may prove difficult to rely on a SD card to flash an OS image to an Allwinner A64 device. In such instances OS images can be directly flashed by means of entering into FEL mode. FEL is a low-level subroutine in the BootROM, and the process of enabling FEL differs from one device to another. To learn more about FEL please refer to the SUNXI Wiki section dedicated to the subject.\nThe process of flashing via FEL is more complex than utilising a micro SD and is therefore better suited for proficient and advanced users.\nFor the process of flashing an image to the eMMC on a device in FEL mode you will need:\nA computer running Mac OS or Linux An OTG USB A-to-A cable To enter FEL you will need to:\nOn the Pinebook, power down the Pinebook and remove the PSU, unscrew the bottom of the case and press down the FEL button on the PCB (REF). Plug in the OTG USB A-to-A cord to your computer and the OTG USB port on the Pinebook (on the right facing an open case). Reinsert the PSU cord and press the power button with the FEL button pressed down. Release the FEL button after 3 seconds. On the Pine A64(+) power down the board and remove the micro SD card and power cord. Plug in the OTG USB A-to-A cord to your computer and the OTG USB port on the Pine A64 (+) and SoPine (top port). Power on the device and immediately after insert a micro SD card with FEL code. You can check if your device entered FEL mode using lsusb command in terminal. It should be listed as a device on the USB Bus.\nThe next step is to mount your device so that your computer recognizes the eMMC as mass storage (UMS). A script called boot-tools streamlining this process is available thanks to ayufan on his github. Follow his instructions and in terminal perform the following steps:\ngit clone https://github.com/ayufan-pine64/boot-tools.git cd boot-tools make pinebook_ums or\nmake pine64_ums Once your device mounts as UMS it will appear in your file manager. In CLI you can check if the storage is listed using fdisk -l.\nThis process of flashing an OS image to eMMC with the device in FEL mode and mounted as UMS is literally identical to imaging micro SD cards, so please read Step-by-Step Instructions to Flashing Micro SD Cards and follow the procedure. You can use DD or Disks/ Disk Utility to flash the OS image directly to your device’s eMMC.\nOnce the flashing process is completed, power down your device, remove the A-to-A USB OTG cable and after reapply power to boot your device from eMMC.\nFlashing to eMMC using Rockchip Tools (Rock64 Only) Rockchip has a different boot hierarchy to Allwinner’s devices making it much more difficult to flash OS images using the micro SD-to-eMMC scheme used on A64. There are, however, flashing tools that make it possible to flash directly to eMMC on a Rock64 in loader and MarkROM modes.\nTo flash to the eMMC module using these tools you will need the following:\nA Windows, Mac OS or Linux computer An A-to-A USB cable The Rock64 board with the eMMC module inserted into the socket Using Windows 7/8.1/10:\nYou will need to download the DriverAssistant aka Rockchip driver as well as the AndroidTool_Release used for flashing OS images. Having completed the downloads extract both archives.The Rockchip driver needs to be installed prior to using the AndroidTool utility.\nHaving installed the driver and flashing utility, follow these steps:\nMake sure that eMMC is inserted into the slot on the Rock64 Place a jumper / short out the eMMC pins on the board (consult this PDF document for more details. Insert one end of the A-to-A cable into your Windows PC and the other into your Rock64 OTG USB port (top) Inset the power cord into the Rock64 Start AndroidTool; make sure that it reports \u0026lsquo;Found One Maskrom Device\u0026rsquo; (if it does not recognise your device, please repeat previous steps) Select either the latest Stock Android build or ayufan’s Android TV build with the suffic -update. Download and the extract the chosen image. In AndroidTool press the firmware tab and navigate to where you extracted the OS image and select it. Press the upgrade tab. You will be prompted when the flashing process is completed. Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. Using Linux or Mac OS:\nMake sure that eMMC is inserted into the slot on the Rock64 Download latest stable or pre-release (to be used at own risk) Android TV OS image from ayufan’s github. The image you wish to download is the one without a suffix; without -update or -raw in the OS image title. In terminal, download rkflashtool following instructions on ayufan’s github Extract the folder containing partitions of the OS image and place the script listed on ayufan’s github in the folder Hold down the recovery button on the board Insert one end of the A-to-A cable into your Mac OS or Linux PC and the other into your Rock64 OTG USB port (top) Inset the power cord into the Rock64 Check that your device is in loader mode by typing in the terminal sudo rkflashtool n. If rkflashtool doesn’t detect the Rock64 please repeat last 3 steps In terminal navigate to where you extracted the Android folder containing the OS partitions and the script and type rkinstall; this will install the community Android TV build to eMMC. Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. Flashing to eMMC Android \u0026lsquo;Update\u0026rsquo; OS Images on Linux (Rock64 Only) It is possible to flash Android \u0026lsquo;update\u0026rsquo; images to the Rock64 eMMC using a Linux PC. This process requires a tool called Linux Upgrade Tool and the full documentation of its functions can be found here. Make sure that you download v1.2 or newer, as older tools do not support the RK3328 used on the Rock64.\nTo flash the eMMC module using this method you will need the following:\nA Linux computer An A-to-A USB cable The Rock64 board with the eMMC module inserted into the socket Start by downloading an Android update image for the Rock64. Both PINE64 and Ayufan provide such images for the board - and they are clearly designated as such on both this WiKi’s download section and on ayufan’s github. For the purpose of this example, I’ll use the ayufan’s ATV community build:\nDownload latest stable or pre-release (to be used at own risk) Android TV OS image from ayufan’s github. The image you wish to download is the one with update suffix. You need to rename the downloaded image to update.img. Download the Linux Upgrade Tool to your Linux PC and unarchived it. Extract the archived update Android OS image somewhere where you will remember its path Hold down the recovery button on the board Insert one end of the A-to-A cable into your Mac OS or Linux PC and the other into your Rock64 OTG USB port (top) Inset the power cord into the Rock64 In terminal, navigate to where you extracted Rockchip Update Tool and issue the following command substituting the correct path for where the Android Update OS Image is located: sudo ./upgrade_tool uf /path/to/update.img\nWait as the utility installs Android to eMMC on your Rock64. Remove the USB A-to-A cable, power off your board and power it on again to boot into eMMC. Flashing u-boot to SPI Flash Some of PINE64 devices, such as the Rock64 and SOPine, are equipped with SPI Flash. This allows users to flash u-boot onto the SPI and boot from an external USB 2.0 or USB 3.0 SSD/HDD/thumb-drive, thereby forgoing use of eMMC or microSD card.\nTo find out more about which images can used in conjunction for SPI booting please see ayufan’s github.\nWriting u-boot to SPI Flash can be achieved in two ways:\nUsing a Stand-Alone Image to Write u-boot to SPI This may be the simplest method of flashing u-boot to SPI. Download a dedicated image labelled u-boot-flash-spi.img.xz from ayufan’s github and flash it to a microSD card, the same as you would with any OS image (to learn how to flash OS images to microSD please follow steps outlined in Section 3.\nHaving flashed the image follow these steps:\nInsert the SD into the ROCK64 Remove all other peripherals from the board Make sure that the eMMC module is disconnected from the board Apply power to the ROCK64 Wait (few seconds) until the the LEDs on the board will blink continually Power off the board. The board is now ready to boot from USB 2.0/3.0 storage.\nUsing a Script on Linux OS Images Most of recent (newer than 0.6.9) Linux OS images contain a script called rock64_write_spi_flash.sh, which is found in /usr/local/sbin directory. To run the script you will first need to flash a Linux OS image to a micro SD card (to learn how to flash OS images to micro SD please following steps outlined in Section 3). Before proceeding make sure that the eMMC module is disconnected from the board. Once you have booted into Linux on your PINE64 device all you have to do is run the aforementioned script using this command:\nsudo ./rock64_write_spi_flash.sh\nOnce the script finishes its operation, power off your board and remove the microSD card. The board is now ready to boot from USB 2.0/3.0 storage.\nErasing and Rewriting SPI There are two ways of removing u-boot from SPI. You can either download u-boot-flash-spi.img.xz from ayufan’s github or use a script found on Linux OS images titled:rock64_erase_spi_flash.sh. Follow the instructions in the previous sub-sections for the chosen method of removing u-boot from SPI; the instructions are are identical, as the process of erasing u-boot is the exact opposite of flashing it.\nYou can also erase SPI manually. To do so, you need to download mtd-utils. on Debian or Ubuntu follow these instructions:\nsudo apt-get install mtd-utils\nsudo flash_eraseall /dev/mtd0\nBooting an OS image from USB 2.0/3.0 Storage To boot an OS image from USB 2.0/3.0 Storage such as a SSD/HDD or a thumbdrive you first need to have u-boot written to your SPI flash. Please follow the instructions in the previous sub-sections to learn how to write u-boot to SPI on your PINE64 device.\nOnce you have u-boot on your SPI, the process of booting is very similar to booting from microSD or eMMC.\nDownload one of the supported OS images for your PINE64 device Flash the OS image to your USB 2.0/USB 3.0 storage device (to learn how to flash OS images please following steps outlined in Section 3 The instructions are identical for all types of storage, including USB 2.0/USB 3.0 HDDs and thumb-drives.) Insert the USB storage device with the flashed OS image into one of the USB ports on your PINE64 device Apply power If you have followed all the steps correctly, the board should boot from your USB 2.0/3.0 storage device.\nTroubleshooting Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. A number of things can prevent the PINE64 board from booting up properly. The most common culprits of a failed boot are: (to find out more click here)\nSubpar or counterfeit microSD card Subpar Power Supply High resistance (thin) or a very long microUSB cable Failed imaging of the microSD card or eMMC module Make sure to have the newest version of the OS image your are running. On Allwinner A64 devices running Linux you can update the kernel and U-Boot using scripts located in the following directory: /usr/local/sbin\nTo navigate to the directory type (in terminal): cd /usr/local/sbin You list all the available scripts by typing (in terminal): ls To run the script required update script run the following command: sudo ./update_script.sh (substitute the relevant update script for update_script) Troubleshooting Step by Step\nFollow these steps to determine the cause of your problem:\nCheck your PSU and microUSB cable ratings Download and image a base image of Linux Plug in power and Ethernet into your PINE64 device Watch Ethernet port LED activity Check your router for your device’s IP Attempt to ssh into your device’s from your computer If your PSU and microUSB meet the criteria, and you have correctly followed the instructions to image your card and power on the board, but you are not seeing any LED activity and cannot ssh into your device then either the imaging process failed (possibly due to a subpar microSD) OR the PSU / microUSB cable is/are faulty.\nIf your PSU and microUSB meet the criteria, and you have correctly imaged the OS to your card and power on the board and your can ssh into your PINE A64(+) but get no video feed, then it’s likely that the native resolution of your monitor/TV is not supported.\nIf neither of the above mentioned scenarios fits the problem you are facing, please consult this thread (thanks to Ghost for compiling the list): https://forum.pine64.org/showthread.php?tid=680\nHow to Contribute The following article contains a selection of common ways to contribute to the community projects.\nReporting issues Reporting issues is a great way to contribute (if done correctly). The software projects are using bug trackers to keep track of bugs and to link patches or changes with these bug reports.\nSee the article where to report bugs to find out where you can report bugs.\nContributing code By contributing code, for example as documented in the following project pages (alphabetical order):\nelementary: Get Involved and the ARM project on GitHub KDE: see Get Involved and Help:Contribute Plasma Mobile: https://plasma-mobile.org/get-source/ (see the \u0026ldquo;Contributing\u0026rdquo; section) Donating to community projects and developers Many community projects and developers are working on the software on their free time. Donating to community projects and developers is a great way to support these projects and developers developing the software for the devices. The following list is an exemplary selection to which projects and developers can be donated to (in alphabetical order):\nTip The following list is not a comprehensive list and solely a selection of different community projects and developers, which can be supported. Any FOSS development effort is valuable and should be rewarded, please support your favorite developer(s) or project(s) even if not mentioned on the list Your name or project not on the list? Community projects Armbian: https://www.armbian.com/donate/ elementary: https://elementary.io/get-involved KDE: https://kde.org/community/donations/ LibreELEC: https://libreelec.tv/sponsor/ Manjaro ARM: Open Collective, Liberapay, Patreon (see https://manjaro.org/donate/ for an overview) Mobian: Liberapay postmarketOS: https://postmarketos.org/donate/ UBports: https://ubports.com/donate and many more!\nDevelopers Danct12: Ko-fi, Liberapay, Patreon megi: https://xnux.eu/contribute.html#toc-donations and many more!\nHelp with the documentation All projects typically require help with the documentation. That can include the wikis of the projects, help pages, tutorials, manuals and technical or informative drawings.\nOther ways to contribute Other ways to contribute to the projects might include:\nTranslations and localization Designs and creative work Ideas Supplying hardware and many more!\nBy being a positive member of the community By being a positive member of the community you can help answering common questions and help people find the correct places for their inquiries.\nWhere to Report Bugs Reporting bugs is a great way to contribute and to help bringing order at managing and solving issues.\nOverview Issues should only be reported in the correct bug trackers, not in the community chats. The following list is a selection of common bug trackers.\nPinePhone and PinePhone Pro Issues with the PinePhone and the PinePhone Pro can be reported on the following bug trackers (selection).\nOperating Systems and Distributions Arch Linux ARM (DanctNIX): https://github.com/dreemurrs-embedded/Pine64-Arch/issues?q=is%3Aissue Fedora: https://github.com/nikhiljha/pp-fedora-sdsetup/issues?q=is%3Aissue Gentoo: On the bug tracker of the corresponding unofficial overlay GloDroid: https://github.com/GloDroid/glodroid_manifest/issues?q=is%3Aissue Kali Linux: https://github.com/Shubhamvis98/kali-pinephone/issues?q=is%3Aissue LuneOS: https://github.com/webOS-ports/meta-pine64-luneos/issues?q=is%3Aissue Maemo Leste: https://github.com/maemo-leste/bugtracker/issues?q=is%3Aissue Manjaro ARM: https://gitlab.manjaro.org/manjaro-arm/issues/pinephone Mobian: https://gitlab.com/mobian1/issues Multi-distro demo image: - Nemo Mobile: https://github.com/nemomobile-ux/main/issues?q=is%3Aissue NixOS: https://github.com/NixOS/mobile-nixos/issues?q=is%3Aissue OpenMandriva Lx: - openSUSE: https://gitlab.com/slem.os/slem.os/-/issues?sort=created_date\u0026state=all postmarketOS: PinePhone: https://gitlab.com/postmarketOS/pmaports/-/issues?sort=created_date\u0026state=opened\u0026label_name%5B%5D=device-pine64-pinephone PinePhone Pro: https://gitlab.com/postmarketOS/pmaports/-/issues?sort=created_date\u0026state=opened\u0026label_name%5B%5D=device-pine64-pinephonepro PureOS: unmaintained Sailfish OS: https://github.com/sailfish-on-dontbeevil SkiffOS: https://github.com/skiffos/SkiffOS/issues?q=is%3Aissue Slackware: - Swmo: https://todo.sr.ht/~mil/sxmo-tickets Ubuntu Touch: https://gitlab.com/ubports/community-ports/pinephone/-/issues?sort=created_date\u0026state=all User Interfaces Plasma Mobile: https://invent.kde.org/plasma/plasma-mobile/-/issues Plasma Mobile applications: https://invent.kde.org/groups/plasma-mobile/-/issues Phosh: https://gitlab.gnome.org/World/Phosh/phosh/-/issues?scope=all\u0026state=all Phosh projects: https://gitlab.gnome.org/World/Phosh Bootloaders and Firmwares U-Boot: TBD Tow-Boot: https://github.com/Tow-Boot/Tow-Boot/issues?q Levinboot: https://gitlab.com/DeltaGem/levinboot/-/issues?sort=created_date\u0026state=all Crust: https://github.com/crust-firmware/crust/issues?q=is%3Aissue Pinephone Modem SDK: https://github.com/Biktorgj/pinephone_modem_sdk/issues?q=is%3Aissue Hardware Issues The page Hardware issues can be used to track known problems with the hardware (and how to fix them). If you’re not exactly sure how to describe the issue, try the discussion tab for that page, or other community resources.\nAccessories TBD\nPineTime InfiniTime: https://github.com/InfiniTimeOrg/InfiniTime/issues?q=is%3Aissue PineTab Arch Linux ARM: https://github.com/dreemurrs-embedded/Pine64-Arch/issues?q=is%3Aissue+label%3A%22device%3A+pinetab%22 Manjaro ARM: https://gitlab.manjaro.org/manjaro-arm/issues Mobian: https://gitlab.com/mobian1/issues postmarketOS: https://gitlab.com/postmarketOS/pmaports/-/issues?sort=created_date\u0026state=opened\u0026label_name%5B%5D=device-pine64-pinetab Ubuntu Touch: https://gitlab.com/ubports/community-ports/pinephone/-/issues?sort=created_date\u0026state=all Writing a blog post This guide is for community members wanting to announce project updates on the Pine64 community blog.\nSetup You should first prepare a fork of the pine64 website repository on GitHub, then clone it.\ngit clone https://github.com/USERNAME/website.git\nOnce the repository is cloned, you can open up the template folder at /content/blog/template and copy template_update.txt to /content/blog as a .md file.\nImportant Heads up, try to keep the naming of blog post files consistent. Put the month and year and a brief description of the contents. For example: august_2025_pt2_factory_image.md and december_2020_pinephone_release.md. Blog post details Once the template is copied, you can start editing the blog post details. Below is an example of a blog posts basic layout with some explanations of each option does (with explanation after \u0026ldquo;//\u0026rdquo;):\n1title: \u0026#34;PROJECT update: TAGLINE\u0026#34; // The title for the blog post. 2date: \u0026#34;yyyy-mm-dd\u0026#34; // Date of publishing. 3authors: [\u0026#34;Name of author\u0026#34;] // Author(s) of the blog post. 4categories: 5 - \u0026#34;community\u0026#34; 6 - \u0026#34;news\u0026#34; 7 - \u0026#34;pine64-community\u0026#34; 8tags: 9 - \u0026#34;tag_1\u0026#34; // E. g. \u0026#34;pinetab2\u0026#34;, \u0026#34;pinenote\u0026#34; 10 - \u0026#34;tag_2\u0026#34; 11images: // Cover art (preview and embedded) 12 - \u0026#34;/blog/images/pine64_banners/pine64_blue.png\u0026#34; 13summary: \u0026#34;Summary about the contents\u0026#34; 14 // Blog post summary, used in RSS and blog post list 15 16--- 17 18![Blog post banner artwork](/blog/images/pine64_banners/pine64_blue.png) 19 // Cover art found in the blog post itself. 20 21{{\u0026lt; toc \u0026gt;}} 22 // Creates the table of contents 23 24## HEADING TITLE 25 // First headline, put what your blog post is about here. The title should be formatted like \u0026ldquo;Project Update: New PineTab2 Factory Image\u0026rdquo; or \u0026ldquo;Project Update: PinePhone Pro FreeBSD port\u0026rdquo; The date entry follows the yyyy-mm-dd format. Make sure to test that the blog post appears in the hugo preview, depending on your timezone you may have to set it a day back. Categories are already correct in the template, so leave these alone. Tags are used to recommend similar blog posts with the same tags. For example: pinetab2, pinetab-v and pinenote. Important A useful tip, if you find yourself stuck with what what to put in the details at the top of the file, there is a completed example in the templates folder. Cover image details There are a number of different cover images to choose from that are included in the /content/blog/images/pine64_banners folder. The default image is called pine64_blue.png and has green, yellow and red color variations in pine64_banners/pine64_colors.\nBlog post list cover image The first option cover: image: is used for the cover image found on the blog post list. The image path for this option starts with the pine64_banners folder.\npine64_banners/festival_lights.png pine64_banners/pine64_colors/pine64_yellow.png Embed cover image The second option images: is used for the embed cover image. This image will appear when you post a link to the post on platforms like Mastodon and Matrix. The image path for this option starts with the /blog folder.\n/blog/images/pine64_banners/festival_lights.png /blog/images/pine64_banners/pine64_colors/pine64_yellow.png Blog post cover image The cover image found in the blog post itself can be set just after the option section ends. The image path for this option starts with the /blog folder.\n![Blog post banner artwork](/blog/images/pine64_banners/festival_lights.png) ![Blog post banner artwork](/blog/images/pine64_banners/pine64_colors/pine64_yellow.png) Write After the setup is done you are ready to start writing. Blog posts are written in Markdown so it is expected that you take a look at the Markdown syntax guide if you haven\u0026rsquo;t already. If you are unsure on how to lay out your blog post, take a look at the completed template for inspiration.\nInstall hugo You can preview what the final post will look like by installing the hugo site generator. On Linux it\u0026rsquo;s straight forward, use your package manager to install hugo.\nFedora: sudo dnf install hugo Debian/Ubuntu: sudo apt install hugo Arch Linux: sudo pacman -S hugo On Windows you must download the hugo binary and add it to your environment variables, you can find prebuilt binaries here. For any other operating systems and installation information you can find the documentation here.\nTest your blog post Start the hugo site generator by running hugo server in the root of the website repository, then check for anything that may look off in your blog post.\nMerge that thing! Once you\u0026rsquo;re happy with what you\u0026rsquo;ve written, you can submit a pull request on the website repository and we will review and merge it.\nAvailable cover image The source files for the following cover images have been placed in the /content/blog/images/pine64_banners/source_files folder. Make sure to not overwrite the originals.\npine64_blue.png (default) festival_lights.png the_sign.png forest.png fountain.png Bring your own cover image If you\u0026rsquo;d like to bring your own cover image for your blog post, you can drop it in the /content/blog/images/pine64_banners/community folder. Make sure to edit the path for the cover image at the top of the blog post document to reflect this.\nTry to keep cover image at a 16:9 aspect ratio, 1920x1080 is a good resolution to aim for. The font size used for the tagline in GIMP is 150px. ","permalink":"/documentation/Introduction/_full/","tags":null,"title":"Introduction (Single Page)"},{"categories":null,"contents":" Default JTAG pins GPIO Pin JTAG Pin GPIO17 TDI GPIO11 TDO GPIO12 TMS GPIO14 TCK BL602 multiplexes four GPIO pins to provide the familiar JTAG lines. See the accompanying table for the default pin mappings.\nThese are the default JTAG pins in use after a cold boot. However, many pieces of software, including the demo that\u0026rsquo;s installed by default on new PineCones, remap these pins to other functions. You cannot use the default wiring for JTAG while such software is running. This issue is especially prevalent on the PineCone because three of the default JTAG pins are connected to the onboard RGB LED. Nothing about the LED itself interferes with JTAG, but any program that uses the LED will necessarily remap some of the default JTAG pins to be GPIO.\nThe MaskROM download mode that the BL602 enters when you tie GPIO8 high does not remap the default JTAG pins, and so you can and should use that mode while checking basic functionality of your JTAG adapter.\nNote that, just as software can remap the default JTAG pins to be something else, it can also remap other pins to be JTAG. Control over this is quite granular, with 5-6 candidate pins for each individual JTAG signal that can be mapped independently of one another. LEE Lup Yuen has written some sample code showing how to remap the JTAG pins so that your software can use the LED without giving up support for debugging.\nUSB JTAG Adapter The USB JTAG Adapter is an adapter with openOCD for Pinecone and Pinenut development.\nFeatures Using FTDI FT232H chipset Aluminum housing Dimension: 56.8 x 20.2 x 8.6 mm Include 20cm length 5 wires female-to-female DuPont cable Information and schematics PINE64 USB JTAG Adapter Schematic-20201215.pdf (pine64_ft232hl_board-2020-12-14) PINE64 USB JTAG Adapter schematic 20210109 1.0a ","permalink":"/documentation/PineCone/JTAG/","tags":null,"title":"JTAG"},{"categories":null,"contents":" Picture of the PinePhone (Pro) Keyboard\nThe PinePhone (Pro) Keyboard Case is a case compatible with the PinePhone and PinePhone Pro, adding a keyboard functionality to the phone. It features a clam-shell design and uses the pogo pins located on the smartphone’s midsection and attaches by replacing the default back cover. This add-on effectively turns the PinePhone (Pro) into a PDA with an in-built LTE modem.\nGetting started ① Contact pads\n② Battery switch\n③ USB-C connector\nThe keyboard case works with both the PinePhone and PinePhone Pro and features a clam-shell design. It uses pogo pins located on the phone’s midsection and attaches by replacing the default back cover. When folded, the phone’s screen and the keyboard rest securely against each other. The hinge features a 180° design, which not only allows for two-hand typing on a surface but also for comfortable thumb-typing when fully extended. The etched keycaps can be easily relocated for alternate layouts such as AZERTY or QWERTZ. The keyboard case runs an open firmware, which means that anyone with the know-how can alter existing functions or add new ones. The bottom (keyboard) and top (phone) sections of the assembly are well-balanced thanks to the large, 6000mAh, internal battery capable of charging the PinePhone (Pro) during operation. The internal battery effectively triples the phone’s battery life. The internal keyboard battery can be manually toggled on/off and the keyboard’s battery charge level can be read in the supported operating systems; the keyboard remains functional with the battery fully depleted.\nYou do not lose access to the PinePhone (Pro)’s USB-C port, speaker, microphone, or any external features, such as volume and lock buttons, with the keyboard attached. There is also a cut-out for the camera, torch, and headphone jack. The USB-C port on the keyboard is capable of powering both the keyboard and PinePhone (Pro) simultaneously. This means that you can plug in a USB-C charger into the keyboard to charge the keyboard’s internal battery, while the PinePhone (Pro) is charging via the internal connection between phone and keyboard.\nWarning Do not plug in a charger into the keyboard and the phone at the same time. Using the USB-C port of the PinePhone (Pro) while a charger to is connected to the USB-C port of the keyboard is also discouraged for the same reason. Technical details regarding the issue can be found in the blog post of the developer megi here, in this blog post and the safety section. Please keep in mind that the keyboard case transforms the PinePhone (Pro) into a PDA, which means that taking calls will likely prove awkward without a wired or wireless headset connected (try speakerphone button if available).\nMounting the keyboard Power off your PinePhone and remove the back case. To remove the back case of the PinePhone use your fingernail or another soft object to pry up the back case. A notch to easily remove the cover is located at the bottom left of the PinePhone with the backcover facing the user.\nOpen and place the keyboard flat on a hard surface with the hinge fully extended. Proceed to insert the PinePhone into the keyboard at an angle of approx. 15 degrees. Make sure that the PinePhone’s pogo pins and the corresponding pads ① on the keyboard are aligned. The leading edge with volume and power buttons should make contact first. Firmly press the PinePhone into place. Multiple clicks should be heard as the two snap into place. Pay special attention to the plastic pin below the camera hole. Firmly push from the rear, below the camera hole, to click it into position. Failing to do so may cause an insufficient pin contact and prevent the case from charging the phone.\nThe PinePhone can be removed from the keyboard easily using a notch similar to the one found on the back case. The notch is located at the bottom of the leading edge with the power and volume buttons.\nOperation The keyboard will function automatically once a PinePhone running a compatible operating system is mounted. For alterations to physical layout and firmware see the relevant sections respectively.\nThe keyboard features an in-built 6000mAh battery. The battery can be turned ON/OFF using the button on the right leading edge of the keyboard ②. A short button press activates the internal battery while a long (15 seconds) press or double press deactivates it. Compatible operating systems display both the PinePhone’s and keyboard’s battery status together.\nYou should charge the PinePhone and the keyboard only using the USB-C ③ port on the keyboard. The keyboard’s USB-C port cannot be used for peripherals. The PinePhone’s USB-C port remains operational when mounted in the keyboard and can be used for data and peripherals.\nTroubleshooting There are multiple possible hardware issues users could face. It is recommend to check the following most common hardware issues and their solutions and workarounds.\nPogo pins not making proper contact Under certain scenarios the keyboard’s contacts are not making proper contact with the pogo pins of the phone. To address the issue:\nPower down the phone! Apply slight pressure in the upper mid of the PinePhone’s backside until the plastic holder pin towards the upper middle of the keyboard cover, until an audible click can be heard. Make sure the contacts and pogo pins are clean and the pogo pins can be slightly pressed individually. If the above does not work, a shim under the keyboard’s contacts might be required, as explained FAQ troubleshooting section. See also this photo of where to place the shim, or this video. Top row is less responsive The keys of the top row may be less responsive. The issue can be worked around by adding inserts to the underside of the top row key caps to decrease the travel distance. More details regarding the workaround can be found in the corresponding section of the FAQ page of the developer megi: https://xnux.eu/pinephone-keyboard/faq.html#ts\nSoftware issues For any software issue please see the Software support section and the FAQ section.\nSafety Do not plug in a charger into the keyboard and the phone at the same time. Doing so may result in damage or loss of the keyboard charging functionality. Using the USB-C port of the PinePhone (Pro) while a charger to is connected to the USB-C port of the keyboard is also discouraged for the same reason. Technical details regarding the issue can be found in the blog post of the developer megi here and this blog post.\nPlease note: Only use mild isopropyl alcohol when wiping down the clamshell of the device. Stronger solutions may partially strip the coatings. Do not lube the keyboard with GPL 205G0 switch grease, it can cause problems with the key responsiveness and tactility.\nSoftware support Kernel-space driver Kernel driver implementation from Samuel Holland: CONFIG_IP5XXX_POWER (module ip5xxx_power) and CONFIG_KEYBOARD_PINEPHONE (module pinephone_keyboard) https://github.com/smaeul/linux/commits/wip/pp-keyboard\nNote: If you’ve upgraded to \u0026gt;=5.18, don’t forget to upgrade the dtb as kb151 now appears to be a stub.\nUser-space driver The user-space driver is available here. Use git to clone the repository. You’re going to need sdcc 4.1+ installed to build it, so use your package manager to install that first. Next you’ll cd into the directory you cloned pinephone-keyboard and use the command \u0026ldquo;make\u0026rdquo; to build. After the build is completed, cd into the build directory and you’ll notice several new files starting with ppkb-. To use your keyboard case, you’ll want to run the following command: sudo ./ppkb-i2c-inputd. Open something you can type into like a new terminal window or text editor and you should now be able to use the keyboard case.\nNotes Virtual keyboards such as squeekboard are opening whenever a text field is selected.\nTo disable this behavior under Linux running Phosh you can change the corresponding settings under Settings \u0026gt; Accessibility \u0026gt; Screen Keyboard (see here). The virtual keyboard can also be disabled temporarily for one session using:\nTo temporarily disable the virtual keyboard: gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled false To temporarily enable the virtual keyboard: gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled true The virtual keyboard needs to be activated before removing the keyboard case again.\nUnder Plasma Mobile the keyboard can be disabled via a widget, see here.\nIn Sxmo disabling the keyboard is not required, as the keyboard will only shown when the corresponding hotkey button is pressed.\nKeyboard layout The keyboard features a default layout (pictured below) created and agreed upon by the community. The keyboard layout can be altered using software as well as by physically repositioning keycaps. All keycaps, with the exception of space and return keys, can be easily and safely relocated for alternative layouts corresponding to software settings.\nThe keyboard layout how the keys were originally intended\nKeyboard firmware PinePhone’s keyboard firmware was developed independently by Ondřej Jirman as a free-of-charge contribution to PINE64. The firmware source code is freely and publicly available and you can modify it, and the supporting utilities, using common FOSS tools.\nFirmware and supporting utilities The design of the firmware allows the keys, modifier keys, and their combinations to be handled in virtually unlimited ways, without a need to flash a customized version of the firmware. Mapping of keys is defined at runtime, using the supporting utilities, and is not hardcoded in the firmware. Different keyboard layouts can be loaded dynamically to support various use cases.\nThe repository that contains the source code of the firmware, supporting utilities and associated documentation is located at https://xnux.eu/pinephone-keyboard/.\nYou are welcome to contribute patches and improvements to the firmware and the supporting utilities. A summary of firmware development history is available at https://xnux.eu/log/ alongside other development updates from the firmware author.\nMuch time and effort went into the development of this firmware. If you wish to send a token of appreciation or support the development efforts in any way, please consider making a donation to the author via one of the methods listed at the bottom of this web page: https://xnux.eu/contribute.html.\nFirmware License Copyright (C) 2021 Ondřej Jirman \u0026lt;megi@xff.cz\u0026gt; This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, with either version 3 of the License or (at your discretion) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See GNU General Public License for more details. GNU General Public License https://www.gnu.org/licenses/ Hardware Key hardware specifications:\nDimensions (closed): 161 x 95 x 25mm Weights (without / with PinePhone mounted): ~ 191 / ~391 grams Number of keys: 54 Number of rows: 5 Keyboard IC: Keyboard IC: EM85F684A 8-bit microcontroller with 256 bytes RAM, 2048/ bytes XRAM; 16kB for user’s own firmware Battery capacity: 6000mAh (22.2Wh 3.7V) Charger input: 5V, 3A (15W) Charging and battery IC chip: IP5209 power management IC with charge indicate controller and boost converter Frequently asked questions What is the keyboard driver situation?\nSee https://xnux.eu/pinephone-keyboard/faq.html#drivers\nAre keyboard drivers included in my distribution?\nSee https://xnux.eu/pinephone-keyboard/faq.html#distros\nWhat’s the status of the existing software for the keyboard?\nSee https://xnux.eu/pinephone-keyboard/faq.html#sw-status\nMy keyboard doesn’t work (well)!\nSee https://xnux.eu/pinephone-keyboard/faq.html#faq-ts\nHow does charging work?\nSee https://xnux.eu/pinephone-keyboard/faq.html#charging\nWhat charger is best for the keyboard?\nSee https://xnux.eu/pinephone-keyboard/faq.html#chargers\nHow safe is the charger circuit in the keyboard?\nSee https://xnux.eu/pinephone-keyboard/faq.html#safety\nKeyboard doesn’t react to any key presses\nSee https://xnux.eu/pinephone-keyboard/faq.html#ts\nKeyboard works but top row of keys is less responsive\nSee https://xnux.eu/pinephone-keyboard/faq.html#ts\nPhone is not charging from the keyboard\nSee https://xnux.eu/pinephone-keyboard/faq.html#ts\nPhone is charging slowly from the keyboard battery\nSee https://xnux.eu/pinephone-keyboard/faq.html#ts and https://forum.pine64.org/showthread.php?tid=16979\u0026pid=111414#pid111414#ts\nCan you open the keyboard and add extra functionality?\nIt is possible to do so, however the production units can be extremely difficult to open. Do not attempt to open the keyboard if you do not want to risk cosmetic damage (scaring and scratching of the plastic).\nHow can I rotate the screen display in tty ?\nUnder Linux this can be done using the command echo 1 | sudo tee /sys/class/graphics/fbcon/rotate\nTop row stopped displaying symbols (kernel \u0026gt; 5.17)\nFor Phosh (at the example of Mobian) see: https://wiki.mobian-project.org/doku.php?id=ppaccessories For TTY and SWMO see: https://codeberg.org/HazardChem/PinePhone_Keyboard For Plasma Mobile, one of either /etc/xdg/kxkbrc or ~/.config/kxkbrc is necessary, with contents as described in https://gitlab.com/postmarketOS/pmaports/-/merge_requests/3438 Documents PinePhone Keyboard 4 language user manual ver 2.0 in PDF format PinePhone Keyboard 4 language user manual ver 2.0 in ODT format Schematics, Datasheet and certifications Schematic:\nPinePhone Keyboard Schematic ver 1.0 20211009 Datasheet:\nPEM85F684A USB Microcontroller Datasheet IP5209 Power Bank SOC Datasheet TXS0104E 4-Bit Bidirectional Voltage-Level Translator Datasheet Certifications:\nPinePhone Keyboard FCC Certificate PinePhone Keyboard CE RED Certificate External links Pre-order announcement FAQ of the developer megous: https://xnux.eu/pinephone-keyboard/faq.html ","permalink":"/documentation/Phone_Accessories/Keyboard/","tags":null,"title":"Keyboard"},{"categories":null,"contents":"Overview: The PineTab detachable keyboard features a full function row, FN key functionality, meta key (where the Windows key would be) and all of the keys you need for daily use.\nFN keys: Pause/play (F2), Stop (F3), Previous(F4), Next(F5), Music (F6), Mail (F7), Home (F8), Mute (F9), Vol- (F10), Vol+ (F11), Disable touchpad (F12), NumLock (Insert), Scroll Lock (Delete), PgUp (Up Arrow), PgDn (Down Arrow), Home (Left Arrow), End (Right Arrow), Digital Numpad (7,8,9,0,U,I,O,P,J,K,L,;,M,.,/)\n","permalink":"/documentation/PineTab/Keyboard/","tags":null,"title":"Keyboard"},{"categories":null,"contents":" Wi-Fi and Bluetooth The BES2600 Wi-Fi driver needs major cleanup and bugfixing (at the moment it often causes system crashes). This is a priority, but for now, you can USB tether a phone or use a supported WI-FI dongle. There are at least two code releases available, with two respective/non-interchangeable firmware versions. Kernel 6.9.2-danctnix1-1-pinetab2 has a somewhat working WiFi driver. The BES2600 Bluetooth driver needs to be implemented. Hardware bugs - the power and reset circuitry is not properly implemented in the circuitry, so hard reset of the chip (in the theoretical case it freezes) is impossible without power cycling the whole board. Camera The camera drivers needs to be ported (gc02m2, ov5648), Rockchip CSI/ISP driver needs to be extended to handle 2 lanes. Suspend Suspend does not currently work reliably due to a driver issue. It is therefore disabled in the factory image. Caveat Emptor if you chose to unmask the feature prior to it being fixed. ","permalink":"/documentation/PineTab2/Development/Known_issues/","tags":null,"title":"Known issues"},{"categories":null,"contents":" The Clusterboard with labels\nLabel Description 1 Barrel-type DC jack (6.3 mm outer diameter, 3.0 mm inner diameter) for a +5 V, 15 A power supply 2 Gigabit Ethernet port 3 Reset button, for all seven modules 4 Holder for two non-rechargeable 1.5 V AA-size batteries, providing backup for the real-time clock (RTC) on all modules 5 Connector for an eMMC module, for the first SOPINE or SOEDGE module 6 Slot for a SOPINE or SOEDGE module 7 USB 2.0 Type-A socket 8 MicroUSB Type-B USB 2.0 socket 9 Activity LED 10 20-pin expansion connector 11 Three-pin connector for a lithium battery 12 RTL8211E Gigabit Ethernet PHY, with two status LEDs 13 Gigabit Ethernet Switch (RTL8370N) 14 24-pin ATX Power Connector 15 Two-pin connector for a switch/button that turns on connected ATX power supply 16 5 V power output for hard disk drives (optional) 17 Places for soldering two resistors (optional, for use with an ATX power supply that requires dummy load on 3.3 V and 12 V rails) For the part 4, please see the important note in the specifications page. For the part 11, please see the notes in the hardware revisions page. Parts 6 to 12 exist separately for each of all seven SOPINE or SOEDGE modules.\n20-pin Expansion Connector The 20-pin expansion connector is the part 10 described in the section above, available for each SOPINE or SOEDGE module. There is an unofficial description of the pinout in this forum thread. The unofficial pinout is also visible directly in this picture.\nSOPINE Module Front view of the SOPINE module with labels\nRear view of the SOPINE module with labels\nLabel Description 1 A64 SoC 2 2 GB of DDR3 RAM 3 AXP803 PMIC 4 Edge connector, the same as on SO-DIMM modules 5 Power LED 6 microSD card slot 7 SPI flash memory ","permalink":"/documentation/Clusterboard/Layout/","tags":null,"title":"Layout"},{"categories":null,"contents":" Main Chips RK3399 system-on-chip (1) LPDDR4 SDRAM 1 (18) LPDDR4 SDRAM 2 (3) SPI NOR flash memory (17) RK808 power management (near 19) RTL8211 ethernet transceiver (near 25) ES8316 Sound Codec (on rear of board) The heatsink mounting holes around the RK3399 are 59 mm apart Switches The Power button (11, SW3): is the same as on your mobile phone - press and release after about 1 second to power on. Press and hold for about 3 seconds to power off.\nThe Reset button (10, SW901): performs a reset.\nThe Recover button (28, SW900): used to enter maskrom mode.\nConnectors, Sockets and Headers Diagram Schematic designator Silkscreen label Number of pins Description 2 U39 PI-2-bus 40 Pi-2 bus 4 J8 +FAN- 2 PWM controlled fan header 5 J10 SPDIF 3 SPDIF header 6 U6 +RTC- 2 RTC battery backup header 7 U31 Wifi-BT 16 SDIO WIFI/BT module-MIMO 2 8 USB3 9 USB-3 and USB Type C 9 USB1 2×4 Dual USB-2 12 IR1 IR 3 infrared receiver socket 13 J16 Headphone+mic 4 Headphone + mic 3.5mm jack - CON16 GND PWR RST GND 4 Power \u0026amp; reset, unpopulated header near Headphone jack 14 U29 EMMC 34 eMMC connector (Note: Some datasheets indicate a low supported number of mating cycles.) 14* J13 13 TF-card, a.k.a. microSD (* under 14 on the bottom side) 15 U30 14 SDIO WIFI/BT module-MIMO 1 16 SW4 2 Jumper to Disable eMMC 19 J15 PCI 64 PCI-express X4 socket 20 J21 DSI 30 DSI 21 J22 EDP 30 LCD EDP 22 CON1 TP 6 touch panel connector 23 CON15 4 DC out for SATA disk cable (direct connect from DC-IN) 24 J11 DC-IN 2 Power input, positive tip; 12V/3A (minimum) recommended 25 U32 8 8P8C (often referred to as \u0026lsquo;RJ45\u0026rsquo;) 26 J14 19 HDMI 27 J17 MIPI CAM 32 MIPI-1 29 J19 MIPI CAM 32 MIPI-2 30 J18 CIF 26 CIF LEDs A green LED next to the 12V input barrel connector will light as long as there is 12V applied to the connector. (Even if the RockPro64 is powered off.)\nA white LED behind the reset button will light as long as the RockPro64 is running (it comes on a few seconds after power on, when control is passed to the operating system.)\nA red LED behind the reset button is DIY - it is lit for example if the board is in OTG mode with an Ayufan image, or if an Android image is in standby mode.\nYellow and green LEDs on the LAN socket behave in a standard way.\nJumpers They are used for boot device selection, as described in the following section.\nDisable eMMC There is an unlabelled (on the PCB silk-screen) 2-pin jumper (16) between the eMMC socket (14) and the SPI chip (17). It is designated as SW4 on the schematic diagram under \u0026ldquo;Board Information, Schematics and Certifications\u0026rdquo;. The default condition is OPEN (no jumper). It is useful for controlling the boot as follows:\nDefault boot device (with no SPI software) is eMMC, then SDcard. If both the eMMC and the SDcard contain bootable images then the eMMC can be disabled by installing the jumper. This completely removes the eMMC from the resulting OS. If you wish the eMMC to be visible in the booted OS the jumper should be removed 2 seconds after applying power (and before the white LED comes on).\nThe possible combinations are summarised in the table below.\n1 = present 0 = not present µSD eMMC SW4 boot from 0 0 0 unsupported 0 0 1 unsupported 0 1 0 eMMC 0 1 1 unsupported 1 0 0 SDCard 1 0 1 SDCard 1 1 0 eMMC 1 1 1 SDCard Disable SPI (while booting) There is a second possibility to jumper your ROCKPro64: If you mess-up your SPI and are unable to boot, jumpering pins 23 (CLK) and 25 pin (GND) on the PI-2-bus header will disable the SPI as a boot device. (This was taken from the IRC logs, 09 August 2018 @ 17:23) You have to remove the jumper 2 seconds after having started your RP64 (before the white LED turns ON) otherwise the SPI will be missing and you won’t be able to flash it. Ayufan images contain (at the moment) only one script for the SPI and the RP64, it’s \u0026ldquo;rockpro64_reset_spi_flash\u0026rdquo;. Other SPI scripts are dedicated to the R64 (as it is written on the name) and it will mess-up your RP64 SPI if you use them.\n","permalink":"/documentation/ROCKPro64/Board/Layout/","tags":null,"title":"Layout"},{"categories":null,"contents":" Model: BOE NV140FHM-N49 14.0\u0026quot; (35.56 cm) diagonal size 1920x1080 resolution 60 Hz refresh rate IPS technology 1000:1 contrast 250 nit brightness 63% sRGB coverage 6-bit color 30-pin eDP connection ","permalink":"/documentation/Pinebook_Pro/Features/LCD_panel/","tags":null,"title":"LCD panel"},{"categories":null,"contents":"In total, there are four LEDs on the Pinebook Pro, three of which are placed in the top-left side of the keyboard, and one near the barrel port:\nThe red LED next to the barrel port indicates charging, in three ways. First, it will illuminate steadily when either the barrel jack power supply or a USB Type-C charger is connected to the Pinebook Pro, and the charging is active (that means power is supplied to the battery and system in parallel, and if it’s not enough the battery can still be discharging). Second, if the battery is at 100 %, the LED will remain turned off regardless of the connected power input (however, this is not possible for more than a split-second when the system is running). Third, this LED will flash at 0.5 Hz if there are any problems that prevent charging, such as the battery becoming too hot. To fully understand all the nuances, read the Power and charging article. The power indicator LED, above the keyboard, supports three different colors: green, amber and red. It is also capable of flashing to indicate eMMC activity, with proper software support. In the default Debian with MATE build, green LED means power and red means suspend (amber is unused). The green NumLock LED, above the keyboard. The green CapsLock LED, above the keyboard. The NumLock and CapsLock LEDs serve their usual purposes on a keyboard, but they also have a secondary function. When the privacy switches get activated they blink to confirm that the switch has been activated.\n","permalink":"/documentation/Pinebook_Pro/Features/LEDs/","tags":null,"title":"LEDs"},{"categories":null,"contents":"The LEDs can be configured to stop blinking. Under Linux this can be done using the following command (as root):\necho \u0026#34;default-on\u0026#34; \u0026gt; /sys/devices/platform/leds/leds/blue-led/trigger To list possible other triggers for the blue LED:\ncat /sys/devices/platform/leds/leds/blue-led/trigger An example for a trigger is activity, where the the blue LED reflects the CPU activity.\n","permalink":"/documentation/STAR64/LEDs/","tags":null,"title":"LEDs"},{"categories":null,"contents":"Linux BSP Kernel 4.9\nDownload:\nDirect download from pine64.org (5.04GB, MD5 of the TAR-XZ file 06B675B1C217D4CC6A21FF320DA250C1) ","permalink":"/documentation/PINE_H64_Model_B/Software/Linux_BSP_SDK/","tags":null,"title":"Linux BSP SDK"},{"categories":null,"contents":"To load code, you must move the jumper to the position closest to the edge, press reset, load the code, move the jumper back toward the center of the board, and press reset again.\nThere are currently a number of loaders in progress, each with differing degrees of completeness and success on various operating systems.\nIn the build tree, there is BLFlashCube for Windows, which is a proprietary GUI for flashing images. Linux and macOS binaries are available via Bouffalo Lab’s developer portal. bl60x-flash is in Python and has been reported successful on MacOS catalina (10.15.6) by Punnerud and madushan1000. BLOpenFlasher is a WIP, written in go, by Bouffalo Labs to provide source for a flash utility. bl602tool is a Python utility in development. Bouffalo’s MCU tool (Mar 2021) Python image tool replaced both of the above. Now combined with eflash loader, deals with partitions, DTS, signing, fuses etc. blflash serial flasher BL602 serial flasher, inspired by BLOpenFlasher ","permalink":"/documentation/PineCone/Loading_code/","tags":null,"title":"Loading code"},{"categories":null,"contents":"Store page: pine64.com\nUses the pogo pins to interface a Semtech SX1262 LoRa module with the PinePhone (Pro).\nImportant Software for receiving and sending LoRa messages with this back cover does exist, however no PinePhone operating system has added support for it yet. Schematics and Datasheet Schematic:\nPinePhone LoRa Back Cover Schematic ver 1.0 20210425 Datasheet:\nSX1262 Long Range, Low Power, sub-GHz RF Transceiver Datasheet ATmel ATtiny Microcontroller Datasheet I2C to SPI firmware:\nzschroeder6212’s tiny-i2c-spi Github page ","permalink":"/documentation/Phone_Accessories/LoRa/","tags":null,"title":"LoRa Add-on"},{"categories":null,"contents":"To set the MAC address on ROCK64 with the \u0026ldquo;Android eMMC\u0026rdquo; image:\nWindows ADB driver package installation is required as prerequisite Download and unzip WNpctool_V1.1.2_1226.zip. Run WNpctool.exe \u0026ldquo;as Administrator\u0026rdquo; on Windows OS Press recovery button on ROCK64 and power ON the ROCK64. After 2 seconds release the recovery button Plug the USB Cable from Top USB2 slot of ROCK64 to PC USB slot (WNpctool will show \u0026ldquo;Found one loader\u0026rdquo; at the bottom) Fill in LANMAC: with small letter MacAddress (e.g. 01234567abcd) then press on Write button Unplug the USB Cable and reboot the ROCK64 and use DOS command \u0026ldquo;ping \u0026hellip;\u0026rdquo; and \u0026ldquo;arp -a\u0026rdquo; or netscan to check the MAC address of the ROCK64 ","permalink":"/documentation/ROCK64/Software/MAC_address/","tags":null,"title":"MAC Address"},{"categories":null,"contents":" Note This page is incomplete, you\u0026rsquo;re welcome to improve it. Mainline Hardware Decoding refers to video decoding done using hardware accelerators on the mainline Linux kernel (i.e. what sits in Linus\u0026rsquo; tree).\nOn most consumer-oriented SoCs, there is what is referred to as a VPU (Video Processing Unit). The VPU is responsible for power-efficient encoding and decoding of videos. Hardware-accelerated video decoding can be useful to get smoother video playback on your devices, lower power consumption, and lower CPU utilization. Below is information regarding various hardware PINE64 uses and software that works with it.\nHardware Here\u0026rsquo;s a table of the current support for different hardware. \u0026ldquo;In review\u0026rdquo; means the patch series to enable support has been posted to the mailing lists but is undergoing review, \u0026ldquo;linux-next\u0026rdquo; means it has been accepted and staged for the next Linux merge window.\nRK3328 RK3399 RK3566 RK3588 JPEG No Yes No No MPEG-2 Yes Yes Yes No MPEG-4 Part 2/H.263 No No No No VP8 Yes Yes Yes No H.264/AVC Yes Yes Yes¹ Yes H.265/HEVC In review In review No Yes VP9 Yes Yes No No AVS2 N/A N/A N/A No AV1 N/A N/A N/A No Notes ¹ only Hantro, not rkvdec2, so with a maximum resolution of 1080p for now\nCedrus In 2018, Bootlin launched a crowdfunding campaign to bring a open source Allwinner VPU driver to mainline Linux, which came to be called Cedrus. The Cedrus media driver (For Allwinner SOCs such as A64) supported by mainline Linux supports H.264 and H.265 video decoding as of Linux 5.10, and with 5.11 came VP8 decoding support and a H.264 stateless video decoder interface. For more information refer to the Sunxi wiki.\nHantro The Hantro media driver supports Rockchip and NXP SoCs including the RK3399 used in the Pinebook Pro and RockPro64. In November 2020 it was announced that Bootlin was working on encoding support for the driver.\nrkvdec rkvdec is the video decoding hardware that\u0026rsquo;s developed by Rockchip presumably in house. It\u0026rsquo;s what Rockchip uses for decoding 4K H.264/AVC, VP9 and H.265/HEVC content. The driver in mainline linux for the first generation rkvdec (used in RK3328 and RK3399) supports VP9 and H.264, patches for HEVC support are also in the process of review.\nRK3566, RK3568 and likely RK3588 use a second generation of rkvdec called rkvdec2. No mainline driver for this exists yet. The rkvdec instance on RK3588 additionally supports the AVS2 video codec.\nrkdjpeg rkdjpeg is Rockchip\u0026rsquo;s in-house hardware accelerated JPEG decoder. It can be found on the RK3566 and RK3568 as well as the RK3588.\nNo mainline driver exists for it so far.\nSoftware GStreamer H.264 video decoding is possible when using GStreamer built from source, or an application utilizing it such as Clapper or µPlayer. µPlayer includes a indicator of when hardware acceleration is properly working and in use.\nFFmpeg Mainline FFmpeg currently lacks the necessary patches to use the v4l2-requests based API, but a fork that can utilize it exists.\nWith the patched ffmpeg, you can utilize hardware decoding using the -hwaccel drm parameter, e.g.:\nffmpeg -hwaccel drm -i input.mp4 -f null - -benchmark\nto measure how fast it decodes.\nmpv mpv v0.35 or later, built against the aforementioned FFmpeg fork, can be used to play back videos with hardware accelerated decoding. The hardware decoder path features interop with the GPU output, saving an expensive copyback operation. You can utilize the hardware decoding with e.g.:\nmpv --hwdec=drm [FILE]\nIn mpv versions prior to 0.35, you can use the copyback hwdec with:\nmpv --hwdec=drm-copy [FILE]\nMore Resources Megi\u0026rsquo;s Cedrus Information HW accelerated GStreamer playback on the PinePhone HW accelerated Clapper video player on the PinePhone ","permalink":"/documentation/General/Mainline_Hardware_Decoding/","tags":null,"title":"Mainline Hardware Decoding"},{"categories":null,"contents":"Mainline Hardware Encoding of video can be achieved through the V4L2 user-space API, for which currently only GStreamer implements the required code.\nSoC Support The following table shows the current supported codecs for encoding for each SoC. Support for decoding is separate.\nRK3328 RK3399 RK3566 RK3588 JPEG N/A Yes Yes No VP8 N/A In review No No H.264/AVC No No No No H.265/HEVC No N/A No No Encoding With GStreamer With GStreamer, in general, any V4L2 control can be set using the extra-controls=foo,name=value syntax after the encode pipeline stage identifier, where foo is any name you wish which GStreamer will promptly ignore, name is the name of the V4L2 control as shown by v4l2-ctl --list-ctrls (make sure to pick the right device with -d), and value is whatever value you want to set it to.\nJPEG Encoding This example converts an input MP4 file to an output MJPEG-inside-MKV file at JPEG quality 95, without any audio.\ngst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2jpegenc extra-controls=s,compression_quality=95 ! matroskamux ! filesink location=output.mkv VP8 Encoding Tip This requires a draft GStreamer merge request and the RFC kernel patchset applied. This example converts an input MP4 file to an output VP8-inside-MKV file with a quantiser between 12 and 28, without any audio. The quantiser value goes from 0 (best quality, biggest filesize) to 63 (worst quality, smallest filesize).\ngst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2slvp8enc min-quality=12 max-quality=28 ! queue ! matroskamux ! filesink location=output.mkv Alternatively, you can encode in variable bitrate mode with a target bitrate given in bits per second. Do note that Hantro doesn’t seem to do target bitrates below 2 mbit/s. In this example, the file is transcoded at a target bitrate of 3 megabits per second.\ngst-launch-1.0 filesrc location=input.mp4 ! qtdemux name=demux demux.video_0 ! decodebin ! videoconvert ! v4l2slvp8enc bitrate=3000000 ! queue ! matroskamux ! filesink location=output.mkv ","permalink":"/documentation/General/Mainline_Hardware_Encoding/","tags":null,"title":"Mainline Hardware Encoding"},{"categories":null,"contents":"Mainline Linux works on the RockBox without patches. To create a compatible u-boot image, https://github.com/mrfixit2001/uboot_builder may be used. The dtb has to be compiled from a recent dts, such as this, otherwise network and video won’t work.\nBuilding the dtb The dtb can be compiled from a recent dts. To do that, download a kernel source and add a dts, or use a kernel source with an fitting dts. The second variant is showcased here:\ngit clone https://github.com/mrfixit2001/mainline-kernel.git Then change the directory to the kernel sources:\ncd mainline-kernel Then create a config (defaults can be accepted):\nmake ARCH=arm64 menuconfig Now compile the dts files:\nmake ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 12 dtbs The compiled dtb file can now be copied from /arch/arm64/boot/dts/rockchip/rk3328-rockbox.dtb into for example the EXTLINUX location.\nConfiguring EXTLINUX In the EXTLINUX location, the /extlinux/extlinux.conf should be pointed to the correct kernel image and the correct dtb file. An example configuration (with serial output with 1500000 baud being enabled for the OS and with the root directory set to the second partition mmcblk1p2) can look like the following example:\ndefault ROCKBOX label ROCKBOX kernel /Image fdt /rk3328-rockbox.dtb append console=tty0 console=ttyS2,1500000n8 rw root=/dev/mmcblk1p2 rootwait rootfstype=ext4 panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 video=HDMI-A-1:1920x1080@60 loglevel=3 ","permalink":"/documentation/RockBox/Development/Mainline_Linux/","tags":null,"title":"Mainline Linux"},{"categories":null,"contents":"Please note:\nthis list is most likely not complete no review of functionality is done here, it only serves as a collection of efforts Linux kernel:\nType Link Available in version Devicetree Entry Pinecube https://lkml.org/lkml/2020/9/22/1241 5.10 Correction for AXP209 driver https://lkml.org/lkml/2020/9/22/1243 5.9 Additional Fixes for AXP209 driver https://lore.kernel.org/lkml/20201031182137.1879521-8-contact@paulk.fr/ 5.12 Device Tree Fixes https://lore.kernel.org/lkml/20201003234842.1121077-1-icenowy@aosc.io/ 5.10 Audio Device and IR LED Fix https://github.com/danielfullmer/pinecube-nixos/blob/master/kernel/Pine64-PineCube-support.patch https://github.com/danielfullmer/pinecube-nixos/issues/2[TBD] U-boot:\nType Link Available in version PineCube Board Support https://patchwork.ozlabs.org/project/uboot/list/?series=210044 v2021.04 Buildroot:\nType Link Available in version PineCube Board Support https://patchwork.ozlabs.org/project/buildroot/list/?series=314653 2023.11 ","permalink":"/documentation/PineCube/Software/Mainlining/","tags":null,"title":"Mainlining"},{"categories":null,"contents":"Making your own image/installation of Linux for SOQuartz is relatively easy, as all major components are mainlined. You will need:\nA build of mainline U-Boot ≥ v2023.10. Flash this to sector 64 (sector size 512, so byte 32768) of your image for SD or eMMC. It’s prudent to \u0026ldquo;protect\u0026rdquo; it by making a small (~16MiB) partition at this offset. A mainline Linux kernel ≥ v6.2. See Quartz64/Development#Linux Kernel Config Options for the device specific kernel configuration options. The root filesystem of the distribution of your choice. This can be on the same filesystem as your kernel and device tree if using extlinux.conf. You can either boot the kernel through U-Boot’s EFI booting, in which case it gets its device tree from U-Boot, or mark the partition containing your kernel and device tree with the legacy bootable flag and write an extlinux/extlinux.conf as explained in the U-Boot documentation.\n","permalink":"/documentation/SOQuartz/Software/Making_your_own/","tags":null,"title":"Making your own"},{"categories":null,"contents":"Here is the good DRM powerpoint presentation by Free Electron: https://free-electrons.com/pub/conferences/2017/kr/ripard-drm/ripard-drm.pdf\nHere is the DRM video presentation by Free Electron: https://www.youtube.com/watch?v=LbDOCJcDRoo\nWayland MALI Driver MALI-400 R6P2 Kernel Mode Setting binary download (1.86MB, MD5 523276872A9A11D1831ACE42F95DBBB1) MALI-400 R6P2 WAYLAND 64-bit binary driver and binary download (179KB, MD5 1698E8C54BDC6FE0804699F545FFE793) X11 MALI Driver MALI EULA document MALI-400 64-bit binary driver and binary download from pine64.org (1.7MB, MD5 4F56AE6FB793E7D946867942AF58FEAC) X11 Notice Attached are the implemented driver and library.\nlib_x11_r6p0.tar.bz2：opengles upper layer library； r6p0_kernel_driver.tar.bz2：gpu driver code； sunxi_arm_video.tar.bz2： dri2 and exa video related accelerator implementation； sunxi_drm_0622.tar.bz2：drm driver； Usage：\nUsing drm driver not able to coexist with display driver，due to utilize display relate BSP section；Drm driver able to integrate with sunxi_arm_video apply gem during cache and cache refresh，open cache able to increase performance；Drm driver utilize sunxi_tr BSP rotate section，not able to public sharing with sunxi_tr；\nKnown issue：\nDue to rotate hardware not support crop, and majority exa accelerators operate using crop，sunxi_arm_video is reference code (features already verified)，this allow familiar with X.Org hardware acceleratio.\nIf using web page and character appear vertical strip, this may not related to cache problem and may due to character library. This issue still need to further verified.\n","permalink":"/documentation/General/Mali_driver/","tags":null,"title":"Mali Driver"},{"categories":null,"contents":"A good DRM PowerPoint presentation by Free Electron here and the DRM video presentation by Free Electron here.\n32-bit Wayland MALI Driver:\nMALI EULA document MALI-T720 32-bit server binary driver and binary download from pine64.org (3.4MB, MD5 F2186A4CAE505A76E0758735886FE682) MALI-T720 32-bit client binary driver and binary download from pine64.org (3.4MB, MD5 F316A78AFABE87E69C8F816D18F15D68) 64-bit Wayland MALI Driver:\nMALI EULA document MALI-T720 64-bit server binary driver and binary download from pine64.org (5.0MB, MD5 13CC8DCB7CF068D80DFC16281E95E9D7) MALI-T720 64-bit client binary driver and binary download from pine64.org (5.0MB, MD5 951BAD6ED66D4CB904CFE0D65F2855E8) ","permalink":"/documentation/PINE_H64_Model_B/Further_information/Mali-T720_driver/","tags":null,"title":"Mali-T720 driver"},{"categories":null,"contents":"While it has been said that some Pinebook Pro units contain only one microphone despite having two labeled microphone holes on the outer casing, other units do indeed contain two microphones. It is presently unclear which batches have either configuration. Units from the initial community batch of 1000 units (following the initial 100) are believed to contain two, populating both labeled holes.\nThe wires leading to both microphones connect to the mainboard with a small white plastic connector, located directly adjacent to the ribbon cable attachment point for the keyboard interface.\nBuilt-in microphones not working If pavucontrol input doesn’t show microphone activity try changing the privacy switches. If the switches are in the correct place and microphone input isn’t working you can run alsamixer from the command line, hit F6 and select the es8316, hit F4 to get to the capture screen, select the bar labeled ADC, increase the gain to 0 dB, change the audio profile in pavucontrol to another one with input. Additionally you may want to modify ADC PGA to get the levels to where you want them. If that still hasn’t fixed it you may want to check that the microphone connector is plugged in.\nExternal wired microphone not working If you connect a headset with a microphone, you might need to open alsamixer, change card to es8316, and change option Differential Mux from lin1-rin1 to lin2-rin2.\n","permalink":"/documentation/Pinebook_Pro/Features/Microphones/","tags":null,"title":"Microphones"},{"categories":null,"contents":" Screenshot of fractal displaying an MMS conversation\nThe one known way to get MMS fully (meaning pictures and group messages) working is by relaying all SMS and MMS to a matrix server and using a matrix client to interact with them. https://gitlab.com/untidylamp/mmmpuppet is the bridge used here\nOutgoing messages over the max size are sent as a link. The link will not resolve if matrix is hosted on the PinePhone itself, so resize your images. An easy way might be to take a screenshot of your image viewer and send that image instead.\nThis method works with a local-to-the-pinephone matrix server but you could instead use a public one on the internet. Free accounts on matrix.org should work fine for example. Sleep may need to be disabled for non-local servers or the bridge can get stuck.\nInstall packages Arch Start with a nice and up-to-date Danctnix\u0026rsquo; Arch ARM PinePhone installation, mine is from April 20 2021. SSH into the PinePhone and then run this to install all the needed packages\nsudo pacman -Sy matrix-synapse fractal python-matrix_client python-gobject git meson ninja base-devel python-matrix-nio python-dbus Start the service\nsudo systemctl enable synapse sudo systemctl start synapse Mobian Flash a fresh mobian nightly (Tested September 28 2021) and install the following:\nsudo apt install matrix-synapse fractal mmsd-tng python3-matrix-nio python3-vobject python3-aiofiles git Set up Matrix Synapse on localhost Skip this if you will be using a remote homeserver. Make a new config with the server name set to local host.\nArch cd /etc/synapse/ sudo python -m synapse.app.homeserver --server-name localhost --config-path homeserver.yaml --generate-config --report-stats=no sudo vi /usr/lib/systemd/user/matrix-synapse.service Description=Multimedia Messaging Service Daemon After=ModemManager.service ExecStart= python3 -m synapse.app.homeserver --config-path=/etc/matrix/homeserver.yaml Restart=on-failure RestartSec=10s WantedBy=default.target Start the service\nsystemctl enable matrix-synapse --user systemctl start matrix-synapse --user Mobian cd /etc/matrix-synapse/ sudo rm homeserver.* sudo python3 -m synapse.app.homeserver --server-name localhost --config-path homeserver.yaml --generate-config --report-stats=no sudo service matrix-synapse start Add new matrix users in /etc/synapse/ (arch) or /etc/matrix-synapse/ (mobian)\nregister_new_matrix_user -c homeserver.yaml http://localhost:8008 # New user name and pw will both be pp register_new_matrix_user -c homeserver.yaml http://localhost:8008 # New user name and pw will both be mm Open fractal and log into the homeserver at http://localhost:8008 with username pp and password pp\nSet up MMSD From git Note: historical, no longer needed, mmsdtng commonly packaged\nGrab the git repository and install it:\ncd ~ git clone https://source.puri.sm/kop316/mmsd.git cd mmsd meson _build meson compile -C _build meson test -C _build sudo meson install -C _build sudo vi /usr/lib/systemd/user/mmsd-mm.service Description=Multimedia Messaging Service Daemon After=ModemManager.service ExecStart=/usr/local/bin/mmsd -n -d Restart=on-failure RestartSec=10s WantedBy=default.target sudo chmod 644 /usr/lib/systemd/user/mmsd-mm.service systemctl enable mmsd-mm.service --user systemctl start mmsd-mm --user Settings for T-Mobile This config works for me\nAfter starting mmsdtng the first time it should generate a config. Edit the following 3 options:\nvi ~/.mms/modemmanager/ModemManagerSettings CarrierMMSC=http://mms.msg.eng.t-mobile.com/mms/wapenc MMS_APN=fast.t-mobile.com AutoProcessSMSWAP=true Restart MMSD ModemManager service systemctl restart mmsdtng Install MMS bridge Grab it from git and put things in places\ncd ~ git clone https://gitlab.com/untidylamp/mmmpuppet.git cd mmmpuppet chmod +x mmmpuppet.py sudo cp mmm*.py /usr/local/bin/ mkdir -p $HOME/.config/mmm/ cp conf.json.sample $HOME/.config/mmm/conf.json Configure MMS bridge This will mostly take care of editing the config for you if you are running a local matrix server.\nsed -i \u0026#39;s^\u0026#34;https://matrix-client.matrix.org\u0026#34;^\u0026#34;http://localhost:8008\u0026#34;^\u0026#39; $HOME/.config/mmm/conf.json sed -i \u0026#39;s^\u0026#34;@bot_account:matrix.org\u0026#34;^\u0026#34;@mm:localhost\u0026#34;^\u0026#39; $HOME/.config/mmm/conf.json sed -i \u0026#39;s^\u0026#34;Change_me\u0026#34;^\u0026#34;mm\u0026#34;^\u0026#39; $HOME/.config/mmm/conf.json sed -i \u0026#39;s^\u0026#34;@your_accounts:matrix.org\u0026#34;^\u0026#34;@pp:localhost\u0026#34;^\u0026#39; $HOME/.config/mmm/conf.json You actually have to fill these two out yourself. I put \u0026ldquo;US\u0026rdquo; and my +1 and rest of 10 digit number.\nvi $HOME/.config/mmm/conf.json \u0026#34;cell_number\u0026#34;: \u0026#34;+15554441234\u0026#34;, \u0026#34;cell_country\u0026#34;: \u0026#34;CA\u0026#34;, Now we need to run it once to process the config file and remove secrets (It will say it has done this and exit on first run)\n/usr/local/bin/mmmpuppet.py check it out now\ncat $HOME/.config/mmm/conf.json If it doesn’t change the file to remove all the linebreaks then it didn’t like it. Figure out why by looking at the log file.\ncat ~/.config/mmm/mmmpuppet.log Go fix whatever went wrong. Which should be nothing. You should have seen a message like this as output before it returns you to a prompt:\nLogin successful. Config updated with token. Run again to start bridge. Set up MMS bridge service Make systemd unit\nsudo vi /usr/lib/systemd/user/mmmpuppet.service Description=Starts mmmpuppet interface After=mmsd-mm.service ExecStart=/usr/bin/python3 /usr/local/bin/mmmpuppet.py Restart=on-failure RestartSec=10s WantedBy=default.target and start it\nsudo chmod 644 /usr/lib/systemd/user/mmmpuppet.service systemctl enable mmmpuppet.service --user systemctl start mmmpuppet.service --user See if services are running:\nps aux | grep mm It should show something like this even after reboot\nalarm 6374 0.0 0.3 235364 7752 ? Ssl 22:44 0:00 /usr/local/bin/mmsd -n -d alarm 6825 9.8 2.7 224976 54188 ? Ssl 22:52 0:05 /usr/bin/python3 /usr/local/bin/mmmpuppet.py Remove Chatty For Arch use Pacman to remove Chatty.\nMobian:\napt remove chatty Don\u0026rsquo;t forget to enable data You can get SMS but not MMS with mobile data off\nLaunch fractal Log in with this homeserver: http://localhost:8008. Username is pp and password is pp.\nLogins are not saved. You need to add a new item named login to the gnome keyring manually to fix it. See: https://wiki.mobian.org/doku.php?id=fractal\nBasically apt install seahorse, open \u0026ldquo;passwords and keys\u0026rdquo; in the app drawer, click new (plus), select password keyring, and name it \u0026ldquo;login\u0026rdquo; (all lower no quotes). Then autologin will work as it should.\nDone At this point if you get a message a new room should be created by the bridge bot which you will be invited to. You can start a new conversation by creating a new room, setting the topic with phone numbers of participants, and then inviting the mm user. See the mmmpuppet readme for examples.\nOther clients quaternion also seems to work but has clunky UI issues. Might work better with scaling\n","permalink":"/documentation/PinePhone/Software_tricks/MMS_with_Matrix/","tags":null,"title":"MMS with Matrix"},{"categories":null,"contents":"The \u0026ldquo;Model A\u0026rdquo; Acrylic Open Enclosure is a case for \u0026ldquo;Model A\u0026rdquo; sized single-board computers (Pine A64, ROCKPro64, Quartz64 Model A) sold by PINE64, available from the official store.\nA Pine A64 mounted in the \u0026quot;Model A\u0026quot; Acrylic Open Enclosure. The text on the top is \u0026quot;PINE64\u0026quot; nowadays.\nInstallation Please refer to the official instructions for assembling the case.\nFor the Quartz64 Model A, you may need to file down the inner corner of one of the mounting posts for the little mic connector on the bottom of the board to clear it.\nMods 3D-Printable Top With Fan and PCIe Cutout Non-artist’s impression of the replacement top plate\nUser:CounterPillow has created an alternate 3D-printable top plate which allows for the mounting of a 40mmx40mmx10mm fan, as well as allowing for PCIe cards to be mounted while the case is assembled. The STL and STEP files are available under https://wiki.pine64.org/wiki/File:Model_A_acrylic_case_top_plate_with_fan_cutout.zip free of charge, licensed as CC-BY 4.0.\nA fan is mounted to it using self-tapping fan screws usually shipped with computer fans; put the fan on the underside of the plate, and screw in the self-tapping screws from the top side. You can either have the fan exhaust air through the top, or blow it onto the SoC’s heatsink. The latter configuration appears to work better, but precise measurements haven’t been made yet.\nRecommended printing material is PETG for its structural rigidity. However, PLA will likely work fine as well, and is easier to print. A 0.6mm nozzle was used for test prints, but any nozzle should work. Depending on the layer height you choose, your print may come out slightly thicker or thinner; this is no problem though. It’s recommended to enable the advanced \u0026ldquo;Detect Thin Walls\u0026rdquo; option in slic3r to get a cleaner g-code result around the fan holes.\n","permalink":"/documentation/Accessories/Cases/Model_A_Acrylic_Open_Enclosure/","tags":null,"title":"Model A Acrylic Open Enclosure"},{"categories":null,"contents":"The Quartz64 Model A allows for it to be powered from a single-cell 3.7V lithium-polymer battery. Because of unfortunate incidents, batteries are not easy to ship internationally, so PINE Store does not sell a matching battery for the board.\nPin-out right\nThe pins on the board are a JST PH-3 compatible header labelled +VBAT-. As one might guess, the positive wire should be towards the +, and the ground wire towards -. The center pin of the connector is for a temperature probe.\nWays to get a battery We will now go into various ways one might go about getting a working battery.\nCrimping one yourself You will need:\nan Engineer PA-20 (Amazon Search, eBay Search) or Hozan P-707 (Amazon Search, eBay Search) or similar crimp tool (\u0026lt;$80, good to have around anyway) The Hozan P-707 is also comparatively good at crimping \u0026ldquo;Dupont\u0026rdquo;-style terminals, in case you find yourself doing that a lot, because it provides round crimping holes in addition to rectangular ones. JST PHR-3 receptacles (~$0.05 on digikey) 3× JST SPH-002T-P0.5L crimp terminals (~$0.03 on digikey per terminal) When ordering from digikey, try to hit the minimum order cost to qualify for free shipping; you’ll get free fast courier shipping with all customs and duties pre-paid. a single-cell 3.7V lithium-polymer battery, ideally with a temperature probe 2800 mAh Renata ICP606168PRT on Conrad Germany, Conrad Switzerland 2000 mAh Adafruit on Adafruit US (no temperature probe, pre-crimped with JST PHR-2; just lift up the plastic tabs and pull out the terminals and shove them back into a PHR-3 connector) Aliexpress: try keywords \u0026ldquo;3.7v lithium battery temperature probe\u0026rdquo; Crimp the terminals onto the wires, crimp the strain relief onto the insulation, slide them into the connector until they firmly click in place.\nPINE64 18650 battery case You will need:\nPINE64 Lithium Battery Casing an 18650 sized lithium battery (not LiFePo4!) TODO: Get one of these and document how to use them\nUsing the battery Hardware Ensure the wires in the connector are in the right order. Turn off your Quartz64 Model A. Remove the BAT ON/OFF jumper. Plug in your battery. It is now ready to use if your device tree has been set up correctly. Caveats Not all parts of the board can be supplied from the battery. When you use battery as backup power for the board keep in mind that following parts of Quartz64-A will lose power when DCIN loses power:\n12V Fan connector EDP LCD backlight 5V power rails on the 20 pin GPIO header PCIe socket (both 12V and 3.3V supplies) All USB ports except for the black one Black USB port’s VBUS (the one above the USB 3.0 port) will go through a 22ms brownout to approximately VCC_SYS - 0.6V voltage, before the RK817 BOOST regulator kicks in. This will likely cause the connected USB device to reset or have its internal state corrupted. Software For the battery to be correctly detected, you will need to edit the device tree to add the charger and battery nodes, like this:\n// add this to root node (you may need to modify the values to fit your chosen battery) battery: battery { compatible = \u0026#34;simple-battery\u0026#34;; charge-full-design-microamp-hours = \u0026lt;6400000\u0026gt;; charge-term-current-microamp = \u0026lt;200000\u0026gt;; constant-charge-current-max-microamp = \u0026lt;2000000\u0026gt;; constant-charge-voltage-max-microvolt = \u0026lt;4200000\u0026gt;; factory-internal-resistance-micro-ohms = \u0026lt;117000\u0026gt;; voltage-max-design-microvolt = \u0026lt;4200000\u0026gt;; voltage-min-design-microvolt = \u0026lt;3200000\u0026gt;; ocv-capacity-celsius = \u0026lt;20\u0026gt;; ocv-capacity-table-0 = \u0026lt;4200000 100\u0026gt;, \u0026lt;4054000 95\u0026gt;, \u0026lt;3984000 90\u0026gt;, \u0026lt;3926000 85\u0026gt;, \u0026lt;3874000 80\u0026gt;, \u0026lt;3826000 75\u0026gt;, \u0026lt;3783000 70\u0026gt;, \u0026lt;3746000 65\u0026gt;, \u0026lt;3714000 60\u0026gt;, \u0026lt;3683000 55\u0026gt;, \u0026lt;3650000 50\u0026gt;, \u0026lt;3628000 45\u0026gt;, \u0026lt;3612000 40\u0026gt;, \u0026lt;3600000 35\u0026gt;, \u0026lt;3587000 30\u0026gt;, \u0026lt;3571000 25\u0026gt;, \u0026lt;3552000 20\u0026gt;, \u0026lt;3525000 15\u0026gt;, \u0026lt;3492000 10\u0026gt;, \u0026lt;3446000 5\u0026gt;, \u0026lt;3400000 0\u0026gt;; }; // add this to \u0026amp;rk817 node rk817_charger: charger { monitored-battery = \u0026lt;\u0026amp;battery\u0026gt;; rockchip,resistor-sense-micro-ohms = \u0026lt;10000\u0026gt;; rockchip,sleep-enter-current-microamp = \u0026lt;300000\u0026gt;; rockchip,sleep-filter-current-microamp = \u0026lt;100000\u0026gt;; }; You will also need to make sure that CONFIG_CHARGER_RK817 is enabled in your kernel.\n","permalink":"/documentation/Quartz64/How-Tos/Using_a_battery/","tags":null,"title":"Model A: Using a battery"},{"categories":null,"contents":"In this article, we’ll go over how to hook up a PCF8574 I^2^C I/O extender to a Quartz64 Model A single-board computer, including what device tree changes to make and how to control it.\nIntroduction to the PCF8574 The PCF8574 is a fairly ubiquitous GPIO extender that communicates through the I^2^C bus. You can find modules featuring it from many vendors on the usual marketplaces for cheap. It exposes 8 additional GPIO lines, and can be daisy chained to up to 8 devices, giving you an additional 64 GPIO outputs. Combining it with 8 PCF8574A modules will actually push this to a total of 128 GPIO outputs added to your board!\nThe PCF8574 has a mainline Linux driver, meaning that you do not need to use I^2^C directly to control it; it will just appear as another /dev/gpiochip_\u0026lt;n\u0026gt;_ device. A lot of Raspberry Pi focused guides for this chip get this precise thing wrong actually, and have the user manually fiddle with the bus.\nDevice tree changes To control the chip, you’ll need to modify your board’s device tree—a description of its hardware for devices that don’t automatically enumerate—so that the kernel knows how to load the driver.\nThere are two ways to edit your device tree. Either you can manually edit the base tree, or use device tree overlays.\nDevice tree overlays On images/distributions which support device tree overlays in their build of u-boot and the device tree blobs, you can very simply write a device tree overlay. This means your base tree can still change as you update your OS, and there’s no manual intervention needed on your part to have your modification be carried forward.\nYour overlay will look something like this:\n/dts-v1/; /plugin/; \u0026amp;i2c3 { #address-cells = \u0026lt;1\u0026gt;; #size-cells = \u0026lt;0\u0026gt;; status = \u0026#34;okay\u0026#34;; pcf8574: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; ; You can compile it with dtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts, assuming your input file is called pcf8574.dts.\nInstalling the overlay depends on your distribution. On Plebian, see DT_OVERLAYS.md.\nIf you want to use constants and includes in your device tree overlay, you’ll need to pass the file through a C preprocessor with the appropriate include directories. For an example of a build system that does this, please consult the Makefile of CounterPillow’s overlay-examples repository.\nManually editing the base tree Important You will need to install dtc for this. The easiest way to go about this is to get a copy of the Linux kernel source code from https://kernel.org that matches your kernel version (uname -a), as the device tree definitions live in the Linux kernel repository. Technically, device trees should be compatible across kernel versions, but I wouldn’t gamble on it.\nOnce you have the kernel source, you can use your local configuration: run zcat /proc/config.gz \u0026gt; .config inside the top-level directory of the Linux kernel source tree to use your running kernel’s configuration. Then run make xconfig (or one of the other non-graphical alternatives, like nconfig or menuconfig), save the configuration to set any new options to their default values, and then also ensure that CONFIG_GPIO_PCF857X (a.k.a. \u0026ldquo;PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders\u0026rdquo;) is either set to \u0026ldquo;M\u0026rdquo; or \u0026ldquo;Y\u0026rdquo;.\nIn arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts, add the following section:\n\u0026amp;i2c3 { status = \u0026#34;okay\u0026#34;; pcf8574: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; ; This lets the kernel know that there’s a PCF8574 hanging off the third I^2^C controller, and is listening on slave address 0x20 (decimal: 32). Be sure to use tabs of size 8 for the indentation, this is the style the kernel uses.\nNow run make dtbs to compile the device tree. This should give you a arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dtb***, which you can then copy into your /boot/dtbs/ as for example quartz-with-pcf8574.dtb* or something like that. Then, in your extlinux.conf*, either add a new boot label or modify your existing boot labels FDT line to point towards this dtb file, with the path being relative to */boot and not to /.\nDaisy chaining As previously stated, you can hook up multiple of these modules onto the same bus. Here’s how the device tree changes for this will look like:\n\u0026amp;i2c3 { status = \u0026#34;okay\u0026#34;; pcf8574_1: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; pcf8574_2: pcf8574@21 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x21\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; ; Notice how the labels (the part before the colon) have been differentiated, and the address (number after the @ and number in the reg field) has changed for the second module.\nNote be sure to change the A0, A1 and A2 pins accordingly to set the addresses of the daisy chained modules! For example, for the second module, pull A0 high and leave A1 and A2 low. The address pins work like a binary counter, so 000 -\u0026gt; 001 -\u0026gt; 010 -\u0026gt; 011 -\u0026gt; 100 -\u0026gt; \u0026hellip; Interrupts The PCF8574 will pull its INT pin low when one of its inputs changed. We can use this to generate an interrupt:\n\u0026amp;i2c3 { status = \u0026#34;okay\u0026#34;; pcf8574: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; interrupt-parent = \u0026lt;\u0026amp;gpio0\u0026gt;; interrupts = \u0026lt;RK_PC1 IRQ_TYPE_EDGE_FALLING\u0026gt;; interrupt-controller; #interrupt-cells = \u0026lt;2\u0026gt;; }; ; In this case, we use GPIO0 Pin C1 (RK_PC1 with interrupt-parent gpio0), a.k.a. UART0_TX, a.k.a. pin 12, as the interrupt pin. (Note: You cannot use pin 7 here, as it’s pulled high.)\nTo know which RK_PXX and which interrupt-parent correspond to which pin on the board, consult the schematics.\nHooking up the module Hook up SDA to pin number 3 of your board, and SCL to pin number 5. Connect GND to ground, e.g. pin number 9, and VCC to 3.3V, for example pin number 1. If you plan on using interrupts, connect the INT pin to whichever GPIO you defined as the interrupt pin.\nTODO: Put photo of hooked up module here.\nUsing the GPIOs Upon booting your board with your modified device tree blob, you should have an additional /dev/gpiochip__ device, most likely /dev/gpiochip5. You can verify this by running libgpiod’s gpioinfo utility, which should now show you an additional GPIO chip with only 8 lines.\ngpiochip5 - 8 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high If you are daisy-chaining the modules, you’ll see an additional gpiochip with 8 lines for each additional module.\nTesting the pins as outputs To test whether this is working, you can connect an LED between a pin (in this example, 4) of your PCF8574, and ground. Then (assuming your chip number is 5) you can use sudo gpioset -B pull-down 5 4=0 to turn off the pin and set its bias mode to be pulled down, and use sudo gpioset 5 4=1 to turn it on and sudo gpioset 5 4=0 to turn it off. Connecting an LED with no resistor in-line should be fine because the pins deliver like 100mA current at most.\nProgrammatically driving the pins TODO: Expand this section with how to control the pins programmatically using libgpiod or whatever.\nAdding a button to send a key code In this example, we’re adding a button that’s hooked between the input pin 0 and ground, and making it type W whenever it’s pressed.\n/ { ... *keyboard {* *compatible = \u0026#34;gpio-keys\u0026#34;;* *w_key {* *gpios = \u0026lt;\u0026amp;pcf8574 0 GPIO_ACTIVE_LOW\u0026gt;;* *linux,code = \u0026lt;17\u0026gt;;* *label = \u0026#34;W_KEY\u0026#34;;* *};* };* ... ; The label here isn’t the defining bit but the input event code is. 17 is for W. You can also include the header file on top and use the symbol name KEY_W\nNote that you will need to have your PCF8574 set up with interrupts for this.\n","permalink":"/documentation/Quartz64/How-Tos/Using_a_PCF8574/","tags":null,"title":"Model A: using a PCF8574"},{"categories":null,"contents":"The \u0026ldquo;Model B\u0026rdquo; Acrylic Open Enclosure is a case for \u0026ldquo;Model B\u0026rdquo; sized single-board computers sold by PINE64, available from the official store.\nA_ROCK64_mounted_in_the_case,_the_correct_way.\nInstallation To install the SBC inside the case, stick the long screws into the SBC mounting holes from below, place the board such that the screws sit in its mounting holes, and screw on the brass fasteners on top of the SBC.\nMods 3D-Printable Top With Fan Cutout Top_view_of_the_plate\nThe assembled modified case with a Noctua NF-A4x10 5V PWM mounted to it. The SBC is mounted in the enclosure upside-down.\nUser:CounterPillow has created an alternate 3D-printable top plate which allows for the mounting of a 40mmx40mmx10mm fan. The STL and STEP files are available free of charge under https://wiki.pine64.org/wiki/File:Model_B_acrylic_case_top_plate_with_fan_cutout.zip, licensed as CC-BY 4.0.\nA fan is mounted to it using self-tapping fan screws usually shipped with computer fans; put the fan on the underside of the plate, and screw in the self-tapping screws from the top side. You can either have the fan exhaust air through the top, or blow it onto the SoC’s heatsink. The latter configuration appears to work better, but precise measurements haven’t been made yet.\nRecommended printing material is PETG for its structural rigidity. However, PLA will likely work fine as well, and is easier to print. A 0.6mm nozzle was used for test prints, but any nozzle should work. Depending on the layer height you choose, your print may come out slightly thicker or thinner; this is no problem though. It’s recommended to enable the advanced \u0026ldquo;Detect Thin Walls\u0026rdquo; option in slic3r to get a cleaner g-code result around the fan holes.\nThe print will take approximately 7.8 metres of filament, and take in the order of one hour, though this depends on slicer settings and printer model.\nThe cooling performance with a Noctua NF-A4x10 5V PWM is enough to no longer throttle after a few minutes of cpuburn, but comfortably sitting at below 75°C instead. The memory has no temperature sensor, but will likely be cooled quite a bit as well.\nRough wiring diagram of how to PWM control the fan from a ROCK64 with a helper Arduino\nSince the ROCK64 has no PWM pins available to control the fan, a slight workaround can be done; with the gpio-fan device tree binding, an Arduino can be controlled to soft-PWM a suitable 25 kHz signal for the fan. The ROCK64 uses 3.3V on the GPIO pins, so you’ll need to logic level convert it to 5V if you’re using a 5V Arduino, and if you’re using a 3.3V microcontroller, you’ll need to logic level shift the output PWM signal as the 5V fan will be expecting 5V PWM on the PWM pin.\nThe device tree changes and the Arduino sketch which User:CounterPillow created for this can be used for any purpose by anyone. It is recommended to play around with the device tree though, to add more trip points for better control over when the fan actually ramps up, and adding more hysteresis as the temperature reading from the ROCK64 is quite jumpy.\n","permalink":"/documentation/Accessories/Cases/Model_B_Acrylic_Open_Enclosure/","tags":null,"title":"Model B Acrylic Open Enclosure"},{"categories":null,"contents":"The PinePhone Pro uses Quectel EG25-G as modem. AT commands are used to communicate with the modem.\nAT commands A list of documented AT commands can be found for example in this AT commands documentation from Quectel. Further undocumented AT commands found by the developer megi, who reverse-engineered parts of the modem and its firmware, can be found on megi’s website here.\nTo send AT commands to the modem under Linux, minicom or the often-preinstalled atinout utility can be used.\natinout example:\necho \u0026quot;AT+\u0026lt;command here\u0026gt;\u0026quot; | sudo atinout - /dev/ttyUSB2 - minicom example:\nminicom -D /dev/ttyUSB2 VoLTE The PinePhone and PinePhone Pro modem supports VoLTE and comes with a few VoLTE profiles preloaded. Most operating systems try to set the correct profile automatically.\nTo list the available VoLTE profiles:\nAT+QMBNCFG=\u0026#34;list\u0026#34; +QMBNCFG: \u0026#34;List\u0026#34;,0,1,1,\u0026#34;ROW_Generic_3GPP\u0026#34;,0x0501081F,201901141 +QMBNCFG: \u0026#34;List\u0026#34;,1,0,0,\u0026#34;VoLTE-ATT\u0026#34;,0x0501033C,201909271 +QMBNCFG: \u0026#34;List\u0026#34;,2,0,0,\u0026#34;hVoLTE-Verizon\u0026#34;,0x05010141,201911251 +QMBNCFG: \u0026#34;List\u0026#34;,3,0,0,\u0026#34;Sprint-VoLTE\u0026#34;,0x05010205,201908141 +QMBNCFG: \u0026#34;List\u0026#34;,4,0,0,\u0026#34;Commercial-TMO_VoLTE\u0026#34;,0x05010505,201811231 +QMBNCFG: \u0026#34;List\u0026#34;,5,0,0,\u0026#34;Telus-Commercial_VoLTE\u0026#34;,0x05800C43,201912031 +QMBNCFG: \u0026#34;List\u0026#34;,6,0,0,\u0026#34;Commercial-SBM\u0026#34;,0x05011C18,201904021 +QMBNCFG: \u0026#34;List\u0026#34;,7,0,0,\u0026#34;Commercial-DT\u0026#34;,0x05011F1C,201905311 +QMBNCFG: \u0026#34;List\u0026#34;,8,0,0,\u0026#34;Reliance_OpnMkt\u0026#34;,0x05011B38,201910161 +QMBNCFG: \u0026#34;List\u0026#34;,9,0,0,\u0026#34;TF_Germany_VoLTE\u0026#34;,0x05010C1B,201909201 +QMBNCFG: \u0026#34;List\u0026#34;,10,0,0,\u0026#34;TF_Spain_VoLTE\u0026#34;,0x05010CFA,201909261 +QMBNCFG: \u0026#34;List\u0026#34;,11,0,0,\u0026#34;Volte_OpenMkt-Commercial-CMCC\u0026#34;,0x05012071,201904281 +QMBNCFG: \u0026#34;List\u0026#34;,12,0,0,\u0026#34;OpenMkt-Commercial-CT\u0026#34;,0x05011322,201911081 +QMBNCFG: \u0026#34;List\u0026#34;,13,0,0,\u0026#34;OpenMkt-Commercial-CU\u0026#34;,0x05011505,201807052 To select a profile manually, select the best fitting one or a generic one if none fits:\nAT+QMBNCFG=\u0026quot;select\u0026quot;,\u0026quot;ROW_Generic_3GPP\u0026quot; Then enable Voice over LTE using:\nAT+QCFG=\u0026quot;ims\u0026quot;,1 And reboot the modem to apply the settings:\nAT+CFUN=1,1 To check the status of VoLTE during a call, the AT command CLCC can be used:\nAT+CLCC +CLCC: 1,1,0,1,0,\u0026#34;\u0026#34;,128 +CLCC: 2,1,0,1,0,\u0026#34;\u0026#34;,128 In the fourth item of the list, \u0026ldquo;0\u0026rdquo; means voice and and \u0026ldquo;1\u0026rdquo; means data. If both rows have \u0026ldquo;1\u0026rdquo; then the voice call is being carried over VoLTE.\nAPN settings The APN setting is only required for a public Internet connection (\u0026ldquo;data\u0026rdquo;) on the phone. For tested APN settings and how to apply them see APN settings.\nCarrier support The page Carrier support contains information about the frequency support of different carriers and hints on setting up cellular network connectivity.\nDocuments Detailed information about the modem can be found on the page of the developer megi, including reverse-engineered parts of the firmware and its functions. There is also a document about using the modem from January 18th 2020 by megi here. A script at the end of the document showcases a way to power off the modem before powering off the phone, which is integrated into most of the available operating systems.\nFirmware update There is a (nearly) free custom firmware and the stock firmware available for the PinePhone Pro. Both can be updated to a newer version with new features and bug fixes.\nCustom firmware There is a (nearly) free custom firmware for the PinePhone and PinePhone Pro modem by the developer biktorgj, which can be found here.\nThe custom firmware has various advantages (and zero disadvantages) over the stock firmware, including:\nSignal tracking support with checks against the OpenCelliD database Persistent storage is optional and unexpected shutdowns don’t mess up the modem A lower energy consumption due to the lower minimum clock frequency And many more, see Features not available on stock firmware The custom firmware can be flashed using fwupd or a flashing script.\nStock firmware Tip The following instructions are directed towards professional users. It is highly recommend to make sure the update process is not interrupted to prevent the modem from bricking. The stock modem firmware can be updated to a newer version if it is outdated. The firmware version can be checked using the following AT command (at the example of atinout, alternatively minicom can be used to communicate with the modem too):\necho \u0026#39;AT+QGMR\u0026#39; | sudo atinout - /dev/ttyUSB2 - Pre-update checklist:\nPlease make sure all requirements of the checklist are fulfilled. If the update process is interrupted it will lead to a corrupted firmware of the modem, causing it to brick. Recovering a bricked modem is exponentially more complicated and requires the user to boot a special mode by physically bridging test points on the modem.\nThe battery needs to be charged sufficiently The phone needs to be plugged into a charger Deep sleep is recommended to be disabled as it can interrupt the update process It is recommended to close all other running applications Use common sense while doing the update, don’t do the update while being impaired in any way To get the latest firmware, clone the repository of user Biktorgj on the phone:\ngit clone https://github.com/Biktorgj/quectel_eg25_recovery After cloning the directory, open it with cd:\ncd quectel_eg25_recovery Then run qfirehose, which starts the flashing process:\nsudo ./qfirehose -f ./ The modem will automatically reboot after the update process is done. The boot process takes around 30 to 60 seconds. After that it is highly recommended to reboot the device.\nFirmware modifications See PineModems for more information regarding modem bootloader unlocking, building a custom modem firmware and modem recovery.\nGPS / GNSS The GPS engine in the modem supports mutli-GNSS reception from GPS, GLONASS, BeiDou, Galileo and QZSS independent of a cellular connection. The operation of the GNSS subsystem can be controlled via a separate set of AT commands, or via qmi. The A-GPS data upload uses the file management AT commands, which also have their own manual. These are linked in the documentation section.\nAs with most smartphones, the PinePhone Pro has a small antenna and has difficulty getting a first fix without assistance data, a cold start can take 15 minutes under good conditions. The eg25-manager is configured to upload A-GPS data by default (see here).\nBasic testing of GNSS reception can be done by using the AT command interface (/dev/ttyUSB2) from a terminal program like minicom and the data output interface (/dev/ttyUSB1) to feed NMEA data into gpsmon or some other program that can parse standard NMEA sentences.\ngpsmon decoding GPS data from /dev/ttyUSB1\nTo check if GNSS data output is enabled, you can\ncat /dev/ttyUSB1 this should display a stream of NMEA sentences\n$GPVTG,,T,,M,,N,,K,N*2C $GPGSA,A,1,,,,,,,,,,,,,,,,*32 $GPGGA,,,,,,0,,,,,,,,*66 Further details can be found under Sensors and navigation.\nVoice mail The operating systems of the PinePhone Pro may not have support for accessing your voicemail by holding down the 1-key. Carriers might support accessing the voice mail via an external number however.\n","permalink":"/documentation/PinePhone_Pro/Modem/","tags":null,"title":"Modem"},{"categories":null,"contents":"This article explains how to install a multiple linux distribution environment on your PinePhone Pro. You can choose to install this environment to the phone’s internal eMMC memory or to a microSD card. These instructions also integrate with the multi-distribution image releases page section.\nVariables During the processes of partitioning the target device, building the image or installing the bootloader, make sure the variables are properly defined. Each time you open a new terminal window, the values of the variables must be re-set.\nInfo BASE is the base directory path on your computer\nDEV is the device name from the lsblk command\nATTR are the attributes of each partition/distribution\nSIZE is the GiB capacity of each partition/distribution\nNameUrl is the Key:Value of distribution name and relative URL download address This guide has been tested with 6 Linux distributions on a 128 GiB microSD card, and following variables:\n$ BASE=ppp-multi-image $ DEV=sdb # i.e. sdb or mmcblk0 $ ATTR=RequiredPartition,LegacyBIOSBootable $ SIZE=11GiB $ declare -A NameUrl $ NameUrl[uboot]=https://xff.cz/kernels/bootloaders-2024.04/ppp.tar.gz $ #NameUrl[uboot]=https://megous.com/dl/tmp/ppp.tar.gz # test build $ NameUrl[arch]=https://github.com/dreemurrs-embedded/Pine64-Arch/releases/download/20240326/archlinux-pinephone-pro-phosh-20240326.img.xz $ NameUrl[manjaro]=https://github.com/manjaro-pinephone/phosh/releases/download/beta37/Manjaro-ARM-phosh-pinephonepro-beta37.img.xz $ NameUrl[mobian]=https://images.mobian.org/pinephonepro/weekly/mobian-rockchip-phosh-20250706.img.xz $ NameUrl[pmos]=https://images.postmarketos.org/bpo/v23.12/pine64-pinephonepro/phosh/20240501-0425/20240501-0425-postmarketOS-v23.12-phosh-22.3-pine64-pinephonepro.img.xz $ NameUrl[sailfish]=https://gitlab.com/sailfishos-porters-ci/dont_be_evil-ci/-/jobs/artifacts/master/download?job=pinephonepro-rootfs $ NameUrl[ut]=https://ci.ubports.com/job/focal-hybris-rootfs-arm64/job/master/lastSuccessfulBuild/artifact/ubuntu-touch-pinephone-pro-img-arm64.raw.xz $ NameUrl[extra]= Install rk2aw Make sure your phone has the rk2aw pre-loader installed to its SPI flash memory. PinePhone Pro models ordered after November 2023 are shipped with rk2aw pre-installed. Otherwise, follow the instructions in this section to install it.\nBoot up the PinePhone Pro’s stock operating system and start a shell session. You can do this either by opening the terminal emulator app, or by enabling the SSH service and logging in from a PC on the same network. Then execute the following commands (from the phone’s shell):\n$ curl -O https://xff.cz/kernels/bootloaders-2024.04/ppp.tar.gz $ tar -xvzf ppp.tar.gz $ cd ppp $ sudo ./spinor-flash-initial-setup.sh Info The multi-boot image can function without rk2aw, but you will need to make sure the correct bootloader is started by your phone’s SoC.\nIf you are installing to a microSD card, then either:\nEnsure that the phone’s SPI flash and eMMC are empty, or Hold down the RE button during boot to force the phone to boot from the microSD card by disabling the SPI flash and the eMMC. If you are installing to the eMMC, make sure the SPI flash is empty.\nFurther instructions can be found on the author’s website.\nExpose the device Connect your PinePhone Pro to a Linux computer, with the stock USB cable. Press power button on. From the graphical menu select eMMC over USB or SD over USB to expose the device to your computer. You can optionally flash microSD directly into your computer’s slot, if available.\nErasing Make sure there are no signatures or partitions left, and overwrite the first sectors with zeroes. You can find the target device under lsblk command.\n$ sudo wipefs /dev/$DEV $ sudo wipefs --all --force /dev/$DEV* $ sudo dd if=/dev/zero of=/dev/$DEV status=progress bs=32768 count=1 Optionally you can zeroes the whole device:\n$ sudo dd if=/dev/zero of=/dev/$DEV status=progress bs=32768 count=$(expr $(lsblk -bno SIZE /dev/$DEV | head -1) \\/ 32768) Partitioning Partition the device for the multiple distributions:\n$ sudo sfdisk /dev/$DEV --wipe always \u0026lt;\u0026lt;EOF label: gpt first-lba: 64 table-length: 10 attrs=RequiredPartition, type=D7B1F817-AA75-2F4F-830D-84818A145370, start=64, size=32704 name=\u0026#34;uboot_raw\u0026#34; $( for name in \u0026#34;${!NameUrl[@]}\u0026#34;; do case ${name} in (uboot|extra) continue ;; esac printf \u0026#39;%s\\n\u0026#39; \u0026#34;attrs=\\\u0026#34;$ATTR\\\u0026#34;, size=$SIZE, name=\\\u0026#34;$BASE-${name}\\\u0026#34;\u0026#34; done | sort ) attrs=\u0026#34;$ATTR\u0026#34;, size=$SIZE, name=\u0026#34;$BASE-ut-data\u0026#34; attrs=\u0026#34;$ATTR\u0026#34;, size=+, name=\u0026#34;extra\u0026#34; EOF Returned string:\nsudo sfdisk /dev/$DEV --wipe always \u0026lt;\u0026lt;EOF label: gpt first-lba: 64 table-length: 10 attrs=RequiredPartition, type=D7B1F817-AA75-2F4F-830D-84818A145370, start=64, size=32704 name=\u0026#34;uboot_raw\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-arch\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-manjaro\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-mobian\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-pmos\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-sailfish\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-ut\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-ut-data\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=+, name=\u0026#34;extra\u0026#34; EOF Expected results:\nChecking that no-one is using this disk right now ... OK Disk /dev/sd[...]: 118.16 GiB, 126877696000 bytes, 247808000 sectors Disk model: microSD card Reader Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes \u0026gt;\u0026gt;\u0026gt; Script header accepted. New situation: Disklabel type: gpt Disk identifier: A012E9D0-B4EB-4677-926F-D93AE4C696FA Device Start End Sectors Size Type sdb1 64 32767 32704 16M unknown sdb2 32768 23101439 23068672 11G Linux fs sdb3 23101440 46170111 23068672 11G Linux fs sdb4 46170112 69238783 23068672 11G Linux fs sdb5 69238784 92307455 23068672 11G Linux fs sdb6 92307456 115376127 23068672 11G Linux fs sdb7 115376128 138444799 23068672 11G Linux fs sdb8 138444800 161513471 23068672 11G Linux fs sdb9 161513472 247805951 86292480 41.1G Linux fs The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. Install U-Boot In order to display the graphical distribution selector when the phone boots, we need to install a custom version of the U-Boot bootloader.\nFirst, use the following commands to download the required U-Boot image. Note that we are downloading the same ppp.tar.gz archive as we did in the rk2aw section; if you already have a copy of this archive on your computer, you may skip the download and simply extract its contents into ~/$BASE/downloads/.\n$ NAME=uboot $ mkdir -p ~/$BASE/downloads \u0026amp;\u0026amp; cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} $ tar -xvzf $(basename \u0026#34;${NameUrl[$NAME]}\u0026#34;) Then, use the following command to install the U-Boot image to the correct location on the microSD/eMMC:\n$ sudo dd if=ppp/foss/u-boot-rockchip.bin of=/dev/$DEV bs=512 seek=64 status=progress conv=fsync Info If you are interested in building this U-Boot image yourself, you can download the source code from xff.cz. However, you will still need a copy of ppp.tar.gz since it contains the U-Boot build configuration file (ppp/foss/.config).\nCopy this file to the root of your U-Boot source directory, keeping the name .config. You can then use make to initiate the build process.\nBuild the partitions Make sure you download an updated file from relases page. You will need to build each partition one by one, setting properly the variables and using specific commands according the selected distribution. When you reach the building repeat advice, come back to this point and build the next distribution.\nArch, Manjaro, Mobian, postmarketOS For these distributions, download and decompress the image:\n$ NAME=arch # set distribution name, i.e. arch, manjaro, mobian, pmos $ mkdir -p ~/$BASE/downloads \u0026amp;\u0026amp; cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} $ xz -v -d -k $(basename \u0026#34;${NameUrl[$NAME]}\u0026#34;) $ mv $(basename -as .xz \u0026#34;${NameUrl[$NAME]}\u0026#34;) $NAME.img Mount the image:\n$ cd ~/$BASE/downloads $ sudo losetup -P /dev/loop0 $NAME.img $ sudo mkdir -p /mnt/$NAME/boot /mnt/$NAME/root /mnt/$NAME/dev $ sudo mount /dev/loop0p1 /mnt/$NAME/boot/ $ sudo mount /dev/loop0p2 /mnt/$NAME/root/ Copy root and boot contents:\n$ sudo dd if=/dev/loop0p2 of=/dev/disk/by-partlabel/$BASE-$NAME bs=1M status=progress conv=fsync $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev/ $ sudo scp -r /mnt/$NAME/boot/* /mnt/$NAME/dev/boot SailfishOS This distribution needs different commands. Download and decompress the image:\n$ NAME=sailfish $ mkdir -p ~/$BASE/downloads \u0026amp;\u0026amp; cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} -O artifacts.zip $ unzip artifacts.zip $ mv pinephonepro/*/*.tar.bz2 sailfish.tar.bz2 $ mkdir -p ~/$BASE/downloads/sailfishos $ sudo tar -xvf sailfish.tar.bz2 -C sailfishos/ \u0026gt; /dev/null Format the partition and copy the extracted files directly onto the device:\n$ sudo mkfs.ext4 -F /dev/disk/by-partlabel/$BASE-$NAME $ sudo mkdir -p /mnt/$NAME/dev $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev $ sudo rsync -avz --progress ~/$BASE/downloads/sailfishos/ /mnt/$NAME/dev $ sudo chmod a=rwx /mnt/$NAME/dev/boot/* Ubuntu Touch For this distribution, download and decompress the image:\n$ NAME=ut $ mkdir -p ~/$BASE/downloads \u0026amp;\u0026amp; cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} $ xz -v -d -k $(basename \u0026#34;${NameUrl[$NAME]}\u0026#34;) $ mv $(basename -as .xz \u0026#34;${NameUrl[$NAME]}\u0026#34;) $NAME.img Mount the image:\n$ cd ~/$BASE/downloads $ sudo losetup -P /dev/loop0 $NAME.img $ sudo mkdir -p /mnt/$NAME/boot /mnt/$NAME/system /mnt/$NAME/userdata /mnt/$NAME/dev $ sudo mount /dev/loop0p2 /mnt/$NAME/boot/ $ sudo mount /dev/loop0p3 /mnt/$NAME/system/ $ #sudo mount /dev/loop0p4 /mnt/$NAME/userdata/ Create the userdata partition and copy system and boot contents:\n$ sudo mkfs.ext4 -F /dev/disk/by-partlabel/$BASE-$NAME-data $ sudo e2label /dev/disk/by-partlabel/$BASE-$NAME-data $NAME-data $ sudo dd if=/dev/loop0p3 of=/dev/disk/by-partlabel/$BASE-$NAME bs=1M status=progress conv=fsync $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev/ $ sudo scp -r /mnt/$NAME/boot/* /mnt/$NAME/dev/boot All distributions If present, you can optionally backup boot.scr, extlinux.conf and fstab files.\n$ sudo mkdir -p /mnt/$NAME/dev/boot/extlinux $ [ ! -f /mnt/$NAME/dev/boot/extlinux/extlinux.conf ] || sudo mv /mnt/$NAME/dev/boot/extlinux/extlinux.conf /mnt/$NAME/dev/boot/extlinux/extlinux.conf.bk $ [ ! -f /mnt/$NAME/dev/boot/boot.scr ] || sudo mv /mnt/$NAME/dev/boot/boot.scr /mnt/$NAME/dev/boot/boot.scr.bk $ [ ! -f /mnt/$NAME/dev/boot/boot.pinephonepro.scr ] || sudo mv /mnt/$NAME/dev/boot/boot.pinephonepro.scr /mnt/$NAME/dev/boot/boot.pinephonepro.scr.bk $ sudo mv /mnt/$NAME/dev/etc/fstab /mnt/$NAME/dev/etc/fstab.bk Then write the new /boot/extlinux/extlinux.conf file, making sure you remove # comment for the selected distributions:\n$ sudo tee /mnt/$NAME/dev/boot/extlinux/extlinux.conf \u0026lt;\u0026lt;EOF ## /boot/extlinux/extlinux.conf menu title Pinephone Pro Boot Menu ## uncomment next line for timed default-selected distro #default $NAME timeout 50 label $NAME menu label $NAME ## uncomment next 3 lines for ARCH #fdt /boot/dtbs/rockchip/rk3399-pinephone-pro.dtb #initrd /boot/initramfs-linux.img #kernel /boot/Image.gz ## uncomment next 3 lines for MANJARO #fdt /boot/dtbs/rockchip/rk3399-pinephone-pro.dtb #initrd /boot/initramfs-linux.img #kernel /boot/Image ## uncomment next 3 lines for MOBIAN #fdtdir /boot/dtbs/6.12-rockchip/ #initrd /boot/initrd.img-6.12-rockchip #linux /boot/vmlinuz-6.12-rockchip ## uncomment next 3 lines for PMOS #fdtdir /boot/dtbs-pine64-pinephonepro/ #initrd /boot/initramfs-extra #linux /boot/vmlinuz ## uncomment next 2 lines for SAILFISH #fdt /boot/rockchip/rk3399-pinephone-pro.dtb #kernel /boot/Image ## uncomment next 3 lines for UT #fdtdir /boot/dtb-6.5.0-okpine-ut/ #initrd /boot/initrd.img-6.5.0-okpine-ut #linux /boot/vmlinuz-6.5.0-okpine-ut ## uncomment next line for all distros, excluding UT ## since there is a bug related to wifi from wpa_supplicant in Archlinux add \u0026#39;brcmfmac.feature_disable=0x82000\u0026#39; just before \u0026#39;rw rootwait\u0026#39; #append root=PARTLABEL=$BASE-$NAME console=ttyS2,115200 console=tty0 loglevel=7 rw rootwait ## uncomment next line for UT only #append root=PARTLABEL=$BASE-$NAME console=ttyS2,115200 console=tty loglevel=7 systempart=/dev/disk/by-partlabel/$BASE-$NAME datapart=/dev/disk/by-partlabel/$BASE-$NAME-data security=apparmor rw rootwait EOF Then write the new /etc/fstab file, making sure you remove # comment for selected distribution:\n$ sudo tee /mnt/$NAME/dev/etc/fstab \u0026lt;\u0026lt;EOF ## \u0026lt;file system\u0026gt; \u0026lt;dir\u0026gt; \u0026lt;type\u0026gt; \u0026lt;options\u0026gt; \u0026lt;dump\u0026gt; \u0026lt;pass\u0026gt; ## uncomment next line for ARCH #PARTLABEL=$NAME / ext4 rw,relatime 0 1 ## uncomment next line for MANJARO #PARTLABEL=$NAME / ext4 defaults 0 1 ## uncomment next line for MOBIAN #PARTLABEL=$NAME / ext4 defaults,x-systemd.growfs 0 1 ## uncomment next line for PMOS #PARTLABEL=$NAME / ext4 defaults 0 0 ## uncomment next 7 lines for SAILFISH #PARTLABEL=$NAME / ext4 rw,noatime 0 1 #devtmpfs /dev devtmpfs nosuid 0 0 #devpts /dev/pts devpts gid=5,mode=620 0 0 #tmpfs /dev/shm tmpfs noexec,nosuid,nodev 0 0 #proc /proc proc defaults 0 0 #sysfs /sys sysfs defaults 0 0 #tmpfs /tmp tmpfs nosuid,nodev 0 0 ## uncomment next 3 lines for UT #PARTLABEL=$NAME / ext4 defaults 0 1 #PARTLABEL=$NAME /boot ext4 defaults 0 2 #PARTLABEL=$NAME-data /userdata ext4 defaults 0 2 EOF Close any mounted directory window.\nUnmount, detach and resize To unmount and deatch all building images, run:\n$ sudo umount /mnt/$NAME/* $ sudo rm -r /mnt/$NAME $ sudo losetup -D On the first boot, if it doesn’t happen automatically, you can manually resize each image to fill the entire partition using GParted GUI software or using the CLI. Please note that SailfishOS doesn’t need any resizing.\n$ sudo e2label /dev/disk/by-partlabel/$BASE-$NAME $NAME $ sudo e2fsck -f /dev/disk/by-partlabel/$BASE-$NAME $ sudo resize2fs /dev/disk/by-partlabel/$BASE-$NAME Important Repeat the building process for the next distribution, adapting needed variables. Follow-up notes Any time a distribution update rebuilds the initramfs it is necessary to delete /boot/boot.scr again to keep the rk2aw menu clean.\nIn case you want to reinstall only one distribution, the easy way is to delete and recreate the selected partition using the GParted GUI.\nIf the device doesn’t start, connect a compatible serial cable to the headphone jack and a computer, switch off microswitch 6 and start a serial console to investigate further. Find out the corresponding USB device using ls /dev/ttyUSB* and then connect to it with for example minicom using the command minicom -b 1500000 -D /dev/ttyUSB[...], where [\u0026hellip;] is the number of the USB device.\nTo find the exact LABEL, UUID, PARTLABEL and PARTUUID names, open a terminal window on the phone and use the command blkid.\nAppendix Build the postmarketOS image\nYou can optionally use pmbootstrap to generate the distribution image on your Linux computer, instead of downloading a pre-made image. Make sure you install pmbootstrap before building the image.\nStart creating 2 GB empty image file, format and mount it.\n$ sudo su # dd if=/dev/zero of=postmarketos.img bs=1 count=0 seek=2G status=progress \u0026amp;\u0026amp; sync # mkfs.ext4 postmarketos.img # losetup -P /dev/loop0 postmarketos.img # exit Then build the image using pmbootstrap\n$ pmbootstrap init $ pmbootstrap status $ pmbootstrap pull $ pmbootstrap install --sdcard=/dev/[LOOP-DEVICE] $ pmbootstrap shutdown ","permalink":"/documentation/PinePhone_Pro/Software/Multi-distribution_image/","tags":null,"title":"Multi-distribution image"},{"categories":null,"contents":"The PINE64 NAS Case is intended for either a Network Attached Storage (NAS) or Desktop application, but it can also be used in a number of other server capacities. It is built from precision-cut and powder-coated aluminum. The physical dimensions are 232.4mm (Width) x 105.0mm (Height) x 145.2mm (Depth).\nAn exploded view of the NAS Case, illustrating how all the components come together, can be found here. Please refer back to this PDF document during assembly to verify correct orientation of individual components.\nFront View of the PINE64 NAS Case for the ROCKPro64\nWhat does the NAS Case house? Internal Layout of the NAS Case\nThe NAS Case can house the following components:\nA ROCKPro64 Single Board Computer (SBC) with a tall, mid-size or slim/ no heatsink A PCIe to dual SATA adapter or a different low-profile PCIe card, e.g. an NVMe adapter Either two 3.5 inches OR t incheso 2.5 inches HDDs / SSDs; combination of any two sized drives is accepted A 80mm fan with a Ph 2-Pin connector Up to three SMA antennas, two of which can be attached to the WiFi/ BT module What comes in the box? When you purchase the NAS Case from the PINE store the following items are shipped to you:\nThe NAS Case itself, which consists of a top and a bottom half as well as an internal HDD SSD mount. Two SATA cables A custom power cable capable of powering two 2.5 inches inchesr 3.5 inches HDDs /SSDs The required screws, fittings and a LED relay What other bare-minimum things do I need for a NAS build? You will need the PCIe to SATA adapter from the PINE64 store to connect your disks to your ROCKPro64 board. https://forum.pine64.org/showthread.php?tid=6932. WARNING: this adapter does not work well with two HDDs, see https://forum.pine64.org/showthread.php?tid=6511:\nTo assemble a functional NAS in the NAS Case you will require a number of additional parts.\nWith the exception of HDDs/SSDs, everything you need for a complete build can be purchased from the PINE store:\nA ROCKPro64 2GB or 4GB board A 12V 5A power supply A PCIe to dual SATA adapter: WARNING, the SATA adapter from PINE64 store is low-quality and will not function well with two SATA HDD. One or two 2.5 inche inches/ 3.5 inches HDDs (not sold in the PINE store). A class 10 micro SD card and/or eMMC module. You can purchase all the aforementioned items in the PINE64 store\nWhat other things should I consider buying for a NAS build in the NAS Case? There are a few other things which you may wish to consider purchasing for your NAS. These peripherals, while not necessary from an operational standpoint, may contribute to the longevity and stability of your NAS’ operation OR expand it with additional functionality:\nAn eMMC to USB 2.0 adapter A tall heatsink (N.B. Any of the three available heatsinks will fit in the NAS Case) An 80mm fan The WiFi / BT module (The fan and heatsink are highly recommended)\nWhich software should I use? The OMV WebGUI is easy to understand but also very robust. It offers easy installation of plugins, system administration and overview of available services\nIf you are intending to build a home or small company NAS, then we strongly recommend you use Open Media Vault (OMV). OMV is an open source NAS solution that makes setting up user accounts, network shares and services a breeze. It also simplifies installing additional features (called plugins), such as: PLEX media server; Remote Desktop; Encryption; RSync; etc.\nIts worth noting that Nextcloud, or other similar Cloud storage solutions, can also be easily installed alongside the OMV OS Image.\nAdministration and monitoring of OMV is done via an advanced WebGUI, which also allows for updating and upgrading the ROCKPro64. To learn more about OMV please visit their website.\nTo download the latest OMV build OR one of the numerous available Linux Distribution OS Images please visit the ROCKPro64 OS download section.\nStep-by-Step Assembly Instructions If you prefer a video tutorial or just want an overview of the process before you start check out this instructional video.\nStep 1. Preparation of the NAS Case for Installation Remove the top of the NAS Case. It is held together by two screws on either side with the exception of the bottom (left, right, top and back). Once done, the top of the case should lift right off without any resistance.\nThe next step is to remove the HDD/SSD holding bracket, which is screwed into the bottom of the case. Flip the bottom over and undo the screws which hold the bracket in place.\nYou should now be left with a bare case ready for installation of the necessary components.\nStep 2. Installing the ROCKPro64 into the NAS Case Correct Placement of the ROCKPro64 in the empty case, with Ethernet; Power; and HDMI at the back of the NAS Case\nFront IO with IR and LED relay installed\nMake sure nothing is plugged into your ROCKPro64 - including a micro SD card. If you intend to use a heatsink with your board then please install it now before proceeding. If you bought the heatsink from the Pine64 store it comes with thermal paste and/or a thermal pad. You can use one or the other (not both!). The thermal pad is easier to apply but the thermal paste should be better at cooling if properly applied.\nPlace your ROCKPro64 into the case with USB 2.0 and 3.0/C ports facing the front of the case. It should fit snugly and align with the port cut-outs in the case. Do not attempt at installing the board at an angle; insert it while holding it level and lowering it into the case.\nSecure the board with 4x screws included in the see-through bag. Make sure that the board is held firmly in the case but do not overtighten the screws.\nIn the see-through bag you will also find a small semi-opaque plastic cylinder. This is the LED light lead and it should be installed from the outside of the case into the hole right over the reset (RST) switch. Simply press it into the hole until it sits tight.\nIf you wish to install an IRx receiver into your case then you should also place it into the IR socket at this stage. It should align with the cutout right above the power (PWR) switch.\nStep 3 PCIe to SATA adapter and Cabling DC header on the ROCKPro64 for the power cable\nPCIe to SATA installed. Note the SATA connection orientation\nWith the board in place it’s time to set up the PCIe to SATA adapter and do the cabling necessary to attach HDDs / SSDs.\nPlace the SATA Adapter into the PCIe slot on the ROCKPro64 board so that the holding bracket of the adapter faces the back of the case. In the back of the case there is a cutout for the PCIe adapter; some variants of the PCIe dual SATA adapter can be configured for eSATA if need be, and the eSATA ports are accessible in the back of the case. By default, the internal SATA connectors are active on the adapter.\nSecure the PCIe dual SATA Adapter with a single screw at the top of the bracket, in the back of the NAS Case.\nThis is the right time to plug in the SATA and custom power cable. The SATA cables plug into the ports on the top or front of the adapter while the power cable plugs into DC header located on the board - just below the power jack, to the left of the Ethernet port (when viewed from front).\nHave the cables hang outside the case or to the side for now so that they do not get in the way until they are needed.\nStep 4. Installing HDDs / SSDs into the Holding Bracket Bracket Orientation in the NAS Case\nThe next step is to install HDDs/ SSDs into their holding bracket; 2.5 inches drives need to be installed at the very bottom of the bracket whi inchese 3.5 inches drives are at the top of the the bracket.\nFor 2.5 inches drives make sure that the drives are oriented up and their SATA and power ports face the front of the NAS Case.\nFor 3.5 inches HDDs, make sure they are oriented up and their SATA and power ports face the right side of the NAS Case (towards the fan mounting location).\nEach drive you mount in the holding bracket requires 4x screws which come supplied in the see-through bag. Make sure the drives are held in place firmly but do not over-tighten the screws.\nOnce the holding bracket is assembled and you have your drives mounted, please set it aside and proceed to the next step.\nStep 5. Installing Extras (eMMC; WiFi BT module + SMA Antennas; 80mm Fan) The 80mm fan is a worthwhile addition to the NAS Case build\nIf you have additional peripherals, such as an eMMC or WiFi/BT module as well as the 80mm fan, then now is the right time to install them. If you have none of the above, please proceed to step 6 of this guide.\nThe eMMC and WiFi/BT modules are fitted into their respective placements on the ROCKPro64 board - please consult the diagram for their correct installation.\nIf you intend to use external u.FL to SMA antennas in the NAS Case then this is also the time to install them into the case. In the back section of the case at the very top you will find three cut-outs where the SMA antennas can be fitted. Don’t plug the u.FL leads antenna leads into the WiFi/BT module just yet - instead wait until after the disk holding bracket is installed into the case (step 6).\nThe fan should be mounted on the right-hand side of the case. We suggest that the fan is oriented for negative pressure, blowing air out of the case rather than taking air in. (User:AlephNull disagrees and recommends a positive pressure configuration both to allow a filter to be placed over the intake to prevent dust ingress and because the cage on the outlet side of the fan helps keep the wiring for 3.5\u0026quot; disks away from the fan blades). For best cable management results, have the fan power lead face the front of the case so that it can easily be routed to its header located next to GPIO pins on the ROCKPro64. The fan should be secured using 4x long screws (that fasten into bolts) which can be found in the see-through bag supplied with the NAS Case. Plug in the fan at this stage of the installation and route the cable at the bottom of the front of the case.\nStep 6. Installing the HDD / SSD Bracket and Routing Cables Complete assembly of the NAS Case\nTop view of a complete NAS Case Assembly\nInstalling the HDD/SSD bracket into the case and wiring it up is the last step before closing up the case.\nPlace the bracket with the disks installed (from step 4) into the case. The bracket should line up with the guiding bolts and screw holes at the bottom of the case. The section of the bracket that holds 3.5 inches HDDs needs to face the left side of the case (when viewed from front) and should overhang the ROCKPro64 board slightly. T inchese 3.5 inches SATA and power ports should face the right side of the case - where the fan mount inches, while 2.5 inches SATA and power ports should face the front of the case.\nWith the bracket aligned, flip the bottom of the case over while holding the bracket in place. Screw it into place using 4x Phillips head screws that came included with the NAS Case.\nThe last thing remaining before the NAS Case can be screwed shut is routing SATA and power cables:\nFor 3.5 inches HDDs we suggest routing power and SATA cables underneath the drives, whe inchese 2.5 inches HDDs/SSDs would otherwise reside.\nFor 2.5 inches disks you have plenty of routing options as there is much space available. The most obvious route is straight over the disks, where t inchese 3.5 inches HDDs would reside.\nStep 7. Closing the NAS Case and Powering On your NAS Almost there. All that’s left to do is to screw together the NAS Case. Screw in the top front screws first followed by screws on either side of the case. Do the back screws last. There, you are done.\nTo power on your new NAS Case and HDDs all you need to do is to plug in power and Ethernet (This is obviously assuming that you are intending to use it as a NAS or a headless server).\nIO accessibility when the NAS Case is assembled When the NAS Case is assembled and screwed shut these ROCKPro64 IO ports remain accessible:\nMicro SD slot USB 2.0 USB 3.0 and USB type C Power and Reset switches The headphone and microphone jack Gigabit Ethernet port HDMI ","permalink":"/documentation/Accessories/Cases/NASCase/","tags":null,"title":"NASCase"},{"categories":null,"contents":" 10/100/1000Mbps Ethernet WiFi 802.11 b/g/n with Bluetooth 4.0 (optional) ","permalink":"/documentation/SOEDGE_Baseboard/Features/Network/","tags":null,"title":"Network"},{"categories":null,"contents":" Armbian To get the cluster running, start off with a basic Armbian SOPINE install on the first module or directly on all the modules. Armbian offers Debian and Ubuntu as options for download.\nThere is an issue recognizing the network that needs you to make a change to the base image described here, and a PXE issue. If you have a good description, please add it here. The network issue has been resolved in Armbian builds post December 2020 - as described here.\nAs of February 2021 the current Armbian image is not working (see the post on the Armbian forum). The latest working version is 21.02.1. To update the system, the package \u0026rsquo;linux-dtb-current-sunxi64\u0026rsquo; needs to be held back by running\necho \u0026quot;linux-dtb-current-sunxi64 hold\u0026quot; | sudo dpkg --set-selections\nThere are a number of possible basic installation methods.\nFull install on each module’s mSD card. eMMC install on the first module. PXE boot for all modules, from the first module, or an external host. Others The current version of NetBSD may have the networking issue solved in Armbian, as described above.\n","permalink":"/documentation/Clusterboard/Operating_systems/","tags":null,"title":"Operating systems"},{"categories":null,"contents":"The PineTab will automatically boot from microSD if a bootable card is inserted. Although it is technically possible to use any ARM distribution (because the PineTab uses the mainline kernel), only few of them will actually be usable on Early Adopters PineTab, due to specifics of working with LCD panel. Among those listed all except for postmarketOS have working builds.\nArch Linux ARM Unofficial Arch Linux ARM with Phosh as the UI selection, maintained by the DanctNIX community.\nDownload:\nThe latest image can be downloaded here Mobian A Mobian build for ARM64 running with Phosh. The current version of the base Debian system is Debian Bookworm. See the installation instructions here. If you have questions about Mobian, please ask them in the Mobian Matrix room.\nDownload:\nPineTab images can be downloaded here. The password is 1234 Default credentials Default user mobian/1234 postmarketOS postmarketOS extends Alpine Linux to run on smartphones and other mobile devices.\nIt offers various user interfaces (Phosh, Plasma Mobile, Sxmo, Plasma Desktop, Gnome 3, Kodi, XFCE4 and more). As of writing, official images are provided with Phosh and Plasma Mobile. The official images come in two flavors, either as demo image to try out postmarketOS, or with the installer.\nWhen using the installer images (recommended), it is possible to:\nencrypt your installation install from the SD card to eMMC Getting postmarketOS for the PineTab:\nDownload page Flashing instructions Power users may also create their own image with the distribution’s install and development tool pmbootstrap Rhino Linux Rhino Linux is an Ubuntu-based distribution that uses the rolling-release model by tracking the devel branch of repositories. The port is currently maintained by Oren Klopfer (oklopfer).\nThe bootloader (U-Boot) comes pre-flashed in the port. Installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload:\nRhino Linux Downloads (select Pine64 on the dropdown)\nDefault credentials Default user rhino/1234 Notes:\nFoundational to the distribution is Pacstall, a Debian-based user repository inspired by the AUR. Additionally, RL comes with Unicorn, a custom modified version of XFCE with various modernizations and improvements, including auto-rotation for mobile devices.\nDiscord - Matrix - GitHub - Wiki\nSailfish OS You can get SailfishOS on your with the flash-it script, which will write an image on a SD card. https://github.com/sailfish-on-dontbeevil/flash-it\nThere is a forum discussion with further information.\nhttps://forum.pine64.org/showthread.php?tid=11850\nMany things are still broken but Bluetooth, Audio, Rotation and Keyboard are working.\nUbuntu Touch Ubuntu Touch is a mobile version of the Ubuntu distribution made and maintained by the UBports community. The port is currently maintained by Oren Klopfer (oklopfer).\nThe bootloader (U-Boot) comes pre-flashed in the port. Installation just requires flashing the the .img.xz file to an SD or the eMMC.\nDownload:\nUBports 20.04 PineTab Latest Releases UBports PineTab Device Info\nDefault credentials Default user Set during boot root phablet/1234 Notes:\nScroll down to the middle of the GitLab project page, or directly here at the UBports website to see which features work.\nContributions and bug reports can be made at the UBports PineTab GitLab page. See UBports website for how to donate.\n","permalink":"/documentation/PineTab/Operating_systems/","tags":null,"title":"Operating systems"},{"categories":null,"contents":" [[Pinecil_Hall_Effect_Sensor| Hall Effect Sensor]]: add a sensor that activates with a magnet to put the Pinecil to sleep when it enters a holder or stand. [[#Fasteners/Screws| Thumb Screws]]: switch tiny tip holder screw to an easy to use thumb screw. LED light ring install: add a PCB light ring to Pinecil. Video of the process LED light install: add two LEDs to Pinecil. RGB internal LED - pink and blue LEDs. ","permalink":"/documentation/Pinecil/Modifications/Optional_advanced_modifications/","tags":null,"title":"Optional advanced modifications"},{"categories":null,"contents":"There are several end-node units planned:\nloRa back case for the PinePhone standalone USB dongle-type end-node adapter PineTab adapter as well as a SPI module (which can also be configured as a USB LoRa dongle) a LoRa stick powered by a single 18650 battery (using the BL602, and can be fitted with GPS, an low-power OLED panel and additional sensors) All the end-nodes use the SX1262 chip.\nPictures ","permalink":"/documentation/Pinedio/Other_end_nodes/","tags":null,"title":"Other end nodes"},{"categories":null,"contents":" Good documentation about PINE A64, A64+, and A64-LTS GPIO pins article Linux Sunxi Wiki page on PINE A64 Collection of scripts to set up a minimal Xenial 14.04.3 / Debian 8 Jessie root filesystem Contributed By Uli Middelberg Linux Image created by Andre Przywara PINE A64 with HypriotOS by Dieter and Govinda H2testw 1.4 – Gold Standard In Detecting USB Counterfeit Drives F3 - an alternative to h2testw Benchmarking The Low-Cost PINE 64+ ARM Single Board Computer by Michael Larabel PINE64 Linux build scripts, tools and instructions by Longsleep PINE64 Linux image by Longsleep A series of Youtube video on PINE A64 Developers Board by Michael Larson PINE64 Quick Start Guide (with Gotchas) Shrinking images on Linux by FrozenCow Manjaro Arm installation script ","permalink":"/documentation/Pine_A64-LTS/Further_information/Other_resources/","tags":null,"title":"Other resources"},{"categories":null,"contents":" Good documentation about PINE A64, A64+, and A64-LTS GPIO pins article Linux Sunxi Wiki page on PINE A64 PINE A64 Linux build scripts, tools and instructions by Longsleep PINE A64 Linux image by Longsleep PINE A64 Linux Github by ayufan PINE A64 Android Github by ayufan Armbian’s PINE A64 Page Collection of scripts to set up a minimal Xenial 14.04.3 / Debian 8 Jessie root filesystem Contributed By Uli Middelberg Linux Image created by Andre Przywara PINE A64 with HypriotOS by Dieter and Govinda H2testw 1.4 – Gold Standard In Detecting USB Counterfeit Drives F3 - an alternative to h2testw Benchmarking The Low-Cost PINE 64+ ARM Single Board Computer by Michael Larabel A series of Youtube video on PINE A64 Developers Board by Michael Larson PINE64 Quick Start Guide (with Gotchas) Shrinking images on Linux by FrozenCow FFmpeg Hardware encoder Cedrus264 on Linux by avafinger ","permalink":"/documentation/Pine_A64/Further_information/Other_resources/","tags":null,"title":"Other resources"},{"categories":null,"contents":" Linux Sunxi Wiki page on Pinebook Pinebook Linux Github by ayufan Pinebook Android Github by ayufan Armbian’s Pinebook Page ","permalink":"/documentation/Pinebook/Further_information/Other_resources/","tags":null,"title":"Other resources"},{"categories":null,"contents":" Video: A peek at Pine64’s LoRa gateway and modules IOTW - Blockchain-Enabled IoT Data Platform PineDio Stack BL604 RISC-V Board: Testing The Prototype LoRaWAN on PineDio Stack BL604 RISC-V Board The Things Network on PineDio Stack BL604 RISC-V Board Monitor IoT Devices in The Things Network with Prometheus and Grafana Internal Temperature Sensor on BL602 IoT Digital Twin with Roblox and The Things Network PineDio LoRa Gateway: Testing The Prototype Apache NuttX OS on RISC-V BL602 and BL604 SPI on Apache NuttX OS LoRa SX1262 on Apache NuttX OS LoRaWAN on Apache NuttX OS Rust on Apache NuttX OS Connect IKEA Air Quality Sensor to Apache NuttX OS PineDio Stack BL604 runs Apache NuttX RTOS NuttX Touch Panel Driver for PineDio Stack BL604 Buttons on BL602 NuttX NuttX GPIO Expander for PineDio Stack BL604 (Mostly) Automated Testing of Apache NuttX RTOS on PineDio Stack BL604 RISC-V Board Zig on RISC-V BL602: Quick Peek with Apache NuttX RTOS Build an IoT App with Zig and LoRaWAN Build an LVGL Touchscreen App with Zig Apache NuttX RTOS on a RISC-V IoT Gadget: PineDio Stack BL604 (Video) Simpler, safer LVGL Touchscreen Apps with Zig and Apache NuttX RTOS (Video) ","permalink":"/documentation/Pinedio/Other_resources/","tags":null,"title":"Other resources"},{"categories":null,"contents":" ROCK64 Forum ROCK64 Linux GitHub Repo ROCK64 ayufan GitHub Repo Rockchip Linux GitHub Repo Rockchip Android RKMC (Forked from Kodi 16.1) Rockchip Open Source Wiki Armbian’s ROCK64 Page ","permalink":"/documentation/ROCK64/Further_information/Other_resources/","tags":null,"title":"Other resources"},{"categories":null,"contents":" ROCKPro64 Forum PINE64 shop Rockchip Linux GitHub Repo Rockchip Open Source Wiki ExplainingComputers have a video review of the RockPro64 here, including linux first boot. Useful articles and blog posts If you want to dive in to the ecosystem, here’s a short list of various articles and blog posts that can help you set up your soft- or hardware development environment.\nBlobless boot with RockPro64 by Andrius Štikonas EBBR on RockPro64 by Marcin Juszkiewicz ","permalink":"/documentation/ROCKPro64/Further_information/Other_resources/","tags":null,"title":"Other resources"},{"categories":null,"contents":" Warning There is the possibility of damaging your equipment by overclocking. Do so at your own risk! Note This page is incomplete, you’re welcome to improve it. Note All information regarding clock speeds, voltages and more are stored in the DTB (Device Tree Blob). You can learn more about it here. Overclocking is a way to get more performance out of the system by running it at higher clock speeds than the factory default, usually while putting out more heat and using more power (You can also downclock to possibly reduce power consumption and thermals at the cost of performance). It is highly recommended that you avoid overvolting the device, as that has a high risk of damaging the hardware, hence the warning at the beginning of this page. However, just some slight overclocks without the added voltage can not only improve performance, but not carry as much risk (Still: Do at your own risk!). It should be noted however that overclocking can cause instability, so you will need to test and see what values work best with your device (There is a silicon lottery for the PinePhone’s hardware).\nA64-based devices Important These instructions are targeting the PinePhone to simplify the explanation, however they can be used to also overclock other devices such as the Pinetab if you modify the proper DTB files. Editing the PinePhone DTS In order to overclock the PinePhone you will have to first convert the DTB file in /boot/dtbs/allwinner/ to a DTS file. You will see sun50i-a64-pinephone-1.2.dtb, and also two other files with different PinePhone mainboard revisions (1.1 and 1.0). You will want to select the correct file for your PinePhone (Only choose 1.1 if you have a Braveheart, As all other consumer PinePhones use the 1.2 DTS).\nOnce you’ve found the file, you can run the following command to convert the DTB to DTS:\ndtc -I dtb -O dts /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dtb -o /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dts Finally, modify the newly converted .dts file and change the clockspeeds you wish to modify. You can simply use a text editor to do so.\nTo convert back to DTB:\ndtc -I dts -O dtb /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dts -o /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dtb Afterwards you can simply reboot and check with sudo cat /sys/kernel/debug/clk/clk_summary to see if the changes have correctly applied.\nImportant In the future it is possible that someone may make a driver to adjust clockspeeds of the A64 from userspace (using a config file) without the need to recompile. However, currently the only way to overclock is to either compile your own kernel, or modify just the DTB (instructions above). GPU Open /boot/dtbs/allwinner/sun50i-a64-pinephone-1.2.dts (You will have to find the source of the kernel used by your distribution. There is the Pine64 kernel, and Megi’s) in a text editor following the PinePhone overclocking instructions.\nLook for mali: gpu@1c4000 { and within that block search for assigned-clock-rates = \u0026lt;432000000\u0026gt;;\nThe assigned-clock-rates line should be set to 432000000, this means that the GPU is clocked at 432MHz by default. So if you want 500MHz, set the value to 500000000.\nSave the DTS file, and recompile the DTB. In order to check if the overclock was successfully applied you can run: sudo cat /sys/kernel/debug/clk/clk_summary.\nImportant The file may be slightly different and you may need to enter the values as hexadecimals Note The GPU appears to run stable overclocked to 540 Mhz, however more testing with a wider group of devices is needed. Note Remember to run a benchmark tool (such as glmark2-es2) to help check stability. CPU The stock speed of the A64 is 1.152 GHz. The A64 can be overclocked significantly, it is highly advisable not to do this unless you can also drop the voltage at the same time.\nIf the CPU is undervolted and overclocked at the same time, it is possible to reach similar thermals and power consumption to the stock configuration but with better performance.\nPower consumption at different voltages and frequencies:\nConfiguration Frequency Voltage Power (Screen 50%) Stock 1.152GHz 1.30v ~4.35w Stock + Undervolt 1.152GHz 1.18v ~3.65w Overclock + Undervolt 1.344Ghz 1.28v ~4.60w The table above contains measurements created in postmarketOS (SWMO/SXMO - postmarketOS 21.12 SP1) with the screen on (set to 50% brightness) under a threaded load.\nAXP803 PMIC voltage steps on DCDC2:\nVoltage range Step size 0.50V-1.20V 10mV 1.22V-1.30V 20mV The table above shows the valid voltages provided by the AXP803 PMIC on DCDC2 (used to power the cores). For example, setting the voltage to 0.60V is valid, but setting it to 1.23V is not. When overclocking, ensure that you only use valid voltages at each operation point (otherwise it will simply be dropped and ignored). You can use (after installing) cpupower to display all valid frequencies after boot.\nImportant The user somefoo was able to undervolt the PinePhone at each frequency operation point by at least -100mv. The A64 set to 1.152Ghz runs at 1.18v instead of the standard 1.3v, dropping the power usage by ~0.7w under full single threaded load|The silicon lottery will dictate how well you can undervolt. Note The exact voltages and frequencies that you can achieve will depend on your device. Make sure to run stress tests (such as stress-ng) to ensure stability. DRAM Warning It is not recommended to exceed 667 MHz clockspeed on the DRAM. 648MHz is likely the upper limit. Note Make sure to set your DRAM to a multiple of 24. Note The current frequency your DRAM is running at can be found using this command: cat /proc/device-tree/memory/ram_freq When overclocking the GPU, it is a good idea to also overclock the DRAM, as the main bottleneck of the A64 SOC is the memory. The A64’s maximum ram clockspeed falls just short of 667MHz. This may be unstable on your device however.\nAround 600 MHz (PC-1200) should work fine, however some people have reported instability at lower clockspeeds. Arch Linux Arm uses a default clockspeed of 552MHz, with U-Boot builds available to easily switch out for a higher (624) or lower (492) DRAM clockspeed.\nIt is possible that by reverse engineering the DRAM driver from Allwinner that auto tuning can be accomplished to get the best performance.\nSetting the DRAM clock is accomplished by modifying pinephone_defconfig in U-Boot (https://gitlab.com/pine64-org/u-boot/-/blob/crust/configs/pinephone_defconfig)\nYou can find simple instructions on doing so here: U-Boot\nVPU In order to allocate more VRAM for the GPU you can add cma=256 to your kernel (or use kconfig with CONFIG_CMA_SIZE_MBYTES=256) cmdline in boot.scr which you will have to compile using mkimage. By default the kernel allocates only 64MB, and the maximum value is 256MB.\nIn order to compile boot.scr you can run mkimage -C none -A arm64 -T script -d boot.cmd boot.scr\nImportant You may not have a boot.cmd file in your boot directory and instead you may instead have a boot.txt Cedrus Overclocking cedrus is achieved by modifying the kernel source code: https://elixir.bootlin.com/linux/latest/source/drivers/staging/media/sunxi/cedrus/cedrus.c#L507\nImportant User 33yn2 is not particularly sure if this makes any difference, or if it might in fact have a negative impact. Probably not worth messing with. RK3399-based devices The RK3399 clocks are found in arch/arm64/boot/dts/rockchip/rk3399-opp.dtsi\nMore optimised voltages and clocks can be found in arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi These include a slight overclock and undervolt, they are intended for the OP1 CPU found in many Chromebooks but have worked fine in all recorded cases on regular RK3399 SoCs in other devices.\nGPU Any clock speeds can be added for the GPU in gpu_opp_table\nThe highest recommended voltage for the GPU is 1.2V as specified in the RK3399 schematic from Rockchip.\nSegfault has found that the RK3399 in his Pinebook Pro can reach 950MHz on the GPU while being stable.\nThe stock speed for the GPU is 800Mhz.\nNote that the GPU in the RK3399 is already bottlenecked by the memory bandwidth available to it, so overclocking generally yields no improvements.\nCPU A set of available clock speeds that can be added to the CPU clusters can be found in drivers/clk/rockchip/clk-rk3399.c under rk3399_cpuclkl_rates for the little cores and rk3399_cpuclkb_rates for the big cores.\nThese clock speeds can be added to cluster0_opp for the small cores and cluster1_opp for the big cores respectively.\nThe maximum limit is 1.8GHz on the little cores and 2.2GHz on the big cores.\nThe highest recommended voltage for the little cores is 1.2V and for the big cores is 1.25V.\nSegfault has found that the RK3399 in his Pinebook Pro can reach 1.7GHz on the little cores and 2.08GHz on the big ones.\nThe stock speed for the little cores is 1.4GHz and on the big cores it is 1.8GHz, the OP1 speeds default to 1.5GHz and 2.0GHz instead.\nROCK64 DTB is in /boot/dtbs/rockchip/rk3328-rock64.dtb. CPU clock rates are inside opp_table0 as hexadecimal numbers in the opp-hz field.\nCheck the achieved clock speed with sudo cat /sys/kernel/debug/clk/clk_summary | grep armclk.\nThanks to Ayufan\u0026rsquo;s work (with their overclocking recipe), we know we can add a 1.392GHz operating point, and a 1.512GHz operating point (you should ensure you have a large heatsink for this last one). You can do so by adding the following in the opp_table0 object, after the opp-1296000000 operating point:\nopp-1392000000 { opp-hz = \u0026lt;0x00 0x52f83c00\u0026gt;; opp-microvolt = \u0026lt;0x149970\u0026gt;; clock-latency-ns = \u0026lt;0x9c40\u0026gt;; }; opp-1512000000 { opp-hz = \u0026lt;0x00 0x5a1f4a00\u0026gt;; opp-microvolt = \u0026lt;0x162010\u0026gt;; clock-latency-ns = \u0026lt;0x9c40\u0026gt;; }; GPU needs investigating, but current mainline device tree does not try to clock up the GPU at all.\n","permalink":"/documentation/General/Overclocking/","tags":null,"title":"Overclocking"},{"categories":["SBCs"],"contents":" An Ox, no bull The Ox64 Single Board Computer features a Bouffalo Lab BL808 RISC-V SoC with single 64-bit 480MHz RV64 C906 core and two 32-bit 320MHz RV32 E907 + 150MHz E902 cores, 728KB internal SRAM and 64MB internal PSRAM.\nStores Global Global: Accessories Affiliates Documentation Ox64 Schematics and certifications ","permalink":"/devices/ox64/","tags":null,"title":"Ox64"},{"categories":null,"contents":" The Ox64 is a RISC-V based single-board computer based on the Bouffalo Lab BL808 RISC-V SoC with C906 64-bit and E907/E902 32-bit CPU cores supported by 64 MB of embedded PSRAM memory, and with built-in WiFi, Bluetooth and Zigbee radio interfaces. The Ox64 comes in a breadboard-friendly form-factor, has a microSD card slot, a USB 2.0 Type-C port, and many other peripheral interfaces for makers to integrate with sensors and other devices.\nThe Ox64\nPinout of the production version\nFeatures Network 2.4 GHz 1T1R WiFi 802.11 b/g/n Bluetooth 5.2 Zigbee 10/100 Mbit/s Ethernet (optional, on expansion board) Storage On-board 16 Mbit (2 MB) or 128 Mbit (16 MB) XSPI NOR flash memory MicroSD - supports SDHC and SDXC (only on the 128 Mb version) Expansion Ports USB 2.0 OTG port 26 GPIO pins, including SPI, I2C and UART functionality, possible I2S and GMII expansion Dual-lane MiPi CSI port, located at USB-C port, for camera module Audio Microphone (optional, on the camera module) Speaker (optional, on the camera module) Software Releases\nBuilding\nFlashing\nReleases Quick Links to the Source of OS Images Build There is a community effort to bring updated kernels, peripherals and buildroot - Lots of communication happening in the #ox64-nutcracker channel.\nbuildroot bringing all the work below together with a bootable kernel and updated filesystem images for SD cards U-Boot and OpenSBI work by Smauel Kernel IRQChip, SDCard, and (WIP) USB by arm000, Alexander Horner and others OpenBouffalo Firmware low_load drivers by Fishwaldo and others Original Linux Images provided by Bouffalo - Very basic alpha build which are only fit for board bring up and testing purposes.\nLinux for BL808 Installation Instructions for Linux on BL808 (Chinese) Installation Instructions for Linux on BL808 (machine-translated to English) Toolchain:\nelf_newlib_toolchain/bin/riscv64-unknown-elf-gcc (Xuantie-900 elf newlib gcc Toolchain V2.2.5 B-20220323) 10.2.0 linux_toolchain/bin/riscv64-unknown-linux-gnu-gcc (Xuantie-900 linux-5.10.4 glibc gcc Toolchain V2.2.4 B-20211227) 10.2.0 cmake version 3.19.3 Software Development Kits BL808 MCU SDK BLDevCube Flashing Tool for Windows, macOS and Ubuntu x64 Ox64 UART Flashing Guide, see the notes BL808 Demo Firmware: bl808_demo_event.bin, see the notes BL808 UART Log Firmware: whole_flash_data.bin, see the notes BL808 DVK Quick Start OpenSBI for BL808 Rust Peripheral Access Crate (PAC) for BL808 System View Description (SVD) for BL808 Building Start the building process cloning both the upstream Buildroot repository and the Buildroot Bouffalo overlay repository:\n$ mkdir -p ~/ox64 $ cd ~/ox64 $ git clone https://github.com/buildroot/buildroot $ git clone https://github.com/openbouffalo/buildroot_bouffalo Define an environment variable for the Buildroot Bouffalo overlay path:\n$ export BR_BOUFFALO_OVERLAY_PATH=$(pwd)/buildroot_bouffalo Change directory into the cloned Buildroot folder:\n$ cd ~/ox64/buildroot Apply the default configuration for Pine64 Ox64:\n$ make BR2_EXTERNAL=$BR_BOUFFALO_OVERLAY_PATH pine64_ox64_defconfig Use the menuconfig tool to adjust the build settings:\n$ make menuconfig Within menuconfig, configure the following:\nSelect Target Options Enable Integer Multiplication and Division (M) Enable Atomic Instructions (A) using space key Enable Single-precision Floating-point (F) Enable Double-precision Floating-point (D) Select Target ABI, set it to lp64d and press Exit Select Toolchain, enable Fortran support, enable OpenMP support, and Save \u0026amp; Exit Initiate the build process, but first make sure that your PATH variable contains no spaces. For Arch Linux distribution you may also need to install extra-packages with sudo pacman -S cpio rsync bc.\n$ make Buildroot will output the needed files to the ~/ox64/buildroot/output/images directory in about 1 hour, according to your computer processing resources and internet connection speed.\nFlashing This page explains how to flash an Ox64 board and a microSD card to boot the system. You will need a Linux computer, a serial UART adapter, the Ox64 board, and a microSD card.\nPrepare images for flashing Download the Ox64 images from the latest OpenBouffalo release. You may skip this step if you built your own images as per the instructions in the Building page.\n$ mkdir -p ~/ox64/openbouffalo $ cd ~/ox64/openbouffalo $ wget https://github.com/openbouffalo/buildroot_bouffalo/releases/download/v1.0.1/bl808-linux-pine64_ox64_full_defconfig.tar.gz $ tar -xvzf bl808-linux-pine64_ox64_full_defconfig.tar.gz $ cd ~/ox64/openbouffalo/firmware $ xz -v -d -k sdcard-pine64_ox64_full_defconfig.img.xz $ mv sdcard-pine64_ox64_full_defconfig.img sdcard.img Optional: create a combined SoC image Use the following commands to combine m0_lowload_bl808_m0.bin, d0_lowload_bl808_d0.bin, and bl808-firmware.bin into a single image. This is mainly useful for troubleshooting (e. g. when using DevCube v1.8.4 or later).\n$ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images $ fallocate -l 0x800000 bl808-combined.bin $ dd conv=notrunc if=m0_lowload_bl808_m0.bin of=bl808-combined.bin $ dd conv=notrunc if=d0_lowload_bl808_d0.bin of=bl808-combined.bin seek=$((0x100000))B $ cat bl808-firmware.bin \u0026gt;\u0026gt; bl808-combined.bin Check that you have the required files for flashing $ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images $ ls -1 *808*.bin *.img Expected files:\nbl808-combined.bin \u0026ndash; If you created the combined image. bl808-firmware.bin \u0026ndash; OpenSBI and UBoot DTB files. Runs on the D0 core. d0_lowload_bl808_d0.bin \u0026ndash; Startup code for the D0 core. m0_lowload_bl808_m0.bin \u0026ndash; Startup code for the M0 core. sdcard.img \u0026ndash; Kernel and root filesystem. Runs on the D0 core. Set up your UART adapter In this section we will configure and wire up a UART adapter in order to flash the Ox64. Choose one of the options below based on the hardware available to you; the first two are the most convenient since they minimize the number of times you will need to swap electrical connections.\nOption 1: Raspberry Pi Pico First, download the Raspberry Pi Pico firmware that allows it to act as a serial UART adapter:\n$ mkdir -p ~/ox64/pico $ cd ~/ox64/pico $ wget https://github.com/Kris-Sekula/Pine64_Ox64_SBC/raw/main/uart/picoprobe.uf2 Put the Raspberry Pi Pico board into programming mode:\nPress the BootSel button Apply power by plugging the USB cable to PC Release the BootSel button Note As an alternative to pressing the BootSel button, you can also connect the probe point TP6 (located on the bottom of the Pico board) to any ground point (e. g. pin 28). The Pico will now appear as a USB mass storage device. Copy the UF2 file to program it:\n$ cp ~/ox64/pico/picoprobe.uf2 /media/\u0026lt;user\u0026gt;/RPI-RP2 Next, connect the Ox64 board to the Pico according to the following wiring diagram:\nOx64 PI PICO /dev/tty uart0_Tx_GPIO14_pin1 uart0_Rx_pin17 ACM1 for flashing uart0_Rx_GPIO15_pin2 uart0_Tx_pin16 ACM1 for flashing Rxd_GPIO17_pin31 uart1_Tx_pin6 ACM0 for serial console Txd_GPIO16_pin32 uart1_Rx_pin7 ACM0 for serial console gnd_pin38 gnd_pin38/3 vbus5v_pin40 vbus5v_pin40 With the Pico flashed and wired as per the instructions above, we have access to two of the Ox64’s UART ports at the same time. This configuration eliminates the need to switch the physical connections for flashing or testing the system.\nReconnect the Pico to your computer’s USB port and verify that we have access to all the serial ports we need:\n$ ls /dev/ttyACM* Expected result:\n/dev/ttyACM0 connects to the D0 core’s (i.e. Linux’s) serial console /dev/ttyACM1 is used for flashing (but also connects to the M0 core’s serial console) Option 2: STM32 Bluepill The Bluepill is an affordable STM32 development board, based on the STM32F103C8T6 chip. We can program it to act as a USB serial adapter, just like we did with the Raspberry Pi Pico.\nNote The one catch is that you already need a serial adapter in order to program your Bluepill board. The good news is that you serial adapter does not have to be one from from the Compatible UARTs list. These programming instructions have been tested with a FT232RL adapter (which, notably, is listed as not supported on that list).\nIf you own an SWD-capable debugger (ST-Link, J-link, etc.) you can use that for programming the Bluepill as well, although instead of stm32flash console command you would be using openocd or other suitable software.\nWarning Your serial adapter must use 3.3V logic levels. Install software to flash Bluepill. For Debian-based systems just install package from repository:\n$ sudo apt install stm32flash For Arch Linux systems, use the AUR repository:\n$ mkdir -p ~/ox64/bluepill $ cd ~/ox64/bluepill $ git clone https://aur.archlinux.org/stm32flash.git $ cd ~/ox64/bluepill/stm32flash $ makepkg -si Download the Bluepill Serial Monster firmware:\n$ mkdir -p ~/ox64/bluepill $ cd ~/ox64/bluepill $ wget https://github.com/r2axz/bluepill-serial-monster/releases/download/v2.6.4/bluepill-serial-monster.hex Put the Bluepill into programming mode:\nSet boot jumpers for booting from rom: Boot0=1, Boot1=0. Connect it to a USB-Serial adapter with A9 to Rx, A10 to Tx, GND to GND, 3v3 to Vcc. Apply power by plugging the USB cable to PC. Press the Reset button. Find your USB serial adapter’s device path with ls /dev/ttyUSB* /dev/ttyACM* (or similar); for the rest of this section we will refer to it as /dev/tty[DEVICE]. Upload the firmware:\n$ cd ~/ox64/bluepill $ sudo stm32flash -w bluepill-serial-monster.hex /dev/tty[DEVICE] After upload, set boot jumpers for boot from flash: Boot0=0, Boot1=0. Disconnect the USB serial adapter from both the PC and Bluepill board.\nNext, connect the Ox64 board to the Bluepill according to the following wiring diagram:\nOx64 Bluepill /dev/tty uart0_Tx_GPIO14_pin1 uart0_Rx_A3 ACM1 for flashing uart0_Rx_GPIO15_pin2 uart0_Tx_A2 ACM1 for flashing Rxd_GPIO17_pin31 uart1_Tx_A9 ACM0 for serial console Txd_GPIO16_pin32 uart1_Rx_A10 ACM0 for serial console gnd_pin38 GND vbus5v_pin40 5V With the Bluepill flashed and wired as per the instructions above, we have access to two of the Ox64’s UART connections at the same time. This configuration eliminates the need to switch the physical connections for flashing or testing the system.\nConnect the Bluepill to your computer’s USB port and verify that we have access to all the serial ports we need:\n$ ls /dev/ttyACM* Expected result:\n/dev/ttyACM0 connects to the D0 core’s (i.e. Linux’s) serial console /dev/ttyACM1 is used for flashing (but also connects to the M0 core’s serial console) /dev/ttyACM2 (unused) Option 3: Generic UART adapter Ox64 pinout\nCheck that your serial adapter is on the Compatible UARTs list. You will (most likely) only have one serial interface available to you; unlike the previous options you will be using this same serial interface for both flashing and testing the system.\nFind its device path with ls /dev/ttyUSB* /dev/ttyACM* (or similar); for the rest of this section we will refer to it as /dev/tty[DEVICE].\nYou will also need a way of powering your Ox64. If your serial adapter has a 5V line, you can connect it to VBUS (pin 40). Otherwise, you can connect either the micro-B or the USB-C port on the Ox64 to any 5V power supply.\nWarning Your serial adapter must use 3.3V logic levels. Refer to the pinout image below. Connect your UART adapter as follows:\nRX -\u0026gt; UART0_TX / GPIO14 / pin 1 TX -\u0026gt; UART0_RX / GPIO15 / pin 2 GND -\u0026gt; any ground (e. g. pin 3) Proceed with the instructions in the sections that follow, up to and including flashing_the_ox64 and flashing_the_microsd_card, but replace all occurrences of /dev/ttyACM1 with /dev/tty[DEVICE].\nNext, power off the Ox64 and re-connect your UART adapter as follows:\nRX -\u0026gt; TXD / GPIO16 / pin 32 TX -\u0026gt; RXD / GPIO17 / pin 31 GND -\u0026gt; any ground (e. g. pin 33) Then, follow the instructions in booting_for_the_first_time, but replace all occurrences of /dev/ttyACM0 with /dev/tty[DEVICE]. You should then have a working Linux system.\nDownload flashing tools You have a choice of flashing software:\nDevCube: Bouffalo\u0026rsquo;s GUI-based closed source flashing tool bflb-iot-tool: Bouffalo\u0026rsquo;s command line open source flashing tool Blisp: Third party command line open source flashing tool Installation: DevCube Download the latest DevCube flashing tool from BouffaloLab’s website:\n$ mkdir -p ~/ox64/devcube $ cd ~/ox64/devcube $ wget https://dev.bouffalolab.com/media/upload/download/BouffaloLabDevCube-v1.8.9.zip $ unzip BouffaloLabDevCube-v1.8.9.zip $ chmod u+x BLDevCube-ubuntu If you did not create a combined image you may need an older version of the DevCube. In that case, download v1.8.3 from one of the mirrors below:\nhttps://openbouffalo.org/static-assets/bldevcube/BouffaloLabDevCube-v1.8.3.zip https://hachyderm.io/@mkroman/110787218805897192 \u0026gt; https://pub.rwx.im/~mk/bouffalolab/BouffaloLabDevCube-v1.8.3.zip https://we.tl/t-eJWShQJ4iF Verify that your copy of BouffaloLabDevCube-v1.8.3.zip matches the hashes below:\nSHA1: 0f2619e87d946f936f63ae97b0efd674357b1166 SHA256: e6e6db316359da40d29971a1889d41c9e97d5b1ff1a8636e9e6960b6ff960913 Installation: bflb-iot-tool Install bflb-iot-tool using your preferred method of managing PIP packages. One option is to set up a Python virtual environment as follows:\n$ sudo apt install pipenv # for Debian-based systems # or $ sudo pacman -S python-pipenv # for Arch Linux systems $ cd ~/ox64/ $ pipenv install setuptools # install prerequisite of CLI flash tool $ pipenv install bflb-iot-tool # install CLI flash tool $ pipenv shell # activate virtual environment $ # bflb-iot-tool --help # return info about the tool Note Each time you open a new terminal window you will need to cd ~/ox64/ and re-run pipenv shell to reactivate the virtual environment. Installation: Blisp At the time of writing, only the development version of Blisp supports flashing the Ox64. You can compile it from source as follows:\n$ sudo apt install cmake # for Debian-based systems # or $ sudo pacman -S cmake # for Arch Linux systems $ cd ~/ox64 $ git clone --recursive https://github.com/pine64/blisp.git $ cd blisp $ git submodule update --init --recursive $ mkdir build \u0026amp;\u0026amp; cd build $ cmake -DBLISP_BUILD_CLI=ON .. $ cmake --build . $ export PATH=$HOME/ox64/blisp/build/tools/blisp:$PATH Note Each time you open a new terminal window you will need to re-run the export PATH=... command above to ensure that the blisp executable remains in your PATH. Full instructions are available in Blisp\u0026rsquo;s README.\nFlashing the Ox64 Put the Ox64 into programming mode:\nPress the BOOT button Apply power or re-plug the USB cable Release the BOOT button If you are using any of the command line flashing utilities (i.e. blisp or bflb-iot-tool), set up the following environment variables:\n$ PORT=/dev/ttyACM1 $ BAUD=230400 # safe value for macOS, set to 2000000 for faster flashing on Linux And change directory to the location of your firmware images:\n$ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images Flashing method: bflb-iot-tool Flash the Ox64. If you created a combined image then run the command below:\n$ bflb-iot-tool --chipname bl808 --interface uart --port $PORT --baudrate $BAUD \\ \u0026gt; --addr 0x0 --firmware bl808-combined.bin --single Otherwise, run the following commands:\n$ bflb-iot-tool --chipname bl808 --interface uart --port $PORT --baudrate $BAUD \\ \u0026gt; --addr 0x0 --firmware m0_lowload_bl808_m0.bin --single $ bflb-iot-tool --chipname bl808 --interface uart --port $PORT --baudrate $BAUD \\ \u0026gt; --addr 0x100000 --firmware d0_lowload_bl808_d0.bin --single $ bflb-iot-tool --chipname bl808 --interface uart --port $PORT --baudrate $BAUD \\ \u0026gt; --addr 0x800000 --firmware bl808-firmware.bin --single If you get permission errors when running any of the commands above, run ls -l /dev/tty[DEVICE], to find out which group is allowed to talk to serial ports and add your user to that group, with sudo usermod -a -G [GROUP] $USER (i.e. dialout for Debian or uucp for Arch Linux). Make sure you re-login. Running the commands as root is not recommended since this will make bflb-iot-tool create root-owned files in your home directory. You can now run exit from virtual environment.\nFlashing method: Blisp Flash the Ox64. If you created a combined image then run the command below:\n$ blisp iot --chip=bl808 --port=$PORT --baudrate=$BAUD \\ \u0026gt; --single-down-loc 0x0 --single-down bl808-combined.bin Otherwise, run the following commands:\n$ blisp iot --chip=bl808 --port=$PORT --baudrate=$BAUD \\ \u0026gt; --single-down-loc 0x0 --single-down m0_lowload_bl808_m0.bin $ blisp iot --chip=bl808 --port=$PORT --baudrate=$BAUD \\ \u0026gt; --single-down-loc 0x100000 --single-down d0_lowload_bl808_d0.bin $ blisp iot --chip=bl808 --port=$PORT --baudrate=$BAUD \\ \u0026gt; --single-down-loc 0x800000 --single-down bl808-firmware.bin Flashing method: DevCube Open a new terminal window to run the DevCube flasher:\n$ cd ~/ox64/devcube $ ./BLDevCube-ubuntu Select chip [BL808], press Finish, and configure BOTH the [MCU] and [IOT] tabs as follows. When you switch between tabs double check that they still match the settings below:\nInterface UART Port/SN /dev/ttyACM1 UART rate 230400 (safe value for macOS, set to 2000000 for faster flashing on Linux) If you created a combined image then you only need to use the [IOT] tab:\nEnable \u0026lsquo;Single Download\u0026rsquo; Image Address [0x0], [PATH to bl808-combined.bin] Click \u0026lsquo;Create \u0026amp; Download\u0026rsquo; and wait until it’s done Close DevCube Otherwise, start in the [MCU] tab:\nM0 Group[group0], Image Address [0x58000000], [PATH to m0_lowload_bl808_m0.bin] D0 Group[group0], Image Address [0x58100000], [PATH to d0_lowload_bl808_d0.bin] Click \u0026lsquo;Create \u0026amp; Download\u0026rsquo; and wait until it’s done Then, switch to the [IOT] tab:\nEnable \u0026lsquo;Single Download\u0026rsquo; Image Address [0x800000], [PATH to bl808-firmware.bin] Click \u0026lsquo;Create \u0026amp; Download\u0026rsquo; again and wait until it’s done Close DevCube Erasing the microSD card Make sure there are no signatures or partitions left, and overwrite the first sectors with zeroes. You can find the target device under lsblk command.\n$ sudo wipefs /dev/[DEVICE] $ sudo wipefs --all --force /dev/[DEVICE]* $ sudo dd if=/dev/zero of=/dev/[DEVICE] status=progress bs=32768 count=1 Optionally you can zeroes the whole device:\n$ sudo dd if=/dev/zero of=/dev/[DEVICE] status=progress bs=32768 count=$(expr $(lsblk -bno SIZE /dev/[DEVICE] | head -1) \\/ 32768) Flashing the microSD card Insert the microSD card into your PC, locate its device under lsblk and write the image:\n$ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images $ sudo dd if=sdcard.img of=/dev/[DEVICE] bs=1M status=progress conv=fsync Booting for the first time Power off your Ox64 and insert the microSD card.\nOpen a terminal window to connect to the D0 core’s (i.e. Linux’s) serial console:\n$ minicom -b 2000000 -D /dev/ttyACM0 If you are using a Pico or Bluepill as your serial adapter, open another terminal window to to monitor the M0 core’s serial console (reminder: /dev/ttyACM1 is the same port we previously used for flashing):\n$ minicom -b 2000000 -D /dev/ttyACM1 Re-apply power to the Ox64.\nOn the main/D0 console (/dev/ttyACM0) you will see Linux booting up. When prompted, log in as root with no password. In case the SD card is missing or empty, you’ll get a Card did not respond to voltage select! : -110 error.\nOn the M0 console (/dev/ttyACM1) you’ll see following messages until the sytem is fully loaded:\n[I][MBOX] Mailbox IRQ Stats: [I][MBOX] Peripheral SDH (33): 0 [I][MBOX] Peripheral GPIO (60): 0 [I][MBOX] Unhandled Interupts: 0 Unhandled Signals 0 Once the system is running, the \u0026ldquo;MBOX\u0026rdquo; logs will abruptly disappear and you’ll be able to manage the M0 multimedia core, i.e. wifi settings, etc. When prompted, type help to see available commands.\nConnecting the Ox64 to your WiFi network The simplest way to connect is to run the following command from the Linux console (i.e. /dev/ttyACM0):\n$ blctl connect_ap \u0026lt;YourSSID\u0026gt; \u0026lt;YourPassword\u0026gt; Wait for it to connect (if you’re monitoring the M0 console on /dev/ttyACM1 it should tell you when it’s done), then run the following command from the Linux console:\n$ udhcpc -i bleth0 Unfortunately the WiFi range leaves something to be desired. When you are performing the procedure above for the first time, move the Ox64 right next to your router. Once you are successfully connected, you can try experimenting with the maximum range.\nFor more information on using the blctl command, see here.\nAppendix Adding Nuttx RTOS In this section, we will set up our Ox64 to dual-boot both Linux and the NuttX real-time operating system. For more information see the official documentation.\nFirst, write the normal Linux image to the SD card if you have not done so already. You can find the correct device under lsblk:\n$ cd ~/ox64/openbouffalo/firmware # if you downloaded pre-built images # or $ cd ~/ox64/buildroot/output/images # if you built your own images $ sudo dd if=/sdcard.img of=/dev/[DEVICE] bs=1M conv=fsync status=progress Run the following command to re-read the partition tables. Re-inserting the SD card works too:\n$ sudo blockdev --rereadpt /dev/[DEVICE] Download the NuttX image:\n$ mkdir -p ~/ox64/nuttx $ cd ~/ox64/nuttx $ wget -O ImageNuttx https://github.com/lupyuen2/wip-pinephone-nuttx/releases/download/bl808d-1/Image Mount the boot partition and make the required modifications:\n$ sudo mount /dev/[DEVICE]2 /mnt $ sudo cp ImageNuttx /mnt/ $ sudo tee -a /mnt/extlinux/extlinux.conf \u0026lt;\u0026lt;EOF LABEL PINE64 OX64 Nuttx KERNEL ../ImageNuttx FDT ../bl808-pine64-ox64.dtb EOF $ sudo umount /mnt Mount the rootfs and make the required modifications:\n$ sudo mount /dev/[DEVICE]3 /mnt $ sudo cp ImageNuttx /mnt/boot/ $ sudo tee -a /mnt/boot/extlinux/extlinux.conf \u0026lt;\u0026lt;EOF LABEL PINE64 OX64 Nuttx KERNEL ../ImageNuttx FDT ../bl808-pine64-ox64.dtb EOF $ sudo umount /mnt Enjoy your new Nuttx booting option!\nDevelopment Efforts Ox64 boots Linux successfully Brennan Ashton is porting Apache NuttX RTOS and OpenAMP (Asymmetric Multiprocessing) to BL808 Phone Concept for BL808 Further information Compatible UARTs\nDatasheets\nResources\nSchematics and certifications\nSoC and Memory Specification\nCompatible UARTs When the Ox64 is in bootloader mode, some UARTs are unable to communicate with it. When this is the case, utilities such as BLDevCube are unable to actually program the device. If you see \u0026ldquo;Shake hand fail\u0026rdquo; and an empty ack, and your device is in bootloader mode, then it is likely an incompatible UART.\nThe below devices have been tested and verified as working:\nRaspberry Pi Pico - running the following UART firmware (GP4 and GP5 are used for port 0, GP12 and GP13 for port 1) Compiled binary for Pi Pico and connectivity diagram is here ESP32 with CP210x - bridge the EN pin to ground to disable the ESP32 itself, and then connect the TX on the esp32 to 14 on the Ox64 and RX to pin 15. Note that only baud rate 115200 works, and this doesn’t seem to work for everyone) Stand-alone CP2102 dongle works at 115200 baud. Brand used was HiLetgo. STM32F401 BlackPill - running the Black Magic Debug firmware STM32F103C8T6 BluePill - running Black Magic Debug. STM32F103C8T6 BluePill - running BluePill Serial Monster Some UART adapters based on the FT232H (note that the FT232RL does not work, and neither does the Pine 64 JTAG) Some CH340G based adapters work and some don’t. Datasheets Bouffalo BL808 SoC information:\nBouffalo Lab BL808 SoC Datasheet Bouffalo Lab BL808 SoC Reference Manual SPI NOR Flash information:\nGigaDevice 16Mb XSPI-Flash Datasheet GigaDevice 128Mb XSPI-Flash Datasheet Winbond 128Mb QSPI-Flash Datasheet (W25Q128JWSQ) Power Regulator information:\nInnovation Analog Tech IA2014 Step_down Converter Datasheet MicroSD socket information:\nPush type microSD socket specification Resources Ox64 SBC - Connecting, Flashing and Booting Linux! ($8 from Pine64): A short video on how to connect to the Ox64, flash and boot #24.5 Ox64 Pine64 $8 Risc-V SBC - Programming and Booting Linux: Another video that covers soldering pins, connecting via Pi Pico and flashing Linux and U-Boot First batch of Ox64 won’t appear as USB serial port First batch of Ox64 tested OK with CH340C/G [https://www.robertlipe.com/bl808-not-symmetric/(First thoughts on the (a)symmetry of Bouffalo Labs BL808 as in Pine64 Ox64) The $8 linux computer (with picoprobe-rp2040 programming instructions) Building the Xuantie GNU Toolchain for Ox64 on macOS and Apple Silicon Ox64 BL808 RISC-V SBC articles by Lup Yuen LEE:\nBooting Linux and (maybe) Apache NuttX RTOS Starting Apache NuttX real-time operating system Sv39 Memory Management Unit NuttX Apps and Initial RAM Disk UART Interrupt and Platform-Level Interrupt Controller (PLIC) Fixing the UART Interrupt and Platform-Level Interrupt Controller $8 RISC-V SBC on a Real-Time Operating System: Ox64 + NuttX Nim on a Real-Time Operating System: Apache NuttX RTOS + Ox64 BL808 SBC Emulate Ox64 BL808 in the Web Browser: Experiments with TinyEMU RISC-V Emulator and Apache NuttX RTOS Automated Testing with Ox64 BL808 Emulator (Apache NuttX RTOS) QuickJS JavaScript Engine on a Real-Time Operating System (Apache NuttX RTOS) Coding Ox64 BL808 SBC the Drag-n-Drop Way Rust Apps on Ox64 BL808 RISC-V SBC and Apache NuttX RTOS Adventures of Ox64 BL808 RISC-V SBC with Apache NuttX RTOS Git repositories:\nOfficial Bouffalo BL-808 site Community made Arduino Core specifically for the Bouffalo Labs BL808 RISC-V MCU (initial development has been postponed until further notice.) Schematics and certifications Pinout for wiring ethernet PHY to EMAC\nBaseboard dimensions: 51 mm x 21 mm x 19 mm x 3.5 mm (breadboard-friendly) Input power: 5 V, 0.5 A through the microUSB or USB-C ports Production version schematic:\nOx64 Schematic 20221018 v1.1 Ox64 PCB Component placement(ToP) 20221018 v1.1 Ox64 PCB Component placement(Bottom) 20221018 v1.1 Prototype (dispatched to developers) schematic:\nOx64 Schematic 20221007 v1.0 Ox64 PCB Component placement(ToP) 20221007 v1.0 Ox64 PCB Component placement(Bottom) 20221007 v1.0 Certifications:\nNot available yet SoC and Memory Specification Based on the Bouffalo Lab BL808\nCPU Architecture XuanTie C906 480 MHz 64-bit RISC-V CPU:\nSupports RISC-V RV64IMAFCV instruction architecture Five-stage single-issue sequentially executed pipeline Level-1 instruction and data cache of Harvard architecture, with a size of 32 KB and a cache line of 64B Sv39 memory management unit, realizing the conversion of virtual and real addresses and memory management jTLB that supports 128 entries Supports AXI 4.0 128-bit master interface Supports core local interrupt (CLINT) and platform-level interrupt controller (PLIC) With 80 external interrupt sources, 3 bits for configuring interrupt priority Supports BHT (8K) and BTB Compatible with RISC-V PMP, 8 configurable areas Supports hardware performance monitor (HPM) units See here XuanTie E907 320 MHz 32-bit RISC-V CPU:\nSupports RISC-V RV32IMAFCP instruction set Supports RISC-V 32-bit/16-bit mixed instruction set Supports RISC-V machine mode and user mode Thirty-two 32-bit integer general purpose registers (GPR) and thirty-two 32-bit/64-bit floating-point GPRs Integer (5-stage)/floating-point (7-stage), single-issue, sequentially executed pipeline Supports AXI 4.0 main device interface and AHB 5.0 peripheral interface 32K instruction cache, two-way set associative structure 16K data cache, two-way set associative structure See here XuanTie E902 150 MHz 32-bit RISC-V CPU:\nSee here System Memory Embedded 64MB PSRAM ","permalink":"/documentation/Ox64/_full/","tags":null,"title":"Ox64 (Single Page)"},{"categories":["SBCs"],"contents":" The Oz64 The Oz64 is a low cost single-board computer based on the Sophgo SG2000 SoC with dual T-Head C906 64-bit RISC-V cores, an ARM Cortex A53 64-bit RISC CPU core and an 8051 8-bit core supported by 512 MB of embedded DRAM memory, with WiFi and Bluetooth radio interfaces.\nThe Oz64 SBC comes in a model-B form-factor, has a microSD card slot, an eMMC plugin connector, an USB 2.0 Type-A host port, and many other peripheral interfaces for makers to integrate with sensors and other devices.\nFeatures and Specifications I/O Interface UART\nI2C\nSPI\nI2S Camera and display interface MIPI-CSI 2 lanes\nMIPI-DSI 2 lanes Communication 2.4GHz 1T1R Wifi 6\nBLE 5.2\n10/100Mbps Ethernet Expansion 40 pins Breadboard friendly form factor Package contents Oz64 board Stores Global Global: Accessories Affiliates Documentation Oz64 ","permalink":"/devices/oz64/","tags":null,"title":"Oz64"},{"categories":null,"contents":" The Oz64 is a low cost single-board computer based on the Sophgo SG2000 SoC with dual T-Head C906 64-bit RISC-V cores, an ARM Cortex A53 64-bit RISC CPU core and an 8051 8-bit core supported by 512 MB of embedded DRAM memory, with WiFi and Bluetooth radio interfaces.\nThe Oz64 SBC comes in a model-B form-factor, has a microSD card slot, an eMMC plugin connector, an USB 2.0 Type-A host port, and many other peripheral interfaces for makers to integrate with sensors and other devices.\nThe Oz64\nFeatures Board dimension Board Dimensions: 85mm x 56mm x 18.8mm, see the model-B board dimension drawing\nThe Oz64 3D model\nNetwork 2.4 GHz 1T1R Wi-Fi 6 Bluetooth 5.2 10/100 Mbit/s Ethernet with optional PoE capability Storage On-board eMMC module socket MicroSD, supports SDHC and SDXC Expansion ports USB 2.0 Host port 26 GPIO pins, including SPI, I^2^C and UART functionality 2x Dual-lane MiPi CSI port Optional dual-lane MiPi DSI port Input power Input Power: +5V @2A with 3.5mm/1.35mm Type H Barrel type DC connector (@1.5A will work if there is no heavy load on the USB 2.0 port)\nSoC and Memory Specification Based on the Sophgo SG-200x\nSG2000 block diagram\nCPU Architecture T-Head C906 1GHz MHz 64-bit RISC-V CPU:\nSupports RISC-V RV64IMAFCV instruction architecture Five-stage single-issue sequentially executed pipeline Level-1 instruction and data cache of Harvard architecture, with a size of 32 KB and a cache line of 64KB Level-2 128KB cache Sv39 memory management unit, realizing the conversion of virtual and real addresses and memory management jTLB that supports 128 entries Supports AXI 4.0 128-bit master interface Supports core local interrupt (CLINT) and platform-level interrupt controller (PLIC) With 80 external interrupt sources, 3 bits for configuring interrupt priority Supports BHT (8K) and BTB Compatible with RISC-V PMP, 8 configurable areas Supports hardware performance monitor (HPM) units See here T-Head C906 700Mhz MHz 64-bit RISC-V CPU:\nSupports RISC-V RV64IMAFCV instruction architecture Five-stage single-issue sequentially executed pipeline Level-1 instruction and data cache of Harvard architecture, with a size of 16 KB and a cache line of 16KB Sv39 memory management unit, realizing the conversion of virtual and real addresses and memory management jTLB that supports 128 entries Supports AXI 4.0 128-bit master interface Supports core local interrupt (CLINT) and platform-level interrupt controller (PLIC) With 80 external interrupt sources, 3 bits for configuring interrupt priority Supports BHT (8K) and BTB Compatible with RISC-V PMP, 8 configurable areas Supports hardware performance monitor (HPM) units See here ARM Cortex-A53 1GHz 64-bit RISC CPU:\nQuad-core Cortex-A53 up to 1.0GHz CPU Full implementation of the ARM architecture v8-A instruction set ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation ARMv8 Cryptography Extensions In-order pipeline with symmetric dual-issue of most instructions Unified system L2 128KB cache Includes VFP v3 hardware to support single and double-precision operations Integrated 32KB L1 instruction cache, 32KB 4-way set associative L1 data cache TrustZone technology support PD_A53: Cortex-A53 + Neon + FPU + L1 I/D Cache of core 2/3 8051 25-300MHz 8-bit CPU:\nIntegrated 8K SRAM System Memory SIP DRAM 512MB Releases Sources There is a community effort to bring updated kernels, peripherals and buildroot - Lots of communication happening in the #ox64-nutcracker channel, see Community.\nNuttx Released Image by Lup Yuen Toolchain:\nelf_newlib_toolchain/bin/riscv64-unknown-elf-gcc (Xuantie-900 elf newlib gcc Toolchain V2.2.5 B-20220323) 10.2.0 linux_toolchain/bin/riscv64-unknown-linux-gnu-gcc (Xuantie-900 linux-5.10.4 glibc gcc Toolchain V2.2.4 B-20211227) 10.2.0 cmake version 3.19.3 Software Development Kits SG200x NPU TDL SDK Fishwaldo SG200x Debian Lup Yuen Apache NuttX RTOS Building See Nuttx Build by Lup Yuen\nSchematics Pre-Production version schematic:\nOz64 Schematic 20240517 v1.0.0 Oz64 PCB Component placement(ToP) 20240517 v1.0.0 Oz64 PCB Component placement(Bottom) 20240517 v1.0.0 Certifications Disclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. Not yet available Datasheets Datasheets for Components and Peripherals Sophgo SG2000 SoC information:\nSophgo SG2000 SoC Technical Reference Manual Wi-Fi and Bluetooth information:\nAIC Semi AIC8800DC Datasheet Power Regulator information:\nEmpower ETA3414 1.5A 3MHz Step_down Converter Datasheet Empower ETA3418 2.5A 3MHz Step_down Converter Datasheet Empower ETA5050 500mA Low Noise, High PSRR, Fast Transient Response LDO Datasheet MicroSD socket information:\nPush type microSD socket specification ","permalink":"/documentation/Oz64/_full/","tags":null,"title":"Oz64 (Single Page)"},{"categories":null,"contents":"AOSC OS\nArmbian\nBatocera Linux\nDietPi\nHardenedBSD\nKDE Community\nKDE Neon\nelementary\nLakka\nLuneOS\nLibreELEC\nMaemo Leste\nManjaro\nMobian\nNEMS Linux\nNetBSD\nNextCloudPi\nNixOS\nOpenBSD\nOpenHAB\nOpen Media Vault\nPlasma Mobile\nPostmarketOS\nQ4OS\nRecalbox\nRetro Arena\nSailfishOS\nUBPorts Foundation\nVolumio\n","permalink":"/community/partner_projects/","tags":null,"title":"Partner projects"},{"categories":null,"contents":"None of us is as smart as all of us – Ken H. Blanchard\nAt the core of our philosophy is the notion that PINE64 is a community platform. A simplistic point of view, often offered up and referenced online, is that ‘PINE64 does hardware while the community does the software’. While this depiction is not inaccurate, it is also a gross oversimplification. The fact that PINE64 is community driven doesn’t simply entail a one-way reliance on the community or partner projects for software support; it means that the community gets to actively shape the devices, as well as the social platform, of PINE64 from the ground up. The goal is to deliver ARM64 devices that you really wish to engage with and a platform that you want to be a part of. As such, the community – PINE64 – and the Pine Store company are interlocked and intertwined, but separate entities.\nWhat does it mean in practice then? It means that we usually announce what we’re working on well ahead of the shipping date – many months before a device is released – so that you have plenty of time to request product features, suggest changes, ask for/make changes to documentation, etc. before the first iteration of the device rolls of the factory line. It also means that the hardware developments – successes and failures alike – are all in the open. You can follow the process on our forum, the IRC, Discord, Matrix, Telegram the online conversations log and, in some instances, on our partner projects forums. But it also means that anyone who is a part of the community gets to shape anything related to the PINE64 project – including the Wiki or this website – and so, software development is only one area where you can contribute your time and skill. In return for time investment, the community gets fair priced devices that developers wish to spend their time on.\nLast, but not least, is our belief in supporting existing SoCs for long periods of time as well as actively developing new devices based on those SOCs. What does this mean for developers then? It means that a developer can start developing software on a PINE64 SBC and, in time, support multiple devices with relative ease. This device convergence is, at the time of writing, most pronounced on the Allwinner A64 SOC used in a number of our devices including the: PINE64-LTS, SOPine, Pinebook and Pinetab. That said, similar convergence is also planned for the Rockchip RK3399, currently used on the RockPro64 and in the Pinebook Pro.\nYou can always find us in the chats or the forum, so if you have any further questions make sure to drop by and ask about how the PINE64 project actually works.\n","permalink":"/community/philosophy/","tags":null,"title":"Philosophy"},{"categories":null,"contents":" How to Create MicroSD Card Android Image for Pine A64 What do I need? The PhoenixCard software from Allwinner. You can download it here A firmware image (.img files) A SD-Card (best Class 10 with 8GB or more SD-Card) - backup everything first, the Card will be formatted! An external SD-Card Reader A Windows PC Step to create the SD-Card Extract the PhonixCard-xx.rar file into an empty directory. Navigate into the directory where you installed PhoenixCard and start PhoenixCard.exe. Click DiskCheck and choose the drive with your SD-Card Click Img File and choose the file you want Write Mode must be set to Startup Press Burn Wait until the burning process is finished (you will see the progress in the progress bar and the notification window) Booting Up the SD-Card Insert the SD-Card into the Pine64 and Power-up On the first time boot-up, it might take up to 5 minute for the system to get ready On the sub-sequence boot-up, it will only take about 40 to 60 second for the system to get ready Related Reference Easily Create an Android Bootable SD Card for Allwinner A80 Devices with PhoenixCard Tool PhoenixCard Tutorial YouTube Video ","permalink":"/documentation/Unsorted/PhoenixCard/","tags":null,"title":"PhoenixCard"},{"categories":null,"contents":" The following add-ons are available:\nKeyboard Fingerprint Reader Add-on Qi Wireless Charging Add-on LoRa Add-on Protection The compatible cases can be found under:\nCases The compatible screen protectors can be found under:\nScreen protectors Stands The following accessory is made by the community:\nPinePhone Development Stand at Thingverse Hubs USB hubs do not require a custom driver and are therefore expected to be compatible with the PinePhone, as long as they are within the USB specification. On revisions the PinePhone mainboard revisions v1.1 and v1.2 the VCONN fix is required, on v1.2a and later the USB hub should work out of the box, see PinePhone.\nCases The Pine store has official cases:\nPinePhone Hard Protective Case PinePhone Soft TPU Protective Case Tight-fit cases of other phones can’t be used with the PinePhone because most times the proportions and/or camera notch won’t fit. The phone can however be used with most \u0026ldquo;phone sleeves\u0026rdquo;, such as those from fitBAG. The sleeve from fitBAG for the Xiaomi Redmi Note 8 Pro fits the PinePhone tightly.\nThe OtterBox uniVERSE Case for Samsung Galaxy XCover Pro is reported to fit the PinePhone well without much modification.\nThe following accessory is made by the community:\nPinePhone Hard Case by The3DmaN at Thingverse PinePhone TPU Case by The3DmaN at Thingverse PinePhone Hard Case by blitzaxt at Thingverse Screen protectors The official screen protector can be found in the Pine64 store under PinePhone Tempered Glass Screen Protector.\nMost screen protectors for the iPhone 11 Pro Max, iPhone XS Max and Huawei Y7 (2018) fit the PinePhone if the top notch is not obscured by a black foil or a similar obstruction.\nKeyboard Picture of the PinePhone (Pro) Keyboard\nThe PinePhone (Pro) Keyboard Case is a case compatible with the PinePhone and PinePhone Pro, adding a keyboard functionality to the phone. It features a clam-shell design and uses the pogo pins located on the smartphone’s midsection and attaches by replacing the default back cover. This add-on effectively turns the PinePhone (Pro) into a PDA with an in-built LTE modem.\nGetting started ① Contact pads\n② Battery switch\n③ USB-C connector\nThe keyboard case works with both the PinePhone and PinePhone Pro and features a clam-shell design. It uses pogo pins located on the phone’s midsection and attaches by replacing the default back cover. When folded, the phone’s screen and the keyboard rest securely against each other. The hinge features a 180° design, which not only allows for two-hand typing on a surface but also for comfortable thumb-typing when fully extended. The etched keycaps can be easily relocated for alternate layouts such as AZERTY or QWERTZ. The keyboard case runs an open firmware, which means that anyone with the know-how can alter existing functions or add new ones. The bottom (keyboard) and top (phone) sections of the assembly are well-balanced thanks to the large, 6000mAh, internal battery capable of charging the PinePhone (Pro) during operation. The internal battery effectively triples the phone’s battery life. The internal keyboard battery can be manually toggled on/off and the keyboard’s battery charge level can be read in the supported operating systems; the keyboard remains functional with the battery fully depleted.\nYou do not lose access to the PinePhone (Pro)’s USB-C port, speaker, microphone, or any external features, such as volume and lock buttons, with the keyboard attached. There is also a cut-out for the camera, torch, and headphone jack. The USB-C port on the keyboard is capable of powering both the keyboard and PinePhone (Pro) simultaneously. This means that you can plug in a USB-C charger into the keyboard to charge the keyboard’s internal battery, while the PinePhone (Pro) is charging via the internal connection between phone and keyboard.\nWarning Do not plug in a charger into the keyboard and the phone at the same time. Using the USB-C port of the PinePhone (Pro) while a charger to is connected to the USB-C port of the keyboard is also discouraged for the same reason. Technical details regarding the issue can be found in the blog post of the developer megi here, in this blog post and the safety section. Please keep in mind that the keyboard case transforms the PinePhone (Pro) into a PDA, which means that taking calls will likely prove awkward without a wired or wireless headset connected (try speakerphone button if available).\nMounting the keyboard Power off your PinePhone and remove the back case. To remove the back case of the PinePhone use your fingernail or another soft object to pry up the back case. A notch to easily remove the cover is located at the bottom left of the PinePhone with the backcover facing the user.\nOpen and place the keyboard flat on a hard surface with the hinge fully extended. Proceed to insert the PinePhone into the keyboard at an angle of approx. 15 degrees. Make sure that the PinePhone’s pogo pins and the corresponding pads ① on the keyboard are aligned. The leading edge with volume and power buttons should make contact first. Firmly press the PinePhone into place. Multiple clicks should be heard as the two snap into place. Pay special attention to the plastic pin below the camera hole. Firmly push from the rear, below the camera hole, to click it into position. Failing to do so may cause an insufficient pin contact and prevent the case from charging the phone.\nThe PinePhone can be removed from the keyboard easily using a notch similar to the one found on the back case. The notch is located at the bottom of the leading edge with the power and volume buttons.\nOperation The keyboard will function automatically once a PinePhone running a compatible operating system is mounted. For alterations to physical layout and firmware see the relevant sections respectively.\nThe keyboard features an in-built 6000mAh battery. The battery can be turned ON/OFF using the button on the right leading edge of the keyboard ②. A short button press activates the internal battery while a long (15 seconds) press or double press deactivates it. Compatible operating systems display both the PinePhone’s and keyboard’s battery status together.\nYou should charge the PinePhone and the keyboard only using the USB-C ③ port on the keyboard. The keyboard’s USB-C port cannot be used for peripherals. The PinePhone’s USB-C port remains operational when mounted in the keyboard and can be used for data and peripherals.\nTroubleshooting There are multiple possible hardware issues users could face. It is recommend to check the following most common hardware issues and their solutions and workarounds.\nPogo pins not making proper contact Under certain scenarios the keyboard’s contacts are not making proper contact with the pogo pins of the phone. To address the issue:\nPower down the phone! Apply slight pressure in the upper mid of the PinePhone’s backside until the plastic holder pin towards the upper middle of the keyboard cover, until an audible click can be heard. Make sure the contacts and pogo pins are clean and the pogo pins can be slightly pressed individually. If the above does not work, a shim under the keyboard’s contacts might be required, as explained FAQ troubleshooting section. See also this photo of where to place the shim, or this video. Top row is less responsive The keys of the top row may be less responsive. The issue can be worked around by adding inserts to the underside of the top row key caps to decrease the travel distance. More details regarding the workaround can be found in the corresponding section of the FAQ page of the developer megi: https://xnux.eu/pinephone-keyboard/faq.html#ts\nSoftware issues For any software issue please see the Software support section and the FAQ section.\nSafety Do not plug in a charger into the keyboard and the phone at the same time. Doing so may result in damage or loss of the keyboard charging functionality. Using the USB-C port of the PinePhone (Pro) while a charger to is connected to the USB-C port of the keyboard is also discouraged for the same reason. Technical details regarding the issue can be found in the blog post of the developer megi here and this blog post.\nPlease note: Only use mild isopropyl alcohol when wiping down the clamshell of the device. Stronger solutions may partially strip the coatings. Do not lube the keyboard with GPL 205G0 switch grease, it can cause problems with the key responsiveness and tactility.\nSoftware support Kernel-space driver Kernel driver implementation from Samuel Holland: CONFIG_IP5XXX_POWER (module ip5xxx_power) and CONFIG_KEYBOARD_PINEPHONE (module pinephone_keyboard) https://github.com/smaeul/linux/commits/wip/pp-keyboard\nNote: If you’ve upgraded to \u0026gt;=5.18, don’t forget to upgrade the dtb as kb151 now appears to be a stub.\nUser-space driver The user-space driver is available here. Use git to clone the repository. You’re going to need sdcc 4.1+ installed to build it, so use your package manager to install that first. Next you’ll cd into the directory you cloned pinephone-keyboard and use the command \u0026ldquo;make\u0026rdquo; to build. After the build is completed, cd into the build directory and you’ll notice several new files starting with ppkb-. To use your keyboard case, you’ll want to run the following command: sudo ./ppkb-i2c-inputd. Open something you can type into like a new terminal window or text editor and you should now be able to use the keyboard case.\nNotes Virtual keyboards such as squeekboard are opening whenever a text field is selected.\nTo disable this behavior under Linux running Phosh you can change the corresponding settings under Settings \u0026gt; Accessibility \u0026gt; Screen Keyboard (see here). The virtual keyboard can also be disabled temporarily for one session using:\nTo temporarily disable the virtual keyboard: gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled false To temporarily enable the virtual keyboard: gsettings set org.gnome.desktop.a11y.applications screen-keyboard-enabled true The virtual keyboard needs to be activated before removing the keyboard case again.\nUnder Plasma Mobile the keyboard can be disabled via a widget, see here.\nIn Sxmo disabling the keyboard is not required, as the keyboard will only shown when the corresponding hotkey button is pressed.\nKeyboard layout The keyboard features a default layout (pictured below) created and agreed upon by the community. The keyboard layout can be altered using software as well as by physically repositioning keycaps. All keycaps, with the exception of space and return keys, can be easily and safely relocated for alternative layouts corresponding to software settings.\nThe keyboard layout how the keys were originally intended\nKeyboard firmware PinePhone’s keyboard firmware was developed independently by Ondřej Jirman as a free-of-charge contribution to PINE64. The firmware source code is freely and publicly available and you can modify it, and the supporting utilities, using common FOSS tools.\nFirmware and supporting utilities The design of the firmware allows the keys, modifier keys, and their combinations to be handled in virtually unlimited ways, without a need to flash a customized version of the firmware. Mapping of keys is defined at runtime, using the supporting utilities, and is not hardcoded in the firmware. Different keyboard layouts can be loaded dynamically to support various use cases.\nThe repository that contains the source code of the firmware, supporting utilities and associated documentation is located at https://xnux.eu/pinephone-keyboard/.\nYou are welcome to contribute patches and improvements to the firmware and the supporting utilities. A summary of firmware development history is available at https://xnux.eu/log/ alongside other development updates from the firmware author.\nMuch time and effort went into the development of this firmware. If you wish to send a token of appreciation or support the development efforts in any way, please consider making a donation to the author via one of the methods listed at the bottom of this web page: https://xnux.eu/contribute.html.\nFirmware License Copyright (C) 2021 Ondřej Jirman \u0026lt;megi@xff.cz\u0026gt; This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, with either version 3 of the License or (at your discretion) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See GNU General Public License for more details. GNU General Public License https://www.gnu.org/licenses/ Hardware Key hardware specifications:\nDimensions (closed): 161 x 95 x 25mm Weights (without / with PinePhone mounted): ~ 191 / ~391 grams Number of keys: 54 Number of rows: 5 Keyboard IC: Keyboard IC: EM85F684A 8-bit microcontroller with 256 bytes RAM, 2048/ bytes XRAM; 16kB for user’s own firmware Battery capacity: 6000mAh (22.2Wh 3.7V) Charger input: 5V, 3A (15W) Charging and battery IC chip: IP5209 power management IC with charge indicate controller and boost converter Frequently asked questions What is the keyboard driver situation?\nSee https://xnux.eu/pinephone-keyboard/faq.html#drivers\nAre keyboard drivers included in my distribution?\nSee https://xnux.eu/pinephone-keyboard/faq.html#distros\nWhat’s the status of the existing software for the keyboard?\nSee https://xnux.eu/pinephone-keyboard/faq.html#sw-status\nMy keyboard doesn’t work (well)!\nSee https://xnux.eu/pinephone-keyboard/faq.html#faq-ts\nHow does charging work?\nSee https://xnux.eu/pinephone-keyboard/faq.html#charging\nWhat charger is best for the keyboard?\nSee https://xnux.eu/pinephone-keyboard/faq.html#chargers\nHow safe is the charger circuit in the keyboard?\nSee https://xnux.eu/pinephone-keyboard/faq.html#safety\nKeyboard doesn’t react to any key presses\nSee https://xnux.eu/pinephone-keyboard/faq.html#ts\nKeyboard works but top row of keys is less responsive\nSee https://xnux.eu/pinephone-keyboard/faq.html#ts\nPhone is not charging from the keyboard\nSee https://xnux.eu/pinephone-keyboard/faq.html#ts\nPhone is charging slowly from the keyboard battery\nSee https://xnux.eu/pinephone-keyboard/faq.html#ts and https://forum.pine64.org/showthread.php?tid=16979\u0026pid=111414#pid111414#ts\nCan you open the keyboard and add extra functionality?\nIt is possible to do so, however the production units can be extremely difficult to open. Do not attempt to open the keyboard if you do not want to risk cosmetic damage (scaring and scratching of the plastic).\nHow can I rotate the screen display in tty ?\nUnder Linux this can be done using the command echo 1 | sudo tee /sys/class/graphics/fbcon/rotate\nTop row stopped displaying symbols (kernel \u0026gt; 5.17)\nFor Phosh (at the example of Mobian) see: https://wiki.mobian-project.org/doku.php?id=ppaccessories For TTY and SWMO see: https://codeberg.org/HazardChem/PinePhone_Keyboard For Plasma Mobile, one of either /etc/xdg/kxkbrc or ~/.config/kxkbrc is necessary, with contents as described in https://gitlab.com/postmarketOS/pmaports/-/merge_requests/3438 Documents PinePhone Keyboard 4 language user manual ver 2.0 in PDF format PinePhone Keyboard 4 language user manual ver 2.0 in ODT format Schematics, Datasheet and certifications Schematic:\nPinePhone Keyboard Schematic ver 1.0 20211009 Datasheet:\nPEM85F684A USB Microcontroller Datasheet IP5209 Power Bank SOC Datasheet TXS0104E 4-Bit Bidirectional Voltage-Level Translator Datasheet Certifications:\nPinePhone Keyboard FCC Certificate PinePhone Keyboard CE RED Certificate External links Pre-order announcement FAQ of the developer megous: https://xnux.eu/pinephone-keyboard/faq.html LoRa Add-on Store page: pine64.com\nUses the pogo pins to interface a Semtech SX1262 LoRa module with the PinePhone (Pro).\nImportant Software for receiving and sending LoRa messages with this back cover does exist, however no PinePhone operating system has added support for it yet. Schematics and Datasheet Schematic:\nPinePhone LoRa Back Cover Schematic ver 1.0 20210425 Datasheet:\nSX1262 Long Range, Low Power, sub-GHz RF Transceiver Datasheet ATmel ATtiny Microcontroller Datasheet I2C to SPI firmware:\nzschroeder6212’s tiny-i2c-spi Github page Fingerprint Reader Add-on Store page: pine64.com\nUses the pogo pins to interface a high quality fingerprint sensor, which uses open firmware for it’s i2c bridge, and can also be used for gesture navigation thanks to it’s ability to detect directional swipes.\nImportant No PinePhone operating system has added support for the fingerprint reader yet. Credits Credit goes to the user zschroeder6212, who carried the PinePhone Fingerprint Cover project from an idea to a real product. Their progress can be followed on GitHub under https://github.com/zschroeder6212.\nSchematics and Datasheet Schematic:\nPinePhone Finger Print Back Cover Schematic ver 3.0 20210124 Datasheet:\nP2SD Personal Identity Authentication Module Datasheet ATmel ATtiny Microcontroller Datasheet I2C to SPI firmware:\nzschroeder6212’s tiny-i2c-spi Github page Qi Wireless Charging Add-on Warning Possible safety hazard: If the wireless charging chip fails for some reason, do not plug the phone in to charge via USB-C. Take the back case off first. It is possible that power gets fed into the chip, causing it to overheat, possibly causing damage to the phone and creating a fire-hazard.\nAlbum of damage caused by reverse current: https://imgur.com/a/dJsp5wD\nUntil the cause of this is determined, it is recommended NOT to use the wireless charging add-on.\nUses the pogo pins to supply Qi Wireless and Wireless Power Consortium compatible charging. No software required.\nSchematics and Datasheet Schematic:\nPinePhone Wireless Charger Back Cover Schematic ver 1.0 20210508 Datasheet:\nHL6111RFNWP5 5W WPC Wireless Power Receiver Datasheet ","permalink":"/documentation/Phone_Accessories/_full/","tags":null,"title":"Phone Accessories (Single Page)"},{"categories":null,"contents":"Pre-release:\nPinecil_renders\nPinecil prototype\nProduction:\nPinecil V2, side view\nPinecil_V2_disassembled,_newly_designed_shorter_6.2_ohm_tip\nTransparent_handle\nReplacement internal contacts\nCartridge/Tips:\nShort tips, fine set\nShort tips, gross set\nNormal tips, fine set\nNormal tips, gross set\nPCB:\nPinecil_PCB_screen_side,_V2_on_top,_V1_on_bottom\nPinecil PCB bottom side, V2 on top, V1 on bottom\nAccessories:\nThumb screws on V1 \u0026amp; V2\n","permalink":"/documentation/Pinecil/Further_information/Pictures/","tags":null,"title":"Pictures"},{"categories":null,"contents":" The PINE A64\nThe PINE A64 and the PINE A64+ is PINE64’s first Single Board Computer powered by Allwinner’s A64 quad-core ARM Cortex A53 64-Bit SoC. There are many Operating Systems available for the PINE A64 created by the open source community and various partner projects.\nPresently, most Linux distributions for the PINE A64 rely on mainline Linux. However, there also exist a variety of BSP-based distributions and legacy systems that users can download.\nBoard features Layout Board Dimensions: 133mm x 80mm x 19mm\nBoard layout\nLabel Description 1 Touch panel connector 2 Camera port connector 3 PI 2 bus 4 3 pin connector for Lithium battery 5 2 pin RTC battery port 6 2x USB 2.0 Host Port 7 for Reset button 8 for Power OFF/ON button 9 Wi-Fi / Bluetooth port 10 IR receiver 11 Headphone jack (with microphone) 12 microSD card slot 13 Exp bus 14 Euler \u0026ldquo;e\u0026rdquo; bus 15 DSI connector 16 +5V microUSB DC power jack 17 Ethernet port 18 Digital Video Type A port Video Digital Video Port (Type A - full) Audio 3.5mm stereo earphone/microphone plug Network 10/100/1000 Mbps Ethernet (PINE A64+ version), 10/100 Mbps Ethernet (PINE A64 version) WiFi 802.11 b/g/n with Bluetooth 4.0 (optional) Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t2 USB2.0 Host port Expansion Ports DSI - Display Serial Interface, 4 lanes MiPi, up to 1080P CSI - CMOS Camera Interface up to 5 mega pixel TP - Touch Panel Port, SPI with interrupt RTC - Real Time Clock Battery Connector VBAT - Lithium Battery Connector with temperature sensor input Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 2x17 pins \u0026ldquo;Euler\u0026rdquo; GPIO Header 2x5 pins \u0026ldquo;EXP\u0026rdquo; Console Header Power Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, microUSB connector, Euler connector\nSoftware Releases This page contains a list of all available software releases and other resources for the PINE A64 and PINE A64+.\nNote The images for the PINE A64 and PINE A64+ are not compatible with the PINE A64-LTS due to LPDDR3 memory configuration. For PINE A64-LTS releases, please see the Software. Linux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. To learn more about AOSC, please visit the official AOSC website.\nDownload:\nhttps://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more) Default credentials aosc anthon Arch Linux ARM Arch Linux ARM is a distribution of Linux for ARM computers.\nInstallation:\nhttps://archlinuxarm.org/platforms/armv8/allwinner/pine64 Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://www.armbian.com/pine64/ Debian Debian is an operating system and a distribution of free software. See the forum thread here.\nDownload:\nDebian 11 Bullseye (recommended) Debian 12 Bookworm Daily netboot images Instructions:\nDownload: firmware.pine64_plus.img.gz Download: partition.img.gz Create the disk image: For Linux: zcat firmware.pine64_plus.img.gz partition.img.gz \u0026gt; complete_image.img For Mac: gzcat firmware.pine64_plus.img.gz partition.img.gz \u0026gt; complete_image.img Write the image to your boot device: For Linux: dd if=complete_image.img of=your_chosen_boot_device bs=4M For Mac: see Getting started Notes:\nAn Ethernet connection is required for the above installer DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the PINE A64 build on the PINE64 forum thread.\nDownload:\nDebian 11 Bullseye (supports the microSD card and eMMC, 4GB or more) Debian 12 Bookworm (supports the microSD card and eMMC, 4GB or more) Default credentials root dietpi FreedomBox FreedomBox is a private server for non-experts: it lets you install and configure server applications with only a few clicks. For more information about FreedomBox, please visit http://www.freedombox.org.\nDownload:\nRelease Signature Torrent Notes:\nThis is a headless build, not HDMI output. Please plug-in Ethernet cable first before initial power up. After power up for 10 minutes, using browser and type in https://fredombox.local to setup. Browser may warms for unsecure site and please proceed with exception. Freedom Manual: https://wiki.debian.org/FreedomBox/Manual LibreELEC LibreELEC is a \u0026ldquo;Just enough OS\u0026rdquo; Linux distribution combining the Kodi media center with an operating system.\nDownload:\n512MB PINE A64: direct download from Libreelec nightly build site (look for LibreELEC-A64.arm-\u0026hellip;-nightly-xxxxxxxx-xxxxxxx-pine64.img.gz) 1GB/2GB PINE A64+ Board: direct download from Libreelec nightly build site (look for LibreELEC-A64.arm-\u0026hellip;-nightly-xxxxxxxx-xxxxxxx-pine64-plus.img.gz) Notes:\nNightly build for microSD boot motionEyeOS motionEyeOS is a Linux distribution that turns a single-board computer into a video surveillance system. The OS is based on BuildRoot and uses motion as a backend and motionEye for the frontend. Visit the motionEyeOS GitHub and its GitHub Wiki for more information\nDownload:\n1GB/2GB PINE A64(+): Direct download from GitHub (look for motioneyeos-pine64-xxxxxxxx.img.xz) Notes:\nSuitable for 1GB/2GB PINE A64(+) variants There are 2 ways to interact with the OS: Scan for its IP with hostname MEYE-* and go to the admin web interface https://[IP] and after login, you should able to see the output of the CAMERA MODULE on the web interface Use the PINE64 USB SERIAL CONSOLE/PROGRAMMER and login Default credentials admin none NEMS Linux NEMS stands for Nagios Enterprise Monitoring Server and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their site.\nWarning Outdated release Download:\nDownload torrent seed from NEMS Linux (2.66GB, MD5 of the xz file is ac508549a829021491cfa23aeb18a063) Direct download from pine64.org (2.66GB, MD5 of the xz file is ac508549a829021491cfa23aeb18a063) Notes:\nSuitable for all 512MB/1GB/2GB PINE A64(+) variants Default credentials nemsadmin nemsadmin openSUSE openSUSE is a free and open source RPM-based Linux distribution developed by the openSUSE project. More details can be found under https://en.opensuse.org/HCL:Pine64.\nDownload:\nImages Headless build: Direct download OpenWRT The OpenWrt Project is a Linux operating system targeting embedded devices.\nDownload:\nDirect download (look for pine64_pine64-baseboard-ext4-sdcard.img.gz and pine64_pine64-baseboard-squashfs-sdcard.img.gz) Notes:\nOpenWRT community build for microSD boot. This is headless build, please use serial console to configure Default credentials Default user Use the command passwd BSD NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. To learn more about NetBSD please visit NetBSD main page.\nDownload:\nDirect download (345MB, select PINE A64 / PINE A64+) Notes:\nNetBSD community build for microSD boot Instructions concerning enabling SSH can be found here Default credentials root and SSH none Windows 10 IoT Download:\nWindows IoT direct download from pine64.org (957MB, MD5 of FFU file ACA617C0C9CEDA705DD510BF041E79B4) Notes:\nPINE64 Win10 IoT build already passed the Microsoft Azure certification For step by step installation process, please follow this github link For release note, please follow this github link For Microsoft Azure IoT SDKs, please follow this github link Changelog for Win10 IoT 10.0.15063.0_20170602:\nUpdate Notes since 10.0.15063.0_20170524: Fix the failure of default application installation caused by a app certification issue Fix that the default application cannot start automatically after installation Fix Ethernet initialization problem and now the Ethernet will start successfully every time Enable the usermode access for all unusable GPIO pins in Pi-2 bus( later provide a UWP sample to show how to control these pins ) Extra Notes: If you want to connect a USB peripheral for extension, please connect a USB hub to the lower USB interface as the medium Please refer to Part 2 of chapter 3: Debug with a virtual net over USB on how to use the upper USB interface Changelog for Win10 IoT 10.0.15063.0_20170524:\nSome Updates: Update the OS version to build v.10.0.15063.0 (Creators Update) New page style of Device Portal, visit https://deviceipaddr:8080 to check it Built-in Cortana assistant, need to be enabled in settings page in default app and Device Portal Support on-screen keyboard, need to be enabled in Device Portal Enable 100M Ethernet and fix some bugs Support built-in UART bus in A64 SoC(not built in the ffu, later provide driver binary and deployment helper) Support built-in IR module in A64 SoC(not built in the ffu, later provide source code and dev doc for developers in community) Known Issues: Kernel debug is enabled by default. This will slow the bring-up process. If a kernel debug is not necessary for you, visit Device Portal and navigate to Processes-\u0026gt;Run Command page, run this command to disable: Bcdedit /store C:\\EFIESP\\EFI\\Microsoft\\boot\\BCD /set {default} debug off An PnP bug in audio device may cause a blue screen when acting software shutdown Ethernet device may not start with problem code 12 at the first time to bring up Linux BSP SDK Linux BSP Kernel 4.9\nDirect Download from pine64.org (5.4GB, MD5 of the TAR-GZip file 7736e3c4d50c021144d125cc4ee047a4) Android SDK Android Oreo (v8.1)\nDirect Download from pine64.org (24.94GB, MD5 of the TAR-GZip file b0394af324c70ce28067e52cd7bc0c87) Other resources Allwinner PhoenixCard Bootable SD-Card Creator Allwinner DragonFace software that will let you edit and modify A64 Stock Android Build PhoenixCard image Below you will find useful links to various resources and forum threads:\nSunxi PINE64 Page Longsleep BSP Linux Builds Download Page Longsleep BSP Linux Kernel Thread on PINE64 Forum Longsleep BSP Xenial Thread on PINE64 Forum Longsleep BSP Arch Linux Thread on PINE64 Forum Accessories Under Accessories Step by Step Guides you can find instructions and guides pertaining to:\nEnclosures Bluetooth and WiFi module Real Time Clock (RTC) battery Real Time Clock (RTC) battery holder First and third party cases Featured 3D printed cases (and more). Further information Datasheets\nHeat sinks\nOther resources\nPine A64 POT\nSchematics and certifications\nSoC and Memory Specification\nDatasheets Allwinner A64 SoC information:\nAllwinner A64 SoC Brief Introduction Allwinner A64 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC Datasheet Related to the PINE A64 5MPixel CMOS Camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) S5K4EC 5MP CMOS Image Sensor SoC Module Datasheet S5K4EC 5MP CMOS Image Sensor SoC Chip Datasheet S5K4EC 5MP CMOS Image Sensor Driver Source Code in C language Early version Camera module information:\nBonsen Kexin V118-A64-GC2145-HM5065 CMOS Image Sensor Module HiMax 5MP CMOS Image Sensor SoC LCD Touch Screen Panel information:\n7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Lithium Battery information:\n8000mAH Lithium Battery Specification Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64+ Board Realtek RTL8201 10/100M Ethernet Transceiver for PINE A64 Board Wifi/BT module information:\nPINE A64 Wifi/BT Module Schematic Realtek RTL8723BS WiFi with BT SDIO Enclosure information:\nPlaybox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port Remote control button mapping:\nOfficial Remote Control for the PINE A64 Button Mapping Heat sinks Overclocking requires heat sinks:\nPosition of the heat sinks\nOther resources Good documentation about PINE A64, A64+, and A64-LTS GPIO pins article Linux Sunxi Wiki page on PINE A64 PINE A64 Linux build scripts, tools and instructions by Longsleep PINE A64 Linux image by Longsleep PINE A64 Linux Github by ayufan PINE A64 Android Github by ayufan Armbian’s PINE A64 Page Collection of scripts to set up a minimal Xenial 14.04.3 / Debian 8 Jessie root filesystem Contributed By Uli Middelberg Linux Image created by Andre Przywara PINE A64 with HypriotOS by Dieter and Govinda H2testw 1.4 – Gold Standard In Detecting USB Counterfeit Drives F3 - an alternative to h2testw Benchmarking The Low-Cost PINE 64+ ARM Single Board Computer by Michael Larabel A series of Youtube video on PINE A64 Developers Board by Michael Larson PINE64 Quick Start Guide (with Gotchas) Shrinking images on Linux by FrozenCow FFmpeg Hardware encoder Cedrus264 on Linux by avafinger Pine A64 POT PINE A64 Peripheral On Top (POT) and Related Devices WiFi Remote I2c Quick Start Guide Schematics and certifications Schematics and general files:\nPINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016) Board schematics:\nPINE A64 512MB Rev B Board Schematic PINE A64+ 1GB Rev B Board Schematic PINE A64+ 2GB Rev C Board Schematic PINE A64 Wifi/BT Module Schematic Stereo audio DAC schematics:\nPINE A64 Stereo audio DAC schematics Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submit the SBC for FCC, CE, and ROHS certifications and obtain the certificates to prove that the SBC board can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. PINE A64 FCC Certificate PINE A64 CE Certificate PINE A64 RoHS Certificate SoC and Memory Specification The Pine A64 is based on the Allwinner A64.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions (LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard System Memory RAM Memory Variants: 512MB, 1GB and 2GB DDR3. Storage Memory: PINE A64 boards do not have built-in Flash memory but use bootable microSD Cards or USB attached storage. ","permalink":"/documentation/Pine_A64/_full/","tags":null,"title":"Pine A64 (Single Page)"},{"categories":["SBCs"],"contents":" PINE64\u0026rsquo;s First 64-bit Single Board Computer This is where the journey began. The PINE A64 and PINE A64+ are PINE64\u0026rsquo;s first Single Board Computer powered by Allwinner’s A64 quad-core ARM Cortex A53 64-Bit SoC. There are many Operating Systems available for the PINE A64 (+) created by the open source community and various partner projects. Currently the majority of Linux distributions for the PINE A64 are using mainline Linux but there are a number of BSP-based distribution and / or legacy systems that you can download too.\nApart from Linux, you also have a choice of a selection of *BSD, Android, Remix OS and Windows IoT.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.152 GHz GPU ARM Mali 400 MP2 GPU Memory DDR3 RAM (up to 2GB) Networking Gigabit Ethernet Flash Memory Micro SD Connections HD digital video out 2x USB 2.0 Host Euler bus Expansion bus PI-2 bus Touch Panel (TP) port Display Serial Interface (DSI) port IR R/X port Real Time Clock Port (RTC) Lithium battery port CMOS Sensor Interface port Optional expansion module with 802.11 b/g/n WiFI and Bluetooth 4.0 3.5mm headphone jack Micro USB power (5V 2A) port Quad-Core A64 SoC First broadly avaliable quad-core ARM64 platform\n2GB DDR3 RAM Up to 2GB DDR3 RAM\nGigabit Ethernet Built-in Ethernet port allows for fast internet access\nWiFi And Bluetooth Optional 802.11 b/g/n WiFi and Bluetooth 4.0 module\nDocumentation PINE A64 Schematics and certifications ","permalink":"/devices/pine_a64/","tags":null,"title":"PINE A64 and PINE A64+"},{"categories":null,"contents":" PINE A64 Peripheral On Top (POT) and Related Devices WiFi Remote I2c Quick Start Guide ","permalink":"/documentation/Pine_A64-LTS/Further_information/Pine_A64_POT/","tags":null,"title":"Pine A64 POT"},{"categories":null,"contents":" PINE A64 Peripheral On Top (POT) and Related Devices WiFi Remote I2c Quick Start Guide ","permalink":"/documentation/Pine_A64/Further_information/Pine_A64_POT/","tags":null,"title":"Pine A64 POT"},{"categories":["SBCs"],"contents":" The Long Term Supply Version of the PINE A64 (+) The PINE A64-LTS is the Long Term Supply version of the PINE A64 (+), our first Single Board Computer, powered by Allwinner’s A64 quad-core ARM Cortex A53 64-Bit SoC. There are many Operating Systems available for the PINE A64-LTS created by the open source community and various partner projects. Currently the majority of Linux distributions for the PINE A64-LTS are using mainline Linux but there are a number of BSP-based distribution and / or legacy systems that you can download too.\nApart from Linux, you also have a choice of a selection of *BSD and Android. The PINE A64-LTS is guaranteed to be supplied for 5 years until year 2022 at the very least.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.152 GHz GPU ARM Mali 400 MP2 GPU Memory DDR3 RAM (up to 2GB) Networking Gigabit Ethernet Flash Memory Micro SD Connections HD digital video out 2x USB 2.0 Host Euler bus Expansion bus PI-2 bus Touch Panel (TP) port Display Serial Interface (DSI) port IR R/X port Real Time Clock port (RTC) Lithium battery port CMOS Sensor Interface port Optional WiFi 802.11 b/g/n with Bluetooth 4.0 expansion module 3.5mm headphone jack 3.5mm barrel power (5V 2A) port Quad-Core A64 SoC First broadly avaliable quad-core ARM64 platform\n2GB DDR3 RAM Up to 2GB DDR3 RAM\nGigabit Ethernet Built-in Ethernet port allows for fast internet access\nWiFi And Bluetooth Optional 802.11 b/g/n WiFi and Bluetooth 4.0 module\nStores Global Global: Accessories Global: Add-ons Affiliates Documentation PINE A64-LTS Schematics and certifications ","permalink":"/devices/pine_a64-lts/","tags":null,"title":"PINE A64-LTS"},{"categories":null,"contents":" The PINE A64-LTS\nThe PINE64-LTS is the long term supply version of the PINE A64 (+), PINE64’s first single board computer, powered by Allwinner’s A64 quad-core ARM Cortex A53 64-Bit SoC. There are many operating systems available for the PINE A64-LTS created by the open source community and various partner projects. The PINE A64-LTS is guaranteed to be supplied until the year 2025 at the very least.\nBoard features Layout Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm\nVideo Digital Video (Type A - full) Audio 3.5mm stereo earphone/microphone plug Network 10/100/1000Mbps Ethernet(PINE A64+ version), 10/100Mbps Ethernet(PINE A64 version) WiFi 802.11 b/g/n with Bluetooth 4.0 (optional) Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t2 USB2.0 Host port Expansion ports DSI - Display Serial Interface, 4 lanes MiPi, up to 1080P CSI - CMOS Camera Interface up to 5 mega pixel TP - Touch Panel Port, SPI with interrupt RTC - Real Time Clock Battery Connector VBAT - Lithium Battery Connector with temperature sensor input Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 2x17 pins \u0026ldquo;Euler\u0026rdquo; GPIO Header 2x5 pins \u0026ldquo;EXP\u0026rdquo; Console Header Power Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, 3.5OD/1.35ID Barrel DC Jack connector, Euler connector\nAccessories Please see Accessories Step by Step Guides for a list of guides for Pine A64 accessories; there you can find instructions and guides about the following:\nEnclosures Bluetooth and WiFi module Real Time Clock (RTC) battery Real Time Clock (RTC) battery holder First and third party cases Featured 3D printed cases (and more) Further information Datasheets\nOther resources\nPine A64 POT\nSchematics and certifications\nSoC and Memory Specification\nDatasheets Allwinner A64/R18 SoC information:\nAllwinner A64 SoC Brief Introduction Allwinner R18 SoC Brief Introduction Allwinner A64/R18 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64/R18 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC Datasheet LPDDR3 information:\nAllwinner LPDDR3 Datasheet Foresee LPDDR3 Datasheet Samsung LPDDR3 Datasheet Hynix LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Related to the PINE A64-LTS 5MPixel CMOS Camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) S5K4EC 5MP CMOS Image Sensor SoC Module Datasheet S5K4EC 5MP CMOS Image Sensor SoC Chip Datasheet S5K4EC 5MP CMOS Image Sensor Driver Source Code in C language Early version Camera module information:\nBonsen Kexin V118-A64-GC2145-HM5065 CMOS Image Sensor Module HiMax 5MP CMOS Image Sensor SoC LCD Touch Screen Panel information:\n7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Lithium Battery information:\n8000mAH Lithium Battery Specification Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64-LTS Board and SOPINE Baseboard Wifi/BT module information:\nPINE A64 Wifi/BT Module Schematic Realtek RTL8723BS WiFi with BT SDIO Enclosure information:\nPlaybox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port Remote control button mapping:\nOfficial Remote Control for the PINE A64 Button Mapping Other resources Good documentation about PINE A64, A64+, and A64-LTS GPIO pins article Linux Sunxi Wiki page on PINE A64 Collection of scripts to set up a minimal Xenial 14.04.3 / Debian 8 Jessie root filesystem Contributed By Uli Middelberg Linux Image created by Andre Przywara PINE A64 with HypriotOS by Dieter and Govinda H2testw 1.4 – Gold Standard In Detecting USB Counterfeit Drives F3 - an alternative to h2testw Benchmarking The Low-Cost PINE 64+ ARM Single Board Computer by Michael Larabel PINE64 Linux build scripts, tools and instructions by Longsleep PINE64 Linux image by Longsleep A series of Youtube video on PINE A64 Developers Board by Michael Larson PINE64 Quick Start Guide (with Gotchas) Shrinking images on Linux by FrozenCow Manjaro Arm installation script Pine A64 POT PINE A64 Peripheral On Top (POT) and Related Devices WiFi Remote I2c Quick Start Guide Schematics and certifications Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, 3.5OD/1.35ID Barrel DC Jack connector, Euler connector\nSchematics:\na PDF mapping the pins from the A64 chip itself, to the gold-fingers on the SO-DIMM edge, to the multiple connectors on the baseboard and on the clusterboard, attached to this forum post. PINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016) Pine A64-LTS schematic:\nPine A64-LTS Schematic Pine A64-LTS V2 schematic:\nPine A64-LTS V2 Schematic SoC and Memory Specification The PINE A64-LTS is based on the Allwinner A64/R18. The R18 and A64 are identical SoCs but the is R18 committed for a 10 years supply by the vendor.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard System Memory RAM Memory Variants: 2GB LPDDR3. Storage Memory: 128Mb SPI Flash and optional eMMC module from 16GB up to 128GB Software The SOPINE operating system images are compatible with PINE A64-LTS. Under Software you will find a complete list of currently supported operating system images, which work with the PINE A64-LTS, as well as other related software.\nBelow is a list of links to the build sources and environments for some operating system images. Some of them are labelled as beta or nightly builds, which means they are fit for testing purposes only. Those images should be used at your own risk and are not fit for regular use.\nlongsleep BSP Linux ayufan Linux ayufan Android 7.1, Android 6.0, and Android 5.1 openSUSE SOPINE Armbian Arch Linux XFCE OpenMediaVault ","permalink":"/documentation/Pine_A64-LTS/_full/","tags":null,"title":"Pine A64-LTS (Single Page)"},{"categories":["SBCs"],"contents":" The PINE H64 Model A The PINE H64 Model A is Single Board Computer by PINE64. It is powered by an Allwinner “H6” Quad-Core ARM Cortex A53 64-Bit Processor with a MALI T-722 GPU.\nDocumentation PINE H64 Model A Schematics and Certifications ","permalink":"/devices/pine_h64_model_a/","tags":null,"title":"PINE H64 Model A"},{"categories":null,"contents":" The PINE H64 Model A\nThe PINE H64 Model A is a discontinued Single Board Computer by PINE64. It is powered by an Allwinner \u0026ldquo;H6\u0026rdquo; Quad-Core ARM Cortex A53 64-Bit Processor with a MALI T-722 GPU.\nBoard Features Dimensions Board dimensions: 133mm x 80mm x 19mm\nPower Input power: DC 5V @ 3A, 3.5mm OD/ 1.35mm ID DC jack connector, Euler connector\nVideo Digital Video 4KP60 (Type A - full) Audio 3.5mm stereo earphone/microphone plug Network 10/100/1000 Mbps Ethernet WiFi 802.11 b/g/n/ac with Bluetooth 4.0/4.1 (optional) Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t1 USB3.0 Host port and 2 USB2.0 Host port Expansion Ports RTC - Real Time Clock Battery Connector Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header mini PCIe connector SoC and memory specifications The PINE H64 Model A is based on the Allwinner H6.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1488Mhz footnote:[see Cortex-A53 on arm.com] A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Trustzone technology supported Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions (LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali T-720MP2 Dual-core GPU footnote:[see Mali-T720 on arm.com] Supports OpenGL ES 3.1/3.0/2.0/1.1, OpenCL 1.2/1.1 Supports ATSC (Adaptive Scalable Texture Compression) Supports FAST (4x) FSAA, IO Coherency Floating point operation greater than 70 GFLOPS System Memory RAM Memory Variants: 1GB, 2GB, and 3GB LPDDR3. Storage Memory: PINE H64 boards have a built-in 128Mb SPI Flash memory and can use bootable eMMC modules, bootable microSD cards or USB-attached storage. Software Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://www.armbian.com/pineh64/ Default credentials root 1234 DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the PINE H64 build on the PINE64 forum thread.\nDownload:\nTrixie image Default credentials root dietpi Linux BSP SDK The Linux BSP Kernel version 4.9\nDownload:\nH6 BSP 4.9 Tools H6 BSP 4.9 \u0026ldquo;Brandy\u0026rdquo; Github H6 BSP 4.9 Linux Github Linux BSP Kernel ver 3.10 Lichee ver 1.1 Direct Download from pine64.org MD5 (TAR-GZip file): AE6CA68A230923031680BCFABDD7FC89 File Size: 2.76GB Linux BSP Kernel ver 3.10 Lichee ver 1.0 Direct Download from pine64.org MD5 (TAR-GZip file): 2D90557E63946A7DA64CD133EE57F206 File Size: 2.40GB Mali-T720 driver A good DRM PowerPoint presentation by Free Electron here and the DRM video presentation by Free Electron here.\n32-bit Wayland MALI Driver:\nMALI EULA document MALI-T720 32-bit server binary driver and binary download (3.4 MB MD5 F2186A4CAE505A76E0758735886FE682) MALI-T720 32-bit client binary driver and binary download (3.4 MB MD5 F316A78AFABE87E69C8F816D18F15D68) Further information Datasheets\nSchematics and Certifications\nDatasheets Allwinner H6 SoC information:\nAllwinner H6 SoC Brief Introduction Allwinner H6 SoC Data Sheet V1.1 (Official Released Version) Allwinner H6 SoC User Manual V1.0 (Official Release Version) X-Powers AXP805 PMU (Power Management Unit) information:\nX-Powers AXP805 Data Sheet V1.0 (Official Release Version) LPDDR3 (178 Balls) SDRAM:\nHynix LPDDR3 Datasheet V1.2 Samsung LPDDR3 Datasheet V1.00.00 Spectek LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG SanDisk eMMC Datasheet Hynix eMMC Datasheet Foresee eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE H64 Board Wifi/BT module information:\nAMPAK AP6356 2x2WiFi with BT 4.1 SDIO Realtek RTL8723BS 1x1 WiFi with BT 4.0 SDIO miniPCIe SATA module information:\nMolex miniPCie Socket information ASmedia ASM1061 2x2WiFi with BT 4.1 SDIO Enclosure information:\nABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Remote control button mapping\nOfficial Remote Control for the PINE H64 Button Mapping Schematics and Certifications PINE H64 Pi-2/Euler/Ext Bus Connector Pin Assignment PINE H64 Board Schematic:\nPINE H64 1GB/2GB/3GB Rev 1.1 Board Schematic PINE H64 Certification:\n[Not yet available] ","permalink":"/documentation/PINE_H64_Model_A/_full/","tags":null,"title":"PINE H64 Model A (Single Page)"},{"categories":["SBCs"],"contents":" PINE H64 Model B Single Board Computer Featuring USB 3.0 and Gigabit Ethernet The PINE H64 Model B is powered by an Allwinner “H6” quad-core ARM Cortex A53 64-Bit Processor with a Mali T-722 GPU. The PINE H64 is equipped with up-to 3GB LPDDR3 PC-1600 system memory and 128Mb SPI boot Flash. There is also an optional eMMC module (up to 128GB) and microSD slot for booting. The board is also equipped with onboard built-in 802.11n Wifi and Bluetooth 4.0, 1x USB 3.0 Host, 2x USB 2.0 Host, Gigabit Ethernet, PI-2 GPIO Bus, and a Euler GPIO bus as well other peripheral device interfaces such as UART, SPI, and I2C for makers to integrate with sensors and other peripherals.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.488 GHz GPU ARM Mali-T720 MP2 GPU Memory LPDDR3 RAM (up to 3GB) Networking Gigabit Ethernet Storage Micro SD slot eMMC module slot SPI Flash 128Mbit Connections 4K digital video out 2x USB 2.0 Host 1x USB 3.0 Host PI-2 bus IR R/X port Real Time Clock (RTC) port A/V jack Built-in 802.11ac WiFi with Bluetooth 4.1 Power, Reset and Recovery buttons 3.5mm barrel power (5V 3A) port Allwinner H6 Quad ARM Cortex A53 cores @ 1.48 GHz and a powerful ARM Mali-T720 MP2 GPU\n3GB LPDDR3 RAM Up to 3GB of LPDDR3 RAM\nGigabit Ethernet Built-in Ethernet port allows for fast internet access\nWiFi And Bluetooth Built-in 802.11ac WiFi and Bluetooth 4.1\nDocumentation PINE H64 Model B Schematics and Certifications ","permalink":"/devices/pine_h64_model_b/","tags":null,"title":"PINE H64 Model B"},{"categories":null,"contents":" The PINE H64 Model B\nThe PINE H64 Model B is a Single Board Computer by PINE64. It is powered by an Allwinner \u0026ldquo;H6\u0026rdquo; Quad-Core ARM Cortex A53 64-Bit Processor with a MALI T-722 GPU. The PINE H64 is equipped with up to 3GB of LPDDR3 PC-1600 system memory and 128 Mbit of SPI boot Flash. There is also an optional eMMC module (up to 128GB) and a microSD slot for booting. The board is equipped with an onboard 802.11n Wifi/BT chipset, one USB 3.0 host port, two USB 2.0 host ports, Gigabit Ethernet, a PI-2 GPIO bus, an Euler GPIO bus as well as many other peripheral device interfaces such as UART, SPI, and I^2^C.\nBoard Features Dimensions Board dimensions: 85mm x 56mm x 18.8mm\nPower Input power: DC 5V @ 3A, 3.5mm OD/ 1.35mm ID DC jack connector\nVideo Digital Video 4KP60 (Type A - full) Audio 3.5mm stereo earphone/microphone plug Network 10/100/1000 Mbps Ethernet WiFi 802.11 b/g/n/ac with Bluetooth 4.0/4.1 MHF1 RF coaxial connector for external BT/wifi antenna Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t1 USB3.0 Host port and 2 USB2.0 Host port Expansion Ports RTC - Real Time Clock Battery Connector Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 3x3 pins \u0026ldquo;EXT\u0026rdquo; Header giving console, power switch and reset switch access Console The console UART is available on the 6-pin header connector between the HDMI and headphone jacks. The pins are on the front row, closer to the board’s edge: TX, RX, GND, from left (HDMI) to right (headphone). The default standard is 8,n,1 at 115200bps. SoC and memory specifications The PINE H64 Model B is based on the Allwinner H6.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1488Mhz footnote:[see Cortex-A53 on arm.com] A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Trustzone technology supported Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions (LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali T-720MP2 Dual-core GPU footnote:[see Mali-T720 on arm.com] Supports OpenGL ES 3.1/3.0/2.0/1.1, OpenCL 1.2/1.1 Supports ATSC (Adaptive Scalable Texture Compression) Supports FAST (4x) FSAA, IO Coherency Floating point operation greater than 70 GFLOPS System Memory RAM Memory Variants: 1GB, 2GB, and 3GB LPDDR3. Storage Memory: PINE H64 boards have a built-in 128Mb SPI Flash memory and can use bootable eMMC modules, bootable microSD cards or USB-attached storage. Software Releases\nLinux BSP SDK\nAndroid SDK\nReleases The following releases are for the PINE H64 Model B\nLinux Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://www.armbian.com/pine-h64-b/ DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the PINE H64 build on the PINE64 forum thread.\nDownload:\nTrixie image Default credentials root dietpi LibreELEC LibreELEC is a \u0026ldquo;Just enough OS\u0026rdquo; Linux distribution combining the Kodi media center with an operating system.\nDownload:\nStable builds (Look for LibreELEC-H6.arm-xx.x.x-pine-h64.img.gz) Notes:\nSupports microSD card and eMMC boot BSD FreeBSD FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms. To learn more about FreeBSD, please visit FreeBSD main page.\nInstructions:\nSee general information about FreeBSD on Allwinner ARM and specific details about creating a microSD card for the PINE H64 Notes:\nFreeBSD supports booting from the microSD card NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. To learn more about NetBSD please visit NetBSD main page.\nDownload:\nDirect download latest release build from NetBSD by select PINE H64 Notes:\nNetBSD supports booting from the microSD card Instructions concerning enabling SSH can be found here Default credentials root (root user and SSH) [none] Linux BSP SDK Linux BSP Kernel 4.9\nDownload:\nDirect download from pine64.org (5.04GB, MD5 of the TAR-XZ file 06B675B1C217D4CC6A21FF320DA250C1) Android SDK Android Pie 9.0 SDK version 1.0\nDirect download from pine64.org (29.14GB, MD5 of the TAR-XZ file 734B4DBB03CAF82A4E955F7E83DE0C65) Further information Datasheets\nSchematics and Certifications\nMali-T720 driver\nDatasheets Allwinner H6 SoC information:\nAllwinner H6 SoC Brief Introduction Allwinner H6 SoC Data Sheet V1.1 (Official Released Version) Allwinner H6 SoC User Manual V1.0 (Official Release Version) X-Powers AXP805 PMU (Power Management Unit) information:\nX-Powers AXP805 Data Sheet V1.0 (Official Release Version) LPDDR3 (178 Balls) SDRAM:\nHynix LPDDR3 Datasheet V1.2 Samsung LPDDR3 Datasheet V1.00.00 Spectek LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE H64 Board Wifi/BT module information:\nRealtek RTL8723BS WiFi with BT SDIO Remote control button mapping:\nOfficial Remote Control for the PINE H64 Button Mapping Schematics and Certifications PINE H64 Model B Pi-2 Bus and EXP Bus Connector Pin Assignment PINE H64 board schematics:\nPINE H64 Model B 1GB/2GB/3GB Rev 1.2 Board Schematic PINE H64 Model B certification:\nPINE-H64 Model-B FCC Certificate PINE-H64 Model-B CE Certificate] Mali-T720 driver A good DRM PowerPoint presentation by Free Electron here and the DRM video presentation by Free Electron here.\n32-bit Wayland MALI Driver:\nMALI EULA document MALI-T720 32-bit server binary driver and binary download from pine64.org (3.4MB, MD5 F2186A4CAE505A76E0758735886FE682) MALI-T720 32-bit client binary driver and binary download from pine64.org (3.4MB, MD5 F316A78AFABE87E69C8F816D18F15D68) 64-bit Wayland MALI Driver:\nMALI EULA document MALI-T720 64-bit server binary driver and binary download from pine64.org (5.0MB, MD5 13CC8DCB7CF068D80DFC16281E95E9D7) MALI-T720 64-bit client binary driver and binary download from pine64.org (5.0MB, MD5 951BAD6ED66D4CB904CFE0D65F2855E8) ","permalink":"/documentation/PINE_H64_Model_B/_full/","tags":null,"title":"PINE H64 Model B (Single Page)"},{"categories":null,"contents":"PINE64 and the PINE64 pinecone logo are trademarked by Pine Store Limited. The trademark extends to the PINE64 brand name in writing, the PINE64 pinecone logo (referred to as logo in the document) and in some instances also to logo derivatives (see section 4).\nThe brand and logo were first trademarked in 2015 by then Pine Microsystems Inc. Pine Store Ltd. permits the usage of the brand name, the logo and logo derivatives for all non-commercial software endeavours and non-software projects undertaken by PINE64’s Community and community projects (subject to the terms outlined in this document). Pine Store Ltd. may also permit the usage of the logo and branding for commercial software and non-software goods projects upon prior agreement. PINE64 Community also permits the usage of the logo and branding to sponsored projects or community endeavours and affiliate programs (see section 3.1).\nWe are highly protective of our trademark and copyrights, and will seek any and all legal measures to enforce guidelines contained in this document.\n1. Presentation and typography The PINE64 project logotype is always capitalised: PINE64 The logotype always uses high tonal contrast, all capital letters and is preceded by the logo. The original logotype uses Arial Std Narrow Regular, but an acceptable and frequently used variant is written in Noto Sans Telugu UI.\nThe PINE64 logo is a polygon geometric pinecone representation. The original logo uses five shades of blue colour.\nPINE64 logo colors in HTML notation, top to bottom:\n[#52accd] [#2f82c4] [#2969b1] [#3d5c8b] [#475677] Other variants, including all-white logo and typography on black or transparent background, are in use and permitted for non-commercial usage. Other colour variations are also permitted for non-commercial use. Other variants than the official logotype may be used for commercial use following an inquiry with PINE64 Community representatives and/ or designated Pine Store Ltd. staff members.\n1.1. Slogan(s), look and branding The PINE64 community slogan is “Open. Friendly. Community Driven”. PINE64 hardware packaging uses the tagline “Open Sesame”.\nPINE64 uses a distinct brand look which makes use of the original colour scheme of the pine cone logo (see section 1.) in conjunction with black, grey and white as background colours. The distinct look of PINE64 organization’s (pine64.org) website, the official forum (forum.pine64.org) and the Pine Store’s (pine64.com) website is restricted to official PINE64 portals and community services. It may not be copied or imitated by community run services such as forums or websites.\n1.2. PINE64 logo kit We provide a PINE64 logo media kit in .zip format containing a range of acceptable logo variations in SVG file format. The .zip file also contains a READ ME document with detailed information and instructions.\nMedia kit in .zip format 1.3. Branding on devices We choose to keep PINE64 branding on our devices to a minimum. Our design follows our inherent ideology that devices we sell belong to the end-users, not to us.\nA PINE64 pinecone is always printed on the PCB of a single board computer or device, alongside with the hardware’s name and revision number version. The full brand name is never used on our devices.\nThe PINE64 pinecone is also discreetly placed between the torch and camera on the PinePhone, on the LCD of the PineTab and on the SUPER key on the Pinebook Pro. This minimal branding aesthetic will also be used for future PINE64 hardware.\nPackaging of PINE64 devices varies in branding implementation, ranging from plain white boxes from recycled materials to the hallmark “Open Sesame” tagline alongside PINE64 logotype from recycled cardboard. The PinePhone also uses a distinct “PINEPHONE” logotype written in Good Times Regular font.\n2. Non-commercial usage Any and all derivatives of the PINE64 brand name and pinecone logo, including alterations to the original logo per bounds in section 1, are permitted for non-commercial use.\nUse of the logo and brand name is permitted in communities or projects, as long as it is clearly denoted that the software, community, portal, website, subreddit, etc., does not belong to and is not administered by PINE64 community nor Pine Store Ltd.\n2.1. Examples of appropriate non-commercial usage Including PINE64 logo and brand name in open source software, offered freely and free of charge, written for PINE64 devices Including PINE64 logo and brand name on publicly available 3D files offered freely and free of charge Including PINE64 logo and brand name on software project websites to indicate that software compatibility with PINE64 hardware Including PINE64 logo on community run forums, subreddits, chats, etc. Including PINE64 logo to indicate that software is compatible with PINE64 hardware Any alterations to the logotype for private or community use - for example as freely distributed wallpapers, icons, emotes, etc. Including PINE64 slogan and distinct brand look in freely distributed and royalty free software 2.2. Restrictions to non-commercial usage The PINE64 logo and logotype may not, under any circumstances, be used or associated with any software or hardware projects not related to PINE64 hardware. Our brand name look and slogan (see section 1.1) are also restricted to use on official PINE64 websites, chats, forums and hardware (but allowed on freely distributed software for PINE64 devices).\nWe reserve the right to request the PINE64 logo and logotype be removed if a non-profit endeavour or project doesn’t align with our rules and code of conduct. This includes, but is not limited to, any community project, endeavour or piece of software promoting any political, religious or social agendas outside the scope of what our rules and code of conduct guidelines permit.\nThe PINE64 logo and logotype may not, under any circumstances, be used to mislead existing or prospectus PINE64 community members into believing that software, social media account, community service, website, forum, subreddit, chat, social media account, etc., is representative of or run by official spokespersons of the PINE64 community or the Pine Store Ltd. staff members. The PINE64 logo and brand name may not be used in a way that creates a false impression that a product or business is endorsed, sponsored by or associated with the PINE64 community or Pine Store Ltd.\n3. Commercial, affiliate and sponsorship usage Commercial use of the logo, logotype or brand name, as well as any derivatives or alterade logotypes, is not permitted without prior consent of Pine Store Ltd. This means that any software project, merchandise vendor or community endeavour that seeks to turn a financial profit based on the PINE64 brand name needs to first acquire appropriate consent from Pine Store Ltd.\nThe logo and logotype are copyrighted. Sale of any merchandise with PINE64 branding is not permitted without an agreement from the Pine Store Ltd. This applies to both goods in physical or digital form.\nProjects, events or other engagements sponsored by PINE64 Community need to clearly indicate PINE64’s relation to the sponsorship by proceeding the logotype with text to the effect of “Sponsored by” or placing PINE64 branding in a dedicated “Sponsors” section. See 3.1 for details\nWe will seek any and all legal measures to enforce compliance with the use of all our copyrights and the PINE64 trademark.\n3.1. Commercial and affiliate use or as part of sponsorship Any use of the PINE64 logo and brand name in digital form should adhere to guidelines in section 1. PINE64 partner projects, business partners, affiliate programs, sponsored programs or events, etc. are welcome to reach out to PINE64 representatives and/ or Pine Store Ltd. staff members for graphical assets (e.g. the logo and logotype) and to consult usage.\nUse of the PINE64 logo and branding on physical merchandise, such as T-shirts, hoodies, caps, cups, etc. needs to include a registered trademark symbol ® following the banding.\nThe PINE64 logo and brand name must appear less prominent than the business’ or project’s logo and brand name. The purpose for using the PINE64 logo or brand name needs to be indicated on a business’ or project’s website. In example, if the purpose of using PINE64 branding is to indicate partnership, then our branding should be preceded by text to the effect of “In partnership with PINE64” or by placing our branding in a dedicated “Partners” section on a website.\nIn the case of sponsorship, sponsors are asked to include an identification of PINE64’s affinity with the said sponsored project. This includes, but is not limited to, placing PINE64 logo and/ logotype in a “Sponsors” section or being processed by “Sponsored by” to indicate sponsorship.\n3.2 Applying for inclusion of branding in commercial application or sponsorship For business, partnership or sponsorship inquiries please email: info@pine64.org Applications are reviewed on a case-by-case basis.\n3.3 Examples of appropriate commercial, sponsorship or affiliate usage Including PINE64 logo and brand name on a dedicated “sponsors” page or in a designated “sponsors” section of a webpage Including PINE64 logo and brand name on a partner project’s website, with preceding text to the effect of “in partnership with PINE64” or in a designated “partners” section Including PINE64 logo and brand name on physical merchandise with a registered trademark symbol ® Including PINE64 logo on product packaging to indicate compatibility with PINE64 hardware Including PINE64 logo and brand name in paid software and associated promotional materials (e.g. on business’ website), to indicate compatibility with PINE64 hardware Including PINE64 logo as part of promotional materials by partner projects or affiliated businesses upon prior agreement 3.4 Restrictions to commercial usage No business, sponsored project or affiliate may use the PINE64 logo and logotype to mislead existing or prospectus PINE64 community members into believing that software, community service, social media account, website, forum, subreddit, chat, social media account, etc., is representative of or run by official spokespersons of the PINE64 community or the Pine Store Ltd. staff members. We reserve the right to request a sponsored event, affiliate program, business or partner project to remove PINE64 branding under particular circumstances.\n4. Creation of derivative logos and logotypes Anyone is allowed to create PINE64 derivatives for personal or community usage. This extends to any form of artwork, community-made mockups or any other clearly identifiable community-activity that does not mislead existing or prospectus community members to believe it is PINE64 official material.\nDerivatives of the PINE64 logo and banding are permitted for non-commercial usage, granted they do not mislead prospectus or existing PINE64 community members into believing the material is PINE64 sanctioned or issued by PINE64. Derivatives of the logo and branding may not be used in a context that could cause brand damage nor for commercial purposes.\nDerivatives of PINE64 branding may still be subject to our copyright and as such need to adhere to restrictions outlined in section 2.2. We may request the removal of PINE64 logo or logotype derivatives if we feel that they are misused, used for commercial purposes or result in damage to our brand name.\nWe strongly advise anyone willing to create a derivative of our logo or brand name to reach out to a PINE64 Community associate or a Pine Store Ltd. staff member.\n","permalink":"/community/Brand_and_logo/","tags":null,"title":"PINE64 brand and logo"},{"categories":null,"contents":"These rules apply to all official PINE64 platforms and protocols facilitating social interactions, and will be enforced by moderators at all times. Failure to comply with these rules may result in a temporary or permanent ban from all PINE64 community platforms. If deemed necessary, a permanent ban can be issued without a prior notice. In extreme circumstances - such as those involving threats or hate speech - the Pine Store reserves the right to deny service to the offending party and notify local or regional authorities.\nForeword We trust in people’s common sense. There are intangible subtleties in human interactions that make a behaviour ‘OK’ at one time but not at others, and no artificial list of social-engagement rules, no matter how extensive, could capture this complexity accurately. To this end, we ask that you stay mindful of people’s sensitivities and address others respectfully at all times. Moderators are tasked with facilitating discussion, maintaining order and keeping the debate on-topic. They also have the necessary tools to enforce these rules at their discretion. The official forum, subreddit(s) and some chat protocols have systems dedicated to issuing warnings. In the absence of a formal moderation system, a moderator may reach out to a user directly via PM/ DM to issue a warning. In extreme circumstances, moderation actions will be taken without issuing prior warnings. Lastly, keep in mind that moderators have no power to make someone a friendly or nice human being (this was the said person’s parents\u0026rsquo; job). Being an unsympathetic or crude person is not an actionable offense from a moderation standpoint. Hint: some chat protocols also give you the option to mute messages from select users.\n1) General Rules Read the rules before posting on the forum, the subreddit(s) or engaging in the chat(s). Be respectful to other community members. Discourse is always a good thing, and sharing your opinions and insight is valuable to us and our user base. But how you engage with others is just as important as the ideas you share. We pride ourselves on this being a friendly community, and we will take measures to maintain it this way. Stay on topic. If a topic is set for a forum thread or discussion group/ channel then stick to it. Want to talk about something else? - there is an #offtopic chat on our Discord and IRC, and a Community and Events section on the forums. Write in English. Unless the subforum or chat specifies a different language, please stick to using English. There are numerous unofficial PINE64-product forums and chats catering to end-users who prefer communicating in a different language. If there isn’t a discussion group in your native tongue, why not start one? Watch your language. Some of our community members are younger than others; expletives are not necessary to communicate your viewpoints or experience. Please avoid using curse words, thank you. Use the search feature before posting or asking. The official PINE64 form and various chat protocols offer a search feature. If you’re looking for information, before you ask, try searching for the key words related to your query first - it is likely the topic you’re interested in has already been discussed. Obey platform-specific rules. Some communication platforms may have additional rules in place. For instance, you may not ping everyone in Discord chat using the @everyone function or paste lengthy log print-outs in Matrix. Where applicable, chat or forum-specific rules need to be followed. Ask If you are unsure. If you are unsure about where to best ask your question, or you are not sure if the topic is compliant with our rules and code of conduct, then please first reach out to someone on our moderation team. Moderators are always clearly demarcated on the various social interaction platforms. Stay on-topic. The chats and forum have clearly designated topics related to hardware and software. It is expected that you stay on-topic in the individual chats or forum sub-sections, and that you refrain from posting off-comments that divert the discussion towards an irrelevant subject (sometimes called \u0026lsquo;hijacking\u0026rsquo;). Some chat platforms offer an \u0026lsquo;off-topic\u0026rsquo; channel, and here on the forum there is a \u0026lsquo;community\u0026rsquo; sub-section, where subjects not directly related to hardware and software can be discussed (granted it does not violate any of the rules contained within this post). 2) Form and Content Use standard formatting. You should adhere to platform standard formatting, such as default font, font-size, font-colour, line spacing, etc. Content written in all CAPS or in rainbow colours is at a risk of being permanently removed by moderators. Making your writing easily legible also helps with getting your query answered. Describe your problem and don’t ask if you may ask a question. When stating your query, make sure to describe the issues you’re experiencing and the trouble-shooting steps you already attempted. In the chat: don’t ask for permission to ask, just state your problem. If your question is directed at a particular person, make sure to use @ their username or handle to get their attention. Do not post any knowingly false or inaccurate material. This is self-explanatory. Posting information that is false may get you suspended or banned from our platforms. Do not post or distribute copyrighted or stolen material. Links to stolen material, be it images, video, plagiarized written content or pirated software will be removed immediately. Posting such content may result in a temporary or permanent suspension from all our PINE64 community platforms. Signatures are allowed on the forum. Please be mindful that your signature has to comply with all rules, just as any other content you submit on the official forum. You may, however, be asked by a member of the moderation team to alter your forum signature if it affects legibility of posted content. No advertisements of non-FOSS and commercial products. You are welcome to let people know about your FOSS project, as well as any FOSS/OSH hardware project, but other types of advertisements will be removed immediately. If deemed as spam, posting such content may result in a temporary or permanent ban on all our platforms. Images and other media are best shared via links. It is always best to upload your videos or images and link them on the forum or in the chats. While attachments can be uploaded on the forum, they are limited to 2MB total per post. The different chat protocols handle attachments differently, which may lead to the content not displaying across the chat protocol bridge. No politics, religion or other sensitive topics is permissible on any of our platforms. Simply put, there are better places to discuss such topics. This rule also applies to #OffTopic chat and Community and Events subforum. Posts referring to such subject matter will be removed and may result in a warning, and even a temporary ban if the activity does not cease. No offensive nicknames, account names or online handles. If your online handle includes curse words, inappropriate imagery, inappropriate or offensive mockery, or otherwise relates to sensitive subject matter you may be asked to change your handle (or the Admin may change it for you). Not complying with the request will be met with a warning, followed by a ban on all platforms. Moderation of heated discussions. In general, if a discussion is heated (and doesn’t violate any of our rules or general code of conduct) but productive, then the moderation team will not intervene. There are, however, instances where a heated discussion is either moot or likely to take a turn for the worse; in such an event a moderator may ask for a halt to the conversation. One moderator may deem a heated discussion to be in a good spirit, while another moderator may ask for the discussion to cease. The decision to stop the conversation is completely at the moderator’s discretion. 3) Spam, Illegal and Inappropriate Content Automated spam (bots). We employ an automated spam protection as well as other measures that prevent new accounts from spamming the official PINE64 forum. New user’s posts need to be manually approved by the moderation team for a period of 3 days. Automated spam in the chats needs to be reported to the moderation team. We always strive to remove the spam and the bots as soon as possible. An IP associated with spam bots will be IP-banned. Spamming by end-users. Accidental or uninformed ‘spam’ - such as, for instance, pastes of lengthy log print-outs - may be removed by moderators, if it affects legibility of the chat. Use pastebin or similar to share a link with logs. Trolling. Trolling is defined as posting inflammatory messages to cause havoc in the community. Posting such content will result in a temporary or permanent ban from all PINE64 community platforms. Illegal content of any kind will be removed immediately and lead to permanent ban on all our platforms. If you encounter any illegal content on the official forum, subreddit or in the chat please report it immediately to the moderation team. In instances where it is applicable, the content itself and the associated account which submitted the post will be reported to the relevant regulator or local authorities. Sexual content. Any form of sexual content - in written, video or photographic format - is not allowed on our platforms. Posting sexual content will result in an instant ban on all PINE64 platforms. 4) Threats, Hate Speech, Bullying and Harassment Threats of any kind will result in an instant ban from all PINE64 platforms. Threats made may also be reported to local or regional authorities by the moderation team, if they are deemed legitimate or/ and a cause of psychological distress. Any form of hate speech will result in an instantaneous ban on all our platforms and may be reported to local or regional authorities by the moderation team. Hate speech is a crime in most of the civilized world. Discrimination of any kind. Any forms or discrimination including, but not limited to, misogyny, sexism, racism, xeniophobia and agism will result in an instant ban across all of PINE64 platforms. Bullying. We will not stand for bullying of any kind on our community communication platforms. Every community member can rest assured that they can express themselves and their viewpoints without being made fun of or ridiculed. If you have been the subject of or witnessed to behaviour, please report it to the moderation team. Bullying will result in an instant ban on all PINE64 platforms. Harassment, defined as any behaviour aimed at intimidating or humiliating another community member, needs to be immediately reported to the moderation team. If moderators determine that the offending party’s actions were designed to purposefully humiliate and intimidate another community member, then a subsequent ban from all PINE64 platforms will be enforced. Slander of fellow community members, Pine Store contractors and moderation team members will result in warning and, if the situation is not rectified, a permanent ban spanning all PINE64 social platforms. Slander is defined as: a knowingly false statement designed to damage reputation. 5) Privacy Private details. Any materials made public on purpose or by accident which contains private or otherwise identifying information will be removed from our platform without prior notice. We define private details as information that includes, but is not limited to, phone numbers, emails, shipping addresses or IP address. For example: if you post a video of an unboxing where you inadvertently show your shipping address, the moderation team will pull the video down to preserve your privacy. If you encounter such content, please notify the moderation team. Materials under NDA or Embargo. Any confidential materials issued under an NDA are subject to removal from our community platforms without notifying the original poster. Such materials may include documents (e.g. schematics), schematics of unreleased devices, images of prototypes or written descriptions of unannounced devices. 6) Software Feedback Software feedback. We and our partner projects value your feedback, but this feedback needs to be communicated in a structured and respectful manner. When addressing developers on our platforms please make sure to formulate your feedback and criticism in a constructive manner. Everyone has their favorite distribution, desktop environment and software implementations. This, however, doesn’t mean that alternatives to your favorite software should be taunted or ridiculed; ultimately, everyone is working towards a common goal and everyone’s work ought to be respected. In short, stay respectful of people’s work. Software feature requests, similarly to feedback, should be relayed in a respectful and considerate manner. Keep in mind that many developers working on PINE64 hardware do so in their spare time, on limited resources and are offering their software as a service to this community. No user has ‘a right to demand’ inclusion of software features. Reporting bugs. The PINE64 official forum and chats aren’t the ideal place to report bugs or other software issues. You are, of course, welcome to notify developers of the issues you encountered on the forum or in the chats, but ultimately this should be accompanied by submission of a bug report on GitHub and the software project’s forum. Adhere to partner project’s rules when engaging with their community on their social interaction platforms. Partner project’s forums and chats may be subject to different communication rules than our own; we ask you to stay mindful of this when discussing software designed for our devices outside of the PINE64 community platform. ","permalink":"/community/Rules/","tags":null,"title":"PINE64 Community Rules and Code of Conduct"},{"categories":["Laptops"],"contents":" A Thin and Light Open Source ARM 64-bit Notebook for Tinkering The Pinebook is an 11.6″ notebook powered by the same quad-core ARM Cortex A53 64-Bit Processor used in our popular PINE A64 Single Board Computer. It is very lightweight, hackable and comes equipped with a full-sized keyboard and large multi-touch trackpad. It runs numerous mainline Linux distributions as well as *BSD and Android. The most recent iteration has received an upgrade in the form of a 1080p IPS panel.\nAs a new open source platform, Pinebook development is an ongoing process and represents a great opportunity to get involved with computing on a different level, to customize and personalize the portable computer experience, to understand what is going on beneath the surface. If you are looking for a device in a convenient laptop form-factor that you wish to tinker with, then it is safe to say the Pinebook is the right device for you. We do no wish to discourage anyone from getting the Pinebook, but it is not a daily driver, so if you are looking to replace your current work or school laptop it may be wise to look elsewhere.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.152 GHz GPU ARM Mali 400 MP2 GPU Memory 2GB LPDDR3 RAM Display 1080p IPS panel Storage Bootable Micro SD slot 16GB of eMMC (upgradable) Connections HD digital video out 2x USB 2.0 Host Lithium polymer battery (10000mAH) Stereo speakers 802.11 b/g/n WiFi with Bluetooth 4.0 3.5mm headphone jack Microphone 0.3 MP front-facing camera Full-sized keyboard Large trackpad 3.5mm OD/1.35mm ID (5V 3A) port Large 10,000 mAh Battery Large 10,000 mAh battery to give all day battery life\n1080p IPS panel 11.6\u0026quot; 1080p IPS display\nRepairability You can find parts for the Pinebook on the store to fully repair the device\nPortable The Pinebook’s light weight and small size make it a extremely portable machine\nDocumentation Pinebook Schematics and certifications Accessories Serial Cable Serial console powered by CH340 chipset enables USB-to-Serial-communication through the earphone jack for development. Resources YouTube: Pinebook review showcasing Q4OS YouTube: Seytonic’s review of the Pinebook YouTube: MUO review of the Pinebook ","permalink":"/devices/pinebook/","tags":null,"title":"Pinebook"},{"categories":null,"contents":" The Pinebook\nThe Pinebook is an 11.6″ or 11.6″ with 1080P IPS panel or 14″ notebook powered by the same quad-core ARM Cortex A53 64-Bit Processor used in our popular PINE A64 Single Board Computer. It is very lightweight, hackable and comes equipped with a full-sized keyboard and large multi-touch trackpad. It runs numerous mainline Linux distributions as well as *BSD and Android.\nVariants The following variants exist of the Pinebook:\nPinebook 11.6″ Pinebook 11.6″ 1080p Pinebook 14″ More information can be found on the sunxi wiki.\nSoftware This page contains a list of all available releases and tools for the Pinebook.\nLinux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. To learn more about AOSC, please visit the official AOSC website.\nDownload:\nhttps://aosc.io/downloads/ Default credentials aosc anthon Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored. To find out more about Armbian and available download options please visit the Armbian ROCK64 site.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ✅ ✅ Download:\nhttps://www.armbian.com/pinebook-a64/ Default credentials root 1234 Debian Debian is an operating system and a distribution of Free Software. The forum thread for release can be found here.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ✅ ✅ Download:\nDebian 11 Bullseye (recommended) Debian 12 Bookworm Daily netboot images Installation:\nThe Readme provides info about concatenating firmware.pinebook.img.gz + partition.img.gz to create a bootable installer image. Notes:\nInstaller offers automatic partitioning and full-disk encryption (LUKS), but only manual partitioning with a single ext4 partition has been confirmed to work. Bootloader must be installed separately after installation, before rebooting. WiFi driver kernel module must be provided during installation, or a USB network adapter used. (Android USB tethering works, with network driver rndis_host). See also: Debian Netboot installer on the 1080P Pinebook under Software releases DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the ROCK64 build on the PINE64 forum thread.\nDownload:\nDebian 11 Bullseye (supports the microSD card and eMMC, 4GB or more) Debian 12 Bookworm (supports the microSD card and eMMC, 4GB or more) Default credentials root dietpi Kali Kali Linux is an Advanced Penetration Testing Linux distribution used for Penetration Testing, Ethical Hacking and network security assessments.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ✅ ✅ Download:\nhttps://www.kali.org/get-kali/#kali-arm Default credentials kali kali Slackware Slackware is a very old, interesting, convenient and easy distribution. Visit the project’s website here (https://fail.pp.ua). You can follow the ongoing discussion about Slackware on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=9439).\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ❓ ✅ ❓ Download:\nDirect download from developer KRT site and look for slarm64-current-aarch64-xfce-rootfs-xxxxxxxx-x.x.xx-pinebook-build-xxxxxxxx.img.lrz Default credentials Root user root/password BSD Image Releases NetBSD NetBSD community build. To learn more about NetBSD please visit the NetBSD main page.\nDownload:\nDirect download latest release build from NetBSD by select 64bit - Pinebook Compatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ❓ ❓ Notes:\nInstructions concerning enabling SSH can be found here Default credentials root (SSH and TTY) [none] OpenBSD OpenBSD 6.6-snapshot, Community Build Image (FVWM2 WM). To learn more about OpenBSD please visit OpenBSD main page. If you need more information please ping: https://forum.pine64.org/member.php?action=profile\u0026uid=12423.\nWarning Outdated release Download:\nSHA256: Community member elewarr’s Dropbox Image: Community member elewarr’s Dropbox Default credentials pine64 (SSH and TTY) pine64 root pine64 Android Image Releases Android 7.x Android 7.1 Community Build Image [microSD Boot] by ayufan. It only works on the 14.1\u0026quot; and 11.6\u0026quot; Pinebook, not applicable to 1080P 11.6\u0026rsquo; Pinebook. Special thanks to ayufan, Icenowy, lennyraposo, longsleep, lukasz, tkaiser, Xalius and PINE64 community contributors. Please use good random IO access performance microSD card such as the Samsung EVO when trying out Android 7.1.\nWarning Outdated release Download:\nayufan’s GitHub, look for android-7.1-pine-a64-pinebook-x.x.x-xx.img.gz (for microSD cards with 4GB or more) Notes:\nPlease allows some time (around 5 minutes) for the initialization process on the first boot. Android 6.x eMMC Android 6.0.1 Rootable build, online update (OTA) only works when the build is not rooted. The LCD resolution is 1366 x 768.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ❌ ✅ Warning Outdated release Download:\nRooted image (for microSD cards with 4GB or more) from pine64.org (776MB, MD5 of the Gzip file C99BF459C6724BA73F12C532E87A8BA5, build 20170605) Notes:\nmicroSD to eMMC Android 6.0.1 Rootable build. The LCD resolution is 1920 x 1080.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ❌ ✅ ❌ Warning Outdated release Download:\nRooted image (for microSD cards with 4GB or more) from pine64.org (595MB, MD5 of the Gzip file E433A148CEBD743EADE6CAA765331A4B, build 20181001) Notes:\nmicroSD to eMMC Android 6.0.1 Rootable build. The LCD resolution is 1920 x 1080. Please use an high performance microSD card for Android. Please ignore the warning message regarding an corrupted SD on the home screen in the upper left corner.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ❌ ✅ ❌ Warning Outdated release Download:\nFor 8GB microSD cards from pine64.org (553MB, MD5 of the Gzip file CD27DF6083E6A4A5E7C8B986EB92FAA7, build 20181001) For 16GB microSD cards from pine64.org (703MB, MD5 of the Gzip file 1376AAE8382E96FD7B45B0998A5CD6E9, build 20181001) For 32GB microSD cards from pine64.org (867MB, MD5 of the Gzip file B54E7F323B316750654E385B078AEC58, build 20181001) For 64GB microSD cards from pine64.org (734MB, MD5 of the Gzip file C8DBC6293EB51E58F91E27364C8C587D, build 20181001) Notes:\nmicroSD boot /e/ /e/OS community build. To learn more about /e/OS, please visit the official website. Please check out this article on the Pinebook /e/ build. For a thread discussion please visit the PINE64 forum\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ❌ ✅ ❌ Warning Outdated release Download:\nDirect download from pine64.org (685MB, MD5 of the GZip file: 4DC46A4E3ED2B47F4830E96DFCBBC6D8) Linux BSP SDK Download:\nLinux BSP 4.0 from pine64.org (4.67GB, MD5 of the TAR-GZip file 802D7C92D27177CBD17567359F9845A7) Linux BSP 3.0 from pine64.org (4.18GB, MD5 of the TAR-GZip file 898ACF446851DF3BE7B643F62CE3CE84) Linux BSP 2.0, kernel v3.10 (including GPL compliance header) from pine64.org (6.41GB, MD5 of the TAR-GZip file 2EE11C9AED246C17995493F213A6A6DA) Android SDK Android Marshmallow (v6.0)\nDownload:\nDirect Download from pine64.org (15.92GB, MD5 of the Zip file 12362D0B63EBF29FC363A50A942346D5) Compatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ❓ ❓ Other resources Mali_Driver Allwinner PhoenixCard Bootable SD-Card Creator Allwinner DragonFace V2.2.5 software that will let you edit and modify A64 Android Build PhoenixCard image (Direct download at Mega) FAQ and tips Key left of Z ( \\ | ) How to map the key next to Z to the symbols on \\ and | (rather than \u0026lt;\u0026gt;) ?\nChoose the alternative international US keyboard layout and variant. The name will depend on you desktop environment:\nEnglish (US, alt. intl.) English (US, international AltGr Unicode combining, alternative) English (US, alternative international) Note keyboard variants with similar names as the ones above change the upper left key for ` and ~. You have to press that key twice to get the desired char. This happens with the alt-intl variant. Choose the altgr-intl variant (or however it is called in your desktop environment) and it should work as expected. To set the keyboard layout and variant in the terminal for X-Windows use:\nsetxkbmap -layout us -variant altgr-intl The Archlinux Wiki has some good help if you need to tweak your layout further [https://wiki.archlinux.org/index.php/Xorg/Keyboard_configuration#Setting_keyboard_layout]\nKey between Fn and Alt (Menu) How to map the key between Fn and Alt to SUPER / META ?\nThe initial setup in many desktop environments maps the key between Fn and Alt to MENU. Although the menu key can be useful as well (e.g. spell correction in the browser) many desktop environments and window manager use the Super key for many other useful functions. And users are probably more used to have the META key near Ctrl and Alt.\nIn X-windows the following command maps the key between Fn and Alt to META and the Caps-Lock key to MENU.\nsetxkbmap -option caps:menu,altwin:alt_super_win Set display brightness in the terminal To set the display brightness in the terminal use xbacklight (if available in your distro):\nxbacklight -setXX XX is the percentage (%) of brightness. E.g. for 70% brightness\nxbacklight -set70 If you use LXQt you can also use:\npkexec lxqt-backlight_backend --inc pkexec lxqt-backlight_backend --dec For an alternative solution please see the scripts discussed in this thread: [https://forum.pine64.org/showthread.php?tid=5062]\nGet battery % in CLI As ACPI is not compatible with ARM, to gather the % battery this can be used:\ncat /sys/class/power_supply/battery/capacity Firefox font size How to get a useful font size with firefox ?\nTo have every web page displayed in a larger more readable font size type about:config in the search bar and confirm on the first page that you want to make changes. Then search for this parameter:\nlayout.css.devPixelsPerPx and modify the value (right click) to something between 1.2 to 1.5 depending on your preferences.\nIn addition to that you can set in Preferences -\u0026gt; General -\u0026gt; Fonts \u0026amp; Color -\u0026gt; Advanced Minimum font size to 16\nDisable wireless power management If having issues with wifi connectivity, try to disable power management in the 8723cs module options, adding rtw_power_mgnt=0 in /etc/modprobe.d/8723cs.conf\noptions 8723cs rtw_initmac=00:ba:ch:16:85:46 rtw_power_mgnt=0 Touchpad acceleration and scroll direction To set touchpad parameters from the cli you can use the command xinput. To use it correctly you first need to determine the device id / name for your touchpad. To do so, use:\nxinput list You are looking for a line like this:\nHAILUCK CO.,LTD USB KEYBOARD Mouse id=7\t[slave pointer (2)] With the device id = 7 found you can list the parameters that can be set with xinput.\nxinput list-props 7 The result looks similar to this:\ndevice \u0026#39;HAILUCK CO.,LTD USB KEYBOARD Mouse\u0026#39;: ... libinput Natural Scrolling Enabled (256):\t0 ... libinput Accel Speed (265):\t0.000000 ... To change the parameter use xinput set-prop\nTo set reverse scrolling for the touchpad use this command\nxinput set-prop 7 \u0026#39;libinput Natural Scrolling Enabled\u0026#39; 1 To set mouse speed\nxinput set-prop 7 \u0026#39;libinput Accel Speed\u0026#39; 0.95 Check different numbers for 0.95 to meet your needs.\nFor more details on xinput and mouse speed also see the Archlinux Wiki [https://wiki.archlinux.org/index.php/Mouse_acceleration#Using_xinput]\nProlong battery life How to reduce the max voltage the battery is charged to:\n$ cd /sys/class/power_supply/axp20x-battery Note The voltage_max_design is writable by root, values are in microvolts. The factory value is 4200000 or 4.2V on my device. This charges to 100% capacity. $ cat voltage_max_design 4200000 Check the factory value on your device, and record it if it is different. The value depends on the battery installed. You can reduce it to 4.1 V by running the following Linux command as root:\n$ echo 4100000 \u0026gt; voltage_max_design If you are fully charged and on AC, the battery will start discharging until it reaches 4.1 V. This will be about 98% capacity on my device. This prolongs the battery life when you don’t need the extra few minutes of offline power. The Linux driver will not let you set the maximum voltage to a value smaller than 4.1V (as of Linux kernel 6.3.8).\nThe setting seems to be retained across reboots.\nService guides These are instruction guides for the disassembly:\nNote The installation process is the reverse order of removal guide 11.6″ Pinebook:\nLithium Battery Pack Removal Guide LCD Panel Screen Removal Guide eMMC Module Removal Guide 14″ Pinebook:\nLithium Battery Pack Removal Guide LCD Panel Screen Removal Guide eMMC Module Removal Removal Guide Further information Specifications\nDatasheets\nSchematics and certifications\nOther resources\nSpecifications The Pinebook is based on the Allwinner A64.\nDimensions:\n299mm x 200mm x 12mm (WxDxH - 11″ Pinebook); 329mm x 220mm x 12mm (WxDxH - 14″ Pinebook) Weight:\n1.04Kg (11″ Pinebook); 1.26Kg (14″ Pinebook) Input Power:\nDC 5V @ 3A CPU Architecture:\nQuad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture:\nARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard Open source driver System Memory:\nSystem RAM Memory: 2GB Storage Memory: 16GB eMMC module, can be upgrade to 32GB or 64GB eMMC module Battery:\nLithium Polymer Battery (10,000 mAh; 9,600 mAh in later batches) Video:\nMini Digital Video Port (Type A - mini) Audio:\n3.5mm stereo earphone/microphone plug Network:\nWiFi 802.11 b/g/n with Bluetooth 4.0 10/100 Mbps USB Ethernet Dongle (Optional) Storage:\nmicroSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t2 USB2.0 Host port Expansion Ports:\nmini Digital Video port microSD card port - support SD, SDHC, SDXC uo to 256GB 2x USB 2.0 port earphone plug with UART console mux circuit Datasheets Allwinner A64 SoC:\nAllwinner A64 SoC Brief Introduction Allwinner A64 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit):\nAXP803 PMIC Datasheet LPDDR3:\nAllwinner LPDDR3 Datasheet Foresee LPDDR3 Datasheet Samsung LPDDR3 Datasheet Hynix LPDDR3 Datasheet eMMC:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR flash:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet WiFi/BT module:\nRealtek RTL8723BS WiFi with BT SDIO LCD Panel:\n1920x1080 1080P 11.6″ IPS LCD Panel datasheet 1366x768 11.6″ TFT LCD Panel datasheet 1366x768 14″ TFT LCD Panel datasheet Touchpad:\nTouchpad Specification for 11.6″ model Touchpad Specification for 14″ model Camera sensor:\nVGA Camera module specification VGA Camera Sensor Data Sheet Lithium battery:\n10000 mAH Lithium Battery Specification for 11.6″ model 10000 mAH Lithium Battery Specification for 14″ model Schematics and certifications Mainboard schematics:\nPinebook Mainboard schematics Daughter Board schematics:\nPinebook Daughter board schematics Serial Console Earphone Jack pinout:\nPinebook Serial Console Earphone Jack pinout Certifications:\nPinebook FCC Certificate Pinebook FCC ID-Spread Spectrum Transmitter Certificate Pinebook FCC ID-Digital Transmission System Certificate Pinebook CE Certificate Pinebook RoHS Certificate Other resources Linux Sunxi Wiki page on Pinebook Pinebook Linux Github by ayufan Pinebook Android Github by ayufan Armbian’s Pinebook Page ","permalink":"/documentation/Pinebook/_full/","tags":null,"title":"Pinebook (Single Page)"},{"categories":["Laptops"],"contents":" A Powerful, Metal and Open Source ARM 64-Bit Laptop for Work, School or Fun The Pinebook Pro is meant to deliver solid day-to-day Linux or *BSD experience and to be a compelling alternative to mid-ranged Chromebooks that people convert into Linux laptops. In contrast to most mid-ranged Chromebooks however, the Pinebook Pro comes with an IPS 1080p 14″ LCD panel, a premium magnesium alloy shell, 64/128GB of eMMC storage* (more on this later – see asterisk below), a 10,000 mAh capacity battery and the modularity / hackability that only an open source project can deliver – such as the unpopulated PCIe m.2 NVMe slot (an optional feature which requires an optional adapter). The USB-C port on the Pinebook Pro, apart from being able to transmit data and charge the unit, is also capable of digital video output up-to 4K at 60hz.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.4GHz + 2 x ARM Cortex A72 cores @ 1.8 GHz GPU ARM Mali T860 MP4 GPU Memory 4GB LPDDR4 RAM Display 1080p IPS Panel Body Magnesium alloy shell body Storage Bootable microSD slot 64GB of eMMC (upgradable) M.2 NVMe SSD slot (requires optional adapter) SPI flash 128Mbit Connections HD Digital Video Out via USB-C USB 2.0 Host USB 3.0 Host USB-C (Data, Power and Video out) Lithium Polymer Battery (10000mAH) Stereo Speakers Built-in 802.11ac WiFi with Bluetooth 5.0 Headphone Jack Microphone Front-Facing Camera (1080p) ISO \u0026amp; ANSI Keyboard Variants Privacy Switches for Camera, Microphones and BT/WiFi Large Trackpad UART Access via Audio Jack Barrel Power (5V 3A) Port NVMe SSD Expansion Option With a optional adapter it is possible to install a M.2 NVMe SSD into the Pinebook Pro\n1080p IPS Panel Bright 14\u0026quot; 1080p IPS display gives you a excellent viewing experience\nRepairability You can find parts for the Pinebook Pro on the store to fully repair the device\nPrivacy The Pinebook Pro’s keyboard firmware includes key combinations to disable the Camera, Microphones, and Bluetooth and WiFi\nStores Global Global: Laptop accessories Global: Accessories Global: Spare parts Affiliates Documentation Pinebook Pro Schematics and certifications Accessories Serial Cable Serial console powered by CH340 chipset enables USB-to-Serial-communication through the earphone jack for development. Resources YouTube: DistroTube unboxing and review of the Pinebook Pro YouTube: Pinebook Pro teardown YouTube: Sabrent NVMe drive installation in the Pinebook Pro ","permalink":"/devices/pinebook_pro/","tags":null,"title":"Pinebook Pro"},{"categories":null,"contents":" Pinebook Pro running Debian with MATE\nThe Pinebook Pro is a Linux and *BSD ARM laptop from PINE64. It is built to be a compelling alternative to mid-ranged Chromebooks that people convert into Linux laptops.\nThe Pinebook Pro features an IPS 1080p 14″ LCD panel, a premium magnesium alloy shell, high capacity eMMC storage, a 10,000 mAh (9,600 mAh in later batches) capacity battery, and the modularity that only an open source project can deliver with the dimensions of 329mm x 220mm x 12mm (WxDxH). Key features include the Rockchip RK3399 SoC, USB-C for data, video-out and power-in (2.5 A at 5 V), privacy switches for the microphone, BT/WiFi module, camera and expandable storage via NVMe (PCIe x4) with an optional adapter.\nThe Pinebook Pro is equipped with 4 GB of LPDDR4 system memory, up to 128 GB of eMMC flash storage, and 128 Mbit of SPI boot flash. The I/O includes: 1 x micro SD card reader (bootable), 1 x USB 2.0, 1 x USB 3.0, 1 x USB Type-C host with DP 1.2 and power-in, PCI Express x4 for an M.2 NVMe SSD drive (requires an optional adapter), and serial console UART (via the headphone jack by setting an internal switch). The keyboard and touchpad both use the USB 2.0 protocol. The LCD panel uses the eDP MiPi display protocol.\nVersions Pinebook Pro v1 and v2 were prototype models that did not make it to the public. The \u0026ldquo;first batch\u0026rdquo; (first 100 forum pre-orders) onward are v2.1. [https://forum.pine64.org/showthread.php?tid=8111]\nSoftware Debian Installer\nInstalling Arch Linux ARM\nInstalling Void Linux ARM\nReleases\nQuick Start Manjaro\nTuning\nReleases This page contains a list of all available releases and tools for the Pinebook Pro.\nLinux OS Image Releases For information on how to install these images onto your device, please see the Getting started Page, which includes information on writing images to the device eMMC or an SD card\nArmbian Armbian is a base operating system platform for single board computers (SBCs) that other projects can trust to build upon. It is a lightweight Debian or Ubuntu based Linux distribution specialized for ARM development boards. Each system is compiled, assembled and optimized by the Armbian Build Tools. It has powerful build and software development tools to make custom builds and a vibrant community.\nDownload:\nThe Pinebook Pro Download Page Notes:\nIf you have any difficulties please visit our forum or come chat with us on IRC / Discord As of April 2023, Armbian only has Ubuntu images pre-made. However, using their tools to create a Debian image from scratch takes little expertise and results in an image that can be burned onto a USB stick or SD card. Their installer can then install it onto internal eMMC, including a working bootloader. Fedora Fedora Linux is a Linux distribution developed by the Fedora Project. It creates an innovative, free, and open source platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.\nInstallation:\nUsing this blog post it is possible to run Official Fedora on the Pinebook Pro Notes:\nUpstream Fedora uses the SPI flash on the Pinebook Pro to manage U-Boot. Arch Linux ARM Official Installation See Installing Arch Linux ARM for instructions on how to install the official Arch Linux ARM.\npostmarketOS Official postmarketOS stable builds are available for the Pinebook Pro with the following interfaces:\nconsole GNOME KDE Plasma Desktop Phosh Sway It boots from microSD card and from eMMC.\nDownload location\nGet the stable image here: https://postmarketos.org/download/ (size: 103 MB to 775 MB)\nThe installer images allows setting up an encrypted installation on SD or eMMC.\nUsername and password\nDefault credentials user 147147 Kali Linux Official pre-built OS images of Kali Linux for the Pinebook Pro featuring all tools you’d expect from the distribution. It boots from microSD card and from eMMC.\nDownload location\nGet the latest image here: Direct download latest images from Offensive Security’s website (size: 3.1 GB)\nUsername and password\nDefault credentials kali kali R-Cade Retro Center’s R-Cade [USB / microSD / eMMC Boot]\nThe 4K Media Center Arcade RCade Features 100+ retro-gaming systems, a lightweight web browser, and full 4K UHD media playback DD image to USB, microSD, or eMMC and boot. Highly recommend using Etcher Direct download from Retro Center’s GitHub Username and password\nDefault credentials root retro DietPi DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the Pinebook Pro build on the PINE64 forum thread.\nDownload:\nDirect download of Trixie from dietpi.com Default credentials root dietpi openSUSE Download location\nGet the latest openSUSE Tumbleweed images for Pinebook Pro here: https://en.opensuse.org/HCL:Pinebook-Pro-RK3399. Credits to https://bugzilla.opensuse.org/show_bug.cgi?id=1194491.\nStep 1. Flash Tow-Boot to SPI Step 2. Flash openSUSE image to sd card \u0026amp; insert it Step 3. When it loads grub, press e and add the following line: devicetree /boot/dtb/rockchip/rk3399-pinebook-pro.dtb\nPress ctrl + x to boot\nWorks: display, WiFi Not tested: bluetooth Doesn’t work: audio\nYou may build RPMs and see if it fix issues from this repository: https://github.com/bengtfredh/pinebook-pro-copr\nDefault password for root is \u0026ldquo;linux\u0026rdquo;\nVoid Linux Images Void Linux packages U-Boot and a kernel for the Pinebook Pro, but does not distribute any images for the device.\nCameron Nemo (User:CameronNemo) distributes unofficial Void Linux images for the Pinebook Pro:\nglibc download musl download Some notes about the images:\nThey were released on 2022-05-30 (glibc) and 2022-06-10 (musl) They ship U-Boot 2022.04 and Linux 5.15 (with minimal patches) Meant to be uncompressed then flashed to either an SD card or the internal eMMC module The root partition is ~1.7GB, and must be expanded manually There are very few services enabled on the images by default: udev and some getty’s Default credentials root voidlinux Do It Yourself Warning This is not an official, nor supported way of using Void Linux on the Pinebook Pro. You can also manually install Void from a rootfs tarball: see instructions here.\nBSD NetBSD The image boots from microSD card and from eMMC. To learn more about NetBSD please visit NetBSD main page\nDownload location\nGet the latest image here: Direct download from NetBSD\nInstallation\nInstructions concerning enabling SSH can be found here.\nUsername and password\nDefault credentials root none OpenBSD The image boots from microSD card and from eMMC. To learn more about OpenBSD, please visit OpenBSD main page\nDownload location\nARM64 images, (including support for Pinebook Pro), can be found here OpenBSD arm64\nLinux Installer Releases Armbian You can use the Armbian Builder to generate your own Armbian images of various types.\nThe builder supports building any version of Debian and any version of Ubuntu with various desktop options:\nBudgie Cinnamon Deepin Enlightenment Gnome I3-wm Kde-plasma Mate Xfce Xmonad Debian Uses only the upstream kernel and firmware without special patches Display doesn’t always work properly on first boot of installer, usually fixed after a couple tries Requires adding the non-free component to your /etc/apt/sources.list file and installing the \u0026ldquo;firmware-linux\u0026rdquo; package for Wi-Fi and Bluetooth support. If your Pinebook Pro was part of the June/July 2022 batch, then you will need the \u0026ldquo;firmware-brcm80211\u0026rdquo; to accommodate the changed networking hardware. You will also need \u0026ldquo;brcmfmac43455-sdio.txt\u0026rdquo; in /lib/firmware/brcm, at least until it is included within firmware-brcm80211 upstream. Installer is loaded into RAM, can install onto the same media from which it’s booted Supports automatic partitioning and full disk encryption through LVM Installer currently doesn’t install a functional bootloader, leaving the installed system in an unbootable state until it’s manually added (if installed to eMMC, the system cannot be booted even to an SD card unless the eMMC is physically switched off or there is U-Boot in the SPI) The relevant files are built daily here and may sometimes be unavailable if the build system is having issues. The \u0026ldquo;README.concatenateable_images\u0026rdquo; file provides instructions on how to combine the partition.img.gz file with the firmware.pinebook-pro.rk3399.img.gz file in order to create a DD-able image.\nThe official images are not recommended yet until the display begins working consistently and the installer properly installs the bootloader. Building a Debian-based image via the Armbian builder on the other hand seems to work with no changes. Previously the best tool was Daniel Thompson’s Debian Installer, but unfortunately as of April 2023 some of the upstream kernel sources this tool used seem to no longer exist.\nGentoo There is a script that prepares a Gentoo arm64 stage 3 tarball for the Pinebook Pro. Unfortunately, this script is not currently functional, and requires extensive troubleshooting to make work. New instructions are currently being created and will be available here.\nWord to the wise\nCurrently, following the instructions on the Pinebook pro gentoo github page will not result in a functional system. Therefore it is necessary to follow the instructions given here. Please bear in mind that the Pinebook pro’s six arm cores and 4gb of ram are extremely anemic. For example, emerging the package net-libs/webkit-gtk in order to build the minimalist web-browser \u0026ldquo;surf\u0026rdquo;, a process which takes eighty minutes on an intel core i5-8250U with 8gb of ram, required eight hours of compile time, Basic installation alone can take 24 hours of compilation, dozens of reboots, and hours of troubleshooting. After that, even installing firefox would take 17 hours. Now that that’s out of the way, we may begin the installation.\nPreparing the bootloader\nInstalling a functional bootloader can be difficult. Luckily, the tow-boot project provides a UEFI-like experience for some arm-based devices. Furthermore, it is not neccesary install this bootloader manually, as it will continue to be useable even after the disk has been reformatted, as long as the bootloader remains unscathed.\nhttps://manjaro.org/downloads/arm/pinebook-pro/arm8-pinebook-pro-minimal/\nNo-matter where you intend to install gentoo, the bootloader should always be installed on the eMMC flash, although technically the SD card slot could also be used. Either way, install any of the official Manjaro arm disk images to the internal eMMC (there’s no reason not to use the minimal image, as you will not be using this OS for anything). You may use a second operating system installed on an SD-card, or the official Pine64 eMMC USB adapter. Boot into this operating system to ensure that the bootloader functions, but after that you have no further need of it.\nNext, if you already have an OS on an SD card, you can use that for installing gentoo. If you don’t, you may be pleasantly surprised to find that tow-boot is capable of booting from a USB drive. Therefore, you may install the same Manjaro image to your USB drive or SD card, and select it from the boot menu. You should now have an unused but bootable OS on the eMMC, and another bootable, usable OS on your external storage.\nPreparing the Disks\nLog into your host device as root with the following command:\nsudo su\nEnter your password.\nLet the device on which you intend to install gentoo be referred to hereafter as /dev/. Use the following command to prepare this disk for installation:\nfdisk -B /dev/\u0026lt;gentoo\u0026gt;\nNote Don’t just copy these commands! You should substitute for mmcblk2 for the internal eMMC flash storage. Note that the first block of the boot partition is block 62500. Delete all partitions, but do not re-format the disk. Create a new boot partition starting at 62500, and as it’s size select \u0026ldquo;+1GB\u0026rdquo;. Create a new swap partition. fdisk will try to start it at the beginning of the volume (before the boot partition) Instead, when it prompts you for the starting position, enter in the end sector of the boot partition. It should then tell you that this is within an existing partition, and recommend a slightly higher value. Press enter, and give for the size of the partition any value greater than \u0026ldquo;+4gb\u0026rdquo;. You need this much ram to be able to suspend your system, and emerge large packages. Don’t be stingy - you still have SD cards. I recommend \u0026ldquo;+8gb\u0026rdquo;.\nFinally, add a root partition starting at the end sector of the swap partition, and use the rest of the disk for it. That should be 50-60 GB depending on the size of your swap and boot partitions.\nLastly, press \u0026ldquo;t\u0026rdquo; to set the type of each partition. You may set partition 1 to type 6, 2 to type 82, and 3 to type 83.\nto set the partition types of the three partitions.\nlsblk\nto remind yourself which disk is /dev/ Write the filesystems to these three partitions with the commands:\nmkfs.vfat /dev/\u0026lt;gentoo\u0026gt;p1 mkswap /dev/\u0026lt;gentoo\u0026gt;p2 mkfs.ext4 /dev/\u0026lt;gentoo\u0026gt;p3 This may be a slightly different format if you’re installing to an USB stick.\nInstallation\nmake the directory for mounting the filesystem you just created. These should be made on the external OS.\nmkdir /mnt/gentoo mount /dev/\u0026lt;gentoo\u0026gt;p3 /mnt/gentoo cd into this directory and fire up links. Navigate to gentoo.org/downloads and select the stage 3 minimal stage 3 tarball. Download it to your current directory, or move it to that directory from wherever it has been downloaded to. Once you are in the correct directory, unpack the tarball.\ntar xpvf stage3-arm64-\u0026lt;blah blah blah\u0026gt;\nMount the boot partition.\nmount /dev/\u0026lt;gentoo\u0026gt;p1 /mnt/gentoo/boot\nChroot into the mounted directory and Install the operating system as per the AMD64 manual [https://wiki.gentoo.org/wiki/Handbook:AMD64]. Before you emerge anything, however, be sure to set your use flags as follows:\nnano /etc/portage/make.conf MAKEOPTS=\u0026#34;-j4 -l4\u0026#34; ACCEPT_KEYWORDS=\u0026#34;* **\u0026#34; ACCEPT_LICENSE=\u0026#34;*\u0026#34; USE=\u0026#34;X gtk bluetooth pulseaudio\u0026#34; You can use your own options instead of these if you know what you’re doing. It’s not super difficult.\nContinue installing the operating system, but stop just before emerging the @world set. I don’t know if this is necessary, but I haven’t had the time to try without doing this. Clone Jannik2099’s github repo. It doesn’t matter where, and run the script. If it fails run it a couple more times.\n`git clone https://github.com/Jannik2099/gentoo-pinebookpro\nDon’t follow any of Jannik’s other instructions. They appear to be out of date (no offense bro). Let me be clear: DO NOT INSTALL U-BOOT. I don’t know what will happen, but it won’t be an improvement over the existing boot-loader so don’t worry about it.\nFinish installing your system until you come to the kernel.\nCustom Kernel\nUse sys-kernel/gentoo-kernel-bin as your kernel. You will need to manually edit the kernel configuration. First, select it as your kernel.\neselect kernel list\nThis should list only one option. Otherwise, select the number matching linux-5.\u0026lt;whatever is latest\u0026gt;-gentoo-dist, and cd into the kernel source directory.\neselect kernel set \u0026lt;number\u0026gt; cd /usr/src/linux Begin the kernel configuration\nmake menuconfig\nAt this point, you’re almost on your own. I don’t know a strict cause-and-effect relationship between my kernel config and the behavior of my system. For starters, just go into platform selection and deselect everything except Rockchip platforms. Once you’re done save your configuration and exit. Make sure boot is mounted, and your fstab is set up with your swap mounted. Make sure dracut is installed.\nmake make modules make dtbs make install make modules install make dtbs_install ls /lib/modules dracut -f --kver \u0026lt;name of directory in /lib/modules matching your kernel, **not** the kernel name from eselect\u0026gt; emerge the package extlinux and run u-boot-update. Open the extlinux configuration file.\nnano /boot/extlinux/extlinux.conf\nAnd configure it as follows:\nLABEL \u0026lt;label of your choice, for example GENTOO ARM\u0026gt; KERNEL /\u0026lt;name of your vmlinuz kernel image. Include the slash, but be relative to boot, not root.\u0026gt; FDT /dtbs/\u0026lt;kernel-version\u0026gt;/rockchip/rk3399-pinebook-pro.dtb APPEND initrd=/\u0026lt;name of initramfs image\u0026gt; root=PARTUUID-\u0026lt;nboot partition’s PARTUUID, no quotes\u0026gt; rw rootwait You can use the blkid command to find the PARTUUID of every partition on the machine. None of this configuration is guaranteed to work, but it worked for me, and given enough fiddling you can get it to work as well.\nNow you should reboot the machine and see if it boots into gentoo. If it does: congratulations|If not, too bad. Try again.\nKali Linux There is a script to create official Kali Linux OS images for the Pinebook Pro. The script carries out the build process in entirety and is Pinebook Pro specific.\nInstallation\nPlease pull the latest Kali Linux install script from the project’s GitLab. For more information regarding building the OS image please read the README instruction at https://gitlab.com/kalilinux/build-scripts/kali-arm/blob/master/README.md NixOS You can follow the ongoing discussion about NixOS on the PINE64 forum. There is a good chance we will see Tier 1 support for aarch64, including the Pinebook Pro, in 2021 (see https://github.com/NixOS/rfcs/pull/87).\nInstallation\nThis is instructions to install NixOS on the Pinebook Pro: https://wiki.nixos.org/wiki/NixOS_on_ARM/PINE64_Pinebook_Pro Please pull the latest samueldr’s repository from the project’s GitHub. SkiffOS Installation\nInstructions to build/install on the Pinebook Pro: https://github.com/skiffos/SkiffOS/tree/master/configs/pine64/book Please pull the latest version from the project’s GitHub. Compiling the boot image takes approximately 30 minutes. Easily configure the kernel, compiler, etc with Buildroot. Pre-built ISOs will be available with the upcoming 2021.02 release. Slackware Slackware is the world’s oldest actively developed Linux distribution, providing a modern user land (applications) and Linux Kernel, within a more classic Unix Operating System environment.\nMore information can be found about Slackware in this 20 minute video.\nInstallation instructions.\nInstallation guide video\nUbuntu If you install Tow-Boot to the SPI, you may then be able to use generic arm64 install disks, such as those for Ubuntu. This is because Tow-Boot can use UEFI boot partitions. The arm64 builds of the Ubuntu installer \u0026ldquo;ISOs\u0026rdquo; can be found here. These can then be converted to UEFI bootable USB drives using a tool such as unetbootin or the Ubuntu \u0026ldquo;Startup Disk Creator\u0026rdquo;.\nUbuntu 22.04 does install and boot on a Pinebook Pro, however the speakers and wifi are non-functional. A USB wifi adapter can get you online.\nUpgrading such an install to 22.10 fixes the wifi. The graphics are broken in an odd way on first boot, but then functional after that. The speakers are still non-functional.\nA fresh install of 22.10 would presumably produce a similar result.\nQuick Start Manjaro When you first get your Pinebook Pro and boot it up for the first time, it’ll come with Manjaro using the KDE desktop. The Pinebook Pro is officially supported by the Manjaro ARM project, and support can be found on the Manjaro ARM forums.\nOn first boot, it will ask for certain information such as your timezone location, keyboard layout, username, password, and hostname. Most of these should be self-explanatory. Note that the hostname it asks for should be thought of as the \u0026ldquo;codename\u0026rdquo; of your machine, and if you don’t know what it’s about, you can make something up (use a single word, all lower case, no punctuation, e.g. \u0026ldquo;pbpro\u0026rdquo;).\nAfter you’re on the desktop, be sure to update it as soon as possible and reboot after updates are finished installing. If nothing appears when you click on the Networking icon in your system tray to connect to your Wi-Fi, ensure the Wi-Fi privacy switch is not disabled.\nDebian Installer This is an image creator and Debian installer that runs from an existing Linux OS and installs Debian Bullseye Installer can configure an encrypted rootfs and provides a choice of desktops, including the default Debian desktop based on Gnome 3 Strict adoption of upstream Debian packages (with exception of kernel and bootloaders) in order to provide a clean upgrade path as Bullseye matures Download at: https://github.com/daniel-thompson/pinebook-pro-debian-installer/ Pull requests welcome but for discussion and support please use the forum topic. Features Feature Status Notes Install to micro SD card Works Automatically expands to use all available space Install to eMMC Works Automatically adapts for 64GB and 128GB models Full disk encryption Works Run installer with CRYPT=yes. Requires kernel support and this support is missing in the original factory kernel so it it not possible to install a LUKS filesystem from the factory distro. You can make a temporary unencrypted install with this installer and then use the temporary OS to perform a full encypted install. Wifi Works Issues have been reported with WPA2 networks [https://forum.pine64.org/showthread.php?tid=8822] Firefox Works VLC Works Fn+ keys Work After updating mesa to 20.0.7-1 Current issues Issue Category Status Workaround Notes cdn-dp fec00000.dp: Direct firmware load for rockchip/dptx.bin failed with error -2 Debian issue https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857054 If having FDE, it fails to load at boot as the firmware is not included in initramfs Include the dptx.bin firmware in the initramfs See https://forum.pine64.org/showthread.php?tid=8487\u0026pid=57202#pid57202 Bluetooth doesn’t work bluetooth hci1: Direct firmware load for brcm/BCM4345C5.hcd failed with error -2 Copy those firmware https://gitlab.manjaro.org/manjaro-arm/packages/community/ap6256-firmware to /lib/firmware/brcm/. After that, Bluetooth works fine. It seems some firmware is missing. See https://forum.pine64.org/showthread.php?tid=8731\u0026pid=57525#pid57525 Suspend doesn’t work properly, when lid is closed, the laptops gets hot and dramatically dry the battery Install is preconfigured to use suspend-to-idle instead. This offers some power savings compared to normal running but suspend should only be used for short periods. # echo deep \u0026gt; /sys/power/mem_sleep PBP simply doesn’t wake up after \u0026lsquo;deep\u0026rsquo; sleep. Often very slow to wake from suspend: 30-60 seconds. Forum thread https://forum.pine64.org/showthread.php?tid=8822 Sometimes pressing the power key helps wake it up. Set this key to not trigger sleep/shutdown in the Desktop Environment config. Installing Arch Linux ARM These instructions can be followed to install Arch Linux ARM on an SD Card, USB Flash Drive, eMMC, or even NVMe if your U-Boot supports it (example Tow-Boot on SPI).\nCommands to be run as a normal user are prefixed with $, commands to be run as root (or with sudo) are prefixed with #. The target device is assumed to be /dev/sdb, adjust accordingly.\nPartitioning Flashing U-Boot Important While any build of U-Boot for the Pinebook Pro can be used, this tutorial uses Tow-Boot. The process of installing Tow-Boot is different from any other U-Boot build, so large parts of the partitioning section will need to be changed if you want to use something else. If you already have Tow-Boot installed via SPI, you can skip this step. Use fdisk to create a blank GPT partition table. /boot will be partition 1, and / will be partition 2. Download and extract the latest release of Tow-Boot for the Pinebook Pro from https://github.com/Tow-Boot/Tow-Boot/releases.\n$ wget https://github.com/Tow-Boot/Tow-Boot/releases/download/release-2021.10-004/pine64-pinebookPro-2021.10-004.tar.xz $ tar xf pine64-pinebookPro-2021.10-004.tar.xz Flash Tow-Boot to /dev/sdb (replace this with the device you actually intend to use).\n# dd if=pine64-pinebookPro-2021.10-004/shared.disk-image.img of=/dev/sdb bs=1M oflag=direct,sync This creates the partition table for the device, with the first partition serving to protect Tow-Boot. Do not move or write to this partition.\nCreating the partitions Use fdisk to add partitions to /dev/sdb.\n# fdisk /dev/sdb Create the /boot partition.\nType n to create a new partition. Press enter for partition number two. Press enter for the default start sector. Type +512M to make the new partition with 512 MB. Mark the /boot partition bootable.\nType x to enter expert mode. Type A to mark a partition bootable. Type 2 to select partition two. Type r to exit expert mode. Create the root partition.\nType n to create a new partition. Press enter for partition number three. Press enter for the default start sector. Press enter to fill the rest of the device. Write the changes to disk.\nType w to write the changes and exit. Formatting the partitions Format the /boot partition as a filesystem supported by your U-Boot. ext4 is recommended:\n# mkfs.ext4 /dev/sdb2 Format the root partition as any filesystem supported by Arch Linux ARM. btrfs for example:\n# mkfs.btrfs /dev/sdb3 Installing the root filesystem Mounting the partitions # mount /dev/sdb3 /mnt # mkdir /mnt/boot # mount /dev/sdb2 /mnt/boot Downloading and verifying the rootfs tarball Download the tarball and its PGP signature.\n$ wget http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} Import the Arch Linux ARM signing key.\n$ gpg --keyserver keyserver.ubuntu.com --recv-keys 68B3537F39A313B3E574D06777193F152BDBE6A6 Verify the tarball’s authenticity.\n$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig Verifying the authenticity of the tarball protects you in two ways:\nMakes sure the tarball came directly from Arch Linux ARM and was not tampered with Prevents you from using a corrupt tarball (for example from an interrupted download) Extracting and configuring the root filesystem Extracting the root filesystem # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt Editing fstab Find the partitions\u0026rsquo; UUIDs with blkid.\n# blkid /dev/sdb3 /dev/sdb2 Example output:\n/dev/sdb3: UUID=\u0026#34;c1ec9712-5c64-46da-852c-9d665416e8a6\u0026#34; UUID_SUB=\u0026#34;90e5b654-6967-471a-9d35-8997488b1ba8\u0026#34; BLOCK_SIZE=\u0026#34;4096\u0026#34; TYPE=\u0026#34;btrfs\u0026#34; PARTUUID=\u0026#34;885dd863-a550-2d47-89dd-f54fd6744ca5\u0026#34; /dev/sdb2: UUID=\u0026#34;21bbff3f-b82e-416e-93c8-e6d44c3daf82\u0026#34; BLOCK_SIZE=\u0026#34;4096\u0026#34; TYPE=\u0026#34;ext4\u0026#34; PARTUUID=\u0026#34;be571200-1a56-5d4c-9a5b-88a5f36a295e\u0026#34; Add the following lines to /mnt/etc/fstab, substituting the example UUIDs with those you received from blkid.\nUUID=c1ec9712-5c64-46da-852c-9d665416e8a6 / btrfs defaults 0 1 UUID=21bbff3f-b82e-416e-93c8-e6d44c3daf82 /boot ext4 defaults 0 2 Creating extlinux.conf Create a file /mnt/boot/extlinux/extlinux.conf with the following contents, replacing the example UUID with the one for /dev/sdb3 from blkid.\nDEFAULT arch MENU TITLE Boot Menu PROMPT 0 TIMEOUT 50 LABEL arch MENU LABEL Arch Linux ARM LINUX /Image INITRD /initramfs-linux.img FDT /dtbs/rockchip/rk3399-pinebook-pro.dtb APPEND root=UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 rw LABEL arch-fallback MENU LABEL Arch Linux ARM with fallback initramfs LINUX /Image INITRD /initramfs-linux-fallback.img FDT /dtbs/rockchip/rk3399-pinebook-pro.dtb APPEND root=UUID=c1ec9712-5c64-46da-852c-9d665416e8a6 rw Booting and finishing setup Boot into Arch Linux ARM and log in as root with password root.\nInitialize the pacman keyring.\n# pacman-key --init # pacman-key --populate archlinuxarm For security, change the default passwords for root and the default user alarm.\n# passwd # passwd alarm You have now installed Arch Linux ARM on your PineBook Pro.\nInstalling Void Linux ARM Warning This guide is a Work In Progress; no warranty is implied. This installation method is not officially recommended (or discouraged) by the Void Linux project. This guide is for experienced Linux users. This will not be a complete guide, as it borrows heavily on Installing Arch Linux ARM, so read it first then come back here.\nOnly the steps that are different are listed here. Be careful, the numbering of the sections is not the same.\nInstalling the root filesystem Downloading and verifying the rootfs tarball You can go to the Void Linux download page, select the \u0026ldquo;arm\u0026rdquo; tab, and choose one of the aarch64 rootfs tarballs, either glibc or musl. How to check integrity of the downloaded file is explained on the same page.\nOr use the following instructions (on Debian):\n$ wget https://repo-default.voidlinux.org/live/current/void-aarch64-musl-ROOTFS-20221001.tar.xz $ wget https://repo-default.voidlinux.org/live/current/sha256sum.{txt,sig} $ wget https://github.com/void-linux/void-packages/raw/master/srcpkgs/void-release-keys/files/void-release-20221001.pub $ signify-openbsd -V -p void-release-20221001.pub -x sha256sum.sig -m sha256sum.txt Signature Verified $ sha256sum -c --ignore-missing sha256sum.txt void-aarch64-musl-ROOTFS-20221001.tar.xz: OK Extracting and configuring the root filesystem Extracting the root filesystem tar -xpf void-aarch64-musl-ROOTFS-20221001.tar.xz -C /mnt Kernel The Void Linux rootfs tarball does not contain a kernel, however the pinebookpro-kernel package can be installed from the Void Linux repositories. Alternatively, one can (cross) build a kernel themselves. Skip this section if you would rather install the package.\nWarning If you choose the manually built kernel route, you’ll have to keep it updated yourself, the same way: manually (cross-)building and installing. Manually cross-compiling a mainline kernel suitable for the Pinebook Pro We’ll use the postmarketOS kernel configuration and boot parameters, because they are working properly, and are sufficiently up-to-date. This is done from an x86_64 computer.\nThis has been tested with postmarketOS configuration for 6.0.2 and kernel 6.1.0-rc5+. No additional initramfs was needed to boot the Void Linux OS.\n$ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git $ cd linux $ wget -O .config \u0026#39;https://gitlab.com/postmarketOS/pmaports/-/raw/master/device/community/linux-postmarketos-rockchip/config-postmarketos-rockchip.aarch64?inline=false\u0026#39; $ sed -i \\ -e \u0026#39;s|CONFIG_ROCKCHIP_CDN_DP=.*|CONFIG_ROCKCHIP_CDN_DP=n|\u0026#39; \\ -e \u0026#39;s|CONFIG_BATTERY_CW2015=.*|CONFIG_BATTERY_CW2015=y|\u0026#39; \\ -e \u0026#39;s|CONFIG_TYPEC_FUSB302=.*|CONFIG_TYPEC_FUSB302=y|\u0026#39; \\ -e \u0026#39;s|CONFIG_TYPEC_TCPM=.*|CONFIG_TYPEC_TCPM=y|\u0026#39; \\ .config $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 oldconfig $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(grep -c \u0026#39;^processor\u0026#39; /proc/cpuinfo) Manually installing the newly built kernel, modules \u0026amp; DTB files $ KVER=\u0026#34;$(make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 kernelrelease)\u0026#34; $ sudo make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j1 modules_install dtbs_install \\ INSTALL_MOD_STRIP=1 \\ INSTALL_MOD_PATH=/mnt \\ INSTALL_DTBS_PATH=/mnt/boot/dtbs $ sudo cp arch/arm64/boot/Image \u0026#34;/mnt/boot/Image-${KVER}\u0026#34; Configuring a login agent on the serial console cp -R /mnt/etc/sv/agetty-ttyS0 /mnt/etc/sv/agetty-ttyS2 ln -sf /etc/sv/agetty-ttyS2 /mnt/etc/runit/runsvdir/default Creating extlinux.conf Note If using the official PBP kernel package, it is also recommended to use the u-boot-menu package, which automatically regenerates the extlinux.conf file on kernel upgrades. In that case, you will not need to follow the below instructions. The following borrows from postmarketOS u-boot configuration for the kernel command-line parameters.\nWe force the serial console to 115200 bauds (from the default 1.5M bauds), so that it is the same as tow-boot’s.\n# mkdir -p /mnt/boot/extlinux # cat \u0026lt;\u0026lt;EOF \u0026gt; /mnt/boot/extlinux/extlinux.conf default l0 menu title Pinebook Pro Boot Menu prompt 0 timeout 50 label l0 menu label Boot Kernel on SD linux /Image-${KVER} fdt /dtbs/rockchip/rk3399-pinebook-pro.dtb append console=tty0 console=ttyS2,115200n8 coherent_pool=1M pcie_aspm.policy=performance video=HDMI-A-1:1920x1080@60 video=eDP-1:1920x1080@60 rw rootwait root=/dev/mmcblk1p3 EOF Finalizing Now you can umount the partition(s) and boot the Pinebook Pro with Void Linux. The default root password is \u0026ldquo;voidlinux\u0026rdquo;.\nTuning Details on how to get the most out of a Pinebook Pro.\nCustomizing the Pinebook Pro\u0026rsquo;s default Manjaro KDE system Watching DRM content (Netflix, etc.) Most paid online streaming services use Widevine DRM to make their content more difficult to pirate. Widevine is not directly supported on Manjaro KDE, however it is still possible to watch DRM content via the \u0026ldquo;chromium-docker\u0026rdquo; package which downloads a 32-bit ARM container and installs Chromium with Widevine inside of that. While not space-efficient, or efficient in general, it’s the recommended solution for watching this content on your Pinebook Pro. You can install this package with:\nsudo pacman -Sy chromium-docker Checking GPU capabilities To see what versions of OpenGL and OpenGL ES are supported by the Pinebook Pro, what driver is in use, and what version of the driver is loaded, install the \u0026ldquo;mesa-demos\u0026rdquo; package with:\nsudo pacman -Sy mesa-demos And then run:\nglxinfo | grep OpenGL This will give detailed information about your graphics card and driver, useful for debugging.\nBetter GPU compatibility and performance For better graphics performance, you may install the \u0026ldquo;mesa-git\u0026rdquo; package, built and supplied in the Manjaro ARM repos. This lets you bring in the latest features, optimizations, and bugfixes for the graphics driver used by the Pinebook Pro. Installation is as simple as:\npacman -Sy mesa-git Then you may reboot to load the newer driver.\nWith Mesa 20.2 there is no longer much reason to use this over the standard mesa package, and applications may occasionally break with mesa-git.\nReporting bugs to the Mesa project will help make sure any problems are quickly fixed.\nOpenGL 3.3 support By default, with the current state of the Panfrost GPU driver, the Pinebook Pro supports OpenGL 2.1 and OpenGL ES 3.0. If you want to use OpenGL 3.3, you need to set the system-wide environment variable, open the /etc/environment file with:\nkate /etc/environment And then at the bottom of the file, on a new line, add:\nPAN_MESA_DEBUG=\u0026#34;gl3\u0026#34; Then save the file, entering your password when prompted, and reboot the system. When you check your GPU capabilities, it should report OpenGL 3.3 and applications that rely on it should function properly. Note that GL 3.3 support is incomplete and some rendering features do not work yet, notably geometry shaders.\nInstall Anbox on Pinebook Pro Manjaro 20.10 Youtube video on installing Anbox on Pienbook Pro Manjaro Build 20.10 by LivingLinux\nCustomizing the Pinebook Pro\u0026rsquo;s previously-default Debian system Here are some hints on what you can do to customize the Pinebook Pro’s previous factory image (aka mrfixit2001 debian build)\nInitial user changes, password, name, etc When you first get your Pinebook Pro, you should consider setting strong passwords and making the default account your own.\nReboot (this is just to ensure all background processes belong to the user are not running. There are other ways to achieve this but this way is easy)\nOnce the machine reboots press Alt-Ctrl-F1 to bring up a text terminal\nLogin as root (login: root, password: root)\nSet a strong password for the root user using the following command and it’s prompts:\n# passwd (and follow prompts) Rename the rock user to your prefered username (replace username with whatever you like):\n# usermod -l _username_ -d /home/_username_ -m rock Rename the rock group to match your preferred username:\n# groupmod -n _username_ rock Put your name in the account, (replace \u0026ldquo;John A Doe\u0026rdquo; with your name):\n# chfn -f \u0026quot;John A Doe\u0026quot; _username_ Set a strong password for the normal user:\n# passwd _username_ Log out of the text terminal:\n# logout Press Alt-Ctrl-F7 to go back to the login screen and then login as the normal user\nOpen text terminal to fix login error: \u0026ldquo;Configured directory for incoming files does not exist\u0026rdquo;:\n$ blueman-services Select \u0026ldquo;Transfer\u0026rdquo; tab and set \u0026ldquo;Incoming Folder\u0026rdquo; to yourself or if adduser is in the distributions, create an user with sudo adduser $USER (fill out variables as required), then add the user to the groups using sudo adduser $USER $GROUP by adding one group at a time.\nChanging the default hostname Debian 9 has a command to allow you to change the hostname. You can see the current settings using:\n$ sudo hostnamectl Static hostname: Debian-Desktop Icon name: computer Machine ID: dccbddccbdccbdccbdccbdccbdccbccb Boot ID: ea99ea99ea99ea99ea99ea99ea99ea99 Operating System: Debian GNU/Linux 9 (stretch) Kernel: Linux 4.4.210 Architecture: arm64 To change, use this, (with hostname used as the example):\n$ sudo hostnamectl set-hostname _hostname_ Whence done, you can re-verify using the first example.\nThen you should backup and edit your /etc/hosts entry’s name:\n$ sudo cp -p /etc/hosts /etc/hosts.`date +%Y%m%d` $ sudo vi /etc/hosts 127.0.0.1\tlocalhost 127.0.0.1\t_hostname_ ::1\tlocalhost ip6-localhost ip6-loopback fe00::0\tip6-localnet ff00::0\tip6-mcastprefix ff02::1\tip6-allnodes ff02::2\tip6-allrouters 127.0.1.1 linaro-alip Disable Chromium browser\u0026rsquo;s prompt for passphrase \u0026amp; password storage Perform the following steps:\nOn the tool bar, hover over the Chromium icon Using the right mouse button, select Properties In the Command: line section, add --password-store=basic before the %U Use the x Close button to save the change This will of course, use basic password storage, meaning any saved passwords are not encrypted. Perfectly fine if you never use password storage. Changing the boot splash picture The default boot splash picture can be replaced using the following instructions:\nInstall ImageMagick which will do the conversion $ sudo apt-get install imagemagick Create a 1920 x 1080 picture. For the best results, use a PNG image (It supports lossless compression). From the directory in which your new image is stored run the following commands Convert your image to the bootsplash raw format using imagemagick convert. $ convert yoursplashimage.png -separate +channel -swap 0,2 -combine -colorspace sRGB RGBO:splash.fb Create a backup copy of your current splash screen $ sudo cp /usr/share/backgrounds/splash.fb /usr/share/backgrounds/splash_original.fb Copy your new splash screen into place $ sudo cp splash.fb /usr/share/backgrounds/splash.fb Set the correct permissions on the splash.fb file $ sudo chmod 644 /usr/share/backgrounds/splash.fb If you do not want to see kernel console text messages, make sure you don’t have Plymouth installed Watching Amazon Prime videos with Chromium When you create a new user, it will be necessary to launch the Chromium browser with a specific user agent like below:\nchromium-browser --user-agent=\u0026#34;Mozilla/5.0 (X11; CrOS armv7l 6946.63.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36\u0026#34; There may be more tweaks needed.\nEnabling text boot time messages By default, most Linux distributions have a boot screen with a picture. To see all the boot time messages, use one of the following:\nDebian Backup and edit the U-Boot configuration file: cp -p /etc/default/u-boot /etc/default/u-boot.`date +%Y%m%d` chmod a-w /etc/default/u-boot.`date +%Y%m%d` vi /etc/default/u-boot Remove the quiet and splash parameters. Leave everything else alone.\nUpdate the U-Boot configuration: u-boot-update Test and verify you get what you think you should be seeing. Manjaro Backup and edit the U-Boot configuration file: cp -p /boot/extlinux/extlinux.conf /boot/extlinux/extlinux.conf.`date +%Y%m%d` chmod a-w /boot/extlinux/extlinux.conf.`date +%Y%m%d` vi /boot/extlinux/extlinux.conf Change console=ttyS2,1500000 to console=tty1 Remove the bootsplash.bootfile option and it’s parameter. You can add verbose logging by appending ignore_loglevel to the line where boot splash was. Leave everything else alone. Test and verify you get what you think you should be seeing. Retro Gaming on the Pinebook Pro A retro-gaming OS named R-Cade has been made available for the Pinebook Pro, provided by The Retro Center.\nR-Cade includes over 100 retro-gaming systems, a lightweight web browser, and includes the latest release of KODI to provide full 4K UHD media playback and streaming. Streaming options in KODI are provided by various addons, such as Netflix, Disney+, and Amazon Prime. More information can be found here.\nReleases can be downloaded from their GitHub.\nImproving readability Some people find that a 14\u0026quot; LCD screen with 1080p, (1920 x 1080), has text and icons a bit too small. There are things you can do to make the screen easier to use and read.\nIncrease the font size Use a font with more pronounced features Increase the various window manager sizes (e.g. increase the height of the tool bar) Change the color scheme to be easier on the eyes. Higher contrast can help usability. Change the window manager’s decorations (e.g. use larger icons) Use a workspace manager, with one application per workspace When at home or office, use an external monitor Change the X-Windows DPI. One such method that someone used successfully, is: echo \u0026quot;Xft.dpi: 150\u0026quot; \u0026gt;\u0026gt; ~/.Xresources Change the 150 as desired to get the size adjustment you want. However, do not change the resolution of the LCD screen, otherwise you may end up with a blank / black screen. If that happens, see this troubleshooting section for the fix: Blank screen after changing builtin LCD resolution\nChromium tweaks Flags From the official Debian image:\n--disable-low-res-tiling \\ --num-raster-threads=6 \\ --profiler-timing=0 \\ --disable-composited-antialiasing \\ --test-type \\ --show-component-extension-options \\ --ignore-gpu-blacklist \\ --use-gl=egl \\ --ppapi-flash-path=/usr/lib/chromium-browser/pepper/libpepflashplayer.so \\ --ppapi-flash-version=32.0.0.255 \\ --enable-pinch \\ --flag-switches-begin \\ --enable-gpu-rasterization \\ --enable-oop-rasterization \\ --flag-switches-end Note that in some cases, this may also decrease performance substantially, as observed when using these flags on the Manjaro KDE desktop. Feel free to experiment to find what is smoothest for you personally.\ngVim has performance issue It appears that using GTK3 can cause very slow scrolling, while Vim in a terminal window works fine. Simply revert back to using GTK2 (how to do so is somewhat Linux distriobution-specific).\nAnother solution may be to run gVim with\nGDK_RENDERING=image environment variable set. It seems that this improves the performance by reverting back to software-only rendering.\nKernel options Here are some Pinebook Pro \u0026amp; its RK3399 SoC Linux specific options. If kernel version, (or version range specific), it should list that information in the description.\nTo see if a specific feature is enabled in the current kernel, you can use something like this:\n$ zgrep -i rockchip_pcie /proc/config.gz # CONFIG_ROCKCHIP_PCIE_DMA_OBJ is not set CONFIG_PHY_ROCKCHIP_PCIE=m If it’s listed as =m, then it’s a module. You can see if the module is loaded with:\n$ lsmod | grep -i rockchip_pcie phy_rockchip_pcie 16384 0 Note modules are not loaded until needed. Thus, we sometimes check the kernel configuration instead to see if a feature is configured first, then see if it’s a module.\nHardware video decoding Here is a method to check for hardware video decoding by the VPU. There are special Linux kernel modules that perform this function.\nOlder systems, such as the previously-default Debian desktop, use the Rockchip-supplied kernel module rk-vcodec. To check, something like this can be used:\n$ lsmod | grep rk-vcodec or\n$ zgrep RK_VCODEC /proc/config.gz CONFIG_RK_VCODEC=y Note that in the above example, the Rockchip video CODEC is not built as a module, but included into the kernel. Thus, it does not show up in the list modules check.\nNewer systems may use a different option as in the configuration below:\n$ zgrep HANTRO /proc/config.gz CONFIG_VIDEO_HANTRO=m CONFIG_VIDEO_HANTRO_ROCKCHIP=y Dock The Pinebook Pro USB-C Docking Deck can be used to extend the Pinebook Pro with additional functionality. It is custom designed for both, physical dimensions and ports, to compliment the Pinebook Pro laptop. It has been tested on several disparate platforms and seems to be fully compatible with Android, Windows, ChromeOS, and GNU/Linux. It may be compatible with Apple systems, but this has yet to be documented.\nPorts List of ports available on docking station:\nUSB-C Charging Port x1 USB 3.0 Ports x3 USB-C 2.0 Ports x2 4K @ 30fps HDMI x1 1080P VGA x1 Gigabit Ethernet networking port x 1 Card readers: micro SD x 1 \u0026amp; SD x 1, supports: SD, SDHC and SDXC Audio Jack: 3.5mm Earphone Jack with mic x1 Hardware Tests Acer Aspire e15\nNote that machine lacks USB-C video. Tested with both Windows 10 and Gentoo GNU/Linux. Every device functions properly with the exception of the microphone jack. In Linux, the jack will only function with its volume set at or above 98 in alsamixer. This is uncomfortably loud. 8/10 for compatibility.\niPad Air (4th generation)\nUSB dock functions for fast charging and input from USB keyboard and mouse peripherals. Audio jack does not function under any tested circumstances. Bluetooth audio disabled when dock in use. Other devices not tested. 8/10\nSamsung Chromebook Plus V2\nEverything functions perfectly, with the exception of Ethernet, which was not tested. 9/10.\nGoogle Pixel 4a\nNote that the machine lacks USB-C video. Using android version 11. Video and Ethernet were not tested. Everything else functioned properly. 8/10.\nPineBook Pro\nUsing Manjaro ARM minimal with dwm. Video out, USB, and SD card readers all work. Did not test Ethernet or audio jack. 8/10.\nUsing devuan ARM \u0026amp; debian ARM, xfce4. Did not test Video out. USB and SD card readers work. Ethernet is working at full speed. The Docking Deck is able to negotiate USB-C 9V 1.6A and convert to 5V 2.5A for the PBP. No charging issues; the PBP makes some noise, but that isn’t the docking deck’s fault. Audio out is working. Note that adding another audio device obviates the need for the audio device default to be restored on reboot, which did not work on xfce4. 9/10.\nPinePhone Pro Explorer Edition\nWith Mobian: jack, Ethernet, SD-card readers, USB-A and -C, VGA fully works, HDMI lacks sound output. Video-out works fully on Mobian. 9/10\nKnown Bugs Audio Volume on Linux Currently, the audio output from this dock\nOn some Linux systems, and possibly all of them, the volume range for headphones from audible to loud is from 64562-64575 to 65000. That’s absolute, not percentages. This is an extremely tiny range \u0026ndash; completely impossible to navigate with percentages, and dangerous as well. For the time being, this audio output should be treated as unsafe for human health, as well as the health of your speakers. To ensure safe audio levels, users can switch to the digital output to lower the volume to a safe level.\nPinebook Pro does not charge when connected to USB-C dock It has been observed in the past that the Pinebook Pro is somewhat temperamental when used with the USB-C dock. Sometimes it will not charge when connected to its dock, even if the dock is powered from the official Pinepower power supply (i.e., even when it is provided with sufficient power). The more astute may have surmised that the Pinebook Pro was powering the dock, rather than being powered itself. The solution, luckily, is quite simple. The following command should always work:\necho \u0026quot;sink\u0026quot; | sudo tee /sys/class/typec/port0/power_role Please note:\nThis command cannot be run with sudo, you must be the root user. If this command still fails with the message \u0026ldquo;bash: /sys/class/typec/port0/power_role: No such file or directory\u0026rdquo; Please ensure that the file actually exists. The most likely cultprits are that either /sys/class/typec does not exist or /sys/class/typec/port0 has a different name on your machine. Unable to output to external display Unplug the dock cable turn 180 degrees reinsert in new orientation. (Sometimes works for charging the laptop too.)\nComponents List of chips used in the docking station:\nPD Negotiation chip - PDFL7102 HDMI/VGA chip - IT6564 GbE Ethernet chip - RTL8153B USB 3.0 Hub chip - VL817 SD card reader chip - GL823K Audio CODEC chip - HZD100 External Links The Pinebook Pro Docking Deck at the Pine64 store The \u0026ldquo;Pinebook Pro Hardware and Accessories\u0026rdquo; section of the Pine64 forum Power and charging The Pinebook Pro external power and charging circuity is quite rudimentary, and hence quirky. This article aims to explain all the fine points so that the behavior could be understood and dealt with.\nMonitoring and control Overview No control of charging is possible other than by physically plugging and unplugging a charger.\nSoftware monitoring is also quite limited, one can check whether a charger is connected (in /sys/class/power_supply/dc-charger/online and /sys/class/power_supply/tcpm-source-psy-4-0022/online) and see the current battery voltage (in /sys/class/power_supply/cw2015-battery/voltage_now).\nThe CW2015 battery monitoring IC only measures the voltage and tries to estimate the State Of Charge and Remaining Run Time. The last value (along with the \u0026lsquo;\u0026rsquo;nominal\u0026rsquo;\u0026rsquo; battery capacity) is also used by the kernel driver to \u0026lsquo;\u0026lsquo;compute\u0026rsquo;\u0026rsquo; the current. The estimations might be relatively accurate under certain conditions but you can not really know if they’re met with your laptop load at any given moment, so the only value provided that can be trusted is the voltage.\nCharging indicator LED There is a red LED near the barrel socket that’s connected directly to the BQ24171 battery charging IC.\nIt can indicate one of the three states:\nLED \u0026lsquo;\u0026lsquo;on\u0026rsquo;\u0026rsquo; means the charger is supplying current to the battery and the system; LED \u0026lsquo;\u0026lsquo;off\u0026rsquo;\u0026rsquo; means the charger is turned off, and the whole system is powered from the battery; LED \u0026lsquo;\u0026lsquo;blinking with 0.5 Hz frequency\u0026rsquo;\u0026rsquo; signals some hardware error: typically battery over-temperature protection or input under-voltage (from a failed charger); in this case the charger is also off, and the system is powered from the battery all the time. All other kinds of blinking really indicate the charger getting turned on and off, this happens when BQ24171 detects \u0026lsquo;\u0026lsquo;battery full\u0026rsquo;\u0026rsquo; condition, disables the charger, the system starts drawing current from the battery, the voltage quickly drops, and the charger is enabled again to compensate for the discharge. The blinking frequency would depend on the current system load, battery temperature, and the backlight level (as the backlight power source adds up to ~70 mV ripple to the voltage monitoring net). This \u0026ldquo;trickle-charging\u0026rdquo; is harmful for lithium batteries, but no workaround is possible other than fully disconnecting the external power source, and it’s not clear whether that would do more good than harm.\nAnother observed behavior is that the status LED blinks randomly, from time to time and unrelated to the system load, especially when the screen brightness is cranked to the maximum, and the battery isn’t fully charged. This has been attributed to some strange feedback that the BQ24171 receives and becomes confused, but further analysis is required.\nMonitoring currents The charging IC uses two measurement shunt resistors: \u0026lsquo;\u0026lsquo;R37\u0026rsquo;\u0026rsquo; for input current, and \u0026lsquo;\u0026lsquo;R43\u0026rsquo;\u0026rsquo; for battery current, both 0.010 Ohm. They’re easily accessible for external equipment after removing the RF shield on the mainboard, and one can use a battery-powered voltmeter or a differential probe to properly measure the real current at any given moment. Do \u0026lsquo;\u0026rsquo;not\u0026rsquo;\u0026rsquo; connect non-isolated oscilloscope ground clip to them, that might damage the equipment.\nWith the external chargers disconnected the system is powered by the battery, so measuring voltage on \u0026lsquo;\u0026lsquo;R43\u0026rsquo;\u0026rsquo; (along with the battery voltage at about the same moment) can be used to learn the system power consumption under different software loads.\nCharging Overview Pinebook Pro simplified charging schematics\nWhen an external charger is connected, the battery charging process is automatically activated, it doesn’t depend on any software interactions and works all the same even with the main SoC powered down. The system automatically chooses between the barrel socket (limiting current draw to 3 A) and Type-C source (limited to 2.5 A), with the former preferred when both are connected at the same time (but the current limit is enforced as if Type-C was used).\nThe maximum charging current under normal conditions is limited to 2.75 A and the voltage to 4.35 V. Battery temperature affects these values, and if the measuring is done properly (see the section Battery temperature fix) the charge is fully suspended under 0 °C or above 60 °C, maximum current halved below 10 °C, maximum voltage reduced to 4.24 V above 45 °C and to 4.19 V above 50 °C.\nThe charging process automatically terminates when the voltage reaches the recharge threshold (upper limit - 0.1 V) \u0026lsquo;\u0026lsquo;and\u0026rsquo;\u0026rsquo; the current falls below 275 mA. However, this also stops supplying external power to the system, so if it’s running the battery voltage almost immediately drops below the recharge threshold, and the charging is turned on again.\nExample run and charge time calculations Assuming a fully charged 9600 mAh battery and an idle system using \u0026lsquo;\u0026lsquo;performance\u0026rsquo;\u0026rsquo; cpufreq governor with backlight at 3700/4095 consuming 9.6 W we can expect\n9.6 Ah * 3.8 V / 9.6 W = 3.8 h so that gives 3.8 hours of run time.\nIf the same battery is empty and a barrel plug charger is connected while system has the same load it will need\n9.6 Ah * 3.8 V / ((3 A * 5 V * 0.9 - 9.6 W) * 0.95) = 9.85 h that is 9.85 hours of charging from zero to full, assuming 0.9 DC-DC conversion efficacy and 0.95 charging efficacy.\nRemoving the system load reduces the time to\n9.6 Ah * 3.8 V / (2.75 A * 3.8 V * 0.95) = 3.67 h so if you need to fully charge the battery, e.g. before a trip, the fastest and most reliable way is to power down (not suspend) the system, leave the device with the charger connected for a few hours, upside down for better cooling, and wait for the red LED on the side to turn off.\nWorking without battery With the battery disconnected the charger isn’t going to turn on, and the system won’t be getting any power from the external source. That’s why PBP has additional bypass cable that allows connecting external power directly to the system power bus. Of course it should be kept disconnected when the battery is present to avoid excess voltage overcharging and destroying the battery. It’s also recommended to add additional insulation to the cable connectors, as they expose battery and charger positive terminals on bare metal, and should never be accidentally connected to ground.\nHardware modifications Type-C current limit Warning The 0.5 A difference described in this section is there to carve out some power for a USB-C dock connected to the Pinebook Pro’s USB-C port. This is actually against the USB Power Delivery specification, but it leaves some power to the USB-C dock, which it requires to power itself and any devices connected to it. Thus, the procedure described in this section will most probably make using USB-C docks unreliable or even impossible, leaving the USB-C port usable for connecting only USB-C chargers or bus-powered USB-C devices. Since there’s no software control over the input current limit unmodified PBP always tries to draw up to 2.5 A from a Type-C charger.\nIt’s recommended to manually check /sys/class/power_supply/tcpm-source-psy-4-0022/current_max for all the chargers you’re using. When the value is lower than 2.5 A you shouldn’t use that charger with PBP as it would get overloaded, running out of specs.\nIf all of the chargers you want to use can supply 3 A or more \u0026lsquo;\u0026lsquo;at 5 V\u0026rsquo;\u0026rsquo; (the sysfs file will still report 2.5 A so check the official charger specs and/or label) consider lifting the limit to make it even with the barrel plug charger. For that remove the \u0026lsquo;\u0026lsquo;R148\u0026rsquo;\u0026rsquo; resistor on the bottom layer of the mainboard.\nThe easiest way is to use a soldering iron tip big enough to hold a 1 mm drop of an SnPb solder (it mixes with Pb-free nicely and lowers the melting point) to heat both sides of the resistor at once and lift it off.\nBattery temperature fix Warning The procedure described in this section alters the operating parameters of the lithium battery built into the Pinebokk Pro, which may be unsafe, and in extreme conditions may even introduce a fire hazard. Use the described procedure at your own risk. Additional verfication of the described procedure is currently pending. To ensure safe operation the charger IC is constantly monitoring the battery temperature with the sensor integrated inside the pack. The thermistor used is a 103AT NTC but the corresponding circuity on PBP mainboard was calculated for some other type. This results in the charger IC detecting 45 °C when the battery is in fact at just 35 °C, and 60 °C when the battery is at 46 °C. It’s easy to hit this threshold with heavy CPU or GPU loads as the metal back cover heats up from the SoC and slightly warms up the battery. Under these conditions the charging is suspended (with charging LED signalling a hardware issue), and the intensive tasks are continued on battery power alone, heating it up even more.\nTo fix this issue the resistor divider needs to be replaced to match the datasheet recommended values. For that one needs to change two 0402 resistors on the bottom side of the mainboard: use 2.2 kOhm 1 % for \u0026lsquo;\u0026lsquo;R52\u0026rsquo;\u0026rsquo; (instead of 4.4 kOhm installed by the factory), note it’s the one closer to the board edge; and 6.8 kOhm 1 % for \u0026lsquo;\u0026lsquo;R54\u0026rsquo;\u0026rsquo; (30 kOhm from the factory).\nIf your local hackspace doesn’t have suitable resistors consider getting a sample book from e.g. Aliexpress, it should cost less than 15 USD including shipping.\nTroubleshooting Tips, tricks and other information for troubleshooting your Pinebook Pro If something has gone wrong, the key thing is remain calm and not do anything hasty and make things worse, particularly when flashing the eMMC or firmware. Try and make a record of all the things you did in the run-up to the problem (even to the point of using a camera to take a note of errors on the screen, this record can be vital later).\nManjaro Updates Fail With 404 If you have an old Manjaro installation then it will have the wrong repositories/mirrors set up and they won’t work. Set up new repositories by following these instructions: https://archived.forum.manjaro.org/t/another-mirror-transition-manual-intervention-required/132302\nPower And Boot New from the factory - Pinebook Pro won\u0026rsquo;t boot / power on Some Pinebook Pros came from the factory with the eMMC switch in the disabled position. It should be switched towards the back / hinge to enable the eMMC. The eMMC may have come loose during shipment. Open the back and verify that the eMMC is firmly seated. You may want to try unplugging the SD card daughterboard ribbon cable and see if it powers on (remove the battery and peel off a bit of the tape before unplugging it to avoid damage). If it does, try reseating it on both sides. It might have come loose during shipping. It’s possible that your eMMC is empty from the factory. Simply create a bootable SD card and see if your Pinebook Pro Getting started. Pinebook Pro will not power on after toggling the eMMC enable/disable switch This may happen if you meant to toggle the UART/Headphone switch (9) towards touchpad for headphone use and instead you toggled the eMMC enable/disable switch (24). After reenabling eMMC by toggling switch (24) towards hinge, if Pinebook Pro does not turn on then press the RESET button (28). It is clearly marked \u0026lsquo;reset\u0026rsquo; on the PCB board. Pinebook Pro will not power on after removing and replacing EMI shielding Closely inspect that the shielding is firmly seated in the clips on all sides. You can be seated in the clips on one axis, and have missed on an another axis. Pinebook Pro won\u0026rsquo;t boot when using UART console cable If you’re using the UART console cable from the Pine Store, you may want to see if it boots after you disconnect it. Some users report that custom-made cables based on FTDI UART adapters do not cause this issue. Make sure your USB to serial UART device is 3.3v. Many are 5v and some even +-12v. Pinebook Pro’s only support 3.3v and may act eratically when using higher voltage. Further, higher voltage could permananetly damage the Pinebook Pro’s SoC. Pinebook Pro will not sleep with lid closed A problem with the positioning of the lid magnet has been identified by several forum users in mid-2020 models of the Pinebook Pro. The magnetic field from the lid magnet operates a hall effect sensor located on the daughterboard (smallboard), which causes the Pinebook Pro to sleep when the lid is closed. If the magnet is not positioned correctly, the Pinebook Pro will not sleep when the lid is fully closed, but may sleep if the lid is open about an inch. If you experience this problem, repositioning of the magnet may be necessary.\nLid Magnet Repositioning Step-by-Step Read these steps thoroughly before starting. This is a somewhat laborious process involving fragile parts!\nRemove bottom cover. Disconnect LCD and webcam ribbon cable from main board. Flip the small black strip on the connector upward and the ribbon cable can be easily removed. Do not pull the cable out without first raising the black retaining mechanism. Remove the small black plastic standoffs on each hinge and set aside. Remove the three screws from each hinge on the display assembly. Move the hinges upward to a 90 degree angle independently from the main body. Then lift the main body to the same 90 degree angle and you should be able to separate the display assembly from the main body. Set the main body aside. Remove the plastic hinge cover on the display assembly. There’s not really an easy way to do this, just work slowly and deliberately so as not to damage the sensitive cable inside. Start from either end and work your way inward. Use a small flathead screwdriver or similar tool to get started. Remove the hinges from the display assembly. Remove the rubber bumpers at the top corners of the display assembly to expose two screws. Remove the screws. Starting at the corners, separate the bezel from the lid. The clips that hold it in place are similar to those found on the hinge cover. Again, slow deliberate work will get it done. Work from the top down. Take care not to damage the cables in the bottom. With the bezel separated from the lid, feed the cable through the slot and set the bezel aside. Without removing the LCD panel completely, lift and move the panel slightly to the left, taking care not to damage the cable running underneath up to the webcam. This will give you room to remove the magnet without risking damage to the panel. The magnet is a silver colored bar near the bottom right side of the lid. Pry the magnet out with a small flathead or similar tool and set it aside. There is some adhesive but it’s not very strong. Put the LCD panel back where it belongs. Note the foam pads on either side of the panel. The magnet is the same width as the foam pad that keeps the panel in place, and should fit perfectly in the same channel. The magnet should be placed about 1 to 1.5cm lower than where it was originally. There should be no need for adhesive, as the magnet will stick to the LCD panel. For reference, the hall effect sensor that the magnet interacts with is in between the USB port and audio jack. Reassemble using these steps in reverse order. Your Pinebook Pro should now sleep properly when the lid is closed.\nAlternative Non-Invasive Lid Magnet Repositioning Method This method only takes a few seconds, and doesn’t require disassembling your Pinebook Pro: Turn on your Pinebook Pro so you can easily test when the internal magnet is in the correct position. Open the lid. Take a tiny 1/8\u0026quot; neodymium magnet, and place it along the right edge of the front bezel (LCD side) to locate the internal positioning magnet and discover the correct polarity. There should be one spot where it has the most attraction. Mark that spot. Using a very strong neodymium magnet(s) oriented with the same polarity you discovered using the tiny magnet, carefully place it on the spot you marked, and slowly slide it down the bezel until the internal magnet is pulled into the proper position. I successfully used four 1/2\u0026quot; cube neodymium magnets stacked on top of each other each having 20lbs of pull force to accomplish this. The internal magnet should be placed about 1 to 1.5cm lower than where it was originally. There should be no need for adhesive, as the magnet will stick to the LCD panel. For reference, the hall effect sensor that the magnet interacts with is in between the USB port and audio jack. Remove all external magnets, and test that the internal magnet is positioned correctly by slowly closing the lid while watching the LCD screen to make sure it stays suspended when closed, and wakes up when opened. Your Pinebook Pro should now sleep properly when the lid is closed.\nWiFi And Bluetooth WiFi issues First, check the privacy switches to make sure your WiFi is enabled. They are persistant. See Privacy Switches Next, you may have to modify the /etc/NetworkManager/NetworkManager.conf as root user, and replace managed=false with managed=true. Then reboot. If that doesn’t work, and if dmesg | grep brcmfmac reports missing firmware, you will need to manually add the brcmfmac43455-sdio.* firmware files. This is due to a quiet change in the 2022 hardware revision. This repo has been tested and confirmed to work by no112. For connections that drop and resume too often, it might be due to WiFi power management from earlier OS releases. Later OS releases either removed WiFi power management, or default to full power. (Power management can be turned off via command line with iw dev wlan0 set power_save off or iwconfig wlan0 power off, although it is not persistent through re-boot.) For connections that drop under load on the default Debian, remove iwconfig wlan0 power off in the file /etc/rc.local. If WiFi is un-usable or often crashes when using an alternate OS, then it might because its WiFi firmware is not appropriate for the WiFi chip in the Pinebook Pro. Try the latest firmware patch from https://gitlab.manjaro.org/tsys/pinebook-firmware/tree/master/brcm After re-enabling WiFi via the privacy switch, you have to reboot to restore function. There is a work around for the default Debian, (and may work with others); sudo tee /sys/bus/platform/drivers/dwmmc_rockchip/{un,}bind \u0026lt;\u0026lt;\u0026lt; 'fe310000.dwmmc' On extremely rare occasions, the WiFi antenna connection is loose. To fix, simply open up the bottom, re-connect the WiFi antenna cable. This may show up as any of the following symptoms: Can’t connect to any network, but the network manager software sees the WiFi device, (so it has not been disabled by the Privacy Switch) Very limited range, meaning you can make a connection if the Pinebook Pro is next to the WiFi router. But not the next room. Unreliable connections, that are also limited by range. Every once in a great while, the kernel will just fail to detect the wifi hardware (symptom: `ip link`` shows no wlan0). Only solution found so far is to hard-reset the machine (complete power-off then on again). Bluetooth issues When connecting a Bluetooth device, such as a Bluetooth mouse, it does not automatically re-connect on re-boot. In the Bluetooth connection GUI, there is a yellow star for re-connect on boot. Use that button to enable a persistent connection. It can be changed back later. Bluetooth-attached speakers or headset require the pulseaudio-module-bluetooth package. If not already installed, it can be installed with a package manager or using the following: sudo apt-get install pulseaudio-module-bluetooth When using Bluetooth-attached speakers or headset and 2.4Ghz WiFi at the same time, you may experience stuttering of the audio. One solution is to use 5Ghz WiFi if you can. Or you may try using a different 2.4Ghz channel, perhaps channel 1 or the top channel, (11 in the USA, or 13/14 in some other countries). Sound issues Many reports of no sound are due to the OS, incorrect settings, or other software problems (eg. PulseAudio). So first test to see if it is a software or hardware problem, by trying another OS via SD card. (For example, if Debian is installed on the eMMC, try Ubuntu on SD.) If you cannot get sound from the headphone jack, but can get sound from the speakers, then the headphone / UART console switch may be set to the UART mode. You can open the back and check the position of the switch. If set to UART mode, switch it to headphone mode. See the parts layout for the location and correct position of the switch. When using the USB C alternate DisplayPort mode, it is possible that the audio has been re-directed through this path. If your monitor has speakers, see if they work. See manjaro-arm/pinebookpro-post-install /var/lib/alsa/asound.state for some ALSA tweaks. See manjaro-arm/pinebookpro-audio for how to handle 3.5mm jack plug/unplug events with ACPID. Serveral users have reported that one internal speaker had reversed polarity. Thus, sound from the speakers is like an echo effect. There is a software fix using alsamixer and then enable either \u0026ldquo;R invert\u0026rdquo; or \u0026ldquo;L invert\u0026rdquo;, however, now the headphones have incorrect audio. The permanent fix is to re-wire one speaker, though this requires soldering small wires. Sound playback may be affected by the \u0026ldquo;mirroring\u0026rdquo; between the right and left channels, which results in distorted sound image. The root cause is the ALSA mixer setting named \u0026ldquo;DAC Stereo Enhancement\u0026rdquo;, which needs to be changed to 0% to fix this issue. Please see this forum post for further information. NVMe SSD issues Many Pinebook Pro users have reported issues with M.2 NVMe SSD drives, including random Linux lockups and crashes. Some of these issues are related to the RK3399’s errata that disables Gen2 (5 GT/s) speed for the PCI Express link used by the NVMe SSD, reducing it down to Gen1 speed (2.5 GT/s). However, Linux distributions that use Linux kernels older than version 5.12 still configure the PCI Express link to run at Gen2 speed, which requires manual reconfiguration to Gen1 speed in case system instability is experienced. See also this related discussion. This issue does not affect distributions with recent (newer than May 2021) kernels such as Manjaro ARM which seem to work with no modifications.\nSome Pinebook Pro users have reported issues with the default settings for the APST (Autonomous Power State Transition) power saving, which cause an NVMe drive to disappear from the system or lock up after a certain period of time. Please see this forum thread for further information.\nThe output of the 3.3 V regulator inside the Pinebook Pro, which powers the M.2 SSD, becomes very noisy when the battery voltage drops below 3.9 V or so. This is a hardware issue of the Pinebook Pro that cannot be corrected without extensive hardware modifications, and it causes many M.2 SSDs to lock up under load and cause operating system crashes. The real trouble is that for some M.2 SSDs it takes a couple of hours of heavy I/O to lock up under these conditions, which may make them appear to be working reliably, while they eventually fail.\nKeyboard and trackpad Random Duplicated Key-Presses Whether caused by an error in the Hailuck Keyboard firmware, or a physical defect in the membrane, the Pinebook Pro keyboard may randomly register some key-presses twice. The solution to this problem is trivial. Simply run the following command:\nxkbset bouncekeys 20\nIf this return the following error:\nbash: xkbset: command not found\nOr some other similar error, you will need to install the command. It can most likely be found in your distro’s repository.\nYou may substitute some other value for 20 - this number denoting the time in milliseconds during which successive, duplicate key-presses will be rejected - with any value of your choice. If you are still receiving duplicates, consider increasing the number - perhaps by half. If you are consistently writing \u0026ldquo;aple\u0026rdquo;, try decreasing this number - perhaps by 25%.\nKeys not registering / missing keys when typing This issue occurs when your thumb or edge of the palm makes contact with left or right tip of the trackpad when you type. This is due to the palm rejection firmware being too forceful. Instead of only disabling the trackpad, so your cursor does not move all over the screen, it disables both the trackpad and the keyboard.\nUsing Fn+F7 to disable the touchpad will keep it from also disabling the keyboard.\nA firmware update has been released to address this.\nKey mapping See this /etc/udev/hwdb.d/10-usb-kbd.hwdb for some key mapping tweaks Pinebook Pro gets stuck after first reboot in Trackpad Firmware Update This refers to the firmware update shown here: https://github.com/dragan-simic/pinebook-pro-keyboard-updater#update-all-firmware-images\nIf the system is not responding after the 1st reboot, it might be easiest to do a system restore or boot an SD-card-only OS, and follow up by running the second step of the trackpad firmware update with a USB keyboard and mouse plugged in System restore https://forum.pine64.org/showthread.php?tid=8229 Firmware update https://github.com/dragan-simic/pinebook-pro-keyboard-updater#update-all-firmware-images ANSI Fn + F keys wrong for F9, F10, F11 and F12 There appears to be a minor firmware issue for ANSI keyboard models of the Pinebook Pro. Some discussion and fixes have been proposed;\nDiscussion thread Fn + F keys screwy for F9, F10, F11 and F12 Proposed fix (ANSI) Fn + F(9-12) has wrong assignment after firmware update #14 USB docks \u0026amp; USB C alternate mode video The Pinebook Pro uses the RK3399 SoC (System on a Chip). It supports a video pass through mode on the USB C port using DisplayPort alternate mode. This DisplayPort output comes from the same GPU used to display the built-in LCD.\nHere are some selection criteria for successfully using the USB C alternate mode for video:\nThe device must use USB C alternate mode DisplayPort. Not USB C alternate mode HDMI, or other. The device can have a HDMI, DVI, or VGA connector, if it uses an active translator. If USB 3 is also desired from a USB dock, the maximum resolution, frame rate and pixel depth is reduced to half the bandwidth. For example, 4K @ 30hz instead of 60hz. USB docks that also use USB C alternate mode DisplayPort will always have USB 2 available, (480Mbps, half-duplex). Screen Also see above about external screen using USB-C adaptor\nAfter changing builtin LCD resolution, blank screen Some people find that the text or icons are too small, so they attempt to change the resolution of the built-in display. Afterwards, the display is blank. Use the following to fix when logged into a text console as yourself, pressing Control-Alt-F1 through F6. After listing the resolutions, select the native resolution, (1920x1080 aka 1080p).\nexport DISPLAY=:0.0 xrandr -q xrandr -s [resolution] Once the screen resolution is restored, try using the software settings to configure the desired screen scaling.\nIf the above fix did not work, you can try this:\nUsing a text console, (Control-Alt-F1), login with your normal user ID Edit the file nano ~/.config/monitors.xml Change the \u0026ldquo;width\u0026rdquo; value to \u0026ldquo;1920\u0026rdquo; Change the \u0026ldquo;height\u0026rdquo; value to \u0026ldquo;1080\u0026rdquo; If there is more than one monitor configuration listed, edit that one too. Be careful to make no other changes. If needed, exit without saving and re-edit. Save the file and exit. Login using the GUI and test If you are still logged in via the GUI, you will have to reboot using sudo shutdown -r now. After the reboot, you should be able to login to the GUI login and have the resolution back to normal. After restoring the usability of your Pinebook Pro’s graphical screen, also see this section on improving readability and usability.\nOuter Shell Cracks in the plastic There have been multiple reports of cracks in the plastic keyboard and trackpad part of the case. These are generally near:\nHinges USB ports Top side, around the corners This seems to apply to the first batches in 2019. Later versions of the keyboard and trackpad have used better plastic. With replacements now in the Pine64 Store, it’s possible to simply order a replacement.\nThere have been a few reports of cracks in the plastic around the LCD display, but these appear to be less common. There are replacement LCDs with top cases available in the Pine64 Store.\nBe extra careful if you open the PBP, the plastic parts of the shell, around the back corners or the hinges are really tiny and break easily.\nUART This shows signals from the Pinebook Pro’s point of view, so connect the adapter’s RX to ring 1, and TX to the tip. See also the Pine64 official document describing this.\nSerial console UART is enabled by flipping the UART switch to the ON position (item 9). To do so, you need to remove the Pinebook Pro’s bottom cover by following the disassembly and reassembly guidelines. The OFF position is towards the touchpad, while the ON position is towards the display hinges.\nWith the UART switch in the ON position, the console is relayed via the headset jack, on which the audio output is no longer available. Please ensure that you are using a 3.3 V UART interface (such as the CH340, FTDI-232R, or PL2303, which are available in both 3.3 V and 5 V variants) to avoid damage to the RK3399 SoC. Older version of the serial console cable sold by the Pine Store used wrong voltage level and should not be used, see this forum thread for further information. Recent version of the same cable uses the right voltage level, which can also be checked by measuring the voltage on the TX ring.\nInsert the USB plug of the cable into a USB port on the machine that you will use to monitor the Pinebook Pro’s serial console, ensuring that the audio jack of the serial cable is be fully inserted into the Pinebook Pro’s headphone port. Run lsusb in a terminal and you should see a line similar to this:\nBus 001 Device 058: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Serial console output should now be accessible on the respective machine using a terminal emulator, such as screen, picocom or minicom. Here are a few examples of how to invoke a terminal emuator:\nscreen /dev/ttyUSB0 1500000 picocom /dev/ttyUSB0 -b 1500000 minicom -D /dev/ttyUSB0 -b 1500000 Features Additional hardware\nAudio\nBluetooth and WiFi\nBootable storage\nExternal ports list\nInternal layout\nLCD panel\nLEDs\nMicrophones\nPower supply\nSPI\nTouchpad\nWebcam\nAdditional hardware Hardware that is not part of the SoC.\nBattery Lithium Polymer Battery (10,000 mAh; 9,600 mAh in later batches) Monitored by CW2015 which only measures the current voltage; reported state (charging/discharging), capacity (State-Of-Charge), remaining runtime and current are (poor) estimates Display 14.0\u0026quot; 1920x1080 IPS LCD panel Lid closed magnet There is a magnet to detect when the laptop lid is closed, so action can be taken like sleep. This meets up with the Hall sensor on the daughter / small board to detect lid closed.\nThe magnet is located on the LCD panel right side, around 1.5 inches up measure from bottom edge. Webcam Internal USB attached Webcam Audio 3.5mm stereo earphone/microphone plug Built-in microphone Built-in stereo speakers: Oval in design 3 mm high x 20 mm x 30 mm Network WiFi: 802.11 b/g/n/ac Dual band: 2.4Ghz \u0026amp; 5Ghz Single antenna Bluetooth 5.0 Optional NVMe adapter PCIe 1.1, 2.5 GT/s per lane Note that due to errata, PCIe is limited to Gen1. See this commit. Four PCIe lanes, which can not be bifurcated, but can be used with one- or two-lane NVMe cards M keyed, though M+B keyed devices will work too Maximum length for M.2 card is 80mm (M.2 2280). The following sizes will also work: 2230, 2242, 2260 Power: 2.5 W (continuous) Does not support SATA M.2 cards Does not support USB M.2 cards Audio ALSA configuration If you do not have the integrated sound card selected as the default, create /etc/asound.conf with the following contents:\ndefaults.pcm.!card rockchipes8316c defaults.ctl.!card rockchipes8316c If you want to enable software mixing (dmix) by default for all ALSA apps (works without Pipewire or PulseAudio), make /usr/share/alsa/cards/simple-card.conf file contain this:\n# default with dmix/dsnoop simple-card.pcm.default { @args [ CARD ] @args.CARD { type string } type asym playback.pcm { type plug slave.pcm { @func concat strings [ \u0026#34;dmix:CARD=\u0026#34; $CARD \u0026#34;,RATE=44100\u0026#34; ] } } capture.pcm { type plug slave.pcm { @func concat strings [ \u0026#34;dsnoop:CARD=\u0026#34; $CARD \u0026#34;,RATE=44100\u0026#34; ] } } } Pop/click suppression workaround If you’re annoyed by loud popping and clicking sounds, which occur a few seconds after the sound playback stops as a result of the components of the audio chain being turned on and off automatically by the Linux kernel, you can execute the following command manually, or automatically on boot using the tmpfiles.d systemd feature, for example:\necho 50 \u0026gt; /sys/kernel/debug/asoc/rockchip,es8316-codec/dapm_pop_time This is a workaround because it effectively (ab)uses a built-in debugging feature of the Linux kernel’s audio subsystem, and one of the downsides is that a lot of messages are produced in the kernel log whenever the components of the audio chain are turned on and off automatically by the kernel.\nSpeaker polarity workaround On newer Pinebook Pro batches, the inverted built-in speaker polarity issue has been fixed. On these units, the speaker polarity can be made reversed again by the alsa-ucm-conf package, which configures ALSA devices continuously. One workaround would be to remove the package, and the speaker polarity will no longer be set incorrectly. However, this also prevents the built-in speakers from being muted when an output device is plugged into the aux port. Another workaround is to edit file /usr/share/alsa/ucm2/Rockchip/es8316/HiFi.conf and change all instances of R Invert to Normal. This is a workaround because it’s likely to be overwritten and lost if the alsa-ucm-conf package is updated.\nBluetooth and WiFi The Pinebook Pro’s AP6256 wireless module\nHardware Overview The Pinebook Pro contains an AMPAK AP6256 wireless module to provide Wi-Fi (compliant to IEEE 802.11ac) and Bluetooth (compliant to Bluetooth SIG revision 5.0). The module contains a Broadcom transceiver IC, believed to be the BCM43456, as well as the support electronics needed to allow the Wi-Fi and Bluetooth modes to share a single antenna.\nThe wireless module interfaces with the Pinebook Pro’s system-on-chip using a combination of three interfaces: Bluetooth functionality is operated by serial UART and PCM, while the Wi-Fi component uses SDIO. It is unknown if the module’s Bluetooth capabilities are usable under operating systems that do not support SDIO.\nThe module’s RF antenna pin is exposed on the mainboard via a standard Hirose U.FL connector, where a coaxial feedline links it to a flexible adhesive antenna situated near the upper right corner of the Pinebook Pro’s battery. As the RF connector is fragile and easily damaged, it should be handled carefully during connection and disconnection, and should not be reconnected frequently.\nIssues Problems have been reported with the Wi-Fi transceiver’s reliability during extended periods of high throughput, especially on the 2.4 GHz band. While the cause of this has yet to be determined, switching to the 5 GHz band may improve stability.\nSince the Bluetooth transceiver shares both its spectrum and antenna with 2.4 GHz Wi-Fi, simultaneous use of these modes may cause interference, especially when listening to audio over Bluetooth. If Bluetooth audio cuts out frequently, switching to the 5 GHz band – or deactivating Wi-Fi – may help.\nWi-Fi Capabilities Wi-Fi on the Pinebook Pro is capable of reaching a maximum data transfer rate of approximately 433 megabits per second, using one spatial stream. The transceiver does not support multiple spatial streams or 160-MHz channel bandwidths.\nThe Wi-Fi transceiver supports the lower thirteen standard channels on the 2.4 GHz band, using a bandwidth of 20 MHz. At least twenty-four channels are supported on the 5 GHz band, spanning frequencies from 5180 to 5320 MHz, 5500 to 5720 MHz, and 5745 to 5825 MHz, with bandwidths of 20, 40, or 80 MHz. This might vary depending on the country you specify in the wireless settings, see iw reg get; iw list.\nMaximum reception sensitivity for both bands is approximately -92 dBm. The receiver can tolerate input intensities of no more than -20 dBm on the 2.4 GHz band, and no more than -30 dBm on the 5 GHz band. Maximum transmission power is approximately +15 dBm for either band, falling further to approximately +10 dBm at higher data transfer rates on the 5 GHz band.\nWith current available drivers and firmware, the Wi-Fi interface supports infrastructure, ad-hoc, and access-point modes with satisfactory reliability. Monitor mode is not presently supported. Wi-Fi Direct features may be available, but it is unclear how to make use of them under Linux.\nBe aware that Linux userspace utilities, such as iw, may report inaccurate information about the capabilities of wireless devices. Parameter values derived from vendor datasheets, or direct testing, should be preferred to the outputs of hardware-querying tools. That said, if a certain feature is not reported by iw it means the currently running kernel driver plus firmware combination doesn’t support it, even when the hardware is capable.\nWPA3 PSK support should be possible with iwd but not wpa_supplicant, see this ticket for details.\nBluetooth Capabilities Bluetooth data transfer speeds have an indicated maximum of 3 megabits per second, but it is unclear what practical data rates can be expected. Audio streaming over Bluetooth is functioning normally, as is networking. Bluetooth Low-Energy functions, such as interacting with Bluetooth beacons, have not yet been tested conclusively.\nThe Bluetooth transceiver supports all 79 channel allocations, spanning frequencies from 2402 MHz to 2480 MHz. Reception sensitivity is approximately -85 dBm, with a maximum tolerable reception intensity of -20 dBm. Bluetooth transmission power is limited to +10 dBm.\nDisabling Bluetooth To disable Bluetooth under Linux once:\nsudo rfkill block bluetooth To confirm if Bluetooth under Linux is disabled:\nrfkill To disable Bluetooth on boot (NOTE: for distributions such as Manjaro XFCE see the step below):\nsudo systemctl enable rfkill-block@bluetooth To disable Bluetooth on certain distributions, such as Manjaro XFCE, right click on the Bluetooth panel icon, select plugins, then PowerManager, then configuration and then deselect the auto power on option\nBootable storage The PineBook Pro eMMC module and switch, shown in \u0026rsquo;enabled\u0026rsquo; position\nBoot sequence details The RK3399’s mask 32KB ROM boot code looks for the next stage of code at byte off-set 32768, (sector 64 if using 512 byte sectors). This is where U-Boot code would reside on any media that is bootable, RK3399 boot sequence\nBoot devices The Pinebook Pro is capable of booting from eMMC, USB 2.0, USB 3.0, or an SD card. It cannot boot from USB-C. The boot order of the hard-coded ROM of its RK3399 SoC is: SPI NOR, eMMC, SD, USB OTG.\nAt this time, the Pinebook Pro ships with a Manjaro + KDE build with u-boot on the eMMC. Its boot order is: SD, USB, then eMMC.\n(An update has been pushed for the older Debian + MATE build that improves compatibility with booting other operating systems from an SD card. In order to update, fully charge the battery, establish an internet connection, click the update icon in the toolbar, and then reboot your Pinebook Pro. Please see this log for details.)\nPlease note that PCIe, the interface used for NVMe SSD on the Pinebook Pro, is not bootable on the RK3399 and therefore is not a part of the boot hierarchy. It is possible to run the desired OS from NVMe by pointing extlinux on the eMMC to rootfs on the SSD. This requires U-Boot, the Kernel image, DTB, and extlinux.conf in a /boot partition on the eMMC.\neMMC information The eMMC appears to be hot-pluggable. This can be useful if trying to recover data or a broken install. Best practice is probably to turn the eMMC switch to off position before changing modules. Note that the enable/disable label on the silkscreen is incorrect on some board revisions (known bad on v2.1).\nThe eMMC storage will show up as multiple block devices:\nmmcblk1boot0 - eMMC standard boot0 partition, may be 4MB mmcblk1boot1 - eMMC standard boot1 partition, may be 4MB mmcblk1rpmb - eMMC standard secure data partition, may be 16MB mmcblk1 - This block contains the user areas Only the last is usable as regular storage device in the Pinebook Pro. The device number of \u0026ldquo;1\u0026rdquo; shown above may vary, depending on kernel.\nIf the eMMC module is enabled after boot from an SD card, you can detect this change with the following commands as user \u0026ldquo;root\u0026rdquo;:\necho fe330000.mmc \u0026gt;/sys/bus/platform/drivers/sdhci-arasan/unbind echo fe330000.mmc \u0026gt;/sys/bus/platform/drivers/sdhci-arasan/bind (Note: with the device trees coming with older kernels (Linux \u0026lt; 5.11), the device name may be fe330000.sdhci instead of fe330000.mmc)\nExternal ports list Here are a list of the external ports. See Technical Reference - Expansion Ports for port specifications.\nLeft side Barrel jack for power, (with LED) USB 3, Type A USB 3, Type C Right side USB 2, Type A Standard headset jack MicroSD card slot Internal layout Main chips RK3399 system-on-chip (1) LPDDR4 SDRAM (21) SPI NOR flash memory (29) eMMC flash memory module (26; Note: Some datasheets indicate a low supported number of mating cycles.) WiFi/BT module (27) Mainboard Switches and Buttons There are two switches on the main board: disabling the eMMC module (24), and enabling serial console UART (9) via headphone jack.\nThe Reset and Recovery buttons (28): the reset button performs an immediate reset of the laptop. The Recovery button is used to place the device in maskrom mode. This mode allows flashing eMMC using Rockchip tools (e.g. rkflashtools).\nKey Internal Parts Number Type Descriptor 1 Component RK3399 System-On-Chip 2 Socket PCIe x4 slot for optional NVMe adapter 3 Socket Speakers socket 4 Socket Touchpad socket 5 Component Left speaker 6 Connector Power bridge connector 7 Socket Keyboard Socket 8 Component Optional NVMe SSD adapter 9 Switch UART/Audio switch - enables serial console UART via headphone jack 10 Socket Power bridge socket 11 Socket Battery socket 12 Component Touchpad 13 Component Battery 14 Component Right speaker 15 Socket MicroSD card slot 16 Socket Headphone / serial console UART jack 17 Socket USB 2.0 Type A 18 Socket Daughterboard-to-mainboard ribbon cable socket 19 Cable Daughterboard-to-mainboard ribbon cable 20 Component microphone 21 Component LPDDR4 RAM 22 Socket Mainboard-to-daughterboard ribbon cable socket 23 Socket Microphone socket 24 Switch Switch to hardware disable eMMC 25 Antenna BT/WiFI antenna 26 Component eMMC flash memory module 27 Component BT/WiFi module chip 28 Buttons Reset and recovery buttons 29 Component SPI flash storage 30 Socket eDP LCD socket 31 Socket Power in barrel socket 32 Socket USB 3.0 Type A 33 Socket USB 3.0 Type C Smallboard detailed picture LCD panel Model: BOE NV140FHM-N49 14.0\u0026quot; (35.56 cm) diagonal size 1920x1080 resolution 60 Hz refresh rate IPS technology 1000:1 contrast 250 nit brightness 63% sRGB coverage 6-bit color 30-pin eDP connection LEDs In total, there are four LEDs on the Pinebook Pro, three of which are placed in the top-left side of the keyboard, and one near the barrel port:\nThe red LED next to the barrel port indicates charging, in three ways. First, it will illuminate steadily when either the barrel jack power supply or a USB Type-C charger is connected to the Pinebook Pro, and the charging is active (that means power is supplied to the battery and system in parallel, and if it’s not enough the battery can still be discharging). Second, if the battery is at 100 %, the LED will remain turned off regardless of the connected power input (however, this is not possible for more than a split-second when the system is running). Third, this LED will flash at 0.5 Hz if there are any problems that prevent charging, such as the battery becoming too hot. To fully understand all the nuances, read the Power and charging article. The power indicator LED, above the keyboard, supports three different colors: green, amber and red. It is also capable of flashing to indicate eMMC activity, with proper software support. In the default Debian with MATE build, green LED means power and red means suspend (amber is unused). The green NumLock LED, above the keyboard. The green CapsLock LED, above the keyboard. The NumLock and CapsLock LEDs serve their usual purposes on a keyboard, but they also have a secondary function. When the privacy switches get activated they blink to confirm that the switch has been activated.\nMicrophones While it has been said that some Pinebook Pro units contain only one microphone despite having two labeled microphone holes on the outer casing, other units do indeed contain two microphones. It is presently unclear which batches have either configuration. Units from the initial community batch of 1000 units (following the initial 100) are believed to contain two, populating both labeled holes.\nThe wires leading to both microphones connect to the mainboard with a small white plastic connector, located directly adjacent to the ribbon cable attachment point for the keyboard interface.\nBuilt-in microphones not working If pavucontrol input doesn’t show microphone activity try changing the privacy switches. If the switches are in the correct place and microphone input isn’t working you can run alsamixer from the command line, hit F6 and select the es8316, hit F4 to get to the capture screen, select the bar labeled ADC, increase the gain to 0 dB, change the audio profile in pavucontrol to another one with input. Additionally you may want to modify ADC PGA to get the levels to where you want them. If that still hasn’t fixed it you may want to check that the microphone connector is plugged in.\nExternal wired microphone not working If you connect a headset with a microphone, you might need to open alsamixer, change card to es8316, and change option Differential Mux from lin1-rin1 to lin2-rin2.\nPower supply Input Power: 5V DC, 15W (current limit 3A) Mechanical: 3.5mm OD / 1.35mm ID, Barrel jack USB-C 5V, 12.5W (current limit is at 2.5A regardless of the USB PD negotiations result) Only use one power input at a time, barrel jack OR USB-C (note: some powerful Type-C adapters have rather limited current for 5 V operation, and e.g. 2 A won’t be enough to run the system and charge the battery at the same time, so check the specs) SPI The Pinebook Pro comes equipped with two non-volatile storage components, the eMMC and the SPI. The capacity of the SPI is 128Mbit (16MiB) and it may be used in the boot process.\nBoot data can be written to the SPI via two methods: either from within PBP or from a second machine connected to the PBP by USB.\nWriting to SPI from within PBP Forum user pcm720 provided an example of writing to the SPI from within Linux in their self-published version of U-Boot that offers boot functionality for NVMe drives. It involves use of flash_erase command (available in the mtd-utils package on Arch/Manjaro) and the dd command.\nHowever, flashcp command should be used instead of dd, to make sure all specifics of the underlying flash memory are covered.\nWriting to SPI from a second machine Writing to the SPI from a second machine is more complicated than the other method, but it is the only option when troubleshooting an SPI flash gone wrong. This method works by bringing the RK3399 SoC into maskrom mode and issuing commands on the second machine that download the flash image onto the Pinebook Pro.\nUpon entering maskrom mode, the power LED on your Pinebook Pro won’t light up and neither will the display. Instead, your second machine, the one connected to your Pinebook Pro via USB, will indicate maskrom mode by logging to journalctl.\nThere are two ways to reach maskrom mode, but the first tends to be less reliable.\nMaskrom mode (unreliable method) Note The recovery button relies entirely on the software support in the boot loader, which makes it unreliable. According to Rockchip documentation, these steps should work; unfortunately, many users have reported them to be unsuccessful. You may need to repeat these steps several times for them to work.\nPress and hold recovery button. Short press reset. Release recovery button after about three seconds. In case this approach fails, please see the section below for a more reliable method.\nMaskrom mode (reliable method) Warning When removing the large RF shield found on the mainboard, to be able to short the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. Build and install rkdeveloptool (see project repository for instructions) Verify successful installation. Running rkdeveloptool --version should output: rkdeveloptool ver 1.3 Run journalctl -f and keep it running. Once the Pinebook Pro is connected and maskrom mode is reached it will produce additional output. Power off the Pinebook Pro. Unscrew the bottom cover. Remove the metal RF shield surrounding the main CPU. The shield is held in place small clamps on the board. The clamps can be released with a pry tool and some force. This forum post with photos shows how it can be done. Disconnect all boot devices, i.e. eMMC, microSD card and USB. Locate SPI flash (component number 29 on this photo of the Pinebook Pro internals). Connect your Pinebook Pro with USB-C to USB-A cable to second machine (Pinebook Pro on the USB-C side) Short pins CLK and VSS (see chip diagram to the right for the names of pins). This can be done with a pair of tweezers when short on tools. right\nPower on the Pinebook Pro. Press the reset button (component number 28). Check if there is new output from journalctl program. Check if the Pinebook Pro is connected by running rkdeveloptool ld. If successful, the output should be like: DevNo=1 Vid=0x2207,Pid=0x330c,LocationID=1401 Maskrom After entering maskrom mode Now that when the RK3399 SoC is in maskrom mode, you can use rkdeveloptool to write data to the SPI. To do so you’ll need the binary file you’ll be writing to SPI, which will be referred to as SPI_new.bin, and a helper file named rk3399_loader_spinor_v1.15.114.bin.\nFlash the flash helper db file: rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin. If successful, the output should read Downloading bootloader succeeded. Flash the new SPI binary: rkdeveloptool wl 0 SPI_new.bin. If successful, the output should read: Write LBA from file (100%). Test the installation: rkdeveloptool td. If successful, output should read Reset Device OK. Run rkdeveloptool rd to reboot your Pinebook Pro. Zeroing out the SPI In case, you wrote something bad to your SPI, it’s helpful to wipe away that data with zeros. To do that, you follow the same steps above to enter maskrom mode and then write a binary file that consists of all zeros.\nCreate the binary file dd if=/dev/zero of=zero.bin bs=1M count=16 Flash the flash helper db file: rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin. If successful, the output should read Downloading bootloader succeeded. Flash the new SPI binary: rkdeveloptool wl 0 zero.bin. If successful, the output should read: Write LBA from file (100%). Test the installation: rkdeveloptool td. If successful, output should read Reset Device OK. Run rkdeveloptool rd to reboot your Pinebook Pro. Touchpad Documentation for the touchpad can be found in Datasheets for Components and Peripherals. It is the only component of the Pinebook Pro held in place with strong adhesive tape. Here are some of its features:\n2 actuating buttons. multi-touch functionality. A matte finish that your finger can slide along easily. A reasonable size (96 mm × 64 mm; diagonal: 115.378 mm or 4.542 inches). Troubleshooting If you are having trouble using 2 fingers to scroll or emulate the click of a mouse’s right-button, then try these solutions:\nUpdate the firmware. Keep your 2 fingers spread apart rather than close together. Individual programs might need to be configured specially. *. For smooth scrolling and gestures under X-Windows, Firefox should be launched with with the following environment variable assignment: MOZ_USE_XINPUT2=1\nExperiment with other settings, via X-Windows Configuration or some other system preferences. For example, you could disable double-finger scrolling, and instead enable scrolling by sliding one finger along the edge of the touchpad. Firmware The touchpad controller is connected to the keyboard controller. All touchpad events go through the keyboard controller and its software, then to the keyboard controller’s USB port. Note that the touchpad does have separate firmware (which has to be written through the keyboard controller). The touchpad vendor’s firmware binary can be flashed from userspace using the following open source command-line utility:\nKamil Trzciński’s pinebook-pro-keyboard-updater. Naturally, forks have begun to appear:\nJack Humbert’s fork Dragan Simic’s fork. This one has recently delivered a much improved firmware from the vendor one, which greatly improves the control of the cursor (see this thread for discussion). Before installing this update, consider resetting to the defaults any configuration of your touchpad. All Pinebook Pros shipped from the factory have the old buggy version installed so consider updating the keyboard and touchpad firmware with the latest fixes from Dragan.\nWarning DO NOT update the touchpad firmware before checking which keyboard IC your Pinebook Pro has. Some Pinebook Pro were delivered with a SH61F83 instead of a SH68F83. The SH61F83 can only be written 8 times, this will render the keyboard and touchpad unusable if this limit is reached when step 1 (see below) is flashed. See Reddit SH61F83 thread. The keyboard IC corresponds to U23 on the top layer silkscreen of the main board. It is located under the keyboard flat flexible cable. All the PBPs from the post-pandemic batches have SH61F83 but TL Lim claimed they can be flashed just the same. No updated datasheet or a statement from the MCU vendor was provided though, so proceed at your own risk. Experience shows flashing those works for at least one time. Before updating any firmware, your Pinebook Pro should be either fully charged or, preferably, running from mains. This utility will be writing data to chips on the keyboard and touchpad, so a loss of power during any stage of the update can result in irrecoverable damage to your touchpad or keyboard.\nThe scripts ought to work on all operating systems available for the Pinebook Pro. Some operating systems may however, require installation of relevant dependencies. The instructions below assume a Debian desktop. To install these dependencies, newer Pinebook Pro models that come with Manjaro will require a different command.\nThere are two keyboard versions of the Pinebook Pro: ISO (vertical Enter key) and ANSI (horizontal Enter key). You need to know which model you have prior to running the updater.\nFirmware update steps for both models are listed below.\nWhat you will need:\nConnection to internet for getting dependencies, either through Wi-Fi or wired ethernet (USB dongle). Your Pinebook Pro fully charged or running from mains power. An external USB keyboard and mouse (or access to the Pinebook Pro via SSH. Please note that for some configurations, the SSH service might not be available without first having logged in once. In this case, you will definitely want at least an external keyboard or UART serial console). ISO Model From the terminal command line:\nDebian-based distributions:\ngit clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater cd pinebook-pro-keyboard-updater sudo apt-get install build-essential libusb-1.0-0-dev xxd make Arch-based distributions (note: build-essential, xxd are named differently. Arch linux does not split its packages as foo and foo-dev):\ngit clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater cd pinebook-pro-keyboard-updater sudo pacman -Syu base-devel xxd-standalone libusb make The next steps are identical for both Debian and Arch distros.\nStep 1\ncd pinebook-pro-keyboard-updater sudo ./updater step-1 sudo poweroff # do not use \u0026#39;reboot\u0026#39; Step 2 (after booting)\ncd pinebook-pro-keyboard-updater sudo ./updater step-2 iso sudo poweroff # do not use \u0026#39;reboot\u0026#39; ANSI Model Note Running step 1 on the ANSI keyboard model will make the keyboard and touchpad inaccessible until step 2 is run, so an external keyboard must be connected to complete the update on this model! From the terminal command line:\nDebian-based distributions:\ngit clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater cd pinebook-pro-keyboard-updater sudo apt-get install build-essential libusb-1.0-0-dev xxd make Arch-based distributions (note: build-essential, xxd are named differently. Arch linux does not split its packages as foo and foo-dev):\ngit clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater cd pinebook-pro-keyboard-updater sudo pacman -Syu base-devel xxd-standalone libusb make The next steps are identical for both Debian and Arch distros.\nStep 1\ncd pinebook-pro-keyboard-updater sudo ./updater step-1 sudo poweroff # do not use \u0026#39;reboot\u0026#39; Step 2 (after booting)\ncd pinebook-pro-keyboard-updater sudo ./updater step-2 ansi sudo poweroff # do not use \u0026#39;reboot\u0026#39; When done, if some of the keys produce incorrect characters, please check your OS’s language settings. For ANSI users, the default OS may have shipped with English UK as the default language. You can change it to English US if desired.\nRevised Firmware In addition, you might consider using revised firmware data. This is one final step that should not require a reboot:\nStep 3: ISO (after booting)\nsudo ./updater flash-kb firmware/default_iso.hex Step 3: ANSI (after booting)\nsudo ./updater flash-kb firmware/default_ansi.hex X Window System Configuration Note Before making adjustments, consider updating the firmware. Reset your adjustments before updating the firmware, so that your adjustments do not interfere with new functionality. When using X.Org display server the touchpad can be handled either by libinput or synaptic input drivers. The former allows to have shared configuration for both X.Org and Wayland but the latter provides more tunables (e.g. configurable edge scrolling, circular scrolling, mapping of multi-touch events to mouse buttons etc.).\nSome forum members have found that an adjustment to X11 will allow finer motion in the touchpad. If you use the synaptic mouse/touchpad driver, use this command to make the change live:\nsynclient MinSpeed=0.2 You may experiment with different settings, but 0.25 was tested as helping noticeably.\nTo make the change persist across reboots, change the file /etc/X11/xorg.conf similar to below:\nSection \u0026#34;InputClass\u0026#34; Identifier \u0026#34;touchpad catchall\u0026#34; Driver \u0026#34;synaptics\u0026#34; MatchIsTouchpad \u0026#34;on\u0026#34; MatchDevicePath \u0026#34;/dev/input/event*\u0026#34; *Option \u0026#34;MinSpeed\u0026#34; \u0026#34;0.25\u0026#34;* EndSection The line \u0026ldquo;Option \u0026ldquo;MinSpeed\u0026rdquo; \u0026ldquo;0.25\u0026quot;\u0026rdquo; is changed here.\nAnother forum user built on the above settings a little, and have found these to be very good:\nsynclient MinSpeed=0.25 synclient TapButton1 synclient TapButton2=3 synclient TapButton3=2 synclient FingerLow=30 synclient PalmDetect=1 synclient VertScrollDelta=64 synclient HorizScrollDelta=64 FingerLow has the same value as \u0026lsquo;FingerHigh\u0026rsquo; in one config (30). It is believed to help reduce mouse movement as you lift your finger, but it’s unknown whether synaptic works like this. You may find this config to be comfortable for daily use.\nTabButton allows to just tab the touchpad instead of physically pressing it down (to get this click noise).\nThe right mouse click is emulated by tapping with two fingers on the touchpad. If you feel that this is not very responsive you can try this value:\nsynclient MaxTapTime=250 Some users may encounter an issue with the mouse jumping when typing when using libinput driver due to their hand hitting the touchpad which can be fixed by updating the X.Org settings to disable it while typing. One can disable the touchpad while typing by setting the below option in the X.Org config simliar to the previous example.\nOption \u0026#34;DisableWhileTyping\u0026#34; \u0026#34;on\u0026#34; The setting can be verified by using the xinput command to first list the devices and then listing the properties for the touchpad device. Exact commands to check this have been omitted for save of brevity. If DisableWhileTyping is shown enabled but does not appear to be working the issue may be due to the fact that the keyboard is connected to a USB bus which causes it to be seen as a external keyboard. Make sure you have libinput version 1.19.0 or later installed as it includes the necessary quirk.\nSynaptic driver users can add syndaemon to their X11 session for the same effect.\nWebcam Tip You can use Cheese to test the Camera functionality Streaming video resolutions supported, (uncompressed):\n320 x 240 640 x 480 800 x 600 1280 x 720 1600 x 1200 Still frame resolutions supported:\n160 x 120 176 x 144 320 x 240 352 x 288 640 x 480 800 x 600 1280 x 720 1600 x 1200 Keyboard The Pinebook Pro is available in two keyboard configurations: ISO and ANSI. Both the keyboard and touchpad in the Pinebook Pro use the USB 2.0 protocol and show up as such in xinput. The keyboard features function (Fn) keys in the F-key row, which include display brightness controls, sound volume, touchpad lock, and other functionality. There is also a custom PINE64 logo key that functions as Menu/Super key. It has also a secondary functionality for setting the privacy switches.\nThe keyboard firmware binary can be flashed from userspace using the provided open source utility.\nWarning DO NOT update the keyboard firmware before checking which keyboard IC your Pinebook Pro has. Some Pinebook Pro were delivered with a SH61F83 instead of a SH68F83. The SH61F83 can only be written 8 times, this will render the keyboard and touchpad unusable if this limit is reached when step 1 is flashed, see the Reddit SH61F83 thread. The keyboard IC corresponds to U23 on the top layer silkscreen of the main board. It is located under the keyboard flat flexible cable. Documentation for the keyboard can be found in Datasheets for Components and Peripherals and details regarding the assembly can be found under Keyboard assembly.\nTyping special characters The UK ISO Layout does not have dedicated keys for characters like the German umlauts (Ä, Ö, Ü, etc). Certain characters can still be generated by means of either key combinations or key sequences.\nCharacter Key combination/sequence Ä, Ö, Ü, ä, ö, ü AltGr + [ followed by A, O, U, a, o or u µ AltGr + m Ø, ø AltGr + O, AltGr + o @ AltGr + q (as on the German layout) ß AltGr + s § AltGr + S ° AltGr + ) Privacy Switches There are three privacy switches mapped to the F10, F11 and F12 keys on the Pinebook Pro keyboard. They de/activate the following:\nPrivacy switch function and description\nCombination Effect Description Notes PINE64 logo key+F10 Microphone Privacy switch CAPs lock LED blinks. 2 blinks = enabled, 3 blinks = disabled PINE64 logo key+F11 WiFi Privacy switch NUM lock LED blinks. 2 blinks = WiFi enabled / privacy switch disabled, 3 blinks = WiFi disabled / privacy switch enabled. Re-enabling requires reboot (or a command line hack to bind/unbind). PINE64 logo key+F12 Camera privacy switch CAPs lock and NUM lock LEDs blink together. 2 blinks = enabled, 3 blinks = disabled Can use tools like lsusb to detect camera’s presence. If not detected, check privacy switch. Note Press the PINE64 logo key plus F10/F11/F12 for 3 seconds The keyboard operates on firmware independent of the operating system. It detects if one of the F10, F11 or F12 keys is pressed in combination with the Pine key for 3 seconds. Doing so disables power to the appropriate peripheral, thereby disabling it. This has the same effect as cutting off the power to each peripheral with a physical switch. This implementation is very secure, since the firmware that determines whether a peripheral gets power is not part of the Pinebook Pro’s operating system. So the power state value for each peripheral cannot be overridden or accessed from the operating system. The power state setting for each peripheral is stored across reboots inside the keyboard’s firmware flash memory.\nBasic summary of replacing keyboard This guide is very basic and should be fleshed out with (better) pictures. There just isn’t a list of steps anywhere else yet.\nHere’s what the replacement keyboard looks like:\nStep 0: If changing from ISO keyboard to ANSI keyboard, or vice versa, be sure to have a system capable of running the firmware updater that you can access either remotely or with a USB keyboard beyond the internal keyboard, as the firmware for each is very different and keys won’t work correctly. See https://forum.pine64.org/showthread.php?tid=8407 (and for NetBSD, https://forum.pine64.org/showthread.php?tid=8716).\nStep 1: The remove back back panel.\nThere are 10 screws on the back that must be removed, and the back panel detached. I recommend using a PH0 bit. The speakers may remain attached via glue to the case and should be carefully pried off. When this is done, taking photos of how everything looks now can help put it all back together later.\nStep 2: Places to unscrew.\nThere are 3 items screwed into the keyboard frame that must be removed. There are 2 large screws for daughter board, 3 large screws and 1 small screw for mainboard, and 4 small screws for battery. Be sure to not lose them. I recommend a PH00 bit for the large screws on the daughter and main boards and a PH1 bit for the small screws on the battery and mainboard.\nStep 3: Remove the battery.\nOnce the battery screws are removed, it should be unplugged from the mainboard and removed. Note that there are two unconnected cables lying around, that should remain unconnected. They are used when the battery is disconnected entirely.\nStep 4: Unplug the ribbon cables.\nNote you should remove the M.2 adapter board now if you have one installed. See elsewhere in the documentation for instructions on how to install/remove that piece. There are several ribbon cables. To remove, flip up the tab and gentle pull the ribbon out.\nOne cable runs from the mainboard to the daughterboard underneath the battery. Detach from both ends. With the battery removed, detach from keyboard shell, and set aside for the new keyboard shell. One cable runs between the touchpad and the mainboard. Detach from both ends, and also set aside. One cable runs between the keyboard and the mainboard. This one remains attached to the keyboard and only needs to be detached from the mainboard. One cable from the LCD attaches near the lid hinge. It should be just unplugged. Step 5: Detach microphone, speakers, and antenna.\nOne of the Pinebook Pro microphones after removal\nThe speakers, microphone, and antenna don’t have to be detached from the mainboard, but they need to be detached from the keyboard shell. The microphones are held in place by tape, and the speakers have sticky sides. The speakers are found obviously, but the microphones (two of) can be found between the battery and the hinge area. Each microphone can be carefully pulled/wedged out of its position by a small screwdriver or pick. The antenna, similar to the microphones, is found near the hinge area and to the top left of the battery.\nStep 6: Remove mainboard and daughterboard.\nAt this point, the mainboard and daughterboards should be removed. When unscrewed (see Step 2) they should pull out fairly easily. Put them aside (including microphones and speakers if left attached.)\nStep 7: Detach the LCD panel.\nStep 2 didn’t tell you, there are 6 more screws to remove here, 3 for each of the hinges. I recommend a PH1 bit for these screws. Unscrew these and the LCD panel will be able to be removed. You may have to jiggle or move the hinges for this. When detached, be sure to place the LCD panel such that the display is protected.\nStep 8: Try not to break your touchpad\nNOTE This section really feels like you’re going to break something.\nThe touchpad is glued to the keyboard shell and it’s glued well. There are two places it is glued to. If you can, only the middle must be force-detached. You will think you’re going to break it. Gently apply increasing force until the glue begins to detach (you will hear a crackle as it comes off), and continue very slowly until the whole thing is detached. This may take minutes due to that feeling you’re going to break it.\nI found it helpful to lift the top left plastic bit on the keyboard to unstick that portion of the touchpad, then push on the top left portion of the touchpad to unstick the rest of the touchpad.\nStep 9: Over the hill, touchpad goes into new shell.\nIn the new keyboard shell put the touchpad back where it was, hopefully the glue will remain sufficiently attached. If there is a glue issue, this guide unfortunately has no advice currently.\nStep 10: Reattach the LCD panel.\nThe LCD panel should slot back into the keyboard frame, the same way it came out. If the hinges were moved, they should be very gently closed such that the LCD panel and keyboard closed like normal for the remaining steps.\nStep 11: Tape it out.\nMove any tape from the old keyboard shell to the new one. These items protect the mainboard and daughterboard, and keep various wires in their right place. Some are grey and some are black. For tape that holds the speakers, microphones, or their cables in place, do not reattach yet.\nStep 12: Board install.\nInstall the mainboard, the daughterboard, and their connecting ribbon cable. Be sure to put the boards in place, 2 large flat screws for the daughterboard, 3 large flat screws and one small screw for the mainboard, before attempting to place the ribbon.\nStep 13: Microphone, speaker, and antenna install.\nReattach the microphones, antenna, and speakers to their respective areas, making sure that both are properly oriented - the speaker \u0026ldquo;out\u0026rdquo; faces up, and the microphone cables as connected must face up (these are opposite directions.)\nStep 14: Reattach other ribbon cables.\nNote this would be a good time to attach/install the M.2 adapter board if that is desired. See elsewhere in the documentation for those instructions. The LCD panel, keyboard and touchpad ribbon cables should be reattached. Make sure the flap is open, insert the ribbon into the slot (a portion of the cable will disappear), and push the flap down. The cable should not be easy to pull out.\nStep 15: Reattach the battery, and final re-tape.\nThe battery should be installed with the 4 screws holding it in place, and the connector attached to the mainboard. Be sure to keep the two other cables remain unconnected. Ensure all wires and other tapes are held in place.\nStep 16: Reattach the back panel.\nPut the back panel back on, and reattach the 10 screws.\nStep 17: If you changed from ISO to ANSI or from ANSI to ISO, you’ll need to update your firmware now. See the links in Step 0 above.\nAssembly Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. The Pinebook Pro keyboard comes as a pre-assembled unit built into the main shell of the device, a damaged shell had the keyboard removed from it to be studied. Note that removing the keyboard from the shell is technically irreversible since it’s held in with melted plastic rivets. If these ever happen to break then you could likely hold the keyboard in with adhesives or drill small holes and use screws instead.\nThe keyboard is sandwiched between a thick (likely 0.7mm) steel plate and the plastic shell, this steel plate serves as a mounting point for some of the components inside the laptop as well as adding a significant amount of structural rigidity to the device. The actual keyboard is made of a very thin metal backplate, a clear flexible plastic PCB, and a black flexible plastic layer that appears to be removable but more research will need to be done.\nThe key mechanism is a relatively modern style of scissor switch, the upside to this mechanism is that the keys have a very nice feel to them and don’t fall apart easily, the downside is that if the plastic scissor mechanism gets damaged the whole key assembly will start to fall off due to slipping out from under the metal arms in the keyboard backplate. The only known fix is to replace the key assembly, or more likely the entire keyboard mechanism, more research should be done into this.\nOlder style scissor switches allowed you to just pull the keycap straight off the mechanism and snap it back into place by pressing down on it. Do not do this for newer mechanisms like the Pinebook Pro keyboard, all that will do is damage the mechanism.\nRemoving Keys Warning Do not attempt this unless you know what you’re doing, there will be very few cases where this works Keys can be relatively safely removed (however the mechanism can easily be damaged by someone who doesn’t know what they’re doing) when the keyboard assembly has been removed from the shell, however with the shell in place it blocks movement of the keys that is required to unhook the mechanism from the metal backplate.\nTip The keys might be removable without taking the keyboard out of the frame, this needs more research To remove a key, first push it all the way in, slide it upwards slightly, and lift the top half of the key, this should dislodge the upper half of the scissor mechanism, this step can be tricky, the keys were designed to be assembled once and never removed again.\nNext you can just slide the key down slightly, this will dislodge the lower half of the scissor mechanism and the key should come completely off the keyboard.\nRe-attaching a key can be quite fiddly since the mechanism stays attached to the key rather than the keyboard like older scissor designs.\nThe assembly process is the same as disassembly, just reversed, but you have to be careful with horizontal alignment, otherwise the lower half of the mechanism won’t lodge in place.\nNote that if a key mechanism is damaged, pressing in the upper corners of the key will cause it to dislodge and fall off the keyboard.\nDamaged keys might look like this, note that the pin on the lower right side of the mechanism is slightly deformed and the latch on the upper half of the mechanism is bowed out slightly and cracked. This is enough damage to cause the key to pop out when pressed in the upper corners.\nGuides Caring\nDisassembly and Reassembly\nSkinning and case customization\nUsing the optional NVMe adapter\nUsing the SPI flash device\nCaring Bypass Cables Warning Do not connect the bypass cables with the battery connected. Using the bypass cables with the battery connected can permanently damage your Pinebook Pro. After you’re done with using the bypass cables and want to return to the default setup, make sure to affix the bypass cables to the main body of the laptop using adhesive tape, in the same way as it was done in the factory. This ensures that the exposed leads in the connectors on the bypass cables don’t touch any conductive surface inside the laptop, which may cause a short. The mainboard features two bypass cables that are to be used only with the battery disconnected. The two bypass cables are disconnected by default. The female (10) male (6) ends of the bypass cables can be connected to provide power to the mainboard if you need to run your Pinebook Pro with no battery. Please refer to this engineering notice for more details.\nConnecting the bypass cables together effectively connects the charger input where the battery output is, which also bypasses the charging circuit inside the Pinebook Pro. Thus, with the bypass cables connected together, the charger powers the Pinebook Pro directly, just like the battery does it when the laptop is running on battery power. This also means that no input current limiting is any longer in place, making it possible to draw more than 3 A from the charger, and to trigger its overcurrent protection, which may cause operating system instability and crashes.\nDespite the bypass cables having two conductors, they are used as a single conductor. Having both wires soldered together on either side of the bypass cables is normal, and such load-sharing design allows use of a compact connector on the bypass cables.\nWhen removing the large RF shield found on the mainboard, for example when shorting the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back.\nGuides These are self-service instruction guides for the disassembly of the 14-inch Pinebook, but they still almost directly apply to the Pinebook Pro:\nLithium Battery Pack Removal Guide LCD Panel Screen Removal Guide eMMC Module Removal Removal Guide Assembling it back requires the described steps to be performed in the reverse order.\nDisassembly and Reassembly Pinebook Screw stand-offs correct placement and location\nHinge_area_of_the_Pinebook_Pro_lid_with the cover removed\nClose-up of a Pinebook Pro lid hinge\nThere are a few mandatory precautions to be taken:\nDo not open the laptop by lifting the lid while the Pinebook Pro bottom cover is removed - this can cause structural damage to the hinges and/or other plastic components of the chassis such as the IO port cut-outs. When removing the back cover plate, do not, under any circumstances, slide your fingertips between the metal shell and the plastic frame! The back cover plate edges are sharp, and when combined with the pressure and movement generated from, specifically, attempting to slide the tips of your fingers along the bottom edge of the plate along the lid-hinge, they will slice open the tips of your fingers like a knife. When removing the back cover plate, use care to avoid damaging the speakers. They can be stuck to the back cover with double-sided tape, and the thin wires are very delicate. Newer Pinebook Pro laptops (as of the May 2021 batch, and perhaps earlier) seem to lack the double-sided tape to the rear cover, instead opting for tape or glue that makes them stick to the front cover. Nevertheless, be gentle when removing the back cover. Pinebook Pro external screws (this particular unit has suffered damage on screw (4)L)\nWhen disassembling the laptop make sure that it is powered off and folded closed. To remove the bottom cover of the Pinebook Pro, first remove the ten (10) Phillips head screws that hold the bottom section of the laptop in place. There are four (4) short screws along the front edge, and six (6) long screws along the 3 remaining sides. Remove the cover from the back where the hinges are situated by lifting it up and away from the rest of the chassis. The aluminum case is held on only by screws. There are no plastic snaps, and the shell should pull away without any effort. If you experience any resistance at all stop and ensure all ten (10) screws are accounted for.\nDuring reassembly, make sure that the back-screw standoffs are in place and seated correctly. Before replacing the aluminum back-plate, ensure that the speakers are properly seated by pressing gently on the hard plastic edge of the speaker module. Slide the bottom section into place so it meets the front lip of the keyboard section. Secure the front section (where the touchpad is located) in place using the short screws in the front left and right corners. Then proceed to pop in the bottom panel into place. Secure the bottom section (where hinges are located) by screwing in the left and right corners. Then screw in the remaining screws and run your finger though the rim on the chassis to make sure its fitted correctly. Note that the front uses the remaining 4 short screws.\nThe screws are small and should only be finger tight. Too much force will strip the threads. If after installing screws the back cover plate has not seated properly on one side (which may be caused by the aforementioned misseating of the speakers), open the display and hold the base on either side of the keyboard and gently flex the base with both hands in opposing directions. Once the side pops further in, then recheck the screws on that side. If it does not pop back in, re-open the machine and check for misseated components.\nA basic 3D model to print replacement standoffs for the back cover screws is available on Thingiverse, until the official drawings or 3D models are made available.\nMany units come with the hinges too stiff from the factory. You can tell if it affects your device by carefully observing if operating the lid on a fully assembled notebook flexes the case. This repeated flexing can lead to plastic and metal fatigue and eventually broken parts. Consider carefully using a flat screwdriver or similar object to unbend the hinges a bit by wedging it into the slot (requires the display part to be fully detached from the main body).\nDisplay disassembly It is not recommended to adjust the position of the lid when the bottom cover is removed, because the bottom cover provides structural strength, so the lid should be open fully as the first step, before starting any disassembly of the laptop. After opening the lid, remove the bottom cover by following the instruction found in the section above. Alternatively, you can keep the lid closed and remove the screws that hold the hinges to the main laptop body, as described in Pinebook Service Step by Step Guides.\nParts of the hinge mechanism, as well as the screws that hold the hinges to the lid, are hidden behind an elongated plastic U-shaped cover that snaps in place using latches. Use a dedicated plastic prying tool or a guitar pick to gently pry the cover and remove it, starting from the outer edge. Once you pry the cover to a certain extent, it should be possible to remove it fully using only your hands. The U-shaped cover is rather sturdy, but still be careful not to break or bend it.\nThere are two small screws hidden underneath the two small rubber nubs on the upper part of the screen bezel, so first gently remove the nubs and then remove the screws. The screen bezel is held in place with a combination of latches and some adhesive tape, which is there to prevent dust ingress. The adhesive isn’t very strong, and the bezel is capable of flexing back into shape after being twisted to a certain extent. There is more adhesive on the bottom part of the screen bezel, so be more careful while prying that section apart. Use the same prying tool that you used for the U-shaped cover, and work it around the outer edges of the screen bezel.\nSkinning and case customization Template files for creating custom skins. Each includes template layers for art placement, and CUT lines:\nCase Lid Template Case Bottom Template Case Palmrest Template Using the optional NVMe adapter The optional NVMe adapter allows the use of M.2 SSDs that support the NVMe standard (SATA is not supported). The adapter supports M and M+B keyed devices, in both 2242 and 2280 physical sizes, which are the most commonly available. In addition, 2230 and 2260 sizes are also supported, though NVMe devices that use those sizes are rare.\nMake sure to read the notes in Accessory compatibility before selecting an M.2 SSD for your Pinebook Pro, because there are certain limitations. Once you have fitted and tested your NVMe drive, please consider adding a note to that page\nPlease see a separate section that describes reported issues with the NVMe drives in Pinebook Pro.\nInstalling the adapter The V2.1-2019-0809 SSD adapter that shipped with the initial Pinebook Pro batches had significant issues. A repair kit will be shipped to address those issues. (If necessary, it can be modified to work. There is an unofficial tutorial on the forums describing these modifications.)\nThe updated SSD adapter, labeled V2-2019-1107, takes into account the prior problems with touchpad interference. New orders as of Feb. 22nd, 2020 will be the updated adapter.\nThis is the link to the Pinebook Pro accessories in the store: https://pine64.com/?v=0446c16e2e66\nActual installation instructions are a work in progress. Unofficial instructions for installing V2-2019-1107 can be found here.\nPost NVMe install power limiting Some NVMe SSDs allow reducing the maximum amount of power. Doing so may reduce the speed, but it may be needed in the Pinebook Pro to both improve reliability on battery: Some NVME may be stable with default settings when running on AC power but cause frequent kernel panics (system freeze with power LED blinking red/green) when running on battery. Reducing NVME power drain solves this in some cases. And reducing power used gives better battery life. Here are the commands to obtain and change the power settings. The package \u0026rsquo;nvme-cli\u0026rsquo; is required to run these commands. The example shows how to find the available power states, and then sets it to the lowest, non-standby setting, (which is 3.8 watts for the device shown):\n$ sudo nvme id-ctrl /dev/nvme0 NVME Identify Controller: ... ps 0 : mp:9.00W operational enlat:0 exlat:0 rrt:0 rrl:0 rwt:0 rwl:0 idle_power:- active_power:- ps 1 : mp:4.60W operational enlat:0 exlat:0 rrt:1 rrl:1 rwt:1 rwl:1 idle_power:- active_power:- ps 2 : mp:3.80W operational enlat:0 exlat:0 rrt:2 rrl:2 rwt:2 rwl:2 idle_power:- active_power:- ps 3 : mp:0.0450W non-operational enlat:2000 exlat:2000 rrt:3 rrl:3 rwt:3 rwl:3 idle_power:- active_power:- ps 4 : mp:0.0040W non-operational enlat:6000 exlat:8000 rrt:4 rrl:4 rwt:4 rwl:4 idle_power:- active_power:- $ sudo nvme get-feature /dev/nvme0 -f 2 get-feature:0x2 (Power Management), Current value:00000000 $ sudo nvme set-feature /dev/nvme0 -f 2 -v 2 -s set-feature:02 (Power Management), value:0x000002 Some NVMe SSDs don’t appear to allow saving the setting with \u0026ldquo;-s\u0026rdquo; option. In those cases, leave off the \u0026ldquo;-s\u0026rdquo; and use a startup script to set the non-default power state at boot. If you want to test performance without saving the new power setting semi-permanently, then leave off the \u0026ldquo;-s\u0026rdquo; option.\nOn systemd based distributions like Manjaro, a non-default power state for an NVME can be set using a systemd service. This is useful in cases where the NVME drive does not save the power state and/or uses APST. An example systemd service, nvme-throttle.service, is shown below:\n[Unit] Description=Throttles NVME to lesss power hungry mode After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target [Service] Type=oneshot ExecStart=/usr/bin/nvme set-feature /dev/nvme0 -f 2 -v 1 [Install] WantedBy=multi-user.target suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target Here the value after \u0026ldquo;-v\u0026rdquo; is the maximum power state that you want your SSD to use. This will be executed at system startup, and every time your system exits any suspend mode that might reset the SSD to default values.\nThis file needs to be placed in the /etc/systemd/system directory. Afterwards, to activate the service, run:\nsystemctl daemon-reload systemctl enable --now nvme-throttle.service There is another power saving feature for NVMes, APST, (Autonomous Power State Transitions). This performs the power saving \u0026amp; transitions based on usage. To check if you have a NVMe SSD with this feature:\n$ sudo nvme get-feature -f 0x0c -H /dev/nvme0 Information for this feature, (on a Pinebook Pro), is a work in progress. It is enabled by default in latest Manjaro kernels and reported to work. On some NVME SSDs (WD), APST is compatible with limiting NVMe maximum power: APST will work and not exceed maximum power state defined using previous method.\nUsing as data drive As long as the kernel in use has both the PCIe and NVMe drivers, you should be able to use a NVMe drive as a data drive. It can automatically mount when booting from either the eMMC or an SD card. This applies to Linux, FreeBSD, and Chromium, using the normal partitioning and file system creation tools. Android requires testing.\nUsing as OS root drive The SoC does not include the NVMe boot code, so the NVMe is not in the SoC’s boot order. However, using the U-Boot update script from the mrfixit2001 Debian or Arglebargle’s modified script, and the modified u-boot images provided by forum user pcm720, you can now add support to boot from an NVMe drive. Binary images are useable with SD, eMMC, and SPI flash. For OS images using the mainline kernel, there are a few variants of U-Boot available that also support NVMe as the OS drive. Though these may require writing the U-Boot to the SPI flash for proper use of the NVMe as the OS drive.\nThe current boot order, per last testing, for this modified U-Boot is:\nMicroSD eMMC NVMe For more information, please refer to the forum post.\nIt is also possible to initially boot off an eMMC or SD card, then transfer to a root file system on the NVMe. Currently, it is necessary to have the U-Boot code on an eMMC or SD card. (A forum member posted here about using a modified version of U-Boot with NVMe drivers, that uses /boot and / off the NVMe drive. So this may change in the future.)\nPlease see Bootable Storage.\nUsing the SPI flash device Warning When removing the large RF shield found on the mainboard, to be able to short the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. See SPI for details.\nThe Pinebook Pro comes with a 128 Mbit, (16MByte), flash device suitable for initial boot target, to store the bootloader. The SoC used on the Pinebook Pro boots from this SPI flash device first, before eMMC or SD card. At present, April 19, 2020, the Pinebook Pros ship without anything programmed in the SPI flash device. So the SoC moves on to the next potential boot device, the eMMC. ARM/ARM64 computers do not have a standardized BIOS, yet.\nHere is some information on using the SPI flash device:\nYou need the kernel built with SPI flash device support, which will supply a device similar to: /dev/mtd0 The Linux package below, will need to be available: mtd-utils You can then use this program from the package to write the SPI device: flashcp \u0026lt;filename\u0026gt; /dev/mtd0 Even if you need to recover from a defective bootloader written to the SPI flash, you can simply short pin 6 of the SPI flash to GND and boot. This will render the SoC bootrom unable to read from the SPI flash and have it fall back to reading the bootloader from other boot media like the eMMC or Micro SD card.\nThe procedures described above are a lot less risky than attaching an external SPI flasher and do not require any additional hardware. At present, April 19th, 2020, there is no good bootloader image to flash into the SPI flash device. This is expected to change, as there are people working on issue.\nFurther information Case dimensions and data\nDatasheets\nSchematics and certifications\nSpecifications\nCase dimensions and data Dimensions: 329 mm x 220 mm x 12 mm (W x D x H) Weight: 1.26 kg Screws on the bottom lid Philips-head type screws M2 flat-head machine screws 4 x short screw (used along the front edge): head diameter - 3.44 mm, thread diameter - 1.97 mm, thread length - 2.1 mm, overall length - 3.05 mm 6 x long screw (used elsewhere): head diameter - 3.44 mm, thread diameter - 1.97 mm, thread length - 4.41 mm, overall length - 5.85 mm Rubber feet 18 mm diameter 3 mm height Dome shaped Datasheets Rockchip RK3399 SoC information:\nRockchip RK3399 SoC Brief Rockchip RK3399 Datasheet v2.1 Rockchip RK3399 Technical Reference Manual v1.4, part 1 Rockchip RK3399 Technical Reference Manual v1.3, part 1 and part 2 Rockchip RK808 Datasheet v1.6 LPDDR4 SDRAM (366-pin BGA):\nMicron 366 balls Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet (updated) Wireless and Bluetooth information:\nAMPAK AP6256 11AC Wi-Fi + Bluetooth5 Datasheet Audio codec:\nEverest ES8316 Audio Codec Datasheet Everest ES8316 User Guide with register-level description LCD panel:\n14\u0026quot; 1920x1080 IPS LCD Panel datasheet USB-related information:\nInternal USB 2.0 hub: GL850G USB Hub Datasheet USB Type-C Controller: ON Semiconductor FUSB302 Datasheet Touchpad information:\nPineBook Pro Touchpad Specification Keyboard information:\nSinowealth SH68F83 Datasheet US ANSI: XK-HS002 MB27716023 Full HD camera sensor:\nFull HD Camera module specification (in Chinese) GalaxyCore GC2145 Full HD Camera Sensor Datasheet Battery-related information:\nBattery charging IC: Texas Instruments BQ24171 Datasheet Battery monitoring IC: Cellwise CW2015 Datasheet 10000 mAH Lithium Battery Specification Later batches 9600 mAh / 36.48 Wh model WYC40110175P Lithium Battery Specification Power path device:\nN-MOS / MOSFET NVMe adapter:\nFH26-35S-0.3SHW flat flex connector (compatible, not OEM) Schematics and certifications Pinebook Pro Main Board Schematic And Silkscreen:\nPinebook Pro Main Board ver 2.1a Schematic 20220419 Pinebook Pro Main Board ver 2.1 Schematic 20190905 Pinebook Pro ver 2.1 Top Layer Silkscreen Pinebook Pro ver 2.1 Bottom Layer Silkscreen Pinebook Pro Daughter Board Schematic:\nPinebook Pro Daughter Board ver 2.1 Schematic Optional Pinebook Pro NVMe Adapter Schematic:\nPinebook Pro NVMe Adapter Board ver 2.1 Schematic Serial Console Earphone Jack Pinout:\nPinebook Serial Console Earphone Jack Pinout Pinebook Pro Case:\nAutoCAD PDF File AutoCAD AI File AutoCAD DWG File Pinebook Pro Certifications:\nPinebook Pro FCC Certificate Pinebook Pro CE Certificate Pinebook Pro RoHS Certificate Specifications Based on Rockchip RK3399\nCPU Architecture big.LITTLE architecture: Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU\nFull implementation of the ARM architecture v8-A instruction set (both AArch64 and AArch32) ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation ARMv8 Cryptography Extensions VFPv4 floating point unit supporting single and double-precision operations Hardware virtualization support TrustZone technology support Full CoreSight debug solution One isolated voltage domain to support DVFS Cortex-A72 (big cluster):\nDual-core Cortex-A72 up to 2.0GHz CPU Superscalar, variable-length, out-of-order pipeline L1 cache 48KB Icache and 32KB Dcache for each A72 L2 cache 1024KB for big cluster Cortex-A53 (little cluster):\nQuad-core Cortex-A53 up to 1.5GHz CPU In-order pipeline with symmetric dual-issue of most instructions L1 cache 32KB Icache and 32KB Dcache for each A53 L2 cache 512KB for little cluster Cortex-M0 (control processors):\nCortex-M0 CPU Two Cortex-M0 cooperate with the central processors Architecture: Armv6-M Thumb/Thumb2 instruction set 32 bit only GPU Architecture ARM Mali-T860MP4 Quad-core GPU The highest performance GPUs built on Arm Mali’s famous Midgard architecture, the Mali-T860 GPU is designed for complex graphics use cases and provide stunning visuals for UHD content. Frequency 650MHz Throughput 1300 Mtri/s, 10.4 Gpix/s Graphic interface standards:\nOpenGL® ES 1.1, 1.2, 2.0, 3.0, 3.1, 3.2 (Panfrost has initial support of 3.0 beginning 2020/02/27) Vulkan 1.0, using the Mali binary blob (Panfrost does not support Vulkan as of 2020/06/24) OpenCL™ 1.1, 1.2 DirectX® 11 FL11_1 RenderScript™ System Memory RAM Memory:\nLPDDR4 800 MHz (limited by RK3399) Dual memory channels on the CPU, each 32 bits wide Quad memory channels on the RAM chip, each 16 bits wide, 2 bonded together for each CPU channel 4 GB as a single 366 pin mobile RAM chip Storage Memory:\n64GB eMMC module, can be upgraded to an 128GB eMMC module. (The initial PINE64 community build version shipped with a 128GB eMMC.) eMMC version 5.1, HS400, 8 bit on RK3399 side Bootable SPI flash:\nSPI 128 Mbit / 16MByte 1 bit interface Bootable, (first boot device, ahead of eMMC \u0026amp; SD card) U-Boot images can be made to work, but as of 2020/06/24 there is no standardized image available. Video out USB-C Alt mode DP Up to 3840x2160 p60, dependant on adapter, (2 lanes verses 4 lanes) Expansion Ports MicroSD card:\nBootable Supports SD, SDHC and SDXC cards, up to 512GB tested. SDXC standard says 2TB is the maximum. Version SD3.0, (MMC 4.5), up to 50 MB/s SD card Application Performance Class 1 (A1), (or better), recommended by some users, for better IOPS USB ports:\n1 x USB 2.0 Type-A Host Port, bootable 1 x USB 3.0 Type-A Host Port, 5 Gbps, is not bootable 1 x USB 3.0 Type-C OTG Port, 5 Gbps, (includes laptop charging function), is not bootable Note that high power USB devices may not work reliably on a PBP. Or they may draw enough power to drain the battery even when the PBP is plugged into A.C. One alternative is externally powered USB devices. Headphone jack switchable to UART serial console mux circuit\n","permalink":"/documentation/Pinebook_Pro/_full/","tags":null,"title":"Pinebook Pro (Single Page)"},{"categories":["Wearables"],"contents":" The PineBuds Pro The PineBuds Pro are open firmware capable ANC wireless earbuds. Some of the notable features include their light weight, 3 Microphones, ANC (Active Noise Cancellation), ENC (Environment Noise Cancellation) and high fidelity 6mm speaker. It is a fully community-driven side-project which anyone can contribute to, allowing you to keep control of your device even though hardware is proprietary.\nStores Global Global: Spare parts Affiliates Documentation PineBuds Pro Schematics and Certifications ","permalink":"/devices/pinebuds_pro/","tags":null,"title":"PineBuds Pro"},{"categories":null,"contents":" The PineBuds Pro\nThe PineBuds Pro are open firmware capable ANC wireless earbuds. Some of the notable features include their light weight, 3 Microphones, ANC (Active Noise Cancellation), ENC (Environment Noise Cancellation) and high fidelity 6mm speaker. It is a fully community-driven side-project which anyone can contribute to, allowing you to keep control of your device even though hardware is proprietary.\nFeatures The PineBuds Pro’s buds are based on the BES 2300YP.\nCPU Features:\nDual-core ARM Cortex-M4F Processor Processor up to 300MHz CPU CMOS Single-chip Fully-integrated RF, PMU, Audio CODEC and Cortex-M4F CPU Memory Features:\n4MB Serial Flash On-chip for Custom Program Internal ROM 448KB for critical constants and code Internal SRAM 992KB for critical data and code BT Features:\nBluetooth 5.2 dual-mode compliant Profiles: A2DP, AVRCP, HFP Audio Codecs: SBC, AAC Audio Features:\nSupport BES Intelligent Bluetooth Retransmission (IBRT) Support FF/Hybrid ANC Dual MICs noise reduction Echo Cancellation Support low power voice activity detection Multi-band EQ and Bass enhancement Support Active Crossover Support TWS HiFi Stereo Audio DAC: 120dB SNR, 110dB DNR HiFi Stereo Audio ADC: 100dB SNR Sample rates from 8 kHz to 384 kHz Support dual/single Mic noise suppression -45dB attenuation nominal 50-200Hz -55dB max attenuation @150Hz Support ambient awareness Support talk through 24-bit audio processing PMU Features\n3.1V-5.5V Input for VBAT Internal LPO for low power mode. DCXO with internal oscillator circuit Internal temperature sensor Buttons/touch sensors Buds One capacitive touch sensor is located on the outward facing surface of each bud near the logo.\nCharging case Charging case have a reset button in center under the lid which is hooked to ThinkPlus Semi SY8821 integrated circuit and that button reset it from the safety off mode.\nSpecifications Dimensions:\nEarbud: Unknown Charging case: 70 x 50 x 35mm (unconfirmed) Weight:\nEarbud: 5g Charging case: 65g IP Rating of Earbuds: IPX4\nDynamic transducer (speaker): 6mm\nMicrophone: 3 – FeedForward, FeedBack, Talk\nSystem on Chip (in each earbud): BES 2300YP\nCPU: Dual-core 300MHz ARM Cortex-M4F ROM: 448KB SRAM: 992KB BT shared SRAM: 64KB Flash: 4MB (Endurance erase cycles: \u0026gt;500) Communication:\nBluetooth: Bluetooth 5.2 dual-mode compliant USB: USB to dual UARTs at charging case Battery:\nEarbud: Built-in LiPo 3.7V 40mAh Charging case: Built-in LiPo 3.7V 800mAh Ports earbud:\n4 pins Ports charging case:\n4 pogo pins USB type-C port 5V 500mA Power The charging case’s input power is DC 5V @ 0.5A USB Type-C.\nSoftware Firmwares OpenPineBuds Little Buddy Firmware images Flash back factory default firmware using Windows based utility:\nPineBuds Pro Windows based programmer utility user manual PineBuds Pro Windows based programmer utility PineBuds Pro factory default firmware build PineBuds Pro factory default OTA build SDK PineBuds Pro \u0026ldquo;Little Whale\u0026rdquo; SDK date:20221128 Community projects The following community projects are currently being worked on:\nWireless charging, bringing wireless charging to the PineBuds Pro case using vacant contacts Silicone case, a transparent silicone case with an improved grip to the case Straps, to add straps to the PineBuds Pro Silicone case This page is about the community project to bring a silicone case to the PineBuds Pro.\nIntroduction The idea is to create a silicone case like this for PineBuds Pro.\nConcept \u0026ldquo;Design a mold, use a hobby 3D printer to manufacture it, then fill with silicone.\u0026rdquo; (source) \u0026ldquo;You can find a local hackspace or makerspace. Or you can use one of the many services available via the Internet who can print a model for you. Just design, upload, and pay.\u0026rdquo; (source) \u0026ldquo;The only one I know of is \u0026ldquo;https://www.pcbway.com/rapid-prototyping/injection-molding/\"\" (source) Straps This page is about the community project to add straps to the PineBuds Pro.\nStrap for buds Although PineBuds Pro, \u0026ldquo;true wireless\u0026rdquo;, earbuds are comfortably light and stay in ears better than wired ones (when nothing tug them from your ear), they can still did it, for example, during sports. Because they are completely non-wired, it also means that they will then drop directly to the ground and may break. That’s why it might make sense to use a strap like this in sports. We are trying make strap for PineBuds Pro.\nStrap with 3.5mm AUX connector Each bud has pins through which is UART connection. When we find or make a strap for PineBuds Pro we can add wiring inside it and put PCB in the middle that receives analog signal with the 3.5mm AUX connector and feeds it to the buds.\nWireless charging This page is about the community project to bring wireless charging to the PineBuds Pro.\nWireless charging The PineBuds Pro don’t have wireless charging by default, but you can add it. However, you need to know how to disassemble the charging case and solder bunch of SMT components to the PCB.\nPine originally planned to have wireless charging for the PineBuds Pro, but apparently for cost reasons they decided to cancel it. However, they left footprints on the PCB for wireless charging component. They also designed COPO CP2021 component to be used. You also need a bunch of other components, such as resistors and of course electromagnetic coil. The places intended for the components, the footprints, are made for SMT (also called SMD) components. That means you need a hot air soldering station and experience.\nRequired tools Picks/thin cards Screwdriver Hot air soldering station Tweezers Solder Flux Glue Required components COPO CP2021 WIP Steps First open the lid and then try to press the case from the front edge with a plectrum or a thin card. There are two clips on each side. Soon the case will snap open. Carefully unscrew and remove the PCB from the case. Solder the necessary components to their respective footprints, use the PineBuds Pro Charging Case Schematic/COPO CP2021 2.5W Qi Wire Power Receiver Datasheet (below). Screw the PCB back into the place. There is plenty of space, glue the coil to the bottom of the case. Close the charging case. Further information Datasheets\nSchematics and Certifications\nDisassembly and assembly\nCleaning\nDatasheets BES 2300YP SoC information:\nBES 2300-YP Datasheet V1.0 Charging case:\nThinkPlus Semi SY8821 Datasheet in Chinese WCH Tech CH342DS USB to Dual Serial ports chip Datasheet COPO CP2021 2.5W Qi Wire Power Receiver Datasheet (Unpopulated) EarBuds:\nChiPower Tech CE3156 Single Cell Charger Datasheet LowPower Semi LP3992 LDO Regulator Datasheet HLW Semi HLW-YHX190 OTP micro Datasheet in Chinese (noted: for power-on and reset control) Tontek TTP-233D one key touch pad detect IC Datasheet Schematics and Certifications Documents:\nPineBuds Pro User Manual Schematics:\nPineBuds Pro Earbuds Schematic 20220817 PineBuds Pro Charging Case Schematic 20220915 Certifications:\nPineBuds Pro CE EMC Certificate PineBuds Pro CE RED Certificate PineBuds Pro FCC Certificate PineBuds Pro ROHS Report Disassembly and assembly Disassembling the charging case:\nFirst open the lid and then try to press the case from the front edge with a plectrum or a thin card. There are two clips on each side. Soon the case will snap open. Carefully unscrew and remove the PCB from the case. Assembling the charging case:\nScrew the PCB back into the place. There is plenty of space, glue the coil to the bottom of the case. Close the charging case. External resources A video regarding the assembly and disassembly of the PineBuds Pro can be watched from Linux Lounge here. Cleaning PineBuds Pro only have IPX4 rating, so they are only splash-proof and cannot withstand immersion in water. Clean the charging case inside and out with a damp microfiber cloth. Inside, be careful near the pogo pins! The cloth easily sticks to them and may tear them. You can use a microfiber cloth at the end of a stick to immerse of the buds, but a cleaning tool made for this can help. When cleaning the buds, carefully remove the tips, place the buds on a damp microfiber cloth and one by one wipe it from all sides. Be careful with the protective mesh. If there is dirt in the mesh, you can carefully clean it with the brush of the previously mentioned tool. Wash the tips with soap and water, but be careful, they easily drip from your hand to drain. After drying them, carefully put them back to the buds.\nYou need:\nA microfiber cloth A cleaning tool ","permalink":"/documentation/PineBuds_Pro/_full/","tags":null,"title":"PineBuds Pro (Single Page)"},{"categories":[""],"contents":" The PineCam IP camera The PineCam is a successor to the PineCube IP camera, featuring a refined design and improved specifications. Based on the oz64 single-board computer, it utilizes the SG2000 SoC with dual RISC-V cores and one ARM core, and includes 512 MB of RAM to support a full Linux-based OS like MotionEyeOS.\nThe device is equipped with a 2 MP camera module (GalaxyCore GC02M2) connected via MIPI CSI, and can function as a USB-C wired camera. It features GPIO, a microphone, speaker, and a USB-C power input, with a removable flap for GPIO access.\nDocumentation PineCam ","permalink":"/devices/pinecam/","tags":null,"title":"PineCam"},{"categories":null,"contents":" The PineCam is a successor to the PineCube IP camera, featuring a refined design and improved specifications. Based on the oz64 single-board computer, it utilizes the SG2000 SoC with dual RISC-V cores and one ARM core, and includes 512 MB of RAM to support a full Linux-based OS like MotionEyeOS.\nThe device is equipped with a 2 MP camera module (GalaxyCore GC02M2) connected via MIPI CSI, and can function as a USB-C wired camera. It features GPIO, a microphone, speaker, and a USB-C power input, with a removable flap for GPIO access.\nThe PineCam without a case\nThe PineCam with a case\n","permalink":"/documentation/PineCam/_full/","tags":null,"title":"PineCam (Single Page)"},{"categories":["Soldering irons"],"contents":" RISC-V Soldering Iron Running an Open Firmware The Pinecil is a smart mini portable soldering iron with a 32-bit RISC-V SoC featuring a sleek design, auto standby and it heats up to an operating temperature in just 12 seconds when paired with a sufficiently powerful power supply unit – such as the PinePower. It runs a community built firmware that is simple to update and altered to your use-case need. We offer a wide selection of tips for the Pinecil in the Pine Store, so the soldering iron is ready to aid you in whatever projects you’re about to undertake.\nFeatures and Specifications 17cm x 12cm x 2.3cm 88 gram weight 170mm (98mm without the solder tip) x 12.8mm x 16.2mm 30g weight with solder tip (20g weight without solder tip) Black plastic build with metal clip (handle) Ralim’s IronOS operating system GigaDevice GD32VF103TB chipset 32-bit RV32IMAC RISC-V “Bumblebee Core” @ 108 MHz 0.69″ OLED white color monochrome display with 96x16p resolution 128KB Flash 32KB SRAM USB-C PD and QC 3.0 12V-20V 3A DC5525, 12V-21V DC 3A barrel jack Capable of receiving power from either USB-C port or barrel jack GPIO break-out through USB-C port Type B2 soldering tip as default USB-C Power Delivery USB-C PD for delivering optimal power\nOLED Built-in white color monochrome display\nGPIO Break-Out Optional GPIO breakout for development purposes\n32 Bit RISC-V Processor 32-bit RV32IMAC RISC-V processor running open firmware\nStores Global Affiliates Documentation Pinecil Certifications Resources YouTube: Pinecil soldering iron powered by a PinePower Desktop unit YouTube: Pinecil soldering iron review by Level1Techs ","permalink":"/devices/pinecil/","tags":null,"title":"Pinecil"},{"categories":null,"contents":" Pinecil is a portable soldering iron with computer controlled temperature, sleep modes, motion detection, and allows many options for power from AC supplies (USB-C, DC Barrel) to external tool/LiPo batteries. You may already have a power supply that works. It also has the intended use of being a RISC-V development device using a breakout board. The Pinecil has evolved over the years from a 60W device into the latest rendition, the V2, which supports 24V/88W and includes the new PINE64 designed shorter tip.\nNote: Other irons only care if they can solder. The Pinecil is held to an additional standard; how well can it meet the needs of the open source community as a RISC-V development tool. It includes hardware features not found on other soldering irons such as BLE Bluetooth in the V2 in order to support FOSS community feature requests for both fun and science.\nPinecil V2, launched Aug 2, 2022\nPinecil V2, side view\nAuthenticity There are no PINE64 Pinecils sold on AliExpress. They are not made by PINE64. There are no authorized resellers on AliExpress. Some manufacturer has copied the PINE64 company name, trademark and Pinecone logo and is selling a product made to look like Pinecil through many store fronts, but it is not an authentic. They use a different type of box, i.e., a blue or red box. They are fake copies and do not go through the same quality control as PINE64. It is unclear what type of chips or poor quality cloned chips are used in them. They are not recommended. Genuine new PINE64 Pinecil only comes in a black handle color with a green silicone thumb grip. The original V1 always came in a black box. This model was discontinued and has not been made or sold by PINE64 or authorized resellers since July 2022.\nThe current official Pinecil (a.k.a. V2 model) comes in a white box (see Pictures), it has a black color handle with a green silicone thumb grip. If you receive anything that has the PINE64 brand name and Pinecone and does not look like described, it is a fake copy that was not made or authorized by PINE64 or the Pine Store Ltd (see Authenticity Checker below, all real PINE64 Pinecils purchased after Aug. 2, 2022 should pass the checker if they are genuine).\nPinecil V2 Authenticity Checker Pinecil V2 comes with a unique internal ID/Serial number. This allows people to check if the Pinecil V2 is Authentic. To be more sure, update to the newest stable Ralim’s IronOS and check again, see Firmware.\nImportant The Authenticity Checker can be found here. Features Portability and Temperature control Soldering tips: Replaceable and low cost Many styles: currently sold as 4-packs, one fine set, the other larger. Compatible with other ts100 tips. Multiple power sources will work for more flexibility: USB-C PD (power delivery), minimum 3 Amps, 12V. DC 5525 Barrel jack charger, minimum 3 Amps, 12V. Battery: connect to 18V-21V Lithium-ion tool batteries or 3S/4S/5S LiPo batteries. Pinecil V2 has a BL706 chip, see history of changes below. Board schematics are open. Software is open. Create your own! Pinecil breakout board lets you use JTAG, GPIO, A2D, SPI, and more. Additional features (useful for devkit):\nProgrammable Risc-V BL706 embedded processor V2 model allows BLE Bluetooth control because of the switch to the Bouffalo BL706 MCU. 0.69\u0026quot; Monochrome Display that can render text or graphics Support for Idle detection, sleep mode of tip, automatic shut-down Programmable with tools from Bouffalo Labs, HomeBrew or Linux RISC-V. Usage Quick links Pinecil V1 Quick Start Guide Navigate the Pinecil menus: Guide here. Overview Prep Tasks\nTip Clean new cartridges/tips with isopropyl alcohol (IPA) to remove factory residue before installing (even if it looks clean). If you have no IPA, at least try a paper towel, especially clean the white end with the two silver electric contacts (do not use water; it could get into the seam line on the white end). This resolves issues with jumping temperatures or random no-tip symbol from poor electric contact. Do not try to bend the two internal contacts, they are made of a thin stiff spring metal and could break (not soft copper), but you could wipe them with IPA (including the small PCB pad below the contacts).\n1. Install the tip: The Pinecil comes with a separate heating element, the tip.\nRemove the screw from the front top-side of handle. Then, gently push the tip all the way back until the wide collar/guard is touching the front of the plastic (see \u0026ldquo;File:Pinecilv2-1.jpg\u0026rdquo; (photo). Gently tighten or loosen this screw to install or swap the tip. (careful, tiny screws break easy, if tip does not fall out, it’s tight enough) The bottom front screw should not touch the tip, it only holds the handle together (see Fasteners). Always unplug before swapping tips if you have multiple tips. 2. Supply power: the USB-C port, connected to any supply, is enough power to show the display screen, but not necessarily enough to heat the tip.\nUSB port at 5 volts (i.e., laptop) shows DC Low, this is enough for firmware updates and to view the menu, but not to run the soldering iron. See Power section for details on power options. QC 12V phone chargers will not work, as they are too weak. 3. Heat the tip: plug Pinecil into an appropriate power supply.\nClicking [+] starts the tip heating. The detailed display option shows power draw, current temperature, supply voltage, and time until sleep mode starts. Adjust the target temperature with further clicks of [+] and [-] buttons. Wait a few seconds for the regular display to return, then hold down [-] for a moment to turn the heat off. You can observe the temperature measurement go up and down. Certain settings involve holding down both buttons (see GitHub IronOS for details on firmware settings). 4. Using the Settings Menu:\nTo check the firmware version, hold down the [-] button. It will display something like \u0026ldquo;v2.19.A3BBABC 13-07-22\u0026rdquo;. This is the firmware number and release date, the date is July 13, 2022 in the example. Clicking [-] when heat is off steps through main categories menus to control a variety of settings, see Getting started with menus section. Clicking [-] also returns to the regular display of temperature and supply voltage (this view varies if you activate detailed idle). At other times it may show power draw. Click [-] to scroll to the the main menu section desired (i.e., User Interface). Then click [+] button to change various internal settings. Then click [-] again to go to the next item in the sub-menu. 5. Important notes:\nThe iron will \u0026ldquo;sleep\u0026rdquo;, switching to a lower temperature, after it has been put down for a short time, and heat up again when it is picked up. Calibration of the Tip temperature is usually not necessary and should only be done if the tip is off by +/- 5 °C or temperature is behaving oddly. See instructions to calibrate the tip in the firmware on GitHub IronOS. For Safety, unplug the soldering Iron when not in use or left unattended. To heat up the tip, we need a power supply that can provide at least 12V 3A to run. This is the bare minimum. Pinecil will heat slowly at only 12V/3A. To maximize performance, higher Volts/Amps/Watts is recommended (see Power supplies). Option 1: a USB-C supply that can negotiate up to such a voltage. For good performance and soldering experience, a USB-C PD65W, 20V, 3+ A charger is recommended (suitable for most users). Option 2: a supply with a DC 5525 barrel connector (+ pos center, - neg outside) that supplies anywhere from 12V-21V, 3+ amps (V1 Pinecil) or 12V-24V, 3+ amps (V2 Pinecil). Option 3: use a battery, i.e., an 18V-21V tool Battery with a Power Wheels adapter, and a cable to plug into the Pinecil DC5525 barrel jack. You may have a suitable supply already that could be used, (see Power supplies). While 12V-3A will work, it will not heat the tip as quickly and efficiently as a PD65W-20V USB-C charger or a higher rated DC barrel charger. See warnings about using random DC barrel chargers, not all of them have the correct polarity or DC 5525 style plug and some may be too high of voltage which could damage the Pinecil. Getting Started with the Menu Getting Started Guide in GitHub/IronOS Main Settings Menu: updated list is found in the firmware repository Settings Menu Power settings: settings related to power, battery cells, input voltage. Soldering settings: settings for soldering such as, boost temps, increments for temperature change Sleep mode: power \u0026amp; tip saving, such as sleep mode, sleep temperature, and shutdown modes, motion sensitivity User interface: settings such as, units C/F, display orientation, button reversal, animation speed, brightness, boot logo duration Advanced settings: assorted catchall for settings that don’t fit elsewhere or settings that require some thought before use. Restore default/factory settings is here. It will not change the firmware version, but rather resets the menu back to IronOS defaults. This is good to do after a major firmware update as settings may have been altered and need to be re-selected/customized again to work as expected. Hidden Debug Menus: also available, see GitHub/IronOS Power supplies Power Supplies\nWatts\nPower Supplies This article is about compatible power supplies for the Pinecil.\nPower Options for Pinecil Overview Using a power supply that is at the higher end of the Voltage/Amps requirements will give faster heating and performance. Any USB-C power supply that supports PD (Power Delivery) and has at least the minimum Volt/amps listed should work. The USB-C PD65W, 3.25A, 20V is recommended, but a lower PD45W will also work on V1. Also, any quality \u0026ldquo;center positive\u0026rdquo; DC barrel 12-21V battery or power supply using a DC 5525 jack (5.5mm outer diameter, 2.5mm post) see the video on center-positive polarity. It is sometimes better to get a pre-used name brand laptop brick Dell/Lenovo/HP etc., over a cheap brick which could have voltage spikes that damage the Pinecil or other electronics. V2 can handle a DC barrel supply up to 24V without modifying the PCB (always check polarity, must be a center-positive jack). Any typical tool battery 18V-21V will work, see the tool battery section for details. QC3.0 phone chargers: not recommended, it is weaker in power and does not auto-negotiate like USB-C PD does. QC3 requires manually setting the voltage in the Power settings. A minimum of 3 amps is needed and many QC phone chargers are only able to provide a low 12V 1.5amp, limiting Pinecil to about 17W of thermal capability which is weak and slow. It may not even start to heat, but if it does, it may get repeated Thermal Runaway message (this means the weak power causes Pinecil to auto-shutdown continuously). QC is more problematic for V2 which comes with the Pine64 designed shorter 6.2 ohm resistance tip. This means the V2 needs more power than the V1. Switching to the longer tys100 style tip in V2 would reduce the power requirement a little, but then you lose a small amount of heat speed/performance. Magnetic tip USB-C cables are not recommended, and are not USB compliant. Troubleshooting QC chargers older QC2.0 chargers are not supported in IronOS firmware (only QC3.0 and PD type). Some QC power adapters only allow a limited time for QC negotiation, otherwise voltage will fall back to 5V. To address this, starting from firmware v2.16+, there is a PD timeout setting (in 100ms steps) which allows QC negotiation to start earlier. Change this only if you are having issues with your QC charger (lower the PD timeout to see if that will help QC charger work). (Power Settings \u0026gt; PD timeout) This enables some QC adapters to work (i.e., some Baseus QC chargers). Alternately, lowering the number may result in problems with PD negotiation on some PD type adapters that are slower to negotiate. If you switch between QC \u0026amp; PD adapters, you may have to change this setting. For certain QC adapters, lowering the PD timeout value to 15 could help, and most PD adapters will also still work using 15. If a PD charger does not work at 15, then increase the timeout (PD default is 20 = 20x 100ms = 2 seconds). Note that some QC chargers simply will not work, are too weak, or cheaply made (PD USB-C chargers are recommended over QC only type) How to Test if my charger will work? As long as you do the following you should be fine:\nDon’t plug in something that is higher voltage than the official ratings for V1 (21v limit) or V2 (24V limit). If using a DC barrel charger, check the Polarity first, it must be center positive (see Video) Use a known good quality cable that will not short. There are low cost $3 cable testers that test for shorts. If the Pinecil heats up very slowly or gets Thermal Runaway message, then the charger is too weak, get something else. Phone chargers are too weak, most are only 12V 1.5 amps which is too low and prevent proper Pinecil operation. QC 2.0 not supported by IronOS firmware (only QC 3.0 and PD type). most PC \u0026amp; laptop ports don’t work as they are only 5V which is good enough for simple Firmware updates but not to provide the constant higher power a \u0026ldquo;resistance\u0026rdquo; type of soldering Iron needs to maintain heat. Check the specs on your laptop/PC ports and charger ports, most of the time when it doesn’t work, it’s because the rating is very low on it and not designed to power an Iron (check specified Watts, Volts, Amps on the port and see if they meet the minimum needed by Pinecil). Cables, Chargers, Batteries This is a very small list compared to all the possible chargers that work, and new chargers come on the market all the time.\nUSB-C Cables Silicone USB-C cables are recommended if possible, they are more flexible and heat resistance. They do not melt or smoke if touched briefly with an iron compared with most other cords.\nUSB-C Charger Should I get a GaN type Charger? Sure, if there are two PD65 20V chargers that are similar in price, and one is GaN, this is generally a good chioce. Older style chargers could become dangerously hot, whereas GaN can stay cooler, even in a smaller size. If the GaN charger senses a potentially dangerous condition, i.e., overcurrent spikes, the chips are designed to go into a cycle-by-cycle sleep state, protecting the device. Over current protection in GAN. The PinePower Portable PD65 is GAN II (2nd generation GaN). Will Pinecil work with regular USB-C PD 65w 20V-3.25A chargers also? Yes, as long as it supports PD (power delivery protocol). EPR PD3.1, 140W Chargers Voltme 140W, 28V max Rocoren 140W, 28V max Apple 140W 28V Anker 737 Power Bank (only EPR battery on the market presently). Note a PD3.1 240W cable needs to be purchased if you want the full 28V performance. EPR PD3.1 chargers are backwards compatible and work for all USB-C devices. They do up to 28V on PD3.1 devices,e.g, Pinecil V2, and will do 20V and less for older USB-C devices that don’t need as much power. Lower cables will also work but then the charger will only deliver a max of 20V. PD3.0 65w 20V Chargers PD120w PinePower Desktop w/Grounded 3-pin plug PD65w GAN II Pinepower Portable Travel charger (PD@20V) Cirtek 65W charger 3-port Etre Jeune 65W 3-port charger EfaithFix PD65W, 3-port TREBLEET Ultra-thin Portable PD65w small flat, full 20V PD65W charger, works well with Pinecil it may not as durable as bigger chargers as it has no thick insulation around it. HTC PD65W, 3-port black HTC PD65W, 3-port, white Amazon Basics 65W One-Port GaN USB-C PD 3.0 Battery Power bank Anker 737 28V-140W EPR (must use EPR-PD 3.1 240W cable if you want the full 28V, otherwise it will provide a lower PD20V) Blitzwolf BW-P1 10400mAh QC2 Insignia 80W 26,800mAh NS-PWLB80 Intenso 7332330 Powerbank PD 10000 - External Battery PowerDelivery \u0026amp; QuickCharge3 - 10000mAh Powerbank, the Pinecil shows 12V and about 17W when heating up, using USB C PD (Red Silicone Pinecil cable) Marbero M87 30W PD 3.0 Charmast C2032 65W Power Bank, maximum power at 20V is only available from the IN/OUT USB-C port, the OUT USB-C port delivers only 12V. Baseus BiPow 10000mAh 18W PD\u0026amp;QC3.0 INIU Power Bank 65 W 25000 mAh - Make sure to use the 65W port DC Barrel Power Important Check the polarity of the DC Barrel plug before plugging in a random charger or it could break the Pinecil. DC Laptop Brick Generally a center-positive laptop charger with more than 3 Amps and 19V-24V will work on Pinecil V2 (video to check polarity). Plugging in a DC barrel charger with the wrong polarity symbol on the back will break the Pinecil. Avoid Universal power supplies and cheap off-brand ones with low quality control. \u0026lt;tl_lim\u0026gt; said \u0026ldquo;try to avoid such universal power. The output contains sharp voltage spike and can kill the Pinecil. There are already several cases reported by support team that Pinecils are damaged by such power supply.\u0026rdquo; Read the 2 answers in this link that give an idea of why using cheap DC power supplies could damage electronics due to switching noise/voltage spikes. Cheap DC bricks don’t have all the extra protections needed, go through little quality control, and most have no certification stamps related to industry testing. DC5525 barrel plug will plug in directly (5.5mmm x 2.5mm) but if you have a different plug, there are many adapters to convert it to 5.5mm, 2.5mm (don’t force a different plug into Pinecil, it will Break the barrel port), and possibly push back and break the positive pin connection inside Pinecil where the DC barrel attaches to the PCB. DC barrel 24V is supported on V2 (most V1 can only do a max of 21V unless a modification is performed to cut the trace to the Vbus and enable 24V safely (see Ralim’s IronOS DebugMenu for details)) It is recommended to use a quality brand DC barrel charger. Often a used name-brand laptop charger (Dell, HP, Toshiba, etc..) that gets some QC testing is a better option than a no-name cheap DC barrel charger. The cheap ones might have large voltage spikes that are out of the 21V range for Pinecil V1 and 24V range of Pinecil V2 causing the Mosfet and Buck regulator to break. These two parts are low cost and not too hard to replace if your Pinecil breaks from a poor quality DC charger (see the datasheets section for links to get replacement chips). Members have experienced broken Pinecils after using low quality off-brand DC barrel chargers and had to replace both the Mosfet and Buck Converter. Sometimes it’s just one part, but it’s best to order a couple of both as they are usually under $0.35 each. Tool Batteries 18V-21V Power-Wheels adapter link with Ryobi battery\nEasy way: just get a Power Wheels adapter. They are made for different tool brands and get a DC5525 Pigtail wire. DC5525 pigtail (keep the XT60 connector or cut it off) Some people print their own 3D adapters for tool batteries. Must use a 5.5mm x 2.5 mm DC barrel Plug. Forcing an an incorrect size, i.e., DC 5521 will break the connector as seen here (if it doesn’t go in, it doesn’t fit). If you use a random DC barrel charger, first Check the Polarity of the plug to make sure it is Center Positive before using it. (how to check polarity). Using reverse polarity DC plug will destroy the Pinecil. Get a Power Wheels Adapter like this for Ryobi, then splice/connect it to a DC5525 Pigtail to complete connection to Pinecil. Other kinds of Power-Wheels Adapters here (Ridgid, Milwaukee, Makita, etc). Adapter for Ridgid batteries To prevent battery overdrain, add this Pinecil setting which works for all the 18-21V tool batteries typical for Dewalt, etc.. Some tool brands have the overdrain protection already; it doesn’t hurt to also set this in Pinecil or in case you don’t know if your brand/type has it or not. Power source = 5S, Minimum Voltage = 3.3V Hint: only if you change to a different size battery do you need to alter this. If you only ever switch between a USB-C charger and the tool battery, you could just leave the 5S/3.3V setting. Overdrain means using the battery past the point where you can charge it again. Many tool batteries have internal protection to prevents this, but some brands don’t have it (unfortunately, unlike most brands, Dewalt puts it into the tool \u0026amp; not the battery). Setting it in Pinecil is an extra safety setting in case you are not sure and want to preserve batteries. Limited usability:\nNintendo Switch AC Adapter (USB-C wall-wart) (PD@15V). Does not work well on V2 (needs 3+amps). Works on V1, but slower heat speed because it’s low amps and only 15V. Notebook Docking Station HP Thunderbolt Dock 230W G2 (PD@20V) (had problems with lower firmware versions, but works fine Pinecil firmware: 2.15 and DockingStation firmware: 1.0.69.1) Smartphone Charger Samsung EP-TA20EWE (QC2@9V) Smartphone Charger Google Pixel G1000-US (PD@9V) Notebook AC Adapter Delta Electronics ADP-65JH BB (DC@19V) and ADP-90CD DB (1.7x 4.8mm need adapter, tip is not DC5525) Notebook AC Adapter LITEON PA-1700-02 (DC@18.5V, 65W) (tip is 1.7mmx5.5mm would need adapter for DC5525) Nillkin 63W USB Car Charger Quick Charge 3.0 PD (Pinecil Firmware: 2.14.2425902) QC3@9V/12V and PD@15V work, PD@20V doesn’t PD@20V works fine when using PDC004-20V or ZY12PDN on dc jack (DC@20V, limit: 45W) Not compatible Zendure Power bank like this one does not work. It does not appear to be USB-C PD 3.0 compliant. Only the USB-A port seems to work at lower QC voltage. It does not deliver USB-C 20V-5amps or USB-C 20V -3amps. Smartphone Charger RAVpower 30W Dual USB Turbo Wall Charger (Should provide QC3@9V/12V, but only provides 5 V on both ports) Sabrent HB-B7C3 USB3 hub, 7 data ports, 3 charge ports, 60W supply \u0026ndash; does not negotiate higher voltages. Watts Generally, a higher power charger is better; a 20V power supply will give better performance than a 15V charger. The Pinecil needs a minimum of 3 amps and will work with higher amps charger. However, do not exceed the volts rating for V1 and V2 models or damage to components could occur (see the side of the Pinecil handle for the maximum volts).\nPower Chart Type Volts / Tip Ω = Amps * Volts = Watts USB-C PD3.0 20V / 8.0 Ω = 2.5A * 20V = 50W USB-C PD3.0 20V / 6.2 Ω = 3.2A * 20V = 64W DC Barrel 24V / 8.0 Ω = 3.0A * 24V = 72W DC Barrel 24V / 6.2 Ω = 3.8A * 24V = 92W **EPR PD3.1 28V / 8.0 Ω = 3.5A * 28V = 98W* **EPR PD3.1 28V / 6.2 Ω = 4.5A * 28V = 126W* Power Notes PINE64 officially states the Pinecil V2 will support up to 24V-88W. Tentatively, the V2 also unofficially supports 28V-140W EPR/PD3.1 USB-C chargers with certified EPR 240W USB-C cables. DC barrel power is 24V-5A maximum on V2. This allows headroom for higher spikes that happen in DC bricks or off-brand bench supplies. It is not a smart charger like a USB-C charger which uses chips to negotiate with devices like the Pinecil. Ralim’s IronOS firmware works with the PD3.1 protocol (EPR 28V-140W chargers) on Pinecil V2. EPR USB-C is new to the market in 2022. The first wave of these smart chargers are 28V/140W, are more expensive, and require a PD 3.1/240W cable to fully allow the 28V power to V2. EPR is backwards compatible for all USB-C devices. EPR chargers/cables can be used for everything else USB-C as well. Pinecil is not a USB-C tester: when the detailed screen is enabled on Pinecil, note it shows estimates and are at best +-10%. The watts shown on detailed mode are a big picture number for convenience and debugging various chargers used. It is not going to be as accurate as an external tester. Use external metering for comparisons or testing (external testers also cause a small reduction in Watts). QC Chargers Many Quick Charge or QC3 phone chargers are not recommended as Pinecil V2 is rated for a minimum of 3 Amps or more to work properly (see Pine Store Official rating on power ports). Most QC 12V phone chargers are only 1.5 Amps, this will lead to Thermal Runaway or Undervoltage messages because of weak power (older QC2 type is not supported in the IronOS firmware at all).\nFirmware This document provides a step-by-step guide on how to update the firmware of the Pinecil soldering iron, applicable to both V1 and V2 models. Keeping your firmware up to date ensures that you have the latest features, improvements, and bug fixes.\nOverview Tip Pinecil is designed to use only 1 power port at any time. Only the USB-C cable should be plugged in during firmware updates. Never attempt to use both rear ports at the same time or the PC and Pinecil will be damaged. The firmware that comes with the Pinecil is open source Ralim’s IronOS. It’s a good idea to check for updates regularly as development is very active and there may be enhancements or bug fixes.\nDepending on whether you have a Pinecil V1 or V2, they are updated using different flashers since they have completely different MCU chip (brains). The V1 is any Pinecil sold up to July 2022 (has a blue thumb grip). The V2 is any Pinecil sold after Aug 1, 2022 (has a green thumb grip). If you don’t have the two models mentioned, then you might not have an authentic Pinecil. This aritcle is designed and tested on authentic Pinecils only.\nGo to the appropriate section below depending on if you have a V1 or V2 model. Long hold down [-] to see the current firmware version installed. It is very hard to brick a Pinecil doing a firmware update because of the firmware is in ROM. Usually, just re-flashing it fixes it. Even if the other firmware caused the screen to go black, one could connect, put the Pinecil into flash mode, and flash again to an older or newer version of firmware or a beta version. Pinecil V1 only uses *.hex files for both firmware and boot logo art. Pinecil V2 uses only *.bin files for firmware. Note Loading boot logo art onto the V2 (BL706 MCU chip) is not yet possible. Volunteers are looking into this on both GitHub Blisp and GitHub IronOS. If you would like to see the progress or help with the code see Boot Logo Art ticket Flash Mode Important Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Both V1 and V2 connect to the PC/laptop and enter the Flash mode the same way for updating purposes:\nPlug one end of the USB cable to the PC/laptop. Long hold the [-] button before plugging the USB-C cable into the back of the Pinecil. Keep holding down the [-] for ~10-15 seconds after plugging in the cable, then release the button. Screen should be black/empty which means Pinecil is in Flashing Mode. If you have issues, try again, do not plug the USB-C cable into Pinecil until you first press \u0026amp; hold the [-] button. Flip the cable over or try another port/cable/PC if you still have issues. Unlike irons from other brands, Pinecil will not show in the PC as a USB data drive. On Windows, you will hear a single beep when connected in flash mode. Then use one of the flasher methods below based on the OS you have in order to flash new firmware (older V1 instructions are lower down here). Update V2: Windows Important Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Option 1: PineFlash The PineFlash is a GUI updater it’s an all-in one app that downloads firmware and flashes.\nDownload the easy premade binary installer for Windows here. If PineFlash doesn’t work try the Blisp terminal app. Option 2: Blisp Blisp is a CLI (command line interface or terminal) and needs a program like the Powershell, which is already installed on most Windows PCs. For using Blisp only a couple basic terminal commands are needed, such as cd to change directories (folders). If you prefer to use \u0026ldquo;command\u0026rdquo; terminal over Powershell, see instructions for Command in Troubleshooting and then skip to #8 here Can install newest Powershell from here. Rick click and run Powershell as administrator. Enter this command C:\\\u0026gt; Set-ExecutionPolicy RemoteSigned to enable powershell permissions. It only needs to be done one time and should persist on reboots. Check that Powershell has correct permissions,enter Get-ExecutionPolicy -list LocalMachine should be RemoteSigned. For V2, download the Blisp Flasher here. Next download the newest firmware, release here. Scroll down to the bottom of the page, under Assets, get the Pinecilv2.zip. Right click on all zip files \u0026gt; properties, and check \u0026ldquo;Unblock\u0026rdquo; if present to unblock them, then extract the Blisp zip and the Pinecilv2 zip screenshot of Unblock here. If you don’t see \u0026ldquo;Unblock\u0026rdquo; then keep going. From the Pinecilv2 folder you extracted above, copy the Pinecilv2_EN.bin (English) file into the Blisp folder (same place as the Blisp.exe). Other languages are available, substitute the Pinecil_EN.bin file for the language file desired (follow 2-letter international language code). The Pinecil Zip can now be deleted, only the single BIN file in the language you want is used. Run powershell as administrator. Now, connect the Pinecil V2 to the PC: hold down the [-] Before plugging the cable to the back of Pinecil. See (Flash Mode section for details). Screen on Pinecil should be black/empty before proceeding; it means you are in the correct Flash mode. If you are curious, it will connect as a PORT COM device in Device Manager. If your screen is not black, then repeat the connect to PC above. If necessary, change cables or ports, or try a different PC/laptop. Use cd to change to the Blisp folder (location of blisp.exe and Pinecil_EN.bin). #example change to location of blisp folder PS C:\\\u0026gt; cd G:\\Users\\name\\Downloads\\blisp\\ Execute this line (can replace the EN file name with the language bin selected). Type the .\\ (dot and slash) or it will fail to find the files! .\\blisp.exe write -c bl70x --reset .\\Pinecilv2_EN.bin After update, unplug and reboot it, then hold down [-] for ~3 seconds to see the new version. See troubleshooting down below if it does not flash. Bluetooth (BLE) Apps Must have newer Pinecil V2 model (green thumb grip). First, update firmware to Ralim’s IronOS 2.21 or higher. 2.21 is the first stable release that has BLE support built-in for Pinecil V2. Get the PineSAM app here or try Joric’s BLE website here. These BLE apps are also listed in Development projects Joric’s BLE API may be the easiest to get started with as it does not require anything to be installed. It runs off Chromium based browsers (since they are capable of BLE GATT) and shows a graph of Temperature/Watts (MacOS/iPhone and firefox don’t work bc they do not have BLE GATT). Hint: some Chromium browsers like Vivaldi, may need to check chrome://flags/ and enable bluetooth options. PineSAM is BLE Settings and Menus and will run on any major OS. It allows change of all settings, and can be controlled from Mac, Linux, Windows, iPhone, Android and more; needs python script running as back end. For easy phone connection just open a browser address http://\u0026lt;ipaddress of PC running script\u0026gt;:8080/ (see PineSAM website for details) Update V2: Linux and Mac Important Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Option 1: PineFlash PineFlash is a GUI updater that downloads firmware and flashes. Download the easy premade binary for Linux here.\nFor MacOS, currently there is a 2-step script that will build PineFlash. If you have issues with Pineflash, then use Blisp below. Option 2: Blisp Flasher This is a CLI that runs in a terminal console. Get the latest zip file for Linux or Mac. The main page has background info and there are instructions if you want to build it from code instead of using the easier premade executable.\nExtract the Blisp zip, and using a terminal, cd to the blisp folder.\nDownload the latest stable Pinecilv2.zip release (scroll down to the Assets section, get the Pinecilv2.zip).\nExtract the zip file and put Pinecilv2_EN.bin (for English) into the Blisp folder (same place as the Blisp executable). Other languages are available, substitute the *EN.bin file for the language file desired (use the 2-digit international language code). If you have the Pinecil Zip, the rest could be deleted, only the single BIN file is needed. Select the appropriate two-letter code for your language. If you accidentally flash *.dfu file on your Pinecil, it will not boot or work - be sure to only use the BIN file.\nConnect the V2 to the PC and enter Flash mode: hold down the [-] before plugging the cable to the back of Pinecil. See (Flash Mode section for details). If you are curious on Linux, it will connect as a serial ttyACM USB ACM type device.\nScreen on Pinecil should be black/empty before proceeding or you are not in Flash mode.\nBlisp must have executable permission set.\ncd to the Blisp folder and ls -l to check permissions of blisp.\nMake blisp executable: chmod +x ./blisp\nThen execute:\nsudo ./blisp write -c bl70x --reset Pinecilv2_EN.bin After a successful update, unplug and reboot it, then hold down [-] for ~2 seconds to see the new version.\nSee troubleshooting down below if it does not flash.\nTo use V2 with BLE Apps, see here.\nTroubleshoot V2 Flashing Double check that the command is typed exactly, e.g., in Windows, the dot\\slash .\\ can not be skipped in Powershell.\nFor Windows, instead of PowerShell, try the cmd.exe (right click, run as administrator) and move into the blisp folder; example commands to move to folders.\nTwo different samples work when the cmd.exe is run as administrator. First move into the folder you have both blisp.exe and Pinecil_EN.bin. Then execute one of the following:\nC:\\Users\\yourName\\Downloads\\blisp1\u0026gt;blisp.exe write -c bl70x --reset Pinecilv2_EN.bin C:\\Users\\yourName\\Downloads\\blisp1\u0026gt; .\\blisp.exe write -c bl70x --reset .\\Pinecilv2_EN.bin Often, updating issues are related to the USB cable, or the port on the PC does not support a connection to Pinecil, try:\nflipping the cable over, different cables. Try both use-C to C cables and also USB-C to USB-A cables (your cable may be power-only and not able to do firmware data transfers). All working USB-C to USB-C cables can do data transfer but some USB-A cables can only do power and will not work for firmware updates because they can not do data transfers. Try other ports on the PC/laptop, or a different machine. There have been issues with some laptop USB-C ports not negotiating correctly, but the flashing worked using the USB-A port. Try a different OS if you can access one, some people who had issues on Linux for example were able to flash on Windows. Note that some virtual environments might have an issue with flashing to USB ports. Don’t use a hub, connect directly to a port, ports on the back of a PC may sometimes be better as they are directly connected to the motherboard. Follow the Flash mode instructions and make sure the [-] button is held down BEFORE plugging in the cable to the back of the Pinecil. And don’t release for ~10 seconds.\nIf that doesn’t work try holding down the [-] the whole time (don’t let go of the button).\nBlisp flashers are from Gamiee’s open source Blisp code here. It is only an updater for the BL706 MCU on the Pinecil V2. It is separate from the firmware files needed which are in located in GitHub Ralim’s IronOS. The firmware contains all the menus, functions, and languages, and the flasher is the tool to push the firmware onto the MCU chip (the brain). Different MCU’s need different flasher tools.\nIf you have issues completing the update, try joining the live Pinecil community chat to get tips from volunteers.\nIf there was any special work-around you had to do to get the Blisp Flasher to work, or could not get it to work at all, post an Issue in Github Blisp.\nIf you are running Windows in a virtual machine and the process fails, make sure you have Microsoft Visual C++ 2015-2022 installed.\nAll firmware releases and betas are located in the GitHub Ralim’s IronOS here. If you would like to add enhancements/features to the IronOS (firmware that runs the Pinecil) or have an issue, please look at the GitHub documents or submit an issue ticket. It is recommended to read through all the GitHub IronOS documents first as they may have the answers. Screen menus and troubleshooting is documented as well on IronOS and maintained by volunteers.\nBuild the Blisp Flasher from Code If there is a problem with the Blisp flasher, or you have a different Linux architecture like ARM, the Blisp can be built from code. See directions at GitHub Blisp Wiki page. Blisp will only work on Pinecil V2 or devices with Bouffalo BL70x MCU chips and does not work for older Pinecil V1 that was sold before Aug. 1, 2022. Update V1 right\nPinecil V1 uses a *.dfu file type for firmware. The newer Pinecil V2 only uses *.bin firmware type files. Pinecil V1 models were sold until July 2022 and then discontinued. Boot logo art: the same flashers used to install IronOS firmware can be used to install the art. Boot logo art will not overwrite the firmware, it resides in a separate space on the chip. Important Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. V1 Windows or Mac Follow these instructions on GitHub and download the easy GUI updater app Pine64 Updater. Install the app, and follow the screen prompts which requires connecting the Pinecil to the PC. Connect the Pinecil to the PC by holding down the [-] before plugging the cable into the back of Pinecil. Keep holding down the [-] button for about ~10 seconds even after plugging in the cable. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. Repeat the steps if needed. If that does not work, flip the cable, try a new cable, or port or different PC, then see the Troubleshooting section. The app will automatically fetch the latest stable Ralim’s IronOS firmware, pick the language desired from the drop down list. The app also allows browsing to a local folder to install a specific beta firmware file or a boot logo that you may have downloaded or created. If multiple firmware flashing is done, the app must be closed and reopened. V1 Linux or Mac Option 1 for Linux, the simple command line DFU-Util can be used per IronOS instructions. Make sure to update to the newest DFU-Util to prevent issues that some members reported with older versions of DFU-util. Option 2 works for both Linux or Mac. Download the alternative Pineflash GUI App for Linux and Mac. Connect the Pinecil to the PC by holding down the [-] before plugging the cable into the back of Pinecil. Keep holding down the [-] button for about ~10 seconds even after plugging in the cable. Screen on Pinecil should be black/empty before proceeding or you are not in Flash mode. If that does not work, flip the cable, try a new cable, or port or different PC, then see the Troubleshooting section. PineFlash app will automatically fetch the latest stable Ralim’s IronOS firmware, pick the language desired from the drop down list. Pineflash app also allows browsing to a local folder to install a specific beta firmware file or a boot logo that you may have downloaded or created. General Firmware Details Do not use the DC barrel jack while updating firmware or you may destroy your PC and Pinecil. Pinecil is designed to only use one power port at a time and never both at the same time. Get the beta and release firmware from GitHub with update instructions To submit a feature request, or help Ralim enhance the code, create a ticket or start a discussion at Ralim’s IronOS Ben (ralimtek) supports IronOS out of love for the IronOS creative open community. He volunteers countless hours coding, debugging, and enhancing IronOS with all the feature requests submitted. To give some love back, donate to IronOS; buy Ralim a coffee/kofi or donate here. One advantage of Pinecil (V1/V2) over other irons (i.e., Miniware) is you can not really brick them since Pinecil’s bootloader is in ROM. If there is a problem, just flash the firmware again or a different version. This empowers people to experiment and do forks of the main IronOS firmware without as much risk. Problems with IronOS firmware? - read documents here. If the answer is not found, open a ticket here or join the live Pinecil community chat. Boot Logo Art Dog bone by River M.\nGet Art Boot logo art is art that you custom make or download from IronOS Meta. It displays when you initially power on the Pinecil (boot up). Currently only older Pinecil V1 models which use DFU files can flash boot logo art. Download and extract all the premade Boot logo art from this pinecil.zip file here. Note that for Pinecil V1, only the images with filename \u0026ldquo;dfu\u0026rdquo; will work, you can delete all other formats from the extracted zip. Sample images of premade free art. To make custom art, follow instructions here. Some art is animated: the very small file size limit for boot logos prevents too many frames from being possible. Install If you have Windows or Mac, you can use this GUI Pine64 flasher. If you have Linux or Mac, use this GUI Pineflash. Info For Pinecil V2 model, Ralim has started work on this (reference). Please watch this ticket, give Ralim support and encouragement. This is all volunteer work. Further information Certifications\nHistory of hardware changes\nPictures\nPinecil in the Media\nSchematics and datasheets\nSpecifications\nCertifications Pinecil V2 Certifications:\nPinecil V2 CE Certificate Pinecil V2 FCC Certificate Pinecil V2 ROHS Report Pinecil V1 Certifications:\nPinecil CE RED Certificate Pinecil FCC Certificate Pinecil ROHS Certificate History of hardware changes Pinecil V2\nOn Aug. 2, 2022, Pinecil V2 was released with improved hardware \u0026amp; accessories. It retains the same ergonomics and design as the original Pinecil, and will work with any accessories you already have including existing handles, cases, and tips. It comes with a green color silicone grip versus the light blue finger grip from Pinecil V1. It also includes one of PINE64’s newly designed shorter 6.2 ohm tips. By reducing the tip length and resistance from 8 to 6.2 ohms, it allows greater performance and and faster heating (short tips are potentially 64W @ 20V compared to 8ohm normal tips which allow a max of 50W to Pinecil). Pinecil V2 is officially rated for 12V-24V. Key changes in V2: new processor (BL706), higher maximum input voltage (24V versus V1’s 21V rating), support for measuring tip resistance, allows automatic detection of 6.2 vs 8 ohm tips. A notable improvement is the new BL706 RISC-V processor from Bouffalo. It is similar to the BL602 in the Pinenut. The BL706 features Bluetooth Low Energy (BLE / Zigbee); future IronOS firmware releases will expose features over BLE. This is not trivial work, but as people contribute to the opensource code of GitHub/IronOS, BLE options will expand. There is also tentative support for USB-PD3.1 EPR (28V, 140W chargers), Ralim’s IronOS supports V2 running with USB-C EPR-28V. EPR/PD3.1 is not officially acknowledged yet by the Pine Store. Many brands of EPR USB-C chargers are confirmed by members to work on Pinecil V2 at 28V and this results in faster heating performance over PD 20V chargers see short test here. Things staying the same in V2: it still uses a RISC-V processor, but adds noticeable upgrades to the hardware. GPIO is broken out on USB-C for creating your own projects, same pinout as Pinecil V1, same great feel, including the rubber grip, works with all existing tips, same DC input + USB-C input connections, and compatibility with existing clear or black handles. In the V2 handle’s side label, the 88W figure comes from a 6.5ohm tip calculation. The reason for using 6.5 instead of 6.2 for the new short tips calculation is due to tolerance during manufacturing, and leaving a conservative margin of error (actual tips appear to be 6.2 ohms). V2 set max voltage is listed as 24V because this was the value used during design and component selection. Pinecil V1\nFor the first manufacture batch (October 2020, order number 158xxx) of the Pinecil, the copper ring connecting the earth screw to the tip was omitted as the engineering team found the TS100 design lacking. For the second round onward, an improved design copper ring has been included as standard, and is also included with the replacement clear and black handles. For normal operation of the iron, omission of the ring does not impact it’s operation. If you are working with ESD components, you will need it in order to ground the iron tip via the earth screw at the back of the iron. Programmable with tools from Gigadevice The first batch of Pinecils were rated 12-24v @ 65W. After some heated discussion on the discussion group, it was decided that it would be downgraded to 12-21V @ 60W, due to concern over the connection of the DC jack to the USB-PD chip, which has a recommended maximum of 21v, and absolute maximum of 28v. Pictures Pre-release:\nPinecil_renders\nPinecil prototype\nProduction:\nPinecil V2, side view\nPinecil_V2_disassembled,_newly_designed_shorter_6.2_ohm_tip\nTransparent_handle\nReplacement internal contacts\nCartridge/Tips:\nShort tips, fine set\nShort tips, gross set\nNormal tips, fine set\nNormal tips, gross set\nPCB:\nPinecil_PCB_screen_side,_V2_on_top,_V1_on_bottom\nPinecil PCB bottom side, V2 on top, V1 on bottom\nAccessories:\nThumb screws on V1 \u0026amp; V2\nPinecil in the Media Humor Most interesting man Science Pinecil Videos V2 review, Aditya Mukherjee V2 review, Platima Tinkers V1 review, Adrian’s Basement V1 review, Adam Welch Custom made wood box Aluminum carry box Pinecil V2 Articles Smart Soldering Iron, Got Bluetooth? How Pinecil Integrates newest USB-C protocols Tomshardware Review CNX Software Review Pinecil V1 Reviews Hackspace Review Hackaday Review Pinecils in the Field Pinecils in the field Schematics and datasheets Schematics and Board Data Pinecil V2 mainboard schematic Pinecil mainboard schematic ver 2.0 20220608, this is production version schematic Pinecil mainboard ver 2.0 PCB Component Placement PDF file Pinecil V1 mainboard schematic V1 was only sold until July 2022, and then discontinued for newer V2 model\nPinecil mainboard schematic ver 1.0 20201120, this is production version schematic Pinecil mainboard ver 1.0 PCB Component Placement Top PDF file Pinecil mainboard ver 1.0 PCB Component Placement Bottom PDF file Pinecil mainboard ver 1.0 PCB Component Placement Top Drawing file Pinecil mainboard ver 1.0 PCB Component Placement Bottom Drawing file Datasheets for Components Pinecil V2 datasheets Power MOSFET Switch: HSM4313, location U13 (Replacement HSM4313). LDO Regulator: LP 3986-33, Ultra-low noise, location U5 (Replacement LP 3986-33). Buck Converter: TP6841S6 40V, Step-Down, location U8, (Replacement TP6841S6-A). USB-C PD Controller: FUSB302MPX, location U1, (Replacement FUSB302MPX) Acceleration/Gyroscope: SC7A20 sensor, Silan, location U9 (replacement unknown). NTC Temperature Sensor: NTCG163JF103FTDS, location NTC1 (Replacement NTC here). Note that U10 is empty if NTC type thermistor is used. Optional Hall Effect Sensor: Si7210-B-00-IV(R) by Silicon Labs, location U14. This is a user add-on and does not come installed on the pcb. (How magnets work near Hall Sensor Si7210) (Replacement Si7210-B-00-IV, also at Digikey and Mouser) Operational Amplifier SGM8557-1AXN5G, SGMicro, Low Noise OP Amp Datasheet, location U11 (replacement unknown). Display Screen OLED QUG-9616TSWCG02 datasheet (Replacement QUG-9616TSWCG02 OLED Display). MCU: Bouffalo Labs, BL-706_QFN48, RISC-V + 2.4 GHz RF SoC\nBL706 Analysis, by Lupyuen, includes datasheet, location U15. BL706 datasheet BL706 Reference Manual SDK and Bouffalo documents SMD Resonator for Bluetooth BLE, 32MHZ/12PF-10PPM, SMD2016-4P, location UX1 (Replacement SMD Resonator). USB-C port:\npossible part, has not been verified: Replacement USB-C port Pinecil V1 datasheets Buck converter: RT7272B 3A Datasheet, Ricktek, Step-Down converter, location U8 LDO Regulator: LP 3986-33, location U5, (Replacement here). MOSFET Switch: CJQ7328 8A datasheet, Chang Jiang. Hint: people have replaced V1 mosfet using the better rated one from the newer V2 datasheets (HSM4313 has same footprint and higher rating), see V2 section for MOSFET. Acceleration Bosch BMA223 Sensor Datasheet Temperature Sensor: Analog Device TMP36 Datasheet, location U10, (possible replacement here). Optional Hall Effect Sensor: Si7210-B-00-IV(R) by Silicon Labs, location U14. This is a user add-on and does not come installed on the pcb. (How magnets work near Hall Sensor Si7210) (One place to buy it, also at Digikey and Mouser) OLED Display screen: QUG 9616TSWCG02 Display Module Datasheet USB Type-C PD Controller: FUSB302 USB PD Datasheet OP Amp information: SGMicro SGM8557-1 Low Noise OP Amp Datasheet (U11) Capacitors: possible replacement part for C5, 1uF/50V USB-C port: possible part, has not been verified: Replacement GigaDevice RISC-V SoC data:\nGigaDevice RISC-V GD32VF103TB SoC Datasheet V1.1 GigaDevice RISC-V GD32VF103TB SoC Usermanual V1.2 Breakout Board Datasheet: LP6498B6F 1.2A Switching Power Regulator\nSpecifications Pinecil V2 Package: 15cm x 9cm x 2.2cm, white box (released Aug 2, 2022) Dimensions: 155mm with solder tip or 103mm without solder tip x 12.8mm x 16.2mm Weight: 28g with solder tip, 18g without solder tip Soldering Tip: includes type ST-B2 (short tip), Length 86mm, weight 8.2g Platform: Ralim’s IronOS build Display: OLED White Color Monochrome Display 0.69\u0026quot; 96x16 pixels Chipset: Bouffalo BL-706 CPU: 32-bit RV32IMAFC RISC-V \u0026ldquo;SiFive E24 Core\u0026rdquo; @ 144 MHz Memory: 192KB Internal ROM 132KB SRAM System Power Ports (12V-24V, 88 Watts): Only use one power port at a time (USB or DC barrel) USB type C: PD 12V-20V 3A and QC 3.0 12V-20V 3A (magnetic tip USB-C cables are not recommended, and not USB compliant) Barrel Jack: DC5525, 12V-24V, minimum 3amps. Trying to use an incorrect barrel jack, i.e., DC5521 will BREAK the connector (if it doesn’t go in easy, it doesn’t fit). Recommend operating voltage 12-24V, but a 12V USB-C charger will not perform as well or heat as fast as a USB-C PD65W/20V/3amp charger. Tentative support: EPR 140W/28V PD3.1 chargers + EPR cables are theoretically supported in hardware and IronOS firmware. EPR is new technology in 2022. Theoretically Pinecil could get a max of 28V and 126W using EPR chargers \u0026amp; EPR cables (natural loss of 140W to 126W due to Tip ohms). Bleeding edge users are using/testing this. EPR is potentially the fastest/highest performance possible for V2; officially Pine Store states 12V-24V, 88W. Pinecil V1 Package: 16.8cm x 11.8cm x 2.3cm, black box with clear plastic front (sold before Aug 2, 2022) Dimensions: 170mm with solder tip or 98mm without solder tip x 12.8mm x 16.2mm Weight: 30g with solder tip, 20g without solder tip Display: 0.67\u0026quot; QUG 9616TSWCG02 96x16 Monochrome Matrix display CPU: GD32VF103TB 32-bit RV32IMAC RISC-V \u0026ldquo;Bumblebee Core\u0026rdquo; @ 108 MHz Memory: 128KB Flash 32KB SRAM Power supply (12V -21V, 65W): Only use one power port at a time (USB or DC barrel) DC 12V-21V 5525 Barrel Jack. Do not try to use a larger 5521 (which requires excessive force). It will BREAK the connector. USB-C 12-20V PD or QC3.0 (magnetic tip USB-C cables are not recommended, and not USB compliant) Recommend operating voltage 12-21V, some components can tolerate higher voltages at \u0026ldquo;absolute maximum\u0026rdquo; but it’s very ill-advised Fasteners/Screws Originals screws are Phillips (source): two M2x3mm at the front, and one M2x4mm is the ground screw near the [-] minus button. The bottom-front screw only holds the handle together and does not touch the tip, hence is a shorter m2x 3mm. Thumb screws are popular upgrades: an M2 x 4mm thumb screw could replace both the front screen-side Tip holder screw and the ground screw in the rear of the handle. It was found that an M2x3mm thumb screw for the tip is a hair too short, and just grazes the Tip and the longer m2 x 4mm is better on top. Note If the screw is too long (for example with a length of 5mm) a metal file can be used lightly to shorten it a small amount. Stainless steel is recommended as the softer aluminum screws could mushroom as you tighten down the tip screw too much or over time. Breakout board The Pinecil Break out board has these features:\nConnect to JTAG port or ADC/DAC, I2C, UART, SPI Independent power regulator circuit Allows pass through power from USB-C charger to Pinecil. Get the Breakout Board here. Pinecil breakout board schematic ver 1.0 20201005 Pinecil breakout board PCB layout ver 1.0 Photos:\nTop_view\nBottom_view\nUART Debugging\nChecklist Prep tasks:\nClean new cartridges/tips with 99% isopropyl alcohol (IPA) to remove factory residue before installing (avoid strange behavior from poor electric contact). If you have none, try to at least wipe down the new cartridge with a clean towel especially the 2 contacts at the rear white end (do not use water, as it could get into the small white seam line). Do not bend the two tiny internal contacts, they are thin spring metal and may break. Only use one port, USB-C or the DC barrel, but Never both at the same time. Damage will occur to PC/Laptop/Pinecil! If using a DC barrel brick for power, do not use more than 24V for Pinecil V2 and not more than 21V for Pinecil V1 (a special end-user modification is possible for V1 which allows it to use up to 24V safely). Upon receipt, or buying a used Pinecil, one may want to check the following:\nThe display turns on when 5-21V is supplied (V2 models can do 24V). Use a USB type C cable or a DC 5525 center positive barrel (how to check polarity) Use the video linked to make sure the DC barrel charger is Center Positive before plugging it into Pinecil. Several users have accidentally plugged incorrect center-negative chargers into Pinecil which immediately breaks it because it is the wrong type of charger (this is sometimes repairable, see live community chat). Note that 5v shows DC low and is not high enough to run Pinecil. 5V is only enough for firmware update and to see the menu. It gets full power. 20V from a 20V capable USB-C PD charger or power from DC barrel charger that is the appropriate specifications. The screen displays the voltage from the charger. Check both orientations of the USB-C cable (try to flip it if one way doesn’t work). Check for new firmware updates, see the firmware section. Note: do not connect the DC barrel at the same time as a USB-C cable. Pinecil was designed to only have one cable plugged in at a time. You could damage/break the PC and Pinecil doing this. V1 and V2 used different flasher apps to load firmware onto the Pinecil, see the Firmware section. Updating firmware requires a data capable USB cable connected to a PC/laptop. Check that both buttons work [-] to enter menu or decrease temperature, long press [-] to get the software version info or to turn off heating [+] to turn on heating or select a menu item The displayed text rotates according to gravity when orientation is set to Automatic User interface -\u0026gt; Display orientation -\u0026gt; Automatic More menu options listed on IronOS documents Check that all 3 external screws are present One near the back of the screen (ground screw for optional ground wire) One at the front on top (to hold the tip in) One at the front on the bottom (to hold the case together, does not touch the tip) Check that the tip is clean \u0026amp; wipe it down with a dry towel or IPA (uniformly silver at the front, with no pitting or texture). Some tips come pre-dipped in solder for protection and may look odd. Heat them up then wipe clean on a soldering sponge or brass wool and inspect. Heat up the tips a few times to 350°C for a couple minutes to check that they are working and melting solder. See Pinecil Tips and Guides to Soldering \u0026amp; Maintenance for soldering advice. Re-tin the tip before storing is advised to prevent oxidation. Check that it heats up with an installed tip, and stops increasing when it reaches the set point. This may draw up to ~3A, make sure the power supply can provide a minimum of 3amps or more. Minor overshoot may occur, but, disconnect power if the temperature keeps going up higher without user input and check with the live volunteer Pinecil channel. Do a simple test is to see if the iron will melt solder at approximately the expected temperature for the alloy of solder being tested. If no direct measurement is possible, set it to ~230°C and see if it just about melts SAC (lead-free) solder (~190°C for leaded). This may be more if the room is cold. If there are multiple tips, wipe all of them with isopropyl alcohol (IPA) or a dry clean towel and check that they all heat up. If the tip moves a little while using it, try to hold Pinecil with the screen facing the side or screen downwards. Members found that if the screen is up and the screw loosens during use, then the tip wobbles a little. Changing holding angles helps the tip press against the solid barrel instead of wobbling on the stub of the small screw. Development projects Author Project Homepage Description Supported Ben Brown (ralimtek) Ralim’s IronOS Official Pinecil firmware BL706, GD32VF103TB, Stm32f103 Marek Kraus gamiee/gamelaster Blisp V2 Flasher CLI Updater for Pinecil V2, BL70x MCU Windows, Linux, Mac Marek Kraus gamiee/gamelaster Pinecil V1 Flasher Pinecil V1 GUI Updater Windows, Mac Arkaitz Goni Hedger spagett1 PineFlash Pinecil V1 GUI Updater Linux, Mac Builder555 BLE PineSAM Bluetooth LE Settings \u0026amp; temperature control from any browser Cross-platform, runs local script to control Pinecil from PC or phone. Joric (iamjoric) BLE browser API Bluetooth LE Graph Windows, Linux, Android browsers that support BLE GATT Tom W (TomW1605) \u0026amp; ithinkido BLE V2 + ESP32 Bluetooth LE V2 data =\u0026gt; ESP32 BLE+Wifi =\u0026gt; Home Assist display Cross Platform Bouffalo Lab B-Lab Dev Cube MCU vendor GUI for Dev BL70x, BL60x, others (does not work for Pinecil V2) Alvin Wong Rust code on GD32VF103 Rust code demos for Pinecil V1 GD32VF103TB tr4nt0r pynecil Python library to communicate with Pinecil V2 via Bluetooth Cross-platform, Python \u0026gt;= 3.11 tr4nt0r Home Assistant Monitor and control Pinecil V2 from Home Assistant IronOS integration introduced in HA 2024.8 Note Bluetooth (BLE) apps require upgrading Pinecil V2 to IronOS 2.21 or newer firmware here. Guides to Soldering This article is a list of convenient links to guides on soldering. Although it’s not directly related to Pinecil hardware, many PINE64 members ask for this kind of information in daily live chat. If you don’t find something here, then try an Internet search as this is just a starting point for convenience.\nGeneral soldering guides Why have different tips? Easier method to solder SMD, and a clever Cleaning method How to Solder SMD \u0026amp; Small Components - Mr. Solder Pace Basic Soldering lesson 1-9 How to Desolder/Correct mistakes Mr. Solderfix - Remove Components Ultimate soldering guide Should I switch to Lead-free solder? Beginner’s Guide to Soldering - Mr. Solder Fine SMD Soldering Comic book - Soldering Does solder type and flux matter? Does Solder quality matter? When to use Flux 63/37 or 60/40 Solder? How to keep the tip clean? Clean \u0026amp; Care for Tips How to Clean Soldering Tips Sodering Tip Maintenance What temperature should I use? General Formula: add 120°C to the melting point listed on the solder label, and adjust up/down as needed for different tasks. Example: the solder says 220°C melt point, then 220 + 120 = 340 °C\nOne could also try these common working temperatures below, start lower and increment by 5°C until you get a comfortable working temperature (thicker wires \u0026amp; situations dictate more or less).\nCommon working temperatures if direct data for the solder can not be found: # For Lead solder: 300°C - 320°C # For No-lead solder: 350°C - 365°C Another method is an Internet search to find a chart like below for your specific type of solder alloy: Alloy Temperature Chart - Kester Adding a small amount of solder to your tip before starting increases the thermal mass of the tip and could help instead of cranking the temperature super high (which causes other problems). See the soldering guides above for demonstrations of this in several articles and videos. Using the Conical tip How do I use the conical tip that comes default with Pinecil to get enough heat transfer?\nUse the side of the tip to heat the pin. Do not hold it vertically like a pen because the very end of the tip has little heat mass. See https://cdn.sparkfun.com/assets/learn_tutorials/5/8/4/SolderingAdvice_1edit.png Correct amount of solder and solder flow. See https://cdn.sparkfun.com/assets/learn_tutorials/5/8/4/SolderingAdvice_2.png How to Repair This article explains how dismantle, test, and repair the Pinecil.\nCautions Warning while opening your Pinecil will not necessarily void your warranty, all self-repairs are done at your own risk. Read everything in this section and related or linked articles to get a good idea of the procedure, and go to the Pinecil community chat if you desire advice/support from experienced volunteers. Self-repairs or modifications might void your warranty so proceed if this is not a concern. This information is for educational purposes only. Pinecil V1 and V2 have slightly different schematics and have different MCU chips. Doing repairs often requires referencing the correct schematics or photos. The datasheets are also important to get information about the chips, and to order replacement parts. The schematics and known datasheets are all at the bottom of this article and linked in the contents table at the top. Chatting with other owners of Pinecil is encouraged as they have experience - already broke things so you don’t have to (see Pinecil volunteer chat link here).\nNote This is a new work in progress (WIP) started Feb. 18, 2023 which may be updated over time as volunteers have time to write up information. For sections that are missing, try asking in the live chat as a volunteer may have some clues to get you headed in the right path. Tools needed Digital multimeter (DMM) Philips screwdriver All schematics, datasheets for known common parts, and links to where to buy replacement parts are all in this article under Schematics and board data. Refer to the correct section for V1 or V2 parts. Which model do I have? The older V1 model has an all black handle with a blue silicone grip and was discontinued in July 2022. The new V2 model has a black handle with a green thumb grip and is the only model PINE64 and authorized resellers started selling after August 1, 2022. Magnifying lamp or jeweler’s glasses with led light and good room light. Photos/videos will help to chat with volunteers in the live Pinecil chat channel if getting clarification or troubleshooting. Optional: mobile phone to take macro photos or video. A macro lens to take phone photos is helpful; there are cheap ones that simply clip on. Possibly another soldering iron to do the repair, some flux, solder, and isopropyl alcohol (IPA) for cleaning the PCB. See [[Pinecil_Cases,_Stands,_Supplies#Soldering_supplies| this guide]] for some basic supply options. Optional: better needle size probe leads for DMM makes things easier and are nice for electronic work. Reference photos are in the images section. Dismantle steps Easy trick to open Pinecil Video of easy trick: https://www.youtube.com/watch?v=aK01V5DrrVk Handle replacement graphic Step-by-step It is recommended to take photos to help with reassembly. Loosen the top tip screw (PH1) (top is the side with the screen). Gently pull the tip out and set aside (let the tip cool down first or use protection to prevent burns). Slide the rubber thumb grip off the front. Remove the bottom-front screw (between the bottom feet (PH1)). Remove the ground screw (longer m2x4mm screw next to the screen near the (-) button (PH1)). Slightly pull the two halves of the case apart at the tip front end first, enough to get a fingernail or guitar pick between 2 parts. Move the pick down the length of the split to loosen the bottom half’s clips from the top half of the case. Once loose, remove the bottom half by sliding it a little forward (it is retained by the top half at the DC barrel side). Remove the screws retaining the copper tip contacts (PH000, M1.4 x 5). Remove the copper tip contacts (note the orientation of the contacts \u0026amp; tiny tab hole). Lift the PCB gently up from Tip end. Remove the round copper ring contact from under the PCB, near the tip end of the handle (this is installed first before the PCB because it provides ground contact from the front of the Pinecil to the rear ground screw). Remove the two small round buttons so they do not get lost. Assembly steps Place the two round buttons into the two holes in the top half of the case. Install the round copper ground ring at the tip end before installing the PCB. Place the PCB board into handle at an angle, DC barrel end goes in first. Lower the rest of the board into the case and align the PCB with the 2 contact screw holes. Install the two copper tip contacts (note the small tab on the contact and the small hole in the PCB for it). Orient the contact to align the alignment pin with the alignment hole next to the big hole on one of the big gold pads. Install and gently tighten the PH000 screw until the clip is no longer loose. Place the bottom half of the case into the top half by sliding the lip on the port side (side without the feet) of the bottom half under the arch of the port side of the top half. Gently close the case by bringing the two halves together, paying attention to each clip’s alignment and ensuring the case edges align. Install the short PH1 screw at the bottom of the tip side of the case. Install the longer PH1 screw at the ground connection point at the top side of the case (between the display and the ports). Slide the rubber sleeve on (larger ridge first). Gently insert tip. Gently tighten the top PH1 screw to retain the tip. Note For normal operation of the iron, omission of the copper ring in step #2 does not impact operation. If you are working with ESD components, you need it in order to ground the iron tip via the earth screw at the back of the iron. It is recommended to keep this installed. FAQ Common Fixes Sometimes, just updating to the newest firmware fixes issues as Ralim and team are very active in adding features and enhancements (see Firmware). Some Troubleshooting information is also on GitHub Ralim’s IronOS (which is the firmware that is on the Pinecil). There are several hidden Debug tools in the firmware that also help with diagnosis. Clean all new Tips (Cartridges) with 90%-99% IPA (Isopropyl Alcohol) especially the white end with the 2 silver contacts. If you can’t find the information here or it hasn’t been written yet; simply join the volunteer run live Pinecil chat channel. Sometimes you can get a clue to the right path. Common Questions Temperature is flickering wildly: Most likely just need to clean whole cartridge/tip with IPA (reference issue). See Poor Contact Fix here]. If it’s jumping wildly after reaching set temperature, this is also caused by using a low amp/volt charger that is below the 3amp minimum required for Pinecil (per manufacturer rating), upgrading to a 3.25amp/20V USB-C charger often fixes this (reference issue). Some people might see a random spike while idle. Solution: update firmware, there are some ADC timing adjustments in IronOS 2.21+; it’s a good idea to keep your firmware updated to newest stable release (reference issue). This fix is included in 2.21+ release. I see No Tip connected symbol randomly on new Pinecil: tip is installed and it heats up, but randomly I get no tip symbol. See #1 above, it is most likely the same reason, dirty contacts on the back of the cartridge/tip. follow the same instructions for Poor Contact Fix here. Reference ticket on Github. How do I install the optional Hall Effect Sensor? See the Hall Effect Sensor article for installation; location is U14 on the PCB \u0026amp; in the Schematics. Reference schematics section also. Help, I think I bricked Pinecil doing an update: no worries, it’s very hard to brick a Pinecil because of the way the firmware is loaded in ROM. Usually just flashing again with a newer or different version brings it back to life (see Firmware). This can be done even if you can’t see your screen anymore. My Pinecil keeps rebooting: change to a different charger or add a ground wire to your Pinecil ground screw (search for ts100 ground wire on a search engine). Also see the Power Supplies article. This could happen because of the way 2-prong no-ground chargers are made with no ground path for small current leakage. Also try to plug the charger into a surge protector strip (type that have 3-prong ground and plug the surge protector into a 3-prong grounded wall outlet). Try a different cable or flipping the cable over also. Tip is glowing red hot. Unplug immediately, you have most likely a blown MOSFET, check that out, replacement parts in Datasheets below. Tip is probably damaged too. My temperature display is way off and Pinecil is at room temerature: first, check the poor contact fix. Then enter the hidden debug menu and look for HAN C which is the internal handle temperature. This should normally be close to or slightly higher than the room temperature if the Pinecil tip is also at room temperature. Under load, the HAN C can go up a bit, otherwise when the tip is cold, the HAN C should be close to ambient. Check the hidden debug menu for HAN C or C Han depending on your version of IronOS. See IronOS Troubleshooting here, esp. about CHan and the Temperature sensor. If the reading is out of spec (very low/high), and reflowing/resoldering the Temperature sensor does not work, replacement might be needed. Screen shows X symbol (no tip installed) and I have a tip installed. Remove the Tip screw, seat the tip all the way back, reinstalled the screw. See Tips and Poor Contact repair. I see Thermal Runaway or Undervoltage messages on the screen. This is often caused by using a weak power supply that does not have a minimum of 12V-3amps and is not rated to work with Pinecil. Pinecil will stop heat to the tip and display Thermal Runaway. TL;DR get a USB-C charger 20V 3.25 amps, PD 65W (best bang for the buck for good Pinecil performance) many available between $15-$25. Detailed information on chargers can be found under Power supplies. I plugged in the wrong kind of DC barrel charger, it was a not Center-positive pin and now the Pinecil won’t turn on: see Reverse polarity damage. Usually requires replacing the MOSFET (U13) and Buck Converter/Step-down (U8). See the datasheets for links to parts. I hear a sizzling/crackle sound from my new Pinecil: this is usually fine and may disappear after a few days of use, see Hissing Crackle Sound. Screen is black: first try to update firmware. Check out the IronOS troubleshooting guide here for possible issues. See the datasheets here at the bottom of this article for links to replacement parts. Repair method would be similar to ts100 screens of which there are many guides like this video. If the tip heats up, but screen is black, the OLED may have failed/burned out. If tip does not heat up, it may be something else. Sometimes just reflow/reheat the solder for the OLED screen fixes issues. Using OLED screen at lower brightness extends the life. Solutions Hissing Crackle Sound The sizzle sound will usually go away after a few days of use and heating up the iron. After wiping the tip contacts with IPA, heat it up a few times to 350 °C. Ralim said, \u0026ldquo;there is usually a bit of noise when you first use it, and a slight hiss/pop noise from the handle and that is normal. depends a bit on exactly what batch of caps are in your unit. The Tip drive signal is AC coupled through a capacitor for safety, downside is that it means the firmware is hitting that cap with a square wave the whole time the tip is on. Once you have heated up the duty cycle, it drops off so it’s not as noticeable.\u0026rdquo; Some members reported that after they opened their new Pinecil, wiped the PCB and tips gently with IPA, let it dry, all the sizzling noise went away. They also did a break-in of the new tips, bringing the temperature to 350 C a few times. Video of similar crackle sound on the ts100 iron (don’t have example of Pinecil, but it’s similar sound). Cartridge/Tip Problems Wipe entire tip (cartridge) clean, details in Poor Contact section Using a multimeter, switch it to ohms to measure resistance. Measure the two silver bands at the rear end (white). If it measures OL or infinity, or extremely out of the spec range below, it might be bad. Normal ts100 style tips should measure ~7.8 ohms - 8.3 ohms. PINE64 brand Short tips should measure ~6.1-6.5 ohms. See the Tips for more details. Poor Contact Fix Most likely the tip (cartridge) is not making good contact (at the silver bands on the rear white end). Usually this issue goes away after a few days of use as the cartridge rubs against the internal contacts more. New cartridges could have factory residue on them that interferes with the R-tip reading. To fix this issue quicker, wipe all new tips (cartridges) with a dry towel or 90-99% IPA (isopropyl alcohol) especially the two silver contacts at the white end (do not use water to wipe as it could get into the seam line on the white end). With the Pinecil unplugged, remove and reinsert the tip a couple times and spin it a little inside against the contacts. Then plug it in and heat it up to 350 °C a few times for a couple minutes. These steps tend to resolve most new Pinecil or new cartridges causing flickering temperatures or \u0026ldquo;no-tip\u0026rdquo; icon displays randomly. Always unplug Pinecil before swapping tips. Hot swapping is not a good idea, and for the V2 this could cause strange behavior as the V2 auto-detects tip resistance only on power-up or reboot. Sometimes just disassembling and reassembling all parts back correctly and installing the 2 internal contacts with screws correctly also helps. Poor contact could happen if the tips are not clean or brand new with factory residue or not making good contact with the internal clips inside the Pinecil. The two contacts inside might need to also be removed, wiped and reinstalled with the two screws (ensure the small metal tab on the clip sits into the small hole in the PCB). See Pinecil Tips article for more details on testing. Reverse Polarity Damage Pinecil requires a center-positive DC power supply which most are, but some are reverse polarity and will destroy the electronics if used. If you plugged in a \u0026ldquo;center-negative\u0026rdquo; DC power supply, most likely the MOSFET and the buck converter are broken. This usually requires replacing the MOSFET (U13) and buck converter / step-down (U8). See the datasheets for links to replacement parts which is at the bottom of this article [[#Datasheets_for_Components| here]].\nImportant Check the polarity of the DC barrel plug before plugging in a random charger. Incorrect polarity will break the Pinecil. The video here shows how to check. Reference the article on [[Pinecil_Power_Supplies#DC_Barrel_Power| DC barrel chargers here]], (i.e., laptop bricks) for appropriate USB-C and DC chargers that will work with the Pinecil.\nImages Screen side: V2 on top, V1 below\nPinecone side: V2 on top, V1 below\nMOSFET V2\n_LDO_and_OP-Amp\nUnder the OLED screen, V2\nPinecil V1, 24V Mod Warning Do this at your own risk, read everything in this section and related/linked articles, and go to the Pinecil community chat if you desire advice. An incorrect cut of the trace could render the Pinecil non-working. Pinecil V1 has blue rubber. Newer Pinecil V2 has green rubber \u0026amp; Bluetooth LE chip\nThis modification is not for the V2 (sold after Aug 1, 2022 with green thumb grip) as the V2 already has 24V DC barrel charger capability. If you have an older V1 model, then first upgrade to the newest firmware here before starting this modification. The PD debug menu was added to the firmware in 2.17 and other important fixes came later. Access to the hidden PD debug menu is necessary to assist with this mod. See Ralim’s IronOS for how to use the hidden PD Debug here and check if your version of Pinecil V1 could benefit from the modification. If PD-Debug menu says \u0026ldquo;No VBUS\u0026rdquo;, then stop here, you do not need the modification or any cut of the trace line, it will not benefit you because there is no connection to the VBUS already. If it says \u0026ldquo;w. Vbus\u0026rdquo; then continue. If you don’t have a PD-Debug menu, then upgrade to the newest firmware first, see instructions above. Some models of V1 came with the PCB already capable of 24V as the Pine Store made modifications to the PCB (not all batches of V1 were the same). Do the PD debug test first to see if the mod is not required. See the February 2022 Community update here. The photo is incorrect in the article. It is not a before and after photo. Photo shows two separate PCBs of Pinecil V1 made at different times; therefore, the trace is cut in a slightly different location depending on which one it looks like. The PCB with 2 small via holes and is harder to cut in the correct location to avoid damaging the holes. This is called the \u0026ldquo;whalecil\u0026rdquo; in community chat (looks like a whale). PCB 1 style (left photo) is easier to cut the trace. Cut all the way across the trace and deep enough to cut the copper contact. PCB 2 style (right photo) is harder because the trace has to be cut without damaging the 2 via holes. Don’t plug in 24V until you first check with a USB-C PD charger that PD debug says No VBUS which means the mod is complete. If it still says W. Vbus, then the connection still exist. Cut a little deeper and clean the cut with some IPA (isopropyl alcohol) to remove any copper dust, dry it and check again. Taking a macro photo with a phone helps to examine the cut. If a USB-C charger is not available, often a phone with a USB-C port is a PD type, and can be used like a charger to plug in and check the PD debug messages (unfortunately, a PC port is not normally \u0026ldquo;PD\u0026rdquo; and won’t give proper PD Debug). If you want another set of eyes on it before you cut, post a photo of your PCB (near the Pinecone) on the Pinecil chat channel. Ask for a volunteer who has completed the 24V mod on a Pinecil V1 to assist. Not all chat people own a Pinecil even if they are in the Pinecil channel. Modifications Hall Effect Sensor\nOptional advanced modifications\nHall Effect Sensor Instructions to install a hall effect sensor (HES) on the Pinecil V1 and V2.\nThe Hall Effect Sensor (HES) is an optional end user installed sensor that activates to put Pinecil to sleep when it enters a holder or stand. This requires a neodymium magnet attached to the stand. The closer the HES in the Pinecil is to the magnet, the more likely the HES will activate to enter sleep mode. This adds a feature to Pinecil that is often seen in high end pro irons.\nTools and Supplies Order a Hall Effect Sensor (SI7210-B-00 here), also at Digikey and Mouser. Ordering 2-3 might be a good idea in case the first one is damaged during install (if all goes well, one could mail the extras to a friend or another Pine64 member in the community chat ;). Jeweler’s magnifying glasses or magnifying lamp or a microscope is recommended as the SOT23 chip is very small. Borrow a second soldering iron (this is when 2x Pinecils is a good idea). Get some neodymium magnets, just two 8x2.7mm at 8:00PM and 12:00PM on the stand could be enough. Experimentation is needed. Start with just one small magnet and increase the number placed around the stand until 360° sleep is activated when the Pinecil hits the stand. Reference [[Pinecil:_How_to_Repair#Schematics_and_Board_Data | Schematics are here]] (search for U14). Videos Easy trick to Open Pinecil. How to install Hall Sensor video. Installation Updating to the newest firmware before installing is recommended, see the Firmware article. These instructions are for 2.18 or newer firmware. The HES is located at the very front of the Pinecil, tip end, see PCB images here. Once it is soldered, cleaned, and assembled, check the sleep menu, a new hall sensitivity option appears. See this article on how to set up the sensitivity settings on the firmware menu (Ralim’s IronOS). Once you change the Sleep menu \u0026gt; Hall sensitivity to what you like, then scroll back to the main screen in order for the setting to be saved and persist on reboot. Note: IronOS firmware does not flash a setting change until one scrolls out of the sub-menu back to the main screen. This is to reduce the total number of flashes done as several settings might be changed in one section (number of flashes is not unlimited; most users will not encounter the maximum allowed flashes on normal use over years). Hints Try not to overheat the sensor while soldering as that could damage it and even cause a leg to fall off. This is a small SOT23 chip. Tacking one pin on the 2-pin side helps to hold it in place before soldering the rest of the sensor. It is recommended to solder this with an iron with a small tip instead of using hot air (depends on your experience with hot air). See photos below, use kapton tape to protect nearby components: the 3 via holes above the 3-pin side, and the NTC temperature sensor on the other side. If too much heat is applied, it could damage the pcb, and/or affect the I2C and cause screen corruption. Apply generous flux to the area. If lead solder is being used, it is recommended to remove some of the existing no-lead solder that is already on the U14 pads. After the HES is soldered, clean the area completely with 99% isopropyl alcohol (IPA) and a soft toothbrush or small paint brush and dry before assembly. Air/hair dryer could be used to blow out some of the wet IPA. Not cleaning it well enough could cause some I2C noise on the screen. Try to keep IPA/alcohol away from OLED screens. If the stand/holder is not metal, tape magnets near where the Pinecil enters the hole in the holder to test out good locations. Hot glue is another option. When closing the handle, inspect that the the seam line is fully snaped closed; avoid pressing the screen. Images Before installation, location at U14: After installation: Only needs small amount of solder: Kapton tape/protect the 3 Via holes above 3-pin side,title=\u0026ldquo;Kapton tape/protect the 3 Via holes above 3-pin side\u0026rdquo;: Kapton tape/protect the NTC sensor on opposite side of V2 (V1 does not have this): Optional advanced modifications [[Pinecil_Hall_Effect_Sensor| Hall Effect Sensor]]: add a sensor that activates with a magnet to put the Pinecil to sleep when it enters a holder or stand. [[#Fasteners/Screws| Thumb Screws]]: switch tiny tip holder screw to an easy to use thumb screw. LED light ring install: add a PCB light ring to Pinecil. Video of the process LED light install: add two LEDs to Pinecil. RGB internal LED - pink and blue LEDs. Purchase Shipping and Tracking\nWhere to buy\nShipping and Tracking This article applies only to the main Pine Store, pine64.com items that ship from their Shenzhen, China facility, such as the Pinecil soldering iron and PinePower chargers.\nNot discussed in this article: big battery devices such as the Pinebook Pro, PineTab, PineNote, PinePhone and PinePhone Pro which all ship from Hong Kong (the PinePhone ships from Poland for EU orders).\nHow does it work? Order Email: when the Pine Store receives an order, an initial email is sent out within one day. This email confirms your order was charged (check spam folders for \u0026lsquo;Pine Store\u0026rsquo;). Shipping Email: after several more days, when the order is shipped, a second email is sent with a tracking number. This could take a week or two. Pine does shipments in batches, you get the tracking number faster or slower depending on when batch day is. In general, people report getting a shipping/tracking email within 5 days, just wait for this email (search emails for \u0026lsquo;Pine Store\u0026rsquo;). If you don’t get the first \u0026ldquo;order email\u0026rdquo; soon after placing the order, then contact the Pine Store here as your order may not have completed or been charged. Courier options Cheap shipping (~$12): could take 2-7 weeks or more, this sometimes gets delayed in the customs department in your home country due to backlogs (some had 7 weeks mainly because it was stuck in their country’s customs department for many weeks before being cleared to leave customs, especially during height of COVID and reduced customs staffing). Currently, members report about 2-3 weeks, as always it can be held up in the customs department of your country if you are shipping it from outside of your country. Courier shipping: more expensive (~$25-$30), can take ~4-10 business days or more based on feedback from PINE64 members. Pine Store shipping policy (30-day warranty starts when Pinecil is delivered). Note: resellers operate independently from the main Pine Store. They are in different countries and set all of their own procedures, shipping costs and options. Get all reseller shipping details for each store from their specific websites/chat tools/email. Tracking The tracking number issued in the shipping email may not work for a couple days, just check again. https://parcelsapp.com/ https://www.17track.net/ If you see the message \u0026ldquo;outbound imports cancelled\u0026rdquo;, just wait. It is a poorly worded message. Members experience that it updates after 1-3 days to show a hand off from China Post to a USA facility. The message would be more clear if it was \u0026ldquo;outbound imports transferred/complete\u0026rdquo;. Why doesn\u0026rsquo;t Pine Store Ship to my country? If Pine Store does not ship to your country currently, check out one of the many legit resellers here. Try emailing a few of the resellers, you might get lucky. Consider that resellers probably don’t want to lose money sending a package that doesn’t get there because then the customer asks for a refund. Keep in mind that the Pine Store is small with a limited number of staff. Some major couriers have temporarily stopped shipping to some countries. Customs paperwork for some countries is too difficult for a small business like Pine Store to manage. If Customs laws change in some countries, Pine Store may have to move from cheaper shipping options to more expensive courier options. Too many packages have gotten lost to some countries. Pinecil and other items have a low margin; lost packages have a great impact. Some resellers are more prepared to take the risks so that the Pine Store can stay focused on engineering new hardware. When possible, the Pine Store leaves open the more expensive courier option instead of stopping all shipping to a country. Some friends try to do a group purchase to spread out the shipping cost for each person. Pine Store is registered at Hong Kong/Singapore and is not a registered China company and therefore can not ship to China addresses (exports only) even though many Pine64 products like Pinecil are made and shipped from Shenzhen, China. Pine Store can not sell on AliExpress (see above). All AliExpress items using the PINE64 and Pinecone logos are fake copies (see authenticity here). For some countries people reported using a package forwarding company (unsure if safe or reliable, use at your own risk). Where to buy PINE64 Official Stores\nMain global PINE64 store (ships from China, exports only, Global, VAT not included). Amazon-USA official pine64 store (ships from USA, has Pinecil V2 - no tips/accessories) Affiliates\nAmeriDroid (offers pre-order, ships to USA/Global/Brazil) blinkyparts GmbH (ships from Germany, shipping worldwide, full sortiment 2-years warranty included, offers full range of Pinecil accessories) Eleshop.eu (ships from EU, offers pre-order, 2-year warranty included per EU laws). In Netherlands, use this NL link. Droneit (ships from Sweden, sells all Pine tips/accessories). Handheld Legend (ships from USA to worldwide). Keycapsss (ships from Germany to EU/AUS/Global) Testclips (ships from GB) Typeractive (ships from USA to 55 countries). URS Electronics (local in-store only sales in Portland, Oregon, USA) bitcompact (ships from Canada) Reference: https://pine64.com/affiliates/ Why buy from a legitimate seller?\nThe PINE64 Mission is to get hardware into the hands of open source developers and tinkerers. Buying authentic Pinecils supports that mission (see this article).\nIn July 2022, all final stock sold out of Pinecil V1 (GD32VF103 mcu) at the Pine Store \u0026amp; all legit resellers. There are zero new authentic Pinecil V1 sold in the world after July 2022. Pinecil V1 was made in a black color with a light blue finger grip. PINE64 never made an all-blue Pinecil, and never used blue or red color boxes (those are fake copies with fake PINE64 logos and Pinecone).\nStarting Aug. 2, 2022, only the new Pinecil V2 model with the new BL706 Bluetooth Low Energy (BLE) MCU are made by PINE64 and sold at all authentic resellers. They are black with a green finger grip (see photos in the Picture section). The new model has anti-counterfeiting features. Authentic Pinecil using the newest official GitHub IronOS firmware, will successfully pass the Authenticiy Checker website. If a new Pinecil (post Aug. 1, 2022) does not have a BL706 chip, then it is a fake copy. If the AliExpress seller tries to show \u0026ldquo;CE certification\u0026rdquo; documents as some type of proof, those are all copied public info from the documentation page in the certifications section. PINE64 publishes those as they are the CE/FCC certifications for the stamps on the Pinecil. They are not proof of purchase from the Pine Store Ltd.\nTips This article is about the available tips for the Pinecil and how they work.\nPinecil Tips Tip Pay attention to the length! Pine Store sells two different lengths of tips. What kind of tips work? Pinecil V2 uses both Pine64 designed Short Tips (ST line, 6.2-6.5 Ω) and TS-100 Normal length compatible tips (TS line, ~8.0 Ω). Presently, the V1 uses the normal length TS100 style tips (~8.0 ohms) until a firmware update enables manually switching the tip types. Check Github Ralim’s IronOS here for progress on this. Unplug before swapping tips as the V2 automatically detects the tip resistance at boot-up and it is safer. How to increase tip life? Typically, lead solder uses a working temperature of ~300°C-320°C and no-lead solder ~350°C-365°C (check the temperature charts in the soldering guides or google it for your specific solder type, it varies). Always start lower than needed and increase ~5°C at a time until you reach a good working temperature. If you want your tips to last longer, use the lowest temperatures you can comfortably work at. Thicker wires, etc., may need more (adjust). The open source firmware may allow the use of temperatures past the manufacturer limit for tips, but that doesn’t mean you should. That said, people have reported using the boost feature at 5-15 second burst to \u0026gt;430°C and have been perfectly fine (TS100 and Pine64 tips are readily available at reasonable prices and some people prefer convenience of higher temperatures and accept they might replace tips more frequently as a trade-off). If the tips are not too expensive, some keep spare tips and boost to high temperatures freely for convenience, and simply replace the tip when it loses the plating or the tip fails (common sign of tip failure is tip plating is gone, has pit holes, or a multimeter measures OL infinite ohms across the 2 silver contacts on the cold end of the tip). Check out this Soldering Guide article for more details on best practices for use and maintenance of tips. How to check new tips? Short Tip 6.2 Ω\nRemove the screw on top, then remove the cartridge. Clean new cartridges/tips with isopropyl alcohol (IPA) to remove any factory residue before installing (avoid strange behavior). If you have no IPA, use a dry clean towel, especially the white end with the two silver contacts (do not use water; it could get into the seam line on the white end). This often resolves issues with glitchy temperatures or random no-tip symbol from poor or dirty electric contact [reference]https://github.com/Ralim/IronOS/issues/1601). Clean contacts with IPA\n. Then install the cartridge/tip, re-install the screw on top, and heat the tip a few times to 350 °C for a couple minutes. . If you don’t have a multimeter, then after you initially heat the tips a few times to 350 °C. Then change the temperature to the correct range for the solder you purchased and check if it melts solder (add a little solder to the tip end also before storing it). . If you have a multimeter (dmm) and have an issue with the cartridge/tip, then you can measure when the tip is cold (room temperature and unused a couple hours). Set dmm to ohms and the correct range, and measure the 2 silver contacts on the rear white end. . Warning: warm tips change the measurements (measure only when cold and unused for a couple hours).\nShort tips could be ~6.2-6.5 ohms Normal length tips could be ~7.8-8.3 ohms If the tip measures OL (open loop) it is defective. Also a tip that is way off spec, e.g., 10 ohm will cause strange behavior on temperature readings. If you measure when it’s even a little warm, the ohms will be much higher; this is normal and how the cartridge/tip works. Why have different tips? See the Soldering Guides for usage of different tips and how to keep tips clean. How does the tip work? A thermocouple is integrated into the end of the tip itself; advantage is every new tip includes a brand new thermocouple and it’s a more accurate measurement of the temperature. Pinecil tips are considered newer tech style. This is more accurate compared to older style Irons where the thermocouple is in the handle and much farther from the end of the tip. Science: what is a thermocouple? How is Tip Temperature measured in Ralim’s IronOS firmware? What does the inside of a ts100 tip look like? Pine Store Tip Options I. Short tips Important Pay attention to the length in your cart! Pine Store sells two different lengths. All new Pinecil V2 soldering irons include a single Pine64 newly designed Short tip (ST-B2 conical). The discontinued V1 came with a longer normal length TS-B2 conical tip. Pine Store carries 4-Packs of Pine64 designed Short Tips (only Pine64 makes the short style presently) Short tips Fine link, white box (~6.2-6.5 Ω) Short tips Gross link, white box (~6.2-6.5 Ω) Pine64 Short tip packs are lower resistance/ohms which means higher performance and better ergonomics. Many professional irons have shorter tips for more control while soldering. Note Older Pinecil V1 can not use the short tips until firmware code is written to enable manual selection of 6.2 Ω or 8.0 Ω tip. Only the V2 model has the hardware to auto-detect the two kinds of tips short 6.2 Ω or regular length 8.0 Ω. If you would like to help with the code, see GitHub/IronOS. Short gross set, white box\nShort fine set, white box\nST-B2 conical short tip included with the V2 Pinecil\nThe shorter tip is designed for higher performance and requires more power than longer traditional TS100 tips\nRecommend using minimum of usb-C PD65W-3.25A-20V or higher voltage charger when using Short tips (short tip draws more power than longer tips because of the lower ohms).\nFor example with a PD65W-20V charger, the maximum watts with a standard 8 ohm tip is 50W, whereas the max watt with a 6.2 ohm tip is ~64 watts (watts/volts calculator).\nHeating formula: P = IV = I^2 * R = V^2 / R (⇧ watts = ⇧ faster heating)\n20V @8Ω tip=50W; @6.2Ω tip=64.5W 24V @8Ω tip=72W; @6.2Ω tip=92.9W II. Normal tips Important Pay attention to the length! Pine Store sells two different lengths. Normal Length Gross Set here (~8.0 Ω) Normal Length Fine Set here (~8.0 Ω) Fine Set, Normal length\nGross Set, Normal length\nRegular Length TS Tips: Left= Fine set, Right = Gross set. Both TS sets have ~8.0 ohm tips and are the standard length similar to other TS100 style tips.\nImportant Currently, Pinecil V1 original uses the normal length ts100 style tips and not the newer Short tips designed for V2. Ralim is working on adding a feature to the firmware to allow people with the older V1 Pinecil to manually switch a profile setting which allows toggling between Normal Tip and Short tip profiles (adequate power supply must also be used min. PD65w 3.25A, 20V recommended). Check Github Ralim’s IronOS for progress information. Always unplug when swapping tips. Other compatible tips BC3 and JL02 are not sold by Pine Store, ~8.0 Ω\nCommon resistances for tips:\nPINE64 designed short tip 6.2 Ω, shorter length, only at pine64.com. no brand long tip 7.9 Ω, normal length ts100 style Miniware long tip 8.0 Ω, normal length ts100 style no brand long tip 8.3 Ω, normal length ts100 style Compare different soldering iron sizes:\nThis photo shows common irons to compare the distance from the finger grip to the work surface.\n","permalink":"/documentation/Pinecil/_full/","tags":null,"title":"Pinecil (Single Page)"},{"categories":null,"contents":" Humor Most interesting man Science Pinecil Videos V2 review, Aditya Mukherjee V2 review, Platima Tinkers V1 review, Adrian’s Basement V1 review, Adam Welch Custom made wood box Aluminum carry box Pinecil V2 Articles Smart Soldering Iron, Got Bluetooth? How Pinecil Integrates newest USB-C protocols Tomshardware Review CNX Software Review Pinecil V1 Reviews Hackspace Review Hackaday Review Pinecils in the Field Pinecils in the field ","permalink":"/documentation/Pinecil/Further_information/Pinecil_in_the_Media/","tags":null,"title":"Pinecil in the Media"},{"categories":[""],"contents":" The PineCone: A board to blob-Free WiFi \u0026amp; BLE The PineCone is a BL602 evaluation board, which was developed with the goal to challenge the open source community to achieve blob-free and free and open source WiFi and Bluetooth, see the Nutcracker Challenge.\nStores Global Affiliates Documentation PineCone Further information ","permalink":"/devices/pinecone/","tags":null,"title":"PineCone"},{"categories":null,"contents":" The PineCone is a BL602 evaluation board, which was developed with the goal to challenge the open source community to achieve blob-free and free and open source WiFi and Bluetooth, see the Nutcracker Challenge.\nChallenge The goal of the challenge is to achieve a blob-free BL602 for the open source community to achieve a blob-free FOSS Bluetooth and WiFi on PINE64 devices, see Nutcracker Challenge: Blob-Free WiFi \u0026amp; BLE.\nJTAG Default JTAG pins GPIO Pin JTAG Pin GPIO17 TDI GPIO11 TDO GPIO12 TMS GPIO14 TCK BL602 multiplexes four GPIO pins to provide the familiar JTAG lines. See the accompanying table for the default pin mappings.\nThese are the default JTAG pins in use after a cold boot. However, many pieces of software, including the demo that\u0026rsquo;s installed by default on new PineCones, remap these pins to other functions. You cannot use the default wiring for JTAG while such software is running. This issue is especially prevalent on the PineCone because three of the default JTAG pins are connected to the onboard RGB LED. Nothing about the LED itself interferes with JTAG, but any program that uses the LED will necessarily remap some of the default JTAG pins to be GPIO.\nThe MaskROM download mode that the BL602 enters when you tie GPIO8 high does not remap the default JTAG pins, and so you can and should use that mode while checking basic functionality of your JTAG adapter.\nNote that, just as software can remap the default JTAG pins to be something else, it can also remap other pins to be JTAG. Control over this is quite granular, with 5-6 candidate pins for each individual JTAG signal that can be mapped independently of one another. LEE Lup Yuen has written some sample code showing how to remap the JTAG pins so that your software can use the LED without giving up support for debugging.\nUSB JTAG Adapter The USB JTAG Adapter is an adapter with openOCD for Pinecone and Pinenut development.\nFeatures Using FTDI FT232H chipset Aluminum housing Dimension: 56.8 x 20.2 x 8.6 mm Include 20cm length 5 wires female-to-female DuPont cable Information and schematics PINE64 USB JTAG Adapter Schematic-20201215.pdf (pine64_ft232hl_board-2020-12-14) PINE64 USB JTAG Adapter schematic 20210109 1.0a Loading code To load code, you must move the jumper to the position closest to the edge, press reset, load the code, move the jumper back toward the center of the board, and press reset again.\nThere are currently a number of loaders in progress, each with differing degrees of completeness and success on various operating systems.\nIn the build tree, there is BLFlashCube for Windows, which is a proprietary GUI for flashing images. Linux and macOS binaries are available via Bouffalo Lab’s developer portal. bl60x-flash is in Python and has been reported successful on MacOS catalina (10.15.6) by Punnerud and madushan1000. BLOpenFlasher is a WIP, written in go, by Bouffalo Labs to provide source for a flash utility. bl602tool is a Python utility in development. Bouffalo’s MCU tool (Mar 2021) Python image tool replaced both of the above. Now combined with eflash loader, deals with partitions, DTS, signing, fuses etc. blflash serial flasher BL602 serial flasher, inspired by BLOpenFlasher Development PineCone BL602 GitHub Page (PINE64 fork) has compilers, linkers, and all the code to build on Windows, Linux (x86_64), and MacOS. Bouffalo Lab GitHub Page BL602 Developer organize documentation GitHub Page BL602 Developer organize tool GitHub Page Programming tool for Bouffalo Labs BL602/BL604 chips BL602 reverse engineering working group Linux kernel module BL602 Documentation BL602 serial flasher Awesome Bouffalo Further information Articles and blogs\nBL602 specifications\nDatasheets\nInformation and schematics\nArticles and blogs Quick Peek of PineCone BL602 RISC-V Evaluation Board by Lup Yuen Documenting the BouffaloLab BL602 firmware image format by MK Connect PineCone BL602 to OpenOCD by Lup Yuen Debug Rust on PineCone BL602 with VSCode and GDB by Lup Yuen Porting Mynewt to PineCone BL602 by Lup Yuen Flashing Firmware to PineCone BL602 by Lup Yuen Control PineCone BL602 RGB LED with GPIO and PWM by Lup Yuen Mynewt GPIO ported to PineCone BL602 RISC-V Board by Lup Yuen PineCone BL602 talks to I2C Sensors by Lup Yuen PineCone BL602 talks SPI too! by Lup Yuen PineCone BL602 Blasting Pixels to ST7789 Display with LVGL Library by Lup Yuen PineCone BL602 Talks UART to Grove E-Ink Display by Lup Yuen The RISC-V BL602 Book by Lup Yuen Connect PineCone BL602 to LoRa Transceiver by Lup Yuen RAKwireless WisBlock talks LoRa with PineCone BL602 RISC-V Board by Lup Yuen PineCone BL602 RISC-V Board Receives LoRa Packets by Lup Yuen Run Rust RISC-V Firmware with BL602 IoT SDK by Lup Yuen PineCone BL602 Talks LoRaWAN by Lup Yuen uLisp and Blockly on PineCone BL602 RISC-V Board by Lup Yuen Simulate RISC-V BL602 with WebAssembly, uLisp and Blockly by Lup Yuen BL602 Bootloader by Lup Yuen Machine Learning on RISC-V BL602 with TensorFlow Lite by Lup Yuen Reverse Engineering WiFi on RISC-V BL602 by Lup Yuen Rust on RISC-V BL602: Is It Sunny? by Lup Yuen Rust on RISC-V BL602: Simulated with WebAssembly by Lup Yuen PineDio Stack BL604 RISC-V Board: Testing The Prototype by Lup Yuen Rust on RISC-V BL602: Rhai Scripting by Lup Yuen LoRaWAN on PineDio Stack BL604 RISC-V Board by Lup Yuen The Things Network on PineDio Stack BL604 RISC-V Board by Lup Yuen Encode Sensor Data with CBOR on BL602 by Lup Yuen IoT Digital Twin with Roblox and The Things Network by Lup Yuen Internal Temperature Sensor on BL602 by Lup Yuen CBOR Payload Formatter for The Things Network by Lup Yuen Monitor IoT Devices in The Things Network with Prometheus and Grafana by Lup Yuen Apache NuttX OS on RISC-V BL602 and BL604 by Lup Yuen SPI on Apache NuttX OS by Lup Yuen LoRa SX1262 on Apache NuttX OS by Lup Yuen LoRaWAN on Apache NuttX OS by Lup Yuen Rust on Apache NuttX OS by Lup Yuen Auto Flash and Test NuttX on RISC-V BL602 by Lup Yuen BL602 EFlash Loader: Reverse Engineered with Ghidra by Lup Yuen Connect IKEA Air Quality Sensor to Apache NuttX OS by Lup Yuen Apache NuttX Driver for BME280 Sensor: Ported from Zephyr OS by Lup Yuen Rust talks I2C on Apache NuttX RTOS by Lup Yuen ST7789 Display with LVGL Graphics on Apache NuttX RTOS by Lup Yuen PineDio Stack BL604 runs Apache NuttX RTOS by Lup Yuen NuttX Touch Panel Driver for PineDio Stack BL604 by Lup Yuen Buttons on BL602 NuttX NuttX GPIO Expander for PineDio Stack BL604 by Lup Yuen (Mostly) Automated Testing of Apache NuttX RTOS on PineDio Stack BL604 RISC-V Board by Lup Yuen Zig on RISC-V BL602: Quick Peek with Apache NuttX RTOS by Lup Yuen Build an IoT App with Zig and LoRaWAN by Lup Yuen Build an LVGL Touchscreen App with Zig by Lup Yuen Read NuttX Sensor Data with Zig by Lup Yuen Visual Programming with Zig and NuttX Sensors by Lup Yuen Visual Programming with Zig and Apache NuttX Sensors (Video) BL602 specifications CPU:\n32-bit RV32IMAFC RISC-V \u0026ldquo;SiFive E24 Core\u0026rdquo; SiFive E24 Core information Memory:\n128KB ROM 276KB SRAM 1Kb eFuse 2MB Embedded Flash Security:\nSecure boot Secure debug AES 128/192/256 SHA-1/224/256 TRNG (True Random Number Generator) PKA (Public Key Accelerator) Wireless:\nWi-Fi 802.11 b/g/n Bluetooth® Low Energy 5.0 Wi-Fi Fast connection with BLE assistance Wi-Fi and BLE coexistence Wi-Fi Security WPS/WEP/WPA/WPA2/WPA3 STA, SoftAP and sniffer modes Multi-Cloud connectivity 2.4 GHz RF transceiver Integrated RF balun, PA/LNA Package Type:\n32 pin QFN 4mm x 4mm JTAG support:\nSee below for BL602 impact Datasheets Bouffalo BL-602 SoC information:\nBouffalo Lab’s official bl_docs repository: should always contain the latest SoC documentation available, in PDF, HTML, and reStructuredText source forms. PINE64’s bl602-docs repository: contains an archive of all historical datasheets and reference manual PDFs but may lag behind Bouffalo’s official repository. If you notice that it is, please submit a pull request! USB/Serial adapter:\nCH340 serial converter Information and schematics The approximate dimensions are 26mm x 43mm.\nSchematics: PineCone BL602 EVB schematic ver 1.1\nNote: In the PineCone revision 1.1 (\u0026ldquo;BL62B_EVB V1.1\u0026rdquo; silkscreened on back of board), CC1 and CC2 share one 5.1KΩ resistor. This means the board will fail to power when you use an e-marked USB-C cable like the one that comes with Apple chargers. See this article for details of why this happens. The next schematic design will give each line its own 5.1KΩ resistor as per the USB-C specification.\nThe board uses a CH340 Serial/USB adapter. This chip is commonly used in Arduino-class development boards. It is a full speed (12Mbps) USB interface and has vendor ID 0x1a86 with product ID 0x7523.\nThe GPIO pins (11, 12, 14, 17) plus the nearby RESET, POWER, and GND pins are all located on one side of the board, on J1 to provide JTAG connection.\n","permalink":"/documentation/PineCone/_full/","tags":null,"title":"PineCone (Single Page)"},{"categories":["IP cameras"],"contents":" Who is Looking at You? The PineCube is an Open Source IP Cam Under Your Control The PineCube is a small, low-powered, open source IP camera. Whether you’re a parent looking for a FOSS baby-camera, a privacy oriented shop keeper, home owner looking for a security camera, or perhaps a tinkerer needing a camera for your drone – the PineCube can be the device for you. Featuring an 5MPx Omnivision sensor and IR LEDs for night vision, as well as Power Over Ethernet, and a microphone, the use-cases for this little camera are limitless.\nBeing a FOSS device means that the PineCube remains under your, and only your, control at all times. This is a rather important factor for a device that has a camera and a microphone installed, wouldn’t you say?\nFeatures and Specifications Allwinner S3 Cortex-A7 128MB DDR3 128Mb SPI Flash mSD slot 5 MPx OV5640 sensor 10/100M Ethernet 802.11 b/g/n WiFi Bluetooth 4.1 USB 2.0 26 pin GPIO header Microphone Passive Power Over Ethernet (PoE) Interchangeable M12 lens type (wide, fisheye, zoom, etc.,) IR LEDs for night vision Optional 4.5″ RGB LCD screen Battery support Power Over Ethernet Power the Pinecube using Power Over Ethernet\nNight Vision With built-in IR the Pinecube can see in the dark\nBluetooth Built-in Bluetooth and 802.11 b/g/n WiFi\n26 GPIO Pins GPIO pins to allow further functionality in your project\nStores Global Affiliates Documentation PineCube Schematics and certifications ","permalink":"/devices/pinecube/","tags":null,"title":"PineCube"},{"categories":null,"contents":" The PineCube\nThe PineCube is a small, low-powered, open source IP camera. Whether you’re a parent looking for a FOSS baby-camera, a privacy oriented shop keeper, home owner looking for a security camera, or perhaps a tinkerer needing a camera for your drone – the CUBE can be the device for you. It features an 5 MP Omnivision sensor and IR LEDs for night vision, as well as Power Over Ethernet, as well as a microphone.\nSoftware Armbian Notes\nBuildroot\nReleases\nMainlining\nSDK\nReleases Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://www.armbian.com/pinecube/ Notes:\nSee Armbian notes NixOS NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades.\ndanielfullmer’s Github Mainlining Please note:\nthis list is most likely not complete no review of functionality is done here, it only serves as a collection of efforts Linux kernel:\nType Link Available in version Devicetree Entry Pinecube https://lkml.org/lkml/2020/9/22/1241 5.10 Correction for AXP209 driver https://lkml.org/lkml/2020/9/22/1243 5.9 Additional Fixes for AXP209 driver https://lore.kernel.org/lkml/20201031182137.1879521-8-contact@paulk.fr/ 5.12 Device Tree Fixes https://lore.kernel.org/lkml/20201003234842.1121077-1-icenowy@aosc.io/ 5.10 Audio Device and IR LED Fix https://github.com/danielfullmer/pinecube-nixos/blob/master/kernel/Pine64-PineCube-support.patch https://github.com/danielfullmer/pinecube-nixos/issues/2[TBD] U-boot:\nType Link Available in version PineCube Board Support https://patchwork.ozlabs.org/project/uboot/list/?series=210044 v2021.04 Buildroot:\nType Link Available in version PineCube Board Support https://patchwork.ozlabs.org/project/buildroot/list/?series=314653 2023.11 Armbian Notes This article contains notes regarding Armbian on the PineCube.\nGeneral notes GitHub gist for the user patch which pre-installs and configures the motion (detection) package.\nA serial console can be established with 1152008N1 (no hardware flow control). Login credentials are as usual in Armbian (login: root, password: 1234).\nMotion daemon can be enabled using systemctl (With root) systemctl enable motion. Set the video settings in /etc/motion/motion.conf to 640x480 15fps YU12. Then just reboot. Note that motion currently takes considerable resources on the PineCube, so you’ll want to stop it when doing things like apt upgrade and apt update with systemctl stop motion and then systemctl start motion\nSerial connection using screen and the Woodpecker USB serial device First set the Woodpecker’s S1 jumper to 3V3. Then connect the Woodpecker USB serial device to the PineCube. Pin 1 on the PineCube has a small white dot on the PCB - this should be directly next to the micro-USB power connection. Attach the GND pin on the Woodpecker to pin 6 (GND) on the PineCube, TXD from the Woodpecker to pin 10 (UART_RXD) on the PineCube, and RXD from the Woodpecker to pin 8 (UART_TXD) on the PineCube.\nOn the host system which has the Woodpecker USB serial device attached, it is possible to run screen and to communicate directly with the PineCube:\nscreen /dev/ttyUSB0 115200\nSerial connection using screen and Arduino Uno You can use the Arduino Uno or other Arduino boards as a USB serial device.\nFirst you must either remove the microcontroller from it’s socket, or if your Arduino board does not allow this, then you can use wires to jump RESET (RST) and GND to isolate the SOC.\nAfter this you can either use the Arduino IDE and it’s Serial monitor after selecting your /dev/ttyACMx Arduino device, or screen:\nscreen /dev/ttyACM0 115200\nSerial connection using pinephone/pinebook pro serial debugging cable You can use the serial console USB cable for PinePhones and Pinebook Pros at the store. With a female terminal block wire using breadboard wire into the GPIO block at the following locations in a \u0026ldquo;null modem\u0026rdquo; configuration with transmit and receive crossed between your computer and the PineCube:\nS - Ground (to pin 9) R - Transmit (to pin 8) T - Receive (to pin 10) From Linux you can access the console of the PineCube using the screen command:\nscreen /dev/ttyUSB0 115200\nBasic bandwidth tests with iperf3 Install armbian-config:\napt install armbian-config\nEnable iperf3 through the menu in armbian-config:\narmbian-config\nOn a test computer on the same network segment run iperf3 as a client:\niperf3 -c pinecube -t 60\nThe same test computer, run iperf3 in the reverse direction:\niperf3 -c pinecube -t 60 -R\nBuildroot PineCube is supported in Buildroot since version 2023.11. See the file board/pine64/pinecube/readme.txt in the Buildroot repository for details how to build it.\nThere is also available Buildroot fork by Elimo Engineering, you can find the repository on Elimo’s GitHub account and build instructions in the board support directory readme.\nThe most important thing that this provides is support for the S3’s DDR3 in u-boot. Unfortunately mainline u-boot does not have that yet, but the u-boot patches from Daniel Fullmer’s NixOS repo were easy enough to use on buildroot.\nThis should get you a functional system that boots to a console on UART0. It’s pretty fast too, getting there in 1.5 seconds from u-boot to login prompt.\nSDK Stock Linux:\nDirect Download from pine64.org (MD5 (7zip file): efac108dc98efa0a1f5e77660ba375f8, file size: 3.50GB) Compilation:\nYou can either setup a machine for the build environment, or use a Vagrant virtual machine provided by Elimo Engineering\nCompile on a dedicated machine Recommended system requirements:\nOS: (L)Ubuntu 16.04 CPU: 64-bit based Memory: 8 GB or higher Disk: 15 GB free hard disk space Install required packages:\nsudo apt-get install p7zip-full git make u-boot-tools libxml2-utils bison build-essential gcc-arm-linux-gnueabi g++-arm-linux-gnueabi zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32z1-dev Install older Make 3.82 and Java JDK 6:\npushd /tmp wget https://ftp.gnu.org/gnu/make/make-3.82.tar.gz tar xfv make-3.82.tar.gz cd make-3.82 ./configure make sudo apt purge -y make sudo ./make install cd .. # Please, download jdk-6u45-linux-x64.bin from https://www.oracle.com/java/technologies/javase-java-archive-javase6-downloads.html (requires free login) chmod +x jdk-6u45-linux-x64.bin ./jdk-6u45-linux-x64.bin sudo mkdir /opt/java/ sudo mv jdk1.6.0_45/ /opt/java/ sudo update-alternatives --install /usr/bin/javac javac /opt/java/jdk1.6.0_45/bin/javac 1 sudo update-alternatives --install /usr/bin/java java /opt/java/jdk1.6.0_45/bin/java 1 sudo update-alternatives --install /usr/bin/javaws javaws /opt/java/jdk1.6.0_45/bin/javaws 1 sudo update-alternatives --config javac sudo update-alternatives --config java sudo update-alternatives --config javaws popd PineCubes SPI Flash support patch:\nFrom 9316112c37ee86645fd691c6d3352183b95177d8 Mon Sep 17 00:00:00 2001 From: Marek Kraus \u0026lt;gamelaster@outlook.com\u0026gt; Date: Fri, 8 Jul 2022 21:01:47 +0200 Subject: [PATCH] Add support for xt25f128 SPI Flash --- drivers/mtd/devices/m25p80.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index 31e5795..0f46a4c 100755 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -803,6 +803,7 @@ static const struct spi_device_id m25p_ids[] = { { \u0026#34;w25x64\u0026#34;, INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) }, { \u0026#34;w25q64\u0026#34;, INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) }, { \u0026#34;W25q128\u0026#34;, INFO(0xef4018, 0, 64 * 1024, 256, 0) }, +\t{ \u0026#34;xt25f128\u0026#34;, INFO(0x0b4018, 0, 64 * 1024, 256, SECT_4K) }, /* Catalyst / On Semiconductor -- non-JEDEC */ 7.4 Unpack SDK and then compile and pack the image:\n7z x \u0026#39;PineCube Stock BSP-SDK ver1.0.7z\u0026#39; mv \u0026#39;PineCube Stock BSP-SDK ver1.0\u0026#39; pinecube-sdk cd pinecube-sdk/camdroid # apply SPI Flash patch above or edit m25p80.c file source build/envsetup.sh lunch # select [1] here mklichee extract-bsp make -j3 pack Compile using Vagrant You can avoid setting up your machine and just use Vagrant to spin up a development environment in a VM.\nJust clone the Elimo Engineering repo and follow the instructions in the readme file\nAfter spinning up the VM, you just need to run the build:\ncd pinecube-sdk/camdroid # apply SPI Flash patch above or edit m25p80.c file source build/envsetup.sh lunch # select [1] here mklichee extract-bsp make -j3 pack Flashing the image See PhoenixCard for a manual on how to flash Allwinners BSP images.\nPinout Note: Pin1 is marked on the board by a white dot on the PCB. See the PDF and HTML for details.\nCases Model:\nPineCube (proprietary) 3D file User models:\nQuick and dirty STL conversion (beta) by doodlebro. Prints and fits at 0.25mm layer height. New model with removable front cover and mounting plate with hole for strong magnet and adjustable rotation angle. See README for more details. Available FreeCAD source models, STL, G-code and 3mf data. Also available at printables.com GPIO GPIO header pin table:\nPin Name Physical Pin (Designation) Linux GPIO Alternate Func 1 Alternate Func 2 Interrupt 1 3V3 DCDC3 2 5V PS 3 TWI1_SDA PB9 41 TWI1_SDA UART0_RX PB_EINT9 4 5V PS 5 TWI1_SCK PB8 40 TWI1_SCK UART0_TX PB_EINT8 6 GND GND 7 PWM1 PB5 37 PWM1 PB_EINT5 8 UART_TXD PB0 32 UART2_TXD PB_EINT0 9 GND GND 10 UART_RXD PB1 33 UART2_RX PB_EINT1 11 GPIO17 PC5 69 SDC2_D2 12 GPIO18 PC6 70 SDC2_D3 13 GPIO27 PC7 71 SDC2_D4 14 GND GND 15 GPIO22 PC8 72 SDC2_D5 16 GPIO23 PC9 73 SDC2_D6 17 3V3 DCDC3 18 GPIO24 PC10 74 SDC2_D7 19 SPI-MOSI PC3 67 SPI0_MOSI SDC2_D0 20 GND GND 21 SPI-MISO PC0 64 SPI0_MISO SDC2_CLK 22 PWM0 PB4 36 PWM0 PB_EINT4 23 SPI-CLK PC1 65 SPI0_CLK SDC2_CMD 24 SPI_CE0 PC2 66 SPI0_CS SDC2_RST 25 GND GND 26 SPI_CE1 PC4 68 SDC2_D1 Important notes:\nFirst ball is marked with white dot SPI is multiplexed also with SPI flash SPI_CE1 is normal GPIO pin\u0026quot; Debugging Camera issues can be debugged with the gstreamer pipeline. If the camera does not appear to work, it is possible to change the v4l2src to videotestsrc and the gstreamer pipeline will produce a synthetic test image without using the camera hardware.\nIf the camera is only sensor noise lines over a black or white image, the camera may be in a broken state. When in that state, the following kernel messages were observed:\n[ 1703.577304] alloc_contig_range: [46100, 464f5) PFNs busy [ 1703.578570] alloc_contig_range: [46200, 465f5) PFNs busy [ 1703.596924] alloc_contig_range: [46300, 466f5) PFNs busy [ 1703.598060] alloc_contig_range: [46400, 467f5) PFNs busy [ 1703.600480] alloc_contig_range: [46400, 468f5) PFNs busy [ 1703.601654] alloc_contig_range: [46600, 469f5) PFNs busy [ 1703.619165] alloc_contig_range: [46100, 464f5) PFNs busy [ 1703.619528] alloc_contig_range: [46200, 465f5) PFNs busy [ 1703.619857] alloc_contig_range: [46300, 466f5) PFNs busy [ 1703.641156] alloc_contig_range: [46100, 464f5) PFNs busy Tuning Camera\nSound controls\nCamera Focus The focus of the lens can be manually adjusted through rotation. Note that initially, the lens could be tight.\nLow light mode To get imagery in low-light conditions you can turn on the infrared LED’s to light up the dark area and also enable the IR cut filter using the commands below. Note that these were performed on Armbian using the instructions from here [https://github.com/danielfullmer/pinecube-nixos#enablingdisabling-ir-cut-filter].\n# Run these as root # Turn on the IR LED lights (note that you can see a faint red glow from them when it’s low light) # Turn them off with echo 1 instead (this may be inverted depending on the version of the kernel you have) echo 0 \u0026gt; /sys/class/leds/pine64\\:ir\\:led1/brightness echo 0 \u0026gt; /sys/class/leds/pine64\\:ir\\:led2/brightness # Export gpio, set direction echo 45 \u0026gt; /sys/class/gpio/export echo out \u0026gt; /sys/class/gpio/gpio45/direction # Enable IR cut filter (note that you can hear the switching noise) # Disable with echo 0 instead echo 1 \u0026gt; /sys/class/gpio/gpio45/value Camera controls It is possible to adjust the camera using certain internal camera controls, such as contrast, brightness, saturation and more. These controls can be accessed using the v4l2-ctl tool that is part of the v4l-utils package.\n# List the current values of the controls v4l2-ctl -d /dev/v4l-subdev* --list-ctrls User Controls contrast 0x00980901 (int) : min=0 max=255 step=1 default=0 value=0 flags=slider turation 0x00980902 (int) : min=0 max=255 step=1 default=64 value=64 flags=slider hue 0x00980903 (int) : min=0 max=359 step=1 default=0 value=0 flags=slider utomatic 0x0098090c (bool) : default=1 value=1 flags=update _balance 0x0098090e (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider _balance 0x0098090f (int) : min=0 max=4095 step=1 default=0 value=0 flags=inactive, slider exposure 0x00980911 (int) : min=0 max=65535 step=1 default=0 value=4 flags=inactive, volatile utomatic 0x00980912 (bool) : default=1 value=1 flags=update gain 0x00980913 (int) : min=0 max=1023 step=1 default=0 value=20 flags=inactive, volatile tal_flip 0x00980914 (bool) : default=0 value=0 cal_flip 0x00980915 (bool) : default=0 value=0 requency 0x00980918 (menu) : min=0 max=3 default=1 value=1 Camera Controls auto_exposure 0x009a0901 (menu) : min=0 max=1 default=0 value=0 flags=update Image Processing Controls pixel_rate 0x009f0902 (int64) : min=0 max=2147483647 step=1 default=61430400 value=21001200 flags=read-only st_pattern 0x009f0903 (menu) : min=0 max=4 default=0 value=0 # Set the contrast controls to the maximum value v4l2-ctl -d /dev/v4l-subdev* --set-ctrl contrast=255 You can see which flags can be changed and which ones cannot by looking at the flags. The inactive flag indicates that it is currently disabled. Some of these flags are disabled when other flags are turned on. For example, the gain flag above is inactive because gain_automatic is enabled with a value of \u0026ldquo;1\u0026rdquo;.\nNote At the current time the auto_exposure flag is inverted, so a value of \u0026ldquo;0\u0026rdquo; means on, while \u0026ldquo;1\u0026rdquo; means off. Maybe the auto_exposure flag will get changed someday. You’ll need to turn off auto_exposure (value=1) if you want to manually set the exposure flag. Sound controls Note that sound is only currently available with special patches on top of a 5.13.13 or higher kernel with Armbian or NixOS. Once you have a kernel that supports sound you can install alsa-utils to get the alsamixer tool. The following mixer settings have been found to work with both playback and record. Note that you’ll need to press F5 to get the capture controls and space bar to turn on/off capture for a device. The speaker dangles on a wire from the device. The microphone is located about 1cm below the lens on the front facing circuit board.\nProjects The following projects are documented here:\nStreaming the camera to the network Security camera with Motion WiFi access point Webcam Recorder for loud noises Further projects:\nOpenWrt from juansef - GitHub, Pine64 Forum thread Recorder for loud noises The PineCube can be used as a recorder for loud noises. If you have a kernel that has the sound support (see the Sound Control section) then you can use it to make recordings when there is a noise above a certain threshold. The following script is a very simple example that uses the alsa-utils and the sox command to do this. You can use the noise-stats.txt file and some noise testing to figure out a good threshold for your camera.\n#!/bin/bash # Directory where the sound recordings should go NOISE_FILE_DIR=\u0026#34;/root/noises\u0026#34; # Threshold to use with the mean delta to decide to preserve the recording MEAN_DELTA_THRESHOLD=\u0026#34;0.002\u0026#34; # Sample length (in seconds) SAMPLE_LENGTH=\u0026#34;10\u0026#34; while : do stats=$(arecord -d \u0026#34;$SAMPLE_LENGTH\u0026#34; -f S16_LE \u0026gt; /tmp/sample.wav 2\u0026gt;/dev/null \u0026amp;\u0026amp; sox -t .wav /tmp/sample.wav -n stat 2\u0026gt;\u0026amp;1 | grep \u0026#39;Mean delta:\u0026#39; | cut -d: -f2 | sed \u0026#39;s/^[ ]*//\u0026#39;) ts=$(date +%s) if (( $(echo \u0026#34;$stats \u0026gt; $MEAN_DELTA_THRESHOLD\u0026#34; | bc -l) )); then mv /tmp/sample.wav \u0026#34;$NOISE_FILE_DIR/noise-$ts.wav\u0026#34; # TODO convert to mp3 fi rm -f /tmp/sample.wav echo \u0026#34;$ts $stats\u0026#34; \u0026gt;\u0026gt; noise-stats.txt done Security camera with Motion It’s possible to use the PineCube as an inside or outside security camera using motion. For outside, you’ll need an enclosure with a transparent dome to protect from the weather. One suggestion is to mount the camera with the lens as close as possible to the dome to avoid reflection.\nThe Motion package can be installed in a variety of Linux flavors. There’s a package in the standard Ubuntu and Debian repositories and works with Armbian. It provides a very simple web interface for live viewing of the camera feed and also has motion trigger capabilities to store either still pictures or in later versions videos. Note that it is also possible to build hooks to automatically process or upload those recordings.\nTo get things working quickly with motion you can set the following in the /etc/motion/motion.conf and start it with \u0026ldquo;sudo /etc/init.d/motion start\u0026rdquo;\nv4l2_palette 14 # UYVY8 width 640 height 480 framerate 15 This mode and resolution works fine with Motion and works well with video motion capture (Motion version \u0026gt;= 4.2.2). However, if you want different modes and resolutions you’ll need to set the camera to those modes with the media-ctl tool that comes with the v4l-utils package. That will need to be set before the motion service starts. A simple method to ensure that it gets set before motion starts every time, even across reboots, is to make a small modification to the /lib/systemd/system/motion.service\n[Service] Type=simple User=motion ExecStartPre=/usr/bin/media-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:UYVY8_2X8/1280x720@1/15]\u0026#39; # \u0026lt;=- Add this line here with the mode that the camera will use ExecStart=/usr/bin/motion Note that you must modify /etc/motion/motion.conf to match the v4l2_palette, width, height and framerate to match the mode you set with media-ctl. See the Motion documentation to match the v4l2_palette to the mode. Here are a list of modes that have been tried so far.\nUYVY8_2X8/640x480@1/30 UYVY8_2X8/640x480@1/15 UYVY8_2X8/1280x720@1/15 # This one seems to be fine for live viewing, but causes performance problems when using Motion to capture videos JPEG_1X8/1280x720@1/15 Streaming the camera to the network In this section we document a variety of ways to stream video to the network from the PineCube. Unless specified otherwise, all of these examples have been tested on Ubuntu groovy (20.10). See this small project for the PineCube for easy to use programs tuned for the PineCube.\nIn the examples which use h264, we are currently encoding using the x264 library which is not very fast on this CPU. The SoC in the PineCube does have a hardware h264 encoder, which the authors of these examples have so far not tried to use. It appears that https://github.com/gtalusan/gst-plugin-cedar might provide easy access to it, however. Please update this wiki if you find out how to use the hardware encoder!\ngstreamer: h264 HLS HLS (HTTP Live Streaming) has the advantage that it is easy to play in any modern web browser, including Android and iPhone devices, and that it is easy to put an HTTP caching proxy in front of it to scale to many viewers. It has the disadvantages of adding (at minimum) several seconds of latency, and of requiring an h264 encoder (which we have in hardware, but haven’t figured out how to use yet, so, we’re stuck with the slow software one).\nHLS segments a video stream into small chunks which are stored as .ts (MPEG Transport Stream) files, and (re)writes a playlist.m3u8 file which clients constantly refresh to discover which .ts files they should download. We use a tmpfs file system to avoid needing to write these files to the microSD card in the PineCube. Besides the program which writes the .ts and .m3u8 files (gst-launch-1.0, in our case), we’ll also need a very basic web page in tmpfs and a webserver to serve the files.\nCreate an hls directory to be shared in the existing tmpfs file system that is mounted at /dev/shm:\nmkdir /dev/shm/hls/\nCreate an index.html and optionally a favicon.ico or even a set of icons, and then put the files into the /dev/shm/hls directory. An example index.html that works is available in the Getting Started section of the README for hls.js. We recommend downloading the hls.js file and editing the example index.html to serve your local copy of it instead of fetching it from a CDN. This file provides HLS playback capabilities in browsers which don’t natively support it (which is most browsers aside from the iPhone).\nIn one terminal, run the camera capture pipeline:\ncd /dev/shm/hls/ \u0026amp;\u0026amp; media-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:UYVY8_2X8/240x320@1/15]\u0026#39; \u0026amp;\u0026amp; gst-launch-1.0 v4l2src ! video/x-raw,width=320,height=240,format=UYVY,framerate=15/1 ! decodebin ! videoconvert ! video/x-raw,format=I420 ! clockoverlay ! timeoverlay valignment=bottom ! x264enc speed-preset=ultrafast tune=zerolatency ! mpegtsmux ! hlssink target-duration=1 playlist-length=2 max-files=3 Alternatively it is possible to capture at a higher resolution:\nmedia-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:UYVY8_2X8/1920x1080@1/15]\u0026#39; cd /dev/shm/hls/ \u0026amp;\u0026amp; gst-launch-1.0 v4l2src ! video/x-raw,width=1920,height=1080,format=UYVY,framerate=15/1 ! decodebin ! videoconvert ! video/x-raw,format=I420 ! clockoverlay ! timeoverlay valignment=bottom ! x264enc speed-preset=ultrafast tune=zerolatency ! mpegtsmux ! hlssink target-duration=1 playlist-length=2 max-files=3 In another, run a simple single threaded webserver which will serve html, javascript, and HLS to web clients:\ncd /dev/shm/hls/ \u0026amp;\u0026amp; python3 -m http.server Alternately, install a more efficient web server (apt install nginx) and set the server root for the default configuration to be /dev/shm/hls. This will run on port 80 rather than the python3 server which defaults to port 8000.\nIt should be possible to view the HLS stream directly in a web browser by visiting http://pinecube:8000/ if pinecube is the correct hostname and the name correctly resolves.\nYou can also view the HLS stream with VLC: vlc http://pinecube:8000/playlist.m3u8\nOr with gst-play-1.0: gst-play-1.0 http://pinecube:8000/playlist.m3u8 (or with mpv, ffplay, etc)\nTo find out about other options you can configure in the hlssink gstreamer element, you can run gst-inspect-1.0 hlssink.\nIt is worth noting here that the hlssink element in GStreamer is not widely used in production environments. It is handy for testing, but for real-world free-software HLS live streaming deployments the standard tool today (January 2021) is nginx’s RTMP module which can be used with ffmpeg to produce \u0026ldquo;adaptive streams\u0026rdquo; which are re-encoded at varying quality levels. You can send data to an nginx-rtmp server from a gstreamer pipeline using the rtmpsink element. It is also worth noting that gstreamer has a new hlssink2 element which we have not tested; perhaps in the future it will even have a webserver!\nv4l2rtspserver: h264 RTSP Install dependencies:\napt install -y cmake gstreamer1.0-plugins-bad gstreamer1.0-tools \\ gstreamer1.0-plugins-good v4l-utils gstreamer1.0-alsa alsa-utils libpango1.0-0 \\ libpango1.0-dev gstreamer1.0-plugins-base gstreamer1.0-x x264 \\ gstreamer1.0-plugins-{good,bad,ugly} liblivemedia-dev liblog4cpp5-dev \\ libasound2-dev vlc libssl-dev iotop libasound2-dev liblog4cpp5-dev \\ liblivemedia-dev autoconf automake libtool v4l2loopback-dkms liblog4cpp5-dev \\ libvpx-dev libx264-dev libjpeg-dev libx265-dev linux-headers-dev-sunxi; Install kernel source and build v4l2loopback module:\napt install linux-source-5.11.3-dev-sunxi64 #Adjust kernel version number to match current installation with \u0026#34;uname -r\u0026#34; cd /usr/src/v4l2loopback-0.12.3; make \u0026amp;\u0026amp; make install \u0026amp;\u0026amp; depmod -a Build required v4l2 software:\ngit clone --recursive https://github.com/mpromonet/v4l2tools \u0026amp;\u0026amp; cd v4l2tools \u0026amp;\u0026amp; make \u0026amp;\u0026amp; make install; git clone --recursive https://github.com/mpromonet/v4l2rtspserver \u0026amp;\u0026amp; cd v4l2rtspserver \u0026amp;\u0026amp; cmake -D LIVE555URL=https://download.videolan.org/pub/contrib/live555/live.2020.08.19.tar.gz . \u0026amp;\u0026amp; make \u0026amp;\u0026amp; make install; Running the camera:\nmedia-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:UYVY8_2X8/640x480@1/30]\u0026#39;; modprobe v4l2loopback video_nr=10 debug=2; v4l2compress -fH264 -w -vv /dev/video0 /dev/video10 \u0026amp; v4l2rtspserver -v -S -W 640 -H 480 -F 10 -b /usr/local/share/v4l2rtspserver/ /dev/video10 Note that you might get an error when running media-ctl indicating that the resource is busy. This could be because of the motion program that runs on the stock OS installation. Check and terminate any running /usr/bin/motion processes before running the above steps.\nThe v4l2compress/v4l2rtspserver method of streaming the camera uses around ~45-50% of the CPU for compression of the stream into H264 (640x480@7fps) and around 1-2% of the CPU for serving the HLS stream. Total system RAM used is roughly 64MB and the load average is ~0.4-~0.5 when idle, and ~0.51-~0.60 with one HLS client streaming the camera.\nYou’ll probably see about a 2-3s lag with this approach, possibly due to the H264 compression and the lack of hardware acceleration at the moment.\ngstreamer: JPEG RTSP GStreamer’s RTSP server isn’t an element you can use with gst-launch, but rather a library. We failed to build its example program, so instead used this very small 3rd party tool which is based on it: https://github.com/sfalexrog/gst-rtsp-launch/\nAfter building gst-rtsp-launch (which is relatively simple on Ubuntu groovy; just apt install libgstreamer1.0-dev libgstrtspserver-1.0-dev first), you can read JPEG data directly from the camera and stream it via RTSP: media-ctl --set-v4l2 '\u0026quot;ov5640 1-003c\u0026quot;:0[fmt:JPEG_1X8/1280x720]' \u0026amp;\u0026amp; gst-rtsp-launch 'v4l2src ! image/jpeg,width=1280,height=720 ! rtpjpegpay name=pay0'\nThis stream can be played using vlc rtsp://pinecube.local:8554/video or mpv, ffmpeg, gst-play-1.0, etc. If you increase the resolution to 1920x1080, mpv and gst-play can still play it, but VLC will complain The total received frame size exceeds the client’s buffer size (2000000). 73602 bytes of trailing data will be dropped! if you don’t tell it to increase its buffer size with --rtsp-frame-buffer-size=300000\ngstreamer: h264 RTSP Left as an exercise to the reader (please update the wiki). Hint: involves bits from the HLS and the JPEG RTSP examples above, but needs a rtph264pay name=pay0 element.\ngstreamer: JPEG RTP UDP Configure camera: media-ctl --set-v4l2 '\u0026quot;ov5640 1-003c\u0026quot;:0[fmt:JPEG_1X8/1920x1080]'\nTransmit with: gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! rtpjpegpay name=pay0 ! udpsink host=$client_ip port=8000\nReceive with: gst-launch-1.0 udpsrc port=8000 ! application/x-rtp, encoding-name=JPEG,payload=26 ! rtpjpegdepay ! jpegdec ! autovideosink\nNote that the sender must specify the recipient’s IP address in place of $client_ip; this can actually be a multicast address allowing for many receivers! (You’ll need to specify a valid multicast address in the receivers\u0026rsquo; pipeline also; see gst-inspect-1.0 udpsrc and gst-inspect-1.0 udpsink for details.)\ngstreamer: JPEG RTP TCP Configure camera: media-ctl --set-v4l2 '\u0026quot;ov5640 1-003c\u0026quot;:0[fmt:JPEG_1X8/1920x1080]'\nTransmit with: gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! rtpjpegpay name=pay0 ! rtpstreampay ! tcpserversink host=0.0.0.0 port=1234\nReceive with: gst-launch-1.0 tcpclientsrc host=pinecube.local port=1234 ! application/x-rtp-stream,encoding-name=JPEG ! rtpstreamdepay ! application/x-rtp, media=video, encoding-name=JPEG ! rtpjpegdepay ! jpegdec ! autovideosink\ngstreamer and socat: MJPEG HTTP server This rather ridiculous method uses bash, socat, and gstreamer to implement an HTTP-ish server which will serve your video as an MJPEG stream which is playable in browsers.\nThis approach has the advantage of being relatively low latency (under a second), browser-compatible, and not needing to reencode anything on the CPU (it gets JPEG data from the camera itself). Compared to HLS, it has the disadvantages that MJPEG requires more bandwidth than h264 for similar quality, pause and seek are not possible, stalled connections cannot jump ahead when they are unstalled, and, in the case of this primitive implementation, it only supports one viewer at a time (Though the RTSP examples on this page perform very poorly with multiple viewers).\nGstreamer can almost do this by itself, as it has a multipartmux element which produces the headers which precede each frame. But sadly, despite various forum posts lamenting the lack of one over the last 12+ years, as of the end of the 50th year of the UNIX era (aka 2020), somehow nobody has yet gotten a webserver element merged in to gstreamer (which is necessary to produce the HTTP response, which is required for browsers other than firefox to play it). So, here is an absolutely minimal \u0026ldquo;webserver\u0026rdquo; which will get MJPEG displaying in a (single) browser.\nCreate a file called mjpeg-response.sh:\n#! /bin/bash media-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:JPEG_1X8/1920x1080]\u0026#39; b=\u0026#34;--duct_tape_boundary\u0026#34; echo -en \u0026#34;HTTP/1.1 200 OK\\r\\nContent-type: multipart/x-mixed-replace;boundary=$b\\r\\n\\r\\n\u0026#34; gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! multipartmux boundary=$b ! fdsink fd=2 2\u0026gt;\u0026amp;1 \u0026gt;/dev/null Make it executable: chmod +x mjpeg-response.sh\nRun the server: socat TCP-LISTEN:8080,reuseaddr,fork EXEC:./mjpeg-response.sh\nAnd browse to http://pinecube.local:8080/ in your browser.\nvirtual web camera: gstreamer, mjpeg, udp rtp unicast It’s possible to set up the PineCube as a virtual camera video device (Video 4 Linux) so that you can use it with video conferencing software, such as Jitsi Meet. Note that this has fairly minimal (\u0026lt;1s) lag when tested on a wired 1Gb Ethernet network connection and the frame rate is passable. MJPEG is very wasteful in terms of network resources, so this is something to keep in mind. The following instructions assume Debian Linux (Bullseye) as your desktop machine, but could work with other Linux distributions too. It’s possible that someday a similar system could work with Mac OS X provided that someone writes a gstreamer plugin that exposes a Mac OS Core Media DAL device as a virtual webcam, like they did here for OBS.\nFirst, you will need to set up the pinecube with gstreamer much like the above gstreamer, but in 1280x720 resolution. Also, you will be streaming to the desktop machine using UDP, with IP address represented by $desktop below at UDP port 8000.\nmedia-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:JPEG_1X8/1280x720]\u0026#39; gst-launch-1.0 v4l2src device=/dev/video0 ! image/jpeg,width=1280,height=720,framerate=30/1 ! rtpjpegpay name=pay0 ! udpsink host=$desktop port=8000 On your desktop machine, you will need to install the gstreamer suite and the special v4l2loopback kernel module to bring the mjpeg stream to the Video 4 Linux device /dev/video10.\nsudo apt install gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly v4l2loopback-dkms sudo modprobe v4l2loopback video_nr=10 max_buffers=32 exclusive_caps=1 # Creates /dev/video10 as a virtual v4l2 device, allocates increased buffers and exposes exclusive capabilities for chromium to find the video device gst-launch-1.0 udpsrc port=8000 ! application/x-rtp, encoding-name=JPEG,payload=26,framerate=30/1 ! rtpjpegdepay ! jpegdec ! video/x-raw, format=I420, width=1280, height=720 ! autovideoconvert ! v4l2sink device=/dev/video10 The most common error found when launching the gstreamer pipeline above is the following error message, which seems to happen when the max_buffers aren’t set on the v4l2loopback module (see above), or if there is a v4l client (vlc, chromium) already connected to /dev/video10 when starting the pipeline. There does seem to be a small level of instability in this stack that could be improved.\ngstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: streaming stopped, reason not-negotiated (-4) Now that you have /dev/video10 hooked into the gstreamer pipeline you can then connect to it using VLC. VLC is a good local test that things are working. You can view the stream like this. Note that you could do the same thing with mpv/ffmpeg, but there are problems currently.\nvlc v4l2:///dev/video10 Be sure to disconnect VLC before trying to use the virtual web camera with chromium. Launch chromium and go to a web conference like jitsi. When it prompts you for the camera pick the \u0026ldquo;Dummy Video Device\u0026hellip;\u0026rdquo; and it should be much like what you see in VLC. Note that Firefox isn’t really working at this moment and the symptoms appear very similar to the problem with mpv/ffmpeg mentioned above, ie. when they connect to the camera they show only the first frame and then drop. It’s unclear whether the bug is in gstreamer, v4l, or ffmpeg (or somewhere in these instructions).\nWebcam The PineCube can be powered by the host and communicate as a peripheral. First, you’ll need to a dual USB-A (male) cable to plug it into your computer. Note that the Micro-USB port can be used only for power because the data lines are not connected.\nUSB as an Ethernet gadget Goal: To achieve fast (low latency) wired network connection via USB-A port of PineCube. PineCube will be shown as a network device when connected to a computer via USB-A port. You can set up the computer to be in the same network as PineCube and connect to PineCube via SSH and/or Stream Videos from it.\nAdditional patch to PineCube device tree disable ehci0 and ohci0, enabling usb_otg device instead and setting dr_mode to otg. If otg is not working for you, try setting dr_mode to peripheral. On Armbian there is no need for disabling ehci0 and ohci0. Device tree can be edited via armbian-config tool on Armbian OS (armbian-config -\u0026gt; System -\u0026gt; DTC). Example DTC on Armbian: usb@1c19000 { compatible = \u0026#34;allwinner,sun8i-h3-musb\u0026#34;; reg = \u0026lt;0x1c19000 0x400\u0026gt;; clocks = \u0026lt;0x03 0x1d\u0026gt;; resets = \u0026lt;0x03 0x11\u0026gt;; interrupts = \u0026lt;0x00 0x47 0x04\u0026gt;; interrupt-names = \u0026#34;mc\u0026#34;; phys = \u0026lt;0x0e 0x00\u0026gt;; phy-names = \u0026#34;usb\u0026#34;; extcon = \u0026lt;0x0e 0x00\u0026gt;; status = \u0026#34;okay\u0026#34;; dr_mode = \u0026#34;otg\u0026#34;; phandle = \u0026lt;0x2c\u0026gt;; }; Load necessary kernel modules. You can skip this step if you use Armbian OS because necessary modules are already loaded by default (Detailed instructions for sunxi and Ethernet gadget: https://linux-sunxi.org/USB_Gadget/Ethernet)\nmodprobe sunxi modprobe configfs modprobe libcomposite modprobe u_ether modprobe usb_f_rndis Add sunxi and g_ether to /etc/modules to get them to load on startup. /etc/modules:\nsunxi g_ether Configure the g_ether device to start with a stable MAC address. /etc/modprobe.d/g_ether.conf:\noptions g_ether host_addr=f6:11:fd:ed:ec:6e Set a static IP address for usb0 on startup with network manager\n/etc/network/interfaces: auto usb0 iface usb0 inet static address 192.168.10.2 netmask 255.255.255.0 Boot the PineCube plugging it into a computer\nConfigure the USB Ethernet device on the computer to be in the same subnet as the PineCube. Example setting:\nnetwork setting: Manual address: 192.168.10.5 netmask: 255.255.255.0 gateway: 192.168.10.2 Done. You can use above methods to stream video through this USB Ethernet connection. Bandwidth and response time is much faster compared to usual network methods.\nUSB as a Webcam (UVC) gadget Note This is work in progress. Goal: Make PineCube behave almost as same as like normal Webcam. When you connect PineCube to a computer it will be shown as a webcam device. No need for an additional set up you can use it straight after plugging the PineCube to a computer. USB-A port is for data transfer between PineCube and computer/phone. Micro-USB port is for power.\nAction Plan (by Newton688):\nAttempt to load the uvc_gadget (usb_f_uvc) or g_webcam Look at this project to see if it can bridge UVC gadget output with the v4l from the OV5650 camera sensor: https://github.com/wlhe/uvc-gadget Progress report so far (by Disctanger):\nConfigfs method is going to be used to control OTG port.\nAdditional patch to PineCube device tree disable ehci0 and ohci0, enabling usb_otg device instead and setting dr_mode to otg. If otg is not working for you, try setting dr_mode to peripheral. On Armbian there is no need for disabling ehci0 and ohci0. Device tree can be edited via armbian-config tool on Armbian OS. (armbian-config -\u0026gt; System -\u0026gt; DTC). Example DTC on Armbian:\nusb@1c19000 { compatible = \u0026#34;allwinner,sun8i-h3-musb\u0026#34;; reg = \u0026lt;0x1c19000 0x400\u0026gt;; clocks = \u0026lt;0x03 0x1d\u0026gt;; resets = \u0026lt;0x03 0x11\u0026gt;; interrupts = \u0026lt;0x00 0x47 0x04\u0026gt;; interrupt-names = \u0026#34;mc\u0026#34;; phys = \u0026lt;0x0e 0x00\u0026gt;; phy-names = \u0026#34;usb\u0026#34;; extcon = \u0026lt;0x0e 0x00\u0026gt;; status = \u0026#34;okay\u0026#34;; dr_mode = \u0026#34;otg\u0026#34;; phandle = \u0026lt;0x2c\u0026gt;; }; Load necessary kernel modules:\nmodprobe sunxi modprobe configfs modprobe libcomposite Set up camera so that it would capture images in YUYV format (Currently only supported format in UVC gadget). You can adjust resolutions but have to adjust Configfs set up step as well.\nmedia-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:YUYV8_2X8/640x480@1/30]\u0026#39; Clone UVC gadget repo for raspberry pi to your PineCube\ngit clone https://github.com/peterbay/uvc-gadget.git cd uvc_gadget Comment out 1182~1185 lines of uvc-gadget.c file:\n// if (! uvc_shutdown_requested \u0026amp;\u0026amp; ((uvc_dev.dqbuf_count + 1) \u0026gt;= uvc_dev.qbuf_count)) { // return; // } Build the source code inside PineCube using make command. It takes only few seconds to build the code.\nmake gcc -W -Wall -g -c -o uvc-gadget.o uvc-gadget.c gcc -g -o uvc-gadget uvc-gadget.o Set up configfs (multi-gadget). You can have the following script as a bash script as well.\nGADGET_PATH=/sys/kernel/config/usb_gadget/pinecube mkdir $GADGET_PATH echo 0x1d6b \u0026gt; $GADGET_PATH/idVendor echo 0x0104 \u0026gt; $GADGET_PATH/idProduct echo 0x0100 \u0026gt; $GADGET_PATH/bcdDevice echo 0x0200 \u0026gt; $GADGET_PATH/bcdUSB echo 0xEF \u0026gt; $GADGET_PATH/bDeviceClass echo 0x02 \u0026gt; $GADGET_PATH/bDeviceSubClass echo 0x01 \u0026gt; $GADGET_PATH/bDeviceProtocol mkdir $GADGET_PATH/strings/0x409 echo 100000000d2386db \u0026gt; $GADGET_PATH/strings/0x409/serialnumber echo \u0026#34;Pine64\u0026#34; \u0026gt; $GADGET_PATH/strings/0x409/manufacturer echo \u0026#34;PineCube Webcam\u0026#34; \u0026gt; $GADGET_PATH/strings/0x409/product mkdir $GADGET_PATH/configs/c.1 mkdir $GADGET_PATH/configs/c.1/strings/0x409 echo 500 \u0026gt; $GADGET_PATH/configs/c.1/MaxPower echo \u0026#34;UVC\u0026#34; \u0026gt; $GADGET_PATH/configs/c.1/strings/0x409/configuration mkdir $GADGET_PATH/functions/uvc.usb0 mkdir $GADGET_PATH/functions/acm.usb0 echo 512 \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming_maxpacket # cat \u0026lt;\u0026lt;EOF $GADGET_PATH/functions/uvc.usb0/control/processing/default/bmControls # 0 # 0 # EOF mkdir -p $GADGET_PATH/functions/uvc.usb0/control/header/h ln -s $GADGET_PATH/functions/uvc.usb0/control/header/h $GADGET_PATH/functions/uvc.usb0/control/class/fs/h # ln -s $GADGET_PATH/functions/uvc.usb0/control/header/h $GADGET_PATH/functions/uvc.usb0/control/class/hs/h # ln -s $GADGET_PATH/functions/uvc.usb0/control/header/h $GADGET_PATH/functions/uvc.usb0/control/class/ss/h config_frame () { FORMAT=$1 NAME=$2 WIDTH=$3 HEIGHT=$4 framedir=$GADGET_PATH/functions/uvc.usb0/streaming/$FORMAT/$NAME/${HEIGHT}p mkdir -p $framedir echo $WIDTH \u0026gt; $framedir/wWidth echo $HEIGHT \u0026gt; $framedir/wHeight echo 333333 \u0026gt; $framedir/dwDefaultFrameInterval echo $(($WIDTH * $HEIGHT * 80)) \u0026gt; $framedir/dwMinBitRate echo $(($WIDTH * $HEIGHT * 160)) \u0026gt; $framedir/dwMaxBitRate echo $(($WIDTH * $HEIGHT * 2)) \u0026gt; $framedir/dwMaxVideoFrameBufferSize cat \u0026lt;\u0026lt;EOF \u0026gt; $framedir/dwFrameInterval 333333 400000 666666 EOF } config_frame mjpeg m 640 360 config_frame mjpeg m 640 480 config_frame mjpeg m 800 600 config_frame mjpeg m 1024 768 config_frame mjpeg m 1280 720 config_frame mjpeg m 1280 960 config_frame mjpeg m 1440 1080 config_frame mjpeg m 1536 864 config_frame mjpeg m 1600 900 config_frame mjpeg m 1600 1200 config_frame mjpeg m 1920 1080 SMALL_WIDTH=480p mkdir -p $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH echo 640 \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/wWidth echo 480 \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/wHeight echo 333333 \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwDefaultFrameInterval echo $((640 * 480 * 80)) \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMinBitRate echo $((640 * 480 * 160)) \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMaxBitRate echo $((640 * 480 * 2)) \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMaxVideoFrameBufferSize cat \u0026lt;\u0026lt;EOF \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwFrameInterval 333333 400000 666666 EOF mkdir $GADGET_PATH/functions/uvc.usb0/streaming/header/h cd $GADGET_PATH/functions/uvc.usb0/streaming/header/h # ln -s ../../mjpeg/m ln -s ../../uncompressed/u cd ../../class/fs ln -s ../../header/h cd ../../class/hs ln -s ../../header/h cd ../../../../.. ln -s $GADGET_PATH/functions/uvc.usb0 $GADGET_PATH/configs/c.1/uvc.usb0 ln -s $GADGET_PATH/functions/acm.usb0 $GADGET_PATH/configs/c.1/acm.usb0 udevadm settle -t 5 ! : ls /sys/class/udc \u0026gt; $GADGET_PATH/UDC If above script goes without issues you should be able to see one more additional /dev/video* device.\nrun uvc-gadget. UVC Gadget software links camera of PineCube and UVC gadget (OTG port). \u0026ldquo;-v\u0026rdquo; is for video input device - PineCube Camera, \u0026ldquo;-u\u0026rdquo; is for output video device UVC device or OTG port, -x shows FPS.\n./uvc-gadget -u /dev/video1 -v /dev/video0 -x Plug the PineCube to your laptop or pc and check if you can see PineCube Webcam.\nKnown issues Low Frame rate(3FPS~5FPS). That is because:\nAt the time of writing this section, streaming_maxpacket value cannot be set to max value (2048 bytes.) It can be set only to 512 bytes. If streaming_maxpacket is set to max (2048) value, UDC cannot be turned on with Invalid Value error. YUYV (uncompressed) file format is being used to stream the images. Uncompressed images take a lot of USB bandwidth compared to compressed. We can stream more frames, if MJPEG or even H254 (compressed images) would be used. I will be investigating further on how to stream more frames through USB port. WiFi AP If the PineCube will have a wired Ethernet connection to the main network it is possible to use it as a WiFi access point, possibly extending your existing network to further outside. Here are some steps you can take to do this starting from an Armbian system as a starting point. Note that you may need to upgrade your kernel to 5.13.x for this to work well.\nInstall bridge-utils package using apt-get\nAdd the following to your /etc/network/interfaces to set up both the eth0 Ethernet interface and the br0 bridge interface (change br0 to manual if static IP is preferred)\n/etc/network/interfaces: auto eth0 iface eth0 inet manual pre-up /sbin/ifconfig $IFACE up pre-down /sbin/ifconfig $IFACE down auto br0 iface br0 inet dhcp bridge_ports eth0 bridge_stp on Edit the /etc/default/hostapd uncommenting the line with \u0026lsquo;DAEMON_CONF=\u0026quot;/etc/hostapd.conf\u0026quot;\u0026rsquo;\nEdit the /etc/hostapd.conf to set the SSID, password and channel for your AP.\nRun sudo systemctl enable hostapd.service to enable the hostapd service on startup\nReboot your cube with the ethernet cable connected\nFurther information Specifications\nDatasheets\nSchematics and certifications\nSpecifications Dimensions: 55mm x 51mm x 51.5mm Weight: 55g Storage: MicroSD slot, bootable 128Mb SPI Nor Flash, bootable Cameras: OV5640, 5Mpx CPU: Allwinner (Sochip) ARM Cortex-A7 MPCore, 800MHz RAM: 128MB DDR3 I/O: 10/100 Mbps Ethernet with passive PoE (4-18V!) USB 2.0 A host 26 pins GPIO port 2x 3.3V Ouptut 2x 5V Output 1x I2C 2x UART (3.3V) 2x PWM 1x SPI 1x eMMC/SDIO/SD (8-bit) 6x Interrupts Note: Interfaces are multiplexed, so they can’t be all used at same time Internal microphone Network: WiFi Screen: optional 4.5\u0026quot; RGB LCD screen ( RB043H40T03A-IPS or DFC-XS4300240 V01 ) Misc. features: Volume and home buttons Speakers and Microphone IR LEDs for night vision Passive infrared sensor Power DC in: 5V 1A from MicroUSB Port or GPIO port 4V-18V from Ethernet passive PoE Battery: optional 950-1600mAh model: 903048 Lithium Polymer Ion Battery Pack, can be purchase at Amazon.com Datasheets Allwinner (Sochip) S3 SoC information:\nSochip S3 SoC Data Sheet V1.1 X-Powers AXP209 PMU (Power Management Unit) information:\nAXP209 PMIC datasheet CMOS camera module information:\nPineCube Camera Module Specification OV5640 5MP CMOS Image Sensor SoC datasheet LCD touch screen panel information:\nLithium battery information:\nWiFi/BT module information:\nRTL8189ES specification Schematics and certifications PineCube mainboard schematic:\nPineCube mainboard Released Schematic ver 1.0 PineCube faceboard schematic:\nPineCube faceboard Released Schematic ver 1.0 PineCube certifications:\nPineCube FCC Certificate PineCube CE RED Certificate PineCube ROHS Test Report ","permalink":"/documentation/PineCube/_full/","tags":null,"title":"PineCube (Single Page)"},{"categories":[""],"contents":" The Pinedio The Pinedio is a device utilizing LoRa. LoRa is a long range, low power wireless platform that is being used by a lot of Internet of Things (IoT) products. Using LoRa and LoRaWAN, devices can communicate across the world using the internet, using various decentralised networks such as The Things Network or Helium. Since, PINE64 believes in openness, the LoRa gateway can connect to any network, per the developer implementation. If Helium Spots open up for PINE64 gateway and developers have implemented the hook for Helium, then this is good thing. The PINE64 LoRa gateway also open connect to The Things Network if developers implement support. The choice is yours!\nStores Global Affiliates Documentation Pinedio Datasheets and schematics ","permalink":"/devices/pinedio/","tags":null,"title":"Pinedio"},{"categories":null,"contents":" The Pinedio is a device utilizing LoRa. LoRa is a long range, low power wireless platform that is being used by a lot of Internet of Things (IoT) products. Using LoRa and LoRaWAN, devices can communicate across the world using the internet, using various decentralized networks such as The Things Network or Helium. Since, PINE64 believes in openness, the LoRa gateway can connect to any network, per the developer implementation. If Helium Spots open up for PINE64 gateway and developers have implemented the hook for Helium, then this is good thing. The PINE64 LoRa gateway also open connect to The Things Network if developers implement support. The choice is yours!\nGateway The gateway will be available in two variants - indoor and outdoor. All that is known about the outdoor unit is that it will have \u0026ldquo;an aluminum, rugged and water resistant case\u0026rdquo;. The indoor unit consists of a PINE A64-LTS, fitted with a purpose built hat (adapter) which uses a LoRa module by RakWireless. The chipset used is the SX1303, and the module via the SPI interface. There are two external connections on the enclosure for the GPS and loRa antenna.\nConnections GPS is connected to UART2 on the A64 board SX1303 on SPI0 RAK5146 module PI-2 connector PINE A64-LTS SX1303 SPI Pin 19 = MOSI / PC0\nPin 21 = MISO/PC1\nPin23 = CLK/PC2\nPin24 = CS/PC3 SPI0 (/dev/spidev0.0) SX1303 RESET Pin 11 = GPIO17/PC7 GPIO71 (/sys/class/gpio/gpio71) GPS UART Pin 8 = TX/\nPin 10 = RX UART2 (/dev/ttyS2) GPS RESET Pin 33 = GPIO13/PC5 GPIO69 (/sys/class/gpio/gpio69) GPS Standby Pin 35 = GPIO19/PC9 GPIO73 (/sys/class/gpio/gpio73) Pictures Operating systems The Pinedio Gateway carries the A64-LTS board. The SOPINE releases are also compatible based on the RAM specifications.\nUSB adapter The PINE64 USB LoRa adapter\nThe PINE64 USB LoRa adapter is based on the Semtech SX1262 LoRa module and the CH341 USB bus converter chip. The CH341 chip can be configured in multiple mode to convert USB to various serial and parallel ports. In this case, it’s configured in synchronous serial mode, which allows this chip to convert from USB to the SPI bus needed to talk to the SX1262 LoRa module:\n-------- -------------------------- | | | USB LoRa Adapter | | PC | \u0026lt;--USB--\u0026gt; | CH341 \u0026lt;--SPI--\u0026gt; SX1262 | | | | \u0026lt;--I/O--\u0026gt; | -------- -------------------------- Pins Pinout\nSX1262 Pin Name Description 1 ANT Antenna 2 GND2 3 VREG 4 DCC 5 VCC 6 DIO1 Connected on CH341 Pin 7 7 DIO2 Connected on CH341 Pin6 8 DIO3 Connected on CH341 Pin 5 9 GND 10 MISO SPI MISO (CH341 Pin 20) 11 MOSI SPI MOSI (CH341 Pin 22) 12 SCK SPI clock (CH341 Pin 24) 13 NSS SPI Chip select 14 POR Reset pin 15 Busy Busy pin 16 GND Kernel module for CH341 We need a driver for the CH341 USB bus converter chip. This driver will allow us to send command to the CH341 (SPI messages and access to the GPIOs). I’ve successfully build and run this driver from rogerjames99 on my desktop computer (running Manjaro Linux) and on my Pinebook Pro (ARM64, running Manjaro ARM Linux). For any kernel newer than 3.10 but mandatory for kernels newer than 5.15 you need to use the dimich-dmb fork of the the spi-ch341-usb driver. This fork has updated documentation for the newer kernel interfaces. If this driver gives you problems please drop by any of the social platforms in the Pine64 LoRa chat and give a holler, and if you are using a 5.15 or older kernel you can use the rogerjames99 fork.\n$ git clone https://github.com/rogerjames99/spi-ch341-usb.git or $ git clone https://github.com/dimich-dmb/spi-ch341-usb.git then $ cd spi-ch341-usb $ make $ sudo make install\nOnce the driver is installed, unload the module ch341 if it has been automatically loaded:\n$ lsmod |grep ch341 $ sudo rmmod ch341 On my setup, ch341 would be automatically loaded once I connected my USB adapter. This module drives the CH341 is asynchronous serial mode, which will not work for a SPI bus.\nThen load the new module:\n$ sudo modprobe spi-ch341-usb Plug your USB adapter and check that the module is correctly loaded :\n$ dmesg [20141.872107] usb 1-1.1: USB disconnect, device number 4 [20143.820756] usb 1-1.1: new full-speed USB device number 5 using ehci-platform [20143.973366] usb 1-1.1: New USB device found, idVendor=1a86, idProduct=5512, bcdDevice= 3.04 [20143.973413] usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [20143.973434] usb 1-1.1: Product: USB UART-LPT [20143.975137] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: connect device [20143.975164] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: bNumEndpoints=3 [20143.975183] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: endpoint=0 type=2 dir=1 addr=2 [20143.975206] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: endpoint=1 type=2 dir=0 addr=2 [20143.975229] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: endpoint=2 type=3 dir=1 addr=1 [20143.975254] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs0 SPI slave with cs=0 [20143.975273] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs0 gpio=0 irq=0 [20143.975295] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs1 SPI slave with cs=1 [20143.975313] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs1 gpio=1 irq=1 [20143.975334] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs2 SPI slave with cs=2 [20143.975352] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs2 gpio=2 irq=2 [20143.975373] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input gpio4 gpio=3 irq=3 [20143.975394] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input gpio6 gpio=4 irq=4 [20143.975415] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input err gpio=5 irq=5 [20143.975435] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input pemp gpio=6 irq=6 [20143.975456] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input int gpio=7 irq=7 (hwirq) [20143.975478] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input slct gpio=8 irq=8 [20143.975499] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input wait gpio=9 irq=9 [20143.975520] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input autofd gpio=10 irq=10 [20143.975542] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input addr gpio=11 irq=11 [20143.975564] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output ini gpio=12 irq=12 [20143.975585] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output write gpio=13 irq=13 [20143.975607] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output scl gpio=14 irq=14 [20143.975628] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output sda gpio=15 irq=15 [20143.975650] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: start [20143.975677] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: SPI master connected to SPI bus 1 [20143.977831] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: SPI device /dev/spidev1.0 created [20143.978183] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: SPI device /dev/spidev1.1 created [20143.978552] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: SPI device /dev/spidev1.2 created [20143.978726] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: done [20143.978735] spi-ch341-usb 1-1.1:1.0: ch341_irq_probe: start [20143.979133] spi-ch341-usb 1-1.1:1.0: ch341_irq_probe: irq_base=103 [20143.979154] spi-ch341-usb 1-1.1:1.0: ch341_irq_probe: done [20143.979162] spi-ch341-usb 1-1.1:1.0: ch341_gpio_probe: start [20143.979220] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=cs0 dir=0 [20143.979229] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=cs1 dir=0 [20143.979237] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=cs2 dir=0 [20143.979245] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=gpio4 dir=1 [20143.979253] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=gpio6 dir=1 [20143.979260] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=err dir=1 [20143.979268] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=pemp dir=1 [20143.979275] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=int dir=1 [20143.979283] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=slct dir=1 [20143.979290] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=wait dir=1 [20143.979298] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=autofd dir=1 [20143.979306] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=addr dir=1 [20143.979314] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=ini dir=0 [20143.979321] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=write dir=0 [20143.979329] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=scl dir=0 [20143.979337] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=sda dir=0 [20143.979831] spi-ch341-usb 1-1.1:1.0: ch341_gpio_probe: registered GPIOs from 496 to 511 [20143.981152] spi-ch341-usb 1-1.1:1.0: ch341_gpio_probe: done [20143.981212] spi-ch341-usb 1-1.1:1.0: ch341_gpio_poll_function: start [20143.981291] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: connected [20144.756250] usbcore: registered new interface driver ch341 [20144.756334] usbserial: USB Serial support registered for ch341-uart With kernel 5.16 and newer the output is shorter:\n$ dmesg [ 6744.813564] usb 1-2.1.1: new full-speed USB device number 21 using xhci_hcd [ 6744.904377] usb 1-2.1.1: New USB device found, idVendor=1a86, idProduct=5512, bcdDevice= 3.04 [ 6744.904383] usb 1-2.1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 6744.904385] usb 1-2.1.1: Product: USB UART-LPT [ 6744.960243] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: output cs0 SPI slave with cs=0 [ 6744.960246] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: output cs1 SPI slave with cs=1 [ 6744.960247] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: output cs2 SPI slave with cs=2 [ 6744.960249] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: input gpio4 gpio=0 irq=0 (hwirq) [ 6744.960251] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: input gpio5 gpio=1 irq=1 [ 6744.960302] spi-ch341-usb 1-2.1.1:1.0: ch341_spi_probe: SPI master connected to SPI bus 0 [ 6744.960350] spi-ch341-usb 1-2.1.1:1.0: ch341_spi_probe: SPI device /dev/spidev0.0 created [ 6744.960398] spi-ch341-usb 1-2.1.1:1.0: ch341_spi_probe: SPI device /dev/spidev0.1 created [ 6744.960445] spi-ch341-usb 1-2.1.1:1.0: ch341_spi_probe: SPI device /dev/spidev0.2 created [ 6744.960583] spi-ch341-usb 1-2.1.1:1.0: ch341_usb_probe: connected Driver development Kernels 5.14 and older Once the module spi-ch341-usb is correctly loaded, here’s how you can transfer data on the SPI bus (in C):\n/* Open the SPI bus */ int spi = open(\u0026quot;/dev/spidev1.0\u0026quot;, O_RDWR); uint8_t mmode = SPI_MODE_0; uint8_t lsb = 0; ioctl(spi, SPI_IOC_WR_MODE, \u0026amp;mmode); ioctl(spi, SPI_IOC_WR_LSB_FIRST, \u0026amp;lsb); /* Transfer data */ /* TODO: Init buffer_out, buffer_in and size */ const uint8_t *mosi = buffer_out; // output data uint8_t *miso = buffer_in; // input data struct spi_ioc_transfer spi_trans; memset(\u0026amp;spi_trans, 0, sizeof(spi_trans)); spi_trans.tx_buf = (unsigned long) mosi; spi_trans.rx_buf = (unsigned long) miso; spi_trans.cs_change = true; spi_trans.len = size; int status = ioctl (spi, SPI_IOC_MESSAGE(1), \u0026amp;spi_trans); To access GPIOs, you first need to export them (to make them accessible via /sys/class/gpio. As you can see in the dmesg output, GPIOs from 496 to 511 were registered, which means we can export 16 GPIOs. The mapping of these I/O is available in the source code of the driver. For example, pin slct is the 12th, meaning we need to export GPIO 496+12 = 508.\nint fd; if ((fd = open(\u0026quot;/sys/class/gpio/export\u0026quot;, O_WRONLY)) == -1) { perror(\u0026quot;open ini\u0026quot;); exit(-1); } if (write(fd, \u0026quot;508\u0026quot;, 3) == -1){ perror (\u0026quot;write export 508\u0026quot;); } Once exported, the GPIO is available in /sys/class/gpio/sclt (the naming is specified by the driver). You can read the pin in C:\nint fd; if ((fd = open(\u0026quot;/sys/class/gpio/slct/value\u0026quot;, O_RDWR)) == -1) { perror(\u0026quot;open\u0026quot;); } char buf; if (read(fd, \u0026amp;buf, 1) == -1) { perror(\u0026quot;read\u0026quot;); } int value = (buf == '0') ? 0 : 1; You can also write it:\nint fd; if ((fd = open(\u0026quot;/sys/class/gpio/ini/value\u0026quot;, O_RDWR)) == -1) { perror(\u0026quot;open ini\u0026quot;); } if (write(fd, value ? \u0026quot;1\u0026quot; : \u0026quot;0\u0026quot;, 1) == -1) { perror (\u0026quot;write\u0026quot;); } Kernel 5.15 and newer We need some help documenting how these interfaces work|\nThe driver creates these interfaces:\nPin SPI Function GPIO function GPIO name IRQ 15 CS0 - - - 16 CS1 - - - 17 CS2 - - - 19 - Input gpio4 hardware 21 - Input gpio5 software The dimich-dmb fork of spi-ch341-usb works with 5.15+ kernels, but as you can see above it is not configured for the needs of the Pinedio-USB by default. I have started a branch in my fork to work on getting the driver pre-configured for our needs. The branch can be found here. Please feel free to help|And open issues or discussions in the repo if you have problems or ideas how to help. Any improvements to the actual code beyond configuration should be pushed to the temporary upstream.\nSince linux-5.15 binding to spidev driver is required to make slave devices available via /dev/, e.g. for slave 1 on bus 0 as real root (not with sudo):\n# echo spidev \u0026gt; /sys/class/spi_master/spi0/spi0.1/driver_override # echo spi0.1 \u0026gt; /sys/bus/spi/drivers/spidev/bind For all devices handled by spi_ch341_usb driver (again, only as real root):\n# for i in /sys/bus/usb/drivers/spi-ch341-usb/*/spi_master/spi*/spi*.*; do echo spidev \u0026gt; $i/driver_override; echo $(basename $i) \u0026gt; /sys/bus/spi/drivers/spidev/bind; done The documentation found at https://github.com/dimich-dmb/spi-ch341-usb/blob/master/README.md has more information.\nThe 5.15+ driver is not ready yet. But if you are interested in testing, helping to get the configuration right, or working on application development you can build and test the current driver:\n$ git clone -b pinedio https://github.com/UncleGrumpy/spi-ch341-usb.git $ cd spi-ch341-usb $ make $ sudo make install So far this will automatically set up the SPI slave device /dev/spi0.0. It names the ch341-usb device as \u0026ldquo;pinedio\u0026rdquo; this will allow application developers to find the correct gpiochip by name. I need help confirming the correct gpio pins but as of now the driver will setup the following configuration:\nThe driver uses following CH341A pins for the SPI interface.\nPin Name Direction Function SPI (CH341A) 18 D3 output SCK (DCK) 20 D5 output MOSI (DOUT) 22 D7 input MISO (DIN) 15 D0 output CS0 The driver uses the following GPIO configuration.\nWarning It is not sure if these are the correct pins to use| CH341 Pin CH341A Name Function GPIO Name GPIO Configuration SX1262 connection 7 INT# IRQ dio_irq Input DIO1 (IRQ) 8 SLCT BUSY dio_busy Input BUSY 26 RST# Hard Reset dio_reset Output NRESET The function of these pins can be changed from user space by using libgpiod. The command line tools installed with the library (gpioset, gpioget, gpiodetect, gpioinfo and others can be used for bash scripts, etc. and applications should all use the libgpiod interfaces. The /sys/class/gpio interface has been removed from the kernel in 5.15, so any apps using /sys/class/gpio to access gpio pins are broken, or will be as distos update their kernels to 5.15 and beyond.\nGPIO pins can be listed with gpioinfo:\n$ gpioinfo pinedio The output should look similar to:\ngpiochip1 - 3 lines: line 0: \u0026quot;dio_irq\u0026quot; unused input active-high line 1: \u0026quot;dio_busy\u0026quot; unused input active-high line 2: \u0026quot;dio_reset\u0026quot; unused output active-high The gpiochip# might be different. The driver exposes the Pinedio with the gpio name \u0026ldquo;pinedio\u0026rdquo;, developers should use this name to interact with the gpiochip because the gpiochip# of the device is likely to be different from one system to the next, or depending on the order devices are initialized.\nDriver for the SX1262 LoRa module Now that we can talk to the SX1262 via the CH341 USB converter chip, we need to send actual commands to make it emit or receive LoRa messages. To do this, you can implement the driver yourself using info from the datasheet, or use an existing driver (you can easily find drivers for the Arduino framework, for example. I found this C++ driver. It’s well written, lightweight and easily portable across many platforms. All you have to do is implement 3 HAL function : read GPIO, write GPIO and transfer data on SPI. I wrote a quick’n’dirty app that emits a LoRa frame. It’s available here.\nAs I don’t have any \u0026lsquo;raw\u0026rsquo; LoRa device on hands, I check that it was actually transmitting something using my SDR setup (simple TNT usb key and Gqrx software):\nOther end nodes There are several end-node units planned:\nloRa back case for the PinePhone standalone USB dongle-type end-node adapter PineTab adapter as well as a SPI module (which can also be configured as a USB LoRa dongle) a LoRa stick powered by a single 18650 battery (using the BL602, and can be fitted with GPS, an low-power OLED panel and additional sensors) All the end-nodes use the SX1262 chip.\nPictures Datasheets and schematics Gateway SX1303 datasheets and resources RAK5146 datasheets and resources Pine64 LoRa Gateway module adapter schematic End nodes SX1262 datasheets and resources Pinephone backplate https://wiki.pine64.org/wiki/File:Pinephone_LoRa_BackPanel_Schematic-v1.0-20210402.pdf https://wiki.pine64.org/wiki/File:CA-S01_LoRa_Chip_Antenna_in_Chinese.pdf I2C SPI Bridge code running on ATtiny84 USB LoRa adapter https://wiki.pine64.org/wiki/File:USB_LoRa_adapter-PINE64_RFM90_SCH_2021_04_26.pdf CH341 datasheet: https://wiki.pine64.org/wiki/File:CH341DS1.pdf Semtech SX1262 datasheet: File on Semtech website (file is too big for the wiki) PineDio Stack Schematic: https://wiki.pine64.org/wiki/File:PINEDIO_STACK_V1_0-2021_05_24C.pdf Other resources Video: A peek at Pine64’s LoRa gateway and modules IOTW - Blockchain-Enabled IoT Data Platform PineDio Stack BL604 RISC-V Board: Testing The Prototype LoRaWAN on PineDio Stack BL604 RISC-V Board The Things Network on PineDio Stack BL604 RISC-V Board Monitor IoT Devices in The Things Network with Prometheus and Grafana Internal Temperature Sensor on BL602 IoT Digital Twin with Roblox and The Things Network PineDio LoRa Gateway: Testing The Prototype Apache NuttX OS on RISC-V BL602 and BL604 SPI on Apache NuttX OS LoRa SX1262 on Apache NuttX OS LoRaWAN on Apache NuttX OS Rust on Apache NuttX OS Connect IKEA Air Quality Sensor to Apache NuttX OS PineDio Stack BL604 runs Apache NuttX RTOS NuttX Touch Panel Driver for PineDio Stack BL604 Buttons on BL602 NuttX NuttX GPIO Expander for PineDio Stack BL604 (Mostly) Automated Testing of Apache NuttX RTOS on PineDio Stack BL604 RISC-V Board Zig on RISC-V BL602: Quick Peek with Apache NuttX RTOS Build an IoT App with Zig and LoRaWAN Build an LVGL Touchscreen App with Zig Apache NuttX RTOS on a RISC-V IoT Gadget: PineDio Stack BL604 (Video) Simpler, safer LVGL Touchscreen Apps with Zig and Apache NuttX RTOS (Video) ","permalink":"/documentation/Pinedio/_full/","tags":null,"title":"Pinedio (Single Page)"},{"categories":null,"contents":" PINE64 position on alternative firmware PINE64 ships the PinePhone with a stock version of the Quectel EG25-G modem’s firmware. Some administrative regions, in the EU and Asia in particular, require the entirety of the modem’s firmware to be licensed. Therefore, the PinePhone cannot ship with an unlicensed firmware, and the PINE64 project cannot, officially encourage its userbase to use alternative modem firmware.\nQuectel EG25-G Modem Quectel EG25-G is an LTE Cat 4 module optimized specially for M2M and IoT applications. It is used in the PinePhone.\nSpecifications: https://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf Hardware design: https://wiki.pine64.org/wiki/File:Quectel_EG25-G_Hardware_Design_V1.4.pdf AT Interface reference manual: 1.3 for EC25: https://wiki.pine64.org/wiki/File:Quectel_EC25\u0026EC21_AT_Commands_Manual_V1.3.pdf 2.0 for EC25 and EG25-G: https://wiki.pine64.org/wiki/File:Quectel_EC2x\u0026EG9x\u0026EG2x-G\u0026EM05_Series_AT_Commands_Manual_V2.0.pdf AT Interface file operations: https://wiki.pine64.org/wiki/File:Quectel_EC2xEG25-GEG9xEM05_FILE_AT_Commands_Manual_V1.0.pdf GNSS Application note: https://wiki.pine64.org/wiki/File:Quectel_EC2x\u0026EG9x\u0026EG2x-G\u0026EM05_Series_GNSS_Application_Note_V1.3.pdf Specifications Processor Family Qualcomm MDM9607 CPU Qualcomm MDM9207 Cores 1 ACPU Core, Qualcomm Hexagon DSP Total RAM 256Mb Total flash space 256Mb Available RAM for the ACPU 160Mb NAND Partition table layout Index Name Description MTD0 SBL Secondary Bootloader, called from the BootROM. Used to start the TrustZone kernel and the Application Bootloader (LK). Also used to enter Quectel’s recovery mode MTD1 mibib NAND Partition table MTD2 EFS2 IMEI and settings used by the ADSP are stored here MTD3 sys_rev Unexplored MTD4 rawdata This is where FOTA update data exists before being committed to system or recoveryfs partitions MTD5 tz TrustZone kernel MTD6 rpm Resource / Power Manager MTD7 cust_info Unexplored MTD8 aboot Application Bootloader. Uses LK (LittleKernel, LK embedded kernel) as the bootloader. By default it allows flashing unsigned images but won’t allow booting them, soft-bricking the modem until you enter EDL mode MTD9 boot OpenEmbedded boot kernel + DTB MTD10 recovery Recovery kernel (used for FOTA updates) MTD11 modem ADSP firmware blobs MTD12 misc Some settings are stored here, along with commands that need to be picked by LK on next boot (to reboot to fastboot or recovery mode) MTD13 recoveryfs Recovery filesystem image (FOTA updates) MTD14 usr_data User data partition (/data when mounted by OpenEmbedded) MTD15 sec Used to blow fuses in the mdm9207 from images generated by Qualcomm Sectools MTD16 system Linux OpenEmbedded root image, formatted in UBIFS (Unsorted Block Image File System, Wikipedia) Firmware Recovery Warning The following instructions are directed towards expert-level users and developers! The System partition is mounted as read-only mode, but the data partition is writable. It might be possible, if there’s an unexpected reset or power is lost while running, that the data partition gets corrupt and thus unable to boot.\nPinePhone USB_BOOT test points\nThe modem has 4 different boot modes:\nNormal boot Recovery mode (used by the modem usually to install a FOTA update) Fastboot mode Qualcomm EDL Mode If the modem is unable to boot, depending on the type of crash, it might:\nnot show anywhere (USB device missing) or malfunction (no radio but USB working) or enter EDL mode, if the entire flash is corrupt. Boot the device in EDL mode\nTo check if the device is booted in EDL mode, run lsusb (a part of the usbutils package) in a terminal and inspect the output. You should see the following device listed:\nBus 003 Device 003: ID 05c6:9008 Qualcomm, Inc. Gobi Wireless Modem (QDL mode) In any scenario, the modem can be triggered to enter EDL mode by shorting two test pins on the PinePhone motherboard.\nPower off the phone short the two test points boot the phone while keeping the test points shorted until fully booted up, at least until you hear the camera clicking twice (which is normally when the modem is powered). Get the Firmware Recovery Package\nThe Firmware Recovery Package is at: https://github.com/Biktorgj/quectel_eg25_recovery\nEither clone its repo with git, or download its archive \u0026amp; unzip it.\nAs you should have no access to the Internet on PinePhone when its modem need a Recovery, you can fetch it on other devices and copy it to the Pinephone.\nExecute the Quectel QFirehose utility\nOnce in EDL mode, open a terminal, navigate to the root directory of the recovery package, and run:\nIf you use an ARM64 distribution (most likely): sudo ./qfirehose -f ./ or sudo ./qfirehose_arm64 -f ./ If you use an ARMHF (32 bit) distribution: sudo ./qfirehose_armhf -f ./ It will reboot the modem after finished. After about 30 seconds, it will get back up and running. To check the firmware version after that, use an AT command AT+QGMR like at PinePhone.\nBootloader unlocking Warning The following instructions are directed towards expert-level users and developers! The Modem has a locked bootloader. It won’t allow to boot unsigned Kernel images, but will allow to flash them, making it easy to brick the modem. To fix this, you can flash an unlocked bootloader, which will then allow you to do as you please with the hardware.\nUnlocked bootloader:\nSource code: https://github.com/Biktorgj/quectel_lk Prebuilt binary releases: https://github.com/Biktorgj/quectel_lk/releases Custom Kernels and system images Warning The following instructions are directed towards expert-level users and developers! Custom kernel builds and system images can be created for the modem, though they require a couple of things to be correctly built and be bootable.\nThe source code release for the kernel provided by the manufacturer is incomplete and won’t build Common Android tools like mkbootimg and dtbtool won’t build a bootable image, even if the kernel is correctly compiled and all the DTBs attached. Further, there’s no source for the OpenEmbedded parts, so building a new system image must be done from scratch, and retrieving the mandatory binary blobs to use the ADSP part of the modem. There’s a work in progress SDK to allow creating custom kernels and system images, which can be downloaded from the following repository: https://github.com/Biktorgj/pinephone_modem_sdk\nSee its readme for infomations and instructions. Once downloaded, you should run the init.sh script, which will create all the base directories and download all the different repositories required to build. After the initial setup is complete, runmake without arguments to list the available options.\nUpgrade/switch firmware via fwupd https://fwupd.org/ is an open-source tool for managing the installation of firmware on Linux systems.\nfwupd \u0026gt;= 1.7.6 (with the ModemManager plugin) supports writing/upgrading the https://github.com/Biktorgj/pinephone_modem_sdk firmware on the Quectel EG25-G modem.\nhttps://wiki.postmarketos.org/wiki/Fwupd discusses how to use fwupd to do this.\nMore context:\nhttps://dylanvanassche.be/blog/2022/pinephone-modem-upgrade/ https://gitlab.com/postmarketOS/pmaports/-/merge_requests/2760 https://gitlab.com/linux-mobile/tracker/-/issues/11 Modem management To allow PinePhones to receive calls while the PinePhone is suspended, the modem should be kept running. ModemManager and a eg25-specific manager must be used for the eg25-manager to work correctly.\nModemManager ModemManager \u0026ldquo;is a DBus-activated daemon which controls mobile broadband (2G/3G/4G) devices and connections\u0026rdquo;. Distributions should enable the --test-quick-suspend-resume flag, per https://gitlab.com/linux-mobile/tracker/-/issues/12.\nContext: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/321\neg25-specific manager Some functionality is not built into ModemManager, and is instead managed via eg25-specific software. There are two variants of this, but only one should be used.\neg25-manager recommended, used in most distributions. modem-power Testing When a distribution makes a significant change to their modem management setup, they should consider testing the following:\nModem is recognized by ModemManager on boot. Can make a call Can receive a call Can receive a call when asleep: systemctl suspend See also \u0026ldquo;PinePhone modem myths\u0026rdquo; by Dylan Van Assche ","permalink":"/documentation/General/PineModems/","tags":null,"title":"PineModems"},{"categories":["Tablets"],"contents":" One of the most powerful Linux-based Eink tablets Introducing the PineNote – A new early adopter Linux Eink tablet. The 1404 x 1872 resolution Eink panel with a fast refresh rate has 16 levels of grayscale and is not only contained by a hardened scratch-resistant glass with an anti-glare coating and a wacom EMR layer, but it also contains a frontlight with white or amber illumination settings. Powered by a powerful and efficient RK3566 SoC with four A55 cores, and backed by 4GBs of RAM and 128GBs of eMMC storage this will be a powerful portable device capable of taking notes, writing and reading documents, reading books, terminal usage, and more.\nThe first batch of the PineNote will be great to write software for, but not great to write notes on. Wait for a later batch with better preinstalled software if you just want to use the device as an e-reader, e-note, or your everyday computing device.\nFeatures and Specifications SoC 4 x ARM Cortex A55 cores @ 1.8 GHz GPU ARM Mali G52 MP2 GPU Memory 4GB LPDDR4 RAM Networking Built-in 802.11ac WiFi and Bluetooth 5 Storage 128GB eMMC storage Display 10.3″ 1404×1872 (227 DPI) 16 grayscale multi-touch Eink panel 36 levels of cold and warm frontlighting Scratch and glare resistant hardened glass Optional Wacom EMR pen Power 4,000mAh battery Connections 4 x DMIC microphones G-Sensor for rotation sensing 1.3W stereo speaker\nUSB-C charging port (2.0) Optional magnetic cover (hall sensor) 10.3\u0026quot; Anti-Glare Eink Display Take notes with the pen, read and write documents on the fly, or simply read a good book while relaxing.\nQuad-Core RK3566 SoC Powered by a powerful and efficient RK3566 SoC with four A55 cores and a Mali G52 GPU\nMagnesium Alloy Case A premium-feeling 7mm thick Magnesium Alloy casing with a magnetic cover\nWireless Connectivity Expand what you can do with the device thanks to onboard WiFi and Bluetooth\nStores Global Global: Accessories Global: Spare parts Affiliates Documentation PineNote Schematics and certifications ","permalink":"/devices/pinenote/","tags":null,"title":"PineNote"},{"categories":null,"contents":" The PineNote\nThe PineNote is the first hybrid notepad computer device combination of notebook, tablet and e-reader using an e-ink panel. It is derived from the Quartz64 model A SBC and powered by a Rockchip RK3566 quad-core ARM Cortex A55 64-bit processor with a MALI G-52 GPU.\nIntroduction State of the software The PineNote is based on the in 2021 released Rockchip RK3566 SoC. The upstreaming status of the SoC functionality can be found on the Quartz64 development documentation page of the Quartz64 single-board computer using the same SoC. In the PineNote development documentation page you’ll find the items specific for the PineNote.\nThe community edition batch of the PineNote is aimed solely at users with extensive Linux experience. The software while it has improved is still prone to software breaking issues, so users must be prepared to get their hands dirty. This batch is suitable for taking notes, reading ebooks and documents, and general tasks such as web browsing.\nThe current default Debian firmware is available for users to download here. All core features works well out of the box (taking notes, reading ebooks and documents) but there are still some issues that arise due to updates from Debian (Trixie) testing.\nHelp and support Still have any questions regarding software, shipping, or ordering after reading the documentation? Please don’t hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See the community page.\nPlease keep in mind that PINE64 is not like a regular company (see the PINE64 philosophy) and that support resources are limited - the best way to get support quickly is to ask in the community chat. Please only contact the PINE64 support directly if questions couldn’t be solved via the community chat or the documentation.\nGetting Started Important note for buyers after October 2024 Note Dear new PineNote users, you may have noticed that suspend/resume is not working on your new PineNote! You may also noticed that using rkdeveloptool is not possible because you cannot trigger maskrom mode using the magnet method.\nThese issues are caused by differences in testing procedures of the shipped Debian-based image, and factory flashing procedures. Namely, the factory used a Windows-based flashing system, and it turned out that this system does overwrite crucial parts of the u-boot bootloader with same only-partially working data. The effect is that the PineNote will boot, but not suspend.\nFixing the issue Fortunately the PineNote ships with a complete set of bootloader files and fixing the issue is a matter of a few shell commands:, which are flashing a working U-Boot to get MASKROM with magnet working on PineNote:\nLogin via UART-adapter or ssh, or use the Gnome-Terminal (found in the quick slots of the dashboard - switch to BW+Dithering mode for faster screen responses):\nusername: user password: 1234 Gain root access by executing sudo su - root (the password is: 1234).\nExecute the following (two) commands (as root):\ncd /root/uboot bash install_stable_1056mhz_uboot.sh Turn off the PineNote by executing init 0\nDone. The pinenote should now have a proper U-Boot installed, with rkdeveloptool-support and suspend.\nThe output of step 3 should read:\nroot@pinenote:~/uboot# bash install_stable_1056mhz_uboot.sh 568+0 records in 568+0 records out 290816 bytes (291 kB, 284 KiB) copied, 0.00419942 s, 69.3 MB/s 8192+0 records in 8192+0 records out 4194304 bytes (4.2 MB, 4.0 MiB) copied, 0.447542 s, 9.4 MB/s If not errors were reported, then the 1056 MHz u-boot/ram-blob was installed Please reboot root@pinenote:~/uboot# init 0 What\u0026rsquo;s inside the PineNote package Included in the box are:\nPineNote Stylus USB-C to USB-A cable (only pre 2024 PineNotes) USB-C to Micro-USB cable - specifically for the stylus UART Dongle - for UART connectivity Foldable cover Installing the foldable cover The foldable cover can be applied to the PineNote in these simple steps:\nStep 1: Remove the protective plastic from the adhesive strip.\nStep 2: The black adhesive strip should now be exposed.\nStep 3: Carefully place the PineNote on top of the side with the adhesive strip, ensuring that the corners and edges are properly aligned with the device.\nReleases The following releases are available for the PineNote.\nFactory-installed Images Summary Pre-2024 PineNotes were not shipped with a working linux installation. Batch-2 (Community Edition) PineNotes that started selling in October 2024 were shipped with the community-maintained, Debian-based, Linux image found here: https://github.com/PNDeb/pinenote-debian-image. While the factory-flashed image cannot be freely distributed due to unclear distribution rights of the waveform, OS files without the shipped waveforms can be found in this release and a basically equivalent to the shipped images: https://github.com/PNDeb/pinenote-debian-image/releases/tag/batch-2-factory-image-wo-waveform Parts of the batch-2 PineNotes will be flashed with an updated OS version. Notes regarding differentiating between factory OS versions will be made available here in time. Debian A full GNOME-enabled rootfs/disc image is provided under PNDeb/pinenote-debian-image/releases. This image can be flashed using rkdeveloptool. Note Check the trixie branch and github actions artifacts (possibly requires github login) for builds newer than the latest release. A Debian-based minimalistic rootfs/disc image can be built using debos using the work from Eugen Răhăian. The GNOME image above is building on this work. Alpine See https://github.com/DorianRudolph/pinenotes#alpine\nArch Linux hrdl hrdl is maintaining a sway setup on Arch Linux alongside their kernel tree.\nKernel source Packages, helpers, distribution image Installation process dbus service sway configuration DorianRudolph See https://github.com/DorianRudolph/pinenotes#arch-linux\npostmarketOS See https://wiki.postmarketos.org/wiki/PINE64_PineNote_(pine64-pinenote)\nDevelopment Warning The following releases are targeted towards experienced developers. Linux Kernel Batch-2 PineNotes (Community Edition) ares shipped with kernels maintained here https://github.com/m-weigand/linux. RK3566 EBC Reverse-Engineering for the EBC (eInk Panel) driver. PineNote Development/Building Kernel BSP Linux SDK version 4.19 for the PineNote and Quartz64 Model A: Direct download from pine64.org (32.67GB, MD5 of the TAR-GZip file 24554419aec29700add97167a3a4c9ed) Mirror by mwfc An unofficial torrent download provided by a community member of the BSP Linux and Android SDKs can be found here (100GB). Android Android 11 e-ink SDK for the PineNote and Quartz64 Model A. This is the Android SDK build for 10.3\u0026quot; eink panels on Quartz64 Model A.\nDownload:\nDirect download from pine64.org (72.88GB, MD5 of the TAR-GZip file 293a550584298de4fb95ceae18103672) Mirror by mwfc An unofficial torrent download provided by a community member of the BSP Linux and Android SDKs can be found here (100GB). Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz Notes:\nView Android SDK for RK3566 for more information how to compile an image for the PineNote using this SDK Chimera Linux See https://www.1a-insec.net/stuff/pinenote/\nDevelopment Sub pages Building Kernel\nFlashing\nBooting Linux\nUART\nApps\nSoftware tweaks\nMainline development Status The following table aims to provide a list of kernel modules required for running the PineNote. It also aims at listing repositories of work in progress. While some overlap with the Quartz64 module list (Development) is expected, only modules relevant to the PineNote hardware should be listed here.\nFunction Status Module Notes Suspend mode driver tbd rockchip-sip The rockchip-sip driver is not mainlineable; it is only needed via a hack for suspend/resume to work when downstream TF-A is used. Suspend on upstream TF-A (status) should work without any special drivers. Touchscreen Implemented in Linux Mainline cyttsp5 As of 6.2-rc1[source] Digitizer Implemented in Linux Mainline i2c_hid_of Pen BLE Buttons tbd ws8100-pen https://github.com/smaeul/linux/commit/46e87f1f9c7dd22af26d99f60eb83d2cace43cb5 EBC Display controller tbd rockchip-ebc RFC PATCH 00/16 drm/rockchip: Rockchip EBC (\u0026ldquo;E-Book Controller\u0026rdquo;) display driver EBC PMic tbd tps65185 driver developed here, small tweaks to resume behavior added on top here LED backlight driver Implemented in Linux Mainline lm3630a Accelerometer Implemented in Linux Mainline st-accel-i2c (silan,sc7a20) As of 5.18-rc1 [source] Rastergraphics unit RGA2e tbd rga (v4l2 mem2mem driver) WIP patches for activation on the Pinenote/dithering/Y4-conversion can be found here: [source]. Note that the rga2e in the rk3566 only works for RAM \u0026lt;= 4 G!). Simple demo program found here: [source] Mali GPU Not in Linux Mainline\nImplemented in upstream Mesa panfrost As of 5.18 [source] this got added to the .dtsi file, but it’s status is disabled. Enabling the gpu node upstream needs to wait till rockchip-ebc is upstreamed. Wifi/BT Implemented in Linux Mainline brcmfmac Mainlining notes Some work happening here: https://gitlab.com/calebccff/linux, the idea is to import the parts of the eink/ebc drivers which are open source and use the downstream u-boot framebuffer driver as a reference to create a basic framebuffer driver.\nCurrently mainline struggles to boot due to weird issues while probing fixed regulators (?). It also fails to detect eMMC.\nFurther work is being done here: https://github.com/smaeul/linux/commits/rk356x-ebc-dev. This has a complete device tree, with working eMMC. Pen input also works out of the box. Wi-Fi and BT work with firmware copied from the factory Android image.\nHow to boot mainline UART is currently REQUIRED for this to work|We depend on u-boot falling back to console. Once we have a prebuilt u-boot which will use extlinux by default, UART won’t be needed anymore.\nYou can compile a u-boot that uses extlinux by default by following the instructions here.\nGetting to a U-Boot prompt You can get to a U-Boot prompt by:\nHolding Ctrl-C while the display panel initializes. Wiping the \u0026ldquo;boot\u0026rdquo; partition. Using sysboot The extlinux.conf should have the following contents:\ntimeout 10 default MAINLINE menu title boot prev kernel label MAINLINE kernel /vmlinuz fdt /rk3566-pinenote.dtb initrd /initramfs append earlycon console=tty0 console=ttyS2,1500000n8 fw_devlink=off PMOS_NO_OUTPUT_REDIRECT At the U-Boot console, run the following command to boot your mainline kernel:\nsysboot ${devtype} ${devnum}:9 any ${scriptaddr} extlinux.conf Booting with individual commands Booting with individual commands can be useful when you need to temporarily add some kernel command line arguments. Use these or similar commands at the U-Boot shell:\nload mmc 0:b ${kernel_addr_r} boot/Image load mmc 0:b ${fdt_addr_r} boot/rk3566-pinenote.dtb setenv bootargs ignore_loglevel root=/dev/mmcblk0p11 rootwait init=/bin/bash booti ${kernel_addr_r} - ${fdt_addr_r} Configuration Firmware for WiFi \u0026amp; Bluetooth and Waveform data Using Maximilian\u0026rsquo;s Debian image If the Android partition (super) and waveform partition (waveform) is left intact the image extracts the WiFi, BT driver and waveform from the partitions on first run.\nFor instance if you repartitions the userdata partition and installs the image there.\nGetting it from the Android install manually Copy WiFi/BT firmware from Android:\nmkdir -p /cache/lib/firmware/brcm cp /vendor/etc/firmware/fw_bcm43455c0_ag_cy.bin /cache/lib/firmware/brcm/brcmfmac43455-sdio.bin cp /vendor/etc/firmware/nvram_ap6255_cy.txt /cache/lib/firmware/brcm/brcmfmac43455-sdio.txt cp /cache/lib/firmware/BCM4345C0.hcd /cache/lib/firmware/brcm/BCM4345C0.hcd Copy waveform partition (via previously dumped file):\nadb root adb push waveform.img /cache/lib/firmware/waveform.bin Or via dd within Linux:\ndd if=/dev/mmcblk0p3 of=/lib/firmware/waveform.bin bs=1k count=2048 Getting the Wifi and Bluetooth driver blobs from \u0026ldquo;other\u0026rdquo; sources WiFi The WiFi firmware .bin blob can be obtained by installing the Debian package firmware-brcm80211 (in the non-free section; in Bookworm and later it’s in the non-free-firmware section)\nThe WiFi brcmfmac43455-sdio.txt file can according to Eugen be sourced from https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/tree/brcm/brcmfmac43455-sdio.AW-CM256SM.txt needs a renaming when copying it to /lib/firmware/brcm/brcmfmac43455-sdio.txt). The content of the upstream .txt is different than the Android configuration, but is supposed to work.\nAs you don’t have WiFi yet you need to get the firmware-brcm80211*.deb and brcmfmac43455-sdio.txt file on the PineNote by other means, for instance using an USB stick\nBluetooth Once you have WiFi working you can get BCM4345C0.hcd by installing the bluez-firmware:\nsudo apt install bluez-firmware Configuring the E-ink refresh mode https://github.com/m-weigand/mw_pinenote_misc/tree/main/rockchip_ebc/patches contains information on how/where to write in /sys to alter the refresh mode https://github.com/m-weigand/mw_pinenote_misc/tree/main/gnome_extension contains the gnome extension used in Maximilian image Touchscreen and Pen In X.org By default the pen config is flipped 180° (which makes it unusable) and the touchscreen doesn’t work. Placing the following config in /etc/X11/xorg.conf.d/50-touchscreen.conf will fix both problems:\nSection \u0026#34;InputClass\u0026#34; Identifier \u0026#34;evdev touchscreen\u0026#34; MatchProduct \u0026#34;tt21000\u0026#34; MatchIsTouchscreen \u0026#34;on\u0026#34; Driver \u0026#34;evdev\u0026#34; EndSection Section \u0026#34;InputClass\u0026#34; Identifier \u0026#34;RotateTouch\u0026#34; MatchProduct \u0026#34;w9013\u0026#34; Option \u0026#34;TransformationMatrix\u0026#34; \u0026#34;-1 0 1 0 -1 1 0 0 1\u0026#34; EndSection Further information Notes Written by Some Developers https://github.com/m-weigand/mw_pinenote_misc (Not super legible \u0026ldquo;notes\u0026rdquo;, but very helpful repo with patches, videos, etc) specifically see this section for helpful install/configure scripts: https://github.com/m-weigand/mw_pinenote_misc/tree/main/rockchip_ebc/patches#compiling. https://github.com/0cc4m/pinenote-misc patch for enabling gpu: https://github.com/0cc4m/pinenote-misc/blob/main/mesa-archlinux-arm/mesa/rockchip-ebc.patch prebuilt pkg’s: https://github.com/0cc4m/pinenote-misc/releases https://pwarren.id.au/pinenote/build_notes.txt https://github.com/DorianRudolph/pinenotes https://github.com/tpwrules/nixos-pinenote Alternative to patching of mesa Mesa needs to be patched to add the driver entry point. The alternative to this, is the renaming of the ebc driver to an existing mesa driver entry point. A good existing name can be \u0026ldquo;repaper\u0026rdquo;. To change the driver name, edit in the kernel tree the following files:\nreplace \u0026ldquo;rockchip-ebc\u0026rdquo; with \u0026ldquo;repaper\u0026rdquo; in the two places in the file: drivers/gpu/drm/rockchip/rockchip_ebc.c preventive, replace \u0026ldquo;repaper\u0026rdquo; with \u0026ldquo;repaper-disabled\u0026rdquo; in the two places in the file: drivers/gpu/drm/tiny/repaper.c Video of Factory Android OS PineNote Developer Edition w/Tech Demo Android OS (Video Only)\nInformal walkthrough of the factory Android installation on the PineNote Developer Edition, recorded by a community member (Apr 2022). This is useful to look back at the original OS after erasing it from your device, or to get some additional detail before your device arrives.\nThe video also includes a chapter at the end showing how to enable Android Debug Bridge (\u0026ldquo;adb\u0026rdquo;) over USB. Once enabled, keep the device powered and connect a USB cable directly to the PineNote (i. e. no UART breakout) to a computer running adb.\nIssues Resolved issues The following topics have resolved:\n/documentation/PineNote/Further_information/Closed_Case_UART[PineNote/Hardware Changes/Closed Case UART] Could the USB-C port support USB 3.1 5Gbps? Yes and no. The RK3566 only has a host-mode 5Gbps controller, meaning it can only negotiate such a high data rate with a device such as a flash drive. When the RK3566 is acting as a device, it only supports 480Mbps transfer rates. The hardware required to switch between these modes would raise the PineNote’s price unreasonably. Therefore, the USB-C port will remain at USB 2.0 speeds for Host and Device mode. Could the USB-C port output DisplayPort? Yes and no. The hardware required to support such a feature would raise the PineNote’s price unreasonably. Therefore, DisplayPort output will not be possible through the USB-C port. Where is the microSD card slot? The case design of the PineNote is fixed, making physical changes like adding a microSD card slot would raise the cost unreasonably. How will I install software to the PineNote? This is a hardware and software question. If the software on your PineNote is completely broken and cannot boot to a recoverable state, a Hall (magnet) sensor was fitted to the PineTab motherboard as U9009. This sensor is attached to SARADC_VIN0_KEY/RECOVERY on the RK3566. With the device powered off, and screen face down, holding a magnet over U9009 and plugging in a USB-C cable causes the device to boot into \u0026ldquo;rockusb\u0026rdquo; flash mode. With proper flashing software and drivers, it should be possible to load a new operating system using rockusb if the system is soft-bricked. Of course, software vendors will need to be more careful with flashing firmware and providing useful \u0026ldquo;recovery\u0026rdquo; options on this device due to this process’s relative difficulty to other PINE64 devices. Unresolved issues The following concerns have been brought up as open, unanswered topics:\nDoes Audio Adapter Accessory Mode work? It appears that the Headphone output of the audio codec was routed to the USB-C audio+USB switch, but it’s unclear whether CC lines are hooked up correctly for detection of such a device. The PineNote hardware team will be testing this functionality soon (as of August 19, 2021). Note that Audio Accessory mode is detectable by reading the I2C registers of the WUSB3801Q. So connecting ASEL to a GPIO would be enough to get this working if it is not working already. Why is the Headphone output of the audio codec routed to the speakers? HPL_OUT is routed from the RK817 PMIC and audio codec to U9010 (the USB-C switch) and U6 (the audio amplifier). SPK_OUT is unused. It seems like SPK_OUT should be routed to U6 and HPL_OUT to U9010. Nitpick: The cold white charging LED bleeds through the gap between the rear case and the device’s face. It does not bleed onto the screen, but it is jarring in low-light conditions or when the screen is amber. Could be resolved in software by turning off the charge LED when the screen is on. Is there any way to indicate when the device is in rockusb mode, such as connecting a certain magic pin to the power LED? The modem/4G connector (J6010) has its I2C and UART pins unconnected. Could those be connected to the SoC? Building Kernel This page contains information on how to build a linux kernel for the PineNote.\nAvailable Kernel Repositories The following PineNote-specific kernel repositories are available:\nhttps://github.com/m-weigand/linux/ (based mainly on the repository from smaeul, with additional patches pulled in from other sources, Debian packages available) https://git.sr.ht/~hrdl/linux (based on Maximilian\u0026rsquo;s kernel tree, which improves display responsiveness with per pixel scheduling and the automatic redraw of pixels among other improvements) Building the kernel There are currently a couple of up to date trees to choose from.\nMaximilian\u0026rsquo;s kernel is found on the default Debian based operating system shipped with the community edition devices. Currently the most stable option. hrdl\u0026rsquo;s tree is more experimental with new features such as per pixel scheduling and the automatic redrawing of pixels. Prerequisites Building on Debian: Building on device (or another 64bit arm device) will require you to install build-essential. If you are wanting to cross compile you are required to install gcc-12-aarch64-linux-gnu-base (or equivalent) and build-essential. m-weigand kernel Found at https://github.com/m-weigand/linux/\n# Clone the kernel repository and set up the working environment. $ git clone --depth 1 --branch branch_pinenote_6-6-30 https://github.com/m-weigand/linux $ cd linux # Set the PineNote defconfig and compile the kernel. # Remember to pick the commands that reflect your compilation environment below. # For cross compilation $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- pinenote_defconfig $ make -j 2 ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- LOCALVERSION=-pinenote-`date +%Y%m%d%H%M` KBUILD_IMAGE=arch/arm64/boot/Image # For aarch64 host compilation $ make pinenote_defconfig $ make -j 2 LOCALVERSION=-pinenote-`date +%Y%m%d%H%M` KBUILD_IMAGE=arch/arm64/boot/Image Once finished you will have your Image and vmlinux files. To install your modules and dtbs:\n# Make a folder to store these files $ mkdir pack # For cross compilation $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_MOD_PATH=${PWD}/pack modules_install $ make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- INSTALL_PATH=${PWD}/pack dtbs_install # For aarch64 host compilation $ make INSTALL_MOD_PATH=${PWD}/pack modules_install $ make INSTALL_PATH=${PWD}/pack dtbs_install # Copy these to store them in our pack folder. $ cp ./arch/arm64/boot/dts/rockchip/rk3566-pinenote-v1.2.dtb pack/ $ cp ./arch/arm64/boot/Image pack/ hrdl kernel Found at https://git.sr.ht/~hrdl/linux/\n# Clone the kernel repository $ git clone --depth 1 https://git.sr.ht/~hrdl/linux hrdl-linux $ cd hrdl-linux # Set the PineNote defconfig and compile the kernel. # Remember to pick the commands that reflect your compilation environment below. # For cross compilation $ make ARCH=arm64 pinenote_defconfig $ make ARCH=arm64 -j$(($(nproc)-1)) $ make ARCH=arm64 INSTALL_PATH=pack INSTALL_MOD_PATH=pack modules_install dtbs_install # For aarch64 host compilation $ make pinenote_defconfig $ make LLVM=1 -j$(($(nproc)-1)) $ make INSTALL_PATH=pack INSTALL_MOD_PATH=pack modules_install dtbs_install Next steps Configuring the driver The driver has several options that can improve performance. These can be read about here.\nUsers should edit the /etc/modprobe.d/rockchip_ebc.conf to configure their driver.\nFor m-weigand kernel options rockchip_ebc direct_mode=0 auto_refresh=1 refresh_threshold=60 split_area_limit=0 panel_reflection=1 prepare_prev_before_a2=0 dclk_select=0\nFor hrdl kernel 6.15rc3 options rockchip_ebc dithering_method=2 default_hint=0x80 early_cancellation_addition=2 redraw_delay=200\nFixing suspend If you’re using a logind system, edit your /etc/systemd/logind.conf config. More information on what to do in Arch’s documentation.\nConfiguring your apps See Apps.\nBooting Linux instead of Android PineNote Development/Booting Linux\nFixing Bluetooth See PineNote Development/Software Tweaks\nFlashing Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. Note These instructions are directed towards experienced developers only! This page contains information on flashing software to the PineNote.\nThe general process is as follows:\nTake a backup of all important data on the PineNote Modify the partition layout to make space for your desired Linux distribution Instantiate a root filesystem (rootfs) in the new partition space Install your Linux distribution to the boot partition Modify the boot process to boot the Linux distribution by default There are multiple possible methods of executing these steps, and this page attempts to document all of them.\nYou can use:\nrkdeveloptool, a command line utility for modifying Rockchip devices over USB The UART shell Android Debug Bridge Fastboot Getting rkdeveloptool Most flashing operations on the PineNote are done through rkdeveloptool, a command line utility built on libusb. PINE64 maintains its own fork here that you will need to get. The repo’s README contains a list of dependencies (libusb 1.0) and instructions for building the tool.\nInstalling (not just building) rkdeveloptool will configure PAM to elevate privileges where necessary on your system; you can configure this manually as follows:\nsudo cp 99-rk-rockusb.rules /etc/udev/rules.d/ sudo udevadm control --reload Entering Maskrom/Rockusb mode Interfacing with the PineNote over USB using rkdeveloptool requires first booting the PineNote into an alternative operating mode called Maskrom or Rockusb mode.\nPossible methods There are three possible methods of entering Maskrom/Rockusb mode:\nHardware magnet switch Developer Edition Connect the PineNote to your computer via USB and boot the PineNote into Android Locate \u0026amp; identify the small circular marking on the back of the PineNote, in the top right quadrant; have the PineNote pen close at hand, or any other small magnet Hold the PineNote power button to bring up the reboot/shutdown menu; select reboot, then place the PineNote face down with the \u0026ldquo;eraser\u0026rdquo; end of the pen (or your magnet) resting on the small circular marking Community Edition The community edition is shipped with Debian and a passive pen without a magnet, therefore you will need to source your own magnet.\nMake sure you have flashed the new U-Boot image after receiving your community edition PineNote. You can do this if you haven\u0026rsquo;t already by running:\n$ cd /root/uboot ... $ bash install_stable_1056mhz_uboot.sh Power off the PineNote from the Gnome quick settings menu in the top right.\nPlace the PineNote display side facing down and place the magnet on the small circle in the top right quadrant of the device.\nPlug the PineNote into your computer (you do not need to press the power button).\nU-Boot terminal Stock UART dongle The stock UART dongle does not support regular USB functions while plugged in. It must be removed after entering maskrom so the host can communicate with the device in maskrom mode.\nConnect to the PineNote via UART and USB simultaneously Interrupt the U-Boot startup using ctrl+c sent over UART In the U-Boot terminal over UART, run rockusb 0 mmc 0. The UART terminal should print RKUSB and display a spinner. Remove the UART dongle and connect directly to the PineNote. rkdeveloptool list should now list the PineNote. Non-stock UART dongle with passthrough This method requires a UART dongle with passthrough allowing simultaneous UART \u0026amp; USB connections.\nIt is nice because you can easily switch back \u0026amp; forth between U-Boot and Rockusb without having to physically manipulate the PineNote or its connectors; this is especially helpful when trying to develop U-Boot.\nConnect to the PineNote via UART and USB simultaneously Interrupt the U-Boot startup using ctrl+c sent over UART In the U-Boot terminal over UART, run rockusb 0 mmc 0 The UART terminal should print RKUSB then a spinner will appear. You can exit back to the U-Boot terminal by sending ctrl+c again.\nShorting test points If the bootloader is broken/corrupted, you cannot get to Maskrom without opening up the device (it can be opened using spudger and a bit of patience).\nOnce inside, short TP1301 (GND) and TP1302 (eMMC_D0/FLASH_D0) with a small tweezers, this is how it looks on board view (credit to Caleb):\nSuccess No matter what approach you take, you can tell whether you succeeded by running the lsusb command on your computer:\nIf you find the entry 2207:0018 Fuzhou Rockchip Electronics Company rk3566_eink in the list, the process did not succeed; reboot and retry The entry 2207:350a Fuzhou Rockchip Electronics Company will occur if you detach then reattach the USB-C cable while the PineNote is in Maskrom/Rockusb mode; rkdeveloptool won’t work and you will have to do a hard reboot (hold down power button for 30 seconds to shutdown) If you find the entry 2207:350a Fuzhou Rockchip Electronics Company USB download gadget then the process succeeded You can also look at the output of the rkdeveloptool list command:\nIf this prints out No devices in rockusb mode found the process did not succeed; reboot and retry If this prints out DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=305 Maskrom then you probably detached/reattached the USB-C cable while in Maskrom/Rockusb mode and rkdeveloptool won’t work; perform a hard reboot to fix If this prints out DevNo=1 Vid=0x2207,Pid=0x350a,LocationID=303 Loader then the process succeeded Exiting You can boot the PineNote back into its normal mode of operation by powercycling the PineNote with its hardware power switch, or running the rkdeveloptool reboot command. If you used the magnetic switch method be sure to remove the pen/magnet before rebooting.\nBackup A backup of the content of the internal eMMC before anything gets messed up is mandatory.\nEspecially the waveform partition contains data unique to your PineNote and is a prime candidate for backup.\nOther partitions like U-Boot (need for any operation of the device) or the un-partitioned space at the beginning containing the GPT partition table (and presumably the VCOM setting for the e-ink display and maybe device mac addresses) contain data you may also wish to backup.\nDepending of your personal level of data hoarder you may want to backup more than this or even just everything (the large userdata partition is supposed to be able to be repopulated as empty space by Android)\nIn any case it is easier to restore/extract data from a backup than not having one if you need one.\nThis process was developed by Dorian Rudolph, originally described here.\nList partitions First, run rkdeveloptool list-partitions to print out your PineNote’s partitions to get an idea of what you’re dealing with.\nCommunity Edition Stock partition layout of the Community Edition:\nNumber Name Size Purpose 0 uboot 64 MB The U-Boot embedded systems bootloader 1 waveform 2 MB Important files controlling the e-ink screen’s state changes 2 uboot_env 1 MB U-Boot environment partition 3 logo 64 MB Splash image displayed during boot 4 os1 14.65 GB Default OS slot where Debian is stored 5 os2 14.65 GB An alternative operating system can be flashed here such as PostmarketOS or Arch Linux 6 data 85.82 GB /home partition for user files Developer Edition The stock Developer Edition has a fairly standard Android partition setup:\nNumber Name Size Purpose 0 uboot 4 MB The U-Boot embedded systems bootloader 1 trust 4 MB Secrets that can be encrypted with a key stored in the TPM 2 waveform 2 MB Important files controlling the e-ink screen’s state changes 3 misc 4 MB Data used by the recovery partition 4 dtbo 4 MB Device Tree Blob for Overlay, files describing the PineNote’s hardware configuration 5 vbmeta 1 MB Data required for verified boot 6 boot 42 MB The kernel image \u0026amp; ramdisk to boot 7 security 4 MB 8 recovery 134 MB The recovery image, booted during Android updates 9 backup 400 MB 10 cache 1 GB Stores temporary data; can be used to install a minimal Linux distribution! 11 metadata 17 MB Used for disk encryption 12 super 3.25 GB Android itself is installed here 13 logo 17 MB Splash image displayed during boot 14 device 67 MB 15 userdata 119 GB The big one; user-installed Android apps and files live here Patch U-Boot Note This applies only to Developer Edition. Community Edition devices are shipped with fixed U-Boot. Do not flash the uboot_patched.img if the output of rkdeveloptool list-partitions doesn\u0026rsquo;t match Developer Edition above. Before we can back up our partitions, we have a problem to solve. The version of U-Boot installed on the stock PineNote contains a bug where it can’t dump partitions beyond 32 MB (above that limit all bytes in the dump are just 0xCC), meaning the PineNote must be flashed with a fixed version of U-Boot before it is possible to take a backup of the larger partitions. It is possible to extract and modify the U-Boot image from your PineNote if you’re interested in some light reverse-engineering (following Dorian’s notes), or you can simply download a patched U-Boot image directly here.\nOnce you’ve acquired a patched U-Boot image, run:\nrkdeveloptool read-partition uboot uboot_backup.img rkdeveloptool write-partition uboot uboot_patched.img rkdeveloptool reboot Taking the backup With U-Boot patched, you can back up every partition except for super and userdata; run:\nrkdeveloptool read-partition partition_name partition_name_backup.img\nUnfortunately the super and userdata partitions run into a second limitation preventing dumping partitions larger than 2 GB, this time originating in rkdeveloptool itself. This means if you have a large number of documents in the Android userdata partition they might not all make it into the backup. If you don’t have many documents (or don’t care about losing them) this should not be a problem. If you do have a lot of documents, workarounds include:\nA possible patch written by Thomas exists here but has not yet been upstreamed; consider investigating how to get the patch tested \u0026amp; upstreamed, or just apply it to your own local copy of rkdeveloptool Use this Python script written by Visti Andresen (talpadk) to automatically backup your entire partition by splitting reads into 2 GB chunks See instructions on this artifact. It will instruct you on extracting the rootfs into an empty ext4 partition. This can be done from Linux or Android. Further instructions on building your own rootfs can be found here.\nUsing a user installed Linux A Linux installed to the cache partition should be able to easily backup everything over WiFi or to a USB stick/disk using dd.\nHowever the user would need to backup the cache partition (if they want that).\nAnd more importantly they would only be getting the backup after they started playing with the content of the eMMC.\nSide-by-side setup It is possible to set up a partition for mainline development without disturbing the factory Android installation. This allows updating a mainline kernel, DTB, and initramfs over Wi-Fi until WiFi or USB OTG is working in mainline Linux.\nWithout Repartitioning The recommended partition for this is mmcblk0p11 aka /cache. It is large and already formatted as ext4, so it is readable from U-Boot. Here are some general steps:\nFrom the UART or adb shell, set up your chroot in /cache. I used the Alpine Linux rootfs tarball. Copy in your kernel and DTB, using for example scp or wget inside the chroot. Finally, create and boot an extlinux.conf as described below. With Repartitioning It is possible to shrink the userdata partition, and create a new partition at the end for use with mainline Linux. This provides much more space than cache. However, because userdata is formatted with f2fs, and that filesystem cannot be shrunk, resizing the partition requires wiping userdata.\nBack up any necessary files from userdata Boot to a mainline kernel from mmcblk0p11, either using that partition as rootfs (see above), or using an initramfs with repartitioning tools Modify the partition table with your favorite tool, e.g. fdisk, gdisk, or parted Reboot into fastboot and wipe userdata. Reboot into Android, where you can now chroot in and install your favorite distribution to the new partition. Using rkdeveloptool Building Downstream U-Boot While in maskrom mode, we need to have a u-boot to download onto the device for any of the other commands to work. To build you’ll also need to install device-tree-compiler.\nYou also need to install Python and pyelftools.\nNote The rkbin is a \u0026gt;5GB download! This will take some time to clone and process the deltas. git clone -b quartz64 https://gitlab.com/pgwipeout/u-boot-rockchip.git git clone -b rkbin https://github.com/JeffyCN/rockchip_mirrors.git rkbin cd u-boot-rockchip # If using Arch Linux, export CROSS_COMPILE=aarch64-linux-gnu- export CROSS_COMPILE=aarch64-none-linux-gnu- make rk3566-quartz64_defconfig ./make.sh In the current version (current as of 2022-01-02), there might have to be made a change to one line to get a clean compilation:\ndiff --git a/lib/avb/libavb/avb_slot_verify.c b/lib/avb/libavb/avb_slot_verify.c index 123701fc3b..64a1ce6450 100644 --- a/lib/avb/libavb/avb_slot_verify.c +++ b/lib/avb/libavb/avb_slot_verify.c @@ -296,7 +296,7 @@ static AvbSlotVerifyResult load_and_verify_hash_partition( bool image_preloaded = false; uint8_t* digest; size_t digest_len; - const char* found; + const char* found = NULL; uint64_t image_size; size_t expected_digest_len = 0; uint8_t expected_digest_buf[AVB_SHA512_DIGEST_SIZE]; For systems where the global python executable points to python2, compilation fails with an error related to pyelftools not being installed (even if it is). To fix this:\ndiff --git a/make.sh b/make.sh index 2bba05b4e4..cfe5b0afd5 100755 --- a/make.sh +++ b/make.sh @@ -758,7 +758,7 @@ function pack_fit_image() fi if [ \u0026#34;${ARM64_TRUSTZONE}\u0026#34; == \u0026#34;y\u0026#34; ]; then - if ! python -c \u0026#34;import elftools\u0026#34; ; then + if ! python3 -c \u0026#34;import elftools\u0026#34; ; then echo \u0026#34;ERROR: No python \u0026#39;pyelftools\u0026#39;, please: pip install pyelftools\u0026#34; exit 1 fi You can now download u-boot onto the PineNote:\n./rkdeveloptool boot ../u-boot-rockchip/rk356x_spl_loader_v1.08.111.bin This should output \u0026ldquo;Downloading bootloader succeeded\u0026rdquo;.\nWe can now verify that this worked using e.g. the \u0026ldquo;read flash info\u0026rdquo; command:\n./rkdeveloptool read-flash-info Note Section needs to be finished Creating a mainline boot image You can create a filesystem image that replaces the Android boot or recovery partition by doing roughly the following:\nErase boot and dtbo with rkdeveloptool or fastboot (back them up first!!!) Create an ext2 partition image and mount it (fallocate, mkfs.ext2) Build your mainline kernel Copy the kernel, dtb and an initramfs to the root of the mounted image (use any old postmarketOS initramfs) Create a file in the root of the mounted image called extlinux.conf as described below Unmount the image and then use rkdeveloptool to flash it to the \u0026ldquo;recovery\u0026rdquo; partition on the pinenote (it’s about the right size until we get around to replacing the partition layout). Using fastboot Follow the steps for Creating a mainline boot image, but instead of flashing it with rkdeveloptool, use fastboot. You can enter fastboot in either of two ways:\nUse \u0026ldquo;reboot bootloader\u0026rdquo; from adb or a UART console or get a U-Boot prompt and run fastboot usb 0. Booting Linux Warning This page is only relevant for the first batch of PineNotes (December 2021)! The second batch of PineNotes (October 2024) come with Linux pre-installed! To boot Linux, the stock U-Boot has to be patched.\nHere the method from charasyn is used, based of work from Dorian as credited in the script. We’ll use the script to pull the U-Boot environment out of the stock U-Boot partition. We’ll then apply the patch, recreate the image, add a configuration file, and flash the new image to the PineNote.\nSteps to patch U-Boot Get the patch and the Python tool:\n$ mkdir pinenote-uboot \u0026amp;\u0026amp; cd pinenote-uboot $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/boot-menu.patch -o boot-menu.patch $ curl https://gist.githubusercontent.com/charasyn/206b2537534b6679b0961be64cf9c35f/raw/cc513998a36fac0cea266260e3ca3e64abfe3696/pinenote-uboot-envtool.py -o pinenote-uboot-envtool.py $ chmod o+x pinenote-uboot-envtool.py Write your U-Boot partition to an image file: dd if=/dev/mmcblk0p1 of=~/uboot.img\nExtract the environment: ./pinenote-uboot-envtool.py extract uboot.img uboot.env\nPoke around the files (or skip this if you don’t like to learn):\nOpen uboot.env \u0026ndash; see, it’s just text at this point!\nOpen boot-menu.patch to get a feel for how that works\nThe boot-menu.patch makes assumptions about where your Linux partition lives. Specifically, it will look at partition 0x11 (which is 17 in decimal). Change this in boot-menu.patch to reflect where your Linux boot partition lives.\nApply boot-menu.patch: patch uboot.env boot-menu.patch\nNote Note: Might fail with the following error: \u0026ldquo;patch: ****** unexpected end of file in patch at line 27\u0026rdquo;. In that case applying the patch manually is the solution. Rewrite the new environment to the image: ./pinenote-uboot-envtool.py insert uboot.img uboot.env uboot-patched.img Write the image to the boot partition from the PineNote: dd if=~/uboot-patched.img of=/dev/mmcblk0p1 At this point, restarting your system will boot into Android \u0026ndash; this is because the patched U-Boot we’ve just created looks for /boot/which_os.txt to determine whether to boot Android or Linux, and since it can’t find this file (we haven’t made it yet), the bootloader defaults to Android. Create that file on the same boot partition you specified in the boot-menu.patch file, placing an l in the file for Linux. Reboot into Linux Sources and further reading U-boot with rockchip docs Helpful stack overflow to learn a bit about the boot process/terminology This conversation in matrix between pgwipeout, vveapon, and pinenewb about flashing U-Boot. UART Basic non-stock PineNote UART dongle\nThe USB UART dongle delivered with the PineNote allows you to have access to its serial console via USB-C Debug Accessory Mode (DAM) without having to disassemble the device. The factory-installed operating system runs the serial console at the 1,500,000 bps speed, 8 data bits and 1 stop bit, no parity, and no flow control. The USB-C male end should go into the PineNote and the female end can be connected with a standard USB-C cable to your computer.\nIt is relatively easy to build your own UART interface with a USB-C breakout board (for example https://www.ebay.com/itm/275407037613), two resistors and a 3.3V USB serial adapter. It is basically just two 1K pull up resistors (R3, R4), the data sheet values of 10K isn’t whats on the real hardware, see the schematic. The pull ups enable the serial output on SBU1 and SBU2 you can use with any 3.3V USB serial adapter.\nThe UART dongle is not necessary to flash the PineNote, but is essential if something goes wrong to fix it without having to open the case.\nThis page contains information on creating and using a UART dongle for the PineNote. The PineNote was shipped with a compatible UART dongle, but replacements are not available to order in case of loss or hardware fault. Thankfully it is not difficult to make your own from easily-acquired components and a small bit of soldering.\nFear not if you’ve never soldered anything before! This serves as an excellent first soldering project. Borrow the tools from a friend, local hackerspace, or tool library. Pine64 also makes a nice soldering iron themselves, the Pinecil.\nA PineNote UART dongle enables you to:\nInteract with the system boot menu Read system events in real time as the PineNote is used Fix the PineNote without opening the case if something goes wrong while flashing it Since the PineNote is an embedded system, interfacing with it during boot is more complicated than with an ordinary computer. The UART dongle enables you to do this.\nThe PineNote factory firmware runs UART at a baud rate of 1500000 bps, 8 data bits, 1 stop bit, no parity and no flow control. The process by which the PineNote design was modified to include closed-case UART is documented here.\nStock dongle The stock UART dongle included with the PineNote was a simple device plugging directly into the PineNote’s USB-C port. The dongle exposed a female USB-C port, which the user plugged into to get UART access. This design unfortunately ruled out passthrough USB connections, where the user connects to the PineNote via UART and USB simultaneously. The dongle is not currently available for purchase.\nFront\nBack\nCreating a dongle A typical self-built PineNote UART dongle design has the following components:\nA USB-C breakout board with a male connector exposing the 24 pins of the PineNote’s USB-C port A USB-UART adapter, to plug into a USB port of the computer you’ll use to interface with the PineNote Jump wires to connect specific breakout board pins to pins on the USB-UART adapter Two 1,000 Ohm through-hole resistors to splice into the jump wires Electrical tape or heat shrink to wrap connectors and prevent shorts You will also need the following tools:\nSoldering iron with solder Wire cutters \u0026amp; strippers The PineNote’s internal UART system is documented in this schematic. The purpose of all 24 USB-C pins is documented on the USB-C Wikipedia page.\nWe are interested in three sets of pins:\nThe SBU1 (A8) and SBU2 (B8) side band use pins The CC1 (A5) and CC2 (B5) configuration channel pins The GND ground return pins (A1, A12, B1, and B12) In the PineNote UART schematic you can see (on the bottom right diagram labeled USB_TYPEC_Male) the side band pins are given the labels UART2_TX_SUB1 for A8 and UART2_RX_SUB2 for B8. The first (TX) is used for transmitting data and the second (RX) is used for receiving data, from the perspective of the PineNote. Also note the configuration channel pins labeled TYPEC_CC1 for A5 and TYPEC_CC2 for B5. The diagram shows they must be connected to a 3.3V source in parallel, mediated by resistors. Per the USB-C standard, when these pins are pulled high this indicates the device should enter Debug Accessory Mode; connecting them to a voltage source \u0026amp; limiting the current with pull-up resistors accomplishes this. The schematic indicates 10,000 Ohm resistors, but community member Visti Andresen (talpadk) experimented and found 1,000 Ohm resistors work better. Our mission is to wire up pins from a USB-UART adapter to a USB-C breakout board following these requirements.\nBuying components There are many possible USB-C breakout board designs available for purchase online. One particularly useful design is a \u0026ldquo;passthrough\u0026rdquo; or \u0026ldquo;intercept\u0026rdquo; style, with both male and female USB-C ports. This design is more versatile in case you want to reuse it in other projects, and also enables you to connect to the PineNote via UART and USB at the same time. An example of this product can be found here, although you are encouraged to shop around for cheaper options. If you’re fine with a bit more soldering, there is a very cheap one here.\nSimilarly, there are many USB-UART adapter designs available. These devices plug into your computer and expose a number of pins themselves, connecting to specific pins on the breakout board with jump wires. It is important to get a 3.3V model, or at least a model with the option of 3.3V, as a 5V source might fry the PineNote. Here is one example with jump wires included, although you are again encouraged to shop around for alternatives.\nAll other necessary components of our UART dongle are readily \u0026amp; cheaply available in many locations.\nSplicing resistors The desired end result; wrap removed from resistors for illustration purposes.\nThis is the only difficult part of the whole process. Your goal is to create a Y-shaped jump wire with 1,000 Ohm through-hole resistors spliced into each of the twin arms. The solitary leg will connect to a 3.3V source on your USB-UART adapter. The twin arms will connect to the configuration channel pins on your USB-C breakout board. Per the USB-C standard, when these pins are pulled high this indicates the device should enter Debug Accessory Mode; connecting them to a voltage source \u0026amp; limiting the current with pull-up resistors accomplishes this.\nFor this project you’ll need:\nA soldering iron with solder Wire cutters \u0026amp; strippers 2x jumper wires, male/female as compatible with your board designs 2x 1,000 Ohm through-hole resistors Electrical tape or heat shrink wrap Consider buying extra jumper wires and resistors in case you mess up. Also double-check that you have 1K resistors with this color code calculator. Although the PineNote UART schematic says to use 10K Ohm resistors, community member Visti Andresen (talpadk) experimented and found 1K is more appropriate.\nAssemble your Y-cable as follows:\nGraft one jump wire onto the other to form a Y shape using this technique, ensuring solitary leg end is compatible with your USB-UART adapter Splice resistors into the twin arms using this technique Splice remaining jump wire onto the ends of the resistors, ensuring ends are compatible with your USB-C breakout board Cover all exposed wire \u0026amp; resistors with electrical tape or heat shrink wrap Assembly Once you have acquired all necessary components, assemble the UART dongle as follows:\nConnect a jump wire from the GND pin on the USB-UART adapter to any one of the four GND pins on the USB-C breakout board (A1, A12, B1, or B12) Connect a jump wire from the RXD pin on the USB-UART adapter to the UART2_TX_SUB1 SBU1 pin on the USB-C breakout board (A8) Connect a jump wire from the TXD pin on the USB-UART adapter to the UART2_RX_SUB2 SBU2 pin on the USB-C breakout board (B8) Connect your Y-shaped jump wire from the 3.3V source pin on the USB-UART adapter to the CC1 and CC2 pins on the USB-C breakout board (A5 and B5) Wrap all metal connectors in electrical tape or heat shrink to prevent accidental shorts Be very certain of your connections for the 3.3V source and its cable, as there is a real risk of irreparably frying your PineNote if they’re wrong! Especially be sure you are connecting to a 3.3V source and not a 5V source.\nNote that if you mix up the TX/RX pins, it will still work but the USB-C breakout board will just plug into the PineNote upside down. You can therefore choose which orientation you want by swapping the TX/RX pin connections. Experience shows that RX/TX-TX/RX connections will have the PineNote face down while connected, while RX/RX-TX/TX connections will put the PineNote face up.\nUsing the dongle First, use your UART dongle to physically connect your PineNote to your computer:\nPlug the USB-UART adapter into one of your computer’s USB ports Plug the USB-C breakout board into the USB-C port on the bottom of your PineNote; the orientation matters, so try both and remember which one works Once the hardware is connected, we need some program on your computer to communicate over that connection with 1500000 (1.5 million) bps, 8 data bits, 1 stop bit, no parity and no flow control.\nHere’s how you do that:\nIdentify the USB-UART adapter in your /dev directory by running ls /dev with it plugged in, unplugging it, then again running ls /dev and seeing what changed; it is likely to be called /dev/ttyUSB0 Check your permissions; run ls -l /dev/ttyUSB0 to see which groups have access to the dongle (probably dialout or uucp), and add your user to that group; remember you need to log out before group changes take effect Install minicom (or some other option, but the instructions below are written for minicom) In a terminal window, run minicom -D /dev/ttyUSB0 -b 1500000 or run minicom --setup to specify these settings by default Once the software is set up, power-cycle your PineNote; as the system boots you should see text appearing in your terminal window. You can exit the session with ctrl+a x then pressing Enter to confirm. Run man minicom for more details.\nSending commands Pressing ctrl+a in minicom enables you to send keystrokes to your PineNote. The most important of these is ctrl+c, which if sent during boot will put you in the U-Boot command prompt. You can then type help to list possible commands.\nTroubleshooting If you don’t see any text in your terminal as the PineNote boots, or the text is garbled, try the following:\nEnsure your GND, RX/TX, and CC jump wires are connected to the correct pins on both the USB-UART adapter and the USB-C breakout board Connect your USB-C breakout board to your PineNote in the opposite orientation Run minicom as sudo in case your user doesn’t have appropriate permissions Ensure you are setting the baud rate to 1500000 (1.5 million), and (less importantly because these are probably used by default) 8 data bits, 1 stop bit, no parity and no flow control If you can see text but are having trouble sending ctrl+c to the PineNote during boot:\nBe sure you’re typing ctrl+a first, or whatever escape sequence your terminal emulator uses Send it right as the PineNote is booting, before the loading bar appears on screen Double-check your Y-shaped pull-up resistor cable; if this isn’t working properly you’ll probably be able to read text but not send text USB passthrough If your USB-C breakout board has a passthrough/intercept design, you can connect to your PineNote over USB and UART at the same time. This can be useful when you’re doing development work on the PineNote boot process so you don’t have to continually reconnect cables. You’ll need a USB-A to USB-C cable, connecting directly from your computer’s USB-A hub to your USB-C breakout board’s female USB-C port. It’s important to connect directly from USB-A, without any intermediate USB-C components. Note that connecting a live USB cable to your USB-C breakout board in this way dramatically increases the danger of frying your PineNote with a short, so you should only do this if all connectors are safely wrapped in electrical tape.\nApps This page lists applications and tweaks for the PineNote.\nDevelopment Here are some resources you may find helpful in learning to develop on embedded Linux devices:\nGreat YouTube series introducing you to the kernel and lower-level components of Linux: https://www.youtube.com/watch?v=WiZ05pnHZqM https://embetronicx.com/ https://bootlin.com/training/ https://www.nand2tetris.org Emulator recommendation for developing and testing PineNote apps: https://github.com/michaelshiel/picom-epaper\nThe PineNote is a specialized device, mainly due to the e-ink display having unique display and refresh characteristics. Finding and configuring apps that work well sometimes requires a lot of tweaking and a lot exploring, especially for applications containing fast screen updates and animations, as well as depend on a lot of colors.\nHere is a video showing the performance of a few applications.\nDesktop Environments Sway WinkShell \u0026ldquo;Collected applications, configurations and scripts for using a wlroots-based compositor with an EPD (aka e-ink display). Currently supports Sway only.\u0026rdquo; 0cc4m’s config Getting touch + pen working on sway If you notice that touching the screen works, but when you use the pen the mouse coordinates are inverted, don’t worry! We can fix it! Set rockchip_ebc.panel_reflection=0 on boot (see this page for more info). Add the following line to your sway config:\n# This line rotates the mouse input by 180 degrees. See https://wayland.freedesktop.org/libinput/doc/1.11.3/absolute_axes.html input \u0026#34;type:table_tool\u0026#34; calibration_matrix -1 0 1 0 -1 1 Gnome Gnome on wayland runs nicely on the PineNote. However, a slightly patched version of mutter is required at the moment.\nSee this repository for .deb packages and patch/compile files: Patched Debian Mutter for Bookworm The ready-to-use Debian image provides a pre-configured GNOME environment], with specific GNOME configurations found here A GNOME extension is being developed that provides access to some of the ebc-specific driver options. PNEink is a GNOME Theme for use with the PineNote GTK3 High contrast style for e-ink-devices can be found here.\nGTK4 High contrast style for e-ink-devices can be found here.\nApplication support on the PineNote System-Control A rust-based dbus service is being developed to enable easy, system-wide control over some of the PineNote-specific settings by users and programs (e.g., triggering global screen refreshes, changing waveforms, enabling/disabling dithering). Requires this kernel.\nNotetaking Xournal++ Works well. Version 1.2 version offers repainting-related optimizations and supports PDF highlighting as well as links. To remove artifacts from the eraser set the eraser cursor’s visibility to Never via Preferences -\u0026gt; Stylus -\u0026gt; Eraser Visibility. Also, disable GTK3 intertial scroll via Preferences -\u0026gt; Touchscreen -\u0026gt; Touch Scrolling -\u0026gt; Disable GTK’s built-in intertial scroll, as this interferes with Xournal++\u0026rsquo;s internal touch event handling.\nXournal++ uses anti-aliasing and interpolation, which do not work well for the A1 waveform. Mitigations include using either dithering or black-and-white mode in the ebc driver. https://gitlab.com/hrdl/pinenote-shared/-/blob/main/patches/xournalpp/0001-Disable-anti-aliasing-and-use-NEAREST-interpolation-.patch is an outdated patch that used to work well without changing the bw mode.\nPre-compiled Debian packages with some of the PineNote-related modifications and support for triggering global refreshes after scrolling using the dbus service (see above) can be found here\nObsidian Works well, EInk-Theme can be found here.\nReading Foliate Foliate is an ebook reader written in GTK4. It works well with the default Debian Gnome experience. You can bookmark pages and annotate selections of words/sentences. Foliate supports \u0026ldquo;Open EPUB, Mobipocket, Kindle, FB2, CBZ, and PDF files\u0026rdquo;.\nKOReader KOReader is a document viewer made for e-ink devices. It is a feature packed application, a user can highlight text, bookmark pages, use gesture navigation and change font and page size/margins/spacing among many things. KOReader can also be used as a full screen UI with battery information reporting while reading books. KOReader supports \u0026ldquo;EPUB, PDF, DjVu, XPS, CBT, CBZ, FB2, PDB, TXT, HTML, RTF, CHM, DOC, MOBI and ZIP files\u0026rdquo;.\nWeb Browsing Firefox Pretty good experience! Enabling GPU acceleration is helpful.\nGPU Acceleration in Firefox See 0ccam’s notes here.\nCloud syncthing High contrast theme can be found here.\nGames Generating crosswords There are some scripts here for generating crosswords for the Pinenote from IPUZ files.\nSoftware tweaks Fixing Bluetooth Some users have noticed instability with their wireless driver. Upgrading the driver to the version provided by LibreELEC may help! To do this, download the BCM4345C0.hcd, brcmfmac43455-sdio.bin, and brcmfmac43455-sdio.txt from the libreELEC repositories and place them in the same location as your previous firmware (/lib/firmware/brmc/). Then rename brcmfmac43455-sdio.{txt,bin} as brcmfmac43455-sdio.pine64,pinenote-v1.2.{txt,bin}. If this doesn’t help, ask about it in the matrix chat!\nPreliminary fix for stuttering bluetooth audio Following a fix used for the Quartz Model A (which uses the same SoC as the Pinenote), we can modify the device tree prior to building the kernel to try to mitigate poor Bluetooth audio streaming. (reference: see https://lore.kernel.org/linux-arm-kernel/20220926055435.31284-1-leo@nabam.net/T/)\nSteps:\nOpen arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi Go to line 939, \u0026ldquo;bluetooth\u0026rdquo;, under the \u0026ldquo;uart1\u0026rdquo; section Edit the two lines that read \u0026ldquo;device-wake-gpios\u0026rdquo; and \u0026ldquo;host-wake-gpios\u0026rdquo;; you want them to read \u0026ldquo;device-wakeup-gpios\u0026rdquo; and \u0026ldquo;host-wakeup-gpios\u0026rdquo; respectively Add the following line to the end of the bluetooth section (under the vddio-supply line in my .dtsi): \u0026ldquo;max-speed = \u0026lt;3000000\u0026gt;;\u0026rdquo; Count your zeros, don’t forget your punctuation.. Caveats:\nThis will improve BT audio quality at least when using the AAC codec. In my experience, the quality is more than acceptable, but there are still issues apparent: occasional isolated stutters even on AAC; prohibitively frequent stutters on SBC-XQ remain. Fully resolving BT audio issues might require further changes similar to the one described above, or may alternatively be a matter of audio software settings (e. g., process priority, audio server buffer settings). Investigation ongoing.\nlibinput Palm Detection See https://gitlab.com/hrdl/pinenote-shared/-/blob/main/etc/libinput/local-overrides.quirks.\nlibinput Touch Arbitration Prerequisites: libinput\u0026gt;1.22.1 and setup touch arbitration via udev: https://gitlab.com/hrdl/pinenote-shared/-/blob/main/etc/udev/rules.d/81-libinput-pinenote.rules\nIssues and workarounds No resolution reported by touchscreen driver. Workaround: patch cyttsp5.c and device tree: https://gitlab.com/hrdl/linux/-/commit/f1f9eb197d3bd88c9189ab9d8fba2d03d2e13960 or set device quirk AttrSizeHint=210x157. Touch screen arbitration is independent of the screen’s rotation. Workaround: use AttrEventCode=-ABS_TILT_X (on older version: AttrEventCodeDisable=ABS_TILT_X) in a libinput quirk matching w9013 2D1F:0095 Stylus. This makes touch arbitration independent of the pen’s location. Further information Specification\nSoC and memory specifications\nSchematics and certifications\nDatasheets\nClosed case UART\nDisassembly and Parts Replacement\nPress\nSpecification General Information Dimensions: 191.1x232.5x7.4mm Weight: 438g Core CPU: RK3566 1.8GHz 64-bit quad-core A55 GPU: MALI G52 2EE System memory: 4GB LPDDR4 Flash: 128GB eMMC E-ink Display Size: 10.3\u0026quot; Resolution: 1404x1872 DPI: 227 Grayscale: 16 Front Light: 36 level cold and warm Capacitive multi-touch panel EMR pen digitizer Network WiFi: 2.4/5GHz 802.11a/b/g/n/ac Bluetooth: 5.0 Audio Built in stereo speakers 4 x DMIC microphone Sensor G-Sensor for portrait and landscape sensing Power 4000mAH LiPo battery DC 5V @ 3A USB-C connector Accessories December 2021 batch: Optional EMR pen with magnetic attachment (included in the first production batch) October 2024 batch: Optional passive pen Optional Cover (included in the December 2021 and October 2024 batch) SoC and memory specifications The PineNote is based on the Rockchip RK3566.\nCPU Architecture Quad-core ARM Cortex-A55@1.8GHz AArch32 for full backwards compatibility with ARMv7 ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation Includes VFP hardware to support single and double-precision operations ARMv8 Cryptography Extensions Integrated 32KB L1 instruction cache and 32KB L1 data cache per core 512KB unified system L3 cache TrustZone technology support 22nm process, believed to be FD-SOI GPU (Graphics Processing Unit) Capabilities Mali-G52 2EE Bifrost GPU@800MHz 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop 128KB L2 Cache configurations Supports OpenGL ES 1.1, 2.0, and 3.2 Supports Vulkan 1.0 and 1.1 Supports OpenCL 2.0 Full Profile Supports 1600 Mpix/s fill rate when at 800MHz clock frequency Supports 38.4 GLOP/s when at 800MHz clock frequency NPU (Neural Processing Unit) Capabilities Neural network acceleration engine with processing performance of up to 0.8 TOPS Supports integer 8 and integer 16 convolution operations Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet System Memory RAM Memory: 4GB LPDDR4. Flash Memory: 128GB eMMC Schematics and certifications PineNote Developer kit version Version v1.2 is the PineNote production version that was sold through the Pines64 store\nPineNote Mainboard Schematic ver 1.2 20210824 PDF file PineNote USB-C Daughter Board Schematic ver 1.0 PDF file PineNote USB-C Console UART Breakout Board Schematic ver 1.0 PDF file Note: When building USB-C console breakout board, please be aware 10k CC pin pull-up is too weak to pull CC to logically high level. Replacing it to lower resistance, such as 1k is recommended. The v1.1 is early release schematic just for reference only and used by developers who received the prototype.\nPineNote early released Schematic ver 1.1 20210726 PDF file PineNote early released ver 1.1 20210726 PCB Connector placement PDF file Certifications:\nPineNote FCC-15C Certificate PineNote FCC-15E Certificate PineNote CE RED Certificate PineNote ROHS Certificate Datasheets Rockchip RK3566 SoC information:\nRockchip RK3566 ver 1.0 datasheet, release permission from Rockchip Rockchip RK817 PMU (Power Management Unit) Information:\nRockchip RK817 version 1.01 datasheet LPDDR4 (200 Balls) SDRAM:\neMMC information:\nBiwin 128GB eMMC model: BWCTASC41P128G E-ink Panel information:\nE-Ink 10.3\u0026quot; 1872x1404 ED103TC2 Glass Panel Specification TPS65185x PMIC for E-Ink Enabled Electronic Paper Display Datasheet Touch Screen information:\nCypress CYTMA448 multi-Point Capacitive Touch Controller Datasheet Wacom Pen Digitizer Unit Model: SUDE-10S15MI-01X for 10.3\u0026quot; Display Module WiFi/BT module information:\nAzurewave CM256SM 11AC WiFi + Bluetooth5.0 Datasheet] G Sensor information:\nSilan SC7A20 3-Axis MEMS Accelerometer Audio Amplifier information:\nAwinic AW87318 Class-K Audio Amp Datasheet Closed case UART Closed case debugging was brought up during a week of community schematic review of the PineNote. This page documents the discussion of this proposed issue and its resolution.\nDates on this page are relative to UTC-5.\nBackground When debugging bootloader and kernel initialization on a new hardware platform, a hardware UART is indispensable. The PineNote 1.1 required taking the device apart to access a hardware UART broken out on the motherboard. This did not seem tenable long-term, as developers usually don’t like taking their devices apart to debug bootloaders. Therefore, it is important to provide resources to debug the PineNote’s boot process such as a hardware UART.\nRecent PINE64 devices have included a hardware UART connected to their 3.5mm TRRS jacks through a hardware switch. However, the PineNote doesn’t have an audio jack. It also doesn’t have a convenient place to put a hardware switch which is accessible without taking the device apart. The case only has the affordance for a single USB-C port.\nDiscussion August 15, 2021 We decided to ask the PineNote product team to explore USB-C Debug Accessory Mode, where the product changes the USB-C port’s personality when both CC1 and CC2 are pulled high. In normal usage, either CC1 or CC2 will be floating since these are the connector rotation pins. When both are detected, there is a very good chance that a debug harness is connected.\nThis decision requires the PineNote motherboard to be able to detect an AND condition between CC1 and CC2 and connect one of the SOC’s UARTs to pins on the USB-C connector. In all other cases, the UART should be disconnected. It also requires the PINE64 Store ship a simple one-sided (no magical flipping here, sorry) connector board which breaks out USB 2.0 and UART.\nAugust 16-18, 2021 There were concerns that cheap USB-C cables have both CC1 and CC2 shorted together to save a wire. This may cause the PineNote to output 3.3v UART to a device that isn’t expecting it, assuming the two are plugged together with a nonstandard cable. This seems unfounded (or not enough of a problem to worry about on a large scale), since the USB-C specification states in section B.2.3.1, \u0026ldquo;The general concept for setting up a valid connection between a DTS and TS is based on being able to detect the typical USB Type-C termination resistances. However, detecting a Debug Accessory Mode connection requires that both CC pins must detect a pull-up (Rp) or pull-down (Rd) termination. A USB Type-C Cable does not pass both CC wires so a receptacle to receptacle Debug Accessory Mode connection cannot be detected.\u0026rdquo;\nThere were concerns that checking CC1 and CC2 being pulled high was not strictly to USB-C standard, as detecting them being pulled low is mentioned in the standard. However, detecting a pull-up condition is all that is required. According to the USB-C spec, \u0026lsquo;B.2.4.1.5.1 (\u0026ldquo;UnattachedDeb.SRC Requirements\u0026rdquo;), a Debug and Test System (DTS) that is a power source must pull CC1/CC2 up, while the Target System (TS) in Unattached.SNK is supposed to pull them low.\u0026rsquo; In English, this means that we’d only need to detect a pull-up condition on CC1 and CC2, meaning a logical AND between them is a sane solution.\nIt should be possible to make the UART connection and breakout cable magically flippable by connecting the UART multiple times to the USB-C port.\nResolution This proposed circuitry is added to the PineNote v1.1 schematic\nOn August 19, 2021, TL posted the results of the hardware team’s efforts. This includes \u0026ldquo;PineNote USB-C DAM Schematic Addition.png\u0026rdquo;, shown on this page, as well as the following additional documentation:\nDatasheet for ON Semiconductor NS5S1153 USB-C USB 2.0 and Audio Switch. Additionally, the hardware team proposed designing a breakout board with pull-up resistors on CC1 and CC2 and the appropriate UART signals routed to headers on the board. Then a developer can bring their own USB TTL adapter. They almost definitely have at least one, or could access one for a low price.\ndsimic commented that this proposed layout meant that a Google-designed SuzyQable would not work for debugging the PineNote. This was deemed acceptable, as long as it is clear to developers that the combination of PineNote and SuzyQable will not result in any useful debugging abilities.\nCaleb commented that the Google Pixel series of devices bring out UART over the SB1 and SB2 pins on the USB-C connector. It was surmised that copying this layout would allow reusing hardware that developers already have, however there are no harnesses on the market that directly break out this interface. Instead, it seems that most developers use a USB-C breakout board and stuff wires in the appropriate place when needed[https://github.com/Peter-Easton/android-debug-cable-howto]. A similar approach could be taken with the proposed PineNote solution if someone did not wish to purchase the breakout board.\nDisassembly and Parts Replacement Battery replacement See writeup on the wiki: https://wiki.pine64.org/wiki/PineNote/Battery_Replacement\nUSB-C Sideboard replacement The USB-C Sideboard is one of the few replacement parts available from the Pine64 Store: https://pine64.com/product/pinepmote-usb-c-side-board/\nStarting at the top of the device, and continuing around the top corners and down the sides, pry the back case away from the face of the device. A pry tool may be useful, though it has been reported possible to do with bare fingers. Like any plastic-clipped case, it requires gentleness while at other times significant force to remove the back panel. See Battery Replacement guide above for another description. Flip the device over and locate the USB-C Sideboard on the very bottom. It looks just like the replacement! It is connected by a small ribbon, gently lift the retaining flap on the connector to release the ribbon cable, and slide the cable out. Two shallow phillips screws secure the sideboard, unscrew them, replace the sideboard with new one, screw the replacement in place. Note a very pointy screwdriver will not work, the screw does not have much depth to it and requires a relatively blunt screwdriver head. Gently replace the ribbon and press retaining flap down to secure the ribbon. Test the new USB-C by connecting a cable to power or data and make sure the tablet responds before replacing the back case. Without putting any pressure on the new USB-C connection, line it up with the bottom of the device and firmly press in bottom edge and corners of the device back into the casing with audible click. Firm pinching with your whole hand up the edge of the case should easily click the entire case back into place. Test that the power/sleep button functions and the case is flush everywhere. Press Vector images and pictures for the PineNote you can freely use for projects and press inquiries. Attribute the author if attribution is required via the license (such as CC BY and CC0).\nBackgrounds Background ideas:\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\n","permalink":"/documentation/PineNote/_full/","tags":null,"title":"PineNote (Single Page)"},{"categories":null,"contents":"The Matter-certified Pinenut-01M module offers a digital output control and embedded with unique Matter certificate. User can use this ready to use module to perform IOT control (default one output and can configure up to three outputs) interoperate within Matter Home Automation network. Each module comes with unique QR code for Matter pairing purpose. Please note that this is not a hackable module and no source code provided.\nFeatures Matter-certified Build-in antenna BL602 MCU 4MBytes Flash Size Input power: 3.3V I/O voltage tolerance: 3.6V Max Dimension: 14.3 x 24.8mm ","permalink":"/documentation/Pinenut/Versions/Pinenut-01M/","tags":null,"title":"Pinenut-01M"},{"categories":null,"contents":"The Pinenut-01S module offers a complete and self-contained Wi-Fi and BLE networking solution, allowing it to either host the application or to offload all Wi-Fi and Bluetooth networking functions to another application processor.\nSchematics and GPIO definitions:\nPinenut-01S schematic ver 1.01 PineNut-01S KiCad schematic ver 1.01 Pinenut-01S GPIO Definition ver 1.0 USB Programmer adapter for Pinenut-01S schematic ver 1.0 The default firmware runs the UART at 2000000 bps. It will accept input whilst regularly outputting:\nproc_hellow_entry: RISC-V rv32imafc cur key status:1 ","permalink":"/documentation/Pinenut/Versions/Pinenut-01S/","tags":null,"title":"Pinenut-01S"},{"categories":["IoT"],"contents":" PineNut-01M - Matter-certified The Matter-certified Pinenut-01M module offers a digital output control and embedded with unique Matter certificate. User can use this ready to use module to perform IOT control (default one output and can configure up to three outputs) interoperate within Matter Home Automation network. Each module comes with unique QR code for Matter pairing purpose. Please note that this is not a hackable module and no source code provided.\nFeatures and Specifications Matter-certified Build-in antenna BL602 MCU 4MBytes Flash Size Input power: 3.3V I/O voltage tolerance: 3.6V Max Dimension: 14.3 x 24.8mm Stores Global Affiliates Documentation Pinenut ","permalink":"/devices/pinenut-01m/","tags":null,"title":"PineNut-01S"},{"categories":["IoT"],"contents":" PineNut-01S, an Attempt to Open Source WiFi and BLE module for PINE64 devices The Pinenut-01S module offers a complete and self-contained Wi-Fi and BLE networking solution, allowing it to either host the application or to offload all Wi-Fi and Bluetooth networking functions to another application processor. We are actively working together with the PINE64 community to open source as much as possible of the WiFi and BLE stack of the PineNut. In time, we hope to use the PineNut as base for open Wifi implementations in our flagship devices.\nFeatures and Specifications Built-in antenna Powered by Pineseed BL602 SoC 32-bit RV32IMAFC RISC-V “SiFive E24 Core” 2MB Flash Size Serial/UART baud rate: 115200 bps Input power: 3.3V I/O voltage tolerance: 3.6V Max Eight pin interface, VCC-3V3, GND, RST TXD and RXD. Three extra GPIOs can be used for ADC, PWM, i2C, or UART functions Three built-in LEDs for output and one push button input Dimensions: 14.3 x 24.8mm Built-In Antenna Use the PineNut for a robotics project.\nPineseed BL602 SoC Powered by a Pineseed RISC-V BL602 SoC\nPower Tolerance Input power tolerance range of 3.3V-3.6V\nGPIO Interface Plenty of I/O to allow for greater functionality in your project\nStores Global Affiliates Documentation Pinenut ","permalink":"/devices/pinenut-01s/","tags":null,"title":"PineNut-01S"},{"categories":null,"contents":"The Pinenut-01S USB Programmer is a companion utility for Pinenut-01S: an USB-to-serial adapter that converts the USB interface to a serial port suitable for Pinenut-01S module. The programmer allows the Pinenut-01S module to be plugged into a power bank for potable power application. It has a duplicate GPIO extension port.\nThe Pinenut-01S USB Programmer front\nThe Pinenut-01S USB Programmer back\nThe following operating mode options can be selected: onboard toggle switch, toggling between programming and running operation.\n","permalink":"/documentation/Pinenut/Pinenut-01S_USB_Programmer/","tags":null,"title":"Pinenut-01S USB Programmer"},{"categories":null,"contents":"The Pinenut-12S module is a Wi-Fi and BLE5 Stamp.\nUnlike the Pinenut-01S, the Pinenut-12S is castellated, allowing it to be directly soldered onto a carrier board.\nFeatures:\nBuild-in PCB antenna Powered by Pineseed BL602 SoC 2MBytes Flash Serial/UART baud rate: 115200 bps Input power: 3.3V I/O voltage tolerance: 3.6V Max Eleven GPIOs can be used for ADC, PWM, i2C, UART and SPI functions Dimension: 16 x 24×3.1mm GPIO definition: Pinenut-12S GPIO Definition ver 1.0\nThe onboard LED is connected to IO0.\n","permalink":"/documentation/Pinenut/Versions/Pinenut-12S/","tags":null,"title":"Pinenut-12S"},{"categories":["IoT"],"contents":" Pinenut Model-12S Wi-Fi/BLE5 Stamp The Pinenut-12S module is a Wi-Fi and BLE5 Stamp.\nUnlike the Pinenut-01S, the Pinenut-12S is castellated, allowing it to be directly soldered onto a carrier board.\nFeatures and Specifications Build-in PCB antenna Powered by Pineseed BL602 SoC 2 MBytes Flash Serial/UART baud rate: 115200 bps Input power: 3.3V I/O voltage tolerance: 3.6V Max Eleven GPIOs can be used for ADC, PWM, i2C, UART and SPI functions Dimension: 16 x 24×3.1mm Stores Global Affiliates Documentation Pinenut ","permalink":"/devices/pinenut-12s/","tags":null,"title":"PineNut-12S"},{"categories":["Phones"],"contents":" An Open Source Smartphone Supported by All Major Linux Phone Projects The PinePhone is a smartphone that empowers users with control over the device. It is capable of running mainline Linux, features hardware privacy switches, and is designed for open-source enthusiasts. Powered by the same quad-core ARM Cortex A53 64-Bit SoC used in our popular PINE A64 Single Board Computer, the PinePhone runs mainline Linux as well as anything else you’ll get it to run.\nThe purpose of the PinePhone isn’t only to deliver a functioning Linux phone to end-users, but also to actively create a market for such a device, as well as to support existing and well established Linux-on-Phone projects. All major Linux Phone-oriented projects, as well as other free and open source operating systems, are represented on the PinePhone and developers work together on our platform to bring support to this community-driven device.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.152 GHz GPU ARM Mali 400 MP2 GPU Memory 2GB / 3GB LPDDR3 RAM Display 5.95″ LCD 1440×720, 18:9 aspect ratio (hardened glass) Storage Bootable microSD 16GB / 32GB eMMC Modem Quectel EG25-G with worldwide bands Wi-Fi Built-in 802.11 b/g/n WiFi Bluetooth Bluetooth 4.0 Navigation GNSS: GPS, GPS-A, GLONASS Cameras Selfie and Main camera (2/5Mpx respectively) Main Camera Single OV5640, 5MP, 1/4″, LED Flash Selfie Camera Single GC2035, 2MP, f/2.8, 1/5″ Sensors Accelerator, gyro, proximity, compass, ambient light 3 External Switches volume up, volume down, and power Privacy switches LTE/GNSS, WiFi, Microphone, Speaker, Cameras Video HD digital video out USB USB Type C (Power, Data and Video Out) Vibration motor Light RGB status LED Extensibility Six pogo pins allowing for custom hardware extensions such as a thermal camera, wireless charging, NFC, a extended battery case, or keyboard case Battery Samsung J7 form-factor 3000mAh battery Case Case is matte black finished plastic Headphone jack Extensibility You can use the PinePhone’s six pogo pins to add a variety of attachments such as a keyboard or wireless charging case\nConvergence Hooked up to a external monitor the PinePhone can used as a small low-powered portable computer\nRepairability You can find parts for the PinePhone on the store to fully repair or upgrade your device\nPrivacy Five hardware switches allow you to disable the cameras, microphone, WiFi and Bluetooth, and the LTE modem\nStores Global Global: Accessories Global: Spare parts Affiliates Documentation PinePhone Schematics and certifications Accessories PinePhone (Pro) Keyboard The keyboard add-on for the PinePhone and PinePhone Pro adds a physical keyboard and a large battery. LoRa Add-on A LoRa add-on which uses the pogo pins to interface a Semtech SX1262 LoRa module Qi Wireless Charging Add-on A Qi wireless charging add-on which ses the pogo pins to supply Qi Wireless and Wireless Power Consortium compatible charging. No software required. Fingerprint Reader Add-on A fingerprint reader add-on which uses the pogo pins to interface a high quality fingerprint sensor, uses open firmware for it’s i2c bridge, and can also be used for gesture navigation. USB-C Docking Bar An USB-C docking bar adding an ethernet port, two USB ports, an HDMI port and a power input. TPU Protective Case A soft TPU protective case. Serial Cable Serial console powered by CH340 chipset enables USB-to-Serial-communication through the earphone jack for development. Battery Charger An external charger for the battery. Flex Break-out Board A flexible break-out PCB for i2c IO expansion. Tempered Glass Screen Protector 9H hardness tempered glass screen protector specially designed for the Pinephone and PinePhone Pro.. Resources YouTube: ShortCircuit review of the PinePhone YouTube: PinePhone Beta edition quickstart guide YouTube: A showcase of a early developer unit of PinePhone keyboards which interfaces with the pogo pins ","permalink":"/devices/pinephone/","tags":null,"title":"PinePhone"},{"categories":null,"contents":" The PinePhone is a smartphone created by PINE64. It is capable of running mainline Linux and is supported by many partner projects.\nThe Braveheart Edition of the PinePhone was the first publicly available version of the phone. It shipped without a fully functional operating system and was geared specifically towards early adopters. The Braveheart Edition’s successors were the Community Editions, which featured a branded backcover and box of selected community projects. The Community Editions became available in June 2020. The Beta Edition featuring Manjaro with Plasma Mobile is the latest edition, it became available in March 2021.\nIntroduction The PinePhone is not a regular phone and you might not get the latest and greatest hardware and this years\u0026rsquo; newest innovation. You will get a device with good mainline support with a great community behind it.\nState of the software First things first, the PinePhone is aimed solely at early adopters - more specifically, the units are solely intended to find their way into the hands of users with extensive operating system experience.\nBear in mind that the software for these smartphones is very early, with most of the software being in alpha or beta state. That’s especially also the case for scalability of applications, their availability and practicability, any hardware function implementations and the firmware. The software is provided as is. There is no warranty for the software, not even for merchantability or fitness for a particular purpose.\nIf you have any questions regarding the current state of the software or of specific features working, please don’t hesitate to ask in the community chat (see Main Page)!\nHelp and support Still have any questions regarding software, shipping, or ordering after reading this wiki? Please don’t hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See Main Page.\nPlease keep in mind that PINE64 is not like a regular company (see the PINE64 philosophy) and that support resources are limited - the best way to get support quickly is to ask in the community chat! Please only contact the PINE64 support directly if questions couldn’t be solved via the community chat or this wiki.\nGetting started A protection foil isolates the battery for the shipping.\nWhen shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery will not charge or boot until it is removed and the battery is connected again.\nNote To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery. The PinePhone’s SIM slot only accepts a micro-SIM, please do not insert a nano-SIM without an adapter and make sure that the nano-SIM does not get released from its adapter. The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot.\nNote Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them! The microSD belongs in the upper slot, the micro-SIM in the lower slot.\nAn adapter from a nano to a micro-SIM might be included under tape in the camera notch of the phone’s packaging. Some nano-SIMs will not fit firmly into that adapter that comes with the PinePhone and if the included adapter is used without a well-fitting nano-SIM, the contact pins might get damaged. In that case it is highly recommended to acquire a better fitting adapter.\nInstallation To learn more about the boot priority on the PinePhone, click on boot priority.\nThe installation instructions can be found here:\nInstallation to the microSD card Installation to the eMMC The releases for the PinePhone can be found under Releases.\nBoot priority The PinePhone always boots from the microSD card first. It is therefore recommended to have a microSD card handy. It is not possible to lock themself out of the phone when the installation on the internal storage (the eMMC) fails, as a correctly flashed microSD card will always boot. Note: Booting from USB is not supported by the hardware, a live USB stick will not boot.\nThe phone will also try to boot from microSD cards, which were previously flashed with an OS and formatted later, causing the phone to fail to boot. See reuse microSD card on how to format the microSD card properly, including wiping the residues of u-boot.\nInstallation to the microSD card For this installation method you need a microSD card, a microSD card reader and a compatible device, such as a computer or a laptop with Linux, iOS, Windows or similar (note: ChromeOS is not supported).\nTo install an image to the microSD card:\nDownload your chosen image from Releases for the regular PinePhone (not compatible with the PinePhone Pro). Extract the compressed file Write (flash) the image to your microSD card, see the instructions below Plug microSD card into phone (make sure to use the top slot, not the bottom slot) Boot up the phone The microSD belongs in the upper slot, the micro-SIM in the lower slot.\nUsing Balena Etcher Using the graphical application Balena Etcher to flash the microSD card is \u0026lsquo;recommended\u0026rsquo; for new or inexperienced users.\nDownload and install the application: https://etcher.balena.io/#download-etcher\nThen start it and click the button Flash from file:\nSelect the downloaded image and make sure that you downloaded the correct one. Images for the PinePhone and the PinePhone Pro are \u0026rsquo;not compatible\u0026rsquo; with each other. Images for the PinePhone typically have the word \u0026ldquo;PinePhone\u0026rdquo; in the filename, while images for the PinePhone Pro typically have \u0026ldquo;PinePhone Pro\u0026rdquo; in their filename.\nNote At this the image file does not have to be extracted from the archive format. Balena Etcher handles the extracting automatically. Then click on Select target:\nNote Make sure to select the correct target by comparing the name and the disk capacity with the label on the microSD card. Then click on Flash!:\nThat’s it!\nUsing dd For flashing the microSD card, the command dd can be used as well.\nMake sure to select the correct device using lsblk. Then run dd with the selected device:\nsudo dd if=IMAGE.img of=/dev/[DEVICE] bs=1M status=progress conv=fsync\nNote The image needs to be written to the whole device, not to partition 1. Make sure you’re NOT selecting /dev/sda1 or /dev/mmcblk0p1 as target. Using bmaptool Make sure to select the correct device using lsblk. Then run bmaptool with the correct device:\nDownload the IMAGE.xz and the IMAGE.bmap files, then run:\nbmaptool copy --bmap IMAGE.bmap IMAGE.xz /dev/[DEVICE]\nThis takes around 2.5 minutes to flash a 4 Gb file.\nUsing Gnome Disks The graphical application Gnome Disks can be used to flash the microSD card as well.\nTo do so, select the correct device in the left device selection, then click on the three dot menu and select Restore Disk Image\u0026hellip; and follow the on-screen instructions.\nInstallation to the eMMC The internal memory of the PinePhone (eMMC) can be flashed using multiple different methods.\nFrom the booted microSD OS Flash an OS to the microSD card (and optionally resize the partition, see below) Insert microSD card and boot the phone Download the desired OS\u0026rsquo; image on the booted OS or transfer it to the microSD card Extract the image file if it is archived Flash the image file to eMMC using dd if=IMAGE.img of=/dev/mmcblkX bs=1M conv=fsync where X is the number label of the eMMC (of the disk, not the partition!). Use the command lsblk to check your devices: typically with the current kernel the microSD card is /dev/mmcblk0 and the eMMC is /dev/mmcblk2 but as always with dd be extremely cautious to get the devices correct. Turn off phone, remove microSD card and then turn on the phone. Using JumpDrive Note This only applies to the regular PinePhone, not the PinePhone Pro. Jumpdrive running on the PinePhone\nThe internal eMMC flash storage can be flashed using the Jumpdrive utility by Danct12 and Martijn from postmarketOS. This utility boots from micro SD and exposes the internal eMMC flash storage when the PinePhone is connected to a computer. The process of flashing an OS to the exposed and mounted eMMC is identical to that of any other storage medium - e.g. a microSD card. You can use the dd command or a utility such as Etcher or Gnome Disks, etc.\nLatest Jumpdrive can be found here.\nDownload and extract the Jumpdrive image Flash the Jumpdrive image to a microSD card Boot the PinePhone from the Jumpdrive microSD card Connect the PinePhone to your computer using USB-A -\u0026gt; USB-C cable Flash the exposed PinePhone drive (e.g. /dev/mm\u0026hellip;, check for the right device in dmesg, GNOME disks, or similar, and make sure it’s unmounted) with your chosen OS image Once the flashing process is complete, disconnect the PinePhone from your PC, power it down and remove the Jumpdrive microSD card The process is now finished, and you can boot from eMMC The Jumpdrive image is smaller than 50MB. You can keep an microSD card specifically for using Jumpdrive, and there are 64MB microSD cards sold cheaply that will suffice. Jumpdrive also acts as a rescue image in case if you messed up your installation. To do so, you can telnet to 172.16.42.1, mount rootfs and fix it!\nSD to eMMC via installer An special installer image booted from the microSD card can be used to flash the eMMC as well. Mobian and postmarketOS installer images booted from microSD card will simply ask the user if they want to install to eMMC. The feature lives in the distribution-agnostic calamares-extensions repository (see calamares-extensions#7), so other distributions might adopt this in the future.\nUsing Tow-Boot Tow-Boot is an opinionated distribution of the U-Boot bootloader. It includes an USB Mass Storage Mode, which exposes the flash drive(s) to a computer connected to the phone via USB-C. The Tow-Boot bootloader has to be installed if it is not pre-installed already. For instructions see the following links:\nPinePhone: https://tow-boot.org/devices/pine64-pinephoneA64.html PinePhone Pro: https://tow-boot.org/devices/pine64-pinephonePro.html If Tow-Boot is installed the phone can be started into USB Mass Storage Mode by holding the volume up key on startup.\nThe steps of flashing an operating system to the phone after booting Tow-Boot’s USB Mass Storage Mode and connecting the phone to a computer is identical to that of any other storage medium - e.g. a microSD card. You can use the dd command or a utility such as Etcher or Gnome Disks from the computer the phone is connected to.\nReuse microSD card Once you have installed your release of choice to eMMC, you may wish to use an microSD card for data storage. If you choose to re-use a card you have previously used to boot from, you will find your phone might not boot if you just reformat the card and insert it. This is because the Allwinner firmware in the PinePhone uses some (normally) unused space at the front of the microSD card to store boot software, which you need to clear.\nThis can be done as follows on any Linux system:\nlsblk to check the device of your microSD card – as an example lets assume it is /dev/mmcblk0 then\nsudo dd if=/dev/zero of=/dev/[DEVICE] bs=8k seek=1 count=4\nwill clear the relevant sectors of your card.\nSince Danctnix (arch) switched to a gpt partition table from mbr in May of 2022 it installs u-boot at an offset of 128k instead of 8k, which means this command must be used instead\nsudo dd if=/dev/zero of=/dev/[DEVICE] bs=32k seek=4 count=1\nExtend partition Once you’ve flashed the OS to your microSD card or eMMC storage, you may also need to expand the partition to fill all the available space.\nNote Many operating systems already include a script, which is resizing the partition on first boot, where this step is not required. Resize SD card\u0026rsquo;s partition using computer For microSD cards, insert the microSD card and resize the partitions through the computer. For eMMC, insert the phone cable and use Jumpdrive to access the eMMC directly, and resize the partition after flashing the image. To do the flashing you have two options:\nUsing Growpart Install growpart and run:\ngrowpart /dev/**mmcblkX** **Y** resize2fs /dev/**mmcblkXpY** where X is the storage device and Y is the partition number (viewable from lsblk).\nIf you get any errors about missing or unknown commands, use apt-cache search to find and install the needed software. Also don’t forget to use sudo.\nUsing Parted Parted’s interactive mode and resize work well together. Do this before you put your microSD card into the PinePhone for the first time for best results.\nsudo parted /dev/*\u0026lt;your_sd_card_device\u0026gt;* (parted) resizepart 2 100% (parted) quit sudo resize2fs /dev/*\u0026lt;the_second_sd_card_PARTITION\u0026gt;* Resize from within the PinePhone eMMC: you would need to resize the partition on eMMC (flashed with the operating system) by booting another image from the microSD card: that way, the eMMC will be unmounted. It is not recommended to resize eMMC while booted from eMMC! Resizing a currently mounted partition can have weird results. If you booted from the microSD card, you can follow the above guidelines on how to resize from a computer.\nMicroSD card: It is generally not possible to boot from eMMC to partition the unmounted microSD card, because of the boot order - you would have to write the image to the empty microSD card first, then resize partition, all without rebooting. It is also not recommended to resize the microSD card while booted from microSD card! Resizing a currently mounted partition can have weird results.\nReleases This page provides a comprehensive and alphabetically organized list of available software releases and tools for the PinePhone. For guidance on installing the operating systems, please refer to the Installation instructions.\nNote Some releases may not have a good setup for the backlight at low brightness. If configured too low, the backlight shuts down completely, but the screen is still displayed and usable in bright front-light. Software Releases Arch Linux ARM (Unofficial) Arch Linux ARM with choice of Phosh UI, Plasma Mobile, sxmo or barebones.\nIt is maintained by the DanctNIX community (GitHub: danctnix, dreemurrs-embedded).\nDownload Get both stable and test builds at GitHub releases or directly from the DanctNIX server.\nDefault credentials Default user alarm/123456 root (barebone only) root/root Notes There are archmobile chat rooms on Matrix (#archmobile:kde.org) and Telegram (@archmobile). Feel free to send us pull requests and reports issues on GitHub. Fedora An (unofficial) vanilla Fedora rawhide build for aarch64 with megi\u0026rsquo;s kernel and some additional packages to tie it all together. It aims to eventually be an upstream part of the Fedora project, rather than a phone-specific distribution.\nForum discussion: Fedora + Phosh for PinePhone GitLab: Fedora Mobility SIG Download Build scripts Packages (Fedora COPR) There is also an FTP server with images build every night @ ftp://pine.warpspeed.dk/nightly/pinephone/ (Mount this with something like Nautilus)\nDefault credentials Nightly images (via FTP) pine/1111 Notes WiFi, Bluetooth, SMS, Data, Calls all work|There are still a few bugs though, and some features don\u0026rsquo;t have driver support yet on any PinePhone distribution.\nPlease send your bug reports to the project\u0026rsquo;s issue tracker. Be sure to include logs if applicable|Send us pull requests on GitLab.\nGentoo There are unofficial Gentoo overlays with ebuilds for the PinePhone. There are no images - the image must be built manually, including picking the kernel, bootloader and the desired desktop environment. The ARM64 version of Gentoo has to be selected.\nDownload Overlay locations:\nhttps://git.gjdwebserver.nl/gjdwebserver/gjdwebserver-overlay Notes The documentation can be found here:\nhttps://blog.gjdwebserver.nl/ords/f?p=107:HOME:::::ARTICLE:gentoo-on-a-pinephone https://blog.gjdwebserver.nl/ords/f?p=107:HOME:::::ARTICLE:gentoo-on-a-pinephone-making-it-a-usable-phone https://blog.gjdwebserver.nl/ords/f?p=107:HOME:::::ARTICLE:gentoo-on-a-pinephone-pro https://wiki.gentoo.org/wiki/User:Dr41nU/PinePhone https://wiki.gentoo.org/wiki/PinePhone (incomplete) Note Please consider cross-compiling the software on the computer. Long compilation times and heat production can lead to a reduced lifespan of the phone. GloDroid A fully open-source port of Android and LineageOS to the PinePhone.\nGitHub: GloDroid\nDownload Releases: GloDroid Notes Feature overview:\nWorks: WiFi, screen dimming, sound, touchscreen, charging and telephony(partially) works. Doesn\u0026rsquo;t work: Bluetooth and GPS See more at project status page Kali Linux The official Kali Nethunter images for PinePhone and PinePhone Pro have been released now. For older/unofficial releases, you can still download from the GitHub releases page. Get Nethunter App for your PinePhone\u0026rsquo;s Kali Linux. Packet Injection is working now, use iwconfig instead of airmon-ng.\nDownload Kali Phosh Unofficial Kali Nethunter Pro Official Default credentials Default user for Unofficial Releases kali/8888 Default user for Nethunter Releases kali/1234 LuneOS LuneOS is one of the original multi-tasking OS-es that runs on Linux. Based on HP/Palm\u0026rsquo;s webOS, merged with latest technology stack from LG called webOS OSE (a derivative of what LG uses on their Smart TV\u0026rsquo;s), software such as Qt5 and makes use of the Yocto build system.\nWebOS Ports Wiki WebOS-Ports Wiki\u0026rsquo;s Pinephone page How to Build LuneOS for PinePhone Install LuneOS for PinePhone GitHub: WebOS Ports Download Release images: Releases Testing images: Open the testing releases page, then use Ctrl + F to search release that built image for PinePhone Default credentials Default user root Notes In order to connect to the device using SSH/SCP via WiFi: You can simply connect via SSH/SCP via WiFi using the PinePhone\u0026rsquo;s IP address on port 22.\nMaemo Leste Maemo is a trimmed-down version of Debian for mobile devices, originally a collaboration between Nokia and many open source projects (the Maemo community) before Nokia abandoned it. The more well-known devices Maemo supports are the OpenMoko and N900. The community now takes full responsibility in developing fully open source Maemo for a variety of mobile devices. You may be interested to learn more about the features in their Maemo Leste FAQ.\nMaemo 8 \u0026ldquo;Leste\u0026rdquo; is an ARM64 port of Devuan (Debian without systemd) and runs the mainline Linux kernel. The default user interface stack is Hildon, Xorg, Matchbox WM, and GTK.\nDownload Maemo Leste test builds There is also an image builder, see the wiki for instructions on how to build a custom image. For current status and instructions, please read their PinePhone wiki page.\nDefault credentials root toor user 12345 (lockscreen) Notes Most discussion occurs at #maemo-leste on irc.libera.chat (link) and this thread.\nAll other contact information is listed on the main page of the Maemo wiki.\nSubmit bug reports on GitHub. To track known issues, you may use these search terms: pinephone and pine64.\nMobian A Mobian build for ARM64 running with Phosh (developed by Purism, uses Wayland instead of Xorg). The current version of the base Debian system is Debian Bookworm. Only the GUI applications and a few others (ModemManager, WiFi chip firmware) are built from modified sources (as well as the kernel and u-boot).\nDownload Images Note Tow-Boot is required to be able to boot the images, see here! Default credentials Default user mobian/1234 Notes The development is work in progress. See pinephone-support for further information. The Mobian wiki can be found here.\nIn order to connect to the device using SSH/SCP via WiFi, you need to install SSH on the device. You can do this by executing the following in a shell: \u0026ldquo;sudo apt-get install ssh\u0026rdquo;, afterwards you can connect via SSH/SCP via WiFi using the PinePhone\u0026rsquo;s IP address on port 22.\nMovuan Movuan is the incipient stage of a new distribution for the PinePhone. It is derived from Mobian, yet using Devuan instead of Debian. The image attempts to be as short lived as possible, hoping to get merged into mainline Devuan as soon as possible.\nDownload Image This is a split zip file. To extract it, the following command can be used:\n7z e movuan-pinephone-phosh-daedalus-20250224.img-split.zip Note Tow-Boot is required to be able to boot, same as for Mobian Default credentials Default user movuan/1234 Notes Current image version is based on Devuan Daedalus. Source Code Announcement/Discussion/Motivation Further interest Customizing Movuan under Host Mounting At this time expecting feedback or offers to help with building/packing.\nAnybody is welcome to fork this project, or use it in any GPL compliant way. Use a different name though and change the logo, and notify the author of the project to review if it can be incorporated back.\nIf you want to just mirror the code and provide additional pre-built images on a different server, there is no need to change the logo/name. Just make sure to prominently point to the original location.\nMulti-distro demo image Warning This is a demo image for testing different operating systems before installing a regular image. Attempting to use this image productively is highly discouraged. The kernel is shared across the different operating systems and is not updated. This image allow users to try many Linux distributions easily, without having to figure out how to flash them individually and juggle with many microSD cards. Also called megi\u0026rsquo;s 15-in-1 multi boot image.\nMain page: https://xnux.eu/p-boot-demo/ Git repo: https://megous.com/git/pinephone-multi-boot/ Forum discussion: 15-distro multi-boot image for Pinephone Download Update 2022-01-26, using megi\u0026rsquo;s kernel 5.16.2\nDD image to SD card and boot. This image is for 16GiB or larger SD cards, also works if flashed to eMMC.\nThis is also a good build for charging depleted battery. Just boot up this build with power supply connected, keep the PinePhone charging for 3 hours at power down stage.\nFor more info on this build, please visit its entry the \u0026ldquo;News\u0026rdquo; section of its web page.\nDownload torrent file from author\u0026rsquo;s website File name: multi.img.zst SHA-256: 39915b9d2aa2f33fd78552ac9a0e665c4aef97dd68a9f9a6c76f9fa2f0ac049e File Size: 6.9GiB Due to its size, download though torrent is suggested by the author on its main page.\nDefault credentials General 1111 sxmo user/1111 Manjaro seems to insist on 123456 Notes Note Note about zstd archive file (.zst):\nOn Linux, you may install or compile zstd, then write the image to SD card by piping zstdcat and dd. See the \u0026ldquo;Installation\u0026rdquo; section of its web page for command examples.\nOn Windows, instead of the offical zstd command line program, you may use 7-zip-zstd. Different installation method is provided in their README. Install 7-Zip-zstd / zstd, extract the disk image file (.img) from the zstd archive, and flash with tools like Win32 Disk Imager.\nAlso see Installation instructions.\nNemo Mobile Nemo Mobile is an open source build of Sailfish OS with a open source UI called Glacier, based on openSUSE.\nNemoMobile Website Installation Guide for both real devices and Virtualbox Download Latest release, not every device are built every time. Older release: yyyy.mm/ dirs under https://img.nemomobile.net/. Has every supported device\u0026rsquo;s image. The manjaro/ dir only contains the software packages instead of installation images. Default credentials Default user nemo/1234 root root/linux Notes Please report bugs regarding the Nemo Mobile UI as GitHub issue. Checkout the troubleshooting and contributing guide to learn more.\nNixOS NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades.\nDownload There is a guided installer by the Mobile NixOS project available. An installer image that can be flashed to a sdcard can be downloaded from the Hydra build instance.\nUsers that want to build a local image, are expected to follow the instructions in the Getting Started page, and Project\u0026rsquo;s device page.\nNotes Project home page: Mobile NixOS\nopenSUSE Our images use the same openSUSE Tumbleweed base as our desktop images, except what needs to be changed for the PinePhone. The images include zypper (RPM) as the default package manager, and have access to virtually the same (open source) software as our desktop repositories, thanks to the Factory ports. Using dnf is possible, if preferred.\nDownload Phosh / SHA-256 / SHA-256 Signature Plasma Mobile / SHA-256 / SHA-256 Signature To verify the images you need to import our GPG key. Keep on mind that the first boot may stay on black screen for about a minute - consequent boots should be faster.\nYou can find install instructions at this section in the openSUSE Wiki.\nDefault credentials Default user pine/1234 root root/linux Notes You can find all information about the releases of the project here. Detailed information, tips and troubleshooting suggestions are also provided at the openSUSE Wiki. You will also find information in our wiki on how to report issues (Contributing section).\npostmarketOS postmarketOS extends Alpine Linux to run on smartphones and other mobile devices. It offers various user interfaces (Phosh, Plasma Mobile, Sxmo, Plasma Desktop, Gnome 3, Kodi, XFCE4 and others).\nDownload Download page\nDefault credentials Test images user user/147147 Notes As of writing, official images are provided with Phosh, Plasma Mobile and Sxmo. The official images come in two flavors, either as a test image to try out postmarketOS, or with the installer.\nWhen using the installer images (recommended), it is possible to:\nencrypt the installation install from the SD card to eMMC Power users may also create their own image with the distribution\u0026rsquo;s install and development tool pmbootstrap.\nSee the pine64-pinephone page of the postmarketOS wiki for details.\nRhino Linux Rhino Linux is an Ubuntu-based distribution that uses the rolling-release model by tracking the devel` branch of repositories. The port is currently maintained by Oren Klopfer (oklopfer).\nTow-Boot is required for installing Rhino Linux. Instructions for installing Tow-Boot to the PinePhone can be found here. After Tow-Boot has been installed to your device, Rhino Linux installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload Rhino Linux Downloads (select Pine64 on the dropdown)\nDefault credentials Default user rhino/1234 Notes Foundational to the distribution is Pacstall, a Debian-based user repository inspired by the AUR. Additionally, RL comes with Unicorn, a custom modified version of XFCE with various modernizations and improvements, including auto-rotation for mobile devices.\nDiscord - Matrix - GitHub - Wiki\nSailfish OS Sailfish OS is a Linux-based operating system based on open source projects such as Mer, and a closed source UI based on Lipstick.\nPinePhone Wiki Page on Mer Wiki, for both Nemo Mobile and Sailfish OS. Linux kernel config repo Sailfish OS repo Download Flashing script\nThe Sailfish OS image is built on Gitlab CI. The latest image can be installed using the flashing script.\nThe script downloads the image and bootloader from the CI, extracts everything and burns it onto the SD card.\nNote The script will format and erase the SD card! Instructions:\nDownload the flashing script Insert a microSD card in your device Make the script executable: chmod +x flash-it.sh Verify that you have the bsdtar package installed Execute it: ./flash-it.sh Follow the instructions. Some commands in the script require root permissions (for example: mounting and flashing the SD card). When asked where to flash, type \u0026lsquo;raw\u0026rsquo; and it will build the image on your computer. Otherwise define the path /dev/[\u0026hellip;]. to flash to card or internal emmc.\nusername/password\nSet PIN on initialization.\nNotes Sometimes the first run stalls before the tutorial. Reboot and it will start from setting the security pin. The homescreen may be locked unless you boot with a sim card inserted. An old expired sim will do. If you do not have a SIM card on hands, do NOT set a security code on first boot. When a screen with a loading circle is displayed, just left/right swipe it away. If you\u0026rsquo;re not familiar with Sailfish OS, pay attention to the tutorial - the interface works great, but is not immediately obvious. If you are familiar with it, you can skip the tutorial by touching all 4 corners starting top left. What works, what does not work\nSee the Hardware Support section on the Mer Wiki\u0026rsquo;s PinePhone Page.\nThere is a limited selection of apps available from the Jolla store, the vast majority are hosted on openrepos.net. If the Storeman app for openrepos is not preinstalled, download the RPM and click to install.\nHow to contribute and report defects\nSee the documentation wiki at the github project for help and links.\nSee the Installation section on the Mer Wiki\u0026rsquo;s PinePhone Page for compile, build and development.\nGit repo links are at the top of this OS section. other repos that may be helpful:\nGitHub project page the repo of the flash-it.sh flashing script Mer Open Build Service page (Mer is being assimilated into Sailfish OS and OBS is shutting down, also see OpenStack is replacing OBS with another build system based on Jenkins, if it\u0026rsquo;s related, even OBS come back under Sailfish OS, it will be different.) See the Sailfish OS wiki for links to their forum, as well as info required when reporting an issue. See the Sailfish OS wiki main page for options to contribute to Sailfish OS.\nNotes\nOTA is supported: zypper refresh \u0026amp;\u0026amp; zypper update as root (devel-su to get root access). Things that need reflash are bootloader specific at the moment. If improvements like Crust or changes of partition layout are added, then you need to reflash.\nSkiffOS Minimal in-memory cross-compiled OS optimized for hosting multiple in parallel Docker containers. Provides the reliability of firmware with the ease-of-use of package managers.\nDownload The repository and instructions can be found here.\nNotes Upgrade over-the-air via a simple rsync script, or copying 3 files.\nUses the Buildroot cross-compilation tool for support for all Pine64 boards.\nUse configuration packages to configure distro:\nPackage Distro core/pinephone_neon KDE Neon via Ubuntu repositories core/pinephone_nixos Nixos Mobile core/pinephone_gentoo Gentoo with Link-time Optimization \u0026amp; KDE Mobile or Phosh core/pinephone_ubports Ubuntu Ports for PinePhone core/pinephone_manjaro_kde Manjaro for PinePhone: KDE variant core/pinephone_manjaro_phosh Manjaro for PinePhone: Phosh variant core/pinephone_manjaro_lomiri Manjaro for PinePhone: Lomiri variant The boot-up OS is upgraded independently from the containers.\nSlackware Slackware is the world\u0026rsquo;s oldest actively developed Linux distribution, providing a modern user land (applications) and Linux Kernel, within a more classic Unix Operating System environment.\nDownload https://dl.irradium.org/slackware/images/pinephone/ Notes Discussion: Thread\nUbuntu Touch A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community. The port is currently maintained by Oren Klopfer (oklopfer).\nNote Tow-Boot is required for installing the latest version of Ubuntu Touch (20.04) on the PinePhone. Instructions for installing Tow-Boot to the PinePhone can be found here. Installation instructions can be found at this UBports post. After Tow-Boot has been installed to your device, Ubuntu Touch installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload UBports 20.04 PinePhone Latest Releases UBports PinePhone Device Info Default credentials Default user Set during boot root phablet/1234 Notes Scroll down to the middle of the GitLab project page, or directly here at the UBports website to see which features work.\nContributions and bug reports can be made at the UBports PinePhone GitLab page. See UBports website for how to donate.\nTools There are software tools, that can be booted on the PinePhone.\nJumpDrive JumpDrive can be used to flash the eMMC (and the microSD card), see Installation instructions.\nSee https://github.com/dreemurrs-embedded/Jumpdrive/releases for the latest image. Make sure to download the \u0026ldquo;PinePhone\u0026rdquo; image and to unpack the archive before flashing.\nTow-Boot Tow-Boot is a more user-friendly distribution of U-Boot. It can mount internal storage as USB Mass Storage by holding the volume up button at startup before and during the second vibration. The LED will turn blue if done successfully.\nSee https://github.com/Tow-Boot/Tow-Boot/releases for the latest image. Make sure to download the image with pinephoneA64 in the name.\nNote The USB Mass Storage mode might not be recognized by your computer for some cable + PC USB port + PC OS combos, see this reddit thread and this GitHub issue. If you encounter any problem like this, try use any Linux distro for your PC, or switch USB cables or ports. A patch has been posted on the GitHub issue, try that if you can patch and compile the Tow-Boot yourself, and tell them if that works. Hardware test build Warning The factorytest image for hardware testing appears to be no longer maintained. On the Braveheart model, there was a postmarketOS based basic Factory Test OS pre-installed on the eMMC. The developer Martijn Braam from postmarketOS has improved the functionality of the image considerably later. Since the 20200501 version, it is able to test all the hardware. It also includes functionality to install a new OS to the eMMC when using with an test image that includes that OS image. The downloadable image just does the hardware tests. Do not flash eMMC to test your device, just flash it to microSD and test from there. New versions are distributed as part of the postmarketOS distribution.\nNote The magnetometer test will fail on the new Beta Edition, as the factory image wasn\u0026rsquo;t updated for it yet. Links:\nSoftware Images (NOTE: Link is is broken) (download the latest one named like pine-pinephone-yyyyMMdd-factorytestX.img.xz) Git repo Documentation Historic factory builds These are different operating system builds that was preloaded in the factory with testing utility.\nDownload the build, extract the image and dd it to a 8 GB or larger microSD card, then insert it into the PinePhone. After power up or reboot, you may perform and complete the test routine, or apply the build from microSD card to eMMC.\nAll the download links below are direct download from pine64.org.\nWarning These images are for testing purposes only. If you are looking for an up-to-date image please select one from the software releases section instead. Distribution Download Link File Size MD5 Beta Edition pine64-pinephone-plamo-beta-factorytest.img.xz 1.78GB f16bce93504a52217540ac886863a418 Mobian pine64-pinephone-20201207-factorytest-mobian.img.xz 1.41GB 015be381ff4e650a7fca6d4eaa90d63d KDE pine64-pinephone-20201208-factorytest-kde.img.xz 2.28GB 32979ff17b5ec4d358ce99f1aff0c77c Manjaro pine64-pinephone-20201013-manjaro-stable-20201018-factory56.img.xz 1.04GB 4edfd4dceaefdd32a3417c1727161c29 postmarketOS pine64-pinephone-20200726-phosh-v20.05-factory.img.xz 517MB 244093be2f6d728fcbd1d29114607727 Ubuntu Touch PinePhone-flasher-ubuntu-7b.img.gz 1.05GB 2d7f5271e7a281db8f1b1219bedbe131 Further Releases Apache NuttX RTOS Apache NuttX RTOS is a Real-Time Operating System that supports PinePhone.\nApache NuttX RTOS on PINE64 PinePhone Sculpt Operating System (Genode OS Framework) Sculpt OS since version 23.04 supports PinePhone.\nReady-to-use system image available on the download page.\nInstalling other ARM64 distributions Other ARM64 distributions might be installed as well, however this requires some tinkering and may not work well.\nNote Distributions not on this page may not even boot after you follow this section. In the best case, they will be barely usable. This is more for fun, or if you would like to port a new distribution to the PinePhone. General steps:\nCreate a boot partition (from 4 MB to about 252 MB) and a root partition (from the end of boot to the end of the card) filesystem on the SD card. Format the boot partition with vfat, and the root partition with a supported filesystem like ext4 or f2fs. Extract the root filesystem from your distribution\u0026rsquo;s ARM image into the root filesystem on the SD card. Do not copy the partition, copy the files instead (in archive mode, like rsync -ar). Edit /etc/fstab to match your partitions. Grab megi\u0026rsquo;s kernel from https://xff.cz/kernels/, Follow the instructions in the README, which involves copying the kernel modules into the SD card rootfs, and writing u-boot and the bootloader. If you would like to see examples or specific commands for how to complete these steps, see:\nan example for Fedora, current unofficial [#Fedora] release an example for Arch Linux by megi Other Resources Other software information\nsunxi community wiki megi\u0026rsquo;s feature/driver support matrix megi bootUI notes (for dualbooting/multibooting) see demonstration on YouTube ayufan boot tools Other\nPine64 blog on blobs Martijn Braam Librem 5 comparison, especially covering openness/blobs Bart Ribbers blog on Linux distributions and desktop environments on mobile devices Jeff Geerling on testing microSD cards Troubleshooting If the PinePhone is not booting from eMMC and/or microSD card anymore it can have two causes:\nThe battery is drained If the battery is fully drained, most operating systems and distributions won’t boot anymore. One of the exceptions which still boots is the utility Jumpdrive, which can usually be used to expose the eMMC and microSD card as drives to a USB-connected computer. Mind that JumpDrive won’t expose the eMMC and microSD card with a drained battery but it still can be flashed and booted from microSD card to confirm that the phone still functions and boots up fine.\nJumpDrive can be downloaded from here (not compatible with the PinePhone Pro!).\nNote If JumpDrive boots and other releases do not boot, the battery is likely drained. In that case let it charge while running JumpDrive with a compatible charger for multiple hours and make sure to not fully drain the battery in the future anymore, as that significantly reduces the battery lifetime. Alternatively to testing JumpDrive, the issue can also be diagnosed by checking the battery charge. Simply remove the battery from the device and measure the voltage on the (+) and (-) contacts on the battery. Make sure to not shorten the contacts as shorting battery pins is a severe life and safety danger.\nThe installation is corrupted or incorrect If the installation of the prioritized boot medium is corrupted or incorrect, the PinePhone will not boot anymore. The following problems are common:\nThe microSD card is in the wrong slot (see first time installation) The image file was flashed to partition 1 (example: sdx1, nvme0x1p1) instead of the whole device (example: sdx, nvme0x1) An image without bootloader was flashed (mind the Tow-Boot bootloader requirements of Mobian and postmarketOS) The operating systems got corrupted, for example after running updates (reflash the device, see Installation instructions) An incompatible image was flashed (make sure that the images are compatible. Images for the PinePhone Pro won’t boot on the PinePhone and vice versa. Check your invoice to see if you ordered a PinePhone or a PinePhone Pro). Modem The PinePhone uses Quectel EG25-G as modem. AT commands are used to communicate with the modem.\nAT commands A list of documented AT commands can be found for example in this AT commands documentation from Quectel. Further undocumented AT commands found by the developer megi, who reverse-engineered parts of the modem and its firmware, can be found on megi’s website here.\nTo send AT commands to the modem under Linux, minicom or the often-preinstalled atinout utility can be used.\natinout example:\necho \u0026#34;AT+\u0026lt;command here\u0026gt;\u0026#34; | sudo atinout - /dev/ttyUSB2 - minicom example:\nminicom -D /dev/ttyUSB2 VoLTE The PinePhone’s modem supports VoLTE and comes with a few VoLTE profiles preloaded. Most operating systems try to set the correct profile automatically.\nTo list the available VoLTE profiles:\nAT+QMBNCFG=\u0026#34;list\u0026#34; +QMBNCFG: \u0026#34;List\u0026#34;,0,1,1,\u0026#34;ROW_Generic_3GPP\u0026#34;,0x0501081F,201901141 +QMBNCFG: \u0026#34;List\u0026#34;,1,0,0,\u0026#34;VoLTE-ATT\u0026#34;,0x0501033C,201909271 +QMBNCFG: \u0026#34;List\u0026#34;,2,0,0,\u0026#34;hVoLTE-Verizon\u0026#34;,0x05010141,201911251 +QMBNCFG: \u0026#34;List\u0026#34;,3,0,0,\u0026#34;Sprint-VoLTE\u0026#34;,0x05010205,201908141 +QMBNCFG: \u0026#34;List\u0026#34;,4,0,0,\u0026#34;Commercial-TMO_VoLTE\u0026#34;,0x05010505,201811231 +QMBNCFG: \u0026#34;List\u0026#34;,5,0,0,\u0026#34;Telus-Commercial_VoLTE\u0026#34;,0x05800C43,201912031 +QMBNCFG: \u0026#34;List\u0026#34;,6,0,0,\u0026#34;Commercial-SBM\u0026#34;,0x05011C18,201904021 +QMBNCFG: \u0026#34;List\u0026#34;,7,0,0,\u0026#34;Commercial-DT\u0026#34;,0x05011F1C,201905311 +QMBNCFG: \u0026#34;List\u0026#34;,8,0,0,\u0026#34;Reliance_OpnMkt\u0026#34;,0x05011B38,201910161 +QMBNCFG: \u0026#34;List\u0026#34;,9,0,0,\u0026#34;TF_Germany_VoLTE\u0026#34;,0x05010C1B,201909201 +QMBNCFG: \u0026#34;List\u0026#34;,10,0,0,\u0026#34;TF_Spain_VoLTE\u0026#34;,0x05010CFA,201909261 +QMBNCFG: \u0026#34;List\u0026#34;,11,0,0,\u0026#34;Volte_OpenMkt-Commercial-CMCC\u0026#34;,0x05012071,201904281 +QMBNCFG: \u0026#34;List\u0026#34;,12,0,0,\u0026#34;OpenMkt-Commercial-CT\u0026#34;,0x05011322,201911081 +QMBNCFG: \u0026#34;List\u0026#34;,13,0,0,\u0026#34;OpenMkt-Commercial-CU\u0026#34;,0x05011505,201807052 To select a profile manually, select the best fitting one or a generic one if none fits:\nAT+QMBNCFG=\u0026#34;select\u0026#34;,\u0026#34;ROW_Generic_3GPP\u0026#34; Then enable Voice over LTE using:\nAT+QCFG=\u0026#34;ims\u0026#34;,1 And reboot the modem to apply the settings:\nAT+CFUN=1,1 To check the status of VoLTE during a call, the AT command CLCC can be used:\nAT+CLCC +CLCC: 1,1,0,1,0,\u0026#34;\u0026#34;,128 +CLCC: 2,1,0,1,0,\u0026#34;\u0026#34;,128 In the fourth item of the list, \u0026ldquo;0\u0026rdquo; means voice and and \u0026ldquo;1\u0026rdquo; means data. If both rows have \u0026ldquo;1\u0026rdquo; then the voice call is being carried over VoLTE.\nAPN settings The APN setting is only required for a public Internet connection (\u0026ldquo;data\u0026rdquo;) on the phone. For tested APN settings and how to apply them see APN settings.\nCarrier support The page Carrier support contains information about the frequency support of different carriers and hints on setting up cellular network connectivity.\nDocuments Detailed information about the modem can be found on the page of the developer megi, including reverse-engineered parts of the firmware and its functions. There is also a document about using the modem from January 18th 2020 by megi here. A script at the end of the document showcases a way to poweroff the modem before powering off the phone, which is integrated into most of the available operating systems.\nFirmware update There is a (nearly) free custom firmware and the stock firmware available for the PinePhone. Both can be updated to a newer version with new features and bug fixes.\nCustom firmware There is a (nearly) free custom firmware for the PinePhone modem by the developer biktorgj, which can be found here.\nThe custom firmware has various advantages (and zero disadvantages) over the stock firmware, including:\nSignal tracking support with checks against the OpenCelliD database Persistent storage is optional and unexpected shutdowns don’t mess up the modem A lower energy consumption due to the lower minimum clock frequency And many more, see Features not available on stock firmware The custom firmware can be flashed using fwupd or a flashing script.\nStock firmware Tip The following instructions are directed towards professional users. It is highly recommend to make sure the update process is not interrupted to prevent the modem from bricking. The stock modem firmware can be updated to a newer version if it is outdated. The firmware version can be checked using the following AT command (at the example of atinout, alternatively minicom can be used to communicate with the modem too):\necho \u0026#39;AT+QGMR\u0026#39; | sudo atinout - /dev/ttyUSB2 - Pre-update checklist:\nPlease make sure all requirements of the checklist are fulfilled. If the update process is interrupted it will lead to a corrupted firmware of the modem, causing it to brick. Recovering a bricked modem is exponentially more complicated and requires the user to boot a special mode by physically bridging test points on the modem.\nThe battery needs to be charged sufficiently The phone needs to be plugged into a charger Deep sleep is recommended to be disabled as it can interrupt the update process It is recommended to close all other running applications Use common sense while doing the update, don’t do the update while being impaired in any way To get the latest firmware, follow the instructions on https://github.com/Biktorgj/quectel_eg25_recovery (fastboot or qfirehose method). The modem will automatically reboot after the update process is done. The boot process takes around 30 to 60 seconds. After that it is highly recommended to reboot the device.\nFirmware modifications See PineModems for more information regarding modem bootloader unlocking, building a custom modem firmware and modem recovery.\nGPS / GNSS The GPS engine in the modem supports mutli-GNSS reception from GPS, GLONASS, BeiDou, Galileo and QZSS independent of a cellular connection. The operation of the GNSS subsystem can be controlled via a separate set of AT commands, or via qmi. The A-GPS data upload uses the file management AT commands, which also have their own manual. These are linked in the documentation section below.\nAs with most smartphones, the PinePhone has a small antenna and has difficulty getting a first fix without assistance data, a cold start can take 15 minutes under good conditions. The eg25-manager is configured to upload A-GPS data by default (see here).\nBasic testing of GNSS reception can be done by using the AT command interface (/dev/ttyUSB2) from a terminal program like minicom and the data output interface (/dev/ttyUSB1) to feed NMEA data into gpsmon or some other program that can parse standard NMEA sentences.\ngpsmon decoding GPS data from /dev/ttyUSB1\nTo check if GNSS data output is enabled, you can\ncat /dev/ttyUSB1 this should display a stream of NMEA sentences\n$GPVTG,,T,,M,,N,,K,N*2C $GPGSA,A,1,,,,,,,,,,,,,,,,*32 $GPGGA,,,,,,0,,,,,,,,*66 Further details can be found under Sensors and navigation.\nVoice mail The operating systems of the PinePhone may not have support for accessing your voicemail by holding down the 1-key. Carriers might support accessing the voice mail via an external number however.\nAPN settings The APN setting is the gateway between your carrier’s cellular network and the public Internet. The APN setting - if not set automatically by the user’s OS - has to be set by the user to enable the use of the mobile Internet on the phone.\nSetting the APN The location of the APN setting depend on the user interface the distribution is using.\nGnome One of the biggest actively maintained open (Creative Commons Public Domain) database of mobile broadband service providers and their APN settings is maintained by the Gnome project, and is available in their serviceproviders.xml. It is a rare case, when you don’t find your own provider in that list, but if it happens, then please consider contributing to it upstream. If your provider is in that database, then for setting up the APN, you only have to select your provider from the list under Settings \u0026gt; Network \u0026gt; Network Dropdown \u0026gt; Add new connection.\nFurther details are described by the Gnome help.\nPhosh The APN settings are either located under Settings \u0026gt; Mobile \u0026gt; Access Point Names or Settings \u0026gt; Network \u0026gt; Network Dropdown \u0026gt; Add new connection.\nPlasma Mobile The APN settings are located under Settings \u0026gt; Cellular Networks \u0026gt; SIM 0 \u0026gt; Modify APNs. While this is an auto-detect button, some cell providers may be detected incorrectly. Additionally, the settings for MMS are located under Spacebar \u0026gt; Settings \u0026gt; Multimedia Messages (MMS).\nCarrier support Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. This page contains hints on setting up cellular network connectivity for specific carriers. For more general information, see the carrier support section of PinePhone. For the APN settings see APN settings.\nCheck compatibility To check if the PinePhone is supported on your carrier:\nSearch for your carrier on frequencycheck.com and compare the carrier’s LTE/GSM/WCDMA frequencies to the PinePhone’s supported frequencies (listed in the https://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf modem specification sheet).\nIt is likely that there will be a few frequencies that your carrier uses which are not supported by the PinePhone. Not all of the carrier’s frequencies need to be supported by the PinePhone for it to work - as long as most of them are supported, you will still get good coverage.\nNote Some providers may allow only certain known devices identified by their Type Allocation Code. MMS workarounds These scripts allow partial MMS support on a PinePhone in distributions without working MMS support:\nJMMS: https://git.sr.ht/~amindfv/jmms silvermms: https://gitlab.com/5ilver/silvermms MMS via Matrix with mmmpuppet: MMS with Matrix There is a Haskel MMS client. MMS can also be manually composed with mmsd on the command line.\nPrivacy switches Picture of the privacy switches\nThe PinePhone features six switches that can be used to configure its hardware. They are numbered 1-6, with switch 1 located nearest to the modem. Their \u0026ldquo;on\u0026rdquo; position is toward the top of the phone.\nWarning It is not recommended to change the PinePhone’s privacy switch positions while the device is powered on. In particular, toggling the modem privacy switch while the phone is running can lead to modem firmware corruption. Additionally, the phone is not notified of the loss of power to the disabled part, so it may continue to assume the component is operating normally; if you switch the dip switches back on during operation, it may not automatically regain functionality. Number Name Explanation Description 1 Modem Pulls Q1501 gate up (FET killing modem power) \u0026ldquo;On\u0026rdquo; enables 2G/3G/4G communication and GNSS hardware, \u0026ldquo;off\u0026rdquo; disables it. 2 WiFi / Bluetooth Pulls up CHIP_EN \u0026ldquo;On\u0026rdquo; enables WiFi and Bluetooth communication hardware, \u0026ldquo;off\u0026rdquo; disables it. 3 Microphone Breaks microphone bias voltage from the SoC \u0026ldquo;On\u0026rdquo; enables audio input from on-board microphones (not 3.5 mm jack), \u0026ldquo;off\u0026rdquo; disables it. 4 Rear camera Pulls up PWDN on OV5640 \u0026ldquo;On\u0026rdquo; enables the rear camera, \u0026ldquo;off\u0026rdquo; disables it. 5 Front camera Pulls up PWDN on GC2145 \u0026ldquo;On\u0026rdquo; enables the front camera, \u0026ldquo;off\u0026rdquo; disables it. 6 Headphone Pulls up IN2 on analog switch BCT4717ETB \u0026ldquo;On\u0026rdquo; enables audio input and output via the 3.5 mm audio jack, \u0026ldquo;off\u0026rdquo; switches the jack to hardware UART mode. Repairs Spare parts not available in the Pine Store The following parts are not available for purchase in the Pine Store, however compatible parts can be sourced from other shops:\nEarpiece speaker dimensions: 12x6x2 mm. Compatible with Xiaomi Mi2 / Mi3 (but not Mi4!) and others, see here Loudspeaker dimensions: 15x11x3 mm. Compatible with Nokia N91, Lenovo A536 (requires soldering) and others, see here Proximity sensor rubber isolator Earpiece speaker The earpiece speaker refers to the small speaker at the top of the PinePhone and PinePhone Pro.\nThis part is not available to purchase from the PINE64 Store. However, it is possible to buy a replacement earpiece for another device, and install it in a PinePhone or PinePhone Pro. This documents earpieces that have been tested by the community, and verified to work.\nNote that the earpiece dimensions for both the PinePhone and PinePhone Pro are 12x6x2 mm. When looking into earpieces not found in this list, aim for these dimensions.\nCompatible earpiece speaker Model PinePhone PinePhone Pro Example shop LG K8 2017 M200N Kind of ¹ Broken Nokia 5 Works Works Nokia 7 Works ² Works ² Replace Base Nokia X5 Works Works OnePlus One Works Works iFixit, Replace Base OnePlus X Works Works Replace Base PinePhone Works Works Xiaomi Mi A1 Works Works Replace Base Xiaomi Redmi Note 4 Works Works Notes:\n¹ The earpiece is too thin, it can work with padding to keep the contacts together.\n² Audio playback is very low quality.\nIncompatible earpiece speakers The following devices are known to have replacement earpiece speakers with dimensions too large to fit inside the PinePhone or PinePhone Pro.\nBlackberry Classic Q20 HTC Desire 500 HTC M10 Huawei Honor 7A Huawei Mate 10 Pro Huawei Y7 Prime 2018 OnePlus 2 Oppo Reno 5 4G Sony Xperia X Compact Sony Xperia XA1 Ultra Sony Xperia XP X Performance Sony Xperia XZ Replacing the mainboard The mainboard can be replaced if it is faulty. The replacement board does not have an operating system pre-installed, to test if everything is working after swapping the mainboard a flashed microSD card is required.\nTip Replacement boards come with an empty eMMC, which means that trying to boot from them looks like the board is faulty (no LEDs, no screen, no reaction of the phone). Please boot an operating System from a microSD card. Prior to replacing your PinePhone’s mainboard please read the steps outlined in bullet points below and watch the attached video.\nYou’ll need a small Phillips screwdriver and a prying tool to swap out the mainboard. Remove the PinePhone’s back cover. See your quick start guide for details. Remove the battery as well as any inserted SD and SIM cards. Unscrew all 15 Phillips head screws around the midframe of the phone. Gently pry up the midframe using a guitar pick or credit card corner. It is easiest to separate the midframe at one of the bottom edges. Work your way around all the sides of the phone until the midframe separates from the phone’s body. Detach all ribbon cables and \u0026ldquo;Lego\u0026rdquo; connectors. List of things to detach: 1) two \u0026ldquo;Lego\u0026rdquo; connects at the bottom of the mainboard. 2) u.FL antenna connect and touchscreen digitizer on PCD left side. 3) LCD ribbon cable top of mainboard, next to audio and UART jack. Pry the mainboard up gently from the left-hand side. Remove front and main cameras and reset them into the new mainboard. Check that the rubber proximity sensor housing is in the chassis, not stuck to the removed mainboard. Place the new mainboard in the chassis, hooking in on the plastic tabs on left side and pressing down firmly on opposite side, and follow the steps (7-2) in reverse. When reattaching the midframe take care that no cables are out of place or trapped, as they may be damaged when tightening screws. After swapping the mainboard the phone won’t boot as there is no OS on the replacement board’s eMMC preinstalled. To boot an OS insert a flashed SD card.\nA video tutorial by Martijn Braam can be found here (or alternatively a video tutorial by user brigadan with additional notes about the camera swap and proximity sensor isolator here):\nFlashing the ANX firmware Method 1 After swapping the mainboard the ANX7688 chip has to be flashed for full USB functionality.\nUnder GNU/Linux this can be done by downloading the latest ANX7688 firmware image on the phone:\nwget https://xff.cz/git/linux-firmware/plain/anx7688-fw.bin and executing as root (\u0026ldquo;sudo su\u0026rdquo;) on the phone:\ncp anx7688-fw.bin /lib/firmware/ echo 1 \u0026gt; /sys/class/typec/port0/device/flash_eeprom Method 2 Booting a factory test image will automatically flash the ANX7688 chip. See Factory Test OS for such an image.\nReplacing the screen Before attempting to replace the screen be sure to review the section on replacing the mainboard since that will get you most of the way there. Be aware that the replacement screen is actually the entire front frame of the phone and there are components that will need to be swapped from your old screen.\nMake sure you have a precision screwdriver set that has the correct size Philips tip. The screws are very small and the heads can easily be stripped if the screwdriver is not correct - if you feel your screwdriver slipping, stop what you are doing and try one that is a better fit. A magnetized screwdriver will help in not losing screws, as will a magnetic parts holder to keep them in while working. There are a number of components and cables as well as the insulator sheet under the battery that are glued in place. A hair dryer will loosen the glue and make them much easier to remove. You may want to order extra cables along with the screen just in case. The vibration motor, which is part of the USB-C board assembly and glued into place, will come apart easily and be damaged if you pry it up in the wrong place. Make sure you pry from underneath the complete part, not midway on its housing. The ribbon cable attaching this to the USB-C board is small, thin, and fragile so be careful with that as well. The new screen comes with new side switches and insulator sheet but there are a number of parts that need to be transferred from the old screen, like the thin coax cable running up the side, the phone ear speaker, proximity sensor gasket, and a gold-colored mesh glued in place that needs to be transferred to a flexible circuit included on the new screen. If you don’t swap over the proximity sensor rubber gasket the screen will immediately turn off after logging in. Be careful when routing the coax cable that it goes around the screw holes or you may drive a screw right through the cable. Take your time, use the right tools, be careful and you should be rewarded with success.\nHardware issues SIM reader The SIM reader may fail to read a SIM card (reporting \u0026lsquo;sim-missing\u0026rsquo; in mmcli), possibly due to deformed pins (if you put your SIM adapter in without a SIM), or due to a warped SIM card adapter.\nA possible solution is to bend the pins back (using a plastic spudger), and/or use a different SIM card adapter (which your carrier may provide to you).\nUSB-C side board Many issues with the USB-C side board can be fixed by replacing the USB-C side noard\nInternal microphone The microphone may stop working or occasionally stop working or give off static when power is plugged in.\nOne possible fix is to shim U101 (as seen on the back side of the USB-C side board) with a piece of paper or cardboard, see https://wiki.pine64.org/wiki/User:Earboxer/Shim_U101.\nBottom speaker The bottom speaker may stop working, especially if you have recently mishandled the USB-C side board, stressing the point of connection between the circuit board and the circuit flex. This can be fixed by touching up the solder between the two.\nMods There are a number of options to hardware mod the PinePhone.\nSome are upgrades to fix issues that were not done optimally in the production of that version of the electronics, and some are to add options that were not part of the phone spec.\nGeneral Make pictures of the situation before and after your mods, so you can compare the change, and don’t need to disassemble the device to get the right pics later.\nLaser-cut parts User Mcyam2 has created some laser-cut templates for the rear facing components here:\nhttps://imgur.com/a/LAUatOa\nhttps://anonfiles.com/L0BeK5L5oe/ppsvg-backplate-CUTOUT_svg\nOriginally based on silver’s work on a 3d printed rear frame\n3D-printed parts Silver has created a 3D-printable rear frame for the PinePhone and used it to create a folding keyboard design (work in progress), User:Silver/3d printed a folding keyboard mostly.\nhttps://ibb.co/album/ScDttH\nhttps://www.youmagine.com/designs/pinephone-folding-keyboard-mockup\nPCBs https://github.com/SMR404/PinephonePogoBreakout\nhttps://github.com/jnavarro7/pinephone_flex_breakout_board_grove\nBraveheart Edition Warning These are fixes for hardware bugs for old revisions of the PinePhone (from 2019 and early 2020). They do not apply to current revisions. PMIC mod - Stops the battery drain from a shutdown phone, draining the battery to 0V. VCONN mod - Unblocks the USB-C power negotiation rail, so convergence functions are unlocked. PMIC mod PinePhone 1.1 VBUS power usage hardware fix\nThe original description of this fix is given on megi’s pager here https://xnux.eu/devices/pp-pmic-fix.jpg\nVCONN mod See below.\nBraveheart Edition and UBPorts Community Edition Warning These are fixes for hardware bugs for old revisions of the PinePhone (from 2019 and early 2020). They do not apply to current revisions. VCONN mod - Unblocks the USB-C power negotiation rail, so convergence functions are unlocked. There are also a number of mods that can be done adding more functions by adding extra hardware to the pogo pins, and a number of options to change the screen protector.\nAt this moment there are not many pogo addons, and most are just connector boards. Likely the makers will add links to these projects to this page. Pine is looking into adding a N900 style keyboard attached to these pins.\nVCONN mod The original description of this fix is given on megi’s pager here https://xnux.eu/devices/pp-usbc-fix.jpg There is a discussion on the merits of the different ways to do the fix.\nVCONN mod, Removal only PinePhone 1.2 VCONN hardware fix\nThere are now a few documented ways,\nRemoval only, the tweezer \u0026ldquo;stupid\u0026rdquo; way: https://www.youtube.com/watch?v=j3jc7Mvn9Eo Removal only, the soldering iron \u0026ldquo;less stupid\u0026rdquo; way: https://www.youtube.com/watch?v=ZqOb45N2sMc There are hopefully videos coming doing it the proper way, and so they can be linked here.\nAfter this the firmware for the power negotiation chip needs to be upgraded, this can be done by running the factory test image, version https://images.postmarketos.org/pinephone/pine64-pinephone-20200724-factorytest55.img.xz or higher. This will do the firmware flashing and respond with a message indicating the state. After this the phone is ready for its added functions. ANX states:\nNo CC Fix - Fix not applied No USB Cable - No USB-C connection, cannot upgrade firmware OK - Firmware Applied, you are all set VCONN mod, Replacement Using 2x NCP334FCT2G you could do the full fix, making VCONN powered devices able to negotiate power. IT needs the parts to be removed first without damaging the pads, and then replacing the parts.\nFurther mods PinePhone 1.1 VBUS power usage Hardware Fix\nPinePhone 1.2 VCONN Hardware Fix\nPinePhone 1.2b R1318 backlight Hardware Fix\nPinePhone 1.1 VBUS power usage Hardware Fix This page details a hardware fix for an issue that affects some early v1.1 Braveheart units (fixed since 1.2 community edition included).\nThe issue was PinePhone_v1.1-Braveheart#Excess_power_usage_while_driving_VBUS by megi.\nTODO: Add more pictures and schematics, better reference the fix origin and tradeofs, remove TODOs/FIXMEs.\nAffected Units PinePhone v1.1 - Braveheart FIXME: confirm \u0026ldquo;Project Don’t Be Evil\u0026rdquo; devkit and PinePhone v1.0 - Developer batch are unaffected.\nDisclaimer Though easier to perform than the PinePhone 1.2 VCONN hardware fix, this fix requires desoldering relatively small Surface Mount Technology (SMT) components, therefore some experience with soldering is recommended.\nIssue description TODO: pictures\nThe AXP803 cannot detect when the USB port is powered by the battery. Therefore, the Power Management IC (PMIC) continues draining current from it. This is especially problematic since this USB port is powered from the battery with the USB OTG boost regulator. One of the symptoms is the battery discharging rather quickly even when the phone is powered off.\nWorkaround HW workaround is desoldering the U1301 regulator (TODO: describe its role) and shorting pads for R1309 on the PCB (this is a \u0026ldquo;0 ohm\u0026rdquo; resistor on the schematic, so it’s completely fine).\nShorting the pads is easy to do with some solder (while carefully avoiding to short it with nearby resistors).\nDesoldering the regulator is harder to do, since its large pads are designed to use the PCB as a heatsink and will happily cool down while you are trying to melt it. It should be possible to use properly sized pliers to cut the pins first, please edit if you attempt this.\nPlease be careful not to overheat nearby components trough the PCB traces when applying heat to the regulator. It can be helpful to start the operation with melting some leaded solder tin together with the pads, and lifting the regulator while applying heat also helps. Start with the side that has only one pad: though it is bigger, it should be easier to lift up. It might be useful to apply a relatively large quantity of molten solder tin to each pin, in turn, while lifting the regulator, to reduce the PCB heatsink effectiveness.\nFeel free to add your experiences and tips here.\nTradeoffs TODO: Unknown to the author\nProper fix TODO\nSources and tutorials Tutorial from megi Description from megi at the end of the page PinePhone 1.2 VCONN Hardware Fix This page details a hardware fix for an issue that was found on early PinePhone hardware revisions (see PinePhone for an overview of the different revisions) and has been fixed since the 1.2a hardware revision.\nThe issue was PinePhone_v1.1-Braveheart#USB-C_CC_pins_are_pulled_to_the_GND_by_AW3512.28VCONN_switches.29_when_VCONN_is_off_ by megi.\nAffected Units Requires confirmation: \u0026ldquo;Project Don’t Be Evil\u0026rdquo; devkit Requires confirmation: PinePhone v1.0 - Developer batch PinePhone v1.1 - Braveheart PinePhone v1.2 - UBports Community Edition Disclaimer This fix requires desoldering tiny (1 mm per 1 mm, from the datasheet) BGA components, therefore some experience with soldering is highly recommended.\nIssue description Close-up picture of the two identical switches the issue originates from, with the ANX USB controller in the frame\nExcerpt from the PinePhone schematic showing the two components.\nThe USB standard specifies that both halves (top and bottom) of the USB-C port contains one \u0026ldquo;CC\u0026rdquo; pin (CC1 and CC2, respectively). A regular cable will connect a CC pin from one end to the other end. This allows detecting which way the cable is plugged. Some active USB-C cables exist (both \u0026ldquo;e-marked\u0026rdquo; and \u0026ldquo;managed active cables\u0026rdquo;); they contain a chip, which needs to be powered. This is done by having one of the cable end connect its CC pins to 5V and VCONN, and requires switches to plug the right CC pin to the right voltage.\nThe issue arises due to the switches that were chosen up to v1.2a (the a revision excluded) of the PCB assembly: the infamous AW3512, labelled U1305 and U1309 on the schematic. Instead of leaving the output pin \u0026ldquo;dangling\u0026rdquo; with a high impedance when disabled, the switch pull the output down. This feature is intended for discharging a capacitor, hence its \u0026ldquo;Quick output discharge\u0026rdquo; name. This is an excerpt from the datasheet:\n\u0026ldquo;The AW3512/AW35122 includes the Quick Output Discharge (QOD) feature, in order to discharge the application capacitor connected on OUT pin. When EN pin is set to low level (disable state), a discharge resistance with a typical value of 276Ω (AW35122: 75Ω) is connected between the output and ground, pull down the output and prevent it from floating when the device is disabled.\u0026rdquo;\nThis issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There’s no SW workaround for automatic detection of cable plug or power role.\nIn SW this could theoretically be worked around by manual selection of PinePhone’s data and power role by the user, but hasn’t been attempted, and might damage hardware if done incorrectly.\nWorkaround Hardware workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles.\nTradeoffs Voiding the VCONN control might (TODO: gather more data) prevent some accessories from working, notably those using an active cable.\nProper fix HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn’t have the \u0026ldquo;quick discharge function\u0026rdquo; that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement. PCBA revision 1.2a onwards incorporate that fix.\nSources and tutorials megi’s writeup another writeup from megi with a few words on firmware Video: \u0026ldquo;The right way\u0026rdquo; with a hot air gun/reflow station, by mozzwald Video: \u0026ldquo;The equally stupid way\u0026rdquo;, workaround video by Dalton, using a soldering iron. Less chances to permanently damage the board than the next if you are handy with a soldering iron, but still high. Video: \u0026ldquo;The stupid way\u0026rdquo; workaround video by Lukasz, with pliers. Slightly damages the circuit board, preventing you from soldering the replacement chips at a later point. You might be fine with this. PinePhone 1.2b R1318 backlight Hardware Fix This page details a hardware fix for an issue that was found on early PinePhone hardware revisions (see PinePhone for an overview of the different revisions) and has been fixed since the 1.2b hardware revision.\nAffected Units PinePhone v1.2 - UBports Community Edition PinePhone v1.2a - postmarketOS Community Edition Disclaimer This fix requires desoldering a tiny resistor, therefore some experience with soldering is highly recommended.\nIssue description When connecting a VBUS powered device to the affected devices, like USB-C docks or hubs, the brightness changes significantly. The cause of the issue was a VBUS_CTRL signal provided by ANX7688 to control VBUS power direction. The signal is connected to AXP803 to tell it to not trying to charge from VBUS when the VBUS is generated from the battery. The signal is connected to the PL9 pin of the SoC, withut there being a reason for that. VBUS_CTRL is a 3.3V signal and the PL port is a 1.8V port. The issue was introduced in the 1.2 board revision.\nFix The fix of the issue is to remove the R1318 resistor.\nA detailed instruction will follow here.\nR1318 location on the board\nSources and tutorials Megi’s blog: Backlight changes when swithcing between USB-C power modes Software tricks Crust\nMMS with Matrix\nPower Management\nSecurity\nThermal tweaks\nSecurity Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. Encryption While encryption alone is not sufficient to protect sensitive data, it is an important tool to safeguard data in certain attack vectors.\nFull-Disk Encryption Full-disk encryption encrypts the entire disk (except for the boot bits). Currently some operating systems such as postmarketOS and Mobian offer an installation image, which have the option to encrypt the entire disk. Some operating systems, such as postmarketOS (via pmbootstrap) and Arch Arm also offer an installation script for an fully encrypted installation.\nDecryption is done at boot after entering the encryption password via an on-screen keyboard (Osk-sdl).\nEncrypted home directory SSH An open SSH port is a typical gateway for attackers on any device exposed to the public Internet. Exposed devices might be attacked within minutes after being exposed. Typically such attacks try default passwords such as \u0026ldquo;12345\u0026rdquo;, potentially putting the user at risk after connecting the phone to an open/unsecured access point, activating mobile data or mobile Internet.\nFor safety reasons it is highly recommended to only use SSH in combination with keys, instead of simple numeric passwords.\nTo generate a key pair for ssh, open a terminal on your local computer, and type\nssh-keygen It will ask you where to save the key pair. By default, this is in ~./ssh . Usually it’s best to keep it in the default location. If you have previously generated a key pair, it will ask you if you wish to overwrite your existing one. You probably do not want to do this, as you will no longer be able to use your existing key pair for authentication.\nNext, you will be prompted to enter a passphrase. It is recommended that you use this feature.\nNote Do not share your private key with anyone, nor change its file permissions Now, you must start SSHD on your distribution of choice, as this process varies depending on init system, please consult the documentation of your distribution.\nNow enabled, you can copy over your public key either manually, or via\nssh-copy-id $username@$ipaddress replacing the variables \u0026ldquo;$username\u0026rdquo; and \u0026ldquo;$ipaddress\u0026rdquo; with the appropriate values, e.g user@192.168.1.15\nYou may see a message similar to this\nOutput The authenticity of host '192.168.1.15 (192.168.1.15)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:57:fe:23:44:e1:55:00:bd:d6:6d:42:fe. Are you sure you want to continue connecting (yes/no)? This will happen anytime you connect to a new host. Type \u0026ldquo;yes\u0026rdquo; and hit enter.\nfinally, to disable password authentication, type\nsed -i -E 's/#?PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config as root on your PinePhone and either restart the sshd service, or reboot your device\nCrust As per the README.md on the crust github:\nCrust improves battery life and thermal performance by implementing a deep sleep state. During deep sleep, the CPU cores, the DRAM controller, and most onboard peripherals are powered down, reducing power consumption by 80% or more compared to an idle device.\nFor this to work, Crust runs outside the main CPU and DRAM, on a dedicated always-on microprocessor called a System Control Processor (SCP). Crust is designed to run on a specific SCP implementation, Allwinner’s AR100.\nTo build crust manually with U-Boot you can find instructions Here.\nRTC wakeups It is possible to set the device to wakeup at a specific time or after a certain number of seconds using rtcwake: rtcwake -m mem -s 10\nThis example will put the device to sleep for 10 seconds and then wake it up. More information on the rtcwake command can be found in the man pages\nManual suspend For manually suspending the device on distributions with Systemd you can use the following command with super user permissions: systemctl suspend\nOn non-systemd distributions you can directly echo: echo mem \u0026gt; /sys/power/state\nMMS with Matrix Screenshot of fractal displaying an MMS conversation\nThe one known way to get MMS fully (meaning pictures and group messages) working is by relaying all SMS and MMS to a matrix server and using a matrix client to interact with them. https://gitlab.com/untidylamp/mmmpuppet is the bridge used here\nOutgoing messages over the max size are sent as a link. The link will not resolve if matrix is hosted on the PinePhone itself, so resize your images. An easy way might be to take a screenshot of your image viewer and send that image instead.\nThis method works with a local-to-the-pinephone matrix server but you could instead use a public one on the internet. Free accounts on matrix.org should work fine for example. Sleep may need to be disabled for non-local servers or the bridge can get stuck.\nInstall packages Arch Start with a nice and up-to-date Danctnix\u0026rsquo; Arch ARM PinePhone installation, mine is from April 20 2021. SSH into the PinePhone and then run this to install all the needed packages\nsudo pacman -Sy matrix-synapse fractal python-matrix_client python-gobject git meson ninja base-devel python-matrix-nio python-dbus Start the service\nsudo systemctl enable synapse sudo systemctl start synapse Mobian Flash a fresh mobian nightly (Tested September 28 2021) and install the following:\nsudo apt install matrix-synapse fractal mmsd-tng python3-matrix-nio python3-vobject python3-aiofiles git Set up Matrix Synapse on localhost Skip this if you will be using a remote homeserver. Make a new config with the server name set to local host.\nArch cd /etc/synapse/ sudo python -m synapse.app.homeserver --server-name localhost --config-path homeserver.yaml --generate-config --report-stats=no sudo vi /usr/lib/systemd/user/matrix-synapse.service Description=Multimedia Messaging Service Daemon After=ModemManager.service ExecStart= python3 -m synapse.app.homeserver --config-path=/etc/matrix/homeserver.yaml Restart=on-failure RestartSec=10s WantedBy=default.target Start the service\nsystemctl enable matrix-synapse --user systemctl start matrix-synapse --user Mobian cd /etc/matrix-synapse/ sudo rm homeserver.* sudo python3 -m synapse.app.homeserver --server-name localhost --config-path homeserver.yaml --generate-config --report-stats=no sudo service matrix-synapse start Add new matrix users in /etc/synapse/ (arch) or /etc/matrix-synapse/ (mobian)\nregister_new_matrix_user -c homeserver.yaml http://localhost:8008 # New user name and pw will both be pp register_new_matrix_user -c homeserver.yaml http://localhost:8008 # New user name and pw will both be mm Open fractal and log into the homeserver at http://localhost:8008 with username pp and password pp\nSet up MMSD From git Note: historical, no longer needed, mmsdtng commonly packaged\nGrab the git repository and install it:\ncd ~ git clone https://source.puri.sm/kop316/mmsd.git cd mmsd meson _build meson compile -C _build meson test -C _build sudo meson install -C _build sudo vi /usr/lib/systemd/user/mmsd-mm.service Description=Multimedia Messaging Service Daemon After=ModemManager.service ExecStart=/usr/local/bin/mmsd -n -d Restart=on-failure RestartSec=10s WantedBy=default.target sudo chmod 644 /usr/lib/systemd/user/mmsd-mm.service systemctl enable mmsd-mm.service --user systemctl start mmsd-mm --user Settings for T-Mobile This config works for me\nAfter starting mmsdtng the first time it should generate a config. Edit the following 3 options:\nvi ~/.mms/modemmanager/ModemManagerSettings CarrierMMSC=http://mms.msg.eng.t-mobile.com/mms/wapenc MMS_APN=fast.t-mobile.com AutoProcessSMSWAP=true Restart MMSD ModemManager service systemctl restart mmsdtng Install MMS bridge Grab it from git and put things in places\ncd ~ git clone https://gitlab.com/untidylamp/mmmpuppet.git cd mmmpuppet chmod +x mmmpuppet.py sudo cp mmm*.py /usr/local/bin/ mkdir -p $HOME/.config/mmm/ cp conf.json.sample $HOME/.config/mmm/conf.json Configure MMS bridge This will mostly take care of editing the config for you if you are running a local matrix server.\nsed -i \u0026#39;s^\u0026#34;https://matrix-client.matrix.org\u0026#34;^\u0026#34;http://localhost:8008\u0026#34;^\u0026#39; $HOME/.config/mmm/conf.json sed -i \u0026#39;s^\u0026#34;@bot_account:matrix.org\u0026#34;^\u0026#34;@mm:localhost\u0026#34;^\u0026#39; $HOME/.config/mmm/conf.json sed -i \u0026#39;s^\u0026#34;Change_me\u0026#34;^\u0026#34;mm\u0026#34;^\u0026#39; $HOME/.config/mmm/conf.json sed -i \u0026#39;s^\u0026#34;@your_accounts:matrix.org\u0026#34;^\u0026#34;@pp:localhost\u0026#34;^\u0026#39; $HOME/.config/mmm/conf.json You actually have to fill these two out yourself. I put \u0026ldquo;US\u0026rdquo; and my +1 and rest of 10 digit number.\nvi $HOME/.config/mmm/conf.json \u0026#34;cell_number\u0026#34;: \u0026#34;+15554441234\u0026#34;, \u0026#34;cell_country\u0026#34;: \u0026#34;CA\u0026#34;, Now we need to run it once to process the config file and remove secrets (It will say it has done this and exit on first run)\n/usr/local/bin/mmmpuppet.py check it out now\ncat $HOME/.config/mmm/conf.json If it doesn’t change the file to remove all the linebreaks then it didn’t like it. Figure out why by looking at the log file.\ncat ~/.config/mmm/mmmpuppet.log Go fix whatever went wrong. Which should be nothing. You should have seen a message like this as output before it returns you to a prompt:\nLogin successful. Config updated with token. Run again to start bridge. Set up MMS bridge service Make systemd unit\nsudo vi /usr/lib/systemd/user/mmmpuppet.service Description=Starts mmmpuppet interface After=mmsd-mm.service ExecStart=/usr/bin/python3 /usr/local/bin/mmmpuppet.py Restart=on-failure RestartSec=10s WantedBy=default.target and start it\nsudo chmod 644 /usr/lib/systemd/user/mmmpuppet.service systemctl enable mmmpuppet.service --user systemctl start mmmpuppet.service --user See if services are running:\nps aux | grep mm It should show something like this even after reboot\nalarm 6374 0.0 0.3 235364 7752 ? Ssl 22:44 0:00 /usr/local/bin/mmsd -n -d alarm 6825 9.8 2.7 224976 54188 ? Ssl 22:52 0:05 /usr/bin/python3 /usr/local/bin/mmmpuppet.py Remove Chatty For Arch use Pacman to remove Chatty.\nMobian:\napt remove chatty Don\u0026rsquo;t forget to enable data You can get SMS but not MMS with mobile data off\nLaunch fractal Log in with this homeserver: http://localhost:8008. Username is pp and password is pp.\nLogins are not saved. You need to add a new item named login to the gnome keyring manually to fix it. See: https://wiki.mobian.org/doku.php?id=fractal\nBasically apt install seahorse, open \u0026ldquo;passwords and keys\u0026rdquo; in the app drawer, click new (plus), select password keyring, and name it \u0026ldquo;login\u0026rdquo; (all lower no quotes). Then autologin will work as it should.\nDone At this point if you get a message a new room should be created by the bridge bot which you will be invited to. You can start a new conversation by creating a new room, setting the topic with phone numbers of participants, and then inviting the mm user. See the mmmpuppet readme for examples.\nOther clients quaternion also seems to work but has clunky UI issues. Might work better with scaling\nPower Management The data on this page is based on the the PinePhone v1.1 - Braveheart.\nRegulators Current Assignments Name/GPIO Output Voltage Can disable at runtime? Can disable in suspend? Consumers (internal/external separated by semicolon) DCDC1 3.3V No No (VCC-IO) VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN DCDC2 DVFS No Yes VDD-CPUX DCDC3 DVFS N/A N/A VDD-CPUX (polyphase with DCDC2) DCDC4 N/A Yes Yes Not used DCDC5 1.2V No Yes (future) VCC-DRAM; DRAM DCDC6 1.1V No Yes (future) VDD-SYS DC1SW N/A Yes Yes Not used ALDO1 2.8V Yes Yes VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C ALDO2 1.8V No No (VCC-PL) VCC-PL; Pogo INT ALDO3 3.0V No No (KEYADC) AVCC, KEYADC, VCC-PLL DLDO1 3.3V No No (ANX7688 AVDD33) HVCC, VCC-DSI; ANX7688 [AVDD33, HDMI_VT, I2C, ANX-V1.0 Enable, VCONN_EN Disable Pull-up], HDMI [DDC, HPD], Proximity LED, Sensor I2C, Sensor VDD DLDO2 1.8V? 3.3V? Yes Yes MIPI-DSI VIO DLDO3 2.8V Yes Yes Camera AVDD DLDO4 1.8V-3.3V Yes Yes VCC-PG; VQMMC1 ELDO1 1.8V No No (DRAM) CPVDD; DRAM ELDO2 N/A Yes Yes Not used ELDO3 1.8V Yes Yes Camera DVDD FLDO1 1.2V Yes Yes HSIC-VCC (not used) FLDO2 1.1V No No (VDD-CPUS) VDD-CPUS GPIO0-LDO 3.3V Yes Yes Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC] GPIO1-LDO 1.8V No No (ANX7688 DVDD1V8) ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up] PD6 5.0V Yes Yes USB OTG PD8 5.0V Yes Yes Pogo supply, USB OTG via PD6 PD9 5.0V Yes Yes VCONN (USB Type C) PH10 PWM Yes Yes Backlight PL7 VBAT Yes Yes Modem ANX-V1.0 1.0V Yes Yes ANX7688 [AVDD1V0, DVDD1V0] Suggested Regulator Hardware Changes ANX7688 Move ANX7688 AVDD33 (the chip input only, not the other things connected to 3v3) and ANX7688 I2C Level Shift (3.3V side) from DLD01 to DCDC1, and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to ANX1.8V Move ANX7688 ANX1.8V from GPIO1-LDO to ALDO2 Move ANX7688 ANX-V1.0 Regulator Enable (R1352) from DLDO1 to a GPIO These are all medium priority.\nThe result of these changes would be that:\nThe always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered GPIO1-LDO only needs to be powered when a USB cable is detected, and is enough to power the rest of the chip (except HDMI) DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in Assignments after Suggested Changes Note: Only regulators that were modified are included here.\nName/GPIO Output Voltage Can disable at runtime? Can disable in suspend? Consumers (internal/external separated by semicolon) DCDC1 3.3V No No (VCC-IO) VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; ANX7688 [AVDD33, I2C], Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN ALDO2 1.8V No No (VCC-PL) VCC-PL; ANX7688 [DVDD1V8], Pogo INT DLDO1 3.3V Yes Yes HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD GPIO0-LDO 3.3V Yes Yes Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC] GPIO1-LDO 1.8V Yes Yes ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up] Open Questions How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both? Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places. From LCD and LCD controller datasheets, this should be 1.8V. If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent? Looks like this is N/A, because DLDO2 should be 1.8V. GPIO Current Modem Pin Assignments Note: only pins relevant to power management are included in this table.\nPin Signal Name Description Direction (as modem) Needed in suspend? Connected to 1 WAKEUP_IN Drive low to wake up the modem I No PH7 (active high) 2 AP_READY Drive high/low to signal the A64 is ready to receive URCs I No (if held) NC 4 W_DISABLE# Drive low to enter Airplane Mode I No (if held/tristate) PH8 (active high) 20 RESET_N Drive low to reset the modem I No (if held/tristate) PC4 (active high) 21 PWRKEY Drive low to turn the modem on/off I No (if held/tristate) PB3 (active high) 61 STATUS Open drain output, pulled low when the modem is on O No PB3 62 RI Pulled low to request host wakeup O Yes PB2 66 DTR Drive low to wake up the modem I No PL6 (active low) Current Port L Pin Assignments Pin Signal Name Description Direction Needed in suspend? PL0 PMU-SCK AXP803 I2C/RSB Clock O Yes PL1 PMU-SDA AXP803 I2C/RSB Data I/O Yes PL2 WL-REG-ON Not Connected N/A N/A PL3 WL-WAKE-AP Wake-on-WLAN Interrupt I Yes PL4 BT-RST-N Bluetooth Reset Control O No (if held) PL5 BT-WAKE-AP Wake-on-BT Interrupt I Yes PL6 DTR Modem DTR (Wakeup Request) O No PL7 4G-PWR-BAT Modem Power Supply Control O No (if held) PL8 ANX7688-CABLE_DET ANX7688 Cable Detection Interrupt I Yes PL9 ANX_RESET ANX7688 Reset Control O No (if held) PL10 LCD-PWM LCD Backlight PWM Brightness Control O No PL11 ANX7688-INT ANX7688 Alert Interrupt I Yes PL12 POGO-INT Pogo Pin Interrupt I Yes Pins Held During Suspend Pins Active During Suspend Suggested GPIO Hardware Changes Connect WL-REG-ON (PL2) to WL-PMU-EN (WiFi). bugfix Connect the LIS3MDL DRDY pin, not INT pin, to PB1. bugfix Reconnect LINEOUTN to make the line output differential. Connect PH7 to AP_READY instead of WAKEUP_IN. Since the A64 needs to drive this pin high (no pull-up on the modem side), this uses the level shifter channel previously used by RI (U1503 channel 4). Swap DTR (was at PL6, now at PB2 with U1503 channel 3 level shift) and RI (was at PB2, now at PL6 with no level shift, but a pull-up to ALDO2 on the A64 side*). partly a bugfix Connect the modem PWRKEY to PB3 only, not STATUS or DCDC1 (depopulate R1526). bugfix Connect the modem STATUS to PH9. This is an open-drain signal, so it needs a pull-up on the A64 side. bugfix Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART). Connect the modem debug UART TX/RX to PD0-1. Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere. Connect both AXP803 USB-DRVVBUS (populate R1300) and ANX7688 VBUS_CTRL to DRVVBUS (in addition to PD6). Connecting to ANX7688 VBUS_CTRL would need a level shift to 1.8V. Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level. Alternatively, do not connect ANX7688 VBUS_CTRL*, and at least populate R1300 to connect AXP803 USB-DRVVBUS*. Reorient the transistors for ANX_POWER (PD10) and ANX_RESET (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.) Remove the transistors inverting VCONN1_EN and VCONN2_EN*, and use a pull-up to DVDD1V8* (that is really already present) instead of the pull-up to 3V3. Note: Changes 1-7 and 11 are high priority. Changes 12-13 are medium priority. Changes 8-10 are low priority.\n* There should be at least one pin where the default value at boot changes, due to being pulled differently, for use in distinguishing the hardware revisions. In v1.1, PL6 reads 0 at boot. Since RI is an active-low interrupt, it needs a pull up. And it doesn’t need any level translation. So that’s our perfect opportunity. If PL6 reads low at boot, it’s a v1.1 device; if PL6 reads high at boot, it’s a v1.2 device.\nOpen Questions What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1? Currently STATUS pin is connected to PWRKEY and to PB3. STATUS can’t be read reliably since voltage divider from R1526 and R1517 places the STATUS signal at 0V or 0.5Vcc-IO, which is unspecified input value according to A64 datasheet (Vih is 0.7Vcc-IO, Vil is 0.3*Vcc-IO, the range in between is unspecified). Thermal tweaks This page explains how to read the thermal sensor data, and how to read and change the default settings.\nUnder Linux Warning Setting wrong values for the thermal trip points poses a risk. These instructions are directed towards expert-level users and developers. Thermal management of the PinePhone CPU is handled by the thermal framework of the Linux kernel. Depending on the Linux distribution used on a PinePhone, the default settings may differ. It may be advised to lower the settings (i.e. the thermal trip point temperatures) to prevent the phone components from being damaged by excessive heat.\nCurrent CPU temperature can be displayed using the following command:\ncat /sys/class/thermal/thermal_zone0/temp The unit for all numeric values is millidegree Celsius. To read the thermal trip point types and current trip point temperatures, use the following:\ngrep . /sys/class/thermal/thermal_zone0/trip_point_*_temp grep . /sys/class/thermal/thermal_zone0/trip_point_*_type The default trip point temperatures are also available in the A64 device tree. The possible names and associated meanings for the trip point types are the following:\n\u0026ldquo;active\u0026rdquo; – a trip point to enable active cooling \u0026ldquo;passive\u0026rdquo; – a trip point to enable passive cooling \u0026ldquo;hot\u0026rdquo; – a trip point to notify emergency \u0026ldquo;critical\u0026rdquo; – hardware not reliable The values for the trip point temperatures can be lowered individually, but make sure the trip points have the correct value for their corresponding trip type, e.g. don’t simply swap the values for the first and the second trip point. Make sure not to set values higher than 110000 (i.e. 110 degrees Celsius, which is the default value) for the third threshold, as it may cause damage to the phone. Use the following commands:\necho 55000 \u0026gt; /sys/class/thermal/thermal_zone0/trip_point_0_temp # passive echo 75000 \u0026gt; /sys/class/thermal/thermal_zone0/trip_point_1_temp # hot echo 100000 \u0026gt; /sys/class/thermal/thermal_zone0/trip_point_2_temp # critical Further information can be found in these documents from the Linux kenel source:\nDocumentation/thermal/sysfs-api.txt Documentation/hwmon/sysfs-interface Documentation/devicetree/bindings/thermal/thermal.txt Hardware revisions The history of the PinePhone CEs\nThe following are all hardware revisions of the PinePhone that have existed, ordered by the time of their releases:\nProject Anakin - Development kit Project Don’t be evil - Development kit PinePhone v1.0 - Developer Edition PinePhone v1.1 - Braveheart Edition PinePhone v1.2 - Ubports Community Edition PinePhone v1.2a - postmarketOS Community Edition PinePhone v1.2b - Manjaro Community Edition, KDE Community Edition, Mobian Community Edition and Beta Edition PinePhone v1.0 - Dev The PinePhone v1.0 is the developer hardware revision of the PinePhone.\nThis page contains resources which are exclusive to the 1.0 revision of the PinePhone. For other revisions, or for resources related to all PinePhone revisions, see PinePhone.\nSchematic PinePhone v1.0 Schematic 20190708 Pinephone V1.0 Mainboard Top Layer Silkscreen Pinephone V1.0 Mainboard Bottom Layer Silkscreen Pinephone V1.0 Daughterboard Top Layer Silkscreen Pinephone V1.0 Daughterboard Bottom Layer Silkscreen Known issues See the known issues with v1.1 (Braveheart), which are all carried forward from v1.0.\nPinePhone v1.1 - Braveheart The PinePhone v1.1 \u0026ldquo;Braveheart\u0026rdquo; is a hardware revision of the PinePhone that shipped in January 2020.\nThis page contains resources which are exclusive to the 1.1 revision of the PinePhone. For newer revisions or for resources related to other PinePhone revisions see PinePhone.\nSchematic Hardware schematic\nChanges from 1.0 Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.\nAdded CPU shielding and cover plate Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot Connect WiFi enable to VD33 Set the EG25G’s PWRKEY on by default (see resistor R1526) Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software. Add voltage shift to Pogo pins I2C-CLK, I2C-DATA, and INT. The Pogo Pin specified voltage is 3.3v while the A64’s I2C is 2.8V. A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential DIY Hardware fixes Some of the known issues can be fixed with more or less involved hardware modifications:\nVCONN mod: USB-C CC pins are pulled to GND, removing small switches can make USB-OTG work. A proper fix is to replace those with another component. PMIC mod / PinePhone 1.1 VBUS power usage hardware fix to lower power consumption, especially when the phone is powered off. Known issues This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision. Most of these were fixed in the 1.2 revision mainboard.\nNeed a way to distinguish v1.1 from v1.2 from U-Boot SPL Resolved in v1.2 by PL6 being connected directly to the modem, instead of through the level shifter, so it is pulled low at boot.\nTo load the correct device tree, there needs to be some hardware feature that can distinguish the two versions. This can be as simple as an I/O pin that is pulled differently by default between v1.1 and v1.2. Reading the pin in SPL will tell us which device tree to use.\nWiFi module cannot be disabled or reset in software Resolved in v1.2 by connecting PL2 to the WiFi module’s WiFi reset pin.\nNeither the WL-REG-ON nor WL-PMU-EN signal is connected to anything, and the WiFi module’s CHIP_EN pin is connected (through the privacy switch) to a regulator that cannot be turned off (easily, if at all). So while the privacy switch works, there’s no way to disable the WiFi module in software. This will lead to excess power consumption when WiFi is turned off.\nMagnetometer\u0026rsquo;s IRQ signal is routed to the wrong pin Resolved in v1.2 by connecting the magnetometer’s DRDY pin to PB1.\nIt needs to go to DRDY, not to INT. The kernel driver expects the trigger events to be fired when DRDY changes, and does not even configure the interrupts to be enabled on the INT pin.\nSoftware workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.\nSpeaker output could be differential Resolved in v1.2 by connecting LINEOUTP to the speaker amplifier’s INP input.\nUsing a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.\nModem AP_READY signal is not connected Resolved in v1.2 by connecting PH7 to AP_READY instead of WAKEUP_IN.\nThe modem’s power management documentation describes how to implement modem power saving. The modem can wake up the host using either the Ring Indicator pin (section 4.5) or USB remote wakeup (section 4.3). Either way, it suggests the AP_READY signal needs to be connected. The modem needs that signal to know when the host is asleep (and the modem needs to queue its messages and wake it up), and when the host has finished waking up (and is ready to receive the queued messages).\nModem RI signal routing prevents wakeup Resolved in v1.2 by connecting RI to PL6.\nThe EG25G’s Ring Indicator (RI) pin is currently routed to GPIO pin PB2. The A64 needs to receive interrupts via this pin while suspended, so the modem can wake up the A64 (for incoming calls and text messages). The only GPIO bank that can receive interrupts while the A64 is suspended is Port L (on R_PIO).\nNote: Port L is powered by VCC-PL, and runs at 1v8, so it should not have a level shift to DCDC1/3v3 between the AP and the modem, like DTR currently has. The way DTR is currently connected is a bug.\nExcess power usage while driving VBUS Resolved in v1.2 by connecting PL9 and VBUS_CTRL on the ANX7688 to N_VBUSEN on the PMIC. A crude hardware workaround is also possible, see PinePhone 1.1 VBUS power usage Hardware Fix.\nThe N_VBUSEN/DRIVEVBUS input on the AXP803 PMIC, labeled USB-DRVVBUS on the schematic, is not connected to the USB OTG boost regulator enable input, because R1300 is marked \u0026ldquo;NC\u0026rdquo;. This prevents the AXP803 from automatically detecting when the USB port is being powered from the battery. Thus, the PMIC continues to draw power from the USB port, and this doubles the drain on the battery (since the whole phone is being powered by the USB OTG boost regulator). This could be fixed by populating R1300.\nThe ANX7688’s VBUS_CTRL pin should also be connected to the DRVVBUS signal to perform role switching in hardware without needing OS interaction. In that case PD6 becomes an input. Otherwise, we would need to hook up the VBUS status change interrupt from the ANX7688 to control the USB PHY driver.\nANX7688 power supply situation is problematic Resolved in v1.2 by powering always-on 3v3 from DCDC1, video-related 3v3 from DLDO1, 1v8 from GPIO-LDO1, and 1v0 controlled by PD11.\nANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).\nThe main 3v3 input, to AVDD33, should always be on according to the datasheet. For this reason, it should be connected to an always-on regulator, such as DCDC1, so DLDO1 can be turned off when the screen is off. It has extremely low power consumption. HDMI_VT is only needed during video transmission, and should remain connected to DLDO1. The only other 3v3 consumer is the VCONN_EN pull-ups. These could be pulled to GPIO1-LDO (1.8V) instead; the pins are open drain. The DVDD18 input should also always be on according to the datasheet. It has extremely low power consumption. I recommend connecting it and the PL11 pull-up to VCC-PL, so GPIO1-LDO can be turned off. The remaining 1v8 inputs only need to be enabled when a USB cable is connected (supply or OTG). They are connected to their own regulator (GPIO1-LDO), so that is fine. (Note that the next issue suggests removing the pull-ups for POWER_EN and RESET_N.) The 1v0 input is only needed when a USB cable is connected (supply or OTG). It is currently controlled by DLDO1, but I think controlling it with GPIO1-LDO would be an improvement. That way DLDO1 only needs to be enabled when transmitting video, not always when a cable is connected. Modem PWR_KEY signal resistor population Resolved in v1.2 by separating the modem PWRKEY (PB3) and STATUS (PH9) signals.\nOn the dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can’t do anything to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).\nIt would be nice to also have access to the STATUS signal from the modem, so that the driver can detect whether the modem is on or off (userspace might have turned modem off already via AT commands). Given that PWR_KEY pulse will either turn the modem on or off, based on the current status, it’s necessary to know the current status before sending the pulse.\nThere’s a STATUS signal routed to PWR_KEY on BraveHeart, that keeps the PWRKEY deasserted when the modem is on and it’s not possible to pull it up from PB3, even if R1516 would be optionally mounted.\nSo after powerup you can’t change PWR_KEY signal anymore from PB3 even if R1516 is mounted, and it’s not possible to turn off the modem via PB3.\nModem has access to sensors on I2C1 Resolved in v1.2 by disconnecting the modem’s I2C port.\nThe modem is a master on the I2C1 bus. A malicious firmware on the modem would be able to read the phone’s gravity/light/proximity sensors and prevent the main Linux OS from reading them. The modem’s audio design note describes the AT+QIIC command which can be used to read and write registers on I2C devices.\nAccording to the modem documentation, its I2C interface is only used for direct connection to a standalone audio codec. On the PinePhone, since the modem’s audio is routed through the A64 SoC, the modem’s I2C interface has no legitimate use.\nThe modem’s I2C interface should be left floating. U1503 pins A1, A2, B1, and B2 can be disconnected, and R1527/R1528 can be removed.\nAllow access the modem debug UART Not resolved in v1.2 \u0026ndash; would have required moving several other GPIOs.\nInstead of the modem’s I2C pins, which aren’t very useful (see above), it would be great to have access to the modem’s debug UART, for debugging/updating the modem. This could be on UART3 (PD0-PD1, no flow control), while the main modem UART is on UART4 (PD2-PD5, with flow control).\nModem UART flow control is broken Not resolved in v1.2 \u0026ndash; assumption is that USB will be used for high-bandwidth modem I/O.\nBB-TX and BB-RX are connected to UART3 (PD0/PD1). BB-RTS and BB-CTS are connected to UART4 (PD4/PD5). To use hardware flow control, TX/RX would need to be connected to UART4, swapping PD0/PD1 with the motor control and rear camera reset GPIOs at PD2/PD3. This would need a device tree change.\nHardware flow control can be disabled with the AT+IFC command, and USB can also be used for commands instead of the UART. So the impact of this problem is unclear.\nANX7688 power/reset control pulled the wrong way Not resolved in v1.2 \u0026ndash; this has minimal impact.\nBoth ANX_POWER_EN and ANX_RESET_N have pull-ups when they should not. Both signals need to be pulled low by default. They only need to be brought high (turning the chip on) when a USB cable is attached; and they should only be brought high after the 1v8 and 1v0 regulators are turned on. ANX_POWER_EN needs an external pull-down. ANX_RESET_N has an internal pull-down.\nVCONN_EN signals are possibly inverted Further investigation determined that the hardware is correct as-is in v1.1, so no change was made.\nI don’t have a datasheet for the AW3512 chips, but I assume the enable input is active-high. VCONN1_EN and VCONN2_EN are open-drain. When they are open, it appears that VCONN should be enabled. But right now, when they are open, VCONN is disabled, because the AW3512 EN pin will be pulled low by the FET.\nCameras have the same default I2C address Resolved in software by reprogramming the one of the cameras\u0026rsquo; I2C addresses at boot.\nThis makes it hard to keep both of them powered at the same time and switch quickly between them (on the per-frame basis) without having to re-initialize the sensors on each switch, which takes some time.\nUSB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There’s no SW workaround for automatic detection of cable plug or power role.\nIn SW this can only be worked around by manual selection of PinePhone’s data and power role by the user.\nHW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles. I confirmed that desoldering fixes the issue. (Howto: https://megous.com/dl/tmp/pp-usbc-fix.jpg)\nHW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn’t have the \u0026ldquo;quick discharge function\u0026rdquo; that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.\nThis issue is also present on the PinePhone 1.2 (CE) version and was fixed with revision 1.2a. See the workaround for affected revisions.\nPogo Pins supply 5v0, not 3v3 No hardware change suggested, to maintain accessory compatibility.\nThis is possibly just a documentation issue. The wiki claimed they provide a \u0026ldquo;3.3v power source\u0026rdquo;, and on this page, \u0026ldquo;The Pogo Pin specified voltage is 3.3v\u0026rdquo;. But according to the schematic, they are connected to USB-5V, the output of the 5V boost regulator.\nPinePhone v1.2 The PinePhone v1.2 is a hardware revision of the PinePhone that was shipped in 2020 as UBports Community Edition.\nThis page contains information and resources which are specific to the UBports Community Edition (v1.2 PCB) revision of the PinePhone. For other revisions or for resources related to all PinePhone revisions, see PinePhone.\nSchematics Hardware schematic v1.2 (2020-03-10, for the UBports Community Edition) Changes from v1.1 The v1.2 mainboard revision changes the routing of several GPIOs to fix bugs and to improve power management. Therefore, it needs an updated device tree. The state of PL6 at boot can be used to distinguish between v1.1 (it can be pulled high) and v1.2 (it will remain low).\nThe WiFi module’s CHIP_EN input (connected to the privacy switch) is now pulled down, so the WiFi will turn off reliably when the switch is off. PL2 is now connected to the WiFi module’s reset pin, allowing the WiFi to be turned off or reset in software. The magnetometer’s DRDY pin is now connected to PB1, allowing interrupt-driven periodic sensor readings. LINEOUTP is again connected to the speaker amplifier’s INP input (like in v1.0), increasing the SNR of the rear speaker. PH7 is now connected to the modem’s AP_READY input (instead of WAKEUP_IN), allowing the modem to buffer URCs (interrupts) while the phone is asleep. The modem’s RI output and DTR input had their GPIOs swapped between PL6 and PB2, so the RI signal can be detected without powering the main pin controller. Both PL9 and VBUS_CTRL (from the ANX7688) are now connected to N_VBUSEN on the PMIC. This causes the PMIC to automatically stop drawing power from the USB port when supplying power to a USB-OTG peripheral. It also allows the ANX7688 to automatically control the direction of current flowing through the USB port. As part of the previous change, the ANX7688’s reset input was moved to PD6; this pin previously controlled the USB OTG power. Some of the regulators supplying the ANX7688 were rearranged, to reduce power consumption when the USB port is not connected and not being used to transmit video. As part of the previous change, PD11 now controls the ANX7688’s 1v0 digital power domain. The modem’s STATUS output is now connected to PH9, allowing the modem on/off state to be visible in software (note: this only works while the modem is powered). Since it is no longer connected to PB3, reading STATUS no longer turns the modem on. The modem no longer has access to the I2C bus containing the sensors. HBIAS is now connected to the headphone jack. Known issues Backlight Backlight LED current regulation depends on gpio0-ldo voltage stability due to feedback voltage from current sensing resistor being modified via SoC’s PWM pin and pullup resistor to gpio0-ldo. gpio0-ldo also powers the CTP controller and light/proximity sensor, among other things. When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily. It’s not a very good idea to tie boost converter’s current regulating feedback circuit to the potential source of noise, especially since the noise will have much larger effect when the backlight LED current is low. It’s possible this can be mitigated if C1110 can be raised to 22-47uF range, or by changing the resistor values in the feedback circuit.\nPWM duty cycle for the lowest brightness of the backlight is also not very predictable, varying from 7-20% (tested with a small sample size of 2 devices). Therefore it’s not possible to come up with a single device tree brightness settings that will work for everyone, requiring per-device calibration.\nOn PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE pin of the regulator, and lowest brightness setting seems more stable. On the other hand, the lowest achievable brightness was brighter than on 1.1+.\nAdditionally there is also another backlight issue, where the brightness is lower when connecting a VBUS powered device, https://xnux.eu/log/#022. See PinePhone 1.2b R1318 backlight hardware fix.\nUSB The USB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off. This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There’s no SW workaround for automatic detection of cable plug or power role.\nThe issue was was fixed with revision 1.2a. See PinePhone 1.2 VCONN hardware fix for details and an instruction about how to do the hardware fix.\nIn SW this can only be worked around by manual selection of PinePhone’s data and power role by the user.\nHardware workaround is to desolder U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles (see https://xnux.eu/devices/pp-usbc-fix.jpg).\nHardware fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn’t have the \u0026ldquo;quick discharge function\u0026rdquo; that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. User mozzwald used NCP334FCT2G as a replacement.\nPinePhone v1.2a The PinePhone v1.2a is a hardware revision of the PinePhone that started shipping in Q3 2020.\nThis page contains information and resources which are specific to the v1.2a revision of the PinePhone. For other revisions or for resources related to all PinePhone revisions, see PinePhone.\nSchematics Hardware schematic v1.2a (2020-06-08, for the postmarketOS Community Edition) Changes from v1.2 A thermal pad was added to the SoC alongside a graphene foil covering the metal shielding of the mainboard which is in direct contact with the LCD backplane to help dissipate heat. Another graphene foil sticker was added to the rear cover of the device to help disperse thermals from the back of the modem. Fixed a rectangular dead spot of the touchscreen under the speaker grill Antenna changes USB-C CC fix for video out and OTG functionality Known issues The backlight issue of v1.2 is still present, see PinePhone v1.2. There is also another backlight issue, where the brightness is lower when connecting a VBUS powered device, https://xnux.eu/log/#022. See PinePhone 1.2b R1318 backlight hardware fix.\nPinePhone v1.2b The PinePhone v1.2b is a hardware revision of the PinePhone that started shipping in Q4 2020.\nThis page contains information and resources which are specific to the v1.2b revision of the PinePhone. For other revisions or for resources related to all PinePhone revisions, see PinePhone.\nSchematics Hardware schematic v1.2b (for the Manjaro Community Edition) Changes from v1.2a A bug was fixed, where connecting a VBUS powered device lowered the screen brightness (resistor R1318 changed to NC). Changes with the Beta Edition Due to the global pandemic early 2021 and the component shortage as a result, the magnetometer in the Beta Edition had to be replaced from an LIS3MDL to an AF8133J. Known issues HDMI hotplug detection is not reliable due to a HW bug in level shifting circuitry for the hot plug detect (HPD) signal between HDMI bridge and A64 SoC, see megi’s blog post. It is not known if three issues of previous revisions are still present and if yes to which degree, or if they have been fixed by removing resistor R1318, see PinePhone v1.2 for some details. Please edit this page once this has been confirmed. Mind that there is currently a likely software-related bug present, which also causes the screen to flicker. The bug usually happens after abruptly shutting down the phone previously (for example by forcing it off), in contrast to powering it off. Project Anakin The Project \u0026ldquo;Anakin\u0026rdquo; - Phase 1 of PINE64 Smartphone \u0026ldquo;PinePhone\u0026rdquo; Development Kit Project Anakin is a marsh-up kit for the PINE64 Smartphone dubbed \u0026ldquo;PinePhone\u0026rdquo;. It is used in the early stages of development as a starting point for affiliated projects.\nPinePhone development has been broken down into three distinct phases:\nFirst phase - Project Anakin Second phase - purpose-built development kit code named \u0026ldquo;Don’t be evil\u0026rdquo;. It will be introduced at FOSDEM 2019 Lastly, the third phase which is the PinePhone itself - scheduled to be released in Q3 2019 (pending on software development). The Anakin kit consists of following components:\nSoPine Module SoPine Model A baseboard Pine A64 Wifi/BT module 16GB eMMC module 5 Mega Piixel CMOS Camera Sensor 7\u0026quot; Touch Screen LCD Panel Playbox Enclosure Lithium Ion Battery case (note: battery not included, can accommodate 1-3 pieces of 18650 size Lithium Ion batter. In general, one is good enough) Quectel EC20 R2.1 LTE Module (note: The SIM tray design not distinguish polarity well and all reverse slot in) Accessories Step-by-Step Guides Under \u0026lsquo;Guides for PINE A64(+) accessories\u0026rsquo; you can find instructions and guides concerning:\nPlaybox Enclosure Bluetooth and WiFi module 7\u0026quot; Touch Screen LCD Panel SoC and Memory Specification Based on Allwinner A64/R18 R18 and A64 are identical SoC but R18 committed for 10 years supply by vendor. CPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard System Memory RAM Memory Variants: 2GB LPDDR3. Storage Memory: SPI Flash and optional eMMC module from 16GB up to 64GB Project Anakin, SOPine Module and Baseboard Information, Schematics, and Certifications Model \u0026ldquo;A\u0026rdquo; Baseoard Dimensions: 133mm x 80mm x 19mm Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, 3.5OD/1.35ID Barrel DC Jack connector, Euler connector PINE A64 Connector Layout @courtesy of norm24 PINE A64 Connector List SOPine Module Pin Assignment ver 1.0 PINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016) Good documentation about PINE A64, A64+, and A64-LTS GPIO pins article SOPine Module Schematic:\nSOPine Module Schematic SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic and PCB Board Resource:\nSOPine model \u0026ldquo;A\u0026rdquo; Baseboard is an hardware open source project but is not \u0026ldquo;OSH\u0026rdquo; compliant SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic capture Rev B DSN source file SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic Rev B PDF file SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Job source file SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Gerber file SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Layout PDF file SOPine (together with model \u0026ldquo;A\u0026rdquo; baseboard) Certification:\nSOPine with model \u0026ldquo;A\u0026rdquo; baseboard FCC Certificate SOPine with model \u0026ldquo;A\u0026rdquo; baseboard CE Certificate SOPine with model \u0026ldquo;A\u0026rdquo; baseboard RoHS Certificate Datasheets for Components and Peripherals Allwinner A64/R18 SoC information:\nR18 and A64 are identical SoC but R18 committed for 10 years supply by vendor. Allwinner A64 SoC Brief Introduction Allwinner R18 SoC Brief Introduction Allwinner A64/R18 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64/R18 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC Datasheet LPDDR3 information:\nAllwinner LPDDR3 Datasheet Foresee LPDDR3 Datasheet Samsung LPDDR3 Datasheet Hynix LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG SanDisk eMMC Datasheet Hynix eMMC Datasheet Foresee eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Project Anakin module/component related information 5MPixel Rear CMOS Camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) S5K4EC 5MP CMOS Image Sensor SoC Module Datasheet S5K4EC 5MP CMOS Image Sensor SoC Chip Datasheet S5K4EC 5MP CMOS Image Sensor Driver Source Code in C language LCD Touch Screen Panel information:\n7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64+ Board Realtek RTL8201 10/100M Ethernet Transceiver for PINE A64 Board Wifi/BT module information:\nRealtek RTL8723BS WiFi with BT SDIO Enclosure information:\nPlaybox Enclosure 3D file Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port right\nLTE module information:\nNote: The current Project Anakin kit deploy on using Quectel EC20_R2.1 which belongs to EC25 family. Actual production will use EC25 and EG25-G (still preliminary) module pending on region. Quectel EC20 R2.1 LTE Module Specification Quectel EC25 LTE Module Specification Quectel EG25-G LTE Module Specification Quectel EC25 LTE Module AT Cammands Set Manual Quectel EC25 LTE Module Hardware Design Guide Quectel EC25 LTE Module Reference Design Guide Other Resources Linux Sunxi Wiki page on PINE A64 Linux Image created by Andre Przywara PINE64 Linux build scripts, tools and instructions by Longsleep PINE64 Linux image by Longsleep Shrinking images on Linux by FrozenCow Quectel EC-25 LTE module open source information Project Don’t be evil The Project Don’t be evil is the phase two of PINE64’s smartphone, the PinePhone Development Kit. Project Don’t be evil is an actual smartphone developer kit for the PINE64 Smartphone dubbed \u0026ldquo;PinePhone\u0026rdquo;. It is used in the early stages of development as a starting point for affiliated projects.\nThe PinePhone development has been broken down into three distinct phases:\nFirst phase - Project Anakin Second phase - purpose-built development kit code named \u0026ldquo;Don’t be evil\u0026rdquo; and introduced at FOSDEM 2019 Lastly, the third phase which is the PinePhone itself - scheduled to be prototype released in Q3 2019 and BTO batch released with mobile OS parents in Q4 2019 (pending on software development). Baseboard and SOPine Module Information, and Schematics Baseboard Dimensions: 165mm x 76mm x 19.5mm Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, USB type-C connector Baseboard Schematic:\n\u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Structure \u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Ver 1.1 Schematic \u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Ver 1.1 PCB Artwork \u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Ver 1.2 Schematic \u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Ver 1.2 PCB Artwork SOPine Module Schematic:\nSOPine Module Schematic SOPine Module Pin Assignment ver 1.0 Wifi/BT module information:\nPINE A64 Wifi/BT Module Schematic Pin assignment:\nPINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016) SoC and Memory Specification Based on the Allwinner A64/R18. The R18 and A64 are identical SoC but R18 committed for 10 years supply by vendor.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard System Memory RAM Memory Variants: 2GB LPDDR3. Storage Memory: SPI Flash and optional eMMC module from 16GB up to 64GB Datasheets for Components and Peripherals Allwinner A64/R18 SoC information:\nNote: the R18 and A64 are identical SoC but the R18 is committed for a 10 years supply by the vendor. Allwinner A64 SoC Brief Introduction Allwinner R18 SoC Brief Introduction Allwinner A64/R18 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64/R18 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC Datasheet LPDDR3 information:\nAllwinner LPDDR3 Datasheet Foresee LPDDR3 Datasheet Samsung LPDDR3 Datasheet Hynix LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG SanDisk eMMC Datasheet Hynix eMMC Datasheet Foresee eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Related datasheets 2MPixel front CMOS Camera module information:\n2MP CMOS Image Sensor Module Drawing GalaxyCore GC2035 2MP CMOS Image Sensor Product Brief GalaxyCore GC2035 2MP CMOS Image Sensor Datasheet 5MPixel Rear CMOS Camera module information:\n5MP CMOS Image Sensor Module Drawing OmniVision OV5640 5MP CMOS Image Sensor Datasheet OmniVision OV5640 5MP CMOS Image Sensor Software Application Note LCD Touch Screen Panel information:\n5.7\u0026quot; 1440x720 IPS LCD Panel Specification fiti JD9365D LCD Controller Datasheet 5.7\u0026quot; Front Panel Touch Screen Specification FocalTech FT6336GU Front Panel Touch Screen Specification Lithium Battery information:\nPanasonic NCR18650B 3350mAH Lithium Ion Battery Specification Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver Wifi/BT module information:\nRealtek RTL8723BS WiFi with BT SDIO LTE module information:\nQuectel EC25 LTE Module Specification Quectel EG25-G LTE Module Specification Quectel EC25 LTE Module AT Cammands Set Manual Quectel EC25 LTE Module Hardware Design Guide Quectel EC25 LTE Module Reference Design Guide Sensors:\nST LIS3MDL 3-axis Magnetomater Datasheet InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS Datasheet SensorTek STK3335 Ambient Light Sensor and Proximity Sensor Software releases A64 mainline status matrix chart Some these OS images labelled as beta or nightly builds which means they are only fit for testing purposes. These images should be used at your own risk and are not fit for normal use.\nArch Linux XFCE longsleep BSP Linux ayufan Linux postmarketOS Download:\nDirect download from postmarketOS image site Instructions:\npostmarketOS PinePhone \u0026ldquo;Don’t Be Evil\u0026rdquo; dev kit wiki site Notes:\npostmarketOS early alpha test build for microSD boot for 8GB microSD cards and above Suitable for PinePhone \u0026ldquo;Don’t Be Evil\u0026rdquo; Dev Kit version 1.1 and version 1.2 There are two type of LCD panels. For long touch screen cable, please use the build with inverted wording. Sailfish OS The Sailfish OS image is build on Gitlab CI, the latest image can be installed using our flashing script written in Bash.\nThe script downloads the image and bootloader from our CI, extracts everything and burns it onto the SD card.\nInstructions:\nDownload the flashing script Insert a microSD card in your device Make the script executable: chmod +x flash-it.sh Execute it: ./flash-it.sh Follow the instructions. Some commands in the script require root permissions (for example: mounting and flashing the SD card). Notes:\nThe script will format and flash the SD card, make sure that you don’t have any important data on the SD card! Maemo Leste Download:\nMaemo Leste test builds download Notes:\nWorks on dev kit versions 1.1 and 1.2 Write the image to a micro SD (8GB+) or eMMC LuneOS Download:\nLuneOS test image for PinePhone and thanks to Tofe Notes:\nIt is recommended to use bmaptool for example bmaptool copy https://build.webos-ports.org/luneos-testing/images/pinephone/luneos-dev-image-pinephone-testing-0-15.rootfs.wic.gz /dev/mmcblk0 Mali Driver For the Mali driver see Mali Driver.\nErrata for ver1.1 and ver1.2 board Please DON’T insert micro SIM card to dev kit board micro SIM card slot, the SIM data, VPP, and GND signal have been misplaced. A miciPCIe adapter with sim card holder 9shown as below photo) will be provide to developers to correct this mistake. The PinePhone dev kit doesn’t charge due to VBUS on SOPine module is not connected. Please connect R9688 solder pads with 0 ohm resistor or using thin wire bridge up the solder pads. Location shows as below: The SOPINE’s SPI NOR flash storage and the devkit’s camera flash (heh) share the same GPIO pins. The flash storage may not be used. On the camera flash GPIO conflict, the new assignment of GPIO PB3 pin for SGM3140 FLASH_EN and GPIP PD7 for FLASH_TRIGOUT. Please note that PD7 is also LCD_ID pin which may not be used. Images:\nGPIO_PB3_location\nFlash GPIOs Reassigned wiring\nOther Resources Linux Sunxi Wiki page on PINE A64 Linux Image created by Andre Przywara PINE64 Linux build scripts, tools and instructions by Longsleep PINE64 Linux image by Longsleep Shrinking images on Linux by FrozenCow Quectel EC-25 LTE module open source information Accessory Add-ons The PinePhone (and PinePhone Pro) is compatible with the official add-on cases, such as the keyboard, the LoRa add-on, the Qi wireless charging add-on and the fingerprint reader add-on. Details can be found under:\nAccessories Keyboard USB The USB-C can be used to power the device, and offers USB2 host and OTG capabilities, and also can make use of the USB-C capability to integrate HDMI signals. Some USB-C hubs are available that offer power throughput, USB connection, an HDMI port and Ethernet connection.\nPogo pins The pogo pins, as visible under the back cover.\nThe PinePhone has six pogo pins on the back allowing for custom hardware extensions such as wireless charging, an IR blaster, a keyboard extension or extended battery case. The pogo pins provide access to an interrupt line, power inputs/outputs and an I2C interface.\nInterrupt SDA SCL DCIN USB-5V GND DCIN and USB-5V are the names used in the schematics. The actual behavior of these pogo pins is not obvious based on their names. DCIN is connected both to the VBUS line of the USB Type-C connector and to the ACIN/VBUS inputs on the PMIC. This means that, depending on a number of factors, DCIN may be at 0 V or 5 V. USB-5V is connected at the output of an LP6226 DC/DC boost converter (5 V), which in turn is fed by the PS output of the PMIC. The boost converter is enabled or disabled by a GPIO output from the A64 SoC, controlled by software (e.g. the Linux kernel). Depending on inputs and decision made by the PMIC, PS may be at the battery voltage (fed \u0026ldquo;directly\u0026rdquo; by the battery through a transistor controlled by the PMIC), or at the \u0026ldquo;USB\u0026rdquo; voltage (fed by the PMIC’s ACIN/VBUS inputs). This means that depending on a number of factors, USB-5V may be at battery voltage (between 3.0 V and 4.3 V), or at 5 V.\nBecause the PinePhone may act as a USB host (providing 5 V at the USB Type-C connector’s VBUS to a connected device) or as a USB device (drawing from a 5 V source on the USB Type-C connector’s VBUS), DCIN is actually not strictly an input nor an output. Some community analysis of the PinePhone schematic (and some testing) indicates that you can connect a 5 V power supply to DCIN in order to power the phone at the PMIC’s ACIN/VBUS inputs (and, as a side effect, charge the battery). This may not be safe to do in all conditions, e.g., when the phone is acting as a USB host to a connected USB device. It should also be safe to use DCIN as a power output from the PinePhone, e.g., when a USB Type-C charger is connected, you can draw current directly from the USB Type-C port’s VBUS, which is provided by the charger. Please note that, when using DCIN as an output from the PinePhone, DCIN isn’t \u0026ldquo;always on\u0026rdquo;; it may be 0 V. It is currently not documented on how much current can be safely drawn.\nUSB-5V should be safe to use as an \u0026ldquo;always on\u0026rdquo; power output from the PinePhone. Depending on a number of factors, voltage may be from 3 V to 5 V; thus, if you are using USB-5V to power your pogo-pins expansion board, you will probably need to use DC/DC converters/regulators as appropriate. USB-5V is on even while the A64 SoC is powered down.\nThe I2C and interrupt lines have pull-ups on the phone side. The I2C lines are pulled up to 3v3 by the phone.\nFor a breakout board see here. For an example project see Martijn’s blog post \u0026ldquo;Making a backcover extension for the PinePhone\u0026rdquo;.\nPINE64 store currently sells the PinePhone Flex Breakout Board. With the pitch being 2.54 mm, this Flex Breakout Board may have leads soldered directly to the contacts for use in a solderless board. A non-soldered solution would be to use a TE AMP Connector that will accept a Flat Flexible Cable 2.54 mm pitch.\nBack cover A step file for the back cover for creating custom cases is freely available here.\nSerial console Pinout of the serial adapter.\nThe PinePhone has a serial port in the headphone connector, it’s activated by the 6th contact on the dipswitch. If the switch is set to \u0026ldquo;on\u0026rdquo;, the headphone connector is in audio mode, if it is set to \u0026ldquo;off\u0026rdquo; it’s in UART mode. The UART serial connection can also be used for communication with other devices from the PinePhone.\nThe UART is 115200n8.\nThe pinout for the serial connector is:\nTip: RX Ring: TX Sleeve: GND You can buy a serial debug cable from the PINE64 Store. The store cable uses a 4 ring plug, as seen in the here, but a 3 ring plug works just as well. The cable uses a CH340 chipset based serial to USB converter, but any 3.3v serial connection can be used. Because it is a \u0026ldquo;host\u0026rdquo;/DTE it means that you need a cross modem cable (Null Modem) with TX on Tip to be connected to RX. A cable like e.g. FTDI TTL-232R-3V3-AJ which has TX on Tip and RX on Ring fits perfectly.\nBattery The phone ships with a protective plastic sticker between the battery and the phone to protect the device from turning on during shipping. You need to gently open the back cover, then remove the battery and finally remove the sticker and check that the pins aren’t bent. Note: If the battery is stuck inside the phone, the mid screw in the lower part of the midframe needs to be slightly loosened, see here.\nNote The EG25-G modem and the RTL8723CS WiFi and Bluetooth do not work without a battery and with a drained battery, even when enough power is supplied to the PinePhone via the USB Type-C port. Most operating systems won’t boot without a battery or with a drained battery. The supplied battery is meant to be compatible with Samsung part number EB-BJ700BBC / BBE / CBE from the 2015 J7 phone. The extended life aftermarket BBU does fit, although it is a tight fit.\nWarning Using an aftermarket battery with a higher capacity is done at own risk. Batteries with a higher capacity especially in combination with an external charger can lead to overvoltage, which fries the modem and/or the Bluetooth and WiFi chip. The battery terminals, from the nearest to the battery edge to the nearest to the middle of battery, are as follows:\n+ve thermistor -ve not connected The battery includes a protection circuit that isolates it in a number of fault conditions, including if it is discharged too far. The fully discharged battery can be recharged by connecting the phone to a charger with a sufficient output. Once it has charged sufficiently you will be able to boot the phone.\nCamera The PinePhone has two cameras, OmniVision OV5640 with 5MP (up to 2592 x 1944 pixels) as rear camera and GalaxyCore GC2145 with 2MP (up to 1600 x 1200 pixels) as front camera.\nExample picture taken on the PinePhone’s rear camera by Martijn Braam using his app Megapixels.\nFurther details regarding the camera and the Megapixels camera app can be found on Martijn’s blog.\nFAQ A list of frequently asked question.\nHardware Revisions What are Community Editions? Community Editions of the PinePhone were versions of the PinePhone which came preinstalled with the operating system of a partner project and featured the logo of the project on the back panel. The Community Edition was intended to help partner projects developing these systems: \u0026ldquo;Community editions are meant to bring exposure to partner-projects operating systems and communities, as well as help finance ongoing development.\u0026rdquo;, source.\nIs the Community Edition hardware the latest revision? The Community Edition program (featuring the mainboard numbers 1.2 through 1.2b and branded back covers) which provided the branded PinePhones has since ended, and a Beta Edition has since been released. The only difference between each Community Edition is the inclusion of crucial bug fixes, with the last issue being fixed with the 1.2b motherboard shipping with the Manjaro CE PinePhones. The 1.2b motherboard is also currently used in the Beta Edition PinePhones, however the Beta Edition units do not ship with any back cover branding. There are currently no plans for further hardware revisions.\nAside from the back cover, the only other difference between each Community Edition is that starting with the postmarketOS PinePhone, a convergence package option was released that adds another gigabyte of ram to the phone and a 32GB eMMC instead of a 16GB eMMC. Convergence packages also included a dock for plugging in USB peripherals and connecting to an HDMI monitor, however you can purchase a generic USB-C dock to use with a 2GB PinePhone.\nThe predecessor to the Convergence Edition PinePhones was the Braveheart Edition intended for developers to bring up the platform, which had the version number 1.1. For more details about the topic see PinePhone.\nWill there be other Community Editions? Five Community Editions have been announced: UBports, postmarketOS, Manjaro, KDE, and Mobian. Since the release of the Mobian edition, the Beta Edition PinePhones have been released and the Community Edition Program has ended.\nIn simple terms, what are the differences between Braveheart and the new Community Edition? The Braveheart PinePhone was the first public revision of the PinePhone which was intended solely for developers and Linux enthusiasts. The UBports Community Edition was the next revision of the PinePhone with an updated mainboard based on feedback from the Braveheart Edition, see PinePhone. All current revisions of the PinePhone continue to be intended for developers and enthusiasts, however, PINE64 will be starting to offer partnered retail units of the PinePhone which will have a better warranty and technical support (keep in mind even then it is not intended for a broader audience at this time, as the software still needs work and the hardware does not hold up well to modern consumer standards).\nWill there be a newer revision after the Community Editions? Starting with the UBports Community Edition the PinePhone has gotten CE and FCC certifications, repeating the certification process due to changes in the hardware design is very expensive, so the 1.2b motherboard is viewed as the final revision. The PinePhone (and parts for them) will be produced and sold for at least 5 years.\nWill there be hardware differences between the Community Editions? Besides the varied back covers, starting with the launch of the PostmarketOS CE there has been the release of a convergence package option for the PinePhone which includes more ram and storage, and an included dock for convenience. There has also been minor hardware changes with the UBports CE (mainboard 1.2) and the Manjaro CE (mainboard revision 1.2b).\nGeneral How powerful is the PinePhone\u0026rsquo;s hardware? The PinePhone is about on par with a Raspberry Pi 3 in terms of CPU performance, however it’s Mali 400 MP2 is much weaker than the Pi 3’s VideoCore IV. The Mali 400 was the first mobile OpenGL ES 2.0 GPU on the market back in 2008 when it was released, compared to the much newer Videocore IV released in 2010. The PinePhone has been shown to handle smooth H.264 1440p30 video playback using Cedrus and gstreamer as documented here. The device should be more than capable of a smooth phone experience when used in conjunction with well optimized software that makes use of its hardware features. It is also capable of running many light games (including 3D ones such as SuperTuxKart), and retro gaming. Expect further speed improvements over time as the drivers are improved, and in the meanwhile you can look into slightly Overclocking the device (at your own risk).\nSound The default ringtone for Mobian Phosh can be found at /usr/share/sounds/freedesktop/stereo/phone-incoming-call.oga\nBluetooth For some reason, using pipewire-pulse with bluetooth headphones (In my case, Sony WH1000X-M3) using the default LDAC codec causes the headphones to constantly connect and disconnect until they eventually give up pairing. A work around I’ve found is to quickly go into Sound settings and switch the codec to \u0026ldquo;SBC\u0026rdquo;.\nModem The modem isn\u0026rsquo;t working In order to use the modem and Wi-Fi/Bluetooth, you need to ensure the battery is inside the device and has a sufficient charge. Even when supplying the phone with enough power, the modem and Wi-Fi chip will not work without a connected battery. Further, double check that you have not put the SD card into the sim card slot, or vice versa.\nDoes the PinePhone only wake up from sleep for calls and texts? Yes. Unless the PinePhone is configured to wake up every few minutes from deep sleep in Crust (At the cost of battery life. However, in the future there may be other solutions), then there is not any way to get any notifications for applications. The modem on the PinePhone will wake the device for incoming calls and texts however, and the real-time clock is also capable of waking the device for alarms.\nBattery The battery is stuck inside the phone The battery can be stuck in the phone if the screws of the frame are overtightened.\nFirst, try loosening the screws to the left and right of the battery compartment and remove the battery, it should go much easier now. These screws may be the culprit as they seem to make the sides of the midframe grip the battery. Do not tighten them fully and the problem should go away.\nIf your battery is still stuck inside the PinePhone, completely unscrew all the screws of the midframe. Then pull out the battery (you may have to fully take off the midframe in some cases to get it out). And then rescrew the midframe, but only tighten the screws to the point where they are just barely tight to hold. This should allow you to remove the battery easily.\nThe battery is discharging while the phone is powered off (Braveheart Edition) The issue is not present on the Community Edition. Due to a hardware bug, after power off, the phone still consumes 20–30mA which drains the battery in 3-4 days. A manual procedure to fix the hardware bug is described here.\nThe battery only charges to ~84% Some pre-made operating systems using megi’s kernel limit the maximum amount of charge to roughly ~84% in the hope of prolonging the battery life, as repeatedly reaching the upper level of battery charge reduces the battery’s lifetime (this is not a safety feature!). The same effect however also applies when repeatedly draining the battery to a low level - users are therefore advised to consider if that setting is reasonable depending on their usage. The setting can be overwritten via Sysfs, to let the battery fully charge (this can lower the replaceable battery’s lifetime considerably depending on the charging behavior!):\nWarning The following instructions are directed towards expert-level users and developers! echo 4350000 \u0026gt; /sys/class/power_supply/axp20x-battery/voltage_max_design\nPrivacy Switches What are the privacy switches doing? Number Name Explanation Description 1 Modem Pulls Q1501 gate up (FET disabling modem power) \u0026ldquo;On\u0026rdquo; enables cellular communication and GNSS hardware, \u0026ldquo;off\u0026rdquo; disables it. 2 Wi-Fi / Bluetooth Pulls up CHIP_EN \u0026ldquo;On\u0026rdquo; enables Wi-Fi and Bluetooth communication hardware, \u0026ldquo;off\u0026rdquo; disables it. 3 Microphone Breaks microphone bias voltage from the SoC \u0026ldquo;On\u0026rdquo; enables audio input from on-board microphones (not 3.5mm jack), \u0026ldquo;off\u0026rdquo; disables it. 4 Rear camera Pulls up PWDN on OV5640 \u0026ldquo;On\u0026rdquo; enables the rear camera, \u0026ldquo;off\u0026rdquo; disables it. 5 Front camera Pulls up PWDN on GC2145 \u0026ldquo;On\u0026rdquo; enables the front camera, \u0026ldquo;off\u0026rdquo; disables it. 6 Headphone Pulls up IN2 on analog switch BCT4717ETB \u0026ldquo;On\u0026rdquo; enables audio input and output via the 3.5mm audio jack, \u0026ldquo;off\u0026rdquo; switches the jack to hardware UART mode. Memory What\u0026rsquo;s the speed difference between the eMMC and SD cards? Maximum transfer speed of the eMMC is around 85 MB/s, while SD cards are limited to approximately 23 MB/s (even with faster cards).\nGPS GPS doesn\u0026rsquo;t work Like almost all smartphones, the PinePhone GPS antenna is small and can only get a first fix unassisted if the GPS signal is very strong. To make first fix faster and more reliable, phones download assistance data either from the phone network or from the internet. The GPS in the PinePhone modem supports the internet based assistance method, as detailed in the modem documentation, but this is currently only supported by a few distributions, and a proof of concept script that shows it can work.\nUntil aGPS support becomes standard you’ll have to make some manual changes - see for example Mobian wiki\nGPS can\u0026rsquo;t determine direction Currently, due to the magnetometer not being hooked up in software at this time, it is not possible for GPS software to use the phone’s compass functionality. This means while you are walking it will not be possible to determine the direction of travel. This is not as much of an issue for vehicles as the faster speeds mean that it is possible to estimate the direction of travel, however it will still be an issue should the vehicle travel through a tunnel and lose GPS signal.\nSoftware Installation How can I install an operating system on the SD card / eMMC? See Installation instructions.\nBooting What\u0026rsquo;s the boot order for SD cards and eMMC? The PinePhone will automatically boot from microSD if a bootable card is inserted. If no (bootable) microSD is found, it will boot from eMMC.\nHow can I select different operating systems at boot? There was a project by Danct12 which allowed the user to select different operating systems at boot, but the repository has since been archived: https://github.com/dreemurrs-embedded/Pineloader.\nI turned on my Manjaro CE PinePhone. The red LED and screen backlight are briefly lit, then both are not and it will not boot. This can be the result of at least one situation:\nThe eMMC installation became corrupt or otherwise unbootable An SD card is present but not bootable (consider PinePhone Troubleshooting) If there is an installation of Manjaro on both the eMMC \u0026amp; an SD card, the SD card will always boot first on the device. Try taking the SD card out and booting the installation that is on the eMMC. If the problem persists, it is likely there is an issue with both installations and you will need to reinstall your distribution. You may also want to check with your distribution’s maintainers if boot issues are a common problem in a recent update.\nI did not install an update in Ubuntu Touch and I\u0026rsquo;m stuck on the PINE64 logo after rebooting. Use a USB A-C cable to plug your phone into your PC Hold the PinePhone’s power button for 4 seconds or more to power it off. Wait 5 seconds Hold the Volume Up and Power buttons on the PinePhone to boot into recovery. You should see the LED light red, then yellow, then green. The \u0026ldquo;Installing update\u0026rdquo; screen will appear, but a progress bar to indicate update progress will not. Ignore the \u0026ldquo;Installing update\u0026rdquo; part. Your PC may automatically mount the PinePhone’s partitions. If it does, Safely Remove or Eject all of them. Open a terminal on your PC. Type telnet 172.16.42.1 You should receive the text \u0026lsquo;Welcome to Rescue SD Shell|\u0026rsquo; In the new Rescue SD shell, type umount /dev/mmcblk2p10; e2fsck -fy /dev/mmcblk2p10 \u0026amp;\u0026amp; sync Once this command pipeline finishes, type sync \u0026amp;\u0026amp; reboot -f Your PinePhone should reboot into Ubuntu Touch. Now head to Settings - Updates and install the new update!\nIf these steps did not solve your issue, please create a new thread here on the PINE64 forums, note what the problem looks like, then say that you’ve tried these steps already.\nThis is caused by corruption on the userdata partition. Normally this should be fixed by \u0026rsquo;e2fsck\u0026rsquo; in the initramfs, however, an error in image creation means that that version of e2fsck is unable to correct the corruption. This has been fixed in all new PinePhone updates, so if you update from the factory image to any other image available to the PinePhone now, you will not experience this issue any longer.\nThe PinePhone does not boot Most operating systems on the PinePhone do not boot if the battery is not connected or if it is fully drained. If you received a new PinePhone make sure to remove the battery isolator as explained under PinePhone Getting started.\nIf you removed the battery isolator and the battery contacts are intact, the battery is either fully drained or there is no valid OS (or a corrupted OS or bootloader) installed on the eMMC or the SD card. Make sure to charge the phone with a compatible charger (500 mAh is not enough for modern phones), as well as the installation instruction under Installation instructions. If the OS got corrupted it is highly recommend to simply reflash.\nIf nothing works please don’t hesitate to contact the community, they are eager to help and booting issues are usually very easy to solve (as they are typically either battery or installation related). The phones itself are all tested individually at the factory. Do not contact PINE64’s support for booting issues.\nA protection foil isolates the battery for the shipping.\nThe microSD belongs in the upper slot, the micro SIM in the lower slot.\nCan I install a different OS on my Community Edition? Yes. While all the Community Edition PinePhones come with an OS preinstalled, you are free to use any OS on the integrated storage (the eMMC) or an SD card, see Installation instructions and Operating systems on how to install them.\nOther How can I enable SSH? In Ubuntu Touch you can run \u0026ldquo;sudo start ssh\u0026rdquo; to get a one-time start, or edit /etc/init/ssh.override and remove the manual line to make it auto-start.\nIn other distributions you may have to install SSH through its package manager and then proceed to use its init system to enable it. For Manjaro, Arch, and Mobian you can use \u0026ldquo;systemctl enable sshd\u0026rdquo; and \u0026ldquo;systemctl start sshd\u0026rdquo; command to enable and start the ssh daemon.\nWhat works, what doesn\u0026rsquo;t? For Ubuntu Touch see https://gitlab.com/ubports/community-ports/pinephone#what-works-what-doesnt.\nOther distributions will have different levels of functionality. Please refer to the release page of your chosen distribution for further information.\nI can\u0026rsquo;t connect to a 2.4Ghz Wi-Fi network in Ubuntu Touch. Reboot your device by holding the power button until the \u0026ldquo;Power\u0026rdquo; dialog appears, then pressing \u0026ldquo;Restart\u0026rdquo;.\nIf that does not fix the issue, note that all the following conditions must be met to use Wi-Fi on the PinePhone:\nThe plastic tab between the battery and the device’s battery contacts has been removed The battery is installed The Wi-Fi privacy switch (switch number two) on the rear of the device is switched \u0026ldquo;ON\u0026rdquo; Wi-Fi in the PinePhone only seems stable after a warm reboot like this.\nWhat\u0026rsquo;s the status of Android for the PinePhone? Currently, there isn’t any major push to get Android running well on the PinePhone. The developer Icenowy did get a partially working Android image, but it was slow and buggy, lacking some major functions. As of now, use Anbox as an alternative for your android apps, which is currently not included in Ubuntu Touch. In other distributions your millage may vary on what applications will run and how well.\nWhy are my apps loading slower than on my Android phone? Android has multiple techniques in place to speed up launching applications after the first launch, such as the \u0026ldquo;Dalvik cache\u0026rdquo;.\nUsing an alternative filesystem such as F2FS on the eMMC (which is considerably faster than running software on the SD card) may help improve performance slightly. Over time you can expect further optimizations and improvements in various distributions that will help speed up the PinePhone.\nHow can I turn on the backlight? On some devices the default calibration of the backlight is not sufficient and the minimum setting of the brightness of the used OS can be too low, causing the backlight to completely shut down. In that case it is recommended to connect the phone to a charger and/or to shine a flashlight at the screen to adjust the brightness to a higher setting again.\nOn many Linux distributions the brightness setting is an integer between 0 and 1000 and available at runtime in /sys/class/backlight/backlight/brightness and stored at shutdown and loaded at boot from /var/lib/systemd/backlight/platform-backlight:backlight:backlight by systemd-backlight@backlight:backlight.service. Changing the brightness setting can be done at runtime, for example over SSH, by executing as root echo 500 \u0026gt; /sys/class/backlight/backlight/brightness. The stored brightness setting can be modified using another system, by mounting the root filesystem of the system you want to fix and by executing echo 500 \u0026gt; [MOUNT LOCATION]/var/lib/systemd/backlight/platform-backlight\\:backlight\\:backlight.\nHow can I contribute regarding the WiFi and Bluetooth firmware? The PinePhone uses Realtek RTL8723CS for its Wi-Fi and Bluetooth connectivity. Unfortunately, just like the other Realtek wireless chipsets (see more info) - the RTL8723CS chipset requires proprietary firmware for Wi-Fi and Bluetooth functionality. For those who want to create replacement free software firmware, resources like this and this (different chipsets, but still Realtek) could be a great starting point for further research.\nSMS The phone does not receive SMS Sometimes incoming SMS messages are not being received, but outgoing ones, phone calls and data are working fine. One cause of this is if ModemManager fails to receive messages from the modem and they build up. These messages are not cleared by either rebooting reflashing the phone.\nNew versions of the (mostly) foss community firmware implement a workaround that helps ModemManager receive stuck messages.\nMost UIs (at least phosh, plasma, and sxmo) use ModemManager to communicate with the modem including for phone calls, cellular data, GPS and SMS.\nYou can check for stuck sms messages using the mmcli command:\n$ mmcli -m any --messaging-list-sms Found 10 SMS messages: /org/freedesktop/ModemManager1/SMS/0 (received)\nAny messages that are listed have gotten stuck, they can be deleted like this:\n$ mmcli -m any --messaging-delete-sms=77 (Repeat with all listed messages)\nFor more information on the messaging related actions available in mmcli you can check the help with mmcli --help-messaging. This article is also helpful in learning: https://electronproton.com/mmcli-command-examples/.\nShipping I did not receive an order confirmation Check your \u0026ldquo;spam\u0026rdquo; folder. It was reported that some users did not receive an order confirmation. You will also still get a shipping notification when the device ships out, even if you didn’t get an order confirmation email.\nWhen does the phone ship? For up-to-date information when the phone’s shipping date is estimated, see the edits in the corresponding forum thread.\nIt is shipping day but I did not receive a shipping notification For shipments with DHL the shipping notification is sent out as soon as the packet reached DHL’s warehouse and scanned (it can take up to 24 hours after scanning after the shipment is added to DHL’s database). For all other shipments (via Ascendia) the notification is sent out sometime after shipment.\nWhen does my phone ship if I order now? Orders made after Friday, 22nd May 2020 are shipped after the first bulk of pre-orders has been shipped. The exact date is not known yet due to various reasons, it may be a few weeks after the first bulk shipped. The forum will be edited with updated information and you will receive a shipping notification when the device was shipped.\nWhat about import taxes? Import taxes have to be paid by the buyer depending on the jurisdiction of the country of the buyer. Please check with your local laws if there are import taxes to pay and if so how to do the tax filing.\nAccessories Protection Which screen protector should I use? Protecting your screen is important, especially for devices like the PinePhone that doesn’t have access to the newest glass technology. The Braveheart and Community Editions of the PinePhone comes with a plastic film screen protector installed, and PINE64 sells a tempered glass screen protector in their store.\nYou can also buy a third-party screen protector, as the screen protectors for the iPhone 11 Pro Max/XS Max fit the PinePhone pretty well based on this forum post.\nBatteries I want a replacement battery, which one should I buy? Replacement batteries for US customers are available in the store.\nCurrently the PinePhone battery is known to be compatible with replacement batteries for the Samsung J700. Specifically, models \u0026ldquo;EB-BJ700BBC\u0026rdquo; and \u0026ldquo;EB-BJ700BBE\u0026rdquo; are compatible with all PinePhone models, and \u0026ldquo;EB-BJ700CBE\u0026rdquo; is compatible with Community Editions after UBPorts (due to plastic tabs on its bottom which only the newer phones have tolerance for).\nExternal hardware Will PINE64 sell other add-ons made for the PinePhone? Yes, currently there is a keyboard case with similarities to the Psion 5 which includes an internal battery, and a Qi wireless charging add-on planned, both of which PINE64 intends to directly sell. There is the potential for future add-ons such as a game pad, however that is currently just an idea and not in any way planned.\nFurther information Accessibility\nComponents\nDatasheets\nPress\nResources\nSafety\nSchematics and certifications\nSensors and navigation\nSpecifications\nAccessibility Although most accessibility support for the PinePhone and PinePhone Pro is implemented in software, the underlying hardware is still relevant. This page discusses some issues and options.\nInput Braille Various portable devices, such as Apple’s iPhone, support braille input. This uses multi-touch capability on the device’s capacitative touch screen. The gating factors for this input mode are the dimensions of the screen and the number of contact points that can be distinguished.\nThe PinePhone screen has 1440 × 720 pixel resolution and measures 5.95\u0026quot; diagonally. Assuming that the pixels are square, the screen dimensions should be about 2.68\u0026quot; by 5.37\u0026quot;. This should provide plenty of room for four fingertips on each of the long sides. Indeed, there is a bit of space left over for control functions, etc.\nKeyboard The PinePhone can support either Bluetooth or USB keyboards. So, a device such as the Jelly Comb Foldable Bluetooth Keyboard B003 might be a reasonable input device.\nSpeech The PinePhone should be able to accept speech input using either Bluetooth or its built-in microphone. According to this page, Mozilla’s DeepSpeech ASR (automatic speech recognition) engine works pretty well on a Raspberry Pi 4, using only a single core. Assuming that the PinePhone’s more limited (2 or 3 GB) RAM isn’t a constraint, the phone should be able to produce similar results.\nOutput Speech The PinePhone’s processor should have plenty of capacity to generate clear speech. This can be output using either the 3.5 mm audio jack or a Bluetooth connection.\nSee also postmarketOS wiki: Accessibility Components Component Model Touchscreen Goodix GT917S Rear camera OmniVision OV5640 Camera flash SGMICRO SGM3140 Front camera GalaxyCore GC2145 LCD Xingbangda XBD599 WiFi Realtek RTL8723CS Bluetooth Realtek RTL8723CS Modem Quectel EG25-G GNSS/GPS Quectel EG25-G Magnetometer ST LIS3MDL Ambient light / Proximity SensorTek STK3335 Accelerometer / Gyroscope InvenSense MPU-6050 Vibration motor Unknown model Notification LED LED0603RGB Volume buttons Buttons connected to the KEYADC Power button X-Powers AXP803 Battery fuel gauge X-Powers AXP803 Components list The following list of components are found in the schematic for the PinePhone 1.2b.\nAbreviations used in schematic The following abbreviations are used as the starting letter(s) to identify the components in the PinePhone schematics:\nANT: antenna C: capacitor D: diode DU: Only used in the \u0026ldquo;DU1\u0026rdquo;, which is an integrated circuit for memory ED: Zener diode to protect against electrostatic discharge FB: ferrite bead J: wire link (i.e. a connector) R: resistor L: inductor NC/: not connected (i.e. the part probably isn’t placed on the board, but there are circuits in the PCB for it) Q: transistor SW: switch T: test point U: integrated circuit (i.e. a silicon chip) X: crystal oscillator (used for clocks) P.4 LPDDR3 FPGA178 Note: The title of this schematic page should be changed from \u0026ldquo;LPDDR3 FPGA178\u0026rdquo; to \u0026ldquo;LPDDR3 FBGA178\u0026rdquo;, because the RAM chip is a 178-pin fine pitch ball grid array (FBGA), not a field-programmable gate array (FPGA).\nDU1:\nArtmem ATL3A1632H12A 2GB 800MHz LPDDR3-1600 SDRAM, FBGA-178 11.0x11.5x0.93 mm Note: RAM will be clocked slower, since the Allwinner A64 only supports up to 3GB DDR3-1333 (666.5MHz) and doesn’t specify the top supported LPDDR3 speed. P.5 CPU U1:\nAllwinner A64 1.2Ghz 4x Cortex-A53, 64-bit, superscalar, 32KB instruction \u0026amp; 32KB data L1 cache per core, 512KB L2 shared cache, ARM Mali-400 MP2 (Utgard) GPU, HDMI 1.4 (up to 4K@30), USB 2.0 with OTG, MIPI CSI, 4 channels in/out, 24-bit, 8-48 KHz audio, video encode: H.264 1080p@60, video decode: H.265 4K@30, H.265 1080p@120, H.264, MPEG1/2/4 / VP8 / AVS / AVS+ 1080p@60, FBGA-396 15x15 mm Note: Clocked at 1.152Ghz on the PinePhone. X501:\nAxtal AXX3225 24MHz ±10ppm quartz crystal oscillator in SMD package, 3.2x2.5 mm D500:\nWill Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. X500:\nSeiko Instruments Inc. (SII) SC32S 32.768KHz crystal oscillator Note: Not clear if using the SC32S-12.5PF20PPM or the SC32S-7PF20PPM P.6 POWER ED600:\nWill Semiconductor (WILLSEMI) ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. Note: This part is marked as optional in the schematic and may not be included. U600:\nX-Powers AXP803 power management integrated circuit (PMIC) optimized for multi-core systems, li-ion battery fuel gauge, USB charger (up to 2.8A), QFN 68-pin, 8x8 mm Q600:\nWill Semiconductor WPM1481 single P-channel, -12V, -5.5A, power MOSFET J600:\nBA5924211-R battery connector Note: Picture shows this part as having 8 pins, but the schematic shows 6 pins. One page says that it is made by LateralPressure, but another says it is made by ROHM. L606:\nIND_252010 2.2uH-2A inductor Note: Maybe this is the TDK VLS252010HBU. U601:\nLowPowerSemi LP6226CB6F high efficiency boost DC/DC converter with 33V, 1.5A power MOSFET, SOT23-6 package D600:\nOn semiconductor SS24 Schottky power rectifier, SOD123 package P.7 NAND/eMMC U700:\nKimtigo KM110SS0016GxA-DDD00WT 16GB eMMC 5.1 TLC NAND Flash memory, FBGA-153 11.5×13.0×1.0 mm. Note 1: The schematic says the package is BGA-169, but the Kimtigo documentation says it is FBGA-153. Note 2: The A64 only supports up to eMMC 5.0. Note 3: The schematic lists the part as KM110SS0016GxA-DDD00WT, but these photos show that its variant, the KM111SS0016GxA-DDD00WT, is being used in the 16GB PinePhone. P.8 AUDIO ED800, ED801, ED802, ED803, ED804, ED805, ED806:\nWill Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. U801:\nBroadchip BCT4717ETB-TR 4.0Ω, 300MHz bandwidth, dual bi-directional SPDT (single-pole/double-throw) analog switch J800:\nEAROUTN-A64 receiver J801:\nJA-3606-001AA 3.5mm audio jack Q801:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type U800:\nShanghai awinic technology AW8737SCSR high efficiency (80%), low noise (53μV), ultra-low distortion (0.008%), constant large volume, 7th generation class K audio amplifier, 1.6×1.68 mm CSP-14 package, 0.4mm pitch datasheet FB800, FB801:\n600ohm at 100MHz ferrite bead in a 0402 package (examples) P.9 T-CADD/USB Q901, Q902, Q903:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type ED900, ED901, ED902:\nWill Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. J901:\nSA-2202-112 25-pin Micro-SIM and TF slot P.10 CAMERA J1000:\nT03-1025-FG01 27-pin connector to the rear camera. Note: The schematic says \u0026ldquo;GC2035-200W\u0026rdquo;, which is a mistake because the rear camera is the OmniVision OV6540. J1001:\nT03-1025-FG01 27-pin connector to the front camera. Note: The schematic says \u0026ldquo;GC2035-200W\u0026rdquo;, which is a mistake because the rear camera is the GalaxyCore GC2145, not the GalaxyCore GC2035. U1000:\nShanghai awinic technology AW3641EDNR flash LED driver with programmable timer and PWM dimming torch mode, 1A, 8 current levels. P.11 LCM/CTP Note: \u0026ldquo;LCM/CTP\u0026rdquo; means \u0026ldquo;liquid crystal display monitor/capacitive touch panel\u0026rdquo;. An LCM generally includes an LCD screen + LED backlight + PCB with the LCD controller + frame.\nJ1100:\nFPC24-PT05B, OK-24F-04 28-pin connector to the MIPI-DSI LCD LED2:\nRGB LED J1101:\nCON6-0.5, TP_6PIN-ZQ01 8-pin connector to the capacitive touch panel controller Note: The label says that the connector has 6-pins, but the schematic shows 8-pins. ED1100, ED1101, ED1102, ED1103:\nWill Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. U1100:\nChipown AP3127B025 step-up DC/DC converter series, white LED backlight driver, 6-pin SOT-23-6L package. P.12 SENSORS/MT/KEY J1200:\n8-pin connector to test points ED1200, ED1201: Will Semiconductor ESD5451X 1-line, bi-directional, transient voltage suppressor, EDS protection up to ±30kV and 8A. U1200:\nSTmicroelectronics LIS3MDL ultra-low-power three-axis magnetometer, LGA-12 2.0x2.0x1.0 mm datasheet Note: The LIS3MDL is currently unavailable, so it has been replaced in the PinePhone Beta Edition with the Voltafield AF8133L e-Compass, which is unlisted on the Voltafield web site, but the AF8133J is listed. Presumably U1200 will be unpopulated and U1203 will be populated in the Beta Edition, since they appear to be alternatives. U1201:\nSensorTek https://web.archive.org/web/20190601120915 / STK3311-A proximity and ambient light sensor (large gap) with built-in infrared LED, DFN-8 3.94x2.36x1.35 mm datasheet U1202:\nTDK InvenSense MPU6050 six-axis, low-power MEMS gyroscope and accelerometer, QFN-24 4x4x0.9 mm datasheet U1203:\nAsahi Kasei Microdevices (AKM) AK09911 3-axis electronic compass IC with Hall sensor, 8-pin WL-CSP (BGA), 1.2×1.2×0.5 mm or Voltafield Technology Corp. (VTC) AF8133J 3-axis electronic compass with proprietary anisotropic magneto resistive (AMR) technology, 8-pin WLCSP 1.2x1.2x0.5 mm Note: These parts appear to be alternatives to be used if the LIS3MDL is unavailable, so U1203 was probably unpopulated in BraveHeart and the Community Editions, but will be populated in the Beta Edition. U1204:\nBosch Sensortek BMI120 3-axis gyroscope and accelerometer, LGA-14 2.5x3.0x0.83 mm Note: Listed as \u0026ldquo;NC/BMI120\u0026rdquo;, where \u0026ldquo;NC\u0026rdquo; probably means \u0026ldquo;not connected\u0026rdquo;, so there may be circuits in the PCB for the part, but it is not placed on the board. This is probably an alternative to the TDK InvenSense MPU6050, in case it isn’t available or costs too much. Q1200:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type D1200:\nTorex XBS104S14 Schottky barrier diode, 1A, 40V, SOD-123A package J1201:\n2-pin connector to a motor, 1x1.8 mm Note: Presumably this is a vibration motor. P.13 DIGITAL VIDEO J1300:\nOK-50F-04 40-pin connector Note: This part is probably produced by Shenzhen Yaqi Technology Co., which is part of OCN in Taiwan, and uses the Archie brand name.\u0026lt; U1304:\nAnalogix ANX7688 HDMI to USB-C bridge with MUX, converts HDMI 2.0 to DisplayPort Alternate Mode, USB-C Power Delivery (PD), BGA-64. Note 1: The schematic lists this part as \u0026ldquo;ANX7688S\u0026rdquo;, but it is unclear what the \u0026ldquo;S\u0026rdquo; at the end stands for. Note 2: xnux.eu provides more info on the ANX7688, including flashing the firmware. U1300:\nAmerica Techcode Semiconductor TD6817 1.5MHz 2A synchronous step-down regulator dropout, SOT23-5 package or Diodes Incorporated AP3406K-ADJTRG1 buck switching regulator IC positive adjustable 0.6V 650mA datasheet U1302:\nLowPowerSemi LPW5206H USB power loading switch, N-channel MOSFET, SOT23-5 package U1303:\nTexas Instruments TXB0104YZT 4-bit bidirectional voltage-level translator with automatic direction sensing and ±15-kV ESD protection, 12-pin DSBGA 1.40×1.90 mm Q1300, Q1301, Q1302, Q1304, Q1305:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type U1305, U1309:\nWill Semiconductor WS4621C-1X1 2A, 38 mΩ, 290nA quiescent current and 70nA standby current load switch, CSP-4L 1x1 mm. U1308:\nShanghai awinic technology AW3632 high efficiency, low profile, fixed 5V output pump power supply, QFN-8 package X1300:\nMercury United Electronics X3225 27.000 MHz crystal oscillator P.14 WIFI+BT U1400:\nRealtek RTL8723CS 802.11 b/g/n, single-band (2.4 GHz), Bluetooth 4.0, with SDIO for WiFi and UART for Bluetooth, LGA-40 12x12x1.6 mm. X1400:\n24Mhz ±10ppm crystal oscillator D1400:\nSXSEMI AU0511P1 low capacitance ESD protection diode, SOD-882 ANT1400\nAntenna P.15 MODEM-4G U1500:\nQuectel EG25-G https://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf GSM/UMTS/LTE cellular modem and GNSS (GPS/Galileo/GLONASS/BeiDou/QZSS, with A-GPS), LGA-144 9.0x32.0x2.4 mm U1502, 1503, 1504:\nTexas Instruments TXB0104YZT 4-bit bidirectional voltage-level translator with automatic direction sensing and ±15-kV ESD protection, 12-pin DSBGA 1.40×1.90 mm Q1501, Q1503, Q1504, Q1505:\nToshiba SSM3K35MFV field-effect transistor, silicon N-channel MOS type J1500, J1502:\nMRF004-P01A 4-pin connector Q1500:\nWill Semiconductor WPM1481 single P-channel, -12V, -5.5A, power MOSFET Note: The documentation shows 6 pins, but the schematic shows 8 pins. Component Counts Type of component Main PCB USB PCB Antenna connectors (ANT_xxx_) 6 4 Capacitors (C_xxx_) 296 16 Diodes (D_xxx_) 5 0 Zener diodes (ED_xxx_) 17 0 Ferrite beads (FB_xxx_) 6 0 Wire links / connectors (J_xxx_) 14 4 Resistors (R_xxx_) 222 0 Inductors (L_xxx_) 15 0 Transistors (Q_xxx_) 16 19* Switches (SW_xxx_) 1 0 Test points (T_xxx_) 27 3 Integrated circuits (U/DU_xxx_) 24† 2 Crystal oscillators (X_xxx_) 5 0 Total without test points 627 45 Total with test points 654 48 Here is how the PinePhone compares with the Librem 5 in terms of components:\nType of component Librem 5 main Librem 5 USB PinePhone main PinePhone USB Antenna connectors (ANT_xxx_) 3 2 6 4 Capacitors (C_xxx_) 521 11 296 16 Diodes (D/TVS/ED_xxx_) 59 1 22 0 Connectors (J/CON_xxx_) 26 10 14 4 Resistors (R/F_xxx_) 348 8 222 0 Inductors (L/FB_xxx_) 79 7 21 0 Transistors (Q_xxx_) 17 0 16 19* Switches (SW_xxx_) 5 0 1 0 Test points (T/TC/TP/TS/TV_xxx_) 126 4 27 3 Integrated circuits (U/DU_xxx_) 65 2 24† 2 Crystal oscillators (Y/X_xxx_) 10 0 5 0 Total without test points 1133 41 627 45 Total with test points 1259 45 654 48 18 parts for the PinePhone USB-C port are labeled as T_xxx_ in the schematic with the image of transistors, but it is possible that these are resistors and capacitors. † There are 26 U/DU_xxx_ listed in the PinePhone schematic, but the two extra are for an alternative magnetometer (U1200 / U1203) and an alternative gyroscope and accelerometer (U1202 / U1204) which are unpopulated.\nSource: Amos Batto\nOther components not in the schematics SGMICRO SGM3140 500mA buck/boost charge pump LED driver for camera flash and torch, TDFN-10 3x3x0.75 mm Note: The PinePhone page lists the SGM3140, but the schematics contain the U1000: awinic AW3641EDNR, so it is unclear why the SGM3140 is needed. Goodix GT917S touch controller Sitronix ST7703 MIPI LCD driver Xingbangda XBD599 5.99″ IPS LCD, 720x1440 pixels, 16.7M colors, hardened glass Datasheets Allwinner A64 SoC information:\nAllwinner A64 SoC brief introduction Allwinner A64 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMIC (Power Management IC) information:\nAXP803 PMIC datasheet LPDDR3 (178 Balls) SDRAM:\nArtmem LPDDR3 datasheet eMMC information:\nKimtigo eMMC datasheet CMOS camera module information:\nPinePhone 5M Pixel Real CMOS Image Sensor Module OV5640 5MP CMOS Image Sensor SoC for Rear Module datasheet OV5640 Embedded Firmware User Guide – VCM AF Module PinePhone 2M Pixel Front CMOS Image Sensor Module GC2145 2MP CMOS Image Sensor SoC for Front Module datasheet LCD touch screen panel information:\n5.99\u0026quot; 1440x720 LCD IPS Panel specification ST7703 LCD Controller datasheet GOODiX GT917S Capacitive Touch Controller datasheet Lithium battery information:\nPinePhone Lithium Battery specification PinePhone Lithium Battery ZCV curve chart PinePhone Lithium Battery 3D onshape drawing WiFi/BT module information:\nRTL8723BS/RTL8723CS specification LTE module information:\nhttps://wiki.pine64.org/wiki/File:Quectel_EG25-G_LTE_Standard_Specification_V1.3.pdf https://wiki.pine64.org/wiki/File:Quectel_EG25-G_Hardware_Design_V1.4.pdf https://wiki.pine64.org/wiki/File:Quectel_EC2x\u0026EG9x\u0026EG2x-G\u0026EM05_Series_AT_Commands_Manual_V2.0.pdf https://wiki.pine64.org/wiki/File:Quectel_EC2xEG25-GEG9xEM05_FILE_AT_Commands_Manual_V1.0.pdf https://wiki.pine64.org/wiki/File:Quectel_EC2x\u0026EG9x\u0026EG2x-G\u0026EM05_Series_GNSS_Application_Note_V1.3.pdf Sensors:\nST LIS3MDL 3-axis Magnetometer Datasheet InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS datasheet SensorTek STK3335 Ambient Light Sensor and Proximity Sensor Digital video to USB-C bridge:\nANX7688 product brief Case information:\nPinePhone case exploded diagram PinePhone back cover 3D file Other components:\nSee the Component List Press Vector images and pictures of the PinePhone and PinePhone Pro you can freely use for projects and press inquiries. Attribute the author if attribution is required via the license (such as CC BY).\nPinePhone Pro Author: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nPinePhone Beta Edition. Author: Funeral, License: CC0\nAuthor: Funeral, License: CC0\n3D model The 3D model can be used for a wide variety of purposes, for example for product renderings:\nhttps://www.thingiverse.com/thing:4520124 Example rendering:\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nNew template:\nAuthor: Funeral, License: CC0\nOld template:\nAuthor: Funeral, License: CC0\nLockscreen template For renderings you can use and modify this template:\nVersion with black background. Author: Funeral, License: CC0.\nVersion with no background. Author: Funeral, License: CC0.\nManual and Instructions Author: Jedi2light, License: CC BY 4.0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nResources The following resources have been made available by Ondřej Jirman, a developer for the Pinephone:\nGetting started with PinePhone Hardware State of development progress Development log PinePhone Technical News and Update, also applies to other Allwinner devices including PINE A64 SBC Contributions to the kernel development Safety General recommendations Due to the greater control the user is having over the device and its software comes also greater responsibility. It is necessary to verify the configuration of the device to make sure that responsible settings are used. The different operating systems may come with non-sane default settings, including SSH with weak password authentication being enabled by default and exposed to the public Internet, the absence of a firewall, default passwords, unencrypted files, too high temperature zones and emergency shutoff values or an enabled root account. The usage of public resources to verify such settings (such as the in case of GNU/Linux, the Arch Linux security wiki page, or the general recommendations) as well as the corresponding operating system’s or distribution’s resources are strongly recommended.\nCharging safety The PinePhone supports up to 5V 3A (15W) Quick Charge, it follows the USB Power Delivery specification. Only compatible phone chargers may be used, charging the phone with incompatible chargers (for example laptop chargers with a higher voltage) is prohibited. Charging the phone releases heat, general safety recommendations must be followed, see the section Thermal safety.\nThermal safety With the Allwinner A64 being an older generation SoC with a large 40nm chip, the phone produces quite some heat with medium or higher use and especially also during charging or when using USB accessories, like a docking station. Measurements to prevent damage to the phone and to its surroundings need to be taken by the user. This includes especially a proper handling of the phone: do not charge the phone in a way where heat builds up around the phone without being able to escape. Especially don’t charge your phone under a pillow, blankets, in pockets or bags. Charging the phone produces heat and charging the phone in a way, where the excessive heat can’t dispose around the phone poses an immediate fire risk.\nThe user might notice that the phone gets warm under usage, compared to phones with more up-to-date hardware. Under normal circumstances these temperatures don’t pose a risk while being in the levels within the safe operating temperatures (which lay far beyond the point where components can be too hot to touch). Higher temperatures might especially be experienced on the top side of the screen and on the inside of the phone at the RF shield of the modem. The higher temperature of the RF shield of the modem is commonly caused by the SoC on the opposite side of the mainboard, the RF shield of the modem is used to disperse heat of the SoC. In newer mainboard revisions starting from 1.2a there are also thermal pads on the back cover and between the SoC’s RF shield and the screen, dispersing heat on the screen and on the back cover. In the past there has been safety issues regarding thermal safety functions, causing temperature reads to not properly work over an extended period of time, which was causing heat damage in some cases (see the documentation of that issue by the developer Megous here and here). While the developers are working hard to prevent such issues, they can’t be excluded under all circumstances. The users are expected to monitor their phones\u0026rsquo; thermal safety at every point at this state of the software.\nIt is highly recommend to update the phone on a regular basis to always get the latest improvements. The default settings to throttle the performance and to shut down the phone when reaching critical temperatures might be set to a too high point depending on the specific usage and usage length. Under GNU/Linux the phone’s thermal management behavior can be modified via the Thermal Sysfs driver to achieve lower temperatures and preventing the screen and other components to potentially take damage, see Thermal tweaks for the details.\nSchematics and certifications PinePhone mainboard schematic:\nPinePhone mainboard Released Schematic ver 1.2b PinePhone mainboard Released Schematic ver 1.2a PinePhone mainboard Released Schematic ver 1.2 PinePhone schematic ver 1.2 change list \u0026ldquo;Braveheart\u0026rdquo; PinePhone mainboard Schematic ver 1.1 \u0026ldquo;Braveheart\u0026rdquo; PinePhone mainboard component top placement drawing ver 1.1 \u0026ldquo;Braveheart\u0026rdquo; PinePhone mainboard component bottom placement drawing ver 1.1 Components list PinePhone USB-C small board schematic:\nPinePhone USB-C small board Schematic ver 1.0 PinePhone USB-C small board component top placement drawing ver 1.0 PinePhone USB-C small board component bottom placement drawing ver 1.0 PinePhone certifications:\nPinePhone FCC Certificate RF Exposure SAR Information from FCC ID site PinePhone CE RED Certificate PinePhone ROHS Report Note: PinePhone’s Type Allocation Code (TAC) is 86769804 Sensors and navigation Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. Overview The PinePhone contains various components that enable or aid orientation and navigation tasks.\nMulti-GNSS Receiver as part of the cellular modem (GPS/Galileo/GLONASS/BeiDou) IMU (Inertial Measurement Unit), combined Accelerometer and Gyroscope sensor (MPU6050) Magnetometer (LIS3MDL or AF8133J) PinePhone navigation sensors\nHardware Quectel EG25G Modem / GNSS Receiver Invensense/TDK MPU6050 IMU Key features:\nDigital-output X-, Y-, and Z-Axis angular rate sensors (gyroscopes) with selectable range of ±250, ±500, ±1000, and ±2000°/sec Digital-output triple-axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g 400 kHz Fast Mode I2C for communicating with all registers ST LIS3MDL Magnetometer/Compass Key features:\n±4/±8/±12/±16 gauss selectable magnetic full scale range 16-bit data output \u0026hellip; VTC AF8133J Magnetometer/Compass Key features:\n±12/±22 gauss selectable magnetic full scale range 400Hz max. update rate 16-bit data output Sensor reference frames The sensors are mounted on the PinePhone’s mainboard in different positions and orientations. For the purpose of orientation and navigation it is important to know the relationship between the sensor coordinate frames and the body frame of the phone.\nPinePhone sensor coordinates systems (red) and body coordinate system (cyan)\nAs a basis for software development, a common body coordinate system has to be established along with it’s relation to a world coordinate system. \u0026ldquo;iio-sensor-proxy expects the (sensor) readings to match those defined in the Linux IIO documentation, the Windows Integrating Motion and Orientation Sensors whitepaper, and the Android sensor documentation\u0026rdquo;[ref]. To transform the sensor coordinate systems into body coordinates, \u0026lsquo;mount matrices\u0026rsquo; have to be defined.\nTODO: explain body reference choices, north-east-down world coordinates\nSoftware Drivers TODO: i2cdev, linux-iio, support matrix\nEG25G: provides either UART or USB based interfaces for NMEA data /dev/ttyUSB2: AT command interface /dev/ttyUSB1: default NMEA data output MPU6050:inv_mpu6050, inv_mpu6050_i2c, industrialio iio:device2: mpu6050 (buffer capable) 9 channels found: accel_x: (input, index: 0, format: be:S16/16\u0026gt;\u0026gt;0) 6 channel-specific attributes found: attr 0: calibbias value: -2102 attr 1: matrix value: 0, 0, 0; 0, 0, 0; 0, 0, 0 attr 2: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 3: raw value: 912 attr 4: scale value: 0.000598 attr 5: scale_available value: 0.000598 0.001196 0.002392 0.004785 accel_y: (input, index: 1, format: be:S16/16\u0026gt;\u0026gt;0) 6 channel-specific attributes found: attr 0: calibbias value: 941 attr 1: matrix value: 0, 0, 0; 0, 0, 0; 0, 0, 0 attr 2: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 3: raw value: 516 attr 4: scale value: 0.000598 attr 5: scale_available value: 0.000598 0.001196 0.002392 0.004785 accel_z: (input, index: 2, format: be:S16/16\u0026gt;\u0026gt;0) 6 channel-specific attributes found: attr 0: calibbias value: 1242 attr 1: matrix value: 0, 0, 0; 0, 0, 0; 0, 0, 0 attr 2: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 3: raw value: 15860 attr 4: scale value: 0.000598 attr 5: scale_available value: 0.000598 0.001196 0.002392 0.004785 temp: (input) 3 channel-specific attributes found: attr 0: offset value: 12420 attr 1: raw value: -1073 attr 2: scale value: 2.941176 anglvel_x: (input, index: 4, format: be:S16/16\u0026gt;\u0026gt;0) 5 channel-specific attributes found: attr 0: calibbias value: 0 attr 1: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 2: raw value: -32 attr 3: scale value: 0.001064724 attr 4: scale_available value: 0.000133090 0.000266181 0.000532362 0.001064724 anglvel_y: (input, index: 5, format: be:S16/16\u0026gt;\u0026gt;0) 5 channel-specific attributes found: attr 0: calibbias value: 0 attr 1: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 2: raw value: 4 attr 3: scale value: 0.001064724 attr 4: scale_available value: 0.000133090 0.000266181 0.000532362 0.001064724 anglvel_z: (input, index: 6, format: be:S16/16\u0026gt;\u0026gt;0) 5 channel-specific attributes found: attr 0: calibbias value: 0 attr 1: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 2: raw value: 0 attr 3: scale value: 0.001064724 attr 4: scale_available value: 0.000133090 0.000266181 0.000532362 0.001064724 timestamp: (input, index: 7, format: le:S64/64\u0026gt;\u0026gt;0) gyro: (input, WARN:iio_channel_get_type()=UNKNOWN) 1 channel-specific attributes found: attr 0: matrix value: 0, 0, 0; 0, 0, 0; 0, 0, 0 3 device-specific attributes found: attr 0: current_timestamp_clock value: realtime attr 1: sampling_frequency value: 50 attr 2: sampling_frequency_available value: 10 20 50 100 200 500 2 buffer-specific attributes found: attr 0: data_available value: 0 attr 1: watermark value: 1 Current trigger: trigger1(mpu6050-dev2) LIS3MDL: st_sensors, st_sensors_i2c, st_magn, st_magn_i2c, industrialio iio:device1: lis3mdl (buffer capable) 4 channels found: magn_x: (input, index: 0, format: le:S16/16\u0026gt;\u0026gt;0) 3 channel-specific attributes found: attr 0: raw value: 6766 attr 1: scale value: 0.000146 attr 2: scale_available value: 0.000146 0.000292 0.000438 0.000584 magn_y: (input, index: 1, format: le:S16/16\u0026gt;\u0026gt;0) 3 channel-specific attributes found: attr 0: raw value: -2046 attr 1: scale value: 0.000146 attr 2: scale_available value: 0.000146 0.000292 0.000438 0.000584 magn_z: (input, index: 2, format: le:S16/16\u0026gt;\u0026gt;0) 3 channel-specific attributes found: attr 0: raw value: 12726 attr 1: scale value: 0.000146 attr 2: scale_available value: 0.000146 0.000292 0.000438 0.000584 timestamp: (input, index: 3, format: le:S64/64\u0026gt;\u0026gt;0) 3 device-specific attributes found: attr 0: current_timestamp_clock value: realtime attr 1: sampling_frequency value: 1 attr 2: sampling_frequency_available value: 1 2 3 5 10 20 40 80 2 buffer-specific attributes found: attr 0: data_available value: 0 attr 1: watermark value: 1 Current trigger: trigger0(lis3mdl-trigger) Userspace services TODO: \u0026hellip;\nModem Manager ofono gpsd iio-sensor-proxy geoclue Tools/Utilities TODO: minicom, gpsmon, monitor-sensor, iio-utils\u0026hellip;\nApplications TODO: pure-maps, navit, \u0026hellip;\nDevelopment TODO: Open issues, tasks, projects\nOpen issues AGPS integration how to enable/disable the service? update triggers? network connectivity? agps data valid? Raw magnetometer handling Issue: Support polling/non-compensated magnetometers in iio-sensor-proxy https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/310 https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/316 (needs more work) Issue: raw magnetometer calibration implementation https://appelsiini.net/2018/calibrate-magnetometer/ GPS/Compass App TODO: specification Frameworks/APIs/\u0026hellip; Modem Manager location API https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Modem.Location.html oFono location API (experimental?) https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/location-reporting-api.txt geoclue API https://www.freedesktop.org/software/geoclue/docs/gdbus-org.freedesktop.GeoClue2.Location.html https://www.freedesktop.org/software/geoclue/docs/libgeoclue/GClueLocation.html Specifications Dimensions: 160.5 x 76.6 x 9.2mm Weight: Between 180 ~ 200 grams SIM Card: Micro-SIM Display: Size: 5.95 inches (151mm) diagonal Type: HD IPS capacitive touchscreen, 16M colors Resolution: 1440x720, 18:9 ratio System on Chip: Allwinner A64 RAM: 2GB or 3GB LPDDR3 SDRAM Internal Storage: 16GB or 32GB eMMC, extendable up to 2TB via microSD, supports SDHC and SDXC Back Camera: Single 5MP, 1/4\u0026quot;, LED Flash Front Camera: Single 2MP, f/2.8, 1/5\u0026quot; Sound: Loudspeaker, 3.5mm jack \u0026amp; mic (jack doubles as hardware UART if hardware switch 6 is deactivated) Communication: Modem: Quectel EG25-G LTE-FDD: B1, B2, B3, B4, B5, B7, B8, B12, B13, B18, B19, B20, B25, B26, B28 LTE-TDD: B38, B39, B40, B41 WCDMA: B1, B2, B4, B5, B6, B8, B19 GSM: B2, B3, B5, B8 (850, 900, 1800, 1900 MHz) WLAN: Wi-Fi 802.11 b/g/n, single-band, hotspot Bluetooth: 4.0, A2DP GNSS: GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS Sensors: Accelerometer, gyroscope, proximity, ambient light, compass Privacy switches: Modem, WiFi \u0026amp; Bluetooth, Microphone, Cameras Battery: Lithium-ion, rated capacity 2800mAh (10.64Wh), typical capacity 3000mAh (11.40Wh) (nominally replaceable with any Samsung J7 form-factor battery) I/O: USB Type-C, USB Host, DisplayPort Alternate Mode output, 15W 5V 3A Quick Charge, follows USB PD specification ","permalink":"/documentation/PinePhone/_full/","tags":null,"title":"PinePhone (Single Page)"},{"categories":null,"contents":"This page details a hardware fix for an issue that affects some early v1.1 Braveheart units (fixed since 1.2 community edition included).\nThe issue was PinePhone_v1.1-Braveheart#Excess_power_usage_while_driving_VBUS by megi.\nTODO: Add more pictures and schematics, better reference the fix origin and tradeofs, remove TODOs/FIXMEs.\nAffected Units PinePhone v1.1 - Braveheart FIXME: confirm \u0026ldquo;Project Don’t Be Evil\u0026rdquo; devkit and PinePhone v1.0 - Developer batch are unaffected.\nDisclaimer Though easier to perform than the PinePhone 1.2 VCONN hardware fix, this fix requires desoldering relatively small Surface Mount Technology (SMT) components, therefore some experience with soldering is recommended.\nIssue description TODO: pictures\nThe AXP803 cannot detect when the USB port is powered by the battery. Therefore, the Power Management IC (PMIC) continues draining current from it. This is especially problematic since this USB port is powered from the battery with the USB OTG boost regulator. One of the symptoms is the battery discharging rather quickly even when the phone is powered off.\nWorkaround HW workaround is desoldering the U1301 regulator (TODO: describe its role) and shorting pads for R1309 on the PCB (this is a \u0026ldquo;0 ohm\u0026rdquo; resistor on the schematic, so it’s completely fine).\nShorting the pads is easy to do with some solder (while carefully avoiding to short it with nearby resistors).\nDesoldering the regulator is harder to do, since its large pads are designed to use the PCB as a heatsink and will happily cool down while you are trying to melt it. It should be possible to use properly sized pliers to cut the pins first, please edit if you attempt this.\nPlease be careful not to overheat nearby components trough the PCB traces when applying heat to the regulator. It can be helpful to start the operation with melting some leaded solder tin together with the pads, and lifting the regulator while applying heat also helps. Start with the side that has only one pad: though it is bigger, it should be easier to lift up. It might be useful to apply a relatively large quantity of molten solder tin to each pin, in turn, while lifting the regulator, to reduce the PCB heatsink effectiveness.\nFeel free to add your experiences and tips here.\nTradeoffs TODO: Unknown to the author\nProper fix TODO\nSources and tutorials Tutorial from megi Description from megi at the end of the page ","permalink":"/documentation/PinePhone/Repairs/PinePhone_1.1_VBUS_power_usage_Hardware_Fix/","tags":null,"title":"PinePhone 1.1 VBUS power usage Hardware Fix"},{"categories":null,"contents":"This page details a hardware fix for an issue that was found on early PinePhone hardware revisions (see PinePhone for an overview of the different revisions) and has been fixed since the 1.2a hardware revision.\nThe issue was PinePhone_v1.1-Braveheart#USB-C_CC_pins_are_pulled_to_the_GND_by_AW3512.28VCONN_switches.29_when_VCONN_is_off_ by megi.\nAffected Units Requires confirmation: \u0026ldquo;Project Don’t Be Evil\u0026rdquo; devkit Requires confirmation: PinePhone v1.0 - Developer batch PinePhone v1.1 - Braveheart PinePhone v1.2 - UBports Community Edition Disclaimer This fix requires desoldering tiny (1 mm per 1 mm, from the datasheet) BGA components, therefore some experience with soldering is highly recommended.\nIssue description Close-up picture of the two identical switches the issue originates from, with the ANX USB controller in the frame\nExcerpt from the PinePhone schematic showing the two components.\nThe USB standard specifies that both halves (top and bottom) of the USB-C port contains one \u0026ldquo;CC\u0026rdquo; pin (CC1 and CC2, respectively). A regular cable will connect a CC pin from one end to the other end. This allows detecting which way the cable is plugged. Some active USB-C cables exist (both \u0026ldquo;e-marked\u0026rdquo; and \u0026ldquo;managed active cables\u0026rdquo;); they contain a chip, which needs to be powered. This is done by having one of the cable end connect its CC pins to 5V and VCONN, and requires switches to plug the right CC pin to the right voltage.\nThe issue arises due to the switches that were chosen up to v1.2a (the a revision excluded) of the PCB assembly: the infamous AW3512, labelled U1305 and U1309 on the schematic. Instead of leaving the output pin \u0026ldquo;dangling\u0026rdquo; with a high impedance when disabled, the switch pull the output down. This feature is intended for discharging a capacitor, hence its \u0026ldquo;Quick output discharge\u0026rdquo; name. This is an excerpt from the datasheet:\n\u0026ldquo;The AW3512/AW35122 includes the Quick Output Discharge (QOD) feature, in order to discharge the application capacitor connected on OUT pin. When EN pin is set to low level (disable state), a discharge resistance with a typical value of 276Ω (AW35122: 75Ω) is connected between the output and ground, pull down the output and prevent it from floating when the device is disabled.\u0026rdquo;\nThis issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There’s no SW workaround for automatic detection of cable plug or power role.\nIn SW this could theoretically be worked around by manual selection of PinePhone’s data and power role by the user, but hasn’t been attempted, and might damage hardware if done incorrectly.\nWorkaround Hardware workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles.\nTradeoffs Voiding the VCONN control might (TODO: gather more data) prevent some accessories from working, notably those using an active cable.\nProper fix HW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn’t have the \u0026ldquo;quick discharge function\u0026rdquo; that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement. PCBA revision 1.2a onwards incorporate that fix.\nSources and tutorials megi’s writeup another writeup from megi with a few words on firmware Video: \u0026ldquo;The right way\u0026rdquo; with a hot air gun/reflow station, by mozzwald Video: \u0026ldquo;The equally stupid way\u0026rdquo;, workaround video by Dalton, using a soldering iron. Less chances to permanently damage the board than the next if you are handy with a soldering iron, but still high. Video: \u0026ldquo;The stupid way\u0026rdquo; workaround video by Lukasz, with pliers. Slightly damages the circuit board, preventing you from soldering the replacement chips at a later point. You might be fine with this. ","permalink":"/documentation/PinePhone/Repairs/PinePhone_1.2_VCONN_Hardware_Fix/","tags":null,"title":"PinePhone 1.2 VCONN Hardware Fix"},{"categories":null,"contents":"This page details a hardware fix for an issue that was found on early PinePhone hardware revisions (see PinePhone for an overview of the different revisions) and has been fixed since the 1.2b hardware revision.\nAffected Units PinePhone v1.2 - UBports Community Edition PinePhone v1.2a - postmarketOS Community Edition Disclaimer This fix requires desoldering a tiny resistor, therefore some experience with soldering is highly recommended.\nIssue description When connecting a VBUS powered device to the affected devices, like USB-C docks or hubs, the brightness changes significantly. The cause of the issue was a VBUS_CTRL signal provided by ANX7688 to control VBUS power direction. The signal is connected to AXP803 to tell it to not trying to charge from VBUS when the VBUS is generated from the battery. The signal is connected to the PL9 pin of the SoC, withut there being a reason for that. VBUS_CTRL is a 3.3V signal and the PL port is a 1.8V port. The issue was introduced in the 1.2 board revision.\nFix The fix of the issue is to remove the R1318 resistor.\nA detailed instruction will follow here.\nR1318 location on the board\nSources and tutorials Megi’s blog: Backlight changes when swithcing between USB-C power modes ","permalink":"/documentation/PinePhone/Repairs/PinePhone_1.2b_R1318_backlight_Hardware_Fix/","tags":null,"title":"PinePhone 1.2b R1318 backlight Hardware Fix"},{"categories":["Phones"],"contents":"Meet the PinePhone Pro, our flagship smartphone and the best way to experience mainline Linux on a mobile device.\nFeatures and Specifications System on Chip (SoC) Rockchip RK3399S 64bit SoC – 2x A72 and 4x A53 CPU cores @ 1.5GHz GPU ARM Mali T860 4x core GPU @ 500MHz RAM 4GB LPDDR4 @ 800MHz Storage 128GB eMMC flash storage Optional micro SD card (SDXC up-to 2TB) LCD panel 6″ 1440 x 720 in-cell IPS with Gorilla Glass 4™ Cameras 13MP Sony IMX258 main camera with Gorilla Glass 4™ protective layer 8MP OmniVision OV8858 front-facing camera Modem \u0026amp; GPS Quectel EG25-G – global GSM and CDMA bands GPS, GPS-A, GLONASS WiFi \u0026amp; Bluetooth AMPAK AP6255 WiFi 11ac + Bluetooth V4.1 I/O MicroSD slot Pogo-pins (compatible with the original PinePhone) USB-C power, data (USB 3.0) and DP alt-mode video out Sensors Accelerator Gyroscope Proximity Compass Ambient light Privacy hardware switches Cameras Microphone WiFi and Bluetooth LTE modem (including GPS) Headphones (to enable UART output) External buttons Volume up / down rocker Power ON/ OFF Audio Out Headset speaker Audio jack Loud Speaker Other Flash / Torch Vibration motor Status LED UART via audio jack Battery Samsung J7 form-factor 3000mAh Charging 5V 3A (15W) Quick Charge – USB Power Delivery specification Dimensions 160.8 x 76.6 x 11.1mm Weight Approx. 215g Stores Global Global: Accessories Global: Spare parts Affiliates Documentation PinePhone Pro Datasheets, schematics and certifications What’s inside? We learned a lot from working on the original PinePhone. Over the past two years we painstakingly collected and analyzed your feedback and explored all avenues for hardware improvements. The PinePhone Pro is the end result of this journey. It is powered by a Rockchip hexa-core SoC operating at 1.5GHz, and ships paired with 4GB of dual-channel LPDDR4 RAM as well as 128GB of internal eMMC flash storage. It features a high-fidelity 13MP main camera sensor and a 5MP front-facing camera.\nWe worked closely with Rockchip’s engineering team to fine-tune the SoC’s performance so that it meets the necessary thermal and battery-consumption envelopes. The result of this cooperation is the RK3399S – a RK3399 variant made specifically for the PinePhone Pro. Rockchip’s team was also instrumental in enabling the PinePhone Pro’s suspend state, which allows the smartphone to receive calls and SMS messages while preserving battery.\nHardware privacy dip switches for the cameras, the microphone, WiFi \u0026amp; BT, headphone jack (enabling UART) and the LTE modem (including GPS) are accessible under the back cover, just as on the original PinePhone.\nWhat’s the outside like? We wanted the PinePhone Pro to reflect its status as a pro-grade device while maintaining perfect compatibility with all existing PinePhone peripherals. The PinePhone Pro uses the same pogo-pin systems and back cover attachment as the original PinePhone, making it compatible with all existing add-ons. The keyboard, PineDio LoRa, fingerprint reader and wireless charging cases will all work with the PinePhone Pro.\nThe PinePhone Pro features a vibrant in-cell IPS display covered with Corning Gorilla Glass 4™ with an oleophobic coating, offering superior scratch resistance and image clarity. The camera is covered by Corning Gorilla Glass 4™ and protected by an elevated bezel, similar to the one found on the original PinePhone.\nThe chassis is slightly thicker (~2mm) than the original PinePhone’s. Proportions of the original design were altered to accommodate the new display and to allow for improved heat dissipation. The coating on the back of the PinePhone Pro has been given a premium feel and engineered to minimize oily fingerprints. We think you’ll be pleased with the end-result.\nWho is it for? Contemporary mobile Linux operating systems have a way to go before they can be considered true alternatives to Android or iOS. While mobile Linux isn’t in a state that could satisfy most mainstream electronics consumers, we recognize that a sizable portion of our community is ready to make the jump to a Linux-only smartphone today. The PinePhone Pro has the raw horsepower to be your daily driver, granted you’re ready to accept the current software limitations.\nIn a nutshell: if you are an existing PinePhone owner and your only wish is for the device to be more powerful and refined, then the PinePhone Pro is for you\nWho isn’t it for? We’re not in the business of selling empty promises – a much faster mainline Linux smartphone won’t make the existing operating systems more refined, nor will it magically spawn software replacements for your iOS or Android applications. There is a long road ahead of us, all of us, and it will require time and effort for the software to reach a degree of maturity that would satisfy mainstream users.\nIf you depend on proprietary mainstream mobile messenger applications, banking applications, use loyalty or travel apps, consume DRM media, or play mobile video games on your fruit or Android smartphone, then the PinePhone Pro is likely not for you.\nWhat does it run? Openness means privacy and security as well as software choice. Just as the original PinePhone, the PinePhone Pro runs mainline Linux (with patches, which are being upstreamed) with open source drivers.\nWhere do I learn more? More information about the PinePhone Pro will be available in the days and weeks to come. We encourage you to read the October Community Update featuring an explanation of the rationale behind bringing the PinePhone Pro to the market and an account of our team’s decision-making process.\nAccessories PinePhone (Pro) Keyboard The keyboard add-on for the PinePhone and PinePhone Pro adds a physical keyboard and a large battery. LoRa Add-on A LoRa add-on which uses the pogo pins to interface a Semtech SX1262 LoRa module Qi Wireless Charging Add-on A Qi wireless charging add-on which ses the pogo pins to supply Qi Wireless and Wireless Power Consortium compatible charging. No software required. Fingerprint Reader Add-on A fingerprint reader add-on which uses the pogo pins to interface a high quality fingerprint sensor, uses open firmware for it’s i2c bridge, and can also be used for gesture navigation. USB-C Docking Bar An USB-C docking bar adding an ethernet port, two USB ports, an HDMI port and a power input. TPU Protective Case A soft TPU protective case. Serial Cable Serial console powered by CH340 chipset enables USB-to-Serial-communication through the earphone jack for development. Battery Charger An external charger for the battery. Flex Break-out Board A flexible break-out PCB for i2c IO expansion. Tempered Glass Screen Protector 9H hardness tempered glass screen protector specially designed for the Pinephone and PinePhone Pro.. FAQ I am a PinePhone owner – will I be able to upgrade it by installing a PinePhone Pro mainboard? Probably not. While the PinePhone Pro’s mainboard will fit the PinePhone, the chassis, IPS display panel, cameras, the daughterboard, and thermal dissipation systems are all different. For instance, the PinePhone Pro’s cameras will not fit into the PinePhone chassis and are electrically incompatible with the PinePhone’s mainboard. Software enablement would also be required to drive the original PinePhone’s components (such as the LCD) using the PinePhone Pro’s mainboard. Thermal dissipation is another important consideration, as the higher heat output may not be trivial to overcome in the original PinePhone’s chassis.\nWill you keep on producing and selling the original PinePhone? Absolutely! There are many people who either need a less expensive option or simply aren’t ready to make the commitment to switch to a Linux smartphone just yet. The PinePhone will keep on catering to this crowd for the foreseeable future.\nMoreover, we believe that the PinePhone will retain its position as the most popular mobile Linux development platform on the market due to its price point and broad adoption. We know that the development community depends on the PinePhone’s continued availability, so we will produce it for as long as there is demand and available components.\nCan I use the PinePhone keyboard and other add-on back cases with the PinePhone Pro? Yes, we designed the midframe and pogo pin layout of the PinePhone Pro to be compatible with the original PinePhone. You can expect all PinePhone accessories, bar the original PinePhone’s soft and hard protective covers, to work with the PinePhone Pro. Future accessories will strive to be compatible with both smartphones.\nHow does the PinePhone Pro compare to the Pinebook Pro performance-wise? Although both devices use a similar SoC, due to the thermal constraints imposed by the chassis, the PinePhone Pro is around 20% slower than a Pinebook Pro. The RK3399S chips used in the PinePhone Pro are binned and voltage locked for optimal performance with sustainable power and thermal limits. That said, the perceived performance of the two devices ought to be comparable due to the PinePhone Pro’s lower screen resolution and better optimization.\nDoes the PinePhone Pro have fewer blobs and more open firmware than the original? The PinePhone Pro is as open as the original PinePhone. Read more here.\nWill PinePhone Pro’s production be affected by global component shortages? It is highly likely that production will be affected by global component shortages at some stage, but it is very difficult for us to determine the degree, given how hard it is to foresee how the situation will unfold in the coming months. Our website features an inventory availability, stock and shipping status page updated on a regular basis.\nHow repairable is the PinePhone Pro? Just as the original PinePhone, the PinePhone Pro is built to be user repairable and we will offer spare parts in the Pine Store. The store’s selection will include all parts that frequently break if the device is dropped (the screen, back case and mid section) as well as all electronic components, including the mainboard.\nThe PinePhone Pro is held together by standard Phillips screws – all you need to repair it is a suitable screwdriver and some spare time.\n","permalink":"/devices/pinephone_pro/","tags":null,"title":"PinePhone Pro"},{"categories":null,"contents":" The PinePhone Pro is PINE64’s flagship smartphone announced on October 15, 2021. It features 4GB of RAM, an 128GB eMMC and is using an Rockchip RK3399S SoC, which is a specialized version of the RK3399 made specifically for the PinePhone Pro.\nIntroduction The PinePhone Pro is PINE64’s second smartphone and a successor to the original PinePhone. It does not, however, replace the original PinePhone. It should also not be considered a second generation PinePhone; it is a higher-end device, with much better specs, aimed at those who wish to daily-drive a open system stack. Achieving this goal will, however, take time as the software and overall smartphone software ecosystem needs to mature.\nNote: This image preview protects your privacy. Click to load the video from the Google servers. Link to the video Editions and revisions Similarly to the original PinePhone, various PinePhone Pro editions are planned, the first of which is the Developer Edition (aimed at developers, as the name entails) followed by the Explorer Edition, which is aimed at early adopters.\nDeveloper Edition Explorer Edition Help and support Still have any questions regarding software, shipping, or ordering after reading the documentation? Please don’t hesitate to contact the community in the bridged community channels for detailed answers or simply to chat with friendly people in the community! See Main Page.\nPlease keep in mind that PINE64 is not like a regular company (see the PINE64 philosophy) and that support resources are limited - the best way to get support quickly is to ask in the community chat! Please only contact the PINE64 support directly if questions couldn’t be solved via the community chat or the documentation.\nFirst time setup A protection foil isolates the battery for the shipping.\nWhen shipped the battery is isolated from the device using a protective plastic tab, which is required to be removed before using the phone. The battery will not charge or boot until it is removed and the battery is connected again.\nNote To remove the sticker after unboxing the phone: Carefully remove the back panel using the notch in the corner of the back cover without overbending it. Then remove the battery. Peel off the clear plastic sticker below it, which isolates the charging contacts and reinsert the battery. The SIM card has to be placed in the lower slot, while the microSD has to be placed in the upper slot. Devices shipped after the end of July 2022 do only accept a nano-SIM, the SIM is inserted into a carriage released by slightly pulling on the handle in the lower slot (for information regarding devices shipped prior to end of July 2022 see below).\nThe microSD belongs in the upper slot, the SIM card in the lower slot.\nNote The PinePhone Pros shipped prior to the end of July 2022 come with a micro-SIM slot instead of a nano-SIM slot. Do not insert an empty micro-SIM adapter into the phone and do not release the nano-SIM inside the adapter, as it will get stuck on the contact pins. If the nano-SIM got released inside the adapter inside the phone, carefully reinsert the nano-SIM card without moving the adapter. In that case do not pull on the empty adapter as it will get stuck on the contact pins and damage them! Software Boot order\nInstallation instructions\nReleases\nSoftware State\nBootloaders\nMulti-distribution image\nBoot order The RK3399S processor in the PinePhone Pro searches for the bootloader (such as U-Boot or Tow-Boot) in the following order:\nSPI flash eMMC (the internal memory) MicroSD card Boot from microSD card temporarily To temporarily boot from an inserted microSD card do the following:\nOn the Explorer Edition ordered after November 2023 the microSD card is first in boot order due to using rk2aw instead of Tow-Boot, see here. A boot menu can be opened by holding power at boot for not too long. On the Explorer Edition ordered after July 2022 hold the volume down key while powering on the device. The batches bought after July 2022 come with Tow-Boot flashed to the SPI, which offers additional functionality over U-Boot as bootloader. On the Explorer Edition ordered between January and July 2022 hold the RE button underneath the cover for a few seconds, while powering on the device. If the button is labeled RESET instead of RE please verify if the device is a regular PinePhone (or the Developer Edition). This is required because older batches don’t ship with Tow-Boot on the SPI. Flashing Tow-Boot can be caught up by following this instruction. Note: If Tow-Boot is flashed later, the microSD card can be selected at boot with the volume down key as well. On the Developer Edition (sold to selected developers only) the SPI and the eMMC can be bypassed by shorting the bypass test points while booting. The process is explained in the article PinePhone Pro Developer Edition. Please join the community chat for any questions regarding the process. The RE button disables the SPI and the eMMC at the hardware level while the button is held and the PinePhone Pro will try to boot from the next available boot medium, which is the microSD card. Note: When holding the RE button (or when shorting the contact points in case of the Developer Edition) for a longer time at boot the operating system will not initialize the SPI and eMMC and it will not be possible to write to these storage mediums until the next reboot.\nNote The bootloader uses its own boot order for loading the kernel and other core operating system components at boot, which for example may result in the boot loader residing on the eMMC loading and booting the kernel from a microSD card. Boot from microSD card permanently The bootloader (such as U-Boot) resides in the free space in front of the first partition. Wiping the bootloader from the eMMC to make the PinePhone Pro boot from microSD card can be done using sudo dd if=/dev/zero of=/dev/mmcblk2 seek=64 count=400 conv=fsync. Formatting the drive or deleting the partition table is not sufficient to wipe the bootloader.\nInstallation instructions The software releases can be installed (the process is being referred to as flashing) to the internal memory of the PinePhone Pro (the eMMC) or to an microSD card.\nInstallation to the microSD card The images can be installed to an microSD card and be booted from it.\nThe microSD belongs in the upper slot, the SIM in the lower slot.\nNote Compared to installations to the eMMC, running operating systems from the microSD card is slower than to the eMMC due to the microSD card’s slower reading and writing speeds. To install an image to the microSD card:\nDownload a compatible image from Releases. Important: Typically the image will be compressed in an archive file to reduce the download size (such as .gz or .xz). Extract the image from its archive file to get the file with the file extension .img. Write the image to your microSD card using your favorite method, examples: Using dd: On the device you’re flashing the microSD card from, find the correct device under lsblk and then flash the image to the microSD card using sudo dd if=IMAGE.img of=/dev/[DEVICE] bs=1M status=progress conv=fsync and make sure the target is the whole microSD card and not its first partition, sdc1 or mmcblk0p1 are wrong! Using bmaptool: Make sure to select the correct device using lsblk. Then run bmaptool with the correct device: Download the IMAGE.xz and the IMAGE.bmap files, then run bmaptool copy --bmap IMAGE.bmap IMAGE.xz /dev/[DEVICE]. This takes around 2.5 minutes to flash a 4 GB file. Using a graphical tool: A graphical tool such as Gnome Disks under Linux or Etcher under Windows may also be used. Insert the microSD card into the top slot of the PinePhone Pro Boot the device using the following method: With rk2aw (as on the Explorer Edition ordered after November 2023): boot the phone without any further action if the image includes a bootloader or one is installed to the eMMC (such as in the default installation). With Tow-Boot (as on the Explorer Edition ordered after July 2022): hold the volume down key while booting. With an empty SPI (like on the Explorer Edition ordered between January and July 2022): hold the RE button underneath the back cover while booting (or use the volume down key if you flashed Tow-Boot). On the Developer Edition (sold to selected developers only) there is no RE button. Instead apply the bypass by shorting the testing pads while booting according to the datasheet. Installation to the eMMC Installing an operating system to the eMMC (the internal memory of the PinePhone Pro) can either be done by booting an operating system from the microSD and by installing to the eMMC directly from the booted microSD card operating system (recommended) or by using Tow-Boot\u0026rsquo;s USB Mass Storage mode.\nWarning Many images don’t include a bootloader. If the SPI only contains rk2aw (like phones ordered after November 2023) or is empty (like phones ordered between January and July 2022), the installation on the eMMC won’t boot. In these cases, it is required to install a bootloader (such as Tow-Boot) in order to get the phone to boot. By booting a microSD card The eMMC can be overwritten by booting an image from the microSD card and overwriting the eMMC from within that booted microSD card image.\nThis installation method is recommended.\nBoot an operating system from the microSD card. If there is already a bootloader on the eMMC installed see the section Boot order to bypass it. Download or copy the desired image to the microSD card as file Check if the eMMC appears under lsblk. If it doesn’t appear in the output of the command, the eMMC wasn’t initialized due to applying the above explained bypass method for a too long time during the boot Important: Typically the image will be compressed in an archive file to reduce the download size (such as .gz or .xz). Extract the image from its archive file to get the file with the file extension .img. Flash the image file using sudo dd if=IMAGE.img of=/dev/mmcblk2 bs=1M status=progress conv=fsync (replace IMAGE.img with the filename of the image you want to flash and make sure it has the file extension .img). Reboot the PinePhone Pro By using Tow-Boot The image can be written to the eMMC by using Tow-Boot’s USB Mass Storage mode.\nThis installation method is not recommended, as the USB connection can be unreliable and in some cases not work at all.\nPre-requirement: Tow-Boot must be installed on the SPI, eMMC or the microSD card Power off the device Power on the device and hold the volume up key before and during the second vibration The LED will turn blue if done successfully. This will only work if Tow-Boot is installed When connecting the device to a computer via USB it will behave like an USB drive now Check if the eMMC appears under lsblk, the output might look like the following:\nmmcblk2 179:0 0 115.2G 0 disk\n├─mmcblk2p1 179:1 0 122M 0 part /boot\n└─mmcblk2p2 179:2 0 115.1G 0 part /\nNote: In this example, /dev/mmcblk2 is the device, while mmcblk2p1 and mmcblk2p2 are partitions of the device. The downloaded images are images from full devices, which means that the full device (mmcblk2 in this example) needs to be flashed. Ignore the partitions! Important: Typically the image will be compressed in an archive file to reduce the download size (such as .gz or .xz). Extract the image from its archive file to get the file with the file extension .img Flash the image file using sudo dd if=IMAGE.img of=/dev/DEVICE bs=1M status=progress conv=fsync (replace IMAGE.img with the filename of the image you want to flash and make sure it has the file extension .img and replace DEVICE with the correct device from the lsblk command) Reboot the PinePhone Pro Releases This page contains a list of all available software releases and tools for the PinePhone Pro.\nFactory builds These are two operating system builds that was preloaded in the factory with testing utility.\nDownload the build, extract the image and dd it to a 8 GB or larger microSD card, then insert it into the PinePhonePro. Press \u0026ldquo;RE\u0026rdquo; button for two seconds when power up, follows on screen instruction and apply the build from microSD card to eMMC.\nDistribution Download Link File Size MD5 Sailfish with RK2AW ppp-factory-image-20231118.img.gz 447MB 4e31e0a6b0999e3e3df45f86a7dc9c33 Manjaro with Tow-Boot Manjaro-ARM-plasma-mobile-pinephonepro-factory-20211212.img.xz 1.37GB b82ba02287c1699b14fed403ce485b44 Arch Linux ARM (Unofficial) Arch Linux ARM with choice of Phosh UI, Plasma Mobile, sxmo or barebones. Currently being maintained by the DanctNIX community (GitHub: danctnix, dreemurrs-embedded).\nDownload Get both stable and test builds at GitHub releases or directly from the DanctNIX server.\nDefault credentials alarm 123456 root (barebone only) root Notes The GitHub page can be found here: dreemurrs-embedded/Pine64-Arch\nA re-image of the above Arch image providing a Btrfs root partitioning has been made by user kaida.\nGentoo The image must be built manually, including picking the kernel, bootloader and the desired desktop environment. The ARM64 version of Gentoo has to be selected. The PinePhone Pro will not boot with P-Boot but will boot with U-Boot.\nhttps://wiki.gentoo.org/wiki/PINE64_PinePhone_Pro\nNotes Note Please consider cross-compiling the software on the computer. Long compilation times and heat production can lead to a reduced lifespan of the phone. GloDroid A fully open-source port of Android and LineageOS to the PinePhone Pro.\nGitHub: GloDroid\nDownload Releases: GloDroid Notes Project status link\nLuneOS LuneOS is one of the original multi-tasking OS-es that runs on Linux. Based on HP/Palm’s webOS, merged with latest technology stack from LG called webOS OSE (a derivative of what LG uses on their Smart TV’s), software such as Qt5 and makes use of the Yocto build system.\nDownload LuneOS (Initial preview): Downloads Default credentials root Notes In order to connect to the device using SSH/SCP via WiFi: You can simply connect via SSH/SCP via WiFi using the PinePhonePro’s IP address on port 22.\nMobian A Mobian build for ARM64 running with Phosh. The current version of the base Debian system is Debian Trixie. See the installation instructions here. If you have questions about Mobian, please ask them in the Mobian Matrix room.\nDownload Images\nNote Tow-Boot required to be able to boot the images, see here! Default credentials mobian 1234 Notes The development is work in progress. The Mobian wiki can be found here.\nIn order to connect to the device using SSH/SCP via WiFi, you need to install SSH on the device. You can do this by executing the following in a shell: \u0026ldquo;sudo apt-get install ssh\u0026rdquo;, afterwards you can connect via SSH/SCP via WiFi using the PinePhonePro’s IP address on port 22.\nKali Linux The official Kali Nethunter images for PinePhone and PinePhone Pro have been released now. Get Nethunter App for your PinePhone’s Kali Linux.\nDownload Kali Phosh Unofficial Kali Nethunter Pro Official Default user for Unofficial Releases kali 8888 Default user for Nethunter Releases kali 1234 Nemo Mobile Nemo Mobile is the open source build of Sailfish OS with a open source UI called Glacier, based on OpenSUSE.\nDownload OpenSUSE based images\nDefault credentials manjaro 123456 root root Notes The website of the Nemo Mobile UX Team can be found here. Please report bugs regarding the Nemo Mobile UI as GitHub issue.\nNixOS NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades.\nDownload Not available yet.\nNotes Device page on the mobile NixOS website\npostmarketOS postmarketOS extends Alpine Linux to run on smartphones and other mobile devices. It offers various user interfaces (Phosh, Plasma Mobile, Sxmo, Plasma Desktop, Gnome 3, Kodi, XFCE4, [\u0026hellip;]).\nDownload Download page\nNote that images for the PinePhone Pro are in the \u0026ldquo;community\u0026rdquo; category of devices indicating some features may not work. You can also build your own image using pmbootstrap\nDefault credentials user 147147 Notes See the pine64-pinephonepro page of the postmarketOS wiki for details.\nRhino Linux Rhino Linux is an Ubuntu-based distribution that uses the rolling-release model by tracking the devel branch of repositories. The port is currently maintained by Oren Klopfer (oklopfer).\nTow-Boot is required for installing Rhino Linux. Instructions for installing Tow-Boot to the PinePhone Pro can be found here. After Tow-Boot has been installed to your device, Rhino Linux installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload Rhino Linux Downloads (select Pine64 on the dropdown) Default credentials rhino 1234 Notes Foundational to the distribution is Pacstall, a Debian-based user repository inspired by the AUR. Additionally, RL comes with Unicorn, a custom modified version of XFCE with various modernizations and improvements, including auto-rotation for mobile devices.\nDiscord - Matrix - GitHub - Wiki\nUbuntu Touch A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community. The port is currently maintained by Oren Klopfer (oklopfer).\nTow-Boot is required for installing the latest version of Ubuntu Touch (20.04) to the PinePhone Pro. Instructions for installing Tow-Boot to the PinePhone Pro can be found here.\nInstallation instructions can be found at\nthis UBports post. After Tow-Boot has been installed to your device, Ubuntu Touch installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload UBports 20.04 PinePhone Pro Latest Releases UBports PinePhone Pro Device Info Default credentials Regular user Set during boot phablet (root) 1234 Notes Scroll down to the middle of the GitLab project page, or directly here at the UBports website to see which features work.\nContributions and bug reports can be made at the UBports PinePhone Pro GitLab page. See UBports website for how to donate.\nMulti-distribution image Warning Work in progress; updating the distributions via their respective package managers may break the system. A PinePhone Pro analogue of the PinePhone multi-distro demo image. This image allows the user to switch between multiple Linux distributions without having to swap microSD cards.\nDownload Clone this git repository and follow the instructions in the README to create a bootable microSD card.\nNotes The shell script in the repository above was derived from these instructions.\nVarious DPA Images Multiple versions of unofficial images of various Debian-based distributions by the user DPA. They also contain some of DPA’s own software.\nDownload The latest successful image builds can be found here: https://repo.dpa.li/apt/dpa-image-builder/images/?board=pinephone-pro\nNotes Most of these images are still in development / incomplete and DPA doesn’t have time to test them all, but they can still be useful as a starting point to get distributions running for which no other images have been created yet. DPA made these images because they wanted to run their favorite distribution, Devuan, on their phone.\nThe build scripts can be found in various places: GitLab, my server, GitHub\nIn theory, these build scripts can create images for any Debian-based distribution which supports ARM64 and can be bootstrapped using debootstrap.\nSoftware State Presently the PinePhone Pro Explorer Edition is aimed at Linux developers with an extensive knowledge of embedded systems and/or experience with mobile Linux. It will take time for all the PinePhone Pro’s functionality to reach software parity with the original PinePhone and for mobile operating systems, in more general, to reach a higher degree of maturity.\nBear in mind that the software for these smartphones is still in a very early stage, with most of the software being in alpha or beta state. That\u0026rsquo;s especially also the case for scalability of applications, their availability and practicability, any hardware function implementations and the firmware. The software is provided as is. There is no warranty for the software, not even for merchantability or fitness for a particular purpose.\nThe following table lists the feature functionality status of the unaltered pre-installed factory image of the current shipping batch and as comparison an up-to-date reference image (no responsibility is accepted for the accuracy of this information, the list is provided and updated by the community). If you have any questions regarding the current state of the software or of specific features working, please don\u0026rsquo;t hesitate to ask in the community chat before buying the device:\nDiscord: #pinephone under https://discord.gg/pine64 IRC: #pinephone on irc.pine64.org. Note: please consider Matrix, Discord or Telegram due to the volatile nature of IRC Matrix: https://app.element.io/#/room/#pinephone:matrix.org Telegram: https://t.me/pinephone Note The software is written by the community, any contributions towards the community projects are greatly appreciated! Please see \u0026ldquo;How to Contribute\u0026rdquo; to learn about how to contribute to the software projects and \u0026ldquo;Where to Report Bugs\u0026rdquo; to learn about where to report bugs. Bootloader:\nComponent Status Notes Bootloader Working SPI Working Boot GUI Working Devices bought after July 2022 come with Tow-Boot or rk2aw flashed to the SPI memory Operating System:\nComponent Status Notes Stability WIP Suspend Experimental Audio is often higher pitched after waking up from suspend due to a bug, make sure to update your systemReport; Report Updates WIP The pre-flashed and outdated operating system on the eMMC often gets corrupted after updatingExample; Pacman database lock preventing updatesSolution; Keyring bug (solution is to run \u0026ldquo;pinephonepro-post-install\u0026rdquo; script as root). Modem:\nComponent Status Notes General WIP Alternative firmware; Slow wakeupReport; Some carriers blocking specific TANs in their network; Note: Proprietary firmware Phone WIP The modem connection crashes frequently, which can lead to missed callsReport; Alternative firmware; Slow wakeupReport; bad call audio qualityReport; Audio is often higher pitched after waking up from suspend due to a bugReport; Report SMS Working SMS functionality is expected to work. In certain cases the functionality might be blocked by a clogged modemReport; Some bugs MMS WIP MMS functionality is integrated into the application \u0026ldquo;Spacebar\u0026rdquo;, some bugs remaining and expected Push notifications Not implemented Receiving push notifications while the phone is suspended is not implemented Components:\nComponent Status Notes LCD WIP Hardware issueDetails Touch Working Rear camera WIP Camera work-in-progress with DTS fix[Citation]; userspace still needs to do some catching up; Green image tint[Citation] Front camera WIP Camera work-in-progress with DTS fix[Citation]; userspace still needs to do some catching up; Green image tint[Citation] Camera flash Critical issues Hardware issueDetails; Note: /sys/class/leds/white:flash WiFi Working WiFi is expected to work. The firmware does not support monitor mode and package injection. Note: Proprietary firmware Bluetooth WIP Bluetooth not necessarily working for calls yet due to missing audio routing[Citation]; Bluetooth in general dodgy under Pulseaudio.Info Note: Proprietary firmware GNSS/GPS WIP aGPS to be implemented; long loading times to get a GPS fix[Citation]; No preinstalled application[Citation] Sensors WIP \u0026ldquo;Geo Magnetic Sensor\u0026rdquo; (af8133j): Status unknown (at /sys/bus/i2c/devices/4-001c/iio:device1) \u0026ldquo;Accelerometer / Gyroscope\u0026rdquo; (mpu6500): Working (at /sys/bus/i2c/devices/4-0068/iio:device2) \u0026ldquo;Ambient light / Proximity\u0026rdquo; (stk3311): Working after updating Vibration motor Working Notification LED Working Buttons Working Power buttons and volume buttons are working. Accessory compatibility, spare parts:\nComponent Status Notes Keyboard Add-on WIP The keyboard add-on compatibility is work-in-progress. LoRa Add-on Not implemented No software support implemented Qi Wireless Charging Add-on WIP Wireless charging with the add-on case is expected to work to some degree. Certain software functionality and a driver is currently missing[Citation] Fingerprint Reader Add-on Not implemented No software support implemented Spare parts Partial Some spare parts now available in the store.Store Software notes:\nComponent Status Notes Waydroid Working Waydroid is an Android container used to run Android applications. ¹ Status of the features at the time of the last factory installation without updates\n² Status of the features with an up-to-date reference image\nBootloaders The following section contains notes regarding compatible bootloaders with the PinePhone Pro.\nrk2aw The rk2aw loader program is designed for modern Rockchip SoCs. It modifies the boot ROM bootloader load order from the original and rigid “SPI NOR flash -\u0026gt; eMMC -\u0026gt; SD card” to a more flexible “SD card -\u0026gt; eMMC -\u0026gt; SPI NOR flash”. Additionally, it enables robust A/B bootloader updates in SPI NOR flash, allowing users to choose fallback options via a pre-boot menu. For details see the rk2aw page.\nU-Boot U-Boot is an open-source bootloader commonly used in embedded operating systems and is often pre-installed on device images.\nTow-Boot Tow-Boot is an opinionated distribution of U-Boot and brings numerous advantages over stock U-Boot, such as the possibility to choose from booting the eMMC or microSD card using the volume buttons during boot, as well as a USB Mass Storage mode, where the device can be written to by connecting the device to a computer via USB.\nThe user can flash Tow-Boot to the PinePhone Pro using the instructions on the Tow-Boot website.\nlevinboot The levinboot bootloader is another option for the PinePhone Pro. The project repository can be found here. (Pinephone Pro supporting fork is here.)\nMulti-distribution image This article explains how to install a multiple linux distribution environment on your PinePhone Pro. You can choose to install this environment to the phone’s internal eMMC memory or to a microSD card. These instructions also integrate with the multi-distribution image releases page section.\nVariables During the processes of partitioning the target device, building the image or installing the bootloader, make sure the variables are properly defined. Each time you open a new terminal window, the values of the variables must be re-set.\nInfo BASE is the base directory path on your computer\nDEV is the device name from the lsblk command\nATTR are the attributes of each partition/distribution\nSIZE is the GiB capacity of each partition/distribution\nNameUrl is the Key:Value of distribution name and relative URL download address This guide has been tested with 6 Linux distributions on a 128 GiB microSD card, and following variables:\n$ BASE=ppp-multi-image $ DEV=sdb # i.e. sdb or mmcblk0 $ ATTR=RequiredPartition,LegacyBIOSBootable $ SIZE=11GiB $ declare -A NameUrl $ NameUrl[uboot]=https://xff.cz/kernels/bootloaders-2024.04/ppp.tar.gz $ #NameUrl[uboot]=https://megous.com/dl/tmp/ppp.tar.gz # test build $ NameUrl[arch]=https://github.com/dreemurrs-embedded/Pine64-Arch/releases/download/20240326/archlinux-pinephone-pro-phosh-20240326.img.xz $ NameUrl[manjaro]=https://github.com/manjaro-pinephone/phosh/releases/download/beta37/Manjaro-ARM-phosh-pinephonepro-beta37.img.xz $ NameUrl[mobian]=https://images.mobian.org/pinephonepro/weekly/mobian-rockchip-phosh-20250706.img.xz $ NameUrl[pmos]=https://images.postmarketos.org/bpo/v23.12/pine64-pinephonepro/phosh/20240501-0425/20240501-0425-postmarketOS-v23.12-phosh-22.3-pine64-pinephonepro.img.xz $ NameUrl[sailfish]=https://gitlab.com/sailfishos-porters-ci/dont_be_evil-ci/-/jobs/artifacts/master/download?job=pinephonepro-rootfs $ NameUrl[ut]=https://ci.ubports.com/job/focal-hybris-rootfs-arm64/job/master/lastSuccessfulBuild/artifact/ubuntu-touch-pinephone-pro-img-arm64.raw.xz $ NameUrl[extra]= Install rk2aw Make sure your phone has the rk2aw pre-loader installed to its SPI flash memory. PinePhone Pro models ordered after November 2023 are shipped with rk2aw pre-installed. Otherwise, follow the instructions in this section to install it.\nBoot up the PinePhone Pro’s stock operating system and start a shell session. You can do this either by opening the terminal emulator app, or by enabling the SSH service and logging in from a PC on the same network. Then execute the following commands (from the phone’s shell):\n$ curl -O https://xff.cz/kernels/bootloaders-2024.04/ppp.tar.gz $ tar -xvzf ppp.tar.gz $ cd ppp $ sudo ./spinor-flash-initial-setup.sh Info The multi-boot image can function without rk2aw, but you will need to make sure the correct bootloader is started by your phone’s SoC.\nIf you are installing to a microSD card, then either:\nEnsure that the phone’s SPI flash and eMMC are empty, or Hold down the RE button during boot to force the phone to boot from the microSD card by disabling the SPI flash and the eMMC. If you are installing to the eMMC, make sure the SPI flash is empty.\nFurther instructions can be found on the author’s website.\nExpose the device Connect your PinePhone Pro to a Linux computer, with the stock USB cable. Press power button on. From the graphical menu select eMMC over USB or SD over USB to expose the device to your computer. You can optionally flash microSD directly into your computer’s slot, if available.\nErasing Make sure there are no signatures or partitions left, and overwrite the first sectors with zeroes. You can find the target device under lsblk command.\n$ sudo wipefs /dev/$DEV $ sudo wipefs --all --force /dev/$DEV* $ sudo dd if=/dev/zero of=/dev/$DEV status=progress bs=32768 count=1 Optionally you can zeroes the whole device:\n$ sudo dd if=/dev/zero of=/dev/$DEV status=progress bs=32768 count=$(expr $(lsblk -bno SIZE /dev/$DEV | head -1) \\/ 32768) Partitioning Partition the device for the multiple distributions:\n$ sudo sfdisk /dev/$DEV --wipe always \u0026lt;\u0026lt;EOF label: gpt first-lba: 64 table-length: 10 attrs=RequiredPartition, type=D7B1F817-AA75-2F4F-830D-84818A145370, start=64, size=32704 name=\u0026#34;uboot_raw\u0026#34; $( for name in \u0026#34;${!NameUrl[@]}\u0026#34;; do case ${name} in (uboot|extra) continue ;; esac printf \u0026#39;%s\\n\u0026#39; \u0026#34;attrs=\\\u0026#34;$ATTR\\\u0026#34;, size=$SIZE, name=\\\u0026#34;$BASE-${name}\\\u0026#34;\u0026#34; done | sort ) attrs=\u0026#34;$ATTR\u0026#34;, size=$SIZE, name=\u0026#34;$BASE-ut-data\u0026#34; attrs=\u0026#34;$ATTR\u0026#34;, size=+, name=\u0026#34;extra\u0026#34; EOF Returned string:\nsudo sfdisk /dev/$DEV --wipe always \u0026lt;\u0026lt;EOF label: gpt first-lba: 64 table-length: 10 attrs=RequiredPartition, type=D7B1F817-AA75-2F4F-830D-84818A145370, start=64, size=32704 name=\u0026#34;uboot_raw\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-arch\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-manjaro\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-mobian\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-pmos\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-sailfish\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-ut\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=11GiB, name=\u0026#34;ppp-multi-image-ut-data\u0026#34; attrs=\u0026#34;RequiredPartition,LegacyBIOSBootable\u0026#34;, size=+, name=\u0026#34;extra\u0026#34; EOF Expected results:\nChecking that no-one is using this disk right now ... OK Disk /dev/sd[...]: 118.16 GiB, 126877696000 bytes, 247808000 sectors Disk model: microSD card Reader Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes \u0026gt;\u0026gt;\u0026gt; Script header accepted. New situation: Disklabel type: gpt Disk identifier: A012E9D0-B4EB-4677-926F-D93AE4C696FA Device Start End Sectors Size Type sdb1 64 32767 32704 16M unknown sdb2 32768 23101439 23068672 11G Linux fs sdb3 23101440 46170111 23068672 11G Linux fs sdb4 46170112 69238783 23068672 11G Linux fs sdb5 69238784 92307455 23068672 11G Linux fs sdb6 92307456 115376127 23068672 11G Linux fs sdb7 115376128 138444799 23068672 11G Linux fs sdb8 138444800 161513471 23068672 11G Linux fs sdb9 161513472 247805951 86292480 41.1G Linux fs The partition table has been altered. Calling ioctl() to re-read partition table. Syncing disks. Install U-Boot In order to display the graphical distribution selector when the phone boots, we need to install a custom version of the U-Boot bootloader.\nFirst, use the following commands to download the required U-Boot image. Note that we are downloading the same ppp.tar.gz archive as we did in the rk2aw section; if you already have a copy of this archive on your computer, you may skip the download and simply extract its contents into ~/$BASE/downloads/.\n$ NAME=uboot $ mkdir -p ~/$BASE/downloads \u0026amp;\u0026amp; cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} $ tar -xvzf $(basename \u0026#34;${NameUrl[$NAME]}\u0026#34;) Then, use the following command to install the U-Boot image to the correct location on the microSD/eMMC:\n$ sudo dd if=ppp/foss/u-boot-rockchip.bin of=/dev/$DEV bs=512 seek=64 status=progress conv=fsync Info If you are interested in building this U-Boot image yourself, you can download the source code from xff.cz. However, you will still need a copy of ppp.tar.gz since it contains the U-Boot build configuration file (ppp/foss/.config).\nCopy this file to the root of your U-Boot source directory, keeping the name .config. You can then use make to initiate the build process.\nBuild the partitions Make sure you download an updated file from relases page. You will need to build each partition one by one, setting properly the variables and using specific commands according the selected distribution. When you reach the building repeat advice, come back to this point and build the next distribution.\nArch, Manjaro, Mobian, postmarketOS For these distributions, download and decompress the image:\n$ NAME=arch # set distribution name, i.e. arch, manjaro, mobian, pmos $ mkdir -p ~/$BASE/downloads \u0026amp;\u0026amp; cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} $ xz -v -d -k $(basename \u0026#34;${NameUrl[$NAME]}\u0026#34;) $ mv $(basename -as .xz \u0026#34;${NameUrl[$NAME]}\u0026#34;) $NAME.img Mount the image:\n$ cd ~/$BASE/downloads $ sudo losetup -P /dev/loop0 $NAME.img $ sudo mkdir -p /mnt/$NAME/boot /mnt/$NAME/root /mnt/$NAME/dev $ sudo mount /dev/loop0p1 /mnt/$NAME/boot/ $ sudo mount /dev/loop0p2 /mnt/$NAME/root/ Copy root and boot contents:\n$ sudo dd if=/dev/loop0p2 of=/dev/disk/by-partlabel/$BASE-$NAME bs=1M status=progress conv=fsync $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev/ $ sudo scp -r /mnt/$NAME/boot/* /mnt/$NAME/dev/boot SailfishOS This distribution needs different commands. Download and decompress the image:\n$ NAME=sailfish $ mkdir -p ~/$BASE/downloads \u0026amp;\u0026amp; cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} -O artifacts.zip $ unzip artifacts.zip $ mv pinephonepro/*/*.tar.bz2 sailfish.tar.bz2 $ mkdir -p ~/$BASE/downloads/sailfishos $ sudo tar -xvf sailfish.tar.bz2 -C sailfishos/ \u0026gt; /dev/null Format the partition and copy the extracted files directly onto the device:\n$ sudo mkfs.ext4 -F /dev/disk/by-partlabel/$BASE-$NAME $ sudo mkdir -p /mnt/$NAME/dev $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev $ sudo rsync -avz --progress ~/$BASE/downloads/sailfishos/ /mnt/$NAME/dev $ sudo chmod a=rwx /mnt/$NAME/dev/boot/* Ubuntu Touch For this distribution, download and decompress the image:\n$ NAME=ut $ mkdir -p ~/$BASE/downloads \u0026amp;\u0026amp; cd ~/$BASE/downloads $ wget ${NameUrl[$NAME]} $ xz -v -d -k $(basename \u0026#34;${NameUrl[$NAME]}\u0026#34;) $ mv $(basename -as .xz \u0026#34;${NameUrl[$NAME]}\u0026#34;) $NAME.img Mount the image:\n$ cd ~/$BASE/downloads $ sudo losetup -P /dev/loop0 $NAME.img $ sudo mkdir -p /mnt/$NAME/boot /mnt/$NAME/system /mnt/$NAME/userdata /mnt/$NAME/dev $ sudo mount /dev/loop0p2 /mnt/$NAME/boot/ $ sudo mount /dev/loop0p3 /mnt/$NAME/system/ $ #sudo mount /dev/loop0p4 /mnt/$NAME/userdata/ Create the userdata partition and copy system and boot contents:\n$ sudo mkfs.ext4 -F /dev/disk/by-partlabel/$BASE-$NAME-data $ sudo e2label /dev/disk/by-partlabel/$BASE-$NAME-data $NAME-data $ sudo dd if=/dev/loop0p3 of=/dev/disk/by-partlabel/$BASE-$NAME bs=1M status=progress conv=fsync $ sudo mount /dev/disk/by-partlabel/$BASE-$NAME /mnt/$NAME/dev/ $ sudo scp -r /mnt/$NAME/boot/* /mnt/$NAME/dev/boot All distributions If present, you can optionally backup boot.scr, extlinux.conf and fstab files.\n$ sudo mkdir -p /mnt/$NAME/dev/boot/extlinux $ [ ! -f /mnt/$NAME/dev/boot/extlinux/extlinux.conf ] || sudo mv /mnt/$NAME/dev/boot/extlinux/extlinux.conf /mnt/$NAME/dev/boot/extlinux/extlinux.conf.bk $ [ ! -f /mnt/$NAME/dev/boot/boot.scr ] || sudo mv /mnt/$NAME/dev/boot/boot.scr /mnt/$NAME/dev/boot/boot.scr.bk $ [ ! -f /mnt/$NAME/dev/boot/boot.pinephonepro.scr ] || sudo mv /mnt/$NAME/dev/boot/boot.pinephonepro.scr /mnt/$NAME/dev/boot/boot.pinephonepro.scr.bk $ sudo mv /mnt/$NAME/dev/etc/fstab /mnt/$NAME/dev/etc/fstab.bk Then write the new /boot/extlinux/extlinux.conf file, making sure you remove # comment for the selected distributions:\n$ sudo tee /mnt/$NAME/dev/boot/extlinux/extlinux.conf \u0026lt;\u0026lt;EOF ## /boot/extlinux/extlinux.conf menu title Pinephone Pro Boot Menu ## uncomment next line for timed default-selected distro #default $NAME timeout 50 label $NAME menu label $NAME ## uncomment next 3 lines for ARCH #fdt /boot/dtbs/rockchip/rk3399-pinephone-pro.dtb #initrd /boot/initramfs-linux.img #kernel /boot/Image.gz ## uncomment next 3 lines for MANJARO #fdt /boot/dtbs/rockchip/rk3399-pinephone-pro.dtb #initrd /boot/initramfs-linux.img #kernel /boot/Image ## uncomment next 3 lines for MOBIAN #fdtdir /boot/dtbs/6.12-rockchip/ #initrd /boot/initrd.img-6.12-rockchip #linux /boot/vmlinuz-6.12-rockchip ## uncomment next 3 lines for PMOS #fdtdir /boot/dtbs-pine64-pinephonepro/ #initrd /boot/initramfs-extra #linux /boot/vmlinuz ## uncomment next 2 lines for SAILFISH #fdt /boot/rockchip/rk3399-pinephone-pro.dtb #kernel /boot/Image ## uncomment next 3 lines for UT #fdtdir /boot/dtb-6.5.0-okpine-ut/ #initrd /boot/initrd.img-6.5.0-okpine-ut #linux /boot/vmlinuz-6.5.0-okpine-ut ## uncomment next line for all distros, excluding UT ## since there is a bug related to wifi from wpa_supplicant in Archlinux add \u0026#39;brcmfmac.feature_disable=0x82000\u0026#39; just before \u0026#39;rw rootwait\u0026#39; #append root=PARTLABEL=$BASE-$NAME console=ttyS2,115200 console=tty0 loglevel=7 rw rootwait ## uncomment next line for UT only #append root=PARTLABEL=$BASE-$NAME console=ttyS2,115200 console=tty loglevel=7 systempart=/dev/disk/by-partlabel/$BASE-$NAME datapart=/dev/disk/by-partlabel/$BASE-$NAME-data security=apparmor rw rootwait EOF Then write the new /etc/fstab file, making sure you remove # comment for selected distribution:\n$ sudo tee /mnt/$NAME/dev/etc/fstab \u0026lt;\u0026lt;EOF ## \u0026lt;file system\u0026gt; \u0026lt;dir\u0026gt; \u0026lt;type\u0026gt; \u0026lt;options\u0026gt; \u0026lt;dump\u0026gt; \u0026lt;pass\u0026gt; ## uncomment next line for ARCH #PARTLABEL=$NAME / ext4 rw,relatime 0 1 ## uncomment next line for MANJARO #PARTLABEL=$NAME / ext4 defaults 0 1 ## uncomment next line for MOBIAN #PARTLABEL=$NAME / ext4 defaults,x-systemd.growfs 0 1 ## uncomment next line for PMOS #PARTLABEL=$NAME / ext4 defaults 0 0 ## uncomment next 7 lines for SAILFISH #PARTLABEL=$NAME / ext4 rw,noatime 0 1 #devtmpfs /dev devtmpfs nosuid 0 0 #devpts /dev/pts devpts gid=5,mode=620 0 0 #tmpfs /dev/shm tmpfs noexec,nosuid,nodev 0 0 #proc /proc proc defaults 0 0 #sysfs /sys sysfs defaults 0 0 #tmpfs /tmp tmpfs nosuid,nodev 0 0 ## uncomment next 3 lines for UT #PARTLABEL=$NAME / ext4 defaults 0 1 #PARTLABEL=$NAME /boot ext4 defaults 0 2 #PARTLABEL=$NAME-data /userdata ext4 defaults 0 2 EOF Close any mounted directory window.\nUnmount, detach and resize To unmount and deatch all building images, run:\n$ sudo umount /mnt/$NAME/* $ sudo rm -r /mnt/$NAME $ sudo losetup -D On the first boot, if it doesn’t happen automatically, you can manually resize each image to fill the entire partition using GParted GUI software or using the CLI. Please note that SailfishOS doesn’t need any resizing.\n$ sudo e2label /dev/disk/by-partlabel/$BASE-$NAME $NAME $ sudo e2fsck -f /dev/disk/by-partlabel/$BASE-$NAME $ sudo resize2fs /dev/disk/by-partlabel/$BASE-$NAME Important Repeat the building process for the next distribution, adapting needed variables. Follow-up notes Any time a distribution update rebuilds the initramfs it is necessary to delete /boot/boot.scr again to keep the rk2aw menu clean.\nIn case you want to reinstall only one distribution, the easy way is to delete and recreate the selected partition using the GParted GUI.\nIf the device doesn’t start, connect a compatible serial cable to the headphone jack and a computer, switch off microswitch 6 and start a serial console to investigate further. Find out the corresponding USB device using ls /dev/ttyUSB* and then connect to it with for example minicom using the command minicom -b 1500000 -D /dev/ttyUSB[...], where [\u0026hellip;] is the number of the USB device.\nTo find the exact LABEL, UUID, PARTLABEL and PARTUUID names, open a terminal window on the phone and use the command blkid.\nAppendix Build the postmarketOS image\nYou can optionally use pmbootstrap to generate the distribution image on your Linux computer, instead of downloading a pre-made image. Make sure you install pmbootstrap before building the image.\nStart creating 2 GB empty image file, format and mount it.\n$ sudo su # dd if=/dev/zero of=postmarketos.img bs=1 count=0 seek=2G status=progress \u0026amp;\u0026amp; sync # mkfs.ext4 postmarketos.img # losetup -P /dev/loop0 postmarketos.img # exit Then build the image using pmbootstrap\n$ pmbootstrap init $ pmbootstrap status $ pmbootstrap pull $ pmbootstrap install --sdcard=/dev/[LOOP-DEVICE] $ pmbootstrap shutdown Troubleshooting If the PinePhone Pro is not booting (either booting incompletely into a boot splash or tty or if the PinePhone Pro is showing no signs of life) this will typically have the following two reasons:\nThe battery is fully drained If the battery is drained then the board can reset during boot causing a boot loop because of undervoltage condition. It can happen on all stages of the boot including U-Boot bootloader, display initialization and USB (re-)configuration. In that case it is not possible to charge the phone. The battery can be charged by interrupting the boot loop by booting the PinePhone Pro into Maskrom mode or by charging the battery externally. It is possible to follow these instructions without a computer by using a wall charger, however it would not be possible to determine if Maskrom mode was started successfully. To boot the PinePhone Pro into Maskrom mode:\nRemove any microSD card from the phone and keep it removed for the below procedure Remove the battery, any USB cable and any serial cable Reinsert the battery Hold the RE button underneath the back cover of your Explorer Edition (or short the bypass contact points on the Developer Edition) Note Confirm that the label of the button says RE and not RESET! If the button label says RESET instead you probably have a regular PinePhone and you’re reading the wrong page. Connect the phone to an USB port of a computer, while still holding the button for some time Confirm if the phone was booted in Maskrom mode: On Linux check if the Maskrom mode appears as device in the output of the terminal command lsusb on the computer, the expected VID:PID of the device is 2207:330c. On Windows this can be checked using the Device Manager and checking the VID \u0026ldquo;2207\u0026rdquo; and PID \u0026ldquo;330c\u0026rdquo; of an Unknown device appears. On macOS this can be checked in /Applications/Utilities/System Information.app under USB and by checking if the VID \u0026ldquo;2207\u0026rdquo; and PID \u0026ldquo;330c\u0026rdquo; is appearing for a Composite Device. Let the phone charge for multiple hours Note If the device doesn’t appear under lsusb please try again with a different known good USB-C cable and make sure that there is no microSD card in the phone inserted. The device should now be able to boot from the boot medium again. If that is not the case the installation got corrupted, as explained below.\nThe installation is corrupted The PinePhone Pro won’t be able to boot if the installation on the SPI flash, the eMMC or the microSD card got corrupted. To boot a working operating system:\nPrepare a microSD card as explained in the section Flashing to microSD card Remove any USB-C cable or device or add-on case from the PinePhone Pro Make sure the device is powered off by shortly removing the battery for a second Insert the microSD card into the top slot of the PinePhone Pro. Make sure the microSD card is inserted all the way and that the notch of the right side of the microSD card is not visible anymore. Power on the device (bypassing the SPI and eMMC might be required, see Boot order) The device should now boot from the microSD card. If the phone does not boot from the microSD card the microSD card was flashed with an incompatible image or the battery got drained as explained above.\nModem The PinePhone Pro uses Quectel EG25-G as modem. AT commands are used to communicate with the modem.\nAT commands A list of documented AT commands can be found for example in this AT commands documentation from Quectel. Further undocumented AT commands found by the developer megi, who reverse-engineered parts of the modem and its firmware, can be found on megi’s website here.\nTo send AT commands to the modem under Linux, minicom or the often-preinstalled atinout utility can be used.\natinout example:\necho \u0026quot;AT+\u0026lt;command here\u0026gt;\u0026quot; | sudo atinout - /dev/ttyUSB2 - minicom example:\nminicom -D /dev/ttyUSB2 VoLTE The PinePhone and PinePhone Pro modem supports VoLTE and comes with a few VoLTE profiles preloaded. Most operating systems try to set the correct profile automatically.\nTo list the available VoLTE profiles:\nAT+QMBNCFG=\u0026#34;list\u0026#34; +QMBNCFG: \u0026#34;List\u0026#34;,0,1,1,\u0026#34;ROW_Generic_3GPP\u0026#34;,0x0501081F,201901141 +QMBNCFG: \u0026#34;List\u0026#34;,1,0,0,\u0026#34;VoLTE-ATT\u0026#34;,0x0501033C,201909271 +QMBNCFG: \u0026#34;List\u0026#34;,2,0,0,\u0026#34;hVoLTE-Verizon\u0026#34;,0x05010141,201911251 +QMBNCFG: \u0026#34;List\u0026#34;,3,0,0,\u0026#34;Sprint-VoLTE\u0026#34;,0x05010205,201908141 +QMBNCFG: \u0026#34;List\u0026#34;,4,0,0,\u0026#34;Commercial-TMO_VoLTE\u0026#34;,0x05010505,201811231 +QMBNCFG: \u0026#34;List\u0026#34;,5,0,0,\u0026#34;Telus-Commercial_VoLTE\u0026#34;,0x05800C43,201912031 +QMBNCFG: \u0026#34;List\u0026#34;,6,0,0,\u0026#34;Commercial-SBM\u0026#34;,0x05011C18,201904021 +QMBNCFG: \u0026#34;List\u0026#34;,7,0,0,\u0026#34;Commercial-DT\u0026#34;,0x05011F1C,201905311 +QMBNCFG: \u0026#34;List\u0026#34;,8,0,0,\u0026#34;Reliance_OpnMkt\u0026#34;,0x05011B38,201910161 +QMBNCFG: \u0026#34;List\u0026#34;,9,0,0,\u0026#34;TF_Germany_VoLTE\u0026#34;,0x05010C1B,201909201 +QMBNCFG: \u0026#34;List\u0026#34;,10,0,0,\u0026#34;TF_Spain_VoLTE\u0026#34;,0x05010CFA,201909261 +QMBNCFG: \u0026#34;List\u0026#34;,11,0,0,\u0026#34;Volte_OpenMkt-Commercial-CMCC\u0026#34;,0x05012071,201904281 +QMBNCFG: \u0026#34;List\u0026#34;,12,0,0,\u0026#34;OpenMkt-Commercial-CT\u0026#34;,0x05011322,201911081 +QMBNCFG: \u0026#34;List\u0026#34;,13,0,0,\u0026#34;OpenMkt-Commercial-CU\u0026#34;,0x05011505,201807052 To select a profile manually, select the best fitting one or a generic one if none fits:\nAT+QMBNCFG=\u0026quot;select\u0026quot;,\u0026quot;ROW_Generic_3GPP\u0026quot; Then enable Voice over LTE using:\nAT+QCFG=\u0026quot;ims\u0026quot;,1 And reboot the modem to apply the settings:\nAT+CFUN=1,1 To check the status of VoLTE during a call, the AT command CLCC can be used:\nAT+CLCC +CLCC: 1,1,0,1,0,\u0026#34;\u0026#34;,128 +CLCC: 2,1,0,1,0,\u0026#34;\u0026#34;,128 In the fourth item of the list, \u0026ldquo;0\u0026rdquo; means voice and and \u0026ldquo;1\u0026rdquo; means data. If both rows have \u0026ldquo;1\u0026rdquo; then the voice call is being carried over VoLTE.\nAPN settings The APN setting is only required for a public Internet connection (\u0026ldquo;data\u0026rdquo;) on the phone. For tested APN settings and how to apply them see APN settings.\nCarrier support The page Carrier support contains information about the frequency support of different carriers and hints on setting up cellular network connectivity.\nDocuments Detailed information about the modem can be found on the page of the developer megi, including reverse-engineered parts of the firmware and its functions. There is also a document about using the modem from January 18th 2020 by megi here. A script at the end of the document showcases a way to power off the modem before powering off the phone, which is integrated into most of the available operating systems.\nFirmware update There is a (nearly) free custom firmware and the stock firmware available for the PinePhone Pro. Both can be updated to a newer version with new features and bug fixes.\nCustom firmware There is a (nearly) free custom firmware for the PinePhone and PinePhone Pro modem by the developer biktorgj, which can be found here.\nThe custom firmware has various advantages (and zero disadvantages) over the stock firmware, including:\nSignal tracking support with checks against the OpenCelliD database Persistent storage is optional and unexpected shutdowns don’t mess up the modem A lower energy consumption due to the lower minimum clock frequency And many more, see Features not available on stock firmware The custom firmware can be flashed using fwupd or a flashing script.\nStock firmware Tip The following instructions are directed towards professional users. It is highly recommend to make sure the update process is not interrupted to prevent the modem from bricking. The stock modem firmware can be updated to a newer version if it is outdated. The firmware version can be checked using the following AT command (at the example of atinout, alternatively minicom can be used to communicate with the modem too):\necho \u0026#39;AT+QGMR\u0026#39; | sudo atinout - /dev/ttyUSB2 - Pre-update checklist:\nPlease make sure all requirements of the checklist are fulfilled. If the update process is interrupted it will lead to a corrupted firmware of the modem, causing it to brick. Recovering a bricked modem is exponentially more complicated and requires the user to boot a special mode by physically bridging test points on the modem.\nThe battery needs to be charged sufficiently The phone needs to be plugged into a charger Deep sleep is recommended to be disabled as it can interrupt the update process It is recommended to close all other running applications Use common sense while doing the update, don’t do the update while being impaired in any way To get the latest firmware, clone the repository of user Biktorgj on the phone:\ngit clone https://github.com/Biktorgj/quectel_eg25_recovery After cloning the directory, open it with cd:\ncd quectel_eg25_recovery Then run qfirehose, which starts the flashing process:\nsudo ./qfirehose -f ./ The modem will automatically reboot after the update process is done. The boot process takes around 30 to 60 seconds. After that it is highly recommended to reboot the device.\nFirmware modifications See PineModems for more information regarding modem bootloader unlocking, building a custom modem firmware and modem recovery.\nGPS / GNSS The GPS engine in the modem supports mutli-GNSS reception from GPS, GLONASS, BeiDou, Galileo and QZSS independent of a cellular connection. The operation of the GNSS subsystem can be controlled via a separate set of AT commands, or via qmi. The A-GPS data upload uses the file management AT commands, which also have their own manual. These are linked in the documentation section.\nAs with most smartphones, the PinePhone Pro has a small antenna and has difficulty getting a first fix without assistance data, a cold start can take 15 minutes under good conditions. The eg25-manager is configured to upload A-GPS data by default (see here).\nBasic testing of GNSS reception can be done by using the AT command interface (/dev/ttyUSB2) from a terminal program like minicom and the data output interface (/dev/ttyUSB1) to feed NMEA data into gpsmon or some other program that can parse standard NMEA sentences.\ngpsmon decoding GPS data from /dev/ttyUSB1\nTo check if GNSS data output is enabled, you can\ncat /dev/ttyUSB1 this should display a stream of NMEA sentences\n$GPVTG,,T,,M,,N,,K,N*2C $GPGSA,A,1,,,,,,,,,,,,,,,,*32 $GPGGA,,,,,,0,,,,,,,,*66 Further details can be found under Sensors and navigation.\nVoice mail The operating systems of the PinePhone Pro may not have support for accessing your voicemail by holding down the 1-key. Carriers might support accessing the voice mail via an external number however.\nPrivacy switches Picture of the privacy switches\nThe PinePhone features six switches that can be used to configure its hardware. They are numbered 1-6, with switch 1 located nearest to the modem. Their \u0026ldquo;on\u0026rdquo; position is toward the top of the phone.\nWarning It is not recommended to change the PinePhone’s privacy switch positions while the device is powered on. In particular, toggling the modem privacy switch while the phone is running can lead to modem firmware corruption. Additionally, the phone is not notified of the loss of power to the disabled part, so it may continue to assume the component is operating normally; if you switch the dip switches back on during operation, it may not automatically regain functionality. Number Name Description 1 Modem \u0026ldquo;On\u0026rdquo; enables 2G/3G/4G communication and GNSS hardware, \u0026ldquo;off\u0026rdquo; disables it. 2 WiFi / Bluetooth \u0026ldquo;On\u0026rdquo; enables WiFi and Bluetooth communication hardware, \u0026ldquo;off\u0026rdquo; disables it. 3 Microphone \u0026ldquo;On\u0026rdquo; enables audio input from on-board microphones (not 3.5 mm jack), \u0026ldquo;off\u0026rdquo; disables it. 4 Rear camera \u0026ldquo;On\u0026rdquo; enables the rear camera, \u0026ldquo;off\u0026rdquo; disables it. 5 Front camera \u0026ldquo;On\u0026rdquo; enables the front camera, \u0026ldquo;off\u0026rdquo; disables it. 6 Headphone \u0026ldquo;On\u0026rdquo; enables audio input and output via the 3.5 mm audio jack, \u0026ldquo;off\u0026rdquo; switches the jack to hardware UART¹ mode. ¹ Note: The baud rate may be 1500000 instead of 115200.\nHardware Components Component Model Touchscreen Goodix GT917S LCD Himax HX8394 compatible Rear camera IMX258 Front camera OV8858 Camera flash AW3641EDNR WiFi + Bluetooth AzureWave AW-CM256SM Modem Quectel EG25-G GNSS/GPS Quectel EG25-G 3 Axis Magnetometer AF8133J Geo Magnetic Sensor Voltafield AF8133J Ambient light / Proximity STK3311-A Accelerometer / Gyroscope TDK MPU-6500 Vibration motor Notification LED LED0603RGB Audio Codec ALC5616 and ALC5640 Volume buttons Buttons connected to the KEYADC Power button Battery fuel gauge RK818 Replacement earpieces The earpiece (or earpiece speaker) refers to the small speaker at the top of the PinePhone and PinePhone Pro.\nThis part is not available to purchase from the PINE64 Store. However, it is possible to buy a replacement earpiece for another device, and install it in a PinePhone or PinePhone Pro. This documents earpieces that have been tested by the community, and verified to work.\nNote that the earpiece dimensions for both the PinePhone and PinePhone Pro are 12x6x2 mm. When looking into earpieces not found in this list, aim for these dimensions.\nEarpiece PinePhone PinePhone Pro Where to Buy LG K8 2017 M200N Kind of ¹ Broken Replace Base Nokia 5 Works Works Replace Base Nokia 7 Works ² Works ² Replace Base Nokia X5 Works Works Replace Base OnePlus One Works Works iFixit, Replace Base OnePlus X Works Works Replace Base PinePhone Works Works Xiaomi Mi A1 Works Works Replace Base Xiaomi Redmi Note 4 Works Works Replace Base Notes:\n¹ The earpiece is too thin, it can work with padding to keep the contacts together.\n² Audio playback is very low quality.\nIncompatible earpieces The following devices are known to have replacement earpieces with dimensions too large to fit inside the PinePhone or PinePhone Pro.\nBlackberry Classic Q20 HTC Desire 500 HTC M10 Huawei Honor 7A Huawei Mate 10 Pro Huawei Y7 Prime 2018 OnePlus 2 Oppo Reno 5 4G Sony Xperia X Compact Sony Xperia XA1 Ultra Sony Xperia XP X Performance Sony Xperia XZ Camera The PinePhone Pro has two cameras, Sony IMX258 with 13MP as rear camera and OmniVision OV8858 with 8MP as front-facing camera.\nExample picture taken on the PinePhone’s (not Pro) rear camera by Martijn Braam using his app Megapixels.\nAs mentioned in Software State, the cameras are work-in-progress, including a required DTS fix, userspace still needs to do some catching up and there is a green image tint. This article explains how to fix camera sofware on your PinePhone Pro. The work is on progress and will be available soon for different distributions. Make sure your PinePhone Pro is connected to the web to download needed software.\nArch Linux ARM + Phosh Installation Open terminal and update your system:\n$ sudo pacman -Syyuu Remove original Megapixels app:\n$ sudo pacman -Rns megapixels Install camera dependencies:\n$ sudo pacman -Syu gst-plugin-libcamera libcamera-tools pipewire-libcamera Install flatpak software manager:\n$ sudo pacman -S flatpak Install Megapixels2 app:\n$ flatpak install https://flatpak.brixit.nl/megapixels2.flatpakref --user You will be prompted to some options\nShould the remote be kept for future installations? [Y/n]: n Configure this as new remote \u0026lsquo;flathub\u0026rsquo; [Y/n]: y Required runtime for me.gapixels.Megapixels/aarch64/master (runtime/org.gnome.Platform/aarch64/47) found in remote flathub. Do you want to install it? [Y/n]: y To launch camera app you can both click on Megapixels icon on your desktop or enter into terminal following command\n$ flatpak run me.gapixels.Megapixels In case you need to reinstall Megapixels2\n$ flatpak list $ flatpak uninstall --delete-data me.gapixels.Megapixels $ flatpak uninstall --unused $ flatpak repair Green Tint Issue To fix the green tint issue during post processing of your pictures, add \u0026ldquo;-a\u0026rdquo; and \u0026ldquo;-f\u0026rdquo; to dcraw line (about #82) into postprocess.sh file\nFirst look for postprocess.sh file:\n$ cd ../.. $ sudo find / -type f -name postprocess.sh Goto the postprocess.sh directory you found using the above command. Here the example /var/lib/flatpak/app/me.gapixels.Megapixels/aarch64/master/[\u0026hellip;]/files/share/megapixels/postprocess.sh is used:\n$ cd /var/lib/flatpak/app/me.gapixels.Megapixels/aarch64/master/[...]/files/share/megapixels Backup original file and add \u0026ldquo;-a\u0026rdquo; and \u0026ldquo;-f\u0026rdquo; to dcraw line, using replace command:\n$ sudo cp postprocess.sh postprocess.sh.bk $ sudo sed -i \u0026#39;s/$DCRAW +M -H 4 -o 1 -q 3 -T \u0026#34;$@\u0026#34; \u0026#34;$MAIN_PICTURE.dng\u0026#34;/$DCRAW +M -H 4 -o 1 -q 3 -T -a -f \u0026#34;$@\u0026#34; \u0026#34;$MAIN_PICTURE.dng\u0026#34;/\u0026#39; postprocess.sh If you want to patch automatically the file, just copy and paste following code into CLI:\n$ BASE=\u0026#34;/home/alarm/.local/share/flatpak/app/me.gapixels.Megapixels/aarch64/master\u0026#34; $ find \u0026#34;$BASE\u0026#34; -type f -path \u0026#34;*/files/share/megapixels/postprocess.sh\u0026#34; | while read -r f; do $ [ -z \u0026#34;$f\u0026#34; ] \u0026amp;\u0026amp; continue $ cp \u0026#34;$f\u0026#34; \u0026#34;$f.bk\u0026#34; $ if grep -Fq \u0026#39;$DCRAW +M -H 4 -o 1 -q 3 -T -a -f \u0026#34;$@\u0026#34; \u0026#34;$MAIN_PICTURE.dng\u0026#34;\u0026#39; \u0026#34;$f\u0026#34;; then $ echo \u0026#34;string already patched\u0026#34; $ elif grep -Fq \u0026#39;$DCRAW +M -H 4 -o 1 -q 3 -T \u0026#34;$@\u0026#34; \u0026#34;$MAIN_PICTURE.dng\u0026#34;\u0026#39; \u0026#34;$f\u0026#34;; then $ sed -i \u0026#39;s#\\$DCRAW +M -H 4 -o 1 -q 3 -T \u0026#34;\\$@\u0026#34; \u0026#34;\\$MAIN_PICTURE\\.dng\u0026#34;#\\$DCRAW +M -H 4 -o 1 -q 3 -T -a -f \u0026#34;\\$@\u0026#34; \u0026#34;\\$MAIN_PICTURE.dng\u0026#34;#g\u0026#39; \u0026#34;$f\u0026#34; $ echo \u0026#34;patch done\u0026#34; $ else $ echo \u0026#34;string not found\u0026#34; $ fi $ done Further details regarding the camera and the Megapixels camera app can be found on Martijn’s blog.\nFactory tests Battery charging\nHardware checking\nBattery charging Note Please note that this Android build solely for PinePhone Pro hardware checking purpose and solely used by support team. This is NOT a general release build. Download:\nDirect download from pine64.org (722MB, for 8GB microSD cards or bigger, MD5 of the GZip file 214e063c8205c1a98d44b2015a21bb5d) Instructions:\nDownload the build, extract the image and dd it to a 8 GB or larger microSD card, takes out the PinePhone Pro Explorer Edition then insert it into microSD slot (upper slot). Insert battery, press RE button (bypass SPI and eMMC boot) while plug in USB-C power. After 3 seconds release RE button. When power up, below battery icon screen show up and battery will start charging. The battery icon display for few seconds and then LCD panel turn off while charging. To check charging status, just quick press power button (about 0.5 second) and battery icon will display progress. Hardware checking Note Please note that this Android build solely for PinePhone Pro hardware checking purpose and solely used by the support team. This is not a general release build. Download:\nDirect download from pine64.org (722MB, for 8GB microSD cards or bigger, MD5 of the GZip file 214e063c8205c1a98d44b2015a21bb5d) Instructions:\nDownload the build, extract the image and dd it to a 8 GB or larger microSD card, take out the PinePhone Pro Explorer Edition, then insert it into microSD slot (upper slot). Insert battery, press the RE button (bypass SPI and eMMC boot) underneath the back cover while plugging in the USB-C power. After 3 seconds release the RE button. When powering up, a battery icon screen will show up. Press the power key for two seconds, then the Rockchip logo screen shows up. Wait for the home screen, double tap on the test app icon (mark red circuit) and this will bring up the factory test screen. Please note that the SD test is disabled due in this is SD boot build. After running a particular test function, please snapshot the test result and pass it back to support team Notes:\nPlease insert a functional SIM card when performing the SIM test When perform GPS test, the first result may fail and please ignore this false message. For light sensing test, please have a light shine to the PinePhone Pro when performing the test. Revisions Developer Edition Explorer Edition Developer Edition The Developer Edition was the first edition of the PinePhone Pro, shipped to developers in December 2021. The aim of the the Developer Edition was to give development community access to the hardware prior to end-users, boost development efforts and allow for porting of existing mobile Linux operating systems to the new hardware. It featured a factory test installation of AOSP as pre-installed operating system and was shipped with the packaging and manual of the succeeding Explorer Edition.\nGetting started This documentation page is strictly aimed at developers receiving their PinePhone Pro dev units. Please note that the following instructions do not apply to Explorer Edition or other future editions of the PinePhone Pro - everything below is only pertinent to the dev phones.\nConsider this a crash course rather than a comprehensive overview; you are also welcome to participate in documenting the process (and everything else related to the PinePhone Pro) on the documentation.\nGetting the hardware ready After unpacking the PinePhone Pro from its box, detach the back cover (looking at the back of the phone, there is a fingernail notch on the left leading edge) and remove the plastic tab between the battery and mainboard. You can also flip the headphone jack privacy switch at this point - this enables UART output via the headphone jack. Serial console works the same way as on the original PinePhone.\nFactory hardware test image The PinePhone Pro developer edition ships with a BSP AOSP factory image flashed to the eMMC. This image includes a number of factory applications meant to validate operation of the sensors, the modem, cameras, LCD \u0026amp; touch panel, etc. You’ll have to nuke the AOSP build to run a Linux installation on the PinePhone Pro. Booting from SD with the AOSP factory build present on eMMC is not possible due to the SoCs native boot order.\nChanging the language of factory AOSP This is optional and only if you want to test out the AOSP test image.\nSwipe up from the bottom of the screen. Tap on the Gear icon. Tap on the 2nd from last option that has an i inside of a circle icon. Tap on the first choice with the globe icon. Tap on the first choice with the language icon. Tap on the second choice to add another language. Tap on your language in the list. If there is a secondary choice required, tap on the preferred country. Tap the four horizontal bars icon to the right of the new second language and drag to the top of the list to set the new language as the default. Backing up the factory AOSP It may be a good idea to create an image of the eMMC in case you want to flash it back. Free up at least 117GB of disk space. Install adb.\nadb root \u0026amp;\u0026amp; adb pull /dev/block/mmcblk1 ~/pinephonepro-factory-AOSP.img\nNuking the factory AOSP installation To be able to boot from the microSD card easily it is recommend to wipe the bootloader from the pre-installed operating system on the eMMC due to the eMMC being higher in the boot priority than the microSD card.\nMethod 1: Via ADB In the factory test image, navigate to setting (gear icon) \u0026gt; at the very bottom of the settings list you will find a phone icon with rk3999mid written underneath it \u0026gt; tap the last (bottom) setting 7 times in quick succession. Following this, you may need to do the following: open the Settings application and enable USB debugging in Settings \u0026gt; System \u0026gt; Developer Options \u0026gt; USB debugging. Then connect the PinePhone Pro to your PC with the supplied USB-C cable.\nPlease note: It is recommended to charge the device to at least 50% before proceeding with wiping the eMMC.\nTip Note: You may have gotten a Chinese factory image; in the settings menu you can change the language to English by selecting the gray info icon (系统, one from bottom), then the first option (语言..), and again the first option (also 语言), then press +, English and drag it to the top of the list). Connect the phone to your computer and check adb devices in the terminal. The phone should be registered as attached. If the device doesn’t show you may want to try a different port or cable. Then enter adb shell followed by su to gain root access. At this point you can erase the eMMC installation:\ncat /dev/zero \u0026gt; /dev/block/mmcblk1\nThe phone will freeze and then the screen will go blank. Let it sit for no less than 10 minutes and then power it off by holding down the power button. You’ll know the phone is powered down when the notification LED turns off.\nMethod 2: Via serial cable Another method of erasing the image is to connect serial console, break into U-Boot when it says to press Ctrl-C, and then the \u0026ldquo;mmc erase\u0026rdquo; command can be used to zero blocks on the eMMC. For example, \u0026ldquo;mmc erase 0 16384\u0026rdquo; will zero the first 8MB, and is enough to stop it from being bootable. The baud rate for the serial console is 1500000.\nFlashing Linux You will want to do all your testing and development on a SD card; you DO NOT want to flash an OS to eMMC at this time. Builds frequently break at this early development stage and recovering from a corrupted eMMC installation is presently time consuming and tedious. A fast 16-64GB micro SD card for $15 will work just fine.\nThere are a handful of OS builds available for the PinePhone Pro already. These can be found under the Software Releases section.\nIf you are a developer porting your own distribution to the PinePhone Pro, please make sure to make an entry for it in the Software Releases section on the documentation. If you want / need help with entering your build onto the documentation please ping one of the mods or admins in the chats (see Forums and Chats drop-down menu).\nResources Aside from the PINE64 documentation there are also other useful resources scattered across different Wikis, repositories and blogs. In time these will be gathered into one place - the DevZone - which will help to streamline the development process.\nAt the time of publishing, these are some of the notable resource, listed in no particular order:\npostmarketOS Wiki Megi’s (b)log DanctNIX repository Manjaro repository Development Development This page documents development processes and provides links to resources to help prospective contributors get started. For an overview of the current software state see software state.\nUpstreaming status Function Status Component Notes Bootloader (u-boot) Working. Not upstreamed. https://github.com/dreemurrs-embedded/Pine64-Arch/tree/master/PKGBUILDS/pine64/uboot-pinephonepro uses https://git.sr.ht/~martijnbraam/u-boot. Modem Working. Not upstreamed. Support in https://gitlab.com/mobian1/devices/eg25-manager and Megi’s kernel. Levinboot-based kernel development image This guide will help you get a comfortable environment for testing your kernel builds on Pinephone Pro. It assumes you either already know how to build or cross-build a Linux kernel for arm64, or if you have a way to get a pre-built kernel from somewhere. For a quick test that your setup works, you can use megi’s pre-built kernels.\nQuick and easy way to get started with kernel development and testing is to use CrystalGamma’s Levinboot patched with support for Pinephone Pro and 3-option boot selection using volume keys. You will be able to switch between kernels quickly without swapping uSD cards, which is necessary for painless kernel development experience.\nCreate a following partitioning scheme on a uSD card using sfdisk: label: gpt first-lba: 64 table-length: 8 start=64, size=8128, type=D7B1F817-AA75-2F4F-830D-84818A145370, name=\u0026#34;sd-lboot\u0026#34; size=60M, type=E5AB07A0-8E5E-46F6-9CE8-41A518929B7C, name=\u0026#34;sd-lpayload1\u0026#34; size=60M, type=5f04b556-c920-4b6d-bd77-804efe6fae01, name=\u0026#34;sd-lpayload2\u0026#34; size=60M, type=c195cc59-d766-4b78-813f-a0e1519099d8, name=\u0026#34;sd-lpayload3\u0026#34; size=14G name=\u0026#34;sd-rootfs1\u0026#34; name=\u0026#34;sd-rootfs2\u0026#34; This can either be done interactively, or by saving the above to a file, like format.txt, and running sfdisk /dev/\u0026lt;sdcard\u0026gt; \u0026lt; format.txt\nWrite Levinboot to sd-lboot partition using dd. You can get a pre-built and tested version here There are two options levinboot-sd.img and levinboot-emmc.img you can use either one of them for your sd-lboot partition. They differ in where they load the payloads from (either from SD or eMMC) and not in where they can be flashed to. For uSD card only workflow, you’ll want levinboot-sd.img.\nPrepare payloads for Levinboot and copy them to appropriate partitions. Partition sd-lpayload1 is used by default, sd-lpayload2 when you hold a volume down key during powerup, and sd-lpayload3 when you hold the volume up key.\nPreparing a payload involves getting a TF-A bl31.elf build, kernel Image build, DTB file for Pinephone Pro, and optionally an initramfs archive, modifying DTB to include kernel boot arguments, and compressing these using lz4 in specific order, as shown below.\nBOOTOPTS=( console=tty1 earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8 root=PARTLABEL=emmc-rootfs1 rootfstype=f2fs rootflags=fastboot rootwait rw loglevel=7 ) BOOTOPTS=\u0026#34;${BOOTOPTS[@]}\u0026#34; ALGO=\u0026#34;lz4 -zc\u0026#34; cp -f rk3399-pinephone-pro.dtb board-cfg.dtb fdtput -pt s board-cfg.dtb /chosen bootargs \u0026#34;$BOOTOPTS\u0026#34; ( $ALGO bl31.elf $ALGO board-cfg.dtb $ALGO Image . $ALGO initramfs.img ) \u0026gt; payload.img dd if=payload.img of=/dev/disk/by-partlabel/sd-lpayload1 bs=4M oflag=direct Prepare root filesystem. You can use any Linux distribution for aarch64 for development. For example if you want to use Arch Linux ARM, you would need to format the sd-rootfs1 partition with f2fs filesystem and extract the Arch Linux ARM rootfs tarball there. That will give you a bootable SD card image for Pinephone Pro.\nRepeat steps 3 and 4 if you want either more kernel payloads, or more Linux distributions on the same uSD card. I recommend having at least some module-less working kernel in sd-payload3 and perhaps a small userspace in sd-rootfs1 with a pre-configured WiFi connection, that will allow you to always quickly recover if your development kernel fails to boot, just by pressing volume up key during boot and updating the the kernel in one of the primary payload partitions over WiFi.\nResources See megi’s PinePhone Development Log Further information Datasheets, schematics and certifications\nPress\nSpecifications\nDatasheets, schematics and certifications PinePhone Pro mainboard schematic:\nPinePhone Pro mainboard Explorer Edition Released Schematic ver 1.0 20211127 PinePhone Pro mainboard Explorer Edition component top placement ver 1.0 20211127 PinePhone Pro mainboard Explorer Edition component bottom placement ver 1.0 20211127 PinePhone Pro USB-C small board schematic:\nTBD Certifications:\nPinePhone Pro FCC Certificate PinePhone Pro SAR Evaluation Report PinePhone Pro CE RED Certificate PinePhone Pro ROHS Test Report Press For an overview about media of the PinePhone Pro you can use for the news, blogs, or similar see Press.\nSpecifications Dimensions: 160.8 x 76.6 x 11.1mm Weight: Approx. 220g SIM Card: Nano-SIM (Micro-SIM before 07/2022) Display: Size: 6 inches (151mm) diagonal Type: 1440 x 720 in-cell IPS with Gorilla Glass 4™ Resolution: 1440x720, 18:9 ratio System on Chip: Rockchip RK3399S 64bit SoC – 2x A72 and 4x A53 CPU cores @ 1.5GHz RAM: 4GB LPDDR4 @ 800MHz Internal Storage: 128GB eMMC, extendable up to 2TB via microSD, supports SDHC and SDXC NOR Flash: Listed as [GigaDevices] GD25LQ128EWIGR, but physical inspection found a SiliconKaiser SK25LP128. Back Camera: 13MP Sony IMX258 with Gorilla Glass 4™ protective layer, LED Flash Front Camera: 8MP, OmniVision OV8858 front-facing camera Sound: Loudspeaker, 3.5mm jack \u0026amp; mic (jack doubles as hardware UART if hardware switch 6 is deactivated) Communication: Modem Quectel EG25-G LTE-FDD: B1, B2, B3, B4, B5, B7, B8, B12, B13, B18, B19, B20, B25, B26, B28 LTE-TDD: B38, B39, B40, B41 WCDMA: B1, B2, B4, B5, B6, B8, B19 GSM: B2, B3, B5, B8 (850, 900, 1800, 1900 MHz) WLAN \u0026amp; Bluetooth: Wi-Fi 802.11AC, hotspot capable + Bluetooth V5.0 GNSS: GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS Sensors: Accelerometer, gyroscope, proximity, ambient light, compass Privacy switches: Modem, WiFi \u0026amp; Bluetooth, Microphone, Cameras Battery: Lithium-ion, rated capacity 2800mAh (10.64Wh), typical capacity 3000mAh (11.40Wh) (nominally replaceable with any Samsung J7 form-factor battery; unglue bottom black plastic with your nail from Samsung battery before installation in order to match the dimensions) I/O: USB Type-C, USB Host, DisplayPort Alternate Mode output, 15W 5V 3A Quick Charge, follows USB PD specification ","permalink":"/documentation/PinePhone_Pro/_full/","tags":null,"title":"PinePhone Pro (Single Page)"},{"categories":null,"contents":"The PinePhone v1.0 is the developer hardware revision of the PinePhone.\nThis page contains resources which are exclusive to the 1.0 revision of the PinePhone. For other revisions, or for resources related to all PinePhone revisions, see PinePhone.\nSchematic PinePhone v1.0 Schematic 20190708 Pinephone V1.0 Mainboard Top Layer Silkscreen Pinephone V1.0 Mainboard Bottom Layer Silkscreen Pinephone V1.0 Daughterboard Top Layer Silkscreen Pinephone V1.0 Daughterboard Bottom Layer Silkscreen Known issues See the known issues with v1.1 (Braveheart), which are all carried forward from v1.0.\n","permalink":"/documentation/PinePhone/Revisions/PinePhone_v1.0_-Dev/","tags":null,"title":"PinePhone v1.0 - Dev"},{"categories":null,"contents":"The PinePhone v1.1 \u0026ldquo;Braveheart\u0026rdquo; is a hardware revision of the PinePhone that shipped in January 2020.\nThis page contains resources which are exclusive to the 1.1 revision of the PinePhone. For newer revisions or for resources related to other PinePhone revisions see PinePhone.\nSchematic Hardware schematic\nChanges from 1.0 Braveheart is slightly different from the 1.0 revision of the Pinephone. These differences should not require creating different images.\nAdded CPU shielding and cover plate Swap PC3 to FLASH_EN and PD24 to FLASH_TRIGOUT, where previously they were reversed Add pulldown resistor on PD24 (FLASH_TRIGOUT) so the flash LED does not light on boot Connect WiFi enable to VD33 Set the EG25G’s PWRKEY on by default (see resistor R1526) Add R630 resistor location, populate with 0K by default. Allows adjusting to different battery thermistors in case this is not possible in software. Add voltage shift to Pogo pins I2C-CLK, I2C-DATA, and INT. The Pogo Pin specified voltage is 3.3v while the A64’s I2C is 2.8V. A64 LINEOUTN is disconnected from the speaker amplifier, making the speaker output single-ended instead of differential DIY Hardware fixes Some of the known issues can be fixed with more or less involved hardware modifications:\nVCONN mod: USB-C CC pins are pulled to GND, removing small switches can make USB-OTG work. A proper fix is to replace those with another component. PMIC mod / PinePhone 1.1 VBUS power usage hardware fix to lower power consumption, especially when the phone is powered off. Known issues This section lists problems known on the 1.1 revision hardware, possibly because they carried over from the 1.0 revision. Most of these were fixed in the 1.2 revision mainboard.\nNeed a way to distinguish v1.1 from v1.2 from U-Boot SPL Resolved in v1.2 by PL6 being connected directly to the modem, instead of through the level shifter, so it is pulled low at boot.\nTo load the correct device tree, there needs to be some hardware feature that can distinguish the two versions. This can be as simple as an I/O pin that is pulled differently by default between v1.1 and v1.2. Reading the pin in SPL will tell us which device tree to use.\nWiFi module cannot be disabled or reset in software Resolved in v1.2 by connecting PL2 to the WiFi module’s WiFi reset pin.\nNeither the WL-REG-ON nor WL-PMU-EN signal is connected to anything, and the WiFi module’s CHIP_EN pin is connected (through the privacy switch) to a regulator that cannot be turned off (easily, if at all). So while the privacy switch works, there’s no way to disable the WiFi module in software. This will lead to excess power consumption when WiFi is turned off.\nMagnetometer\u0026rsquo;s IRQ signal is routed to the wrong pin Resolved in v1.2 by connecting the magnetometer’s DRDY pin to PB1.\nIt needs to go to DRDY, not to INT. The kernel driver expects the trigger events to be fired when DRDY changes, and does not even configure the interrupts to be enabled on the INT pin.\nSoftware workaround is to disable magnetometer interrupt in the devicetree, and use a hrtimer or some other software triggering mechanism for IIO devices.\nSpeaker output could be differential Resolved in v1.2 by connecting LINEOUTP to the speaker amplifier’s INP input.\nUsing a differential connection to the speaker amplifier would significantly lower the noise floor of the speaker, and would allow doubling the max volume.\nModem AP_READY signal is not connected Resolved in v1.2 by connecting PH7 to AP_READY instead of WAKEUP_IN.\nThe modem’s power management documentation describes how to implement modem power saving. The modem can wake up the host using either the Ring Indicator pin (section 4.5) or USB remote wakeup (section 4.3). Either way, it suggests the AP_READY signal needs to be connected. The modem needs that signal to know when the host is asleep (and the modem needs to queue its messages and wake it up), and when the host has finished waking up (and is ready to receive the queued messages).\nModem RI signal routing prevents wakeup Resolved in v1.2 by connecting RI to PL6.\nThe EG25G’s Ring Indicator (RI) pin is currently routed to GPIO pin PB2. The A64 needs to receive interrupts via this pin while suspended, so the modem can wake up the A64 (for incoming calls and text messages). The only GPIO bank that can receive interrupts while the A64 is suspended is Port L (on R_PIO).\nNote: Port L is powered by VCC-PL, and runs at 1v8, so it should not have a level shift to DCDC1/3v3 between the AP and the modem, like DTR currently has. The way DTR is currently connected is a bug.\nExcess power usage while driving VBUS Resolved in v1.2 by connecting PL9 and VBUS_CTRL on the ANX7688 to N_VBUSEN on the PMIC. A crude hardware workaround is also possible, see PinePhone 1.1 VBUS power usage Hardware Fix.\nThe N_VBUSEN/DRIVEVBUS input on the AXP803 PMIC, labeled USB-DRVVBUS on the schematic, is not connected to the USB OTG boost regulator enable input, because R1300 is marked \u0026ldquo;NC\u0026rdquo;. This prevents the AXP803 from automatically detecting when the USB port is being powered from the battery. Thus, the PMIC continues to draw power from the USB port, and this doubles the drain on the battery (since the whole phone is being powered by the USB OTG boost regulator). This could be fixed by populating R1300.\nThe ANX7688’s VBUS_CTRL pin should also be connected to the DRVVBUS signal to perform role switching in hardware without needing OS interaction. In that case PD6 becomes an input. Otherwise, we would need to hook up the VBUS status change interrupt from the ANX7688 to control the USB PHY driver.\nANX7688 power supply situation is problematic Resolved in v1.2 by powering always-on 3v3 from DCDC1, video-related 3v3 from DLDO1, 1v8 from GPIO-LDO1, and 1v0 controlled by PD11.\nANX7688 has four power inputs: 3v3, 1v8, 1v0, and HDMI_VT (which is also 3v3).\nThe main 3v3 input, to AVDD33, should always be on according to the datasheet. For this reason, it should be connected to an always-on regulator, such as DCDC1, so DLDO1 can be turned off when the screen is off. It has extremely low power consumption. HDMI_VT is only needed during video transmission, and should remain connected to DLDO1. The only other 3v3 consumer is the VCONN_EN pull-ups. These could be pulled to GPIO1-LDO (1.8V) instead; the pins are open drain. The DVDD18 input should also always be on according to the datasheet. It has extremely low power consumption. I recommend connecting it and the PL11 pull-up to VCC-PL, so GPIO1-LDO can be turned off. The remaining 1v8 inputs only need to be enabled when a USB cable is connected (supply or OTG). They are connected to their own regulator (GPIO1-LDO), so that is fine. (Note that the next issue suggests removing the pull-ups for POWER_EN and RESET_N.) The 1v0 input is only needed when a USB cable is connected (supply or OTG). It is currently controlled by DLDO1, but I think controlling it with GPIO1-LDO would be an improvement. That way DLDO1 only needs to be enabled when transmitting video, not always when a cable is connected. Modem PWR_KEY signal resistor population Resolved in v1.2 by separating the modem PWRKEY (PB3) and STATUS (PH9) signals.\nOn the dev phone (1.0) this signal was connected to PB3. This allows for turning on/off the modem via GPIO from a kernel driver. If proper power down is to be implemented in the kernel for the modem, to allow safe shutdown of the modem before turning off the 4g-pwr-bat, kernel has to be able to signal to the modem to shut down and wait 30s. This is not possible on braveheart. Without this signal, kernel can’t do anything to shut down the modem, and would have to rely on userspace to properly manage the modem power up/down sequence. Relying on userspace risks users shutting down the modem without proper wait time of 30s, risking modem damage (flash data corruption).\nIt would be nice to also have access to the STATUS signal from the modem, so that the driver can detect whether the modem is on or off (userspace might have turned modem off already via AT commands). Given that PWR_KEY pulse will either turn the modem on or off, based on the current status, it’s necessary to know the current status before sending the pulse.\nThere’s a STATUS signal routed to PWR_KEY on BraveHeart, that keeps the PWRKEY deasserted when the modem is on and it’s not possible to pull it up from PB3, even if R1516 would be optionally mounted.\nSo after powerup you can’t change PWR_KEY signal anymore from PB3 even if R1516 is mounted, and it’s not possible to turn off the modem via PB3.\nModem has access to sensors on I2C1 Resolved in v1.2 by disconnecting the modem’s I2C port.\nThe modem is a master on the I2C1 bus. A malicious firmware on the modem would be able to read the phone’s gravity/light/proximity sensors and prevent the main Linux OS from reading them. The modem’s audio design note describes the AT+QIIC command which can be used to read and write registers on I2C devices.\nAccording to the modem documentation, its I2C interface is only used for direct connection to a standalone audio codec. On the PinePhone, since the modem’s audio is routed through the A64 SoC, the modem’s I2C interface has no legitimate use.\nThe modem’s I2C interface should be left floating. U1503 pins A1, A2, B1, and B2 can be disconnected, and R1527/R1528 can be removed.\nAllow access the modem debug UART Not resolved in v1.2 \u0026ndash; would have required moving several other GPIOs.\nInstead of the modem’s I2C pins, which aren’t very useful (see above), it would be great to have access to the modem’s debug UART, for debugging/updating the modem. This could be on UART3 (PD0-PD1, no flow control), while the main modem UART is on UART4 (PD2-PD5, with flow control).\nModem UART flow control is broken Not resolved in v1.2 \u0026ndash; assumption is that USB will be used for high-bandwidth modem I/O.\nBB-TX and BB-RX are connected to UART3 (PD0/PD1). BB-RTS and BB-CTS are connected to UART4 (PD4/PD5). To use hardware flow control, TX/RX would need to be connected to UART4, swapping PD0/PD1 with the motor control and rear camera reset GPIOs at PD2/PD3. This would need a device tree change.\nHardware flow control can be disabled with the AT+IFC command, and USB can also be used for commands instead of the UART. So the impact of this problem is unclear.\nANX7688 power/reset control pulled the wrong way Not resolved in v1.2 \u0026ndash; this has minimal impact.\nBoth ANX_POWER_EN and ANX_RESET_N have pull-ups when they should not. Both signals need to be pulled low by default. They only need to be brought high (turning the chip on) when a USB cable is attached; and they should only be brought high after the 1v8 and 1v0 regulators are turned on. ANX_POWER_EN needs an external pull-down. ANX_RESET_N has an internal pull-down.\nVCONN_EN signals are possibly inverted Further investigation determined that the hardware is correct as-is in v1.1, so no change was made.\nI don’t have a datasheet for the AW3512 chips, but I assume the enable input is active-high. VCONN1_EN and VCONN2_EN are open-drain. When they are open, it appears that VCONN should be enabled. But right now, when they are open, VCONN is disabled, because the AW3512 EN pin will be pulled low by the FET.\nCameras have the same default I2C address Resolved in software by reprogramming the one of the cameras\u0026rsquo; I2C addresses at boot.\nThis makes it hard to keep both of them powered at the same time and switch quickly between them (on the per-frame basis) without having to re-initialize the sensors on each switch, which takes some time.\nUSB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There’s no SW workaround for automatic detection of cable plug or power role.\nIn SW this can only be worked around by manual selection of PinePhone’s data and power role by the user.\nHW workaround is desoldering U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles. I confirmed that desoldering fixes the issue. (Howto: https://megous.com/dl/tmp/pp-usbc-fix.jpg)\nHW fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn’t have the \u0026ldquo;quick discharge function\u0026rdquo; that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. mozzwald used NCP334FCT2G as a replacement.\nThis issue is also present on the PinePhone 1.2 (CE) version and was fixed with revision 1.2a. See the workaround for affected revisions.\nPogo Pins supply 5v0, not 3v3 No hardware change suggested, to maintain accessory compatibility.\nThis is possibly just a documentation issue. The wiki claimed they provide a \u0026ldquo;3.3v power source\u0026rdquo;, and on this page, \u0026ldquo;The Pogo Pin specified voltage is 3.3v\u0026rdquo;. But according to the schematic, they are connected to USB-5V, the output of the 5V boost regulator.\n","permalink":"/documentation/PinePhone/Revisions/PinePhone_v1.1_-_Braveheart/","tags":null,"title":"PinePhone v1.1 - Braveheart"},{"categories":null,"contents":"The PinePhone v1.2 is a hardware revision of the PinePhone that was shipped in 2020 as UBports Community Edition.\nThis page contains information and resources which are specific to the UBports Community Edition (v1.2 PCB) revision of the PinePhone. For other revisions or for resources related to all PinePhone revisions, see PinePhone.\nSchematics Hardware schematic v1.2 (2020-03-10, for the UBports Community Edition) Changes from v1.1 The v1.2 mainboard revision changes the routing of several GPIOs to fix bugs and to improve power management. Therefore, it needs an updated device tree. The state of PL6 at boot can be used to distinguish between v1.1 (it can be pulled high) and v1.2 (it will remain low).\nThe WiFi module’s CHIP_EN input (connected to the privacy switch) is now pulled down, so the WiFi will turn off reliably when the switch is off. PL2 is now connected to the WiFi module’s reset pin, allowing the WiFi to be turned off or reset in software. The magnetometer’s DRDY pin is now connected to PB1, allowing interrupt-driven periodic sensor readings. LINEOUTP is again connected to the speaker amplifier’s INP input (like in v1.0), increasing the SNR of the rear speaker. PH7 is now connected to the modem’s AP_READY input (instead of WAKEUP_IN), allowing the modem to buffer URCs (interrupts) while the phone is asleep. The modem’s RI output and DTR input had their GPIOs swapped between PL6 and PB2, so the RI signal can be detected without powering the main pin controller. Both PL9 and VBUS_CTRL (from the ANX7688) are now connected to N_VBUSEN on the PMIC. This causes the PMIC to automatically stop drawing power from the USB port when supplying power to a USB-OTG peripheral. It also allows the ANX7688 to automatically control the direction of current flowing through the USB port. As part of the previous change, the ANX7688’s reset input was moved to PD6; this pin previously controlled the USB OTG power. Some of the regulators supplying the ANX7688 were rearranged, to reduce power consumption when the USB port is not connected and not being used to transmit video. As part of the previous change, PD11 now controls the ANX7688’s 1v0 digital power domain. The modem’s STATUS output is now connected to PH9, allowing the modem on/off state to be visible in software (note: this only works while the modem is powered). Since it is no longer connected to PB3, reading STATUS no longer turns the modem on. The modem no longer has access to the I2C bus containing the sensors. HBIAS is now connected to the headphone jack. Known issues Backlight Backlight LED current regulation depends on gpio0-ldo voltage stability due to feedback voltage from current sensing resistor being modified via SoC’s PWM pin and pullup resistor to gpio0-ldo. gpio0-ldo also powers the CTP controller and light/proximity sensor, among other things. When backlight brightness is very low and the CTP controller actively communicates on the I2C bus the backlight blinks heavily. It’s not a very good idea to tie boost converter’s current regulating feedback circuit to the potential source of noise, especially since the noise will have much larger effect when the backlight LED current is low. It’s possible this can be mitigated if C1110 can be raised to 22-47uF range, or by changing the resistor values in the feedback circuit.\nPWM duty cycle for the lowest brightness of the backlight is also not very predictable, varying from 7-20% (tested with a small sample size of 2 devices). Therefore it’s not possible to come up with a single device tree brightness settings that will work for everyone, requiring per-device calibration.\nOn PinePhone 1.0, this was not the case, PWM signal was directly fed to the CE pin of the regulator, and lowest brightness setting seems more stable. On the other hand, the lowest achievable brightness was brighter than on 1.1+.\nAdditionally there is also another backlight issue, where the brightness is lower when connecting a VBUS powered device, https://xnux.eu/log/#022. See PinePhone 1.2b R1318 backlight hardware fix.\nUSB The USB-C CC pins are pulled to the GND by AW3512 (VCONN switches) when VCONN is off. This issue prevents cable plug/orientation detection and USB-PD communication. ANX always sees cable as plugged even if none is plugged. There’s no SW workaround for automatic detection of cable plug or power role.\nThe issue was was fixed with revision 1.2a. See PinePhone 1.2 VCONN hardware fix for details and an instruction about how to do the hardware fix.\nIn SW this can only be worked around by manual selection of PinePhone’s data and power role by the user.\nHardware workaround is to desolder U1305 and U1309 switches (BGA like packages). This will void the VCONN control, but it will release the CC pins for their proper connection detection and negotiation roles (see https://xnux.eu/devices/pp-usbc-fix.jpg).\nHardware fix is to replace AW3512 with a variant of the chip that preserves the EN signal polarity and that doesn’t have the \u0026ldquo;quick discharge function\u0026rdquo; that ties the output to the GND via a 75 Ohm resistor when the switch is OFF. User mozzwald used NCP334FCT2G as a replacement.\n","permalink":"/documentation/PinePhone/Revisions/PinePhone_v1.2/","tags":null,"title":"PinePhone v1.2"},{"categories":null,"contents":"The PinePhone v1.2a is a hardware revision of the PinePhone that started shipping in Q3 2020.\nThis page contains information and resources which are specific to the v1.2a revision of the PinePhone. For other revisions or for resources related to all PinePhone revisions, see PinePhone.\nSchematics Hardware schematic v1.2a (2020-06-08, for the postmarketOS Community Edition) Changes from v1.2 A thermal pad was added to the SoC alongside a graphene foil covering the metal shielding of the mainboard which is in direct contact with the LCD backplane to help dissipate heat. Another graphene foil sticker was added to the rear cover of the device to help disperse thermals from the back of the modem. Fixed a rectangular dead spot of the touchscreen under the speaker grill Antenna changes USB-C CC fix for video out and OTG functionality Known issues The backlight issue of v1.2 is still present, see PinePhone v1.2. There is also another backlight issue, where the brightness is lower when connecting a VBUS powered device, https://xnux.eu/log/#022. See PinePhone 1.2b R1318 backlight hardware fix.\n","permalink":"/documentation/PinePhone/Revisions/PinePhone_v1.2a/","tags":null,"title":"PinePhone v1.2a"},{"categories":null,"contents":"The PinePhone v1.2b is a hardware revision of the PinePhone that started shipping in Q4 2020.\nThis page contains information and resources which are specific to the v1.2b revision of the PinePhone. For other revisions or for resources related to all PinePhone revisions, see PinePhone.\nSchematics Hardware schematic v1.2b (for the Manjaro Community Edition) Changes from v1.2a A bug was fixed, where connecting a VBUS powered device lowered the screen brightness (resistor R1318 changed to NC). Changes with the Beta Edition Due to the global pandemic early 2021 and the component shortage as a result, the magnetometer in the Beta Edition had to be replaced from an LIS3MDL to an AF8133J. Known issues HDMI hotplug detection is not reliable due to a HW bug in level shifting circuitry for the hot plug detect (HPD) signal between HDMI bridge and A64 SoC, see megi’s blog post. It is not known if three issues of previous revisions are still present and if yes to which degree, or if they have been fixed by removing resistor R1318, see PinePhone v1.2 for some details. Please edit this page once this has been confirmed. Mind that there is currently a likely software-related bug present, which also causes the screen to flicker. The bug usually happens after abruptly shutting down the phone previously (for example by forcing it off), in contrast to powering it off. ","permalink":"/documentation/PinePhone/Revisions/PinePhone_v1.2b/","tags":null,"title":"PinePhone v1.2b"},{"categories":["Power supplies"],"contents":" PinePower, A 65W GaN Power Supply The portable PinePower packs plenty of power in a very compact design. It is capable of powering or charging multiple PINE64 devices; such as the Pinebook Pro, PinePhone and the PineTime simultaneously. If you’re interested in getting the Pinecil, our soldering iron, then we highly recommend the PinePower to ensure optimal power delivery.\nFeatures and Specifications 74.8mm x 36.6mm x 32mm 130 gram weight Black plastic case 100-240V 50/60Hz max input 65W output Power switch 240Vac input US plug, adapters for AU, EU, and UK 1 x USB-A 2 x USB-C 65W 65W combined output with two USB-C ports and one USB-A port\nPower Switch The PinePower comes with a power switch to turn it off when it’s not needed\nAdapters Default US style plug with adapters for the EU, UK, AU\nSmall And Compact Weighing only 130 grams the PinePower is a sleek and lightweight portable charger\nStores Global Affiliates Documentation PinePower ","permalink":"/devices/pinepower/","tags":null,"title":"PinePower"},{"categories":null,"contents":"The PinePower is a small and compact palm size 65W wall socket power adapter. It features 2 USB-C ports and 1 USB-A port charger. Gallium Nitride technology ensures a small and light charger with high charging efficiency. It has a retractable US plug.\nGeneral specifications Body:\nDimensions: 74.8mm x 36.6mm x 32mm Weight: 130 grams Build: Plastic Color: Black Power:\nInput: AC 100-240V 50/60Hz 1.5A Max Output: 65W Power switch Connections:\n240Vac input US plug, adapters for AU, EU, and UK, 1x USB-A 2x USB-C Power specifications Output Max output power Power ranges PD Power ranges QC Power ranges PPS Single USB-C1 or C2 65W 5V3A, 9V3A, 12V3A, 15V3A, 20V3.5A - 3.3-11V5A Single USB-A 65W - QC3.0 4.5V5A, 5V4.5A, 9V3A, 12V3A, 20V3A - USB-C1 \u0026amp;USB-C2 combined 45W18W 5V3A, 9V3A, 12V3A, 15V3A5V3A, 9V2A, 12V1.5A - - USB-C1 \u0026amp;USB-A combined 45W18W 5V3A, 9V3A, 12V3A, 15V3A- -5V3A, 9V2A, 12V1.5A - USB-C1 \u0026amp;USB-C2 + USB-A combined 45W15W 5V3A, 9V3A, 12V3A, 15V3A5V3A - - Internals Teardown Warning Opening this device may expose you to high voltage components that can cause serious injury or death. Do not attempt to open, repair or modify the device. For safety, always consult a qualified technician for any issues. To open your Charger, you just have to Cut away the backplate with the USB-Ports, then you can pull out the PCB.\nImages PCB Back\nPCB Top\nTop view in case\nPCB with unsoldered USB-C ports\nPCB side view\nCertifications 65W PinePower GaN Charger FCC Certificate 65W PinePower GaN Charger CE EMC Certificate 65W PinePower GaN Charger CE LVD Certificate ","permalink":"/documentation/PinePower/Versions/PinePower/","tags":null,"title":"PinePower"},{"categories":null,"contents":" The PinePower devices (the PinePower and the PinePower Desktop) are power supplies, which pack plenty of power. They capable of powering or charging multiple PINE64 devices, such as the Pinebook Pro, PinePhone and the PineTime simultaneously.\nPinePower PinePower\nPinePower Desktop PinePower 65W\nPinePower Desktop V2 PinePower Desktop V2\nVersions PinePower\nPinePower Desktop\nPinePower Desktop V2\nPinePower The PinePower is a small and compact palm size 65W wall socket power adapter. It features 2 USB-C ports and 1 USB-A port charger. Gallium Nitride technology ensures a small and light charger with high charging efficiency. It has a retractable US plug.\nGeneral specifications Body:\nDimensions: 74.8mm x 36.6mm x 32mm Weight: 130 grams Build: Plastic Color: Black Power:\nInput: AC 100-240V 50/60Hz 1.5A Max Output: 65W Power switch Connections:\n240Vac input US plug, adapters for AU, EU, and UK, 1x USB-A 2x USB-C Power specifications Output Max output power Power ranges PD Power ranges QC Power ranges PPS Single USB-C1 or C2 65W 5V3A, 9V3A, 12V3A, 15V3A, 20V3.5A - 3.3-11V5A Single USB-A 65W - QC3.0 4.5V5A, 5V4.5A, 9V3A, 12V3A, 20V3A - USB-C1 \u0026amp;USB-C2 combined 45W18W 5V3A, 9V3A, 12V3A, 15V3A5V3A, 9V2A, 12V1.5A - - USB-C1 \u0026amp;USB-A combined 45W18W 5V3A, 9V3A, 12V3A, 15V3A- -5V3A, 9V2A, 12V1.5A - USB-C1 \u0026amp;USB-C2 + USB-A combined 45W15W 5V3A, 9V3A, 12V3A, 15V3A5V3A - - Internals Teardown Warning Opening this device may expose you to high voltage components that can cause serious injury or death. Do not attempt to open, repair or modify the device. For safety, always consult a qualified technician for any issues. To open your Charger, you just have to Cut away the backplate with the USB-Ports, then you can pull out the PCB.\nImages PCB Back\nPCB Top\nTop view in case\nPCB with unsoldered USB-C ports\nPCB side view\nCertifications 65W PinePower GaN Charger FCC Certificate 65W PinePower GaN Charger CE EMC Certificate 65W PinePower GaN Charger CE LVD Certificate PinePower Desktop The PinePower Desktop is an 120W desktop power adapter. It features 1 USB-C port and 4 USB-A port. The 120W output is not per port, but total output power. This is calculated by combining the 65W USB-C, 3x15W USB-A and the 18W USB-A QC, making a total of 128W. The only difference between the US and EU edition is the supplied power cable. Every port, with exception of the wireless Q-charger, has a display, portraying the output voltage and amps. The display back light can be turned on and off by capacitive touch button, located on the top left side of the unit.\nPinePower Desktop 120W\nGeneral specifications Body:\nDimensions: 123mm x 115mm x 48mm Weight: 543 grams Build: Plastic Color: Black Display:\nIndividual port voltage status display Individual port current status display Controls:\nMains power toggle switch Capacitive power output display switch Power:\nInput: AC 100-240V 50/60Hz ?A Max Output: 120w Connections:\n110/240VAC input (either US/EU/UK figure of 8 plug is supplied) 4x USB-A 1x USB-C Power specifications Output Protocol Version Max output power Power ranges USB-C PD ? 65W 5V3A, 9V3A, 12V3A, 15V3A, 20V3.25A USB-A QC 3.1 18W 5V3A, 9V2A, 12V1.5A USB-A USB ? 15W 5V3A Wireless charger Qi 1.2 10W - Internals The power unit is not made to be disassembled, do so at your own risk. The front plate is secured with 4 tabs, that can be disengaged with a screwdriver. The complete assembly can be slid out, but do mind the same tab in the casing. The power button at the back of the case has a plug that can be disconnected from the main PCB. The wireless charging PCB has to be de-soldered, or forcefully removed from the inner casing, as it is glued to the top of the case.\n(Removal_of_the_front_plate)\n(Front_view_display_PCB)\n(Back_side_display_PCB)\n(Top_side_main_PCB)\n(Bottom_view_main_PCB)\n(Wireless charger)\nSome remarks:\nThis main PCB is marked as XR SEMI v1.1 Two unmarked packages, control the display. An antenna is connected on the display PCB, lining up with the \u0026rsquo;lamp\u0026rsquo; symbol. This is the capacitive touch button to control the display back light. The 65W PD USB-C port is controlled by a HUSB339 controller, paired with a GOFORD G16 MOSFET. The other ports have a NDP1360KC as final power converter. Certifications 120W PinePower Desktop Power Supply FCC Certificate 120W PinePower Desktop Power Supply CE EMC Certificate PinePower Desktop V2 The PinePower Desktop V2 power supply features two sets of 65W PD, two sets of 22.5W QC3.0 and 15W Wireless Charging simultaneous output capability.\nPinePower Desktop V2\nGeneral specifications Body:\nDimensions: 123mm x 114mm x 48mm Weight: 448 grams Build: Plastic Color: Black Power:\nInput: AC 100-240V 50/60Hz Output: 165W Display:\nIndividual port voltage status display Individual port current status display Individual port wattage status display USB-C PD Ports (C1\u0026amp;C2):\n65W Combine Output C1 (45W) + C2 (20W) USB-C PD Port (C3):\n65W total Output 5V3A, 9V3A, 12V3A, 15V3A, 20V3.25A USB-A QC3.0 Ports:\n2 Individual Ports total 45W Output (22.5W each) Each port: 5V3A, 9V2A, 12V1.5A, 4.5V5A, 5V4.5A Wireless Charging:\nQi charging technology 15W, 10W, 7.5W, 5W Fast charging Features:\nSimultaneous supply power to Pinecil, PINE64 SBCs and devices Certification:\nFCC CE ROHS External links Pine blog, containing news about the PinePower products PinePower 65W on the official Pine store PinePower 120W EU version on the official Pine store PinePower 120W US version on the official Pine store ","permalink":"/documentation/PinePower/_full/","tags":null,"title":"PinePower (Single Page)"},{"categories":["Power supplies"],"contents":" PinePower: A 120W Desktop Power Supply The PinePower Desktop is a 120W switching power supply capable of powering all your PINE64 devices. The desktop PinePower can charge the Pinebook Pro, PinePhone, PineTab and the PineTime simultaneously with plenty of headroom to spare.\nFeatures and Specifications 123mm x 115mm x 48mm Weight of 543 grams Black plastic case AC 100-240V 50/60Hz input Combined output of 120W Individual port voltage status display Individual port current status display Display on/off switch Power switch Qi wireless charging technology 1 x USB-A @ up to 18W 3 x USB-A ports @ 15W 1 x USB-C port @ up to 65 120W 120W total output with up to 65W through USB-C\nPlenty of I/O 4 USB-A ports and 1 USB-C port\nWireless Charging The PinePower comes with built-in wireless charging pad on top\nStatus Display Individual voltage and status displays for each port\nStores Global Affiliates Documentation PinePower Resources YouTube: Gary Explains reviews the PinePower YouTube: Desktop PinePower being used to power a Pinecil ","permalink":"/devices/pinepower_desktop/","tags":null,"title":"PinePower Desktop"},{"categories":null,"contents":"The PinePower Desktop is an 120W desktop power adapter. It features 1 USB-C port and 4 USB-A port. The 120W output is not per port, but total output power. This is calculated by combining the 65W USB-C, 3x15W USB-A and the 18W USB-A QC, making a total of 128W. The only difference between the US and EU edition is the supplied power cable. Every port, with exception of the wireless Q-charger, has a display, portraying the output voltage and amps. The display back light can be turned on and off by capacitive touch button, located on the top left side of the unit.\nPinePower Desktop 120W\nGeneral specifications Body:\nDimensions: 123mm x 115mm x 48mm Weight: 543 grams Build: Plastic Color: Black Display:\nIndividual port voltage status display Individual port current status display Controls:\nMains power toggle switch Capacitive power output display switch Power:\nInput: AC 100-240V 50/60Hz ?A Max Output: 120w Connections:\n110/240VAC input (either US/EU/UK figure of 8 plug is supplied) 4x USB-A 1x USB-C Power specifications Output Protocol Version Max output power Power ranges USB-C PD ? 65W 5V3A, 9V3A, 12V3A, 15V3A, 20V3.25A USB-A QC 3.1 18W 5V3A, 9V2A, 12V1.5A USB-A USB ? 15W 5V3A Wireless charger Qi 1.2 10W - Internals The power unit is not made to be disassembled, do so at your own risk. The front plate is secured with 4 tabs, that can be disengaged with a screwdriver. The complete assembly can be slid out, but do mind the same tab in the casing. The power button at the back of the case has a plug that can be disconnected from the main PCB. The wireless charging PCB has to be de-soldered, or forcefully removed from the inner casing, as it is glued to the top of the case.\n(Removal_of_the_front_plate)\n(Front_view_display_PCB)\n(Back_side_display_PCB)\n(Top_side_main_PCB)\n(Bottom_view_main_PCB)\n(Wireless charger)\nSome remarks:\nThis main PCB is marked as XR SEMI v1.1 Two unmarked packages, control the display. An antenna is connected on the display PCB, lining up with the \u0026rsquo;lamp\u0026rsquo; symbol. This is the capacitive touch button to control the display back light. The 65W PD USB-C port is controlled by a HUSB339 controller, paired with a GOFORD G16 MOSFET. The other ports have a NDP1360KC as final power converter. Certifications 120W PinePower Desktop Power Supply FCC Certificate 120W PinePower Desktop Power Supply CE EMC Certificate ","permalink":"/documentation/PinePower/Versions/PinePower_Desktop/","tags":null,"title":"PinePower Desktop"},{"categories":["Power supplies"],"contents":" PinePower Desktop V2 The PinePower Desktop V2 power supply features two sets of 65W PD, two sets of 22.5W QC3.0 and 15W Wireless Charging simultaneous output capability.\nStores Global Affiliates Documentation PinePower ","permalink":"/devices/pinepower_desktop_v2/","tags":null,"title":"PinePower Desktop V2"},{"categories":null,"contents":"The PinePower Desktop V2 power supply features two sets of 65W PD, two sets of 22.5W QC3.0 and 15W Wireless Charging simultaneous output capability.\nPinePower Desktop V2\nGeneral specifications Body:\nDimensions: 123mm x 114mm x 48mm Weight: 448 grams Build: Plastic Color: Black Power:\nInput: AC 100-240V 50/60Hz Output: 165W Display:\nIndividual port voltage status display Individual port current status display Individual port wattage status display USB-C PD Ports (C1\u0026amp;C2):\n65W Combine Output C1 (45W) + C2 (20W) USB-C PD Port (C3):\n65W total Output 5V3A, 9V3A, 12V3A, 15V3A, 20V3.25A USB-A QC3.0 Ports:\n2 Individual Ports total 45W Output (22.5W each) Each port: 5V3A, 9V2A, 12V1.5A, 4.5V5A, 5V4.5A Wireless Charging:\nQi charging technology 15W, 10W, 7.5W, 5W Fast charging Features:\nSimultaneous supply power to Pinecil, PINE64 SBCs and devices Certification:\nFCC CE ROHS ","permalink":"/documentation/PinePower/Versions/PinePower_Desktop_V2/","tags":null,"title":"PinePower Desktop V2"},{"categories":["Tablets"],"contents":" PineTab: The Open Source ARM 64-bit Tablet The PineTab is similar in both form, function and underlying ARM64 architecture to the original 11.6″ Pinebook. It is powered by the same quad-core ARM Cortex A53 64-Bit Processor used in our popular PINE A64 Single Board Computer. The optional keyboard and trackpad – which doubles-up as a screen cover – effectively converts the PineTab into a petite on-the-go laptop with a touch screen functionality. It runs numerous mainline Linux distributions as well as *BSD and Android.\nAs a new open source platform, the PineTab development is an ongoing process and represents a great opportunity to get involved with computing on a different level, to customise and personalise the portable computer experience, to understand what is going on beneath the surface.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.152GHz GPU ARM Mali 400 MP2 GPU Memory 2GB LPDDR3 RAM Display 10″ MiPi 720p capacitive LCD Storage Bootable Micro SD slot 64GB of eMMC Connections Micro HD digital video out port USB 2.0 A Host Micro USB 2.0 OTG 2Mpx front-facing camera 5Mpx rear camera Optional M.2 slot Speakers and microphone 3.5mm headphone jack with mic input Volume rocker Magnetically attached keyboard (optional) Built-in 802.11 b/g/n WiFi with Bluetooth: 4.0 6000mAh battery 2.5mm barrel power (5V 3A) port Multiple expansion boards for LTE, LoRa and SATA SSD Detachable Keyboard Optional magnetic detachable keyboard that acts as a case for the tablet when not in use\nStorage Expansion Add a SATA SSD using a optional expansion board\nExpansion Modules Expansion modules for LTE modem and LoRa\nMicro HD Video Out Micro digital HD video out port allows for displaying content on an external monitor\nDocumentation PineTab Schematics and certifications Accessories Serial Cable Serial console powered by CH340 chipset enables USB-to-Serial-communication through the earphone jack for development. Resources YouTube: Switched to Linux unboxing of the PineTab YouTube: Another PineTab unboxing by Linux Lounge YouTube: First impressions of the PineTab by Privacy \u0026amp; Tech Tips ","permalink":"/devices/pinetab/","tags":null,"title":"PineTab"},{"categories":null,"contents":" The PineTab\nThe PineTab is a 10\u0026quot; tablet created by PINE64. The PineTab is similar in both form, function and underlying ARM64 architecture to the original 11.6″ Pinebook. It is powered by the same quad-core ARM Cortex A53 64-Bit Processor used in our popular PINE A64 Single Board Computer. The optional keyboard and trackpad – which doubles-up as a screen cover – effectively converts the PineTab into a petite on-the-go laptop with a touch screen functionality. It runs numerous mainline Linux distributions as well as *BSD and Android.\nOperating systems The PineTab will automatically boot from microSD if a bootable card is inserted. Although it is technically possible to use any ARM distribution (because the PineTab uses the mainline kernel), only few of them will actually be usable on Early Adopters PineTab, due to specifics of working with LCD panel. Among those listed all except for postmarketOS have working builds.\nArch Linux ARM Unofficial Arch Linux ARM with Phosh as the UI selection, maintained by the DanctNIX community.\nDownload:\nThe latest image can be downloaded here Mobian A Mobian build for ARM64 running with Phosh. The current version of the base Debian system is Debian Bookworm. See the installation instructions here. If you have questions about Mobian, please ask them in the Mobian Matrix room.\nDownload:\nPineTab images can be downloaded here. The password is 1234 Default credentials Default user mobian/1234 postmarketOS postmarketOS extends Alpine Linux to run on smartphones and other mobile devices.\nIt offers various user interfaces (Phosh, Plasma Mobile, Sxmo, Plasma Desktop, Gnome 3, Kodi, XFCE4 and more). As of writing, official images are provided with Phosh and Plasma Mobile. The official images come in two flavors, either as demo image to try out postmarketOS, or with the installer.\nWhen using the installer images (recommended), it is possible to:\nencrypt your installation install from the SD card to eMMC Getting postmarketOS for the PineTab:\nDownload page Flashing instructions Power users may also create their own image with the distribution’s install and development tool pmbootstrap Rhino Linux Rhino Linux is an Ubuntu-based distribution that uses the rolling-release model by tracking the devel branch of repositories. The port is currently maintained by Oren Klopfer (oklopfer).\nThe bootloader (U-Boot) comes pre-flashed in the port. Installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload:\nRhino Linux Downloads (select Pine64 on the dropdown)\nDefault credentials Default user rhino/1234 Notes:\nFoundational to the distribution is Pacstall, a Debian-based user repository inspired by the AUR. Additionally, RL comes with Unicorn, a custom modified version of XFCE with various modernizations and improvements, including auto-rotation for mobile devices.\nDiscord - Matrix - GitHub - Wiki\nSailfish OS You can get SailfishOS on your with the flash-it script, which will write an image on a SD card. https://github.com/sailfish-on-dontbeevil/flash-it\nThere is a forum discussion with further information.\nhttps://forum.pine64.org/showthread.php?tid=11850\nMany things are still broken but Bluetooth, Audio, Rotation and Keyboard are working.\nUbuntu Touch Ubuntu Touch is a mobile version of the Ubuntu distribution made and maintained by the UBports community. The port is currently maintained by Oren Klopfer (oklopfer).\nThe bootloader (U-Boot) comes pre-flashed in the port. Installation just requires flashing the the .img.xz file to an SD or the eMMC.\nDownload:\nUBports 20.04 PineTab Latest Releases UBports PineTab Device Info\nDefault credentials Default user Set during boot root phablet/1234 Notes:\nScroll down to the middle of the GitLab project page, or directly here at the UBports website to see which features work.\nContributions and bug reports can be made at the UBports PineTab GitLab page. See UBports website for how to donate.\nInstallation instructions For instructions on how to install the operating systems to the eMMC or microSD card see Installation instructions. The information is almost the same for the PineTab, as it is a very similar device. Do not try to use the PinePhone images though, use the PineTab images linked above.\nKeyboard Overview: The PineTab detachable keyboard features a full function row, FN key functionality, meta key (where the Windows key would be) and all of the keys you need for daily use.\nFN keys: Pause/play (F2), Stop (F3), Previous(F4), Next(F5), Music (F6), Mail (F7), Home (F8), Mute (F9), Vol- (F10), Vol+ (F11), Disable touchpad (F12), NumLock (Insert), Scroll Lock (Delete), PgUp (Up Arrow), PgDn (Down Arrow), Home (Left Arrow), End (Right Arrow), Digital Numpad (7,8,9,0,U,I,O,P,J,K,L,;,M,.,/)\nTips and tricks Reset If your PineTab is in unknown state or doesn’t want to start: Press power button for 7-8s. It makes a sound and you know it’s totally off. 3 seconds after, power button again for 2-3s and it will start to boot.\nPower Off While Charging When plugging your Pinetab into a charger, it automatically powers on. Use the above \u0026ldquo;Reset\u0026rdquo; instruction (holding the power button in for several seconds) to turn it off. This will allow your Pinetab to charge without being powered on.\nDisplay rotated 90° on Arch ARM With the following command you can turn the display to landscape:\necho 1 | sudo tee /sys/class/graphics/fbcon/rotate This command does not persist a reboot.\nAssembly and disassembly Be very careful here. It is not a \u0026lsquo;pop off\u0026rsquo; cover design. Special care should be directed to AVOID anything that may appear to cause a \u0026ldquo;bend\u0026rdquo; in screen.\nGently use fingernails (or if you have one, plastic pry), starting in the very middle location for each side (saving keyboard connector latch over area (bottom side) for the very last removal step).\nWork your way from the inner middle on each side, slowly. Slide gently towards the direction of each corner (saving the lifting of actual corners themselves for the second to last step). Careful not to break thin speaker wires that line the outside of the inner case.\nThe very last opening piece should be the \u0026ldquo;latch over\u0026rdquo; (where the keyboard pins connect).\nKEEP IN MIND: The main key here is to avoid any potential \u0026ldquo;bend\u0026rdquo; of the screen. We save the corners until after working on the middle of each side to reduce pressure on the screen.\nDo not force anything. If it is not coming off with gentle effort, you are likely doing something wrong (try another side middle).\nFurther information Datasheets\nExternal Links\nSchematics and certifications\nSpecifications\nDatasheets Allwinner A64 SoC information:\nAllwinner A64 SoC brief introduction Allwinner A64 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC datasheet LPDDR3 (178 Balls) SDRAM:\nArtmem LPDDR3 datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 64GB SanDisk eMMC Datasheet CMOS camera module information:\nOV5640 5MP CMOS Image Sensor SoC for Rear Module datasheet GC2145 2MP CMOS Image Sensor SoC for Front Module datasheet LCD touch screen panel information:\nGOODiX GT9271 Capacitive Touch Controller datasheet PineTab GT9271 Capacitive Touch Controller configuration file Lithium battery information:\nN/A WiFi/BT module information:\nRTL8723BS/RTL8723CS specification External Links The PineTab on the Pine64 store The PineTab section of the Pine64 forums Comments on back cover removal on forums Demonstration Video: Pinetab back cover removal on forums Schematics and certifications PineTab mainboard schematic:\nPineTab mainboard Released Schematic ver 1.2 PineTab mainboard component placement ver 1.2 - Top View PineTab mainboard component placement ver 1.2 - Bottom View PineTab keyboard schematic:\nPineTab keyboard and Pinebook (Pro) keyboard using same controller and from same engineering source PineTab Keyboard Schematic PineTab keyboard firmware code PineTab Keyboard Controller Datasheet PineTab certifications:\nPineTab FCC Certificate PineTab CE RED Certificate PineTab ROHS Test Report Specifications Dimensions: 11mm x 175mm x 260mm (Thickness, Width, Height) Weight: 575g (Tablet alone) Build: Plastic Storage: 64GB of internal eMMC storage MicroSD slot, bootable M.2 SSD slot, supports SATA and USB devices only, not NVME (optional) Cameras: 2Mpx Front, 5Mpx Rear SOC: Allwinner A64 Quad Core CPU: 4x ARM A53 1.152GHz GPU: Mali 400 MP2 RAM: 2GB LPDDR3 I/O: HD Video Out (Mini HDMI), Micro USB 2.0 OTG, USB 2.0 A host, 3.5mm Headphone/Mic combo, Network: WiFi (802.11b/g/n, 2.4GHz only) Bluetooth 2.1 M.2 LTE / Cell MODEM card, (optional, and takes place of optional M.2 SSD) Display: Size: 10.1 inches (257mm) diagonal Type: HD IPS capacitive touchscreen, 16M colors Resolution: 1280x800, 16:10 ratio Attachments/Accessories: Magnetically attached keyboard (optional) Battery: 6000MAh (6Ah) Misc. features: Volume rocker Speakers and Microphone 2.5mm OD 0.7mm ID DC Jack Power (5V 2A) Port Revisions Developer Edition - development version sent to roughly 100 developers. Close to the Early Adopter Edition, but with a different display panel Early Adopter Edition - the first hardware revision of the PineTab The insides of the PineTab\nPinetab Board\nEarly Adopter Edition The Early Adopter Edition was the first hardware revision of the PineTab which shipped to customers. Shipping began on September 6, 2020.\nSoftware The device shipped with a beta build of Ubuntu Touch by UBports. This build is available to download at https://ci.ubports.com/job/rootfs/job/rootfs-pinetab-systemimage/18/. It has the following problems which are software, not hardware, issues:\nThe mouse fails to move around the entire screen. It is stuck in an 800px horizontal box. It is not possible to enable Bluetooth Cameras do not function Portrait mode does not function The external keyboard is not always detected There is a faint crackling noise on startup Pasting an item on File Manager after Copy/Cut reboots the operating system GUI apps with Libertine are not working, because of missing bits between wayland and Libertine Cannot add accounts (Google, Evernote and other) in System Settings The first-time setup wizard advises the user to unplug the keyboard dock (avoiding the mouse issues) and update the system. Unfortunately, as of this update to this page (September 8, 2020) this will not fix any of the issues above.\n16GB/64GB storage software error The image installed on the device was sized for a 16GB (~14GiB) eMMC, but the PineTab shipped with a 64GB (~58GiB) eMMC chip installed. This means that the \u0026ldquo;Storage\u0026rdquo; page in the \u0026ldquo;About\u0026rdquo; section of Ubuntu Touch System Settings will show total storage as 14.0GiB until the partition table on the device is edited.\nThis is fixed by an update to Ubuntu Touch released to the Stable channel on September 15, 2020. The image’s tag is \u0026ldquo;2020-09-12\u0026rdquo;, visible in Settings -\u0026gt; About -\u0026gt; OS.\nInstalling using apt Installing software on the read-only root filesystem is unsupported on Ubuntu Touch. You should be able to find updates in System Settings -\u0026gt; Updates and new applications in the OpenStore. If you would like to install and use terminal software from the Ubuntu repositories, see Run desktop applications in the UBports Documentation to set up a Libertine container. Unfortunately, graphical software does not yet work through Libertine. This issue is tracked as ubports/libertine#68\nEnabling ssh Naturally, you should be wary of enabling ssh for security reasons but everything is there. Almost.\nEdit /etc/ssh/sshd_config and change the following:\nPasswordAuthentication yes ChallengeResponseAuthentication yes Then run:\n/etc/init.d/sshd start Use user phablet along with your password or PIN to log in.\nWifi Wifi disappears If wifi stopped working, first try usual means:\nswitching wifi off and on again reboot PineTab If it still doesn’t work, open terminal and type this:\nnmcli radio If output is two lines with red word disabled under word WIFI - rejoice, since this issue is known (although it’s not yet investigated well enough to figure out when it happens, so clues to developers are likely welcome). To fix it, just type this in the terminal:\nnmcli radio wifi on Wi-Fi missing if started with keyboard attached Operating system: Ubuntu Touch (OS version: RC#6 (2020-W37))\nSymptom: if you started with keyboard attached wifi will not come up\nReason: the service urfkill is not running\nFix:\nsudo service urfkill restart Wifi radio reception is very weak This needs a tweak! How to open the PineTab?\nTested with UT, Mobian and Archlinux: sitting right beside the router gives a connection (ca. 60% level). No reception in a distance of 7 meters, no wall, just an opened door, some edges, router not directly visible. Pinephone right beside the Pinetab has an absolutly stable wifi connection.\nIn the event that WiFi fails to connect using Ubuntu Touch, the USB port can be used with an appropriate dongle to connect for internet using ethernet cable.\nKeyboard The keyboard attaches magnetically and will correctly link only one way: so screen faces the keyboard.\nThe keyboard backlight automatically comes on when keyboard is attached, but the light can be turned off/on by holding down the Pine (super) key and tapping the right CTRL key which also shows a bulb icon. The keyboard draws its power from the PineTab battery.\nHolding down the Pine key for two seconds and holding it down reveals a popup window of keyboard shortcuts.\nTo access the icon features on the function keys, hold down the Fn key and tap the appropriate key. Ex: F5 and F6 activate volume control (which also has a rocker button on the tablet edge).\n","permalink":"/documentation/PineTab/_full/","tags":null,"title":"PineTab (Single Page)"},{"categories":["Tablets"],"contents":" The PineTab-V: PINE64\u0026rsquo;s first RISC-V tablet The PineTab-V is PINE64’s first RISC-V tablet. It is based on the JH7110 64-bit RISC-V SoC. The packaging is very similar to ARM-based .\nStores Global Affiliates Documentation PineTab-V Schematics and certifications ","permalink":"/devices/pinetab-v/","tags":null,"title":"PineTab-V"},{"categories":null,"contents":" The PineTab-V with the detachable keyboard attached\nThe PineTab-V is PINE64’s first RISC-V tablet. It is based on the JH7110 64-bit RISC-V SoC.\nIntroduction In late 2022, PINE64 announced plans to help grow the RISC-V hardware ecosystem alongside the existing ARM-based device line-up. The PineTab-V is an experimental device, which ships without an OS and without any promises. The JH7110 RISC-V SoC, and the RISC-V architecture in more general, is currently best described as having limited Linux support. You can think of it as a convenient development platform targeted at those of you interested in bringing Linux support to JH7110 and, by extension, the entire RISC-V ecosystem.\nFeatures Front- and backside of the PineTab-V\nBackside of the PineTab-V\nChassis:\nDimensions: 242mm x 161mm x 9mm Weight: 520 grams (without keyboard), 990 grams (includes keyboard) Build: Metal and Plastic Color: Matte Black Display:\nType: HD IPS capacitive touchscreen, 16.7M colors Size: 10.1 inches Resolution: 1280×800 pixels, 16:10 ratio Platform:\nChipset: StarFive JH7110 CPU: 64-bit Quad-core 1.5 GHz SiFive U74 RISC-V GPU: Imagination Technology BXE-4-32 Memory:\nInternal Flash Memory: 64GB (variant 1) or 128GB (variant 2) eMMC module System Memory: 4GB (variant 1) or 8GB (variant 2) LPDDR4 SDRAM Expansion: micro SD Card support SDHC and SDXC, up to 2TB Camera:\nMain Camera: Single 5MP, LED Flash (chipset: Omnivision OV5648) Selfie Camera: Single 2MP (chipset: Galaxycore GC02M2) Sound:\nLoudspeaker: Yes, stereo 3.5mm jack with mic: Yes, stereo Sound IC: ES8316 Wireless:\nChipset: Realtek RTL8852BU WLAN: Wi-Fi 802.11 ax/ac/b/g/n, dual-band, hotspot Bluetooth: 5.2, A2DP I/O:\n1x USB 3.0 Type-C port (front side 3.0, rear side 2.0) 1x USB 2.0 Type-C port (also use as charging and debug port) 1x USB 2.0 Pogo keyboard port 1x microHDMI HD Video output Battery:\nRemovable Li-Po 6000mAh battery Charging: 15W – 5V 3A Model 30100140 from zgszjjy Charge IC: BQ25890H Fuel Guage: CW2015CHBD Variants There are currently two variants of the PineTab-V:\nPineTab-V – 4GB RAM and 64GB eMMC storage PineTab-V – 8GB RAM and 128GB eMMC storage Software Software state\nReleases\nSoftware state The PineTab-V is an experimental device and lacks dedicated working software – it should therefore only be purchased by people interested in helping with the bring-up process of Linux and BSDs on the RISC-V architecture.\nThe second batch released in 2025 includes a Debian \u0026ldquo;Bookworm/Sid\u0026rdquo; operating system created by StarFive. This build includes a lot of old packages and has a snapshot date of 2022/12/25. It is recommended to be used for development purposes only.\nWarning Do not buy the device unless you intend to use it for operating system development purposes. Releases This page contains a list of all available releases and tools for the PineTab-V in alphabetical order.\nFactory releases Batch 2 (2025) The 2nd batch of PineTab-V devices ship with a Debian Bookworm image from StarFive. This can also be flashed to a batch 1 PineTab-V.\ngithub.com/starfive-tech/Debian/releases/tag/PineTab-V-v1.3.0 The instructions for flashing this image can be found in the StarFive PineTab-V release notes document.\nUsername Password user starfive root starfive Batch 1 (2023) The PineTab-V ships with Factory Test Code. The factory test reference source code can be found here:\nPineTab-V_factorytestcode_SDK-20230725.tar.gz from pine64.org (8.36GB, MD5 of the TAR-GZip file: 3e35e2760d82155b024f7601ac2b1275) Community releases:\nsdcard.img pre-built image from the community member Fishwaldo derived from the factory SDK. Note: Use dd to write it to microSD card or the eMMC. Linux Gentoo A Gentoo overlay is available here, it shares most ebuilds for StarFive VisionFive 2 except the kernel source ebuild contains patches from the above factory SDK.\nKDE Plasma Yocto A KDE Plasma Yocto Image from the community member Fishwaldo. Based on the Star64 images developed here. Please see this issue for known problems.\nDownload https://github.com/Fishwaldo/meta-pine64/releases/ Default credentials Root root/pine64 Default user pine64/pine64 Notes Use dd or Balena Etcher to copy to a microSD card and then insert the microSD card into your PineTab-V and boot UART adapter The UART serves as a console for early boot and kernel messages, and also offers access to a root shell in the factory test image.\nConnecting the UART adapter UART Adapter\nThe UART adapter allows access to the UART through the USB 2.0 Type-C port:\nInsert the UART adapter face-up in the USB 2.0 Type-C port (the USB port furthest from the power button). Connect a USB cable from another computer to the port on the adapter marked \u0026ldquo;DEBUG\u0026rdquo;. The green LED on the adapter should light up. The other adapter port can be connected to USB power if you don’t want to run the tablet on its battery. In a terminal window on the other computer, use tio, screen, minicom, or another application that supports serial port communication to connect via USB serial at 115200 bit/s 8N1 (8 data bits, no parity, 1 stop bit):\ntio /dev/ttyUSB0\nscreen /dev/ttyUSB0 115200\nminicom -D /dev/ttyUSB0 -b 115200 Install one of the above from your distribution’s package manager if none are already installed. The device may have a different name, particularly if multiple USB serial devices are connected. On macOS it will have a name like /dev/tty.usbserial-_nnnn_. If Permission denied is reported, you may need to be added to the group that can access the port with a command like sudo usermod -a -G dialout $USER. Then log out and log back in or use a command like newgrp dialout to create a new shell in that group. Ubuntu-based distro users may encounter the error, \u0026ldquo;cannot open /dev/ttyUSB0: No such file or directory\u0026rdquo;. If this occurs, check the output of sudo dmesg --follow and unplug/replug the USB to look for any errors. If you see an error like, \u0026ldquo;usb 1-1: usbfs: interface 0 claimed by ch341 while \u0026lsquo;brltty\u0026rsquo; sets config #1\u0026rdquo;, then the brltty service is likely conflicting with this device. Brltty provides access to blind users who use a braille display; if you do not need this service, try disabling it using these commands:\nsudo systemctl stop brltty-udev.service\nsudo systemctl mask brltty-udev.service\nsudo systemctl stop brltty.service\nsudo systemctl mask brltty.service The switch on the UART adapter has no function on the PineTab-V; the boot order is controlled by the Vol-/Vol+ switches.\nFrequently asked questions What is the Performance of the PineTab2 compared to the PineTab-V?\nThe PineTab2 is notably faster than the PineTab-V. You can see this by comparing the Quartz64 sbc-bench results to the Star64 ones. Performance should not be a factor of consideration when purchasing a PineTab-V.\nFurther information Certifications\nSchematics\nCertifications PineTab-V certifications:\nPineTab-V FCC Certificate PineTab-V CE RED Certificate PineTab-V CE EMC Certificate PineTab-V ROHS Test Report PineTab2/PineTab-V Detached Keyboard CE EMMC Certificate Schematics PineTab-V mainboard schematic:\nPineTab-V mainboard Released Schematic-20240730 ver 2.0 PineTab-V PCB Component Reference location v2.0 (top layer) PineTab-V PCB Component Reference location v2.0 (bottom layer) PineTab-V mainboard Released Schematic-20230614 ver 1.0 PineTab-V PCB Component Reference location v1.0 (top layer) PineTab-V PCB Component Reference location v1.0 (bottom layer) PineTab2/PineTab-V UART Dongle Schematic-20221107 ","permalink":"/documentation/PineTab-V/_full/","tags":null,"title":"PineTab-V (Single Page)"},{"categories":["Tablets"],"contents":" The PineTab2 The PineTab2 is PINE64’s successor to the original PineTab Linux tablet computer, featuring a faster processor and better availability. The tablet is available in two configurations, 4GB of RAM and 64GB of internal storage or 8GB of RAM and 128GB of internal storage. The tablet ships with a detachable keyboard that doubles as a protective cover.\nThe tablet is designed around the Rockchip RK3566 processor, which features 4 energy-efficient Cortex-A55 64-bit ARM cores and enjoys good mainline Linux support. A similarly packaged RISC-V tablet is the PineTab-V.\nStores Global: 4GB/64GB Global: 8GB/128GB Affiliates Documentation PineTab2 Certifications Schematics Specifications ","permalink":"/devices/pinetab2/","tags":null,"title":"PineTab2"},{"categories":null,"contents":" The PineTab2 with the detachable keyboard attached\nThe PineTab2 is PINE64’s successor to the original PineTab Linux tablet computer, featuring a faster processor and better availability. The tablet is available in two configurations, 4GB of RAM and 64GB of internal storage or 8GB of RAM and 128GB of internal storage. The tablet ships with a detachable keyboard that doubles as a protective cover.\nThe tablet is designed around the Rockchip RK3566 processor, which features 4 energy-efficient Cortex-A55 64-bit ARM cores and enjoys good mainline Linux support.\nPre-orders started on the 13th of April 2023, with pricing starting at USD 159 for the 4GB/64GB version and USD 209 for the 8GB/128GB version. The PineTab2 began shipping on June 2, 2023.\nGetting started The PineTab2 box contains two smaller boxes.\nThe first box includes:\nthe PineTab2, a short user guide, a power cable and the UART adapter. Note that the UART adapter is in the same package as the power cable in a second compartment and can be a bit hidden. The second box has the keyboard in it.\nFirst start The PineTab2 can be started by pressing and holding the power button for two seconds. The device is initialized at the first boot and will power-cycle while the partition table is populated.\nInfo If the initialization process is interrupted it might lead to a corrupted operating system installation. In that case reinstall the operating system as explained below. The PineTab2 ships with DanctNix Arch Linux and comes with a pre-set user and the default password 123456.\nDefault credentials alarm 123456 You can create a new user and set your own password after the initial boot. To do so, go to system settings -\u0026gt; users and create a new profile using your preferred name and password.\nKeyboard cover When connecting the keyboard to the Pinetab2 ensure that the camera and the golden pogo pin connectors are correctly aligned. The external keyboard has 5 connection pins (the golden pins). four are standard USB connectors and one is used to detect that the keyboard is connected.\nThe backlight can be changed with the key combination Pinekey + Ctrl (right).\nSoftware Installation instructions\nReleases\nTutorials and FAQ\nInstallation instructions The PineTab2 is capable of running different operating systems from the internal flash memory (eMMC) and from microSD card.\nPreparing the microSD card To write an operating system to the microSD card (typically called \u0026ldquo;flashing\u0026rdquo; in the community), you need to first download a compatible image from the Releases page.\nNext you need to decompress the downloaded image. The images are typically compressed in an archive format such as xz to reduce the download size. If you are using a graphical tool such as balenaEtcher or Gnome Disks it will handle the decompression of the image in the flashing step automatically.\nFurther you need to flash the image to the microSD card. This can be done using various tools, for example balenaEtcher (recommended for new users), Gnome Disks or command-line tools such as cp and dd. Insert the microSD card in a microSD card reader connected to your computer and then choose a tool of your liking.\nGraphical applications:\nbalenaEtcher (Microsoft Windows, macOS, Linux): Click on Flash from file and select the image. Then select the microSD card target device and click on Flash!. Gnome Disks (Linux): Select the microSD card target device on the left side in the Disks list. Then select the three dot menu on the top right and click on Restore Disk Image\u0026hellip;. Select the image, verify the correct device is selected and then click on Start Restoring\u0026hellip;. Command-line tools:\ncp:\nsudo cp IMAGE.img /dev/[DEVICE]\ndd:\nsudo dd if=IMAGE.img of=/dev/[DEVICE] bs=1M status=progress conv=fsync\nNote Make sure to replace IMAGE.img and [DEVICE] with the filename of the image (double check if it is decompressed and has the file extension .img) and the device name. You can use the command lsblk to find the device name. Make sure to flash to the whole device instead of partition 1 and that you’re NOT selecting /dev/sda1 or /dev/mmcblk0p1 as target. Be very careful to select the correct device, as the tools can overwrite your data when the wrong device is selected. Then insert the microSD card into the PineTab2.\nNote The UART adapter\nUsing the USB UART adapter can be required in some cases as explained in the info box about the boot order. The adapter is shipped with the PineTab2 in the box which is also containing the charging cable. The switch to disable the eMMC and SPI is located on the top right of the image.\nNote Note regarding the boot order: The SPI and the internal memory (eMMC) have a higher boot priority than the microSD card. The pre-installed bootloader on the internal memory (eMMC) tries to boot from the microSD card first. In some cases it can be required to bypass the bootloader, for example if the bootloader is corrupted or was overwritten by a bootloader with varying settings.\nTo force the device to boot from the microSD card, the eMMC and the SPI can be disabled by using the debug UART adapter shipped with the device in the box also containing the charging cable. Set the SD BOOT MASKROM switch on the adapter to the position ON and plug it into the USB/PD charging port. Then power on the tablet and unplug the debug board or set the switch to the position OFF again when the factory image is started, otherwise the factory image won’t find the eMMC.\nPower on the device with the microSD card inserted (and optionally with the USB UART adapter inserted and the bypass switch set to ON depending on the software situation, see the info box above). It should now boot the new operating system from the microSD card.\nSomething is not working? Please join the PineTab channel in the community chat, the community is always happy to help. In the page UART adapter you can find information about how to connect the USB UART adapter and how to retrieve the boot logs if the device is not booting properly even after the above procudere.\nReleases This page contains a list of all available releases and tools for the PineTab2 in alphabetical order.\nFactory releases The PineTab2 ships with Danctnix Arch Linux ARM. The latest factory image can be found here:\nhttps://echo.danctnix.org:7269/factory_images/pinetab2/latest/ Note The factory image is flashed to a microSD card and it will overwrite the eMMC installation after booting. Info Newer images use the volume and power button for selection at boot instead of the keyboard. Linux Arch Linux ARM (Unofficial) Arch Linux ARM maintained by the DanctNIX community (GitHub: danctnix, dreemurrs-embedded).\nDownload SD-card boot: https://github.com/dreemurrs-embedded/Pine64-Arch/releases Factory flash images: https://echo.danctnix.org:7269/factory_images/pinetab2/ Default credentials alarm 123456 Notes Currently ships without Bluetooth driver, and Wifi driver is unstable. Shutdown / Reboot sometimes hangs (but not always), this is caused by the Wifi driver. Buildroot Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation.\nAn external tree for the PINE64 PineTab2 is developed and maintained by Danct12 (same developer behind the PineTab2 port of Arch Linux ARM).\nDownload The repository and build instructions can be found here. Fedora Workstation Fedora Workstation is a polished, user-friendly Linux distribution maintained by the Fedora community.\nDownload The Fedora Workstation aarch64 raw.xz image boots normally without requiring additional configuration after being written to an SD card.\nhttps://fedoraproject.org/de/workstation/download Note U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Fedora from an SD card without installing U-Boot. Notes Currently ships without Bluetooth driver. Wifi driver would need manual compilation. LuneOS LuneOS is one of the original multi-tasking OS-es that runs on Linux. Based on HP/Palm’s webOS, merged with latest technology stack from LG called webOS OSE (a derivative of what LG uses on their Smart TV’s), software such as Qt6, Maliit, PulseAudio, Wayland and makes use of the Yocto build system.\nDownload Stable: https://github.com/webOS-ports/luneos-releases/releases/\nTesting: https://github.com/webOS-ports/luneos-testing/releases/\nNote U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Mobian from an SD card without installing U-Boot. Default credentials root no password Notes The development is work in progress, but all hardware that’s supported by the kernel should work (WiFi/BT included). Camera’s aren’t working, similar to all other distros due to lack of drivers. In order to connect to the device using SSH/SCP, you simply can connect to the device’s IP address on port 5522. Teams can be reached via Telegram or Libera IRC #webos-ports Mobian An unofficial Debian build for ARM64 running with Phosh. The current version of the base Debian system is Debian Bookworm. See the installation instructions here. If you have questions about Mobian, please ask them in the Mobian Matrix room.\nDownload Images Note U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Mobian from an SD card without installing U-Boot. Default credentials mobian 1234 Notes The development is work in progress. Mobian’s support for the PineTab2 is maintained by Julian. The Mobian wiki can be found here. In order to connect to the device using SSH/SCP, you need to install SSH on the device. You can do this by executing the following in a shell: \u0026ldquo;sudo apt-get install ssh\u0026rdquo;, afterwards you can connect via SSH/SCP using the PineTab2’s IP address on port 22. When installing Mobian with full disk encryption and booting with the keyboard case connected, you will have to touch the screen or press a key to show the decryption screen. This is an upstream issue. NixOS NixOS is an immutable Linux distribution built around the Nix configuration language. The NixOS image for PineTab2 uses some downstream modifications to packages, such as an U-Boot package based on 2024.04 and the kernel also used by the Arch Linux Arm image.\nDownload https://codeberg.org/raboof/pinetab2-nixos Notes Note that booting can take a while, and does not show anything on the screen. After about 18 seconds the keyboard backlight turns on, then it\u0026rsquo;s about 30 seconds until the first text appears on the screen, and another 10 seconds before the session manager shows up.\nDefault credentials pinetab2 changeme Plasma Mobile on Debian Images of Plasma Mobile on either Debian Bookworm or Debian Trixie created by dieselnutjob\nThe images include uboot, and are an SDcard installer (modified from the Danctnix OS Factory Tool). Using the installer wipes the eMMC drive.\nDownload https://sourceforge.net/projects/pinetab2debianplasmamobile/files/\nDefault credentials pt2 1234 root 1234 Notes The image will not autoexpand to the fill the eMMC, however once booted it is easy to adjust the size of the rootfs using the included KDE Partition Manager.\nThe PineTab2 may be reluctant to shutdown, with several minutes delay whilst the BES2600 wifi driver unloads. This can be avoided by turning off the wifi in the menu that can be pulled down from the top of the screen before shutting down or rebooting.\nThere is a video of the PineTab2 running one of these images here https://www.youtube.com/watch?v=9xpSuG63Rck\nThe author may be contacted via the pinetab discord channel on the Pine64 discord.\npostmarketOS postmarketOS extends Alpine Linux to run on smartphones and other mobile devices.\nIt offers various user interfaces (Phosh, Plasma Mobile, Sxmo, Plasma Desktop, Gnome 3, Kodi, XFCE4 and more). As of writing, this distro is currently in testing and no official releases are available for download. Instead, users will need to create their own image with the distribution’s install and development tool pmbootstrap.\nDownload Pinetab2 Device Page Build the image with pmbootstrap and flash it to an SD. Rhino Linux Rhino Linux is an Ubuntu-based distribution that uses the rolling-release model by tracking the devel branch of repositories. The port is currently maintained by Oren Klopfer (oklopfer).\nThe bootloader (u-boot) comes pre-flashed in the port. Installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload Rhino Linux Downloads (select Pine64 on the dropdown)\nDefault credentials rhino 1234 Notes Foundational to the distribution is Pacstall, a Debian-based user repository inspired by the AUR. Additionally, RL comes with Unicorn, a custom modified version of XFCE with various modernizations and improvements, including auto-rotation for mobile devices.\nDiscord - Matrix - GitHub - Wiki\nUbuntu Touch A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community. The port is currently maintained by Oren Klopfer (oklopfer).\nThe bootloader (u-boot) comes pre-flashed in the port. Installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload UBports 20.04 PineTab2 Latest Releases\nUBports PineTab2 Device Info\nDefault credentials Default user Set during boot root phablet/1234 Notes Scroll down to the middle of the GitLab project page, or directly here at the UBports website to see which features work.\nContributions and bug reports can be made at the UBports PineTab2 GitLab page. See UBports website for how to donate.\nVoid Linux Void is a general purpose operating system, based on the monolithic Linux kernel. Its package system allows you to quickly install, update and remove software. The port is currently maintained by Sinisha Stojchevski (sini6a).\nThe bootloader (u-boot) comes pre-flashed in the port. Installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload VoidLinux PineTab2\nSource Files for PineTab2\nUser Password root voidlinux Notes To enable graphics driver make sure to install mesa-panfrost-dri.\nContributions and bug reports can be made at the GitHub Project Page. See VoidLinux page for more information about the operating system.\nTutorials and FAQ This is a collection of tutorials and frequently asked questions for the PineTab2.\nTutorials Putting the Device into Maskrom Mode To recover from a bad eMMC/SPI flash, plug the included debug adapter into the charging USB-C port and switch the white switch to its \u0026ldquo;ON\u0026rdquo; position to bypass eMMC/SPI boot. This tries to boot from SD, and if no SD is inserted, enters Maskrom mode.\nRecovery from non-booting device Warning You cannot use a virtual machine for this tutorial as rkdeveloptool does not function as intended. Note Before trying this, try the Maskrom instructions above by changing the debug adapter switch to \u0026ldquo;ON\u0026rdquo; to bypass the internal storage to boot the factory image off an SD Card. If this doesn\u0026rsquo;t work you may proceed with this tutorial. There may be situations where the device refuses to turn on and you cannot see anything coming up through UART. This may indicate that your device is bricked. The PineTab2 includes a debug adapter which allows the user to access Maskrom mode. On it\u0026rsquo;s own this mode is useless as the user requires a miniloader from Rockchip to access any rkdeveloptool commands.\nInstall rkdeveloptool\nFirst you must install rkdeveloptool if you haven\u0026rsquo;t already. You can find instructions on the Rockchip wiki.\nClone\ngit clone https://github.com/rockchip-linux/rkdeveloptool.git\nInstall dependencies\nsudo apt-get install libudev-dev libusb-1.0-0-dev dh-autoreconf pkg-config libusb-1.0\nCompile\nautoreconf -i ./configure make make install Put device into Maskrom mode\nThe debug adapter, bottom port is for UART and the top one is for maskrom\nTurn off your PineTab2 by holding the power button for around five seconds. Then grab your debug adapter, make sure the Maskrom switch is in the \u0026ldquo;ON\u0026rdquo; position, plug it into your PineTab2 and plug a USB-C cable into the top port and into your computer.\nCheck that your device is in Maskrom mode by typing lsusb into a terminal. If it displays Fuzhou Rockchip Electronics Company Device then it has successfully entered Maskrom mode.\nTroubleshooting\nIf you only see QinHeng Electronics USB Serial (UART) either try switching USB-C ports on the adapter or plugging in both adapter ports into your computer. Boot miniloader using Maskrom\nTo issue any commands using rkdeveloptool you must first load a Rockchip miniloader through Maskrom.\nNote The zip is hosted directly on this website. Download MiniLoaderAll.bin.zip\nOnce you download and unzip the miniloader, issue this command using rkdeveloptool.\nrkdeveloptool db MiniLoaderAll.bin\nNote This command downloads the loader to the device temporarily. If you powered off the device and wish to enter Maskrom and issue rkdeveloptool commands you must follow the above instructions again. Once the command completes, wait for the device to reappear in lsusb. Make sure it has a different name than before. Be patient as it can take ~20 seconds.\nFuzhou Rockchip Electronics Company Device USB-MSC\nRecovery to factory firmware\nTo make sure the only boot option for the device is via SD Card, erase the internal storage.\nrkdeveloptool ef\nYou will have to wait for a while until it has finished. Once the command has completed, force power off the device and place an SD Card with the DanctNix factory firmware into the card slot.\nDownload factory image\nhttps://echo.danctnix.org:7269/factory_images/pinetab2/\nNote The factory image is flashed to a microSD card and it will overwrite the eMMC installation after booting. Info Newer images use the volume and power button for selection at boot instead of the keyboard. Screen Rotation Auto-rotating the Screen Auto-rotation is handled by your operating system. However, the following general steps should work on distributions that support iio-sensor-proxy:\nTo enable auto-rotation, install the iio-sensor-proxy package: sudo pacman -S iio-sensor-proxy and reboot. Some desktop environments, such as KDE, default to only allowing screen rotation while in tablet mode (detached from the case.) To enable it with the keyboard attached, go to System Settings\u0026ndash;\u0026gt;Display and Monitor -\u0026gt; Display Configuration -\u0026gt; Uncheck \u0026ldquo;Only when in tablet mode\u0026rdquo; and click \u0026ldquo;Apply.\u0026rdquo; Rotating the Login Screen Login screen orientation is handled by your operating system. Below are the instructions for the SDDM login screen that ships with the factory image:\nBy default, the login screen is set to display in portrait mode. If you wish to change it to landscape mode to match the keyboard while in the case, use the following steps (Credit to chzbacon) :\nInstall necessary software: sudo pacman -S xorg-xrandr xorg-xinput Edit /usr/share/sddm/scripts/Xsetup. For example, using nano: sudo nano /usr/share/sddm/scripts/Xsetup and add the following two lines to the end of file: xrandr --output DSI-1 --mode 800x1280 --rate 60.00 --rotate right xinput set-prop \u0026quot;pointer:Goodix Capacitive TouchScreen\u0026quot; --type=float \u0026quot;Coordinate Transformation Matrix\u0026quot; 0 1 0 -1 0 1 0 0 1 Now edit /etc/sddm.conf.d/sddm.conf, for example: sudo nano /etc/sddm.conf.d/sddm.conf and add the following two lines (case sensitive): [X11] DisplayCommand=/usr/share/sddm/scripts/Xsetup Reboot, and your login screen should now display in landscape mode. Frequently Asked Questions General How does the PineTab2 compare to the Pinebook Pro? It’s slower, as it is intended to be a successor to the PineTab1, not the Pinebook Pro. It’ll still handle web browsing, video playback and documents fine though.\nWhat is the Performance of the PineTab2 compared to the PineTab-V? The PineTab2 is notably faster than the PineTab-V. You can see this by comparing the Quartz64 sbc-bench results to the Star64 ones. Performance should not be a factor of consideration when purchasing a PineTab-V.\nI am a casual user with minimal Linux experience. Is this device for me? The PineTab 2 is considered early release at this point, and the community is expected to develop support for it over time. For example, the Known issues page details several features that are not yet fully working. You may at times need to troubleshoot this device and some development experience is ideal if you want to realize the tablet’s full potential at this stage.\nFor these reasons, the PineTab2 may not be the ideal device for casual users. However, if you feel up to the challenge and want to learn while joining a great community, you are more than welcome! Please join one of our chat platforms: the community is always happy to help!\nWhat works, what doesn\u0026rsquo;t? Please see Known issues.\nI only know Python, can I help with drivers? Drivers are (at least typically) written in the C programming language. Unfortunately, there is no way to \u0026ldquo;code drivers in Python\u0026rdquo; because usually drivers need to access and process memory allocation directly. If you feel like this is interesting to you, we suggest you to spend some time learning the C programming language, maybe with an emphasis in device driver development. The good news is that, since you already know a programming language, you already know part of the skill.\nIn short, you can only help with drivers development if you learn the C programming language first.\nHardware Does the Tablet support a Pen? No, adding a digitiser for pen inputs would make the price too high.\nIs there SPI Flash? Yes! A 128 Mbit flash chip (sk25lp128) is reportedly present on production devices.\nSoftware What operating systems are currently available? The PineTab2 uses ARM operating systems. Please see Software for a current list of software releases.\nHow can I install an operating system on the SD card / eMMC? See the article Software.\nCan I run Android on it? Theoretically yes, practically there’s little chance anyone wants to make a well-supported Android build for this device. If you’re looking for an Android tablet, buy any mainstream tablet, and you’ll get better value for your money.\nHowever, if you just need to run a few simple android apps, you might want to have a look at Waydroid which can be installed on Arch Linux ARM using the following command: sudo pacman -S waydroid\nBooting What\u0026rsquo;s the boot order for SD cards and eMMC? The SPI and the internal memory (eMMC) have a higher boot priority than the microSD card. Please see the Software for more detailed information.\nCan I install a different OS on my PineTab2? Yes! While all PineTab2 come with an OS preinstalled, you are free to use any OS on the integrated storage (the eMMC) or an SD card. See Software for how to install them.\nBluetooth The Bluetooth isn\u0026rsquo;t working The BES2600 Bluetooth driver still needs to be implemented. Please see the Networking Using USB section above for a workaround.\nWi-Fi The Wi-Fi isn\u0026rsquo;t working The BES2600 Wi-Fi driver needs major cleanup and bugfixing: at the moment it causes system crashes. Please see the Networking Using USB section for a workaround.\nVideo Can PineTab2 play back DRM content such as Netflix? Yes, though the specific implementation depends on your installed operating system.\nOn the default Arch Linux Arm: Widevine, using the widevine-aarch64 package in the AUR is working, and was demonstrated on the PineTab2 using Paramount+ and Disney+. Install it (yay -S widevine-aarch64), run the included register script to get Firefox to recognize it, and it should start working.\nDevelopment See the related page Quartz64 development.\nLinux mainline is already quite far along for the device, as the SoC is the same as is used in the Quartz64 line of devices. Some minor PineTab2-specific adjustments can be found here.\nKnown issues Wi-Fi and Bluetooth The BES2600 Wi-Fi driver needs major cleanup and bugfixing (at the moment it often causes system crashes). This is a priority, but for now, you can USB tether a phone or use a supported WI-FI dongle. There are at least two code releases available, with two respective/non-interchangeable firmware versions. Kernel 6.9.2-danctnix1-1-pinetab2 has a somewhat working WiFi driver. The BES2600 Bluetooth driver needs to be implemented. Hardware bugs - the power and reset circuitry is not properly implemented in the circuitry, so hard reset of the chip (in the theoretical case it freezes) is impossible without power cycling the whole board. Camera The camera drivers needs to be ported (gc02m2, ov5648), Rockchip CSI/ISP driver needs to be extended to handle 2 lanes. Suspend Suspend does not currently work reliably due to a driver issue. It is therefore disabled in the factory image. Caveat Emptor if you chose to unmask the feature prior to it being fixed. UART adapter The UART adapter\nThe USB-C UART adapter can be connected to the PineTab2 to debug boot issues at the early boot:\nPlug the adapter face-up in the USB-C port furthest away from the power button. If all the lights are lit, you have the wrong port: only the green light should be lit when you first plug it in. Plug USB-C cable into the port on the adapter marked \u0026ldquo;DEBUG\u0026rdquo; (the other port can be used as a power delivery passthrough so you can charge and debug at the same time) Set the \u0026lsquo;SD BOOT MASKROM\u0026rsquo; switch to OFF if no SD card is inserted and you do not plan to boot from an SD card. If the switch is set to ON without an SD card present, the tablet may fail to boot. Open a terminal window Install minicom or screen via your distribution’s package manager, if you don’t have it installed already Connect via minicom using sudo minicom -D /dev/ttyUSB0 -b 1500000 or via screen using sudo screen /dev/ttyUSB0 1500000 Ubuntu-based distro users may encounter the error, \u0026ldquo;cannot open /dev/ttyUSB0: No such file or directory\u0026rdquo;. If this occurs, check the output of sudo dmesg --follow and unplug/replug the USB to look for any errors. If you see an error like, \u0026ldquo;usb 1-1: usbfs: interface 0 claimed by ch341 while \u0026lsquo;brltty\u0026rsquo; sets config #1\u0026rdquo;, then the brltty service is likely conflicting with this device. Brltty provides access to blind users who use a braille display: if you do not need this service, try disabling it using these commands: sudo systemctl stop brltty-udev.service sudo systemctl mask brltty-udev.service sudo systemctl stop brltty.service sudo systemctl mask brltty.service Further information Certifications\nDatasheets\nDisassembly guide\nSchematics\nSpecifications\nCertifications PineTab2 certifications:\nPineTab2 FCC Certificate PineTab2 CE RED Certificate PineTab2 CE EMC Certificate PineTab2 ROHS Test Report PineTab2/PineTab-V Detached Keyboard CE EMMC Certificate Datasheets Rockchip RK3566 SoC information:\nRockchip RK3566 ver 1.0 datasheet Rockchip RK3566 and RK3568 TRM (Technical Reference Manual) Disassembly guide PineTab2 disassembly guide:\nFile:PineTab2 display panel disassembly guide.pdf Note: this is a very delicate operation, especially around the corners of the screen. Several even experienced users damaged their screen when disassembling the device. Schematics PineTab2 mainboard Schematics:\nPineTab2 mainboard Released Schematic-20230417 ver 2.0 PineTab2 PCB Component Reference location v2.0 (top layer) PineTab2 PCB Component Reference location v2.0 (bottom layer) PineTab2/PineTab-V UART Dongle Schematic-20221107 Specifications SoC: Rockchip RK3566 CPU: 4x ARM Cortex-A55 @ 1.8 GHz 32KB L1 Instruction Cache and 32KB L1 Data Cache per core 512KB unified system L3 cache ARMv8 Cryptography Extensions GPU: Mali-G52 MP2 @ 800 MHz Supported by the open source \u0026lsquo;Panfrost\u0026rsquo; driver in Linux and Mesa Supports OpenGL 3.1 and OpenGL ES 3.1 with many newer extensions NPU: 0.8 TOPS Neural Processing Unit RAM: 4GB or 8GB LPDDR4 Storage: 64GB or 128GB internal eMMC (SiliconGo SGM8 100C-S36BCG; eMMC 5.1, up o 400MB/s) 1x MicroSD slot Display: 10.1\u0026quot; IPS LCD Resolution 1280x800 Cameras: Front: 2Mpx, chipset: Galaxycore GC02M2 Rear: 5Mpx, chipset: Omnivision OV5648 Battery: 6000 mAh (22.2Wh) Buttons: Power, volume up, volume down Network: Wi-Fi: BES2600 Driver under development, use a USB wifi dongle for now Bluetooth: BES2600 I/O: 1x USB-C 3.0 (top, host mode only; power output up to 680mA) 1x USB-C 2.0 + PD (bottom, device mode by default; power input) 1x MicroHDMI 1x 4 pole 3.5mm audio jack (microphone right) and headphone detection 2x speakers + microphone (microphone left) 1x 5 pin (USB 2.0; \u0026lt;=680mA) Pogo connector for keyboard (PCIe on PCB as a flat flex ribbon connector, no room for M.2 NVMe drives in case) Sensors: Accelerometer: Silan SC7A20 Ambient Light \u0026amp; Proximity Sensor Multimedia: rkdjpeg: 1080p120 JPEG decode hantro: JPEG/VP8/H.264 encode, 1080p MPEG-2/H.263/VP8/H.264 AVC decode rkvdec2: 4K H.264 AVC Main10 L5.1/H.265 HEVC Main10 L5.1/VP9 Profile 0 and 2 L5.1 decode rkvenc2: 4K H.264 AVC/H.265 HEVC encode Build: Metal and Plastic Dimensions: 242x161x9mm Weight: 538g Misc: Protective cover with keyboard ","permalink":"/documentation/PineTab2/_full/","tags":null,"title":"PineTab2 (Single Page)"},{"categories":["Smartwatches"],"contents":" An Open Source Smartwatch For Your Favorite Devices. Low Cost, High Fidelity. The PineTime is a free and open source smartwatch capable of running custom-built open operating systems. Some of the notable features include a heart rate monitor, a week-long battery, and a capacitive touch IPS display that is legible in direct sunlight. It is a fully community driven side-project which anyone can contribute to, allowing you to keep control of your device.\nWe envision the PineTime as a companion for not only your PinePhone but also for your favorite devices — any phone, tablet, or even PC. In its current state the PineTime ships with a community firmware called Infinitime, which works with Linux computers and phones, Windows machines, and Android devices. IOS support is currently being looked into for Infinitime.\nFeatures and Specifications Display Square 1.3-inch 240×240 IPS capacitive touch display SoC Low-power Nordic Semiconductor nRF52832 64 MHz + Floating Point Software Any open-source operating systems built on top of numerous RTOSes Body Dimensions: 37.5mm x 40mm x 11mm Weight: 38 grams Made with Zinc alloy and plastic Dustproof and water-resistant up to 1m (rated at IP67) Health Tracking Step Counting (with Accelerometer) Heart rate detection Notification features Notification access Wrist vibration Quick glance via lift-to-wake. Connectivity Bluetooth 5 and Bluetooth Low Energy Compatible with almost any device Over-the-air update Storage 4 MB of User Storage 0.5 MB of OS Storage Battery All-week 180 mAh battery 2-pin USB charging dock IPS touch display The PineTime includes a color IPS capacitive touch display\nDustproof And Water Resistant The PineTime comes with a IP67 rating, meaning that it can handle up to one meter of water and is fully dust proof\nBluetooth 5 With Bluetooth 5 and Bluetooth Low Energy, the PineTime can pair to other devices\nHeartrate And Step Counting With a built-in accelerometer and heart-rate sensor, the PineTime can help you keep track of your health\nStores Global Global: Accessories Affiliates Documentation PineTime Datasheets, schematics and certifications Resources YouTube: WaspOS with a custom star trek theme YouTube: Elatronion’s review of the PineTime YouTube: A review of Infinitime version 1.0.0 on the PineTime ","permalink":"/devices/pinetime/","tags":null,"title":"PineTime"},{"categories":null,"contents":" The PineTime is a free and open source smartwatch capable of running custom-built open operating systems. Some of the notable features include a heart rate monitor, a week-long battery, and a capacitive touch IPS display that is legible in direct sunlight. It is a fully community driven side-project which anyone can contribute to, allowing you to keep control of your device.\nThe PineTime\nGetting started Read these first:\nDevkit wiring Reprogramming the PineTime (development kit) The frequently asked question can be found in the article FAQ.\nAccessory Cases\nWatch band\nCases There are no cases for PineTime yet, but some cases for Fitbit are suitable for it. Cases for Fitbit have one microphone hole, which is unnecessary for the PineTime, but otherwise they fit perfectly (such as the Soft TPU case for Fitbit Versa 2/Versa Lite).\nThe community designed the following cases:\nPineTime Smart Watch case by dara0s at thingiverse PineTime Flexible Cover by AmbiSpace at thingiverse PineTime dev kit back fix by joaquimorg at thingiverse PineTime dev kit charging holder v4 by zevix81 at thingiverse PineTime Charger Travel Case by brett at PrusaPrinters Watch band The PineTime uses a standard 20mm watch band / strap. There is a thread in the forum discussing this.\nDue to the watches design. Retention for the spring bars are recessed into the watch. Not all 20mm bands / straps work. This is especially the case for Nato style bands / straps being too thick.\nKnown working bands:\nBISONSTRAP 20mm Quick Release Silicone Watch Band / Amazon US DMVEIMAL 20mm Quick Release Watch Band Metal Strap / Amazon US Morsey 20mm Quick Release Watch Band / Amazon US BINLUN 20mm Canvas Quick Release Watch Strap / Amazon US Hardware Display Note: The factory-default software on the PineTime does not auto-detect the display being disconnected when it has already booted. That can cause garbled output, to fix it just restart the PineTime.\nThe display is driven using the ST7789 display controller. Use the following pins to drive the screen:\nPineTime pin ST7789 pin LCD_SCK (P0.02) SPI clock LCD_SDI (P0.03) SPI MOSI LCD_RS (P0.18) Command/Data pin (CD) LCD_CS (P0.25) Chip select LCD_RESET (P0.26) Display reset LCD_BACKLIGHT_{LOW,MID,HIGH} Backlight (active low) Notes:\nChip select must be held low while driving the display. It must be high when using other SPI devices on the same bus (such as external flash storage) so that the display controller won’t respond to the wrong commands. SPI must be used in mode 3. Mode 0 (the default) won’t work. LCD_BACKLIGHT_* is used to enable the backlight. Set at least one to low to see anything on the screen. Use SPI at 8MHz (the fastest clock available on the nRF52832) because otherwise refreshing will be super slow. References:\nAdafruit ST7789 driver in cpp\nBattery measurement Reading whether the PineTime has power attached is easy: simply read the charge indication pin (P0.12). When it is high it is running on battery, when it is low it is charging.\nReading the battery voltage is a bit harder. For that you can use the battery voltage pin on P0.31 (AIN7). The returned value is 12 bits, which means it is 0..4095. You can get the measured voltage with the following formula, assuming a reference voltage of 3.3V (this is configurable in the ADC):\nadcVoltage = adcValue / (4095 / 3.3) The measured voltage is actually half of the actual battery voltage, because the ADC is connected between a voltage divider where both resistors are 1MΩ. This can be corrected by multiplying the value:\nbatteryVoltage = adcValue * 2 / (4095 / 3.3) It’s often better to avoid floating point values on embedded systems and in this case there is no reason to use float at all, we can just represent the value in millivolts. Therefore the formula can be simplified to:\nbatteryVoltage = adcValue * 2000 / (4095 / 3.3) batteryVoltage = adcValue * 2000 / 1241 Converting this voltage to an estimated capacity in percent requires a more complicated algorithm, because Lithium-ion batteries have a non-linear discharge curve.\nButton The button on the side of the PineTime is disabled by default. To enable it, drive the button out pin (P0.15) high.\nWhile enabled, the button in pin (P0.13) will be high when the button is pressed, and low when it is not pressed.\nNote the button consumes around 34µA when P0.15 is left high. To reduce current consumption, set it to low most of the time and only set it to high shortly before reading it. The button needs a short time to give good outputs though, setting P0.15 high at least four times in a row seems to result in enough delay that P0.13 has a stable output. Touch panel The touch panel is controlled by a Hynitron CST816S chips. Unfortunately, there is not much information about this chip on the internet apart from the datasheet below and a reference driver. This is enough to implement a basic driver, but crucial information needed to implement advanced functionalities are missing (I²C protocol and registers, timings, power modes).\nPins P0.10=== What do you need to know? If you followed Dorian’s guide to get here and felt semi-comfortable, you’ll be fine. This is no more complicated than that. If you are intimidated, that’s okay! I’ll still encourage you to try. You will learn a lot, just be patient and don’t put any data on your PineNote that you wouldn’t be okay losing. If you run into trouble, ask for help in the Discord / Matrix. Please try to solve problems on your own first, and then ask for help \u0026ndash; if nobody replies, please be patient and ask again soon.\nReset\nP0.28: Interrupt (signal to the CPU when a touch event is detected) P0.06: I²C SDA P0.07: I²C SCL I²C Device address: 0x15 Frequency: from 10Khz to 400Khz Note The controller goes to sleep when no event is detected. In sleep mode, the controller does not communicate on the I²C bus (it appears disconnected). So, for the communication to work, you need to tap on the screen so that the chip wakes-up. Note The I²C bus, also known as TWI bus has known issues, make sure to write your TWI driver with timeouts. Touch events Touch information is available from the 63 first registers of the controller. Remember: the device is in sleep mode when no touch event is detected. It means that you can read the register only when the touch controller detected an event. You can use the Interrupt pin to detect such event in the software.\nThese 63 bytes contain up to 10 touch point (X, Y, event type, pressure,\u0026hellip;) :\nByte Bit7 Bit6 Bit5 Bit4 Bit3 Bit2 Bit1 Bit0 0 ? 1 GestureID: (Gesture code ,\n0x00: no gesture,\n0x01: Slide down,\n0x02: Slide up,\n0x03: Slide left,\n0x04: Slide right,\n0x05: Single click,\n0x0B: Double click,\n0x0C: Long press)\n2 ? Number of touch points 3 Event (0 = Down, 1 = Up, 2 = Contact) ? X (MSB) coordinate 4 X (LSB) coordinate 5 ? Touch ID Y (MSB) coordinate 6 Y (LSB) coordinate 7 Pressure (?) 8 Miscellaneous (?) Bytes 3 to 8 are repeated 10 times (10*6 + 3 = 63 bytes).\nNOTES\nThe touch controller seems to report only 1 touch point Fields X, Y, Number of touch points and touch ID are updated. The others are always 0. Registers The reference driver specifies some registers and value, but there is no information about them:\nRegister Address Description HYN_REG_INT_CNT 0x8F HYN_REG_FLOW_WORK_CNT 0x91 HYN_REG_WORKMODE 0x00 0 = WORK, 0x40 = FACTORY HYN_REG_CHIP_ID 0xA3 HYN_REG_CHIP_ID2 0x9F HYN_REG_POWER_MODE 0xA5 0x03 = SLEEP (reset the touchpanel using the reset pin before using this register: pin_low, delay 5ms, pin_high, delay 50ms then write 3 to register 0xA5) HYN_REG_FW_VER 0xA6 HYN_REG_VENDOR_ID 0xA8 HYN_REG_LCD_BUSY_NUM 0xAB HYN_REG_FACE_DEC_MODE_EN 0xB0 HYN_REG_GLOVE_MODE_EN 0xC0 HYN_REG_COVER_MODE_EN 0xC1 HYN_REG_CHARGER_MODE_EN 0x8B HYN_REG_GESTURE_EN 0xD0 HYN_REG_GESTURE_OUTPUT_ADDRESS 0xD3 HYN_REG_ESD_SATURATE 0xED 0xED Accelerometer The on board accelerometer in devices shipped before July 2021 is a Bosch BMA421, connected to the I2C bus. Devices shipped after July 2021 use a Bosch BMA425 accelerometer.\nPins P0.06: I²C SDA P0.07: I²C SCL P0.08: Interrupt I²C Device address: 0x18\nReducing power consumption The PineTime appears to be able to sleep with a current consumption of only 66µA.\nTo investigate current consumption, it’s a good idea to disable everything possible to get the lowest current consumption possible, and then re-enable things one by one. Here is one way to get a baseline current consumption of 0.60µA, as measured from the 3.3V pin with the battery disconnected:\nEnable the DC/DC regulator. This doesn’t affect the current consumption while sleeping, but almost halves the runtime current consumption. Use the low-frequency (32.768kHz) oscillator. Leave all pins in their default state, except for P0.05 (SPI CS) and P0.25 (LCD CS) which should be configured as an output and set to high. Put the heart rate sensor in sleep mode by setting the PDRIVER (0x0C) register to 0, see the HRS3300 datasheet for details. Put the SPI flash in deep power-down mode by setting flash CS high, then low, then writing the byte 0xb9 on the SPI bus, and then setting flash CS high again. Sleep in a loop, using WFE or WFI (if you’re using the Nordic SoftDevice, call sd_app_evt_wait instead). Here are some current consumption statistics (current consumed in addition to the baseline power), roughly ordered from large to small:\nSource Current Notes SWD 3.05mA Power cycle the chip after programming to avoid this, it can hide other inefficiencies. LCD 5.61mA Set the LCD to sleep mode when not used, using SLPIN. Backlight high 12.27mA Backlight mid 5.51mA Backlight low 1.83mA ADC left enabled 1.3mA Stopping SAADC brings the current back to the baseline. It seems that it doesn’t need to be disabled entirely. Edge triggered pin interrupts 0-0.47mA? It appears that under some configurations, edge triggered interrupts result in a large power drain. One way to avoid this is by using the pin sense mechanism. BUTTON_OUT left high 0.04mA See Button for how to avoid this. SPI flash sleep mode 0.014mA Sleep mode still consumes power. Put it in deep power down mode to avoid this. SPI, I2C (negligible) SPI and I2C appear to consume very little power when idle, around 1µA or less. Software Bluetooth\nCompanion apps\nDefault OS\nFirmware versioning for companion apps\nInfiniTime\nInfiniTime weather\nReprogramming the PineTime\nUpgrade PineTime to InfiniTime 1.0.0\nBluetooth This page is under construction, but aims to get you more familiar with Bluetooth and how the PineTime utilizes it\nPineTime Bluetooth LE agreements These are aimed for firmware developers primarily, and should describe how to design your firmware to be interoperable with the rest.\nFirmware versioning for companion apps External references Uncovering Privacy Leakage in BLE Network Traffic of Wearable Fitness Trackers - http://phpathak.com/files/hotmobile-fitness.pdf Protecting Privacy of BLE Device Users - https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_fawaz.pdf Bluetooth: With Low Energy Comes Low Security - https://www.usenix.org/conference/woot13/workshop-program/presentation/ryan Introduction to Bluetooth Low Energy development - https://devzone.nordicsemi.com/nordic/short-range-guides/b/getting-started/posts/introduction-to-bluetooth-low-energy-and-ble-devel Companion apps PineTime/InfiniTime needs a companion app to e.g. upload a firmware, get notifications from a phone, or just get the date/time. Here are some companion apps:\nGadgetbridge (Android \u0026gt;= 4.4) - Companion mobile app, supports updating firmware/bootloader, send notifications, etc. Amazfish (SailfishOS, Ubuntu Touch and Linux) - Companion mobile and desktop app, supports updating firmware/bootloader, send notifications, etc. Watchmate (Linux) Siglo (Linux) - Companion desktop app. PinetimeFlasher (Windows) - Companion desktop app, only supports flashing firmware. nRFConnect (iOS) - Only supports flashing firmware. The app is closed source and versions after 4.24.3 don’t work for the PineTime anymore InfiniLink (iOS) - Companion mobile app in development. Supports updating firmware/bootloader, setting date and time, Apple Music controls, and battery and heart rate data. ITD (Linux) Default OS The current default operating system on the PineTime is called InfiniTime, you can find more information about the firmware on its GitHub page. First devkits shipped with a proprietary custom firmware.\nYou can find a list of available firmware and other software here: Development\nFirmware versioning for companion apps BLE defines a standard service (Device Information Service, DIS) that allows BLE devices to expose information about them: hardware version, software version.\nCompanion apps will use these information to detect which firmware (or fork of a firmware) is running on the Pinetime they are connected to.\nHow to use the Device Information Service to differentiate firmwares? We’ve briefly talked about this on the community chat and this proposal is the result of this discussion. This is a request for comments.\nFields from the Device Information Service:\nField Description Example value Manufacturer name Manufacturer PINE64 Model number Name of the device \u0026ldquo;PineTime\u0026rdquo;, \u0026ldquo;P8\u0026rdquo; Serial number Not needed by companion apps as they can use the BLE MAC address ? Hardware revision Version of the hardware 1.0a Software revision Project name or fork name \u0026ldquo;InfiniTime\u0026rdquo;, \u0026ldquo;InfiniTime-forkname\u0026rdquo;, \u0026ldquo;Hypnos\u0026rdquo; Firmware revision Version of the firmware \u0026ldquo;0.7.1\u0026rdquo; InfiniTime InfiniTime InfiniTime (also known as JF’s project, FreeRTOS firmware or Pinetime-JF) is an open source (GPLv3) firmware written in {cpp} and based on FreeRTOS, LVGL and NimBLE. This firmware (version 0.7.1) is preloaded at the factory since the new batch of PineTime devkits and sealed PineTimes of end of September 2020. This page contains general information about the project. Actual project documentation and nuances are documented in the repository\nGitHub repo: https://github.com/InfiniTimeOrg/InfiniTime Official website: https://infinitime.io/ Read this first! InfiniTime and the bootloader are still in heavy development, and some features might not work as expected. Any issues should be reported on GitHub. Do not use a sealed PineTime as a development device, there is a fair amount of chances that you’ll brick it with very experimental firmware. OTA is relatively stable, but when you’re on an outdated bootloader version it can freeze which will require you to wait for the battery to run out. Known issues Warning Please read this section carefully before upgrading the firmware on your PineTime, especially if you are using a sealed device! Black screen after a reset in sleep mode Description This issue occurs if you are using the original bootloader (from InfiniTime 0.7.1), upgraded from InfiniTime 0.7.1 to 0.8.2 and the watch resets while the display is OFF: the watch is stuck on a black screen and does not respond to touch, button press or BLE.\nThe reset can be triggered by the watchdog or manually by long pressing the button. If that doesn’t work, wait for the battery to run out, it’ll reboot then.\nThis issue is caused by InfiniTime 0.8.2 that put the external SPI flash memory to sleep before switching the display off and by the bootloader that cannot wake the memory chip up. The bootloader is stuck in an infinite loop.\nMore info: https://github.com/lupyuen/pinetime-rust-mynewt/issues/24 and https://github.com/JF002/InfiniTime/issues/60\nWorkaround On a development kit, a simple reset via SWD is needed to unlock the bootloader.\nOn a sealed device, the only way to work around this issue is to wait for the battery to drain completely before trying again.\nThis issue can be avoided by ensuring that the display is ON when manually resetting the device (long push on the button).\nFixed version This issues is fixed in InfiniTime 0.8.3\nReleases In the order of oldest first.\nVersion 0.7.1 Link: Version 0.7.1\nThis is the version that ships with PineTime devkits and sealed PineTime as of September 2020.\nTime synchronization over BLE Display brightness setting Notifications over BLE Integration with AmazFish (SailFishOS) and Gadgetbridge (Android) OTA using NRFConnect Bootloader: https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v4.1.7\nVersion 0.8.2 Link: Version 0.8.2\nMusic control app Paint app Manual image validation after OTA Bootloader: https://github.com/lupyuen/pinetime-rust-mynewt/releases/tag/v5.0.4.\nThis new version of the bootloader fixes Black screen after a reset in sleep mode and enables the watchdog before launching the firmware.\nVersion 0.8.3 Link: Version 0.8.3\nFixes the \u0026ldquo;bootloader stuck after a reset\u0026rdquo; mentioned in 0.8.2 above Version 0.9.0 Link: Version 0.9.0\nTouch panel fixed (no more freezing) Improved music application (possibility to control both volumes and browsing, display the song progression) Notification UI rewritten: can now display up to 100 characters Improved BLE connectivity Version 0.10.0 Link: Version 0.10.0\n2 new games: Pong and 2048 Fixed display glitches and improved needed time to turn on the display Version 0.11.0 Link: Version 0.11.0\nHeart-rate sensor application: Displays the current value, and when running, this value is also displayed on the clock face Value exposed over BLE, meaning other applications can read it (e.g. companion app such as Amazfish) Navigation app: InfiNav - works e.g. with PureMaps on SailfishOS Version 0.12.0 Link: Version 0.12.0\nImproved BLE connection OTA updates much more reliable Version 0.13.0 Link: Version 0.13.0\nVibration Call notification: it is possible to accept/ignore/reject a call from the PineTime Music app got nicer icons BLE connectivity improved a bit more Version 0.14.0 \u0026ldquo;Green Avocado\u0026rdquo; Link: Version 0.14.0 \u0026ldquo;Green Avocado\u0026rdquo;\nLVGL 7 Bugfixes to the build process Version 0.14.1 Link: Version 0.14.1\nNew Recovery firmware MCUBoot based bootloader Version 0.15.0 \u0026ldquo;Yellow Banana\u0026rdquo; Link: Version 0.15.0 \u0026ldquo;Yellow Banana\u0026rdquo;\nAnalog watch face Support for switching watch faces Stopwatch app Version 1.0.0 \u0026ldquo;Red Cherry\u0026rdquo; Link: Version 1.0.0 \u0026ldquo;Red Cherry\u0026rdquo;\nMotion sensor integration Step countin UI redesign Quick action menu: Brightness setting Do not disturb mode (disable vibrations on notifications) Flash light application Settings menu allowing configuration of: Display timeout Wakeup source (button only, single tap, double tap and wrist rotation) Time format (12/24H) Watchface New navigation flow: User settings stored in flash memory and restored on reset Version 1.1.0 \u0026ldquo;Dragon Fruit\u0026rdquo; Link: Version 1.1.0 \u0026ldquo;Dragon Fruit\u0026rdquo;\nSteps application Timer application UI improvements Clang-format and clang-tidy config files Bugfixes Version 1.2.0 \u0026ldquo;Blue-purple Elderberry\u0026rdquo; Link: Version 1.2.0 \u0026ldquo;Blue-purple Elderberry\u0026rdquo;\nAdded support for alternate accelerometer part BMA425 Metronome app Memory usage optimizations Bugfixes, minor improvements and code cleanup Version 1.3.0 \u0026ldquo;Purple Fig\u0026rdquo; Link: Version 1.3.0 \u0026ldquo;Purple Fig\u0026rdquo;\nLittleFS integration New watchface, PineTimeStyle Battery level notification on BLE (supported by Gadgetbridge) Improved stopwatch app, Paddle game and call notifications Firmware update app is now more foolproof The SPI flash is put in sleep mode when the watch goes to sleep (only if the new bootloader is detected) UI improvements (better \u0026rsquo;tick\u0026rsquo; handling in LVGL, more consistent refresh rate) Various improvements and code cleaning Version 1.4.0 \u0026ldquo;Pink Grapefruit\u0026rdquo; Link: Version 1.4.0 \u0026ldquo;Pink Grapefruit\u0026rdquo;\nImproved touch driver Color customization for background, text and lateral bar of PineTimeStyle UI improvements for better use of the small screen, and screen dimming before display sleeps Call notification improvements Battery level improvements Attempts to fix bootloop issue Version 1.5.0 \u0026ldquo;Huckleberry\u0026rdquo; Link: Version 1.5.0 \u0026ldquo;Huckleberry\u0026rdquo;\nAlarm app Vibration improvements Ability to recover time after a reset BLE improvements Battery level improvements Version 1.6.0 \u0026ldquo;Ice Apple\u0026rdquo; Link: Version 1.6.0 \u0026ldquo;Ice Apple\u0026rdquo;\nA new BLE Fix Version 1.7.0 \u0026ldquo;Jackfruit\u0026rdquo; Link: Version 1.7.0 \u0026ldquo;Jackfruit\u0026rdquo;\nMore accurate battery percentage Faster wakeup (video) New touch handler Wake on notification and charge Memory usage and speed optimizations Motion service (video) Flashlight brightness changes Manual date and time setting Battery percentage reporting Disabled Touch Controller error check Paddle game bounds checking Version 1.7.1 Link: Version 1.7.1\nTouchscreen failure edge case Version 1.8.0 \u0026ldquo;Fuzzy Kiwi\u0026rdquo; Link: Version 1.8.0 \u0026ldquo;Fuzzy Kiwi\u0026rdquo;\nImproved gesture consistency Digital watchface: Changed the color of the BLE icon to the official \u0026ldquo;Bluetooth™ blue\u0026rdquo; PineTimeStyle: Integrated color picker into the watchface (long tap on the PTS watch face, and then tap on the gear icon that appears to open the color settings) * PineTimeStyle: Fixed alignment of the icons Settings: Styled checkboxes as radio buttons Paddle: Speed randomization InfiniPaint: Vibration on color change (long tap to change color when running InfiniPaint) BLE secure pairing BLE file system API Weather service (integrations are planned for the future) Trip meter in Step app Chimes: Short vibration every hour or half an hour. Settings are available in the 3rd page of settings Shake to wake: The calibration of the sensitivity is available in the 3rd page of settings Version 1.9.0 \u0026ldquo;Limeberry\u0026rdquo; Link: Version 1.9.0 \u0026ldquo;Limeberry\u0026rdquo;\nTerminal watchface Enable/Disable BLE InfiniSim, the LVGL simulator for InfiniTime Improve notification and call notification timeout Improve heart-rate measurements Improve Alarm App Better 12-hours mode integration (in settings, alarm and status bar) Code cleanup and many improvements needed by InfiniSim Fix display corruption when the timer is triggered Fix freeze in Music app when the title/album name were too long Version 1.10.0 \u0026ldquo;Yellow Mango\u0026rdquo; Link: Version 1.10.0 \u0026ldquo;Yellow Mango\u0026rdquo;\nNotifications can now be dismissed by right swiping on the notification Faster sleep New sharper battery icon Timer UI was overhauled Tweaked and improved display gamma to improve the colors displayed by the LCD Flashlight now defaults to max brightness Fixed track progress in Music app Fixed alarm sometimes not ringing Version 1.11.0 \u0026ldquo;Red Nectarine\u0026rdquo; Link: Version 1.11.0 \u0026ldquo;Red Nectarine\u0026rdquo;\nAbility to install external resources, such as watch faces, images, and fonts. Created a document to better communicate the vision of InfiniTime project to users, developers and everyone else Compatibility with LFCLK calibration and reduced the power consumption of Nimble Limit backlight brightness when flashlight is off Watch face inspired by the G7710, with day of year and week number info (+ battery level %) Infineat watch face + its external resources Added pink color for PinetimeStyle watch face PineTimeStyle watch face : make step count display configurable (full gauge for step count, half gauge with seconds and numerical display of the step count). Oneshot 1.11 - FOSDEM 2023 Edition Link: Oneshot 1.11 - FOSDEM 2023 Edition\nOneshot version, which was created for the \u0026ldquo;Free and Open source Software Developers\u0026rsquo; European Meeting\u0026rdquo; Digital and analog watchfaces with FOSDEM’s logo as the background Version 1.12.0 \u0026ldquo;Olallieberry\u0026rdquo; Link: Version 1.12.0 \u0026ldquo;Olallieberry\u0026rdquo;\nProject maintenance Added Watchmate to the list of companion apps Better battery level monitoring, and battery indicator alert Date and time settings are combined into a single setting page Updated settings list style Version 1.13.0 \u0026ldquo;Pomegranate\u0026rdquo; Link: Version 1.13.0 \u0026ldquo;Pomegranate\u0026rdquo;\nNew heart rate processing algorithm, provides more accurate and faster results New memory management (heap unification) Weather integration in PineTimeStyle watch face Major power optimizations Bug fix in shake wake InfiniTime weather Infinitime features a weather subsystem which stores weather data on the watch in a timeline which can be queried by apps or watchfaces. It can store many different types of data (see here) and each entry includes a timestamp and an expiry time. When entries expire they are removed from the timeline automatically.\nSending weather data to the watch Weather data must be sent to the watch via a companion app. Currently, ITD and Gadgetbridge have this functionality implemented.\nITD ITD is the easiest option as the feature simply needs enabling in the config file with a location specified. It uses data from MET.no and provides one hour of data at a time.\nGadgetbridge Gadgetbridge is slightly more difficult to set up as it requires a separate app to fetch the weather data. Details are available on the Gadgetbridge website.\nDisplaying weather data Currently there are 2 ways to display weather data on the watch, a debug app which is disabled by default, and the PineTimeStyle watchface. To enable it, press and hold on the watch face, tap the settings icon and enable weather.\nThe easiest way to enable the debug app is to change the entry for the navigation app in DisplayApp.cpp to load the weather debug app instead:\ncase Apps::Navigation: //currentScreen = std::make_unique\u0026lt;Screens::Navigation\u0026gt;(this, systemTask-\u0026gt;nimble().navigation()); currentScreen = std::make_unique\u0026lt;Screens::Weather\u0026gt;(this, systemTask-\u0026gt;nimble().weather()); break; Reprogramming the PineTime Introduction The PineTime Dev Kit comes with the back not glued down to allow it to be easily reprogrammed, however the kit does not include an hardware programmer/debugger.\nBefore you can use your debugger/programmer, you probably have to wire up your pinetime. Heavily recommended you read this first.\nThere is a bewildering variety of different hardware programmers available but whatever programmer you have there are only a few tasks you will have to learn about:\nUnlocking the device Note: PineTime watches shipped after 20 Sep 2020 do not require unlocking. They are shipped unlocked. Uploading new software Running a debugger All of these are described in this article.\nUnlocking the device is a one-time action that is needed to enable the debug port and provide full access to the device. Unlocking the device will erase all existing software from the internal flash.\nSWD Pinout See Devkit wiring\nnrfjprog (for Segger JLink) The following steps have been tested with the Segger JLink embedded in the NRF52-DK development board.\nHookup Connect the Pinetime SWD pins to the debugger (P20 on NRF52-DK)\nPinetime JLink GND GND SWDCLK SWDCLK SWDIO SWDIO VCC (3.3V) VTG (target detect) Unlocking the FLASH Unlocking the device and erase the memory.\nYou need to execute this step only once, to remove the read protection on the memory. Note that it will erase the whole flash memory of the MCU| :\nnrfjprog -f NRF52 --recover Uploading new software Program the BLE softdevice (if needed by the firmware). Replace PATH_TO_NRF_SDK by the path where you unzipped the NRF52 SDK :\nnrfjprog -f NRF52 --program /PATH_TO_NRF_SDK/components/softdevice/s132/hex/s132_nrf52_6.1.1_softdevice.hex --sectorerase Program the firmware (replace firmware.hex by the actual filename of the firmware):\nnrfjprog -f NRF52 --program firmware.hex --sectorerase Reset and run the new firmware:\nnrfjprog -f NRF52 --reset OpenOCD OpenOCD, the Open On-Chip Debugger supports multiple different adapters. You can read more about it here: https://openocd.org/\nAdapters These examples allow you to use telnet to issue futher commands to the devkit. Using them you can connect to 127.0.0.1 (localhost) port 4444 using telnet and invoke OpenOCD commands. GDB should also be available on port 3333.\nYou can simplify your life by creating a configuration file that contains the interface, transport, target and speed configuration. Things like CLion also need one to work properly.\nIf you aren’t using the latest version of OpenOCD, you might need to substitute things in these examples with older syntax (e.g. instead of adapter speed it’s adapter_khz).\nCMSIS-DAP This is a generic specification that is supported by a bunch of different hardware, things such as DAPLink also use it.\nIssue this command to initialize a connection to the devkit:\nopenocd \\ -c 'source [find interface/cmsis-dap.cfg]' \\ -c 'transport select swd' \\ -c 'source [find target/nrf52.cfg]' \\ -c 'adapter speed 8000' \\ -c 'init' JLink Start OpenOCD:\nopenocd \\ -c 'source [find interface/jlink.cfg]' \\ -c 'transport select swd' \\ -c 'source [find target/nrf52.cfg]' \\ -c 'adapter speed 8000' \\ -c 'init' Raspberry Pi openocd \\ -c 'source bcm2835spi' \\ -c 'bcm2835spi_speed 31200' \\ -c 'source [find target/nrf52.cfg]' \\ -c 'init' STLink Connect PineTime SWD Pins to ST-Link v2 as follows:\nPineTime ST-Link GND GND SWDCLK SWDCLK SWDIO SWDIO VCC (3.3V) 3.3V Note that only the bottom row of pins on ST-Link are used.\nTo flash PineTime with ST-Link on Linux and macOS, use PineTime Updater\nST-Link can’t be used to remove nRF52 flash protection\nUnlocking the device If you need to disable access port protection then you can do this using the following commands below.\nThis can be done in two ways:\nAppending this to OpenOCD command line:\n-c 'nrf52.dap apreg 1 0x04' -c 'nrf52.dap apreg 1 0x04 0x01' -c 'nrf52.dap apreg 1 0x04' Or by using the telnet connection, just type in telnet localhost 4444 and then you can issue commands to OpenOCD:\nNote: Unlocking the device to remove access port protection will erase the contents of flash.\ntelnet localhost 4444 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger \u0026gt; nrf52.dap apreg 1 0x04 0x00000000 \u0026gt; nrf52.dap apreg 1 0x04 0x01 \u0026gt; nrf52.dap apreg 1 0x04 0x00000001 (If the nrf52.dap command cannot be found, try just dap instead.)\nUploading new software Just issue this command, replace code.hex with your own (and cmsis-dap.cfg with an appropriate adapter).\nopenocd \\ -c 'source [find interface/cmsis-dap.cfg]' \\ -c 'transport select swd' \\ -c 'source [find target/nrf52.cfg]' \\ -c 'init' \\ -c 'halt' \\ -c 'nrf5 mass_erase' \\ -c 'program code.hex verify' \\ -c 'reset' \\ -c 'exit' Black Magic Probe BlackMagic Probe is an JTAG/SWD adapter with open-source firmware, allowing for it to be ported to a multitude of different boards. One of it’s defining features is lack of need for intermediate software such as OpenOCD - one would just need to connect to the GDB server running on the chip and proceed with debugging. For more information, refer to wiki.\nNative adapters The native adapters are the official Black Magic family of debug adapters, including the original Black Magic Probe and the Black Magic Probe Mini. By buying the official hardware you are supporting the continued development of the Black Magic Probe software.\nProviding your native adapter is running up-to-date firmware then it can be used to program your PineTime.\nSTM32 (Blue Pill) It is possible to flash a popular development board based on STM32F103C8T6 microcontroller, known as Blue Pill, to make a BlackMagic Probe device. For example, one may follow instructions in forum post or gist (mac os). Also, it is possible to use SWD pins on the board to flash other devices, instead using arbitrary pins on the board itself. See this link for more detals.\nOther hardware The Black Magic Probe firmware can be run on a variety of host devices. See BMP Debugger Hardware for more information.\nUsing the BMP to flash the PineTime Refer to the BMP wiki for the full description of commands. Overall, the process on Linux is like following. (/dev/ttyBmpGdb is a symlink created by the udev rule). It’s useful to create a gdb script file (or .gdbinit) with following commands:\ntarget extended-remote /dev/ttyBmpGdb monitor swdp_scan attach 1 file %firmware file% Then one may use load command to flash the firmware, compare-sections to verify the upload, or monitor erase_mass to erase the firmware.\nThen, proceed with debugging as normal.\nExternal links and additional tutorials https://github.com/jlukanc1/pinetime-boot-flasher https://blog.aegrel.ee/absniffer-cmsis-dap-sniffer.html https://blog.dbrgn.ch/2020/5/16/nrf52-unprotect-flash-jlink-openocd/ https://medium.com/@ly.lee/openocd-on-raspberry-pi-better-with-swd-on-spi-7dea9caeb590 https://medium.com/@ly.lee/build-and-flash-rust-mynewt-firmware-for-pinetime-smart-watch-5e14259c55 Upgrade PineTime to InfiniTime 1.0.0 Note Devices shipped before July 2021 were pre-installed with InfiniTime 0.7.1 and an older bootloader. This features green text PINE TIME on boot, and should be updated to the new bootloader as described below.\nNewer devices already have a \u0026gt;=1.0.0 bootloader and do not need updating. You can identify these with a green Pinecone image on boot.\nWarning Do not follow these steps on devices which shipped with the 1.0.1 bootloader or later. You will downgrade the bootloader and (soft-)brick your watch! Congratulations on receiving your new PineTime!\nSo now you’re probably wondering exactly how on earth do you go about upgrading your watch to the latest and greatest version of InfiniTime - you know, that version you’ve seen all those great pictures, videos and reviews of. To those of us that are developing stuff for it, it’s pretty easy and straightforward, but like with all technology, it is a bit tricky.\nWarning Some people ran into issues during the update process that would temporarily make their watch unusable (display frozen or blank). The only know workaround consists of waiting for the battery to drain completely and try again. With the display off, and battery fully charged, you can expect a wait of 5-7 days so it is best to not fully charge it. If it freezes with the display on, it will likely be flat by the end of the day. We’ve never heard of any PineTimes that were permanently bricked (were not recoverable), though. In a nutshell, you need to:\nCharge your watch, but not to 100% - keep it at approximately 50% - for the reason described above. Update InfiniTime Update the bootloader Install the recovery firmware Update Process So how do you do this? Where do you start? Well, with a sealed PineTime, your only easy option is via Over The Air (OTA) Device Firmware Update (DFU), which is done via Bluetooth. There are a couple of different ways and apps you can use to do this. If you have an Android device, you can use Gadgetbridge or NRFConnect (NRFConnect is available on iOS devices as well). Otherwise, if your laptop or desktop computer has Bluetooth and runs Linux, you can use Siglo or Amazfish. You can also use these applications on your Pinebook Pro or Pinephone if you happen to have those devices.\nThe reason for installing the updates in the specified order is because newer versions of InfiniTime have a more robust Bluetooth update process, and since we’re updating everything over Bluetooth, the fewer retries and failures from that you have the better. It will still sometimes disconnect mid update, meaning you’ll need to try again, and possibly restart the watch a few times as well. And since the recovery firmware is new to the 1.0.0 version of the bootloader, it’s best to update that last.\nThis video shows the bootloader and recovery firmware installation procedure.\nThis video shows the bootloader installation and firmware update using Amazfish.\nYou can also read a detailed installation procedure in the documentation of the bootloader.\nUpdate InfiniTime To update the main InfiniTime app, you want to flash pinetime-mcuboot-app-dfu-1.0.0.zip.\nAfter updating InfiniTime, ensure that you validate the firmware to prevent it from being automatically reverted/rolled back if your watch is reset/restarted. To do this, swipe right to access the quick actions panel, press the gear/settings icon, swipe up once to show the second page, press on the \u0026lsquo;Firmware\u0026rsquo; option and then on \u0026lsquo;Validate\u0026rsquo;.\nVideo showing validation process\nGadgetbridge Connect your PineTime to GB Download the aforementioned file to your phone Find the file in your file manager \u0026lsquo;Open With\u0026rsquo; Gadgetbridge F/W Installer (method varies by device) - on my phone, it is press and hold, select the file, and then choose \u0026lsquo;open with app\u0026rsquo; from the more options menu Confirm that you wish to apply the update Wait for the update to complete Video showing how to start the update\nNRFConnect (not recommended) The app is closed source and versions after 4.24.3 don’t work with the PineTime. We recommend you use GadgetBridge instead.\nDownload the aforementioned file to your phone. Open NRFConnect Scan for your device Connect to it Choose the DFU option at the top right of the screen Ensure the \u0026lsquo;Distribution packet (ZIP)\u0026rsquo; option is selected, and press OK Select your previously downloaded file Wait for the update to complete Video showing how to start the update\nSiglo If your device was not detected upon start, press \u0026ldquo;Rescan\u0026rdquo; to find it. Select the \u0026ldquo;1.0.0\u0026rdquo; tag Select the aforementioned file/asset. Select \u0026ldquo;Flash It!\u0026rdquo; Amazfish Run Amazfish (service + UI) Pair with you device: Unzip the DFU file to extract the .bin file. Click on \u0026ldquo;pair with watch\u0026rdquo; on the top Select \u0026ldquo;PineTime\u0026rdquo; (if your device is running InfiniTime 0.7.1 or lower) or \u0026ldquo;InfiniTime (if it’s running InfiniTime 0.8+) and choose your device in the list Click on \u0026ldquo;Download file\u0026rdquo; on the top Click on \u0026ldquo;Choose file\u0026rdquo; and select the .bin file you extracted from the DFU file Click on \u0026ldquo;Send file\u0026rdquo; Wait for the update to complete. See it in action!\nUpdate the bootloader To update the bootloader, you want to flash reloader-mcuboot.zip. Once the bootloader is updated, you should notice that the boot logo has changed. Previously, it was a green \u0026ldquo;PineTime\u0026rdquo; logo, and now it is a large pinecone that is progressively drawn in green.\nVideo showing what the InfiniTime 1.0.0 bootloader looks like\nUsing Gadgetbridge Same process as before, but with the file for this step.\nUsing NRFConnect Same process as before, but with the file for this step.\nUsing Siglo Same process as before, but select the \u0026ldquo;0.14.1\u0026rdquo; tag, and the file/asset for this step.\nUsing Amazfish You may need to re-pair with your device by selecting \u0026ldquo;InfiniTime\u0026rdquo; (since you’ve already upgraded to InfiniTime 1.0) in the device type list. Then follow the same process as before, but with the file for this step.\nInstall the recovery firmware Warning Don’t do this before updating the bootloader, otherwise your PineTime will freeze at the end of the process, and you will need to wait for the battery to go flat To install the recovery firmware, you want to flash pinetime-mcuboot-recovery-loader-dfu-0.14.1.zip. You will know when this is running when it shows an InfiniTime logo with a progress bar running across the bottom whilst it is installing the recovery firmware.\nUsing Gadgetbridge Same process as before, but with the file for this step.\nUsing NRFConnect Same process as before, but with the file for this step.\nUsing Siglo Same process as before, but with the file/asset for this step.\nUsing Amazfish Same process as before, but with the file for this step.\nTroubleshooting Sometimes during the update process, the connection will drop, and the update will fail. Your PineTime isn’t broken, most likely the Bluetooth link dropped for a moment, so just try again. Try rebooting your phone, if it keeps failing, try restarting the watch by holding the power button down for approximately 8 seconds. Try to avoid holding down the button with the screen off. Or try with another device, just in case there are compatibility issues.\nVersion 1.0.0 of InfiniTime is merely the first version that was considered sufficiently feature-complete and stable enough for daily use. This isn’t to say there aren’t still bugs present (\u0026lsquo;cause there are!). So there are a few bugs still present in the update process and the bootloader. One unfortunate bug appears to be that sometimes when the watch tries to restart after an update, the bootloader locks up, and the watch won’t turn on. In this case, you will need to wait until the watch battery goes flat, to force the watch to reset. This will most likely involve waiting for a week, and then when you put the watch on the charging cradle, it will power up and you should be right to try again.\nIf you get stuck or have any questions, join us on your preferred chat platform or the product forum. There’s usually someone available who can help, or will get back to you in a few hours.\nFlashing External flash partitioning\nSD MCUBoot\nExternal flash partitioning The partition table Partitions on a storage (disk of flash memory) have different sizes depending on the type of data they contain. Size and location for those partitions could vary along the time, specially if the operating systems (\u0026ldquo;firmware\u0026rdquo; on embedded systems) are changed or the same OS is upgraded and it has the need of reestructuring the partitions. In any case, an index has to describe the partition structure somewhere.\nWhat is the basic info to know about a storage partitions?\nThe offset address: indicates where the partion starts on the storage. The partition size: how long is the partition from its offset address. The partition type: identifies what is the usage of the data contents. Where to store the partition entries To put that index of partitions hardcoded with the firmware is a bad idea. How to know if those partitions are initialized with the expected data type? What if the user decides to try another OS and it initializes the the partitions just like the developer has decided to do so? Installed OS has to check the rightness of the storage on every boot? Definitely, the index of partitions must be out of the own OS code in order to keep organized the data on the flash memory.\nPC Nowadays, personal computers use partition tables on every disk (see GPT and MBR). This partitions tables are located very close to the beginning of the disk (reserving some initial sector of bytes for old bootloaders). However, this partition tables are designed for very large disks and they have some complexity related to PC and its computer history, not really needed for flash memories.\nSBC Single board computers and embedded systems with the U-Boot bootloader store the partition index as parameters in the mtdparts environment variable and it is passed to the OS as argument. This environment is hardcoded or stored in a defined partition as text. More recently, they use Device tree but this is also stored in a partition.\nESP32 ESP32 is a MCU managing partitions without hardcoded information and it is a good example to examine. It defines a partition table of 3Kb length at a fixed position with capacity to define 95 partitions. Maybe some excessive but the interesting thing is that partition table follow the pattern \u0026ldquo;offset-size-type\u0026rdquo; as basic information.\nThe summing-up is that every system using partition index and not hardcoded stores the partition entries in some storage space and, this partition table, can be considered a little partition too. It is located in a well-know offset address of the flash storage.\nPaper PineTime is a device under open development and it offers undreamed possibilities to develop and to flash several firmwares by users. It might be convenient that external storage (SPI flash) can be accessed by using a partition table so, different firmwares will be able to share partitions with user information, settings, bluetooth bindings, calibration parameters.\nFor example, it is possible to organize the flash to save a logo shown by the bootloader. And it doesn’t mean a mandatory requirement at the moment but bootloader or application can be changed and they will be able to found the logo to show or save a customized one.\nWhat is the cost of managing a partition table? In this case, community (developers) should be discuss and publish a paper with a proposal for the partition table structures and implement in their firmware for the PineTime. It must be simple and suitable in order to organize the flash storage in partitions without more overhead than read the partition table, look for the partitions those are interested in and use them.\nPartition table draft-#0 Location of partition table: first page of external flash (256 bytes).\nC structures C code:\n#define OFFSET_T uint32_t #define SIZE_T uint32_t /* bits 0-7 is type, bits 8-15 is subtype, bits 16-31 are flags */ #define TYPE_T uint32_t struct partition_entry_t { OFFSET_T offset; SIZE_T size; TYPE_T type; }; struct partition_table_t { uint32_t magic_bytes; /* always 0x50494e45 (\u0026#34;PINE\u0026#34;) */ uint32_t reserved[2]; /* reserved, do not use */ partition_entry_t entries[20]; /* 20*sizeof(partition_entry_t) == 240 */ uint32_t checksum; /* CRC-32 MPEG2 variant (used by MCU bootloader) */ }; #define PARTITION_TYPE_NOT_USED\t0x00 #define PARTITION_TYPE_BOOT_LOGO 0x01 #define PARTITION_TYPE_FACTORY_IMG 0x02 #define PARTITION_TYPE_LITTLE_FS 0x03 SD MCUBoot The Problem PineTime ships with the MCUBoot bootloader which boots to the InfiniTime Firmware This assumes that the firmware (InfiniTime, Mynewt, Zephyr, \u0026hellip;) has its own Bluetooth LE (BLE) stack and can handle firmware updates (DFU) But some firmware (wasp-os, ATCwatch) require Nordic SoftDevice to be installed to support the BLE and DFU functions InfiniTime Firmware does not support flashing of SoftDevice as firmware update, because SoftDevice is usually flashed at address 0x1000 (plus a 4k MBR at 0 to switch between the bootloader and the softdevice), which is used by the MCUBoot Bootloader How do we allow SoftDevice-based firmware to be flashed to PineTime via DFU? Dual Bootloader Modes Process PineTime will support 2 Bootloader Modes: MCUBoot and SoftDevice. Default is MCUBoot Mode. The two bootloaders will not coexist, they will be mutually exclusive. This allows a different flash ROM map for each bootloader. To switch from MCUBoot Mode to SoftDevice Mode:\nWe will use DFU to flash a SoftDevice Loader Firmware, which will boot and replace MCUBoot by SoftDevice Thereafter, when PineTime boots, it will start SoftDevice and will be ready to accept SoftDevice-based firmware for DFU: wasp-os, ATCWatch To switch from SoftDevice Mode to MCUBoot Mode:\nWhen we need to switch back to MCUBoot-based firmware (InfiniTime, Mynewt, Zephyr, \u0026hellip;), we will run an MCUBoot Loader (based on https://github.com/daniel-thompson/wasp-reloader ) to replace SoftDevice by MCUBoot plus a Minimal DFU Firmware that accepts DFU commands After rebooting, MCUBoot starts the Minimal DFU Firmware, which will accept MCUBoot-based firmware for flashing The MCUBoot-based firmware replaces the Minimal DFU Firmware Switching modes with Companion App The PineTime Companion App (e.g. Gadgetbridge) will switch modes automatically depending on the firmware to be flashed. So PineTime Owners will never have to switch modes themselves. For SoftDevice-based firmware, the Companion App will also know which SoftDevice version is needed by the firmware, and load the right SoftDevice version. Custom MBR It’s possible to customize (SoftDevice’s) MBR so that it can coexist with MCUBoot.\nPros:\nSeamless switching between the two different boot modes. Both MCUBoot and SD can be used. Cons:\nTechnically more complex - documentation isn’t the best, SoftDevice’s future support for custom MBR might be unknown Should be explored further.\nExternal resources about custom MBR https://devzone.nordicsemi.com/f/nordic-q-a/27599/boot-sequence-for-nrf52832 https://aykevl.nl/2018/01/mbr-softdevice-internals https://forum.pine64.org/showthread.php?tid=9779\u0026pid=65203#pid65203 wasp-reloader wasp-reloader is a simple bare-metal C program that, in a fairly brutal fashion, can rewrite critical parts of the internal flash. It has fairly robust checksumming to avoid flashing problems and verifies that what it written is what is supposed to be written. Having said that more checks (no self-overwrite, battery level) would be nice. When complete it stops updating the watchdog in order to provoke get a clean reset. As a standalone app it can be loaded into the secondary slot using Infinitime DFU upgrade.\nCurrently it has linker scripts for SD132 V6.1.1 and can flash any payload smaller than SD132.\nTo be used to install SoftDevice from mcuboot it would need linker scripts for mcuboot (to ensure the reloader sits high enough in flash to avoid a self-overwrite). To install mcuboot we need an Intel HEX file of the mcuboot payload and InfiniTime (we have to write it in one shot to keep BLE updates working after switching bootloaders). This may need custom linker scripts depending on how big the InfiniTime binaries are.\nWatchfaces Custom watchface\nPineTimeStyle\nCustom watchface This is a tutorial to help new users create custom watchfaces based on the InfiniTime Firmware for PineTime made by user JF002, thanks to him for its development.\nWe will explain some of the things we went through while creating some custom Watchfaces, so consider this as a log of experiments of sorts..\nSo stay tuned to it as it will be dynamically updated.\nWhat you need to start The entire building process will be done by GitHub, so all you need is a device which can give you a GitHub Web Client, a PC, or tablet to give you enough screen space to review your code and a steady internet connection.\nSince the compiling and file management is done by GitHub online, you have nothing else to worry about other than working with the files that display the watch face.\nSo with those things settled, let’s start with the basics of a watchface.\nPlease remember that this is a public documentation, so you can make an account and help us improve this page.\nPlease make sure not to unilaterally remove info though, but offer an alternative. If it is indeed a better way, in time your alternative will grow into the main text, and the latter info will be pruned.\nOverview The Firmware (also called InfiniTime) we will be working with is made with a programming language named C++.\nBasic knowledge of C/{cpp} is required to understand the advanced watch faces as that requires more complex code, but you can still do a some cool things without much knowledge of {cpp} programming, just some small edits to existing programs.\nInfiniTime uses the LVGL graphics library to provide users with a simple and clean UI without overpowering the Nordic nRF52832 microcontroller, which is the brain of the watch.\nTo get the watchface to work, there are these basic steps. We will go over each step separately, so don’t be daunted, all will become clear soon.\nFor now, we will modify the existing watchface, change the positioning of the text labels, add an icon to an existing watchface and later on, we will do a full watchface.\nThe main file we need to focus on is the WatchFaceDigital.cpp file, which contains most of the data attributed to what we see on the watchface, including The time/day characters, the battery, and Bluetooth icons, and also pedometer count.\nSo, everything we will be doing in the basic modifications is purely messing with this single file.\nLabels What are labels? Labels are considered as \u0026ldquo;elemental\u0026rdquo; parts that make up a screen’s Text-based UI by the LVGL library. Each label is also considered as an \u0026ldquo;object\u0026rdquo; or \u0026ldquo;obj\u0026rdquo; and can be manipulated. By changing the data attributed with the \u0026ldquo;obj\u0026rdquo;, for example, position, internal data like the strings/text etc. we can change what the label shows and where it shows it.\nModifying label data let’s observe something small like the word \u0026ldquo;BPM\u0026rdquo; near the bottom of the watch face.\nIf we take a look at the source file of the watchface, (a.k.a. the clock.cpp file) we can observe that these particular lines are what attributes to the word \u0026ldquo;BPM\u0026rdquo; being displayed.\nheartbeatBpm = lv_label_create(lv_scr_act(), NULL); lv_label_set_text(heartbeatBpm, \u0026#34;BPM\u0026#34;); We can modify the text inside the quotes and replace the word \u0026lsquo;BPM\u0026rsquo; between those quotes to something like \u0026lsquo;LOVE\u0026rsquo; and the result after compiling the firmware again with the changes and flashing it to the watch would be that the text changes on the watch face and displays \u0026lsquo;LOVE\u0026rsquo; in place of \u0026lsquo;BPM\u0026rsquo;.\nIf this happened correctly, then you have successfully made a custom new watchface|Now we can do something a bit more complex.\nNow take for in instance the days of the week that we have on the bottom line with the date.\nthey are stored a \u0026ldquo;C array\u0026rdquo; which is basically multiple words separated by commas.. the date is in a format of which in the source file is expressed as,\nsprintf(dateStr, \u0026#34;%s %d %s %d\u0026#34;, DayOfWeekToString(dayOfWeek), day, MonthToString(month), year); lv_label_set_text(label_date, dateStr); here,\n%s %d %s %d stores the print format of the variables, and\nDayOfWeekToString(dayOfWeek), day, MonthToString(month), year are the variables themselves\nNow, if the date was a Saturday 11/7/2020, you can observe that the date looks like\nSATURDAY 11 JUL 2020 as seen in the above image (the one where we changed BPM to LOVE)\nby modifying the format of the variables, we can change how those words are arranged, and add some extra characters if we like (there is a catch to the list of characters you can use however, but it will be discussed later)\nFor example,\nIf we modify the format by adding a comma \u0026ldquo;,\u0026rdquo; in between the second \u0026ldquo;%s\u0026rdquo; and \u0026ldquo;%d\u0026rdquo; like this,\n\u0026#34;%s %d %s, %d\u0026#34; and changing that in the line\nsprintf(dateStr, \u0026#34;%s %d %s, %d\u0026#34;, DayOfWeekToString(dayOfWeek), day, MonthToString(month), year); we can make the date become\nSATURDAY 11 JUL, 2020 which means we now were able to modify how the text got displayed to make it a bit more nice\nbut if you haven’t noticed, the line containing the date is already full, meaning we will get some problems while displaying the date and causing it to wrap around, making a single character go to the next line and look more like,\nSATURDAY 11 JUL, 202 0 So, why don’t we shorten the characters present in the date from being \u0026ldquo;SATURDAY\u0026rdquo; to simply just \u0026ldquo;sat.\u0026rdquo; (It will have the small period at the end, and is only 3 characters long). I will also convert the months of the year from Capital to small letters.\nFor that look into the part where the days of the week of are stored as text, and also while looking at it, we can solve another question, why was there two variables in the date format that looked like, DayOfWeekToString(dayOfWeek), and MonthToString(month) ?\nIt is because the system gives the date/ time as numbers (Monday-1, Tuesday-2 Wednesday-3 for the days, and 1-January, 2-February, 3-March ), and so, a function along with a C array is used to assign these numbers to Days/Months in text form as it is easier to read.\nthis is the Array containing the day of the week, (as text)\nchar const *Clock::DaysString[] = { \u0026#34;\u0026#34;, \u0026#34;MONDAY\u0026#34;, \u0026#34;TUESDAY\u0026#34;, \u0026#34;WEDNESDAY\u0026#34;, \u0026#34;THURSDAY\u0026#34;, \u0026#34;FRIDAY\u0026#34;, \u0026#34;SATURDAY\u0026#34;, \u0026#34;SUNDAY\u0026#34; }; and this Array stores the months of the year, (as text)\nchar const *Clock::MonthsString[] = { \u0026#34;\u0026#34;, \u0026#34;JAN\u0026#34;, \u0026#34;FEB\u0026#34;, \u0026#34;MAR\u0026#34;, \u0026#34;APR\u0026#34;, \u0026#34;MAY\u0026#34;, \u0026#34;JUN\u0026#34;, \u0026#34;JUL\u0026#34;, \u0026#34;AUG\u0026#34;, \u0026#34;SEP\u0026#34;, \u0026#34;OCT\u0026#34;, \u0026#34;NOV\u0026#34;, \u0026#34;DEC\u0026#34; }; Here we can see that the days are stored in a full format as \u0026ldquo;SUNDAY\u0026rdquo;, \u0026ldquo;MONDAY\u0026rdquo;, \u0026ldquo;TUESDAY\u0026rdquo; etc. We can change all of them to a shorter format like \u0026ldquo;sun.\u0026rdquo;, \u0026ldquo;mon.\u0026rdquo;, \u0026ldquo;tue.\u0026rdquo;, to make it short and nice. While doing so, we can even make the months use small letters, as said before.\nso the source file (clock.cpp) becomes,\n(for the days of the week)\nchar const *Clock::DaysString[] = { \u0026#34;\u0026#34;, \u0026#34;mon.\u0026#34;, \u0026#34;tue.\u0026#34;, \u0026#34;wed.\u0026#34;, \u0026#34;thu.\u0026#34;, \u0026#34;fri.\u0026#34;, \u0026#34;sat.\u0026#34;, \u0026#34;sun.\u0026#34; }; and\n(for the months of the year)\nchar const *Clock::MonthsString[] = { \u0026#34;\u0026#34;, \u0026#34;jan\u0026#34;, \u0026#34;feb\u0026#34;, \u0026#34;mar\u0026#34;, \u0026#34;apr\u0026#34;, \u0026#34;may\u0026#34;, \u0026#34;jun\u0026#34;, \u0026#34;jul\u0026#34;, \u0026#34;aug\u0026#34;, \u0026#34;sep\u0026#34;, \u0026#34;oct\u0026#34;, \u0026#34;nov\u0026#34;, \u0026#34;dec\u0026#34; }; which means now our original date, Saturday 11/7/2020 will become\nsat. 11 Jul, 2020 you now know how to change the data present in a label object, and the format of it..,\nHere is a fun idea you can try: you can even replace the days with whatever thing that tells you (or) reminds you the day of the week (like the food served in the café, Monday/taco, Tuesday/burger, Wednesday/pasta etc.)\nNote When making the custom array, don’t forget to leave an empty \u0026quot;\u0026quot; as the first element of the array, This is because the date is given by the system in a natural numbers format (1,2,3, and so on) rather than a zero-starting format (0,1,2,3, and so on), which the C array uses to index. So the C array indexes the days as \u0026ldquo;\u0026quot;-0, \u0026ldquo;Monday\u0026rdquo;-1, \u0026ldquo;Tuesday\u0026rdquo;-2 etc. and the months as \u0026ldquo;\u0026quot;-0, \u0026ldquo;January\u0026rdquo;-1, \u0026ldquo;February\u0026rdquo;-2 and so on. Label positioning The locational placement in LVGL is done on a Cartesian plane, where each object can have dynamic origin placement, and the Y-axis is inverted. So going down is done with a positive Y-axis value and not negative as it is by default.\nLVGL coord system\nThe position of the various objects in WatchFaceDigital.cpp are set by the line,\nlv_obj_set_pos(\u0026lt;obj\u0026gt;, \u0026lt;new_x\u0026gt;, \u0026lt;new_y\u0026gt;) and the top-left corner is the Cartesian origin, aka coordinates (0,0)\nthis image can show you how to decide label placement for lv_obj_set_pos(\u0026hellip;)\nWe use another function, that is more advanced, that gives the positional alignment based on preset locations\nlv_obj_align(obj, obj_ref, LV_ALIGN_..., x_ofs, y_ofs); obj is your text label\nobj_ref is a reference object to which obj will be aligned. If obj_ref = NULL , then the parent of obj will be used. If obj_ref = lv_scr_act(), then the whole screen will be used.\nLV_ALIGN_\u0026hellip; is the type of alignment; inside another object or next to the reference, for example IN_TOP_LEFT, OUT_BOTTOM_MID, \u0026hellip;\nx_ofs, y_ofs allow you to shift the object by a specified number of pixels after aligning it\nLabel positioning based on alignment is both a simple and complicated thing to understand, so here I have given something you can refer to while modifying the position of the various labels and objects.\nYou can also refer here to LVGL’s documentation of coordinate system https://docs.lvgl.io/master/overview/coords.html\nList of the possible alignments: https://docs.lvgl.io/latest/en/html/widgets/obj.html#alignment\nIt is however recommended that you use the first method to set the location\nlv_obj_set_pos(\u0026lt;obj\u0026gt;, \u0026lt;new_x\u0026gt;, \u0026lt;new_y\u0026gt;) as it is simple and easier for beginners\nHere is a small example.\nTake the Label that tells the date, In the Digital Clock source file (WatchFaceDigital.cpp) it is this line,\nlv_obj_align(label_date, lv_scr_act(), LV_ALIGN_CENTER, 0, 60); by increasing the Value of the Y coordinate (60) to a higher value, we can bring the position of the Date downwards a bit away from the Time, and toward the Heartbeat count in the bottom row here I will increase it to 80, so it becomes..\nlv_obj_align(label_date, lv_scr_act(), LV_ALIGN_CENTER, 0, 80); and now we have made some space up top..\nnow let’s try something a bit complex,\nTake the position argument for the label that tells you time. Here, in the source file (WatchFaceDigital.cpp),\nlv_obj_align(label_time, lv_scr_act(), LV_ALIGN_IN_RIGHT_MID, 0, 0); this line determines the position of the Label telling time, as seen in the image\nwe’re modifying this, by changing the origin alignment parameter (here it is LV_ALIGN_IN_RIGHT_MID) to LV_ALIGN_IN_TOP_LEFT\nyou can alternatively swap the whole line to:\nlv_obj_set_pos(label_time, 0, 0); this makes the Time label/obj. to go to the top-left corner\nbut I will do something a little extra, I will modify the label that store the data and Time format, i.e this line,\nsprintf(timeStr, \u0026#34;%c%c:%c%c\u0026#34;, hoursChar[0],hoursChar[1],minutesChar[0], minutesChar[1]); by removing the \u0026ldquo;:\u0026rdquo; colon in between the numbers, and replacing it with a Newline symbol \u0026ldquo;\\n\u0026rdquo; I change it to become,\nsprintf(timeStr, \u0026#34;%c%c\\n%c%c\u0026#34;, hoursChar[0],hoursChar[1],minutesChar[0], minutesChar[1]); this gives it a nice wrapped text format in the top corner, and gives us some space to play with in the side, for things like Pictures and icons, which we will do next..\nIf you have been able to do these things, you now have completed the 2nd part of the tutorial, and now know how to change and modify the position of labels.\nUsing icons The LVGL library allows for the use of widgets known as \u0026ldquo;Images\u0026rdquo;, In short it allows you to use small Icons like pictures with a small dedicated function, However, when this was attempted the first time we stumbled on some problems as LVGL v6 (used on the PineTime) is not much documented as the latest release (v7 as of August 2020) but also the existing code was only documented for C not {cpp}, after some painful attempts we were able to translate it into {cpp},\nTo bring images into Clock.cpp you will need to do the following,\nHave a small image that cannot exceed a maximum size of 240px x 240px (PineTime max resolution) Use this Image converter (Thanks to LVGL) https://lvgl.io/tools/imageconverter to convert your image to a C array and having the Color format as \u0026ldquo;True color\u0026rdquo; and the output format as \u0026ldquo;C array\u0026rdquo;. Make sure to use something simple as the name we will be using \u0026ldquo;bitmap\u0026rdquo; as the name, but will also be referred as for simplicity Note for example we shall use = bitmap, but any simple word can be used, as long as it does not cause problems with system variables Image size considerations since the image will be using the flash directly, we need to be considerate about flash memory usage.\n\u0026lt;picture_X\u0026gt; x \u0026lt;picture_Y\u0026gt; x 2 gives you the number of KB the image used in storage\nwhere, \u0026lt;picture_X\u0026gt; \u0026lt;picture_Y\u0026gt; are the dimensions of the image horizontally and vertically\nfor example,\nif \u0026lt;picture_X\u0026gt;=80px \u0026lt;picture_Y\u0026gt;=64px then,\ntotal storage used = 80 x 60 x 2 = 10.24KB Please use the flash storage with consideration, when using other apps as well, excess usage of storage might mean the Firmware will not compile. The limit to storage to about 400Kb for the user, the firmware size must not exceed that.\nPreparing the image for inclusion as an icon Once you have obtained your C array from the LVGL converter, you can take a look inside it to see all the different formats of your image, try using something like Notepad++ or any of your favorite text editors to peek inside it,\nthere will be 4 sets of Arrays inside it that look like,\n#if LV_COLOR_DEPTH == 1 || LV_COLOR_DEPTH == 8 /*Pixel format: Red: 3 bit, Green: 3 bit, Blue: 2 bit*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00, #endif #if LV_COLOR_DEPTH == 16 \u0026amp;\u0026amp; LV_COLOR_16_SWAP == 0 /*Pixel format: Red: 5 bit, Green: 6 bit, Blue: 5 bit*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00, #endif #if LV_COLOR_DEPTH == 16 \u0026amp;\u0026amp; LV_COLOR_16_SWAP != 0 /*Pixel format: Red: 5 bit, Green: 6 bit, Blue: 5 bit BUT the 2 bytes are swapped*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00, #endif #if LV_COLOR_DEPTH == 32 /*Pixel format: Fix 0xFF: 8 bit, Red: 8 bit, Green: 8 bit, Blue: 8 bit*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0xff, #endif }; And another small bit of info we will need for later that looks like,\nconst lv_img_dsc_t bitmap = { .header.always_zero = 0, .header.w = 40, .header.h = 40, .data_size = 1600 * LV_COLOR_SIZE / 8, .header.cf = LV_IMG_CF_TRUE_COLOR, .data = bitmap_map, }; Note There are some header files at the top, which we can ignore. RGB565 image format The PineTime uses a display that uses a 16 bit color space, also known as RGB565.\nThese 16 bit are assigned to RGB as 5 bits each for Red and Blue and 6 bits for Green, so 5+6+5=16 bits are required, so each pixel’s color occupies 2 bytes of data, and since 2^16^ is equal to 65,536 it allows us to view 65,536 or 65k colors\nThe way it packs these bits is by converting the bits into 2x 4+4 bit hex-code, so for example,\nif the color of a pixel in Binary is 10110100 01011111 (this color is approximately Lavender purple)\nIt is split as 1011 \u0026amp; 0100 for the first byte and 0101 \u0026amp; 1111 for the second byte and so, converting the binary into Hex-code,\nthe two parts are 0xB4 and 0xF5\nThese two parts in conjunction are used for determining the color of one pixel.\nalso from the binary, it is observed that,\nThe bits 10110 is used for Red, 100010 is used for green, and 11111 is used for blue.\nFlipping the bytes The LVGL library has a feature that allows you to flip the two bytes of the pixel, so if the two parts were, \u0026hellip;0xB4,0xF5,\u0026hellip; ,it will change it to become, \u0026hellip;0xF5,0xB4,\u0026hellip;\nThe reason for this is to allow the use of 8-bit SPI interfaces, but we do not require it, and if set with wrong parameter we could get problems with the color\u0026hellip;\nTo make sure you are ready for the next step, make sure that inside your LVGL configuration file (located at src/libs/lv_conf.h)\nthis parameter,\n#define LV_COLOR_16_SWAP 1 is set to \u0026ldquo;1\u0026rdquo; as seen.\nNote If you haven’t modified it or tampered with it with your GitHub fork, you shouldn’t have a problem as it is correct by default, and you can skip these steps Creating an Object from the Array To include the Icon, first Identify the Array you need to copy to the source (clock.cpp)\nThe one we require from it is the data below the tag that looks like:\n#if LV_COLOR_DEPTH == 16 \u0026amp;\u0026amp; LV_COLOR_16_SWAP != 0 /*Pixel format: Red: 5 bit, Green: 6 bit, Blue: 5 bit BUT the 2 bytes are swapped*/ 0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00, #endif from this copy the Data from the array alone\u0026hellip; I.e this part,\n0x00, 0x00, 0x00,... ...0x00, 0x00, 0x00 (Make sure to not include the comma at the end or the #endif as the entire part is going to substitute a new array)\nIn clock.cpp, just below the header files and the Task creation part (I.e event_handler\u0026hellip;),\nstatic void event_handler(lv_obj_t * obj, lv_event_t event) { Clock* screen = static_cast\u0026lt;Clock *\u0026gt;(obj-\u0026gt;user_data); screen-\u0026gt;OnObjectEvent(obj, event); } create a name for the label with,\nstatic lv_img_dsc_t \u0026lt;name\u0026gt;; // remember to replace \u0026lt;name\u0026gt; with the actual name you gave to your image while converting! then below it create a array to hold the data with,\nconst uint8_t \u0026lt;name\u0026gt;_map[] = {}; // paste the array you copied from the conversion file we specified above... so your array is something like,\nconst uint8_t \u0026lt;name\u0026gt;_map[] = {0x00,0x00,0x00... ...0x00,0x00,0x00}; so your Entire top region of declaration looks like,\n#include \u0026lt;cstdio\u0026gt; #include \u0026lt;libs/date/includes/date/date.h\u0026gt; ... using namespace Pinetime::Applications::Screens; extern lv_font_t jetbrains_mono_extrabold_compressed; extern lv_font_t jetbrains_mono_bold_20; extern lv_style_t* LabelBigStyle; static void event_handler(lv_obj_t * obj, lv_event_t event) { Clock* screen = static_cast\u0026lt;Clock *\u0026gt;(obj-\u0026gt;user_data); screen-\u0026gt;OnObjectEvent(obj, event); } //Declare the descriptor here static lv_img_dsc_t \u0026lt;name\u0026gt;; //place the Image data here const uint8_t \u0026lt;name\u0026gt;_map[] = {0x00,0x00,0x00... ...0x00,0x00,0x00 }; Note Declaring variables outside a function like we did above is known as global scope declaration, this means the variable can be used by not just one function but the Entire code. Then inside the\nClock::Clock(DisplayApp* app,...){... region (the watchface function), you need to place a particular set of lines which LVGL uses to define the object to declare the array as an Icon/Image, You can place this set of lines above label_time.\n\u0026lt;name\u0026gt;.header.always_zero = 0; //Initialization \u0026lt;name\u0026gt;.header.w = \u0026lt;picture_X\u0026gt;; // Setting the Width (or) Horizontal length of the image (number of px) \u0026lt;name\u0026gt;.header.h = \u0026lt;picture_Y\u0026gt;; // Setting the Height (or) vertical length of the image (number of px) \u0026lt;name\u0026gt;.data_size = \u0026lt;Hr_length\u0026gt; * \u0026lt;Vr_length\u0026gt; * LV_COLOR_SIZE / 8; //Allocation of memory for the image \u0026lt;name\u0026gt;.header.cf = LV_IMG_CF_TRUE_COLOR; // Sets the color scheme for the image \u0026lt;name\u0026gt;.data = \u0026lt;name\u0026gt;_map; // Maps the Image data to the Array lv_obj_t *img_src = lv_img_create(lv_scr_act(), NULL); // Create an image object lv_img_set_src(img_src, \u0026amp;\u0026lt;name\u0026gt;); // Set the created file as image (\u0026lt;name\u0026gt;) again, make sure to replace with the name you gave it during conversion!\nNow that we have bought in the image data, we need to set the position, you can place this just below the lines we wrote for bringing in the image, It can be done with either,\nlv_obj_set_pos(img_src, \u0026lt;x_pos, \u0026lt;y_pos\u0026gt;); // \u0026lt;x_pos\u0026gt;, \u0026lt;y_pos\u0026gt; are the coordinates of the Cartesian plane or,\nlv_obj_align(img_src, lv_scr_act(), LV_ALIGN_\u0026lt;parameter\u0026gt;, \u0026lt;x_pos, \u0026lt;y_pos\u0026gt;); If done correctly, you will now have a beautiful little Icon/Image in your Watch face, make sure that your Watch face can accommodate the image by pushing the other labels farther away, creating space for it.\nWe have provided a small template you can use for adding even a large image comfortably\nIf you have succeeded with this, you have completed part 3 of the tutorial.\nCreating an entirely new watchface The instructions above describe how to modify the existing default watchface, if you would like to create a new watchface instead you will need to complete some additional steps. We will refer to the new watchface as WatchFaceName in these instructions.\nCreate the watchface files The watchface is composed of 2 files, WatchFaceName.cpp and WatchFaceName.h. You can copy them from one of the existing watchfaces and give it a new name to provide a basic layout to start from. It is important to increment the ClockFace number near the top of WatchFaceName.cpp otherwise the wrong watchface will be displayed when leaving the menu.\nsettingsController.SetClockFace(0); Add the watchface to Clock.cpp and Clock.h Clock.cpp now provides the ability to switch between multiple watchfaces by long-pressing the screen. You will need to make 3 modifications in Clock.cpp and 2 modifications in Clock.h.\nsrc/displayapp/screens/Clock.cpp\n#include \u0026#34;WatchFaceDigital.h\u0026#34; #include \u0026#34;WatchFaceAnalog.h\u0026#34; #include \u0026#34;WatchFaceName.h\u0026#34; [this]() -\u0026gt; std::unique_ptr\u0026lt;Screen\u0026gt; { return WatchFaceDigitalScreen(); }, [this]() -\u0026gt; std::unique_ptr\u0026lt;Screen\u0026gt; { return WatchFaceAnalogScreen(); }, [this]() -\u0026gt; std::unique_ptr\u0026lt;Screen\u0026gt; { return WatchFaceNameScreen(); }, std::unique_ptr\u0026lt;Screen\u0026gt; Clock::WatchFaceAnalogScreen() { return std::make_unique\u0026lt;Screens::WatchFaceAnalog\u0026gt;(app, dateTimeController, batteryController, bleController, notificatioManager, settingsController); } std::unique_ptr\u0026lt;Screen\u0026gt; Clock::WatchFaceNameScreen() { return std::make_unique\u0026lt;Screens::WatchFaceName\u0026gt;(app, dateTimeController, batteryController, bleController, notificatioManager, settingsController, heartRateController); } src/displayapp/screens/Clock.h\nScreenList\u0026lt;3\u0026gt; screens; std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceDigitalScreen(); std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceAnalogScreen(); std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceNameScreen(); Be sure to increment the number of screens.\nAdd the watchface to CMakeLists.txt src/CMakeLists.txt\n## Watch faces displayapp/icons/bg_clock.c displayapp/screens/WatchFaceAnalog.cpp displayapp/screens/WatchFaceDigital.cpp displayapp/screens/WatchFaceName.cpp Creating an entirely new watchface (Updated Alternative) The previous method may not work with the current version of Infinitime as of (2023 Jan 28). Therefore, here I will tell you a method of creating watch faces on the current build.\nCreate the watch face files The watch face is composed of 2 files, WatchFaceName.cpp and WatchFaceName.h. You can copy them from one of the existing watch faces and give it a new name to provide a basic layout to start from.\nImportant do not forget to rename the class names to reflect the new filenames.\nAdd the watchface to Clock.cpp and Clock.h Clock.cpp now provides the ability to switch between multiple watchfaces by long-pressing the screen. You will need to make 3 modifications in Clock.cpp, 1 modification in Clock.h and two modifications in SettingsWatchFace.h which will allow us to select the newly created watch face.\nsrc/displayapp/screens/Clock.cpp\n#include \u0026#34;displayapp/screens/WatchFaceDigital.h\u0026#34; #include \u0026#34;displayapp/screens/WatchFaceAnalog.h\u0026#34; #include \u0026#34;displayapp/screens/WatchFaceName.h\u0026#34; switch (settingsController.GetClockFace()) { case 0: return WatchFaceDigitalScreen(); break; case 1: return WatchFaceAnalogScreen(); break; case 2: return WatchFacePineTimeStyleScreen(); break; case 3: return WatchFaceTerminalScreen(); break; case 4: return WatchFaceInfineatScreen(); break; case 5: return WatchFaceCasioStyleG7710(); break; case 6: return WatchFaceNameScreen(); break; } return WatchFaceDigitalScreen(); } std::unique_ptr\u0026lt;Screen\u0026gt; Clock::WatchFaceAnalogScreen() { return std::make_unique\u0026lt;Screens::WatchFaceAnalog\u0026gt;(app, dateTimeController, batteryController, bleController, notificatioManager, settingsController); } std::unique_ptr\u0026lt;Screen\u0026gt; Clock::WatchFaceNameScreen() { return std::make_unique\u0026lt;Screens::WatchFaceName\u0026gt;(app, dateTimeController, batteryController, bleController, notificatioManager, settingsController, heartRateController); } src/displayapp/screens/Clock.h\nstd::unique_ptr\u0026lt;Screen\u0026gt; screen; std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceDigitalScreen(); std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceAnalogScreen(); std::unique_ptr\u0026lt;Screen\u0026gt; WatchFaceNameScreen(); Since I have set WatchFaceName to case 6 in a switch statement beforehand it will take sixth position in a list.\nsrc/displayapp/screens/settings/SettingWatchFace.h\n#include \u0026#34;displayapp/screens/WatchFaceInfineat.h\u0026#34; #include \u0026#34;displayapp/screens/WatchFaceCasioStyleG7710.h\u0026#34; #include \u0026#34;displayapp/screens/WatchFaceName.h\u0026#34; std::array\u0026lt;Screens::CheckboxList::Item, settingsPerScreen * nScreens\u0026gt; watchfaces { {{\u0026#34;Digital face\u0026#34;, true}, {\u0026#34;Analog face\u0026#34;, true}, {\u0026#34;PineTimeStyle\u0026#34;, true}, {\u0026#34;Terminal\u0026#34;, true}, {\u0026#34;Infineat face\u0026#34;, Applications::Screens::WatchFaceInfineat::IsAvailable(filesystem)}, {\u0026#34;Casio G7710\u0026#34;, Applications::Screens::WatchFaceCasioStyleG7710::IsAvailable(filesystem)}, {\u0026#34;Name Face\u0026#34;, true}, {\u0026#34;\u0026#34;, false}}}; ScreenList\u0026lt;nScreens\u0026gt; screens; Add the watchface to CMakeLists.txt src/CMakeLists.txt\n## Watch faces displayapp/icons/bg_clock.c displayapp/screens/WatchFaceAnalog.cpp displayapp/screens/WatchFaceDigital.cpp displayapp/screens/WatchFaceName.cpp Using git to work on the firmware Cloning the repository Instructions for cloning the repository are available on the Building and programming page on github.\nChanging the code to add the image Use the editor of your choice to modify the source files. Please read the coding conventions before you start.\nCompiling the firmware Information about how to compile the firmware is included on the Building and programming page on github.\nTesting the firmware Installing the new firmware A holistic guide on how to install different firmware using various hardware programmers is available here: Reprogramming the PineTime.\nIf you would like to install the firmware by OTA/DFU, you can follow these steps:\ncmake -DARM_NONE_EABI_TOOLCHAIN_PATH=/path/to/gcc-arm-none-eabi-9-2020-q2-update -DNRF5_SDK_PATH=/path/to/nRF5_SDK_15.3.0_59ac345 -DUSE_OPENOCD=1 -DBUILD_DFU=1 ../ make -j pinetime-mcuboot-app Be aware the paths for the cmake command must be absolute. The -DBUILD_DFU argument will generate a zip file which can be flashed using nRF Connect (not recommended) or Gadgetbridge on Android. You must have adafruit-nrfutil installed in your $PATH for this to work.\nPineTimeStyle PineTimeStyle is a watchface created for Infinitime and has been included since version 1.3 of Infinitime.\nIt is based on TimeStyle for Pebble by Dan Tilden with permission.\nPineTimeStyle Watchface\nLayout The time is displayed on the left in either 12 or 24h format depending on the system setting. An indicator will appear in the bottom left corner if 12h is selected.\nIn the sidebar on the right there is a battery icon which displays the current charge level, and is replaced by a plug icon when charging. Below it is a bluetooth icon which appears only when bluetooth is connected, and a lower case i which indicates unread notifications are available, generally only if notifications are disabled via the quick settings screen.\nThe current date is displayed in the middle, and at the bottom there is a small gauge which displays the step count, the needle will rotate in a clockwise direction as the step count increases. The gauge scales automatically based on the configured step goal, and the outside of the gauge will turn white when the step goal is reached.\nCustomisation Since version 1.4 of Infinitime, a color picker is available for PineTimeStyle. As of version 1.11, an addition page of customisation has been added which allows the user to customise the sidebar. These settings can be accessed by long pressing on the watchface which will display two buttons, one with a palette icon to access the color settings, one with a cog icon for the sidebar options.\nPineTimeStyle Settings Button\nThe color picker PineTimeStyle Color Settings Interface\nThere are 3 pairs of buttons with left and right arrows which scroll through 17 standard colors. The top pair changes the time text color, middle for the sidebar color and bottom for the time background color.\nThere is also a \u0026lsquo;Rnd\u0026rsquo; button which randomises all colors, a \u0026lsquo;Rst\u0026rsquo; button which resets the colors to standard teal and black, and a cross which closes the settings interface. It can also be closed using the physical button.\nThe sidebar settings PineTimeStyle Sidebar Settings\nAs of Infinitime version 1.13, there are 2 options available in the sidebar settings page - Steps style and Weather.\nBy pressing the \u0026lsquo;Steps style\u0026rsquo; button you can toggle between 3 options, the original full gauge, a half size gauge plus seconds display, or a numerical step count display. The second button, Weather, enables or disables this function. When no weather data is available a ban icon will be displayed with 2 dashes below, and when weather data is available the current temperature plus an icon showing conditions based on the cloud cover and precipitation amount.\nTo learn more about the sending weather data to the watch, see InfiniTime weather\nFAQ Does PineTime run Linux? No. Please read this forum article for information about Linux on PineTime. Also check out the article \u0026ldquo;PineTime doesn’t run Linux\u0026hellip; But that’s OK!\u0026rdquo;\nWhy are there two versions of the PineTime in the store? See the below question and answer.\nWhy can I only buy the closed version in a 3-pack, and the open version per one? TL:DR: The unsealed PineTime is for development, the sealed one is for production use, because of firmware uploads. That is also why they were initially sold three in a pack.\nIn the current situation in development there are some reasons to want to be sure you only experiment with an open device. If you install the wrong firmware, your device could be bricked, until you find a way to open it, which will likely damage the device. The idea is that if you want to develop an application for the PineTime, you will be testing it out first, and only after you know for sure your new firmware is well tested, you will install it on sealed devices. If you are in the beta stage, having more than one PineTime is probably a good idea. So to prevent people from locking themselves out at the first test, it was decided to sell the closed version only as a pack of 3. Development can be done on an open device, so any issues can be easily handled.\nHow long does it take to ship my PineTime? That depends on whether you chose for Standard or Express shipping. Standard shipping for the dev kit may take up to a few weeks.\nHow do I install new software on PineTime? If you have a Sealed PineTime, flash only tested PineTime Firmware to your PineTime. If you flash unknown PineTime Firmware, your sealed PineTime may be bricked relatively permanently.\nThere is a lot of different software for flashing. Check out Development page for a list of companion software.\nAlso see this page to see various methods of reprogramming the devkit PineTime the wired way.\nRemember to validate the firmware after flashing: Swipe up to show the menu, tap the checkmark icon, tap \u0026ldquo;Validate\u0026rdquo;.\nMy PineTime arrived, now what? You should start by testing out all the features of the watch, to make sure everything works. Power it on and check the display.\nPineTime is shipped with InfiniTime firmware. Press the watch button to show the clock, then swipe up on the touchscreen to reveal the menu.\nYou probably now wish to update the bootloader and firmware.\nWhat\u0026rsquo;s the OS that\u0026rsquo;s preinstalled on the PineTime by default? PineTime ships with the open source InfiniTime firmware.\nTo support firmware update and rollback, PineTime includes the open source MCUBoot Bootloader.\nCan we use this OS or its source code? Yes, InfiniTime and the MCUBoot Bootloader are open source.\nWhy is the back exposed? Is it supposed to snap on? The back cover of the PineTime devkit is exposed so that you can flash and debug the device with the SWD pins. The main unit and cover does not snap (lock) together. If you want to attach the back cover anyway, you can use glue or tape.\nWhat hardware should I use to flash code to the PineTime? There are several ways you can do this, check out Reprogramming the PineTime\nHow do I connect the PineTime to a programmer? Here’s how: Devkit wiring\nHow do I set the time on PineTime? In recent versions of the firmware, you can set it directly from settings.\nYou can also use either GadgetBridge or the closed-source nRF Connect and Da Fit apps. See \u0026ldquo;Set PineTime Date and Time with nRF Connect\u0026rdquo;\nYou can also set the time using your PinePhone or other Linux-based Bluetooth LE capable device with the Bluez software installed. Install the bluez package and make sure your PineTime is running and awake with InfiniTime 0.7.1 or later.\n$ bluetoothctl [ bluetooth ]# scan on ... [NEW] Device D7:03:FB:6E:31:B2 Pinetime-JF ... [bluetooth]# pair D7:03:FB:6E:31:B2 Attempting to pair with D7:03:FB:6E:31:B2 ... [NEW] Characteristic (Handle 0xfd80) /org/bluez/hci0/dev_D7_03_FB_6E_31_B2/service0015/char0016 00002a2b-0000-1000-8000-00805f9b34fb Current Time ... [Pinetime-JF]# menu gatt ... [Pinetime-JF]# select-attribute /org/bluez/hci0/dev_D7_03_FB_6E_31_B2/service0015/char0016 [Pinetime-JF:/service0015/char0016]# read Attempting to read /org/bluez/hci0/dev_D7_03_FB_6E_31_B2/service0015/char0016 [CHG] Attribute /org/bluez/hci0/dev_D7_03_FB_6E_31_B2/service0015/char0016 Value: b2 07 01 01 00 04 15 00 00 ......... b2 07 01 01 00 04 15 00 00 ......... [Pinetime-JF:/service0015/char0016]# write \u0026#34;0xe4 0x07 0x0c 0x1f 0x0e 0x02 0x00 0x00 0x00\u0026#34; Use the list-attributes command to find the correct path. Look for the characteristic named \u0026lsquo;Current Time\u0026rsquo;\nThis is the format for the current time as hex bytes:\n\u0026lt;lsb of year\u0026gt; \u0026lt;msb of year\u0026gt; \u0026lt;month (1-12)\u0026gt; \u0026lt;day (1-31)\u0026gt; \u0026lt;hour (0-23)\u0026gt; \u0026lt;minute (0-59)\u0026gt; \u0026lt;seconds (0-59)\u0026gt; \u0026lt;weekday (1-7 where Monday)\u0026gt; \u0026lt;fractions (1/256th of second)\u0026gt; Is there a standard agreed method of pushing OTA updates so that one could seal the PineTime dev kit nicely? InfiniTime supports firmware updates over Bluetooth LE with the nRF Connect mobile app. See \u0026ldquo;Download and Test Our PineTime Firmware\u0026rdquo;\nMy PineTime\u0026rsquo;s screen shows garbage, how do I fix it? This is usually caused by unplugging the device after it has booted, it needs to be reinitialised. To do so just restart the watch by removing power to it.\nI have experience developing on Arduino. How does the PineTime compare? To learn programming on PineTime, check out this article\nArduino provides the Arduino IDE (or you use the avr-gcc and avrdude command-line tools) which you can use to compile and upload code to an Arduino board. The PineTime and its ARM processor doesn’t have this, so you’ll have to familiarize yourself with tools like GCC for ARM, and OpenOCD. Some experience with Arduino does translate over to the PineTime, especially if you’ve worked with LCD’s, or SPI. The PineTime is at least four times faster than an Arduino Uno (even faster at certain specific workloads due to hardware acceleration), and it has 32 times more RAM and 16 times more flash storage.\nLup Yuen Lee (just call him Lup, rhymes with \u0026ldquo;Up\u0026rdquo;) has written many articles on PineTime programming. Check out the articles here\nCan I code firmware for PineTime without an actual PineTime? Yes, you may code PineTime Watch Faces and preview them in a web browser (thanks to WebAssembly).\nPineTime Simulator\nThen flash your firmware remotely to a real PineTime via Telegram, and watch your firmware run in a live video stream.\nRemote PineTime\nWhat do I need for building PineTime firmware locally on my computer? Most flavours of PineTime firmware (InfiniTime, Hypnos, Klok, wasp-os) will build fine on Linux (x64, Arm32, Arm64) and macOS. Just follow the instructions provided.\nDownload version 9-2020-q2-update of the Arm Embedded Toolchain arm-none-eabi-gcc. Other versions of gcc may have problems building the firmware correctly.\nOn Windows, install Windows Subsystem for Linux (WSL) and execute the build steps inside the WSL Terminal (instead of the Windows Command Prompt). USB Programmers (like ST-Link and JLink) are not supported in WSL, so use the Windows Command Prompt to flash your built firmware to PineTime.\npinetime-rust-mynewt firmware for PineTime supports building and flashing via the Windows Command Prompt (no need for MinGW and Docker).\nCan I use Pinebook Pro for developing PineTime? Yes, use version 9-2020-q2-update of the Arm Embedded Toolchain arm-none-eabi-gcc. Other versions of gcc may have problems building the firmware correctly.\nWhat is ARM Semihosting? We use the SWD (Single Wire Debug) protocol created by ARM for flashing and debugging PineTime’s nRF52832 microcontroller, which contains an ARM CPU. (SWD is derived from standard JTAG, but with fewer wires) With ARM CPUs you can trigger a software breakpoint, and allow the debugger (OpenOCD) to do something really nifty: Display a message, read console input, dump out a file, even read a file. That’s called ARM Semihosting. More about ARM Semihosting\nWhat is OpenOCD? OpenOCD is Open On-Chip Debugger. It’s the software that drives your microcontroller debugger/flasher. We need it for running any kind of flashing and debugging with Pi or ST-Link. gdb talks to OpenOCD for debugging firmware. gdb also works with VSCode for debugging firmware visually. More about OpenOCD\nPlease use xPack OpenOCD with PineTime. Other versions of OpenOCD seem to have problems with PineTime.\nHow do I remove flash protection? PineTime watches shipped before 20 Sep 2020 have flash protection enabled.\nThe flash protection can be removed using multiple different methods. If you don’t have anything except the PineTime, not even a Raspberry Pi, then you have to order a programmer online: you can use a J-Link, CMSIS-DAP dongle and various other programmers. See this page to see various methods of reprogramming the PineTime.\nIf your PineTime was shipped after 20 Sep 2020, you don’t need to remove flash protection. They are shipped with flash protection disabled. You can flash and debug PineTime right away with ST-Link, JLink and Raspberry Pi.\nWhy can\u0026rsquo;t you use ST-Link to remove nRF52 Flash Protection? Because ST-Link is a High Level Adapter. It doesn’t really implement all SWD functions, just a subset (probably to keep the price low). More details in the section \u0026ldquo;Why Visual Studio Code with ST-Link (instead of nRFgo Studio with J-LINK)\u0026rdquo; in the article \u0026ldquo;Coding nRF52 with Rust and Apache Mynewt on Visual Studio Code\u0026rdquo;.\nSince we need a low level SWD adapter like Raspberry Pi anyway, can we do everything on a Pi instead of ST-Link + Windows? Yes, Raspberry Pi works for flashing and debugging PineTime, even for removing flash protection. We have a special version of OpenOCD called OpenOCD SPI that talks to PineTime’s SWD port over SPI (without bit-banging). See PineTime Updater\nIs there a 3D model of PineTime available somewhere? Not yet. Someone did design a cover you can snap on to keep the back shut. More details\nAre there any alternatives to the wrist band provided with the PineTime? No, but PineTime accepts standard 20mm wrist band that is widely available by a third party.\nNote that some sellers have a different point of view on what standard is. So you should always check the fitting to make sure it looks like the one used by PineTime.\nTroubleshooting PineTime\u0026rsquo;s Bluetooth (InfiniTime firmware) Old (pre 1.4) InfiniTime firmware had an issue where Bluetooth connectivity sometimes gets lost/fails.\nThe fix was to soft-reset the watch, by holding the PineTime button for ~8 seconds until the PineCone logo appears.\nDoes PineTime have an audible beeper or speaker? No, but in practice the vibration component is a substitute for use with alerts.\nDevelopment Available firmware and projects\nCompatibility\nHardware wishlist\nReprogramming\nWrite battery-friendly software\nAvailable firmware and projects Project Homepage Project Source PineTime Implementations FreeRTOS https://www.freertos.org https://sourceforge.net/projects/freertos/ InfiniTime (GitHub: JF002/Pinetime)+ kaythe/pinetime-os Zephyr https://www.zephyrproject.org https://github.com/zephyrproject-rtos/zephyr najnesnaj/pinetime-zephyr\nSuperPrower/pinetime_zephyr_sample_fw\nDejvino/pinetime-hermes-firmware\nendian-albin/pinetime-hypnos\nomegatime watchface mynewt https://mynewt.apache.org/about/ https://github.com/apache/mynewt-core lupyuen/pinetime-rust-mynewt(Discontinued by Creator)\ncaspermeijn/klok MbedOS https://os.mbed.com https://github.com/ARMmbed/mbed-os sethitow/mbed-pinetime\ngeoffrey.vl/mbed-pinetime RIOT http://riot-os.org/ https://github.com/RIOT-OS/RIOT/ bosmoment/PineTime-apps TinyGo https://tinygo.org https://github.com/tinygo-org/tinygo aykevl/go-smartwatch wasp-os (MicroPython) https://wasp-os.readthedocs.io/ https://github.com/daniel-thompson/wasp-os WaspOS PineTime install guide Rust + RTFM https://rtfm.rs/ rtfm-rs/cortex-m-rtfm https://github.com/dbrgn/pinetime-rtfm/ Bare Metal https://github.com/xriss/timecake\nhttps://github.com/Arc13/Pyrus xriss/timecake\nArc13/Pyrus AdaFruit bootloader https://github.com/adafruit/Adafruit_nRF52_Bootloader daniel-thompson/wasp-bootloader Useful drivers https://github.com/sethitow/mbed-pinetime https://github.com/sethitow/mbed-pinetime watchful (rust) https://github.com/lulf/watchful https://github.com/lulf/watchful Project Homepage Project Source PineTime Implementations Gadgetbridge (Android companion app) https://gadgetbridge.org/ https://codeberg.org/Freeyourgadget/Gadgetbridge InfiniTime support in mainline Arduino https://youtu.be/4aFDjymXjOw https://github.com/atc1441/ATCwatch https://github.com/atc1441/ATCwatch OTA Update Flasher / DaFlasher https://youtu.be/gUVEz-pxhgg https://github.com/atc1441/DaFlasherFiles https://github.com/atc1441/DaFlasherFiles InfiniTime companion app for Linux alexr4535/siglo Wasp-os companion app for Linux Siroj42/wasp-companion UI design proposal arteeh/pinetime Flashing app for Linux arteeh/pinetime-flasher Flashing app for Windows ZephyrLabs/PinetimeFlasher ESP32 / ESP8266 SWD WebFlasher https://youtu.be/Iu6RoXRZxOk https://github.com/atc1441/ESP32_nRF52_SWD InfiniTime companion daemon for Linux Elara6331/ITD Compatibility Compatibility with other projects Different firmware running using different bootloaders and Bluetooth stacks on the nRF52832 have different requirements on how they should be initialised and what should be placed where in the internal flash.\nTo keep track of what, how and why things work like they do across the different projects, check out the PineTime SoftDevice and MCUBoot compatibility article.\nCompatibility with companions apps and Bluetooth communication There are a lot of different firmware running on the Pinetime that implement different BLE APIs (for example for time synchronization and notifications). Companion apps must be able to differentiate between different firmware and forks of the same firmware. See Bluetooth.\nHardware wishlist This page contains a list of things people wish PineTime did differently\nHardware Other display technology could be explored. E-ink Still images require no power to maintain **[//en.Wikipedia.org/wiki/Transflective_liquid-crystal_display A transflective LCD] Increased readability in bright daylight **[//en.wikipedia.org/wiki/OLED OLED] Self-emissive display (pixels emit their own light) Allows for lower power usage with mostly black screens Allows for low power visual notifications (imagine an always-on small red square in the corner to indicate a notification) Touchscreen with configurable sensitivity Ideal for gloved fingers and water droplet resistance Preferably it should remain capacitive, as a resistive touchscreen would have too many trade-offs. A slightly bigger 256×256 pixel display This resolution is preferable for its binary alignment for low-level simplicity It has the property that its X and Y coordinates are each addressable with a single byte, with no bounds checking Its total number of pixels is a power of 2 (65536), and each pixel is addressable with exactly 2 bytes. The IBNIZ (Ideally Bare Numeric Impression giZmo) virtual machine, designed for minimalist demoscene graphics, has chosen 256×256 for its virtual display specifically for code efficiency. If PineTime also chose 256×256 then it would be a target platform for unclipped IBNIZ demoscene programmes, which would be really fun to play around with on one’s wrist! Full screen refresh is very slow A full 16-bit redraw on the display takes at worst 120ms, which is 8Hz Modest optimization is possible by adopting 12-bit color A smooth scrolling/usage/animation experience would be 30Hz minimum, preferably 60hz Display redraw is currently bottlenecked by the nRF52832 maximum SPI clock (8MHz). The nRF528(33/40) has one high speed SPI master which supports 32MHz, still well below the ST7789 maximum Parallel data transfer could be an option, but using more GPIOs (which don’t look available) Some sort of scroll wheel (and possibly button combination) would be nice as an additional input method Changed GPIO assignment so more functionality is available (i.e. NFC and VSYNC) Wireless charging, or Qi Charging capability Different MCU with more RAM and ROM, higher clock nRF5840 update 32MHz HS SPI, QuadSPI CryptoCell + Secure Key Storage More RAM, a coprocessor The possibility to expose USB through power pins Ox64/BL808 Open hardware RISC-V based MCU Significant jump in performance Significant jump in memory and storage, allowing for more features and better UI’s Possibly a pre-certified MCU module with a ceramic antenna Version without sensors but maybe bigger battery Pins on the programmer connector to allow UART while developing (currently there is a TX test point on PCB). (Note: There’s ARM SemiHosting, ITM and Segger RTT that fulfil this purpose for most) Connect SDO of ST7889 LCD controller to MCU Allows MCU to execute READ commands Possibility of leveraging ST7889 RAM to save MCU RAM? LCD must be centered on case. Currently is not and watchfaces seems different when clock is put on the other wrist. A NFC antenna around the case, connected to the NFC pins. Used sensors should be NDA-free and preferably also blob-free for easier development Possibly replace BMA421 accelerometer with a magnetometer + gyroscope + accelerometer combination The BMA421 doesn’t have a public datasheet Special attention should be paid to advanced features, such as step counting integration or flick detection. PineTime SoC could support USB or have a FTDI chip with the relevant pins exposed It could allow flashing a sealed device, just like Arduinos work. Alternatively, an USB-C port could be added that provides these features. A bigger pulldown resistor for the power button 100k still leaks a noticeable amount of power when the button is always on. Ceramic Bluetooth antenna for better signal reception An external RTC circuit Allows the main MCU go to deep-sleep while retaining time. Allows time retention through MCU reset. Ultra low quiescent current PMIC In theory could provide a hard reset capability based on button press Better deep sleep/shipping/storage/off lifetime A nano-power system timer IC could in theory provide a RTC, MOSFET-controlled deep sleep, watchdog timer and button-controlled reset Built-in \u0026ldquo;fuel gauge\u0026rdquo; for better estimation of battery capacity Improved haptic or audible feedback E.g. small Piezo buzzer Use case would be for very short beeps (think old-school casio watch) as notification. Of course developers can PWM other frequency to make it sing, but piezos tend to be shrill. A built-in microphone Would allow phone call functionality to be built into the watch. Could potentially allow for speech recognition for text input. Direct access to the external (flash) storage Only a small jump in price Reprogramming Wire it up and then flash something.\nManuals InfiniTime installation Zephyr installation Beginner manual which explains how to install Zephyr (by najnesnaj). Wasp-OS installation Full manual with install instructions and an application writer’s guide. Write battery-friendly software The key to save battery is to enable only what you need when you need it. nRF52832 has a lot of functionalities allowing you to draw as little current as possible. Here are some tips and tricks:\nDisable / shutdown / put in sleep mode all devices around the MCU (display controller, touch controller, external memory). Disable all peripheral inside the MCU when you don’t need them (SPI, TWI(I²C)). The power management of the NRF52832 is very smart and will completely shut down (power off and disable the clock) the peripheral when the software disables it. Put the MCU to sleep as soon and as often as possible. If you are not using a RTOS, this is done by calling WFE (wait for event) instruction. Most of the time, RTOS implement this functionality. For example, FreeRTOS calls it the tickless mode: it puts the CPU in sleep mode when no task is planned for execution for more than a specified time, and wakes up as soon as an event is detected or when a task is ready to run. Do not use logging (JLink RTT, SWO, semihosting), it uses a lot of power. Ensure that the debug circuitry of the MCU is not enabled when you measuring the battery life. The debug peripheral is enabled as soon as you connect a debugger to the device, and is not automatically disabled, even if you disconnect the debugger you will have to wait for the battery to go flat to disable to port. The software running in the NRF52832 cannot disable the debug peripheral. To disable the debug circuitry: using nrfjprog --reset using JLinkExe: issue the command writeDP 1 0 or with OpenOCD: issue the command halt issue the command flash fillw 0x10001208 0xFFFFFF00 0x01 issue the command reset You can check if the debug port is enabled using the following code: DWT-\u0026gt;CYCCNT ? \u0026#34;NO\u0026#34;:\u0026#34;YES\u0026#34; Read the errata sheet of the MCU and apply workarounds if they apply to your software. Discussions Bootloader improvements\nBootloader improvements Discussion by the user JF:\nRequest for comments In this page, I explain the changes and improvements I would like to implement to the MCUBoot bootloader to make it more reliable, and to allow bootloader upgrade and switch (mcuboot \u0026lt;-\u0026gt; wasp-bootloader, for example). I try to explain why I made these choices too.\nDo not hesitate to edit this page and add a new section if you want to add any comment to these points (if you agree, disagree, want to try something else).\nIntroduction This pages describes the improvements I propose to make to the bootloader and OTA to make the whole process more reliable.\nMy goals are:\nKISS: Keep It Stupid Simple. Simple code contains less bugs than complicated/complex code. As reliable as possible. 100% reliability is not feasible with the current hardware (no physical reset button, no bootloader in ROM code), but let’s try to reach 99.9% reliability Provide a read-only factory image we’ll be able to restore in case of unrecoverable errors during OTA Provide a way to upgrade the bootloader Provide a way to switch from MCUBoot to NRF bootloaders Current memory map Pinetime Devkit0 is using a nRF52832-QFAA MCU with 512kB flash and a XT25F32B SPI NOR external flash with 4096kB.\nInternal flash (512Kb):\nPage size is 4Kb. Bootloader contains the MCUBoot bootloader. Boot log is currently not used. Can be use to provide reboot logs to the application App is the PRIMARY SLOT for MCUBoot: the firmware that is currently running. Scratch is used by MCUBoot as temporary storage for swap operation External flash (4096Kb):\nPage size is 256 bytes. Bootloader assets: boot logo OTA: SECONDARY SLOT for MCUBoot. During OTA, this is where the new version of the firmware is stored. FS: space available for the application firmware. This memory map allows a strong boundary between the bootloader and the application :\nThe bootloader is ran by the MCU at reset time and loads its boot logo from the SPI flash The bootloader (MCUBoot) swaps images from primary and secondary slots if necessary The bootloader starts the watchdog The bootloader jumps to 0x8000 to run the application The application don’t know anything about the bootloader except that:\nit must be linked @0x8000 it must refresh the watchdog periodically it must store the image for OTA at a specific location in the external SPI flash memory In this configuration, the boot logo is part of the bootloader, not of the application: the same logo will be displayed whatever application firmware will be loaded.\nChanges Factory image The factory image is a \u0026rsquo;light\u0026rsquo; build of InfiniTime that contains the bare minimum code to provide OTA to the user: basic UI, BLE and OTA. No apps, no fancy functionalities.\nThis factory image will be stored in the \u0026ldquo;bootloader assets\u0026rdquo; area of the external flash memory.\nThis factory image will be restored either automatically, when the bootloader detect it cannot boot from primary slot (App in internal memory) and secondary slot (OTA from exeternal). The user can also request to restore this factory image if necessary (using the button?).\nBootloader assets Graphics can be compressed using a simple RLE encoding. RLE encoding on 1 bits (2 colors images) is very efficient (115200KB -\u0026gt; 1-5KB).\nIn order to simplify the code, the graphics will be stored into the bootloader code instead of storing them into the external flash:\nLess code. Easier to document: 1 specific logo = bootloader mode Do not have to worry about the dynamic size of the logo (the binary size of the graphics will vary with the content when they are RLE encoded). Bootloader Display the bootloader version on the screen and expose the version to the application firmware Provide a way to revert the firmware to the last working version AND to the factory firmware Display status and progression (progress bar similar to wasp-reloader, color code) Test as much as possible Bootloader workflow Upgrade \u0026amp; Reloader The reloader is a tool that allows to upgrade the current version of the bootloader AND to switch from MCUBoot to NRF and vice versa.\nHow does it work? Upgrade The reloader is first OTAed like any firmware upgrade. When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader upgrade the current bootloader and resets the system. It does NOT flag the image as validated. It resets the MCU. The new version of MCUBoot notice that the last upgrade is not validated and reverts to the firmware that was running just before. Voilà, you’re running your firmware and a new version of the bootloader Switch bootloader The reloader is first OTAed like any firmware upgrade. When the system resets, MCUBoot swaps the application firmware with the reloader. The reloader overwrite the current bootloader with a new one and reset. The new bootloader is running. Switch From InfiniTime to wasp-os: the reloader contains the NRF Bootloader and Softdevice. This bootloader provides the OTA mecanism out of the box. Wasp-os is downloaded when the NRF bootloader is running From wasp-os to InfiniTime: the reloader contains the factory image (infinitime-factory). The complete version of InfiniTime will be OTAed when this factory image is running. Discussions Boot Logo: embedded into the bootloader binary vs stored in the external SPI flash Embedding (and compressing) the boot logo inside the bootloader binary brings many advantages:\nAll the data are available in memory at runtime. No need to load them \u0026amp; check them, and no need to handle errors and invalid corrupted data. The data is available and can be sent directly to the display controller 1 unique logo for the bootloader: easier to document and explain to the user that this specific logo is the logo from the bootloader mode. But it also has some disadvantages:\n1-Bit RLE encoding (very effective compression) allows only 2 colors (background/foreground) The boot logo cannot be customized (unless you recompile and flash this new build of the bootloader) The size of the boot logo is limited (depending on the compression ratio) My (JF) point is that the bootloader must be as reliable as possible. I would like to remove all part of the code than can fail. If we read the boot logo from the SPI flash, we will write something like this:\nint ret; boot_logo_info info; ret = SpiNor_read(infoOffset, \u0026amp;info, sizeof(boot_logo_info)); if(ret != 0) { // Something went wrong while reading image info panic(); // ? reset ? } if(check_boot_logo_info(info) == false) { // image info are invalid (ex: size \u0026gt; 240*240), we cannot use them panic(); // ? reset ? Display nothing? } We could find invalid image info if a firmware did not respect the memory map and erased/overwrote the external memory map. In this case, the bootloader couldn’t run properly. Of course, we can implement something smart in panic() (retry, use failover values), but again, this adds complexity and bug probability.\nAll these if’s that call panic() can be avoided by using hard-coded values at build-time.\nIf the image is hard-coded, you won’t be able to easily (not that easy, actually) customize the boot logo. But remember that this logo is only display for a short time only when the device reset (manually or during an OTA).\nWhy not add OTA functionality to the bootloader? This is exactly how the NRF bootloader/SoftDevice works: the bootloader is a standalone firmware that provides OTA functionality thanks to the SoftDevice. The downside is that the BLE stack needed to provide OTA is quite big and uses a lot of space in flash memory (~124kB according to the documentation). This is roughly 1/4 of the available space in the internal flash memory.\nFirmware based on the NRF SoftDevice share the BLE stack with the bootloader, it is mutualised between both entities. The downside of this design is that firmwares developers are somewhat forced to use the NRF BLE stack. If they want to integrate another BLE stacak (NimBLE for example), these 120kB used by the SoftDevice would be wasted.\nThat’s why we decided to make the MCUBoot bootloader a simple bootloader without OTA functionality. It’s very lighweight (less than 20kB) and leaves the developers the right to choose the BLE stack they want.\nFixed vs dynamic memory map A dynamic memory map, using a partition stored in a fixed place (at the beginning of the external flash, for example) would allow different firmware to customize the partition table, image sizes and use the memory for efficiently.\nBut it has the downside to add complexity and code that could fail.\nSee External flash partitioning proposal.\nFurther information Datasheets, schematics and certifications\nPineTime Devkit Wiring\nPineTime Equivalents\nSpecifications\nDatasheets, schematics and certifications Schematics PineTime Schematic ver1.0a PineTime GPIO Port Assignment ver1.0 Note The part number for the SPI FLASH in the schematic diagram is not correct, the PineTime features a larger external FLASH device, see below. Chip Datasheets NORDIC nRF52832 information:\nnRF52832 Product Brief nRF52832 Product Specification v1.4 ARMv7-M information:\nARMv7-M Architecture Reference Manual Component Datasheets PMU (Power Management Unit) information:\nSGMicro SGM40561 Single Cell Charger Datasheet SGMicro SGM2036 3.3V Low Power Low Dropout RF Linear Regulator Datasheet SPI Flash information:\nXTX XT25F32B 32Mb(4MB) SPI NOR Flash (data sheets for this part are hard to find but it acts similar to other QuadSPI SPI NOR Flash such as Macronix 32Mb(4MB) SPI NOR Flash) XTX XT25F32B IDs for XT25F32B are: manufacturer (0x0b), device (0x15), memory type (0x40), density (0x16) LCD Panel:\n1.3\u0026quot; 240x240 IPS LCD Panel Specification for PineTime 11.6\u0026quot; Sitronix LCD Driver/Controller Datasheet Display controller:\nST7789V2 (used in PineTimes produced before May 2026) ST7789P3 (used in PineTimes produced from May 2026) Touchpad information:\nTouchpad Specification for PineTimel 11.6\u0026quot; Hynitron CST816S Capacitive Touch Controller Datasheet in Chinese Touch Controller Datasheet en Sensor:\nBOSCH BMA425 Triaxial Acceleration Sensor Datasheet on current PineTime device BOSCH BMA421 Triaxial Acceleration Sensor Product Brief on early PineTime device TianYiHeXin HRS3300 PPG Heart Rate Sensor Data Sheet Certificates PineTime FCC Certificate PineTime CE Certificate Manuals PineTime Quick Start Guide PineTime Devkit Wiring This article will help you get up to scratch about how to connect your PineTime to your hardware debugger and what to keep in mind.\nThe devkit comes with a set of wires you can use for connecting your programmer to the SWD pins. Most people use friction to make contact with the programming cable. Soldering the wires to the PineTime is not recommended, especially if you don’t have a temperature-controlled iron and good confidence that you can do it - the thin PCB is fragile and easy to break.\nCurrent amount of dead PineTimes (or ruined bundled programming connectors) due to attempted soldering is 5 (update this number when suitable).\nRead this about the battery\nYou have three choices:\na) If you have a soldering iron and you’re confident with using it, it is recommended that you remove the battery until you actually need it. Doing so avoids unnecessary charge cycles and strain on it. It can also potentially prevent issues with your watch not resetting properly or backfeeding power into your debugger-programmer. There’s also the option that you just connect a microswitch between the battery’s positive side and the PineTime, just make sure to isolate your connections so it doesn’t short out against anything.\nb) If you do not have a soldering iron or you’re not confident with using it, don’t disconnect the battery if you ever plan on using it. Don’t bend the wires too much as they’re thin, you won’t be able to reconnect it. Keep in mind that keeping it connected during development will probably reduce the lifetime of the battery. Small load on the 3.3V pin is probably fine, but it will drain the battery empty. Having the battery connected when it’s not empty will also very likely backfeed power into your 3.3V pin - Don’t cause short circuits! Don’t leave the wire dangling!\nc) If you don’t disconnect the battery, also don’t connect the 3.3V pin from the SWD cable when debugging or updating firmware. You only need to use the GND, SWDIO and SWDCLK pins. In that case the watch will run exclusively on battery, but there is no danger of backfeeding power.\nSWD Pinout The devkits have exposed SWD pins for flashing and debugging.\nThe pinout is:\nPogo Pins connection The PineTime Pogo Pins are spring-loaded pins with diamond-shaped tips.\nThe Pogo Pins are meant to be connected temporarily to PineTime’s SWD port for firmware flashing and simple firmware debugging.\nThe other end of the Pogo Pins connects to ST-Link v2 or JLink for flashing and debugging. (ST-Link v2 is shown in the background)\nTo connect PineTime Pogo Pins to PineTime’s SWD Port:\nTo orientate the pins, stick a piece of Sticky Tape to the Pogo Pins as shown above. The Sticky Tape should point away from PineTime’s Battery. Orientation is important. You may damage PineTime with the incorrect orientation! With the Battery at left and Sticky Tape pointing right, the SWD Pins will be arranged left to right as: SWDIO, SWDCLK, 3.3V, GND Connect the other end of the Pogo Pins to the Jumper Cable that’s bundled with PineTime. Connect the Jumper Cable to ST-Link v2 or JLink: SWDIO, SWDCLK, 3.3V, GND. See Reprogramming the PineTime With the Sticky Tape pointing right (away from the Battery), tap and hold the Pogo Pins firmly on PineTime’s SWD Port. But not too hard because the PCB or screen may break. Stabilise the Pogo Pins with your pinky finger as shown above. PineTime should light up and reboot when the Pogo Pins are connected. You may flash and debug PineTime now. See Reprogramming the PineTime The tips of the Pogo Pins will partially penetrate the SWD holes like this. Don’t force them in!\nSoldered wires example Before attempting this, make sure you have a good soldering iron, some magnification and you haven’t set your iron too high. If you haven’t ever before soldered things this small, you really really do not want to start out on something this dense, small and thus fragile.\nRaspberry Pi connection See PineTime Updater\nPineTime Equivalents This page contains a list of PineTime hardware equivalents or very close clones. Primarily to keep track of which devices could possibly be \u0026ldquo;jailbroken\u0026rdquo; and run PineTime firmware.\nPlease add devices that use the same chipset to this list.\nKalakate Seems to be PineTime hardware, interesting GUI, seems DaFit-y\nhttps://www.youtube.com/watch?v=1VdMxbOYxgA Colmi P8 A few firmware already support both the P8 and PineTime, the physical differences are minor - only a few MCU pins are mapped differently. There are a few open issues on InfiniTime’s GitHub page to add support for this device.\nSpecifications Dimensions: 37.5 x 40 x 11mm Weight: 38 grams IP Rating: IP67 (waterproof to 1 meter (sealed edition)) Display: Size: 1.3 inches (33mm) diagonal Type: IPS capacitive touchscreen, RGB 65K colors Display Controller: ST7789 Resolution: 240x240 pixels System on Chip: Nordic Semiconductor nRF52832 Flash: 512KB with additional 4MB SPI NOR RAM: 64KB Bluetooth: 5.0 (including Bluetooth Low Energy) Sensors: Accelerometer, Heart rate sensor Feedback: Vibration motor Battery: 170-180mAh 3.8V LiPo ","permalink":"/documentation/PineTime/_full/","tags":null,"title":"PineTime (Single Page)"},{"categories":null,"contents":"This article will help you get up to scratch about how to connect your PineTime to your hardware debugger and what to keep in mind.\nThe devkit comes with a set of wires you can use for connecting your programmer to the SWD pins. Most people use friction to make contact with the programming cable. Soldering the wires to the PineTime is not recommended, especially if you don’t have a temperature-controlled iron and good confidence that you can do it - the thin PCB is fragile and easy to break.\nCurrent amount of dead PineTimes (or ruined bundled programming connectors) due to attempted soldering is 5 (update this number when suitable).\nRead this about the battery\nYou have three choices:\na) If you have a soldering iron and you’re confident with using it, it is recommended that you remove the battery until you actually need it. Doing so avoids unnecessary charge cycles and strain on it. It can also potentially prevent issues with your watch not resetting properly or backfeeding power into your debugger-programmer. There’s also the option that you just connect a microswitch between the battery’s positive side and the PineTime, just make sure to isolate your connections so it doesn’t short out against anything.\nb) If you do not have a soldering iron or you’re not confident with using it, don’t disconnect the battery if you ever plan on using it. Don’t bend the wires too much as they’re thin, you won’t be able to reconnect it. Keep in mind that keeping it connected during development will probably reduce the lifetime of the battery. Small load on the 3.3V pin is probably fine, but it will drain the battery empty. Having the battery connected when it’s not empty will also very likely backfeed power into your 3.3V pin - Don’t cause short circuits! Don’t leave the wire dangling!\nc) If you don’t disconnect the battery, also don’t connect the 3.3V pin from the SWD cable when debugging or updating firmware. You only need to use the GND, SWDIO and SWDCLK pins. In that case the watch will run exclusively on battery, but there is no danger of backfeeding power.\nSWD Pinout The devkits have exposed SWD pins for flashing and debugging.\nThe pinout is:\nPogo Pins connection The PineTime Pogo Pins are spring-loaded pins with diamond-shaped tips.\nThe Pogo Pins are meant to be connected temporarily to PineTime’s SWD port for firmware flashing and simple firmware debugging.\nThe other end of the Pogo Pins connects to ST-Link v2 or JLink for flashing and debugging. (ST-Link v2 is shown in the background)\nTo connect PineTime Pogo Pins to PineTime’s SWD Port:\nTo orientate the pins, stick a piece of Sticky Tape to the Pogo Pins as shown above. The Sticky Tape should point away from PineTime’s Battery. Orientation is important. You may damage PineTime with the incorrect orientation! With the Battery at left and Sticky Tape pointing right, the SWD Pins will be arranged left to right as: SWDIO, SWDCLK, 3.3V, GND Connect the other end of the Pogo Pins to the Jumper Cable that’s bundled with PineTime. Connect the Jumper Cable to ST-Link v2 or JLink: SWDIO, SWDCLK, 3.3V, GND. See Reprogramming the PineTime With the Sticky Tape pointing right (away from the Battery), tap and hold the Pogo Pins firmly on PineTime’s SWD Port. But not too hard because the PCB or screen may break. Stabilise the Pogo Pins with your pinky finger as shown above. PineTime should light up and reboot when the Pogo Pins are connected. You may flash and debug PineTime now. See Reprogramming the PineTime The tips of the Pogo Pins will partially penetrate the SWD holes like this. Don’t force them in!\nSoldered wires example Before attempting this, make sure you have a good soldering iron, some magnification and you haven’t set your iron too high. If you haven’t ever before soldered things this small, you really really do not want to start out on something this dense, small and thus fragile.\nRaspberry Pi connection See PineTime Updater\n","permalink":"/documentation/PineTime/Further_information/Devkit_wiring/","tags":null,"title":"PineTime Devkit Wiring"},{"categories":null,"contents":"This page contains a list of PineTime hardware equivalents or very close clones. Primarily to keep track of which devices could possibly be \u0026ldquo;jailbroken\u0026rdquo; and run PineTime firmware.\nPlease add devices that use the same chipset to this list.\nKalakate Seems to be PineTime hardware, interesting GUI, seems DaFit-y\nhttps://www.youtube.com/watch?v=1VdMxbOYxgA Colmi P8 A few firmware already support both the P8 and PineTime, the physical differences are minor - only a few MCU pins are mapped differently. There are a few open issues on InfiniTime’s GitHub page to add support for this device.\n","permalink":"/documentation/PineTime/Further_information/Equivalents/","tags":null,"title":"PineTime Equivalents"},{"categories":null,"contents":"PineTimeStyle is a watchface created for Infinitime and has been included since version 1.3 of Infinitime.\nIt is based on TimeStyle for Pebble by Dan Tilden with permission.\nPineTimeStyle Watchface\nLayout The time is displayed on the left in either 12 or 24h format depending on the system setting. An indicator will appear in the bottom left corner if 12h is selected.\nIn the sidebar on the right there is a battery icon which displays the current charge level, and is replaced by a plug icon when charging. Below it is a bluetooth icon which appears only when bluetooth is connected, and a lower case i which indicates unread notifications are available, generally only if notifications are disabled via the quick settings screen.\nThe current date is displayed in the middle, and at the bottom there is a small gauge which displays the step count, the needle will rotate in a clockwise direction as the step count increases. The gauge scales automatically based on the configured step goal, and the outside of the gauge will turn white when the step goal is reached.\nCustomisation Since version 1.4 of Infinitime, a color picker is available for PineTimeStyle. As of version 1.11, an addition page of customisation has been added which allows the user to customise the sidebar. These settings can be accessed by long pressing on the watchface which will display two buttons, one with a palette icon to access the color settings, one with a cog icon for the sidebar options.\nPineTimeStyle Settings Button\nThe color picker PineTimeStyle Color Settings Interface\nThere are 3 pairs of buttons with left and right arrows which scroll through 17 standard colors. The top pair changes the time text color, middle for the sidebar color and bottom for the time background color.\nThere is also a \u0026lsquo;Rnd\u0026rsquo; button which randomises all colors, a \u0026lsquo;Rst\u0026rsquo; button which resets the colors to standard teal and black, and a cross which closes the settings interface. It can also be closed using the physical button.\nThe sidebar settings PineTimeStyle Sidebar Settings\nAs of Infinitime version 1.13, there are 2 options available in the sidebar settings page - Steps style and Weather.\nBy pressing the \u0026lsquo;Steps style\u0026rsquo; button you can toggle between 3 options, the original full gauge, a half size gauge plus seconds display, or a numerical step count display. The second button, Weather, enables or disables this function. When no weather data is available a ban icon will be displayed with 2 dashes below, and when weather data is available the current temperature plus an icon showing conditions based on the cloud cover and precipitation amount.\nTo learn more about the sending weather data to the watch, see InfiniTime weather\n","permalink":"/documentation/PineTime/Watchfaces/PineTimeStyle/","tags":null,"title":"PineTimeStyle"},{"categories":[""],"contents":" A Smart Home The PineVoice is a BL606P-based home assistant smart speaker. Designed to help build a good community option for voice interactions with software such as Home Assistant.\nDocumentation PineVoice ","permalink":"/devices/pinevoice/","tags":null,"title":"PineVoice"},{"categories":null,"contents":" The PineVoice\nThe PineVoice is a RISC-V based smart speaker based on the Bouffalo Lab BL606P RISC-V SoC with C906 64-bit and E907 32-bit CPU cores supported by 32 MiB of embedded pSRAM memory, 16 MiB of Flash, and with built-in Wi-Fi and Bluetooth radio interfaces. Some of notable features include dual microphone array and full local wake word detection. Factory shipped firmware is open-source and provides Wyoming Satellite, compatible with assistence platforms such as Home Assistant.\nSpecifications The PineVoice is a compact smart speaker based on the Bouffalo Lab BL606P RISC-V SoC. It is designed as a local voice assistant satellite, with Wi-Fi, Bluetooth, a speaker, a dual microphone array, buttons, and a center ring LED.\nSoC and memory PineVoice is based on the Bouffalo Lab BL606P.\nCPU architecture T-Head C906 480 MHz 64-bit RISC-V CPU:\nSupports RISC-V RV64IMAFCV instruction architecture Five-stage single-issue sequentially executed pipeline Level-1 instruction and data cache of Harvard architecture, with a size of 32 KiB and a cache line of 64 bytes Sv39 memory management unit Supports AXI 4.0 128-bit master interface Supports core local interrupt (CLINT) and platform-level interrupt controller (PLIC) Compatible with RISC-V PMP T-Head E907 320 MHz 32-bit RISC-V CPU:\nSupports RISC-V RV32IMAFCP instruction set Supports RISC-V 32-bit and 16-bit mixed instruction set Supports RISC-V machine mode and user mode Integer and floating-point pipelines Supports AXI 4.0 main device interface and AHB 5.0 peripheral interface 32 KiB instruction cache 16 KiB data cache T-Head E902 150 MHz 32-bit RISC-V CPU\nMemory and storage 32 MiB pSRAM 788 KiB SRAM 16 MiB flash storage Hardware features Wireless Wi-Fi 802.11 b/g/n Bluetooth 5.2 Dual-mode (BT+BLE) Audio Built-in speaker (tuned for voice applications) Dual microphone array Controls and indicators PineVoice buttons view\nButton controls Center LED ring and button Hardware mute button See Software for the current factory firmware button behavior and LED status colors.\nPower and connectivity USB-C power input and data channel Debug UART is exposed on unused USB-C pins Package contents USB-A to USB-C power cable Board information, schematics and certifications Module dimensions:\n65 mm x 65 mm x 66 mm Production version schematics:\nPineVoice MainBoard Schematic with component placement 20260311 PineVoice Bottom Board Schematic 20250921 Certifications:\nPineVoice CE Certificate PineVoice FCC Certificate Datasheets Bouffalo BL606P SoC information:\nBouffalo Lab BL606P SoC Datasheet Bouffalo Lab BL606P SoC Reference Manual (BL808 RM applies to BL606P as well) Bouffalo Lab BL606P SoC Product Brief SPI NOR flash information:\nGigaDevice 128 Mb XSPI-Flash Datasheet Winbond 128 Mb QSPI-Flash Datasheet Software overview The factory PineVoice firmware is open-source and turns PineVoice into a voice assistant satellite. It provides Wi-Fi provisioning over Improv and voice assistant connectivity over the Wyoming protocol.\nFirmware is using Alibaba\u0026rsquo;s AliOS, specifically it\u0026rsquo;s \u0026ldquo;YoC/YoCop\u0026rdquo; variation.\nSupported features The current factory firmware supports:\nWi-Fi provisioning using the Improv protocol over Bluetooth Low Energy Wyoming satellite for compatible assistance applications Wyoming mDNS auto-discovery for compatible assistance applications Local wake word detection using MicroWakeWord Setup On first boot, PineVoice starts in Wi-Fi provisioning mode. In this mode, the ring LED blinks yellow. Use WiFi Setup to connect PineVoice to a Wi-Fi network and follow further instructions for connection with Assistance application which supports Wyoming protocol, such as Home Assistant.\nLED ring lightshows The center LED ring is used to show the current state of PineVoice. For most actions and states, light shows are used instead of voice feedback so PineVoice does not unexpectedly disturb the user, for example during the night. Active-state light shows, such as the dim cyan standby light, are intentionally kept dim so they remain visible without being distracting in a dark room.\nStartup and setup Light show Meaning Dim white fade-in/fade-out, once Boot-up lightshow. PineVoice has started. Yellow breath, loop PineVoice is in provisioning mode and is ready to connect to Wi-Fi through the Improv protocol. Green fade-in/fade-out, once Identification signal during provisioning, used to identify the paired PineVoice. Dim orange breath, loop PineVoice is trying to connect to Wi-Fi. Dim magenta breath, loop PineVoice is waiting for a Wyoming client to connect. Assistant states Light show Meaning Dim cyan, still PineVoice is active and in standby, waiting for the user to press the center button or say the wake word. Blue-cyan-blue breath, loop PineVoice is listening to the user\u0026rsquo;s voice input. Dim purple, still PineVoice is processing the user\u0026rsquo;s input. Slow green breath, loop PineVoice is answering. Action feedback Light show Meaning White fade-in, once Volume up. White fade-out, once Volume down. Red fade-out, once An error happened or the action failed. Button controls PineVoice buttons view\nPineVoice has five top buttons for voice control, volume, microphone mute, and provisioning.\nCenter LED ring button - starts a voice command session. + button - increases the volume. - button - decreases the volume. Microphone button - hardware microphone mute. The button shines red while microphone mute is active. Dot / user button - currently used to enter provisioning mode. Hold it for 15 seconds to reset Wi-Fi setup and return PineVoice to provisioning mode. Voice feedback As mentioned in LED ring lightshows, voice feedback is used rarely. PineVoice mostly uses light shows instead, and voice feedback is generally reserved for direct user interaction.\nAudio feedback is currently used in the following cases:\nWi-Fi provisioning started - played when Wi-Fi provisioning starts, including on first boot. Wi-Fi provisioning succeeded or failed - played when Wi-Fi provisioning finishes successfully or fails. Wyoming satellite is disconnected - played when Assist is attempted, but the Wyoming satellite/client is not connected. Wi-Fi is disconnected - played when Assist is attempted, but PineVoice is not connected to Wi-Fi. Wake word detection PineVoice uses MicroWakeWord for local wake word detection.\nFor now, PineVoice uses the \u0026ldquo;Hey Jarvis\u0026rdquo; model from the ESPHome MicroWakeWord models project. The wake word generally works well, but recognition may vary depending on the speaker\u0026rsquo;s voice, pronunciation, distance from the device, and background noise.\nNote Future firmware updates are expected to add support for using custom MicroWakeWord-compatible models. There are also plans to train a PineVoice-specific wake word model. If you are interested in helping with model training, contact us through the community channels. Source code You can find source code of this firmware (PineVoice SmartSpeaker SDK) on Codeberg and Github.\nWiFi Setup PineVoice implements open-source WiFi Provisioning protocol Improv. Any application supporting this protocol is capable of setting up WiFi on the PineVoice.\nEntering Provisioning Mode On first boot, the speaker automatically enters Wi-Fi provisioning mode. While in this mode, the ring LED blinks yellow.\nIf the ring LED is not blinking yellow, the speaker is not in provisioning mode. Perform a factory reset to return it to provisioning mode, by holding • dot button for 15 seconds. After releasing the button, PineVoice should restart and launch Provisioning Mode.\nProvisioning Once the speaker is in provisioning mode (ring LED blinking yellow), use one of the following methods to send the Wi-Fi credentials:\nThrough Web Info Web Provisioning requires browser with Web Bluetooth API support. Please refer this table if your browser is supported. Open this website on your PC or phone, which have Bluetooth 4.0 (Low Energy) connectivity and then press following button:\nAlternative web provisioning If button on this website does not work, try it on Improv website.\nThrough Home Assistant Home Assistants supports Improv via BLE. This feature must be set up properly to be functional. Please, follow this instructions on Home Assistant website.\nThis card should pop up automatically in your Home Assistant on Devices page:\nImprov Card in Home Assistant\nAfter successful provisioning, please continue to Assistance Setup.\nAssistance Setup PineVoice implements the open-source Wyoming protocol for voice assistants. Any assistance application supporting this protocol can communicate with PineVoice.\nBefore starting Complete WiFi Setup first. After PineVoice has joined the Wi-Fi network, the center ring LED should slowly breathe in a dim magenta color. This means that PineVoice is connected to Wi-Fi and is waiting for an assistance application to connect through the Wyoming protocol.\nAdding PineVoice to Home Assistant Home Assistant supports Wyoming Protocol devices through the Wyoming Protocol integration. Home Assistant must also have a working Assist voice pipeline. Follow the Home Assistant Assist documentation if Assist has not been configured yet.\nAutomatic setup PineVoice supports mDNS auto-discovery. If Home Assistant can see mDNS announcements on the same network, PineVoice should appear automatically as a discovered Wyoming Protocol device.\nOpen Home Assistant. Go to Settings -\u0026gt; Devices \u0026amp; services. Look for a discovered Wyoming Protocol device. Select Configure. Follow the on-screen instructions to finish adding PineVoice. After setup completes, PineVoice should be available as an Assist satellite in Home Assistant.\nManual setup If PineVoice does not appear automatically, add it manually through the Wyoming Protocol integration.\nFind the IP address of PineVoice in the client list of your Wi-Fi router or access point. Open Home Assistant. Go to Settings -\u0026gt; Devices \u0026amp; services. Select Add integration. Search for and select Wyoming Protocol. Enter the PineVoice IP address as the host. Enter 10700 as the port. Follow the on-screen instructions to finish adding PineVoice. Troubleshooting Important If following bugs occurs:\nPineVoice is stuck in listening state or Home Assistant does not react to start of Assist - restart PineVoice. Device add failed - press Retry / Try Again, or try to add the PineVoice again. Following bugs are being investigated and will be fixed in update of PineVoice firmware or Home Assistant Core.\nIf Home Assistant cannot connect to PineVoice, check the following:\nPineVoice and Home Assistant are on the same network or VLAN. The center ring LED is breathing in dim magenta. The IP address entered in Home Assistant is the current IP address of PineVoice. TCP port 10700 is reachable from the Home Assistant system. mDNS is allowed on the network if using automatic discovery. For more information, see the Home Assistant Wyoming Protocol integration documentation.\nTesting After PineVoice is properly added to an assistance application, assist can be triggered in the following ways:\nSay the wake word: \u0026ldquo;Hey Jarvis\u0026rdquo; Press the center button in the LED ring After triggering assist, say a command supported by the assistance application. The assistance application should then reply accordingly.\n","permalink":"/documentation/PineVoice/_full/","tags":null,"title":"PineVoice (Single Page)"},{"categories":null,"contents":" Note: Pin1 is marked on the board by a white dot on the PCB. See the PDF and HTML for details.\n","permalink":"/documentation/PineCube/Pinout/","tags":null,"title":"Pinout"},{"categories":null,"contents":" Model \u0026ldquo;A\u0026rdquo; The Quartz64 Model A board pinout\nModel \u0026ldquo;B\u0026rdquo; The Quartz64 Model B board pinout\n","permalink":"/documentation/Quartz64/Pinout/","tags":null,"title":"Pinout"},{"categories":null,"contents":" The STAR64 board pinout\n","permalink":"/documentation/STAR64/Pinout/","tags":null,"title":"Pinout"},{"categories":null,"contents":" ","permalink":"/documentation/StarPro64/Pinout/","tags":null,"title":"Pinout"},{"categories":null,"contents":" SOQuartz Module Connector Pins Definition ver 1.0 ","permalink":"/documentation/SOQuartz/Pins/","tags":null,"title":"Pins"},{"categories":null,"contents":" GPIO Alternate Functions Table This is table of all available GPIOs on SOPine with their alternate functions.\nFor more information about GPIOs, check the Allwinner A64 Datasheet section 4.2 GPIO Multiplexing Functions and section 4.3 Detailed Pin/Signal Description\nPin name Linux SOPine Pin Direction Default Function Default Pull Function 2 Function 3 Function 4 Function 5 Function 6 SOPine Name PB0 GPIO32 35 I/O DIS Z UART2_TX JTAG_MS0 PB_EINT0 PB0-UART2_TX PB1 GPIO33 75 I/O DIS Z UART2_RX JTAG_CK0 SIM_PWREN PB_EINT1 PB1-UART2_RX PB2 GPIO34 36 I/O DIS Z UART2_RTS JTAG_DO0 SIM_VPPEN PB_EINT2 PB2 PB3 GPIO35 30 I/O DIS Z UART2_CTS I2S0_MCLK JTAG_DI0 SIM_VPPPP PB_EINT3 PB3-I3S_MCLK PB4 GPIO36 28 I/O DIS Z AIF2_SYNC PCM0_SYNC SIM_CLK PB_EINT4 PB4-I2S_SYNC PB5 GPIO37 27 I/O DIS Z AIF2_BCLK PCM0_BCLK SIM_DATA PB_EINT5 PB5-I2S_BCLK PB6 GPIO38 39 I/O DIS Z AIF2_DOUT PCM0_DOUT SIM_RST PB_EINT6 PB6-I2S_DOUT PB7 GPIO39 29 I/O DIS Z AIF2_DIN PCM0_DIN SIM_DET PB_EINT7 PB7-I2S_DIN PB8 GPIO40 34 I/O DIS Z UART0_TX PB_EINT8 PB8 PB9 GPIO41 33 I/O DIS Z UART0_RX PB_EINT9 PB9 PC0 GPIO64 134 I/O DIS Z NAND_WE SPI0_MOSI PC0-SPIO_MOSI PC1 GPIO65 150 I/O DIS Z NAND_ALE SDC2_DS SPI0_MISO PC1-SPIO_MISO PC2 GPIO66 142 I/O DIS Z NAND_CLE SPI0_CLK PC2-SPIO_CLK PC3 GPIO67 148 I/O DIS Pull-Up NAND_CE1 SPI0_CS PC3-SPIO_CS PC4 GPIO68 135 I/O DIS Pull-Up NAND_CE0 PC4 PC5 GPIO69 25 I/O DIS Z NAND_RE SDC2_CLK PC5 PC6 GPIO70 154 I/O DIS Pull-Up NAND_RB0 SDC2_CMD PC6 PC7 GPIO71 132 I/O DIS Pull-Up NAND_RB1 PC7 PC8 GPIO72 130 I/O DIS Z NAND_DQ0 SDC2_D0 PC8 PC9 GPIO73 153 I/O DIS Z NAND_DQ1 SDC2_D1 PC9 PC10 GPIO74 156 I/O DIS Z NAND_DQ2 SDC2_D2 PC10 PC11 GPIO75 165 I/O DIS Z NAND_DQ3 SDC2_D3 PC11 PC12 GPIO76 146 I/O DIS Z NAND_DQ4 SDC2_D4 PC12 PC13 GPIO77 157 I/O DIS Z NAND_DQ5 SDC2_D5 PC13 PC14 GPIO78 155 I/O DIS Z NAND_DQ6 SDC2_D6 PC14 PC15 GPIO79 133 I/O DIS Z NAND_DQ7 SDC2_D7 PC15 PC16 GPIO80 144 I/O DIS Z NAND_DQS SDC2_RST PC16 PD0 GPIO96 60 I/O DIS Z LCD_D2 UART3_TX SPI1_CS CCIR_CLK PD0-SPI1_CS PD1 GPIO97 49 I/O DIS Z LCD_D3 UART3_RX SPI1_CLK CCIR_DE PD1-SPI1_CLK PD2 GPIO98 57 I/O DIS Z LCD_D4 UART4_TX SPI1_MOSI CCIR_HSYNC PD2-SPI1_MOSI PD3 GPIO99 61 I/O DIS Z LCD_D5 UART4_RX SPI1_MISO CCIR_VSYNC PD3-SPI1_MISO PD4 GPIO100 52 I/O DIS Z LCD_D6 UART4_RTS CCIR_D0 PD4-UART4_RTS PD5 GPIO101 44 I/O DIS Z LCD_D7 UART4_CTS CCIR_D1 PD5-UART4_CTS PD6 GPIO102 45 I/O DIS Z LCD_D10 CCIR_D2 PD6 PD7 GPIO103 40 I/O DIS Z LCD_D11 CCIR_D3 PD7 PD8 GPIO104 73 I/O DIS Z LCD_D12 RGMII_RXD3/RMII_NULL CCIR_D4 GRXD3 PD9 GPIO105 83 I/O DIS Z LCD_D13 RGMII_RXD2/RMII_NULL CCIR_D5 GRXD2 PD10 GPIO106 51 I/O DIS Z LCD_D14 RGMII_RXD1/RMII_RXD1 RMII-RXD1 PD11 GPIO107 48 I/O DIS Z LCD_D15 RGMII_RXD0/RMII_RXD0 RMII-RXD0 PD12 GPIO108 91 I/O DIS Z LCD_D18 LVDS_VP0 RGMII_RXCK/RMII_NULL GRXCK PD13 GPIO109 89 I/O DIS Z LCD_D19 LVDS_VN0 RGMII_RXCT/RMII_CRS_DV RMII-CRS-DV PD14 GPIO110 87 I/O DIS Z LCD_D20 LVDS_VP1 RGMII_NULL/RMII_RXER RMII-RXER PD15 GPIO111 80 I/O DIS Z LCD_D21 LVDS_VN1 RGMII_TXD3/RMII_NULL CCIR_D6 GTXD3 PD16 GPIO112 82 I/O DIS Z LCD_D22 LVDS_VP2 RGMII_TXD2/RMII_NULL CCIR_D7 GTXD2 PD17 GPIO113 78 I/O DIS Z LCD_D23 LVDS_VN2 RGMII_TXD1/RMII_TXD1 RMII-TXD1 PD18 GPIO114 85 I/O DIS Z LCD_CLK LVDS_VPC RGMII_TXD0/RMII_TXD0 RMII-TXD0 PD19 GPIO115 79 I/O DIS Z LCD_DE LVDS_VNC RGMII_TXCK/RMII_TXCK RMII-TXCK PD20 GPIO116 47 I/O DIS Z LCD_HSYNC LVDS_VP3 RGMII_TXCTL/RMII_TXEN RMII-TXEN PD21 GPIO117 74 I/O DIS Z LCD_VSYNC LVDS_VN3 RGMII_CLKINRMII_NULL GCLKIN PD22 GPIO118 53 I/O DIS Z PWM0 MDC RMII-MDC PD23 GPIO119 76 I/O DIS Z MDIO RMII-MDIO PD24 GPIO120 50 I/O DIS Z LCD-RST PE0 GPIO128 58 I/O DIS Z CSI_PCLK TS_CLK CSI-PCLK PE1 GPIO129 102 I/O DIS Z CSI_MCLK TS_ERR CSI-MCLK PE2 GPIO130 100 I/O DIS Z CSI_HSYNC TS_SYNC CSI-HSYNC PE3 GPIO131 101 I/O DIS Z CSI_VSYNC TS_DVLD CSI-VSYNC PE4 GPIO132 95 I/O DIS Z CSI_D0 TS_D0 CSI-D0 PE5 GPIO133 54 I/O DIS Z CSI_D1 TS_D1 CSI-D1 PE6 GPIO134 96 I/O DIS Z CSI_D2 TS_D2 CSI-D2 PE7 GPIO135 65 I/O DIS Z CSI_D3 TS_D3 CSI-D3 PE8 GPIO136 105 I/O DIS Z CSI_D4 TS_D4 CSI-D4 PE9 GPIO137 59 I/O DIS Z CSI_D5 TS_D5 CSI-D5 PE10 GPIO138 107 I/O DIS Z CSI_D6 TS_D6 CSI-D6 PE11 GPIO139 111 I/O DIS Z CSI_D7 TS_D7 CSI-D7 PE12 GPIO140 98 I/O DIS Z CSI_SCK CSI-SCK PE13 GPIO141 113 I/O DIS Z CSI_SDA CSI-SDA PE16 GPIO144 92 I/O DIS Z CSI-RST-F PE17 GPIO145 109 I/O DIS Z CSI-STBY-F PG0 GPIO192 72 I/O DIS Z SDC1_CLK PG_EINT0 WL-SDIO-CLK PG1 GPIO193 108 I/O DIS Z SDC1_CMD PG_EINT1 WL-SDIO-CMD PG2 GPIO194 63 I/O DIS Z SDC1_D0 PG_EINT2 WL-SDIO-D0 PG3 GPIO195 110 I/O DIS Z SDC1_D1 PG_EINT3 WL-SDIO-D1 PG4 GPIO196 106 I/O DIS Z SDC1_D2 PG_EINT4 WL-SDIO-D2 PG5 GPIO197 112 I/O DIS Z SDC1_D3 PG_EINT5 WL-SDIO-D3 PG6 GPIO198 90 I/O DIS Z UART1_TX PG_EINT6 BT-UART-RX PG7 GPIO199 119 I/O DIS Z UART1_RX PG_EINT7 BT-UART-TX PG8 GPIO200 88 I/O DIS Z UART1_RTS PG_EINT8 BT-UART-CTS PG9 GPIO201 117 I/O DIS Z UART1_CTS PG_EINT9 BT-UART-RTS PG10 GPIO202 99 I/O DIS Z AIF3_SYNC PCM1_SYNC PG_EINT10 BT-PCM-SYNC PG11 GPIO203 86 I/O DIS Z AIF3_BCLK PCM1_BCLK PG_EINT11 BT-PCM-CLK PG12 GPIO204 120 I/O DIS Z AIF3_DOUT PCM1_DOUT PG_EINT12 BT-PCM-DIN PG13 GPIO205 97 I/O DIS Z AIF3_DIN PCM1_DIN PG_EINT13 BT-PCM-DOUT PH0 GPIO224 43 I/O DIS Z I2C0_SCL PH_EINT0 TP-SCK PH1 GPIO225 46 I/O DIS Z I2C0_SDA PH_EINT1 TP-SDA PH2 GPIO226 62 I/O DIS Z I2C1_SCL PH_EINT2 PH2-TW1_SCK PH3 GPIO227 37 I/O DIS Z I2C1_SDA PH_EINT3 PH3-TW1_SDA PH4 GPIO228 64 I/O DIS Z UART3_TX PH_EINT4 TP-INT PH5 GPIO229 68 I/O DIS Z UART3_RX PH_EINT5 PH5 PH6 GPIO230 66 I/O DIS Z UART3_RTS PH_EINT6 PH6 PH7 GPIO231 71 I/O DIS Z UART3_CTS PH_EINT7 PH7 PH8 GPIO232 38 I/O DIS Z OWA_OUT PH_EINT8 PH8-OWA_OUT PH9 GPIO233 77 I/O DIS Z PH_EINT9 PH9 PH10 GPIO234 26 I/O DIS Z MIC_CLK PH_EINT10 LCD-BL-EN PH11 GPIO235 67 I/O DIS Z MIC_DATA PH_EINT11 CTP-RST PL2 GPIO354 21 I/O DIS Z S_UART_TX S_PL_EINT2 WL-REG-ON PL3 GPIO355 23 I/O DIS Z S_UART_RX S_PL_EINT3 WL-WAKE-AP PL4 GPIO356 14 I/O DIS Z S_JTAG_MS S_PL_EINT4 BT-RST-N PL5 GPIO357 18 I/O DIS Z S_JTAG_CK S_PL_EINT5 BT-WAKE-AP PL6 GPIO358 16 I/O DIS Z S_JTAG_DO S_PL_EINT6 AP-WAKE-BT PL7 GPIO359 24 I/O DIS Z S_JTAG_DI S_PL_EINT7 PL7 PL8 GPIO360 15 I/O DIS Z S_I2C_CLK S_PL_EINT8 PL8-S_TWI_SCK PL9 GPIO361 17 I/O DIS Z S_I2C_SDA S_PL_EINT9 PL9-S_TWI_SDA PL10 GPIO362 166 I/O DIS Z S_PWM S_PL_EINT10 PL10-S_PWM PL11 GPIO363 13 I/O DIS Z S_CIR_RX S_PL_EINT11 PL11-IR_RX Pin Assignment Table This table contains Pin Assignment of SOPine Edge Finger. For more information about peripherals, GPIOs, powering see:\nAllwinner A64 Datasheet section 4.2 GPIO Multiplexing Functions and section 4.3 Detailed Pin/Signal Description Power Management Unit Datasheet For Edge Finger view, see:\nEdge Finger Pin Assignment Table forum.pine64.org: a PDF mapping the pins from the A64 chip itself, to the gold-fingers on the SO-DIMM edge, to the multiple connectors on the baseboard and on the clusterboard, attached to this forum post. SOPine Pin SOPine Name Allwinner name Allwinner category Ball Type Description 1 HBIAS HBIAS AUDIO_CODEC D13 AO Master Analog Headphone Bias Voltage Output 2 EAROUT_P EAROUTP AUDIO_CODEC B13 AO Earpiece Amplifier Positive Differential Output 3 HPOUTL HPOUTL AUDIO_CODEC C13 AO Headphone Output Left Channel 4 EAROUT_N EAROUTN AUDIO_CODEC A13 AO Earpiece Amplifier Negative Differential Output 5 HPOUTR HPOUTR AUDIO_CODEC C12 AO Headphone Output Right Channel 6 HS-MIC MIC-DET AUDIO_CODEC B10 AI Headphone MIC Detect 7 GND GND POWER ? G 8 GND GND POWER ? G 9 MIC2N MICIN2N AUDIO_CODEC A17 AI Microphone Negative Input 2 10 HPOUTFB HP-FB AUDIO_CODEC C10 AI Headphone Common Reference Feedback Input 11 MIC2P MICIN2P AUDIO_CODEC B17 AI Microphone Positive Input 2 12 KEYADC KEYADC ADC A16 AI ADC input for key 13 GPIO363 PL11 GPIO PL11 GPIO General Purpose Input Output #363 14 GPIO356 PL4 GPIO PL4 GPIO General Purpose Input Output #356 15 GPIO360 PL8 GPIO PL8 GPIO General Purpose Input Output #360 16 GPIO358 PL6 GPIO PL6 GPIO General Purpose Input Output #358 17 GPIO361 PL9 GPIO PL9 GPIO General Purpose Input Output #361 18 GPIO357 PL5 GPIO PL5 GPIO General Purpose Input Output #357 19 GND GND POWER ? G 20 GND GND POWER ? G 21 GPIO354 PL2 GPIO PL2 GPIO General Purpose Input Output #354 22 HP-DET HP-DET AUDIO_CODEC D11 AI Headphone Detect 23 GPIO355 PL3 GPIO PL3 GPIO General Purpose Input Output #355 24 GPIO359 PL7 GPIO PL7 GPIO General Purpose Input Output #359 25 GPIO69 PC5 GPIO PC5 GPIO General Purpose Input Output #69 26 GPIO234 PH10 GPIO PH10 GPIO General Purpose Input Output #234 27 GPIO37 PB5 GPIO PB5 GPIO General Purpose Input Output #37 28 GPIO36 PB4 GPIO PB4 GPIO General Purpose Input Output #36 29 GPIO39 PB7 GPIO PB7 GPIO General Purpose Input Output #39 30 GPIO35 PB3 GPIO PB3 GPIO General Purpose Input Output #35 31 GND GND POWER ? G 32 GND GND POWER ? G 33 GPIO41 PB9 GPIO PB9 GPIO General Purpose Input Output #41 34 GPIO40 PB8 GPIO PB8 GPIO General Purpose Input Output #40 35 GPIO32 PB0 GPIO PB0 GPIO General Purpose Input Output #32 36 GPIO34 PB2 GPIO PB2 GPIO General Purpose Input Output #34 37 GPIO227 PH3 GPIO PH3 GPIO General Purpose Input Output #227 38 GPIO232 PH8 GPIO PH8 GPIO General Purpose Input Output #232 39 GPIO38 PB6 GPIO PB6 GPIO General Purpose Input Output #38 40 GPIO103 PD7 GPIO PD7 GPIO General Purpose Input Output #103 41 GND GND POWER ? G 42 GND GND POWER ? G 43 GPIO224 PH0 GPIO PH0 GPIO General Purpose Input Output #224 44 GPIO101 PD5 GPIO PD5 GPIO General Purpose Input Output #101 45 GPIO102 PD6 GPIO PD6 GPIO General Purpose Input Output #102 46 GPIO225 PH1 GPIO PH1 GPIO General Purpose Input Output #225 47 GPIO116 PD20 GPIO PD20 GPIO General Purpose Input Output #116 48 GPIO107 PD11 GPIO PD11 GPIO General Purpose Input Output #107 49 GPIO97 PD1 GPIO PD1 GPIO General Purpose Input Output #97 50 GPIO120 PD24 GPIO PD24 GPIO General Purpose Input Output #120 51 GPIO106 PD10 GPIO PD10 GPIO General Purpose Input Output #106 52 GPIO100 PD4 GPIO PD4 GPIO General Purpose Input Output #100 53 GPIO118 PD22 GPIO PD22 GPIO General Purpose Input Output #118 54 GPIO133 PE5 GPIO PE5 GPIO General Purpose Input Output #133 55 GND GND POWER ? G 56 GND GND POWER ? G 57 GPIO98 PD2 GPIO PD2 GPIO General Purpose Input Output #98 58 GPIO128 PE0 GPIO PE0 GPIO General Purpose Input Output #128 59 GPIO137 PE9 GPIO PE9 GPIO General Purpose Input Output #137 60 GPIO96 PD0 GPIO PD0 GPIO General Purpose Input Output #96 61 GPIO99 PD3 GPIO PD3 GPIO General Purpose Input Output #99 62 GPIO226 PH2 GPIO PH2 GPIO General Purpose Input Output #226 63 GPIO194 PG2 GPIO PG2 GPIO General Purpose Input Output #194 64 GPIO228 PH4 GPIO PH4 GPIO General Purpose Input Output #228 65 GPIO135 PE7 GPIO PE7 GPIO General Purpose Input Output #135 66 GPIO230 PH6 GPIO PH6 GPIO General Purpose Input Output #230 67 GPIO235 PH11 GPIO PH11 GPIO General Purpose Input Output #235 68 GPIO229 PH5 GPIO PH5 GPIO General Purpose Input Output #229 69 GND GND POWER ? G 70 GND GND POWER ? G 71 GPIO231 PH7 GPIO PH7 GPIO General Purpose Input Output #231 72 GPIO192 PG0 GPIO PG0 GPIO General Purpose Input Output #192 73 GPIO104 PD8 GPIO PD8 GPIO General Purpose Input Output #104 74 GPIO117 PD21 GPIO PD21 GPIO General Purpose Input Output #117 75 GPIO33 PB1 GPIO PB1 GPIO General Purpose Input Output #33 76 GPIO119 PD23 GPIO PD23 GPIO General Purpose Input Output #119 77 GPIO233 PH9 GPIO PH9 GPIO General Purpose Input Output #233 78 GPIO113 PD17 GPIO PD17 GPIO General Purpose Input Output #113 79 GPIO115 PD19 GPIO PD19 GPIO General Purpose Input Output #115 80 GPIO111 PD15 GPIO PD15 GPIO General Purpose Input Output #111 81 GND GND POWER ? G 82 GPIO112 PD16 GPIO PD16 GPIO General Purpose Input Output #112 83 GPIO105 PD9 GPIO PD9 GPIO General Purpose Input Output #105 84 GND GND POWER ? G 85 GPIO114 PD18 GPIO PD18 GPIO General Purpose Input Output #114 86 GPIO203 PG11 GPIO PG11 GPIO General Purpose Input Output #203 87 GPIO110 PD14 GPIO PD14 GPIO General Purpose Input Output #110 88 GPIO200 PG8 GPIO PG8 GPIO General Purpose Input Output #200 89 GPIO109 PD13 GPIO PD13 GPIO General Purpose Input Output #109 90 GPIO198 PG6 GPIO PG6 GPIO General Purpose Input Output #198 91 GPIO108 PD12 GPIO PD12 GPIO General Purpose Input Output #108 92 GPIO144 PE16 GPIO PE16 GPIO General Purpose Input Output #144 93 GND GND POWER ? G 94 GND GND POWER ? G 95 GPIO132 PE4 GPIO PE4 GPIO General Purpose Input Output #132 96 GPIO134 PE6 GPIO PE6 GPIO General Purpose Input Output #134 97 GPIO205 PG13 GPIO PG13 GPIO General Purpose Input Output #205 98 GPIO140 PE12 GPIO PE12 GPIO General Purpose Input Output #140 99 GPIO202 PG10 GPIO PG10 GPIO General Purpose Input Output #202 100 GPIO130 PE2 GPIO PE2 GPIO General Purpose Input Output #130 101 GPIO131 PE3 GPIO PE3 GPIO General Purpose Input Output #131 102 GPIO129 PE1 GPIO PE1 GPIO General Purpose Input Output #129 103 GND GND POWER ? G 104 GND GND POWER ? G 105 GPIO136 PE8 GPIO PE8 GPIO General Purpose Input Output #136 106 GPIO196 PG4 GPIO PG4 GPIO General Purpose Input Output #196 107 GPIO138 PE10 GPIO PE10 GPIO General Purpose Input Output #138 108 GPIO193 PG1 GPIO PG1 GPIO General Purpose Input Output #193 109 GPIO145 PE17 GPIO PE17 GPIO General Purpose Input Output #145 110 GPIO195 PG3 GPIO PG3 GPIO General Purpose Input Output #195 111 GPIO139 PE11 GPIO PE11 GPIO General Purpose Input Output #139 112 GPIO197 PG5 GPIO PG5 GPIO General Purpose Input Output #197 113 GPIO141 PE13 GPIO PE13 GPIO General Purpose Input Output #141 114 GND GND POWER ? G 115 GND GND POWER ? G 116 DSI-D1P MDSI-D1P MIPI_DSI P22 AO MIPI DSI Positive Differential Data Line 1 117 GPIO201 PG9 GPIO PG9 GPIO General Purpose Input Output #201 118 DSI-D1N MDSI-D1N MIPI_DSI R22 AO MIPI DSI Negative Differential Data Line 1 119 GPIO199 PG7 GPIO PG7 GPIO General Purpose Input Output #199 120 GPIO204 PG12 GPIO PG12 GPIO General Purpose Input Output #204 121 DSI-D0P MDSI-D0P MIPI_DSI T22 AO MIPI DSI Positive Differential Data Line 0 122 DSI-D3P MDSI-D3P MIPI_DSI L23 AO MIPI DSI Positive Differential Data Line 3 123 DSI-D0N MDSI-D0N MIPI_DSI T23 AO MIPI DSI Negative Differential Data Line 0 124 DSI-D3N MDSI-D3N MIPI_DSI L22 AO MIPI DSI Negative Differential Data Line 3 125 GND GND POWER ? G 126 DSI-D2P MDSI-D2P MIPI_DSI M22 AO MIPI DSI Positive Differential Data Line 2 127 DSI-CKP MDSI-CKP MIPI_DSI N23 AO MIPI DSI Positive Differential Clock Line 128 DSI-D2N MDSI-D2N MIPI_DSI N22 AO MIPI DSI Negative Differential Data Line 2 129 DSI-CKN MDSI-CKN MIPI_DSI P23 AO MIPI DSI Negative Differential Clock Line 130 GPIO72 PC8 GPIO PC8 GPIO General Purpose Input Output #72 131 GND GND POWER ? G 132 GPIO71 PC7 GPIO PC7 GPIO General Purpose Input Output #71 133 GPIO79 PC15 GPIO PC15 GPIO General Purpose Input Output #79 134 GPIO64 PC0 GPIO PC0 GPIO General Purpose Input Output #64 135 GPIO68 PC4 GPIO PC4 GPIO General Purpose Input Output #68 136 VIDEO-HTX0P HTX0P HDMI G22 AO HDMI Positive Differential Data Line 0 137 GND GND POWER ? G 138 VIDEO-HTX0N HTX0N HDMI G23 AO HDMI Negative Differential Data Line 0 139 VIDEO-HTX2N HTX2N HDMI E22 AO HDMI Negative Differential Data Line 2 140 GND GND POWER ? G 141 VIDEO-HTX2P HTX2P HDMI D23 AO HDMI Positive Differential Data Line 2 142 GPIO66 PC2 GPIO PC2 GPIO General Purpose Input Output #66 143 VIDEO-HTX1P HTX1P HDMI E23 AO HDMI Positive Differential Data Line 1 144 GPIO80 PC16 GPIO PC16 GPIO General Purpose Input Output #80 145 VIDEO-HTX1N HTX1N HDMI F22 AO HDMI Negative Differential Data Line 1 146 GPIO76 PC12 GPIO PC12 GPIO General Purpose Input Output #76 147 GND GND POWER ? G 148 GPIO67 PC3 GPIO PC3 GPIO General Purpose Input Output #67 149 VIDEO-TXCN HTXCN HDMI H23 AO HDMI Negative Differential Clock Line 150 GPIO65 PC1 GPIO PC1 GPIO General Purpose Input Output #65 151 VIDEO-TXCP HTXCP HDMI H22 AO HDMI Positive Differential Clock Line 152 GND GND POWER ? G 153 GPIO73 PC9 GPIO PC9 GPIO General Purpose Input Output #73 154 GPIO70 PC6 GPIO PC6 GPIO General Purpose Input Output #70 155 GPIO78 PC14 GPIO PC14 GPIO General Purpose Input Output #78 156 GPIO74 PC10 GPIO PC10 GPIO General Purpose Input Output #74 157 GPIO77 PC13 GPIO PC13 GPIO General Purpose Input Output #77 158 USB1-DP USB1-DP USB B23 A I/O USB 1 Data Positive 159 GND GND POWER ? G 160 USB1-DM USB1-DM USB C22 A I/O USB 1 Data Negative 161 VIDEO-SCL HSCL HDMI G21 I/O HDMI DDC Clock 162 GND GND POWER ? G 163 VIDEO-SDA HSDA HDMI E20 I/O HDMI DDC Data 164 VIDEO-HPD HHPD HDMI E21 I/O HDMI Hot Plug Detection 165 GPIO75 PC11 GPIO PC11 GPIO General Purpose Input Output #75 166 GPIO362 PL10 GPIO PL10 GPIO General Purpose Input Output #362 167 VIDEO-CEC HCEC HDMI F21 I/O HDMI CEC 168 PWR_ON PWRON PMU 60 I Power On-Off key input 169 GND GND POWER ? G 170 NC 171 USB0-DP USB0-DP USB A22 A I/O USB 0 Data Positive 172 DCDC1 DCDC1 POWER ? P 3.3V from DCDC for eMMC, LEDs and other external devices with higher power consumption 173 USB0-DM USB0-DM USB B22 A I/O USB 0 Data Negative 174 GPIO0-LDO GPIO0 POWER ? P 3.3V@100mA from LDO for Capacitive Touch Screen I2C interface as pull-up and other purposes with low power consumption 175 CHG_LED CHGLED OTHER 53 O Charger status indication 176 ALDO1 ALDO1 POWER ? P 2.8V@500mA from LDO for CSI Camera and other 2.8V based devices with low power consumption 177 RESET RESET OTHER ? I Pin for restarting of device, ground pin to perform device reset 178 NC 179 NC 180 DCIN ACIN POWER ? P 5V input, but probably can be more, look at the AXP803 datasheet 181 ELDO3 ELDO3 POWER ? P 1.8V@200mA from LDO for CSI Camera and other 1.8V based devices with low power consumption 182 DCIN ACIN POWER ? P 5V input, but probably can be more, look at the AXP803 datasheet 183 DLDO3 DLDO3 POWER ? P 2.8V@300mA from LDO for CSI Camera and other 2.8V based devices with low power consumption 184 DCIN ACIN POWER ? P 5V input, but probably can be more, look at the AXP803 datasheet 185 VCC-WIFI DLDO4 POWER ? P 3.3V@500mA from LDO for WiFi, Bluetooth and other 3.3V based devices 186 NC 187 DC1-SW DC1-SW POWER ? P 3.3V from DCDC for LCD and Ethernet (RGMII, RMII so GMAC and EMAC) and other 3.3V based devices 188 USBVBUS USBVBUS POWER ? P 5V for powering and charging PMU 189 DLDO2 DLDO2 POWER ? P Probably 1.8V@400mA (some sources indicate 3.3V) from DCDC for MIPI and other 1.8V based devices 190 USBVBUS USBVBUS POWER ? P 5V for powering and charging PMU 191 DLDO1 DLDO1 POWER ? P 3.3V@500mA from LDO for HDMI, MIPI DSI and other 3.3V based devices 192 USBVBUS USBVBUS POWER ? P 5V for powering and charging PMU 193 VCC-WIFI-IO DLDO4 POWER ? P 3.3V@500mA from LDO for WiFi, Bluetooth and other 3.3V based devices 194 NC 195 NC 196 BATT_SENSOR TS PMU ? I Battery Temperature Sensor Input 197 VRTC VCC-RTC PMU ? O Output pin of RTLCDO (NOT SURE) 198 NC 199 PS IPSOUT POWER 55 P 3.5V-5V@3A System power source 200 VBAT VBAT POWER ? P 3.5-4.2V power input from battery 201 PS IPSOUT POWER 55 P 3.5V-5V@3A System power source 202 VBAT VBAT POWER ? P 3.5-4.2V power input from battery 203 PS IPSOUT POWER 55 P 3.5V-5V@3A System power source 204 VBAT VBAT POWER ? P 3.5-4.2V power input from battery ","permalink":"/documentation/SOPINE/Pins_and_GPIOs/","tags":null,"title":"Pins and GPIOs"},{"categories":null,"contents":"Peripheral On Top (POT)\nPOT Board Recommended PCB Dimension POT board dimension for Pine A64 in DXF format POT board dimension for Pine A64 in PDF format USB/UART Programming/Console Adapter (PMPROG01) Feature Base on Silicon Libs CP2102 Support Virtual COM Port Device Drivers Support USBXpress™ Direct Driver Support With XH 5 pin 2.54mm pitch connector for UART connection Voltage Output on the connection is selectable to either 5V,3.3V or off On board USB-B Connector Receptor Connector J3 can direct insert into Pine A64 Exp-Bus to provide console access to Pine A64 board I/O pin are protected with ESD protector IC. On board 5x2pin connector can direct insert into Pine A64 Exp Bus for UART0 Console access Can use for programming and debugging for Wifi Remote I/O board Related Specification and Document CP2102 Datasheet\nVirtual COM Port Driver\nUSBXpress Driver\nPOT: Veroboard (PMVRB01) Feature Sit on top of Pine A64 board All the header receptor will have extended length pin to allow other POT board to insert on top of it Allow easy access to all the I/O pin on the Pine A64 header On board 4pcs of LED with current limiting resistor all direct connect to I/O pin for status indicator On board 4pcs of Tact switch On board XH5 2.54mm pitch connector for UART0 allow easy connection to USB/UART adapter for console access POT Veroboard on Pine A64\nPOT Veroboard 2 board stack on top of Pine A64\nPOT: Multi I2C Bus (PMI2C01) Feature Sit on top of Pine A64 board All the header receptor will have extended length pin to allow other POT board to insert on top of it Allow easy access to all the I/O pin on the Pine A64 header 2 channel of I2C bus is wire out for easy access I2C bus repeater IC (PCA9517A) are included in each I2C bus to allow connection of more devices on each bus Support 3.3V and 5V I2C bus for each channel separately On Board separated 3.3V supply regulator for 3.3V I2C Bus Each I2C bus pin are protected with ESD protector devices Each channel consist of 4 pcs of XH 4 pin 2.54mm pitch connector and 2 pcs of XH 5 pin 2.54mm pitch connector For the XH 4 pin connector, will consist of GND,SCL,SDA,5V pin For the XH 5 pin connector, will consist of GND,nINT,SCL,SDA,5V pin 5V supplier is direct connect from Pine A64 adapter’s supply thus prevent over loading Pine A64 board The nINT pin will allow peripheral with interrupt pin link back to the Pine A64 I/O pin Related Specification and Document NXP PCA9517A Datasheet\nNXP AN10658 Sending I2C-bus signal via long communication cables\nNXP AN11075 Driving I2C-bus signals over twisted pair cables with PCA9605\nProgram to Enable I2c Port internal pull with full source code\nMulti I2c Bus Schematic\nPOT: Shield Adapter (PMARD01) Adapter for Arduino Shield Separate on board LM1117 3.3V LDO for the Shield Base on Maxim MAX11609 on ADC input. Allow up to 5V analog signal Extra 5V input DC jack socket (suitable for 4.0mm X 1.7mm DC Jack) for extra input power Related Specification and Document https:/ / MAX11609 10bit I2C ADC\nI2C Device: Humidity and Temperature Sensor (PMSDP01) Feature Based on Silicon Labs Si7021 I2C Humidity and Temperature Sensor High Accuracy Temperature Sensor ±0.4 °C (max), –10 to 85 °C 0 to 100% RH operating range Up to –40 to +125 °C operating range On board 3.3V regulator 2pcs of XH 4pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor Related Specification and Document Si7021-A20 Datasheet\nI2C Device: Ambient Light Sensor (PMSAL01) Feature Based on TAOS/AMS TSL2561T I2C Light Sensor Approximates Human Eye Response Programmable Interrupt Function allow user defined upper/lower limit trigger threshold Automatically rejects 50/60Hz lighting ripple Build with 2 channel of photodiode/ADC to allow more accurate calculation of light intensity (in Lux) Can support up to 3pcs of sensor in the same I2C channel On board 3.3V regulator 2pcs of XH 5pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor Related Specification and Document TSL2561T Datasheet\nWiFi Remote I2C (PMWF01A) Feature Based on ESP8266 Wifi chipset Connect to Wifi AP On board chip antenna or U-FL connector for external antenna On board relay contact (TE PCJ-105D3M with 3A 275Vac Contact) with screw type terminal contact to support AC Line On/Off On board 1pc Tact-switch XH 5 2.54mm pitch connector connecting I2C device XH 6 2.54mm pitch connector for GPIO/SPI/PWM output XH 2 2.54mm pitch connector for system power 5V input or output DC Jack socket (suitable for 4.0mm X 1.7mm DC Jack) for system power input UART Port connector ready for on chip programming using USB/UART Programming/Console Adapter (PMPROG01) 2pcs of XH 5pin 2.54 mm pitch connector to allow daisy chain of multiple I2C sensor Further Detail info on the module can be found at WiFi Remote I2c Quick Start Guide wiki page\nRelated Specification and Document TE PCJ-105D3M Relay Datasheet\nESP8266 Datasheet\nESP8266 forum\nInter Connection Wire ","permalink":"/documentation/Accessories/POT/","tags":null,"title":"POT"},{"categories":null,"contents":"If you get the following error in U-Boot (or your 8 GB board is only detected as 4 GB) the possible cause is an empty or corrupted EEPROM:\nNot a StarFive EEPROM data format - magic error EEPROM dump: (0x100 bytes) 00: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF To address this, execute the following commands from within U-Boot:\nmac initialize mac product_id \u0026lt;PRODUCTID\u0026gt; mac write_eeprom Set ProductID to either:\nFor 8 GB Models: STAR64V1-2310-D008E000-01234567 for 4 GB Models: STAR64V1-2310-D004E000-01234567 You can replace the last 8 digits with a random number if you wish.\nIf these commands fail, please join the #star64 channel in the Pine64 community for more assistance.\n","permalink":"/documentation/STAR64/Development/Potential_issues/","tags":null,"title":"Potential issues"},{"categories":null,"contents":"The Pinebook Pro external power and charging circuity is quite rudimentary, and hence quirky. This article aims to explain all the fine points so that the behavior could be understood and dealt with.\nMonitoring and control Overview No control of charging is possible other than by physically plugging and unplugging a charger.\nSoftware monitoring is also quite limited, one can check whether a charger is connected (in /sys/class/power_supply/dc-charger/online and /sys/class/power_supply/tcpm-source-psy-4-0022/online) and see the current battery voltage (in /sys/class/power_supply/cw2015-battery/voltage_now).\nThe CW2015 battery monitoring IC only measures the voltage and tries to estimate the State Of Charge and Remaining Run Time. The last value (along with the \u0026lsquo;\u0026rsquo;nominal\u0026rsquo;\u0026rsquo; battery capacity) is also used by the kernel driver to \u0026lsquo;\u0026lsquo;compute\u0026rsquo;\u0026rsquo; the current. The estimations might be relatively accurate under certain conditions but you can not really know if they’re met with your laptop load at any given moment, so the only value provided that can be trusted is the voltage.\nCharging indicator LED There is a red LED near the barrel socket that’s connected directly to the BQ24171 battery charging IC.\nIt can indicate one of the three states:\nLED \u0026lsquo;\u0026lsquo;on\u0026rsquo;\u0026rsquo; means the charger is supplying current to the battery and the system; LED \u0026lsquo;\u0026lsquo;off\u0026rsquo;\u0026rsquo; means the charger is turned off, and the whole system is powered from the battery; LED \u0026lsquo;\u0026lsquo;blinking with 0.5 Hz frequency\u0026rsquo;\u0026rsquo; signals some hardware error: typically battery over-temperature protection or input under-voltage (from a failed charger); in this case the charger is also off, and the system is powered from the battery all the time. All other kinds of blinking really indicate the charger getting turned on and off, this happens when BQ24171 detects \u0026lsquo;\u0026lsquo;battery full\u0026rsquo;\u0026rsquo; condition, disables the charger, the system starts drawing current from the battery, the voltage quickly drops, and the charger is enabled again to compensate for the discharge. The blinking frequency would depend on the current system load, battery temperature, and the backlight level (as the backlight power source adds up to ~70 mV ripple to the voltage monitoring net). This \u0026ldquo;trickle-charging\u0026rdquo; is harmful for lithium batteries, but no workaround is possible other than fully disconnecting the external power source, and it’s not clear whether that would do more good than harm.\nAnother observed behavior is that the status LED blinks randomly, from time to time and unrelated to the system load, especially when the screen brightness is cranked to the maximum, and the battery isn’t fully charged. This has been attributed to some strange feedback that the BQ24171 receives and becomes confused, but further analysis is required.\nMonitoring currents The charging IC uses two measurement shunt resistors: \u0026lsquo;\u0026lsquo;R37\u0026rsquo;\u0026rsquo; for input current, and \u0026lsquo;\u0026lsquo;R43\u0026rsquo;\u0026rsquo; for battery current, both 0.010 Ohm. They’re easily accessible for external equipment after removing the RF shield on the mainboard, and one can use a battery-powered voltmeter or a differential probe to properly measure the real current at any given moment. Do \u0026lsquo;\u0026rsquo;not\u0026rsquo;\u0026rsquo; connect non-isolated oscilloscope ground clip to them, that might damage the equipment.\nWith the external chargers disconnected the system is powered by the battery, so measuring voltage on \u0026lsquo;\u0026lsquo;R43\u0026rsquo;\u0026rsquo; (along with the battery voltage at about the same moment) can be used to learn the system power consumption under different software loads.\nCharging Overview Pinebook Pro simplified charging schematics\nWhen an external charger is connected, the battery charging process is automatically activated, it doesn’t depend on any software interactions and works all the same even with the main SoC powered down. The system automatically chooses between the barrel socket (limiting current draw to 3 A) and Type-C source (limited to 2.5 A), with the former preferred when both are connected at the same time (but the current limit is enforced as if Type-C was used).\nThe maximum charging current under normal conditions is limited to 2.75 A and the voltage to 4.35 V. Battery temperature affects these values, and if the measuring is done properly (see the section Battery temperature fix) the charge is fully suspended under 0 °C or above 60 °C, maximum current halved below 10 °C, maximum voltage reduced to 4.24 V above 45 °C and to 4.19 V above 50 °C.\nThe charging process automatically terminates when the voltage reaches the recharge threshold (upper limit - 0.1 V) \u0026lsquo;\u0026lsquo;and\u0026rsquo;\u0026rsquo; the current falls below 275 mA. However, this also stops supplying external power to the system, so if it’s running the battery voltage almost immediately drops below the recharge threshold, and the charging is turned on again.\nExample run and charge time calculations Assuming a fully charged 9600 mAh battery and an idle system using \u0026lsquo;\u0026lsquo;performance\u0026rsquo;\u0026rsquo; cpufreq governor with backlight at 3700/4095 consuming 9.6 W we can expect\n9.6 Ah * 3.8 V / 9.6 W = 3.8 h so that gives 3.8 hours of run time.\nIf the same battery is empty and a barrel plug charger is connected while system has the same load it will need\n9.6 Ah * 3.8 V / ((3 A * 5 V * 0.9 - 9.6 W) * 0.95) = 9.85 h that is 9.85 hours of charging from zero to full, assuming 0.9 DC-DC conversion efficacy and 0.95 charging efficacy.\nRemoving the system load reduces the time to\n9.6 Ah * 3.8 V / (2.75 A * 3.8 V * 0.95) = 3.67 h so if you need to fully charge the battery, e.g. before a trip, the fastest and most reliable way is to power down (not suspend) the system, leave the device with the charger connected for a few hours, upside down for better cooling, and wait for the red LED on the side to turn off.\nWorking without battery With the battery disconnected the charger isn’t going to turn on, and the system won’t be getting any power from the external source. That’s why PBP has additional bypass cable that allows connecting external power directly to the system power bus. Of course it should be kept disconnected when the battery is present to avoid excess voltage overcharging and destroying the battery. It’s also recommended to add additional insulation to the cable connectors, as they expose battery and charger positive terminals on bare metal, and should never be accidentally connected to ground.\nHardware modifications Type-C current limit Warning The 0.5 A difference described in this section is there to carve out some power for a USB-C dock connected to the Pinebook Pro’s USB-C port. This is actually against the USB Power Delivery specification, but it leaves some power to the USB-C dock, which it requires to power itself and any devices connected to it. Thus, the procedure described in this section will most probably make using USB-C docks unreliable or even impossible, leaving the USB-C port usable for connecting only USB-C chargers or bus-powered USB-C devices. Since there’s no software control over the input current limit unmodified PBP always tries to draw up to 2.5 A from a Type-C charger.\nIt’s recommended to manually check /sys/class/power_supply/tcpm-source-psy-4-0022/current_max for all the chargers you’re using. When the value is lower than 2.5 A you shouldn’t use that charger with PBP as it would get overloaded, running out of specs.\nIf all of the chargers you want to use can supply 3 A or more \u0026lsquo;\u0026lsquo;at 5 V\u0026rsquo;\u0026rsquo; (the sysfs file will still report 2.5 A so check the official charger specs and/or label) consider lifting the limit to make it even with the barrel plug charger. For that remove the \u0026lsquo;\u0026lsquo;R148\u0026rsquo;\u0026rsquo; resistor on the bottom layer of the mainboard.\nThe easiest way is to use a soldering iron tip big enough to hold a 1 mm drop of an SnPb solder (it mixes with Pb-free nicely and lowers the melting point) to heat both sides of the resistor at once and lift it off.\nBattery temperature fix Warning The procedure described in this section alters the operating parameters of the lithium battery built into the Pinebokk Pro, which may be unsafe, and in extreme conditions may even introduce a fire hazard. Use the described procedure at your own risk. Additional verfication of the described procedure is currently pending. To ensure safe operation the charger IC is constantly monitoring the battery temperature with the sensor integrated inside the pack. The thermistor used is a 103AT NTC but the corresponding circuity on PBP mainboard was calculated for some other type. This results in the charger IC detecting 45 °C when the battery is in fact at just 35 °C, and 60 °C when the battery is at 46 °C. It’s easy to hit this threshold with heavy CPU or GPU loads as the metal back cover heats up from the SoC and slightly warms up the battery. Under these conditions the charging is suspended (with charging LED signalling a hardware issue), and the intensive tasks are continued on battery power alone, heating it up even more.\nTo fix this issue the resistor divider needs to be replaced to match the datasheet recommended values. For that one needs to change two 0402 resistors on the bottom side of the mainboard: use 2.2 kOhm 1 % for \u0026lsquo;\u0026lsquo;R52\u0026rsquo;\u0026rsquo; (instead of 4.4 kOhm installed by the factory), note it’s the one closer to the board edge; and 6.8 kOhm 1 % for \u0026lsquo;\u0026lsquo;R54\u0026rsquo;\u0026rsquo; (30 kOhm from the factory).\nIf your local hackspace doesn’t have suitable resistors consider getting a sample book from e.g. Aliexpress, it should cost less than 15 USD including shipping.\n","permalink":"/documentation/Pinebook_Pro/Power_and_charging/","tags":null,"title":"Power and charging"},{"categories":null,"contents":"The data on this page is based on the the PinePhone v1.1 - Braveheart.\nRegulators Current Assignments Name/GPIO Output Voltage Can disable at runtime? Can disable in suspend? Consumers (internal/external separated by semicolon) DCDC1 3.3V No No (VCC-IO) VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN DCDC2 DVFS No Yes VDD-CPUX DCDC3 DVFS N/A N/A VDD-CPUX (polyphase with DCDC2) DCDC4 N/A Yes Yes Not used DCDC5 1.2V No Yes (future) VCC-DRAM; DRAM DCDC6 1.1V No Yes (future) VDD-SYS DC1SW N/A Yes Yes Not used ALDO1 2.8V Yes Yes VCC-PE; Camera AFVCC, Camera DOVDD, CSI I2C, Pogo I2C ALDO2 1.8V No No (VCC-PL) VCC-PL; Pogo INT ALDO3 3.0V No No (KEYADC) AVCC, KEYADC, VCC-PLL DLDO1 3.3V No No (ANX7688 AVDD33) HVCC, VCC-DSI; ANX7688 [AVDD33, HDMI_VT, I2C, ANX-V1.0 Enable, VCONN_EN Disable Pull-up], HDMI [DDC, HPD], Proximity LED, Sensor I2C, Sensor VDD DLDO2 1.8V? 3.3V? Yes Yes MIPI-DSI VIO DLDO3 2.8V Yes Yes Camera AVDD DLDO4 1.8V-3.3V Yes Yes VCC-PG; VQMMC1 ELDO1 1.8V No No (DRAM) CPVDD; DRAM ELDO2 N/A Yes Yes Not used ELDO3 1.8V Yes Yes Camera DVDD FLDO1 1.2V Yes Yes HSIC-VCC (not used) FLDO2 1.1V No No (VDD-CPUS) VDD-CPUS GPIO0-LDO 3.3V Yes Yes Backlight PWM, LCD, Proximity sensor VDD, Touchscreen [I2C, VCC] GPIO1-LDO 1.8V No No (ANX7688 DVDD1V8) ANX7688 [AVDD1V8, DVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up] PD6 5.0V Yes Yes USB OTG PD8 5.0V Yes Yes Pogo supply, USB OTG via PD6 PD9 5.0V Yes Yes VCONN (USB Type C) PH10 PWM Yes Yes Backlight PL7 VBAT Yes Yes Modem ANX-V1.0 1.0V Yes Yes ANX7688 [AVDD1V0, DVDD1V0] Suggested Regulator Hardware Changes ANX7688 Move ANX7688 AVDD33 (the chip input only, not the other things connected to 3v3) and ANX7688 I2C Level Shift (3.3V side) from DLD01 to DCDC1, and ANX7688 VCONN_EN Disable Pull-up (R1355 and R1366) from DLDO1 to ANX1.8V Move ANX7688 ANX1.8V from GPIO1-LDO to ALDO2 Move ANX7688 ANX-V1.0 Regulator Enable (R1352) from DLDO1 to a GPIO These are all medium priority.\nThe result of these changes would be that:\nThe always-on part of the ANX7688 chip (AVDD33, DVDD1V8) will always be powered GPIO1-LDO only needs to be powered when a USB cable is detected, and is enough to power the rest of the chip (except HDMI) DLDO1 only needs to be enabled if the display pipeline or sensors are active, even if a USB cable is plugged in Assignments after Suggested Changes Note: Only regulators that were modified are included here.\nName/GPIO Output Voltage Can disable at runtime? Can disable in suspend? Consumers (internal/external separated by semicolon) DCDC1 3.3V No No (VCC-IO) VCC-EFUSE, VCC-IO, VCC-PC (VQMMC2), VCC-PD, VCC-USB; ANX7688 [AVDD33, I2C], Modem [I2C, PCM, UART], Motor, Pogo I2C, UART0, VMMC0, VMMC2, WiFi CHIP_EN ALDO2 1.8V No No (VCC-PL) VCC-PL; ANX7688 [DVDD1V8], Pogo INT DLDO1 3.3V Yes Yes HVCC, VCC-DSI; ANX7688 [HDMI_VT], HDMI [DDC, HPD], Proximity sensor VDD, Sensor I2C, Sensor VDD GPIO0-LDO 3.3V Yes Yes Backlight PWM, LCD, Proximity LED, Touchscreen [I2C, VCC] GPIO1-LDO 1.8V Yes Yes ANX7688 [ANX-V1.0 Enable, AVDD1V8, CC, HDMI DDC, I2C, Power/Reset pull-up, VCONN_EN Disable Pull-up] Open Questions How is ANX1.8V actually powered? from GPIO1-LDO (R1309) or PS (U1301) or both? Is DLDO2 supposed to be 1.8V or 3.3V? The schematic says both in different places. From LCD and LCD controller datasheets, this should be 1.8V. If DLDO2 is 3.3V, can we spread the HDMI/DSI/Sensors better across DLDO1 and DLDO2 so they can be more independent? Looks like this is N/A, because DLDO2 should be 1.8V. GPIO Current Modem Pin Assignments Note: only pins relevant to power management are included in this table.\nPin Signal Name Description Direction (as modem) Needed in suspend? Connected to 1 WAKEUP_IN Drive low to wake up the modem I No PH7 (active high) 2 AP_READY Drive high/low to signal the A64 is ready to receive URCs I No (if held) NC 4 W_DISABLE# Drive low to enter Airplane Mode I No (if held/tristate) PH8 (active high) 20 RESET_N Drive low to reset the modem I No (if held/tristate) PC4 (active high) 21 PWRKEY Drive low to turn the modem on/off I No (if held/tristate) PB3 (active high) 61 STATUS Open drain output, pulled low when the modem is on O No PB3 62 RI Pulled low to request host wakeup O Yes PB2 66 DTR Drive low to wake up the modem I No PL6 (active low) Current Port L Pin Assignments Pin Signal Name Description Direction Needed in suspend? PL0 PMU-SCK AXP803 I2C/RSB Clock O Yes PL1 PMU-SDA AXP803 I2C/RSB Data I/O Yes PL2 WL-REG-ON Not Connected N/A N/A PL3 WL-WAKE-AP Wake-on-WLAN Interrupt I Yes PL4 BT-RST-N Bluetooth Reset Control O No (if held) PL5 BT-WAKE-AP Wake-on-BT Interrupt I Yes PL6 DTR Modem DTR (Wakeup Request) O No PL7 4G-PWR-BAT Modem Power Supply Control O No (if held) PL8 ANX7688-CABLE_DET ANX7688 Cable Detection Interrupt I Yes PL9 ANX_RESET ANX7688 Reset Control O No (if held) PL10 LCD-PWM LCD Backlight PWM Brightness Control O No PL11 ANX7688-INT ANX7688 Alert Interrupt I Yes PL12 POGO-INT Pogo Pin Interrupt I Yes Pins Held During Suspend Pins Active During Suspend Suggested GPIO Hardware Changes Connect WL-REG-ON (PL2) to WL-PMU-EN (WiFi). bugfix Connect the LIS3MDL DRDY pin, not INT pin, to PB1. bugfix Reconnect LINEOUTN to make the line output differential. Connect PH7 to AP_READY instead of WAKEUP_IN. Since the A64 needs to drive this pin high (no pull-up on the modem side), this uses the level shifter channel previously used by RI (U1503 channel 4). Swap DTR (was at PL6, now at PB2 with U1503 channel 3 level shift) and RI (was at PB2, now at PL6 with no level shift, but a pull-up to ALDO2 on the A64 side*). partly a bugfix Connect the modem PWRKEY to PB3 only, not STATUS or DCDC1 (depopulate R1526). bugfix Connect the modem STATUS to PH9. This is an open-drain signal, so it needs a pull-up on the A64 side. bugfix Disconnect the modem I2C. The level shifter can be repurposed for the next change (modem debug UART). Connect the modem debug UART TX/RX to PD0-1. Move the modem main UART TX/RX to PD2-3. Motor and CSI reset that are currently at PD2-3 would need to be moved elsewhere. Connect both AXP803 USB-DRVVBUS (populate R1300) and ANX7688 VBUS_CTRL to DRVVBUS (in addition to PD6). Connecting to ANX7688 VBUS_CTRL would need a level shift to 1.8V. Alternatively, swap PL9 and PD6, so the level shift is not necessary, since PL9 is already a 1.8V logic level. Alternatively, do not connect ANX7688 VBUS_CTRL*, and at least populate R1300 to connect AXP803 USB-DRVVBUS*. Reorient the transistors for ANX_POWER (PD10) and ANX_RESET (PL9) so they do not invert their input, and (more importantly) produce a low-level output by default. (Since PL9 is already at 1.8V, it may no longer need a transistor.) Remove the transistors inverting VCONN1_EN and VCONN2_EN*, and use a pull-up to DVDD1V8* (that is really already present) instead of the pull-up to 3V3. Note: Changes 1-7 and 11 are high priority. Changes 12-13 are medium priority. Changes 8-10 are low priority.\n* There should be at least one pin where the default value at boot changes, due to being pulled differently, for use in distinguishing the hardware revisions. In v1.1, PL6 reads 0 at boot. Since RI is an active-low interrupt, it needs a pull up. And it doesn’t need any level translation. So that’s our perfect opportunity. If PL6 reads low at boot, it’s a v1.1 device; if PL6 reads high at boot, it’s a v1.2 device.\nOpen Questions What exactly is the modem PWRKEY currently connected to? PB3? STATUS? DCDC1? Currently STATUS pin is connected to PWRKEY and to PB3. STATUS can’t be read reliably since voltage divider from R1526 and R1517 places the STATUS signal at 0V or 0.5Vcc-IO, which is unspecified input value according to A64 datasheet (Vih is 0.7Vcc-IO, Vil is 0.3*Vcc-IO, the range in between is unspecified). ","permalink":"/documentation/PinePhone/Software_tricks/Power_management/","tags":null,"title":"Power Management"},{"categories":null,"contents":"This article is about compatible power supplies for the Pinecil.\nPower Options for Pinecil Overview Using a power supply that is at the higher end of the Voltage/Amps requirements will give faster heating and performance. Any USB-C power supply that supports PD (Power Delivery) and has at least the minimum Volt/amps listed should work. The USB-C PD65W, 3.25A, 20V is recommended, but a lower PD45W will also work on V1. Also, any quality \u0026ldquo;center positive\u0026rdquo; DC barrel 12-21V battery or power supply using a DC 5525 jack (5.5mm outer diameter, 2.5mm post) see the video on center-positive polarity. It is sometimes better to get a pre-used name brand laptop brick Dell/Lenovo/HP etc., over a cheap brick which could have voltage spikes that damage the Pinecil or other electronics. V2 can handle a DC barrel supply up to 24V without modifying the PCB (always check polarity, must be a center-positive jack). Any typical tool battery 18V-21V will work, see the tool battery section for details. QC3.0 phone chargers: not recommended, it is weaker in power and does not auto-negotiate like USB-C PD does. QC3 requires manually setting the voltage in the Power settings. A minimum of 3 amps is needed and many QC phone chargers are only able to provide a low 12V 1.5amp, limiting Pinecil to about 17W of thermal capability which is weak and slow. It may not even start to heat, but if it does, it may get repeated Thermal Runaway message (this means the weak power causes Pinecil to auto-shutdown continuously). QC is more problematic for V2 which comes with the Pine64 designed shorter 6.2 ohm resistance tip. This means the V2 needs more power than the V1. Switching to the longer tys100 style tip in V2 would reduce the power requirement a little, but then you lose a small amount of heat speed/performance. Magnetic tip USB-C cables are not recommended, and are not USB compliant. Troubleshooting QC chargers older QC2.0 chargers are not supported in IronOS firmware (only QC3.0 and PD type). Some QC power adapters only allow a limited time for QC negotiation, otherwise voltage will fall back to 5V. To address this, starting from firmware v2.16+, there is a PD timeout setting (in 100ms steps) which allows QC negotiation to start earlier. Change this only if you are having issues with your QC charger (lower the PD timeout to see if that will help QC charger work). (Power Settings \u0026gt; PD timeout) This enables some QC adapters to work (i.e., some Baseus QC chargers). Alternately, lowering the number may result in problems with PD negotiation on some PD type adapters that are slower to negotiate. If you switch between QC \u0026amp; PD adapters, you may have to change this setting. For certain QC adapters, lowering the PD timeout value to 15 could help, and most PD adapters will also still work using 15. If a PD charger does not work at 15, then increase the timeout (PD default is 20 = 20x 100ms = 2 seconds). Note that some QC chargers simply will not work, are too weak, or cheaply made (PD USB-C chargers are recommended over QC only type) How to Test if my charger will work? As long as you do the following you should be fine:\nDon’t plug in something that is higher voltage than the official ratings for V1 (21v limit) or V2 (24V limit). If using a DC barrel charger, check the Polarity first, it must be center positive (see Video) Use a known good quality cable that will not short. There are low cost $3 cable testers that test for shorts. If the Pinecil heats up very slowly or gets Thermal Runaway message, then the charger is too weak, get something else. Phone chargers are too weak, most are only 12V 1.5 amps which is too low and prevent proper Pinecil operation. QC 2.0 not supported by IronOS firmware (only QC 3.0 and PD type). most PC \u0026amp; laptop ports don’t work as they are only 5V which is good enough for simple Firmware updates but not to provide the constant higher power a \u0026ldquo;resistance\u0026rdquo; type of soldering Iron needs to maintain heat. Check the specs on your laptop/PC ports and charger ports, most of the time when it doesn’t work, it’s because the rating is very low on it and not designed to power an Iron (check specified Watts, Volts, Amps on the port and see if they meet the minimum needed by Pinecil). Cables, Chargers, Batteries This is a very small list compared to all the possible chargers that work, and new chargers come on the market all the time.\nUSB-C Cables Silicone USB-C cables are recommended if possible, they are more flexible and heat resistance. They do not melt or smoke if touched briefly with an iron compared with most other cords.\nUSB-C Charger Should I get a GaN type Charger? Sure, if there are two PD65 20V chargers that are similar in price, and one is GaN, this is generally a good chioce. Older style chargers could become dangerously hot, whereas GaN can stay cooler, even in a smaller size. If the GaN charger senses a potentially dangerous condition, i.e., overcurrent spikes, the chips are designed to go into a cycle-by-cycle sleep state, protecting the device. Over current protection in GAN. The PinePower Portable PD65 is GAN II (2nd generation GaN). Will Pinecil work with regular USB-C PD 65w 20V-3.25A chargers also? Yes, as long as it supports PD (power delivery protocol). EPR PD3.1, 140W Chargers Voltme 140W, 28V max Rocoren 140W, 28V max Apple 140W 28V Anker 737 Power Bank (only EPR battery on the market presently). Note a PD3.1 240W cable needs to be purchased if you want the full 28V performance. EPR PD3.1 chargers are backwards compatible and work for all USB-C devices. They do up to 28V on PD3.1 devices,e.g, Pinecil V2, and will do 20V and less for older USB-C devices that don’t need as much power. Lower cables will also work but then the charger will only deliver a max of 20V. PD3.0 65w 20V Chargers PD120w PinePower Desktop w/Grounded 3-pin plug PD65w GAN II Pinepower Portable Travel charger (PD@20V) Cirtek 65W charger 3-port Etre Jeune 65W 3-port charger EfaithFix PD65W, 3-port TREBLEET Ultra-thin Portable PD65w small flat, full 20V PD65W charger, works well with Pinecil it may not as durable as bigger chargers as it has no thick insulation around it. HTC PD65W, 3-port black HTC PD65W, 3-port, white Amazon Basics 65W One-Port GaN USB-C PD 3.0 Battery Power bank Anker 737 28V-140W EPR (must use EPR-PD 3.1 240W cable if you want the full 28V, otherwise it will provide a lower PD20V) Blitzwolf BW-P1 10400mAh QC2 Insignia 80W 26,800mAh NS-PWLB80 Intenso 7332330 Powerbank PD 10000 - External Battery PowerDelivery \u0026amp; QuickCharge3 - 10000mAh Powerbank, the Pinecil shows 12V and about 17W when heating up, using USB C PD (Red Silicone Pinecil cable) Marbero M87 30W PD 3.0 Charmast C2032 65W Power Bank, maximum power at 20V is only available from the IN/OUT USB-C port, the OUT USB-C port delivers only 12V. Baseus BiPow 10000mAh 18W PD\u0026amp;QC3.0 INIU Power Bank 65 W 25000 mAh - Make sure to use the 65W port DC Barrel Power Important Check the polarity of the DC Barrel plug before plugging in a random charger or it could break the Pinecil. DC Laptop Brick Generally a center-positive laptop charger with more than 3 Amps and 19V-24V will work on Pinecil V2 (video to check polarity). Plugging in a DC barrel charger with the wrong polarity symbol on the back will break the Pinecil. Avoid Universal power supplies and cheap off-brand ones with low quality control. \u0026lt;tl_lim\u0026gt; said \u0026ldquo;try to avoid such universal power. The output contains sharp voltage spike and can kill the Pinecil. There are already several cases reported by support team that Pinecils are damaged by such power supply.\u0026rdquo; Read the 2 answers in this link that give an idea of why using cheap DC power supplies could damage electronics due to switching noise/voltage spikes. Cheap DC bricks don’t have all the extra protections needed, go through little quality control, and most have no certification stamps related to industry testing. DC5525 barrel plug will plug in directly (5.5mmm x 2.5mm) but if you have a different plug, there are many adapters to convert it to 5.5mm, 2.5mm (don’t force a different plug into Pinecil, it will Break the barrel port), and possibly push back and break the positive pin connection inside Pinecil where the DC barrel attaches to the PCB. DC barrel 24V is supported on V2 (most V1 can only do a max of 21V unless a modification is performed to cut the trace to the Vbus and enable 24V safely (see Ralim’s IronOS DebugMenu for details)) It is recommended to use a quality brand DC barrel charger. Often a used name-brand laptop charger (Dell, HP, Toshiba, etc..) that gets some QC testing is a better option than a no-name cheap DC barrel charger. The cheap ones might have large voltage spikes that are out of the 21V range for Pinecil V1 and 24V range of Pinecil V2 causing the Mosfet and Buck regulator to break. These two parts are low cost and not too hard to replace if your Pinecil breaks from a poor quality DC charger (see the datasheets section for links to get replacement chips). Members have experienced broken Pinecils after using low quality off-brand DC barrel chargers and had to replace both the Mosfet and Buck Converter. Sometimes it’s just one part, but it’s best to order a couple of both as they are usually under $0.35 each. Tool Batteries 18V-21V Power-Wheels adapter link with Ryobi battery\nEasy way: just get a Power Wheels adapter. They are made for different tool brands and get a DC5525 Pigtail wire. DC5525 pigtail (keep the XT60 connector or cut it off) Some people print their own 3D adapters for tool batteries. Must use a 5.5mm x 2.5 mm DC barrel Plug. Forcing an an incorrect size, i.e., DC 5521 will break the connector as seen here (if it doesn’t go in, it doesn’t fit). If you use a random DC barrel charger, first Check the Polarity of the plug to make sure it is Center Positive before using it. (how to check polarity). Using reverse polarity DC plug will destroy the Pinecil. Get a Power Wheels Adapter like this for Ryobi, then splice/connect it to a DC5525 Pigtail to complete connection to Pinecil. Other kinds of Power-Wheels Adapters here (Ridgid, Milwaukee, Makita, etc). Adapter for Ridgid batteries To prevent battery overdrain, add this Pinecil setting which works for all the 18-21V tool batteries typical for Dewalt, etc.. Some tool brands have the overdrain protection already; it doesn’t hurt to also set this in Pinecil or in case you don’t know if your brand/type has it or not. Power source = 5S, Minimum Voltage = 3.3V Hint: only if you change to a different size battery do you need to alter this. If you only ever switch between a USB-C charger and the tool battery, you could just leave the 5S/3.3V setting. Overdrain means using the battery past the point where you can charge it again. Many tool batteries have internal protection to prevents this, but some brands don’t have it (unfortunately, unlike most brands, Dewalt puts it into the tool \u0026amp; not the battery). Setting it in Pinecil is an extra safety setting in case you are not sure and want to preserve batteries. Limited usability:\nNintendo Switch AC Adapter (USB-C wall-wart) (PD@15V). Does not work well on V2 (needs 3+amps). Works on V1, but slower heat speed because it’s low amps and only 15V. Notebook Docking Station HP Thunderbolt Dock 230W G2 (PD@20V) (had problems with lower firmware versions, but works fine Pinecil firmware: 2.15 and DockingStation firmware: 1.0.69.1) Smartphone Charger Samsung EP-TA20EWE (QC2@9V) Smartphone Charger Google Pixel G1000-US (PD@9V) Notebook AC Adapter Delta Electronics ADP-65JH BB (DC@19V) and ADP-90CD DB (1.7x 4.8mm need adapter, tip is not DC5525) Notebook AC Adapter LITEON PA-1700-02 (DC@18.5V, 65W) (tip is 1.7mmx5.5mm would need adapter for DC5525) Nillkin 63W USB Car Charger Quick Charge 3.0 PD (Pinecil Firmware: 2.14.2425902) QC3@9V/12V and PD@15V work, PD@20V doesn’t PD@20V works fine when using PDC004-20V or ZY12PDN on dc jack (DC@20V, limit: 45W) Not compatible Zendure Power bank like this one does not work. It does not appear to be USB-C PD 3.0 compliant. Only the USB-A port seems to work at lower QC voltage. It does not deliver USB-C 20V-5amps or USB-C 20V -3amps. Smartphone Charger RAVpower 30W Dual USB Turbo Wall Charger (Should provide QC3@9V/12V, but only provides 5 V on both ports) Sabrent HB-B7C3 USB3 hub, 7 data ports, 3 charge ports, 60W supply \u0026ndash; does not negotiate higher voltages. ","permalink":"/documentation/Pinecil/Power_supplies/Power_supplies/","tags":null,"title":"Power Supplies"},{"categories":null,"contents":" Input Power: 5V DC, 15W (current limit 3A) Mechanical: 3.5mm OD / 1.35mm ID, Barrel jack USB-C 5V, 12.5W (current limit is at 2.5A regardless of the USB PD negotiations result) Only use one power input at a time, barrel jack OR USB-C (note: some powerful Type-C adapters have rather limited current for 5 V operation, and e.g. 2 A won’t be enough to run the system and charge the battery at the same time, so check the specs) ","permalink":"/documentation/Pinebook_Pro/Features/Power_supply/","tags":null,"title":"Power supply"},{"categories":null,"contents":"Powering the ROCKPro64 single-board computer from an ATX power supply allows the board to be powered with more than just two disks, and is a reliable and safe way to power it from your household mains.\nWarning Please note that following these instructions comes at your own risk. While best efforts have been made to write reliable, safe instructions, the authors cannot be held liable for the quality of procured components or the assembly job of the person following the instructions, and the damages caused by either of these not being up to par. Shopping List Components An ATX breakout board. Get one with fuses. For extra safety, replace the fuses with your own trusted ones once you get it. Some 24 AWG or thicker copper wire, 0.5m of length at most, go thicker if you want to use longer wire. Also go thicker if you’re using copper-coated aluminium. A 2.1mm ID/5.5mm OD barrel jack connector Tools A soldering iron, e.g. the Pinecil, with some solder Some wirestrippers suitable for the thickness of wire you chose Assembly Slide the stress relief over both the wires you will use Solder the positive side of the wire to the centre contact of the barrel connector Solder the negative side of the wire to the outside contact of the barrel connector Fasten the stress relief/barrel connector housing Connect the positive side to your ATX breakout board’s 12V terminal Connect the negative side to your ATX breakout board’s GND terminal Plug in the ATX power supply into the ATX breakout board, with the PSU turned \u0026lsquo;off\u0026rsquo; at the flip switch in the back Set the power switch on the ATX breakout board to the on position Stand out of reach of any glass fuse shrapnel (e.g. put the breakout board in a housing), plug in the ATX power supply and flip its switch on If it didn’t blow up, you did it right, and can now hopefully plug the ROCKPro64 into the ATX breakout board using the cable you’ve made Further Steps If you got one of the green breakout boards with the glass fuses and the red LED, then User:CounterPillow made a 3d printable housing for it. It screws together with heat-set brass inserts. Download .zip containing STEPs and STLs as well as the FreeCAD project file\n","permalink":"/documentation/ROCKPro64/Hardware/Powering_from_an_ATX_supply/","tags":null,"title":"Powering From An ATX Supply"},{"categories":null,"contents":" The case, fully assembled with a ROCK64 inside of it\nThe ROCK64 Premium Aluminum Casing is an aluminum case for the ROCK64 single-board computer sold by Pine64 through their official store. It includes an integrated heat spreader with an included thermal pad that allows the SoC to sink its generated heat into the metal case.\nInstallation Make sure the LED light guide and rubber plug are taken out of the case. Drop your ROCK64 into the bottom half of the case with the ports in the correct place. Tighten it with the four included round top screws, using a Phillips #00 screw driver.\nInstall the light guide and the rubber plug by pushing them in from the outside.\nIdeally, clean the SoC of any possible residue with some isopropyl alcohol. Next, remove the plastic foil protecting the thermal pad on the top half of the case, and slot the top half into place, making sure that the HDMI and audio jack ports fall into their respective place in the side section (see HDMI and Audio Jack Clearance Issues if they don’t.)\nOnce the top half is firmly in place, screw in the four flat top screws with a Phillips #00 screw driver.\nPerformance The built in heat spreader does do its job at sinking heat into the case. User:CounterPillow finds that during a lengthy kernel compilation at 22°C ambient temperature, the average SoC temperature measured around 60°C. The case during such sustained loads becomes warm to the touch, which means it is working as a heat sink.\nTips and Tricks HDMI and Audio Jack Clearance Issues Some cases may not allow the ROCK64 IO to snugly fit into its predestined cutout holes on its long side. If this is the case for you, try loosening the screws on the HDMI, power and audio jack port side, and only tightening the screws on the GPIO side to still make good ground contact. The HDMI and audio jacks should then fit into their holes snugly. If you wish to try, you can also try adjusting the screws holding in the posts on the bottom of the case.\nPlastic Pegs for PWR and RST Buttons FreeCAD displaying the peg. Bottom part goes inside the case.\nIf you are tired of using a pen or a toothpick to push the buttons, there are 3d-printable plastic pegs you can download and print yourself. Recommended material is PLA, excellent results can be obtained using a 0.25mm nozzle, though slightly larger sizes should work fine as well.\nTo use the pegs, open your case and remove the ROCK64 from within. Be sure to pull out the light guide and rubber plug to remove it, or else it will catch on them. Once it is removed, turn your bottom half of the case such that the holes for PWR and RST are pointing towards the floor, and drop the pegs into the holes from inside the case, so that the lip prevents them from falling through. Hold them in position with your finger, turn the case the right side up again, and reinstall your ROCK64.\nPlastic Pegs in their place\nYou should now have buttons that can be pressed from outside the case without any utensils.\nIf you do not own a 3d printer, contact User:CounterPillow. He may mail you some for free in an envelope.\nRemove the black anodised layer from the heat pad Anodising has a significantly poorer thermal conductivity than aluminium, therefore grinding off the anodising before fitting the blue thermal pad should result in a lower CPU temperature.\nUsing the case with the PINE H64 Whilst the case is sold as a ROCK64 accessory, all the connectors and mounting screws on the PINE H64 are in the same spots. The only difficulty is that the H6 CPU is closer to the \u0026ldquo;Pi2\u0026rdquo; connector and extends beyond the edge of the heat spreader by about 5mm. User:AlephNull used a piece of copper shim on top of the H6 (with a smear of thermal paste) to spread the heat back to the thermal pad. In this configuration, the CPU stabilised at about 76°C running 4 copies of a CPU stress test. Whilst a lower temperature might be nice, this is still well below the 125°C limit.\n","permalink":"/documentation/ROCK64/Cases/Premium_aluminum_casing/","tags":null,"title":"Premium Aluminum Casing"},{"categories":null,"contents":"Vector images and pictures for the PineNote you can freely use for projects and press inquiries. Attribute the author if attribution is required via the license (such as CC BY and CC0).\nBackgrounds Background ideas:\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\n","permalink":"/documentation/PineNote/Further_information/Press/","tags":null,"title":"Press"},{"categories":null,"contents":"Vector images and pictures of the PinePhone and PinePhone Pro you can freely use for projects and press inquiries. Attribute the author if attribution is required via the license (such as CC BY).\nPinePhone Pro Author: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nPinePhone Beta Edition. Author: Funeral, License: CC0\nAuthor: Funeral, License: CC0\n3D model The 3D model can be used for a wide variety of purposes, for example for product renderings:\nhttps://www.thingiverse.com/thing:4520124 Example rendering:\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nNew template:\nAuthor: Funeral, License: CC0\nOld template:\nAuthor: Funeral, License: CC0\nLockscreen template For renderings you can use and modify this template:\nVersion with black background. Author: Funeral, License: CC0.\nVersion with no background. Author: Funeral, License: CC0.\nManual and Instructions Author: Jedi2light, License: CC BY 4.0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\nAuthor: Funeral, License: CC0\n","permalink":"/documentation/PinePhone/Further_information/Press/","tags":null,"title":"Press"},{"categories":null,"contents":"For an overview about media of the PinePhone Pro you can use for the news, blogs, or similar see Press.\n","permalink":"/documentation/PinePhone_Pro/Further_information/Press/","tags":null,"title":"Press"},{"categories":null,"contents":" Picture of the privacy switches\nThe PinePhone features six switches that can be used to configure its hardware. They are numbered 1-6, with switch 1 located nearest to the modem. Their \u0026ldquo;on\u0026rdquo; position is toward the top of the phone.\nWarning It is not recommended to change the PinePhone’s privacy switch positions while the device is powered on. In particular, toggling the modem privacy switch while the phone is running can lead to modem firmware corruption. Additionally, the phone is not notified of the loss of power to the disabled part, so it may continue to assume the component is operating normally; if you switch the dip switches back on during operation, it may not automatically regain functionality. Number Name Explanation Description 1 Modem Pulls Q1501 gate up (FET killing modem power) \u0026ldquo;On\u0026rdquo; enables 2G/3G/4G communication and GNSS hardware, \u0026ldquo;off\u0026rdquo; disables it. 2 WiFi / Bluetooth Pulls up CHIP_EN \u0026ldquo;On\u0026rdquo; enables WiFi and Bluetooth communication hardware, \u0026ldquo;off\u0026rdquo; disables it. 3 Microphone Breaks microphone bias voltage from the SoC \u0026ldquo;On\u0026rdquo; enables audio input from on-board microphones (not 3.5 mm jack), \u0026ldquo;off\u0026rdquo; disables it. 4 Rear camera Pulls up PWDN on OV5640 \u0026ldquo;On\u0026rdquo; enables the rear camera, \u0026ldquo;off\u0026rdquo; disables it. 5 Front camera Pulls up PWDN on GC2145 \u0026ldquo;On\u0026rdquo; enables the front camera, \u0026ldquo;off\u0026rdquo; disables it. 6 Headphone Pulls up IN2 on analog switch BCT4717ETB \u0026ldquo;On\u0026rdquo; enables audio input and output via the 3.5 mm audio jack, \u0026ldquo;off\u0026rdquo; switches the jack to hardware UART mode. ","permalink":"/documentation/PinePhone/Privacy_switches/","tags":null,"title":"Privacy switches"},{"categories":null,"contents":" Picture of the privacy switches\nThe PinePhone features six switches that can be used to configure its hardware. They are numbered 1-6, with switch 1 located nearest to the modem. Their \u0026ldquo;on\u0026rdquo; position is toward the top of the phone.\nWarning It is not recommended to change the PinePhone’s privacy switch positions while the device is powered on. In particular, toggling the modem privacy switch while the phone is running can lead to modem firmware corruption. Additionally, the phone is not notified of the loss of power to the disabled part, so it may continue to assume the component is operating normally; if you switch the dip switches back on during operation, it may not automatically regain functionality. Number Name Description 1 Modem \u0026ldquo;On\u0026rdquo; enables 2G/3G/4G communication and GNSS hardware, \u0026ldquo;off\u0026rdquo; disables it. 2 WiFi / Bluetooth \u0026ldquo;On\u0026rdquo; enables WiFi and Bluetooth communication hardware, \u0026ldquo;off\u0026rdquo; disables it. 3 Microphone \u0026ldquo;On\u0026rdquo; enables audio input from on-board microphones (not 3.5 mm jack), \u0026ldquo;off\u0026rdquo; disables it. 4 Rear camera \u0026ldquo;On\u0026rdquo; enables the rear camera, \u0026ldquo;off\u0026rdquo; disables it. 5 Front camera \u0026ldquo;On\u0026rdquo; enables the front camera, \u0026ldquo;off\u0026rdquo; disables it. 6 Headphone \u0026ldquo;On\u0026rdquo; enables audio input and output via the 3.5 mm audio jack, \u0026ldquo;off\u0026rdquo; switches the jack to hardware UART¹ mode. ¹ Note: The baud rate may be 1500000 instead of 115200.\n","permalink":"/documentation/PinePhone_Pro/Privacy_switches/","tags":null,"title":"Privacy switches"},{"categories":null,"contents":" The Project \u0026ldquo;Anakin\u0026rdquo; - Phase 1 of PINE64 Smartphone \u0026ldquo;PinePhone\u0026rdquo; Development Kit Project Anakin is a marsh-up kit for the PINE64 Smartphone dubbed \u0026ldquo;PinePhone\u0026rdquo;. It is used in the early stages of development as a starting point for affiliated projects.\nPinePhone development has been broken down into three distinct phases:\nFirst phase - Project Anakin Second phase - purpose-built development kit code named \u0026ldquo;Don’t be evil\u0026rdquo;. It will be introduced at FOSDEM 2019 Lastly, the third phase which is the PinePhone itself - scheduled to be released in Q3 2019 (pending on software development). The Anakin kit consists of following components:\nSoPine Module SoPine Model A baseboard Pine A64 Wifi/BT module 16GB eMMC module 5 Mega Piixel CMOS Camera Sensor 7\u0026quot; Touch Screen LCD Panel Playbox Enclosure Lithium Ion Battery case (note: battery not included, can accommodate 1-3 pieces of 18650 size Lithium Ion batter. In general, one is good enough) Quectel EC20 R2.1 LTE Module (note: The SIM tray design not distinguish polarity well and all reverse slot in) Accessories Step-by-Step Guides Under \u0026lsquo;Guides for PINE A64(+) accessories\u0026rsquo; you can find instructions and guides concerning:\nPlaybox Enclosure Bluetooth and WiFi module 7\u0026quot; Touch Screen LCD Panel SoC and Memory Specification Based on Allwinner A64/R18 R18 and A64 are identical SoC but R18 committed for 10 years supply by vendor. CPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard System Memory RAM Memory Variants: 2GB LPDDR3. Storage Memory: SPI Flash and optional eMMC module from 16GB up to 64GB Project Anakin, SOPine Module and Baseboard Information, Schematics, and Certifications Model \u0026ldquo;A\u0026rdquo; Baseoard Dimensions: 133mm x 80mm x 19mm Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, 3.5OD/1.35ID Barrel DC Jack connector, Euler connector PINE A64 Connector Layout @courtesy of norm24 PINE A64 Connector List SOPine Module Pin Assignment ver 1.0 PINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016) Good documentation about PINE A64, A64+, and A64-LTS GPIO pins article SOPine Module Schematic:\nSOPine Module Schematic SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic and PCB Board Resource:\nSOPine model \u0026ldquo;A\u0026rdquo; Baseboard is an hardware open source project but is not \u0026ldquo;OSH\u0026rdquo; compliant SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic capture Rev B DSN source file SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic Rev B PDF file SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Job source file SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Gerber file SOPine Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Layout PDF file SOPine (together with model \u0026ldquo;A\u0026rdquo; baseboard) Certification:\nSOPine with model \u0026ldquo;A\u0026rdquo; baseboard FCC Certificate SOPine with model \u0026ldquo;A\u0026rdquo; baseboard CE Certificate SOPine with model \u0026ldquo;A\u0026rdquo; baseboard RoHS Certificate Datasheets for Components and Peripherals Allwinner A64/R18 SoC information:\nR18 and A64 are identical SoC but R18 committed for 10 years supply by vendor. Allwinner A64 SoC Brief Introduction Allwinner R18 SoC Brief Introduction Allwinner A64/R18 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64/R18 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC Datasheet LPDDR3 information:\nAllwinner LPDDR3 Datasheet Foresee LPDDR3 Datasheet Samsung LPDDR3 Datasheet Hynix LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG SanDisk eMMC Datasheet Hynix eMMC Datasheet Foresee eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Project Anakin module/component related information 5MPixel Rear CMOS Camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) S5K4EC 5MP CMOS Image Sensor SoC Module Datasheet S5K4EC 5MP CMOS Image Sensor SoC Chip Datasheet S5K4EC 5MP CMOS Image Sensor Driver Source Code in C language LCD Touch Screen Panel information:\n7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64+ Board Realtek RTL8201 10/100M Ethernet Transceiver for PINE A64 Board Wifi/BT module information:\nRealtek RTL8723BS WiFi with BT SDIO Enclosure information:\nPlaybox Enclosure 3D file Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port right\nLTE module information:\nNote: The current Project Anakin kit deploy on using Quectel EC20_R2.1 which belongs to EC25 family. Actual production will use EC25 and EG25-G (still preliminary) module pending on region. Quectel EC20 R2.1 LTE Module Specification Quectel EC25 LTE Module Specification Quectel EG25-G LTE Module Specification Quectel EC25 LTE Module AT Cammands Set Manual Quectel EC25 LTE Module Hardware Design Guide Quectel EC25 LTE Module Reference Design Guide Other Resources Linux Sunxi Wiki page on PINE A64 Linux Image created by Andre Przywara PINE64 Linux build scripts, tools and instructions by Longsleep PINE64 Linux image by Longsleep Shrinking images on Linux by FrozenCow Quectel EC-25 LTE module open source information ","permalink":"/documentation/PinePhone/Revisions/Project_Anakin/","tags":null,"title":"Project Anakin"},{"categories":null,"contents":" The Project Don’t be evil is the phase two of PINE64’s smartphone, the PinePhone Development Kit. Project Don’t be evil is an actual smartphone developer kit for the PINE64 Smartphone dubbed \u0026ldquo;PinePhone\u0026rdquo;. It is used in the early stages of development as a starting point for affiliated projects.\nThe PinePhone development has been broken down into three distinct phases:\nFirst phase - Project Anakin Second phase - purpose-built development kit code named \u0026ldquo;Don’t be evil\u0026rdquo; and introduced at FOSDEM 2019 Lastly, the third phase which is the PinePhone itself - scheduled to be prototype released in Q3 2019 and BTO batch released with mobile OS parents in Q4 2019 (pending on software development). Baseboard and SOPine Module Information, and Schematics Baseboard Dimensions: 165mm x 76mm x 19.5mm Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, USB type-C connector Baseboard Schematic:\n\u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Structure \u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Ver 1.1 Schematic \u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Ver 1.1 PCB Artwork \u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Ver 1.2 Schematic \u0026ldquo;Don’t Be Evil\u0026rdquo; PinePhone Dev kit Baseboard Ver 1.2 PCB Artwork SOPine Module Schematic:\nSOPine Module Schematic SOPine Module Pin Assignment ver 1.0 Wifi/BT module information:\nPINE A64 Wifi/BT Module Schematic Pin assignment:\nPINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016) SoC and Memory Specification Based on the Allwinner A64/R18. The R18 and A64 are identical SoC but R18 committed for 10 years supply by vendor.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard System Memory RAM Memory Variants: 2GB LPDDR3. Storage Memory: SPI Flash and optional eMMC module from 16GB up to 64GB Datasheets for Components and Peripherals Allwinner A64/R18 SoC information:\nNote: the R18 and A64 are identical SoC but the R18 is committed for a 10 years supply by the vendor. Allwinner A64 SoC Brief Introduction Allwinner R18 SoC Brief Introduction Allwinner A64/R18 SoC Data Sheet V1.1 (Official Released Version) Allwinner A64/R18 SoC User Manual V1.0 (Official Release Version) X-Powers AXP803 PMU (Power Management Unit) information:\nAXP803 PMIC Datasheet LPDDR3 information:\nAllwinner LPDDR3 Datasheet Foresee LPDDR3 Datasheet Samsung LPDDR3 Datasheet Hynix LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG SanDisk eMMC Datasheet Hynix eMMC Datasheet Foresee eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Related datasheets 2MPixel front CMOS Camera module information:\n2MP CMOS Image Sensor Module Drawing GalaxyCore GC2035 2MP CMOS Image Sensor Product Brief GalaxyCore GC2035 2MP CMOS Image Sensor Datasheet 5MPixel Rear CMOS Camera module information:\n5MP CMOS Image Sensor Module Drawing OmniVision OV5640 5MP CMOS Image Sensor Datasheet OmniVision OV5640 5MP CMOS Image Sensor Software Application Note LCD Touch Screen Panel information:\n5.7\u0026quot; 1440x720 IPS LCD Panel Specification fiti JD9365D LCD Controller Datasheet 5.7\u0026quot; Front Panel Touch Screen Specification FocalTech FT6336GU Front Panel Touch Screen Specification Lithium Battery information:\nPanasonic NCR18650B 3350mAH Lithium Ion Battery Specification Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver Wifi/BT module information:\nRealtek RTL8723BS WiFi with BT SDIO LTE module information:\nQuectel EC25 LTE Module Specification Quectel EG25-G LTE Module Specification Quectel EC25 LTE Module AT Cammands Set Manual Quectel EC25 LTE Module Hardware Design Guide Quectel EC25 LTE Module Reference Design Guide Sensors:\nST LIS3MDL 3-axis Magnetomater Datasheet InvenSense MPU-6050 Six-Axis (Gyro + Accelerometer) MEMS Datasheet SensorTek STK3335 Ambient Light Sensor and Proximity Sensor Software releases A64 mainline status matrix chart Some these OS images labelled as beta or nightly builds which means they are only fit for testing purposes. These images should be used at your own risk and are not fit for normal use.\nArch Linux XFCE longsleep BSP Linux ayufan Linux postmarketOS Download:\nDirect download from postmarketOS image site Instructions:\npostmarketOS PinePhone \u0026ldquo;Don’t Be Evil\u0026rdquo; dev kit wiki site Notes:\npostmarketOS early alpha test build for microSD boot for 8GB microSD cards and above Suitable for PinePhone \u0026ldquo;Don’t Be Evil\u0026rdquo; Dev Kit version 1.1 and version 1.2 There are two type of LCD panels. For long touch screen cable, please use the build with inverted wording. Sailfish OS The Sailfish OS image is build on Gitlab CI, the latest image can be installed using our flashing script written in Bash.\nThe script downloads the image and bootloader from our CI, extracts everything and burns it onto the SD card.\nInstructions:\nDownload the flashing script Insert a microSD card in your device Make the script executable: chmod +x flash-it.sh Execute it: ./flash-it.sh Follow the instructions. Some commands in the script require root permissions (for example: mounting and flashing the SD card). Notes:\nThe script will format and flash the SD card, make sure that you don’t have any important data on the SD card! Maemo Leste Download:\nMaemo Leste test builds download Notes:\nWorks on dev kit versions 1.1 and 1.2 Write the image to a micro SD (8GB+) or eMMC LuneOS Download:\nLuneOS test image for PinePhone and thanks to Tofe Notes:\nIt is recommended to use bmaptool for example bmaptool copy https://build.webos-ports.org/luneos-testing/images/pinephone/luneos-dev-image-pinephone-testing-0-15.rootfs.wic.gz /dev/mmcblk0 Mali Driver For the Mali driver see Mali Driver.\nErrata for ver1.1 and ver1.2 board Please DON’T insert micro SIM card to dev kit board micro SIM card slot, the SIM data, VPP, and GND signal have been misplaced. A miciPCIe adapter with sim card holder 9shown as below photo) will be provide to developers to correct this mistake. The PinePhone dev kit doesn’t charge due to VBUS on SOPine module is not connected. Please connect R9688 solder pads with 0 ohm resistor or using thin wire bridge up the solder pads. Location shows as below: The SOPINE’s SPI NOR flash storage and the devkit’s camera flash (heh) share the same GPIO pins. The flash storage may not be used. On the camera flash GPIO conflict, the new assignment of GPIO PB3 pin for SGM3140 FLASH_EN and GPIP PD7 for FLASH_TRIGOUT. Please note that PD7 is also LCD_ID pin which may not be used. Images:\nGPIO_PB3_location\nFlash GPIOs Reassigned wiring\nOther Resources Linux Sunxi Wiki page on PINE A64 Linux Image created by Andre Przywara PINE64 Linux build scripts, tools and instructions by Longsleep PINE64 Linux image by Longsleep Shrinking images on Linux by FrozenCow Quectel EC-25 LTE module open source information ","permalink":"/documentation/PinePhone/Revisions/Project_Dont_be_evil/","tags":null,"title":"Project Don’t be evil"},{"categories":null,"contents":" Warning Possible safety hazard: If the wireless charging chip fails for some reason, do not plug the phone in to charge via USB-C. Take the back case off first. It is possible that power gets fed into the chip, causing it to overheat, possibly causing damage to the phone and creating a fire-hazard.\nAlbum of damage caused by reverse current: https://imgur.com/a/dJsp5wD\nUntil the cause of this is determined, it is recommended NOT to use the wireless charging add-on.\nUses the pogo pins to supply Qi Wireless and Wireless Power Consortium compatible charging. No software required.\nSchematics and Datasheet Schematic:\nPinePhone Wireless Charger Back Cover Schematic ver 1.0 20210508 Datasheet:\nHL6111RFNWP5 5W WPC Wireless Power Receiver Datasheet ","permalink":"/documentation/Phone_Accessories/Qi_wireless_charging/","tags":null,"title":"Qi Wireless Charging Add-on"},{"categories":null,"contents":" The Quartz64 is the most recent Single Board Computer offering from PINE64, with Model A initially released in June of 2021 and Model B in May of 2022. It is powered by a Rockchip RK3566 Quad-Core ARM Cortex A55 64-Bit Processor with a MALI G-52 GPU.\nThe Quartz64 Model B\nKey features include a PCIe x4 open-ended slot (model A) or M.2 slot (model B) using a single Gen2 lane electrically, and the use of LPDDR4 RAM.\nThe Quartz64 is available in two LPDDR4 system memory options: 4 GB and 8 GB. For booting, there is an eMMC module socket (supporting up to 128 GB) and microSD slot, as well as a footprint to solder on an SPI flash chip. The board is equipped with HDMI, 1x USB 3.0 Type-A host, 3x USB 2.0 host, Gigabit Ethernet, SATA (model A), GPIO Bus, MiPi DSI interface, e-ink interface (model A), eDP interface (model A), touch panel interface (model A), MiPi CSI interface, as well as many other device interfaces such as UART, SPI, I^2^C, for makers to integrate with sensors and other peripherals. Many different Operating Systems (OS) are freely available from the open source community, such as Linux (Ubuntu, Debian, Arch), BSD, and Android.\nGetting started Flashing the device Natively the board only supports booting the platform firmware from SPI, the eMMC or a microSD card, see boot order. The platform firmware loaded from there (U-Boot, EDK2, \u0026hellip;) may then allow loading kernels from additional storage mediums or even the network, and they will have their own boot order.\nThe board can be booted by flashing your chosen operating system to a microSD card using another device and inserting the microSD card into the Quartz64, see the article Getting started. Flashing the eMMC is possible by booting an operating system from the microSD card and overwriting the eMMC from within the booted operating system, or by using the USB eMMC adapter.\nBoot order The hardware boot order of the Quartz64 is:\nSPI NOR flash SPI NAND flash eMMC microSD card Pinout Model \u0026ldquo;A\u0026rdquo; The Quartz64 Model A board pinout\nModel \u0026ldquo;B\u0026rdquo; The Quartz64 Model B board pinout\nSoftware Building U-Boot\nInstalling Arch Linux ARM\nInstalling Debian\nReleases\nReleases This page contains a list of all available operating systems for the Quartz64 in alphabetical order, as well as links to other resources.\nSoftware releases Warning You are strongly encouraged to procure a 3.3V UART serial adapter capable of running at 1.5 mbauds, such as the Woodpecker if you want to use a Quartz64, as some images\u0026rsquo; U-Boot may have no video output on this chip. Important Note: The images are provided by the community, not by PINE64. Most community projects currently aim at getting mainline Linux running on the board, not some vendor provided kernel that will never be receiving updates. A mainline-first approach allows for the boards to continue receiving important updates, such as security updates, for years to come, as well as have higher quality code in the kernel as it underwent independent review, but does mean that not all aspects of the hardware work right out of the gate. Armbian Armbian is a base operating system platform for single board computers\nLightweight Debian or Ubuntu based Linux distribution specialized for ARM development boards Each system is compiled, assembled and optimized by Armbian Build Tools It has powerful build and software development tools to make custom builds Download:\nNote This image appears to have issues detecting more than 2GB of RAM. It is strongly recommended to use a different distribution. latest, as fresh as possible, upon code change, images Notes:\nSupport on Armbian forums https://forum.armbian.com/forum/96-upcoming-hardware-wip/ DietPi DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the Quartz64 builds on the PINE64 forum thread.\nDownload:\nQuartz64 Model A: Direct download from dietpi.com Quartz64 Model B: Direct download from dietpi.com SOQuartz: Direct download from dietpi.com Default credentials root dietpi NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. It relies upon the UEFI support in Tianocore. Before NetBSD 10 is released, the latest version of NetBSD-current should be used.\nDownload:\nNetBSD daily builds top level from inside here, navigate to a date, and inside the images/ subdirectory are installable images. Use the one called \u0026ldquo;NetBSD--evbarm-aarch64-install.img.gz\u0026rdquo;. Notes:\nThis image can be written to a supported device, such as the eMMC interface, any USB storage device, NVMe, and PCIe AHCI SATA are all supported with builds after 2022-01-15. Currently this can not be shared with the EDK2 port, ie, microSD for EDK2 and some other media for NetBSD. Tianocore EDK II port by jmcneill This (as of 2021-12-30) is a work in progress to enable UEFI enabled systems, and is able to bring up SD, eMMC, USB, PCIe with SATA and NVMe, HDMI, thermal sensors, TRNG, as well as general Cortex A-55 features. Known to work with NetBSD -current, and the ESXi Arm fling version 1.8.\nDownload:\njmcneill’s Quartz64 UEFI Github Notes:\nThe microSD card image should be written to an microSD card and installed. Currently, using the same card for the operating system as well may be problematic. BSP Linux SDK The *BSP Linux SDK ver 4.19_ for the Quartz64 Model A.\nDownload:\nDirect download from pine64.org (32.67GB, MD5 of the TAR-GZip file 24554419aec29700add97167a3a4c9ed) Android SDK Android 11 SDK The Android 11 SDK for the Quartz64 Model A SBC.\nDownload:\nDirect download from pine64.org (79.00GB, MD5 of the TAR-GZip file 77c2ff57ea3372fb04da7fb49e17d12b) Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz Android 11 Production Test Builds Android 11 Stock The Android 11 Stock images for eMMC boot for the Quartz64 Model A. This is test build that was used during product testing.\nDownload:\nStock image for the 8GB eMMC module from pine64.org (819MB, MD5 of the Gzip file e4365753e584d9fce1b8f10f095eede6, build 20210604) Stock image for the 16GB eMMC module from pine64.org (1.10GB, MD5 of the Gzip file 491c5f7744b0ca0b74ae76e607051836, build 20210604) Stock image for the 32GB eMMC module from pine64.org (846MB, MD5 of the Gzip file 47a6f0cdac8bad06cb920743849a8894, build 20210604) Stock image for the 64GB eMMC module from pine64.org (884MB, MD5 of the Gzip file 4e2fed6f5db0d55afdc8a142fc0c4fe1, build 20210604) Notes:\nWrite the disk images to the eMMC modules using the USB adapter, for example using dd. Please allow 3-5 minutes boot up time on first time for initialization. Android 11 Production Test Build The Android 11 Production Test Build for the Quartz64 model A for eMMC boot using ROCKChip tools method. This is a test build that was used during product testing.\nDownload:\nDirect download from pine64.org (812MB, MD5 of the Gzip file 800f867fdd0d1b2bd7822c156b6067e3, build 20210604) Notes:\nPlease unzip first and then using Rockchip Android tool ver 2.84 to flash in For Windows OS environment please install the DriverAssistant v5.11 driver first The OTG port located at top USB 2.0 port on top of USB 3.0 port, needs USB type A to type A cable. Please allow 3-5 minutes boot up time on first time for initialization Android 13 SDK The Android 13 SDK for the Quartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC.\nDownload:\nDirect download from pine64.org (111GB, MD5 of the TAR-GZip file 0cd965cf68145cc62876d50f320a715a) Android 13 Stock The Android 13 Stock images for eMMC boot for the Quartz64 Model Zero. This is test build.\nDownload:\nDirect download from pine64.org (765MB, MD5 of the Gzip file 00086005b07b23b8de06fd0c9f8c6816, build 20240606) Notes:\nPlease unzip first and then using Rockchip Android tool ver 3.13 to flash in For Windows OS environment please install the DriverAssistant v5.11 driver first The OTG port located on USB 3.0 port, needs USB type A to type A cable. Please allow 3-5 minutes boot up time on first time for initialization The Android 13 Stock images for SD boot for the Quartz64 Model Zero. This is test build.\nDownload:\nDirect download from pine64.org (765MB, MD5 of the Gzip file c80d48ba407533734fb6484c25d2a398, build 20240614) Notes:\nPlease unzip first and then using Rockchip SD card program tool ver 1.74 to program SD card Please allow 3-5 minutes boot up time on first time for initialization Building U-Boot This article guides you through compiling U-Boot for a Quartz64 and SOQuartz device.\nPrerequisites You will need either an x86 machine with an aarch64 cross-compiler installed, or an existing aarch64 system. You will also need the device tree compiler dtc, python3 (including setuptools and pyelftools), swig, GNU make and git.\nArch Linux On an x86_64 Arch Linux system, you can install the required dependencies with:\npacman -S --needed base-devel aarch64-linux-gnu-gcc aarch64-linux-gnu-binutils git dtc python-setuptools swig python-pyelftools Debian On an x86_64 Debian (or derivates such as Ubuntu) system, you can install the required dependencies with:\napt install device-tree-compiler build-essential gcc-aarch64-linux-gnu binutils-aarch64-linux-gnu make python3 python3-dev libssl-dev python3-pyelftools python3-setuptools swig git bison libgnutls28-dev Fetching the repositories Use git to clone the mainline U-Boot repository into the directory u-boot:\ngit clone https://source.denx.de/u-boot/u-boot.git You can use git checkout _tagname_ inside the u-boot directory to check out a specific git tag (release), you can list all of them with git tag -l (but do keep in mind we only have device support since v2023.10).\nThen, also use git to clone the rockchip firmware binaries repository into the directory rkbin:\ngit clone https://github.com/rockchip-linux/rkbin.git Setting up your environment Next, we need to set two environment variables: ROCKCHIP_TPL for the DRAM init binary, and BL31 for the ARM Trusted Firmware binary.\ncd u-boot export ROCKCHIP_TPL=\u0026#34;$(ls ../rkbin/bin/rk35/rk3566_ddr_1056MHz_v*.bin | sort | tail -n1)\u0026#34; export BL31=\u0026#34;$(ls ../rkbin/bin/rk35/rk3568_bl31_v*.elf | sort | tail -n1)\u0026#34; Configuring U-Boot First, we need to use the right default config for our device. Please choose defconfig from the following table depending on your device:\nBoard defconfig Quartz64 Model A quartz64-a-rk3566_defconfig Quartz64 Model B quartz64-b-rk3566_defconfig SOQuartz on Model A soquartz-model-a-rk3566_defconfig SOQuartz on Blade soquartz-blade-rk3566_defconfig SOQuartz on CM4 I/O Board soquartz-cm4-rk3566_defconfig In the u-boot directory with your environment variables set, run:\nmake CROSS_COMPILE=aarch64-linux-gnu- [defconfig] with [defconfig] being the value from the previous table.\nBuilding U-Boot In the u-boot directory, after configuring, and with your environment variables set, run:\nmake CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) This will output a u-boot-rockchip.bin, which is your freshly built SPL+U-Boot combined image.\nFlashing the U-boot Run as root or using sudo:\ndd if=u-boot-rockchip.bin of=/dev/\u0026lt;device, eg:mmcblk0\u0026gt; bs=32k seek=1 conv=fsync Installing Arch Linux ARM The articles explains the installation of Arch Linux ARM on the Quartz64.\nCommands to be run as a normal user are prefixed with $, commands to be run as root are prefixed with #. We assume your target device is /dev/sdX, adjust accordingly.\nPartitioning The Block Device Here we assume your block device is /dev/sdX, adjust as needed.\nCreate a new partition table:\n# parted -s /dev/sdX mklabel gpt Create the partitions for loader and u-boot:\n# parted -s /dev/sdX mkpart loader 64s 8MiB # parted -s /dev/sdX mkpart uboot 8MiB 16MiB Create the partition for u-boot’s environment:\n# parted -s /dev/sdX mkpart env 16MiB 32MiB Create the \u0026ldquo;efi\u0026rdquo; boot partition and mark it as bootable:\n# parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB # parted -s /dev/sdX set 4 boot on Create the root partition:\n# parted -s /dev/sdX mkpart root ext4 544MiB 100% Creating The File Systems Now create the file systems for boot and root:\n# mkfs.vfat -n \u0026#34;efi\u0026#34; /dev/sdX4 # mkfs.ext4 -L \u0026#34;rootfs\u0026#34; /dev/sdX5 Fetching and Flashing U-Boot For this we’ll use the precompiled idblock and u-boot from pgwipeout’s CI.\nGo to https://gitlab.com/pgwipeout/quartz64_ci/-/pipelines and click the three dots, download the merge-job artifacts.\nUnzip them:\n$ unzip artifacts.zip Flash idblock.bin and uboot.img:\n# dd if=artifacts/idblock.bin of=/dev/sdX1 # dd if=artifacts/uboot.img of=/dev/sdX2 Fetching The Root File System Tarball Fetch the root filesystem tarball and the PGP signature\n$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} Fetch the gpg keys:\n$ curl \u0026#39;https://keyserver.ubuntu.com/pks/lookup?op=get\u0026amp;search=0x68b3537f39a313b3e574d06777193f152bdbe6a6\u0026#39; | gpg --import=- Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS)\nVerify the tarball’s authenticity\n$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig Important Do not skip verifying the authenticity. This is important. It also protects you from prematurely aborted transfers giving you a corrupt archive. Installing The Root File System # mount /dev/sdX5 /mnt/alarm-root # mkdir /mnt/alarm-root/boot # mount /dev/sdX4 /mnt/alarm-root/boot # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root Editing fstab Find your partition UUIDs for both partitions using lsblk:\n$ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID In /mnt/alarm-root/etc/fstab, put the lines\nPARTUUID=_root-uuid-here_ / ext4 defaults 0 1 PARTUUID=_boot-uuid-here_ /boot vfat defaults 0 2 with your UUIDs in place of the placeholder.\nWriting extlinux.conf Create a /mnt/alarm-root/boot/extlinux/extlinux.conf with these contents:\ndefault l0 menu title Quartz64 Boot Menu prompt 0 timeout 50 label l0 menu label Boot Arch Kernel linux /Image fdt /dtbs/rockchip/rk3566-quartz64-a.dtb append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xfe660000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait For Model B Kernel 5.18 and 5.19 do not yet have the Quartz64 Model B device tree, however, you can add it manually to your install and adjust extlinux.conf:\nDownload it from here: https://overviewer.org/~pillow/up/5f1fabef1b/rk3566-quartz64-b.dtb (this is just linux-next with sd card speed changed to sd-uhs-sdr50)\nCopy it to /mnt/alarm-root/boot/dtbs/rockchip/rk3566-quartz64-b.dtb\nThen adjust your /mnt/alarm-root/boot/extlinux/extlinux.conf*\u0026rsquo;s fdt* line as follows:\nfdt /dtbs/rockchip/rk3566-quartz64-*b*.dtb Finishing Up Once done, unmount the partitions:\n# umount /mnt/alarm-root/boot # umount /mnt/alarm-root Booting And Finishing Setup Hook up your UART dongle to your Quartz64, open a serial terminal at 1.5mbauds. Install the SD card or eMMC module inside the Quartz64, and plug in the power.\nOnce you hit a login shell, log in as root with password root and run:\n# pacman-key --init # pacman-key --populate archlinuxarm You are now ready to use Arch Linux ARM! Either delete or rename (and move the homedir of) the alarm user, and you’re all set. Don’t forget to install things like sudo and setting up sudo groups and such.\nInstalling Debian It is possible to install Debian onto eMMC of the Quartz64 from the pgewipout quartz64_ci imaged to a Micro SDcard, or vice versa.\nThis might be useful if you don’t have an eMMC to USB adapter or if the board is inside a case which doesn’t allow eMMC removal.\nDownload artifacts merge-job:archive from https://gitlab.com/pgwipeout/quartz64_ci/-/pipelines\nUnpack zip file\nImage to a Micro SDcard present in your PC as /dev/sdX:\nsudo -i; xzcat images/rk3566-quartz64-a.dtb.img.xz \u0026gt; /dev/sdX sudo sync Boot quartz64-a from microSD card\nAt boot menu select 1 (Buildroot-recovery)\nparted -s /dev/mmcblk1 mklabel gpt parted -s /dev/mmcblk1 mkpart loader 64s 8MiB parted -s /dev/mmcblk1 mkpart uboot 8MiB 16MiB parted -s /dev/mmcblk1 mkpart env 16MiB 32MiB parted -s /dev/mmcblk1 mkpart efi fat32 32MiB 544MiB parted -s /dev/mmcblk1 set 4 boot on parted -s /dev/mmcblk1 mkpart root ext4 544MiB 100% dd if=/dev/mmcblk0p1 of=/dev/mmcblk1p1 dd if=/dev/mmcblk0p2 of=/dev/mmcblk1p2 dd if=/dev/mmcblk0p3 of=/dev/mmcblk1p3 mkdosfs -F 32 -n \u0026#34;efi\u0026#34; /dev/mmcblk1p4 mke2fs -L \u0026#34;rootfs\u0026#34; /dev/mmcblk1p5 sync reboot At boot menu select 2 (Debian-Installer)\nchoose manual partitioning\nset partition #5 of mmcbkl1 to be /, format to ext4 and complete the installation\nreboot (installer will do this anyway)\nmkdir /mnt/mmcblk0p5 mkdir /mnt/mmcblk1p4 mkdir /mnt/mmcblk1p5 mount /dev/mmcblk0p5 /mnt/mmcblk0p5 mount /dev/mmcblk1p4 /mnt/mmcblk1p4 mount /dev/mmcblk1p5 /mnt/mmcblk1p5 cp -a /mnt/mmcblk0p5/dtbs /mnt/mmcblk1p4/ cp /mnt/mmcblk0p5/vmlinuz /mnt/mmcblk1p4/ mkdir /mnt/mmcblk1p4/extlinux touch /mnt/mmcblk1p4/extlinux/extlinux.conf echo \u0026#39;label Debian on eMMC\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p4/extlinux/extlinux.conf echo \u0026#39;linux /vmlinuz\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p4/extlinux/extlinux.conf echo \u0026#39;fdt /dtbs/rockchip/rk3566-quartz64-a.dtb\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p4/extlinux/extlinux.conf echo \u0026#39;append earlycon=uart8250,mmio32,0xfe660000 console=ttyS2,1500000n8 root=/dev/mmcblk1p5 rootwait\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p4/extlinux/extlinux.conf cp /mnt/mmcblk0p5/kernel-modules.tar.gz /mnt/mmcblk1p5/root/ The following lines (upto adding the boot partition to fstab) are optional. Debian will boot just fine if the boot partition isn’t in fstab and you may prefer to manually mount it when you want to change the kernel:-\nblkid /dev/mmcblk1p4\nThe output will show the UUID of your boot partition:-\n/dev/mmcblk1p4: LABEL_FATBOOT=\u0026ldquo;efi\u0026rdquo; LABEL=\u0026ldquo;efi\u0026rdquo; UUID=\u0026ldquo;5985-9C7B\u0026rdquo; BLOCK_SIZE=\u0026ldquo;512\u0026rdquo; TYPE=\u0026ldquo;vfat\u0026rdquo; PARTLABEL=\u0026ldquo;efi\u0026rdquo; PARTUUID=\u0026ldquo;93226dfa-53af-4400-8aab-239ff7900dd0\u0026rdquo;\necho \u0026#39;UUID=UUID_from_above /boot vfat defaults 0 1\u0026#39; \u0026gt;\u0026gt; /mnt/mmcblk1p5/etc/fstab chroot /mnt/mmcblk1p5 dpkg -l |grep image To show which kernel images Debian has installed:-\nii linux-base 4.6 all Linux image base package\nii linux-image-4.19.0-18-arm64 4.19.208-1 arm64 Linux 4.19 for 64-bit ARMv8 machines (signed)\nii linux-image-arm64 4.19+105+deb10u13 arm64 Linux for 64-bit ARMv8 machines (meta-package)\nUninstall them:\ndpkg -P linux-image-4.19.0-18-arm64 linux-image-arm64 cd /root tar -xzvf kernel-modules.tar.gz mv lib/modules /lib/ exit halt Remove MicroSD card and boot into eMMC.\nDevelopment This page documents the current status of software support for the Quartz64 single-board computer, and provides links to resources to help prospective contributors get started. Information is kept current on a best-effort basis as various patches get accepted into the kernel.\nOverview Upstreaming Status Function Status Component Notes Applies To Video Output Linux Mainline rockchipdrm/VOP2 As of 5.19-rc1Source,Also featured in Phoronix ArticleSource, 4k@30 support and other improvements in 6.4-rc1Source Needs porting rockchip-edpphy-naneng Downstream: Source and Source Coordinate any porting with Rockchip first Linux Mainline dw-mipi-dsi-rockchip As of 6.1Source 3D Acceleration Linux Mainline Upstream Mesa panfrost As of 5.18Source Video Decode Linux Mainline GStreamer only, no ffmpegSource hantro using v4l2-requests VDPU121 handling 1080p MPEG-2, VP8 and H.264. Mainline as of 5.19Source Needs writing rkvdec2 using v4l2-requests VDPU346 handling 4K H.265, H.264 and VP9 Needs writing rkdjpeg using v4l2-requests VDPU720 handling JPEG, User:CounterPillow is working on this Video Encode Linux Mainline GStreamer only JPEG on VEPU121 Hantro-based. Mainline as of 6.1Source Needs writing ? H.264 on VEPU121 Hantro-based Needs writing ? VP8 on VEPU121 Hantro-based Needs writing ? H.264 on VEPU540 rkvenc-based Needs writing ? H.265 on VEPU540 rkvenc-based Audio Linux Mainline rockchip-i2s-tdm As of 5.16Source Linux Mainline rockchip-spdif As of 5.15Source Linux Mainline rk817-codec As of 5.14Source. Quartz64 Model A/B Bootloader In reviewSource TF-A Merged U-Boot #mainline_u_boot_work[See below]. Quartz64 and SOQuartz as of v2023.10-rc2Source In progressSource Tianocore EDK II Device Tree Linux Mainline Quartz64 Model A As of 5.16Source Quartz64 Model A Linux Mainline Quartz64 Model B As of 5.19Source Quartz64 Model B Linux Mainline SOQuartz As of 5.19Source SOQuartz Linux Mainline PineNote As of 5.18Source PineNote Gigabit Ethernet Linux Mainline rk3566-gmac As of 5.14Source Linux Mainline yt8511-phy As of 5.14Source IOMMU Linux Mainline rockchip-iommu As of 5.14Source GPIO Linux Mainline gpio-rockchip As of 5.15Source pinctrl Linux Mainline Thermal Regulation Linux Mainline rockchip-thermal As of 5.14Source PCIe Linux Mainline pcie-dw-rockchip As of 5.15Source Power Management Linux Mainline rockchip-pm-domains As of 5.14Source Voltage Control Linux Mainline rk3568-pmu-io-voltage-domain As of 5.15Source SPI Linux Mainline spi-rockchip As of 5.14Source.Necessary device tree changes in review. Battery Linux Mainline rk817-charger As of 6.1Source Quartz64 Model A, PineNote Microphone Linux Mainline rockchip-saradc As of 5.15Source. Headphone jack mic seems to connect to SARADC_VIN2_HP_HOOK, so I\u0026rsquo;m pretty sure that the dtsi and driver changes are needed for that mic to work USB 2.0 Linux Mainline rockchip-usb2phy As of 5.17Source e-Ink In review (RFC)Source rockchip-ebc A DRM driver is available here; See also RK3566 EBC Reverse-Engineering Combo PHY Linux Mainline naneng-combphy As of 5.18Source. Still requires DTS changes RGA Linux Mainline; Could be improved rockchip-rga As of 6.5Source. Note that there\u0026rsquo;s still a \u0026lsquo;4GB\u0026rsquo; problem and it\u0026rsquo;s implementations has room for improvements (to put it midly Source and Source) Fan Controller Needs writing gp7101 Someone should write a pwm driver for it so we can then use pwm-fan SOQuartz Blade CSI Camera Needs porting rkisp Downstream: Source Linux Mainline rockchip-inno-csidphy As of 6.1Source NPU Needs writing Downstream version is a closed source SDK and open source kernel module rknpu. Major undertaking to reimplement this as Linux does not (yet) appear to have a generic architecture for neural accelerators. Crypto Needs porting rk-crypto v2 Downstream driver (link) doesn\u0026rsquo;t include a rk3568 compatible either, but the TRM shows that it seemingly matches. TRNG In reviewSource rockchip-rng Wi-Fi Needs porting bes2600 A downstream driver is available but it makes use of some custom Rockchip interfaces and is designed for older kernels, plans are being made to port it to DKMS. PineTab 2 Linux Mainline brcmfmac Quartz64 Model B Current Status The following sections give an overview over the current status of different parts of the board. Some parts are waiting on a driver to be written or ported, others only need various adjustments.\nAccording to pgwipeout, I/O device performance is within expected ranges now.\nWorking eMMC SDMMC0 (SD cards) GMAC (Gigabit Ethernet) USB 2.0 SATA 2 SATA 3 UART UART 0 (Pi-bus) UART 1 (Bluetooth) UART 2 (Pi-bus, debug) Video Decode VP8 H.264 Video Encode JPEG (it’s pretty bad) Battery GPU Video Output HDMI DSI Audio Analog audio works SPDIF works HDMI works SPI — works, user needs to modify device tree to add devices I^2^C — works, user needs to modify device tree to add devices Partially Working PCI-Express Controller — everything but devices that need cache coherency (e.g. dGPUs) should work User:CounterPillow noticed some weirdness with NVMe devices disconnecting during heavy write operations, likely down due to power draw on one of the rails as the same sustained bandwidth could be achieved with a different PCIe device with no issue. SDMMC1 (Wi-Fi) — AP6256 working, BL602 needs some work to make it flash firmware GIC — needs errata published by Rockchip to get upstream to add device-specific workarounds ^link:https://lore.kernel.org/linux-rockchip/CAMdYzYrQ5f-mv_VmTq_CRf9tR=\\j3mwRpKHNLmPFgCF9whsGFRw@mail.gmail.com/[link]^ Confirmed Broken USB 3.0 (applies to Model A only) — only works with very short cables and depends on the device. This is due to a hardware design issue relating to the coupling capacitors needed for SATA, which shares the same lines as USB 3.0. Hardware design changes have been suggested to engineers, it’s in their hands now. Fixed in newer revisions by leaving SATA unpopulated RGA — only works with memory ≤ 4 GiB, because Rockchip didn’t make the address registers larger. Oopsie. Needs Testing E-Paper Microphone Input CSI — needs CIF driver eDP — needs PHY driver and controller driver TODO ebc-dev Reverse Engineering and Development The driver for the eInk panel needs to both be reverse engineered and then rewritten as C. In its current form, it is mostly an assembly dump produced by gcc with debug symbols. See RK3566 EBC Reverse-Engineering for details.\nInvestigate MCU The RK3566 comes with an integrated RISC-V microcontroller (MCU). It communicates with the A55 host through the Mailbox system driven by the rockchip-mailbox driver. Since this MCU would be quite useful for things such as low power standby mode, investigating how it can be turned on and have firmware flashed to it should greatly enhance the power saving features of the PineNote.\nThe user liamur did some investigation into the MCU and found that it is disabled by TF-A on suspend, and doesn’t reside in a low-power part of the RK3566 anyway. It does however have access to most of the chip and could be used as (for example) a real-time coprocessor.\nMainline U-Boot Work We currently use the \u0026ldquo;downstream\u0026rdquo; Rockchip U-Boot, which is based on an old version of U-Boot and contains vendor specific patches that have not undergone the same level of code review as they’d have done had they been submitted upstream.\nWhile the lack of ATF sources means that using mainline U-Boot would still require the use of Rockchip provided binaries for the firmware, even with Rockchip blobs, a more modern version of U-Boot will be much nicer to use.\nMainline U-Boot contains good enough support for the RK3566 SoC used on the Quartz64 as of v2023.07 and have support for Quartz64 and SOQuartz as of v2023.10-rc2. Drivers for ethernet GMAC and Motorcomm PHY are supported as of v2024.01-rc1.\nThings that could be done This list is non-exhaustive as we don’t exactly know how much is missing\nPort a basic VOP2 driver to get a framebuffer from u-boot List of Useful Resources for this Task Downstream Rockchip U-Boot repository with Quartz64 specific patches: https://gitlab.com/pgwipeout/u-boot-rockchip/-/tree/quartz64 Mainline Rockchip custodian U-Boot repository: https://source.denx.de/u-boot/custodians/u-boot-rockchip U-Boot Mailing List: https://lists.denx.de/listinfo/u-boot eDP Driver Porting The eDP PHY driver and controller driver needs to be ported, brought into shape and submitted with proper commit attribution to the Rockchip authors.\nUser:CounterPillow has experimentally ported stuff, but it’s currently not working.\nLinux Kernel Config Options CONFIG_SND_SOC_ROCKCHIP_I2S_TDM for Analog and HDMI audio CONFIG_SND_SOC_RK817 for Analog audio on the Model A CONFIG_STMMAC_ETH Ethernet CONFIG_DWMAC_ROCKCHIP Ethernet CONFIG_MOTORCOMM_PHY Ethernet PHY for Model A, set this one to Y, m won’t work out of the box if the generic PHY driver is y and binds first. Alternatively tell users in board-specific setup instructions to force including the motorcomm module in initramfs if you set it to m. CONFIG_REALTEK_PHY Ethernet PHY for Model B CONFIG_MMC_DW MMC/SD CONFIG_MMC_DW_ROCKCHIP MMC/SD CONFIG_MMC_SDHCI_OF_DWCMSHC MMC/SD CONFIG_PCIE_ROCKCHIP_DW_HOST PCIe CONFIG_PHY_ROCKCHIP_NANENG_COMBO_PHY PHY for PCIe/SATA/USB3 CONFIG_DRM_PANFROST GPU CONFIG_SND_SOC_ROCKCHIP_SPDIF SPDIF audio CONFIG_ROCKCHIP_DW_HDMI HDMI PHY CONFIG_PHY_ROCKCHIP_INNO_DSIDPHY MIPI DSI DPHY CONFIG_ROCKCHIP_VOP2 Video output CONFIG_ARCH_ROCKCHIP General SoC support CONFIG_ROCKCHIP_PHY General SoC support CONFIG_PHY_ROCKCHIP_INNO_USB2 USB 2 CONFIG_RTC_DRV_RK808 Real-time Clock CONFIG_COMMON_CLK_RK808 Real-time Clock CONFIG_MFD_RK808 Various things relating to the RK817 chip CONFIG_CHARGER_RK817 RK817 charger CONFIG_REGULATOR_RK808 Voltage regulators CONFIG_ROCKCHIP_PM_DOMAINS Power management domains CONFIG_GPIO_ROCKCHIP GPIO support CONFIG_PINCTRL_ROCKCHIP GPIO and general SoC support CONFIG_PWM_ROCKCHIP PWM support CONFIG_ROCKCHIP_IOMMU IOMMU support CONFIG_ROCKCHIP_MBOX Mailbox support (for communication with MCU) CONFIG_ROCKCHIP_SARADC Analog-to-digital conversion support, for e.g. microphones CONFIG_ROCKCHIP_THERMAL Temperature sensor and thermal throttling support CONFIG_SPI_ROCKCHIP SPI support CONFIG_VIDEO_HANTRO_ROCKCHIP Hardware video decoder support CONFIG_ROCKCHIP_IODOMAIN General SoC support so your I/O pins have the right voltage CONFIG_COMMON_CLK_ROCKCHIP Common clock support CONFIG_PHY_ROCKCHIP_INNO_CSIDPHY MIPI CSI DPHY CONFIG_I2C_RK3X I2C support Resources Repositories pgwipeout’s kernel tree https://gitlab.com/pgwipeout/linux-next/-/tree/quartz64-v5.15-rc1 BSP based development effort for SPL/U-Boot and Linux https://gitlab.com/pine64-org/quartz-bsp Image CI pipeline aimed at developers https://gitlab.com/pgwipeout/quartz64_ci/ Rockchip U-Boot https://github.com/rockchip-linux/u-boot Downstream rockchip-linux kernel tree https://gitlab.com/pine64-org/quartz-bsp/rockchip-linux Tianocore EDK II port for UEFI on Quartz64 https://github.com/jaredmcneill/quartz64_uefi Mainline U-Boot Port by pgwipeout https://gitlab.com/pgwipeout/u-boot-quartz64 Other Rockchip-SoC Patchwork Page https://patchwork.kernel.org/project/linux-rockchip/list/ Rockchip Kernel Mailing List Archive https://lore.kernel.org/linux-rockchip/ Board/SoC Documentation Booting Boot Order The RK3566 boot ROM will search for a valid ID BLOCK in the following order on the support boot media:\nSPI NOR flash SPI NAND flash eMMC SD-Card If this fails, the boot ROM will initialize the USB0 port and wait for a connection from the Rockchip flash/boot tools.\nBootloader Flashing As per pgwipeout’s commit message:\nMake a partition named uboot as partition number 1 at 8 MiB to 16 MiB dd if=idblock.bin of=/dev/_\u0026lt;mmc/sd\u0026gt;_ seek=64 dd if=uboot.img of=/dev/_\u0026lt;mmc/sd\u0026gt;_1 Efforts See Quartz64 Development\nInformation and resources of the ongoing development effort for the Quartz64 can be found on the Development page, where the current status of various board functions can be found, and whether they have landed in upstream.\nQuartz64 BSP Gitlab Page Frequently Asked Questions Do I Need A Fan/What Heatsink Do I Need? You don’t need a fan. The 20mm medium heatsink for Model A is plenty enough. For Model B, the fan type heatsink will do fine.\nCan This Run A Minecraft Server? Yes! Sort of. Testing on an 8GB Model A with PaperMC, User:CounterPillow was able to out-row world generation in a boat with just one player online, but aside from the slow world gen (which can be pre-generated) the server handled things like TNT explosions and mobs fine. It’ll probably do okay with 1-3 players.\nDo I Need The 5A Power Supply For Model A? You only need the 5A power supply for Model A if you plan on connecting hard disk drives to the 12V header on the board.\nHow Much Power Does It Consume? For Model B, it’s \u0026lt;2W in idle (powertop tunables not set), and \u0026lt;5W under full CPU load (stress-ng -c4). Model A will be similar as it’s the same SoC.\nTroubleshooting Stability/Boot Issues With Missing Battery Shunt If there is no battery plugged into the board, the jumper labelled \u0026ldquo;ON/OFF_BATT\u0026rdquo; must be in place. If this is set wrong, stability issues such as failures to boot will occur.\nNote This affects only Model A No Ethernet Connectivity Make sure the kernel is built with CONFIG_MOTORCOMM_PHY set to y. Building it as a module (m) and then relying on module auto-loading is unlikely to work, because if the generic PHY driver is built in it will bind to the PHY first, unless you include the motorcomm module in your initramfs.\nNote: Starting with Debian’s 6.1~rc3-1~exp1 kernel the module is included, but set to m and I (Diederik) have verified that it gets included in the initramfs and works on Model-A and Model-B with the Quartz64 images.\n\u0026ldquo;Model A\u0026rdquo; Acrylic Case Doesn\u0026rsquo;t Fit The Quartz64 does not really fit onto the bottom plate of the Model A Acrylic Open Enclosure. This is because the \u0026ldquo;Mic\u0026rdquo; connector at the bottom of the board interferes with one of the posts. A workaround is to find out which post that is (you have a 50% chance of guessing it right, accounting for rotating the board) and then filing away the corner of the post pointing inwards by a few millimeters.\nAn alternate solution may be to place plastic spacers with a smaller outer diameter in between the acrylic bottom plate posts and the SBC board.\nNo GPU Acceleration with Debian \u0026ldquo;Bullseye\u0026rdquo; Userland Debian Bullseye ships a Mesa version that is too old to contain the required patches for the RK356x SoC’s GPU. Upgrade to Bookworm.\nWireless Connectivity Doesn\u0026rsquo;t Work ROCKPro64 wireless module may have CYW43455 or CYW43456 chips on board (not sure if this is the same for Quartz64 model B). Both chips are supported by brcmfmac Wi-Fi driver and btbcm Bluetooth driver.\nFor CYW43455 drivers attempt to load /lib/firmware/brcm/brcmfmac43455-sdio.bin for Wi-Fi and /lib/firmware/brcm/BCM4345C0.hcd for Bluetooth. Corresponding firmware files for CYW43456 are /lib/firmware/brcm/brcmfmac43456-sdio.bin and /lib/firmware/brcm/BCM4345C5.hcd.\nOn Manjaro firmware files for both Bluetooth and Wi-Fi on CYW43456 on are provided by ap6256-firmware package (pacman -S ap6256-firmware).\nHowever for CYW43455 wi-fi firmware is in the linux-firmware package and bluetooth is in the firmware-raspberrypi (pacman -S linux-firmware firmware-raspberrypi). linux-firmware package is missing device specific symlinks for quartz64-a. To create them execute:\n# ln -s brcmfmac43455-sdio.bin /lib/firmware/brcm/brcmfmac43455-sdio.pine64,quartz64-a.bin # ln -s brcmfmac43455-sdio.AW-CM256SM.txt /lib/firmware/brcm/brcmfmac43455-sdio.pine64,quartz64-a.txt As of 2022-10-19 device tree in mainline kernel for Quartz64 model A has wrong configuration for the Bluetooth driver. Patch is submitted to the LKML and accepted and included upstream in 6.1-rc7. It’s possible to modify dtb file provided by the current kernel using device tree compiler to enable Bluetooth or perform make dtbs in the patched kernel tree to get updated dtb file (arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dtb). Issue manifests itself with following errors in dmesg:\ncommand 0x0c03 tx timeout Bluetooth: hci0: BCM: Reset failed (-110) How-Tos Connect Debug UART The easiest way to get debug output is to connect a 3.3V 1.5mbaud capable UART adapter to the board.\nTo connect it, connect the ground lead to pin 6, and the RX/TX leads to pins 8 and 10 (consider swapping them if you get no output, things are often mislabeled). These pins are \u0026ldquo;UART2\u0026rdquo; in the above GPIO table.\nOpen a serial terminal at 1500000 bauds, e.g.\n$ picocom -b 1500000 /dev/ttyUSB0 Disable Heartbeat LED (Linux) The flashing LED is called the \u0026ldquo;heartbeat LED\u0026rdquo;, it blinks in a heart rhythm like fashion once the kernel is running. To disable it, you can run\n# echo none \u0026gt; /sys/class/leds/user-led/trigger On model A LED device is called \u0026ldquo;diy-led\u0026rdquo;, not \u0026ldquo;user-led\u0026rdquo;.\nOn a system with systemd, you can do this as soon as the system is ready to be logged in with a systemd unit like this:\n[Unit] Description=Turn off heartbeat LED Wants=multi-user.target After=multi-user.target [Install] WantedBy=multi-user.target [Service] Type=simple ExecStart=sh -c \u0026#39;echo none \u0026gt; /sys/class/leds/user-led/trigger\u0026#39; Place it in /etc/systemd/system/user-led.service, and run\n# systemctl daemon-reload # systemctl enable user-led.service Upon rebooting, you will now notice that the heartbeat LED will blink during boot-up, but stops blinking as soon as the multi-user target is reached (i.e. the user can log in).\nSATA on model A On model A USB 3.0 and SATA ports are using the same I/O line and can’t be used simultaneously. By default USB 3.0 is enabled in Linux device tree and SATA is disabled. FDT modifications are required to turn SATA on.\nFollowing script is tested on Manjaro but should work on the other distributions with minimal changes. Device tree compiler package usually provides fdtput command (on Manjaro run: pacman -S dtc)\n# cp /boot/dtbs/rockchip/rk3566-quartz64-a.dtb /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb # fdtput -t s -v /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb /usb@fd000000 status disabled # fdtput -t s -v /boot/dtbs/rockchip/rk3566-quartz64-a-sata.dtb /sata@fc400000 status okay # sed -i \u0026#39;s#^FDT /dtbs/rockchip/rk3566-quartz64-a.dtb$#FDT /dtbs/rockchip/rk3566-quartz64-a-sata.dtb#\u0026#39; /boot/extlinux/extlinux.conf # systemctl reboot Using a PCF8574 on Model A See Model A: Using a PCF8574.\nUsing a battery on Model A See Model A: Using a battery.\nConnecting a MIPI-DSI display See Connecting a MIPI-DSI display.\nConnecting a MIPI-DSI display The Quartz64 single-board computers (both Model A and Model B) come with MIPI-DSI ports for connecting a MIPI-DSI compatible display.\nThis article will go into how to connect the official PINE64 7\u0026quot; LCD Touch Screen Panel and setting up the software. Since this requires a panel driver for each panel, other displays generally are not interchangeable, as they won’t use the same driver compatible (or even have a mainline driver at all!)\nConnecting the hardware When connecting the display, please make sure the board is powered off and unplugged. Failure to do so could make you short out the pins while connecting it!\nModel A To connect the hardware, lift up the dark flap of the part marked with \u0026ldquo;DSI\u0026rdquo; in red in the above picture. Then, insert the flat flex cable with the contacts pointing down (and the blue backing pointing up). In the same fashion, connect the thinner touch panel controller cable to the port marked with \u0026ldquo;TP\u0026rdquo; in blue.\nFor the DSI cable, connect the other end to the small green joiner/adapter board, which you can first connect to the display’s DSI connector, again with the contacts facing down.\nFor the touch cable, connect the other end to the small green PCB attached to the back of the panel, again paying attention to have the contacts facing downwards (and the blue backing facing upwards).\nModel B Important Note: There’s no port for the touch panel input on Model B. TODO: Write this section. Adapter cable is needed.\nSetting up the software For the display to be used, you need to tell the kernel about it by modifying the device tree. The easiest way to go about this is to use device tree overlays.\nThe kernel needs to be built with CONFIG_DRM_PANEL_FEIYANG_FY07024DI26A30D turned on (either as module or built-in), as that is the driver for this panel.\nOn Plebian Important Note: Currently Debian’s kernel doesn’t have the panel driver built as part of its configuration. We’ll get that sorted soon. Use git clone to clone the overlay-examples repository by CounterPillow. Then, grab a copy of the Linux kernel source from kernel.org if you don’t already have one. To build the device tree overlays, run make INCLUDE_DIR=path/to/linux/include in the overlay-examples directory, substituting path/to/linux/include with your path of course.\nFor Quartz64 Model A, copy build/quartz64a/pine64-lcd-panel.dtbo into your /boot/dtbo/ directory (create it if it doesn’t already exist) and run sudo u-boot-update.\nThat’s all there is to it, the panel should light up on your next reboot.\nModel A: Using a battery The Quartz64 Model A allows for it to be powered from a single-cell 3.7V lithium-polymer battery. Because of unfortunate incidents, batteries are not easy to ship internationally, so PINE Store does not sell a matching battery for the board.\nPin-out right\nThe pins on the board are a JST PH-3 compatible header labelled +VBAT-. As one might guess, the positive wire should be towards the +, and the ground wire towards -. The center pin of the connector is for a temperature probe.\nWays to get a battery We will now go into various ways one might go about getting a working battery.\nCrimping one yourself You will need:\nan Engineer PA-20 (Amazon Search, eBay Search) or Hozan P-707 (Amazon Search, eBay Search) or similar crimp tool (\u0026lt;$80, good to have around anyway) The Hozan P-707 is also comparatively good at crimping \u0026ldquo;Dupont\u0026rdquo;-style terminals, in case you find yourself doing that a lot, because it provides round crimping holes in addition to rectangular ones. JST PHR-3 receptacles (~$0.05 on digikey) 3× JST SPH-002T-P0.5L crimp terminals (~$0.03 on digikey per terminal) When ordering from digikey, try to hit the minimum order cost to qualify for free shipping; you’ll get free fast courier shipping with all customs and duties pre-paid. a single-cell 3.7V lithium-polymer battery, ideally with a temperature probe 2800 mAh Renata ICP606168PRT on Conrad Germany, Conrad Switzerland 2000 mAh Adafruit on Adafruit US (no temperature probe, pre-crimped with JST PHR-2; just lift up the plastic tabs and pull out the terminals and shove them back into a PHR-3 connector) Aliexpress: try keywords \u0026ldquo;3.7v lithium battery temperature probe\u0026rdquo; Crimp the terminals onto the wires, crimp the strain relief onto the insulation, slide them into the connector until they firmly click in place.\nPINE64 18650 battery case You will need:\nPINE64 Lithium Battery Casing an 18650 sized lithium battery (not LiFePo4!) TODO: Get one of these and document how to use them\nUsing the battery Hardware Ensure the wires in the connector are in the right order. Turn off your Quartz64 Model A. Remove the BAT ON/OFF jumper. Plug in your battery. It is now ready to use if your device tree has been set up correctly. Caveats Not all parts of the board can be supplied from the battery. When you use battery as backup power for the board keep in mind that following parts of Quartz64-A will lose power when DCIN loses power:\n12V Fan connector EDP LCD backlight 5V power rails on the 20 pin GPIO header PCIe socket (both 12V and 3.3V supplies) All USB ports except for the black one Black USB port’s VBUS (the one above the USB 3.0 port) will go through a 22ms brownout to approximately VCC_SYS - 0.6V voltage, before the RK817 BOOST regulator kicks in. This will likely cause the connected USB device to reset or have its internal state corrupted. Software For the battery to be correctly detected, you will need to edit the device tree to add the charger and battery nodes, like this:\n// add this to root node (you may need to modify the values to fit your chosen battery) battery: battery { compatible = \u0026#34;simple-battery\u0026#34;; charge-full-design-microamp-hours = \u0026lt;6400000\u0026gt;; charge-term-current-microamp = \u0026lt;200000\u0026gt;; constant-charge-current-max-microamp = \u0026lt;2000000\u0026gt;; constant-charge-voltage-max-microvolt = \u0026lt;4200000\u0026gt;; factory-internal-resistance-micro-ohms = \u0026lt;117000\u0026gt;; voltage-max-design-microvolt = \u0026lt;4200000\u0026gt;; voltage-min-design-microvolt = \u0026lt;3200000\u0026gt;; ocv-capacity-celsius = \u0026lt;20\u0026gt;; ocv-capacity-table-0 = \u0026lt;4200000 100\u0026gt;, \u0026lt;4054000 95\u0026gt;, \u0026lt;3984000 90\u0026gt;, \u0026lt;3926000 85\u0026gt;, \u0026lt;3874000 80\u0026gt;, \u0026lt;3826000 75\u0026gt;, \u0026lt;3783000 70\u0026gt;, \u0026lt;3746000 65\u0026gt;, \u0026lt;3714000 60\u0026gt;, \u0026lt;3683000 55\u0026gt;, \u0026lt;3650000 50\u0026gt;, \u0026lt;3628000 45\u0026gt;, \u0026lt;3612000 40\u0026gt;, \u0026lt;3600000 35\u0026gt;, \u0026lt;3587000 30\u0026gt;, \u0026lt;3571000 25\u0026gt;, \u0026lt;3552000 20\u0026gt;, \u0026lt;3525000 15\u0026gt;, \u0026lt;3492000 10\u0026gt;, \u0026lt;3446000 5\u0026gt;, \u0026lt;3400000 0\u0026gt;; }; // add this to \u0026amp;rk817 node rk817_charger: charger { monitored-battery = \u0026lt;\u0026amp;battery\u0026gt;; rockchip,resistor-sense-micro-ohms = \u0026lt;10000\u0026gt;; rockchip,sleep-enter-current-microamp = \u0026lt;300000\u0026gt;; rockchip,sleep-filter-current-microamp = \u0026lt;100000\u0026gt;; }; You will also need to make sure that CONFIG_CHARGER_RK817 is enabled in your kernel.\nModel A: using a PCF8574 In this article, we’ll go over how to hook up a PCF8574 I^2^C I/O extender to a Quartz64 Model A single-board computer, including what device tree changes to make and how to control it.\nIntroduction to the PCF8574 The PCF8574 is a fairly ubiquitous GPIO extender that communicates through the I^2^C bus. You can find modules featuring it from many vendors on the usual marketplaces for cheap. It exposes 8 additional GPIO lines, and can be daisy chained to up to 8 devices, giving you an additional 64 GPIO outputs. Combining it with 8 PCF8574A modules will actually push this to a total of 128 GPIO outputs added to your board!\nThe PCF8574 has a mainline Linux driver, meaning that you do not need to use I^2^C directly to control it; it will just appear as another /dev/gpiochip_\u0026lt;n\u0026gt;_ device. A lot of Raspberry Pi focused guides for this chip get this precise thing wrong actually, and have the user manually fiddle with the bus.\nDevice tree changes To control the chip, you’ll need to modify your board’s device tree—a description of its hardware for devices that don’t automatically enumerate—so that the kernel knows how to load the driver.\nThere are two ways to edit your device tree. Either you can manually edit the base tree, or use device tree overlays.\nDevice tree overlays On images/distributions which support device tree overlays in their build of u-boot and the device tree blobs, you can very simply write a device tree overlay. This means your base tree can still change as you update your OS, and there’s no manual intervention needed on your part to have your modification be carried forward.\nYour overlay will look something like this:\n/dts-v1/; /plugin/; \u0026amp;i2c3 { #address-cells = \u0026lt;1\u0026gt;; #size-cells = \u0026lt;0\u0026gt;; status = \u0026#34;okay\u0026#34;; pcf8574: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; ; You can compile it with dtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts, assuming your input file is called pcf8574.dts.\nInstalling the overlay depends on your distribution. On Plebian, see DT_OVERLAYS.md.\nIf you want to use constants and includes in your device tree overlay, you’ll need to pass the file through a C preprocessor with the appropriate include directories. For an example of a build system that does this, please consult the Makefile of CounterPillow’s overlay-examples repository.\nManually editing the base tree Important You will need to install dtc for this. The easiest way to go about this is to get a copy of the Linux kernel source code from https://kernel.org that matches your kernel version (uname -a), as the device tree definitions live in the Linux kernel repository. Technically, device trees should be compatible across kernel versions, but I wouldn’t gamble on it.\nOnce you have the kernel source, you can use your local configuration: run zcat /proc/config.gz \u0026gt; .config inside the top-level directory of the Linux kernel source tree to use your running kernel’s configuration. Then run make xconfig (or one of the other non-graphical alternatives, like nconfig or menuconfig), save the configuration to set any new options to their default values, and then also ensure that CONFIG_GPIO_PCF857X (a.k.a. \u0026ldquo;PCF857x, PCA{85,96}7x, and MAX732[89] I2C GPIO expanders\u0026rdquo;) is either set to \u0026ldquo;M\u0026rdquo; or \u0026ldquo;Y\u0026rdquo;.\nIn arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dts, add the following section:\n\u0026amp;i2c3 { status = \u0026#34;okay\u0026#34;; pcf8574: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; ; This lets the kernel know that there’s a PCF8574 hanging off the third I^2^C controller, and is listening on slave address 0x20 (decimal: 32). Be sure to use tabs of size 8 for the indentation, this is the style the kernel uses.\nNow run make dtbs to compile the device tree. This should give you a arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dtb***, which you can then copy into your /boot/dtbs/ as for example quartz-with-pcf8574.dtb* or something like that. Then, in your extlinux.conf*, either add a new boot label or modify your existing boot labels FDT line to point towards this dtb file, with the path being relative to */boot and not to /.\nDaisy chaining As previously stated, you can hook up multiple of these modules onto the same bus. Here’s how the device tree changes for this will look like:\n\u0026amp;i2c3 { status = \u0026#34;okay\u0026#34;; pcf8574_1: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; pcf8574_2: pcf8574@21 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x21\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; ; Notice how the labels (the part before the colon) have been differentiated, and the address (number after the @ and number in the reg field) has changed for the second module.\nNote be sure to change the A0, A1 and A2 pins accordingly to set the addresses of the daisy chained modules! For example, for the second module, pull A0 high and leave A1 and A2 low. The address pins work like a binary counter, so 000 -\u0026gt; 001 -\u0026gt; 010 -\u0026gt; 011 -\u0026gt; 100 -\u0026gt; \u0026hellip; Interrupts The PCF8574 will pull its INT pin low when one of its inputs changed. We can use this to generate an interrupt:\n\u0026amp;i2c3 { status = \u0026#34;okay\u0026#34;; pcf8574: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; interrupt-parent = \u0026lt;\u0026amp;gpio0\u0026gt;; interrupts = \u0026lt;RK_PC1 IRQ_TYPE_EDGE_FALLING\u0026gt;; interrupt-controller; #interrupt-cells = \u0026lt;2\u0026gt;; }; ; In this case, we use GPIO0 Pin C1 (RK_PC1 with interrupt-parent gpio0), a.k.a. UART0_TX, a.k.a. pin 12, as the interrupt pin. (Note: You cannot use pin 7 here, as it’s pulled high.)\nTo know which RK_PXX and which interrupt-parent correspond to which pin on the board, consult the schematics.\nHooking up the module Hook up SDA to pin number 3 of your board, and SCL to pin number 5. Connect GND to ground, e.g. pin number 9, and VCC to 3.3V, for example pin number 1. If you plan on using interrupts, connect the INT pin to whichever GPIO you defined as the interrupt pin.\nTODO: Put photo of hooked up module here.\nUsing the GPIOs Upon booting your board with your modified device tree blob, you should have an additional /dev/gpiochip__ device, most likely /dev/gpiochip5. You can verify this by running libgpiod’s gpioinfo utility, which should now show you an additional GPIO chip with only 8 lines.\ngpiochip5 - 8 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high line 5: unnamed unused input active-high line 6: unnamed unused input active-high line 7: unnamed unused input active-high If you are daisy-chaining the modules, you’ll see an additional gpiochip with 8 lines for each additional module.\nTesting the pins as outputs To test whether this is working, you can connect an LED between a pin (in this example, 4) of your PCF8574, and ground. Then (assuming your chip number is 5) you can use sudo gpioset -B pull-down 5 4=0 to turn off the pin and set its bias mode to be pulled down, and use sudo gpioset 5 4=1 to turn it on and sudo gpioset 5 4=0 to turn it off. Connecting an LED with no resistor in-line should be fine because the pins deliver like 100mA current at most.\nProgrammatically driving the pins TODO: Expand this section with how to control the pins programmatically using libgpiod or whatever.\nAdding a button to send a key code In this example, we’re adding a button that’s hooked between the input pin 0 and ground, and making it type W whenever it’s pressed.\n/ { ... *keyboard {* *compatible = \u0026#34;gpio-keys\u0026#34;;* *w_key {* *gpios = \u0026lt;\u0026amp;pcf8574 0 GPIO_ACTIVE_LOW\u0026gt;;* *linux,code = \u0026lt;17\u0026gt;;* *label = \u0026#34;W_KEY\u0026#34;;* *};* };* ... ; The label here isn’t the defining bit but the input event code is. 17 is for W. You can also include the header file on top and use the symbol name KEY_W\nNote that you will need to have your PCF8574 set up with interrupts for this.\nAccessories Quartz64 Premium Aluminium Case\nQuartz64 Premium Aluminium Case A nice aluminum case is available for the Quartz64 on the PINE64 store listed as \u0026ldquo;ROCKPro64 PREMIUM ALUMINUM CASING\u0026rdquo;.\nThe Quartz64 model A can be made to fit this case, however some filing of one of the holes is necessary because one of the RockPro64 ports is a type-C, whereas on the Quartz64 model A all of the ports are type As.\nInterference between Quartz64 model A and the case as supplied:-\nFitment once the case has been filed:-\nFitment of the other end (no modification necessary):-\nAlso note that the SoC in the Quartz64-A is slightly lower than the Rock64 Pro one (apparently about 0.6mm). This case includes an internal post which (using a thermal pad) touches the SoC to transfer heat from the SoC to the case. However it does not make good contact with the RK3566. The best solution is probably to source a thicker thermal pad.\nEnclosures Note: Please expand this section with more cases known to work.\nModel \u0026ldquo;A\u0026rdquo; All enclosures that fit the ROCKPro64 should fit the Quartz64 Model \u0026ldquo;A\u0026rdquo;, as the I/O has been laid out the same on purpose.\nModel A Acrylic Open Enclosure - but see the troubleshooting section below. RockPro64 Premium Aluminium Case ROCKPro64 (Not an enclosure but allows to mount the board in an ATX/ITX case) Model \u0026ldquo;B\u0026rdquo; Model B Acrylic Open Enclosure the ROCK64 aluminium enclosure does not work, as the DC input jack is placed differently Further information Datasheets\nSchematics and certifications\nSpecifications\nDatasheets Rockchip RK3566 SoC information:\nRockchip RK3566 ver 1.0 datasheet, already got release permission from Rockchip Rockchip RK3566 and RK3568 TRM (Technical Reference Manual) Rockchip PMU (Power Management Unit) Information:\nRockchip RK817 ver 1.01 datasheet for Quartz64 model A Rockchip RK809 ver 1.01 datasheet for Quartz64 model B and SOQuartz LPDDR4 (200 Balls) SDRAM:\nMicron LPDDR4 Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet E-ink Panel information:\nEink 10.3\u0026quot; 1872x1404 ES103TC1 Flex Panel Specification Eink 10.3\u0026quot; 1872x1404 ES103TC1 Glass Panel Specification TPS65185x PMIC for E-Ink Enabled Electronic Paper Display Datasheet LCD Touch Screen Panel information:\n7.0\u0026quot; 1024x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver Wi-Fi/BT module info:\nAzurewave CM256SM 11AC Wi-Fi + Bluetooth 5.0 datasheet for model A and B AICSemi AIC8800DC 11AX Wi-Fi + Bluetooth 5.2 datasheet for model \u0026ldquo;Zero\u0026rdquo; IR LED:\nIRM-3638 Datasheet Enclosure information:\nPlaybox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing 3D Printable Enclosure for Model A Open Frame for Model A Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port (Model A) 1.25mm Picoblade Type connector specification used in RTC Battery port (Model B) 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port Schematics and certifications Model \u0026ldquo;A\u0026rdquo; Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm\nInput Power: DC 12V @ 3A 5.5mmOD/2.1mmID center-positive Barrel DC Jack connector\nQuartz64 Model \u0026ldquo;A\u0026rdquo; SBC Schematic and PCB Board Resource:\nQuartz64 Model \u0026ldquo;A\u0026rdquo; SBC Schematic ver 2.0 20210427 PDF file Quartz64 Model \u0026ldquo;A\u0026rdquo; SBC PCB Connector placement PDF file Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submit the SBC for FCC and CE certification and obtain the certificates to proof that SBC board is capable on passing the testing. Please note a final commercial product needs to performs its owns testing and obtains its owns certificates. Quartz64 model-A CE Certificate Quartz64 model-A FCC Certificate Model \u0026ldquo;B\u0026rdquo; Model \u0026ldquo;B\u0026rdquo; Baseboard Dimensions: 85mm x 56mm x 18.8mm\nInput Power: DC 5V @ 3A 3.5mmOD/1.35mmID center-positive Barrel DC Jack connector\nQuartz64 Model \u0026ldquo;B\u0026rdquo; SBC Schematic and PCB Board Resource:\nQuartz64 Model \u0026ldquo;B\u0026rdquo; SBC Schematic ver 1.3 20220124 PDF file Quartz64 Model \u0026ldquo;B\u0026rdquo; SBC PCB Connector placement PDF file Please note that v1.2 and V1.3 schematic and component placement are identical, just some component value changed. Note: Model B uses a Molex PicoBlade compatible connector for the RTC battery. The Pine64 Backup Battery Holders come with a JST PH type connector. To use the Pine64 RTC Backup Battery Holder, the connector on the battery holder will need to be modified with a PicoBlade type connector. Model \u0026ldquo;Zero\u0026rdquo; Model \u0026ldquo;Zero\u0026rdquo; Baseboard Dimensions: 85mm x 56mm x 18.8mm\nInput Power: DC 5V @ 3A 3.5mmOD/1.35mmID center-positive Barrel DC Jack connector\nQuartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC Schematic and PCB Board Resource:\nQuartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC Schematic ver 1.0 20240428 PDF file Quartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC PCB Component placement (top side) PDF file Quartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC PCB Component placement (bottom side) PDF file Specifications Based on Rockchip RK3566 CPU Architecture Quad-core ARM Cortex-A55@1.8GHz AArch32 for full backwards compatibility with ARMv7 ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation Includes VFP hardware to support single and double-precision operations ARMv8 Cryptography Extensions Integrated 32KB L1 instruction cache and 32KB L1 data cache per core 512KB unified system L3 cache TrustZone technology support 22nm process, believed to be FD-SOI GPU (Graphics Processing Unit) Capabilities Mali-G52 2EE Bifrost GPU@800MHz 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop 128KB L2 Cache configurations Supports OpenGL ES 1.1, 2.0, and 3.2 Supports Vulkan 1.0 and 1.1 Supports OpenCL 2.0 Full Profile Supports 1600 Mpix/s fill rate when at 800MHz clock frequency Supports 38.4 GLOP/s when at 800MHz clock frequency NPU (Neural Processing Unit) Capabilities Neural network acceleration engine with processing performance of up to 0.8 TOPS Supports integer 8 and integer 16 convolution operations Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet System Memory RAM Memory Variants: 2GB (SOQuartz only), 4GB, 8GB LPDDR4. Network 10/100/1000Mbps Ethernet Wi-Fi 802.11 b/g/n/ac with Bluetooth 5.0 (optional on model A, built in on model B) Storage microSD - bootable, supports SDHC and SDXC, storage up to 2TB USB Model A: 2 USB 2.0 host ports, 1 USB 2.0 OTG port, 1 USB 3.0 host port Model B: 1 USB 2.0 host port, 1 USB 2.0 OTG port, 1 USB 3.0 host port one native SATA 3.0 6Gb/s Port (only on model A, shared with USB 3.0 host port) (removed in newer revisions due to electrical signalling issues it caused) optional eMMC module from 8GB up to 128GB 64 Mbit (8 MByte) SPI flash (Model B only), part number 25Q64DWZPIG in the schematic eMMC Speeds On a 64 GB eMMC module:\n$ sudo hdparm -tT /dev/mmcblk1 /dev/mmcblk1: Timing cached reads: 2368 MB in 2.00 seconds = 1184.46 MB/sec Timing buffered disk reads: 452 MB in 3.01 seconds = 149.98 MB/sec Expansion Ports HDMI eDP - 4 lanes of 2.7Gbps, up to 2560x1600@60Hz (only on model A) DSI - Display Serial Interface, 4 lanes MiPi, up to 1440P on model A, 2 lanes MiPi, up to 1080p on model B CSI - CMOS Camera Interface, 4 lanes MiPi up to 8 mega pixel on model A, 2 lanes MiPi up to 5 mega pixel on model B TP - Touch Panel Port, SPI with interrupt on model A RTC - Real Time Clock Battery Connector VBAT - Lithium Battery Connector with temperature sensor input on model A Wi-Fi/BT Module Header - SDIO 3.0 and UART on model A, built-in Wi-Fi/BT Module on model B 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header on model B, 2x10 pins GPO header on model A PCIe x4 open ended slot on model A, m.2 slot on model B, one Gen2 lane due to SoC constraints On Model A, the slot provides 10W of power for the 3.3V supply and however much power your 12V input power supply provides on the 12V supply The PCIe implementation on the RK3566 is much more compatible with a wide range of devices compared to the one on the RK3399 used on the ROCKPro64. This means a lot more devices should work (excluding dGPUs due to a lack of cache snooping ability).\nCombo PHYs Several of the I/O options on the RK3566 used in the Quartz64 are using the same I/O lines, meaning that they cannot be used at the same time. The above diagram illustrates how they are connected.\nIn particular, USB 3.0 and the SATA connector on the board are mutually exclusive, and the PCI-e 2.0 lane can be reconfigured into a second SATA port, though an adapter cable needs to be fashioned for this to be useful.\nGPIO Pins (Quartz64 Model A) Attention! GPIOs are 3.3V!\nAssigned To Pin no. Pin no. Assigned To 3.3 V 1 2 5 V I2C3_SDA_M0 a,b 3 4 5 V I2C3_SCL_M0 a,b 5 6 GND CPU_REFCLK_OUT 7 8 UART2_TX_M0_DEBUG GND 9 10 UART2_RX_M0_DEBUG SPI1_MOSI_M1 11 12 UART0_TX a SPI1_MISO_M1 13 14 UART0_RX a SPI1_CLK_M1 15 16 GND SPI1_CS0_M1 17 18 SPDIF_OUT c GND 19 20 3.3V Notes a: can be a PWM pin\nb: pulled high to 3.3V through 2.2kOhm resistor\nc: low-pass filtered with cutoff of 220 MHz\nSource: Page 28 of the board schematics.\nGPIO Pins (Quartz64 Model B) Attention! GPIOs are 3.3V!\nInteresting alternate pin configurations are listed in [brackets].\nAssigned To Pin no. Pin no. Assigned To 3.3 V 1 2 5 V [I2C3_SDA_M0] GPIO1_A0_3V3 3 4 5 V [I2C3_SCL_M0] GPIO1_A1_3V3 5 6 GND GPIO3_C4_3V3 7 8 UART2_TX GND 9 10 UART2_RX [SPI1_CS0_M1] GPIO3_A1_3V3 11 12 GPIO3_A3_3V3 [I2S3_SCLK_M0] [I2S3_MCLK_M0] GPIO3_A2_3V3 13 14 GND GPIO3_B0_3V3 15 16 GPIO3_B1_3V3 3.3V 17 18 GPIO3_B2_3V3 GPIO4_C3_3V3 19 20 GND GPIO4_C5_3V3 21 22 GPIO3_C1_3V3 [SPI1_MOSI_M1] GPIO4_C2_3V3 23 24 GPIO4_C6_3V3 GND 25 26 GPIO4_D1_3V3 I2C4_SDA_M0 27 28 I2C4_SCL_M0 GPIO3_B3_3V3 29 30 GND GPIO3_B4_3V3 31 32 GPIO3_C2_3V3 [SPI1_MISO_M1] [SPI1_CLK_M1] GPIO3_C3_3V3 33 34 GND [I2S3_LRCK_M0] GPIO3_A4_3V3 35 36 GPIO3_A7_3V3 [SPDIF_TX_M0] GPIO1_A4_3V3 37 38 GPIO3_A6_3V3 [I2S3_SDI_M0] GND 39 40 GPIO3_A5_3V3 [I2S3_SDO_M0] Source: Page 24 of the board schematics.\n","permalink":"/documentation/Quartz64/_full/","tags":null,"title":"Quartz64 (Single Page)"},{"categories":["SBCs"],"contents":" Quartz64 Model A: A 64-bit Quad Core SBC with USB 3.0, Gigabit Ethernet, PCIe x4, and up to 8GBs of LPDD4 RAM The Quartz64 Model A is powered by a Rockchip RK3566 quad-core ARM Cortex A55 64-Bit Processor with a Mali G-52 GPU. It comes equipped with 2GB, 4GB or 8GB LPDDR4 system memory, and a 128Mb SPI boot flash. There is also an optional eMMC module (up to 128GB) and a microSD slot for booting. The board is also equipped with 1x USB 3.0 type A Host, 3x USB 2.0 Host, Gigabit Ethernet, Sata, PCIe, an E-ink interface, touch panel interface, a 40 pin GPIO bus, MiPi DSI interface, MiPi CSI interface, optional 802.11 b/g/n/ac Wifi and Bluetooth 5.0, eDP interface, and other interfaces such as UART, SPI, and I2C are also available for makers to integrate sensors and other peripherals. Many different operating systems are freely available from the open source community, such as Linux (Ubuntu, Debian, Arch, etc), *BSD, and Android.\nFeatures and Specifications SoC 4 x ARM Cortex A55 cores @ 2.0GHz GPU ARM Mali G52 MP2 GPU Memory LPDDR4 RAM (up to 8GB) Networking Gigabit Ethernet Storage Micro SD slot eMMC module slot SPI Flash 128Mbit Connections 4K digital video out 2x USB 2.0 Host 1x USB 3.0 Host PCIe 4x Open-Ended slot (PCIe 2.0 1x electrically) 2×10 GPIO pins Optional WiFi 802.11ac with Bluetooth 5.0 expansion module Touch Panel (TP) port Display Serial Interface (DSI) port eDP port E-ink interface Camera Serial Interface (CSI) port (supports 8MP sensor) Real Time Clock (RTC) port Lithium battery port 3.5mm headphone jack with mic input 12V 3A or 5A (M 5.5mm OD/2.1mm ID) barrel port Efficient and Powerful Powerful Mali G52 GPU and efficient quad A55 cores\nPCIe 4x slot A built-in PCIe slot allowing for a variety of accessories\nE-ink interface The Quartz64 A comes with a built-in E-ink interface\nPlenty of RAM The Quartz64 A comes with up to 8GB of LPDDR4 RAM\nStores Global: 4GB Global: 8GB Global: Accessories Affiliates Documentation Quartz64 Schematics and certifications ","permalink":"/devices/quartz64_model_a/","tags":null,"title":"Quartz64 Model A"},{"categories":["SBCs"],"contents":" Quartz64 Model B: A 64-bit Quad Core SBC with M.2, USB 3.0, Gigabit Ethernet, Integrated Wi-Fi/BT, and up to 8GB of LPDDR4 RAM The Quartz64 Model B is the most recent Single Board Computer offering from PINE64. It is powered by a Rockchip RK3566 quad-core ARM Cortex A55 64-Bit Processor with a Mali G-52 GPU. It comes equipped with 2GB, 4GB or 8GB LPDDR4 system memory, and a 128Mb SPI boot flash. There is also an optional eMMC module (up to 128GB) and a microSD slot for booting. The board is equipped with 1x USB 3.0 type A Host, 2x USB 2.0 Host, Gigabit Ethernet, a 40 pin GPIO bus, MiPi DSI interface, MiPi CSI interface, integrated 802.11 b/g/n/ac Wi-Fi and Bluetooth 5.0, as well as a single lane M.2 PCIe Gen2 slot. Many different operating systems are freely available from the open source community, such as Linux (Ubuntu, Debian, Arch, etc), *BSD, and Android.\nFeatures and Specifications SoC 4 x ARM Cortex A55 cores @ 2.0GHz GPU ARM Mali G52 MP2 GPU Memory LPDDR4 RAM (up to 8GB) Networking Gigabit Ethernet Storage Micro SD slot eMMC module slot SPI Flash 128Mbit Connections 4K digital video out 2x USB 2.0 Host 1x USB 3.0 Host M.2 slot (1x PCIe Gen2) 40 GPIO pins Built-in 802.11ac WiFi with Bluetooth 5.0 Display Serial Interface (DSI) port Camera Serial Interface (CSI) port (supports 5MP sensor) Real Time Clock Port (RTC) 3.5mm headphone jack with mic input 3.5mm barrel power (5V 3A) port Efficient And Powerful Powerful Mali G52 GPU and efficient quad A55 cores\nM.2 Slot A built-in M.2 slot allowing for additional fast storage\nBuilt-In Wireless Built-in 802.11ac Wi-Fi and Bluetooth 5\nPlenty Of RAM The Quartz64 B comes with up to 8GB of LPDDR4 RAM\nStores Global Global: Accessories Affiliates Documentation Quartz64 Schematics and certifications ","permalink":"/devices/quartz64_model_b/","tags":null,"title":"Quartz64 Model B"},{"categories":null,"contents":"A nice aluminum case is available for the Quartz64 on the PINE64 store listed as \u0026ldquo;ROCKPro64 PREMIUM ALUMINUM CASING\u0026rdquo;.\nThe Quartz64 model A can be made to fit this case, however some filing of one of the holes is necessary because one of the RockPro64 ports is a type-C, whereas on the Quartz64 model A all of the ports are type As.\nInterference between Quartz64 model A and the case as supplied:-\nFitment once the case has been filed:-\nFitment of the other end (no modification necessary):-\nAlso note that the SoC in the Quartz64-A is slightly lower than the Rock64 Pro one (apparently about 0.6mm). This case includes an internal post which (using a thermal pad) touches the SoC to transfer heat from the SoC to the case. However it does not make good contact with the RK3566. The best solution is probably to source a thicker thermal pad.\n","permalink":"/documentation/Quartz64/Accessories/Premium_aluminium_case/","tags":null,"title":"Quartz64 Premium Aluminium Case"},{"categories":["SBCs"],"contents":" Quartz64-Zero The Quartz64-Zero SBC is featuring the Rockchip RK3566T SoC in a smaller PCB form factor. This SoC combines a quad-core, ARM Cortex-A55 1.6GHz CPU with a Mali-G52-2EE GPU. It is capable of driving a single 4K display at 60fps and the GPU uses the open source Panfrost driver. It also has the benefit of running very cool, even without a heatsink and under a sustained load. This SBC is equipped with 1GB LPDDR4 system memory, an optional eMMC module (up to 128GB) and microSD slot for booting. The board is equipped with a Wifi/BT with flex antenna, a custom PCIe connector, an USB 3.0 type A host port, as well as many other peripheral device interfaces such as UART, SPI, I2C, for makers to integrate with sensors and other peripherals.\nThe Quartz64-Zero is a low cost board suitable for various commercial project application and guarantee supply at least until year 2028. Commercial order can customize the Quartz64-Zero board (without PCB change request) per their requirement (such as different DRAM Capacity, on-board eMMC, staff Ethernet Port) and MoQ:2000 apply.\nNote: Power Adapter requirement: 5V 3A type H 3.5mm OD/1.35mm ID barrel type DC Jack Power Supply\nFeatures and Specifications CPU QUAD 64-bit ARM Cortex-A55 CPU Embedded 32-bit RISC-V CPU Memory 1GB LPDDR4 System Memory optional eMMC module (up to 128GB) microSD slot Display interface 4Kp60 10 bit Digital Video port Communication 802.11 B/G/N/AX Wi-Fi Bluetooth 5.4 Expansion 1x native USB 3.0 Host Port Custom PCIe Connector GPIO bus 40 pins including i2c, SPI and UART Stores Global Global: Accessories Affiliates Documentation Quartz64 Schematics and certifications ","permalink":"/devices/quartz64-zero/","tags":null,"title":"Quartz64-Zero"},{"categories":["SBCs"],"contents":" A QuartzPro64 Development page before a QuartzPro64 page? It’s more likely than you think!\nStores Global Affiliates Documentation QuartzPro64 ","permalink":"/devices/quartzpro64/","tags":null,"title":"QuartzPro64"},{"categories":null,"contents":" The QuartzPro64 development board, front side\nBack side of the board\nA QuartzPro64 page before a QuartzPro64 release? It’s more likely than you think!\nThis page will be used for both documenting the current development efforts and the board in general, as we don’t know yet how a generally available QuartzPro64 will look like so documenting the dev board is probably best left to the development page.\nUpstreaming status Upstream Linux kernel DT: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts Upstream U-Boot DT: https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi Function Status Component Notes Video Output Needs porting VOP2 Collabora said they’ll work on this. The video output IP on the RK3588 should mostly be the same as the one on the RK356x, but the chip specific stuff will need to be integrated into the vop2 driver. Video Input Needs porting rk_hdmirx Huge 3600 line driver, but generally seems to be in good condition 3D Acceleration Needs writing Needs writing panfrost Collabora said they’ll work on this. New architecture, reportedly needs many changes to the kernel component of Panfrost. Video Decode Needs writing GStreamer only, no ffmpegSource hantro using v4l2-requests VDPU121 handling 1080p60 H.263/MPEG-4, MPEG-1 and MPEG-2 Needs writing rkvdec2 using v4l2-requests Nobody is known to be working on this for now. VDPU346 handling 8K60 H.265, H.264, VP9 and AVS Needs writing rkdjpeg using v4l2-requests User:CounterPillow is doing a little work on this. VDPU720 handling JPEG In reviewSource hantro using v4l2-requests Collabora is working on this. VDPU981 handling 4K60 AV1 Video Encode Needs writing GStreamer only JPEG on VEPU121 Driver already exists, only minor changes needed. Needs writing ? H.264 on VEPU580 Needs writing ? H.265 on VEPU580 Audio Linux Mainline rockchip-i2s-tdm As of 6.2Source CRU Linux Mainline clk-rk3588 As of 6.2Source MMC Linux Mainline sdhci-of-dwcmshc As of 5.19Source pinctrl Linux Mainline pinctrl-rockchip As of 5.19Source GPIO Linux Mainline rockchip-gpio As of 6.1Source I2C Linux Mainline rk3x-i2c Should be the same as RK3399, just needs devicetree work SPI Linux Mainline rockchip-spi Should be the same as previous SoCs, just needs devicetree work PMU In reviewSource rk806 Talks over SPI Regulators Needs porting rk860 Talks over I2C GMAC Linux Mainline dwmac-rk As of 6.1Source Power Domains Linux Mainline rockchip-pm-domain As of 6.1Source CAN Needs porting rockchip_canfd Not broken out on the QuartzPro64, so we probably won’t be the ones porting it SPDIF TX May need porting rockchip-spdif Genuinely just needs the compatible string added, I think, otherwise we’re all good. Not broken out on QuartzPro64 dev board SPDIF RX Needs porting rockchip-spdifrx Not broken out on QuartzPro64 dev board PCIe May need porting rockchip-dw-pcie Downstream driver and upstream are quite different, look into how much work actually needs doing. Seems to be the same controller as rk3568 so maybe none? NPU Needs porting/writing ? rockchip-rknpu USB 2.0 In reviewSource phy-rockchip-inno-usb2 Might have more factors than just the PHY USB 3.0 ? ? SATA Linux Mainline ahci-dwc Just needs the compatible added to the bindings, done here Thermal In reviewSource rockchip-thermal Wifi \u0026amp; Bluetooth ? ? HWRNG Needs porting rockchip-rng The code \u0026amp; DT work is easy to port \u0026amp; working RTC Linux Mainline hym8563 Should only need DT work (see here for an example) OTP In reviewSource rockchip-otp SARADC In reviewSource rockchip_saradc Hardware The SoC and RAM packages\nGeneral RK3588 SoC (8 cores: 4x A76 at 2.4 GHz + 4x A55 at 1.8 GHz) Mali G610MC4 GPU (4x Valhalla cores) 16 GB of LPDDR4X (SK hynix) 64 GB eMMC (Foresee, soldered) 1x USB-C (with video-alt mode) 1x USB-C (FTDI debug UART, FT232RL) 1x USB 3.0 2x USB 2.0 1x HDMI in 2x HDMI out 1x PCIe 3.0 slot (open-ended) 1x SD / TF card slot 2x SATA ports 2x Gigabit Ethernet (1x from SoC, 1x on PCIe, RTL8211F, RTL8111HS) 1x Wi-Fi \u0026amp; Bluetooth module (AMPAK Tech AP6275PR3) 2x SMA Antenna 2x MIPI DPHY 1x MIPI D/C PHY 1x MIPI CSI 1x PWM Fan header (four pins) 1x RTC battery socket (CR1220, 3 V, see QuartzPro64 board schematics PDF, page 21) 1x MIC (soldered) 1x audio output 3.5 mm jack DC 12 V power input Cooler The board comes with two cooler mounts, a 4-hole mount that appears to be spaced 55x55mm apart, and the ~60mm diagonal \u0026ldquo;northbridge heatsink\u0026rdquo; mount the ROCKPro64 and Quartz64 Model A uses.\nRK3588 is slightly (\u0026lt;1mm?) taller than the DRAM chips, use a thick enough thermal pad instead of thermal compound.\nUART Plug in the USB-C port labelled \u0026ldquo;DEBUG PORT\u0026rdquo; on the QP64 board to another computer with a USB-A-to-C cable.\nIt will show up as a FT232 USB Serial adapter in lsusb:\n$ lsusb Bus 005 Device 027: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC Baud rate is 1.5 mbauds or 1500000.\nEnsure you have the driver module loaded:\n. modprobe ftdi_sio . lsmod | grep ftdi_sio ftdi_sio 61440 0 usbserial 53248 1 ftdi_sio usbcore 290816 7 ftdi_sio,usbserial,xhci_hcd,usbhid,usbkbd,usbmouse,xhci_pci If the above is not working, check the required driver is supported by your kernel, using one of the following commands:\n$ zgrep FTDI_SIO /proc/config.gz CONFIG_USB_SERIAL_FTDI_SIO=m $ grep FTDI_SIO \u0026#34;/boot/config-$(uname -r)\u0026#34; CONFIG_USB_SERIAL_FTDI_SIO=m Using the dmesg command, you should see something like the following:\n[24784.535804] usb 5-3: new full-speed USB device number 3 using xhci_hcd [24784.710714] usb 5-3: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00 [24784.710723] usb 5-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [24784.710725] usb 5-3: Product: FT232R USB UART [24784.710727] usb 5-3: Manufacturer: FTDI [24784.710728] usb 5-3: SerialNumber: A10LLO86 [24784.723858] usbcore: registered new interface driver usbserial_generic [24784.723865] usbserial: USB Serial support registered for generic [24784.725286] usbcore: registered new interface driver ftdi_sio [24784.725295] usbserial: USB Serial support registered for FTDI USB Serial Device [24784.725348] ftdi_sio 5-3:1.0: FTDI USB Serial Device converter detected [24784.725368] usb 5-3: Detected FT232RL [24784.731685] usb 5-3: FTDI USB Serial Device converter now attached to ttyUSB0 Then you can get console output from the QP64 with, for example:\nscreen /dev/ttyUSB0 1500000 Mounting Holes Mounting holes are 3 mm in diameter, so standard standoffs can be used, preferably the 2.5 mm variant. See also the PCB layout PDF files, linked in the documentation section of the Resources page.\nThe height from the bottom of the PCB to the top of the USB ports as the tallest components is 18 mm, which can be used as a data point for selecting the suitable standoff length to place some acrylic top cover over the board. However, that doesn’t account for the heatsink that needs to be mounted on the RK3588 SoC, for which a suitable rectangular hole can be cut in the top cover.\nStorage The eMMC on the dev board\nSoldered 64 GB FORESEE eMMC chip, which comes pre-flashed with some Android build One microSD card slot Two SATA 3.0 ports (standard Molex power connector is not populated) Power Power switch \u0026amp; barrel connector\nYou can provide power to the board via the 12V barrel connector, it’s 5.5mm OD/2.1mm ID barrel \u0026lsquo;coaxial\u0026rsquo; type \u0026ldquo;M\u0026rdquo; centre-positive, the ROCKPro64 5A power supply from the PINE64 store will work. (TODO: add alternative ways).\nThere is a hardware flip switch to power up / down the board.\nPMU The PMU\n2x RK806-2, not RK808 compatible. It’s a dual PMU configuration where one PMU is a subordinate of the other.\nVerify this once we have access to SDK sources.\nEthernet The RGMII ethernet port (near the SDCARD socket) is working if you use neg2led’s linux-quartz64 repo.\nThe other port (near the sound jack) is hooked to the SoC via PCIe and is currently reported working (on the matrix channel) with latest neggles kernel.\nBoot The board can boot from the following interfaces:\nSPI eMMC SD/MMC TODO: in which priority / order are those boot options tried ?\nTODO: Add unbricking informations (for example: can the SPI be rewritten with rkdeveloptool)\nTODOs Enable cpufreq Stuff Current neggles kernel has the CPU at 1.2 GHz, apparently SRE has patches to enable cpufreq? (see in Resources)\nAdd RK3588 Support To VOP2 VOP2 IP on the RK3588 is very similar to the one on the RK356x, but it still needs platform specific code added.\nWays to do things Using rkdeveloptool Use the PINE64 fork of rkdeveloptool.\nConnect a USB-C cable to the \u0026ldquo;DEBUG PORT\u0026rdquo; USB-C port, and a second to the \u0026ldquo;DOWNLOAD\u0026rdquo; USB-C port. Cable direction for the latter matters, so if it doesn’t show up after entering download mode, try rotating the USB-C connector to the other side.\nTo enter rockusb mode, interrupt the boot by holding the \u0026ldquo;V+/REC\u0026rdquo; on-board button or mashing Ctrl+C very quickly on the serial comms, then type download.\n$ rkdeveloptool list should now show you the device somewhat like this:\n$ rkdeveloptool list DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=204 Loader Important Note: If you receive an error about being unable to create the comms object in the following steps, make sure you have the udev rules installed with CounterPillow’s RK3588 device id patch, install them to /etc/udev/rules.d/ and udevadm control --reload Now, we can e.g. show the partitions on the eMMC:\n$ rkdeveloptool list-partitions # LBA start (sectors) LBA end (sectors) Size (bytes) Name 00 8192 16383 4194304 security 01 16384 24575 4194304 uboot 02 24576 32767 4194304 trust 03 32768 40959 4194304 misc 04 40960 49151 4194304 dtbo 05 49152 51199 1048576 vbmeta 06 51200 133119 41943040 boot 07 133120 329727 100663296 recovery 08 329728 1116159 402653184 backup 09 1116160 1902591 402653184 cache 10 1902592 1935359 16777216 metadata 11 1935360 1937407 1048576 baseparameter 12 1937408 8310783 3263168512 super 13 8310784 120831935 57610829824 userdata You can now use rkdeveloptool write-partition partitionname yourfile to overwrite one of the eMMC partitions.\nU-Boot and kernel on SD, RootFS on eMMC This is the setup User:CounterPillow currently uses. In short, you’ll need a vendor U-Boot on your SD card, with a boot partition on it that contains your extlinux.conf, device tree and kernel.\nSetting up the SD card Assuming your SD card is /dev/sdX, partition as e.g. follows:\n# parted -s /dev/sdX mklabel gpt # parted -s /dev/sdX mkpart loader 64s 8MiB # parted -s /dev/sdX mkpart uboot 8MiB 16MiB # parted -s /dev/sdX mkpart env 16MiB 32MiB # parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB # increase size as you wish # parted -s /dev/sdX set 4 boot on Flash SPL and u-boot:\n# dd if=rk3588_spl_loader_v1.06.109.bin of=/dev/sdX1 # dd if=uboot.img of=/dev/sdX2 Then make the filesystem:\n# mkfs.vfat -n \u0026#34;efi\u0026#34; /dev/sdX4 Mount it to e.g. /mnt/sdcardboot:\n# mount /dev/sda4 /mnt/sdcardboot Put the following in /mnt/sdcardboot/extlinux/extlinux.conf:\ndefault l0 menu title QuartzPro64 Boot Menu prompt 0 timeout 50 label l0 menu label Boot Jank Kernel SDMMC linux /jank fdt /dtbs/rockchip/rk3588-evb1-v10.dtb append earlycon=uart8250,mmio32,0xfeb50000 console=ttyS2,1500000n8 root=/dev/mmcblk0p14 rw rootwait Copy your kernel to /mnt/sdcardboot/jank and your DTB to /mnt/sdcardboot/dtbs/rockchip/rk3588-evb1-v10.dtb.\nUnmount it, we’re done with the SD card.\nCreating the root file system First, allocate a file the size of your desired root partition (larger sizes will take longer to transfer, don’t make the same mistakes as CounterPillow did), here we choose 16G:\n$ fallocate -l 16G rootpart.bin then, make the filesystem on it. CounterPillow went for ext4 because nobody has ever been fired for using ext4:\n$ mkfs.ext4 rootpart.bin Now mount it:\n# mount rootpart.bin /mnt/emmc-root Now we’ll download the Arch Linux ARM generic rootfs tarball and go to town:\n$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} $ curl \u0026#39;https://keyserver.ubuntu.com/pks/lookup?op=get\u0026amp;search=0x68b3537f39a313b3e574d06777193f152bdbe6a6\u0026#39; | gpg --import=- # in case you\u0026#39;re lacking the key $ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig # don\u0026#39;t you dare skip this # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/emmc-root # notice that this is run as root Then we just need to edit fstab. Get the UUID (not PARTUUID) from lsblk:\n$ lsblk -o NAME,SIZE,MOUNTPOINTS,UUID and put it in /mnt/emmc-root/etc/fstab as follows:\nUUID=_root-uuid-here_ / ext4 defaults 0 1 Unmount /mnt/emmc-root, we’re done with it.\nFlashing the root file system with RockUSB Warning This will destroy whatever data is on that userdata partition. But you’re here to run Linux, not Android, right? Plug one USB-C cable into the debug UART port, the other into the download port. Yes you will need two USB-C cables (or A-to-C cables) for this, get over it.\nPlug in your board, reset it while hammering Ctrl+c on the debug UART until you get into a u-boot command line. Now enter the download command.\nIf your device doesn’t show up in lsusb or rkdeveloptool list command, pull out the download USB-C plug, rotate it axially by 180 Euler degrees, and plug it back in.\nNext, flash the partition. Depending on the size of it, this can take over an hour: $ rkdeveloptool write-partition userdata rootpart.bin\nBooting Unplug the download USB-C cable once done.\nPut the SD card in the board. Reset it. You can now boot and your rootfs on eMMC will be mounted and contains an ALARM userland.\nTo update kernels or the device tree, just shut down the board, take out the SD card, write a new kernel or dtb to it, and plug it back in. No more need for rkdeveloptool, yay.\nResources Kernel The linux-rockchip mailing list archives linux-rockchip patchwork neggles / neg2led’s mainline kernel repository with patches picked from the mailing list Sebastian Reichel’s (SRE) rk3588 branch Rockchip BSP kernel tree Collabora RK3588 integration branch Collabora Mainline Status Table Radxa kernel tree, for reference, a lot is happening here Misc The quartz64 and quartz-dev channels on the PINE64 chats (bridged IRC, Matrix, Discord and Telegram) PINE64 rkdeveloptool fork CounterPillow’s uboot-qp64 repository, used with the official rkbin repository Rockchip OpenSource wiki rockchiprs (rkdeveloptool replacement written in Rust) Documentation The documentation for the QuartzPro64 board and most of the documentation for the chips it uses hasn’t been publicly released yet, but if you do own a QuartzPro64 board, the users CounterPillow and Dsimic will happily provide the documentation to you for the research or development purposes, if you ask them in the PINE64 chat channels. We’ve got the following documents, some of which can also be found elsewhere on the Internet rather easily:\nRK3588 datasheet RK3588 technical reference manual (TRM), parts 1 and 2 RK3588 hardware design guide, machine translated to English from Chinese, and the original version in Chinese RK860 datasheet, including register descriptions RK806 datasheet, including register descriptions QuartzPro64 schematics QuartzPro64 PCB top layout QuartzPro64 PCB bottom layout AMPAK-Tech AP6275PR3 (Wi-Fi and Bluetooth module) datasheet AMPAK AP6275P (Wi-Fi and Bluetooth module) datasheet Recovery In the case you erase the eMMC and are unable to boot the board, you can use rkdeveloptool to recover the board. While you can use the Pine64 Fork, it is recommended to use cypheon’s Fork until some Pending PRs are merged in to resolve issues with larger files. This is important when working with the larger 64 GB eMMC on the QuartzPro64.\nWith rkdeveloptool installed, you will also need the rk3588_spl from rockchip to init the memory/flash when in maskrom mode. This can be downloaded from the rockchip-linux/rkbin repo.\nEntering maskrom can be done in a variety of ways:\nHold the maskrom button (little white button labelled \u0026ldquo;MASKROM\u0026rdquo; next to SATA socket) during powerup, OR Enter rockusb mode, and execute \u0026ldquo;rkdeveloptool reboot-maskrom\u0026rdquo;. Bork your eMMC and SD devices (how? erase?), in which case bootup will fallback to maskrom. Dumping the eMMC Boot the device into maskrom mode, and then verify rkdeveloptool can see the board. # rkdeveloptool list\nDevNo=1\tVid=0x2207,Pid=0x350b,LocationID=503\tMaskrom Once the board shows up, load the rk3588_spl you downloaded earlier, and verify that the eMMC can be seen.\n**# rkdeveloptool boot ./rk3588_spl_loader_v1.08.111.bin** Downloading bootloader succeeded. **# rkdeveloptool read-flash-info** Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 59000 MB Flash Size: 120832000 Sectors Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: Flash\u0026lt;0\u0026gt; You can now dump the eMMC using the read command. Note that first you have to calculate the eMMC size, which can be done using the output from the previous flash info command. You need to take the sector count, and times it by the sector size, to get the total number of bytes. So in the above example, 120832000*512 so the total flash size is 61865984000.\nUsing the calculated size, you can now dump the eMMC. Please note this will take 1-2 minutes.\n**# rkdeveloptool read 0x0 61865984000 ./quartzpro64_emmc_dump.bin** Read LBA to file (0%) ... Read LBA to file (100%) You now have a full dump of the entire eMMC (SHA256 62cb4ae8d02aeacccf231fa1d00087cdc74b599790a274569305693aa205318d). Note that you can also use the list-partitions and read-partition commands to dump specific partitions, but this only shows GPT partitions on the eMMC. Because of this, it will NOT include the spl_loader found in the first 4MB of the eMMC!\nFlasing the eMMC Boot the device into maskrom mode, and then verify rkdeveloptool can see the board. # rkdeveloptool list\nDevNo=1\tVid=0x2207,Pid=0x350b,LocationID=503\tMaskrom Once the board shows up, load the rk3588_spl you downloaded earlier, and verify that the eMMC can be seen.\n**# rkdeveloptool boot ./rk3588_spl_loader_v1.08.111.bin** Downloading bootloader succeeded. **# rkdeveloptool read-flash-info** Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 59000 MB Flash Size: 120832000 Sectors Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: Flash\u0026lt;0\u0026gt; You can now flash the device using either the write command, or write-partition command, depending on what you are trying to do. If you are looking to restore the entire eMMC from a backup you made, you would use the command below to accomplish this.\n**rkdeveloptool write 0 ./quartzpro64_emmc_dump.bin** ","permalink":"/documentation/QuartzPro64/_full/","tags":null,"title":"QuartzPro64 (Single Page)"},{"categories":null,"contents":"When you first get your Pinebook Pro and boot it up for the first time, it’ll come with Manjaro using the KDE desktop. The Pinebook Pro is officially supported by the Manjaro ARM project, and support can be found on the Manjaro ARM forums.\nOn first boot, it will ask for certain information such as your timezone location, keyboard layout, username, password, and hostname. Most of these should be self-explanatory. Note that the hostname it asks for should be thought of as the \u0026ldquo;codename\u0026rdquo; of your machine, and if you don’t know what it’s about, you can make something up (use a single word, all lower case, no punctuation, e.g. \u0026ldquo;pbpro\u0026rdquo;).\nAfter you’re on the desktop, be sure to update it as soon as possible and reboot after updates are finished installing. If nothing appears when you click on the Networking icon in your system tray to connect to your Wi-Fi, ensure the Wi-Fi privacy switch is not disabled.\n","permalink":"/documentation/Pinebook_Pro/Software/Quick_Start_Manjaro/","tags":null,"title":"Quick Start Manjaro"},{"categories":null,"contents":"The PineCube can be used as a recorder for loud noises. If you have a kernel that has the sound support (see the Sound Control section) then you can use it to make recordings when there is a noise above a certain threshold. The following script is a very simple example that uses the alsa-utils and the sox command to do this. You can use the noise-stats.txt file and some noise testing to figure out a good threshold for your camera.\n#!/bin/bash # Directory where the sound recordings should go NOISE_FILE_DIR=\u0026#34;/root/noises\u0026#34; # Threshold to use with the mean delta to decide to preserve the recording MEAN_DELTA_THRESHOLD=\u0026#34;0.002\u0026#34; # Sample length (in seconds) SAMPLE_LENGTH=\u0026#34;10\u0026#34; while : do stats=$(arecord -d \u0026#34;$SAMPLE_LENGTH\u0026#34; -f S16_LE \u0026gt; /tmp/sample.wav 2\u0026gt;/dev/null \u0026amp;\u0026amp; sox -t .wav /tmp/sample.wav -n stat 2\u0026gt;\u0026amp;1 | grep \u0026#39;Mean delta:\u0026#39; | cut -d: -f2 | sed \u0026#39;s/^[ ]*//\u0026#39;) ts=$(date +%s) if (( $(echo \u0026#34;$stats \u0026gt; $MEAN_DELTA_THRESHOLD\u0026#34; | bc -l) )); then mv /tmp/sample.wav \u0026#34;$NOISE_FILE_DIR/noise-$ts.wav\u0026#34; # TODO convert to mp3 fi rm -f /tmp/sample.wav echo \u0026#34;$ts $stats\u0026#34; \u0026gt;\u0026gt; noise-stats.txt done ","permalink":"/documentation/PineCube/Projects/Recorder_for_loud_noises/","tags":null,"title":"Recorder for loud noises"},{"categories":null,"contents":"In the case you erase the eMMC and are unable to boot the board, you can use rkdeveloptool to recover the board. While you can use the Pine64 Fork, it is recommended to use cypheon’s Fork until some Pending PRs are merged in to resolve issues with larger files. This is important when working with the larger 64 GB eMMC on the QuartzPro64.\nWith rkdeveloptool installed, you will also need the rk3588_spl from rockchip to init the memory/flash when in maskrom mode. This can be downloaded from the rockchip-linux/rkbin repo.\nEntering maskrom can be done in a variety of ways:\nHold the maskrom button (little white button labelled \u0026ldquo;MASKROM\u0026rdquo; next to SATA socket) during powerup, OR Enter rockusb mode, and execute \u0026ldquo;rkdeveloptool reboot-maskrom\u0026rdquo;. Bork your eMMC and SD devices (how? erase?), in which case bootup will fallback to maskrom. Dumping the eMMC Boot the device into maskrom mode, and then verify rkdeveloptool can see the board. # rkdeveloptool list\nDevNo=1\tVid=0x2207,Pid=0x350b,LocationID=503\tMaskrom Once the board shows up, load the rk3588_spl you downloaded earlier, and verify that the eMMC can be seen.\n**# rkdeveloptool boot ./rk3588_spl_loader_v1.08.111.bin** Downloading bootloader succeeded. **# rkdeveloptool read-flash-info** Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 59000 MB Flash Size: 120832000 Sectors Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: Flash\u0026lt;0\u0026gt; You can now dump the eMMC using the read command. Note that first you have to calculate the eMMC size, which can be done using the output from the previous flash info command. You need to take the sector count, and times it by the sector size, to get the total number of bytes. So in the above example, 120832000*512 so the total flash size is 61865984000.\nUsing the calculated size, you can now dump the eMMC. Please note this will take 1-2 minutes.\n**# rkdeveloptool read 0x0 61865984000 ./quartzpro64_emmc_dump.bin** Read LBA to file (0%) ... Read LBA to file (100%) You now have a full dump of the entire eMMC (SHA256 62cb4ae8d02aeacccf231fa1d00087cdc74b599790a274569305693aa205318d). Note that you can also use the list-partitions and read-partition commands to dump specific partitions, but this only shows GPT partitions on the eMMC. Because of this, it will NOT include the spl_loader found in the first 4MB of the eMMC!\nFlasing the eMMC Boot the device into maskrom mode, and then verify rkdeveloptool can see the board. # rkdeveloptool list\nDevNo=1\tVid=0x2207,Pid=0x350b,LocationID=503\tMaskrom Once the board shows up, load the rk3588_spl you downloaded earlier, and verify that the eMMC can be seen.\n**# rkdeveloptool boot ./rk3588_spl_loader_v1.08.111.bin** Downloading bootloader succeeded. **# rkdeveloptool read-flash-info** Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 59000 MB Flash Size: 120832000 Sectors Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: Flash\u0026lt;0\u0026gt; You can now flash the device using either the write command, or write-partition command, depending on what you are trying to do. If you are looking to restore the entire eMMC from a backup you made, you would use the command below to accomplish this.\n**rkdeveloptool write 0 ./quartzpro64_emmc_dump.bin** ","permalink":"/documentation/QuartzPro64/Recovery/","tags":null,"title":"Recovery"},{"categories":null,"contents":" Quick Links to the Source of OS Images Build There is a community effort to bring updated kernels, peripherals and buildroot - Lots of communication happening in the #ox64-nutcracker channel.\nbuildroot bringing all the work below together with a bootable kernel and updated filesystem images for SD cards U-Boot and OpenSBI work by Smauel Kernel IRQChip, SDCard, and (WIP) USB by arm000, Alexander Horner and others OpenBouffalo Firmware low_load drivers by Fishwaldo and others Original Linux Images provided by Bouffalo - Very basic alpha build which are only fit for board bring up and testing purposes.\nLinux for BL808 Installation Instructions for Linux on BL808 (Chinese) Installation Instructions for Linux on BL808 (machine-translated to English) Toolchain:\nelf_newlib_toolchain/bin/riscv64-unknown-elf-gcc (Xuantie-900 elf newlib gcc Toolchain V2.2.5 B-20220323) 10.2.0 linux_toolchain/bin/riscv64-unknown-linux-gnu-gcc (Xuantie-900 linux-5.10.4 glibc gcc Toolchain V2.2.4 B-20211227) 10.2.0 cmake version 3.19.3 Software Development Kits BL808 MCU SDK BLDevCube Flashing Tool for Windows, macOS and Ubuntu x64 Ox64 UART Flashing Guide, see the notes BL808 Demo Firmware: bl808_demo_event.bin, see the notes BL808 UART Log Firmware: whole_flash_data.bin, see the notes BL808 DVK Quick Start OpenSBI for BL808 Rust Peripheral Access Crate (PAC) for BL808 System View Description (SVD) for BL808 ","permalink":"/documentation/Ox64/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":" Sources There is a community effort to bring updated kernels, peripherals and buildroot - Lots of communication happening in the #ox64-nutcracker channel, see Community.\nNuttx Released Image by Lup Yuen Toolchain:\nelf_newlib_toolchain/bin/riscv64-unknown-elf-gcc (Xuantie-900 elf newlib gcc Toolchain V2.2.5 B-20220323) 10.2.0 linux_toolchain/bin/riscv64-unknown-linux-gnu-gcc (Xuantie-900 linux-5.10.4 glibc gcc Toolchain V2.2.4 B-20211227) 10.2.0 cmake version 3.19.3 Software Development Kits SG200x NPU TDL SDK Fishwaldo SG200x Debian Lup Yuen Apache NuttX RTOS ","permalink":"/documentation/Oz64/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"The following releases are for the PINE H64 Model B\nLinux Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://www.armbian.com/pine-h64-b/ DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the PINE H64 build on the PINE64 forum thread.\nDownload:\nTrixie image Default credentials root dietpi LibreELEC LibreELEC is a \u0026ldquo;Just enough OS\u0026rdquo; Linux distribution combining the Kodi media center with an operating system.\nDownload:\nStable builds (Look for LibreELEC-H6.arm-xx.x.x-pine-h64.img.gz) Notes:\nSupports microSD card and eMMC boot BSD FreeBSD FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms. To learn more about FreeBSD, please visit FreeBSD main page.\nInstructions:\nSee general information about FreeBSD on Allwinner ARM and specific details about creating a microSD card for the PINE H64 Notes:\nFreeBSD supports booting from the microSD card NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. To learn more about NetBSD please visit NetBSD main page.\nDownload:\nDirect download latest release build from NetBSD by select PINE H64 Notes:\nNetBSD supports booting from the microSD card Instructions concerning enabling SSH can be found here Default credentials root (root user and SSH) [none] ","permalink":"/documentation/PINE_H64_Model_B/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"This page contains a list of all available releases and tools for the Pinebook Pro.\nLinux OS Image Releases For information on how to install these images onto your device, please see the Getting started Page, which includes information on writing images to the device eMMC or an SD card\nArmbian Armbian is a base operating system platform for single board computers (SBCs) that other projects can trust to build upon. It is a lightweight Debian or Ubuntu based Linux distribution specialized for ARM development boards. Each system is compiled, assembled and optimized by the Armbian Build Tools. It has powerful build and software development tools to make custom builds and a vibrant community.\nDownload:\nThe Pinebook Pro Download Page Notes:\nIf you have any difficulties please visit our forum or come chat with us on IRC / Discord As of April 2023, Armbian only has Ubuntu images pre-made. However, using their tools to create a Debian image from scratch takes little expertise and results in an image that can be burned onto a USB stick or SD card. Their installer can then install it onto internal eMMC, including a working bootloader. Fedora Fedora Linux is a Linux distribution developed by the Fedora Project. It creates an innovative, free, and open source platform for hardware, clouds, and containers that enables software developers and community members to build tailored solutions for their users.\nInstallation:\nUsing this blog post it is possible to run Official Fedora on the Pinebook Pro Notes:\nUpstream Fedora uses the SPI flash on the Pinebook Pro to manage U-Boot. Arch Linux ARM Official Installation See Installing Arch Linux ARM for instructions on how to install the official Arch Linux ARM.\npostmarketOS Official postmarketOS stable builds are available for the Pinebook Pro with the following interfaces:\nconsole GNOME KDE Plasma Desktop Phosh Sway It boots from microSD card and from eMMC.\nDownload location\nGet the stable image here: https://postmarketos.org/download/ (size: 103 MB to 775 MB)\nThe installer images allows setting up an encrypted installation on SD or eMMC.\nUsername and password\nDefault credentials user 147147 Kali Linux Official pre-built OS images of Kali Linux for the Pinebook Pro featuring all tools you’d expect from the distribution. It boots from microSD card and from eMMC.\nDownload location\nGet the latest image here: Direct download latest images from Offensive Security’s website (size: 3.1 GB)\nUsername and password\nDefault credentials kali kali R-Cade Retro Center’s R-Cade [USB / microSD / eMMC Boot]\nThe 4K Media Center Arcade RCade Features 100+ retro-gaming systems, a lightweight web browser, and full 4K UHD media playback DD image to USB, microSD, or eMMC and boot. Highly recommend using Etcher Direct download from Retro Center’s GitHub Username and password\nDefault credentials root retro DietPi DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the Pinebook Pro build on the PINE64 forum thread.\nDownload:\nDirect download of Trixie from dietpi.com Default credentials root dietpi openSUSE Download location\nGet the latest openSUSE Tumbleweed images for Pinebook Pro here: https://en.opensuse.org/HCL:Pinebook-Pro-RK3399. Credits to https://bugzilla.opensuse.org/show_bug.cgi?id=1194491.\nStep 1. Flash Tow-Boot to SPI Step 2. Flash openSUSE image to sd card \u0026amp; insert it Step 3. When it loads grub, press e and add the following line: devicetree /boot/dtb/rockchip/rk3399-pinebook-pro.dtb\nPress ctrl + x to boot\nWorks: display, WiFi Not tested: bluetooth Doesn’t work: audio\nYou may build RPMs and see if it fix issues from this repository: https://github.com/bengtfredh/pinebook-pro-copr\nDefault password for root is \u0026ldquo;linux\u0026rdquo;\nVoid Linux Images Void Linux packages U-Boot and a kernel for the Pinebook Pro, but does not distribute any images for the device.\nCameron Nemo (User:CameronNemo) distributes unofficial Void Linux images for the Pinebook Pro:\nglibc download musl download Some notes about the images:\nThey were released on 2022-05-30 (glibc) and 2022-06-10 (musl) They ship U-Boot 2022.04 and Linux 5.15 (with minimal patches) Meant to be uncompressed then flashed to either an SD card or the internal eMMC module The root partition is ~1.7GB, and must be expanded manually There are very few services enabled on the images by default: udev and some getty’s Default credentials root voidlinux Do It Yourself Warning This is not an official, nor supported way of using Void Linux on the Pinebook Pro. You can also manually install Void from a rootfs tarball: see instructions here.\nBSD NetBSD The image boots from microSD card and from eMMC. To learn more about NetBSD please visit NetBSD main page\nDownload location\nGet the latest image here: Direct download from NetBSD\nInstallation\nInstructions concerning enabling SSH can be found here.\nUsername and password\nDefault credentials root none OpenBSD The image boots from microSD card and from eMMC. To learn more about OpenBSD, please visit OpenBSD main page\nDownload location\nARM64 images, (including support for Pinebook Pro), can be found here OpenBSD arm64\nLinux Installer Releases Armbian You can use the Armbian Builder to generate your own Armbian images of various types.\nThe builder supports building any version of Debian and any version of Ubuntu with various desktop options:\nBudgie Cinnamon Deepin Enlightenment Gnome I3-wm Kde-plasma Mate Xfce Xmonad Debian Uses only the upstream kernel and firmware without special patches Display doesn’t always work properly on first boot of installer, usually fixed after a couple tries Requires adding the non-free component to your /etc/apt/sources.list file and installing the \u0026ldquo;firmware-linux\u0026rdquo; package for Wi-Fi and Bluetooth support. If your Pinebook Pro was part of the June/July 2022 batch, then you will need the \u0026ldquo;firmware-brcm80211\u0026rdquo; to accommodate the changed networking hardware. You will also need \u0026ldquo;brcmfmac43455-sdio.txt\u0026rdquo; in /lib/firmware/brcm, at least until it is included within firmware-brcm80211 upstream. Installer is loaded into RAM, can install onto the same media from which it’s booted Supports automatic partitioning and full disk encryption through LVM Installer currently doesn’t install a functional bootloader, leaving the installed system in an unbootable state until it’s manually added (if installed to eMMC, the system cannot be booted even to an SD card unless the eMMC is physically switched off or there is U-Boot in the SPI) The relevant files are built daily here and may sometimes be unavailable if the build system is having issues. The \u0026ldquo;README.concatenateable_images\u0026rdquo; file provides instructions on how to combine the partition.img.gz file with the firmware.pinebook-pro.rk3399.img.gz file in order to create a DD-able image.\nThe official images are not recommended yet until the display begins working consistently and the installer properly installs the bootloader. Building a Debian-based image via the Armbian builder on the other hand seems to work with no changes. Previously the best tool was Daniel Thompson’s Debian Installer, but unfortunately as of April 2023 some of the upstream kernel sources this tool used seem to no longer exist.\nGentoo There is a script that prepares a Gentoo arm64 stage 3 tarball for the Pinebook Pro. Unfortunately, this script is not currently functional, and requires extensive troubleshooting to make work. New instructions are currently being created and will be available here.\nWord to the wise\nCurrently, following the instructions on the Pinebook pro gentoo github page will not result in a functional system. Therefore it is necessary to follow the instructions given here. Please bear in mind that the Pinebook pro’s six arm cores and 4gb of ram are extremely anemic. For example, emerging the package net-libs/webkit-gtk in order to build the minimalist web-browser \u0026ldquo;surf\u0026rdquo;, a process which takes eighty minutes on an intel core i5-8250U with 8gb of ram, required eight hours of compile time, Basic installation alone can take 24 hours of compilation, dozens of reboots, and hours of troubleshooting. After that, even installing firefox would take 17 hours. Now that that’s out of the way, we may begin the installation.\nPreparing the bootloader\nInstalling a functional bootloader can be difficult. Luckily, the tow-boot project provides a UEFI-like experience for some arm-based devices. Furthermore, it is not neccesary install this bootloader manually, as it will continue to be useable even after the disk has been reformatted, as long as the bootloader remains unscathed.\nhttps://manjaro.org/downloads/arm/pinebook-pro/arm8-pinebook-pro-minimal/\nNo-matter where you intend to install gentoo, the bootloader should always be installed on the eMMC flash, although technically the SD card slot could also be used. Either way, install any of the official Manjaro arm disk images to the internal eMMC (there’s no reason not to use the minimal image, as you will not be using this OS for anything). You may use a second operating system installed on an SD-card, or the official Pine64 eMMC USB adapter. Boot into this operating system to ensure that the bootloader functions, but after that you have no further need of it.\nNext, if you already have an OS on an SD card, you can use that for installing gentoo. If you don’t, you may be pleasantly surprised to find that tow-boot is capable of booting from a USB drive. Therefore, you may install the same Manjaro image to your USB drive or SD card, and select it from the boot menu. You should now have an unused but bootable OS on the eMMC, and another bootable, usable OS on your external storage.\nPreparing the Disks\nLog into your host device as root with the following command:\nsudo su\nEnter your password.\nLet the device on which you intend to install gentoo be referred to hereafter as /dev/. Use the following command to prepare this disk for installation:\nfdisk -B /dev/\u0026lt;gentoo\u0026gt;\nNote Don’t just copy these commands! You should substitute for mmcblk2 for the internal eMMC flash storage. Note that the first block of the boot partition is block 62500. Delete all partitions, but do not re-format the disk. Create a new boot partition starting at 62500, and as it’s size select \u0026ldquo;+1GB\u0026rdquo;. Create a new swap partition. fdisk will try to start it at the beginning of the volume (before the boot partition) Instead, when it prompts you for the starting position, enter in the end sector of the boot partition. It should then tell you that this is within an existing partition, and recommend a slightly higher value. Press enter, and give for the size of the partition any value greater than \u0026ldquo;+4gb\u0026rdquo;. You need this much ram to be able to suspend your system, and emerge large packages. Don’t be stingy - you still have SD cards. I recommend \u0026ldquo;+8gb\u0026rdquo;.\nFinally, add a root partition starting at the end sector of the swap partition, and use the rest of the disk for it. That should be 50-60 GB depending on the size of your swap and boot partitions.\nLastly, press \u0026ldquo;t\u0026rdquo; to set the type of each partition. You may set partition 1 to type 6, 2 to type 82, and 3 to type 83.\nto set the partition types of the three partitions.\nlsblk\nto remind yourself which disk is /dev/ Write the filesystems to these three partitions with the commands:\nmkfs.vfat /dev/\u0026lt;gentoo\u0026gt;p1 mkswap /dev/\u0026lt;gentoo\u0026gt;p2 mkfs.ext4 /dev/\u0026lt;gentoo\u0026gt;p3 This may be a slightly different format if you’re installing to an USB stick.\nInstallation\nmake the directory for mounting the filesystem you just created. These should be made on the external OS.\nmkdir /mnt/gentoo mount /dev/\u0026lt;gentoo\u0026gt;p3 /mnt/gentoo cd into this directory and fire up links. Navigate to gentoo.org/downloads and select the stage 3 minimal stage 3 tarball. Download it to your current directory, or move it to that directory from wherever it has been downloaded to. Once you are in the correct directory, unpack the tarball.\ntar xpvf stage3-arm64-\u0026lt;blah blah blah\u0026gt;\nMount the boot partition.\nmount /dev/\u0026lt;gentoo\u0026gt;p1 /mnt/gentoo/boot\nChroot into the mounted directory and Install the operating system as per the AMD64 manual [https://wiki.gentoo.org/wiki/Handbook:AMD64]. Before you emerge anything, however, be sure to set your use flags as follows:\nnano /etc/portage/make.conf MAKEOPTS=\u0026#34;-j4 -l4\u0026#34; ACCEPT_KEYWORDS=\u0026#34;* **\u0026#34; ACCEPT_LICENSE=\u0026#34;*\u0026#34; USE=\u0026#34;X gtk bluetooth pulseaudio\u0026#34; You can use your own options instead of these if you know what you’re doing. It’s not super difficult.\nContinue installing the operating system, but stop just before emerging the @world set. I don’t know if this is necessary, but I haven’t had the time to try without doing this. Clone Jannik2099’s github repo. It doesn’t matter where, and run the script. If it fails run it a couple more times.\n`git clone https://github.com/Jannik2099/gentoo-pinebookpro\nDon’t follow any of Jannik’s other instructions. They appear to be out of date (no offense bro). Let me be clear: DO NOT INSTALL U-BOOT. I don’t know what will happen, but it won’t be an improvement over the existing boot-loader so don’t worry about it.\nFinish installing your system until you come to the kernel.\nCustom Kernel\nUse sys-kernel/gentoo-kernel-bin as your kernel. You will need to manually edit the kernel configuration. First, select it as your kernel.\neselect kernel list\nThis should list only one option. Otherwise, select the number matching linux-5.\u0026lt;whatever is latest\u0026gt;-gentoo-dist, and cd into the kernel source directory.\neselect kernel set \u0026lt;number\u0026gt; cd /usr/src/linux Begin the kernel configuration\nmake menuconfig\nAt this point, you’re almost on your own. I don’t know a strict cause-and-effect relationship between my kernel config and the behavior of my system. For starters, just go into platform selection and deselect everything except Rockchip platforms. Once you’re done save your configuration and exit. Make sure boot is mounted, and your fstab is set up with your swap mounted. Make sure dracut is installed.\nmake make modules make dtbs make install make modules install make dtbs_install ls /lib/modules dracut -f --kver \u0026lt;name of directory in /lib/modules matching your kernel, **not** the kernel name from eselect\u0026gt; emerge the package extlinux and run u-boot-update. Open the extlinux configuration file.\nnano /boot/extlinux/extlinux.conf\nAnd configure it as follows:\nLABEL \u0026lt;label of your choice, for example GENTOO ARM\u0026gt; KERNEL /\u0026lt;name of your vmlinuz kernel image. Include the slash, but be relative to boot, not root.\u0026gt; FDT /dtbs/\u0026lt;kernel-version\u0026gt;/rockchip/rk3399-pinebook-pro.dtb APPEND initrd=/\u0026lt;name of initramfs image\u0026gt; root=PARTUUID-\u0026lt;nboot partition’s PARTUUID, no quotes\u0026gt; rw rootwait You can use the blkid command to find the PARTUUID of every partition on the machine. None of this configuration is guaranteed to work, but it worked for me, and given enough fiddling you can get it to work as well.\nNow you should reboot the machine and see if it boots into gentoo. If it does: congratulations|If not, too bad. Try again.\nKali Linux There is a script to create official Kali Linux OS images for the Pinebook Pro. The script carries out the build process in entirety and is Pinebook Pro specific.\nInstallation\nPlease pull the latest Kali Linux install script from the project’s GitLab. For more information regarding building the OS image please read the README instruction at https://gitlab.com/kalilinux/build-scripts/kali-arm/blob/master/README.md NixOS You can follow the ongoing discussion about NixOS on the PINE64 forum. There is a good chance we will see Tier 1 support for aarch64, including the Pinebook Pro, in 2021 (see https://github.com/NixOS/rfcs/pull/87).\nInstallation\nThis is instructions to install NixOS on the Pinebook Pro: https://wiki.nixos.org/wiki/NixOS_on_ARM/PINE64_Pinebook_Pro Please pull the latest samueldr’s repository from the project’s GitHub. SkiffOS Installation\nInstructions to build/install on the Pinebook Pro: https://github.com/skiffos/SkiffOS/tree/master/configs/pine64/book Please pull the latest version from the project’s GitHub. Compiling the boot image takes approximately 30 minutes. Easily configure the kernel, compiler, etc with Buildroot. Pre-built ISOs will be available with the upcoming 2021.02 release. Slackware Slackware is the world’s oldest actively developed Linux distribution, providing a modern user land (applications) and Linux Kernel, within a more classic Unix Operating System environment.\nMore information can be found about Slackware in this 20 minute video.\nInstallation instructions.\nInstallation guide video\nUbuntu If you install Tow-Boot to the SPI, you may then be able to use generic arm64 install disks, such as those for Ubuntu. This is because Tow-Boot can use UEFI boot partitions. The arm64 builds of the Ubuntu installer \u0026ldquo;ISOs\u0026rdquo; can be found here. These can then be converted to UEFI bootable USB drives using a tool such as unetbootin or the Ubuntu \u0026ldquo;Startup Disk Creator\u0026rdquo;.\nUbuntu 22.04 does install and boot on a Pinebook Pro, however the speakers and wifi are non-functional. A USB wifi adapter can get you online.\nUpgrading such an install to 22.10 fixes the wifi. The graphics are broken in an odd way on first boot, but then functional after that. The speakers are still non-functional.\nA fresh install of 22.10 would presumably produce a similar result.\n","permalink":"/documentation/Pinebook_Pro/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":" Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://www.armbian.com/pinecube/ Notes:\nSee Armbian notes NixOS NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades.\ndanielfullmer’s Github ","permalink":"/documentation/PineCube/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"The following releases are available for the PineNote.\nFactory-installed Images Summary Pre-2024 PineNotes were not shipped with a working linux installation. Batch-2 (Community Edition) PineNotes that started selling in October 2024 were shipped with the community-maintained, Debian-based, Linux image found here: https://github.com/PNDeb/pinenote-debian-image. While the factory-flashed image cannot be freely distributed due to unclear distribution rights of the waveform, OS files without the shipped waveforms can be found in this release and a basically equivalent to the shipped images: https://github.com/PNDeb/pinenote-debian-image/releases/tag/batch-2-factory-image-wo-waveform Parts of the batch-2 PineNotes will be flashed with an updated OS version. Notes regarding differentiating between factory OS versions will be made available here in time. Debian A full GNOME-enabled rootfs/disc image is provided under PNDeb/pinenote-debian-image/releases. This image can be flashed using rkdeveloptool. Note Check the trixie branch and github actions artifacts (possibly requires github login) for builds newer than the latest release. A Debian-based minimalistic rootfs/disc image can be built using debos using the work from Eugen Răhăian. The GNOME image above is building on this work. Alpine See https://github.com/DorianRudolph/pinenotes#alpine\nArch Linux hrdl hrdl is maintaining a sway setup on Arch Linux alongside their kernel tree.\nKernel source Packages, helpers, distribution image Installation process dbus service sway configuration DorianRudolph See https://github.com/DorianRudolph/pinenotes#arch-linux\npostmarketOS See https://wiki.postmarketos.org/wiki/PINE64_PineNote_(pine64-pinenote)\nDevelopment Warning The following releases are targeted towards experienced developers. Linux Kernel Batch-2 PineNotes (Community Edition) ares shipped with kernels maintained here https://github.com/m-weigand/linux. RK3566 EBC Reverse-Engineering for the EBC (eInk Panel) driver. PineNote Development/Building Kernel BSP Linux SDK version 4.19 for the PineNote and Quartz64 Model A: Direct download from pine64.org (32.67GB, MD5 of the TAR-GZip file 24554419aec29700add97167a3a4c9ed) Mirror by mwfc An unofficial torrent download provided by a community member of the BSP Linux and Android SDKs can be found here (100GB). Android Android 11 e-ink SDK for the PineNote and Quartz64 Model A. This is the Android SDK build for 10.3\u0026quot; eink panels on Quartz64 Model A.\nDownload:\nDirect download from pine64.org (72.88GB, MD5 of the TAR-GZip file 293a550584298de4fb95ceae18103672) Mirror by mwfc An unofficial torrent download provided by a community member of the BSP Linux and Android SDKs can be found here (100GB). Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz Notes:\nView Android SDK for RK3566 for more information how to compile an image for the PineNote using this SDK Chimera Linux See https://www.1a-insec.net/stuff/pinenote/\n","permalink":"/documentation/PineNote/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"This page provides a comprehensive and alphabetically organized list of available software releases and tools for the PinePhone. For guidance on installing the operating systems, please refer to the Installation instructions.\nNote Some releases may not have a good setup for the backlight at low brightness. If configured too low, the backlight shuts down completely, but the screen is still displayed and usable in bright front-light. Software Releases Arch Linux ARM (Unofficial) Arch Linux ARM with choice of Phosh UI, Plasma Mobile, sxmo or barebones.\nIt is maintained by the DanctNIX community (GitHub: danctnix, dreemurrs-embedded).\nDownload Get both stable and test builds at GitHub releases or directly from the DanctNIX server.\nDefault credentials Default user alarm/123456 root (barebone only) root/root Notes There are archmobile chat rooms on Matrix (#archmobile:kde.org) and Telegram (@archmobile). Feel free to send us pull requests and reports issues on GitHub. Fedora An (unofficial) vanilla Fedora rawhide build for aarch64 with megi\u0026rsquo;s kernel and some additional packages to tie it all together. It aims to eventually be an upstream part of the Fedora project, rather than a phone-specific distribution.\nForum discussion: Fedora + Phosh for PinePhone GitLab: Fedora Mobility SIG Download Build scripts Packages (Fedora COPR) There is also an FTP server with images build every night @ ftp://pine.warpspeed.dk/nightly/pinephone/ (Mount this with something like Nautilus)\nDefault credentials Nightly images (via FTP) pine/1111 Notes WiFi, Bluetooth, SMS, Data, Calls all work|There are still a few bugs though, and some features don\u0026rsquo;t have driver support yet on any PinePhone distribution.\nPlease send your bug reports to the project\u0026rsquo;s issue tracker. Be sure to include logs if applicable|Send us pull requests on GitLab.\nGentoo There are unofficial Gentoo overlays with ebuilds for the PinePhone. There are no images - the image must be built manually, including picking the kernel, bootloader and the desired desktop environment. The ARM64 version of Gentoo has to be selected.\nDownload Overlay locations:\nhttps://git.gjdwebserver.nl/gjdwebserver/gjdwebserver-overlay Notes The documentation can be found here:\nhttps://blog.gjdwebserver.nl/ords/f?p=107:HOME:::::ARTICLE:gentoo-on-a-pinephone https://blog.gjdwebserver.nl/ords/f?p=107:HOME:::::ARTICLE:gentoo-on-a-pinephone-making-it-a-usable-phone https://blog.gjdwebserver.nl/ords/f?p=107:HOME:::::ARTICLE:gentoo-on-a-pinephone-pro https://wiki.gentoo.org/wiki/User:Dr41nU/PinePhone https://wiki.gentoo.org/wiki/PinePhone (incomplete) Note Please consider cross-compiling the software on the computer. Long compilation times and heat production can lead to a reduced lifespan of the phone. GloDroid A fully open-source port of Android and LineageOS to the PinePhone.\nGitHub: GloDroid\nDownload Releases: GloDroid Notes Feature overview:\nWorks: WiFi, screen dimming, sound, touchscreen, charging and telephony(partially) works. Doesn\u0026rsquo;t work: Bluetooth and GPS See more at project status page Kali Linux The official Kali Nethunter images for PinePhone and PinePhone Pro have been released now. For older/unofficial releases, you can still download from the GitHub releases page. Get Nethunter App for your PinePhone\u0026rsquo;s Kali Linux. Packet Injection is working now, use iwconfig instead of airmon-ng.\nDownload Kali Phosh Unofficial Kali Nethunter Pro Official Default credentials Default user for Unofficial Releases kali/8888 Default user for Nethunter Releases kali/1234 LuneOS LuneOS is one of the original multi-tasking OS-es that runs on Linux. Based on HP/Palm\u0026rsquo;s webOS, merged with latest technology stack from LG called webOS OSE (a derivative of what LG uses on their Smart TV\u0026rsquo;s), software such as Qt5 and makes use of the Yocto build system.\nWebOS Ports Wiki WebOS-Ports Wiki\u0026rsquo;s Pinephone page How to Build LuneOS for PinePhone Install LuneOS for PinePhone GitHub: WebOS Ports Download Release images: Releases Testing images: Open the testing releases page, then use Ctrl + F to search release that built image for PinePhone Default credentials Default user root Notes In order to connect to the device using SSH/SCP via WiFi: You can simply connect via SSH/SCP via WiFi using the PinePhone\u0026rsquo;s IP address on port 22.\nMaemo Leste Maemo is a trimmed-down version of Debian for mobile devices, originally a collaboration between Nokia and many open source projects (the Maemo community) before Nokia abandoned it. The more well-known devices Maemo supports are the OpenMoko and N900. The community now takes full responsibility in developing fully open source Maemo for a variety of mobile devices. You may be interested to learn more about the features in their Maemo Leste FAQ.\nMaemo 8 \u0026ldquo;Leste\u0026rdquo; is an ARM64 port of Devuan (Debian without systemd) and runs the mainline Linux kernel. The default user interface stack is Hildon, Xorg, Matchbox WM, and GTK.\nDownload Maemo Leste test builds There is also an image builder, see the wiki for instructions on how to build a custom image. For current status and instructions, please read their PinePhone wiki page.\nDefault credentials root toor user 12345 (lockscreen) Notes Most discussion occurs at #maemo-leste on irc.libera.chat (link) and this thread.\nAll other contact information is listed on the main page of the Maemo wiki.\nSubmit bug reports on GitHub. To track known issues, you may use these search terms: pinephone and pine64.\nMobian A Mobian build for ARM64 running with Phosh (developed by Purism, uses Wayland instead of Xorg). The current version of the base Debian system is Debian Bookworm. Only the GUI applications and a few others (ModemManager, WiFi chip firmware) are built from modified sources (as well as the kernel and u-boot).\nDownload Images Note Tow-Boot is required to be able to boot the images, see here! Default credentials Default user mobian/1234 Notes The development is work in progress. See pinephone-support for further information. The Mobian wiki can be found here.\nIn order to connect to the device using SSH/SCP via WiFi, you need to install SSH on the device. You can do this by executing the following in a shell: \u0026ldquo;sudo apt-get install ssh\u0026rdquo;, afterwards you can connect via SSH/SCP via WiFi using the PinePhone\u0026rsquo;s IP address on port 22.\nMovuan Movuan is the incipient stage of a new distribution for the PinePhone. It is derived from Mobian, yet using Devuan instead of Debian. The image attempts to be as short lived as possible, hoping to get merged into mainline Devuan as soon as possible.\nDownload Image This is a split zip file. To extract it, the following command can be used:\n7z e movuan-pinephone-phosh-daedalus-20250224.img-split.zip Note Tow-Boot is required to be able to boot, same as for Mobian Default credentials Default user movuan/1234 Notes Current image version is based on Devuan Daedalus. Source Code Announcement/Discussion/Motivation Further interest Customizing Movuan under Host Mounting At this time expecting feedback or offers to help with building/packing.\nAnybody is welcome to fork this project, or use it in any GPL compliant way. Use a different name though and change the logo, and notify the author of the project to review if it can be incorporated back.\nIf you want to just mirror the code and provide additional pre-built images on a different server, there is no need to change the logo/name. Just make sure to prominently point to the original location.\nMulti-distro demo image Warning This is a demo image for testing different operating systems before installing a regular image. Attempting to use this image productively is highly discouraged. The kernel is shared across the different operating systems and is not updated. This image allow users to try many Linux distributions easily, without having to figure out how to flash them individually and juggle with many microSD cards. Also called megi\u0026rsquo;s 15-in-1 multi boot image.\nMain page: https://xnux.eu/p-boot-demo/ Git repo: https://megous.com/git/pinephone-multi-boot/ Forum discussion: 15-distro multi-boot image for Pinephone Download Update 2022-01-26, using megi\u0026rsquo;s kernel 5.16.2\nDD image to SD card and boot. This image is for 16GiB or larger SD cards, also works if flashed to eMMC.\nThis is also a good build for charging depleted battery. Just boot up this build with power supply connected, keep the PinePhone charging for 3 hours at power down stage.\nFor more info on this build, please visit its entry the \u0026ldquo;News\u0026rdquo; section of its web page.\nDownload torrent file from author\u0026rsquo;s website File name: multi.img.zst SHA-256: 39915b9d2aa2f33fd78552ac9a0e665c4aef97dd68a9f9a6c76f9fa2f0ac049e File Size: 6.9GiB Due to its size, download though torrent is suggested by the author on its main page.\nDefault credentials General 1111 sxmo user/1111 Manjaro seems to insist on 123456 Notes Note Note about zstd archive file (.zst):\nOn Linux, you may install or compile zstd, then write the image to SD card by piping zstdcat and dd. See the \u0026ldquo;Installation\u0026rdquo; section of its web page for command examples.\nOn Windows, instead of the offical zstd command line program, you may use 7-zip-zstd. Different installation method is provided in their README. Install 7-Zip-zstd / zstd, extract the disk image file (.img) from the zstd archive, and flash with tools like Win32 Disk Imager.\nAlso see Installation instructions.\nNemo Mobile Nemo Mobile is an open source build of Sailfish OS with a open source UI called Glacier, based on openSUSE.\nNemoMobile Website Installation Guide for both real devices and Virtualbox Download Latest release, not every device are built every time. Older release: yyyy.mm/ dirs under https://img.nemomobile.net/. Has every supported device\u0026rsquo;s image. The manjaro/ dir only contains the software packages instead of installation images. Default credentials Default user nemo/1234 root root/linux Notes Please report bugs regarding the Nemo Mobile UI as GitHub issue. Checkout the troubleshooting and contributing guide to learn more.\nNixOS NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades.\nDownload There is a guided installer by the Mobile NixOS project available. An installer image that can be flashed to a sdcard can be downloaded from the Hydra build instance.\nUsers that want to build a local image, are expected to follow the instructions in the Getting Started page, and Project\u0026rsquo;s device page.\nNotes Project home page: Mobile NixOS\nopenSUSE Our images use the same openSUSE Tumbleweed base as our desktop images, except what needs to be changed for the PinePhone. The images include zypper (RPM) as the default package manager, and have access to virtually the same (open source) software as our desktop repositories, thanks to the Factory ports. Using dnf is possible, if preferred.\nDownload Phosh / SHA-256 / SHA-256 Signature Plasma Mobile / SHA-256 / SHA-256 Signature To verify the images you need to import our GPG key. Keep on mind that the first boot may stay on black screen for about a minute - consequent boots should be faster.\nYou can find install instructions at this section in the openSUSE Wiki.\nDefault credentials Default user pine/1234 root root/linux Notes You can find all information about the releases of the project here. Detailed information, tips and troubleshooting suggestions are also provided at the openSUSE Wiki. You will also find information in our wiki on how to report issues (Contributing section).\npostmarketOS postmarketOS extends Alpine Linux to run on smartphones and other mobile devices. It offers various user interfaces (Phosh, Plasma Mobile, Sxmo, Plasma Desktop, Gnome 3, Kodi, XFCE4 and others).\nDownload Download page\nDefault credentials Test images user user/147147 Notes As of writing, official images are provided with Phosh, Plasma Mobile and Sxmo. The official images come in two flavors, either as a test image to try out postmarketOS, or with the installer.\nWhen using the installer images (recommended), it is possible to:\nencrypt the installation install from the SD card to eMMC Power users may also create their own image with the distribution\u0026rsquo;s install and development tool pmbootstrap.\nSee the pine64-pinephone page of the postmarketOS wiki for details.\nRhino Linux Rhino Linux is an Ubuntu-based distribution that uses the rolling-release model by tracking the devel` branch of repositories. The port is currently maintained by Oren Klopfer (oklopfer).\nTow-Boot is required for installing Rhino Linux. Instructions for installing Tow-Boot to the PinePhone can be found here. After Tow-Boot has been installed to your device, Rhino Linux installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload Rhino Linux Downloads (select Pine64 on the dropdown)\nDefault credentials Default user rhino/1234 Notes Foundational to the distribution is Pacstall, a Debian-based user repository inspired by the AUR. Additionally, RL comes with Unicorn, a custom modified version of XFCE with various modernizations and improvements, including auto-rotation for mobile devices.\nDiscord - Matrix - GitHub - Wiki\nSailfish OS Sailfish OS is a Linux-based operating system based on open source projects such as Mer, and a closed source UI based on Lipstick.\nPinePhone Wiki Page on Mer Wiki, for both Nemo Mobile and Sailfish OS. Linux kernel config repo Sailfish OS repo Download Flashing script\nThe Sailfish OS image is built on Gitlab CI. The latest image can be installed using the flashing script.\nThe script downloads the image and bootloader from the CI, extracts everything and burns it onto the SD card.\nNote The script will format and erase the SD card! Instructions:\nDownload the flashing script Insert a microSD card in your device Make the script executable: chmod +x flash-it.sh Verify that you have the bsdtar package installed Execute it: ./flash-it.sh Follow the instructions. Some commands in the script require root permissions (for example: mounting and flashing the SD card). When asked where to flash, type \u0026lsquo;raw\u0026rsquo; and it will build the image on your computer. Otherwise define the path /dev/[\u0026hellip;]. to flash to card or internal emmc.\nusername/password\nSet PIN on initialization.\nNotes Sometimes the first run stalls before the tutorial. Reboot and it will start from setting the security pin. The homescreen may be locked unless you boot with a sim card inserted. An old expired sim will do. If you do not have a SIM card on hands, do NOT set a security code on first boot. When a screen with a loading circle is displayed, just left/right swipe it away. If you\u0026rsquo;re not familiar with Sailfish OS, pay attention to the tutorial - the interface works great, but is not immediately obvious. If you are familiar with it, you can skip the tutorial by touching all 4 corners starting top left. What works, what does not work\nSee the Hardware Support section on the Mer Wiki\u0026rsquo;s PinePhone Page.\nThere is a limited selection of apps available from the Jolla store, the vast majority are hosted on openrepos.net. If the Storeman app for openrepos is not preinstalled, download the RPM and click to install.\nHow to contribute and report defects\nSee the documentation wiki at the github project for help and links.\nSee the Installation section on the Mer Wiki\u0026rsquo;s PinePhone Page for compile, build and development.\nGit repo links are at the top of this OS section. other repos that may be helpful:\nGitHub project page the repo of the flash-it.sh flashing script Mer Open Build Service page (Mer is being assimilated into Sailfish OS and OBS is shutting down, also see OpenStack is replacing OBS with another build system based on Jenkins, if it\u0026rsquo;s related, even OBS come back under Sailfish OS, it will be different.) See the Sailfish OS wiki for links to their forum, as well as info required when reporting an issue. See the Sailfish OS wiki main page for options to contribute to Sailfish OS.\nNotes\nOTA is supported: zypper refresh \u0026amp;\u0026amp; zypper update as root (devel-su to get root access). Things that need reflash are bootloader specific at the moment. If improvements like Crust or changes of partition layout are added, then you need to reflash.\nSkiffOS Minimal in-memory cross-compiled OS optimized for hosting multiple in parallel Docker containers. Provides the reliability of firmware with the ease-of-use of package managers.\nDownload The repository and instructions can be found here.\nNotes Upgrade over-the-air via a simple rsync script, or copying 3 files.\nUses the Buildroot cross-compilation tool for support for all Pine64 boards.\nUse configuration packages to configure distro:\nPackage Distro core/pinephone_neon KDE Neon via Ubuntu repositories core/pinephone_nixos Nixos Mobile core/pinephone_gentoo Gentoo with Link-time Optimization \u0026amp; KDE Mobile or Phosh core/pinephone_ubports Ubuntu Ports for PinePhone core/pinephone_manjaro_kde Manjaro for PinePhone: KDE variant core/pinephone_manjaro_phosh Manjaro for PinePhone: Phosh variant core/pinephone_manjaro_lomiri Manjaro for PinePhone: Lomiri variant The boot-up OS is upgraded independently from the containers.\nSlackware Slackware is the world\u0026rsquo;s oldest actively developed Linux distribution, providing a modern user land (applications) and Linux Kernel, within a more classic Unix Operating System environment.\nDownload https://dl.irradium.org/slackware/images/pinephone/ Notes Discussion: Thread\nUbuntu Touch A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community. The port is currently maintained by Oren Klopfer (oklopfer).\nNote Tow-Boot is required for installing the latest version of Ubuntu Touch (20.04) on the PinePhone. Instructions for installing Tow-Boot to the PinePhone can be found here. Installation instructions can be found at this UBports post. After Tow-Boot has been installed to your device, Ubuntu Touch installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload UBports 20.04 PinePhone Latest Releases UBports PinePhone Device Info Default credentials Default user Set during boot root phablet/1234 Notes Scroll down to the middle of the GitLab project page, or directly here at the UBports website to see which features work.\nContributions and bug reports can be made at the UBports PinePhone GitLab page. See UBports website for how to donate.\nTools There are software tools, that can be booted on the PinePhone.\nJumpDrive JumpDrive can be used to flash the eMMC (and the microSD card), see Installation instructions.\nSee https://github.com/dreemurrs-embedded/Jumpdrive/releases for the latest image. Make sure to download the \u0026ldquo;PinePhone\u0026rdquo; image and to unpack the archive before flashing.\nTow-Boot Tow-Boot is a more user-friendly distribution of U-Boot. It can mount internal storage as USB Mass Storage by holding the volume up button at startup before and during the second vibration. The LED will turn blue if done successfully.\nSee https://github.com/Tow-Boot/Tow-Boot/releases for the latest image. Make sure to download the image with pinephoneA64 in the name.\nNote The USB Mass Storage mode might not be recognized by your computer for some cable + PC USB port + PC OS combos, see this reddit thread and this GitHub issue. If you encounter any problem like this, try use any Linux distro for your PC, or switch USB cables or ports. A patch has been posted on the GitHub issue, try that if you can patch and compile the Tow-Boot yourself, and tell them if that works. Hardware test build Warning The factorytest image for hardware testing appears to be no longer maintained. On the Braveheart model, there was a postmarketOS based basic Factory Test OS pre-installed on the eMMC. The developer Martijn Braam from postmarketOS has improved the functionality of the image considerably later. Since the 20200501 version, it is able to test all the hardware. It also includes functionality to install a new OS to the eMMC when using with an test image that includes that OS image. The downloadable image just does the hardware tests. Do not flash eMMC to test your device, just flash it to microSD and test from there. New versions are distributed as part of the postmarketOS distribution.\nNote The magnetometer test will fail on the new Beta Edition, as the factory image wasn\u0026rsquo;t updated for it yet. Links:\nSoftware Images (NOTE: Link is is broken) (download the latest one named like pine-pinephone-yyyyMMdd-factorytestX.img.xz) Git repo Documentation Historic factory builds These are different operating system builds that was preloaded in the factory with testing utility.\nDownload the build, extract the image and dd it to a 8 GB or larger microSD card, then insert it into the PinePhone. After power up or reboot, you may perform and complete the test routine, or apply the build from microSD card to eMMC.\nAll the download links below are direct download from pine64.org.\nWarning These images are for testing purposes only. If you are looking for an up-to-date image please select one from the software releases section instead. Distribution Download Link File Size MD5 Beta Edition pine64-pinephone-plamo-beta-factorytest.img.xz 1.78GB f16bce93504a52217540ac886863a418 Mobian pine64-pinephone-20201207-factorytest-mobian.img.xz 1.41GB 015be381ff4e650a7fca6d4eaa90d63d KDE pine64-pinephone-20201208-factorytest-kde.img.xz 2.28GB 32979ff17b5ec4d358ce99f1aff0c77c Manjaro pine64-pinephone-20201013-manjaro-stable-20201018-factory56.img.xz 1.04GB 4edfd4dceaefdd32a3417c1727161c29 postmarketOS pine64-pinephone-20200726-phosh-v20.05-factory.img.xz 517MB 244093be2f6d728fcbd1d29114607727 Ubuntu Touch PinePhone-flasher-ubuntu-7b.img.gz 1.05GB 2d7f5271e7a281db8f1b1219bedbe131 Further Releases Apache NuttX RTOS Apache NuttX RTOS is a Real-Time Operating System that supports PinePhone.\nApache NuttX RTOS on PINE64 PinePhone Sculpt Operating System (Genode OS Framework) Sculpt OS since version 23.04 supports PinePhone.\nReady-to-use system image available on the download page.\nInstalling other ARM64 distributions Other ARM64 distributions might be installed as well, however this requires some tinkering and may not work well.\nNote Distributions not on this page may not even boot after you follow this section. In the best case, they will be barely usable. This is more for fun, or if you would like to port a new distribution to the PinePhone. General steps:\nCreate a boot partition (from 4 MB to about 252 MB) and a root partition (from the end of boot to the end of the card) filesystem on the SD card. Format the boot partition with vfat, and the root partition with a supported filesystem like ext4 or f2fs. Extract the root filesystem from your distribution\u0026rsquo;s ARM image into the root filesystem on the SD card. Do not copy the partition, copy the files instead (in archive mode, like rsync -ar). Edit /etc/fstab to match your partitions. Grab megi\u0026rsquo;s kernel from https://xff.cz/kernels/, Follow the instructions in the README, which involves copying the kernel modules into the SD card rootfs, and writing u-boot and the bootloader. If you would like to see examples or specific commands for how to complete these steps, see:\nan example for Fedora, current unofficial [#Fedora] release an example for Arch Linux by megi Other Resources Other software information\nsunxi community wiki megi\u0026rsquo;s feature/driver support matrix megi bootUI notes (for dualbooting/multibooting) see demonstration on YouTube ayufan boot tools Other\nPine64 blog on blobs Martijn Braam Librem 5 comparison, especially covering openness/blobs Bart Ribbers blog on Linux distributions and desktop environments on mobile devices Jeff Geerling on testing microSD cards ","permalink":"/documentation/PinePhone/Software/","tags":null,"title":"Releases"},{"categories":null,"contents":"This page contains a list of all available software releases and tools for the PinePhone Pro.\nFactory builds These are two operating system builds that was preloaded in the factory with testing utility.\nDownload the build, extract the image and dd it to a 8 GB or larger microSD card, then insert it into the PinePhonePro. Press \u0026ldquo;RE\u0026rdquo; button for two seconds when power up, follows on screen instruction and apply the build from microSD card to eMMC.\nDistribution Download Link File Size MD5 Sailfish with RK2AW ppp-factory-image-20231118.img.gz 447MB 4e31e0a6b0999e3e3df45f86a7dc9c33 Manjaro with Tow-Boot Manjaro-ARM-plasma-mobile-pinephonepro-factory-20211212.img.xz 1.37GB b82ba02287c1699b14fed403ce485b44 Arch Linux ARM (Unofficial) Arch Linux ARM with choice of Phosh UI, Plasma Mobile, sxmo or barebones. Currently being maintained by the DanctNIX community (GitHub: danctnix, dreemurrs-embedded).\nDownload Get both stable and test builds at GitHub releases or directly from the DanctNIX server.\nDefault credentials alarm 123456 root (barebone only) root Notes The GitHub page can be found here: dreemurrs-embedded/Pine64-Arch\nA re-image of the above Arch image providing a Btrfs root partitioning has been made by user kaida.\nGentoo The image must be built manually, including picking the kernel, bootloader and the desired desktop environment. The ARM64 version of Gentoo has to be selected. The PinePhone Pro will not boot with P-Boot but will boot with U-Boot.\nhttps://wiki.gentoo.org/wiki/PINE64_PinePhone_Pro\nNotes Note Please consider cross-compiling the software on the computer. Long compilation times and heat production can lead to a reduced lifespan of the phone. GloDroid A fully open-source port of Android and LineageOS to the PinePhone Pro.\nGitHub: GloDroid\nDownload Releases: GloDroid Notes Project status link\nLuneOS LuneOS is one of the original multi-tasking OS-es that runs on Linux. Based on HP/Palm’s webOS, merged with latest technology stack from LG called webOS OSE (a derivative of what LG uses on their Smart TV’s), software such as Qt5 and makes use of the Yocto build system.\nDownload LuneOS (Initial preview): Downloads Default credentials root Notes In order to connect to the device using SSH/SCP via WiFi: You can simply connect via SSH/SCP via WiFi using the PinePhonePro’s IP address on port 22.\nMobian A Mobian build for ARM64 running with Phosh. The current version of the base Debian system is Debian Trixie. See the installation instructions here. If you have questions about Mobian, please ask them in the Mobian Matrix room.\nDownload Images\nNote Tow-Boot required to be able to boot the images, see here! Default credentials mobian 1234 Notes The development is work in progress. The Mobian wiki can be found here.\nIn order to connect to the device using SSH/SCP via WiFi, you need to install SSH on the device. You can do this by executing the following in a shell: \u0026ldquo;sudo apt-get install ssh\u0026rdquo;, afterwards you can connect via SSH/SCP via WiFi using the PinePhonePro’s IP address on port 22.\nKali Linux The official Kali Nethunter images for PinePhone and PinePhone Pro have been released now. Get Nethunter App for your PinePhone’s Kali Linux.\nDownload Kali Phosh Unofficial Kali Nethunter Pro Official Default user for Unofficial Releases kali 8888 Default user for Nethunter Releases kali 1234 Nemo Mobile Nemo Mobile is the open source build of Sailfish OS with a open source UI called Glacier, based on OpenSUSE.\nDownload OpenSUSE based images\nDefault credentials manjaro 123456 root root Notes The website of the Nemo Mobile UX Team can be found here. Please report bugs regarding the Nemo Mobile UI as GitHub issue.\nNixOS NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades.\nDownload Not available yet.\nNotes Device page on the mobile NixOS website\npostmarketOS postmarketOS extends Alpine Linux to run on smartphones and other mobile devices. It offers various user interfaces (Phosh, Plasma Mobile, Sxmo, Plasma Desktop, Gnome 3, Kodi, XFCE4, [\u0026hellip;]).\nDownload Download page\nNote that images for the PinePhone Pro are in the \u0026ldquo;community\u0026rdquo; category of devices indicating some features may not work. You can also build your own image using pmbootstrap\nDefault credentials user 147147 Notes See the pine64-pinephonepro page of the postmarketOS wiki for details.\nRhino Linux Rhino Linux is an Ubuntu-based distribution that uses the rolling-release model by tracking the devel branch of repositories. The port is currently maintained by Oren Klopfer (oklopfer).\nTow-Boot is required for installing Rhino Linux. Instructions for installing Tow-Boot to the PinePhone Pro can be found here. After Tow-Boot has been installed to your device, Rhino Linux installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload Rhino Linux Downloads (select Pine64 on the dropdown) Default credentials rhino 1234 Notes Foundational to the distribution is Pacstall, a Debian-based user repository inspired by the AUR. Additionally, RL comes with Unicorn, a custom modified version of XFCE with various modernizations and improvements, including auto-rotation for mobile devices.\nDiscord - Matrix - GitHub - Wiki\nUbuntu Touch A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community. The port is currently maintained by Oren Klopfer (oklopfer).\nTow-Boot is required for installing the latest version of Ubuntu Touch (20.04) to the PinePhone Pro. Instructions for installing Tow-Boot to the PinePhone Pro can be found here.\nInstallation instructions can be found at\nthis UBports post. After Tow-Boot has been installed to your device, Ubuntu Touch installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload UBports 20.04 PinePhone Pro Latest Releases UBports PinePhone Pro Device Info Default credentials Regular user Set during boot phablet (root) 1234 Notes Scroll down to the middle of the GitLab project page, or directly here at the UBports website to see which features work.\nContributions and bug reports can be made at the UBports PinePhone Pro GitLab page. See UBports website for how to donate.\nMulti-distribution image Warning Work in progress; updating the distributions via their respective package managers may break the system. A PinePhone Pro analogue of the PinePhone multi-distro demo image. This image allows the user to switch between multiple Linux distributions without having to swap microSD cards.\nDownload Clone this git repository and follow the instructions in the README to create a bootable microSD card.\nNotes The shell script in the repository above was derived from these instructions.\nVarious DPA Images Multiple versions of unofficial images of various Debian-based distributions by the user DPA. They also contain some of DPA’s own software.\nDownload The latest successful image builds can be found here: https://repo.dpa.li/apt/dpa-image-builder/images/?board=pinephone-pro\nNotes Most of these images are still in development / incomplete and DPA doesn’t have time to test them all, but they can still be useful as a starting point to get distributions running for which no other images have been created yet. DPA made these images because they wanted to run their favorite distribution, Devuan, on their phone.\nThe build scripts can be found in various places: GitLab, my server, GitHub\nIn theory, these build scripts can create images for any Debian-based distribution which supports ARM64 and can be bootstrapped using debootstrap.\n","permalink":"/documentation/PinePhone_Pro/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"This page contains a list of all available releases and tools for the PineTab-V in alphabetical order.\nFactory releases Batch 2 (2025) The 2nd batch of PineTab-V devices ship with a Debian Bookworm image from StarFive. This can also be flashed to a batch 1 PineTab-V.\ngithub.com/starfive-tech/Debian/releases/tag/PineTab-V-v1.3.0 The instructions for flashing this image can be found in the StarFive PineTab-V release notes document.\nUsername Password user starfive root starfive Batch 1 (2023) The PineTab-V ships with Factory Test Code. The factory test reference source code can be found here:\nPineTab-V_factorytestcode_SDK-20230725.tar.gz from pine64.org (8.36GB, MD5 of the TAR-GZip file: 3e35e2760d82155b024f7601ac2b1275) Community releases:\nsdcard.img pre-built image from the community member Fishwaldo derived from the factory SDK. Note: Use dd to write it to microSD card or the eMMC. Linux Gentoo A Gentoo overlay is available here, it shares most ebuilds for StarFive VisionFive 2 except the kernel source ebuild contains patches from the above factory SDK.\nKDE Plasma Yocto A KDE Plasma Yocto Image from the community member Fishwaldo. Based on the Star64 images developed here. Please see this issue for known problems.\nDownload https://github.com/Fishwaldo/meta-pine64/releases/ Default credentials Root root/pine64 Default user pine64/pine64 Notes Use dd or Balena Etcher to copy to a microSD card and then insert the microSD card into your PineTab-V and boot ","permalink":"/documentation/PineTab-V/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"This page contains a list of all available releases and tools for the PineTab2 in alphabetical order.\nFactory releases The PineTab2 ships with Danctnix Arch Linux ARM. The latest factory image can be found here:\nhttps://echo.danctnix.org:7269/factory_images/pinetab2/latest/ Note The factory image is flashed to a microSD card and it will overwrite the eMMC installation after booting. Info Newer images use the volume and power button for selection at boot instead of the keyboard. Linux Arch Linux ARM (Unofficial) Arch Linux ARM maintained by the DanctNIX community (GitHub: danctnix, dreemurrs-embedded).\nDownload SD-card boot: https://github.com/dreemurrs-embedded/Pine64-Arch/releases Factory flash images: https://echo.danctnix.org:7269/factory_images/pinetab2/ Default credentials alarm 123456 Notes Currently ships without Bluetooth driver, and Wifi driver is unstable. Shutdown / Reboot sometimes hangs (but not always), this is caused by the Wifi driver. Buildroot Buildroot is a simple, efficient and easy-to-use tool to generate embedded Linux systems through cross-compilation.\nAn external tree for the PINE64 PineTab2 is developed and maintained by Danct12 (same developer behind the PineTab2 port of Arch Linux ARM).\nDownload The repository and build instructions can be found here. Fedora Workstation Fedora Workstation is a polished, user-friendly Linux distribution maintained by the Fedora community.\nDownload The Fedora Workstation aarch64 raw.xz image boots normally without requiring additional configuration after being written to an SD card.\nhttps://fedoraproject.org/de/workstation/download Note U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Fedora from an SD card without installing U-Boot. Notes Currently ships without Bluetooth driver. Wifi driver would need manual compilation. LuneOS LuneOS is one of the original multi-tasking OS-es that runs on Linux. Based on HP/Palm’s webOS, merged with latest technology stack from LG called webOS OSE (a derivative of what LG uses on their Smart TV’s), software such as Qt6, Maliit, PulseAudio, Wayland and makes use of the Yocto build system.\nDownload Stable: https://github.com/webOS-ports/luneos-releases/releases/\nTesting: https://github.com/webOS-ports/luneos-testing/releases/\nNote U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Mobian from an SD card without installing U-Boot. Default credentials root no password Notes The development is work in progress, but all hardware that’s supported by the kernel should work (WiFi/BT included). Camera’s aren’t working, similar to all other distros due to lack of drivers. In order to connect to the device using SSH/SCP, you simply can connect to the device’s IP address on port 5522. Teams can be reached via Telegram or Libera IRC #webos-ports Mobian An unofficial Debian build for ARM64 running with Phosh. The current version of the base Debian system is Debian Bookworm. See the installation instructions here. If you have questions about Mobian, please ask them in the Mobian Matrix room.\nDownload Images Note U-Boot is required to boot the images. If you have the factory image installed and updated to the latest version, you can boot Mobian from an SD card without installing U-Boot. Default credentials mobian 1234 Notes The development is work in progress. Mobian’s support for the PineTab2 is maintained by Julian. The Mobian wiki can be found here. In order to connect to the device using SSH/SCP, you need to install SSH on the device. You can do this by executing the following in a shell: \u0026ldquo;sudo apt-get install ssh\u0026rdquo;, afterwards you can connect via SSH/SCP using the PineTab2’s IP address on port 22. When installing Mobian with full disk encryption and booting with the keyboard case connected, you will have to touch the screen or press a key to show the decryption screen. This is an upstream issue. NixOS NixOS is an immutable Linux distribution built around the Nix configuration language. The NixOS image for PineTab2 uses some downstream modifications to packages, such as an U-Boot package based on 2024.04 and the kernel also used by the Arch Linux Arm image.\nDownload https://codeberg.org/raboof/pinetab2-nixos Notes Note that booting can take a while, and does not show anything on the screen. After about 18 seconds the keyboard backlight turns on, then it\u0026rsquo;s about 30 seconds until the first text appears on the screen, and another 10 seconds before the session manager shows up.\nDefault credentials pinetab2 changeme Plasma Mobile on Debian Images of Plasma Mobile on either Debian Bookworm or Debian Trixie created by dieselnutjob\nThe images include uboot, and are an SDcard installer (modified from the Danctnix OS Factory Tool). Using the installer wipes the eMMC drive.\nDownload https://sourceforge.net/projects/pinetab2debianplasmamobile/files/\nDefault credentials pt2 1234 root 1234 Notes The image will not autoexpand to the fill the eMMC, however once booted it is easy to adjust the size of the rootfs using the included KDE Partition Manager.\nThe PineTab2 may be reluctant to shutdown, with several minutes delay whilst the BES2600 wifi driver unloads. This can be avoided by turning off the wifi in the menu that can be pulled down from the top of the screen before shutting down or rebooting.\nThere is a video of the PineTab2 running one of these images here https://www.youtube.com/watch?v=9xpSuG63Rck\nThe author may be contacted via the pinetab discord channel on the Pine64 discord.\npostmarketOS postmarketOS extends Alpine Linux to run on smartphones and other mobile devices.\nIt offers various user interfaces (Phosh, Plasma Mobile, Sxmo, Plasma Desktop, Gnome 3, Kodi, XFCE4 and more). As of writing, this distro is currently in testing and no official releases are available for download. Instead, users will need to create their own image with the distribution’s install and development tool pmbootstrap.\nDownload Pinetab2 Device Page Build the image with pmbootstrap and flash it to an SD. Rhino Linux Rhino Linux is an Ubuntu-based distribution that uses the rolling-release model by tracking the devel branch of repositories. The port is currently maintained by Oren Klopfer (oklopfer).\nThe bootloader (u-boot) comes pre-flashed in the port. Installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload Rhino Linux Downloads (select Pine64 on the dropdown)\nDefault credentials rhino 1234 Notes Foundational to the distribution is Pacstall, a Debian-based user repository inspired by the AUR. Additionally, RL comes with Unicorn, a custom modified version of XFCE with various modernizations and improvements, including auto-rotation for mobile devices.\nDiscord - Matrix - GitHub - Wiki\nUbuntu Touch A Mobile Version of the Ubuntu Operating System made and maintained by the UBports Community. The port is currently maintained by Oren Klopfer (oklopfer).\nThe bootloader (u-boot) comes pre-flashed in the port. Installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload UBports 20.04 PineTab2 Latest Releases\nUBports PineTab2 Device Info\nDefault credentials Default user Set during boot root phablet/1234 Notes Scroll down to the middle of the GitLab project page, or directly here at the UBports website to see which features work.\nContributions and bug reports can be made at the UBports PineTab2 GitLab page. See UBports website for how to donate.\nVoid Linux Void is a general purpose operating system, based on the monolithic Linux kernel. Its package system allows you to quickly install, update and remove software. The port is currently maintained by Sinisha Stojchevski (sini6a).\nThe bootloader (u-boot) comes pre-flashed in the port. Installation just requires flashing the .img.xz to an SD or the eMMC.\nDownload VoidLinux PineTab2\nSource Files for PineTab2\nUser Password root voidlinux Notes To enable graphics driver make sure to install mesa-panfrost-dri.\nContributions and bug reports can be made at the GitHub Project Page. See VoidLinux page for more information about the operating system.\n","permalink":"/documentation/PineTab2/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"This page contains a list of all available operating systems for the Quartz64 in alphabetical order, as well as links to other resources.\nSoftware releases Warning You are strongly encouraged to procure a 3.3V UART serial adapter capable of running at 1.5 mbauds, such as the Woodpecker if you want to use a Quartz64, as some images\u0026rsquo; U-Boot may have no video output on this chip. Important Note: The images are provided by the community, not by PINE64. Most community projects currently aim at getting mainline Linux running on the board, not some vendor provided kernel that will never be receiving updates. A mainline-first approach allows for the boards to continue receiving important updates, such as security updates, for years to come, as well as have higher quality code in the kernel as it underwent independent review, but does mean that not all aspects of the hardware work right out of the gate. Armbian Armbian is a base operating system platform for single board computers\nLightweight Debian or Ubuntu based Linux distribution specialized for ARM development boards Each system is compiled, assembled and optimized by Armbian Build Tools It has powerful build and software development tools to make custom builds Download:\nNote This image appears to have issues detecting more than 2GB of RAM. It is strongly recommended to use a different distribution. latest, as fresh as possible, upon code change, images Notes:\nSupport on Armbian forums https://forum.armbian.com/forum/96-upcoming-hardware-wip/ DietPi DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the Quartz64 builds on the PINE64 forum thread.\nDownload:\nQuartz64 Model A: Direct download from dietpi.com Quartz64 Model B: Direct download from dietpi.com SOQuartz: Direct download from dietpi.com Default credentials root dietpi NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. It relies upon the UEFI support in Tianocore. Before NetBSD 10 is released, the latest version of NetBSD-current should be used.\nDownload:\nNetBSD daily builds top level from inside here, navigate to a date, and inside the images/ subdirectory are installable images. Use the one called \u0026ldquo;NetBSD--evbarm-aarch64-install.img.gz\u0026rdquo;. Notes:\nThis image can be written to a supported device, such as the eMMC interface, any USB storage device, NVMe, and PCIe AHCI SATA are all supported with builds after 2022-01-15. Currently this can not be shared with the EDK2 port, ie, microSD for EDK2 and some other media for NetBSD. Tianocore EDK II port by jmcneill This (as of 2021-12-30) is a work in progress to enable UEFI enabled systems, and is able to bring up SD, eMMC, USB, PCIe with SATA and NVMe, HDMI, thermal sensors, TRNG, as well as general Cortex A-55 features. Known to work with NetBSD -current, and the ESXi Arm fling version 1.8.\nDownload:\njmcneill’s Quartz64 UEFI Github Notes:\nThe microSD card image should be written to an microSD card and installed. Currently, using the same card for the operating system as well may be problematic. BSP Linux SDK The *BSP Linux SDK ver 4.19_ for the Quartz64 Model A.\nDownload:\nDirect download from pine64.org (32.67GB, MD5 of the TAR-GZip file 24554419aec29700add97167a3a4c9ed) Android SDK Android 11 SDK The Android 11 SDK for the Quartz64 Model A SBC.\nDownload:\nDirect download from pine64.org (79.00GB, MD5 of the TAR-GZip file 77c2ff57ea3372fb04da7fb49e17d12b) Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz Android 11 Production Test Builds Android 11 Stock The Android 11 Stock images for eMMC boot for the Quartz64 Model A. This is test build that was used during product testing.\nDownload:\nStock image for the 8GB eMMC module from pine64.org (819MB, MD5 of the Gzip file e4365753e584d9fce1b8f10f095eede6, build 20210604) Stock image for the 16GB eMMC module from pine64.org (1.10GB, MD5 of the Gzip file 491c5f7744b0ca0b74ae76e607051836, build 20210604) Stock image for the 32GB eMMC module from pine64.org (846MB, MD5 of the Gzip file 47a6f0cdac8bad06cb920743849a8894, build 20210604) Stock image for the 64GB eMMC module from pine64.org (884MB, MD5 of the Gzip file 4e2fed6f5db0d55afdc8a142fc0c4fe1, build 20210604) Notes:\nWrite the disk images to the eMMC modules using the USB adapter, for example using dd. Please allow 3-5 minutes boot up time on first time for initialization. Android 11 Production Test Build The Android 11 Production Test Build for the Quartz64 model A for eMMC boot using ROCKChip tools method. This is a test build that was used during product testing.\nDownload:\nDirect download from pine64.org (812MB, MD5 of the Gzip file 800f867fdd0d1b2bd7822c156b6067e3, build 20210604) Notes:\nPlease unzip first and then using Rockchip Android tool ver 2.84 to flash in For Windows OS environment please install the DriverAssistant v5.11 driver first The OTG port located at top USB 2.0 port on top of USB 3.0 port, needs USB type A to type A cable. Please allow 3-5 minutes boot up time on first time for initialization Android 13 SDK The Android 13 SDK for the Quartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC.\nDownload:\nDirect download from pine64.org (111GB, MD5 of the TAR-GZip file 0cd965cf68145cc62876d50f320a715a) Android 13 Stock The Android 13 Stock images for eMMC boot for the Quartz64 Model Zero. This is test build.\nDownload:\nDirect download from pine64.org (765MB, MD5 of the Gzip file 00086005b07b23b8de06fd0c9f8c6816, build 20240606) Notes:\nPlease unzip first and then using Rockchip Android tool ver 3.13 to flash in For Windows OS environment please install the DriverAssistant v5.11 driver first The OTG port located on USB 3.0 port, needs USB type A to type A cable. Please allow 3-5 minutes boot up time on first time for initialization The Android 13 Stock images for SD boot for the Quartz64 Model Zero. This is test build.\nDownload:\nDirect download from pine64.org (765MB, MD5 of the Gzip file c80d48ba407533734fb6484c25d2a398, build 20240614) Notes:\nPlease unzip first and then using Rockchip SD card program tool ver 1.74 to program SD card Please allow 3-5 minutes boot up time on first time for initialization ","permalink":"/documentation/Quartz64/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"This page contains a list of all available releases for the ROCK64, as well as links to other resources.\nLinux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. To learn more about AOSC, please visit the official AOSC website.\nDownload:\nhttps://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more) Default credentials aosc anthon Arch Linux ARM Official Arch Linux ARM release.\nInstallation:\nhttps://archlinuxarm.org/platforms/armv8/rockchip/rock64 Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nROCK64\u0026rsquo;s Armbian site (supports the microSD card and eMMC, 8GB or more) ayufan\u0026rsquo;s Linux releases The community member ayufan offers multiple ROCK64 Linux releases based on Debian and Ubuntu. The forum thread for release can be found here.\nDownload:\nhttps://github.com/ayufan-rock64/linux-build/releases (supports the microSD card and eMMC) Note Make sure to download images for the ROCK64. Default credentials rock64 rock64 Debian Debian is an operating system and a distribution of Free Software.\nDownload:\nDebian 13 Trixie (recommended) Debian 12 Bookworm Daily netboot images Instructions:\nGo to the download directory Download firmware.rock64-rk3328.img.gz and partition.img.gz Combine the 2 parts into 1 image file: zcat firmware.rock64-rk3328.img.gz partition.img.gz \u0026gt; debian-installer.img Write the created .img file to microSD card or eMMC Module using dd: dd if=debian-installer.img of=/dev/sda bs=4M. Replace /dev/sda with your target drive. Plug the microSD/eMMC card in the Rock64 (and connect a serial console) and boot up to start the Debian Installer Notes:\nAn Ethernet connection is required for the above installer Remember to leave some space before your first partition for u-boot! You can do this by creating a 32M size unused partition at the start of the device. Auto creating all partitions does not work. You can use the following manual partition scheme: #1 - 34MB Unused/Free Space #2 - 512MB ext2 /boot (Remember to set the bootable flag) #3 - xxGB ext4 / (This can be as large as you want. You can also create separate partitions for /home /var /tmp) #4 - 1GB swap (May not be a good idea if using an SD card) See README.concatenateable_images here or README.concatenateable_images here for details regarding the concatenateable images and their installation from non-Linux systems. DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the ROCK64 build on the PINE64 forum thread.\nDownload:\nDebian 13 Trixie (supports the microSD card and eMMC, 4GB or more) Debian 12 Bookworm (supports the microSD card and eMMC, 4GB or more) Default credentials root dietpi Lakka Lakka is a lightweight Linux distribution that transforms a small computer into a full blown retrogaming console. Visit PINE64 forum for more information about the Lakka release.\nDownload:\nhttps://nightly.builds.lakka.tv/latest/RK3328.aarch64/ (supports the microSD card and eMMC) LibreELEC LibreELEC is a \u0026ldquo;Just enough OS\u0026rdquo; Linux distribution combining the Kodi media center with an operating system.\nDownload:\nOfficial build image (supports the microSD card and eMMC, 8GB or more) Daily builds (supports the microSD card and eMMC, 8GB or more) NEMS Linux NEMS stands for \u0026ldquo;Nagios Enterprise Monitoring Server\u0026rdquo; and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their site.\nWarning Only supports ROCK64 ver2 SBC Warning Outdated release Download:\nDownload torrent seed from NEMS Linux (supports the microSD card, 16GB or more, MD5 of the xz file is 6e2088922c5d197db8b8ba3057120389) Direct download from pine64.org (supports the microSD card, 16GB or more, MD5 of the xz file is 6e2088922c5d197db8b8ba3057120389) Note The installation guide can be found here. Default credentials nemsadmin nemsadmin NextCloudPi NextCloudPi comes not only with NextCloud preinstalled, but also with management tools for backups, SSL certificates, SAMBA, enhanced security and more. Visit the project\u0026rsquo;s website. You can follow the ongoing discussion about NextCloudPi on the PINE64 forum.\nDownload:\nWarning Outdated release Direct download from pine64.org Note The MD5 hash of the .gz file is 2d3eb799e99a3bb90d5aa7731baf27c6 Default credentials root 1234 OpenMediaVault Openmediavault is the next generation network attached storage (NAS) solution. The forum thread concerning this release can be found here.\nDownload:\nReleases on ayufan\u0026rsquo;s github Direct download from pine64.org (32 bit armhf) Direct download from pine64.org (64 bit arm64) Note The MD5 hash of the .xz file is 474c2a5aac8874fd188404c8e04e53e8 Direct download from pine64.org (32 bit armhf) Note The MD5 hash of the .xz file is bf5d2ea2bc7a5623ba958ed358a80c2a TTY and SSH, except OMV root root OMV for Web admin openmediavault OMV for TTY root openmediavault Recalbox Recalbox is a free and open-source operating system created for the emulation and preservation for retro games. Recalbox allows you to re-play a variety of videogame consoles and platforms in your living room with ease. To find out more about Recalbox and available tweaks to the installation please visit the PINE64 forum thread. Visit the project\u0026rsquo;s website for more details.\nNote Only supports ROCK64 ver2 SBC Download:\nDirect download latest release build from mrfixit2001 GitHub (supports the microSD card and eMMC, 8GB or more) R-Cade Retro Center\u0026rsquo;s R-Cade, the 4K Media Center Arcade. RCade Features 100+ retro-gaming systems, a lightweight web browser, and full 4K UHD media playback.\nDownload:\nDirect download from Retro Center\u0026rsquo;s GitHub (supports the microSD card, eMMC and USB boot) Slackware Slackware is a very old, interesting, convenient and easy distribution. Visit the project\u0026rsquo;s website here (https://fail.pp.ua). You can follow the ongoing discussion about Slackware on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=5868)\nNote This Slackware build using the ZST compression algorithm, please visit the ZST GitHub site for a decompression utility. Download:\nhttp://dl.fail.pp.ua/slackware/images/rock64/ (supports the microSD card) Default credentials root password Flashing the distribution to the eMMC:\nFlash the image to micro SD, power up the board with micro SD and login Copy the image file to micro SD by using SFTP. The image file must have the .img file extension. After finish copy the file, power off the board and add eMMC module to the board Boot the board, run below command for flashing to eMMC module Run sudo dd if=[IMAGE] of=/dev/[DEVICE] bs=10M (example: sudo dd if=slack-current-aarch64-xfce_08May18-4.4.126-rock64-build-20180508.img of=/dev/mmcblk1 bs=10M). then edit these two files in eMMC module: mount /dev/mmcblk1p1 /media echo \u0026quot;rootdev=/dev/mmcblk1p1\u0026quot; \u0026gt;\u0026gt; /media/boot/uEnv.txt sed -i 's:mmcblk0p1:mmcblk1p1:' /media/etc/fstab After that, power off the board and remove the microSD card. Then boot with only the eMMC module. BSD FreeBSD FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms. The RockChip FreeBSD page has instructions for installing FreeBSD. Version 13.0 and greater include prebuilt images.\nDownload:\nImages for various FreeBSD releases can be found here SSH access (enabled by default) freebsd freebsd Root user root root NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. To learn more about NetBSD please visit NetBSD main page.\nDownload:\nDirect download (select ROCK64, supports the microSD card and eMMC) Notes:\nInstructions concerning enabling SSH can be found here or the bootable image from armbsd.org can have the MSDOS partition modified to setup SSH using this method. Default credentials root (root and SSH) none OpenBSD OpenBSD is a security-focused, free and open-source, Unix-like operating system based on the Berkeley Software Distribution. You can install OpenBSD on your Rock64 by following these instructions.\nAndroid Android TV 9.x eMMC (No Google Play) The Android 9.0 image for eMMC boot. For the installation of the Playstore on Android 9.0 please follow this forum thread.\nImage downloads (for direct flashing):\nStock images (write the image to eMMC module using an USB adapter for the eMMC module)\nStock image for the 16GB eMMC module from pine64.org (560MB, MD5 of the Gzip file D985808B4CA912201372DC2F5F322AE9, build 20190617) Stock image for the 32GB eMMC module from pine64.org (579MB, MD5 of the Gzip file 5D65A44F78BD08B4584413C8BEEAAF05, build 20190617) Stock image for the 64GB eMMC module from pine64.org (615MB, MD5 of the Gzip file B34D1C119386CBA1658E5F0FB9E4413D, build 20190617) Rooted images (write the image to eMMC module using an USB adapter for the eMMC module)\nRooted image for 16GB eMMC module from pine64.org (561MB, MD5 of the Gzip file DBB5B3D46B77A33BC9F09173C9788E6E, build 20190618) Rooted image for 32GB eMMC module from pine64.org (579MB, MD5 of the Gzip file 5F3B97EA72B3227082500B3FB1FAB44A, build 20190618) Rooted image for 64GB eMMC module from pine64.org (615MB, MD5 of the Gzip file 6833B124ABA3AC2269A6B4F51EFD1109, build 20190618) Image downloads (for Rockchip Tool):\nStock image from pine64.org (544MB, MD5 of the Gzip file 9B717263E7749A732C8B5C7D7D59C5C6, build 20190617) Rooted image from pine64.org (544MB, MD5 of the Gzip file FC5F80C3A939AD0F8DCE5B85F22D20A1, build 20190618) Note See the guide to flashing eMMC using Rockchip Tools. Please unzip the file first and then use Rockchip tool to flash it. The OTG port located at top USB 2.0 port and it needs USB type A to type A cable. Notes:\nPlease allow 10-15 minutes on first boot for initialization Android 9.x (No Google Play) The rooted Android 9.0 TV image for booting from the microSD card. For the installation of the Playstore on Android 9.0 please follow this forum thread.\nImage downloads (for direct flashing):\nImage for 8GB microSD cards from pine64.org (546MB, MD5 of the Gzip file A250B72CD6AAB24B8156DE08EB15530C, build 20190621) Image for 16GB microSD cards from pine64.org (556MB, MD5 of the Gzip file 09A6BACD71159853D5E4C6C21C883B0F, build 20190621) Image for 32GB microSD cards from pine64.org (574MB, MD5 of the Gzip file C68DC5D96F1C546B96EC690CE7BFE910, build 20190621) Image for 64GB microSD cards from pine64.org (707MB, MD5 of the Gzip file 4EFC87B4CEE4C7655618DCA95EF7DD0D, build 20190621) Note Flash the file to the microSD card, for example using dd. Image downloads (for Rockchip SDDisk Tool):\nDirect download from pine64.org (539MB, MD5 of the Gzip file EE00D309745F842213E21B2F1E20C510, build 20190621) Note Please unzip first and then using Android tool to flash it. Allow 3-5 minutes boot up time on first boot for initialization. The Rockchip SDDisk Tool ver. 1.57 can be found here. Android 8.x TV eMMC (preinstalled Google Play Store) The Android 8.1 TV stock image for booting from the eMMC.\nImage downloads (for direct flashing to the eMMC module):\nDirect download from pine64.org (561MB, MD5 of the .xz file C05846B89A6483DA911CEA604627524F, build 20180606) Note Please allow 10-15 minutes boot up time on first boot for initialization. Image downloads (for Rockchip Tool):\nDirect download from pine64.org (752MB, MD5 of the .xz file 9738F060D2F62A83637797363D2B38C9, build 20180606) Note See the page about how to flash the eMMC using Rockchip Tools. Please unzip the file first and then use Rockchip tool to flash it. The OTG port located at top USB 2.0 port and it needs USB type A to type A cable. Android 8.x TV The Android 8.1 stock image for microSD boot, build 20180623.\nDownload:\nDirect download from pine64.org (575MB, supports the microSD card) Note The MD5 hash of the .xz file is 85372A568C114ADE7CD9632CEBA193E9 Notes:\nWrite the image to a microSD card using dd and boot it. Please allow 10-15 minutes on first boot for initialization Android 7.x eMMC The rooted Android 7.1.2 stock image, build 20171204.\nDownload image (microSD card to eMMC):\nDirect download from pine64.org (558MB, MD5 of the .xz file 43443467DFCAEDE767556843EB4D6707) Note DD image to a microSD card. Shorting the eMMC PIN with a jumper as shown on the first image of the guide to install stock Android build to eMMC module. After power ON the box for 2-3 second, quickly remove the jumper, then it will start writing the new image to the eMMC. Please allow around 1 minute of boot up time before UI is presented via HDMI. Please allow 10-15 minutes boot up time on first boot for initialization. Has USB 3.0 patches. Enable Real Time Clock support for Popcorn Hour Transformer. Download image (eMMC boot):\nDirect download from pine64.org (544MB, MD5 of the .xz file 7C831F9E6B4311A3B3D4743FBBB628D0) Note Please unzip first and then using Android tool to flash in. Has USB 3.0 patches. Enable Real Time Clock support for Popcorn Hour Transformer. Notes:\nSee MAC address on how to set the MAC address. Android TV 7.x eMMC The Android TV 7.1 community build image by ayufan.\nDownload image (eMMC):\nDirect download latest release build from ayufan github and look for android-7.1-rock-64-rock64_atv-x.x.x-xx-update.zip Note For eMMC flash-all image, please unzip first and then use Android tool to flash in Notes:\nPlease allow 5 minutes boot up time on first time for initialization See MAC address on how to set the MAC address. Release notes on ayufan Android 7.1 github Android TV 7.x The Android TV 7.1 community build image for microSD boot by ayufan.\nDownload:\nDirect download latest release build from ayufan github and look for android-7.1-rock-64-rock64_atv-x.x.x-xx-raw.img.gz (supports the microSD card) Android SDK The Android P SDK (v9.0).\nDownload:\nDirect Download from pine64.org (104.34GB) Note The MD5 hash of the TAR-GZip file is 1EAC08942E238293E3AF11C7890DF307 ","permalink":"/documentation/ROCK64/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"This page contains a list of all available releases and tools for the ROCKPro64 in alphabetical order.\nLinux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. Originally AnthonOS (an OpenSUSE derivative built with SUSE Studio), then remade as a Debian derivative with customized KDE 4 UI and CJK support. To learn more about AOSC, please visit the official AOSC website\nDownload:\nhttps://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more) Default credentials aosc anthon Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored. To find out more about Armbian and available options please visit their site. If you are booting from a Micro SD card, then both Linux kernel versions will work. If you are trying to boot from an eMMC module then the 4.4.y will work, but the newer 5.10.y will not.\nDownload:\nhttps://armbian.com/boards/rockpro64 Batocera Linux Batocera Linux is an open-source and completely free retro-gaming distribution that can be copied to a USB stick or an SD card with the aim of turning any computer/nano computer into a gaming console during a game or permanently. Visit the project’s website here (https://batocera.org/). You can follow the ongoing discussion about batocera.linux on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=7084)\nDownload:\nhttps://batocera.org/download Debian Debian is an operating system and a distribution of free software. See the forum thread here.\nDownload:\nDebian 13 Trixie Debian 12 Bookworm Daily netboot images Instructions:\nDownload: firmware.rockpro64-rk3399.img.gz Download: partition.img.gz Create the disk image: For Linux: zcat firmware.rockpro64-rk3399.img.gz partition.img.gz \u0026gt; complete_image.img For Mac: gzcat firmware.rockpro64-rk3399.img.gz partition.img.gz \u0026gt; complete_image.img Write the image to your boot device: For Linux: dd if=complete_image.img of=your_chosen_boot_device bs=4M For Mac: see Getting started Notes:\nAn Ethernet connection is required for the above installer Remember to leave some space before your first partition for u-boot! You can do this by creating a 32M size unused partition at the start of the device. See the troubleshooting section if you encounter issues with GPU acceleration. DietPi DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the ROCKPro64 build on the PINE64 forum thread.\nDownload:\nDirect download from dietpi.com Default credentials root dietpi LibreELEC LibreELEC is a lightweight \u0026lsquo;Just enough OS\u0026rsquo; Linux distribution purpose-built for Kodi on current and popular mediacentre hardware.\nDownload:\nOfficial LibreELEC build image (look for PINE64 RockPro64-LibreELEC-RK3399.arm-x.x.x-rockpro64.img.gz, supports microSD card and the eMMC module of 8GB or more.) Note Unzip and flash the image to a microSD card or eMMC module, for example using dd. Nems Linux NEMS stands for Nagios Enterprise Monitoring Server and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more about NEMS on the PINE64 and available tweaks to the installation please visit the PINE64 forum thread.\nDownload:\nDownload page with torrent seed or direct download. Default credentials nemsadmin nemsadmin NixOS NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades. More information can be found on the NixOS wiki.\nDownload:\nnixos-installer-rockpro64 OpenMediaVault OpenMediaVault is the next generation network attached storage (NAS) solution, click this link to OMV main page to learn more. Forum thread concerning this release can be found here\nDownload: Warning Outdated release Stretch 32bit (armhf): Direct download from ayufan’s github Stretch 64bit (aarch64): Direct download from ayufan’s github Notes:\nYou need to enable root login in OMV WebGUI OpenMediaVault Plugins can enhance the system Default credentials rock64 (TTY and SSH, except OMV) rock64 admin (WebGUI Login) openmediavault root (TTY and SSH) openmediavault OpenWrt OpenWrt ​is a highly extensible ​GNU/​Linux ​distribution for embedded devices ​(typically wireless routers). Unlike many other distributions for these routers, OpenWrt ​is built from the ground up to be a full-featured, easily modifiable operating system for your router. In practice, this means that you can have all the features you need with none of the bloat, powered by a Linux kernel ​that’s more recent than most other distributions.\nDownload:\nhttps://toh.openwrt.org/?view=normal\u0026brand=pine64 postmarketOS postmarketOS extends Alpine Linux to run on smartphones and other devices. At the time of writing, the only user interface provided through prebuilt images for the ROCKPro64 is Plasma Bigscreen.\nDownload:\nhttps://postmarketos.org/download/ Default credentials user 147147 R-Cade Retro Center’s R-Cade, the 4K Media Center Arcade. RCade Features 100+ retro-gaming systems, a lightweight web browser, and full 4K UHD media playback.\nDownload:\nDirect download from Retro Center’s GitHub (USB, microSD and eMMC boot) Recalbox Recalbox allows you to re-play a variety of videogame consoles and platforms in your living room, with ease|Visit the project’s website here (https://www.recalbox.com/). You can follow the ongoing discussion about Recalbox on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=7194)\nDownload: {{Template:Outdated release}}\ndownload release from mrfixit2001 github. SkiffOS Minimal cross-compiled OS optimized for hosting distributions in Docker containers. Provides the reliability of firmware with the ease-of-use of package managers. Uses the Buildroot cross-compilation tool for support for all Pine64 boards.\nUse configuration packages to configure the distribution:\ncore/gentoo: Gentoo optimized for Rockpro64 core/nixos: NixOS arm64 You can also configure the skiff core yaml file to configure multiple distributions to run in parallel.\nThe boot-up OS can be upgraded independently from the containers.\nDownload:\nThe repository and instructions can be found here. Slackware Slackware is the world’s oldest actively developed Linux distribution, providing a modern user land (applications) and Linux Kernel, within a more classic Unix Operating System environment.\nResources:\nInstallation instructions. Installation video guide slarm64 slarm64 is an unofficial aarch64 / riscv64 Slackware Linux port. You can follow the ongoing discussion about slarm64 on the RockPro64 on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=6823) or this forum thread for more general slarm64 information: https://www.linuxquestions.org/questions/slackware-arm-108/slarm64-aarch64-unofficial-slackware-4175613287/.\nDownloads:\ndownload (supports microSD card, look for slarm64-current-aarch64-xfce-rockpro64-x.xx.x-build-xxxxxxxx.img.zst) Default credentials root password Flashing the distribution to the eMMC:\nFlash the image to micro SD, power up the board with micro SD and login Copy the image file to micro SD by using SFTP. The image file must have the .img file extension. After finish copy the file, power off the board and add eMMC module to the board Boot the board, run below command for flashing to eMMC module Run dd if=[image file] of=/dev/mmcblkX bs=10M (example: sudo dd if=slack-current-aarch64-xfce_29Sep18-4.4.162-rockpro64-build-20181126.img of=/dev/mmcblkX bs=10M) then edit these two files in eMMC module: mount /dev/mmcblk1p1 /media echo \u0026quot;rootdev=/dev/mmcblk1p1\u0026quot; \u0026gt;\u0026gt; /media/boot/uEnv.txt sed -i 's:mmcblk0p1:mmcblk1p1:' /media/etc/fstab After that, power off the board and remove the microSD card. Then boot with only the eMMC module. Void Linux Void Linux is a general purpose operating system, based on the monolithic Linux kernel. The official guide can be found at Guide. At this time there are no RockPro64 images available.\nThe following creates a bootable image from an existing Void Linux installation:\nxbps-insall -Syu to update the xbps installation of the installation create ROCKPro64 image with the void-mklive software (from github.com): create a rootfs via mkrootfs.sh: sh mkrootfs.sh -o void-aarch64-muls-ROOTFS-yyyymmdd.tar.xz sh mkplatformfs.sh rockpro64 void-aarch64-muls-ROOTFS-yyyymmdd.tar.xz sh mkimage.sh -s 7GiB void-rockpro64-PLATFORMFS-yyyymmdd.tar.xz write image to sdcard or eMMC: dd if=IMAGE-FILENAME of=DEVICENAME bs=2M If mkplatformfs.sh errors with ROCKPro64 not supported, install xbps-src from https://github.com/void-linux/void-packages and build the ROCKPro64 package. Tip: write a new U-Boot to the image if you see on the serial console the boot-up stalls: get the two U-Boot files from pkgs.org, the aarch64 files: dd if=idbloader.img of=DEVICENAME seek=64 dd if=u-boot.itb of=DEVICENAME seek=16384 Default credentials voidlinux voidlinux BSD Images FreeBSD FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms. The RockChip FreeBSD page has instructions for installing FreeBSD. Version 13.0 and greater include prebuilt images.\nDownload:\nImages for various FreeBSD releases can be found here Default credentials freebsd (SSH user, SSH enabled by default) freebsd root root Notes:\nThe wiki has instructions on enabling the PWM cooling fan. NetBSD Download:\ndownload latest release build from NetBSD by select 64bit - RockPro64 (size: 339 MB) Default credentials root (root user and SSH login) none Notes:\nInstructions concerning enabling SSH can be found here or the bootable image from armbsd.org can have the MSDOS partition modified to setup SSH using this method. OpenBSD OpenBSD is a security-focused, free and open-source, Unix-like operating system based on the Berkeley Software Distribution. Official instruction to get OpenBSD on ROCKPro64 is here, and blogs on installation is here and here. Forum discussion is here.\nAndroid Android 9.0.0 Stock for DD method [eMMC Boot] [20200804]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization Supports new RockPro64 AP6256 Wifi/BT module Support Sony IMX214 camera module and works on both MiPi-CSI ports This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image for 8GB eMMC module Direct download from pine64.org MD5 (GZip file): 7287fd0846616354615c8d3eff6a2a92 File Size: 602MB DD image for 16GB eMMC module Direct download from pine64.org MD5 (GZip file): 78352bbf21198d062af8bab2217ee691 File Size: 611MB DD image for 32GB eMMC module Direct download from pine64.org MD5 (GZip file): c5c8dce419478f75f85f893ee4808dbd File Size: 624MB DD image for 64GB eMMC module Direct download from pine64.org MD5 (GZip file): aab1cf4d30c4d16e6ce2672f3ecae935 File Size: 666MB Stock for RK Flash tool [eMMC Boot] [20200804]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Direct download from pine64.org MD5 (GZip file): 9ac830527814521e15b009fa2503c9e3 File Size: 589MB Stock for DD method [eMMC Boot] [20200708]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization Supports new RockPro64 AP6256 Wifi/BT module This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image for 8GB eMMC module Direct download from pine64.org MD5 (GZip file): ef5f5a890a9270734e0adee21f006837 File Size: 597MB DD image for 16GB eMMC module Direct download from pine64.org MD5 (GZip file): 179bd684a468f800a86f7c658a543bef File Size: 606MB DD image for 32GB eMMC module Direct download from pine64.org MD5 (GZip file): d930b757c4427be07b83c37a9c8494a1 File Size: 630MB DD image for 64GB eMMC module Direct download from pine64.org MD5 (GZip file): 09a970d68a10bdb3d6495d55860940e6 File Size: 660MB Stock for RK Flash tool [eMMC Boot] [20200708]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Direct download from pine64.org MD5 (GZip file): 6d060ddd47ebcfd5cfcdbf90ec042c97 File Size: 589MB Stock for DD method [eMMC Boot] [20190427]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization Please ignore \u0026ldquo;internal problem with your device\u0026rdquo; popup message if appear on Android boot-up page. This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image for 16GB eMMC module Direct download from pine64.org MD5 (GZip file): 3BA4C72D81BCFC4C21B3B5D2BCB4F9F7 File Size: 609MB DD image for 32GB eMMC module Direct download from pine64.org MD5 (GZip file): 4965CCF50A8F06CEB2E4A6828A21F31C File Size: 627MB DD image for 64GB eMMC module Direct download from pine64.org MD5 (GZip file): 748EC28FE5D5395D33E858C913D744BF File Size: 663MB Stock for DD method [microSD Boot] [20190506]\nDD image to microSD card and boot. Use \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization Please ignore \u0026ldquo;internal problem with your device\u0026rdquo; popup message if appear on Android boot-up page. This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image for 8GB microSD card Direct download from pine64.org MD5 (GZip file): E1C551E8106E178841E1C3F71432194A File Size: 599MB DD image for 16GB microSD card Direct download from pine64.org MD5 (GZip file): 73592FDD5A2F52F08020F16AD99E8C8C File Size: 609MB DD image for 32GB microSD card Direct download from pine64.org MD5 (GZip file): 74DE0FE528F210E4DD483B411A71904B File Size: 627MB DD image for 64GB microSD card Direct download from pine64.org MD5 (GZip file): D7626BD50443A88AEB9254C88C575284 File Size: 663MB Stock for RK Flash tool [eMMC Boot] [20190427]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (GZip file): 046BA4A07933120809FBE1B9577B7341 File Size: 592MB Android 8.1.0 Stock for DD method [eMMC Boot] [20180828]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (XZ file): 9AEE21BC1B9DE886DCB0E64FA123988A File Size: 414MB Stock for DD method [microSD Boot] [20181212]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image (for 8GB microSD card and above) Direct download from pine64.org MD5 (XZ file): 5A6BB7FCD7B3F77FCEE99CE462AE7405 File Size: 616MB Stock for RK Flash tool [eMMC Boot] [20180828]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (XZ file): 4DACFE927BB09EE9C56B5232A7F624EE File Size: 415MB Android 7.1.2 Stock for DD method [eMMC Boot] [20180518]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (XZ file): 33622034ACDBC31A7D7BB01ED634E29B File Size: 345MB Stock for RK Flash tool [eMMC Boot] [20180518]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (XZ file): 90C1991DADAE13ADC94E927F171F8920 File Size: 342MB Android SDK Android P SDK [v9.0]\nDirect Download from pine64.org MD5 (TAR-GZip file): 3CEBEEFD1A873BEEEC149148A785D92E File Size: 125.16GB Slash TV OS Android 7 based system including Play Store, working only from SD card (does not boot when installed on eMMC)\nhttps://drive.google.com/drive/folders/1K5YhWaB7Xstuv2HCo1HkpglCEm9x-RIM Development resources The Ayufan github page\ngithub.com/ayufan-rock64/linux-build/ Below are the LPDDR4 driver for RK3399\nrk3399_loader_v1.10.112_support_1CS.bin, this is 800Mhz version used in Android Build rk3399_ddr_666MHz_v1.11.bin, this is alpha version rk3399_ddr_933MHz_v1.11.bin, this is alpha version ROCKPro64 related files\nROCKPro64 Kernel file trust.img Miscellaneous tools Windows ADB driver package MAC address Guide to install stock Android build to eMMC module Tools to burn Android build into a bootable microSD card Tools that allows developer flash image into eMMC’s Loader/Parameter/Misc/Kernal/Boot/Recovery/System/Backup partition ","permalink":"/documentation/ROCKPro64/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"Releases for the SOEDGE.\nLinux BSP Full BSP Linux image ver 1.1 Download:\nSOEdge_linux_v1.1.img.gz from pine64.org, MD5 (GZip file): 636ebeb66d6d0fc0929397d541b0ce83, size: 119MB Notes:\nThis is full image version can be applied to the model A baseboard DD image (for 8GB microSD card or eMMC Module and above) Neural AI Stick Linux image ver 1.1 Download:\nSOEdge_linux_usb_compute_stick.img.gz from pine64.org, MD5 (GZip file): 6fddf73a34ea2a1cb6f36be673567b5f, size: 47MB Notes:\nThis is USB 3.0 Neural AI Stick image version DD image (for 8GB eMMC Module and above) BSP Linux ver 1.1 Build from SDK Download:\nSOEdge_linux_v1.1.img.gz from pine64.org, MD5 (TAR-GZip file): a6629f997ae2cae7d9d5324c4e942deda9, size: 119MB Notes:\nPlease unzip first and then using Rockchip tool to flash in Guide to flashing eMMC using Rockchip Tools BSP Linux ver 1.1 Build as USB Stick application from SDK Download:\nSOEdge_linux_usb_compute_stick.img.gz from pine64.org, MD5 (GZip file): af6ac45995f7ddd9343a7052efffaf30, size: 47MB Notes:\nPlease unzip first and then using Rockchip tool to flash in Guide to flashing eMMC using Rockchip Tools BSP Linux ver 1.1 Build from SDK Download:\nSOEdge_linux_v1.1.img.gz from pine64.org, MD5 (TAR-GZip file): a6629f997ae2cae7d9d5324c4e942deda9, size: 119MB Notes:\nPlease unzip first and then using Rockchip tool to flash in Guide to flashing eMMC using Rockchip Tools BSP Linux ver 1.1 Build as USB Stick application from SDK Download:\nSOEdge_linux_usb_compute_stick.img.gz from pine64.org, MD5 (GZip file): af6ac45995f7ddd9343a7052efffaf30, size: 47MB Notes:\nPlease unzip first and then using Rockchip tool to flash in Guide to flashing eMMC using Rockchip Tools Linux BSP SDK Linux BSP Kernel ver 1.1.7 from pine64.org, MD5 (TAR-GZip file): 47a81a990a644539f3a0e84034654f78, size: 17.42GB Full BSP SDK ver 1.1 from pine64.org, MD5 (TAR-GZip file): a66c92e52824762d7c0a63400d6342ea, size: 13.55GB Neural AI Stick BSP SDK ver 1.1 from pine64.org, MD5 (TAR-GZip file): 46f12441e8c35c06184681f355c89651, size: 9.65GB ","permalink":"/documentation/SOEDGE/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"Note that SOPINE images are also compatible with the PINE A64-LTS.\nLinux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. To learn more about AOSC, please visit the official AOSC website.\nDownload:\nhttps://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more) Default credentials aosc anthon Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://armbian.hosthatch.com/archive/pine64so/archive/ FreedomBox FreedomBox is a private server for non-experts: it lets you install and configure server applications with only a few clicks. For more information about FreedomBox, please visit https://www.freedombox.org.\nWarning Outdated release Download:\nDirect download from FreedomBox site (418MB) Notes:\nThis is a headless build, not HDMI output. Please plug-in Ethernet cable first before initial power up. After power up for 10 minutes, using browser and type in https://fredombox.local to setup. Browser may warms for unsecure site and please proceed with exception. Freedom Manual: https://wiki.debian.org/FreedomBox/Manual LibreELEC LibreELEC is a \u0026ldquo;Just enough OS\u0026rdquo; Linux distribution combining the Kodi media center with an operating system.\nDownload:\nPine A64+ build direct download from Libreelec nightly (look for LibreELEC-A64.arm-\u0026hellip;-nightly-xxxxxxxx-xxxxxxx-pine64-lts.img.gz) Notes:\nNightly build for microSD and eMMC boot. NEMS Linux NEMS stands for \u0026ldquo;Nagios Enterprise Monitoring Server\u0026rdquo; and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their site.\nWarning Outdated release Download:\nDirect download from pine64.org (supports the microSD card, 16GB or more, MD5 of the xz file is 5ad0d684296d50b4c1fcbac6db205ae0) Download torrent seed from NEMS Linux (supports the microSD card, 16GB or more, MD5 of the xz file is 6e2088922c5d197db8b8ba3057120389) Info The installation guide can be found here. Default credentials nemsadmin nemsadmin OpenEmbedded OpenEmbedded is the build framework for embedded Linux. OpenEmbedded offers a best-in-class cross-compile environment. It allows developers to create a complete Linux Distribution for embedded systems. See https://www.openembedded.org/wiki/Main_Page for more information on OpenEmbedded.\nDownload:\nhttps://github.com/alistair23/meta-pine64/ Notes:\nOpenEmbedded/Yocto layer for the Pine64 boards This layer aims to support as many features as possible on Pine64 devices. Where possible the layer aims to use opensource and upstream projects avoiding custom forks and binary solutions. More information and instructions can be found in the repo readme: https://github.com/alistair23/meta-pine64/#building OpenWRT OpenWRT community build for microSD boot. The OpenWrt Project is a Linux operating system targeting embedded devices.\nDownload:\nDirect download (look for pine64_sopine-baseboard-ext4-sdcard.img.gz and pine64_sopine-baseboard-squashfs-sdcard.img.gz) Notes:\nThis is headless build, please use serial console to configure Default credentials Default user -/passwd BSD NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. To learn more about NetBSD please visit NetBSD main page.\nDownload:\nDirect download (select PINE A64-LTS / SoPine with baseboard) Default credentials root (root user and SSH) [none] Notes:\nNetBSD community build for microSD boot Instructions concerning enabling SSH can be found here Linux BSP SDK Linux BSP Kernel 4.9\nDownload:\nDirect Download from pine64.org (5.40GB, MD5 of the TAR-GZip 7736e3c4d50c021144d125cc4ee047a4) Android SDK Android Oreo (v8.1)\nDownload:\nDirect Download from pine64.org (24.94GB, MD5 of the TAR-Gzip b0394af324c70ce28067e52cd7bc0c87) ","permalink":"/documentation/SOPINE/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":" Note The images are provided by the PINE64 community, not by Pine Store Ltd. Most community projects currently aim at getting mainline Linux running on the board, not some vendor provided kernel that will never be receiving updates. A mainline-first approach allows for the boards to continue receiving important updates, such as security updates, for years to come, as well as have higher quality code in the kernel as it underwent independent review, but does mean that not all aspects of the hardware work right out of the gate. DietPi DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the Quartz64 builds on the PINE64 forum thread.\nDownload:\nDirect download from dietpi.com Default credentials Root user root/dietpi ","permalink":"/documentation/SOQuartz/Software/Releases/","tags":null,"title":"Releases"},{"categories":null,"contents":"Wire it up and then flash something.\nManuals InfiniTime installation Zephyr installation Beginner manual which explains how to install Zephyr (by najnesnaj). Wasp-OS installation Full manual with install instructions and an application writer’s guide. ","permalink":"/documentation/PineTime/Development/Reprogramming/","tags":null,"title":"Reprogramming"},{"categories":null,"contents":" Introduction The PineTime Dev Kit comes with the back not glued down to allow it to be easily reprogrammed, however the kit does not include an hardware programmer/debugger.\nBefore you can use your debugger/programmer, you probably have to wire up your pinetime. Heavily recommended you read this first.\nThere is a bewildering variety of different hardware programmers available but whatever programmer you have there are only a few tasks you will have to learn about:\nUnlocking the device Note: PineTime watches shipped after 20 Sep 2020 do not require unlocking. They are shipped unlocked. Uploading new software Running a debugger All of these are described in this article.\nUnlocking the device is a one-time action that is needed to enable the debug port and provide full access to the device. Unlocking the device will erase all existing software from the internal flash.\nSWD Pinout See Devkit wiring\nnrfjprog (for Segger JLink) The following steps have been tested with the Segger JLink embedded in the NRF52-DK development board.\nHookup Connect the Pinetime SWD pins to the debugger (P20 on NRF52-DK)\nPinetime JLink GND GND SWDCLK SWDCLK SWDIO SWDIO VCC (3.3V) VTG (target detect) Unlocking the FLASH Unlocking the device and erase the memory.\nYou need to execute this step only once, to remove the read protection on the memory. Note that it will erase the whole flash memory of the MCU| :\nnrfjprog -f NRF52 --recover Uploading new software Program the BLE softdevice (if needed by the firmware). Replace PATH_TO_NRF_SDK by the path where you unzipped the NRF52 SDK :\nnrfjprog -f NRF52 --program /PATH_TO_NRF_SDK/components/softdevice/s132/hex/s132_nrf52_6.1.1_softdevice.hex --sectorerase Program the firmware (replace firmware.hex by the actual filename of the firmware):\nnrfjprog -f NRF52 --program firmware.hex --sectorerase Reset and run the new firmware:\nnrfjprog -f NRF52 --reset OpenOCD OpenOCD, the Open On-Chip Debugger supports multiple different adapters. You can read more about it here: https://openocd.org/\nAdapters These examples allow you to use telnet to issue futher commands to the devkit. Using them you can connect to 127.0.0.1 (localhost) port 4444 using telnet and invoke OpenOCD commands. GDB should also be available on port 3333.\nYou can simplify your life by creating a configuration file that contains the interface, transport, target and speed configuration. Things like CLion also need one to work properly.\nIf you aren’t using the latest version of OpenOCD, you might need to substitute things in these examples with older syntax (e.g. instead of adapter speed it’s adapter_khz).\nCMSIS-DAP This is a generic specification that is supported by a bunch of different hardware, things such as DAPLink also use it.\nIssue this command to initialize a connection to the devkit:\nopenocd \\ -c 'source [find interface/cmsis-dap.cfg]' \\ -c 'transport select swd' \\ -c 'source [find target/nrf52.cfg]' \\ -c 'adapter speed 8000' \\ -c 'init' JLink Start OpenOCD:\nopenocd \\ -c 'source [find interface/jlink.cfg]' \\ -c 'transport select swd' \\ -c 'source [find target/nrf52.cfg]' \\ -c 'adapter speed 8000' \\ -c 'init' Raspberry Pi openocd \\ -c 'source bcm2835spi' \\ -c 'bcm2835spi_speed 31200' \\ -c 'source [find target/nrf52.cfg]' \\ -c 'init' STLink Connect PineTime SWD Pins to ST-Link v2 as follows:\nPineTime ST-Link GND GND SWDCLK SWDCLK SWDIO SWDIO VCC (3.3V) 3.3V Note that only the bottom row of pins on ST-Link are used.\nTo flash PineTime with ST-Link on Linux and macOS, use PineTime Updater\nST-Link can’t be used to remove nRF52 flash protection\nUnlocking the device If you need to disable access port protection then you can do this using the following commands below.\nThis can be done in two ways:\nAppending this to OpenOCD command line:\n-c 'nrf52.dap apreg 1 0x04' -c 'nrf52.dap apreg 1 0x04 0x01' -c 'nrf52.dap apreg 1 0x04' Or by using the telnet connection, just type in telnet localhost 4444 and then you can issue commands to OpenOCD:\nNote: Unlocking the device to remove access port protection will erase the contents of flash.\ntelnet localhost 4444 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. Open On-Chip Debugger \u0026gt; nrf52.dap apreg 1 0x04 0x00000000 \u0026gt; nrf52.dap apreg 1 0x04 0x01 \u0026gt; nrf52.dap apreg 1 0x04 0x00000001 (If the nrf52.dap command cannot be found, try just dap instead.)\nUploading new software Just issue this command, replace code.hex with your own (and cmsis-dap.cfg with an appropriate adapter).\nopenocd \\ -c 'source [find interface/cmsis-dap.cfg]' \\ -c 'transport select swd' \\ -c 'source [find target/nrf52.cfg]' \\ -c 'init' \\ -c 'halt' \\ -c 'nrf5 mass_erase' \\ -c 'program code.hex verify' \\ -c 'reset' \\ -c 'exit' Black Magic Probe BlackMagic Probe is an JTAG/SWD adapter with open-source firmware, allowing for it to be ported to a multitude of different boards. One of it’s defining features is lack of need for intermediate software such as OpenOCD - one would just need to connect to the GDB server running on the chip and proceed with debugging. For more information, refer to wiki.\nNative adapters The native adapters are the official Black Magic family of debug adapters, including the original Black Magic Probe and the Black Magic Probe Mini. By buying the official hardware you are supporting the continued development of the Black Magic Probe software.\nProviding your native adapter is running up-to-date firmware then it can be used to program your PineTime.\nSTM32 (Blue Pill) It is possible to flash a popular development board based on STM32F103C8T6 microcontroller, known as Blue Pill, to make a BlackMagic Probe device. For example, one may follow instructions in forum post or gist (mac os). Also, it is possible to use SWD pins on the board to flash other devices, instead using arbitrary pins on the board itself. See this link for more detals.\nOther hardware The Black Magic Probe firmware can be run on a variety of host devices. See BMP Debugger Hardware for more information.\nUsing the BMP to flash the PineTime Refer to the BMP wiki for the full description of commands. Overall, the process on Linux is like following. (/dev/ttyBmpGdb is a symlink created by the udev rule). It’s useful to create a gdb script file (or .gdbinit) with following commands:\ntarget extended-remote /dev/ttyBmpGdb monitor swdp_scan attach 1 file %firmware file% Then one may use load command to flash the firmware, compare-sections to verify the upload, or monitor erase_mass to erase the firmware.\nThen, proceed with debugging as normal.\nExternal links and additional tutorials https://github.com/jlukanc1/pinetime-boot-flasher https://blog.aegrel.ee/absniffer-cmsis-dap-sniffer.html https://blog.dbrgn.ch/2020/5/16/nrf52-unprotect-flash-jlink-openocd/ https://medium.com/@ly.lee/openocd-on-raspberry-pi-better-with-swd-on-spi-7dea9caeb590 https://medium.com/@ly.lee/build-and-flash-rust-mynewt-firmware-for-pinetime-smart-watch-5e14259c55 ","permalink":"/documentation/PineTime/Software/Reprogramming/","tags":null,"title":"Reprogramming the PineTime"},{"categories":null,"contents":" Ox64 SBC - Connecting, Flashing and Booting Linux! ($8 from Pine64): A short video on how to connect to the Ox64, flash and boot #24.5 Ox64 Pine64 $8 Risc-V SBC - Programming and Booting Linux: Another video that covers soldering pins, connecting via Pi Pico and flashing Linux and U-Boot First batch of Ox64 won’t appear as USB serial port First batch of Ox64 tested OK with CH340C/G [https://www.robertlipe.com/bl808-not-symmetric/(First thoughts on the (a)symmetry of Bouffalo Labs BL808 as in Pine64 Ox64) The $8 linux computer (with picoprobe-rp2040 programming instructions) Building the Xuantie GNU Toolchain for Ox64 on macOS and Apple Silicon Ox64 BL808 RISC-V SBC articles by Lup Yuen LEE:\nBooting Linux and (maybe) Apache NuttX RTOS Starting Apache NuttX real-time operating system Sv39 Memory Management Unit NuttX Apps and Initial RAM Disk UART Interrupt and Platform-Level Interrupt Controller (PLIC) Fixing the UART Interrupt and Platform-Level Interrupt Controller $8 RISC-V SBC on a Real-Time Operating System: Ox64 + NuttX Nim on a Real-Time Operating System: Apache NuttX RTOS + Ox64 BL808 SBC Emulate Ox64 BL808 in the Web Browser: Experiments with TinyEMU RISC-V Emulator and Apache NuttX RTOS Automated Testing with Ox64 BL808 Emulator (Apache NuttX RTOS) QuickJS JavaScript Engine on a Real-Time Operating System (Apache NuttX RTOS) Coding Ox64 BL808 SBC the Drag-n-Drop Way Rust Apps on Ox64 BL808 RISC-V SBC and Apache NuttX RTOS Adventures of Ox64 BL808 RISC-V SBC with Apache NuttX RTOS Git repositories:\nOfficial Bouffalo BL-808 site Community made Arduino Core specifically for the Bouffalo Labs BL808 RISC-V MCU (initial development has been postponed until further notice.) ","permalink":"/documentation/Ox64/Further_information/Resources/","tags":null,"title":"Resources"},{"categories":null,"contents":"The following resources have been made available by Ondřej Jirman, a developer for the Pinephone:\nGetting started with PinePhone Hardware State of development progress Development log PinePhone Technical News and Update, also applies to other Allwinner devices including PINE A64 SBC Contributions to the kernel development ","permalink":"/documentation/PinePhone/Further_information/Resources/","tags":null,"title":"Resources"},{"categories":null,"contents":" Kernel The linux-rockchip mailing list archives linux-rockchip patchwork neggles / neg2led’s mainline kernel repository with patches picked from the mailing list Sebastian Reichel’s (SRE) rk3588 branch Rockchip BSP kernel tree Collabora RK3588 integration branch Collabora Mainline Status Table Radxa kernel tree, for reference, a lot is happening here Misc The quartz64 and quartz-dev channels on the PINE64 chats (bridged IRC, Matrix, Discord and Telegram) PINE64 rkdeveloptool fork CounterPillow’s uboot-qp64 repository, used with the official rkbin repository Rockchip OpenSource wiki rockchiprs (rkdeveloptool replacement written in Rust) Documentation The documentation for the QuartzPro64 board and most of the documentation for the chips it uses hasn’t been publicly released yet, but if you do own a QuartzPro64 board, the users CounterPillow and Dsimic will happily provide the documentation to you for the research or development purposes, if you ask them in the PINE64 chat channels. We’ve got the following documents, some of which can also be found elsewhere on the Internet rather easily:\nRK3588 datasheet RK3588 technical reference manual (TRM), parts 1 and 2 RK3588 hardware design guide, machine translated to English from Chinese, and the original version in Chinese RK860 datasheet, including register descriptions RK806 datasheet, including register descriptions QuartzPro64 schematics QuartzPro64 PCB top layout QuartzPro64 PCB bottom layout AMPAK-Tech AP6275PR3 (Wi-Fi and Bluetooth module) datasheet AMPAK AP6275P (Wi-Fi and Bluetooth module) datasheet ","permalink":"/documentation/QuartzPro64/Resources/","tags":null,"title":"Resources"},{"categories":null,"contents":"Once you have installed your release of choice to eMMC, you may wish to use an microSD card for data storage. If you choose to re-use a card you have previously used to boot from, you will find your phone might not boot if you just reformat the card and insert it. This is because the Allwinner firmware in the PinePhone uses some (normally) unused space at the front of the microSD card to store boot software, which you need to clear.\nThis can be done as follows on any Linux system:\nlsblk to check the device of your microSD card – as an example lets assume it is /dev/mmcblk0 then\nsudo dd if=/dev/zero of=/dev/[DEVICE] bs=8k seek=1 count=4\nwill clear the relevant sectors of your card.\nSince Danctnix (arch) switched to a gpt partition table from mbr in May of 2022 it installs u-boot at an offset of 128k instead of 8k, which means this command must be used instead\nsudo dd if=/dev/zero of=/dev/[DEVICE] bs=32k seek=4 count=1\n","permalink":"/documentation/PinePhone/Installation/Reuse_microSD_card/","tags":null,"title":"Reuse microSD card"},{"categories":null,"contents":"As of April 2021, current revision of the Clusterboard is 2.3. Compared with the previous revision, 2.2, it removes the PCB components required for using lithium-polymer batteries for powering each of the modules.\nBesides the 2.2 revision, there was also an early revision (TODO: which exactly?) that required a hardware fix for the eMMC module to work properly.\n","permalink":"/documentation/Clusterboard/Further_information/Revisions/","tags":null,"title":"Revisions"},{"categories":null,"contents":"This article describes the boot sequence of the RK3399, the SoC on which the ROCKPro64 single board computer, Pinebook Pro laptop and the PinePhone Pro are based.\nBoot ROM operation After a hardware reset, the SoC’s boot ROM (BROM) starts running on CPU0, one of the Cortex-A53s on the chip. This code is stored on a block of read-only memory, likely hard-wired into the chip.\nIt employs 5 strategies, in order, to load a bootloader from off-chip:\nloading from NOR flash on SPI1 loading from NAND flash on SPI1 loading from eMMC loading from SD on the SDMMC controller bringing up the OTG0 USB controller in device mode and accepting control transfers to load programs Loading a bootloader from storage is done in 4 steps:\nProbing the boot device Finding the ID block Loading the first stage of the bootloader to main SRAM and running it (if the first stage returned to BROM) Loading the second stage to low DRAM and running it ID block The ID block is a 512-byte block at one of several well-known locations (depending on boot device type) scrambled using RC4 with a well-known key, which begins with the bytes 0x3b 8c dc fc (ciphertext; plaintext: 0x55 aa f0 0f).\nIn addition to the magic number, it contains (all fields little-endian):\na flag to RC4-scramble the bootloader images too (32b at offset 8) offset (in 512 B-sectors) of the first bootloader stage (16b at offset 12) the size (in 2 KiB blocks) of the first bootloader stage (16b at offset 506) the size (in 2 KiB blocks) of the second bootloader stage (16b at offset 508) These fields can be seen in U-Boot tools/rkcommon.c.\nSPI boot The boot ROM tries to probe the device on SPI1 by issuing the SPI-NOR 0x9f (Read Identification) command.\nIf the type and capacity bytes are all-ones or all-zeroes, probe fails. If the first byte (manufacturer ID) is all-ones, the BROM uses NAND protocol, otherwise NOR protocol.\nNOR protocol uses command 0x03 (low-frequency read without turnaround cycles) to read blocks, NAND protocol uses command 0x13.\nThe ID block is searched by loading the 32 bytes at the start of flash (TODO other load offsets) and testing for the magic number at any offset within those 32 bytes.\nThe SPI code has a bug that means that the 2 KiB blocks in which the bootloader is loaded have a stride of 4KiB, leaving the 2KiB inbetween as unused padding.\neMMC/SD boot The boot ROM probes for eMMC on the eMMC controller using the normal MMC enumeration sequence (CMD0/1/2/3) at 375 kHz and runs the bus at 24 MHz, in 8-wide mode. The BROM does not support using the standard option for eMMC boot partitions.\nSD is probed on the SDMMC (not the functionally equivalent SDIO) controller, using the normal SD enumeration sequence at 375 kHz and then runs the card at 12 MHz (TODO confirm) in 4-wide mode.\nAfter initialization, eMMC and SD behave much the same. The ID block is searched by loading the blocks at sector 64 + 1024*n for n from 0 to 4 (inclusive) and checking for the magic number at the start of that sector. The BROM handles both byte- and block-addressed SD/MMC cards.\nHardware root of trust The BROM theoretically supports SHA256/RSA2048 authentication with rollback protection.\nThe relevant data is stored in Secure eFuses: an enable flag, a SHA256 hash of the public key (which is stored on the boot medium) and a range of bits that are sequentially set for rollback protection.\nIn practice, the BROM does not verify the full length of the public key against the hash in eFuses, which means that it is most likely broken (expert review would be appreciated).\nTOOD details\nFOSDEM 2023: Tomasz Żyjewski (3mdeb) - Overview of Secure Boot state in the ARM-based SoCs, 2nd edition Rockchip Developer Guide Linux4.4 Secure Boot EN.pdf (zh_CN) Artur Kowalski (3mdeb) - Enabling Secure Boot on RockChip SoCs - December 2021 RK3399 Efuse Operation Instructions V1.00 - 14 February 2019 USB gadget boot If no ID block is found on SPI, eMMC or SD, the BROM sets up the OTG0 USB controller to act as a USB high-speed (480 Mb/s) device with Vendor/Product ID of 2207:330c. In this state it supports most standard control requests, as well as 2 vendor control requests:\n0x0471\nThe code is loaded to main SRAM. When the transfer is done, it does a function call to the load address.\n0x0472\nThe code is loaded to low DRAM. When the transfer is done, USB is torn down and BROM jumps to the load address.\nTransfer is performed by doing the requests on 4 KiB blocks. BROM considers the transfer complete as soon as a request supplies a block not 4096B long. (This means images a multiple of 4096 bytes long must be padded to achieve this condition.\nU-Boot boot sequence Bootloaders based on U-Boot (including Tow-Boot) run in 4 stages on the RK3399:\nTPL, loaded by the BROM into main SRAM. Its job is to initialize DRAM (main system memory). It returns to BROM. This job can alternatively be performed by proprietary Rockchip DDR blobs. SPL, loaded by the BROM into low DRAM. It loads the respective parts of TF-A BL31 into DRAM, main and PMU SRAM, and U-Boot proper into DRAM. TF-A BL31. It sets up EL2 to run U-Boot and stays resident until system shutdown. U-Boot proper. It can load EFI binaries (Grub, systemd-boot, …) from a variety of block devices (SD, eMMC, NVMe, USB Mass Storage, …). For mainline-based U-Boots, these stages usually come in 2 images:\nidbloader.img\ncontains TPL and SPL.\nu-boot.itb\ncontains TF-A and U-Boot.\nLoad offsets Important This section applies to BSP U-Boot. Mainline-based U-Boots pack TF-A into u-boot.itb. There are 3 sections for the boot loader. They are in order, without gap, though their is no need to use all the space in each section.\nHere are the details:\nStart in sectors Size in sectors Name Description 64 16320 IDBLoader SoC initialization code 16384 8192 OS loader Generally U-Boot 24576 8192 TrustedFirmware-A General maintenance If a new U-Boot is supplied, it is generally installed similar to this:\n# dd if=/boot/idbloader.img conv=notrunc seek=64 of=/dev/mmcblkX # dd if=/boot/u-boot.itb conv=notrunc seek=16384 of=/dev/mmcblkX Different devices The RK3399 boots to multiple devices. Boot device selection is done in the following order, and it cannot be changed.\nIf a device is blank / unused, the SoC code moves on to the next device in the list.\nSPI eMMC SD card However, whence the user boot code runs, it can then give priority to other devices, if available. The following devices are not directly bootable:\nNVMe USB 3 WiFi They can be made bootable by using one of the other devices as an initial bootloader. For example, several people have gotten their NVMe drives to be bootable with \u0026ldquo;/boot\u0026rdquo; and \u0026ldquo;/\u0026rdquo; on the NMVe. This either entails using the SPI or eMMC as the initial bootloader, with code to support PCIe NVMe devices.\nGrub as the target of the bootloader It is possible to use Grub as the target of U-Boot. This would allow;\nSelecting a different boot device Choosing a partition on a boot device for booting Different kernels Changes in kernel command line options However, at present, Grub does not support the video \u0026amp; keyboard of the Pinebook Pro. So, any selection is done through the serial console.\nBoot loader development There are several projects that have their own versions of U-Boot, with different features. Here are some of the more common ones at present, 2020/06/14:\nRockchip The original default Debian Manjaro U-Boot mainline Bootloaders not based on U-Boot:\ncoreboot runs on RK3399-based Chromebooks, it has not been ported to Pine64 boards yet. levinboot is a bootloader developed by CrystalGamma in the Pine64 community. It runs on RockPro64 and Pinebook Pro. Its development is on hiatus as of April 2022, but a fork porting it to the PinePhone Pro exists. ","permalink":"/documentation/General/RK3399_boot_sequence/","tags":null,"title":"RK3399 boot sequence"},{"categories":null,"contents":"The RK3566 SoC, used in the Quartz64 SBC by PINE64, contains an eInk interface. This is referred to as ebc by Rockchip apparently.\nUnfortunately, the driver published for this eInk interface within the BSP kernel is an assembly dump produced by gcc. Fortunately, it contains quite a bit of debug information, which we can use to reverse engineer it.\nSources Downstream The ebc driver source is available from the quartz-bsp repository.\nThe files of interest are ebc_dev_v8.S, which implements a DRM (Direct Rendering Manager) driver for the eInk panel, and the waveform files in the epdlut subdirectory.\nThere’s also a simple driver for u-boot: drivers/video/rk_eink at JeffyCN/rockchip_mirrors\nThese two drivers show the two different programming interfaces exposed by the TCON. The U-Boot driver operates in \u0026ldquo;LUT mode\u0026rdquo;: it writes the waveform LUT to registers in the TCON’s MMIO space, and passes buffers of pixel data to the TCON. The Linux driver operates in \u0026ldquo;direct mode\u0026rdquo; uses the LUTs to compute waveforms in software, and passes buffers of waveform data to the TCON.\nSome reversing of the downstream Linux driver has been done here: https://github.com/Ralim/ebc-dev-reverse-engineering\nReimplementation A human-readable C reimplementation of the LUT and pixel data path is available from smaeul here. This provides everything needed to convert a framebuffer and a waveform data file into a series of \u0026ldquo;frames\u0026rdquo; for the panel. The new implementation includes a test suite to verify its output matches the output from the BSP assembly code. It is based on the downstream Linux driver.\nIn-Development Driver rk356x-ebc-dev is the branch used for developing an upstreamable DRM driver based on mainline kernel sources. The driver currently functions well enough to get a virtual console and X.Org running, but it does not support features like multiple waveforms.\nDocumentation Datasheets EBC The EBC TCON is documented in part 2 of the RK356x TRM.\nTI TPS65185x This is the PMIC used to drive the e-Ink panel, for which the downstream sources also implement a driver.\nhttps://www.ti.com/lit/ds/symlink/tps65185.pdf\nWaveform The format of the waveform file is documented here:\nhttps://www.waveshare.net/w/upload/c/c4/E-paper-mode-declaration.pdf\nhttps://www.waveshare.net/w/upload/archive/c/c4/20190611032540!E-paper-mode-declaration.pdf\nUtilities The inkwave program is designed to parse waveform files. Currently it cannot fully handle the waveform files shipped with the PineNote. Adding support for this to the tool would be helpful.\nAssembly Syntax and Semantics The Syntax is GNU Assembler (GAS) syntax. This modexp article provides a good introduction to the syntax, calling convention, semantics and some often used instructions.\nThe ARM Architecture Reference Manual for ARMv8 should be used as reference for any instructions.\nAt the very least, you should read up on the registers and calling convention used.\nVarious Findings The driver isn’t really something that can be mainlined as-is once reversed, as it makes a number of questionable design decisions.\nIt’s technically a DRM subsystem driver, but doesn’t really utilize what DRM provides at all. It seems to register a new ioctl to set buffer attributes like width and height, despite DRM more than likely having a way for clients to tell a driver what size the framebuffer should be. It directly interacts with the PMIC instead of going through regulators/hwmon. However, reverse engineering to know how it works provides a good baseline from which we can rewrite it in a more sensible manner.\nDebug Information Quite a bit of debug info is left in the assembly dump, including function names, file names and line numbers. We can take this to our advantage.\n.file _file-number_ _file-path_ Specifies a number to reference a file by, and its path. All following code until the next .file or .loc statement are to be understood as originating from this file. This is particularly useful to understand which code has been inlined from other files, for which the source is available.\n.loc _file-number_ _line-number_ 0 Specifies that the following code is generated from _line-number_ stemming from file number _file-number_. See the .file directive for this file number to understand which source file it came from.\n.type _function-name_, %function This tells us that the following code belongs to function _function-name_. You’ll usually see a .cfi_startproc, which signifies the start of the function code, until the matching .cfi_endproc.\nA quick grep for %function shows that we are dealing with 30 functions in this file.\n.type _struct-name_, %object This seems to signify a definition of a C struct named _struct-name_.\nA quick grep for %object shows that we are dealing with around 27 structs in this file.\n.Ldebug_info0: TODO: This seems to contain the main bulk of the DWARF debug information, including enough info to reverse full structs and function signatures.\nFinding Structs and Function Signatures First, we’ll need to assemble the file:\naarch64-linux-gnu-gcc -c -o ebc_dev_v8.o ebc_dev_v8.S\nThis gives us a ebc_dev_v8.o which we can feed into analysis tools.\nFor both of these, keep in mind that we’re only interested in stuff from ebc_dev.c, or any other files for which we don’t have the source. There’s no point in getting the struct description or reverse-engineering a function that we have the source code for. A lot more than ebc_dev will be in the object file due to inlining and such.\nAlso make sure that if you are looking up known struct accesses, that you use struct definitions from the BSP kernel, not from mainline. The kernel has no internal ABI for drivers!\nFaster and Easier - Ghidra Import the file into Ghidra, open the code browser. After analysis, you should be able to find structs in the \u0026ldquo;Data Type Manager\u0026rdquo; marked with an S icon. You’ll also find functions in the symbol tree.\nSlow and Painful - readelf/objdump Use this if you want to manually look up dwarf symbols for some reason.\nreadelf --debug-dump ebc_dev_v8.o\nThis will produce a lot of output, but we’re mainly concerned with the start of the dump. We’ll find things like:\n\u0026lt;2\u0026gt;\u0026lt;101f8\u0026gt;: Abbrev Number: 0 \u0026lt;1\u0026gt;\u0026lt;101f9\u0026gt;: Abbrev Number: 79 (DW_TAG_subprogram) \u0026lt;101fa\u0026gt; DW_AT_name : (indirect string, offset: 0xa2b4): ebc_open \u0026lt;101fe\u0026gt; DW_AT_decl_file : 1 \u0026lt;101ff\u0026gt; DW_AT_decl_line : 1377 \u0026lt;10201\u0026gt; DW_AT_prototyped : 1 \u0026lt;10201\u0026gt; DW_AT_type : \u0026lt;0xc6\u0026gt; \u0026lt;10205\u0026gt; DW_AT_low_pc : 0x0 \u0026lt;1020d\u0026gt; DW_AT_high_pc : 0xc \u0026lt;10215\u0026gt; DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) \u0026lt;10217\u0026gt; DW_AT_GNU_all_call_sites: 1 \u0026lt;10217\u0026gt; DW_AT_sibling : \u0026lt;0x1023a\u0026gt; \u0026lt;2\u0026gt;\u0026lt;1021b\u0026gt;: Abbrev Number: 88 (DW_TAG_formal_parameter) \u0026lt;1021c\u0026gt; DW_AT_name : (indirect string, offset: 0x1153): inode \u0026lt;10220\u0026gt; DW_AT_decl_file : 1 \u0026lt;10221\u0026gt; DW_AT_decl_line : 1377 \u0026lt;10223\u0026gt; DW_AT_type : \u0026lt;0x1c54\u0026gt; \u0026lt;10227\u0026gt; DW_AT_location : 0xd63 (location list) \u0026lt;2\u0026gt;\u0026lt;1022b\u0026gt;: Abbrev Number: 106 (DW_TAG_formal_parameter) \u0026lt;1022c\u0026gt; DW_AT_name : (indirect string, offset: 0x8b06): file \u0026lt;10230\u0026gt; DW_AT_decl_file : 1 \u0026lt;10231\u0026gt; DW_AT_decl_line : 1377 \u0026lt;10233\u0026gt; DW_AT_type : \u0026lt;0x551f\u0026gt; \u0026lt;10237\u0026gt; DW_AT_location : 1 byte block: 51 (DW_OP_reg1 (x1))\nThis essentially tells us the full function signature of ebc_open:\nDW_TAG_subprogram tells us of a function, with DW_AT_name letting us know that this is ebc_open. DW_AT_type of 0xc6 let’s us know, once we jump to \u0026lt;c6\u0026gt;, that this function’s return type is a signed 32-bit integer.\nThe DW_TAG_formal_parameter that follow tell us of each of the parameter the function takes. The first one is called inode and is of type 0x1c54. Referencing what this type is, we find:\n\u0026lt;1\u0026gt;\u0026lt;1c54\u0026gt;: Abbrev Number: 7 (DW_TAG_pointer_type) \u0026lt;1c55\u0026gt; DW_AT_byte_size : 8 \u0026lt;1c56\u0026gt; DW_AT_type : \u0026lt;0x1970\u0026gt; which in of itself goes on to reference 0x1970, and looking this one up, we’ll find a struct definition:\n\u0026lt;1\u0026gt;\u0026lt;1970\u0026gt;: Abbrev Number: 26 (DW_TAG_structure_type) \u0026lt;1971\u0026gt; DW_AT_name : (indirect string, offset: 0x1153): inode \u0026lt;1975\u0026gt; DW_AT_byte_size : 672 \u0026lt;1977\u0026gt; DW_AT_decl_file : 31 \u0026lt;1978\u0026gt; DW_AT_decl_line : 611 \u0026lt;197a\u0026gt; DW_AT_sibling : \u0026lt;0x1c4f\u0026gt; \u0026lt;2\u0026gt;\u0026lt;197e\u0026gt;: Abbrev Number: 27 (DW_TAG_member) \u0026lt;197f\u0026gt; DW_AT_name : (indirect string, offset: 0x7d00): i_mode etc.\nReverse-Engineered Stuff Structs ebc_info See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L124, which is based on the v1.04 BSP Linux driver.\nebc See https://gitlab.com/smaeul/ebc-dev/-/blob/main/auto_image.h#L200, which is based on the v1.04 BSP Linux driver.\nrkf_waveform Note all known waveform data files are the \u0026ldquo;PVI\u0026rdquo; variant, not the \u0026ldquo;RKF\u0026rdquo; variant. struct rkf_waveform { int length, char[16] format, char[16] version, char[16] timeandday, char[16] panel_name, char[16] panel_info, char[64] full_version, char[64] reset_temp_list, char[64] gc16_temp_list, char[64] gl16_temp_list, char[64] glr16_temp_list, char[64] gld16_temp_list, char[64] du_temp_list, char[64] a2_temp_list, uint[64] reset_list, uint[64] gc16_list, uint[64] gl16_list, uint[64] glr16_list, uint[64] gld16_list, uint[64] du_list, uint[64] a2_list } Enums rkf_waveform_type enum rkf_waveform_type { RKF_WF_RESET = 0, RKF_WF_DU = 1, RKF_WF_GC16 = 2, RKF_WF_GL16 = 3, RKF_WF_GLR16 = 4, RKF_WF_GLD16 = 5, RKF_WF_A2 = 6 } ","permalink":"/documentation/General/RK3566_EBC_reverse-engineering/","tags":null,"title":"RK3566 EBC Reverse-Engineering"},{"categories":["SBCs"],"contents":" A Small Form-Factor Single Board Computer Capable of 4K playback The ROCK64 is a credit card sized Single Board Computer powered by Rockchip RK3328 quad-core ARM Cortex A53 64-Bit Processor and support up to 4GB 1600MHz LPDDR3 memory. It provides an eMMC module socket, MicroSD Card slot, Pi-2 bus, Pi-P5+ bus, USB 3.0 and many others peripheral devices interface for makers to integrate with sensors and devices.\nVarious operating systems are made available by open source community and partner projects including numerous Linux Distributions, Android, *BSD and more.\nThe ROCK64 4GB board is designated as LTS (Long Term Supply), which means that PINE64 is committed to supply it for at least 5 years – up until 2022 and possibly beyond.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.5 GHz GPU ARM Mali 450 MP2 GPU Memory LPDDR3 RAM (up to 4GB) Networking Gigabit Ethernet Storage Micro SD Slot eMMC module slot SPI Flash 128Mbit Connections 4K digital video out 2x USB 2.0 Host 1x USB 3.0 Host PI-2 bus PI-P5+ bus IR R/X port Real Time Clock (RTC) port Power Over Ethernet (POE) (when using optional HAT module) A/V jack Power, Reset and Recovery buttons 3.5mm barrel power (5V 3A) port Quad-Core RK3328 SoC Quad ARM Cortex A53 cores @ 1.5 GHz and a ARM Mali 450 MP2 GPU which is well supported by Lima\nGigabit Ethernet Built-in Ethernet port allows for fast internet access\nPower Over Ethernet With an optional HAT module you can power the ROCK64 using POE\n4GB LPDDR3 RAM Up to 4GB of LPDDR3 RAM\nStores Global Global: Accessories Affiliates Documentation ROCK64 ","permalink":"/devices/rock64/","tags":null,"title":"ROCK64"},{"categories":null,"contents":" The ROCK64\nThe ROCK64 is a credit-card size 4K60P HDR Media Board Computer powered by Rockchip RK3328 Quad-Core ARM Cortex A53 64-Bit Processor and supports up to 4GB 1866MHz LPDDR3 memory. It provides an eMMC module socket, MicroSD Card slot, Pi-2 Bus, Pi-P5+ Bus, USB 3.0, and many other peripheral interfaces for makers to integrate with sensors and other devices.\nIt supports many different open source operating systems, such as Android, Debian, and Yocto.\nBoard features The ROCK64 and a size comparison\nVideo Digital Video output up to 4K@60Hz 4K HDR @ 60fps H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4Kx2K @ 60fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4Kx2K @ 60fps VP9, up to 4Kx2K @ 60fps MPEG-1, ISO/IEC 11172-2, up to 1080P @ 60fps MPEG-2, ISO/IEC 13818-2, SP@ML, MP@HL, up to 1080P @ 60fps MPEG-4, ISO/IEC 14496-2, SP@L0-3, ASP@L0-5, up to 1080P @ 60fps VC-1, SP@ML, MP@HL, AP@L0-3, up to 1080P @ 60fps MVC is supported based on H.264 or H.265, up to 1080P @ 60fps Audio 3.5mm A/V Jack (Composite Video Output and RCA Stereo support using conversion cable) Network 10/100/1000Mbps Ethernet WiFi 802.11 b/g/n with Bluetooth 4.0 (optional USB dongle) Storage microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable (optional eMMC Module) 128Mbit (16MB) on-board SPI flash memory (empty by default) - bootable? Usually accessible as a Linux MTD device at /dev/mtd0 1 USB3.0 Dedicated Host port 2 USB2.0 Dedicated Host port (top one is USB-OTG) Position of the two-pin header for disabling the optionally installed eMMC module (highlighted in red)\nPosition of the two-pin header for disabling the optionally installed eMMC module (highlighted in red)\nOptionally installed eMMC module can be disabled by placing a jumper onto the two pins on the separate two-pin header, located near one of the mounting holes and two side-mounted buttons. See the picture in this section, in which this two-pin header is highlighted in red.\nExpansion Ports All GPIO pins, including UART, operate at 3.3V. (See VCCIO5 in the schematics.)\n2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 2x11 pins \u0026ldquo;Pi P5+\u0026rdquo; GPIO Header (with 2nd 10/100Mbps Ethernet pins) Software Releases MAC address OS build Installation Guide and tools:\nGuide to install stock Android build to eMMC module Tools to burn Android build into a bootable microSD card Tools that allows developer flash image into eMMC’s Loader/Parameter/Misc/Kernal/Boot/Recovery/System/Backup partition Windows ADB driver package Requirement GNU/Linux Android/Linux Kodi/Linux 2160p 30Hz 8bit h264/h265/vp8 partial? 1 yes yes UI using GPU no yes yes Youtube no yes no vp9 / mpeg4 / mpeg2 / 10bit HDR / YCbCr no yes? yes Releases This page contains a list of all available releases for the ROCK64, as well as links to other resources.\nLinux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. To learn more about AOSC, please visit the official AOSC website.\nDownload:\nhttps://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more) Default credentials aosc anthon Arch Linux ARM Official Arch Linux ARM release.\nInstallation:\nhttps://archlinuxarm.org/platforms/armv8/rockchip/rock64 Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nROCK64\u0026rsquo;s Armbian site (supports the microSD card and eMMC, 8GB or more) ayufan\u0026rsquo;s Linux releases The community member ayufan offers multiple ROCK64 Linux releases based on Debian and Ubuntu. The forum thread for release can be found here.\nDownload:\nhttps://github.com/ayufan-rock64/linux-build/releases (supports the microSD card and eMMC) Note Make sure to download images for the ROCK64. Default credentials rock64 rock64 Debian Debian is an operating system and a distribution of Free Software.\nDownload:\nDebian 13 Trixie (recommended) Debian 12 Bookworm Daily netboot images Instructions:\nGo to the download directory Download firmware.rock64-rk3328.img.gz and partition.img.gz Combine the 2 parts into 1 image file: zcat firmware.rock64-rk3328.img.gz partition.img.gz \u0026gt; debian-installer.img Write the created .img file to microSD card or eMMC Module using dd: dd if=debian-installer.img of=/dev/sda bs=4M. Replace /dev/sda with your target drive. Plug the microSD/eMMC card in the Rock64 (and connect a serial console) and boot up to start the Debian Installer Notes:\nAn Ethernet connection is required for the above installer Remember to leave some space before your first partition for u-boot! You can do this by creating a 32M size unused partition at the start of the device. Auto creating all partitions does not work. You can use the following manual partition scheme: #1 - 34MB Unused/Free Space #2 - 512MB ext2 /boot (Remember to set the bootable flag) #3 - xxGB ext4 / (This can be as large as you want. You can also create separate partitions for /home /var /tmp) #4 - 1GB swap (May not be a good idea if using an SD card) See README.concatenateable_images here or README.concatenateable_images here for details regarding the concatenateable images and their installation from non-Linux systems. DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the ROCK64 build on the PINE64 forum thread.\nDownload:\nDebian 13 Trixie (supports the microSD card and eMMC, 4GB or more) Debian 12 Bookworm (supports the microSD card and eMMC, 4GB or more) Default credentials root dietpi Lakka Lakka is a lightweight Linux distribution that transforms a small computer into a full blown retrogaming console. Visit PINE64 forum for more information about the Lakka release.\nDownload:\nhttps://nightly.builds.lakka.tv/latest/RK3328.aarch64/ (supports the microSD card and eMMC) LibreELEC LibreELEC is a \u0026ldquo;Just enough OS\u0026rdquo; Linux distribution combining the Kodi media center with an operating system.\nDownload:\nOfficial build image (supports the microSD card and eMMC, 8GB or more) Daily builds (supports the microSD card and eMMC, 8GB or more) NEMS Linux NEMS stands for \u0026ldquo;Nagios Enterprise Monitoring Server\u0026rdquo; and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their site.\nWarning Only supports ROCK64 ver2 SBC Warning Outdated release Download:\nDownload torrent seed from NEMS Linux (supports the microSD card, 16GB or more, MD5 of the xz file is 6e2088922c5d197db8b8ba3057120389) Direct download from pine64.org (supports the microSD card, 16GB or more, MD5 of the xz file is 6e2088922c5d197db8b8ba3057120389) Note The installation guide can be found here. Default credentials nemsadmin nemsadmin NextCloudPi NextCloudPi comes not only with NextCloud preinstalled, but also with management tools for backups, SSL certificates, SAMBA, enhanced security and more. Visit the project\u0026rsquo;s website. You can follow the ongoing discussion about NextCloudPi on the PINE64 forum.\nDownload:\nWarning Outdated release Direct download from pine64.org Note The MD5 hash of the .gz file is 2d3eb799e99a3bb90d5aa7731baf27c6 Default credentials root 1234 OpenMediaVault Openmediavault is the next generation network attached storage (NAS) solution. The forum thread concerning this release can be found here.\nDownload:\nReleases on ayufan\u0026rsquo;s github Direct download from pine64.org (32 bit armhf) Direct download from pine64.org (64 bit arm64) Note The MD5 hash of the .xz file is 474c2a5aac8874fd188404c8e04e53e8 Direct download from pine64.org (32 bit armhf) Note The MD5 hash of the .xz file is bf5d2ea2bc7a5623ba958ed358a80c2a TTY and SSH, except OMV root root OMV for Web admin openmediavault OMV for TTY root openmediavault Recalbox Recalbox is a free and open-source operating system created for the emulation and preservation for retro games. Recalbox allows you to re-play a variety of videogame consoles and platforms in your living room with ease. To find out more about Recalbox and available tweaks to the installation please visit the PINE64 forum thread. Visit the project\u0026rsquo;s website for more details.\nNote Only supports ROCK64 ver2 SBC Download:\nDirect download latest release build from mrfixit2001 GitHub (supports the microSD card and eMMC, 8GB or more) R-Cade Retro Center\u0026rsquo;s R-Cade, the 4K Media Center Arcade. RCade Features 100+ retro-gaming systems, a lightweight web browser, and full 4K UHD media playback.\nDownload:\nDirect download from Retro Center\u0026rsquo;s GitHub (supports the microSD card, eMMC and USB boot) Slackware Slackware is a very old, interesting, convenient and easy distribution. Visit the project\u0026rsquo;s website here (https://fail.pp.ua). You can follow the ongoing discussion about Slackware on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=5868)\nNote This Slackware build using the ZST compression algorithm, please visit the ZST GitHub site for a decompression utility. Download:\nhttp://dl.fail.pp.ua/slackware/images/rock64/ (supports the microSD card) Default credentials root password Flashing the distribution to the eMMC:\nFlash the image to micro SD, power up the board with micro SD and login Copy the image file to micro SD by using SFTP. The image file must have the .img file extension. After finish copy the file, power off the board and add eMMC module to the board Boot the board, run below command for flashing to eMMC module Run sudo dd if=[IMAGE] of=/dev/[DEVICE] bs=10M (example: sudo dd if=slack-current-aarch64-xfce_08May18-4.4.126-rock64-build-20180508.img of=/dev/mmcblk1 bs=10M). then edit these two files in eMMC module: mount /dev/mmcblk1p1 /media echo \u0026quot;rootdev=/dev/mmcblk1p1\u0026quot; \u0026gt;\u0026gt; /media/boot/uEnv.txt sed -i 's:mmcblk0p1:mmcblk1p1:' /media/etc/fstab After that, power off the board and remove the microSD card. Then boot with only the eMMC module. BSD FreeBSD FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms. The RockChip FreeBSD page has instructions for installing FreeBSD. Version 13.0 and greater include prebuilt images.\nDownload:\nImages for various FreeBSD releases can be found here SSH access (enabled by default) freebsd freebsd Root user root root NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. To learn more about NetBSD please visit NetBSD main page.\nDownload:\nDirect download (select ROCK64, supports the microSD card and eMMC) Notes:\nInstructions concerning enabling SSH can be found here or the bootable image from armbsd.org can have the MSDOS partition modified to setup SSH using this method. Default credentials root (root and SSH) none OpenBSD OpenBSD is a security-focused, free and open-source, Unix-like operating system based on the Berkeley Software Distribution. You can install OpenBSD on your Rock64 by following these instructions.\nAndroid Android TV 9.x eMMC (No Google Play) The Android 9.0 image for eMMC boot. For the installation of the Playstore on Android 9.0 please follow this forum thread.\nImage downloads (for direct flashing):\nStock images (write the image to eMMC module using an USB adapter for the eMMC module)\nStock image for the 16GB eMMC module from pine64.org (560MB, MD5 of the Gzip file D985808B4CA912201372DC2F5F322AE9, build 20190617) Stock image for the 32GB eMMC module from pine64.org (579MB, MD5 of the Gzip file 5D65A44F78BD08B4584413C8BEEAAF05, build 20190617) Stock image for the 64GB eMMC module from pine64.org (615MB, MD5 of the Gzip file B34D1C119386CBA1658E5F0FB9E4413D, build 20190617) Rooted images (write the image to eMMC module using an USB adapter for the eMMC module)\nRooted image for 16GB eMMC module from pine64.org (561MB, MD5 of the Gzip file DBB5B3D46B77A33BC9F09173C9788E6E, build 20190618) Rooted image for 32GB eMMC module from pine64.org (579MB, MD5 of the Gzip file 5F3B97EA72B3227082500B3FB1FAB44A, build 20190618) Rooted image for 64GB eMMC module from pine64.org (615MB, MD5 of the Gzip file 6833B124ABA3AC2269A6B4F51EFD1109, build 20190618) Image downloads (for Rockchip Tool):\nStock image from pine64.org (544MB, MD5 of the Gzip file 9B717263E7749A732C8B5C7D7D59C5C6, build 20190617) Rooted image from pine64.org (544MB, MD5 of the Gzip file FC5F80C3A939AD0F8DCE5B85F22D20A1, build 20190618) Note See the guide to flashing eMMC using Rockchip Tools. Please unzip the file first and then use Rockchip tool to flash it. The OTG port located at top USB 2.0 port and it needs USB type A to type A cable. Notes:\nPlease allow 10-15 minutes on first boot for initialization Android 9.x (No Google Play) The rooted Android 9.0 TV image for booting from the microSD card. For the installation of the Playstore on Android 9.0 please follow this forum thread.\nImage downloads (for direct flashing):\nImage for 8GB microSD cards from pine64.org (546MB, MD5 of the Gzip file A250B72CD6AAB24B8156DE08EB15530C, build 20190621) Image for 16GB microSD cards from pine64.org (556MB, MD5 of the Gzip file 09A6BACD71159853D5E4C6C21C883B0F, build 20190621) Image for 32GB microSD cards from pine64.org (574MB, MD5 of the Gzip file C68DC5D96F1C546B96EC690CE7BFE910, build 20190621) Image for 64GB microSD cards from pine64.org (707MB, MD5 of the Gzip file 4EFC87B4CEE4C7655618DCA95EF7DD0D, build 20190621) Note Flash the file to the microSD card, for example using dd. Image downloads (for Rockchip SDDisk Tool):\nDirect download from pine64.org (539MB, MD5 of the Gzip file EE00D309745F842213E21B2F1E20C510, build 20190621) Note Please unzip first and then using Android tool to flash it. Allow 3-5 minutes boot up time on first boot for initialization. The Rockchip SDDisk Tool ver. 1.57 can be found here. Android 8.x TV eMMC (preinstalled Google Play Store) The Android 8.1 TV stock image for booting from the eMMC.\nImage downloads (for direct flashing to the eMMC module):\nDirect download from pine64.org (561MB, MD5 of the .xz file C05846B89A6483DA911CEA604627524F, build 20180606) Note Please allow 10-15 minutes boot up time on first boot for initialization. Image downloads (for Rockchip Tool):\nDirect download from pine64.org (752MB, MD5 of the .xz file 9738F060D2F62A83637797363D2B38C9, build 20180606) Note See the page about how to flash the eMMC using Rockchip Tools. Please unzip the file first and then use Rockchip tool to flash it. The OTG port located at top USB 2.0 port and it needs USB type A to type A cable. Android 8.x TV The Android 8.1 stock image for microSD boot, build 20180623.\nDownload:\nDirect download from pine64.org (575MB, supports the microSD card) Note The MD5 hash of the .xz file is 85372A568C114ADE7CD9632CEBA193E9 Notes:\nWrite the image to a microSD card using dd and boot it. Please allow 10-15 minutes on first boot for initialization Android 7.x eMMC The rooted Android 7.1.2 stock image, build 20171204.\nDownload image (microSD card to eMMC):\nDirect download from pine64.org (558MB, MD5 of the .xz file 43443467DFCAEDE767556843EB4D6707) Note DD image to a microSD card. Shorting the eMMC PIN with a jumper as shown on the first image of the guide to install stock Android build to eMMC module. After power ON the box for 2-3 second, quickly remove the jumper, then it will start writing the new image to the eMMC. Please allow around 1 minute of boot up time before UI is presented via HDMI. Please allow 10-15 minutes boot up time on first boot for initialization. Has USB 3.0 patches. Enable Real Time Clock support for Popcorn Hour Transformer. Download image (eMMC boot):\nDirect download from pine64.org (544MB, MD5 of the .xz file 7C831F9E6B4311A3B3D4743FBBB628D0) Note Please unzip first and then using Android tool to flash in. Has USB 3.0 patches. Enable Real Time Clock support for Popcorn Hour Transformer. Notes:\nSee MAC address on how to set the MAC address. Android TV 7.x eMMC The Android TV 7.1 community build image by ayufan.\nDownload image (eMMC):\nDirect download latest release build from ayufan github and look for android-7.1-rock-64-rock64_atv-x.x.x-xx-update.zip Note For eMMC flash-all image, please unzip first and then use Android tool to flash in Notes:\nPlease allow 5 minutes boot up time on first time for initialization See MAC address on how to set the MAC address. Release notes on ayufan Android 7.1 github Android TV 7.x The Android TV 7.1 community build image for microSD boot by ayufan.\nDownload:\nDirect download latest release build from ayufan github and look for android-7.1-rock-64-rock64_atv-x.x.x-xx-raw.img.gz (supports the microSD card) Android SDK The Android P SDK (v9.0).\nDownload:\nDirect Download from pine64.org (104.34GB) Note The MD5 hash of the TAR-GZip file is 1EAC08942E238293E3AF11C7890DF307 MAC Address To set the MAC address on ROCK64 with the \u0026ldquo;Android eMMC\u0026rdquo; image:\nWindows ADB driver package installation is required as prerequisite Download and unzip WNpctool_V1.1.2_1226.zip. Run WNpctool.exe \u0026ldquo;as Administrator\u0026rdquo; on Windows OS Press recovery button on ROCK64 and power ON the ROCK64. After 2 seconds release the recovery button Plug the USB Cable from Top USB2 slot of ROCK64 to PC USB slot (WNpctool will show \u0026ldquo;Found one loader\u0026rdquo; at the bottom) Fill in LANMAC: with small letter MacAddress (e.g. 01234567abcd) then press on Write button Unplug the USB Cable and reboot the ROCK64 and use DOS command \u0026ldquo;ping \u0026hellip;\u0026rdquo; and \u0026ldquo;arp -a\u0026rdquo; or netscan to check the MAC address of the ROCK64 Upstreaming status Warning The data presented in this section requires updating. Function Status Component Notes Video Output Linux Mainline rockchipdrm With mpv, you\u0026rsquo;ll need to specify something like mpv --gpu-context=drm --drm-connector=1.HDMI-A-1 to get it to play back on a VT 3D Acceleration Linux Mainline Upstream Mesa lima Very recent version recommended for the best experience. Has weird glitches on HDMI output in weston. Video Decode Linux Staging Broken/Not in ffmpeg hantro_vpu and rockchip_vdec, using v4l2-requests Soon to be moved out of staging, ffmpeg patch set seemingly abandoned, does not work on newer kernels. Git branch with commits Audio Linux Mainline snd_soc_rockchip_* Power Button Linux Mainline rk805_pwrkey If your PWR switch does nothing unless held, this may need to be loaded manually with modprobe or by putting it in /etc/modules-load.d/ Analog Video Output Needs porting rockchip_drm_tve Definitely needs some cleanup before it\u0026rsquo;d be ready for mainline, and needs some dt bindings written. Troubleshooting HDMI output disconnects as soon as it connects Some older monitors seemingly can get into a weird state wherein the ROCK64 is unable to establish a proper connection with them. User CounterPillow has seen this happen on an iiyama ProLite G2773HS connected over HDMI, and an Acer P225HQL connected over an HDMI to DVI adapter. The symptoms usually are that you see the monitor briefly turn on its backlight without displaying a picture, but then immediately either shutting off again or showing a \u0026ldquo;No Signal\u0026rdquo; message.\nThe solution is to completely power down your ROCK64, also removing its power source. Then plug in the monitor, and start up the ROCK64 afterwards. You should now be getting a picture again.\nPower button doesn\u0026rsquo;t do anything on a short press (Linux) Make sure the rk805_pwrkey module is loaded, e.g. with lsmod | grep rk805_pwrkey. The module auto loading of rk805_pwrkey was fixed in the following upstream kernels: v6.0/v5.15.66/v5.10.142/v5.4.213/v4.19.258/v4.14.293 so there should be no requirement for fixes with those kernels or newer. If it doesn’t show up, do a modprobe rk805_pwrkey as root. To make this persistent, create a 99-rk805_pwrkey.conf in /etc/modules-load.d/ with the content rk805_pwrkey\nIf it still doesn’t work, make sure your init system is actually listening to the button press. With systemd, check /etc/systemd/logind.conf and make sure it’s either all commented out (uses defaults) or contains something like HandlePowerKey=poweroff. You can change the short press action by setting HandlePowerKey to one of \u0026ldquo;ignore\u0026rdquo;, \u0026ldquo;poweroff\u0026rdquo;, \u0026ldquo;reboot\u0026rdquo;, \u0026ldquo;halt\u0026rdquo;, \u0026ldquo;kexec\u0026rdquo;, \u0026ldquo;suspend\u0026rdquo;, \u0026ldquo;hibernate\u0026rdquo;, \u0026ldquo;hybrid-sleep\u0026rdquo;, \u0026ldquo;suspend-then-hibernate\u0026rdquo;, or \u0026ldquo;lock\u0026rdquo;.\nVideo output is glitchy during activity If your video output glitches out while there is memory bandwidth pressure, the likely reason is that the video output (VOP) quality-of-service (QoS) registers aren’t set to high priority mode.\nUser CounterPillow submitted a patch to u-boot to fix this, but someone still needs to write a kernel patch to save/restore the QoS registers from the power domain driver.\nCases The ROCK64 fits in three officially sold cases.\n\u0026ldquo;Model B\u0026rdquo; Acrylic Open Enclosure, Store \u0026ldquo;Model B\u0026rdquo; Aluminum Waterproof Enclosure, Store Premium Aluminium Casing, Store Premium Aluminum Casing The case, fully assembled with a ROCK64 inside of it\nThe ROCK64 Premium Aluminum Casing is an aluminum case for the ROCK64 single-board computer sold by Pine64 through their official store. It includes an integrated heat spreader with an included thermal pad that allows the SoC to sink its generated heat into the metal case.\nInstallation Make sure the LED light guide and rubber plug are taken out of the case. Drop your ROCK64 into the bottom half of the case with the ports in the correct place. Tighten it with the four included round top screws, using a Phillips #00 screw driver.\nInstall the light guide and the rubber plug by pushing them in from the outside.\nIdeally, clean the SoC of any possible residue with some isopropyl alcohol. Next, remove the plastic foil protecting the thermal pad on the top half of the case, and slot the top half into place, making sure that the HDMI and audio jack ports fall into their respective place in the side section (see HDMI and Audio Jack Clearance Issues if they don’t.)\nOnce the top half is firmly in place, screw in the four flat top screws with a Phillips #00 screw driver.\nPerformance The built in heat spreader does do its job at sinking heat into the case. User:CounterPillow finds that during a lengthy kernel compilation at 22°C ambient temperature, the average SoC temperature measured around 60°C. The case during such sustained loads becomes warm to the touch, which means it is working as a heat sink.\nTips and Tricks HDMI and Audio Jack Clearance Issues Some cases may not allow the ROCK64 IO to snugly fit into its predestined cutout holes on its long side. If this is the case for you, try loosening the screws on the HDMI, power and audio jack port side, and only tightening the screws on the GPIO side to still make good ground contact. The HDMI and audio jacks should then fit into their holes snugly. If you wish to try, you can also try adjusting the screws holding in the posts on the bottom of the case.\nPlastic Pegs for PWR and RST Buttons FreeCAD displaying the peg. Bottom part goes inside the case.\nIf you are tired of using a pen or a toothpick to push the buttons, there are 3d-printable plastic pegs you can download and print yourself. Recommended material is PLA, excellent results can be obtained using a 0.25mm nozzle, though slightly larger sizes should work fine as well.\nTo use the pegs, open your case and remove the ROCK64 from within. Be sure to pull out the light guide and rubber plug to remove it, or else it will catch on them. Once it is removed, turn your bottom half of the case such that the holes for PWR and RST are pointing towards the floor, and drop the pegs into the holes from inside the case, so that the lip prevents them from falling through. Hold them in position with your finger, turn the case the right side up again, and reinstall your ROCK64.\nPlastic Pegs in their place\nYou should now have buttons that can be pressed from outside the case without any utensils.\nIf you do not own a 3d printer, contact User:CounterPillow. He may mail you some for free in an envelope.\nRemove the black anodised layer from the heat pad Anodising has a significantly poorer thermal conductivity than aluminium, therefore grinding off the anodising before fitting the blue thermal pad should result in a lower CPU temperature.\nUsing the case with the PINE H64 Whilst the case is sold as a ROCK64 accessory, all the connectors and mounting screws on the PINE H64 are in the same spots. The only difficulty is that the H6 CPU is closer to the \u0026ldquo;Pi2\u0026rdquo; connector and extends beyond the edge of the heat spreader by about 5mm. User:AlephNull used a piece of copper shim on top of the H6 (with a smear of thermal paste) to spread the heat back to the thermal pad. In this configuration, the CPU stabilised at about 76°C running 4 copies of a CPU stress test. Whilst a lower temperature might be nice, this is still well below the 125°C limit.\nFurther information Certifications\nDatasheets\nOther resources\nSchematics\nSpecifications\nCertifications Certifications:\nROCK64 FCC Certificate ROCK64 CE Certificate ROCK64 RoHS Certificate Datasheets Rockchip RK3328 SoC information:\nRockchip RK3328 SoC Brief Rockchip RK3328 Datasheet V1.2 Rockchip RK3328 Technical Reference Manual part 1 Rockchip RK805 Datasheet V1.1 LPDDR3 (178 Balls) SDRAM:\nHynix LPDDR3 Datasheet V1.2 Samsung LPDDR3 Datasheet V1.00.00 Spectek LPDDR3 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32Gb/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Ethernet related info:\nRealtek RTL8211F 10/100/1000M Ethernet Transceiver Datasheet 10/100Mbps MegJack on Audio DAC POT board Datasheet Peripheral related info:\nJMicron JMS578 to SATA Datasheet Enclosure information:\nOutdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Remote control button mapping:\nOfficial Remote Control for the PINE A64 Button Mapping Other resources ROCK64 Forum ROCK64 Linux GitHub Repo ROCK64 ayufan GitHub Repo Rockchip Linux GitHub Repo Rockchip Android RKMC (Forked from Kodi 16.1) Rockchip Open Source Wiki Armbian’s ROCK64 Page Schematics Board Dimensions: 85mm x 56mm x 18.8mm, see the ROCK64 board dimension drawing\nInput Power: +5V @3A with 3.5mm/1.35mm Type H Barrel type DC connector (@2A will work if there is no heavy load on the USB 3.0 port)\nROCK64 ver 3.0 SBC related info:\nROCK64 SBC v3.0 Change Notice ROCK64 Schematic v3.0 (Production Release) ROCK64 Component Reference location v3.0 (top layer) ROCK64 Component Reference location v3.0 (bottom layer) ROCK64 SBC v3.0 Pi-2 and Pi-P5+ Bus GPIO Assignment ROCK64 Rev3 SBC RTC Battery Connector polarity ROCK64 ver 2.0 SBC related info:\nROCK64 Schematic v2.0 (Production Release) ROCK64 SBC v2.0 Pi-2 and Pi-P5+ Bus GPIO Assignment Github on ROCK64 GPIO library, thanks to Leapo Good documentation about ROCK64 GPIO pins article ROCK64 Audio DAC with 10/100Mbps Ethernet POT Board Schematic ROCK64 3D autodesk drawing (from TeaPack):\nROCK64 board 2D drawing @courtesy of TeaPack ROCK64 board 3D drawing @courtesy of TeaPack ROCK64 Audio DAC with 10/100Mbps Ethernet POT board 3D drawing @courtesy of TeaPack ROCK64 board with Audio DAC POT board 3D drawing @courtesy of TeaPack Specifications Based on Rockchip RK3328\nCPU Architecture Quad-core Cortex-A53 up to 1.5GHz CPU Full implementation of the ARM architecture v8-A instruction set ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation ARMv8 Cryptography Extensions In-order pipeline with symmetric dual-issue of most instructions Unified system L2 cache Includes VFP v3 hardware to support single and double-precision operations Integrated 32KB L1 instruction cache, 32KB 4-way set associative L1 data cache TrustZone technology support Full CoreSight debug solution One separate power domain for CPU core system to support internal power switch, and to externally turn on/off based on different application scenario PD_A53: Cortex-A53 + Neon + FPU + L1 I/D Cache of core 2/3 One isolated voltage domain to support DVFS Frequencies \u0026amp; Voltages Frequency Voltage 408 MHz 0.950 V 600 MHz 0.950 V 816 MHz 1.000 V 1008 MHz 1.100 V 1200 MHz 1.225 V 1296 MHz 1.300 V Power Draw These numbers for power draw have been measured through an USB power monitor (FNB38) while running the stress utility, whereby \u0026ldquo;cpu\u0026rdquo; stands for stress --cpu 4 and \u0026ldquo;vm\u0026rdquo; stands for stress --vm 4. The former spins on the CPU, the latter stresses the memory. Real workloads are usually a mix of both. The tests were ran through ssh, with nothing besides power and ethernet plugged into the ROCK64\nPlease keep in mind that under real world usage, many other factors come into play. Having a display connected, running a graphical session, I/O and most importantly the connected USB peripherals can add a lot.\nHelpful refresher on the formula for power (W) on DC: power = current × voltage, because the power factor is 1. The ROCK64 runs on 5V, so use that to calculate current if you need to.\nFrequency Power cpu Power vm 1296 MHz 2.64 W 2.95 W 1200 MHz 2.32 W 2.69 W 1008 MHz 1.90 W 2.31 W 816 MHz 1.62 W 2.05 W 600 MHz 1.45 W 1.85 W 408 MHz 1.33 W 1.72 W It appears a good upper bound for a headless setup is in the neighbourhood of 3 W, or the energy contained in 0.025 bananas per hour.\nGPU Architecture ARM Mali-450MP2 Dual-core GPU OpenGL ES 1.1 and 2.0, OpenVG1.1 System Memory LPDDR3 RAM Memory Variants: 1GB, 2GB and 4GB. ","permalink":"/documentation/ROCK64/_full/","tags":null,"title":"ROCK64 (Single Page)"},{"categories":null,"contents":" Rendering of the RockBox\nThe Popcorn Hour RockBox Basic is a TV box from the Cloud Media company in partnership with PINE64 and the PINE64 community. It is running a Rockchip RK3328 SoC and is supporting multiple different operating systems. The device is similar to the ROCK64 and runs some of its operating systems, it has a custom PCB and multiple hardware differences however.\nSpecifications Dimensions: 106mm x 106mm x 16.9mm Weight: 143 g CPU: Rockchip RK3328, Quad core Cortex-A53 @ up to 1.5GHz GPU: Mali-450MP2 System Memory: 1GB LPDDR3 Internal Storage: 8GB eMMC Connectivity: 802.11a/b/g/n, Ethernet 10/100 USB: 1x USB 2.0 OTG port, 1x USB 3.0 port Video Output: HDMI Standard HDMI 2.0a@60hz Audio Output: Via HDMI, Optical S/PDIF port Power Supply: DC 5V/2A Software Retro-Center’s R-Cade: 100+ retro-gaming systems, a lightweight web browser, and 4k UHD media center on the RockBox R-Cade Mrfixit2001’s Debian Minimal Release (note: can be updated to a more recent Debian using the regular updating tools, except for the kernel and u-boot) LibreELEC Rockchip (note: select LibreELEC-RK3328.arm-9.2.6-rockbox.img.gz) Hardware LEDs The blue LED can be controlled with via the sysfs (/sys/devices/platform/leds/leds/power/brightness):\nTo turn off the blue LED: echo 0 | sudo tee /sys/devices/platform/leds/leds/power/brightness\nTo turn on the blue LED: echo 1 | sudo tee /sys/devices/platform/leds/leds/power/brightness\nNote: the maximum brightness is defined as 255, it doesn’t support dimming however, so 0 and 1 as brightness is sufficient. Turning off the blue LED will turn on a weak red LED. Trigger can be changed via /sys/devices/platform/leds/leds/power/trigger.\nDevelopment Mainline Linux\nDisassembly\nUART\nMainline Linux Mainline Linux works on the RockBox without patches. To create a compatible u-boot image, https://github.com/mrfixit2001/uboot_builder may be used. The dtb has to be compiled from a recent dts, such as this, otherwise network and video won’t work.\nBuilding the dtb The dtb can be compiled from a recent dts. To do that, download a kernel source and add a dts, or use a kernel source with an fitting dts. The second variant is showcased here:\ngit clone https://github.com/mrfixit2001/mainline-kernel.git Then change the directory to the kernel sources:\ncd mainline-kernel Then create a config (defaults can be accepted):\nmake ARCH=arm64 menuconfig Now compile the dts files:\nmake ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j 12 dtbs The compiled dtb file can now be copied from /arch/arm64/boot/dts/rockchip/rk3328-rockbox.dtb into for example the EXTLINUX location.\nConfiguring EXTLINUX In the EXTLINUX location, the /extlinux/extlinux.conf should be pointed to the correct kernel image and the correct dtb file. An example configuration (with serial output with 1500000 baud being enabled for the OS and with the root directory set to the second partition mmcblk1p2) can look like the following example:\ndefault ROCKBOX label ROCKBOX kernel /Image fdt /rk3328-rockbox.dtb append console=tty0 console=ttyS2,1500000n8 rw root=/dev/mmcblk1p2 rootwait rootfstype=ext4 panic=10 init=/sbin/init coherent_pool=1M ethaddr=${ethaddr} eth1addr=${eth1addr} serial=${serial#} cgroup_enable=cpuset cgroup_memory=1 cgroup_enable=memory swapaccount=1 video=HDMI-A-1:1920x1080@60 loglevel=3 Disassembly The device can be easily disassembled by removing the four rubber feet and by unscrewing the four screws underneath them. The board is held in place by additional two black screws. Note: The board is connected to the main body with a cable.\nUART Internals of the RockBox with the UART contacts visible on the bottom right\nA serial console can be connected to the RockBox to retrieve the UART boot logs. A device such as a USB to TTL converter can be used to connect the RockBox. Simply set the USB device to 3.3 volts and connect GND to the GND connector on the mainboard, RTX to TX and TXD to RX. The fourth unlabelled contact on the mainboard should not be connected.\nNote Unlike the ROCKPro64, connecting TXD does not prevent the device from booting up. Connect the USB device to the PC and use a tool such as screen to display the serial output:\nscreen /dev/ttyUSB0 1500000 Then power up the RockBox and enjoy the serial output on the PC.\nTo enable UART output in the OS as well (otherwise the output would stop at \u0026ldquo;Starting kernel \u0026hellip;\u0026rdquo;), console=ttyS2,1500000n8 can be added to the append line in the /boot/extlinux.conf file when using EXTLINUX.\nExternal resources Retro Center online store R-Cade software detail PINE64 forum ","permalink":"/documentation/RockBox/_full/","tags":null,"title":"RockBox (Single Page)"},{"categories":["SBCs"],"contents":" ROCKPro64: A 64-bit Hexa-Core SBC with PCIe, USB 3.0, USB-C and Gigabit Ethernet Featuring up-to 4GB of LDDDR4 RAM The ROCKPro64 is the most powerful single board computer on offer from PINE64, featuring a Rockchip RK3399 hexa-core SoC as well as a quad-core Mali-T860 MP4 GPU and up-to 4GB of dual-channel LPDDR4 system memory. Moreover, the board comes packed with features, including an USB 3.0 and USB type C with DP1.2 port, a full PCIe x4 as well as eMMC module socket. You also get a 40pin header with I2C, SPI, UARTs and GPIOs. The board is backwards compatible with many of the existing PINE64 peripherals, including the Wifi/BT module, camera module and LCD panel but an array of new peripherals specific for the board is also available. All this in the exact same model “A” dimension as the original PINE A64.\nThe ROCKPro64 4GB board is designated as LTS (long Term Supply) which means that PINE64 is committed to supply it for at least 5 years – until year 2023 and beyond.\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.4GHz and 2 x ARM Cortex A72 cores @ 1.8 GHz GPU ARM Mali T860 MP4 GPU Memory LPDDR4 RAM (up to 4GB) Networking Gigabit Ethernet Storage Micro SD slot eMMC module slot SPI Flash 128Mbit Connections 4K digital video out 2x USB 2.0 Host 1x USB 3.0 Host 1x USB-C Host (With video out) PCIe 4x open-ended slot 40 GPIO pins Expansion bus PI-2 bus Touch Panel (TP) port Display Serial Interface (DSI) port eDP port Stereo MiPi-SCI port for 12MP cameras IR R/X port Real Time Clock (RTC) port Lithium battery port CMOS Sensor Interface port Optional 802.11ac with Bluetooth 5.0 expansion module 3.5mm headphone jack with mic input 5.5mm barrel power (12V 3A/5A) port Tons Of I/O 2xUSB 2.0 Host ports, 1xUSB 3.0 Host port, and 1xUSB-C Host with video out support\n40 GPIO Pins With 40 GPIO pins there is plenty for projects you may throw at the RockPro64\nPCIe 4x Slot PCIe 4x open-ended slot for attaching devices and extra storage\nPowerful Rockchip SoC The power RK3399 hexa-core SoC can handle most tasks you throw at it\nStores Global Global: Accessories Affiliates Documentation ROCKPro64 Schematics and certifications ","permalink":"/devices/rockpro64/","tags":null,"title":"ROCKPro64"},{"categories":null,"contents":" The ROCKPro64\nThe ROCKPro64 is the most powerful single-board computer released by PINE64. It is powered by a Rockchip RK3399 hexa-core (dual ARM Cortex A72 and quad ARM Cortex A53) 64-bit processor with a Mali T-860 quad-core GPU. The key features include a PCI Express (PCIe) x4 open-ended slot, the use of LPDDR4 DRAM, and industry-standard heatsink mounting holes.\nThe ROCKPro64 is equipped with 2 or 4 GB of LPDDR4 system memory, and 128 Mb of SPI boot flash. There is also an optional eMMC module (up to 128 GB) and microSD slot for booting. The board is equipped with 1x USB 3.0 Type-C host port with DP 1.2, 1x USB 3.0 Type-A host port, 2x USB 2.0 host port, Gigabit Ethernet, PI-2 GPIO bus, MiPi DSI interface, eDP interface, touch panel interface, stereo MiPi CSI interface, as well as many other device interfaces such as UART, SPI, I2C, for makers to integrate with sensors and other peripherals. Many different operating systems (OSes) are freely available from the open-source community, such as Linux (Ubuntu, Debian, Arch), BSD and Android.\nGetting started This section gives important information to get the board up and running.\nVideo Playback Hardware video acceleration is supported in recent kernels and user needs only to install the relevant Mesa packages/ports, specifically the Mesa DRI drivers for Mali GPUs (Midgard/Bifrost). One can confirm via software glxinfo, or having the library file such as \u0026hellip;/lib/dri/panfrost_dri.so.\nAyufan has some old documentation on video playback here. For your ROCKPro64 the install should be\nsudo apt-get install ffmpeg mpv libmali-rk-midgard-t86x-r14p0-gbm\n(These modules are included in the Ayufan desktop releases.) At which stage rkmpv myvideo.mp4 will play a fullscreen, hardware assisted, version of your video. rkmpv is at /usr/local/bin/rkmpv\nUsing an NVMe Disk as rootfs Forum member Bullet64 has documented how to move rootfs to an NVMe disk. This is useful until we get a full SPI option to boot from the NVMe.\nSetup a Serial Console (UART2) Warning RockPro64 is designed to use 3VDC3A (3 Volts Direct Current 3 Ampere) for the connection, using 5VDC and more might damage the board! To use Serial Console you will a need operating system that supports it on your RockPro64, by default the serial console is provided for baud 9 600 which is far too slow for rockpro64 so consider using 1 500 000 (1.5Mbps) instead IF your serial console device supports it (many doesn’t which results in their inability to use the console).\nWarning Do not connect RxD (pin 10) until the U-Boot SPL is running (see RK3399 boot sequence) or the SPL will not start.\nTo avoid this issue, a simple Serial Buffer Circuit can be installed between the RockPro64 and the serial adapter.\nIn terms of connections you need to perform the following from your serial console-capable device e.g. Pine64’s Woodpecker available in store:\nGND \u0026lt;-\u0026gt; GND (pin 6) RxD \u0026lt;-\u0026gt; TxD (pin 8) TxD \u0026lt;-\u0026gt; RxD (pin 10) After the configuration of your preferred operating system you can connect to the serial console using any of these commands:\n$ screen /dev/ttyUSB0 1500000 $ picocom /dev/ttyUSB0 -b 1500000 $ minicom -D /dev/ttyUSB0 -b 1500000 Note You might need a root permission if your user is not in the appropriate user-group e.g. dialup on GNU/Linux Alternatively there is a detailed guide on forums: https://forum.pine64.org/showthread.php?tid=6387\nGNU/Linux:\nWith GNU/Linux on your RockPro64 the built-in support for serial console can be enabled by parsing parse e.g. console=ttyS2,1500000n8 in the kernel command line, many distributions make this available by default, but consider verifying the contents of /boot/extlinux/extlinux.conf if you encounter issues. NOTE: the n8 in the kernel argument means no parity, 8 bits per character Booting from USB or PXE The default choice of boot device is first eMMC (if present) then SDcard. See ROCKPro64 under \u0026ldquo;jumpers\u0026rdquo; for details on adjusting this sequence.\nIt is possible to flash the SPI to extend the options for boot devices to USB drives or PXE. The preferred method is now the rock64_write_spi_flash.sh script (see useful scripts above).\nBackground info and historic details of this usage can be found here.\nBooting from SPI using u-boot Warning idbloader is not open-source Always be prepared to recover from a broken SPI boot BEFORE flashing or you will end up with a broken boot.\nIn general the recovery is killswitching SPI through shorting pins 23 \u0026lt;-\u0026gt; 25 together and then loading u-boot from a storage device e.g. SD-card or eMMC where majority of GNU distributions e.g. Manjaro usually have u-boot packaged with the provided images.\nFollow instructions in https://github.com/sigmaris/u-boot/wiki/Flashing-U-Boot-to-SPI#instructions-for-rockpro64\nBoot sequence The RockPro64 boot sequence has been documented here by sigmaris.\nOTG Mode You can boot your ROCKPro64 into OTG mode with the use of the Recover button (see switch 28 under Layout#Switches). Note that there are 2 OTG ports on your ROCKPro64: the type-C USB 3 socket is definitely one. From the schematic it appears the USB 3 (type A) socket is the other, but this has yet to be confirmed.\nThe method is to power off the board. Then push and hold the Recover button and push and release the Power button.\nIf you have an Ayufan bootable image in either the SD-card or eMMC then there are 4 OTG modes described here including Android fastboot, RockUSB and MaskROM modes. Releasing the Recover button as soon as the white LED lights counts as 1 blink. Keeping it pressed you will get 2 blinks of the white LED etc. Once the board enters OTG mode the red LED will be lit. In mode 1 the boot and linux-root partitions of the card with the Ayufan image (partitions 6 \u0026amp; 7 of a Linux installation) are made available as devices. In all cases the USB device made available at the host has device ID 18d1:d00d. If you do not have an Ayufan image in either the SD-card or the eMMC, then neither white nor red LEDs will light, but the board will enter MaskROM mode where the USB device made available at the host has device ID 2207:330c. NVMe Drives Please be aware that the PINE64 SSD interface card is intended for use with NVMe devices. These can be identified by the fact they have a single (Key M) notch, e. g. the WD Black devices.\nWhile M2/NGFF SATA devices (with a Key B notch, typically have Key M as well) will physically fit, they will not work. e. g. WD Blue devices.\nSATA Drives SATA drives can be connected directly via the ROCKPro64 PCIe interface card. Please note the card does not include the power cable - that is a separate item. Equally you must be aware that connecting SATA drives in this manner means they will be drawing power from your ROCKPro64 - please ensure you are using a 5A or better power supply.\nExplainingComputers did a YouTube ROCKPro64 PCIe SATA card review and tests using a Ubuntu console and OpenMediaVault.\nWi-Fi \u0026amp; Bluetooth Module If you have bought the Wi-Fi and Bluetooth module from the Pine store then instructions for connecting it can be found on the accessories page. Please note that the 0.7.9 Ayufan’s Linux releases (August 2018) have deliberately DISABLED support for this module in the search for stability. It can be tested and used with the Android image.\nIt can also be used on Manjaro by installing ap6256-firmware and wireless-regdb packages.\n7\u0026quot; LCD Touch Screen Instructions for connecting the LCD touch screen from the Pineare on the accessories page.\nNote at present (August 2018) this screen is only supported by the Android image.\nWarning When using the touchscreen ensure the cables are properly connected and tightened down and that you do not let the metal backplate touch the SBC RTC Battery Backup The Pine store has a couple of options for RTC battery backups: a AAA version here or a CR-2032 version here.. For the ROCKPro64, the backup plugs into the RTC connector, number 6 in the board layout diagram above, next to the USB3 and case screw point.\nBoard Features\nGPIOs\nLayout\nFeatures This section outlines the most important characteristics of the board and its components.\nSoC and Memory Specification The ROCKPro64 is based on the Rockchip RK3399.\nCPU Architecture Dual-core Cortex-A72 up to 2.0GHz CPU Quad-core Cortex-A53 up to 1.5GHz CPU big.LITTLE architecture: Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU Cortex-A72: 1-4x Symmetrical Multiprocessing (SMP) within a single processor cluster, and multiple coherent SMP processor clusters through AMBA 5 CHI or AMBA 4 ACE technology AArch64 for 64-bit support and new architectural features L1 cache 48KB Icache and 32KB Dcache for each A72 L2 cache 1024KB for big cluster DSP \u0026amp; SIMD extensions VFPv4 floating point Hardware virtualization support Cortex-A53: L1 cache 32KB Icache and 32KB Dcache for each A53 L2 cache 512KB for little cluster Full implementation of the ARM architecture v8-A instruction set ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation ARMv8 Cryptography Extensions In-order pipeline with symmetric dual-issue of most instructions Include VFP v3 hardware to support single and double-precision operations TrustZone technology support Full CoreSight debug solution One isolated voltage domain to support DVFS GPU Architecture ARM Mali-T860MP4 Quad-core GPU The highest performance GPUs built on Arm Mali’s famous Midgard architecture, the Mali-T860 GPU is designed for complex graphics use cases and provides stunning visuals for UHD content. Frequency: 650MHz Throughput: 1300Mtri/s, 10.4Gpix/s OpenGL® ES 1.1, 1.2, 2.0, 3.1, 3.2, Vulkan 1.0*, OpenCL™ 1.1, 1.2, DirectX® 11 FL11_1, RenderScript™. System Memory LPDDR4 RAM Memory Variants: Dual Channels 2GB and 4GB. Storage Memory: 128Mb built-in SPI Flash memory (as at August 2018 only support for USB boot). Display Dual VOP: one supports resolutions up to 4096x2160 and AFBC; the other supports resolutions up to 2560x1600 Dual channel MIPI-DSI (4 lanes per channel) eDP 1.3 (4 lanes with 10.8Gbps) to support displays, with PSR Digital Video port up to 4Kp60 DisplayPort 1.2 (4 lanes, up to 4K 60Hz) Supports Rec.2020 and conversion to Rec.709 Video Digital Video output up to 4K@60Hz 4K HDR @ 30fps H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4Kx2K @ 60fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4Kx2K @ 60fps VP9, up to 4Kx2K @ 60fps MPEG-1, ISO/IEC 11172-2, up to 1080P @ 60fps MPEG-2, ISO/IEC 13818-2, SP@ML, MP@HL, up to 1080P @ 60fps MPEG-4, ISO/IEC 14496-2, SP@L0-3, ASP@L0-5, up to 1080P @ 60fps VC-1, SP@ML, MP@HL, AP@L0-3, up to 1080P @ 60fps MVC is supported based on H.264 or H.265, up to 1080P @ 60fps Audio 3.5mm Phone Jack 3-pin S/PDIF header Audio via Digital Video port Camera Dual MIPI CSI, dual ISP, maximum input resolution of 13M pixels Network 10/100/1000Mbps Ethernet - Capable of pushing 941 MBit/s in iperf3 Wi-Fi 802.11 ac/a/b/g/n with Bluetooth 4.01 (old version with 2x2) / Bluetooth 5 (new version with 1x1) (optional) Storage microSD - bootable, supports SDHC and SDXC eMMC - bootable (optional eMMC module) 1x USB 3.0 host port 1x USB Type-C OTG port with alternate mode DP output 2x USB 2.0 dedicated host port Expansion Ports 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO header PCI Express 2.1 x4 (four full-duplex lanes) open-ended port, limited to the Gen1 speed Working Features Feature/Option Android Android Version Linux Linux Version Test/Verify Steps Notes Product Link PINE64 LCD Touchscreen (Screen/Touch) Yes/Yes No/No Maybe this will help get this working? 7-inch LCD Touch Screen Panel Wireless ROCKPro64 2×2 MIMO Dual Band WiFi 802.11AC / Bluetooth 4.2 Module (old) ROCKPro64 1x1 Dual Band WiFi 802.11AC / Bluetooth 5.0 Module (new) Yes/Yes No/Yes* For the \u0026ldquo;new\u0026rdquo; ROCKPro64 WIFI module: Verified with Manjaro ARM (kernel 6.2.5). A config file (\u0026ldquo;firmware file\u0026rdquo;) is needed at /lib/firmware/brcm/brcmfmac43455-sdio.txt. In 0.7.9 Ayufan linux releases this is deliberately disabled for stability reasons. On Manjaro ARM (kernel 6.2.5), WIFI seems to be stable with the firmware file. On a 5GHz network (802.11AC), it is possible to get about 120Mbps using the \u0026ldquo;new\u0026rdquo; ROCKPro64 WIFI module. ROCKPro64 1x1 Dual Band WiFi 802.11AC / Bluetooth 5.0 Module USB OTG Configure ip on usb0: ifconfig usb0 169.169.222.222 and run iperf, you should likely see about 200-300MB/s ROCKPro64 USB Mass Storage USB2/USB3 Yes/yes Yes/Yes Dedicated Fan Power (pwm1) Yes You might want to use ATS. GPIO pins (raw or via RPI python scripts) Check out what Frank Mankel has done. MIPI CSI Camera 1 and 2 eDP HDMI Audio Yes 7.1.2 Yes 4.4.132-1083 - 4.4.138-1100 Stopped working in 4.4.154.1105. Ayufan is looking into it. This is working in Manjaro ARM (kernel 6.2.5). Select the Analog Output (Built-in Audio Stereo) option in the audio output device selection window (either use pavucontrol or the volume button in the KDE desktop). Despite the slightly misleading name, audio does go through the HDMI port. See here for details: https://forum.manjaro.org/t/no-hdmi-audio-on-rockpro64/25595/2. 3.5mm Audio/Mic USB-C Host Display via USB-C Yes 7.x and 8.x eDP via USB-C per tillim. No sound on Android 7.x. Sound does work on Android 8.x ROCKPro64 PLAYBOX ENCLOSURE N/A N/A N/A Ventilation does not exist, thus requires manual changes to add venting. Case should be modified to account power adapter not being centered in cut holes. Opening the case once close without modifying it first is nearly impossible without special tools. Graphene heatsink is included and does well for Linux but not Android. ROCKPro64 Playbox Enclosure ROCKPro64 30mm Tall Profile Heatsink N/A N/A N/A ROCKPro64 30 mm Tall-Profile Heatsink ROCKPro64 20mm Mid Profile Heatsink N/A N/A N/A ROCKPro64 20 mm Mid-Profile Heatsink Fan For ROCKPro64 20mm Mid Profile Heatsink N/A N/A N/A You might want to use fanctl to control the fan while keeping your CPU cool Fan For ROCKPro64 20 mm Mid-Profile Heatsink HDMI output 4K@60Hz PCI Express 2.1 The PCI Express interface of the RK3399 is limited to the Gen1 speed. As a result, some installed PCI Express devices may operate with degraded performance, such as M.2 SSDs that support fewer than four PCI Express lanes, installed using an adapter like this one. Real Time Clock (RTC) battery backup RTC Backup Battery Holder CR2032 Boot from USB/PXE RockChip themselves have tables of supported features at 4.4 and mainline kernel versions in their wiki here.\nGPIOs GPIO Pins Assigned To Pin Nr. Pin Nr. Assigned To 3.3 V 1 2 5 V GPIO1_C4 (I2C8_SDA) ^a^ 3 4 5 V GPIO1_C5 (I2C8_SCL) ^a^ 5 6 GND GPIO4_D0 (CPU_GPCLK) 7 8 GPIO4_C4 (UART2_TX) GND 9 10 GPIO4_C3 (UART2_RX) GPIO1_C6 11 12 GPIO3_D0 (I2S0_CLK) GPIO1_C2 13 14 GND GPIO1_A1 15 16 GPIO1_A4 3.3 V 17 18 GPIO4_C5 [SPDIF] [UART4_TX] GPIO1_B0 (SPI1_TXD) 19 20 GND [UART4_RX] GPIO1_A7 (SPI1_RXD) 21 22 GPIO4_D1 GPIO1_B1 (SPI1_CLK) 23 24 GPIO1_B2 (SPI1_CSN0) GND 25 26 GPIO1_B5 GPIO1_B3 (I2C4_SDA) 27 28 GPIO1_B4 (I2C4_SCL) GPIO4_D3 29 30 GND GPIO4_D4 31 32 GPIO3_D4 (I2S0_SDI1SDO3) GPIO3_D5 (I2S0_SDI2SDO2) 33 34 GND GPIO3_D2 (I2S0_LRCKTX) 35 36 GPIO3_D6 (I2S0_SDI3SDO1) GPIO3_D1 (I2S0_LRCKRX) 37 38 GPIO3_D3 (I2S0_SDI0) GND 39 40 GPIO3_D7 (I2S0_SDO0) Notes:\npulled high to 3.3V through 2.2kOhm resistor Linux /dev/gpiochip Assignments Pin Nr. Chip Line 3 1 20 5 1 21 7 4 24 8 4 20 10 4 19 11 1 22 12 3 24 13 1 18 15 1 1 16 1 4 18 4 21 19 1 8 21 1 7 22 4 25 23 1 9 24 1 10 26 1 13 27 1 11 28 1 12 29 4 27 31 4 28 32 3 28 33 3 29 35 3 26 36 3 30 37 3 25 38 3 27 40 3 31 On Linux, using the new /dev/gpiochip API, the _n_ in GPIO_n___XX_ appears to correlate to the number of the /dev/gpiochip_n_, and the _XX_ to the definition RK_P_XX_ of lines in include/dt-bindings/pinctrl/rockchip.h of the Linux kernel source. Having these named in the dts would be nice.\nYou can use libgpiod to drive them, and test them with the included tools (gpioinfo, gpioset, \u0026hellip;)\nFor example, gpioset 4 25=1 (run as root) would turn pin 22 on. Do beware that poking the wrong GPIO pin can lock up your system.\nThe conversion table at right is also available as a C header file.\nLayout Main Chips RK3399 system-on-chip (1) LPDDR4 SDRAM 1 (18) LPDDR4 SDRAM 2 (3) SPI NOR flash memory (17) RK808 power management (near 19) RTL8211 ethernet transceiver (near 25) ES8316 Sound Codec (on rear of board) The heatsink mounting holes around the RK3399 are 59 mm apart Switches The Power button (11, SW3): is the same as on your mobile phone - press and release after about 1 second to power on. Press and hold for about 3 seconds to power off.\nThe Reset button (10, SW901): performs a reset.\nThe Recover button (28, SW900): used to enter maskrom mode.\nConnectors, Sockets and Headers Diagram Schematic designator Silkscreen label Number of pins Description 2 U39 PI-2-bus 40 Pi-2 bus 4 J8 +FAN- 2 PWM controlled fan header 5 J10 SPDIF 3 SPDIF header 6 U6 +RTC- 2 RTC battery backup header 7 U31 Wifi-BT 16 SDIO WIFI/BT module-MIMO 2 8 USB3 9 USB-3 and USB Type C 9 USB1 2×4 Dual USB-2 12 IR1 IR 3 infrared receiver socket 13 J16 Headphone+mic 4 Headphone + mic 3.5mm jack - CON16 GND PWR RST GND 4 Power \u0026amp; reset, unpopulated header near Headphone jack 14 U29 EMMC 34 eMMC connector (Note: Some datasheets indicate a low supported number of mating cycles.) 14* J13 13 TF-card, a.k.a. microSD (* under 14 on the bottom side) 15 U30 14 SDIO WIFI/BT module-MIMO 1 16 SW4 2 Jumper to Disable eMMC 19 J15 PCI 64 PCI-express X4 socket 20 J21 DSI 30 DSI 21 J22 EDP 30 LCD EDP 22 CON1 TP 6 touch panel connector 23 CON15 4 DC out for SATA disk cable (direct connect from DC-IN) 24 J11 DC-IN 2 Power input, positive tip; 12V/3A (minimum) recommended 25 U32 8 8P8C (often referred to as \u0026lsquo;RJ45\u0026rsquo;) 26 J14 19 HDMI 27 J17 MIPI CAM 32 MIPI-1 29 J19 MIPI CAM 32 MIPI-2 30 J18 CIF 26 CIF LEDs A green LED next to the 12V input barrel connector will light as long as there is 12V applied to the connector. (Even if the RockPro64 is powered off.)\nA white LED behind the reset button will light as long as the RockPro64 is running (it comes on a few seconds after power on, when control is passed to the operating system.)\nA red LED behind the reset button is DIY - it is lit for example if the board is in OTG mode with an Ayufan image, or if an Android image is in standby mode.\nYellow and green LEDs on the LAN socket behave in a standard way.\nJumpers They are used for boot device selection, as described in the following section.\nDisable eMMC There is an unlabelled (on the PCB silk-screen) 2-pin jumper (16) between the eMMC socket (14) and the SPI chip (17). It is designated as SW4 on the schematic diagram under \u0026ldquo;Board Information, Schematics and Certifications\u0026rdquo;. The default condition is OPEN (no jumper). It is useful for controlling the boot as follows:\nDefault boot device (with no SPI software) is eMMC, then SDcard. If both the eMMC and the SDcard contain bootable images then the eMMC can be disabled by installing the jumper. This completely removes the eMMC from the resulting OS. If you wish the eMMC to be visible in the booted OS the jumper should be removed 2 seconds after applying power (and before the white LED comes on).\nThe possible combinations are summarised in the table below.\n1 = present 0 = not present µSD eMMC SW4 boot from 0 0 0 unsupported 0 0 1 unsupported 0 1 0 eMMC 0 1 1 unsupported 1 0 0 SDCard 1 0 1 SDCard 1 1 0 eMMC 1 1 1 SDCard Disable SPI (while booting) There is a second possibility to jumper your ROCKPro64: If you mess-up your SPI and are unable to boot, jumpering pins 23 (CLK) and 25 pin (GND) on the PI-2-bus header will disable the SPI as a boot device. (This was taken from the IRC logs, 09 August 2018 @ 17:23) You have to remove the jumper 2 seconds after having started your RP64 (before the white LED turns ON) otherwise the SPI will be missing and you won’t be able to flash it. Ayufan images contain (at the moment) only one script for the SPI and the RP64, it’s \u0026ldquo;rockpro64_reset_spi_flash\u0026rdquo;. Other SPI scripts are dedicated to the R64 (as it is written on the name) and it will mess-up your RP64 SPI if you use them.\nSoftware Device Tree Overlays on Mainline\nInstalling Arch Linux ARM\nReleases\nReleases This page contains a list of all available releases and tools for the ROCKPro64 in alphabetical order.\nLinux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. Originally AnthonOS (an OpenSUSE derivative built with SUSE Studio), then remade as a Debian derivative with customized KDE 4 UI and CJK support. To learn more about AOSC, please visit the official AOSC website\nDownload:\nhttps://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more) Default credentials aosc anthon Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored. To find out more about Armbian and available options please visit their site. If you are booting from a Micro SD card, then both Linux kernel versions will work. If you are trying to boot from an eMMC module then the 4.4.y will work, but the newer 5.10.y will not.\nDownload:\nhttps://armbian.com/boards/rockpro64 Batocera Linux Batocera Linux is an open-source and completely free retro-gaming distribution that can be copied to a USB stick or an SD card with the aim of turning any computer/nano computer into a gaming console during a game or permanently. Visit the project’s website here (https://batocera.org/). You can follow the ongoing discussion about batocera.linux on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=7084)\nDownload:\nhttps://batocera.org/download Debian Debian is an operating system and a distribution of free software. See the forum thread here.\nDownload:\nDebian 13 Trixie Debian 12 Bookworm Daily netboot images Instructions:\nDownload: firmware.rockpro64-rk3399.img.gz Download: partition.img.gz Create the disk image: For Linux: zcat firmware.rockpro64-rk3399.img.gz partition.img.gz \u0026gt; complete_image.img For Mac: gzcat firmware.rockpro64-rk3399.img.gz partition.img.gz \u0026gt; complete_image.img Write the image to your boot device: For Linux: dd if=complete_image.img of=your_chosen_boot_device bs=4M For Mac: see Getting started Notes:\nAn Ethernet connection is required for the above installer Remember to leave some space before your first partition for u-boot! You can do this by creating a 32M size unused partition at the start of the device. See the troubleshooting section if you encounter issues with GPU acceleration. DietPi DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the ROCKPro64 build on the PINE64 forum thread.\nDownload:\nDirect download from dietpi.com Default credentials root dietpi LibreELEC LibreELEC is a lightweight \u0026lsquo;Just enough OS\u0026rsquo; Linux distribution purpose-built for Kodi on current and popular mediacentre hardware.\nDownload:\nOfficial LibreELEC build image (look for PINE64 RockPro64-LibreELEC-RK3399.arm-x.x.x-rockpro64.img.gz, supports microSD card and the eMMC module of 8GB or more.) Note Unzip and flash the image to a microSD card or eMMC module, for example using dd. Nems Linux NEMS stands for Nagios Enterprise Monitoring Server and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more about NEMS on the PINE64 and available tweaks to the installation please visit the PINE64 forum thread.\nDownload:\nDownload page with torrent seed or direct download. Default credentials nemsadmin nemsadmin NixOS NixOS is a Linux distribution built on top of the Nix package manager using declarative configuration to allow reliable system upgrades. More information can be found on the NixOS wiki.\nDownload:\nnixos-installer-rockpro64 OpenMediaVault OpenMediaVault is the next generation network attached storage (NAS) solution, click this link to OMV main page to learn more. Forum thread concerning this release can be found here\nDownload: Warning Outdated release Stretch 32bit (armhf): Direct download from ayufan’s github Stretch 64bit (aarch64): Direct download from ayufan’s github Notes:\nYou need to enable root login in OMV WebGUI OpenMediaVault Plugins can enhance the system Default credentials rock64 (TTY and SSH, except OMV) rock64 admin (WebGUI Login) openmediavault root (TTY and SSH) openmediavault OpenWrt OpenWrt ​is a highly extensible ​GNU/​Linux ​distribution for embedded devices ​(typically wireless routers). Unlike many other distributions for these routers, OpenWrt ​is built from the ground up to be a full-featured, easily modifiable operating system for your router. In practice, this means that you can have all the features you need with none of the bloat, powered by a Linux kernel ​that’s more recent than most other distributions.\nDownload:\nhttps://toh.openwrt.org/?view=normal\u0026brand=pine64 postmarketOS postmarketOS extends Alpine Linux to run on smartphones and other devices. At the time of writing, the only user interface provided through prebuilt images for the ROCKPro64 is Plasma Bigscreen.\nDownload:\nhttps://postmarketos.org/download/ Default credentials user 147147 R-Cade Retro Center’s R-Cade, the 4K Media Center Arcade. RCade Features 100+ retro-gaming systems, a lightweight web browser, and full 4K UHD media playback.\nDownload:\nDirect download from Retro Center’s GitHub (USB, microSD and eMMC boot) Recalbox Recalbox allows you to re-play a variety of videogame consoles and platforms in your living room, with ease|Visit the project’s website here (https://www.recalbox.com/). You can follow the ongoing discussion about Recalbox on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=7194)\nDownload: {{Template:Outdated release}}\ndownload release from mrfixit2001 github. SkiffOS Minimal cross-compiled OS optimized for hosting distributions in Docker containers. Provides the reliability of firmware with the ease-of-use of package managers. Uses the Buildroot cross-compilation tool for support for all Pine64 boards.\nUse configuration packages to configure the distribution:\ncore/gentoo: Gentoo optimized for Rockpro64 core/nixos: NixOS arm64 You can also configure the skiff core yaml file to configure multiple distributions to run in parallel.\nThe boot-up OS can be upgraded independently from the containers.\nDownload:\nThe repository and instructions can be found here. Slackware Slackware is the world’s oldest actively developed Linux distribution, providing a modern user land (applications) and Linux Kernel, within a more classic Unix Operating System environment.\nResources:\nInstallation instructions. Installation video guide slarm64 slarm64 is an unofficial aarch64 / riscv64 Slackware Linux port. You can follow the ongoing discussion about slarm64 on the RockPro64 on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=6823) or this forum thread for more general slarm64 information: https://www.linuxquestions.org/questions/slackware-arm-108/slarm64-aarch64-unofficial-slackware-4175613287/.\nDownloads:\ndownload (supports microSD card, look for slarm64-current-aarch64-xfce-rockpro64-x.xx.x-build-xxxxxxxx.img.zst) Default credentials root password Flashing the distribution to the eMMC:\nFlash the image to micro SD, power up the board with micro SD and login Copy the image file to micro SD by using SFTP. The image file must have the .img file extension. After finish copy the file, power off the board and add eMMC module to the board Boot the board, run below command for flashing to eMMC module Run dd if=[image file] of=/dev/mmcblkX bs=10M (example: sudo dd if=slack-current-aarch64-xfce_29Sep18-4.4.162-rockpro64-build-20181126.img of=/dev/mmcblkX bs=10M) then edit these two files in eMMC module: mount /dev/mmcblk1p1 /media echo \u0026quot;rootdev=/dev/mmcblk1p1\u0026quot; \u0026gt;\u0026gt; /media/boot/uEnv.txt sed -i 's:mmcblk0p1:mmcblk1p1:' /media/etc/fstab After that, power off the board and remove the microSD card. Then boot with only the eMMC module. Void Linux Void Linux is a general purpose operating system, based on the monolithic Linux kernel. The official guide can be found at Guide. At this time there are no RockPro64 images available.\nThe following creates a bootable image from an existing Void Linux installation:\nxbps-insall -Syu to update the xbps installation of the installation create ROCKPro64 image with the void-mklive software (from github.com): create a rootfs via mkrootfs.sh: sh mkrootfs.sh -o void-aarch64-muls-ROOTFS-yyyymmdd.tar.xz sh mkplatformfs.sh rockpro64 void-aarch64-muls-ROOTFS-yyyymmdd.tar.xz sh mkimage.sh -s 7GiB void-rockpro64-PLATFORMFS-yyyymmdd.tar.xz write image to sdcard or eMMC: dd if=IMAGE-FILENAME of=DEVICENAME bs=2M If mkplatformfs.sh errors with ROCKPro64 not supported, install xbps-src from https://github.com/void-linux/void-packages and build the ROCKPro64 package. Tip: write a new U-Boot to the image if you see on the serial console the boot-up stalls: get the two U-Boot files from pkgs.org, the aarch64 files: dd if=idbloader.img of=DEVICENAME seek=64 dd if=u-boot.itb of=DEVICENAME seek=16384 Default credentials voidlinux voidlinux BSD Images FreeBSD FreeBSD is an operating system used to power modern servers, desktops, and embedded platforms. The RockChip FreeBSD page has instructions for installing FreeBSD. Version 13.0 and greater include prebuilt images.\nDownload:\nImages for various FreeBSD releases can be found here Default credentials freebsd (SSH user, SSH enabled by default) freebsd root root Notes:\nThe wiki has instructions on enabling the PWM cooling fan. NetBSD Download:\ndownload latest release build from NetBSD by select 64bit - RockPro64 (size: 339 MB) Default credentials root (root user and SSH login) none Notes:\nInstructions concerning enabling SSH can be found here or the bootable image from armbsd.org can have the MSDOS partition modified to setup SSH using this method. OpenBSD OpenBSD is a security-focused, free and open-source, Unix-like operating system based on the Berkeley Software Distribution. Official instruction to get OpenBSD on ROCKPro64 is here, and blogs on installation is here and here. Forum discussion is here.\nAndroid Android 9.0.0 Stock for DD method [eMMC Boot] [20200804]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization Supports new RockPro64 AP6256 Wifi/BT module Support Sony IMX214 camera module and works on both MiPi-CSI ports This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image for 8GB eMMC module Direct download from pine64.org MD5 (GZip file): 7287fd0846616354615c8d3eff6a2a92 File Size: 602MB DD image for 16GB eMMC module Direct download from pine64.org MD5 (GZip file): 78352bbf21198d062af8bab2217ee691 File Size: 611MB DD image for 32GB eMMC module Direct download from pine64.org MD5 (GZip file): c5c8dce419478f75f85f893ee4808dbd File Size: 624MB DD image for 64GB eMMC module Direct download from pine64.org MD5 (GZip file): aab1cf4d30c4d16e6ce2672f3ecae935 File Size: 666MB Stock for RK Flash tool [eMMC Boot] [20200804]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Direct download from pine64.org MD5 (GZip file): 9ac830527814521e15b009fa2503c9e3 File Size: 589MB Stock for DD method [eMMC Boot] [20200708]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization Supports new RockPro64 AP6256 Wifi/BT module This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image for 8GB eMMC module Direct download from pine64.org MD5 (GZip file): ef5f5a890a9270734e0adee21f006837 File Size: 597MB DD image for 16GB eMMC module Direct download from pine64.org MD5 (GZip file): 179bd684a468f800a86f7c658a543bef File Size: 606MB DD image for 32GB eMMC module Direct download from pine64.org MD5 (GZip file): d930b757c4427be07b83c37a9c8494a1 File Size: 630MB DD image for 64GB eMMC module Direct download from pine64.org MD5 (GZip file): 09a970d68a10bdb3d6495d55860940e6 File Size: 660MB Stock for RK Flash tool [eMMC Boot] [20200708]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Direct download from pine64.org MD5 (GZip file): 6d060ddd47ebcfd5cfcdbf90ec042c97 File Size: 589MB Stock for DD method [eMMC Boot] [20190427]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization Please ignore \u0026ldquo;internal problem with your device\u0026rdquo; popup message if appear on Android boot-up page. This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image for 16GB eMMC module Direct download from pine64.org MD5 (GZip file): 3BA4C72D81BCFC4C21B3B5D2BCB4F9F7 File Size: 609MB DD image for 32GB eMMC module Direct download from pine64.org MD5 (GZip file): 4965CCF50A8F06CEB2E4A6828A21F31C File Size: 627MB DD image for 64GB eMMC module Direct download from pine64.org MD5 (GZip file): 748EC28FE5D5395D33E858C913D744BF File Size: 663MB Stock for DD method [microSD Boot] [20190506]\nDD image to microSD card and boot. Use \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization Please ignore \u0026ldquo;internal problem with your device\u0026rdquo; popup message if appear on Android boot-up page. This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image for 8GB microSD card Direct download from pine64.org MD5 (GZip file): E1C551E8106E178841E1C3F71432194A File Size: 599MB DD image for 16GB microSD card Direct download from pine64.org MD5 (GZip file): 73592FDD5A2F52F08020F16AD99E8C8C File Size: 609MB DD image for 32GB microSD card Direct download from pine64.org MD5 (GZip file): 74DE0FE528F210E4DD483B411A71904B File Size: 627MB DD image for 64GB microSD card Direct download from pine64.org MD5 (GZip file): D7626BD50443A88AEB9254C88C575284 File Size: 663MB Stock for RK Flash tool [eMMC Boot] [20190427]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (GZip file): 046BA4A07933120809FBE1B9577B7341 File Size: 592MB Android 8.1.0 Stock for DD method [eMMC Boot] [20180828]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (XZ file): 9AEE21BC1B9DE886DCB0E64FA123988A File Size: 414MB Stock for DD method [microSD Boot] [20181212]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) DD image (for 8GB microSD card and above) Direct download from pine64.org MD5 (XZ file): 5A6BB7FCD7B3F77FCEE99CE462AE7405 File Size: 616MB Stock for RK Flash tool [eMMC Boot] [20180828]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (XZ file): 4DACFE927BB09EE9C56B5232A7F624EE File Size: 415MB Android 7.1.2 Stock for DD method [eMMC Boot] [20180518]\nUse \u0026lsquo;dd\u0026rsquo; to write the image to the eMMC module using the USB-to-eMMC adapter module and boot. Using Etcher or another specialized SD writing tool is preferred. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (XZ file): 33622034ACDBC31A7D7BB01ED634E29B File Size: 345MB Stock for RK Flash tool [eMMC Boot] [20180518]\nPlease unzip first and then using Android tool to flash in The OTG port located at USB type-C connector, needs USB type A to type C cable. Please allow 3-5 minutes boot up time on first time for initialization This build supports PINE64 7\u0026quot; LCD panel with tablet UI (not Android TV) Direct download from pine64.org MD5 (XZ file): 90C1991DADAE13ADC94E927F171F8920 File Size: 342MB Android SDK Android P SDK [v9.0]\nDirect Download from pine64.org MD5 (TAR-GZip file): 3CEBEEFD1A873BEEEC149148A785D92E File Size: 125.16GB Slash TV OS Android 7 based system including Play Store, working only from SD card (does not boot when installed on eMMC)\nhttps://drive.google.com/drive/folders/1K5YhWaB7Xstuv2HCo1HkpglCEm9x-RIM Development resources The Ayufan github page\ngithub.com/ayufan-rock64/linux-build/ Below are the LPDDR4 driver for RK3399\nrk3399_loader_v1.10.112_support_1CS.bin, this is 800Mhz version used in Android Build rk3399_ddr_666MHz_v1.11.bin, this is alpha version rk3399_ddr_933MHz_v1.11.bin, this is alpha version ROCKPro64 related files\nROCKPro64 Kernel file trust.img Miscellaneous tools Windows ADB driver package MAC address Guide to install stock Android build to eMMC module Tools to burn Android build into a bootable microSD card Tools that allows developer flash image into eMMC’s Loader/Parameter/Misc/Kernal/Boot/Recovery/System/Backup partition Device Tree Overlays on Mainline If your U-Boot has been compiled with CONFIG_OF_LIBFDT_OVERLAY (which Manjaro’s is), adding device tree overlays the mainline way is very simple and easy.\nWriting Your Device Tree Overlay First off, you’ll have to write a device tree overlay. In this example, we’ll enable the ROCKPro64’s I2C bus that’s exposed to the pin headers, and declare that a PCF8574 GPIO extender is hanging off it.\n/dts-v1/; /plugin/; \u0026amp;i2c8 { status = \u0026#34;okay\u0026#34;; #address-cells = \u0026lt;1\u0026gt;; #size-cells = \u0026lt;0\u0026gt;; pcf8574: pcf8574@20 { compatible = \u0026#34;nxp,pcf8574\u0026#34;; reg = \u0026lt;0x20\u0026gt;; gpio-controller; #gpio-cells = \u0026lt;2\u0026gt;; }; ; We’ll go through this file line by line.\n/dts-v1/; specifies that this file is a DTS file. /plugin/; specifies that this is not just a regular device tree source file, but an overlay. \u0026amp;i2c8 { references the i2c8 node in the device tree we’re applying on top of, meaning we’re going to modify this specific part of it. status = \u0026quot;okay\u0026quot;; enables the i2c8 node. It’s set to \u0026ldquo;disabled\u0026rdquo; in the tree we’re applying on top of, specifying the property like this overrides it. #address-cells = \u0026lt;1\u0026gt;; is already set in the base tree, but since the compiler doesn’t know what the base tree is, it’ll yell at us if we don’t set this. #size-cells = \u0026lt;0\u0026gt;; same as above. pcf8574: pcf8574@20 { adds a child node labelled pcf8574 to the i2c8 node, which is a PCF8574 controller at address 0x20. compatible = \u0026quot;nxp,pcf8574\u0026quot;; the compatible string of the node, letting the kernel know what driver it needs to load for it. reg = \u0026lt;0x20\u0026gt;; the I2C address the device is listening on, in hexadecimal. gpio-controller; declares that this node is a GPIO controller. #gpio-cells = \u0026lt;2\u0026gt;; required for GPIO controllers. Assuming we’ve saved this as pcf8574.dts, we can compile it as follows:\ndtc -O dtb -o pcf8574.dtbo -@ pcf8574.dts This creates a compiled pcf8574.dtbo from the pcf8574.dts input file, and with -@ we preserve the labels of nodes, which in turn allows something to more easily overlay onto this overlay.\nLoading It Next, copy your compiled device tree overlay file—in the previous example pcf8574.dtbo*—somewhere into your /boot, for example */boot/dtbs/overlays/.\nThen we modify /boot/extlinux/extlinux.conf and add the line emphasised in bold to it:\nLABEL Manjaro ARM KERNEL /Image FDT /dtbs/rockchip/rk3399-rockpro64.dtb *FDTOVERLAYS /dtbs/overlays/pcf8574.dtbo* APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 root=LABEL=ROOT_MNJRO rw rootwait quiet splash plymouth.ignore-serial-consoles To specify multiple overlays, simply separate them with space on the same line.\nNow after a reboot, the device tree overlay file should be applied, and your kernel will see the new device. You can confirm this by dumping the device tree the kernel uses, and grepping it for whatever you added:\ndtc -I fs /sys/firmware/devicetree/base | grep -A4 \u0026#39;pcf8574\u0026#39; Further Reading Linux Kernel Documentation - Devicetree Overlay Notes Embedded Linux Wiki - Device Tree Usage CounterPillow’s overlay-examples repository Installing Arch Linux ARM Warning This page is a work in progress, use at your own risk Commands to be run as a normal user are prefixed with $, commands to be run as root are prefixed with #. We assume your target device is /dev/sdX, adjust accordingly.\nObtaining and Building U-Boot And TF-A The first step is to compile the open firmware (TF-A) and the open bootloader (u-boot).\nClone u-boot git repository:\n$ git clone https://source.denx.de/u-boot/u-boot.git Clone TF-A git repository:\n$ git clone https://github.com/ARM-software/arm-trusted-firmware.git Build TF-A (you will need aarch64-linux-gnu-gcc and arm-none-eabi-gcc for this)\n$ cd arm-trusted-firmware $ make realclean $ make CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 Next, export the path to your compiled BL31 in the shell you’ll build u-boot in. Adjust the path as necessary.\n$ export BL3/path/to/arm-trusted-firmware/build/rk3399/release/bl31/bl31.elf Build U-Boot (you may need to install additional packages to successfully compile, such as bc, python-pyelftools, or swig):\n$ make mrproper $ make rockpro64-rk3399_defconfig $ make CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) Preparing The Block Device Here we assume your block device is /dev/sdX, adjust as needed.\nCreate a new partition table:\n# parted -s /dev/sdX mklabel gpt Create the partitions for loader and u-boot:\n# parted -s /dev/sdX mkpart loader 64s 8MiB # parted -s /dev/sdX mkpart uboot 8MiB 16MiB Create the partition for u-boot’s environment (optional, but you’ll have to adjust the following offsets if you don’t do it):\n# parted -s /dev/sdX mkpart env 16MiB 32MiB Create the \u0026ldquo;efi\u0026rdquo; boot partition and mark it as bootable:\n# parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB # parted -s /dev/sdX set 4 boot on Create the root partition:\n# parted -s /dev/sdX mkpart root ext4 544MiB 100% Creating The File Systems Now create the file systems for boot and root:\n# mkfs.vfat -n \u0026#34;efi\u0026#34; /dev/sdX4 # mkfs.ext4 -L \u0026#34;rootfs\u0026#34; /dev/sdX5 Flashing U-Boot Flash idbloader.img and uboot.img:\n# dd if=idbloader.img of=/dev/sdX1 # dd if=u-boot.itb of=/dev/sdX2 Fetching The Root File System Tarball Fetch the root filesystem tarball and the PGP signature\n$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} Fetch the gpg keys:\n$ curl \u0026#39;https://keyserver.ubuntu.com/pks/lookup?op=get\u0026amp;search=0x68b3537f39a313b3e574d06777193f152bdbe6a6\u0026#39; | gpg --import=- Compare the key ID provided in the above command with the one listed here: https://archlinuxarm.org/about/package-signing (Take good note of the domain and HTTPS)\nVerify the tarball’s authenticity\n$ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig Important Do not skip verifying the authenticity. This is important. It also protects you from prematurely aborted transfers giving you a corrupt archive. Installing The Root File System # mount /dev/sdX5 /mnt/alarm-root # mkdir /mnt/alarm-root/boot # mount /dev/sdX4 /mnt/alarm-root/boot # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/alarm-root Editing fstab Find your partition UUIDs for both partitions using lsblk:\n$ lsblk -o NAME,SIZE,MOUNTPOINTS,PARTUUID In /mnt/alarm-root/etc/fstab, put the lines\nPARTUUID=_root-uuid-here_ / ext4 defaults 0 1 PARTUUID=_boot-uuid-here_ /boot vfat defaults 0 2 with your UUIDs in place of the placeholder.\nWriting extlinux.conf Create a /mnt/alarm-root/boot/extlinux/extlinux.conf with these contents:\ndefault l0 menu title ROCKPro64 Boot Menu prompt 0 timeout 50 label l0 menu label Boot Arch Kernel linux /Image fdt /dtbs/rockchip/rk3399-rockpro64.dtb append initrd=/initramfs-linux.img earlycon=uart8250,mmio32,0xff1a0000 console=ttyS2,1500000n8 root=LABEL=rootfs rw rootwait Once done, unmount the partitions:\n# umount /mnt/alarm-root/boot # umount /mnt/alarm-root Finishing Setup SSH in as root with password root and run\n# pacman-key --init # pacman-key --populate archlinuxarm Troubleshooting No Video or GPU Acceleration on Debian If you can log in through serial but don’t get any video or GPU acceleration on Debian, this is likely due to Debian’s decision to compile the devfreq governors as loadable modules but not including them early enough for panfrost to be able to be provided with one of them.\nThe usual sign of this being the case is the following line in the kernel log: [drm:panfrost_devfreq_init [panfrost]] **ERROR** Couldn’t initialize GPU devfreq\nTo fix this issue, run the following as root and reboot:\necho governor_simpleondemand \u0026gt;\u0026gt; /etc/initramfs-tools/modules update-initramfs -u -k $(uname -r) PCIe probe failures on Linux kernel boot While booting the Linux kernel, you might experience PCIe probe failures, which render the attached PCIe device inaccessible. The \u0026ldquo;drivers: pci: introduce configurable delay for Rockchip PCIe bus scan\u0026rdquo; thread on the Linux kernel mailing list (LKML) discusses this issue and proposes a fix.\nManjaro ARM applies the following patches to the kernel package, which fix the issue:\n1005-rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch 1007-arm64-dts-rockchip-Add-PCIe-bus-scan-delay-to-RockPr.patch Hardware 3D printable ITX mounting brackets\nCases\nHardware tweaks\nHardware compatibility\nPowering From An ATX Supply\nSerial buffer circuit\nHardware tweaks Enabling PCIe 2.0 Warning The downgrade to Gen1 speed came straight from Rockchip, as a result of an undisclosed RK3399 hardware errata. Thus, enabling Gen2 back may cause system instability or data corruption under certain circumstances. Also, the limitations of the RK3399’s internal interconnects prevent the enabling of Gen2 speed from producing some measurable performance gains, unless using specific PCI Express hardware. By default, the RockPro64 runs the PCIe slot at gen 1 speeds because there might be stability issues with gen 2 speeds. The port can be switched back to gen 2 speeds by adding the following device tree overlay.\nCopy and paste the device tree overlay file below into a new file (you could name it pcie-2.0.dts):\n// Pulled from: https://forum.armbian.com/topic/23574-howto-enable-pcie-gen2-to-get-max-speed-of-nvme-rockpi-4b/ /dts-v1/; /plugin/; \u0026amp;pcie0 { max-link-speed = \u0026lt;0x03\u0026gt;; }; Compile the device tree into a binary file. Note that you will need dtc installed.\ndtc -I dts -O dtb -@ pcie-2.0.dts -o pcie-2.0.dto Copy or move the device tree from the current directory into the boot partition (in this case into the /boot/dtbs/overlay/ folder). If you haven’t yet created the /boot/dtbs/overlay/ folder, then create it with sudo mkdir /boot/dtbs/overlay/\nsudo cp pcie-2.0.dto /boot/dtbs/overlay/ Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a extlinux.conf file), then add the following line to the file /boot/extlinux/extlinux.conf:\nFDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb If you already have an FDTOVERLAYS line, then add a space at the end of the current line, then add this overlay file after that. See here for details on this process: Device Tree Overlays on Mainline\nThe resulting /boot/extlinux/extlinux.conf file might look like below after adding this dtb file:\nLABEL Manjaro ARM KERNEL /Image FDT /dtbs/rockchip/rk3399-rockpro64.dtb FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil Overclocking (and undervolting) Warning Please note that changing the maximum operating frequency or the supply voltage may cause system instability or data corruption under certain circumstances. There is even the possibility of damaging your equipment permanently. The RK3399 can be overclocked. See here for details: Overclocking/RK3399-based devices. By overclocking, you do risk damaging your hardware, however, it is possible to achieve small, but measurable improvements in performance with an overclock. The overclock can be applied with a device tree overlay file.\nBelow is an example device tree overlay for CPU overclocking on the RockPro64. It may or may not work well on your device, but some have found that these speeds are stable. The example below bumps the little cores up to 1.608GHz from 1.416GHz and bumps the big cores up to 2.088GHz from 1.8GHz.\nCopy and paste the device tree overlay file below into a new file (you could name it cpu-overclock.dts):\n// Pulled from: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3399-op1-opp.dtsi /dts-v1/; /plugin/; \u0026amp;cluster0_opp { opp00 { opp-hz = /bits/ 64 \u0026lt;408000000\u0026gt;; opp-microvolt = \u0026lt;800000\u0026gt;; clock-latency-ns = \u0026lt;40000\u0026gt;; }; opp01 { opp-hz = /bits/ 64 \u0026lt;600000000\u0026gt;; opp-microvolt = \u0026lt;825000\u0026gt;; }; opp02 { opp-hz = /bits/ 64 \u0026lt;816000000\u0026gt;; opp-microvolt = \u0026lt;850000\u0026gt;; }; opp03 { opp-hz = /bits/ 64 \u0026lt;1008000000\u0026gt;; opp-microvolt = \u0026lt;900000\u0026gt;; }; opp04 { opp-hz = /bits/ 64 \u0026lt;1200000000\u0026gt;; opp-microvolt = \u0026lt;975000\u0026gt;; }; opp05 { opp-hz = /bits/ 64 \u0026lt;1416000000\u0026gt;; opp-microvolt = \u0026lt;1100000\u0026gt;; }; opp06 { opp-hz = /bits/ 64 \u0026lt;1512000000\u0026gt;; opp-microvolt = \u0026lt;1150000\u0026gt;; }; opp07 { opp-hz = /bits/ 64 \u0026lt;1608000000\u0026gt;; opp-microvolt = \u0026lt;1200000\u0026gt;; }; }; \u0026amp;cluster1_opp { opp00 { opp-hz = /bits/ 64 \u0026lt;408000000\u0026gt;; opp-microvolt = \u0026lt;800000\u0026gt;; clock-latency-ns = \u0026lt;40000\u0026gt;; }; opp01 { opp-hz = /bits/ 64 \u0026lt;600000000\u0026gt;; opp-microvolt = \u0026lt;800000\u0026gt;; }; opp02 { opp-hz = /bits/ 64 \u0026lt;816000000\u0026gt;; opp-microvolt = \u0026lt;825000\u0026gt;; }; opp03 { opp-hz = /bits/ 64 \u0026lt;1008000000\u0026gt;; opp-microvolt = \u0026lt;850000\u0026gt;; }; opp04 { opp-hz = /bits/ 64 \u0026lt;1200000000\u0026gt;; opp-microvolt = \u0026lt;900000\u0026gt;; }; opp05 { opp-hz = /bits/ 64 \u0026lt;1416000000\u0026gt;; opp-microvolt = \u0026lt;975000\u0026gt;; }; opp06 { opp-hz = /bits/ 64 \u0026lt;1608000000\u0026gt;; opp-microvolt = \u0026lt;1050000\u0026gt;; }; opp07 { opp-hz = /bits/ 64 \u0026lt;1800000000\u0026gt;; opp-microvolt = \u0026lt;1150000\u0026gt;; }; opp08 { opp-hz = /bits/ 64 \u0026lt;2016000000\u0026gt;; opp-microvolt = \u0026lt;1250000\u0026gt;; }; opp09 { opp-hz = /bits/ 64 \u0026lt;2088000000\u0026gt;; opp-microvolt = \u0026lt;1250000\u0026gt;; }; }; Compile the device tree into a binary file. Note that you will need dtc installed.\ndtc -I dts -O dtb -@ cpu-overclock.dts -o cpu-overclock.dto Copy or move the device tree from the current directory into the boot partition (in this case into the /boot/dtbs/overlay/ folder). If you haven’t yet created the /boot/dtbs/overlay/ folder, then create it with sudo mkdir /boot/dtbs/overlay/\nsudo cp cpu-overclock.dto /boot/dtbs/overlay/ Add the device compiled tree overlay file to the list of files u-boot needs to load. If you are using ManjaroARM (or ArchLinuxARM with a extlinux.conf file), then add the following line to the file /boot/extlinux/extlinux.conf:\nFDTOVERLAYS /dtbs/overlay/cpu-overclock.dtb If you already have an FDTOVERLAYS line, then add a space at the end of the current line, then add this overlay file after that. See here for details on this process: Device Tree Overlays on Mainline\nThe resulting /boot/extlinux/extlinux.conf file might look like below after adding this dtb file:\nLABEL Manjaro ARM KERNEL /Image FDT /dtbs/rockchip/rk3399-rockpro64.dtb FDTOVERLAYS /dtbs/overlay/pcie-2.0.dtb /dtbs/overlay/cpu-overclock.dtb APPEND initrd=/initramfs-linux.img console=ttyS2,1500000 zfs=zroot rw rootwait audit=0 cpufreq.default_governor=schedutil Getting WiFi working (new WiFi module) Warning The information presented in this section may be obsolete because of this commit in the linux-firmware upstream repository Moreover, the suggested modifications to the configuration file should be resolved in the upstream repository, to fix any identified issues, instead of suggesting local changes to be performed. Manjaro ARM and Arch Linux ARM (and probably others) provide the NVRAM file needed to initialize the Wi-Fi module in the linux-firmware package, but it is listed under the generic name brcmfmac43455-sdio.AW-CM256SM.txt. You can copy this file to the new name (that the driver looks for) with the following commands:\ncd /usr/lib/firmware/brcm/ sudo cp brcmfmac43455-sdio.AW-CM256SM.txt brcmfmac43455-sdio.txt Then, reboot and WiFi should start working. Details for this method are here: https://forum.pine64.org/showthread.php?tid=16635\u0026pid=117061#pid117061\nHowever, on a 5GHz network with wireless-regdb installed and the regulatory domain set to \u0026lsquo;US\u0026rsquo;, the adapter is almost unusable. Speeds are usually 0 bits per second. Sometimes a few packets can get through every few seconds, but that is it. On a 2.4GHz network, this is not an issue. This \u0026ldquo;can\u0026rdquo; be resolved by setting the regulator domain to \u0026lsquo;GB\u0026rsquo; or \u0026lsquo;CN\u0026rsquo;, but this isn’t a solution for you if you are in the USA, for instance. There are various other brcmfmac43455-sdio.txt files online that one can try. Some work better than others. Since these are text files where each line represents a property value, one can combine parts of these files to generate new firmware files for testing. One such combination yields decent results. This can be achieved by applying the patch below to the default brcmfmac43455-sdio.AW-CM256SM.txt file. With this firmware file, it is possible to get about 140Mbps up and down with this patch (with the regulatory domain set to \u0026lsquo;US\u0026rsquo;).\n--- brcmfmac43455-sdio.AW-CM256SM.txt 2023-04-27 19:16:47.000000000 -0500 +++ brcmfmac43455-sdio.txt 2023-05-21 11:42:22.058517093 -0500 @@ -21,19 +21,18 @@ ltecxpadnum=0x0504 macaddr=00:90:4c:c5:12:38 manfid=0x2d0 -maxp2ga0=64 -maxp5ga0=80,82,76,77 -mcsbw202gpo=0x99355533 -mcsbw205ghpo=0x99855000 -mcsbw205glpo=0x99755000 -mcsbw205gmpo=0x9df55000 -mcsbw405ghpo=0xd9755000 -mcsbw405glpo=0xb8555000 -mcsbw405gmpo=0xed955000 -mcsbw805ghpo=0xd9555000 -mcsbw805glpo=0xc8555000 -mcsbw805gmpo=0xe9555000 -muxenab=0x10 +maxp2ga0=70 +maxp5ga0=73,74,73,73 +mcsbw202gpo=0x99333322 +mcsbw205ghpo=0x8a875444 +mcsbw205glpo=0x8a875444 +mcsbw205gmpo=0x8a875444 +mcsbw405ghpo=0xda844333 +mcsbw405glpo=0xda844333 +mcsbw405gmpo=0xdb844333 +mcsbw805ghpo=0xda555444 +mcsbw805glpo=0xdb555444 +mcsbw805gmpo=0xda555444 nocrc=1 ofdmlrbw202gpo=0x0033 pa2ga0=-112,6296,-662 To use this patch, copy it off into a file and use the patch command. However, it might be easier to apply the patch by hand. To do this, open the file /usr/lib/firmware/brcm/brcmfmac43455-sdio.txt (after completing the copy step above), delete the line with maxp2ga0=64 through the line with muxenab=0x10.\nThen add the following in its place:\nmaxp2ga0=70 maxp5ga0=73,74,73,73 mcsbw202gpo=0x99333322 mcsbw205ghpo=0x8a875444 mcsbw205glpo=0x8a875444 mcsbw205gmpo=0x8a875444 mcsbw405ghpo=0xda844333 mcsbw405glpo=0xda844333 mcsbw405gmpo=0xdb844333 mcsbw805ghpo=0xda555444 mcsbw805glpo=0xdb555444 mcsbw805gmpo=0xda555444 Reboot and the Wi-Fi (at least for 5GHz networks) should work well. It is not exactly clear what these fields do, so the impact this has on the Wi-Fi module or your ability to operate it legally in your country is not certain. It seems that this file is passed directly to the hardware, where it is interpreted by the Wi-Fi module itself. However, given that this file is simply a combination of other existing files for similar hardware, it might be fine to use. The patch above only pulls in lines from the following firmware file: https://github.com/reMarkable/brcmfmac-firmware/blob/master/brcmfmac43455-sdio.txt. This code comes with the following license - which is not replicated here because it will fill this wiki with text - see the link here for the license: https://github.com/reMarkable/brcmfmac-firmware/blob/master/LICENCE.\nStabilizing the system (underclocking the RAM) Warning As pointed out by CrystalGamma, \u0026ldquo;normal accesses should simply work, though with higher access latency than necessary (since it uses the same number of cycles as would be necessary for a higher frequency), but I’d be slightly worried about refresh, since it also issues refresh based on number of cycles as would be used for a higher frequency, instead of actual time elapsed\u0026rdquo;. In other words, \u0026ldquo;the risk is refreshes coming to late, though it’s probably within tolerance with this little of a frequency diff\u0026rdquo;.\nTo put it simply, the suggested changes to DRAM configuration may actually cause system instability or data corruption under certain circumstances.\nBy default, it seems that the some RockPro64 devices are not stable. This seems to manifest as gcc segfaulting randomly. Usually, this can be \u0026ldquo;fixed\u0026rdquo; by starting the build again and hoping gcc doesn’t crash. If the build finishes or crashes at a different point, this is a good indicator that the system is not stable. The issue seems to be that the RAM is running a little too fast and some bits are getting randomly flipped. Other frequencies are possible, but the highest officially supported frequency below 800MHz is 666MHz, which is still a big step down from the default frequency of 800MHz provided by ManjaroARM. It is also possible to set arbitrary frequencies in u-boot. Frequencies that have been tested with this method are 702MHz and 752MHz. It seems that there is only a slight performance decrease at 752MHz compared to 800MHz.\nBy default, this PKGBUILD uses the default RAM speed of 800MHz. Uncomment the line that begins with \u0026ldquo;patch\u0026rdquo; to enable the 752MHz patch. Details are in the comments at the top of the PKGBUILD. If you would like to try out other frequencies, follow the instructions in the comments at the top of the PKGBUILD.\nAfter building and installing, the install hook will prompt you on if you want to install the new build of U-Boot to EMMC. If you want to, press Y, otherwise, hit N and then copy and paste the printed dd commands and modify them to write to the correct device (change the /dev/mmcblk part).\nAfter installing U-Boot and rebooting, U-Boot should print out that it set the RAM to 400MHz (initially). Then a few lines down, the RAM should be set to 752MHz.\nHardware compatibility Please contribute to the hardware compatibility page, which lists hardware which has been tested with the rockpro64, whether successful or not.\nHardware compatibility PCIe devices Type Make/Model Hardware IDs Kernel Result Notes Tester NIC Intel I350 Dual Port Mainline-5.4 good SR-IOV fails NIC Intel I350 Quad Port ? NIC Intel X520 Dual Port 8086:10fb Mainline-5.6 good SR-IOV fails NIC Intel X550-T2 Dual Port 8086:1563 5.15.0-trunk-arm64 (Debian) good netperf throughput in FW mode, 20 streams: between 4136-6613mb/s across use cases. NIC Intel 82571EB Dual Port (HP NC360T) Mainline-5.6 crash kernel crash on boot NIC Intel 82575EB Dual Port (AOC-SG-I2) Mainline-5.10 crash kernel crash on boot NIC Intel 82575/82576 8086:1521 OpenWrt 21.02-rc1 ; 5.4.111-1 good opkg: kmod-igb; OpenWrt 21.02-rc1 5.4.111-1; ~92.8 KB; Kernel modules for Intel(R) 82575/82576 PCI-Express Gigabit Ethernet adapters. NIC Aquantia 10GBps AQC107 1d6a:07b1 Mainline 5.16 good Works perfectly out of the box. GPU nVidia GTX-645 Mainline-5.4 crash BAR size too small, triggers PCIe error handling bug PCIe Switch PCIE-EUX1-04 Ver.002 Mainline-5.4 good SATA Controller ASM1062 4-Port Mainline-5.6 good tested only with one disk attached SATA Controller ASM1062 (rev 02) 4-Port 1d87:0100 Ayufan-4.4.190 good tested with four disks, 3 in raid 5 SATA Controller IOCrest (Same as Syba?) SI-PEX40063 4-port, Marvell 88SE9235 chip 1b4b:9235 Debian unstable 5.7, 5.8 good Tested with two disks. SATA errors occurred with a WD Red drive in a cheap enclosure; resolved by connecting the same drive directly to the card. SATA Controller Ziyituod SATA Card ASM 1062+1093 6-Port 1b21:0625 Mainline-4.4 (armbian) good tested with 6 disks SATA Controller BEYMEI RAID 4-Port, Marvell 88SE9230 chip 1b4b:9230 Ayufan-5.6.0-1137 good Tested with 3 disks in RAID 5. I added pci=nomsi to /boot/extlinux/extlinux.conf kernel parameters and an udev rule before the disks were recognized: ACTION==\u0026ldquo;add\u0026rdquo;, SUBSYSTEM==\u0026ldquo;pci\u0026rdquo;, ATTR{vendor}==\u0026ldquo;0x1b4b\u0026rdquo;, ATTR{device}==\u0026ldquo;0x9230\u0026rdquo;, RUN+=\u0026quot;/bin/bash -c \u0026rsquo;echo %k \u0026gt; /sys/bus/pci/drivers/ahci/bind'\u0026quot; SATA Controller BEYIMEI SATA Card 6-Port, ASM1166 chip 5.10.0-16-arm64 (Debian) good Tested with 4 disks. Built 2 separate software RAID-1 arrays without errors. Performance seems good enough for a NAS on gigabit LAN. SATA Controller PCE8SAT-A02 VER006S\n2 Lanes, 8-Port, ASM1166 chip\nOdd because chip got only 6 ports? 1b21:1166 6.1.50-current-rockchip64\nArmbian 23.8.1 Bookworm unstable Tested with 3 disks in SW-RAID 5. After 10 hours of burn in test one disk dropped from system and RAID. Hotplug does not work. User:JPT SATA Controller BEYIMEI SATA Card 2-Port, ASM1062 chip 1b21:0612 5.10.0-19-arm64 (Debian) good Using with 2 SSDs in a software RAID-1 array (~190MB/sec for reading and writing) SATA Controller QNINE 4-Port, Marvell 88SE9215 chip Ayufan-5.6.0-1137 very slow Tested with 3 disks in RAID 5. Top speeds were around 50 MiB/s but quickly dropped to below 2 MiB/s due to SATA CRC errors SATA Controller YUNKOZAND-PCIE1X-SATA4-9215, Marvell 88SE9215 chip 1b4b:9215 (rev 11) Armbian 24.11.1, Kernel 6.12.12-current-rockchip64 good Kernel driver in use: ahci Tested with 2 disks in RAID 1. Top speeds were around 100 MB/s User:o1hitman1o SATA Controller DELOCK 90498, JMicron Technology Corp. JMB58x AHCI SATA controller 197b:0585 5.18.0-0.bpo.1-arm64 (Debian bullseye + backports) good, but… Tested with 3 disks, two in RAID1, one standalone. u-boot-rockchip_2023.07 cannot initialize the controller to boot off it. User:Lrissman\nUser:ChriChri SATA Controller DELOCK 90498, JMicron Technology Corp. JMB58x AHCI SATA controller 197b:0585 6.12.63+deb13 (Debian trixie), 6.17.13+deb13 (Debina trixie/backports) crash synchronous external abort @horazont Host Bus Adapter LSI SAS 9211-4i\nSAS2008 chip, 4-Port SAS/SATA, PCI 2.0, 8 lanes 1000:0070 Ayufan-4.4.197 good tested with four disks attached Host Bus Adapter Fujitsu SAS MEGARAID LSI 2008B2\nSAS2008 chip, 8-Port SAS/SATA, PCI 2.0, 8 lanes TODO 6.1.50-current-rockchip64\nArmbian 23.8.1 Bookworm TODO needs special MicroSAS cables. Must be flashed to HBA mode?\nordered, not yet received User JPT USB Controller ASMedia Technology Inc. ASM1142 USB 3.1 Host Controller 1b21:1242 Mainline-5.15.0-rc5 good DTMB Quad Tuner TBS Technologies TSS6514 Mainline-5.10.21 good TV -\u0026gt; LAN streaming server, 7W idle, 8-10W with one FHD channel streaming DVB-T2/C Quad Tuner TBS Technologies TBS6205 5.10.0-16-arm64 (Debian) good Working well with Tvheadend DVB-S2 Dual Tuner Digital Devices Octopus CI S2 Pro 6.1.42-rockchip64 (armbian) good All features are working flawlessly with the latest drivers from Digital Devices NVMe SSD drives Type Make/Model Size Hardware IDs Kernel Result Notes Power options\nActive only Save power setting? NVMe Samsung 970 Evo 500 GB Mainline 5.6 good - defaults defaults NVMe Samsung 960 Evo 500 GB 144d:a804 Mainline 5.13-rc4 doesn’t work Likely due to 64/32 BAR mismatch issue on Linux 5.11+ defaults defaults USB hardware Type Make/Model Hardware IDs Kernel Result Notes Tester Zigbee Bridge Conbee II 1cf1:0030 6.1.50-current-rockchip64\nArmbian 23.8.1 Bookworm good seems to work fine User JPT USB C alternate mode DP Note that only USB C alternate mode Display Port will pass video. Any HDMI, DVI or VGA port must be converted internally by the device from Display Port - or the device won’t work for video.\nType Make/Model Hardware IDs Kernel Result Notes eMMC / SD drives Type Make/Model Hardware IDs Kernel Read Speed Write Speed Result Notes Other hardware Type Make/Model Hardware IDs Kernel Result Notes Limitations Older firmware overwrites actively used memory Some people get system freeze when:\nuse SATA disk with ROCKPro64 PCIe card (maybe on newer PCIe card ASM1062 vs ASM1061) or do read or write 4GB to the flash (not using PCIe) If you connect the serial console you will see a Linux kernel oops: (a)synchronous external abort.\nBoth issues are in fact the same software BUG. There is no hardware problem. Currently, most OS do use uboot with a rockpro blob FW which use memory that Linux kernel is not aware of.\nPeople are currently fixing this BUG, but it may take some time. In the mean time, you can fix it manually.\nThe latest u-boot can boot the rockpro64 without any blobs from rockchip.\nInstall first arm-none-eabi-gcc and aarch64-linux-gnu-gcc compiler, then run the following commands:\nPrerequisite packages (Debian/Ubuntu): device-tree-compiler python gcc-arm-non-eabi flex bison gcc-aarch64-linux-gnu gcc make\ngit clone https://github.com/ARM-software/arm-trusted-firmware.git atf make -C atf CROSS_COMPILE=aarch64-linux-gnu- PLAT=rk3399 bl31 git clone https://gitlab.denx.de/u-boot/u-boot.git u-boot cd u-boot/ git checkout v2020.01-rc5 make rockpro64-rk3399_defconfig BL31=../atf/build/rk3399/release/bl31/bl31.elf make ARCH=arm CROSS_COMPILE=aarch64-linux-gnu- Which gives you idbloader.img and u-boot.itb. Copy them to the rockpro64, and run the following: (Or put your SD card into your PC)\nsudo dd if=idbloader.img of=/dev/mmcblk0 seek=64 sudo dd if=u-boot.itb of=/dev/mmcblk0 seek=16384 sync PCIe Controller Hardware Error Handling Bug There is an issue with the rk3399 pcie controller that is currently unmitigated:\nLKML Original Thread LKML Additional Information The rk3399 pcie controller throws either a synchronous abort or a SError when a pcie device sends an unknown message.\nThe error type is determined by which cpu cluster handles the message.\nVirtualization The PCIe controller on the rk3399 is not behind an IOMMU. This means it is not possible to safely pass through PCIe devices to a virtual machine.\n3D printable ITX mounting brackets A Quartz64-A mounted in an ITX case using 3D printed brackets\nAllows mounting a ROCKPro64-A or Quartz64-A board inside a regular PC case that conforms to the ITX standard, using 3D printed brackets:\nAMF/STL/STEP files plus the original FreeCAD file used to create the models https://wiki.pine64.org/wiki/File:RP64-A_Q64-A_to_ITX_mounting_brackets.zip Make sure to flip the two brackets by 180 degrees on one of the horizontal axes (X/Y) in your slicer of choice before printing to avoid unnecessary supports To allow enough clearance between the board and the bracket you either need to print four copies of the washer model or add nut(s) between the board and the bracket If using nuts for the clearance between the board and the brackets, make sure it creates at least 3.2mm of spacing in between Depending on the accuracy and calibration of a 3D printer, slight deviation can occur and you likely need to manually widen some of the holes to allow screws to fit Cases Acrylic Open Enclosure Acrylic enclosure NAS case Front View of the PINE64 NAS Case for the ROCKPro64\nPlease follow this this link for detailed instructions on how to assemble the ROCKPro64 NAS Case.\nThe NAS Case instructions also contains detailed information about:\nwhat the NAS Case ships with What additional things you need to purchase for your NAS Case What optional things you can consider purchasing for your NAS build What OS Image we recommend you use for your NAS build IO accessibility after installing the ROCKPro64 into the NAS Case NAS Case Exploded View NAS Case Drawing Powering From An ATX Supply Powering the ROCKPro64 single-board computer from an ATX power supply allows the board to be powered with more than just two disks, and is a reliable and safe way to power it from your household mains.\nWarning Please note that following these instructions comes at your own risk. While best efforts have been made to write reliable, safe instructions, the authors cannot be held liable for the quality of procured components or the assembly job of the person following the instructions, and the damages caused by either of these not being up to par. Shopping List Components An ATX breakout board. Get one with fuses. For extra safety, replace the fuses with your own trusted ones once you get it. Some 24 AWG or thicker copper wire, 0.5m of length at most, go thicker if you want to use longer wire. Also go thicker if you’re using copper-coated aluminium. A 2.1mm ID/5.5mm OD barrel jack connector Tools A soldering iron, e.g. the Pinecil, with some solder Some wirestrippers suitable for the thickness of wire you chose Assembly Slide the stress relief over both the wires you will use Solder the positive side of the wire to the centre contact of the barrel connector Solder the negative side of the wire to the outside contact of the barrel connector Fasten the stress relief/barrel connector housing Connect the positive side to your ATX breakout board’s 12V terminal Connect the negative side to your ATX breakout board’s GND terminal Plug in the ATX power supply into the ATX breakout board, with the PSU turned \u0026lsquo;off\u0026rsquo; at the flip switch in the back Set the power switch on the ATX breakout board to the on position Stand out of reach of any glass fuse shrapnel (e.g. put the breakout board in a housing), plug in the ATX power supply and flip its switch on If it didn’t blow up, you did it right, and can now hopefully plug the ROCKPro64 into the ATX breakout board using the cable you’ve made Further Steps If you got one of the green breakout boards with the glass fuses and the red LED, then User:CounterPillow made a 3d printable housing for it. It screws together with heat-set brass inserts. Download .zip containing STEPs and STLs as well as the FreeCAD project file\nSerial buffer circuit Connecting to the ROCKPro64 single-board computer serial interface can sometimes be tricky, as the lack of buffering can cause the Uboot-SPL to stop functioning due to transient voltage spikes during startup. This simple circuit allows a user to hot-plug their serial connection at any time, or can be left attached full time.\nWarning Please note that following these instructions comes at your own risk. While best efforts have been made to write reliable, safe instructions, the author cannot be held liable for the quality of procured components or the assembly job of the person following the instructions, and the damages caused by either of these not being up to par. Shopping List Components You may have some or all of these in your junk/parts drawer. They’re all common value, and easily recovered from scrap circuit-boards.\n3\u0026quot;x4\u0026quot; perf board, will be used for construction of the circuit misc breakout board wires, or any random copper wire that works, I used ribbon cable from an old floppy harness. misc jumper wire with headers, a three-pin header, and a one-pin header, since you’ll be connecting to the RP64 mainboard pin headers in different places Transistors, 1 (one) NPN-type, 2n2222 or equivalent; and 1 (one) PNP-type, 2n2907 or equivalent Resistors, 3 (three) 4.7kΩ 1/4-watt; and 2 (two) 10kΩ 1/4-watt Serial interface jack, 3-pin TRS audio jack works well, as does RJ45 or DB9. You only need, and use, 3 pins though. Double-sided sticky tape, at least 1\u0026quot;x1\u0026quot;, to mount the perf board to your case. Tools A soldering iron, e.g. the Pinecil solder, fine gauge, anything suitable for electronics Wire strippers, suitable for the thickness of wire you chose Diagonal cutters, to trim excess leads from components and wires Assembly Start by creating \u0026ldquo;vias\u0026rdquo; using a stretch of bare wire for both ground and +3.3v along the long edges of the perf board; ground on one side, +3.3v on the opposite At one end of the perf board, start laying out the parts for the NPN transistor portion of the circuit, then solder down. At the opposite end, lay out the PNP transistor portion, and solder down. Connect up the serial interface jack, using enough wire to reach your desired mounting point on your case, from the mounting place for this board Solder the jumper wires to the perf board for the serial jack Solder the header jumpers to the perf board, making sure they’re long enough to reach the RP64 headers with a bit of slack. Let cool, affix the double-sided tape, and mount to your case. Install Mount your serial port Serial RX \u0026lt;-\u0026gt; DCE RX (in) Serial TX \u0026lt;-\u0026gt; DCE TX (out) attach the header jumpers to their respectively labeled points on the various headers RP64 Ground \u0026lt;-\u0026gt; pi2bus-6 RP64 RX (in) \u0026lt;-\u0026gt; pi2bus-8 RP64 TX (out) \u0026lt;-\u0026gt; pi2bus-10 RP64 3.3v \u0026lt;-\u0026gt; pi2bus-1 Circuit Further information Datasheets\nOther resources\nSchematics and certifications\nDatasheets Rockchip RK3399 SoC information:\nRockchip RK3399 SoC Brief Rockchip RK3399 Datasheet V2.1 Rockchip RK3399 Technical Reference Manual part 1 Rockchip RK808 Datasheet V0.8 LPDDR4 (200 Balls) SDRAM:\nMicron LPDDR4 Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet Heatsink related info:\nROCKPro64 Passive Heatsink Dimension Drawing Heatsink Thermal Pad Specification Wireless related info:\nAMPAK AP6256 11AC WiFi + Bluetooth5.0 Datasheet (v. 1.3) (v. 1.7) Ethernet related info:\nRealtek RTL8211F 10/100/1000M Ethernet Transceiver Datasheet Peripheral related info:\nasmedia ASM1061 PCIe SATA 2.0 Datasheet Remote control button mapping:\nOfficial Remote Control for the PINE64 Button Mapping Audio Codec (ES8316) (under board):\nEverest ES8316 Audio Codec PWM controlled fan, SPDIF, and RTC Battery Backup headers:\nJST-PH connector Other resources ROCKPro64 Forum PINE64 shop Rockchip Linux GitHub Repo Rockchip Open Source Wiki ExplainingComputers have a video review of the RockPro64 here, including linux first boot. Useful articles and blog posts If you want to dive in to the ecosystem, here’s a short list of various articles and blog posts that can help you set up your soft- or hardware development environment.\nBlobless boot with RockPro64 by Andrius Štikonas EBBR on RockPro64 by Marcin Juszkiewicz Schematics and certifications Board dimensions: 133 mm x 80 mm x 19 mm Power input: 12 V, 3 A or 5 A, using 5.5 mm (OD) / 2.1 mm (ID) type M barrel DC connector ROCKPro64 Schematic v2.1 (Second Batch Production Release) ROCKPro64 v2.1 Board Top Outline in AutoCad DXF format ROCKPro64 v2.1 Board Bottom Outline in AutoCad DXF format ROCKPro64 v2.1 Board Top Outline in PDF format ROCKPro64 v2.1 Board Bottom Outline in PDF format ROCKPro64 Schematic v2.0 (Pilot Production Release) ROCKPro64 v2.0 Board Top Silkscreen in PDF format (contains component labels) Engineering Change Notice for v2.0 to turn on 3.3V power on PCIe ROCKPro64 AP6359SA Wifi/BT Schematic ROCKPro64 Pi-2 Pin assignment and definition ROCKPro64 3D model Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submit the SBC for FCC, CE, and ROHS certification and obtain the certificates to proof that SBC board is capable on passing the testing. Please note a final commercial product needs to performs its owns testing and obtains its owns certificates. ROCKPro64 FCC Certificate ROCKPro64 CE Certificate ROCKPro64 RoHS Report ","permalink":"/documentation/ROCKPro64/_full/","tags":null,"title":"ROCKPro64 (Single Page)"},{"categories":null,"contents":" General recommendations Due to the greater control the user is having over the device and its software comes also greater responsibility. It is necessary to verify the configuration of the device to make sure that responsible settings are used. The different operating systems may come with non-sane default settings, including SSH with weak password authentication being enabled by default and exposed to the public Internet, the absence of a firewall, default passwords, unencrypted files, too high temperature zones and emergency shutoff values or an enabled root account. The usage of public resources to verify such settings (such as the in case of GNU/Linux, the Arch Linux security wiki page, or the general recommendations) as well as the corresponding operating system’s or distribution’s resources are strongly recommended.\nCharging safety The PinePhone supports up to 5V 3A (15W) Quick Charge, it follows the USB Power Delivery specification. Only compatible phone chargers may be used, charging the phone with incompatible chargers (for example laptop chargers with a higher voltage) is prohibited. Charging the phone releases heat, general safety recommendations must be followed, see the section Thermal safety.\nThermal safety With the Allwinner A64 being an older generation SoC with a large 40nm chip, the phone produces quite some heat with medium or higher use and especially also during charging or when using USB accessories, like a docking station. Measurements to prevent damage to the phone and to its surroundings need to be taken by the user. This includes especially a proper handling of the phone: do not charge the phone in a way where heat builds up around the phone without being able to escape. Especially don’t charge your phone under a pillow, blankets, in pockets or bags. Charging the phone produces heat and charging the phone in a way, where the excessive heat can’t dispose around the phone poses an immediate fire risk.\nThe user might notice that the phone gets warm under usage, compared to phones with more up-to-date hardware. Under normal circumstances these temperatures don’t pose a risk while being in the levels within the safe operating temperatures (which lay far beyond the point where components can be too hot to touch). Higher temperatures might especially be experienced on the top side of the screen and on the inside of the phone at the RF shield of the modem. The higher temperature of the RF shield of the modem is commonly caused by the SoC on the opposite side of the mainboard, the RF shield of the modem is used to disperse heat of the SoC. In newer mainboard revisions starting from 1.2a there are also thermal pads on the back cover and between the SoC’s RF shield and the screen, dispersing heat on the screen and on the back cover. In the past there has been safety issues regarding thermal safety functions, causing temperature reads to not properly work over an extended period of time, which was causing heat damage in some cases (see the documentation of that issue by the developer Megous here and here). While the developers are working hard to prevent such issues, they can’t be excluded under all circumstances. The users are expected to monitor their phones\u0026rsquo; thermal safety at every point at this state of the software.\nIt is highly recommend to update the phone on a regular basis to always get the latest improvements. The default settings to throttle the performance and to shut down the phone when reaching critical temperatures might be set to a too high point depending on the specific usage and usage length. Under GNU/Linux the phone’s thermal management behavior can be modified via the Thermal Sysfs driver to achieve lower temperatures and preventing the screen and other components to potentially take damage, see Thermal tweaks for the details.\n","permalink":"/documentation/PinePhone/Further_information/Safety/","tags":null,"title":"Safety"},{"categories":null,"contents":" Clusterboard version 2.2 Schematic Capture source file Clusterboard version 2.2 Schematic Capture PDF file Clusterboard version 2.2 PCB Job source file Clusterboard version 2.2 PCB Gerber file Clusterboard version 2.2 PCB Layout PDF file Clusterboard 20pins header definition Clusterboard 3D drawing in Fusion360 Clusterboard PDF drawing ","permalink":"/documentation/Clusterboard/Schematics/","tags":null,"title":"Schematics"},{"categories":null,"contents":"Pre-Production version schematic:\nOz64 Schematic 20240517 v1.0.0 Oz64 PCB Component placement(ToP) 20240517 v1.0.0 Oz64 PCB Component placement(Bottom) 20240517 v1.0.0 ","permalink":"/documentation/Oz64/Schematics/","tags":null,"title":"Schematics"},{"categories":null,"contents":"\nPineTab-V mainboard schematic:\nPineTab-V mainboard Released Schematic-20240730 ver 2.0 PineTab-V PCB Component Reference location v2.0 (top layer) PineTab-V PCB Component Reference location v2.0 (bottom layer) PineTab-V mainboard Released Schematic-20230614 ver 1.0 PineTab-V PCB Component Reference location v1.0 (top layer) PineTab-V PCB Component Reference location v1.0 (bottom layer) PineTab2/PineTab-V UART Dongle Schematic-20221107 ","permalink":"/documentation/PineTab-V/Further_information/Schematics/","tags":null,"title":"Schematics"},{"categories":null,"contents":"PineTab2 mainboard Schematics:\nPineTab2 mainboard Released Schematic-20230417 ver 2.0 PineTab2 PCB Component Reference location v2.0 (top layer) PineTab2 PCB Component Reference location v2.0 (bottom layer) PineTab2/PineTab-V UART Dongle Schematic-20221107 ","permalink":"/documentation/PineTab2/Further_information/Schematics/","tags":null,"title":"Schematics"},{"categories":null,"contents":"Board Dimensions: 85mm x 56mm x 18.8mm, see the ROCK64 board dimension drawing\nInput Power: +5V @3A with 3.5mm/1.35mm Type H Barrel type DC connector (@2A will work if there is no heavy load on the USB 3.0 port)\nROCK64 ver 3.0 SBC related info:\nROCK64 SBC v3.0 Change Notice ROCK64 Schematic v3.0 (Production Release) ROCK64 Component Reference location v3.0 (top layer) ROCK64 Component Reference location v3.0 (bottom layer) ROCK64 SBC v3.0 Pi-2 and Pi-P5+ Bus GPIO Assignment ROCK64 Rev3 SBC RTC Battery Connector polarity ROCK64 ver 2.0 SBC related info:\nROCK64 Schematic v2.0 (Production Release) ROCK64 SBC v2.0 Pi-2 and Pi-P5+ Bus GPIO Assignment Github on ROCK64 GPIO library, thanks to Leapo Good documentation about ROCK64 GPIO pins article ROCK64 Audio DAC with 10/100Mbps Ethernet POT Board Schematic ROCK64 3D autodesk drawing (from TeaPack):\nROCK64 board 2D drawing @courtesy of TeaPack ROCK64 board 3D drawing @courtesy of TeaPack ROCK64 Audio DAC with 10/100Mbps Ethernet POT board 3D drawing @courtesy of TeaPack ROCK64 board with Audio DAC POT board 3D drawing @courtesy of TeaPack ","permalink":"/documentation/ROCK64/Further_information/Schematics/","tags":null,"title":"Schematics"},{"categories":null,"contents":" Pinout for wiring ethernet PHY to EMAC\nBaseboard dimensions: 51 mm x 21 mm x 19 mm x 3.5 mm (breadboard-friendly) Input power: 5 V, 0.5 A through the microUSB or USB-C ports Production version schematic:\nOx64 Schematic 20221018 v1.1 Ox64 PCB Component placement(ToP) 20221018 v1.1 Ox64 PCB Component placement(Bottom) 20221018 v1.1 Prototype (dispatched to developers) schematic:\nOx64 Schematic 20221007 v1.0 Ox64 PCB Component placement(ToP) 20221007 v1.0 Ox64 PCB Component placement(Bottom) 20221007 v1.0 Certifications:\nNot available yet ","permalink":"/documentation/Ox64/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":" Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm Input Power: DC 5V @ 2A, 3.7V Li-Ion battery connector, 3.5OD/1.35ID Barrel DC Jack connector, Euler connector\nSchematics:\na PDF mapping the pins from the A64 chip itself, to the gold-fingers on the SO-DIMM edge, to the multiple connectors on the baseboard and on the clusterboard, attached to this forum post. PINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016) Pine A64-LTS schematic:\nPine A64-LTS Schematic Pine A64-LTS V2 schematic:\nPine A64-LTS V2 Schematic ","permalink":"/documentation/Pine_A64-LTS/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"Schematics and general files:\nPINE A64 Pi-2/Eular/Ext Bus/Wifi Bus Connector Pin Assignment (Updated 15/Feb/2016) Board schematics:\nPINE A64 512MB Rev B Board Schematic PINE A64+ 1GB Rev B Board Schematic PINE A64+ 2GB Rev C Board Schematic PINE A64 Wifi/BT Module Schematic Stereo audio DAC schematics:\nPINE A64 Stereo audio DAC schematics Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submit the SBC for FCC, CE, and ROHS certifications and obtain the certificates to prove that the SBC board can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. PINE A64 FCC Certificate PINE A64 CE Certificate PINE A64 RoHS Certificate ","permalink":"/documentation/Pine_A64/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"Mainboard schematics:\nPinebook Mainboard schematics Daughter Board schematics:\nPinebook Daughter board schematics Serial Console Earphone Jack pinout:\nPinebook Serial Console Earphone Jack pinout Certifications:\nPinebook FCC Certificate Pinebook FCC ID-Spread Spectrum Transmitter Certificate Pinebook FCC ID-Digital Transmission System Certificate Pinebook CE Certificate Pinebook RoHS Certificate ","permalink":"/documentation/Pinebook/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"Pinebook Pro Main Board Schematic And Silkscreen:\nPinebook Pro Main Board ver 2.1a Schematic 20220419 Pinebook Pro Main Board ver 2.1 Schematic 20190905 Pinebook Pro ver 2.1 Top Layer Silkscreen Pinebook Pro ver 2.1 Bottom Layer Silkscreen Pinebook Pro Daughter Board Schematic:\nPinebook Pro Daughter Board ver 2.1 Schematic Optional Pinebook Pro NVMe Adapter Schematic:\nPinebook Pro NVMe Adapter Board ver 2.1 Schematic Serial Console Earphone Jack Pinout:\nPinebook Serial Console Earphone Jack Pinout Pinebook Pro Case:\nAutoCAD PDF File AutoCAD AI File AutoCAD DWG File Pinebook Pro Certifications:\nPinebook Pro FCC Certificate Pinebook Pro CE Certificate Pinebook Pro RoHS Certificate ","permalink":"/documentation/Pinebook_Pro/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"PineCube mainboard schematic:\nPineCube mainboard Released Schematic ver 1.0 PineCube faceboard schematic:\nPineCube faceboard Released Schematic ver 1.0 PineCube certifications:\nPineCube FCC Certificate PineCube CE RED Certificate PineCube ROHS Test Report ","permalink":"/documentation/PineCube/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":" PineNote Developer kit version Version v1.2 is the PineNote production version that was sold through the Pines64 store\nPineNote Mainboard Schematic ver 1.2 20210824 PDF file PineNote USB-C Daughter Board Schematic ver 1.0 PDF file PineNote USB-C Console UART Breakout Board Schematic ver 1.0 PDF file Note: When building USB-C console breakout board, please be aware 10k CC pin pull-up is too weak to pull CC to logically high level. Replacing it to lower resistance, such as 1k is recommended. The v1.1 is early release schematic just for reference only and used by developers who received the prototype.\nPineNote early released Schematic ver 1.1 20210726 PDF file PineNote early released ver 1.1 20210726 PCB Connector placement PDF file Certifications:\nPineNote FCC-15C Certificate PineNote FCC-15E Certificate PineNote CE RED Certificate PineNote ROHS Certificate ","permalink":"/documentation/PineNote/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"PinePhone mainboard schematic:\nPinePhone mainboard Released Schematic ver 1.2b PinePhone mainboard Released Schematic ver 1.2a PinePhone mainboard Released Schematic ver 1.2 PinePhone schematic ver 1.2 change list \u0026ldquo;Braveheart\u0026rdquo; PinePhone mainboard Schematic ver 1.1 \u0026ldquo;Braveheart\u0026rdquo; PinePhone mainboard component top placement drawing ver 1.1 \u0026ldquo;Braveheart\u0026rdquo; PinePhone mainboard component bottom placement drawing ver 1.1 Components list PinePhone USB-C small board schematic:\nPinePhone USB-C small board Schematic ver 1.0 PinePhone USB-C small board component top placement drawing ver 1.0 PinePhone USB-C small board component bottom placement drawing ver 1.0 PinePhone certifications:\nPinePhone FCC Certificate RF Exposure SAR Information from FCC ID site PinePhone CE RED Certificate PinePhone ROHS Report Note: PinePhone’s Type Allocation Code (TAC) is 86769804 ","permalink":"/documentation/PinePhone/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"PineTab mainboard schematic:\nPineTab mainboard Released Schematic ver 1.2 PineTab mainboard component placement ver 1.2 - Top View PineTab mainboard component placement ver 1.2 - Bottom View PineTab keyboard schematic:\nPineTab keyboard and Pinebook (Pro) keyboard using same controller and from same engineering source PineTab Keyboard Schematic PineTab keyboard firmware code PineTab Keyboard Controller Datasheet PineTab certifications:\nPineTab FCC Certificate PineTab CE RED Certificate PineTab ROHS Test Report ","permalink":"/documentation/PineTab/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":" Model \u0026ldquo;A\u0026rdquo; Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm\nInput Power: DC 12V @ 3A 5.5mmOD/2.1mmID center-positive Barrel DC Jack connector\nQuartz64 Model \u0026ldquo;A\u0026rdquo; SBC Schematic and PCB Board Resource:\nQuartz64 Model \u0026ldquo;A\u0026rdquo; SBC Schematic ver 2.0 20210427 PDF file Quartz64 Model \u0026ldquo;A\u0026rdquo; SBC PCB Connector placement PDF file Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submit the SBC for FCC and CE certification and obtain the certificates to proof that SBC board is capable on passing the testing. Please note a final commercial product needs to performs its owns testing and obtains its owns certificates. Quartz64 model-A CE Certificate Quartz64 model-A FCC Certificate Model \u0026ldquo;B\u0026rdquo; Model \u0026ldquo;B\u0026rdquo; Baseboard Dimensions: 85mm x 56mm x 18.8mm\nInput Power: DC 5V @ 3A 3.5mmOD/1.35mmID center-positive Barrel DC Jack connector\nQuartz64 Model \u0026ldquo;B\u0026rdquo; SBC Schematic and PCB Board Resource:\nQuartz64 Model \u0026ldquo;B\u0026rdquo; SBC Schematic ver 1.3 20220124 PDF file Quartz64 Model \u0026ldquo;B\u0026rdquo; SBC PCB Connector placement PDF file Please note that v1.2 and V1.3 schematic and component placement are identical, just some component value changed. Note: Model B uses a Molex PicoBlade compatible connector for the RTC battery. The Pine64 Backup Battery Holders come with a JST PH type connector. To use the Pine64 RTC Backup Battery Holder, the connector on the battery holder will need to be modified with a PicoBlade type connector. Model \u0026ldquo;Zero\u0026rdquo; Model \u0026ldquo;Zero\u0026rdquo; Baseboard Dimensions: 85mm x 56mm x 18.8mm\nInput Power: DC 5V @ 3A 3.5mmOD/1.35mmID center-positive Barrel DC Jack connector\nQuartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC Schematic and PCB Board Resource:\nQuartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC Schematic ver 1.0 20240428 PDF file Quartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC PCB Component placement (top side) PDF file Quartz64 Model \u0026ldquo;Zero\u0026rdquo; SBC PCB Component placement (bottom side) PDF file ","permalink":"/documentation/Quartz64/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":" Board dimensions: 133 mm x 80 mm x 19 mm Power input: 12 V, 3 A or 5 A, using 5.5 mm (OD) / 2.1 mm (ID) type M barrel DC connector ROCKPro64 Schematic v2.1 (Second Batch Production Release) ROCKPro64 v2.1 Board Top Outline in AutoCad DXF format ROCKPro64 v2.1 Board Bottom Outline in AutoCad DXF format ROCKPro64 v2.1 Board Top Outline in PDF format ROCKPro64 v2.1 Board Bottom Outline in PDF format ROCKPro64 Schematic v2.0 (Pilot Production Release) ROCKPro64 v2.0 Board Top Silkscreen in PDF format (contains component labels) Engineering Change Notice for v2.0 to turn on 3.3V power on PCIe ROCKPro64 AP6359SA Wifi/BT Schematic ROCKPro64 Pi-2 Pin assignment and definition ROCKPro64 3D model Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submit the SBC for FCC, CE, and ROHS certification and obtain the certificates to proof that SBC board is capable on passing the testing. Please note a final commercial product needs to performs its owns testing and obtains its owns certificates. ROCKPro64 FCC Certificate ROCKPro64 CE Certificate ROCKPro64 RoHS Report ","permalink":"/documentation/ROCKPro64/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"SOEDGE module schematics:\nSOEDGE Module ver 2.0 20190919 Schematic SOEDGE Module ver 2.0 20190919 PCB Component Placement Top PDF file SOEDGE Module ver 2.0 20190919 PCB Component Placement Bottom PDF file SOEDGE Module ver 2.0 20190919 PCB Component Placement Top Drawing file SOEDGE Module ver 2.0 20190919 PCB Component Placement Bottom Drawing file SOEDGE Module Pin Assignment ver 1.0 in Excel format(includes comparison chart to SOPine) SOEDGE Module Pin Assignment ver 1.0 in Open Document format(includes comparison chart to SOPine) SOEDGE Neural AI Stick schematic:\nSOEDGE Neural AI Stick PDF file SOEDGE/SOPINE/PINE A64 WiFi/BT module schematics:\nPINE A64 Wifi/BT Module Schematic SOEDGE module together with the baseboard certification:\nDisclaimer: Please note that SOEDGE module is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, SOEDGE module still submits the mpdel A baseboard for FCC, CE, and ROHS certifications and obtain the certificates to prove that can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available ","permalink":"/documentation/SOEDGE/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":" Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm Input Power: DC 12V @ 3A 5.5OD/2.1ID Barrel DC Jack connector SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard schematics and PCB board resources:\nSOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic 20210223 PDF file SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard 20210223 PCB Component Placement Top PDF file SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard 20210223 PCB Component Placement Bottom PDF file SOEDGE module together with the baseboard certification:\nDisclaimer: Please note that SOEDGE module is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, SOEDGE module still submits the mpdel A baseboard for FCC, CE, and ROHS certifications and obtain the certificates to prove that can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for SOEDGE model A baseboard ","permalink":"/documentation/SOEDGE_Baseboard/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"SOPINE module schematic:\nSOPINE Module Schematic SOPINE pin assignments:\nSOPINE Module Pin Assignment ver 1.0 PINE A64-LTS / SOPINE WiFi/BT module schematic:\nPINE A64 WiFi/BT Module Schematic PINE A64-LTS / SOPINE Stereo Audio DAC board schematic:\nPINE A64-LTS / SOPINE Stereo Audio DAC Board Schematic SOPINE (together with model \u0026ldquo;A\u0026rdquo; baseboard) certification:\nSOPINE with model \u0026ldquo;A\u0026rdquo; baseboard FCC Certificate SOPINE with model \u0026ldquo;A\u0026rdquo; baseboard CE Certificate SOPINE with model \u0026ldquo;A\u0026rdquo; baseboard RoHS Certificate PINE A64, PINE A64+, PINE A64-LTS and SOPINE related Five megapixel CMOS camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) S5K4EC 5MP CMOS Image Sensor SoC Module Datasheet S5K4EC 5MP CMOS Image Sensor SoC Chip Datasheet S5K4EC 5MP CMOS Image Sensor Driver Source Code in C language Early version Camera module information:\nBonsen Kexin V118-A64-GC2145-HM5065 CMOS Image Sensor Module HiMax 5MP CMOS Image Sensor SoC LCD Touch Screen Panel information:\n7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Lithium battery information:\n8000mAH Lithium Battery Specification Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64-LTS Board and SOPINE Baseboard WiFi/BT module information:\nPINE A64 Wifi/BT Module Schematic Realtek RTL8723BS WiFi with BT SDIO Enclosure information:\nPlaybox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port Remote control button mapping:\nOfficial Remote Control for the PINE A64 Button Mapping ","permalink":"/documentation/SOPINE/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard schematic and PCB board resources:\nSOPINE model \u0026ldquo;A\u0026rdquo; Baseboard is an hardware open source project but is not \u0026ldquo;OSH\u0026rdquo; compliant SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic capture Rev B DSN source file SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic Rev B PDF file SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Job source file SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Gerber file SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Layout PDF file SOPINE (together with model \u0026ldquo;A\u0026rdquo; baseboard) certification:\nSOPINE with model \u0026ldquo;A\u0026rdquo; baseboard FCC Certificate SOPINE with model \u0026ldquo;A\u0026rdquo; baseboard CE Certificate SOPINE with model \u0026ldquo;A\u0026rdquo; baseboard RoHS Certificate Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64-LTS Board and SOPINE Baseboard ","permalink":"/documentation/SOPINE_Baseboard/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"SOQuartz Module Schematic:\nSOQuartz Module ver 1.1 20210816 Schematic SOQuartz Module ver 1.1 20210816 PCB Component Placement SOQuartz Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic and PCB Board Resource:\nSOQuartz Model-A baseboard 20220522 Schematic PDF file SOQuartz Model-A baseboard 20220522 Schematic DSN source file SOQuartz SOQuartz Model-A baseboard 20220522 PCB Top Component Placement SOQuartz SOQuartz Model-A baseboard 20220522 PCB Bottom Component Placement SOQuartz Model-A baseboard 20220522 PCB DSN file SOQuartz Model-A baseboard 20220522 PCB Gerber file SOQuartz Blade Baseboard Schematic and PCB Board Resource:\nSOQuartz BLADE 20220522 Schematic SOQuartz BLADE 20220522 PCB component Placement SOQuartz BLADE 1U Rack STP file SOQuartz module certifications:\nSOQuartz module FCC Certificate SOQuartz module CE EMC Certificate ","permalink":"/documentation/SOQuartz/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":"Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm×80mm×19mm\nInput Power: DC 12V @ 3A 5.5mmOD/2.1mm ID center-positive Barrel DC Jack connector\nSchematic:\nSTAR64 Schematic 20230504 v1.1 (Production Released version) STAR64 Schematic 20220721 v1.0 (Prototype Board) Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submits the SBC for FCC, CE, and ROHS certifications and obtain the certificates to prove that the SBC board can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available ","permalink":"/documentation/STAR64/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":" Avaota A1 SBC dimensions\nInput Power: DC 12V @ 3A 5.5mmOD/2.1mmID center-positive Barrel DC Jack connector\nSchematic:\nYuzuki Avaota-A1 Schematic v1.7 Board map of connectors with schematic v1.1 identifiers:\nAvaota A1 SBC layout\nCertifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submits the SBC for FCC, CE, and ROHS certifications and obtain the certificates to prove that the SBC board can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available ","permalink":"/documentation/Yuzuki_Avaota-A1/Further_information/Schematics_and_certifications/","tags":null,"title":"Schematics and certifications"},{"categories":null,"contents":" PINE H64 Pi-2/Euler/Ext Bus Connector Pin Assignment PINE H64 Board Schematic:\nPINE H64 1GB/2GB/3GB Rev 1.1 Board Schematic PINE H64 Certification:\n[Not yet available] ","permalink":"/documentation/PINE_H64_Model_A/Further_information/Schematics_and_Certifications/","tags":null,"title":"Schematics and Certifications"},{"categories":null,"contents":" PINE H64 Model B Pi-2 Bus and EXP Bus Connector Pin Assignment PINE H64 board schematics:\nPINE H64 Model B 1GB/2GB/3GB Rev 1.2 Board Schematic PINE H64 Model B certification:\nPINE-H64 Model-B FCC Certificate PINE-H64 Model-B CE Certificate] ","permalink":"/documentation/PINE_H64_Model_B/Further_information/Schematics_and_Certifications/","tags":null,"title":"Schematics and Certifications"},{"categories":null,"contents":"Documents:\nPineBuds Pro User Manual Schematics:\nPineBuds Pro Earbuds Schematic 20220817 PineBuds Pro Charging Case Schematic 20220915 Certifications:\nPineBuds Pro CE EMC Certificate PineBuds Pro CE RED Certificate PineBuds Pro FCC Certificate PineBuds Pro ROHS Report ","permalink":"/documentation/PineBuds_Pro/Further_information/Schematics_and_Certifications/","tags":null,"title":"Schematics and Certifications"},{"categories":null,"contents":" Schematics and Board Data Pinecil V2 mainboard schematic Pinecil mainboard schematic ver 2.0 20220608, this is production version schematic Pinecil mainboard ver 2.0 PCB Component Placement PDF file Pinecil V1 mainboard schematic V1 was only sold until July 2022, and then discontinued for newer V2 model\nPinecil mainboard schematic ver 1.0 20201120, this is production version schematic Pinecil mainboard ver 1.0 PCB Component Placement Top PDF file Pinecil mainboard ver 1.0 PCB Component Placement Bottom PDF file Pinecil mainboard ver 1.0 PCB Component Placement Top Drawing file Pinecil mainboard ver 1.0 PCB Component Placement Bottom Drawing file Datasheets for Components Pinecil V2 datasheets Power MOSFET Switch: HSM4313, location U13 (Replacement HSM4313). LDO Regulator: LP 3986-33, Ultra-low noise, location U5 (Replacement LP 3986-33). Buck Converter: TP6841S6 40V, Step-Down, location U8, (Replacement TP6841S6-A). USB-C PD Controller: FUSB302MPX, location U1, (Replacement FUSB302MPX) Acceleration/Gyroscope: SC7A20 sensor, Silan, location U9 (replacement unknown). NTC Temperature Sensor: NTCG163JF103FTDS, location NTC1 (Replacement NTC here). Note that U10 is empty if NTC type thermistor is used. Optional Hall Effect Sensor: Si7210-B-00-IV(R) by Silicon Labs, location U14. This is a user add-on and does not come installed on the pcb. (How magnets work near Hall Sensor Si7210) (Replacement Si7210-B-00-IV, also at Digikey and Mouser) Operational Amplifier SGM8557-1AXN5G, SGMicro, Low Noise OP Amp Datasheet, location U11 (replacement unknown). Display Screen OLED QUG-9616TSWCG02 datasheet (Replacement QUG-9616TSWCG02 OLED Display). MCU: Bouffalo Labs, BL-706_QFN48, RISC-V + 2.4 GHz RF SoC\nBL706 Analysis, by Lupyuen, includes datasheet, location U15. BL706 datasheet BL706 Reference Manual SDK and Bouffalo documents SMD Resonator for Bluetooth BLE, 32MHZ/12PF-10PPM, SMD2016-4P, location UX1 (Replacement SMD Resonator). USB-C port:\npossible part, has not been verified: Replacement USB-C port Pinecil V1 datasheets Buck converter: RT7272B 3A Datasheet, Ricktek, Step-Down converter, location U8 LDO Regulator: LP 3986-33, location U5, (Replacement here). MOSFET Switch: CJQ7328 8A datasheet, Chang Jiang. Hint: people have replaced V1 mosfet using the better rated one from the newer V2 datasheets (HSM4313 has same footprint and higher rating), see V2 section for MOSFET. Acceleration Bosch BMA223 Sensor Datasheet Temperature Sensor: Analog Device TMP36 Datasheet, location U10, (possible replacement here). Optional Hall Effect Sensor: Si7210-B-00-IV(R) by Silicon Labs, location U14. This is a user add-on and does not come installed on the pcb. (How magnets work near Hall Sensor Si7210) (One place to buy it, also at Digikey and Mouser) OLED Display screen: QUG 9616TSWCG02 Display Module Datasheet USB Type-C PD Controller: FUSB302 USB PD Datasheet OP Amp information: SGMicro SGM8557-1 Low Noise OP Amp Datasheet (U11) Capacitors: possible replacement part for C5, 1uF/50V USB-C port: possible part, has not been verified: Replacement GigaDevice RISC-V SoC data:\nGigaDevice RISC-V GD32VF103TB SoC Datasheet V1.1 GigaDevice RISC-V GD32VF103TB SoC Usermanual V1.2 Breakout Board Datasheet: LP6498B6F 1.2A Switching Power Regulator\n","permalink":"/documentation/Pinecil/Further_information/Schematics_and_datasheets/","tags":null,"title":"Schematics and datasheets"},{"categories":null,"contents":"The official screen protector can be found in the Pine64 store under PinePhone Tempered Glass Screen Protector.\nMost screen protectors for the iPhone 11 Pro Max, iPhone XS Max and Huawei Y7 (2018) fit the PinePhone if the top notch is not obscured by a black foil or a similar obstruction.\n","permalink":"/documentation/Phone_Accessories/Screen_protectors/","tags":null,"title":"Screen protectors"},{"categories":null,"contents":" The Problem PineTime ships with the MCUBoot bootloader which boots to the InfiniTime Firmware This assumes that the firmware (InfiniTime, Mynewt, Zephyr, \u0026hellip;) has its own Bluetooth LE (BLE) stack and can handle firmware updates (DFU) But some firmware (wasp-os, ATCwatch) require Nordic SoftDevice to be installed to support the BLE and DFU functions InfiniTime Firmware does not support flashing of SoftDevice as firmware update, because SoftDevice is usually flashed at address 0x1000 (plus a 4k MBR at 0 to switch between the bootloader and the softdevice), which is used by the MCUBoot Bootloader How do we allow SoftDevice-based firmware to be flashed to PineTime via DFU? Dual Bootloader Modes Process PineTime will support 2 Bootloader Modes: MCUBoot and SoftDevice. Default is MCUBoot Mode. The two bootloaders will not coexist, they will be mutually exclusive. This allows a different flash ROM map for each bootloader. To switch from MCUBoot Mode to SoftDevice Mode:\nWe will use DFU to flash a SoftDevice Loader Firmware, which will boot and replace MCUBoot by SoftDevice Thereafter, when PineTime boots, it will start SoftDevice and will be ready to accept SoftDevice-based firmware for DFU: wasp-os, ATCWatch To switch from SoftDevice Mode to MCUBoot Mode:\nWhen we need to switch back to MCUBoot-based firmware (InfiniTime, Mynewt, Zephyr, \u0026hellip;), we will run an MCUBoot Loader (based on https://github.com/daniel-thompson/wasp-reloader ) to replace SoftDevice by MCUBoot plus a Minimal DFU Firmware that accepts DFU commands After rebooting, MCUBoot starts the Minimal DFU Firmware, which will accept MCUBoot-based firmware for flashing The MCUBoot-based firmware replaces the Minimal DFU Firmware Switching modes with Companion App The PineTime Companion App (e.g. Gadgetbridge) will switch modes automatically depending on the firmware to be flashed. So PineTime Owners will never have to switch modes themselves. For SoftDevice-based firmware, the Companion App will also know which SoftDevice version is needed by the firmware, and load the right SoftDevice version. Custom MBR It’s possible to customize (SoftDevice’s) MBR so that it can coexist with MCUBoot.\nPros:\nSeamless switching between the two different boot modes. Both MCUBoot and SD can be used. Cons:\nTechnically more complex - documentation isn’t the best, SoftDevice’s future support for custom MBR might be unknown Should be explored further.\nExternal resources about custom MBR https://devzone.nordicsemi.com/f/nordic-q-a/27599/boot-sequence-for-nrf52832 https://aykevl.nl/2018/01/mbr-softdevice-internals https://forum.pine64.org/showthread.php?tid=9779\u0026pid=65203#pid65203 wasp-reloader wasp-reloader is a simple bare-metal C program that, in a fairly brutal fashion, can rewrite critical parts of the internal flash. It has fairly robust checksumming to avoid flashing problems and verifies that what it written is what is supposed to be written. Having said that more checks (no self-overwrite, battery level) would be nice. When complete it stops updating the watchdog in order to provoke get a clean reset. As a standalone app it can be loaded into the secondary slot using Infinitime DFU upgrade.\nCurrently it has linker scripts for SD132 V6.1.1 and can flash any payload smaller than SD132.\nTo be used to install SoftDevice from mcuboot it would need linker scripts for mcuboot (to ensure the reloader sits high enough in flash to avoid a self-overwrite). To install mcuboot we need an Intel HEX file of the mcuboot payload and InfiniTime (we have to write it in one shot to keep BLE updates working after switching bootloaders). This may need custom linker scripts depending on how big the InfiniTime binaries are.\n","permalink":"/documentation/PineTime/Flashing/SD_MCUBoot/","tags":null,"title":"SD MCUBoot"},{"categories":null,"contents":"Stock Linux:\nDirect Download from pine64.org (MD5 (7zip file): efac108dc98efa0a1f5e77660ba375f8, file size: 3.50GB) Compilation:\nYou can either setup a machine for the build environment, or use a Vagrant virtual machine provided by Elimo Engineering\nCompile on a dedicated machine Recommended system requirements:\nOS: (L)Ubuntu 16.04 CPU: 64-bit based Memory: 8 GB or higher Disk: 15 GB free hard disk space Install required packages:\nsudo apt-get install p7zip-full git make u-boot-tools libxml2-utils bison build-essential gcc-arm-linux-gnueabi g++-arm-linux-gnueabi zlib1g-dev gcc-multilib g++-multilib libc6-dev-i386 lib32z1-dev Install older Make 3.82 and Java JDK 6:\npushd /tmp wget https://ftp.gnu.org/gnu/make/make-3.82.tar.gz tar xfv make-3.82.tar.gz cd make-3.82 ./configure make sudo apt purge -y make sudo ./make install cd .. # Please, download jdk-6u45-linux-x64.bin from https://www.oracle.com/java/technologies/javase-java-archive-javase6-downloads.html (requires free login) chmod +x jdk-6u45-linux-x64.bin ./jdk-6u45-linux-x64.bin sudo mkdir /opt/java/ sudo mv jdk1.6.0_45/ /opt/java/ sudo update-alternatives --install /usr/bin/javac javac /opt/java/jdk1.6.0_45/bin/javac 1 sudo update-alternatives --install /usr/bin/java java /opt/java/jdk1.6.0_45/bin/java 1 sudo update-alternatives --install /usr/bin/javaws javaws /opt/java/jdk1.6.0_45/bin/javaws 1 sudo update-alternatives --config javac sudo update-alternatives --config java sudo update-alternatives --config javaws popd PineCubes SPI Flash support patch:\nFrom 9316112c37ee86645fd691c6d3352183b95177d8 Mon Sep 17 00:00:00 2001 From: Marek Kraus \u0026lt;gamelaster@outlook.com\u0026gt; Date: Fri, 8 Jul 2022 21:01:47 +0200 Subject: [PATCH] Add support for xt25f128 SPI Flash --- drivers/mtd/devices/m25p80.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index 31e5795..0f46a4c 100755 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -803,6 +803,7 @@ static const struct spi_device_id m25p_ids[] = { { \u0026#34;w25x64\u0026#34;, INFO(0xef3017, 0, 64 * 1024, 128, SECT_4K) }, { \u0026#34;w25q64\u0026#34;, INFO(0xef4017, 0, 64 * 1024, 128, SECT_4K) }, { \u0026#34;W25q128\u0026#34;, INFO(0xef4018, 0, 64 * 1024, 256, 0) }, +\t{ \u0026#34;xt25f128\u0026#34;, INFO(0x0b4018, 0, 64 * 1024, 256, SECT_4K) }, /* Catalyst / On Semiconductor -- non-JEDEC */ 7.4 Unpack SDK and then compile and pack the image:\n7z x \u0026#39;PineCube Stock BSP-SDK ver1.0.7z\u0026#39; mv \u0026#39;PineCube Stock BSP-SDK ver1.0\u0026#39; pinecube-sdk cd pinecube-sdk/camdroid # apply SPI Flash patch above or edit m25p80.c file source build/envsetup.sh lunch # select [1] here mklichee extract-bsp make -j3 pack Compile using Vagrant You can avoid setting up your machine and just use Vagrant to spin up a development environment in a VM.\nJust clone the Elimo Engineering repo and follow the instructions in the readme file\nAfter spinning up the VM, you just need to run the build:\ncd pinecube-sdk/camdroid # apply SPI Flash patch above or edit m25p80.c file source build/envsetup.sh lunch # select [1] here mklichee extract-bsp make -j3 pack Flashing the image See PhoenixCard for a manual on how to flash Allwinners BSP images.\n","permalink":"/documentation/PineCube/Software/SDK/","tags":null,"title":"SDK"},{"categories":null,"contents":" Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. Encryption While encryption alone is not sufficient to protect sensitive data, it is an important tool to safeguard data in certain attack vectors.\nFull-Disk Encryption Full-disk encryption encrypts the entire disk (except for the boot bits). Currently some operating systems such as postmarketOS and Mobian offer an installation image, which have the option to encrypt the entire disk. Some operating systems, such as postmarketOS (via pmbootstrap) and Arch Arm also offer an installation script for an fully encrypted installation.\nDecryption is done at boot after entering the encryption password via an on-screen keyboard (Osk-sdl).\nEncrypted home directory SSH An open SSH port is a typical gateway for attackers on any device exposed to the public Internet. Exposed devices might be attacked within minutes after being exposed. Typically such attacks try default passwords such as \u0026ldquo;12345\u0026rdquo;, potentially putting the user at risk after connecting the phone to an open/unsecured access point, activating mobile data or mobile Internet.\nFor safety reasons it is highly recommended to only use SSH in combination with keys, instead of simple numeric passwords.\nTo generate a key pair for ssh, open a terminal on your local computer, and type\nssh-keygen It will ask you where to save the key pair. By default, this is in ~./ssh . Usually it’s best to keep it in the default location. If you have previously generated a key pair, it will ask you if you wish to overwrite your existing one. You probably do not want to do this, as you will no longer be able to use your existing key pair for authentication.\nNext, you will be prompted to enter a passphrase. It is recommended that you use this feature.\nNote Do not share your private key with anyone, nor change its file permissions Now, you must start SSHD on your distribution of choice, as this process varies depending on init system, please consult the documentation of your distribution.\nNow enabled, you can copy over your public key either manually, or via\nssh-copy-id $username@$ipaddress replacing the variables \u0026ldquo;$username\u0026rdquo; and \u0026ldquo;$ipaddress\u0026rdquo; with the appropriate values, e.g user@192.168.1.15\nYou may see a message similar to this\nOutput The authenticity of host '192.168.1.15 (192.168.1.15)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:57:fe:23:44:e1:55:00:bd:d6:6d:42:fe. Are you sure you want to continue connecting (yes/no)? This will happen anytime you connect to a new host. Type \u0026ldquo;yes\u0026rdquo; and hit enter.\nfinally, to disable password authentication, type\nsed -i -E 's/#?PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config as root on your PinePhone and either restart the sshd service, or reboot your device\n","permalink":"/documentation/PinePhone/Software_tricks/Security/","tags":null,"title":"Security"},{"categories":null,"contents":"It’s possible to use the PineCube as an inside or outside security camera using motion. For outside, you’ll need an enclosure with a transparent dome to protect from the weather. One suggestion is to mount the camera with the lens as close as possible to the dome to avoid reflection.\nThe Motion package can be installed in a variety of Linux flavors. There’s a package in the standard Ubuntu and Debian repositories and works with Armbian. It provides a very simple web interface for live viewing of the camera feed and also has motion trigger capabilities to store either still pictures or in later versions videos. Note that it is also possible to build hooks to automatically process or upload those recordings.\nTo get things working quickly with motion you can set the following in the /etc/motion/motion.conf and start it with \u0026ldquo;sudo /etc/init.d/motion start\u0026rdquo;\nv4l2_palette 14 # UYVY8 width 640 height 480 framerate 15 This mode and resolution works fine with Motion and works well with video motion capture (Motion version \u0026gt;= 4.2.2). However, if you want different modes and resolutions you’ll need to set the camera to those modes with the media-ctl tool that comes with the v4l-utils package. That will need to be set before the motion service starts. A simple method to ensure that it gets set before motion starts every time, even across reboots, is to make a small modification to the /lib/systemd/system/motion.service\n[Service] Type=simple User=motion ExecStartPre=/usr/bin/media-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:UYVY8_2X8/1280x720@1/15]\u0026#39; # \u0026lt;=- Add this line here with the mode that the camera will use ExecStart=/usr/bin/motion Note that you must modify /etc/motion/motion.conf to match the v4l2_palette, width, height and framerate to match the mode you set with media-ctl. See the Motion documentation to match the v4l2_palette to the mode. Here are a list of modes that have been tried so far.\nUYVY8_2X8/640x480@1/30 UYVY8_2X8/640x480@1/15 UYVY8_2X8/1280x720@1/15 # This one seems to be fine for live viewing, but causes performance problems when using Motion to capture videos JPEG_1X8/1280x720@1/15 ","permalink":"/documentation/PineCube/Projects/Security_camera_with_Motion/","tags":null,"title":"Security camera with Motion"},{"categories":null,"contents":" Under construction This page or section is under construction Please help to review and edit this page or section. Information are subject to change. Overview The PinePhone contains various components that enable or aid orientation and navigation tasks.\nMulti-GNSS Receiver as part of the cellular modem (GPS/Galileo/GLONASS/BeiDou) IMU (Inertial Measurement Unit), combined Accelerometer and Gyroscope sensor (MPU6050) Magnetometer (LIS3MDL or AF8133J) PinePhone navigation sensors\nHardware Quectel EG25G Modem / GNSS Receiver Invensense/TDK MPU6050 IMU Key features:\nDigital-output X-, Y-, and Z-Axis angular rate sensors (gyroscopes) with selectable range of ±250, ±500, ±1000, and ±2000°/sec Digital-output triple-axis accelerometer with a programmable full scale range of ±2g, ±4g, ±8g and ±16g 400 kHz Fast Mode I2C for communicating with all registers ST LIS3MDL Magnetometer/Compass Key features:\n±4/±8/±12/±16 gauss selectable magnetic full scale range 16-bit data output \u0026hellip; VTC AF8133J Magnetometer/Compass Key features:\n±12/±22 gauss selectable magnetic full scale range 400Hz max. update rate 16-bit data output Sensor reference frames The sensors are mounted on the PinePhone’s mainboard in different positions and orientations. For the purpose of orientation and navigation it is important to know the relationship between the sensor coordinate frames and the body frame of the phone.\nPinePhone sensor coordinates systems (red) and body coordinate system (cyan)\nAs a basis for software development, a common body coordinate system has to be established along with it’s relation to a world coordinate system. \u0026ldquo;iio-sensor-proxy expects the (sensor) readings to match those defined in the Linux IIO documentation, the Windows Integrating Motion and Orientation Sensors whitepaper, and the Android sensor documentation\u0026rdquo;[ref]. To transform the sensor coordinate systems into body coordinates, \u0026lsquo;mount matrices\u0026rsquo; have to be defined.\nTODO: explain body reference choices, north-east-down world coordinates\nSoftware Drivers TODO: i2cdev, linux-iio, support matrix\nEG25G: provides either UART or USB based interfaces for NMEA data /dev/ttyUSB2: AT command interface /dev/ttyUSB1: default NMEA data output MPU6050:inv_mpu6050, inv_mpu6050_i2c, industrialio iio:device2: mpu6050 (buffer capable) 9 channels found: accel_x: (input, index: 0, format: be:S16/16\u0026gt;\u0026gt;0) 6 channel-specific attributes found: attr 0: calibbias value: -2102 attr 1: matrix value: 0, 0, 0; 0, 0, 0; 0, 0, 0 attr 2: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 3: raw value: 912 attr 4: scale value: 0.000598 attr 5: scale_available value: 0.000598 0.001196 0.002392 0.004785 accel_y: (input, index: 1, format: be:S16/16\u0026gt;\u0026gt;0) 6 channel-specific attributes found: attr 0: calibbias value: 941 attr 1: matrix value: 0, 0, 0; 0, 0, 0; 0, 0, 0 attr 2: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 3: raw value: 516 attr 4: scale value: 0.000598 attr 5: scale_available value: 0.000598 0.001196 0.002392 0.004785 accel_z: (input, index: 2, format: be:S16/16\u0026gt;\u0026gt;0) 6 channel-specific attributes found: attr 0: calibbias value: 1242 attr 1: matrix value: 0, 0, 0; 0, 0, 0; 0, 0, 0 attr 2: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 3: raw value: 15860 attr 4: scale value: 0.000598 attr 5: scale_available value: 0.000598 0.001196 0.002392 0.004785 temp: (input) 3 channel-specific attributes found: attr 0: offset value: 12420 attr 1: raw value: -1073 attr 2: scale value: 2.941176 anglvel_x: (input, index: 4, format: be:S16/16\u0026gt;\u0026gt;0) 5 channel-specific attributes found: attr 0: calibbias value: 0 attr 1: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 2: raw value: -32 attr 3: scale value: 0.001064724 attr 4: scale_available value: 0.000133090 0.000266181 0.000532362 0.001064724 anglvel_y: (input, index: 5, format: be:S16/16\u0026gt;\u0026gt;0) 5 channel-specific attributes found: attr 0: calibbias value: 0 attr 1: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 2: raw value: 4 attr 3: scale value: 0.001064724 attr 4: scale_available value: 0.000133090 0.000266181 0.000532362 0.001064724 anglvel_z: (input, index: 6, format: be:S16/16\u0026gt;\u0026gt;0) 5 channel-specific attributes found: attr 0: calibbias value: 0 attr 1: mount_matrix value: 0, 1, 0; -1, 0, 0; 0, 0, -1 attr 2: raw value: 0 attr 3: scale value: 0.001064724 attr 4: scale_available value: 0.000133090 0.000266181 0.000532362 0.001064724 timestamp: (input, index: 7, format: le:S64/64\u0026gt;\u0026gt;0) gyro: (input, WARN:iio_channel_get_type()=UNKNOWN) 1 channel-specific attributes found: attr 0: matrix value: 0, 0, 0; 0, 0, 0; 0, 0, 0 3 device-specific attributes found: attr 0: current_timestamp_clock value: realtime attr 1: sampling_frequency value: 50 attr 2: sampling_frequency_available value: 10 20 50 100 200 500 2 buffer-specific attributes found: attr 0: data_available value: 0 attr 1: watermark value: 1 Current trigger: trigger1(mpu6050-dev2) LIS3MDL: st_sensors, st_sensors_i2c, st_magn, st_magn_i2c, industrialio iio:device1: lis3mdl (buffer capable) 4 channels found: magn_x: (input, index: 0, format: le:S16/16\u0026gt;\u0026gt;0) 3 channel-specific attributes found: attr 0: raw value: 6766 attr 1: scale value: 0.000146 attr 2: scale_available value: 0.000146 0.000292 0.000438 0.000584 magn_y: (input, index: 1, format: le:S16/16\u0026gt;\u0026gt;0) 3 channel-specific attributes found: attr 0: raw value: -2046 attr 1: scale value: 0.000146 attr 2: scale_available value: 0.000146 0.000292 0.000438 0.000584 magn_z: (input, index: 2, format: le:S16/16\u0026gt;\u0026gt;0) 3 channel-specific attributes found: attr 0: raw value: 12726 attr 1: scale value: 0.000146 attr 2: scale_available value: 0.000146 0.000292 0.000438 0.000584 timestamp: (input, index: 3, format: le:S64/64\u0026gt;\u0026gt;0) 3 device-specific attributes found: attr 0: current_timestamp_clock value: realtime attr 1: sampling_frequency value: 1 attr 2: sampling_frequency_available value: 1 2 3 5 10 20 40 80 2 buffer-specific attributes found: attr 0: data_available value: 0 attr 1: watermark value: 1 Current trigger: trigger0(lis3mdl-trigger) Userspace services TODO: \u0026hellip;\nModem Manager ofono gpsd iio-sensor-proxy geoclue Tools/Utilities TODO: minicom, gpsmon, monitor-sensor, iio-utils\u0026hellip;\nApplications TODO: pure-maps, navit, \u0026hellip;\nDevelopment TODO: Open issues, tasks, projects\nOpen issues AGPS integration how to enable/disable the service? update triggers? network connectivity? agps data valid? Raw magnetometer handling Issue: Support polling/non-compensated magnetometers in iio-sensor-proxy https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/issues/310 https://gitlab.freedesktop.org/hadess/iio-sensor-proxy/-/merge_requests/316 (needs more work) Issue: raw magnetometer calibration implementation https://appelsiini.net/2018/calibrate-magnetometer/ GPS/Compass App TODO: specification Frameworks/APIs/\u0026hellip; Modem Manager location API https://www.freedesktop.org/software/ModemManager/api/latest/gdbus-org.freedesktop.ModemManager1.Modem.Location.html oFono location API (experimental?) https://git.kernel.org/pub/scm/network/ofono/ofono.git/tree/doc/location-reporting-api.txt geoclue API https://www.freedesktop.org/software/geoclue/docs/gdbus-org.freedesktop.GeoClue2.Location.html https://www.freedesktop.org/software/geoclue/docs/libgeoclue/GClueLocation.html ","permalink":"/documentation/PinePhone/Further_information/Sensors_and_navigation/","tags":null,"title":"Sensors and navigation"},{"categories":null,"contents":"Connecting to the ROCKPro64 single-board computer serial interface can sometimes be tricky, as the lack of buffering can cause the Uboot-SPL to stop functioning due to transient voltage spikes during startup. This simple circuit allows a user to hot-plug their serial connection at any time, or can be left attached full time.\nWarning Please note that following these instructions comes at your own risk. While best efforts have been made to write reliable, safe instructions, the author cannot be held liable for the quality of procured components or the assembly job of the person following the instructions, and the damages caused by either of these not being up to par. Shopping List Components You may have some or all of these in your junk/parts drawer. They’re all common value, and easily recovered from scrap circuit-boards.\n3\u0026quot;x4\u0026quot; perf board, will be used for construction of the circuit misc breakout board wires, or any random copper wire that works, I used ribbon cable from an old floppy harness. misc jumper wire with headers, a three-pin header, and a one-pin header, since you’ll be connecting to the RP64 mainboard pin headers in different places Transistors, 1 (one) NPN-type, 2n2222 or equivalent; and 1 (one) PNP-type, 2n2907 or equivalent Resistors, 3 (three) 4.7kΩ 1/4-watt; and 2 (two) 10kΩ 1/4-watt Serial interface jack, 3-pin TRS audio jack works well, as does RJ45 or DB9. You only need, and use, 3 pins though. Double-sided sticky tape, at least 1\u0026quot;x1\u0026quot;, to mount the perf board to your case. Tools A soldering iron, e.g. the Pinecil solder, fine gauge, anything suitable for electronics Wire strippers, suitable for the thickness of wire you chose Diagonal cutters, to trim excess leads from components and wires Assembly Start by creating \u0026ldquo;vias\u0026rdquo; using a stretch of bare wire for both ground and +3.3v along the long edges of the perf board; ground on one side, +3.3v on the opposite At one end of the perf board, start laying out the parts for the NPN transistor portion of the circuit, then solder down. At the opposite end, lay out the PNP transistor portion, and solder down. Connect up the serial interface jack, using enough wire to reach your desired mounting point on your case, from the mounting place for this board Solder the jumper wires to the perf board for the serial jack Solder the header jumpers to the perf board, making sure they’re long enough to reach the RP64 headers with a bit of slack. Let cool, affix the double-sided tape, and mount to your case. Install Mount your serial port Serial RX \u0026lt;-\u0026gt; DCE RX (in) Serial TX \u0026lt;-\u0026gt; DCE TX (out) attach the header jumpers to their respectively labeled points on the various headers RP64 Ground \u0026lt;-\u0026gt; pi2bus-6 RP64 RX (in) \u0026lt;-\u0026gt; pi2bus-8 RP64 TX (out) \u0026lt;-\u0026gt; pi2bus-10 RP64 3.3v \u0026lt;-\u0026gt; pi2bus-1 Circuit ","permalink":"/documentation/ROCKPro64/Hardware/Serial_buffer_circuit/","tags":null,"title":"Serial buffer circuit"},{"categories":null,"contents":"These are instruction guides for the disassembly:\nNote The installation process is the reverse order of removal guide 11.6″ Pinebook:\nLithium Battery Pack Removal Guide LCD Panel Screen Removal Guide eMMC Module Removal Guide 14″ Pinebook:\nLithium Battery Pack Removal Guide LCD Panel Screen Removal Guide eMMC Module Removal Removal Guide ","permalink":"/documentation/Pinebook/Service_guides/","tags":null,"title":"Service guides"},{"categories":null,"contents":"This article applies only to the main Pine Store, pine64.com items that ship from their Shenzhen, China facility, such as the Pinecil soldering iron and PinePower chargers.\nNot discussed in this article: big battery devices such as the Pinebook Pro, PineTab, PineNote, PinePhone and PinePhone Pro which all ship from Hong Kong (the PinePhone ships from Poland for EU orders).\nHow does it work? Order Email: when the Pine Store receives an order, an initial email is sent out within one day. This email confirms your order was charged (check spam folders for \u0026lsquo;Pine Store\u0026rsquo;). Shipping Email: after several more days, when the order is shipped, a second email is sent with a tracking number. This could take a week or two. Pine does shipments in batches, you get the tracking number faster or slower depending on when batch day is. In general, people report getting a shipping/tracking email within 5 days, just wait for this email (search emails for \u0026lsquo;Pine Store\u0026rsquo;). If you don’t get the first \u0026ldquo;order email\u0026rdquo; soon after placing the order, then contact the Pine Store here as your order may not have completed or been charged. Courier options Cheap shipping (~$12): could take 2-7 weeks or more, this sometimes gets delayed in the customs department in your home country due to backlogs (some had 7 weeks mainly because it was stuck in their country’s customs department for many weeks before being cleared to leave customs, especially during height of COVID and reduced customs staffing). Currently, members report about 2-3 weeks, as always it can be held up in the customs department of your country if you are shipping it from outside of your country. Courier shipping: more expensive (~$25-$30), can take ~4-10 business days or more based on feedback from PINE64 members. Pine Store shipping policy (30-day warranty starts when Pinecil is delivered). Note: resellers operate independently from the main Pine Store. They are in different countries and set all of their own procedures, shipping costs and options. Get all reseller shipping details for each store from their specific websites/chat tools/email. Tracking The tracking number issued in the shipping email may not work for a couple days, just check again. https://parcelsapp.com/ https://www.17track.net/ If you see the message \u0026ldquo;outbound imports cancelled\u0026rdquo;, just wait. It is a poorly worded message. Members experience that it updates after 1-3 days to show a hand off from China Post to a USA facility. The message would be more clear if it was \u0026ldquo;outbound imports transferred/complete\u0026rdquo;. Why doesn\u0026rsquo;t Pine Store Ship to my country? If Pine Store does not ship to your country currently, check out one of the many legit resellers here. Try emailing a few of the resellers, you might get lucky. Consider that resellers probably don’t want to lose money sending a package that doesn’t get there because then the customer asks for a refund. Keep in mind that the Pine Store is small with a limited number of staff. Some major couriers have temporarily stopped shipping to some countries. Customs paperwork for some countries is too difficult for a small business like Pine Store to manage. If Customs laws change in some countries, Pine Store may have to move from cheaper shipping options to more expensive courier options. Too many packages have gotten lost to some countries. Pinecil and other items have a low margin; lost packages have a great impact. Some resellers are more prepared to take the risks so that the Pine Store can stay focused on engineering new hardware. When possible, the Pine Store leaves open the more expensive courier option instead of stopping all shipping to a country. Some friends try to do a group purchase to spread out the shipping cost for each person. Pine Store is registered at Hong Kong/Singapore and is not a registered China company and therefore can not ship to China addresses (exports only) even though many Pine64 products like Pinecil are made and shipped from Shenzhen, China. Pine Store can not sell on AliExpress (see above). All AliExpress items using the PINE64 and Pinecone logos are fake copies (see authenticity here). For some countries people reported using a package forwarding company (unsure if safe or reliable, use at your own risk). ","permalink":"/documentation/Pinecil/Purchase/Shipping_and_tracking/","tags":null,"title":"Shipping and Tracking"},{"categories":null,"contents":"This page is about the community project to bring a silicone case to the PineBuds Pro.\nIntroduction The idea is to create a silicone case like this for PineBuds Pro.\nConcept \u0026ldquo;Design a mold, use a hobby 3D printer to manufacture it, then fill with silicone.\u0026rdquo; (source) \u0026ldquo;You can find a local hackspace or makerspace. Or you can use one of the many services available via the Internet who can print a model for you. Just design, upload, and pay.\u0026rdquo; (source) \u0026ldquo;The only one I know of is \u0026ldquo;https://www.pcbway.com/rapid-prototyping/injection-molding/\"\" (source) ","permalink":"/documentation/PineBuds_Pro/Community_projects/Silicone_case/","tags":null,"title":"Silicone case"},{"categories":null,"contents":"Template files for creating custom skins. Each includes template layers for art placement, and CUT lines:\nCase Lid Template Case Bottom Template Case Palmrest Template ","permalink":"/documentation/Pinebook_Pro/Guides/Skinning_and_case_customization/","tags":null,"title":"Skinning and case customization"},{"categories":null,"contents":"Based on the Bouffalo Lab BL808\nCPU Architecture XuanTie C906 480 MHz 64-bit RISC-V CPU:\nSupports RISC-V RV64IMAFCV instruction architecture Five-stage single-issue sequentially executed pipeline Level-1 instruction and data cache of Harvard architecture, with a size of 32 KB and a cache line of 64B Sv39 memory management unit, realizing the conversion of virtual and real addresses and memory management jTLB that supports 128 entries Supports AXI 4.0 128-bit master interface Supports core local interrupt (CLINT) and platform-level interrupt controller (PLIC) With 80 external interrupt sources, 3 bits for configuring interrupt priority Supports BHT (8K) and BTB Compatible with RISC-V PMP, 8 configurable areas Supports hardware performance monitor (HPM) units See here XuanTie E907 320 MHz 32-bit RISC-V CPU:\nSupports RISC-V RV32IMAFCP instruction set Supports RISC-V 32-bit/16-bit mixed instruction set Supports RISC-V machine mode and user mode Thirty-two 32-bit integer general purpose registers (GPR) and thirty-two 32-bit/64-bit floating-point GPRs Integer (5-stage)/floating-point (7-stage), single-issue, sequentially executed pipeline Supports AXI 4.0 main device interface and AHB 5.0 peripheral interface 32K instruction cache, two-way set associative structure 16K data cache, two-way set associative structure See here XuanTie E902 150 MHz 32-bit RISC-V CPU:\nSee here System Memory Embedded 64MB PSRAM ","permalink":"/documentation/Ox64/Further_information/SoC_and_Memory_Specification/","tags":null,"title":"SoC and Memory Specification"},{"categories":null,"contents":"The PINE A64-LTS is based on the Allwinner A64/R18. The R18 and A64 are identical SoCs but the is R18 committed for a 10 years supply by the vendor.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard System Memory RAM Memory Variants: 2GB LPDDR3. Storage Memory: 128Mb SPI Flash and optional eMMC module from 16GB up to 128GB ","permalink":"/documentation/Pine_A64-LTS/Further_information/SoC_and_Memory_Specification/","tags":null,"title":"SoC and Memory Specification"},{"categories":null,"contents":"The Pine A64 is based on the Allwinner A64.\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions (LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard System Memory RAM Memory Variants: 512MB, 1GB and 2GB DDR3. Storage Memory: PINE A64 boards do not have built-in Flash memory but use bootable microSD Cards or USB attached storage. ","permalink":"/documentation/Pine_A64/Further_information/SoC_and_Memory_Specification/","tags":null,"title":"SoC and Memory Specification"},{"categories":null,"contents":"The PineNote is based on the Rockchip RK3566.\nCPU Architecture Quad-core ARM Cortex-A55@1.8GHz AArch32 for full backwards compatibility with ARMv7 ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation Includes VFP hardware to support single and double-precision operations ARMv8 Cryptography Extensions Integrated 32KB L1 instruction cache and 32KB L1 data cache per core 512KB unified system L3 cache TrustZone technology support 22nm process, believed to be FD-SOI GPU (Graphics Processing Unit) Capabilities Mali-G52 2EE Bifrost GPU@800MHz 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop 128KB L2 Cache configurations Supports OpenGL ES 1.1, 2.0, and 3.2 Supports Vulkan 1.0 and 1.1 Supports OpenCL 2.0 Full Profile Supports 1600 Mpix/s fill rate when at 800MHz clock frequency Supports 38.4 GLOP/s when at 800MHz clock frequency NPU (Neural Processing Unit) Capabilities Neural network acceleration engine with processing performance of up to 0.8 TOPS Supports integer 8 and integer 16 convolution operations Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet System Memory RAM Memory: 4GB LPDDR4. Flash Memory: 128GB eMMC ","permalink":"/documentation/PineNote/Further_information/SoC_and_memory_specifications/","tags":null,"title":"SoC and memory specifications"},{"categories":["Computer modules"],"contents":" A Powerful AI Compute Module The SOEDGE is a 3TOPS compute module that can be paired with a dedicated baseboard or the SOEDGE Baseboard for development. It can also be connected to a SBC, such as the ROCKPro64, or a regular X86 PC using PCIe or USB 3.0 using special adapters. The SOEDGE is, at the time of writing, in early stages of development; if you are a developer interested in Neural Networks and open hardware, please contact us directly for a development unit.\nFeatures and Specifications SoC 2 x ARM Cortex A35 Processor @ 2.0 GHz Memory DDR4 RAM (2GB) Features A power-efficient ARM 64-Bit Armv8-A architecture AArch32 for full backward compatibility with Armv7 Supports NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache AArch64 for 64-bit support and new architectural features TrustZone security technology Neon Advanced SIMD DSP and SIMD extensions VFPv4 Floating point Hardware virtualization support 128KB L2 cache 128Mb SPI Flash Form factor SODIMM form-factor SODIMM Form-Factor With the small SODIMM form-factor the SOEDGE is perfect for use as a embedded project\n2GB DDR4 RAM Each SOEDGE modules includes 2GB DDR4 RAM\nRockchip RK1808 The RK1808 uses a power efficient Armv8-A archeitecture with dual ARM Cortex A35 cores at 2 GHz\nNPU The RK1808 SoC has a Verisilicon Vivante NPU\nStores Global Global: Accessories Affiliates Documentation SOEDGE Schematics and certifications ","permalink":"/devices/soedge/","tags":null,"title":"SOEDGE"},{"categories":null,"contents":" The SOEDGE\nThe SOEDGE is a 3TOPS compute module that can be paired with the SOEDGE Baseboard, the Clusterboard or USB 3.0 and PCIe adapters for development. It can connect to a SBC, such as the ROCKPro64 or a regular PC.\nReleases Releases for the SOEDGE.\nLinux BSP Full BSP Linux image ver 1.1 Download:\nSOEdge_linux_v1.1.img.gz from pine64.org, MD5 (GZip file): 636ebeb66d6d0fc0929397d541b0ce83, size: 119MB Notes:\nThis is full image version can be applied to the model A baseboard DD image (for 8GB microSD card or eMMC Module and above) Neural AI Stick Linux image ver 1.1 Download:\nSOEdge_linux_usb_compute_stick.img.gz from pine64.org, MD5 (GZip file): 6fddf73a34ea2a1cb6f36be673567b5f, size: 47MB Notes:\nThis is USB 3.0 Neural AI Stick image version DD image (for 8GB eMMC Module and above) BSP Linux ver 1.1 Build from SDK Download:\nSOEdge_linux_v1.1.img.gz from pine64.org, MD5 (TAR-GZip file): a6629f997ae2cae7d9d5324c4e942deda9, size: 119MB Notes:\nPlease unzip first and then using Rockchip tool to flash in Guide to flashing eMMC using Rockchip Tools BSP Linux ver 1.1 Build as USB Stick application from SDK Download:\nSOEdge_linux_usb_compute_stick.img.gz from pine64.org, MD5 (GZip file): af6ac45995f7ddd9343a7052efffaf30, size: 47MB Notes:\nPlease unzip first and then using Rockchip tool to flash in Guide to flashing eMMC using Rockchip Tools BSP Linux ver 1.1 Build from SDK Download:\nSOEdge_linux_v1.1.img.gz from pine64.org, MD5 (TAR-GZip file): a6629f997ae2cae7d9d5324c4e942deda9, size: 119MB Notes:\nPlease unzip first and then using Rockchip tool to flash in Guide to flashing eMMC using Rockchip Tools BSP Linux ver 1.1 Build as USB Stick application from SDK Download:\nSOEdge_linux_usb_compute_stick.img.gz from pine64.org, MD5 (GZip file): af6ac45995f7ddd9343a7052efffaf30, size: 47MB Notes:\nPlease unzip first and then using Rockchip tool to flash in Guide to flashing eMMC using Rockchip Tools Linux BSP SDK Linux BSP Kernel ver 1.1.7 from pine64.org, MD5 (TAR-GZip file): 47a81a990a644539f3a0e84034654f78, size: 17.42GB Full BSP SDK ver 1.1 from pine64.org, MD5 (TAR-GZip file): a66c92e52824762d7c0a63400d6342ea, size: 13.55GB Neural AI Stick BSP SDK ver 1.1 from pine64.org, MD5 (TAR-GZip file): 46f12441e8c35c06184681f355c89651, size: 9.65GB Debugging Serial Console System Serial is located on PI-5 bus (11x2 GPIO header).\nTXD: Pin 6 (Yellow cable) (Connect to RXD on Serial adapter) RXD: Pin 8 (Orange cable) (Connect to TXD on Serial adapter) GND: Pin 10 (Black cable) (Connect to GND on Serial adapter) The default baudrate is 1500000, note that not all serial adapters support this high baudrate.\nFurther information Datasheets\nSchematics and certifications\nSpecification\nDatasheets Rockchip RK1808 SoC information:\nRockchip RK1808 ver 1.2 datasheet Rockchip TK1808 Technical Reference Manual Part 1 Rockchip RK809 PMU (Power Management Unit) information:\nRockchip RK809 PMIC Datasheet DDR4 information:\nMicron DDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nWinBond 128Mb SPI Flash Datasheet GigaDevice 128Mb SPI Flash Datasheet SOEDGE Related:\nLCD Touch Screen Panel information: 7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Ethernet PHY information: Realtek RTL8211 10/100/1000M Ethernet Transceiver for SOEDGE model A baseboard Wifi/BT module information: SOEDGE/SOPINE/PINE A64 Wifi/BT Module Schematic Realtek RTL8723BS WiFi with BT SDIO Enclosure information: Playbox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Connector information: 2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port Schematics and certifications SOEDGE module schematics:\nSOEDGE Module ver 2.0 20190919 Schematic SOEDGE Module ver 2.0 20190919 PCB Component Placement Top PDF file SOEDGE Module ver 2.0 20190919 PCB Component Placement Bottom PDF file SOEDGE Module ver 2.0 20190919 PCB Component Placement Top Drawing file SOEDGE Module ver 2.0 20190919 PCB Component Placement Bottom Drawing file SOEDGE Module Pin Assignment ver 1.0 in Excel format(includes comparison chart to SOPine) SOEDGE Module Pin Assignment ver 1.0 in Open Document format(includes comparison chart to SOPine) SOEDGE Neural AI Stick schematic:\nSOEDGE Neural AI Stick PDF file SOEDGE/SOPINE/PINE A64 WiFi/BT module schematics:\nPINE A64 Wifi/BT Module Schematic SOEDGE module together with the baseboard certification:\nDisclaimer: Please note that SOEDGE module is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, SOEDGE module still submits the mpdel A baseboard for FCC, CE, and ROHS certifications and obtain the certificates to prove that can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Specification Based on the Rockchip RK1808.\nCPU Architecture Dual-core ARM Cortex-A35 Processor@1600-2000Mhz A power-efficient ARM 64-Bit Armv8-A architecture AArch32 for full backward compatibility with Armv7 Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions (LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache AArch64 for 64-bit support and new architectural features TrustZone security technology Neon Advanced SIMD DSP and SIMD extensions VFPv4 Floating point Hardware virtualization support 128KB L2 cache Neural Process Unit NPU Capability NPU IP from Verisilicon Vivante Support max 1920 Int8 MAC operation per cycle Support max192 Int16 MAC operation per cycle Support max 64 FP16 MAC operation per cycle 512KB internal buffer One isolated voltage domain to support DVFS Acuity models Github System Memory RAM Memory Variants: 2GB DDR4. Storage Memory: 128Mb SPI Flash and optional eMMC module from 16GB up to 128GB ","permalink":"/documentation/SOEDGE/_full/","tags":null,"title":"SOEDGE (Single Page)"},{"categories":["Computer modules"],"contents":" SOEDGE Baseboard The SOEDGE Baseboard is a baseboard that hosts the SOEDGE compute module and turns it into a full single board computer. Makers can use this baseboard as reference to develop their own PCBs and for software development during early stages for custom hardware or PCB development.\nFeatures and Specifications Gigabit Ethernet HD Digital Video Out 2x USB 3.0 Host Euler Bus Expansion Bus PI-2 Bus PCIe 4X open-ended header Touch Panel Port (TP) Display Serial Interface (DSI) Port IR R/X Port Real Time Clock Port (RTC) Lithium Battery Port SMOS Sensor Interface Port Optional AC WiFi + BT 5.0 module expansion module Headphone Jack 5.5″ Barrel Power (12V 3A/5A) Port Stores Global Global: Accessories Affiliates Documentation SOEDGE Baseboard Schematics and certifications ","permalink":"/devices/soedge_baseboard/","tags":null,"title":"SOEDGE Baseboard"},{"categories":null,"contents":" The SOEDGE Baseboard\nThe SOEDGE Baseboard is a baseboard that hosts the SOEDGE compute module and turns it into a full single board computer. Makers can use this baseboard as reference to develop their own PCBs and for software development during early stages for custom hardware or PCB development.\nFeatures Expansion ports\nNetwork\nStorage\nExpansion ports DSI - Display Serial Interface, 4 lanes MiPi, up to 1080P TP - Touch Panel Port, SPI with interrupt RTC - Real Time Clock Battery Connector VBAT - Lithium Battery Connector with temperature sensor input Wifi/BT Module Header - SDIO 3.0 and UART 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header PCIe 2x open ended slot Schematics and certifications Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm Input Power: DC 12V @ 3A 5.5OD/2.1ID Barrel DC Jack connector SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard schematics and PCB board resources:\nSOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic 20210223 PDF file SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard 20210223 PCB Component Placement Top PDF file SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard 20210223 PCB Component Placement Bottom PDF file SOEDGE module together with the baseboard certification:\nDisclaimer: Please note that SOEDGE module is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, SOEDGE module still submits the mpdel A baseboard for FCC, CE, and ROHS certifications and obtain the certificates to prove that can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for SOEDGE model A baseboard Network 10/100/1000Mbps Ethernet WiFi 802.11 b/g/n with Bluetooth 4.0 (optional) Storage microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t2 USB2.0 Host port Specifications Gigabit Ethernet HD Digital Video Out 2x USB 3.0 Host Euler Bus Expansion Bus PI-2 Bus PCIe 4X open-ended header Touch Panel Port (TP) Display Serial Interface (DSI) Port IR R/X Port Real Time Clock Port (RTC) Lithium Battery Port SMOS Sensor Interface Port Optional AC WiFi + BT 5.0 module expansion module Headphone Jack 5.5″ Barrel Power (12V 3A/5A) Port Schematics and certifications Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm Input Power: DC 12V @ 3A 5.5OD/2.1ID Barrel DC Jack connector SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard schematics and PCB board resources:\nSOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic 20210223 PDF file SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard 20210223 PCB Component Placement Top PDF file SOEDGE Model \u0026ldquo;A\u0026rdquo; Baseboard 20210223 PCB Component Placement Bottom PDF file SOEDGE module together with the baseboard certification:\nDisclaimer: Please note that SOEDGE module is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, SOEDGE module still submits the mpdel A baseboard for FCC, CE, and ROHS certifications and obtain the certificates to prove that can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for SOEDGE model A baseboard ","permalink":"/documentation/SOEDGE_Baseboard/_full/","tags":null,"title":"SOEDGE Baseboard (Single Page)"},{"categories":null,"contents":" Releases Production release build 20250627 Image for 64GB eMMC module This build contains 7b QWen2 LLM. To access the web UI, open http://alpha-one.local:8000/\nDownload:\nDirect download from PINE64 file server File information:\nMD5 (GZip file): d62eeb1645c7b496a0815c4590f798c7 File Size: 18.10 GB User Password eswin eswin Image for 32GB eMMC module and above This is the early test build that contains both 7b Deepseek and QWen2 LLM build, OS is based on ROCKOS. For larger than 32GB eMMC, please use gpart to extend the file partition.\nDownload:\nDirect download from PINE64 file server File information:\nMD5 (GZip file): 6669a436104e97e2ad90679e06f62d78 File Size: 18.21 GB User Password eswin eswin Usage To explore LLM, use terminal program and execute below command lines:\nDeepSeek 7b LLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/deepseek_r1_distill_qwen_7b/config.json Qwen2 7bLLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/qwen2_7b/config.json Qwen2 0.5bLLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/qwen2_0_5b/config.json SDKs The SDK documents can be found under https://files.pine64.org/SDK/StarPro64/docs.7z (some are in Chinese).\nFile information:\nMD5 (7-Zip file): 8ee9b660c336d9979191d212e9826226 File Size: 34 MB SDK Release:\n20250228: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250228.7z (1.932 GB. MD5 checksum of the 7-Zip file is f9171ec8b30e5d4d8eda1185f72af5e4.) 20250330: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250330.7z (1.946 GB. MD5 checksum of the 7-Zip file is 8ddc861755ed26785e67674aad8db87c.) LLM and tools release:\nLLM 20250228: https://files.pine64.org/SDK/StarPro64/deepseek\u0026qwen-v0228.7z (722 MB. MD5 checksum of the 7-Zip file is b8ee72ee6a8912afefac3fa43a18be87) Tools 20250228: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250228.7z (6.625 GB. MD5 checksum of the 7-Zip file is 868434b274412e173c3e264118dcb336) ","permalink":"/documentation/ALPHA-One/Software/","tags":null,"title":"Software"},{"categories":null,"contents":"The SOPINE operating system images are compatible with PINE A64-LTS. Under Software you will find a complete list of currently supported operating system images, which work with the PINE A64-LTS, as well as other related software.\nBelow is a list of links to the build sources and environments for some operating system images. Some of them are labelled as beta or nightly builds, which means they are fit for testing purposes only. Those images should be used at your own risk and are not fit for regular use.\nlongsleep BSP Linux ayufan Linux ayufan Android 7.1, Android 6.0, and Android 5.1 openSUSE SOPINE Armbian Arch Linux XFCE OpenMediaVault ","permalink":"/documentation/Pine_A64-LTS/Software/","tags":null,"title":"Software"},{"categories":null,"contents":"This page contains a list of all available releases and tools for the Pinebook.\nLinux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. To learn more about AOSC, please visit the official AOSC website.\nDownload:\nhttps://aosc.io/downloads/ Default credentials aosc anthon Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored. To find out more about Armbian and available download options please visit the Armbian ROCK64 site.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ✅ ✅ Download:\nhttps://www.armbian.com/pinebook-a64/ Default credentials root 1234 Debian Debian is an operating system and a distribution of Free Software. The forum thread for release can be found here.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ✅ ✅ Download:\nDebian 11 Bullseye (recommended) Debian 12 Bookworm Daily netboot images Installation:\nThe Readme provides info about concatenating firmware.pinebook.img.gz + partition.img.gz to create a bootable installer image. Notes:\nInstaller offers automatic partitioning and full-disk encryption (LUKS), but only manual partitioning with a single ext4 partition has been confirmed to work. Bootloader must be installed separately after installation, before rebooting. WiFi driver kernel module must be provided during installation, or a USB network adapter used. (Android USB tethering works, with network driver rndis_host). See also: Debian Netboot installer on the 1080P Pinebook under Software releases DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the ROCK64 build on the PINE64 forum thread.\nDownload:\nDebian 11 Bullseye (supports the microSD card and eMMC, 4GB or more) Debian 12 Bookworm (supports the microSD card and eMMC, 4GB or more) Default credentials root dietpi Kali Kali Linux is an Advanced Penetration Testing Linux distribution used for Penetration Testing, Ethical Hacking and network security assessments.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ✅ ✅ Download:\nhttps://www.kali.org/get-kali/#kali-arm Default credentials kali kali Slackware Slackware is a very old, interesting, convenient and easy distribution. Visit the project’s website here (https://fail.pp.ua). You can follow the ongoing discussion about Slackware on the PINE64 forum (https://forum.pine64.org/showthread.php?tid=9439).\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ❓ ✅ ❓ Download:\nDirect download from developer KRT site and look for slarm64-current-aarch64-xfce-rootfs-xxxxxxxx-x.x.xx-pinebook-build-xxxxxxxx.img.lrz Default credentials Root user root/password BSD Image Releases NetBSD NetBSD community build. To learn more about NetBSD please visit the NetBSD main page.\nDownload:\nDirect download latest release build from NetBSD by select 64bit - Pinebook Compatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ❓ ❓ Notes:\nInstructions concerning enabling SSH can be found here Default credentials root (SSH and TTY) [none] OpenBSD OpenBSD 6.6-snapshot, Community Build Image (FVWM2 WM). To learn more about OpenBSD please visit OpenBSD main page. If you need more information please ping: https://forum.pine64.org/member.php?action=profile\u0026uid=12423.\nWarning Outdated release Download:\nSHA256: Community member elewarr’s Dropbox Image: Community member elewarr’s Dropbox Default credentials pine64 (SSH and TTY) pine64 root pine64 Android Image Releases Android 7.x Android 7.1 Community Build Image [microSD Boot] by ayufan. It only works on the 14.1\u0026quot; and 11.6\u0026quot; Pinebook, not applicable to 1080P 11.6\u0026rsquo; Pinebook. Special thanks to ayufan, Icenowy, lennyraposo, longsleep, lukasz, tkaiser, Xalius and PINE64 community contributors. Please use good random IO access performance microSD card such as the Samsung EVO when trying out Android 7.1.\nWarning Outdated release Download:\nayufan’s GitHub, look for android-7.1-pine-a64-pinebook-x.x.x-xx.img.gz (for microSD cards with 4GB or more) Notes:\nPlease allows some time (around 5 minutes) for the initialization process on the first boot. Android 6.x eMMC Android 6.0.1 Rootable build, online update (OTA) only works when the build is not rooted. The LCD resolution is 1366 x 768.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ❌ ✅ Warning Outdated release Download:\nRooted image (for microSD cards with 4GB or more) from pine64.org (776MB, MD5 of the Gzip file C99BF459C6724BA73F12C532E87A8BA5, build 20170605) Notes:\nmicroSD to eMMC Android 6.0.1 Rootable build. The LCD resolution is 1920 x 1080.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ❌ ✅ ❌ Warning Outdated release Download:\nRooted image (for microSD cards with 4GB or more) from pine64.org (595MB, MD5 of the Gzip file E433A148CEBD743EADE6CAA765331A4B, build 20181001) Notes:\nmicroSD to eMMC Android 6.0.1 Rootable build. The LCD resolution is 1920 x 1080. Please use an high performance microSD card for Android. Please ignore the warning message regarding an corrupted SD on the home screen in the upper left corner.\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ❌ ✅ ❌ Warning Outdated release Download:\nFor 8GB microSD cards from pine64.org (553MB, MD5 of the Gzip file CD27DF6083E6A4A5E7C8B986EB92FAA7, build 20181001) For 16GB microSD cards from pine64.org (703MB, MD5 of the Gzip file 1376AAE8382E96FD7B45B0998A5CD6E9, build 20181001) For 32GB microSD cards from pine64.org (867MB, MD5 of the Gzip file B54E7F323B316750654E385B078AEC58, build 20181001) For 64GB microSD cards from pine64.org (734MB, MD5 of the Gzip file C8DBC6293EB51E58F91E27364C8C587D, build 20181001) Notes:\nmicroSD boot /e/ /e/OS community build. To learn more about /e/OS, please visit the official website. Please check out this article on the Pinebook /e/ build. For a thread discussion please visit the PINE64 forum\nCompatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ❌ ✅ ❌ Warning Outdated release Download:\nDirect download from pine64.org (685MB, MD5 of the GZip file: 4DC46A4E3ED2B47F4830E96DFCBBC6D8) Linux BSP SDK Download:\nLinux BSP 4.0 from pine64.org (4.67GB, MD5 of the TAR-GZip file 802D7C92D27177CBD17567359F9845A7) Linux BSP 3.0 from pine64.org (4.18GB, MD5 of the TAR-GZip file 898ACF446851DF3BE7B643F62CE3CE84) Linux BSP 2.0, kernel v3.10 (including GPL compliance header) from pine64.org (6.41GB, MD5 of the TAR-GZip file 2EE11C9AED246C17995493F213A6A6DA) Android SDK Android Marshmallow (v6.0)\nDownload:\nDirect Download from pine64.org (15.92GB, MD5 of the Zip file 12362D0B63EBF29FC363A50A942346D5) Compatibility Pinebook 11.6″ Pinebook 11.6\u0026quot; 1080p Pinebook 14″ ✅ ❓ ❓ Other resources Mali_Driver Allwinner PhoenixCard Bootable SD-Card Creator Allwinner DragonFace V2.2.5 software that will let you edit and modify A64 Android Build PhoenixCard image (Direct download at Mega) ","permalink":"/documentation/Pinebook/Software/","tags":null,"title":"Software"},{"categories":null,"contents":" Firmwares OpenPineBuds Little Buddy Firmware images Flash back factory default firmware using Windows based utility:\nPineBuds Pro Windows based programmer utility user manual PineBuds Pro Windows based programmer utility PineBuds Pro factory default firmware build PineBuds Pro factory default OTA build SDK PineBuds Pro \u0026ldquo;Little Whale\u0026rdquo; SDK date:20221128 ","permalink":"/documentation/PineBuds_Pro/Software/","tags":null,"title":"Software"},{"categories":null,"contents":" Retro-Center’s R-Cade: 100+ retro-gaming systems, a lightweight web browser, and 4k UHD media center on the RockBox R-Cade Mrfixit2001’s Debian Minimal Release (note: can be updated to a more recent Debian using the regular updating tools, except for the kernel and u-boot) LibreELEC Rockchip (note: select LibreELEC-RK3328.arm-9.2.6-rockbox.img.gz) ","permalink":"/documentation/RockBox/Software/","tags":null,"title":"Software"},{"categories":null,"contents":"The releases are still in alpha state and are only fit for testing purposes.\nApache NuttX RTOS Apache NuttX RTOS\nArmbian STAR64 on armbian.com. Read the Armbian forum thread on forum.pine64.org.\nDietPi Star64 image on dietpi.com, with Linux 6.1 based on StarFive VisionFive 2 kernel sources, rebased on latest mainline kernel, with Star64 support from Fishwaldo’s kernel sources and own configuration. The kernel sources can be found on the DietPi Star64 repository on GitHub.com.\nDownload:\nDirect image download Fishwaldo images A Set of Images built with Yocto for commandline, weston and plasma, see the project on GitHub.com.\nNotes:\nWhere possible, GPU/VPU acceleration is enabled. NixOS NixOS, based on the the nixos-hardware configuration\n","permalink":"/documentation/STAR64/Software/","tags":null,"title":"Software"},{"categories":null,"contents":"The releases are still in alpha state and are only fit for development and testing purposes.\nNuttX NuttX, an Apache project, is a real-time operating system that prioritizes adherence to standards and maintains a compact size.\nRead StarPro64 EIC7700X RISC-V SBC: Maybe LLM on NPU on NuttX? by lupyuen.\nRockOS RockOS is a customized Debian distribution for the EIC770X by PLCT Lab.\nDownload: https://fast-mirror.isrc.ac.cn/rockos/images/generic/latest/\nMore information on this image SDK can be found at: https://github.com/rockos-riscv.\nALPHA-One This is the early test build that contains both 7b Deepseek and QWen2 LLM build, OS based on RockOS. The image for 32 GB eMMC modules and above. For larger than 32GB eMMC, please use gpart to extend the file partition.\nDownload:\nDirect download from PINE64 file server File information:\nMD5 (GZip file): 6669a436104e97e2ad90679e06f62d78 File Size: 18.21 GB User Password eswin eswin To explore LLM, use terminal program and execute below command lines:\nDeepSeek 7b LLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/deepseek_r1_distill_qwen_7b/config.json Qwen2 7bLLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/qwen2_7b/config.json Qwen2 0.5bLLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/qwen2_0_5b/config.json SDKs SDK document (some in Chinese): https://files.pine64.org/SDK/StarPro64/docs.7z (34 MB. MD5 checksum of the 7-Zip file is 8ee9b660c336d9979191d212e9826226)\nSTARPro64 Uboot and Linux Kernel Release:\n20250330: https://files.pine64.org/SDK/StarPro64/starpro64-sdk-20250330.7z (666 MB. MD5 checksum of the 7-Zip file is 12d44c21a990a64097611ba44eb3c56f) AI SDK Release 20250228: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250228.7z (1.932 GB. MD5 checksum of the 7-Zip file is f9171ec8b30e5d4d8eda1185f72af5e4) 20250330: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250330.7z (1.946 GB. MD5 checksum of the 7-Zip file is 8ddc861755ed26785e67674aad8db87c) 20250530: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250530.7z (1.897 GB. MD5 checksum of the 7-Zip file is 171a147448e42916dd06480f6b129c25) 20250630: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250630.7z (1.988 GB. MD5 checksum of the 7-Zip file is 00a91649522cebb94c29fea388c699e4) 20250730: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250730.7z (1.839 GB. MD5 checksum of the 7-Zip file is d0d839dde6b6f4ef8fa509e0fb4848d6) LLM and Neural Network tools release LLM 20250228: https://files.pine64.org/SDK/StarPro64/deepseek\u0026qwen-v0228.7z (722 MB. MD5 checksum of the 7-Zip file is b8ee72ee6a8912afefac3fa43a18be87) NN-Tools 20250228: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250228.7z (6.625 GB. MD5 checksum of the 7-Zip file is 868434b274412e173c3e264118dcb336) NN-Tools 20250330: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250330.7z (6.625 GB. MD5 checksum of the 7-Zip file is 39348ad2662cc72d12ef411cef2c756c) NN-Tools 20250530: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250530.7z (6.625 GB. MD5 checksum of the 7-Zip file is 5c1562cbaaa2772dbad9e0a9dd41c150) NN-Tools 20250630: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250630.7z (6.625 GB. MD5 checksum of the 7-Zip file is dbae3968126c23deed10d5e673aa10ad) NN-Tools 20250730: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250730.7z (6.643 GB. MD5 checksum of the 7-Zip file is e32b6e1ce699fc05105371a7714979a4) Ollama Pack Based on 20250730 Release install whisper and ollama deb package 20250730 path: /ai_release/EIC7x_AI_Release_20250730 whisper reference: ftp: /share/2025-10-09/whisper/WHISPER_README.md after install ollama deb package，refer to /home/eswin/OLLAMA_README.md for operation manual Ollma Pack 20251009: https://files.pine64.org/SDK/StarPro64/StarPro64%20Ollam%20Pack%202025-10-09.7z (1.826 GB. MD5 checksum of the 7-Zip file is ad0093f121963978af41550790643ab4)\n","permalink":"/documentation/StarPro64/Software/","tags":null,"title":"Software"},{"categories":null,"contents":"The factory PineVoice firmware is open-source and turns PineVoice into a voice assistant satellite. It provides Wi-Fi provisioning over Improv and voice assistant connectivity over the Wyoming protocol.\nFirmware is using Alibaba\u0026rsquo;s AliOS, specifically it\u0026rsquo;s \u0026ldquo;YoC/YoCop\u0026rdquo; variation.\nSupported features The current factory firmware supports:\nWi-Fi provisioning using the Improv protocol over Bluetooth Low Energy Wyoming satellite for compatible assistance applications Wyoming mDNS auto-discovery for compatible assistance applications Local wake word detection using MicroWakeWord Setup On first boot, PineVoice starts in Wi-Fi provisioning mode. In this mode, the ring LED blinks yellow. Use WiFi Setup to connect PineVoice to a Wi-Fi network and follow further instructions for connection with Assistance application which supports Wyoming protocol, such as Home Assistant.\nLED ring lightshows The center LED ring is used to show the current state of PineVoice. For most actions and states, light shows are used instead of voice feedback so PineVoice does not unexpectedly disturb the user, for example during the night. Active-state light shows, such as the dim cyan standby light, are intentionally kept dim so they remain visible without being distracting in a dark room.\nStartup and setup Light show Meaning Dim white fade-in/fade-out, once Boot-up lightshow. PineVoice has started. Yellow breath, loop PineVoice is in provisioning mode and is ready to connect to Wi-Fi through the Improv protocol. Green fade-in/fade-out, once Identification signal during provisioning, used to identify the paired PineVoice. Dim orange breath, loop PineVoice is trying to connect to Wi-Fi. Dim magenta breath, loop PineVoice is waiting for a Wyoming client to connect. Assistant states Light show Meaning Dim cyan, still PineVoice is active and in standby, waiting for the user to press the center button or say the wake word. Blue-cyan-blue breath, loop PineVoice is listening to the user\u0026rsquo;s voice input. Dim purple, still PineVoice is processing the user\u0026rsquo;s input. Slow green breath, loop PineVoice is answering. Action feedback Light show Meaning White fade-in, once Volume up. White fade-out, once Volume down. Red fade-out, once An error happened or the action failed. Button controls PineVoice buttons view\nPineVoice has five top buttons for voice control, volume, microphone mute, and provisioning.\nCenter LED ring button - starts a voice command session. + button - increases the volume. - button - decreases the volume. Microphone button - hardware microphone mute. The button shines red while microphone mute is active. Dot / user button - currently used to enter provisioning mode. Hold it for 15 seconds to reset Wi-Fi setup and return PineVoice to provisioning mode. Voice feedback As mentioned in LED ring lightshows, voice feedback is used rarely. PineVoice mostly uses light shows instead, and voice feedback is generally reserved for direct user interaction.\nAudio feedback is currently used in the following cases:\nWi-Fi provisioning started - played when Wi-Fi provisioning starts, including on first boot. Wi-Fi provisioning succeeded or failed - played when Wi-Fi provisioning finishes successfully or fails. Wyoming satellite is disconnected - played when Assist is attempted, but the Wyoming satellite/client is not connected. Wi-Fi is disconnected - played when Assist is attempted, but PineVoice is not connected to Wi-Fi. Wake word detection PineVoice uses MicroWakeWord for local wake word detection.\nFor now, PineVoice uses the \u0026ldquo;Hey Jarvis\u0026rdquo; model from the ESPHome MicroWakeWord models project. The wake word generally works well, but recognition may vary depending on the speaker\u0026rsquo;s voice, pronunciation, distance from the device, and background noise.\nNote Future firmware updates are expected to add support for using custom MicroWakeWord-compatible models. There are also plans to train a PineVoice-specific wake word model. If you are interested in helping with model training, contact us through the community channels. Source code You can find source code of this firmware (PineVoice SmartSpeaker SDK) on Codeberg and Github.\n","permalink":"/documentation/PineVoice/Software/","tags":null,"title":"Software overview"},{"categories":null,"contents":"These releases are still in beta state and are only fit for development purposes.\nOpenWrt Image Build OpenWrt Github Release Armbian Mainline Linux OS Image Build Source code available at https://github.com/pine64/build/releases, others are welcome to fork and enhance. Attach USB keyboard, then follow onboard small LCD screen message to complete first setup After the initial setup, please allow some time for the download of the HA (Home Assistant) image PineDio Zigbee dongle driver already included For the board with 2GB of memory, please only use OS build with Picoclaw version. The following are 2026.06.05 builds\nDirect Download Ubuntu 26.05 Noble with Home Assistance and Picoclaw build from pine64.org (987MB, MD5 777f08ad5d42f3e8c56aa242eff8f855) Direct Download Ubuntu 26.05 Noble with Home Assistance and openclaw build from pine64.org (988MB, MD5 e40065560256718af2590f85137a55cc) The following are 2026.05.21 builds\nDirect Download Ubuntu 26.05 Noble with Home Assistance and Picoclaw build from pine64.org (987MB, MD5 4f60fdd168817b70f5b782f412009210) Direct Download Ubuntu 26.05 Noble with Home Assistance and openclaw build from pine64.org (982MB, MD5 bd6f6edb2a5733d79b0ea4bf3d867403) Avaota OS Legacy Linux Image Build The following OS build is derived from the Allwinner BSP\nDirect Download Ubuntu 22.04.5 Jimmy CLI build from pine64.org (480MB, MD5 958dce883859ea7dae29ccd460a5996d) Direct Download Ubuntu 22.04.5 Jimmy Gnome build from pine64.org (1.09GB, MD5 916a974dbdbcdc21f13860e597a44df2) Direct Download Ubuntu 22.04.5 Jimmy XFCE build from pine64.org (1.26GB, MD5 7eac664789ad44b4db1241f6d7d15ffe) Direct Download Ubuntu 24.04 Noble CLI build from pine64.org (1.26GB, MD5 8976d153484c6dfb14434f26c1a15e14) Android 13 Image Build Note: \u0026ldquo;eng\u0026rdquo; build enable root and log for development or hacking purpose, \u0026ldquo;user\u0026rdquo; build disable root and log as release version\nDirect Download Eng build from pine64.org (1.25GB, MD5 6692b8cd14aeccfed4bbdc148f607135) Direct Download User build from pine64.org (1.22GB, MD5 cc0227464c7a451b582aba1f3b1944ae) Android 13 SDK Direct Download from pine64.org (62.28GB, MD5 f565ff9d0f712ca9c8131c69011379cf) Resources and Articles Yuzuki github for more information Yuzuki\u0026rsquo;s Avaota fun site dedicated to Avaota OS in Chinese ","permalink":"/documentation/Yuzuki_Avaota-A1/Software/Releases/","tags":null,"title":"Software releases"},{"categories":null,"contents":"This page contains a list of all available software releases and other resources for the PINE A64 and PINE A64+.\nNote The images for the PINE A64 and PINE A64+ are not compatible with the PINE A64-LTS due to LPDDR3 memory configuration. For PINE A64-LTS releases, please see the Software. Linux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. To learn more about AOSC, please visit the official AOSC website.\nDownload:\nhttps://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more) Default credentials aosc anthon Arch Linux ARM Arch Linux ARM is a distribution of Linux for ARM computers.\nInstallation:\nhttps://archlinuxarm.org/platforms/armv8/allwinner/pine64 Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://www.armbian.com/pine64/ Debian Debian is an operating system and a distribution of free software. See the forum thread here.\nDownload:\nDebian 11 Bullseye (recommended) Debian 12 Bookworm Daily netboot images Instructions:\nDownload: firmware.pine64_plus.img.gz Download: partition.img.gz Create the disk image: For Linux: zcat firmware.pine64_plus.img.gz partition.img.gz \u0026gt; complete_image.img For Mac: gzcat firmware.pine64_plus.img.gz partition.img.gz \u0026gt; complete_image.img Write the image to your boot device: For Linux: dd if=complete_image.img of=your_chosen_boot_device bs=4M For Mac: see Getting started Notes:\nAn Ethernet connection is required for the above installer DietPi DietPi is a lightweight yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the PINE A64 build on the PINE64 forum thread.\nDownload:\nDebian 11 Bullseye (supports the microSD card and eMMC, 4GB or more) Debian 12 Bookworm (supports the microSD card and eMMC, 4GB or more) Default credentials root dietpi FreedomBox FreedomBox is a private server for non-experts: it lets you install and configure server applications with only a few clicks. For more information about FreedomBox, please visit http://www.freedombox.org.\nDownload:\nRelease Signature Torrent Notes:\nThis is a headless build, not HDMI output. Please plug-in Ethernet cable first before initial power up. After power up for 10 minutes, using browser and type in https://fredombox.local to setup. Browser may warms for unsecure site and please proceed with exception. Freedom Manual: https://wiki.debian.org/FreedomBox/Manual LibreELEC LibreELEC is a \u0026ldquo;Just enough OS\u0026rdquo; Linux distribution combining the Kodi media center with an operating system.\nDownload:\n512MB PINE A64: direct download from Libreelec nightly build site (look for LibreELEC-A64.arm-\u0026hellip;-nightly-xxxxxxxx-xxxxxxx-pine64.img.gz) 1GB/2GB PINE A64+ Board: direct download from Libreelec nightly build site (look for LibreELEC-A64.arm-\u0026hellip;-nightly-xxxxxxxx-xxxxxxx-pine64-plus.img.gz) Notes:\nNightly build for microSD boot motionEyeOS motionEyeOS is a Linux distribution that turns a single-board computer into a video surveillance system. The OS is based on BuildRoot and uses motion as a backend and motionEye for the frontend. Visit the motionEyeOS GitHub and its GitHub Wiki for more information\nDownload:\n1GB/2GB PINE A64(+): Direct download from GitHub (look for motioneyeos-pine64-xxxxxxxx.img.xz) Notes:\nSuitable for 1GB/2GB PINE A64(+) variants There are 2 ways to interact with the OS: Scan for its IP with hostname MEYE-* and go to the admin web interface https://[IP] and after login, you should able to see the output of the CAMERA MODULE on the web interface Use the PINE64 USB SERIAL CONSOLE/PROGRAMMER and login Default credentials admin none NEMS Linux NEMS stands for Nagios Enterprise Monitoring Server and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their site.\nWarning Outdated release Download:\nDownload torrent seed from NEMS Linux (2.66GB, MD5 of the xz file is ac508549a829021491cfa23aeb18a063) Direct download from pine64.org (2.66GB, MD5 of the xz file is ac508549a829021491cfa23aeb18a063) Notes:\nSuitable for all 512MB/1GB/2GB PINE A64(+) variants Default credentials nemsadmin nemsadmin openSUSE openSUSE is a free and open source RPM-based Linux distribution developed by the openSUSE project. More details can be found under https://en.opensuse.org/HCL:Pine64.\nDownload:\nImages Headless build: Direct download OpenWRT The OpenWrt Project is a Linux operating system targeting embedded devices.\nDownload:\nDirect download (look for pine64_pine64-baseboard-ext4-sdcard.img.gz and pine64_pine64-baseboard-squashfs-sdcard.img.gz) Notes:\nOpenWRT community build for microSD boot. This is headless build, please use serial console to configure Default credentials Default user Use the command passwd BSD NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. To learn more about NetBSD please visit NetBSD main page.\nDownload:\nDirect download (345MB, select PINE A64 / PINE A64+) Notes:\nNetBSD community build for microSD boot Instructions concerning enabling SSH can be found here Default credentials root and SSH none Windows 10 IoT Download:\nWindows IoT direct download from pine64.org (957MB, MD5 of FFU file ACA617C0C9CEDA705DD510BF041E79B4) Notes:\nPINE64 Win10 IoT build already passed the Microsoft Azure certification For step by step installation process, please follow this github link For release note, please follow this github link For Microsoft Azure IoT SDKs, please follow this github link Changelog for Win10 IoT 10.0.15063.0_20170602:\nUpdate Notes since 10.0.15063.0_20170524: Fix the failure of default application installation caused by a app certification issue Fix that the default application cannot start automatically after installation Fix Ethernet initialization problem and now the Ethernet will start successfully every time Enable the usermode access for all unusable GPIO pins in Pi-2 bus( later provide a UWP sample to show how to control these pins ) Extra Notes: If you want to connect a USB peripheral for extension, please connect a USB hub to the lower USB interface as the medium Please refer to Part 2 of chapter 3: Debug with a virtual net over USB on how to use the upper USB interface Changelog for Win10 IoT 10.0.15063.0_20170524:\nSome Updates: Update the OS version to build v.10.0.15063.0 (Creators Update) New page style of Device Portal, visit https://deviceipaddr:8080 to check it Built-in Cortana assistant, need to be enabled in settings page in default app and Device Portal Support on-screen keyboard, need to be enabled in Device Portal Enable 100M Ethernet and fix some bugs Support built-in UART bus in A64 SoC(not built in the ffu, later provide driver binary and deployment helper) Support built-in IR module in A64 SoC(not built in the ffu, later provide source code and dev doc for developers in community) Known Issues: Kernel debug is enabled by default. This will slow the bring-up process. If a kernel debug is not necessary for you, visit Device Portal and navigate to Processes-\u0026gt;Run Command page, run this command to disable: Bcdedit /store C:\\EFIESP\\EFI\\Microsoft\\boot\\BCD /set {default} debug off An PnP bug in audio device may cause a blue screen when acting software shutdown Ethernet device may not start with problem code 12 at the first time to bring up Linux BSP SDK Linux BSP Kernel 4.9\nDirect Download from pine64.org (5.4GB, MD5 of the TAR-GZip file 7736e3c4d50c021144d125cc4ee047a4) Android SDK Android Oreo (v8.1)\nDirect Download from pine64.org (24.94GB, MD5 of the TAR-GZip file b0394af324c70ce28067e52cd7bc0c87) Other resources Allwinner PhoenixCard Bootable SD-Card Creator Allwinner DragonFace software that will let you edit and modify A64 Stock Android Build PhoenixCard image Below you will find useful links to various resources and forum threads:\nSunxi PINE64 Page Longsleep BSP Linux Builds Download Page Longsleep BSP Linux Kernel Thread on PINE64 Forum Longsleep BSP Xenial Thread on PINE64 Forum Longsleep BSP Arch Linux Thread on PINE64 Forum ","permalink":"/documentation/Pine_A64/Software/","tags":null,"title":"Software Releases"},{"categories":null,"contents":"The PineTab-V is an experimental device and lacks dedicated working software – it should therefore only be purchased by people interested in helping with the bring-up process of Linux and BSDs on the RISC-V architecture.\nThe second batch released in 2025 includes a Debian \u0026ldquo;Bookworm/Sid\u0026rdquo; operating system created by StarFive. This build includes a lot of old packages and has a snapshot date of 2022/12/25. It is recommended to be used for development purposes only.\nWarning Do not buy the device unless you intend to use it for operating system development purposes. ","permalink":"/documentation/PineTab-V/Software/Software_state/","tags":null,"title":"Software state"},{"categories":null,"contents":"Presently the PinePhone Pro Explorer Edition is aimed at Linux developers with an extensive knowledge of embedded systems and/or experience with mobile Linux. It will take time for all the PinePhone Pro’s functionality to reach software parity with the original PinePhone and for mobile operating systems, in more general, to reach a higher degree of maturity.\nBear in mind that the software for these smartphones is still in a very early stage, with most of the software being in alpha or beta state. That\u0026rsquo;s especially also the case for scalability of applications, their availability and practicability, any hardware function implementations and the firmware. The software is provided as is. There is no warranty for the software, not even for merchantability or fitness for a particular purpose.\nThe following table lists the feature functionality status of the unaltered pre-installed factory image of the current shipping batch and as comparison an up-to-date reference image (no responsibility is accepted for the accuracy of this information, the list is provided and updated by the community). If you have any questions regarding the current state of the software or of specific features working, please don\u0026rsquo;t hesitate to ask in the community chat before buying the device:\nDiscord: #pinephone under https://discord.gg/pine64 IRC: #pinephone on irc.pine64.org. Note: please consider Matrix, Discord or Telegram due to the volatile nature of IRC Matrix: https://app.element.io/#/room/#pinephone:matrix.org Telegram: https://t.me/pinephone Note The software is written by the community, any contributions towards the community projects are greatly appreciated! Please see \u0026ldquo;How to Contribute\u0026rdquo; to learn about how to contribute to the software projects and \u0026ldquo;Where to Report Bugs\u0026rdquo; to learn about where to report bugs. Bootloader:\nComponent Status Notes Bootloader Working SPI Working Boot GUI Working Devices bought after July 2022 come with Tow-Boot or rk2aw flashed to the SPI memory Operating System:\nComponent Status Notes Stability WIP Suspend Experimental Audio is often higher pitched after waking up from suspend due to a bug, make sure to update your systemReport; Report Updates WIP The pre-flashed and outdated operating system on the eMMC often gets corrupted after updatingExample; Pacman database lock preventing updatesSolution; Keyring bug (solution is to run \u0026ldquo;pinephonepro-post-install\u0026rdquo; script as root). Modem:\nComponent Status Notes General WIP Alternative firmware; Slow wakeupReport; Some carriers blocking specific TANs in their network; Note: Proprietary firmware Phone WIP The modem connection crashes frequently, which can lead to missed callsReport; Alternative firmware; Slow wakeupReport; bad call audio qualityReport; Audio is often higher pitched after waking up from suspend due to a bugReport; Report SMS Working SMS functionality is expected to work. In certain cases the functionality might be blocked by a clogged modemReport; Some bugs MMS WIP MMS functionality is integrated into the application \u0026ldquo;Spacebar\u0026rdquo;, some bugs remaining and expected Push notifications Not implemented Receiving push notifications while the phone is suspended is not implemented Components:\nComponent Status Notes LCD WIP Hardware issueDetails Touch Working Rear camera WIP Camera work-in-progress with DTS fix[Citation]; userspace still needs to do some catching up; Green image tint[Citation] Front camera WIP Camera work-in-progress with DTS fix[Citation]; userspace still needs to do some catching up; Green image tint[Citation] Camera flash Critical issues Hardware issueDetails; Note: /sys/class/leds/white:flash WiFi Working WiFi is expected to work. The firmware does not support monitor mode and package injection. Note: Proprietary firmware Bluetooth WIP Bluetooth not necessarily working for calls yet due to missing audio routing[Citation]; Bluetooth in general dodgy under Pulseaudio.Info Note: Proprietary firmware GNSS/GPS WIP aGPS to be implemented; long loading times to get a GPS fix[Citation]; No preinstalled application[Citation] Sensors WIP \u0026ldquo;Geo Magnetic Sensor\u0026rdquo; (af8133j): Status unknown (at /sys/bus/i2c/devices/4-001c/iio:device1) \u0026ldquo;Accelerometer / Gyroscope\u0026rdquo; (mpu6500): Working (at /sys/bus/i2c/devices/4-0068/iio:device2) \u0026ldquo;Ambient light / Proximity\u0026rdquo; (stk3311): Working after updating Vibration motor Working Notification LED Working Buttons Working Power buttons and volume buttons are working. Accessory compatibility, spare parts:\nComponent Status Notes Keyboard Add-on WIP The keyboard add-on compatibility is work-in-progress. LoRa Add-on Not implemented No software support implemented Qi Wireless Charging Add-on WIP Wireless charging with the add-on case is expected to work to some degree. Certain software functionality and a driver is currently missing[Citation] Fingerprint Reader Add-on Not implemented No software support implemented Spare parts Partial Some spare parts now available in the store.Store Software notes:\nComponent Status Notes Waydroid Working Waydroid is an Android container used to run Android applications. ¹ Status of the features at the time of the last factory installation without updates\n² Status of the features with an up-to-date reference image\n","permalink":"/documentation/PinePhone_Pro/Software/Software_state/","tags":null,"title":"Software State"},{"categories":null,"contents":" Fixing Bluetooth Some users have noticed instability with their wireless driver. Upgrading the driver to the version provided by LibreELEC may help! To do this, download the BCM4345C0.hcd, brcmfmac43455-sdio.bin, and brcmfmac43455-sdio.txt from the libreELEC repositories and place them in the same location as your previous firmware (/lib/firmware/brmc/). Then rename brcmfmac43455-sdio.{txt,bin} as brcmfmac43455-sdio.pine64,pinenote-v1.2.{txt,bin}. If this doesn’t help, ask about it in the matrix chat!\nPreliminary fix for stuttering bluetooth audio Following a fix used for the Quartz Model A (which uses the same SoC as the Pinenote), we can modify the device tree prior to building the kernel to try to mitigate poor Bluetooth audio streaming. (reference: see https://lore.kernel.org/linux-arm-kernel/20220926055435.31284-1-leo@nabam.net/T/)\nSteps:\nOpen arch/arm64/boot/dts/rockchip/rk3566-pinenote.dtsi Go to line 939, \u0026ldquo;bluetooth\u0026rdquo;, under the \u0026ldquo;uart1\u0026rdquo; section Edit the two lines that read \u0026ldquo;device-wake-gpios\u0026rdquo; and \u0026ldquo;host-wake-gpios\u0026rdquo;; you want them to read \u0026ldquo;device-wakeup-gpios\u0026rdquo; and \u0026ldquo;host-wakeup-gpios\u0026rdquo; respectively Add the following line to the end of the bluetooth section (under the vddio-supply line in my .dtsi): \u0026ldquo;max-speed = \u0026lt;3000000\u0026gt;;\u0026rdquo; Count your zeros, don’t forget your punctuation.. Caveats:\nThis will improve BT audio quality at least when using the AAC codec. In my experience, the quality is more than acceptable, but there are still issues apparent: occasional isolated stutters even on AAC; prohibitively frequent stutters on SBC-XQ remain. Fully resolving BT audio issues might require further changes similar to the one described above, or may alternatively be a matter of audio software settings (e. g., process priority, audio server buffer settings). Investigation ongoing.\nlibinput Palm Detection See https://gitlab.com/hrdl/pinenote-shared/-/blob/main/etc/libinput/local-overrides.quirks.\nlibinput Touch Arbitration Prerequisites: libinput\u0026gt;1.22.1 and setup touch arbitration via udev: https://gitlab.com/hrdl/pinenote-shared/-/blob/main/etc/udev/rules.d/81-libinput-pinenote.rules\nIssues and workarounds No resolution reported by touchscreen driver. Workaround: patch cyttsp5.c and device tree: https://gitlab.com/hrdl/linux/-/commit/f1f9eb197d3bd88c9189ab9d8fba2d03d2e13960 or set device quirk AttrSizeHint=210x157. Touch screen arbitration is independent of the screen’s rotation. Workaround: use AttrEventCode=-ABS_TILT_X (on older version: AttrEventCodeDisable=ABS_TILT_X) in a libinput quirk matching w9013 2D1F:0095 Stylus. This makes touch arbitration independent of the pen’s location. ","permalink":"/documentation/PineNote/Development/Software_tweaks/","tags":null,"title":"Software tweaks"},{"categories":["Computer modules"],"contents":" Like the PINEA64-LTS, just much smaller The SOPINE is a compute module powered by the same Quad-Core ARM Cortex A53 64-Bit Processor used in the PINE A64 with 2G LPDDR3 RAM memory, Power Management Unit, SPI Flash and integrated MicroSD Slot (for bootable OS images microSD card). The SOPINE module has a 5 years LTS (Long Term Supply) status, which means that it will be supplied to 2022 at the very least. There is a one year warranty period for the SOPINE module.\nThis tiny compute module uses SODIMM-DDR3 form-factor and can be paired with either the Clusterboard, the Baseboard or a custom host PCB for industrial or other embedded applications. It is fully compatible with the PINE A64-LTS in terms of software support\nFeatures and Specifications SoC 4 x ARM Cortex A53 cores @ 1.152 GHz GPU ARM Mali 400 MP2 GPU Memory LPDDR3 RAM (2GB) SPI SPI Flash 128Mbit Connections CMOS sensor interface port Form factor SODIMM form-factor Versatile A64 SoC The A64 SoC is a versatile SoC perfect for compute functionality\n2GB Of LPDDR3 RAM Each module comes with 2GB of built-in LPDDR3 RAM\nBuilt-In SPI Flash Each module comes with 128Mbit of SPI Flash memory\nSODIMM Form-Factor With the small SODIMM form-factor the SOPINE is perfect for use as a compute module or in a embedded project\nStores Global Global: Accessories Affiliates Documentation SOPINE Schematics and certifications ","permalink":"/devices/sopine/","tags":null,"title":"SOPINE"},{"categories":null,"contents":" The SOPINE is a compute module powered by the same quad-core ARM Cortex A53 64-bit processor used in the PINE A64 with 2 GB of LPDDR3 RAM memory, power management unit, SPI flash and integrated bootable microSD slot. The module features a SODIMM-DDR3 form-factor and can be paired with either the SOPINE Baseboard, the Clusterboard or a custom host PCB for industrial or other embedded applications.\nThe SOPINE module has a five-year LTS (long-term supply) status, which means that it will be supplied to 2022 at the very least. There is a one-year warranty period for the SOPINE module. It is fully compatible with the PINE A64-LTS in terms of software support\nSoftware Releases\nArmbian LCD and Camera\nReleases Note that SOPINE images are also compatible with the PINE A64-LTS.\nLinux AOSC AOSC OS is a general purpose Linux distribution that strives to simplify user experience and improve free and open source software for day-to-day productivity. To learn more about AOSC, please visit the official AOSC website.\nDownload:\nhttps://aosc.io/downloads/ (supports the microSD card and eMMC, 8GB or more) Default credentials aosc anthon Armbian Armbian is a Linux distribution designed for ARM boards. They are usually Debian or Ubuntu flavored.\nDownload:\nhttps://armbian.hosthatch.com/archive/pine64so/archive/ FreedomBox FreedomBox is a private server for non-experts: it lets you install and configure server applications with only a few clicks. For more information about FreedomBox, please visit https://www.freedombox.org.\nWarning Outdated release Download:\nDirect download from FreedomBox site (418MB) Notes:\nThis is a headless build, not HDMI output. Please plug-in Ethernet cable first before initial power up. After power up for 10 minutes, using browser and type in https://fredombox.local to setup. Browser may warms for unsecure site and please proceed with exception. Freedom Manual: https://wiki.debian.org/FreedomBox/Manual LibreELEC LibreELEC is a \u0026ldquo;Just enough OS\u0026rdquo; Linux distribution combining the Kodi media center with an operating system.\nDownload:\nPine A64+ build direct download from Libreelec nightly (look for LibreELEC-A64.arm-\u0026hellip;-nightly-xxxxxxxx-xxxxxxx-pine64-lts.img.gz) Notes:\nNightly build for microSD and eMMC boot. NEMS Linux NEMS stands for \u0026ldquo;Nagios Enterprise Monitoring Server\u0026rdquo; and it is a modern pre-configured, customized and ready-to-deploy Nagios Core image designed to run on low-cost micro computers. To find out more on NEMS Linux, please visit their site.\nWarning Outdated release Download:\nDirect download from pine64.org (supports the microSD card, 16GB or more, MD5 of the xz file is 5ad0d684296d50b4c1fcbac6db205ae0) Download torrent seed from NEMS Linux (supports the microSD card, 16GB or more, MD5 of the xz file is 6e2088922c5d197db8b8ba3057120389) Info The installation guide can be found here. Default credentials nemsadmin nemsadmin OpenEmbedded OpenEmbedded is the build framework for embedded Linux. OpenEmbedded offers a best-in-class cross-compile environment. It allows developers to create a complete Linux Distribution for embedded systems. See https://www.openembedded.org/wiki/Main_Page for more information on OpenEmbedded.\nDownload:\nhttps://github.com/alistair23/meta-pine64/ Notes:\nOpenEmbedded/Yocto layer for the Pine64 boards This layer aims to support as many features as possible on Pine64 devices. Where possible the layer aims to use opensource and upstream projects avoiding custom forks and binary solutions. More information and instructions can be found in the repo readme: https://github.com/alistair23/meta-pine64/#building OpenWRT OpenWRT community build for microSD boot. The OpenWrt Project is a Linux operating system targeting embedded devices.\nDownload:\nDirect download (look for pine64_sopine-baseboard-ext4-sdcard.img.gz and pine64_sopine-baseboard-squashfs-sdcard.img.gz) Notes:\nThis is headless build, please use serial console to configure Default credentials Default user -/passwd BSD NetBSD NetBSD is a free, fast, secure, and highly portable Unix-like Open Source operating system. To learn more about NetBSD please visit NetBSD main page.\nDownload:\nDirect download (select PINE A64-LTS / SoPine with baseboard) Default credentials root (root user and SSH) [none] Notes:\nNetBSD community build for microSD boot Instructions concerning enabling SSH can be found here Linux BSP SDK Linux BSP Kernel 4.9\nDownload:\nDirect Download from pine64.org (5.40GB, MD5 of the TAR-GZip 7736e3c4d50c021144d125cc4ee047a4) Android SDK Android Oreo (v8.1)\nDownload:\nDirect Download from pine64.org (24.94GB, MD5 of the TAR-Gzip b0394af324c70ce28067e52cd7bc0c87) Armbian LCD and Camera Guide on how to get the camera and the LCD working on the SOPINE on Armbian.\nLCD DD the Armbian SOPINE image to the microSD Card and run on the board Login through the terminal vi /boot/armbianEnv.txt (Change off to on): pine64_lcd=on vi /etc/modules (Add following line): gt9xxf_ts reboot Then the display will be on LCD and not HDMI\nCamera DD the Armbian SOPINE image to the microSD Card and run on the board\nLogin through the terminal\nInstall Ubuntu Xenial Mate with ayufan’s script\ncd ~ wget https://github.com/longsleep/build-pine64-image/raw/master/simpleimage/platform-scripts/install_desktop.sh chmod +x install_desktop.sh ./install_desktop.sh mate vi /boot/armbianEnv.txt (Set to \u0026ldquo;s5k4ec\u0026rdquo; or \u0026ldquo;ov5640\u0026rdquo; depending on your camera module)\ncamera_type=s5k4ec vi /etc/modules (Add the following depending on your camera_type \u0026ldquo;s5k4ec\u0026rdquo; or \u0026ldquo;ov5640\u0026rdquo; above. Note that \u0026ldquo;vfe_v4l2\u0026rdquo; has a small letter \u0026lsquo;L'2 not 12)\ns5k4ec vfe_v4l2 reboot\nFollowing https://github.com/avafinger/pine64_camera (Change \u0026ldquo;s5k4ec\u0026rdquo; to \u0026ldquo;ov5640\u0026rdquo; depending on your camera module)\napt-get update apt-get upgrade apt-get remove --purge guvcview apt-get remove --purge libguvcview-1.1-1 modprobe -r -f vfe_v4l2 modprobe -r -f s5k4ec modprobe s5k4ec modprobe vfe_v4l2 ls /dev/video0 dmesg | grep OK sudo apt-get install libmp3lame-dev libx264-dev libpulse-dev libv4l-dev libsdl1.2-dev libgtk-3-dev portaudio19-dev libpng12-dev libavcodec-dev libavutil-dev libudev-dev libusb-1.0-0-dev libpulse-dev libgsl0-dev libv4l-dev cd ~ wget https://raw.githubusercontent.com/avafinger/pine64_camera/master/libguvcview-1.2-1_2.0.3%2Bdebian-1_arm64.deb wget https://raw.githubusercontent.com/avafinger/pine64_camera/master/guvcview_2.0.3%2Bdebian-1_arm64.deb dpkg -i libguvcview-1.2-1_2.0.3+debian-1_arm64.deb dpkg -i guvcview_2.0.3+debian-1_arm64.deb For testing, use Xenial Mate -\u0026gt; Applications -\u0026gt; Sound \u0026amp; Video -\u0026gt; guvcview OR command line\nguvcview -d /dev/video0 -x 640x480 -r sdl -f yu12 guvcview -d /dev/video0 -x 640x480 -r sdl -f nv12 Pins and GPIOs GPIO Alternate Functions Table This is table of all available GPIOs on SOPine with their alternate functions.\nFor more information about GPIOs, check the Allwinner A64 Datasheet section 4.2 GPIO Multiplexing Functions and section 4.3 Detailed Pin/Signal Description\nPin name Linux SOPine Pin Direction Default Function Default Pull Function 2 Function 3 Function 4 Function 5 Function 6 SOPine Name PB0 GPIO32 35 I/O DIS Z UART2_TX JTAG_MS0 PB_EINT0 PB0-UART2_TX PB1 GPIO33 75 I/O DIS Z UART2_RX JTAG_CK0 SIM_PWREN PB_EINT1 PB1-UART2_RX PB2 GPIO34 36 I/O DIS Z UART2_RTS JTAG_DO0 SIM_VPPEN PB_EINT2 PB2 PB3 GPIO35 30 I/O DIS Z UART2_CTS I2S0_MCLK JTAG_DI0 SIM_VPPPP PB_EINT3 PB3-I3S_MCLK PB4 GPIO36 28 I/O DIS Z AIF2_SYNC PCM0_SYNC SIM_CLK PB_EINT4 PB4-I2S_SYNC PB5 GPIO37 27 I/O DIS Z AIF2_BCLK PCM0_BCLK SIM_DATA PB_EINT5 PB5-I2S_BCLK PB6 GPIO38 39 I/O DIS Z AIF2_DOUT PCM0_DOUT SIM_RST PB_EINT6 PB6-I2S_DOUT PB7 GPIO39 29 I/O DIS Z AIF2_DIN PCM0_DIN SIM_DET PB_EINT7 PB7-I2S_DIN PB8 GPIO40 34 I/O DIS Z UART0_TX PB_EINT8 PB8 PB9 GPIO41 33 I/O DIS Z UART0_RX PB_EINT9 PB9 PC0 GPIO64 134 I/O DIS Z NAND_WE SPI0_MOSI PC0-SPIO_MOSI PC1 GPIO65 150 I/O DIS Z NAND_ALE SDC2_DS SPI0_MISO PC1-SPIO_MISO PC2 GPIO66 142 I/O DIS Z NAND_CLE SPI0_CLK PC2-SPIO_CLK PC3 GPIO67 148 I/O DIS Pull-Up NAND_CE1 SPI0_CS PC3-SPIO_CS PC4 GPIO68 135 I/O DIS Pull-Up NAND_CE0 PC4 PC5 GPIO69 25 I/O DIS Z NAND_RE SDC2_CLK PC5 PC6 GPIO70 154 I/O DIS Pull-Up NAND_RB0 SDC2_CMD PC6 PC7 GPIO71 132 I/O DIS Pull-Up NAND_RB1 PC7 PC8 GPIO72 130 I/O DIS Z NAND_DQ0 SDC2_D0 PC8 PC9 GPIO73 153 I/O DIS Z NAND_DQ1 SDC2_D1 PC9 PC10 GPIO74 156 I/O DIS Z NAND_DQ2 SDC2_D2 PC10 PC11 GPIO75 165 I/O DIS Z NAND_DQ3 SDC2_D3 PC11 PC12 GPIO76 146 I/O DIS Z NAND_DQ4 SDC2_D4 PC12 PC13 GPIO77 157 I/O DIS Z NAND_DQ5 SDC2_D5 PC13 PC14 GPIO78 155 I/O DIS Z NAND_DQ6 SDC2_D6 PC14 PC15 GPIO79 133 I/O DIS Z NAND_DQ7 SDC2_D7 PC15 PC16 GPIO80 144 I/O DIS Z NAND_DQS SDC2_RST PC16 PD0 GPIO96 60 I/O DIS Z LCD_D2 UART3_TX SPI1_CS CCIR_CLK PD0-SPI1_CS PD1 GPIO97 49 I/O DIS Z LCD_D3 UART3_RX SPI1_CLK CCIR_DE PD1-SPI1_CLK PD2 GPIO98 57 I/O DIS Z LCD_D4 UART4_TX SPI1_MOSI CCIR_HSYNC PD2-SPI1_MOSI PD3 GPIO99 61 I/O DIS Z LCD_D5 UART4_RX SPI1_MISO CCIR_VSYNC PD3-SPI1_MISO PD4 GPIO100 52 I/O DIS Z LCD_D6 UART4_RTS CCIR_D0 PD4-UART4_RTS PD5 GPIO101 44 I/O DIS Z LCD_D7 UART4_CTS CCIR_D1 PD5-UART4_CTS PD6 GPIO102 45 I/O DIS Z LCD_D10 CCIR_D2 PD6 PD7 GPIO103 40 I/O DIS Z LCD_D11 CCIR_D3 PD7 PD8 GPIO104 73 I/O DIS Z LCD_D12 RGMII_RXD3/RMII_NULL CCIR_D4 GRXD3 PD9 GPIO105 83 I/O DIS Z LCD_D13 RGMII_RXD2/RMII_NULL CCIR_D5 GRXD2 PD10 GPIO106 51 I/O DIS Z LCD_D14 RGMII_RXD1/RMII_RXD1 RMII-RXD1 PD11 GPIO107 48 I/O DIS Z LCD_D15 RGMII_RXD0/RMII_RXD0 RMII-RXD0 PD12 GPIO108 91 I/O DIS Z LCD_D18 LVDS_VP0 RGMII_RXCK/RMII_NULL GRXCK PD13 GPIO109 89 I/O DIS Z LCD_D19 LVDS_VN0 RGMII_RXCT/RMII_CRS_DV RMII-CRS-DV PD14 GPIO110 87 I/O DIS Z LCD_D20 LVDS_VP1 RGMII_NULL/RMII_RXER RMII-RXER PD15 GPIO111 80 I/O DIS Z LCD_D21 LVDS_VN1 RGMII_TXD3/RMII_NULL CCIR_D6 GTXD3 PD16 GPIO112 82 I/O DIS Z LCD_D22 LVDS_VP2 RGMII_TXD2/RMII_NULL CCIR_D7 GTXD2 PD17 GPIO113 78 I/O DIS Z LCD_D23 LVDS_VN2 RGMII_TXD1/RMII_TXD1 RMII-TXD1 PD18 GPIO114 85 I/O DIS Z LCD_CLK LVDS_VPC RGMII_TXD0/RMII_TXD0 RMII-TXD0 PD19 GPIO115 79 I/O DIS Z LCD_DE LVDS_VNC RGMII_TXCK/RMII_TXCK RMII-TXCK PD20 GPIO116 47 I/O DIS Z LCD_HSYNC LVDS_VP3 RGMII_TXCTL/RMII_TXEN RMII-TXEN PD21 GPIO117 74 I/O DIS Z LCD_VSYNC LVDS_VN3 RGMII_CLKINRMII_NULL GCLKIN PD22 GPIO118 53 I/O DIS Z PWM0 MDC RMII-MDC PD23 GPIO119 76 I/O DIS Z MDIO RMII-MDIO PD24 GPIO120 50 I/O DIS Z LCD-RST PE0 GPIO128 58 I/O DIS Z CSI_PCLK TS_CLK CSI-PCLK PE1 GPIO129 102 I/O DIS Z CSI_MCLK TS_ERR CSI-MCLK PE2 GPIO130 100 I/O DIS Z CSI_HSYNC TS_SYNC CSI-HSYNC PE3 GPIO131 101 I/O DIS Z CSI_VSYNC TS_DVLD CSI-VSYNC PE4 GPIO132 95 I/O DIS Z CSI_D0 TS_D0 CSI-D0 PE5 GPIO133 54 I/O DIS Z CSI_D1 TS_D1 CSI-D1 PE6 GPIO134 96 I/O DIS Z CSI_D2 TS_D2 CSI-D2 PE7 GPIO135 65 I/O DIS Z CSI_D3 TS_D3 CSI-D3 PE8 GPIO136 105 I/O DIS Z CSI_D4 TS_D4 CSI-D4 PE9 GPIO137 59 I/O DIS Z CSI_D5 TS_D5 CSI-D5 PE10 GPIO138 107 I/O DIS Z CSI_D6 TS_D6 CSI-D6 PE11 GPIO139 111 I/O DIS Z CSI_D7 TS_D7 CSI-D7 PE12 GPIO140 98 I/O DIS Z CSI_SCK CSI-SCK PE13 GPIO141 113 I/O DIS Z CSI_SDA CSI-SDA PE16 GPIO144 92 I/O DIS Z CSI-RST-F PE17 GPIO145 109 I/O DIS Z CSI-STBY-F PG0 GPIO192 72 I/O DIS Z SDC1_CLK PG_EINT0 WL-SDIO-CLK PG1 GPIO193 108 I/O DIS Z SDC1_CMD PG_EINT1 WL-SDIO-CMD PG2 GPIO194 63 I/O DIS Z SDC1_D0 PG_EINT2 WL-SDIO-D0 PG3 GPIO195 110 I/O DIS Z SDC1_D1 PG_EINT3 WL-SDIO-D1 PG4 GPIO196 106 I/O DIS Z SDC1_D2 PG_EINT4 WL-SDIO-D2 PG5 GPIO197 112 I/O DIS Z SDC1_D3 PG_EINT5 WL-SDIO-D3 PG6 GPIO198 90 I/O DIS Z UART1_TX PG_EINT6 BT-UART-RX PG7 GPIO199 119 I/O DIS Z UART1_RX PG_EINT7 BT-UART-TX PG8 GPIO200 88 I/O DIS Z UART1_RTS PG_EINT8 BT-UART-CTS PG9 GPIO201 117 I/O DIS Z UART1_CTS PG_EINT9 BT-UART-RTS PG10 GPIO202 99 I/O DIS Z AIF3_SYNC PCM1_SYNC PG_EINT10 BT-PCM-SYNC PG11 GPIO203 86 I/O DIS Z AIF3_BCLK PCM1_BCLK PG_EINT11 BT-PCM-CLK PG12 GPIO204 120 I/O DIS Z AIF3_DOUT PCM1_DOUT PG_EINT12 BT-PCM-DIN PG13 GPIO205 97 I/O DIS Z AIF3_DIN PCM1_DIN PG_EINT13 BT-PCM-DOUT PH0 GPIO224 43 I/O DIS Z I2C0_SCL PH_EINT0 TP-SCK PH1 GPIO225 46 I/O DIS Z I2C0_SDA PH_EINT1 TP-SDA PH2 GPIO226 62 I/O DIS Z I2C1_SCL PH_EINT2 PH2-TW1_SCK PH3 GPIO227 37 I/O DIS Z I2C1_SDA PH_EINT3 PH3-TW1_SDA PH4 GPIO228 64 I/O DIS Z UART3_TX PH_EINT4 TP-INT PH5 GPIO229 68 I/O DIS Z UART3_RX PH_EINT5 PH5 PH6 GPIO230 66 I/O DIS Z UART3_RTS PH_EINT6 PH6 PH7 GPIO231 71 I/O DIS Z UART3_CTS PH_EINT7 PH7 PH8 GPIO232 38 I/O DIS Z OWA_OUT PH_EINT8 PH8-OWA_OUT PH9 GPIO233 77 I/O DIS Z PH_EINT9 PH9 PH10 GPIO234 26 I/O DIS Z MIC_CLK PH_EINT10 LCD-BL-EN PH11 GPIO235 67 I/O DIS Z MIC_DATA PH_EINT11 CTP-RST PL2 GPIO354 21 I/O DIS Z S_UART_TX S_PL_EINT2 WL-REG-ON PL3 GPIO355 23 I/O DIS Z S_UART_RX S_PL_EINT3 WL-WAKE-AP PL4 GPIO356 14 I/O DIS Z S_JTAG_MS S_PL_EINT4 BT-RST-N PL5 GPIO357 18 I/O DIS Z S_JTAG_CK S_PL_EINT5 BT-WAKE-AP PL6 GPIO358 16 I/O DIS Z S_JTAG_DO S_PL_EINT6 AP-WAKE-BT PL7 GPIO359 24 I/O DIS Z S_JTAG_DI S_PL_EINT7 PL7 PL8 GPIO360 15 I/O DIS Z S_I2C_CLK S_PL_EINT8 PL8-S_TWI_SCK PL9 GPIO361 17 I/O DIS Z S_I2C_SDA S_PL_EINT9 PL9-S_TWI_SDA PL10 GPIO362 166 I/O DIS Z S_PWM S_PL_EINT10 PL10-S_PWM PL11 GPIO363 13 I/O DIS Z S_CIR_RX S_PL_EINT11 PL11-IR_RX Pin Assignment Table This table contains Pin Assignment of SOPine Edge Finger. For more information about peripherals, GPIOs, powering see:\nAllwinner A64 Datasheet section 4.2 GPIO Multiplexing Functions and section 4.3 Detailed Pin/Signal Description Power Management Unit Datasheet For Edge Finger view, see:\nEdge Finger Pin Assignment Table forum.pine64.org: a PDF mapping the pins from the A64 chip itself, to the gold-fingers on the SO-DIMM edge, to the multiple connectors on the baseboard and on the clusterboard, attached to this forum post. SOPine Pin SOPine Name Allwinner name Allwinner category Ball Type Description 1 HBIAS HBIAS AUDIO_CODEC D13 AO Master Analog Headphone Bias Voltage Output 2 EAROUT_P EAROUTP AUDIO_CODEC B13 AO Earpiece Amplifier Positive Differential Output 3 HPOUTL HPOUTL AUDIO_CODEC C13 AO Headphone Output Left Channel 4 EAROUT_N EAROUTN AUDIO_CODEC A13 AO Earpiece Amplifier Negative Differential Output 5 HPOUTR HPOUTR AUDIO_CODEC C12 AO Headphone Output Right Channel 6 HS-MIC MIC-DET AUDIO_CODEC B10 AI Headphone MIC Detect 7 GND GND POWER ? G 8 GND GND POWER ? G 9 MIC2N MICIN2N AUDIO_CODEC A17 AI Microphone Negative Input 2 10 HPOUTFB HP-FB AUDIO_CODEC C10 AI Headphone Common Reference Feedback Input 11 MIC2P MICIN2P AUDIO_CODEC B17 AI Microphone Positive Input 2 12 KEYADC KEYADC ADC A16 AI ADC input for key 13 GPIO363 PL11 GPIO PL11 GPIO General Purpose Input Output #363 14 GPIO356 PL4 GPIO PL4 GPIO General Purpose Input Output #356 15 GPIO360 PL8 GPIO PL8 GPIO General Purpose Input Output #360 16 GPIO358 PL6 GPIO PL6 GPIO General Purpose Input Output #358 17 GPIO361 PL9 GPIO PL9 GPIO General Purpose Input Output #361 18 GPIO357 PL5 GPIO PL5 GPIO General Purpose Input Output #357 19 GND GND POWER ? G 20 GND GND POWER ? G 21 GPIO354 PL2 GPIO PL2 GPIO General Purpose Input Output #354 22 HP-DET HP-DET AUDIO_CODEC D11 AI Headphone Detect 23 GPIO355 PL3 GPIO PL3 GPIO General Purpose Input Output #355 24 GPIO359 PL7 GPIO PL7 GPIO General Purpose Input Output #359 25 GPIO69 PC5 GPIO PC5 GPIO General Purpose Input Output #69 26 GPIO234 PH10 GPIO PH10 GPIO General Purpose Input Output #234 27 GPIO37 PB5 GPIO PB5 GPIO General Purpose Input Output #37 28 GPIO36 PB4 GPIO PB4 GPIO General Purpose Input Output #36 29 GPIO39 PB7 GPIO PB7 GPIO General Purpose Input Output #39 30 GPIO35 PB3 GPIO PB3 GPIO General Purpose Input Output #35 31 GND GND POWER ? G 32 GND GND POWER ? G 33 GPIO41 PB9 GPIO PB9 GPIO General Purpose Input Output #41 34 GPIO40 PB8 GPIO PB8 GPIO General Purpose Input Output #40 35 GPIO32 PB0 GPIO PB0 GPIO General Purpose Input Output #32 36 GPIO34 PB2 GPIO PB2 GPIO General Purpose Input Output #34 37 GPIO227 PH3 GPIO PH3 GPIO General Purpose Input Output #227 38 GPIO232 PH8 GPIO PH8 GPIO General Purpose Input Output #232 39 GPIO38 PB6 GPIO PB6 GPIO General Purpose Input Output #38 40 GPIO103 PD7 GPIO PD7 GPIO General Purpose Input Output #103 41 GND GND POWER ? G 42 GND GND POWER ? G 43 GPIO224 PH0 GPIO PH0 GPIO General Purpose Input Output #224 44 GPIO101 PD5 GPIO PD5 GPIO General Purpose Input Output #101 45 GPIO102 PD6 GPIO PD6 GPIO General Purpose Input Output #102 46 GPIO225 PH1 GPIO PH1 GPIO General Purpose Input Output #225 47 GPIO116 PD20 GPIO PD20 GPIO General Purpose Input Output #116 48 GPIO107 PD11 GPIO PD11 GPIO General Purpose Input Output #107 49 GPIO97 PD1 GPIO PD1 GPIO General Purpose Input Output #97 50 GPIO120 PD24 GPIO PD24 GPIO General Purpose Input Output #120 51 GPIO106 PD10 GPIO PD10 GPIO General Purpose Input Output #106 52 GPIO100 PD4 GPIO PD4 GPIO General Purpose Input Output #100 53 GPIO118 PD22 GPIO PD22 GPIO General Purpose Input Output #118 54 GPIO133 PE5 GPIO PE5 GPIO General Purpose Input Output #133 55 GND GND POWER ? G 56 GND GND POWER ? G 57 GPIO98 PD2 GPIO PD2 GPIO General Purpose Input Output #98 58 GPIO128 PE0 GPIO PE0 GPIO General Purpose Input Output #128 59 GPIO137 PE9 GPIO PE9 GPIO General Purpose Input Output #137 60 GPIO96 PD0 GPIO PD0 GPIO General Purpose Input Output #96 61 GPIO99 PD3 GPIO PD3 GPIO General Purpose Input Output #99 62 GPIO226 PH2 GPIO PH2 GPIO General Purpose Input Output #226 63 GPIO194 PG2 GPIO PG2 GPIO General Purpose Input Output #194 64 GPIO228 PH4 GPIO PH4 GPIO General Purpose Input Output #228 65 GPIO135 PE7 GPIO PE7 GPIO General Purpose Input Output #135 66 GPIO230 PH6 GPIO PH6 GPIO General Purpose Input Output #230 67 GPIO235 PH11 GPIO PH11 GPIO General Purpose Input Output #235 68 GPIO229 PH5 GPIO PH5 GPIO General Purpose Input Output #229 69 GND GND POWER ? G 70 GND GND POWER ? G 71 GPIO231 PH7 GPIO PH7 GPIO General Purpose Input Output #231 72 GPIO192 PG0 GPIO PG0 GPIO General Purpose Input Output #192 73 GPIO104 PD8 GPIO PD8 GPIO General Purpose Input Output #104 74 GPIO117 PD21 GPIO PD21 GPIO General Purpose Input Output #117 75 GPIO33 PB1 GPIO PB1 GPIO General Purpose Input Output #33 76 GPIO119 PD23 GPIO PD23 GPIO General Purpose Input Output #119 77 GPIO233 PH9 GPIO PH9 GPIO General Purpose Input Output #233 78 GPIO113 PD17 GPIO PD17 GPIO General Purpose Input Output #113 79 GPIO115 PD19 GPIO PD19 GPIO General Purpose Input Output #115 80 GPIO111 PD15 GPIO PD15 GPIO General Purpose Input Output #111 81 GND GND POWER ? G 82 GPIO112 PD16 GPIO PD16 GPIO General Purpose Input Output #112 83 GPIO105 PD9 GPIO PD9 GPIO General Purpose Input Output #105 84 GND GND POWER ? G 85 GPIO114 PD18 GPIO PD18 GPIO General Purpose Input Output #114 86 GPIO203 PG11 GPIO PG11 GPIO General Purpose Input Output #203 87 GPIO110 PD14 GPIO PD14 GPIO General Purpose Input Output #110 88 GPIO200 PG8 GPIO PG8 GPIO General Purpose Input Output #200 89 GPIO109 PD13 GPIO PD13 GPIO General Purpose Input Output #109 90 GPIO198 PG6 GPIO PG6 GPIO General Purpose Input Output #198 91 GPIO108 PD12 GPIO PD12 GPIO General Purpose Input Output #108 92 GPIO144 PE16 GPIO PE16 GPIO General Purpose Input Output #144 93 GND GND POWER ? G 94 GND GND POWER ? G 95 GPIO132 PE4 GPIO PE4 GPIO General Purpose Input Output #132 96 GPIO134 PE6 GPIO PE6 GPIO General Purpose Input Output #134 97 GPIO205 PG13 GPIO PG13 GPIO General Purpose Input Output #205 98 GPIO140 PE12 GPIO PE12 GPIO General Purpose Input Output #140 99 GPIO202 PG10 GPIO PG10 GPIO General Purpose Input Output #202 100 GPIO130 PE2 GPIO PE2 GPIO General Purpose Input Output #130 101 GPIO131 PE3 GPIO PE3 GPIO General Purpose Input Output #131 102 GPIO129 PE1 GPIO PE1 GPIO General Purpose Input Output #129 103 GND GND POWER ? G 104 GND GND POWER ? G 105 GPIO136 PE8 GPIO PE8 GPIO General Purpose Input Output #136 106 GPIO196 PG4 GPIO PG4 GPIO General Purpose Input Output #196 107 GPIO138 PE10 GPIO PE10 GPIO General Purpose Input Output #138 108 GPIO193 PG1 GPIO PG1 GPIO General Purpose Input Output #193 109 GPIO145 PE17 GPIO PE17 GPIO General Purpose Input Output #145 110 GPIO195 PG3 GPIO PG3 GPIO General Purpose Input Output #195 111 GPIO139 PE11 GPIO PE11 GPIO General Purpose Input Output #139 112 GPIO197 PG5 GPIO PG5 GPIO General Purpose Input Output #197 113 GPIO141 PE13 GPIO PE13 GPIO General Purpose Input Output #141 114 GND GND POWER ? G 115 GND GND POWER ? G 116 DSI-D1P MDSI-D1P MIPI_DSI P22 AO MIPI DSI Positive Differential Data Line 1 117 GPIO201 PG9 GPIO PG9 GPIO General Purpose Input Output #201 118 DSI-D1N MDSI-D1N MIPI_DSI R22 AO MIPI DSI Negative Differential Data Line 1 119 GPIO199 PG7 GPIO PG7 GPIO General Purpose Input Output #199 120 GPIO204 PG12 GPIO PG12 GPIO General Purpose Input Output #204 121 DSI-D0P MDSI-D0P MIPI_DSI T22 AO MIPI DSI Positive Differential Data Line 0 122 DSI-D3P MDSI-D3P MIPI_DSI L23 AO MIPI DSI Positive Differential Data Line 3 123 DSI-D0N MDSI-D0N MIPI_DSI T23 AO MIPI DSI Negative Differential Data Line 0 124 DSI-D3N MDSI-D3N MIPI_DSI L22 AO MIPI DSI Negative Differential Data Line 3 125 GND GND POWER ? G 126 DSI-D2P MDSI-D2P MIPI_DSI M22 AO MIPI DSI Positive Differential Data Line 2 127 DSI-CKP MDSI-CKP MIPI_DSI N23 AO MIPI DSI Positive Differential Clock Line 128 DSI-D2N MDSI-D2N MIPI_DSI N22 AO MIPI DSI Negative Differential Data Line 2 129 DSI-CKN MDSI-CKN MIPI_DSI P23 AO MIPI DSI Negative Differential Clock Line 130 GPIO72 PC8 GPIO PC8 GPIO General Purpose Input Output #72 131 GND GND POWER ? G 132 GPIO71 PC7 GPIO PC7 GPIO General Purpose Input Output #71 133 GPIO79 PC15 GPIO PC15 GPIO General Purpose Input Output #79 134 GPIO64 PC0 GPIO PC0 GPIO General Purpose Input Output #64 135 GPIO68 PC4 GPIO PC4 GPIO General Purpose Input Output #68 136 VIDEO-HTX0P HTX0P HDMI G22 AO HDMI Positive Differential Data Line 0 137 GND GND POWER ? G 138 VIDEO-HTX0N HTX0N HDMI G23 AO HDMI Negative Differential Data Line 0 139 VIDEO-HTX2N HTX2N HDMI E22 AO HDMI Negative Differential Data Line 2 140 GND GND POWER ? G 141 VIDEO-HTX2P HTX2P HDMI D23 AO HDMI Positive Differential Data Line 2 142 GPIO66 PC2 GPIO PC2 GPIO General Purpose Input Output #66 143 VIDEO-HTX1P HTX1P HDMI E23 AO HDMI Positive Differential Data Line 1 144 GPIO80 PC16 GPIO PC16 GPIO General Purpose Input Output #80 145 VIDEO-HTX1N HTX1N HDMI F22 AO HDMI Negative Differential Data Line 1 146 GPIO76 PC12 GPIO PC12 GPIO General Purpose Input Output #76 147 GND GND POWER ? G 148 GPIO67 PC3 GPIO PC3 GPIO General Purpose Input Output #67 149 VIDEO-TXCN HTXCN HDMI H23 AO HDMI Negative Differential Clock Line 150 GPIO65 PC1 GPIO PC1 GPIO General Purpose Input Output #65 151 VIDEO-TXCP HTXCP HDMI H22 AO HDMI Positive Differential Clock Line 152 GND GND POWER ? G 153 GPIO73 PC9 GPIO PC9 GPIO General Purpose Input Output #73 154 GPIO70 PC6 GPIO PC6 GPIO General Purpose Input Output #70 155 GPIO78 PC14 GPIO PC14 GPIO General Purpose Input Output #78 156 GPIO74 PC10 GPIO PC10 GPIO General Purpose Input Output #74 157 GPIO77 PC13 GPIO PC13 GPIO General Purpose Input Output #77 158 USB1-DP USB1-DP USB B23 A I/O USB 1 Data Positive 159 GND GND POWER ? G 160 USB1-DM USB1-DM USB C22 A I/O USB 1 Data Negative 161 VIDEO-SCL HSCL HDMI G21 I/O HDMI DDC Clock 162 GND GND POWER ? G 163 VIDEO-SDA HSDA HDMI E20 I/O HDMI DDC Data 164 VIDEO-HPD HHPD HDMI E21 I/O HDMI Hot Plug Detection 165 GPIO75 PC11 GPIO PC11 GPIO General Purpose Input Output #75 166 GPIO362 PL10 GPIO PL10 GPIO General Purpose Input Output #362 167 VIDEO-CEC HCEC HDMI F21 I/O HDMI CEC 168 PWR_ON PWRON PMU 60 I Power On-Off key input 169 GND GND POWER ? G 170 NC 171 USB0-DP USB0-DP USB A22 A I/O USB 0 Data Positive 172 DCDC1 DCDC1 POWER ? P 3.3V from DCDC for eMMC, LEDs and other external devices with higher power consumption 173 USB0-DM USB0-DM USB B22 A I/O USB 0 Data Negative 174 GPIO0-LDO GPIO0 POWER ? P 3.3V@100mA from LDO for Capacitive Touch Screen I2C interface as pull-up and other purposes with low power consumption 175 CHG_LED CHGLED OTHER 53 O Charger status indication 176 ALDO1 ALDO1 POWER ? P 2.8V@500mA from LDO for CSI Camera and other 2.8V based devices with low power consumption 177 RESET RESET OTHER ? I Pin for restarting of device, ground pin to perform device reset 178 NC 179 NC 180 DCIN ACIN POWER ? P 5V input, but probably can be more, look at the AXP803 datasheet 181 ELDO3 ELDO3 POWER ? P 1.8V@200mA from LDO for CSI Camera and other 1.8V based devices with low power consumption 182 DCIN ACIN POWER ? P 5V input, but probably can be more, look at the AXP803 datasheet 183 DLDO3 DLDO3 POWER ? P 2.8V@300mA from LDO for CSI Camera and other 2.8V based devices with low power consumption 184 DCIN ACIN POWER ? P 5V input, but probably can be more, look at the AXP803 datasheet 185 VCC-WIFI DLDO4 POWER ? P 3.3V@500mA from LDO for WiFi, Bluetooth and other 3.3V based devices 186 NC 187 DC1-SW DC1-SW POWER ? P 3.3V from DCDC for LCD and Ethernet (RGMII, RMII so GMAC and EMAC) and other 3.3V based devices 188 USBVBUS USBVBUS POWER ? P 5V for powering and charging PMU 189 DLDO2 DLDO2 POWER ? P Probably 1.8V@400mA (some sources indicate 3.3V) from DCDC for MIPI and other 1.8V based devices 190 USBVBUS USBVBUS POWER ? P 5V for powering and charging PMU 191 DLDO1 DLDO1 POWER ? P 3.3V@500mA from LDO for HDMI, MIPI DSI and other 3.3V based devices 192 USBVBUS USBVBUS POWER ? P 5V for powering and charging PMU 193 VCC-WIFI-IO DLDO4 POWER ? P 3.3V@500mA from LDO for WiFi, Bluetooth and other 3.3V based devices 194 NC 195 NC 196 BATT_SENSOR TS PMU ? I Battery Temperature Sensor Input 197 VRTC VCC-RTC PMU ? O Output pin of RTLCDO (NOT SURE) 198 NC 199 PS IPSOUT POWER 55 P 3.5V-5V@3A System power source 200 VBAT VBAT POWER ? P 3.5-4.2V power input from battery 201 PS IPSOUT POWER 55 P 3.5V-5V@3A System power source 202 VBAT VBAT POWER ? P 3.5-4.2V power input from battery 203 PS IPSOUT POWER 55 P 3.5V-5V@3A System power source 204 VBAT VBAT POWER ? P 3.5-4.2V power input from battery Troubleshooting There is a number of things that can prevent the board from booting up properly. The most common culprits of a failed boot are:\nSubpar or counterfeit microSD card Subpar Power Supply High resistance (thin) or a very long microUSB cable Failed imaging of the microSD card Note Make sure to have the newest version of the operating system and the bootloader installed. To find out more, visit the PINE64 forum thread.\nSupported screen resolutions The board supports a number of video resolutions under Linux, however RemixOS and Android images currently only support 720p and 1080p. Linux supports a wider range of resolutions (see all resolutions supported on Linux here). If the native resolution of your monitor or TV is not compatible with the board you will be unable to get video output working with your screen.\nSteps Follow these steps to determine the cause of your problem:\nCheck your PSU and barrel cable ratings Download and install a base image of Linux Plug in power and ethernet into your Board Confirm activity on the ethernet port LED Find out the IP of the SOPINE on the router interface Try to connect to the running SOPINE from your computer using SSH Notes If neither of the above mentioned scenarios fits the problem you are facing, please consult the PINE64 forum thread from user Ghost.\nFurther information Specification\nSchematics and certifications\nSpecification Based on the Allwinner A64\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Supports OpenGL ES 2.0 and OpenVG 1.1 standard Five megapixel CMOS camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) Schematics and certifications SOPINE module schematic:\nSOPINE Module Schematic SOPINE pin assignments:\nSOPINE Module Pin Assignment ver 1.0 PINE A64-LTS / SOPINE WiFi/BT module schematic:\nPINE A64 WiFi/BT Module Schematic PINE A64-LTS / SOPINE Stereo Audio DAC board schematic:\nPINE A64-LTS / SOPINE Stereo Audio DAC Board Schematic SOPINE (together with model \u0026ldquo;A\u0026rdquo; baseboard) certification:\nSOPINE with model \u0026ldquo;A\u0026rdquo; baseboard FCC Certificate SOPINE with model \u0026ldquo;A\u0026rdquo; baseboard CE Certificate SOPINE with model \u0026ldquo;A\u0026rdquo; baseboard RoHS Certificate PINE A64, PINE A64+, PINE A64-LTS and SOPINE related Five megapixel CMOS camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) S5K4EC 5MP CMOS Image Sensor SoC Module Datasheet S5K4EC 5MP CMOS Image Sensor SoC Chip Datasheet S5K4EC 5MP CMOS Image Sensor Driver Source Code in C language Early version Camera module information:\nBonsen Kexin V118-A64-GC2145-HM5065 CMOS Image Sensor Module HiMax 5MP CMOS Image Sensor SoC LCD Touch Screen Panel information:\n7.0\u0026quot; 1200x600 TFT-LCD Panel Specification Touch Panel Specification GOODiX GT911 5-Point Capacitive Touch Controller Datasheet Lithium battery information:\n8000mAH Lithium Battery Specification Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64-LTS Board and SOPINE Baseboard WiFi/BT module information:\nPINE A64 Wifi/BT Module Schematic Realtek RTL8723BS WiFi with BT SDIO Enclosure information:\nPlaybox Enclosure 3D file ABS Enclosure 3D file Outdoor Aluminum Cast Dust-proof IP67 Enclosure Drawing Connector information:\n2.0mm PH Type connector specification use in Lithium Battery (VBAT) port and RTC Battery port 0.5mm Pitch cover type FPC connector specification use in DSI port, TP port and CSI port Remote control button mapping:\nOfficial Remote Control for the PINE A64 Button Mapping ","permalink":"/documentation/SOPINE/_full/","tags":null,"title":"SOPINE (Single Page)"},{"categories":["Computer modules"],"contents":" SOPINE Baseboard The SOPINE Baseboard Model A is a hosts the SOPINE A64 Compute Module and turns it into a full single board computer. Makers can use this baseboard as reference to develop their own PCBs and for software development during early stages for custom hardware or PCB development.\nFeatures and Specifications Networking Gigabit Ethernet Storage eMMC module slot Connections HD Digital Video Out 2x USB 2.0 Host Euler bus Expansion bus PI-2 bus Touch Panel Port (TP) Display Serial Interface (DSI) port IR R/X port Real Time Clock port (RTC) Lithium battery port SMOS sensor interface port Optional 802.11GBN + BT 4.0 module expansion module Headphone jack 3.5mm Barrel Power (5V 3A) port Gigabit Ethernet The baseboard’s Ethernet port allows for fast internet access\nUSB 2.0 Two USB 2.0 Host ports allow for connecting external accessories\nBattery Port Lithium battery port allows for running the board without being tethered to a outlet\nPI-2 GPIO The SOPINE baseboard comes with a 2x20 pin PI-2 GPIO heade\nStores Global Global: Accessories Affiliates Documentation SOPINE_Baseboard Schematics and certifications ","permalink":"/devices/sopine_baseboard/","tags":null,"title":"SOPINE Baseboard"},{"categories":null,"contents":" The SOPINE Baseboard Model A is a baseboard that hosts the SOPINE A64 Compute Module and turns it into a full single board computer. Makers can use this baseboard as reference to develop their own PCBs and for software development during early stages for custom hardware or PCB development.\nSpecifications Gigabit Ethernet eMMC module slot HD Digital Video Out 2x USB 2.0 Host Euler bus Expansion bus PI-2 bus Touch Panel Port (TP) Display Serial Interface (DSI) port IR R/X port Real Time Clock port (RTC) Lithium battery port SMOS sensor interface port Optional 802.11GBN + BT 4.0 module expansion module Headphone jack 3.5mm Barrel Power (5V 3A) port Schematics and certifications SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard schematic and PCB board resources:\nSOPINE model \u0026ldquo;A\u0026rdquo; Baseboard is an hardware open source project but is not \u0026ldquo;OSH\u0026rdquo; compliant SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic capture Rev B DSN source file SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic Rev B PDF file SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Job source file SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Gerber file SOPINE Model \u0026ldquo;A\u0026rdquo; Baseboard PCB Layout PDF file SOPINE (together with model \u0026ldquo;A\u0026rdquo; baseboard) certification:\nSOPINE with model \u0026ldquo;A\u0026rdquo; baseboard FCC Certificate SOPINE with model \u0026ldquo;A\u0026rdquo; baseboard CE Certificate SOPINE with model \u0026ldquo;A\u0026rdquo; baseboard RoHS Certificate Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver for PINE A64-LTS Board and SOPINE Baseboard ","permalink":"/documentation/SOPINE_Baseboard/_full/","tags":null,"title":"SOPINE Baseboard (Single Page)"},{"categories":["SBCs"],"contents":" The SOQuartz The SOQuartz is a RK3566 based compute module and parts of Quartz64 series.\nStores Global Global: Accessories Affiliates Documentation SOQuartz Schematics and certifications ","permalink":"/devices/soquartz/","tags":null,"title":"SOQuartz"},{"categories":null,"contents":" The SOQuartz\nThe SOQuartz is a RK3566 based compute module and parts of Quartz64 series.\nSoftware Android SDK\nBSP Linux SDK\nMaking your own\nReleases\nReleases Note The images are provided by the PINE64 community, not by Pine Store Ltd. Most community projects currently aim at getting mainline Linux running on the board, not some vendor provided kernel that will never be receiving updates. A mainline-first approach allows for the boards to continue receiving important updates, such as security updates, for years to come, as well as have higher quality code in the kernel as it underwent independent review, but does mean that not all aspects of the hardware work right out of the gate. DietPi DietPi is a lightweight, yet easy to setup and feature-rich Linux distribution, based on Debian. To find out more about DietPi, please visit the official documentation. Discuss the Quartz64 builds on the PINE64 forum thread.\nDownload:\nDirect download from dietpi.com Default credentials Root user root/dietpi Android SDK Android 11 SDK for Quartz64 model A SBC Download:\nDirect Download from pine64.org Notes:\nMD5 (TAR-GZip file): 77c2ff57ea3372fb04da7fb49e17d12b File size: 79.00 GB Just the boot blobs (\u0026lt;1MB): https://wiki.pine64.org/wiki/File:Rk35-blobs.tar.gz BSP Linux SDK BSP Linux SDK ver 4.19 for Quartz64 model A SBC Download:\nDirect Download from pine64.org Notes:\nMD5 (TAR-GZip file): 24554419aec29700add97167a3a4c9ed File size: 32.67 GB Making your own Making your own image/installation of Linux for SOQuartz is relatively easy, as all major components are mainlined. You will need:\nA build of mainline U-Boot ≥ v2023.10. Flash this to sector 64 (sector size 512, so byte 32768) of your image for SD or eMMC. It’s prudent to \u0026ldquo;protect\u0026rdquo; it by making a small (~16MiB) partition at this offset. A mainline Linux kernel ≥ v6.2. See Quartz64/Development#Linux Kernel Config Options for the device specific kernel configuration options. The root filesystem of the distribution of your choice. This can be on the same filesystem as your kernel and device tree if using extlinux.conf. You can either boot the kernel through U-Boot’s EFI booting, in which case it gets its device tree from U-Boot, or mark the partition containing your kernel and device tree with the legacy bootable flag and write an extlinux/extlinux.conf as explained in the U-Boot documentation.\nPins SOQuartz Module Connector Pins Definition ver 1.0 Heatsinks The SOQuartz SoM does not have a lot of copper to sink heat into. Therefore, it’s recommended you use a heatsink such as the Waveshare CM4 Heatsink, the other Waveshare CM4 Heatsink, or the PINE64 Small Fan Type Heatsink. Please be aware that the Waveshare heatsinks may interfere with any eMMC module, unless you use very thick (2-3 mm?) thermal pads. Local resellers may sell CM4 heatsinks or small stick-on heatsinks, so there’s no need to order them from abroad unless it’s cheaper.\nAlternatively, or in addition to this, a rectangle-shaped piece of 1 mm thick thermal pad can be sandwiched between the SoM and the carrier board. This allows the SoM to more efficiently sink heat into the larger mass of the base board.\nBaseboards SOQuartz BLADE Baseboard\nSOQuartz Model-A Baseboard\nVarious CM4 carrier boards\nSOQuartz BLADE Baseboard SOQuartz BLADE Baseboard\nSOQuartz BLADE Baseboard Dimensions: 200mm x 40mm x 15mm Input Power: DC 5V @ 3A 3.5OD/1.35ID (IEC 60130-10 Type H) Barrel DC Jack connector PoE Storage microSD - bootable, support SDHC and SDXC, storage up to 2TB USB - USB2.0 Host port (with header for setting OTG ID pin) Expansion Ports 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header M.2 slot PWM fan header Jumpers OTG ID jumper GPIO voltage, select 3.3V or 1.8V PoE Enable SOQuartz Model-A Baseboard SOQuartz Model-A Baseboard\nModel \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm Input Power: DC 12V @ 3A 5.5OD/2.1ID (IEC 60130-10 Type A) Barrel DC Jack connector Storage microSD - bootable, support SDHC and SDXC, storage up to 2TB USB -\t2 USB2.0 Host port Expansion Ports MiPi-CSI - 1x 2 lanes, 1x 4 lanes MiPi-DSI - 1x 2 lanes, 1x 4 lanes 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header PCIe 1x open ended slot 1x5 pin USB Expansion Header (J15) GPIO Pins Attention! GPIOs are 3.3V!\nInteresting alternate pin configurations are listed in [brackets].\nAssigned To Pin no. Pin no. Assigned To 3.3 V 1 2 5 V [I2C2_SDA_M1] GPIO4_B4_3V3 a 3 4 5 V [I2C2_SCL_M1] GPIO4_B5_3V3 a 5 6 GND [GPCLK0] GPIO4_A4_3V3 7 8 GPIO0_D1_3V3 [UART2_TX_M0] GND 9 10 GPIO0_D0_3V3 [UART2_RX_M0] [I2S1_MCLK_M1] GPIO3_C6_3V3 11 12 GPIO3_C7_3V3 [I2S1_SCLK_M1] GPIO4_A0_3V3 13 14 GND GPIO4_A2_3V3 15 16 GPIO4_A3_3V3 3.3V 17 18 GPIO4_A1_3V3 [SPI3_MOSI_M0] GPIO4_B2_3V3 19 20 GND [SPI3_MISO_M0] GPIO4_B0_3V3 21 22 GPIO4_B1_3V3 [SPI3_CLK_M0] GPIO4_B3_3V3 23 24 GPIO4_A6_3V3 [SPI3_CS0_M0] GND 25 26 GPIO4_A7_3V3 [SPI3_CS1_M0] [I2C3_SDA_M0] GPIO1_A0_3V3 a 27 28 GPIO1_A1_3V3 [I2C3_SCL_M0] a GPIO3_A5_3V3 29 30 GND GPIO3_D4_3V3 31 32 GPIO3_D6_3V3 GPIO3_D7_3V3 33 34 GND [I2S1_LRCK_M1] GPIO3_D0_3V3 35 36 GPIO3_D5_3V3 GPIO3_D3_3V3 37 38 GPIO3_D2_3V3 [I2S1_SDI_M1] GND 39 40 GPIO3_D1_3V3 [I2S1_SDO_M1] Notes a pulled high to 3.3V through 2.2kOhm resistor\nSource: Page 11 of the board schematics.\nUSB Expansion Header Pin no Assigned To 1 USB2_HOST_5V 2 HOST_DM3 3 HOST_DP3 4 GND 5 GND Source: Page 10 of the board schematics.\nVarious CM4 carrier boards For CM4 carrier board comprehensive list, please visit Jeff Geerling collection SOQuartz with DF Robot CM4 Carrier Board\nSOQuartz with Waveshare CM4 Carrier Board\nSOQuartz with Waveshare CM4 PoE Board\nFurther information Datasheets\nSchematics and certifications\nSpecifications\nDatasheets Rockchip RK3566 SoC information:\nRockchip RK3566 ver 1.0 datasheet, already got release permission from Rockchip Rockchip PMU (Power Management Unit) Information:\nRockchip RK809 ver 1.01 datasheet for SOQuartz PMU DDR4 information:\nMicron LPDDR4 Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet Ethernet PHY information:\nRealtek RTL8211 10/100/1000M Ethernet Transceiver WiFi/BT module info:\nAzurewave CM256SM 11AC WiFi + Bluetooth5.0 Datasheet i2C to PWM Controller user in BLADE info:\nGP7101 i2c to PWM Controller Datasheet in Chinese GP7101 i2c to PWM Controller Datasheet translated to English by neggles https://wiki.pine64.org/wiki/File:GP7101 cn V1 qsxn en.pdf I^2^C address is 0x58 despite what datasheet says PoE DC/DC Controller user in BLADE info:\nSilan SD4954B PD and DC/DC Controller compatible with IEEE 802.3AF standard Datasheet Schematics and certifications SOQuartz Module Schematic:\nSOQuartz Module ver 1.1 20210816 Schematic SOQuartz Module ver 1.1 20210816 PCB Component Placement SOQuartz Model \u0026ldquo;A\u0026rdquo; Baseboard Schematic and PCB Board Resource:\nSOQuartz Model-A baseboard 20220522 Schematic PDF file SOQuartz Model-A baseboard 20220522 Schematic DSN source file SOQuartz SOQuartz Model-A baseboard 20220522 PCB Top Component Placement SOQuartz SOQuartz Model-A baseboard 20220522 PCB Bottom Component Placement SOQuartz Model-A baseboard 20220522 PCB DSN file SOQuartz Model-A baseboard 20220522 PCB Gerber file SOQuartz Blade Baseboard Schematic and PCB Board Resource:\nSOQuartz BLADE 20220522 Schematic SOQuartz BLADE 20220522 PCB component Placement SOQuartz BLADE 1U Rack STP file SOQuartz module certifications:\nSOQuartz module FCC Certificate SOQuartz module CE EMC Certificate Specifications The SOQuartz is based on the Rockchip RK3566.\nCPU Architecture Quad-core ARM Cortex-A55@1.8GHz AArch32 for full backwards compatibility with ARMv7 ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation Includes VFP hardware to support single and double-precision operations ARMv8 Cryptography Extensions Integrated 32KB L1 instruction cache and 32KB L1 data cache per core 512KB unified system L3 cache GPU (Graphics Processing Unit) Capabilities Mali-G52 2EE Bifrost GPU@800MHz 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop 128KB L2 Cache configurations Supports OpenGL ES 1.1, 2.0, and 3.2 Supports Vulkan 1.0 and 1.1 Supports OpenCL 2.0 Full Profile Supports 1600 Mpix/s fill rate when at 800MHz clock frequency Supports 38.4 GLOP/s when at 800MHz clock frequency Neural Process Unit NPU Capability Neural network acceleration engine with processing performance of up to 0.8 TOPS Supports integer 8 and integer 16 convolution operations Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet System Memory RAM Memory Variants: 2GB, 4GB, 8GB LPDDR4. Storage Memory: optional 128Mb SPI Flash and optional eMMC module from 8GB up to 128GB Network 10/100/1000 Mbps Ethernet WiFi 802.11 b/g/n/ac with Bluetooth 5.0 Displays / Cameras 1x HDMI 2x DSI 1x eDP (Instead of HDMI1) 1x LVDS (not available when dual-mode DSI) 1x CSI 4-line Connectivity 1x Ethernet (1 Gbit) 1x USB 2.0 OTG 1x SD Card (SD) 1x PCIe 1-Line 28x GPIO (TBD) ","permalink":"/documentation/SOQuartz/_full/","tags":null,"title":"SOQuartz (Single Page)"},{"categories":null,"contents":" SOQuartz BLADE Baseboard\nSOQuartz BLADE Baseboard Dimensions: 200mm x 40mm x 15mm Input Power: DC 5V @ 3A 3.5OD/1.35ID (IEC 60130-10 Type H) Barrel DC Jack connector PoE Storage microSD - bootable, support SDHC and SDXC, storage up to 2TB USB - USB2.0 Host port (with header for setting OTG ID pin) Expansion Ports 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header M.2 slot PWM fan header Jumpers OTG ID jumper GPIO voltage, select 3.3V or 1.8V PoE Enable ","permalink":"/documentation/SOQuartz/Baseboards/BLADE/","tags":null,"title":"SOQuartz BLADE Baseboard"},{"categories":null,"contents":" SOQuartz Model-A Baseboard\nModel \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm x 80mm x 19mm Input Power: DC 12V @ 3A 5.5OD/2.1ID (IEC 60130-10 Type A) Barrel DC Jack connector Storage microSD - bootable, support SDHC and SDXC, storage up to 2TB USB -\t2 USB2.0 Host port Expansion Ports MiPi-CSI - 1x 2 lanes, 1x 4 lanes MiPi-DSI - 1x 2 lanes, 1x 4 lanes 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header PCIe 1x open ended slot 1x5 pin USB Expansion Header (J15) GPIO Pins Attention! GPIOs are 3.3V!\nInteresting alternate pin configurations are listed in [brackets].\nAssigned To Pin no. Pin no. Assigned To 3.3 V 1 2 5 V [I2C2_SDA_M1] GPIO4_B4_3V3 a 3 4 5 V [I2C2_SCL_M1] GPIO4_B5_3V3 a 5 6 GND [GPCLK0] GPIO4_A4_3V3 7 8 GPIO0_D1_3V3 [UART2_TX_M0] GND 9 10 GPIO0_D0_3V3 [UART2_RX_M0] [I2S1_MCLK_M1] GPIO3_C6_3V3 11 12 GPIO3_C7_3V3 [I2S1_SCLK_M1] GPIO4_A0_3V3 13 14 GND GPIO4_A2_3V3 15 16 GPIO4_A3_3V3 3.3V 17 18 GPIO4_A1_3V3 [SPI3_MOSI_M0] GPIO4_B2_3V3 19 20 GND [SPI3_MISO_M0] GPIO4_B0_3V3 21 22 GPIO4_B1_3V3 [SPI3_CLK_M0] GPIO4_B3_3V3 23 24 GPIO4_A6_3V3 [SPI3_CS0_M0] GND 25 26 GPIO4_A7_3V3 [SPI3_CS1_M0] [I2C3_SDA_M0] GPIO1_A0_3V3 a 27 28 GPIO1_A1_3V3 [I2C3_SCL_M0] a GPIO3_A5_3V3 29 30 GND GPIO3_D4_3V3 31 32 GPIO3_D6_3V3 GPIO3_D7_3V3 33 34 GND [I2S1_LRCK_M1] GPIO3_D0_3V3 35 36 GPIO3_D5_3V3 GPIO3_D3_3V3 37 38 GPIO3_D2_3V3 [I2S1_SDI_M1] GND 39 40 GPIO3_D1_3V3 [I2S1_SDO_M1] Notes a pulled high to 3.3V through 2.2kOhm resistor\nSource: Page 11 of the board schematics.\nUSB Expansion Header Pin no Assigned To 1 USB2_HOST_5V 2 HOST_DM3 3 HOST_DP3 4 GND 5 GND Source: Page 10 of the board schematics.\n","permalink":"/documentation/SOQuartz/Baseboards/Model-A/","tags":null,"title":"SOQuartz Model-A Baseboard"},{"categories":null,"contents":"Note that sound is only currently available with special patches on top of a 5.13.13 or higher kernel with Armbian or NixOS. Once you have a kernel that supports sound you can install alsa-utils to get the alsamixer tool. The following mixer settings have been found to work with both playback and record. Note that you’ll need to press F5 to get the capture controls and space bar to turn on/off capture for a device. The speaker dangles on a wire from the device. The microphone is located about 1cm below the lens on the front facing circuit board.\n","permalink":"/documentation/PineCube/Tuning/Sound_controls/","tags":null,"title":"Sound controls"},{"categories":null,"contents":" General Information Dimensions: 191.1x232.5x7.4mm Weight: 438g Core CPU: RK3566 1.8GHz 64-bit quad-core A55 GPU: MALI G52 2EE System memory: 4GB LPDDR4 Flash: 128GB eMMC E-ink Display Size: 10.3\u0026quot; Resolution: 1404x1872 DPI: 227 Grayscale: 16 Front Light: 36 level cold and warm Capacitive multi-touch panel EMR pen digitizer Network WiFi: 2.4/5GHz 802.11a/b/g/n/ac Bluetooth: 5.0 Audio Built in stereo speakers 4 x DMIC microphone Sensor G-Sensor for portrait and landscape sensing Power 4000mAH LiPo battery DC 5V @ 3A USB-C connector Accessories December 2021 batch: Optional EMR pen with magnetic attachment (included in the first production batch) October 2024 batch: Optional passive pen Optional Cover (included in the December 2021 and October 2024 batch) ","permalink":"/documentation/PineNote/Further_information/Specification/","tags":null,"title":"Specification"},{"categories":null,"contents":"Based on the Rockchip RK1808.\nCPU Architecture Dual-core ARM Cortex-A35 Processor@1600-2000Mhz A power-efficient ARM 64-Bit Armv8-A architecture AArch32 for full backward compatibility with Armv7 Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions (LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache AArch64 for 64-bit support and new architectural features TrustZone security technology Neon Advanced SIMD DSP and SIMD extensions VFPv4 Floating point Hardware virtualization support 128KB L2 cache Neural Process Unit NPU Capability NPU IP from Verisilicon Vivante Support max 1920 Int8 MAC operation per cycle Support max192 Int16 MAC operation per cycle Support max 64 FP16 MAC operation per cycle 512KB internal buffer One isolated voltage domain to support DVFS Acuity models Github System Memory RAM Memory Variants: 2GB DDR4. Storage Memory: 128Mb SPI Flash and optional eMMC module from 16GB up to 128GB ","permalink":"/documentation/SOEDGE/Further_information/Specification/","tags":null,"title":"Specification"},{"categories":null,"contents":"Based on the Allwinner A64\nCPU Architecture Quad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture ARM Mali400MP2 Dual-core GPU Supports OpenGL ES 2.0 and OpenVG 1.1 standard Five megapixel CMOS camera module information:\nPINE64 YL-PINE64-4EC 5M Pixel CMOS Image Sensor Module (Description in Chinese) ","permalink":"/documentation/SOPINE/Further_information/Specification/","tags":null,"title":"Specification"},{"categories":null,"contents":" Based on StarFive JH7110 CPU Architecture Quad-core U74 up to 1.5GHz CPU Fully compliant with the RISC-V ISA specification 64-bit RISC-V Application Core 32KB L1 I-cache with ECC 32KB L1 D-cache with ECC 8 Region Physical Memory Protection Virtual Memory support with up to 47 Physical Address bits Integrated up to 2MB L2 Cache with ECC includes RV64IMAC S7 monitor core, 16 KB L1 I-Cache with ECC, 8 KB DTIM with ECC 32-bit RISC-V CPU core (E24) for real time control, support RV32IMFC RISC-V ISA GPU Architecture Imagination Technology BXE-4-32 up to 600Mhz GPU Support OpenCL 3.0 Support OpenGL ES 3.2 Support Vulkan 1.2 Tile-based deferred rendering architecture for 3D graphics workloads, with concurrent processing of multiple tiles Support for GPU visualization, up to 8 virtual GPUs On fly frame buffer compression and decompression (TFBC) algorithm Performance: 128 FP32 FLOPs/Clock, 256 FP16 FLOPs/Clock System Memory LPDDR4 RAM Memory Variants: 2GB, 4GB and 8GB. ","permalink":"/documentation/STAR64/Further_information/Specification/","tags":null,"title":"Specification"},{"categories":null,"contents":" Main Board and SoC Specification Based on StarPro64 Single Board Computer wiki page Based on ESWIN EIC7700X SoC EIC7700X block diagram\nFeatures System Memory 32GB 64bits LPDDR5@6400MHz RAM Memory. 64GB eMMC preinstalled with 7b Deepseek/Qwen LLM Case CNC from single Aluminum block Passive cooling, built-in heat pipe that directly contact with SoC Network Dual 10/100/1000 Mbps Ethernet 2.4GHz/5GHz MIMO WiFi 802.11 b/g/n/ac/ax with Bluetooth 5.3 Expansion Ports 2× USB3.0 Dedicated Host port 2× USB2.0 Shared Host port Digital Video output up to 4K@60Hz 3.5mm audio Jack with mic in Certifications Not yet available Potential Improvement Current 7bLLM throughput is around 3.5 tokens/second using docker form, potential improve up to 10 tokens/second when operates LLM in native mode. Potential increase LLM capability from 7b to 15b with system software optimization If ALPHA-One proven its potential, consider release ALPHA-Two which can host up to 30b LLM ","permalink":"/documentation/ALPHA-One/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":"These are the Clusterboard specifications:\nStandard mITX form-factor (167 mm x 170 mm) Built-in eight-port Gigabit Ethernet switch, using RTL8370N ASIC; the switch is unmanaged although the ASIC provides management functions, see this forum thread for further information Seven internal Gigabit Ethernet ports, one for each SOPINE module, connected to the built-in switch using RTL8211E PHYs One connector for an eMMC module, for the first SOPINE module Seven USB 2.0 ports, one for each SOPINE module GPIO pins exposed for each SOPINE module, including the UARTs Gigabit Ethernet port activity LEDs, one for each SOPINE module Battery holder for two standard non-rechargeable AA-size 1.5 V batteries, for the real time clock (RTC) backup on all SOPINE modules Barrel-style jack as a power input, 6.3 mm outer diameter and 3.0 mm inner diameter, for a 5 V, 15 A DC power supply Standard 24-pin ATX header as a power input, for an ATX power supply capable of providing at least 15 A at its 5 V output Please note than only one power input may be used at once. The barrel-style jack is additionally protected by a built-in 15 A polyfuse.\nNote No batteries for RTC backup should be installed unless certain hardware modifications are applied to the Clusterboard. Internal circuitry of the Clusterboard and SOPINE modules will eventually attempt to charge the batteries, which will result in damage to the batteries and the Clusterboard. Keep in mind that rechargeable batteries cannot be used because there is no charging circuitry for them on the Clusterboard. Please see this forum thread and this article for further information. ","permalink":"/documentation/Clusterboard/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":"The Pinebook is based on the Allwinner A64.\nDimensions:\n299mm x 200mm x 12mm (WxDxH - 11″ Pinebook); 329mm x 220mm x 12mm (WxDxH - 14″ Pinebook) Weight:\n1.04Kg (11″ Pinebook); 1.26Kg (14″ Pinebook) Input Power:\nDC 5V @ 3A CPU Architecture:\nQuad-core ARM Cortex-A53 Processor@1152Mhz A power-efficient ARM v8 architecture 64 and 32bit execution states for scalable high performance Support NEON Advanced SIMD (Single Instruction Multiple Data) instruction for acceleration of media and signal processing function Support Large Physical Address Extensions(LPAE) VFPv4 Floating Point Unit 32KB L1 Instruction cache and 32KB L1 Data cache 512KB L2 cache GPU Architecture:\nARM Mali400MP2 Dual-core GPU Support OpenGL ES 2.0 and OpenVG 1.1 standard Open source driver System Memory:\nSystem RAM Memory: 2GB Storage Memory: 16GB eMMC module, can be upgrade to 32GB or 64GB eMMC module Battery:\nLithium Polymer Battery (10,000 mAh; 9,600 mAh in later batches) Video:\nMini Digital Video Port (Type A - mini) Audio:\n3.5mm stereo earphone/microphone plug Network:\nWiFi 802.11 b/g/n with Bluetooth 4.0 10/100 Mbps USB Ethernet Dongle (Optional) Storage:\nmicroSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t2 USB2.0 Host port Expansion Ports:\nmini Digital Video port microSD card port - support SD, SDHC, SDXC uo to 256GB 2x USB 2.0 port earphone plug with UART console mux circuit ","permalink":"/documentation/Pinebook/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":"Based on Rockchip RK3399\nCPU Architecture big.LITTLE architecture: Dual Cortex-A72 + Quad Cortex-A53, 64-bit CPU\nFull implementation of the ARM architecture v8-A instruction set (both AArch64 and AArch32) ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation ARMv8 Cryptography Extensions VFPv4 floating point unit supporting single and double-precision operations Hardware virtualization support TrustZone technology support Full CoreSight debug solution One isolated voltage domain to support DVFS Cortex-A72 (big cluster):\nDual-core Cortex-A72 up to 2.0GHz CPU Superscalar, variable-length, out-of-order pipeline L1 cache 48KB Icache and 32KB Dcache for each A72 L2 cache 1024KB for big cluster Cortex-A53 (little cluster):\nQuad-core Cortex-A53 up to 1.5GHz CPU In-order pipeline with symmetric dual-issue of most instructions L1 cache 32KB Icache and 32KB Dcache for each A53 L2 cache 512KB for little cluster Cortex-M0 (control processors):\nCortex-M0 CPU Two Cortex-M0 cooperate with the central processors Architecture: Armv6-M Thumb/Thumb2 instruction set 32 bit only GPU Architecture ARM Mali-T860MP4 Quad-core GPU The highest performance GPUs built on Arm Mali’s famous Midgard architecture, the Mali-T860 GPU is designed for complex graphics use cases and provide stunning visuals for UHD content. Frequency 650MHz Throughput 1300 Mtri/s, 10.4 Gpix/s Graphic interface standards:\nOpenGL® ES 1.1, 1.2, 2.0, 3.0, 3.1, 3.2 (Panfrost has initial support of 3.0 beginning 2020/02/27) Vulkan 1.0, using the Mali binary blob (Panfrost does not support Vulkan as of 2020/06/24) OpenCL™ 1.1, 1.2 DirectX® 11 FL11_1 RenderScript™ System Memory RAM Memory:\nLPDDR4 800 MHz (limited by RK3399) Dual memory channels on the CPU, each 32 bits wide Quad memory channels on the RAM chip, each 16 bits wide, 2 bonded together for each CPU channel 4 GB as a single 366 pin mobile RAM chip Storage Memory:\n64GB eMMC module, can be upgraded to an 128GB eMMC module. (The initial PINE64 community build version shipped with a 128GB eMMC.) eMMC version 5.1, HS400, 8 bit on RK3399 side Bootable SPI flash:\nSPI 128 Mbit / 16MByte 1 bit interface Bootable, (first boot device, ahead of eMMC \u0026amp; SD card) U-Boot images can be made to work, but as of 2020/06/24 there is no standardized image available. Video out USB-C Alt mode DP Up to 3840x2160 p60, dependant on adapter, (2 lanes verses 4 lanes) Expansion Ports MicroSD card:\nBootable Supports SD, SDHC and SDXC cards, up to 512GB tested. SDXC standard says 2TB is the maximum. Version SD3.0, (MMC 4.5), up to 50 MB/s SD card Application Performance Class 1 (A1), (or better), recommended by some users, for better IOPS USB ports:\n1 x USB 2.0 Type-A Host Port, bootable 1 x USB 3.0 Type-A Host Port, 5 Gbps, is not bootable 1 x USB 3.0 Type-C OTG Port, 5 Gbps, (includes laptop charging function), is not bootable Note that high power USB devices may not work reliably on a PBP. Or they may draw enough power to drain the battery even when the PBP is plugged into A.C. One alternative is externally powered USB devices. Headphone jack switchable to UART serial console mux circuit\n","permalink":"/documentation/Pinebook_Pro/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Pinecil V2 Package: 15cm x 9cm x 2.2cm, white box (released Aug 2, 2022) Dimensions: 155mm with solder tip or 103mm without solder tip x 12.8mm x 16.2mm Weight: 28g with solder tip, 18g without solder tip Soldering Tip: includes type ST-B2 (short tip), Length 86mm, weight 8.2g Platform: Ralim’s IronOS build Display: OLED White Color Monochrome Display 0.69\u0026quot; 96x16 pixels Chipset: Bouffalo BL-706 CPU: 32-bit RV32IMAFC RISC-V \u0026ldquo;SiFive E24 Core\u0026rdquo; @ 144 MHz Memory: 192KB Internal ROM 132KB SRAM System Power Ports (12V-24V, 88 Watts): Only use one power port at a time (USB or DC barrel) USB type C: PD 12V-20V 3A and QC 3.0 12V-20V 3A (magnetic tip USB-C cables are not recommended, and not USB compliant) Barrel Jack: DC5525, 12V-24V, minimum 3amps. Trying to use an incorrect barrel jack, i.e., DC5521 will BREAK the connector (if it doesn’t go in easy, it doesn’t fit). Recommend operating voltage 12-24V, but a 12V USB-C charger will not perform as well or heat as fast as a USB-C PD65W/20V/3amp charger. Tentative support: EPR 140W/28V PD3.1 chargers + EPR cables are theoretically supported in hardware and IronOS firmware. EPR is new technology in 2022. Theoretically Pinecil could get a max of 28V and 126W using EPR chargers \u0026amp; EPR cables (natural loss of 140W to 126W due to Tip ohms). Bleeding edge users are using/testing this. EPR is potentially the fastest/highest performance possible for V2; officially Pine Store states 12V-24V, 88W. Pinecil V1 Package: 16.8cm x 11.8cm x 2.3cm, black box with clear plastic front (sold before Aug 2, 2022) Dimensions: 170mm with solder tip or 98mm without solder tip x 12.8mm x 16.2mm Weight: 30g with solder tip, 20g without solder tip Display: 0.67\u0026quot; QUG 9616TSWCG02 96x16 Monochrome Matrix display CPU: GD32VF103TB 32-bit RV32IMAC RISC-V \u0026ldquo;Bumblebee Core\u0026rdquo; @ 108 MHz Memory: 128KB Flash 32KB SRAM Power supply (12V -21V, 65W): Only use one power port at a time (USB or DC barrel) DC 12V-21V 5525 Barrel Jack. Do not try to use a larger 5521 (which requires excessive force). It will BREAK the connector. USB-C 12-20V PD or QC3.0 (magnetic tip USB-C cables are not recommended, and not USB compliant) Recommend operating voltage 12-21V, some components can tolerate higher voltages at \u0026ldquo;absolute maximum\u0026rdquo; but it’s very ill-advised Fasteners/Screws Originals screws are Phillips (source): two M2x3mm at the front, and one M2x4mm is the ground screw near the [-] minus button. The bottom-front screw only holds the handle together and does not touch the tip, hence is a shorter m2x 3mm. Thumb screws are popular upgrades: an M2 x 4mm thumb screw could replace both the front screen-side Tip holder screw and the ground screw in the rear of the handle. It was found that an M2x3mm thumb screw for the tip is a hair too short, and just grazes the Tip and the longer m2 x 4mm is better on top. Note If the screw is too long (for example with a length of 5mm) a metal file can be used lightly to shorten it a small amount. Stainless steel is recommended as the softer aluminum screws could mushroom as you tighten down the tip screw too much or over time. ","permalink":"/documentation/Pinecil/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Dimensions: 55mm x 51mm x 51.5mm Weight: 55g Storage: MicroSD slot, bootable 128Mb SPI Nor Flash, bootable Cameras: OV5640, 5Mpx CPU: Allwinner (Sochip) ARM Cortex-A7 MPCore, 800MHz RAM: 128MB DDR3 I/O: 10/100 Mbps Ethernet with passive PoE (4-18V!) USB 2.0 A host 26 pins GPIO port 2x 3.3V Ouptut 2x 5V Output 1x I2C 2x UART (3.3V) 2x PWM 1x SPI 1x eMMC/SDIO/SD (8-bit) 6x Interrupts Note: Interfaces are multiplexed, so they can’t be all used at same time Internal microphone Network: WiFi Screen: optional 4.5\u0026quot; RGB LCD screen ( RB043H40T03A-IPS or DFC-XS4300240 V01 ) Misc. features: Volume and home buttons Speakers and Microphone IR LEDs for night vision Passive infrared sensor Power DC in: 5V 1A from MicroUSB Port or GPIO port 4V-18V from Ethernet passive PoE Battery: optional 950-1600mAh model: 903048 Lithium Polymer Ion Battery Pack, can be purchase at Amazon.com ","permalink":"/documentation/PineCube/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Dimensions: 160.5 x 76.6 x 9.2mm Weight: Between 180 ~ 200 grams SIM Card: Micro-SIM Display: Size: 5.95 inches (151mm) diagonal Type: HD IPS capacitive touchscreen, 16M colors Resolution: 1440x720, 18:9 ratio System on Chip: Allwinner A64 RAM: 2GB or 3GB LPDDR3 SDRAM Internal Storage: 16GB or 32GB eMMC, extendable up to 2TB via microSD, supports SDHC and SDXC Back Camera: Single 5MP, 1/4\u0026quot;, LED Flash Front Camera: Single 2MP, f/2.8, 1/5\u0026quot; Sound: Loudspeaker, 3.5mm jack \u0026amp; mic (jack doubles as hardware UART if hardware switch 6 is deactivated) Communication: Modem: Quectel EG25-G LTE-FDD: B1, B2, B3, B4, B5, B7, B8, B12, B13, B18, B19, B20, B25, B26, B28 LTE-TDD: B38, B39, B40, B41 WCDMA: B1, B2, B4, B5, B6, B8, B19 GSM: B2, B3, B5, B8 (850, 900, 1800, 1900 MHz) WLAN: Wi-Fi 802.11 b/g/n, single-band, hotspot Bluetooth: 4.0, A2DP GNSS: GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS Sensors: Accelerometer, gyroscope, proximity, ambient light, compass Privacy switches: Modem, WiFi \u0026amp; Bluetooth, Microphone, Cameras Battery: Lithium-ion, rated capacity 2800mAh (10.64Wh), typical capacity 3000mAh (11.40Wh) (nominally replaceable with any Samsung J7 form-factor battery) I/O: USB Type-C, USB Host, DisplayPort Alternate Mode output, 15W 5V 3A Quick Charge, follows USB PD specification ","permalink":"/documentation/PinePhone/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Dimensions: 160.8 x 76.6 x 11.1mm Weight: Approx. 220g SIM Card: Nano-SIM (Micro-SIM before 07/2022) Display: Size: 6 inches (151mm) diagonal Type: 1440 x 720 in-cell IPS with Gorilla Glass 4™ Resolution: 1440x720, 18:9 ratio System on Chip: Rockchip RK3399S 64bit SoC – 2x A72 and 4x A53 CPU cores @ 1.5GHz RAM: 4GB LPDDR4 @ 800MHz Internal Storage: 128GB eMMC, extendable up to 2TB via microSD, supports SDHC and SDXC NOR Flash: Listed as [GigaDevices] GD25LQ128EWIGR, but physical inspection found a SiliconKaiser SK25LP128. Back Camera: 13MP Sony IMX258 with Gorilla Glass 4™ protective layer, LED Flash Front Camera: 8MP, OmniVision OV8858 front-facing camera Sound: Loudspeaker, 3.5mm jack \u0026amp; mic (jack doubles as hardware UART if hardware switch 6 is deactivated) Communication: Modem Quectel EG25-G LTE-FDD: B1, B2, B3, B4, B5, B7, B8, B12, B13, B18, B19, B20, B25, B26, B28 LTE-TDD: B38, B39, B40, B41 WCDMA: B1, B2, B4, B5, B6, B8, B19 GSM: B2, B3, B5, B8 (850, 900, 1800, 1900 MHz) WLAN \u0026amp; Bluetooth: Wi-Fi 802.11AC, hotspot capable + Bluetooth V5.0 GNSS: GPS/GLONASS/BeiDou/Galileo/QZSS, with A-GPS Sensors: Accelerometer, gyroscope, proximity, ambient light, compass Privacy switches: Modem, WiFi \u0026amp; Bluetooth, Microphone, Cameras Battery: Lithium-ion, rated capacity 2800mAh (10.64Wh), typical capacity 3000mAh (11.40Wh) (nominally replaceable with any Samsung J7 form-factor battery; unglue bottom black plastic with your nail from Samsung battery before installation in order to match the dimensions) I/O: USB Type-C, USB Host, DisplayPort Alternate Mode output, 15W 5V 3A Quick Charge, follows USB PD specification ","permalink":"/documentation/PinePhone_Pro/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Dimensions: 11mm x 175mm x 260mm (Thickness, Width, Height) Weight: 575g (Tablet alone) Build: Plastic Storage: 64GB of internal eMMC storage MicroSD slot, bootable M.2 SSD slot, supports SATA and USB devices only, not NVME (optional) Cameras: 2Mpx Front, 5Mpx Rear SOC: Allwinner A64 Quad Core CPU: 4x ARM A53 1.152GHz GPU: Mali 400 MP2 RAM: 2GB LPDDR3 I/O: HD Video Out (Mini HDMI), Micro USB 2.0 OTG, USB 2.0 A host, 3.5mm Headphone/Mic combo, Network: WiFi (802.11b/g/n, 2.4GHz only) Bluetooth 2.1 M.2 LTE / Cell MODEM card, (optional, and takes place of optional M.2 SSD) Display: Size: 10.1 inches (257mm) diagonal Type: HD IPS capacitive touchscreen, 16M colors Resolution: 1280x800, 16:10 ratio Attachments/Accessories: Magnetically attached keyboard (optional) Battery: 6000MAh (6Ah) Misc. features: Volume rocker Speakers and Microphone 2.5mm OD 0.7mm ID DC Jack Power (5V 2A) Port ","permalink":"/documentation/PineTab/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" SoC: Rockchip RK3566 CPU: 4x ARM Cortex-A55 @ 1.8 GHz 32KB L1 Instruction Cache and 32KB L1 Data Cache per core 512KB unified system L3 cache ARMv8 Cryptography Extensions GPU: Mali-G52 MP2 @ 800 MHz Supported by the open source \u0026lsquo;Panfrost\u0026rsquo; driver in Linux and Mesa Supports OpenGL 3.1 and OpenGL ES 3.1 with many newer extensions NPU: 0.8 TOPS Neural Processing Unit RAM: 4GB or 8GB LPDDR4 Storage: 64GB or 128GB internal eMMC (SiliconGo SGM8 100C-S36BCG; eMMC 5.1, up o 400MB/s) 1x MicroSD slot Display: 10.1\u0026quot; IPS LCD Resolution 1280x800 Cameras: Front: 2Mpx, chipset: Galaxycore GC02M2 Rear: 5Mpx, chipset: Omnivision OV5648 Battery: 6000 mAh (22.2Wh) Buttons: Power, volume up, volume down Network: Wi-Fi: BES2600 Driver under development, use a USB wifi dongle for now Bluetooth: BES2600 I/O: 1x USB-C 3.0 (top, host mode only; power output up to 680mA) 1x USB-C 2.0 + PD (bottom, device mode by default; power input) 1x MicroHDMI 1x 4 pole 3.5mm audio jack (microphone right) and headphone detection 2x speakers + microphone (microphone left) 1x 5 pin (USB 2.0; \u0026lt;=680mA) Pogo connector for keyboard (PCIe on PCB as a flat flex ribbon connector, no room for M.2 NVMe drives in case) Sensors: Accelerometer: Silan SC7A20 Ambient Light \u0026amp; Proximity Sensor Multimedia: rkdjpeg: 1080p120 JPEG decode hantro: JPEG/VP8/H.264 encode, 1080p MPEG-2/H.263/VP8/H.264 AVC decode rkvdec2: 4K H.264 AVC Main10 L5.1/H.265 HEVC Main10 L5.1/VP9 Profile 0 and 2 L5.1 decode rkvenc2: 4K H.264 AVC/H.265 HEVC encode Build: Metal and Plastic Dimensions: 242x161x9mm Weight: 538g Misc: Protective cover with keyboard ","permalink":"/documentation/PineTab2/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Dimensions: 37.5 x 40 x 11mm Weight: 38 grams IP Rating: IP67 (waterproof to 1 meter (sealed edition)) Display: Size: 1.3 inches (33mm) diagonal Type: IPS capacitive touchscreen, RGB 65K colors Display Controller: ST7789 Resolution: 240x240 pixels System on Chip: Nordic Semiconductor nRF52832 Flash: 512KB with additional 4MB SPI NOR RAM: 64KB Bluetooth: 5.0 (including Bluetooth Low Energy) Sensors: Accelerometer, Heart rate sensor Feedback: Vibration motor Battery: 170-180mAh 3.8V LiPo ","permalink":"/documentation/PineTime/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":"The PineVoice is a compact smart speaker based on the Bouffalo Lab BL606P RISC-V SoC. It is designed as a local voice assistant satellite, with Wi-Fi, Bluetooth, a speaker, a dual microphone array, buttons, and a center ring LED.\nSoC and memory PineVoice is based on the Bouffalo Lab BL606P.\nCPU architecture T-Head C906 480 MHz 64-bit RISC-V CPU:\nSupports RISC-V RV64IMAFCV instruction architecture Five-stage single-issue sequentially executed pipeline Level-1 instruction and data cache of Harvard architecture, with a size of 32 KiB and a cache line of 64 bytes Sv39 memory management unit Supports AXI 4.0 128-bit master interface Supports core local interrupt (CLINT) and platform-level interrupt controller (PLIC) Compatible with RISC-V PMP T-Head E907 320 MHz 32-bit RISC-V CPU:\nSupports RISC-V RV32IMAFCP instruction set Supports RISC-V 32-bit and 16-bit mixed instruction set Supports RISC-V machine mode and user mode Integer and floating-point pipelines Supports AXI 4.0 main device interface and AHB 5.0 peripheral interface 32 KiB instruction cache 16 KiB data cache T-Head E902 150 MHz 32-bit RISC-V CPU\nMemory and storage 32 MiB pSRAM 788 KiB SRAM 16 MiB flash storage Hardware features Wireless Wi-Fi 802.11 b/g/n Bluetooth 5.2 Dual-mode (BT+BLE) Audio Built-in speaker (tuned for voice applications) Dual microphone array Controls and indicators PineVoice buttons view\nButton controls Center LED ring and button Hardware mute button See Software for the current factory firmware button behavior and LED status colors.\nPower and connectivity USB-C power input and data channel Debug UART is exposed on unused USB-C pins Package contents USB-A to USB-C power cable Board information, schematics and certifications Module dimensions:\n65 mm x 65 mm x 66 mm Production version schematics:\nPineVoice MainBoard Schematic with component placement 20260311 PineVoice Bottom Board Schematic 20250921 Certifications:\nPineVoice CE Certificate PineVoice FCC Certificate Datasheets Bouffalo BL606P SoC information:\nBouffalo Lab BL606P SoC Datasheet Bouffalo Lab BL606P SoC Reference Manual (BL808 RM applies to BL606P as well) Bouffalo Lab BL606P SoC Product Brief SPI NOR flash information:\nGigaDevice 128 Mb XSPI-Flash Datasheet Winbond 128 Mb QSPI-Flash Datasheet ","permalink":"/documentation/PineVoice/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Based on Rockchip RK3566 CPU Architecture Quad-core ARM Cortex-A55@1.8GHz AArch32 for full backwards compatibility with ARMv7 ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation Includes VFP hardware to support single and double-precision operations ARMv8 Cryptography Extensions Integrated 32KB L1 instruction cache and 32KB L1 data cache per core 512KB unified system L3 cache TrustZone technology support 22nm process, believed to be FD-SOI GPU (Graphics Processing Unit) Capabilities Mali-G52 2EE Bifrost GPU@800MHz 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop 128KB L2 Cache configurations Supports OpenGL ES 1.1, 2.0, and 3.2 Supports Vulkan 1.0 and 1.1 Supports OpenCL 2.0 Full Profile Supports 1600 Mpix/s fill rate when at 800MHz clock frequency Supports 38.4 GLOP/s when at 800MHz clock frequency NPU (Neural Processing Unit) Capabilities Neural network acceleration engine with processing performance of up to 0.8 TOPS Supports integer 8 and integer 16 convolution operations Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet System Memory RAM Memory Variants: 2GB (SOQuartz only), 4GB, 8GB LPDDR4. Network 10/100/1000Mbps Ethernet Wi-Fi 802.11 b/g/n/ac with Bluetooth 5.0 (optional on model A, built in on model B) Storage microSD - bootable, supports SDHC and SDXC, storage up to 2TB USB Model A: 2 USB 2.0 host ports, 1 USB 2.0 OTG port, 1 USB 3.0 host port Model B: 1 USB 2.0 host port, 1 USB 2.0 OTG port, 1 USB 3.0 host port one native SATA 3.0 6Gb/s Port (only on model A, shared with USB 3.0 host port) (removed in newer revisions due to electrical signalling issues it caused) optional eMMC module from 8GB up to 128GB 64 Mbit (8 MByte) SPI flash (Model B only), part number 25Q64DWZPIG in the schematic eMMC Speeds On a 64 GB eMMC module:\n$ sudo hdparm -tT /dev/mmcblk1 /dev/mmcblk1: Timing cached reads: 2368 MB in 2.00 seconds = 1184.46 MB/sec Timing buffered disk reads: 452 MB in 3.01 seconds = 149.98 MB/sec Expansion Ports HDMI eDP - 4 lanes of 2.7Gbps, up to 2560x1600@60Hz (only on model A) DSI - Display Serial Interface, 4 lanes MiPi, up to 1440P on model A, 2 lanes MiPi, up to 1080p on model B CSI - CMOS Camera Interface, 4 lanes MiPi up to 8 mega pixel on model A, 2 lanes MiPi up to 5 mega pixel on model B TP - Touch Panel Port, SPI with interrupt on model A RTC - Real Time Clock Battery Connector VBAT - Lithium Battery Connector with temperature sensor input on model A Wi-Fi/BT Module Header - SDIO 3.0 and UART on model A, built-in Wi-Fi/BT Module on model B 2x20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header on model B, 2x10 pins GPO header on model A PCIe x4 open ended slot on model A, m.2 slot on model B, one Gen2 lane due to SoC constraints On Model A, the slot provides 10W of power for the 3.3V supply and however much power your 12V input power supply provides on the 12V supply The PCIe implementation on the RK3566 is much more compatible with a wide range of devices compared to the one on the RK3399 used on the ROCKPro64. This means a lot more devices should work (excluding dGPUs due to a lack of cache snooping ability).\nCombo PHYs Several of the I/O options on the RK3566 used in the Quartz64 are using the same I/O lines, meaning that they cannot be used at the same time. The above diagram illustrates how they are connected.\nIn particular, USB 3.0 and the SATA connector on the board are mutually exclusive, and the PCI-e 2.0 lane can be reconfigured into a second SATA port, though an adapter cable needs to be fashioned for this to be useful.\nGPIO Pins (Quartz64 Model A) Attention! GPIOs are 3.3V!\nAssigned To Pin no. Pin no. Assigned To 3.3 V 1 2 5 V I2C3_SDA_M0 a,b 3 4 5 V I2C3_SCL_M0 a,b 5 6 GND CPU_REFCLK_OUT 7 8 UART2_TX_M0_DEBUG GND 9 10 UART2_RX_M0_DEBUG SPI1_MOSI_M1 11 12 UART0_TX a SPI1_MISO_M1 13 14 UART0_RX a SPI1_CLK_M1 15 16 GND SPI1_CS0_M1 17 18 SPDIF_OUT c GND 19 20 3.3V Notes a: can be a PWM pin\nb: pulled high to 3.3V through 2.2kOhm resistor\nc: low-pass filtered with cutoff of 220 MHz\nSource: Page 28 of the board schematics.\nGPIO Pins (Quartz64 Model B) Attention! GPIOs are 3.3V!\nInteresting alternate pin configurations are listed in [brackets].\nAssigned To Pin no. Pin no. Assigned To 3.3 V 1 2 5 V [I2C3_SDA_M0] GPIO1_A0_3V3 3 4 5 V [I2C3_SCL_M0] GPIO1_A1_3V3 5 6 GND GPIO3_C4_3V3 7 8 UART2_TX GND 9 10 UART2_RX [SPI1_CS0_M1] GPIO3_A1_3V3 11 12 GPIO3_A3_3V3 [I2S3_SCLK_M0] [I2S3_MCLK_M0] GPIO3_A2_3V3 13 14 GND GPIO3_B0_3V3 15 16 GPIO3_B1_3V3 3.3V 17 18 GPIO3_B2_3V3 GPIO4_C3_3V3 19 20 GND GPIO4_C5_3V3 21 22 GPIO3_C1_3V3 [SPI1_MOSI_M1] GPIO4_C2_3V3 23 24 GPIO4_C6_3V3 GND 25 26 GPIO4_D1_3V3 I2C4_SDA_M0 27 28 I2C4_SCL_M0 GPIO3_B3_3V3 29 30 GND GPIO3_B4_3V3 31 32 GPIO3_C2_3V3 [SPI1_MISO_M1] [SPI1_CLK_M1] GPIO3_C3_3V3 33 34 GND [I2S3_LRCK_M0] GPIO3_A4_3V3 35 36 GPIO3_A7_3V3 [SPDIF_TX_M0] GPIO1_A4_3V3 37 38 GPIO3_A6_3V3 [I2S3_SDI_M0] GND 39 40 GPIO3_A5_3V3 [I2S3_SDO_M0] Source: Page 24 of the board schematics.\n","permalink":"/documentation/Quartz64/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":"Based on Rockchip RK3328\nCPU Architecture Quad-core Cortex-A53 up to 1.5GHz CPU Full implementation of the ARM architecture v8-A instruction set ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation ARMv8 Cryptography Extensions In-order pipeline with symmetric dual-issue of most instructions Unified system L2 cache Includes VFP v3 hardware to support single and double-precision operations Integrated 32KB L1 instruction cache, 32KB 4-way set associative L1 data cache TrustZone technology support Full CoreSight debug solution One separate power domain for CPU core system to support internal power switch, and to externally turn on/off based on different application scenario PD_A53: Cortex-A53 + Neon + FPU + L1 I/D Cache of core 2/3 One isolated voltage domain to support DVFS Frequencies \u0026amp; Voltages Frequency Voltage 408 MHz 0.950 V 600 MHz 0.950 V 816 MHz 1.000 V 1008 MHz 1.100 V 1200 MHz 1.225 V 1296 MHz 1.300 V Power Draw These numbers for power draw have been measured through an USB power monitor (FNB38) while running the stress utility, whereby \u0026ldquo;cpu\u0026rdquo; stands for stress --cpu 4 and \u0026ldquo;vm\u0026rdquo; stands for stress --vm 4. The former spins on the CPU, the latter stresses the memory. Real workloads are usually a mix of both. The tests were ran through ssh, with nothing besides power and ethernet plugged into the ROCK64\nPlease keep in mind that under real world usage, many other factors come into play. Having a display connected, running a graphical session, I/O and most importantly the connected USB peripherals can add a lot.\nHelpful refresher on the formula for power (W) on DC: power = current × voltage, because the power factor is 1. The ROCK64 runs on 5V, so use that to calculate current if you need to.\nFrequency Power cpu Power vm 1296 MHz 2.64 W 2.95 W 1200 MHz 2.32 W 2.69 W 1008 MHz 1.90 W 2.31 W 816 MHz 1.62 W 2.05 W 600 MHz 1.45 W 1.85 W 408 MHz 1.33 W 1.72 W It appears a good upper bound for a headless setup is in the neighbourhood of 3 W, or the energy contained in 0.025 bananas per hour.\nGPU Architecture ARM Mali-450MP2 Dual-core GPU OpenGL ES 1.1 and 2.0, OpenVG1.1 System Memory LPDDR3 RAM Memory Variants: 1GB, 2GB and 4GB. ","permalink":"/documentation/ROCK64/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Dimensions: 106mm x 106mm x 16.9mm Weight: 143 g CPU: Rockchip RK3328, Quad core Cortex-A53 @ up to 1.5GHz GPU: Mali-450MP2 System Memory: 1GB LPDDR3 Internal Storage: 8GB eMMC Connectivity: 802.11a/b/g/n, Ethernet 10/100 USB: 1x USB 2.0 OTG port, 1x USB 3.0 port Video Output: HDMI Standard HDMI 2.0a@60hz Audio Output: Via HDMI, Optical S/PDIF port Power Supply: DC 5V/2A ","permalink":"/documentation/RockBox/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Gigabit Ethernet HD Digital Video Out 2x USB 3.0 Host Euler Bus Expansion Bus PI-2 Bus PCIe 4X open-ended header Touch Panel Port (TP) Display Serial Interface (DSI) Port IR R/X Port Real Time Clock Port (RTC) Lithium Battery Port SMOS Sensor Interface Port Optional AC WiFi + BT 5.0 module expansion module Headphone Jack 5.5″ Barrel Power (12V 3A/5A) Port ","permalink":"/documentation/SOEDGE_Baseboard/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" Gigabit Ethernet eMMC module slot HD Digital Video Out 2x USB 2.0 Host Euler bus Expansion bus PI-2 bus Touch Panel Port (TP) Display Serial Interface (DSI) port IR R/X port Real Time Clock port (RTC) Lithium battery port SMOS sensor interface port Optional 802.11GBN + BT 4.0 module expansion module Headphone jack 3.5mm Barrel Power (5V 3A) port ","permalink":"/documentation/SOPINE_Baseboard/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":"The SOQuartz is based on the Rockchip RK3566.\nCPU Architecture Quad-core ARM Cortex-A55@1.8GHz AArch32 for full backwards compatibility with ARMv7 ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation Includes VFP hardware to support single and double-precision operations ARMv8 Cryptography Extensions Integrated 32KB L1 instruction cache and 32KB L1 data cache per core 512KB unified system L3 cache GPU (Graphics Processing Unit) Capabilities Mali-G52 2EE Bifrost GPU@800MHz 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop 128KB L2 Cache configurations Supports OpenGL ES 1.1, 2.0, and 3.2 Supports Vulkan 1.0 and 1.1 Supports OpenCL 2.0 Full Profile Supports 1600 Mpix/s fill rate when at 800MHz clock frequency Supports 38.4 GLOP/s when at 800MHz clock frequency Neural Process Unit NPU Capability Neural network acceleration engine with processing performance of up to 0.8 TOPS Supports integer 8 and integer 16 convolution operations Supports the following deep learning frameworks: TensorFlow, TF-lite, Pytorch, Caffe, ONNX, MXNet, Keras, Darknet System Memory RAM Memory Variants: 2GB, 4GB, 8GB LPDDR4. Storage Memory: optional 128Mb SPI Flash and optional eMMC module from 8GB up to 128GB Network 10/100/1000 Mbps Ethernet WiFi 802.11 b/g/n/ac with Bluetooth 5.0 Displays / Cameras 1x HDMI 2x DSI 1x eDP (Instead of HDMI1) 1x LVDS (not available when dual-mode DSI) 1x CSI 4-line Connectivity 1x Ethernet (1 Gbit) 1x USB 2.0 OTG 1x SD Card (SD) 1x PCIe 1-Line 28x GPIO (TBD) ","permalink":"/documentation/SOQuartz/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" The StarPro64\nThe StarPro64 backside\nSoC and Memory Specification Based on ESWIN EIC7700X EIC7700X block diagram\nCPU Architecture Quad-core P550 up to 1.8GHz CPU Fully compliant with the RISC-V RV64GBC ISA specification 64-bit RISC-V Application Core Features 13-stage, triple-issue, out-of-order pipeline 32KB L1 I-cache with ECC 32KB L1 D-cache with ECC Private 256KB L2 Cache Shared 4MB L3 Cache GPU Architecture Imagination Technology AXM-8-256 up to 600Mhz GPU Support OpenCL 3.0 Support OpenGL ES 3.x Support Vulkan 1.3 128-wide arithmetic logic unit (ALU) design Visually Lossless image compression – frame buffer compression and decompression (FBCDC) algorithm Lossless data compression – geometry compression, which is performed in the Geometry Processing phase of the 3D graphics workload Performance: 256 FP32 FLOPs/Clock, 1024 AI INT8/Clock NPU Architecture 19.95 TOPS(INT8), 9.975TOPS(FP16 or INT16) System Memory 32GB 64bits LPDDR5@6400MHz RAM Memory. Board Features Video Digital Video output up to 4K@60Hz H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4K×2K @ 60fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4K×2K @ 60fps Audio 3.5mm audio Jack Network Dual 10/100/1000Mbps Ethernet 2.4GHz/5Ghz MIMO WiFi 802.11 b/g/n/ac/ax with Bluetooth 5.3 Storage on-board 128Mbit (16MByte) XSPI NOR flash memory - bootable microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable (optional eMMC Module) 2× USB3.0 Dedicated Host port 2× USB2.0 Shared Host port Expansion Ports PCIe Gen3 ×4 lane 2×20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 4 lane MiPi DSI port for LCD panel 4 lane MiPi CSI port for camera module Board Information, Schematics and Certifications Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm×80mm×19mm\nInput Power: DC 12V @ 3-5A 5.5mmOD/2.1mmID center-positive Barrel DC Jack connector\nSchematic:\nStarPro64 Schematic 20250310 v2.0 (Production Released version) StarPro64 Component Reference location v2.0 (top layer) StarPro64 Component Reference location v2.0 (bottom layer) Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submits the SBC for FCC, CE, and ROHS certifications and obtain the certificates to prove that the SBC board can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Datasheets for Components and Peripherals ESWIN EIC7700X SoC information:\nESWIN EIC7700X SoC Product Brief ESWIN EIC7700X SoC Datasheet LPDDR5 (315 Balls) SDRAM:\nRayson LPDDR5 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nGigaDevice 128Mb XSPI-Flash Datasheet Ethernet related info:\nTBA WiFi/BT module info:\nAIC AIC8800D80 11AX Dual Band WiFi + Bluetooth5.3 Datasheet Bringup Notes Lup Yuen\u0026rsquo;s StarPro64 bring up article section 1-7 Boot DIP switches\u0026rsquo; labeling is the same as STAR64: \u0026ldquo;ON\u0026rdquo; means \u0026ldquo;0\u0026rdquo;. Boot DIP switch 1 represents the least significant bit in the table at page 14 of the schematic. ","permalink":"/documentation/StarPro64/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":" SoC and Memory Specification Based on Allwinner A527 Allwinner T527 A527 block diagram\nCPU Architecture Quad-core ARM Cortex-A55 at 2.0 GHz AArch32 for full backwards compatibility with ARMv7 ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation Includes VFP hardware to support single and double-precision operations ARMv8 Cryptography Extensions Integrated 32KB L1 instruction cache and 32KB L1 data cache per core Integrated 64KB L2 instruction cache and 128KB L2 data cache per cluster 1MB unified system L3 cache GPU Architecture Mali-G57 Valhall GPU@850MHz 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop 128KB L2 Cache configurations Supports OpenGL ES 1.1, 2.0, and 3.2 Supports Vulkan 1.1 Supports OpenCL 1.1, 1.2, 2.0 Full Profile Supports Renderscript L2 Cache Configurable 64KB – 512KB ** 64KB-128KB for 1-Core ** 128KB-256KB for 2-Core ** 256KB for 3-Core ** 1x256KB-2x256KB for 4-Core ** 2x256KB-2x512KB for 5-Core and 6-Core configurations Supports 3400 Mpix/s fill rate when at 850MHz clock frequency Supports 243.2 GLOP/s when at 850MHz clock frequency for peak single precision (FP32) performance System Memory LPDDR4 RAM Memory Variants: 2GB and 4GB. Board Features Video Digital Video output up to 4K@60Hz H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4K×2K @ 30fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4K×2K @ 60fps Audio 3.5mm audio Jack Network Dual 10/100/1000Mbps Ethernet 2.4GHz/5Ghz MIMO WiFi 802.11 b/g/n/ac with Bluetooth 5.2 Storage on-board 128Mbit (16MByte) XSPI NOR flash memory - bootable microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable on-board 16GB or 32GB Expansion Ports 2×20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header Avaota-A1 40 pin connector diagram\n4 lane MiPi DSI port for LCD panel 4 lane MiPi CSI port for camera module 1× USB3.0 OTG port 1× USB2.0 Host port 1× USB2.0 OTG port 1× CAN port ","permalink":"/documentation/Yuzuki_Avaota-A1/Further_information/Specifications/","tags":null,"title":"Specifications"},{"categories":null,"contents":"The Pinebook Pro comes equipped with two non-volatile storage components, the eMMC and the SPI. The capacity of the SPI is 128Mbit (16MiB) and it may be used in the boot process.\nBoot data can be written to the SPI via two methods: either from within PBP or from a second machine connected to the PBP by USB.\nWriting to SPI from within PBP Forum user pcm720 provided an example of writing to the SPI from within Linux in their self-published version of U-Boot that offers boot functionality for NVMe drives. It involves use of flash_erase command (available in the mtd-utils package on Arch/Manjaro) and the dd command.\nHowever, flashcp command should be used instead of dd, to make sure all specifics of the underlying flash memory are covered.\nWriting to SPI from a second machine Writing to the SPI from a second machine is more complicated than the other method, but it is the only option when troubleshooting an SPI flash gone wrong. This method works by bringing the RK3399 SoC into maskrom mode and issuing commands on the second machine that download the flash image onto the Pinebook Pro.\nUpon entering maskrom mode, the power LED on your Pinebook Pro won’t light up and neither will the display. Instead, your second machine, the one connected to your Pinebook Pro via USB, will indicate maskrom mode by logging to journalctl.\nThere are two ways to reach maskrom mode, but the first tends to be less reliable.\nMaskrom mode (unreliable method) Note The recovery button relies entirely on the software support in the boot loader, which makes it unreliable. According to Rockchip documentation, these steps should work; unfortunately, many users have reported them to be unsuccessful. You may need to repeat these steps several times for them to work.\nPress and hold recovery button. Short press reset. Release recovery button after about three seconds. In case this approach fails, please see the section below for a more reliable method.\nMaskrom mode (reliable method) Warning When removing the large RF shield found on the mainboard, to be able to short the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. Build and install rkdeveloptool (see project repository for instructions) Verify successful installation. Running rkdeveloptool --version should output: rkdeveloptool ver 1.3 Run journalctl -f and keep it running. Once the Pinebook Pro is connected and maskrom mode is reached it will produce additional output. Power off the Pinebook Pro. Unscrew the bottom cover. Remove the metal RF shield surrounding the main CPU. The shield is held in place small clamps on the board. The clamps can be released with a pry tool and some force. This forum post with photos shows how it can be done. Disconnect all boot devices, i.e. eMMC, microSD card and USB. Locate SPI flash (component number 29 on this photo of the Pinebook Pro internals). Connect your Pinebook Pro with USB-C to USB-A cable to second machine (Pinebook Pro on the USB-C side) Short pins CLK and VSS (see chip diagram to the right for the names of pins). This can be done with a pair of tweezers when short on tools. right\nPower on the Pinebook Pro. Press the reset button (component number 28). Check if there is new output from journalctl program. Check if the Pinebook Pro is connected by running rkdeveloptool ld. If successful, the output should be like: DevNo=1 Vid=0x2207,Pid=0x330c,LocationID=1401 Maskrom After entering maskrom mode Now that when the RK3399 SoC is in maskrom mode, you can use rkdeveloptool to write data to the SPI. To do so you’ll need the binary file you’ll be writing to SPI, which will be referred to as SPI_new.bin, and a helper file named rk3399_loader_spinor_v1.15.114.bin.\nFlash the flash helper db file: rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin. If successful, the output should read Downloading bootloader succeeded. Flash the new SPI binary: rkdeveloptool wl 0 SPI_new.bin. If successful, the output should read: Write LBA from file (100%). Test the installation: rkdeveloptool td. If successful, output should read Reset Device OK. Run rkdeveloptool rd to reboot your Pinebook Pro. Zeroing out the SPI In case, you wrote something bad to your SPI, it’s helpful to wipe away that data with zeros. To do that, you follow the same steps above to enter maskrom mode and then write a binary file that consists of all zeros.\nCreate the binary file dd if=/dev/zero of=zero.bin bs=1M count=16 Flash the flash helper db file: rkdeveloptool db rk3399_loader_spinor_v1.15.114.bin. If successful, the output should read Downloading bootloader succeeded. Flash the new SPI binary: rkdeveloptool wl 0 zero.bin. If successful, the output should read: Write LBA from file (100%). Test the installation: rkdeveloptool td. If successful, output should read Reset Device OK. Run rkdeveloptool rd to reboot your Pinebook Pro. ","permalink":"/documentation/Pinebook_Pro/Features/SPI/","tags":null,"title":"SPI"},{"categories":[""],"contents":" A star among the single-board computers The STAR64 Model A single-board computer features the StarFive JH-7110 SoC. This SoC combines a quad-core SiFive U74 RISC-V 64bit CPU with an IM BXE-4-32-G52-2EE GPU. It is equipped with 8GB LPDDR4 system memory, onboard 128Mb QSPI NOR Flash, an optional eMMC module (up to 128 GB) and a microSD slot for booting. The board is equipped with a dual band Wi-Fi and Bluetooth with a flex antenna, a PCIe x1 open ended slot, 1x USB 3.0 type A Host, 3x USB 2.0 Host, dual Gigabit Ethernet port, MiPi DSI interface, touch Panel interface, MiPi CSI interface, as well as many other peripheral device interface such as UART, SPI, I2C, for makers to integrate with sensors and other peripherals.\nThe Star64 is a new RISC-V platform that will serve PINE64 community for years to come.\nStores Global Global: Accessories Affiliates Documentation STAR64 Schematics and certifications ","permalink":"/devices/star64/","tags":null,"title":"STAR64"},{"categories":null,"contents":" The STAR64\nThe Star64 is a RISC-V based Single Board Computer powered by StarFive JH7110 Quad-Core SiFive U74 64-Bit CPU, Imagination Technology BX-4-32 GPU and supports up to 8GB 1866MHz LPDDR4 memory. It provides an eMMC module socket, MicroSD Card slot, PCI-e, Pi-2 Bus, USB 3.0, and many other peripheral interfaces for makers to integrate with sensors and other devices.\nSoftware The releases are still in alpha state and are only fit for testing purposes.\nApache NuttX RTOS Apache NuttX RTOS\nArmbian STAR64 on armbian.com. Read the Armbian forum thread on forum.pine64.org.\nDietPi Star64 image on dietpi.com, with Linux 6.1 based on StarFive VisionFive 2 kernel sources, rebased on latest mainline kernel, with Star64 support from Fishwaldo’s kernel sources and own configuration. The kernel sources can be found on the DietPi Star64 repository on GitHub.com.\nDownload:\nDirect image download Fishwaldo images A Set of Images built with Yocto for commandline, weston and plasma, see the project on GitHub.com.\nNotes:\nWhere possible, GPU/VPU acceleration is enabled. NixOS NixOS, based on the the nixos-hardware configuration\nBoard features Board layout Board map of connectors with schematic v1.1 identifiers:\nSTAR64 board layout\nFeatures The STAR64 board\nVideo Digital Video output up to 4K@30Hz 4K HDR @ 60fps H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4K×2K @ 60fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4K×2K @ 60fps Audio 3.5mm audio Jack Network Single or Dual 10/100/1000 bps Ethernet 2.4GHz/5Ghz MIMO WiFi 802.11 b/g/n/ac with Bluetooth 5.2 Storage on-board 128Mbit (16MByte) XSPI NOR flash memory - bootable microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable (optional eMMC Module) 1× USB3.0 Dedicated Host port 3× USB2.0 Host port Expansion Ports PCIe 2.0 ×1 lane 2×20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header The JH7110 SoC supports full multiplexing of its GPIO pins. This means any non-power/ground pin can be configured to any function outlined in Table 4-2 of the SoC datasheet. 4 lane MiPi DSI port for LCD panel 4 lane MiPi CSI port for camera module Pinout The STAR64 board pinout\nDevelopment Bringup notes\nPotential issues\nBringup notes The USB over-current protection is not wired up correctly to the USB ports on Star64. The default Starfive Kernel will disable USB on boot as it believes the ports are overcurrent. This ugly hack works around it: https://github.com/Fishwaldo/Star64_linux/commit/2634a13ecfa1fa5c232ec2b9f6a6b6b0d9d66898 The Wifi Chip (RTL8852BU) is not supported in the kernel. There is a Vendor Driver that is imported in the kernel at https://github.com/Fishwaldo/Star64_linux/tree/Star64_devel/drivers/staging/rtl8852bu but it really needs a cleanup. It does BUG_ON at boot, but wifi is confirmed working. HDMI can be finicky. 4K Monitors are known to have a issue. This is also relevant for VisionFive2 Some kernels/distributions do not detect the total memory correctly. This is due to the way u-boot is configured. Currently, u-boot reads the memory from the eeprom on the Star64, and updates the dtb file before booting the kernel. Distributions that boot differently may not get the updated dtb file with the correct memory entry. You can work around this by recompiling the DTB with the correct memory for your board VisionFive2 Kernels will only offer limited functionality on the Star64 - Mainly USB, Wifi and PCI will not work. The 4-pin 12 volt JST-XH-4A connector found on the Star64 is incompatible with the dual SATA power adapter intended for the ROCKPro64. The connector on the Star64 is rotated 180 degrees to the one on the ROCKPro64, resulting in the cable receiving +12V where GND is expected and vice versa. The cable’s internal circuitry ends up shorting in this configuration. Booting from uSD: Component S1804 is adjacent to the 40pin GPIO Bus; ignore the printed text on S1804 that says \u0026ldquo;ON\u0026rdquo; or \u0026ldquo;ONKE\u0026rdquo;. Do pay attention to the \u0026lsquo;1\u0026rsquo; and \u0026lsquo;2\u0026rsquo; printed on S1804. Also pay attention to the \u0026lsquo;L\u0026rsquo; and \u0026lsquo;H\u0026rsquo; text on the board next to S1804. The \u0026lsquo;L\u0026rsquo; stand for \u0026lsquo;0\u0026rsquo; and the \u0026lsquo;H\u0026rsquo; stands for \u0026lsquo;1\u0026rsquo;. You will need to flip switch \u0026lsquo;1\u0026rsquo; (GPIO_1) on S1804 to the \u0026lsquo;L\u0026rsquo; position and switch \u0026lsquo;2\u0026rsquo; (GPIO_0) on S1804 to the \u0026lsquo;H\u0026rsquo; position. S1804 maps to the table next to S1804 that has text [ [GPIO_1 | GPIO_0], [0|0] Flash, [0|1] SD, [1|0] EMMC, [1|1] UART ]; Helpful links: https://mrrcode979.github.io/blog/post/star64-guide/, https://www.bortzmeyer.org/star64-first-boot.html TTL use notes: Ground is on pin 6, RXD is on pin 8, and TXD is on pin 10. Prototype Bringup Notes Note This section is relevant to the original prototype (v1.0) that a few developers received. The schematic has several discrepancies with actual board labels.\nThe serial console can be found with TXD on pin 8 and RXD on pin 10; a convention common to Pi-style boards. Use the 40pin header pinouts in color on page one and not the schematic prose.\nIf you have only a single core running and no PCI card present, it appears to power up via the +5V/GND lines from the USB serial adapter pins.\nIt will not boot from a VisionFive R1 uSD card.\nThe boot device switch labels and the silk screen are inverted. \u0026ldquo;0\u0026rdquo; means \u0026ldquo;On\u0026rdquo;.\n2021.10-00001-gdbdaad919b will attempt to boot from SPI, but it appears blank. If you let it for many minutes, the device will eventually time out and boot OpenSBI v1.0 from (SPI?). This will fail, but only after self-identifying as a VisionFive R2, complete with five cores and 4 GB of RAM, before failing. A \u0026ldquo;press any key\u0026rdquo; timeout is offered, but I’ve been unable to make it stop. It will eventually crash with:\nLoading Environment from SPIFlash... SF: Detected gd25lq128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB *** Warning - bad CRC, using default environment Not a StarFive EEPROM data format - magic error Potential issues If you get the following error in U-Boot (or your 8 GB board is only detected as 4 GB) the possible cause is an empty or corrupted EEPROM:\nNot a StarFive EEPROM data format - magic error EEPROM dump: (0x100 bytes) 00: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 10: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 20: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 30: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 40: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 50: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 60: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 70: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 80: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF 90: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF A0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF B0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF C0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF D0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF E0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0: FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF To address this, execute the following commands from within U-Boot:\nmac initialize mac product_id \u0026lt;PRODUCTID\u0026gt; mac write_eeprom Set ProductID to either:\nFor 8 GB Models: STAR64V1-2310-D008E000-01234567 for 4 GB Models: STAR64V1-2310-D004E000-01234567 You can replace the last 8 digits with a random number if you wish.\nIf these commands fail, please join the #star64 channel in the Pine64 community for more assistance.\nLEDs The LEDs can be configured to stop blinking. Under Linux this can be done using the following command (as root):\necho \u0026#34;default-on\u0026#34; \u0026gt; /sys/devices/platform/leds/leds/blue-led/trigger To list possible other triggers for the blue LED:\ncat /sys/devices/platform/leds/leds/blue-led/trigger An example for a trigger is activity, where the the blue LED reflects the CPU activity.\nFurther information Datasheets\nSchematics and certifications\nSpecification\nDatasheets Star64 JH7110 SoC information:\nStarFive JH7110 SoC Product Brief StarFive JH7110 SoC Datasheet StarFive JH7110 SoC Technical Reference Manual X-Power PMU information:\nX-Power AXP15060 Datasheet V0.1 LPDDR4 (200 Balls) SDRAM:\nMicron LPDDR4 Mobile LPDDR4 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nGigaDevice 128Mb XSPI-Flash Datasheet Ethernet related info:\nTBA WiFi/BT module info:\nFn-Link 6252B 11AC Dual Band 2T2R WiFi + Bluetooth5.2 Datasheet Schematics and certifications Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm×80mm×19mm\nInput Power: DC 12V @ 3A 5.5mmOD/2.1mm ID center-positive Barrel DC Jack connector\nSchematic:\nSTAR64 Schematic 20230504 v1.1 (Production Released version) STAR64 Schematic 20220721 v1.0 (Prototype Board) Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submits the SBC for FCC, CE, and ROHS certifications and obtain the certificates to prove that the SBC board can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Specification Based on StarFive JH7110 CPU Architecture Quad-core U74 up to 1.5GHz CPU Fully compliant with the RISC-V ISA specification 64-bit RISC-V Application Core 32KB L1 I-cache with ECC 32KB L1 D-cache with ECC 8 Region Physical Memory Protection Virtual Memory support with up to 47 Physical Address bits Integrated up to 2MB L2 Cache with ECC includes RV64IMAC S7 monitor core, 16 KB L1 I-Cache with ECC, 8 KB DTIM with ECC 32-bit RISC-V CPU core (E24) for real time control, support RV32IMFC RISC-V ISA GPU Architecture Imagination Technology BXE-4-32 up to 600Mhz GPU Support OpenCL 3.0 Support OpenGL ES 3.2 Support Vulkan 1.2 Tile-based deferred rendering architecture for 3D graphics workloads, with concurrent processing of multiple tiles Support for GPU visualization, up to 8 virtual GPUs On fly frame buffer compression and decompression (TFBC) algorithm Performance: 128 FP32 FLOPs/Clock, 256 FP16 FLOPs/Clock System Memory LPDDR4 RAM Memory Variants: 2GB, 4GB and 8GB. ","permalink":"/documentation/STAR64/_full/","tags":null,"title":"STAR64 (Single Page)"},{"categories":["SBCs"],"contents":" The StarPro64 The StarPro64 is a RISC-V single-board computer from PINE64, featuring the EIC7700X SoC with a CPU speed of 1.8 GHz and NPU performance of 19.95 TOPS. It retains the model-A board format, similar to the Star64, with dual Ethernet ports, digital video output, USB 2.0 and 3.0 ports, a full GPIO header, and a 4x PCIe lane.\nAvailable in 8GB, 16GB, or 32GB LPDDR5 RAM configurations, the StarPro64 aims to be a gateway of a range of affordable RISC-V devices.\nStores Global Affiliates Documentation StarPro64 ","permalink":"/devices/starpro64/","tags":null,"title":"StarPro64"},{"categories":null,"contents":" The StarPro64 is a RISC-V based Single Board Computer powered by ESWIN EIC7700X Quad-Core SiFive P550 1.8GHz 64-Bit CPU, Imagination Technology AXM-8-256 GPU, 20TOPS NPU, and supports up to 32GB 64bit 6400MHz LPDDR5 memory. It provides an eMMC module socket, MicroSD Card slot, PCI-e, Pi-2 Bus, USB 3.0, and many other peripheral interfaces for makers to integrate with sensors and other devices.\nThe StarPro64\nSoftware The releases are still in alpha state and are only fit for development and testing purposes.\nNuttX NuttX, an Apache project, is a real-time operating system that prioritizes adherence to standards and maintains a compact size.\nRead StarPro64 EIC7700X RISC-V SBC: Maybe LLM on NPU on NuttX? by lupyuen.\nRockOS RockOS is a customized Debian distribution for the EIC770X by PLCT Lab.\nDownload: https://fast-mirror.isrc.ac.cn/rockos/images/generic/latest/\nMore information on this image SDK can be found at: https://github.com/rockos-riscv.\nALPHA-One This is the early test build that contains both 7b Deepseek and QWen2 LLM build, OS based on RockOS. The image for 32 GB eMMC modules and above. For larger than 32GB eMMC, please use gpart to extend the file partition.\nDownload:\nDirect download from PINE64 file server File information:\nMD5 (GZip file): 6669a436104e97e2ad90679e06f62d78 File Size: 18.21 GB User Password eswin eswin To explore LLM, use terminal program and execute below command lines:\nDeepSeek 7b LLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/deepseek_r1_distill_qwen_7b/config.json Qwen2 7bLLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/qwen2_7b/config.json Qwen2 0.5bLLM command:\n$ sudo /opt/eswin/sample-code/npu_sample/qwen_sample/bin/es_qwen2 /opt/eswin/sample-code/npu_sample/qwen_sample/src/qwen2_0_5b/config.json SDKs SDK document (some in Chinese): https://files.pine64.org/SDK/StarPro64/docs.7z (34 MB. MD5 checksum of the 7-Zip file is 8ee9b660c336d9979191d212e9826226)\nSTARPro64 Uboot and Linux Kernel Release:\n20250330: https://files.pine64.org/SDK/StarPro64/starpro64-sdk-20250330.7z (666 MB. MD5 checksum of the 7-Zip file is 12d44c21a990a64097611ba44eb3c56f) AI SDK Release 20250228: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250228.7z (1.932 GB. MD5 checksum of the 7-Zip file is f9171ec8b30e5d4d8eda1185f72af5e4) 20250330: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250330.7z (1.946 GB. MD5 checksum of the 7-Zip file is 8ddc861755ed26785e67674aad8db87c) 20250530: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250530.7z (1.897 GB. MD5 checksum of the 7-Zip file is 171a147448e42916dd06480f6b129c25) 20250630: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250630.7z (1.988 GB. MD5 checksum of the 7-Zip file is 00a91649522cebb94c29fea388c699e4) 20250730: https://files.pine64.org/SDK/StarPro64/EIC7x_AI_Release_20250730.7z (1.839 GB. MD5 checksum of the 7-Zip file is d0d839dde6b6f4ef8fa509e0fb4848d6) LLM and Neural Network tools release LLM 20250228: https://files.pine64.org/SDK/StarPro64/deepseek\u0026qwen-v0228.7z (722 MB. MD5 checksum of the 7-Zip file is b8ee72ee6a8912afefac3fa43a18be87) NN-Tools 20250228: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250228.7z (6.625 GB. MD5 checksum of the 7-Zip file is 868434b274412e173c3e264118dcb336) NN-Tools 20250330: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250330.7z (6.625 GB. MD5 checksum of the 7-Zip file is 39348ad2662cc72d12ef411cef2c756c) NN-Tools 20250530: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250530.7z (6.625 GB. MD5 checksum of the 7-Zip file is 5c1562cbaaa2772dbad9e0a9dd41c150) NN-Tools 20250630: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250630.7z (6.625 GB. MD5 checksum of the 7-Zip file is dbae3968126c23deed10d5e673aa10ad) NN-Tools 20250730: https://files.pine64.org/SDK/StarPro64/EIC7x_nn-tools_Release_20250730.7z (6.643 GB. MD5 checksum of the 7-Zip file is e32b6e1ce699fc05105371a7714979a4) Ollama Pack Based on 20250730 Release install whisper and ollama deb package 20250730 path: /ai_release/EIC7x_AI_Release_20250730 whisper reference: ftp: /share/2025-10-09/whisper/WHISPER_README.md after install ollama deb package，refer to /home/eswin/OLLAMA_README.md for operation manual Ollma Pack 20251009: https://files.pine64.org/SDK/StarPro64/StarPro64%20Ollam%20Pack%202025-10-09.7z (1.826 GB. MD5 checksum of the 7-Zip file is ad0093f121963978af41550790643ab4)\nPinout Specifications The StarPro64\nThe StarPro64 backside\nSoC and Memory Specification Based on ESWIN EIC7700X EIC7700X block diagram\nCPU Architecture Quad-core P550 up to 1.8GHz CPU Fully compliant with the RISC-V RV64GBC ISA specification 64-bit RISC-V Application Core Features 13-stage, triple-issue, out-of-order pipeline 32KB L1 I-cache with ECC 32KB L1 D-cache with ECC Private 256KB L2 Cache Shared 4MB L3 Cache GPU Architecture Imagination Technology AXM-8-256 up to 600Mhz GPU Support OpenCL 3.0 Support OpenGL ES 3.x Support Vulkan 1.3 128-wide arithmetic logic unit (ALU) design Visually Lossless image compression – frame buffer compression and decompression (FBCDC) algorithm Lossless data compression – geometry compression, which is performed in the Geometry Processing phase of the 3D graphics workload Performance: 256 FP32 FLOPs/Clock, 1024 AI INT8/Clock NPU Architecture 19.95 TOPS(INT8), 9.975TOPS(FP16 or INT16) System Memory 32GB 64bits LPDDR5@6400MHz RAM Memory. Board Features Video Digital Video output up to 4K@60Hz H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4K×2K @ 60fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4K×2K @ 60fps Audio 3.5mm audio Jack Network Dual 10/100/1000Mbps Ethernet 2.4GHz/5Ghz MIMO WiFi 802.11 b/g/n/ac/ax with Bluetooth 5.3 Storage on-board 128Mbit (16MByte) XSPI NOR flash memory - bootable microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable (optional eMMC Module) 2× USB3.0 Dedicated Host port 2× USB2.0 Shared Host port Expansion Ports PCIe Gen3 ×4 lane 2×20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 4 lane MiPi DSI port for LCD panel 4 lane MiPi CSI port for camera module Board Information, Schematics and Certifications Model \u0026ldquo;A\u0026rdquo; Baseboard Dimensions: 133mm×80mm×19mm\nInput Power: DC 12V @ 3-5A 5.5mmOD/2.1mmID center-positive Barrel DC Jack connector\nSchematic:\nStarPro64 Schematic 20250310 v2.0 (Production Released version) StarPro64 Component Reference location v2.0 (top layer) StarPro64 Component Reference location v2.0 (bottom layer) Certifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submits the SBC for FCC, CE, and ROHS certifications and obtain the certificates to prove that the SBC board can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Datasheets for Components and Peripherals ESWIN EIC7700X SoC information:\nESWIN EIC7700X SoC Product Brief ESWIN EIC7700X SoC Datasheet LPDDR5 (315 Balls) SDRAM:\nRayson LPDDR5 Datasheet eMMC information:\nPINE64 eMMC module schematic PINE64 USB adapter for eMMC module V2 schematic PINE64 USB adapter for eMMC module PCB in JPEG 16GB Foresee eMMC Datasheet 32GB/64GB/128GB SanDisk eMMC Datasheet SPI NOR Flash information:\nGigaDevice 128Mb XSPI-Flash Datasheet Ethernet related info:\nTBA WiFi/BT module info:\nAIC AIC8800D80 11AX Dual Band WiFi + Bluetooth5.3 Datasheet Bringup Notes Lup Yuen\u0026rsquo;s StarPro64 bring up article section 1-7 Boot DIP switches\u0026rsquo; labeling is the same as STAR64: \u0026ldquo;ON\u0026rdquo; means \u0026ldquo;0\u0026rdquo;. Boot DIP switch 1 represents the least significant bit in the table at page 14 of the schematic. Cases The table below collect known information about casing and enclosure compatibility for the StarPro64 SBC:\nCase Compatible Notes ROCKPro64 PREMIUM ALUMINUM CASING No StarPro64 has two stacked ethernet ports, making it too tall. Model A Acrylic Open Enclosure Partial The screw closer to the LEDs and the one closer to the dip switches touch some components, potentially shorting or damaging them. Screw with a smaller head might work. ","permalink":"/documentation/StarPro64/_full/","tags":null,"title":"StarPro64 (Single Page)"},{"categories":null,"contents":" microSD - bootable, support SDHC and SDXC, storage up to 256GB USB -\t2 USB2.0 Host port ","permalink":"/documentation/SOEDGE_Baseboard/Features/Storage/","tags":null,"title":"Storage"},{"categories":null,"contents":"This page is about the community project to add straps to the PineBuds Pro.\nStrap for buds Although PineBuds Pro, \u0026ldquo;true wireless\u0026rdquo;, earbuds are comfortably light and stay in ears better than wired ones (when nothing tug them from your ear), they can still did it, for example, during sports. Because they are completely non-wired, it also means that they will then drop directly to the ground and may break. That’s why it might make sense to use a strap like this in sports. We are trying make strap for PineBuds Pro.\nStrap with 3.5mm AUX connector Each bud has pins through which is UART connection. When we find or make a strap for PineBuds Pro we can add wiring inside it and put PCB in the middle that receives analog signal with the 3.5mm AUX connector and feeds it to the buds.\n","permalink":"/documentation/PineBuds_Pro/Community_projects/Straps/","tags":null,"title":"Straps"},{"categories":null,"contents":"In this section we document a variety of ways to stream video to the network from the PineCube. Unless specified otherwise, all of these examples have been tested on Ubuntu groovy (20.10). See this small project for the PineCube for easy to use programs tuned for the PineCube.\nIn the examples which use h264, we are currently encoding using the x264 library which is not very fast on this CPU. The SoC in the PineCube does have a hardware h264 encoder, which the authors of these examples have so far not tried to use. It appears that https://github.com/gtalusan/gst-plugin-cedar might provide easy access to it, however. Please update this wiki if you find out how to use the hardware encoder!\ngstreamer: h264 HLS HLS (HTTP Live Streaming) has the advantage that it is easy to play in any modern web browser, including Android and iPhone devices, and that it is easy to put an HTTP caching proxy in front of it to scale to many viewers. It has the disadvantages of adding (at minimum) several seconds of latency, and of requiring an h264 encoder (which we have in hardware, but haven’t figured out how to use yet, so, we’re stuck with the slow software one).\nHLS segments a video stream into small chunks which are stored as .ts (MPEG Transport Stream) files, and (re)writes a playlist.m3u8 file which clients constantly refresh to discover which .ts files they should download. We use a tmpfs file system to avoid needing to write these files to the microSD card in the PineCube. Besides the program which writes the .ts and .m3u8 files (gst-launch-1.0, in our case), we’ll also need a very basic web page in tmpfs and a webserver to serve the files.\nCreate an hls directory to be shared in the existing tmpfs file system that is mounted at /dev/shm:\nmkdir /dev/shm/hls/\nCreate an index.html and optionally a favicon.ico or even a set of icons, and then put the files into the /dev/shm/hls directory. An example index.html that works is available in the Getting Started section of the README for hls.js. We recommend downloading the hls.js file and editing the example index.html to serve your local copy of it instead of fetching it from a CDN. This file provides HLS playback capabilities in browsers which don’t natively support it (which is most browsers aside from the iPhone).\nIn one terminal, run the camera capture pipeline:\ncd /dev/shm/hls/ \u0026amp;\u0026amp; media-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:UYVY8_2X8/240x320@1/15]\u0026#39; \u0026amp;\u0026amp; gst-launch-1.0 v4l2src ! video/x-raw,width=320,height=240,format=UYVY,framerate=15/1 ! decodebin ! videoconvert ! video/x-raw,format=I420 ! clockoverlay ! timeoverlay valignment=bottom ! x264enc speed-preset=ultrafast tune=zerolatency ! mpegtsmux ! hlssink target-duration=1 playlist-length=2 max-files=3 Alternatively it is possible to capture at a higher resolution:\nmedia-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:UYVY8_2X8/1920x1080@1/15]\u0026#39; cd /dev/shm/hls/ \u0026amp;\u0026amp; gst-launch-1.0 v4l2src ! video/x-raw,width=1920,height=1080,format=UYVY,framerate=15/1 ! decodebin ! videoconvert ! video/x-raw,format=I420 ! clockoverlay ! timeoverlay valignment=bottom ! x264enc speed-preset=ultrafast tune=zerolatency ! mpegtsmux ! hlssink target-duration=1 playlist-length=2 max-files=3 In another, run a simple single threaded webserver which will serve html, javascript, and HLS to web clients:\ncd /dev/shm/hls/ \u0026amp;\u0026amp; python3 -m http.server Alternately, install a more efficient web server (apt install nginx) and set the server root for the default configuration to be /dev/shm/hls. This will run on port 80 rather than the python3 server which defaults to port 8000.\nIt should be possible to view the HLS stream directly in a web browser by visiting http://pinecube:8000/ if pinecube is the correct hostname and the name correctly resolves.\nYou can also view the HLS stream with VLC: vlc http://pinecube:8000/playlist.m3u8\nOr with gst-play-1.0: gst-play-1.0 http://pinecube:8000/playlist.m3u8 (or with mpv, ffplay, etc)\nTo find out about other options you can configure in the hlssink gstreamer element, you can run gst-inspect-1.0 hlssink.\nIt is worth noting here that the hlssink element in GStreamer is not widely used in production environments. It is handy for testing, but for real-world free-software HLS live streaming deployments the standard tool today (January 2021) is nginx’s RTMP module which can be used with ffmpeg to produce \u0026ldquo;adaptive streams\u0026rdquo; which are re-encoded at varying quality levels. You can send data to an nginx-rtmp server from a gstreamer pipeline using the rtmpsink element. It is also worth noting that gstreamer has a new hlssink2 element which we have not tested; perhaps in the future it will even have a webserver!\nv4l2rtspserver: h264 RTSP Install dependencies:\napt install -y cmake gstreamer1.0-plugins-bad gstreamer1.0-tools \\ gstreamer1.0-plugins-good v4l-utils gstreamer1.0-alsa alsa-utils libpango1.0-0 \\ libpango1.0-dev gstreamer1.0-plugins-base gstreamer1.0-x x264 \\ gstreamer1.0-plugins-{good,bad,ugly} liblivemedia-dev liblog4cpp5-dev \\ libasound2-dev vlc libssl-dev iotop libasound2-dev liblog4cpp5-dev \\ liblivemedia-dev autoconf automake libtool v4l2loopback-dkms liblog4cpp5-dev \\ libvpx-dev libx264-dev libjpeg-dev libx265-dev linux-headers-dev-sunxi; Install kernel source and build v4l2loopback module:\napt install linux-source-5.11.3-dev-sunxi64 #Adjust kernel version number to match current installation with \u0026#34;uname -r\u0026#34; cd /usr/src/v4l2loopback-0.12.3; make \u0026amp;\u0026amp; make install \u0026amp;\u0026amp; depmod -a Build required v4l2 software:\ngit clone --recursive https://github.com/mpromonet/v4l2tools \u0026amp;\u0026amp; cd v4l2tools \u0026amp;\u0026amp; make \u0026amp;\u0026amp; make install; git clone --recursive https://github.com/mpromonet/v4l2rtspserver \u0026amp;\u0026amp; cd v4l2rtspserver \u0026amp;\u0026amp; cmake -D LIVE555URL=https://download.videolan.org/pub/contrib/live555/live.2020.08.19.tar.gz . \u0026amp;\u0026amp; make \u0026amp;\u0026amp; make install; Running the camera:\nmedia-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:UYVY8_2X8/640x480@1/30]\u0026#39;; modprobe v4l2loopback video_nr=10 debug=2; v4l2compress -fH264 -w -vv /dev/video0 /dev/video10 \u0026amp; v4l2rtspserver -v -S -W 640 -H 480 -F 10 -b /usr/local/share/v4l2rtspserver/ /dev/video10 Note that you might get an error when running media-ctl indicating that the resource is busy. This could be because of the motion program that runs on the stock OS installation. Check and terminate any running /usr/bin/motion processes before running the above steps.\nThe v4l2compress/v4l2rtspserver method of streaming the camera uses around ~45-50% of the CPU for compression of the stream into H264 (640x480@7fps) and around 1-2% of the CPU for serving the HLS stream. Total system RAM used is roughly 64MB and the load average is ~0.4-~0.5 when idle, and ~0.51-~0.60 with one HLS client streaming the camera.\nYou’ll probably see about a 2-3s lag with this approach, possibly due to the H264 compression and the lack of hardware acceleration at the moment.\ngstreamer: JPEG RTSP GStreamer’s RTSP server isn’t an element you can use with gst-launch, but rather a library. We failed to build its example program, so instead used this very small 3rd party tool which is based on it: https://github.com/sfalexrog/gst-rtsp-launch/\nAfter building gst-rtsp-launch (which is relatively simple on Ubuntu groovy; just apt install libgstreamer1.0-dev libgstrtspserver-1.0-dev first), you can read JPEG data directly from the camera and stream it via RTSP: media-ctl --set-v4l2 '\u0026quot;ov5640 1-003c\u0026quot;:0[fmt:JPEG_1X8/1280x720]' \u0026amp;\u0026amp; gst-rtsp-launch 'v4l2src ! image/jpeg,width=1280,height=720 ! rtpjpegpay name=pay0'\nThis stream can be played using vlc rtsp://pinecube.local:8554/video or mpv, ffmpeg, gst-play-1.0, etc. If you increase the resolution to 1920x1080, mpv and gst-play can still play it, but VLC will complain The total received frame size exceeds the client’s buffer size (2000000). 73602 bytes of trailing data will be dropped! if you don’t tell it to increase its buffer size with --rtsp-frame-buffer-size=300000\ngstreamer: h264 RTSP Left as an exercise to the reader (please update the wiki). Hint: involves bits from the HLS and the JPEG RTSP examples above, but needs a rtph264pay name=pay0 element.\ngstreamer: JPEG RTP UDP Configure camera: media-ctl --set-v4l2 '\u0026quot;ov5640 1-003c\u0026quot;:0[fmt:JPEG_1X8/1920x1080]'\nTransmit with: gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! rtpjpegpay name=pay0 ! udpsink host=$client_ip port=8000\nReceive with: gst-launch-1.0 udpsrc port=8000 ! application/x-rtp, encoding-name=JPEG,payload=26 ! rtpjpegdepay ! jpegdec ! autovideosink\nNote that the sender must specify the recipient’s IP address in place of $client_ip; this can actually be a multicast address allowing for many receivers! (You’ll need to specify a valid multicast address in the receivers\u0026rsquo; pipeline also; see gst-inspect-1.0 udpsrc and gst-inspect-1.0 udpsink for details.)\ngstreamer: JPEG RTP TCP Configure camera: media-ctl --set-v4l2 '\u0026quot;ov5640 1-003c\u0026quot;:0[fmt:JPEG_1X8/1920x1080]'\nTransmit with: gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! rtpjpegpay name=pay0 ! rtpstreampay ! tcpserversink host=0.0.0.0 port=1234\nReceive with: gst-launch-1.0 tcpclientsrc host=pinecube.local port=1234 ! application/x-rtp-stream,encoding-name=JPEG ! rtpstreamdepay ! application/x-rtp, media=video, encoding-name=JPEG ! rtpjpegdepay ! jpegdec ! autovideosink\ngstreamer and socat: MJPEG HTTP server This rather ridiculous method uses bash, socat, and gstreamer to implement an HTTP-ish server which will serve your video as an MJPEG stream which is playable in browsers.\nThis approach has the advantage of being relatively low latency (under a second), browser-compatible, and not needing to reencode anything on the CPU (it gets JPEG data from the camera itself). Compared to HLS, it has the disadvantages that MJPEG requires more bandwidth than h264 for similar quality, pause and seek are not possible, stalled connections cannot jump ahead when they are unstalled, and, in the case of this primitive implementation, it only supports one viewer at a time (Though the RTSP examples on this page perform very poorly with multiple viewers).\nGstreamer can almost do this by itself, as it has a multipartmux element which produces the headers which precede each frame. But sadly, despite various forum posts lamenting the lack of one over the last 12+ years, as of the end of the 50th year of the UNIX era (aka 2020), somehow nobody has yet gotten a webserver element merged in to gstreamer (which is necessary to produce the HTTP response, which is required for browsers other than firefox to play it). So, here is an absolutely minimal \u0026ldquo;webserver\u0026rdquo; which will get MJPEG displaying in a (single) browser.\nCreate a file called mjpeg-response.sh:\n#! /bin/bash media-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:JPEG_1X8/1920x1080]\u0026#39; b=\u0026#34;--duct_tape_boundary\u0026#34; echo -en \u0026#34;HTTP/1.1 200 OK\\r\\nContent-type: multipart/x-mixed-replace;boundary=$b\\r\\n\\r\\n\u0026#34; gst-launch-1.0 v4l2src ! image/jpeg,width=1920,height=1080 ! multipartmux boundary=$b ! fdsink fd=2 2\u0026gt;\u0026amp;1 \u0026gt;/dev/null Make it executable: chmod +x mjpeg-response.sh\nRun the server: socat TCP-LISTEN:8080,reuseaddr,fork EXEC:./mjpeg-response.sh\nAnd browse to http://pinecube.local:8080/ in your browser.\nvirtual web camera: gstreamer, mjpeg, udp rtp unicast It’s possible to set up the PineCube as a virtual camera video device (Video 4 Linux) so that you can use it with video conferencing software, such as Jitsi Meet. Note that this has fairly minimal (\u0026lt;1s) lag when tested on a wired 1Gb Ethernet network connection and the frame rate is passable. MJPEG is very wasteful in terms of network resources, so this is something to keep in mind. The following instructions assume Debian Linux (Bullseye) as your desktop machine, but could work with other Linux distributions too. It’s possible that someday a similar system could work with Mac OS X provided that someone writes a gstreamer plugin that exposes a Mac OS Core Media DAL device as a virtual webcam, like they did here for OBS.\nFirst, you will need to set up the pinecube with gstreamer much like the above gstreamer, but in 1280x720 resolution. Also, you will be streaming to the desktop machine using UDP, with IP address represented by $desktop below at UDP port 8000.\nmedia-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:JPEG_1X8/1280x720]\u0026#39; gst-launch-1.0 v4l2src device=/dev/video0 ! image/jpeg,width=1280,height=720,framerate=30/1 ! rtpjpegpay name=pay0 ! udpsink host=$desktop port=8000 On your desktop machine, you will need to install the gstreamer suite and the special v4l2loopback kernel module to bring the mjpeg stream to the Video 4 Linux device /dev/video10.\nsudo apt install gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-plugins-bad gstreamer1.0-plugins-ugly v4l2loopback-dkms sudo modprobe v4l2loopback video_nr=10 max_buffers=32 exclusive_caps=1 # Creates /dev/video10 as a virtual v4l2 device, allocates increased buffers and exposes exclusive capabilities for chromium to find the video device gst-launch-1.0 udpsrc port=8000 ! application/x-rtp, encoding-name=JPEG,payload=26,framerate=30/1 ! rtpjpegdepay ! jpegdec ! video/x-raw, format=I420, width=1280, height=720 ! autovideoconvert ! v4l2sink device=/dev/video10 The most common error found when launching the gstreamer pipeline above is the following error message, which seems to happen when the max_buffers aren’t set on the v4l2loopback module (see above), or if there is a v4l client (vlc, chromium) already connected to /dev/video10 when starting the pipeline. There does seem to be a small level of instability in this stack that could be improved.\ngstbasesrc.c(3055): gst_base_src_loop (): /GstPipeline:pipeline0/GstUDPSrc:udpsrc0: streaming stopped, reason not-negotiated (-4) Now that you have /dev/video10 hooked into the gstreamer pipeline you can then connect to it using VLC. VLC is a good local test that things are working. You can view the stream like this. Note that you could do the same thing with mpv/ffmpeg, but there are problems currently.\nvlc v4l2:///dev/video10 Be sure to disconnect VLC before trying to use the virtual web camera with chromium. Launch chromium and go to a web conference like jitsi. When it prompts you for the camera pick the \u0026ldquo;Dummy Video Device\u0026hellip;\u0026rdquo; and it should be much like what you see in VLC. Note that Firefox isn’t really working at this moment and the symptoms appear very similar to the problem with mpv/ffmpeg mentioned above, ie. when they connect to the camera they show only the first frame and then drop. It’s unclear whether the bug is in gstreamer, v4l, or ffmpeg (or somewhere in these instructions).\n","permalink":"/documentation/PineCube/Projects/Streaming_the_camera_to_the_network/","tags":null,"title":"Streaming the camera to the network"},{"categories":null,"contents":" Important Contribute to it by looking for MIPI-DSI panels in drivers/gpu/drm/panel/ and filling out the table from their data sheets MIPI-DSI Displays MIPI-DSI Displays are displays that follow the MIPI-DSI standard. Such displays can be connected to various PINE64 Single Board Computers.\nMIPI Channels and Lanes The MIPI Lanes number is given in a format of channels×lanes. Before buying one, make sure that your SBC has enough channels and lanes to drive the display!\nROCKPro64: 2×4 Quartz64 Model A: 1×4 Quartz64 Model B: 1×2 SOQuartz: 1×4 + 1×2 Displays With Mainline Drivers These displays have free and open-source drivers in the main Linux kernel tree.\nManufacturer Part Number Size Resolution Panel Technology MIPI Lanes Feiyang FY07024DI26A30-D 7.0\u0026quot; data-sort-value=\u0026ldquo;614400\u0026rdquo; 1024×600 TN? data-sort-value=\u0026ldquo;4\u0026rdquo; 1×4 Sharp LQ101R1SX01 10.1\u0026quot; data-sort-value=\u0026ldquo;4096000\u0026rdquo; 2560×1600 TN? data-sort-value=\u0026ldquo;8\u0026rdquo; 2×4 Sharp LS060T1SX01 6.0\u0026quot; data-sort-value=\u0026ldquo;2073600\u0026rdquo; 1080×1920 ? data-sort-value=\u0026ldquo;4\u0026rdquo; 1×4 LVDS Displays LVDS Displays are displays that follow the LVDS standard.\nLVDS Hardware Support Only Quartz64 Model A seems to support LVDS panels.\nDisplays and Timings TBD\n","permalink":"/documentation/Unsorted/Supported_displays/","tags":null,"title":"Supported Displays"},{"categories":null,"contents":"This page explains how to read the thermal sensor data, and how to read and change the default settings.\nUnder Linux Warning Setting wrong values for the thermal trip points poses a risk. These instructions are directed towards expert-level users and developers. Thermal management of the PinePhone CPU is handled by the thermal framework of the Linux kernel. Depending on the Linux distribution used on a PinePhone, the default settings may differ. It may be advised to lower the settings (i.e. the thermal trip point temperatures) to prevent the phone components from being damaged by excessive heat.\nCurrent CPU temperature can be displayed using the following command:\ncat /sys/class/thermal/thermal_zone0/temp The unit for all numeric values is millidegree Celsius. To read the thermal trip point types and current trip point temperatures, use the following:\ngrep . /sys/class/thermal/thermal_zone0/trip_point_*_temp grep . /sys/class/thermal/thermal_zone0/trip_point_*_type The default trip point temperatures are also available in the A64 device tree. The possible names and associated meanings for the trip point types are the following:\n\u0026ldquo;active\u0026rdquo; – a trip point to enable active cooling \u0026ldquo;passive\u0026rdquo; – a trip point to enable passive cooling \u0026ldquo;hot\u0026rdquo; – a trip point to notify emergency \u0026ldquo;critical\u0026rdquo; – hardware not reliable The values for the trip point temperatures can be lowered individually, but make sure the trip points have the correct value for their corresponding trip type, e.g. don’t simply swap the values for the first and the second trip point. Make sure not to set values higher than 110000 (i.e. 110 degrees Celsius, which is the default value) for the third threshold, as it may cause damage to the phone. Use the following commands:\necho 55000 \u0026gt; /sys/class/thermal/thermal_zone0/trip_point_0_temp # passive echo 75000 \u0026gt; /sys/class/thermal/thermal_zone0/trip_point_1_temp # hot echo 100000 \u0026gt; /sys/class/thermal/thermal_zone0/trip_point_2_temp # critical Further information can be found in these documents from the Linux kenel source:\nDocumentation/thermal/sysfs-api.txt Documentation/hwmon/sysfs-interface Documentation/devicetree/bindings/thermal/thermal.txt ","permalink":"/documentation/PinePhone/Software_tricks/Thermal_tweaks/","tags":null,"title":"Thermal tweaks"},{"categories":null,"contents":"This article is about the available tips for the Pinecil and how they work.\nPinecil Tips Tip Pay attention to the length! Pine Store sells two different lengths of tips. What kind of tips work? Pinecil V2 uses both Pine64 designed Short Tips (ST line, 6.2-6.5 Ω) and TS-100 Normal length compatible tips (TS line, ~8.0 Ω). Presently, the V1 uses the normal length TS100 style tips (~8.0 ohms) until a firmware update enables manually switching the tip types. Check Github Ralim’s IronOS here for progress on this. Unplug before swapping tips as the V2 automatically detects the tip resistance at boot-up and it is safer. How to increase tip life? Typically, lead solder uses a working temperature of ~300°C-320°C and no-lead solder ~350°C-365°C (check the temperature charts in the soldering guides or google it for your specific solder type, it varies). Always start lower than needed and increase ~5°C at a time until you reach a good working temperature. If you want your tips to last longer, use the lowest temperatures you can comfortably work at. Thicker wires, etc., may need more (adjust). The open source firmware may allow the use of temperatures past the manufacturer limit for tips, but that doesn’t mean you should. That said, people have reported using the boost feature at 5-15 second burst to \u0026gt;430°C and have been perfectly fine (TS100 and Pine64 tips are readily available at reasonable prices and some people prefer convenience of higher temperatures and accept they might replace tips more frequently as a trade-off). If the tips are not too expensive, some keep spare tips and boost to high temperatures freely for convenience, and simply replace the tip when it loses the plating or the tip fails (common sign of tip failure is tip plating is gone, has pit holes, or a multimeter measures OL infinite ohms across the 2 silver contacts on the cold end of the tip). Check out this Soldering Guide article for more details on best practices for use and maintenance of tips. How to check new tips? Short Tip 6.2 Ω\nRemove the screw on top, then remove the cartridge. Clean new cartridges/tips with isopropyl alcohol (IPA) to remove any factory residue before installing (avoid strange behavior). If you have no IPA, use a dry clean towel, especially the white end with the two silver contacts (do not use water; it could get into the seam line on the white end). This often resolves issues with glitchy temperatures or random no-tip symbol from poor or dirty electric contact [reference]https://github.com/Ralim/IronOS/issues/1601). Clean contacts with IPA\n. Then install the cartridge/tip, re-install the screw on top, and heat the tip a few times to 350 °C for a couple minutes. . If you don’t have a multimeter, then after you initially heat the tips a few times to 350 °C. Then change the temperature to the correct range for the solder you purchased and check if it melts solder (add a little solder to the tip end also before storing it). . If you have a multimeter (dmm) and have an issue with the cartridge/tip, then you can measure when the tip is cold (room temperature and unused a couple hours). Set dmm to ohms and the correct range, and measure the 2 silver contacts on the rear white end. . Warning: warm tips change the measurements (measure only when cold and unused for a couple hours).\nShort tips could be ~6.2-6.5 ohms Normal length tips could be ~7.8-8.3 ohms If the tip measures OL (open loop) it is defective. Also a tip that is way off spec, e.g., 10 ohm will cause strange behavior on temperature readings. If you measure when it’s even a little warm, the ohms will be much higher; this is normal and how the cartridge/tip works. Why have different tips? See the Soldering Guides for usage of different tips and how to keep tips clean. How does the tip work? A thermocouple is integrated into the end of the tip itself; advantage is every new tip includes a brand new thermocouple and it’s a more accurate measurement of the temperature. Pinecil tips are considered newer tech style. This is more accurate compared to older style Irons where the thermocouple is in the handle and much farther from the end of the tip. Science: what is a thermocouple? How is Tip Temperature measured in Ralim’s IronOS firmware? What does the inside of a ts100 tip look like? Pine Store Tip Options I. Short tips Important Pay attention to the length in your cart! Pine Store sells two different lengths. All new Pinecil V2 soldering irons include a single Pine64 newly designed Short tip (ST-B2 conical). The discontinued V1 came with a longer normal length TS-B2 conical tip. Pine Store carries 4-Packs of Pine64 designed Short Tips (only Pine64 makes the short style presently) Short tips Fine link, white box (~6.2-6.5 Ω) Short tips Gross link, white box (~6.2-6.5 Ω) Pine64 Short tip packs are lower resistance/ohms which means higher performance and better ergonomics. Many professional irons have shorter tips for more control while soldering. Note Older Pinecil V1 can not use the short tips until firmware code is written to enable manual selection of 6.2 Ω or 8.0 Ω tip. Only the V2 model has the hardware to auto-detect the two kinds of tips short 6.2 Ω or regular length 8.0 Ω. If you would like to help with the code, see GitHub/IronOS. Short gross set, white box\nShort fine set, white box\nST-B2 conical short tip included with the V2 Pinecil\nThe shorter tip is designed for higher performance and requires more power than longer traditional TS100 tips\nRecommend using minimum of usb-C PD65W-3.25A-20V or higher voltage charger when using Short tips (short tip draws more power than longer tips because of the lower ohms).\nFor example with a PD65W-20V charger, the maximum watts with a standard 8 ohm tip is 50W, whereas the max watt with a 6.2 ohm tip is ~64 watts (watts/volts calculator).\nHeating formula: P = IV = I^2 * R = V^2 / R (⇧ watts = ⇧ faster heating)\n20V @8Ω tip=50W; @6.2Ω tip=64.5W 24V @8Ω tip=72W; @6.2Ω tip=92.9W II. Normal tips Important Pay attention to the length! Pine Store sells two different lengths. Normal Length Gross Set here (~8.0 Ω) Normal Length Fine Set here (~8.0 Ω) Fine Set, Normal length\nGross Set, Normal length\nRegular Length TS Tips: Left= Fine set, Right = Gross set. Both TS sets have ~8.0 ohm tips and are the standard length similar to other TS100 style tips.\nImportant Currently, Pinecil V1 original uses the normal length ts100 style tips and not the newer Short tips designed for V2. Ralim is working on adding a feature to the firmware to allow people with the older V1 Pinecil to manually switch a profile setting which allows toggling between Normal Tip and Short tip profiles (adequate power supply must also be used min. PD65w 3.25A, 20V recommended). Check Github Ralim’s IronOS for progress information. Always unplug when swapping tips. Other compatible tips BC3 and JL02 are not sold by Pine Store, ~8.0 Ω\nCommon resistances for tips:\nPINE64 designed short tip 6.2 Ω, shorter length, only at pine64.com. no brand long tip 7.9 Ω, normal length ts100 style Miniware long tip 8.0 Ω, normal length ts100 style no brand long tip 8.3 Ω, normal length ts100 style Compare different soldering iron sizes:\nThis photo shows common irons to compare the distance from the finger grip to the work surface.\n","permalink":"/documentation/Pinecil/Tips/","tags":null,"title":"Tips"},{"categories":null,"contents":" Reset If your PineTab is in unknown state or doesn’t want to start: Press power button for 7-8s. It makes a sound and you know it’s totally off. 3 seconds after, power button again for 2-3s and it will start to boot.\nPower Off While Charging When plugging your Pinetab into a charger, it automatically powers on. Use the above \u0026ldquo;Reset\u0026rdquo; instruction (holding the power button in for several seconds) to turn it off. This will allow your Pinetab to charge without being powered on.\nDisplay rotated 90° on Arch ARM With the following command you can turn the display to landscape:\necho 1 | sudo tee /sys/class/graphics/fbcon/rotate This command does not persist a reboot.\n","permalink":"/documentation/PineTab/Tips_and_tricks/","tags":null,"title":"Tips and tricks"},{"categories":null,"contents":" Enable cpufreq Stuff Current neggles kernel has the CPU at 1.2 GHz, apparently SRE has patches to enable cpufreq? (see in Resources)\nAdd RK3588 Support To VOP2 VOP2 IP on the RK3588 is very similar to the one on the RK356x, but it still needs platform specific code added.\n","permalink":"/documentation/QuartzPro64/TODOs/","tags":null,"title":"TODOs"},{"categories":null,"contents":"Documentation for the touchpad can be found in Datasheets for Components and Peripherals. It is the only component of the Pinebook Pro held in place with strong adhesive tape. Here are some of its features:\n2 actuating buttons. multi-touch functionality. A matte finish that your finger can slide along easily. A reasonable size (96 mm × 64 mm; diagonal: 115.378 mm or 4.542 inches). Troubleshooting If you are having trouble using 2 fingers to scroll or emulate the click of a mouse’s right-button, then try these solutions:\nUpdate the firmware. Keep your 2 fingers spread apart rather than close together. Individual programs might need to be configured specially. *. For smooth scrolling and gestures under X-Windows, Firefox should be launched with with the following environment variable assignment: MOZ_USE_XINPUT2=1\nExperiment with other settings, via X-Windows Configuration or some other system preferences. For example, you could disable double-finger scrolling, and instead enable scrolling by sliding one finger along the edge of the touchpad. Firmware The touchpad controller is connected to the keyboard controller. All touchpad events go through the keyboard controller and its software, then to the keyboard controller’s USB port. Note that the touchpad does have separate firmware (which has to be written through the keyboard controller). The touchpad vendor’s firmware binary can be flashed from userspace using the following open source command-line utility:\nKamil Trzciński’s pinebook-pro-keyboard-updater. Naturally, forks have begun to appear:\nJack Humbert’s fork Dragan Simic’s fork. This one has recently delivered a much improved firmware from the vendor one, which greatly improves the control of the cursor (see this thread for discussion). Before installing this update, consider resetting to the defaults any configuration of your touchpad. All Pinebook Pros shipped from the factory have the old buggy version installed so consider updating the keyboard and touchpad firmware with the latest fixes from Dragan.\nWarning DO NOT update the touchpad firmware before checking which keyboard IC your Pinebook Pro has. Some Pinebook Pro were delivered with a SH61F83 instead of a SH68F83. The SH61F83 can only be written 8 times, this will render the keyboard and touchpad unusable if this limit is reached when step 1 (see below) is flashed. See Reddit SH61F83 thread. The keyboard IC corresponds to U23 on the top layer silkscreen of the main board. It is located under the keyboard flat flexible cable. All the PBPs from the post-pandemic batches have SH61F83 but TL Lim claimed they can be flashed just the same. No updated datasheet or a statement from the MCU vendor was provided though, so proceed at your own risk. Experience shows flashing those works for at least one time. Before updating any firmware, your Pinebook Pro should be either fully charged or, preferably, running from mains. This utility will be writing data to chips on the keyboard and touchpad, so a loss of power during any stage of the update can result in irrecoverable damage to your touchpad or keyboard.\nThe scripts ought to work on all operating systems available for the Pinebook Pro. Some operating systems may however, require installation of relevant dependencies. The instructions below assume a Debian desktop. To install these dependencies, newer Pinebook Pro models that come with Manjaro will require a different command.\nThere are two keyboard versions of the Pinebook Pro: ISO (vertical Enter key) and ANSI (horizontal Enter key). You need to know which model you have prior to running the updater.\nFirmware update steps for both models are listed below.\nWhat you will need:\nConnection to internet for getting dependencies, either through Wi-Fi or wired ethernet (USB dongle). Your Pinebook Pro fully charged or running from mains power. An external USB keyboard and mouse (or access to the Pinebook Pro via SSH. Please note that for some configurations, the SSH service might not be available without first having logged in once. In this case, you will definitely want at least an external keyboard or UART serial console). ISO Model From the terminal command line:\nDebian-based distributions:\ngit clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater cd pinebook-pro-keyboard-updater sudo apt-get install build-essential libusb-1.0-0-dev xxd make Arch-based distributions (note: build-essential, xxd are named differently. Arch linux does not split its packages as foo and foo-dev):\ngit clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater cd pinebook-pro-keyboard-updater sudo pacman -Syu base-devel xxd-standalone libusb make The next steps are identical for both Debian and Arch distros.\nStep 1\ncd pinebook-pro-keyboard-updater sudo ./updater step-1 sudo poweroff # do not use \u0026#39;reboot\u0026#39; Step 2 (after booting)\ncd pinebook-pro-keyboard-updater sudo ./updater step-2 iso sudo poweroff # do not use \u0026#39;reboot\u0026#39; ANSI Model Note Running step 1 on the ANSI keyboard model will make the keyboard and touchpad inaccessible until step 2 is run, so an external keyboard must be connected to complete the update on this model! From the terminal command line:\nDebian-based distributions:\ngit clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater cd pinebook-pro-keyboard-updater sudo apt-get install build-essential libusb-1.0-0-dev xxd make Arch-based distributions (note: build-essential, xxd are named differently. Arch linux does not split its packages as foo and foo-dev):\ngit clone https://github.com/dragan-simic/pinebook-pro-keyboard-updater cd pinebook-pro-keyboard-updater sudo pacman -Syu base-devel xxd-standalone libusb make The next steps are identical for both Debian and Arch distros.\nStep 1\ncd pinebook-pro-keyboard-updater sudo ./updater step-1 sudo poweroff # do not use \u0026#39;reboot\u0026#39; Step 2 (after booting)\ncd pinebook-pro-keyboard-updater sudo ./updater step-2 ansi sudo poweroff # do not use \u0026#39;reboot\u0026#39; When done, if some of the keys produce incorrect characters, please check your OS’s language settings. For ANSI users, the default OS may have shipped with English UK as the default language. You can change it to English US if desired.\nRevised Firmware In addition, you might consider using revised firmware data. This is one final step that should not require a reboot:\nStep 3: ISO (after booting)\nsudo ./updater flash-kb firmware/default_iso.hex Step 3: ANSI (after booting)\nsudo ./updater flash-kb firmware/default_ansi.hex X Window System Configuration Note Before making adjustments, consider updating the firmware. Reset your adjustments before updating the firmware, so that your adjustments do not interfere with new functionality. When using X.Org display server the touchpad can be handled either by libinput or synaptic input drivers. The former allows to have shared configuration for both X.Org and Wayland but the latter provides more tunables (e.g. configurable edge scrolling, circular scrolling, mapping of multi-touch events to mouse buttons etc.).\nSome forum members have found that an adjustment to X11 will allow finer motion in the touchpad. If you use the synaptic mouse/touchpad driver, use this command to make the change live:\nsynclient MinSpeed=0.2 You may experiment with different settings, but 0.25 was tested as helping noticeably.\nTo make the change persist across reboots, change the file /etc/X11/xorg.conf similar to below:\nSection \u0026#34;InputClass\u0026#34; Identifier \u0026#34;touchpad catchall\u0026#34; Driver \u0026#34;synaptics\u0026#34; MatchIsTouchpad \u0026#34;on\u0026#34; MatchDevicePath \u0026#34;/dev/input/event*\u0026#34; *Option \u0026#34;MinSpeed\u0026#34; \u0026#34;0.25\u0026#34;* EndSection The line \u0026ldquo;Option \u0026ldquo;MinSpeed\u0026rdquo; \u0026ldquo;0.25\u0026quot;\u0026rdquo; is changed here.\nAnother forum user built on the above settings a little, and have found these to be very good:\nsynclient MinSpeed=0.25 synclient TapButton1 synclient TapButton2=3 synclient TapButton3=2 synclient FingerLow=30 synclient PalmDetect=1 synclient VertScrollDelta=64 synclient HorizScrollDelta=64 FingerLow has the same value as \u0026lsquo;FingerHigh\u0026rsquo; in one config (30). It is believed to help reduce mouse movement as you lift your finger, but it’s unknown whether synaptic works like this. You may find this config to be comfortable for daily use.\nTabButton allows to just tab the touchpad instead of physically pressing it down (to get this click noise).\nThe right mouse click is emulated by tapping with two fingers on the touchpad. If you feel that this is not very responsive you can try this value:\nsynclient MaxTapTime=250 Some users may encounter an issue with the mouse jumping when typing when using libinput driver due to their hand hitting the touchpad which can be fixed by updating the X.Org settings to disable it while typing. One can disable the touchpad while typing by setting the below option in the X.Org config simliar to the previous example.\nOption \u0026#34;DisableWhileTyping\u0026#34; \u0026#34;on\u0026#34; The setting can be verified by using the xinput command to first list the devices and then listing the properties for the touchpad device. Exact commands to check this have been omitted for save of brevity. If DisableWhileTyping is shown enabled but does not appear to be working the issue may be due to the fact that the keyboard is connected to a USB bus which causes it to be seen as a external keyboard. Make sure you have libinput version 1.19.0 or later installed as it includes the necessary quirk.\nSynaptic driver users can add syndaemon to their X11 session for the same effect.\n","permalink":"/documentation/Pinebook_Pro/Features/Touchpad/","tags":null,"title":"Touchpad"},{"categories":null,"contents":" Tips, tricks and other information for troubleshooting your Pinebook Pro If something has gone wrong, the key thing is remain calm and not do anything hasty and make things worse, particularly when flashing the eMMC or firmware. Try and make a record of all the things you did in the run-up to the problem (even to the point of using a camera to take a note of errors on the screen, this record can be vital later).\nManjaro Updates Fail With 404 If you have an old Manjaro installation then it will have the wrong repositories/mirrors set up and they won’t work. Set up new repositories by following these instructions: https://archived.forum.manjaro.org/t/another-mirror-transition-manual-intervention-required/132302\nPower And Boot New from the factory - Pinebook Pro won\u0026rsquo;t boot / power on Some Pinebook Pros came from the factory with the eMMC switch in the disabled position. It should be switched towards the back / hinge to enable the eMMC. The eMMC may have come loose during shipment. Open the back and verify that the eMMC is firmly seated. You may want to try unplugging the SD card daughterboard ribbon cable and see if it powers on (remove the battery and peel off a bit of the tape before unplugging it to avoid damage). If it does, try reseating it on both sides. It might have come loose during shipping. It’s possible that your eMMC is empty from the factory. Simply create a bootable SD card and see if your Pinebook Pro Getting started. Pinebook Pro will not power on after toggling the eMMC enable/disable switch This may happen if you meant to toggle the UART/Headphone switch (9) towards touchpad for headphone use and instead you toggled the eMMC enable/disable switch (24). After reenabling eMMC by toggling switch (24) towards hinge, if Pinebook Pro does not turn on then press the RESET button (28). It is clearly marked \u0026lsquo;reset\u0026rsquo; on the PCB board. Pinebook Pro will not power on after removing and replacing EMI shielding Closely inspect that the shielding is firmly seated in the clips on all sides. You can be seated in the clips on one axis, and have missed on an another axis. Pinebook Pro won\u0026rsquo;t boot when using UART console cable If you’re using the UART console cable from the Pine Store, you may want to see if it boots after you disconnect it. Some users report that custom-made cables based on FTDI UART adapters do not cause this issue. Make sure your USB to serial UART device is 3.3v. Many are 5v and some even +-12v. Pinebook Pro’s only support 3.3v and may act eratically when using higher voltage. Further, higher voltage could permananetly damage the Pinebook Pro’s SoC. Pinebook Pro will not sleep with lid closed A problem with the positioning of the lid magnet has been identified by several forum users in mid-2020 models of the Pinebook Pro. The magnetic field from the lid magnet operates a hall effect sensor located on the daughterboard (smallboard), which causes the Pinebook Pro to sleep when the lid is closed. If the magnet is not positioned correctly, the Pinebook Pro will not sleep when the lid is fully closed, but may sleep if the lid is open about an inch. If you experience this problem, repositioning of the magnet may be necessary.\nLid Magnet Repositioning Step-by-Step Read these steps thoroughly before starting. This is a somewhat laborious process involving fragile parts!\nRemove bottom cover. Disconnect LCD and webcam ribbon cable from main board. Flip the small black strip on the connector upward and the ribbon cable can be easily removed. Do not pull the cable out without first raising the black retaining mechanism. Remove the small black plastic standoffs on each hinge and set aside. Remove the three screws from each hinge on the display assembly. Move the hinges upward to a 90 degree angle independently from the main body. Then lift the main body to the same 90 degree angle and you should be able to separate the display assembly from the main body. Set the main body aside. Remove the plastic hinge cover on the display assembly. There’s not really an easy way to do this, just work slowly and deliberately so as not to damage the sensitive cable inside. Start from either end and work your way inward. Use a small flathead screwdriver or similar tool to get started. Remove the hinges from the display assembly. Remove the rubber bumpers at the top corners of the display assembly to expose two screws. Remove the screws. Starting at the corners, separate the bezel from the lid. The clips that hold it in place are similar to those found on the hinge cover. Again, slow deliberate work will get it done. Work from the top down. Take care not to damage the cables in the bottom. With the bezel separated from the lid, feed the cable through the slot and set the bezel aside. Without removing the LCD panel completely, lift and move the panel slightly to the left, taking care not to damage the cable running underneath up to the webcam. This will give you room to remove the magnet without risking damage to the panel. The magnet is a silver colored bar near the bottom right side of the lid. Pry the magnet out with a small flathead or similar tool and set it aside. There is some adhesive but it’s not very strong. Put the LCD panel back where it belongs. Note the foam pads on either side of the panel. The magnet is the same width as the foam pad that keeps the panel in place, and should fit perfectly in the same channel. The magnet should be placed about 1 to 1.5cm lower than where it was originally. There should be no need for adhesive, as the magnet will stick to the LCD panel. For reference, the hall effect sensor that the magnet interacts with is in between the USB port and audio jack. Reassemble using these steps in reverse order. Your Pinebook Pro should now sleep properly when the lid is closed.\nAlternative Non-Invasive Lid Magnet Repositioning Method This method only takes a few seconds, and doesn’t require disassembling your Pinebook Pro: Turn on your Pinebook Pro so you can easily test when the internal magnet is in the correct position. Open the lid. Take a tiny 1/8\u0026quot; neodymium magnet, and place it along the right edge of the front bezel (LCD side) to locate the internal positioning magnet and discover the correct polarity. There should be one spot where it has the most attraction. Mark that spot. Using a very strong neodymium magnet(s) oriented with the same polarity you discovered using the tiny magnet, carefully place it on the spot you marked, and slowly slide it down the bezel until the internal magnet is pulled into the proper position. I successfully used four 1/2\u0026quot; cube neodymium magnets stacked on top of each other each having 20lbs of pull force to accomplish this. The internal magnet should be placed about 1 to 1.5cm lower than where it was originally. There should be no need for adhesive, as the magnet will stick to the LCD panel. For reference, the hall effect sensor that the magnet interacts with is in between the USB port and audio jack. Remove all external magnets, and test that the internal magnet is positioned correctly by slowly closing the lid while watching the LCD screen to make sure it stays suspended when closed, and wakes up when opened. Your Pinebook Pro should now sleep properly when the lid is closed.\nWiFi And Bluetooth WiFi issues First, check the privacy switches to make sure your WiFi is enabled. They are persistant. See Privacy Switches Next, you may have to modify the /etc/NetworkManager/NetworkManager.conf as root user, and replace managed=false with managed=true. Then reboot. If that doesn’t work, and if dmesg | grep brcmfmac reports missing firmware, you will need to manually add the brcmfmac43455-sdio.* firmware files. This is due to a quiet change in the 2022 hardware revision. This repo has been tested and confirmed to work by no112. For connections that drop and resume too often, it might be due to WiFi power management from earlier OS releases. Later OS releases either removed WiFi power management, or default to full power. (Power management can be turned off via command line with iw dev wlan0 set power_save off or iwconfig wlan0 power off, although it is not persistent through re-boot.) For connections that drop under load on the default Debian, remove iwconfig wlan0 power off in the file /etc/rc.local. If WiFi is un-usable or often crashes when using an alternate OS, then it might because its WiFi firmware is not appropriate for the WiFi chip in the Pinebook Pro. Try the latest firmware patch from https://gitlab.manjaro.org/tsys/pinebook-firmware/tree/master/brcm After re-enabling WiFi via the privacy switch, you have to reboot to restore function. There is a work around for the default Debian, (and may work with others); sudo tee /sys/bus/platform/drivers/dwmmc_rockchip/{un,}bind \u0026lt;\u0026lt;\u0026lt; 'fe310000.dwmmc' On extremely rare occasions, the WiFi antenna connection is loose. To fix, simply open up the bottom, re-connect the WiFi antenna cable. This may show up as any of the following symptoms: Can’t connect to any network, but the network manager software sees the WiFi device, (so it has not been disabled by the Privacy Switch) Very limited range, meaning you can make a connection if the Pinebook Pro is next to the WiFi router. But not the next room. Unreliable connections, that are also limited by range. Every once in a great while, the kernel will just fail to detect the wifi hardware (symptom: `ip link`` shows no wlan0). Only solution found so far is to hard-reset the machine (complete power-off then on again). Bluetooth issues When connecting a Bluetooth device, such as a Bluetooth mouse, it does not automatically re-connect on re-boot. In the Bluetooth connection GUI, there is a yellow star for re-connect on boot. Use that button to enable a persistent connection. It can be changed back later. Bluetooth-attached speakers or headset require the pulseaudio-module-bluetooth package. If not already installed, it can be installed with a package manager or using the following: sudo apt-get install pulseaudio-module-bluetooth When using Bluetooth-attached speakers or headset and 2.4Ghz WiFi at the same time, you may experience stuttering of the audio. One solution is to use 5Ghz WiFi if you can. Or you may try using a different 2.4Ghz channel, perhaps channel 1 or the top channel, (11 in the USA, or 13/14 in some other countries). Sound issues Many reports of no sound are due to the OS, incorrect settings, or other software problems (eg. PulseAudio). So first test to see if it is a software or hardware problem, by trying another OS via SD card. (For example, if Debian is installed on the eMMC, try Ubuntu on SD.) If you cannot get sound from the headphone jack, but can get sound from the speakers, then the headphone / UART console switch may be set to the UART mode. You can open the back and check the position of the switch. If set to UART mode, switch it to headphone mode. See the parts layout for the location and correct position of the switch. When using the USB C alternate DisplayPort mode, it is possible that the audio has been re-directed through this path. If your monitor has speakers, see if they work. See manjaro-arm/pinebookpro-post-install /var/lib/alsa/asound.state for some ALSA tweaks. See manjaro-arm/pinebookpro-audio for how to handle 3.5mm jack plug/unplug events with ACPID. Serveral users have reported that one internal speaker had reversed polarity. Thus, sound from the speakers is like an echo effect. There is a software fix using alsamixer and then enable either \u0026ldquo;R invert\u0026rdquo; or \u0026ldquo;L invert\u0026rdquo;, however, now the headphones have incorrect audio. The permanent fix is to re-wire one speaker, though this requires soldering small wires. Sound playback may be affected by the \u0026ldquo;mirroring\u0026rdquo; between the right and left channels, which results in distorted sound image. The root cause is the ALSA mixer setting named \u0026ldquo;DAC Stereo Enhancement\u0026rdquo;, which needs to be changed to 0% to fix this issue. Please see this forum post for further information. NVMe SSD issues Many Pinebook Pro users have reported issues with M.2 NVMe SSD drives, including random Linux lockups and crashes. Some of these issues are related to the RK3399’s errata that disables Gen2 (5 GT/s) speed for the PCI Express link used by the NVMe SSD, reducing it down to Gen1 speed (2.5 GT/s). However, Linux distributions that use Linux kernels older than version 5.12 still configure the PCI Express link to run at Gen2 speed, which requires manual reconfiguration to Gen1 speed in case system instability is experienced. See also this related discussion. This issue does not affect distributions with recent (newer than May 2021) kernels such as Manjaro ARM which seem to work with no modifications.\nSome Pinebook Pro users have reported issues with the default settings for the APST (Autonomous Power State Transition) power saving, which cause an NVMe drive to disappear from the system or lock up after a certain period of time. Please see this forum thread for further information.\nThe output of the 3.3 V regulator inside the Pinebook Pro, which powers the M.2 SSD, becomes very noisy when the battery voltage drops below 3.9 V or so. This is a hardware issue of the Pinebook Pro that cannot be corrected without extensive hardware modifications, and it causes many M.2 SSDs to lock up under load and cause operating system crashes. The real trouble is that for some M.2 SSDs it takes a couple of hours of heavy I/O to lock up under these conditions, which may make them appear to be working reliably, while they eventually fail.\nKeyboard and trackpad Random Duplicated Key-Presses Whether caused by an error in the Hailuck Keyboard firmware, or a physical defect in the membrane, the Pinebook Pro keyboard may randomly register some key-presses twice. The solution to this problem is trivial. Simply run the following command:\nxkbset bouncekeys 20\nIf this return the following error:\nbash: xkbset: command not found\nOr some other similar error, you will need to install the command. It can most likely be found in your distro’s repository.\nYou may substitute some other value for 20 - this number denoting the time in milliseconds during which successive, duplicate key-presses will be rejected - with any value of your choice. If you are still receiving duplicates, consider increasing the number - perhaps by half. If you are consistently writing \u0026ldquo;aple\u0026rdquo;, try decreasing this number - perhaps by 25%.\nKeys not registering / missing keys when typing This issue occurs when your thumb or edge of the palm makes contact with left or right tip of the trackpad when you type. This is due to the palm rejection firmware being too forceful. Instead of only disabling the trackpad, so your cursor does not move all over the screen, it disables both the trackpad and the keyboard.\nUsing Fn+F7 to disable the touchpad will keep it from also disabling the keyboard.\nA firmware update has been released to address this.\nKey mapping See this /etc/udev/hwdb.d/10-usb-kbd.hwdb for some key mapping tweaks Pinebook Pro gets stuck after first reboot in Trackpad Firmware Update This refers to the firmware update shown here: https://github.com/dragan-simic/pinebook-pro-keyboard-updater#update-all-firmware-images\nIf the system is not responding after the 1st reboot, it might be easiest to do a system restore or boot an SD-card-only OS, and follow up by running the second step of the trackpad firmware update with a USB keyboard and mouse plugged in System restore https://forum.pine64.org/showthread.php?tid=8229 Firmware update https://github.com/dragan-simic/pinebook-pro-keyboard-updater#update-all-firmware-images ANSI Fn + F keys wrong for F9, F10, F11 and F12 There appears to be a minor firmware issue for ANSI keyboard models of the Pinebook Pro. Some discussion and fixes have been proposed;\nDiscussion thread Fn + F keys screwy for F9, F10, F11 and F12 Proposed fix (ANSI) Fn + F(9-12) has wrong assignment after firmware update #14 USB docks \u0026amp; USB C alternate mode video The Pinebook Pro uses the RK3399 SoC (System on a Chip). It supports a video pass through mode on the USB C port using DisplayPort alternate mode. This DisplayPort output comes from the same GPU used to display the built-in LCD.\nHere are some selection criteria for successfully using the USB C alternate mode for video:\nThe device must use USB C alternate mode DisplayPort. Not USB C alternate mode HDMI, or other. The device can have a HDMI, DVI, or VGA connector, if it uses an active translator. If USB 3 is also desired from a USB dock, the maximum resolution, frame rate and pixel depth is reduced to half the bandwidth. For example, 4K @ 30hz instead of 60hz. USB docks that also use USB C alternate mode DisplayPort will always have USB 2 available, (480Mbps, half-duplex). Screen Also see above about external screen using USB-C adaptor\nAfter changing builtin LCD resolution, blank screen Some people find that the text or icons are too small, so they attempt to change the resolution of the built-in display. Afterwards, the display is blank. Use the following to fix when logged into a text console as yourself, pressing Control-Alt-F1 through F6. After listing the resolutions, select the native resolution, (1920x1080 aka 1080p).\nexport DISPLAY=:0.0 xrandr -q xrandr -s [resolution] Once the screen resolution is restored, try using the software settings to configure the desired screen scaling.\nIf the above fix did not work, you can try this:\nUsing a text console, (Control-Alt-F1), login with your normal user ID Edit the file nano ~/.config/monitors.xml Change the \u0026ldquo;width\u0026rdquo; value to \u0026ldquo;1920\u0026rdquo; Change the \u0026ldquo;height\u0026rdquo; value to \u0026ldquo;1080\u0026rdquo; If there is more than one monitor configuration listed, edit that one too. Be careful to make no other changes. If needed, exit without saving and re-edit. Save the file and exit. Login using the GUI and test If you are still logged in via the GUI, you will have to reboot using sudo shutdown -r now. After the reboot, you should be able to login to the GUI login and have the resolution back to normal. After restoring the usability of your Pinebook Pro’s graphical screen, also see this section on improving readability and usability.\nOuter Shell Cracks in the plastic There have been multiple reports of cracks in the plastic keyboard and trackpad part of the case. These are generally near:\nHinges USB ports Top side, around the corners This seems to apply to the first batches in 2019. Later versions of the keyboard and trackpad have used better plastic. With replacements now in the Pine64 Store, it’s possible to simply order a replacement.\nThere have been a few reports of cracks in the plastic around the LCD display, but these appear to be less common. There are replacement LCDs with top cases available in the Pine64 Store.\nBe extra careful if you open the PBP, the plastic parts of the shell, around the back corners or the hinges are really tiny and break easily.\n","permalink":"/documentation/Pinebook_Pro/Troubleshooting/","tags":null,"title":"Troubleshooting"},{"categories":null,"contents":"If the PinePhone is not booting from eMMC and/or microSD card anymore it can have two causes:\nThe battery is drained If the battery is fully drained, most operating systems and distributions won’t boot anymore. One of the exceptions which still boots is the utility Jumpdrive, which can usually be used to expose the eMMC and microSD card as drives to a USB-connected computer. Mind that JumpDrive won’t expose the eMMC and microSD card with a drained battery but it still can be flashed and booted from microSD card to confirm that the phone still functions and boots up fine.\nJumpDrive can be downloaded from here (not compatible with the PinePhone Pro!).\nNote If JumpDrive boots and other releases do not boot, the battery is likely drained. In that case let it charge while running JumpDrive with a compatible charger for multiple hours and make sure to not fully drain the battery in the future anymore, as that significantly reduces the battery lifetime. Alternatively to testing JumpDrive, the issue can also be diagnosed by checking the battery charge. Simply remove the battery from the device and measure the voltage on the (+) and (-) contacts on the battery. Make sure to not shorten the contacts as shorting battery pins is a severe life and safety danger.\nThe installation is corrupted or incorrect If the installation of the prioritized boot medium is corrupted or incorrect, the PinePhone will not boot anymore. The following problems are common:\nThe microSD card is in the wrong slot (see first time installation) The image file was flashed to partition 1 (example: sdx1, nvme0x1p1) instead of the whole device (example: sdx, nvme0x1) An image without bootloader was flashed (mind the Tow-Boot bootloader requirements of Mobian and postmarketOS) The operating systems got corrupted, for example after running updates (reflash the device, see Installation instructions) An incompatible image was flashed (make sure that the images are compatible. Images for the PinePhone Pro won’t boot on the PinePhone and vice versa. Check your invoice to see if you ordered a PinePhone or a PinePhone Pro). ","permalink":"/documentation/PinePhone/Troubleshooting/","tags":null,"title":"Troubleshooting"},{"categories":null,"contents":"If the PinePhone Pro is not booting (either booting incompletely into a boot splash or tty or if the PinePhone Pro is showing no signs of life) this will typically have the following two reasons:\nThe battery is fully drained If the battery is drained then the board can reset during boot causing a boot loop because of undervoltage condition. It can happen on all stages of the boot including U-Boot bootloader, display initialization and USB (re-)configuration. In that case it is not possible to charge the phone. The battery can be charged by interrupting the boot loop by booting the PinePhone Pro into Maskrom mode or by charging the battery externally. It is possible to follow these instructions without a computer by using a wall charger, however it would not be possible to determine if Maskrom mode was started successfully. To boot the PinePhone Pro into Maskrom mode:\nRemove any microSD card from the phone and keep it removed for the below procedure Remove the battery, any USB cable and any serial cable Reinsert the battery Hold the RE button underneath the back cover of your Explorer Edition (or short the bypass contact points on the Developer Edition) Note Confirm that the label of the button says RE and not RESET! If the button label says RESET instead you probably have a regular PinePhone and you’re reading the wrong page. Connect the phone to an USB port of a computer, while still holding the button for some time Confirm if the phone was booted in Maskrom mode: On Linux check if the Maskrom mode appears as device in the output of the terminal command lsusb on the computer, the expected VID:PID of the device is 2207:330c. On Windows this can be checked using the Device Manager and checking the VID \u0026ldquo;2207\u0026rdquo; and PID \u0026ldquo;330c\u0026rdquo; of an Unknown device appears. On macOS this can be checked in /Applications/Utilities/System Information.app under USB and by checking if the VID \u0026ldquo;2207\u0026rdquo; and PID \u0026ldquo;330c\u0026rdquo; is appearing for a Composite Device. Let the phone charge for multiple hours Note If the device doesn’t appear under lsusb please try again with a different known good USB-C cable and make sure that there is no microSD card in the phone inserted. The device should now be able to boot from the boot medium again. If that is not the case the installation got corrupted, as explained below.\nThe installation is corrupted The PinePhone Pro won’t be able to boot if the installation on the SPI flash, the eMMC or the microSD card got corrupted. To boot a working operating system:\nPrepare a microSD card as explained in the section Flashing to microSD card Remove any USB-C cable or device or add-on case from the PinePhone Pro Make sure the device is powered off by shortly removing the battery for a second Insert the microSD card into the top slot of the PinePhone Pro. Make sure the microSD card is inserted all the way and that the notch of the right side of the microSD card is not visible anymore. Power on the device (bypassing the SPI and eMMC might be required, see Boot order) The device should now boot from the microSD card. If the phone does not boot from the microSD card the microSD card was flashed with an incompatible image or the battery got drained as explained above.\n","permalink":"/documentation/PinePhone_Pro/Troubleshooting/","tags":null,"title":"Troubleshooting"},{"categories":null,"contents":" Stability/Boot Issues With Missing Battery Shunt If there is no battery plugged into the board, the jumper labelled \u0026ldquo;ON/OFF_BATT\u0026rdquo; must be in place. If this is set wrong, stability issues such as failures to boot will occur.\nNote This affects only Model A No Ethernet Connectivity Make sure the kernel is built with CONFIG_MOTORCOMM_PHY set to y. Building it as a module (m) and then relying on module auto-loading is unlikely to work, because if the generic PHY driver is built in it will bind to the PHY first, unless you include the motorcomm module in your initramfs.\nNote: Starting with Debian’s 6.1~rc3-1~exp1 kernel the module is included, but set to m and I (Diederik) have verified that it gets included in the initramfs and works on Model-A and Model-B with the Quartz64 images.\n\u0026ldquo;Model A\u0026rdquo; Acrylic Case Doesn\u0026rsquo;t Fit The Quartz64 does not really fit onto the bottom plate of the Model A Acrylic Open Enclosure. This is because the \u0026ldquo;Mic\u0026rdquo; connector at the bottom of the board interferes with one of the posts. A workaround is to find out which post that is (you have a 50% chance of guessing it right, accounting for rotating the board) and then filing away the corner of the post pointing inwards by a few millimeters.\nAn alternate solution may be to place plastic spacers with a smaller outer diameter in between the acrylic bottom plate posts and the SBC board.\nNo GPU Acceleration with Debian \u0026ldquo;Bullseye\u0026rdquo; Userland Debian Bullseye ships a Mesa version that is too old to contain the required patches for the RK356x SoC’s GPU. Upgrade to Bookworm.\nWireless Connectivity Doesn\u0026rsquo;t Work ROCKPro64 wireless module may have CYW43455 or CYW43456 chips on board (not sure if this is the same for Quartz64 model B). Both chips are supported by brcmfmac Wi-Fi driver and btbcm Bluetooth driver.\nFor CYW43455 drivers attempt to load /lib/firmware/brcm/brcmfmac43455-sdio.bin for Wi-Fi and /lib/firmware/brcm/BCM4345C0.hcd for Bluetooth. Corresponding firmware files for CYW43456 are /lib/firmware/brcm/brcmfmac43456-sdio.bin and /lib/firmware/brcm/BCM4345C5.hcd.\nOn Manjaro firmware files for both Bluetooth and Wi-Fi on CYW43456 on are provided by ap6256-firmware package (pacman -S ap6256-firmware).\nHowever for CYW43455 wi-fi firmware is in the linux-firmware package and bluetooth is in the firmware-raspberrypi (pacman -S linux-firmware firmware-raspberrypi). linux-firmware package is missing device specific symlinks for quartz64-a. To create them execute:\n# ln -s brcmfmac43455-sdio.bin /lib/firmware/brcm/brcmfmac43455-sdio.pine64,quartz64-a.bin # ln -s brcmfmac43455-sdio.AW-CM256SM.txt /lib/firmware/brcm/brcmfmac43455-sdio.pine64,quartz64-a.txt As of 2022-10-19 device tree in mainline kernel for Quartz64 model A has wrong configuration for the Bluetooth driver. Patch is submitted to the LKML and accepted and included upstream in 6.1-rc7. It’s possible to modify dtb file provided by the current kernel using device tree compiler to enable Bluetooth or perform make dtbs in the patched kernel tree to get updated dtb file (arch/arm64/boot/dts/rockchip/rk3566-quartz64-a.dtb). Issue manifests itself with following errors in dmesg:\ncommand 0x0c03 tx timeout Bluetooth: hci0: BCM: Reset failed (-110) ","permalink":"/documentation/Quartz64/Troubleshooting/","tags":null,"title":"Troubleshooting"},{"categories":null,"contents":" HDMI output disconnects as soon as it connects Some older monitors seemingly can get into a weird state wherein the ROCK64 is unable to establish a proper connection with them. User CounterPillow has seen this happen on an iiyama ProLite G2773HS connected over HDMI, and an Acer P225HQL connected over an HDMI to DVI adapter. The symptoms usually are that you see the monitor briefly turn on its backlight without displaying a picture, but then immediately either shutting off again or showing a \u0026ldquo;No Signal\u0026rdquo; message.\nThe solution is to completely power down your ROCK64, also removing its power source. Then plug in the monitor, and start up the ROCK64 afterwards. You should now be getting a picture again.\nPower button doesn\u0026rsquo;t do anything on a short press (Linux) Make sure the rk805_pwrkey module is loaded, e.g. with lsmod | grep rk805_pwrkey. The module auto loading of rk805_pwrkey was fixed in the following upstream kernels: v6.0/v5.15.66/v5.10.142/v5.4.213/v4.19.258/v4.14.293 so there should be no requirement for fixes with those kernels or newer. If it doesn’t show up, do a modprobe rk805_pwrkey as root. To make this persistent, create a 99-rk805_pwrkey.conf in /etc/modules-load.d/ with the content rk805_pwrkey\nIf it still doesn’t work, make sure your init system is actually listening to the button press. With systemd, check /etc/systemd/logind.conf and make sure it’s either all commented out (uses defaults) or contains something like HandlePowerKey=poweroff. You can change the short press action by setting HandlePowerKey to one of \u0026ldquo;ignore\u0026rdquo;, \u0026ldquo;poweroff\u0026rdquo;, \u0026ldquo;reboot\u0026rdquo;, \u0026ldquo;halt\u0026rdquo;, \u0026ldquo;kexec\u0026rdquo;, \u0026ldquo;suspend\u0026rdquo;, \u0026ldquo;hibernate\u0026rdquo;, \u0026ldquo;hybrid-sleep\u0026rdquo;, \u0026ldquo;suspend-then-hibernate\u0026rdquo;, or \u0026ldquo;lock\u0026rdquo;.\nVideo output is glitchy during activity If your video output glitches out while there is memory bandwidth pressure, the likely reason is that the video output (VOP) quality-of-service (QoS) registers aren’t set to high priority mode.\nUser CounterPillow submitted a patch to u-boot to fix this, but someone still needs to write a kernel patch to save/restore the QoS registers from the power domain driver.\n","permalink":"/documentation/ROCK64/Troubleshooting/","tags":null,"title":"Troubleshooting"},{"categories":null,"contents":" No Video or GPU Acceleration on Debian If you can log in through serial but don’t get any video or GPU acceleration on Debian, this is likely due to Debian’s decision to compile the devfreq governors as loadable modules but not including them early enough for panfrost to be able to be provided with one of them.\nThe usual sign of this being the case is the following line in the kernel log: [drm:panfrost_devfreq_init [panfrost]] **ERROR** Couldn’t initialize GPU devfreq\nTo fix this issue, run the following as root and reboot:\necho governor_simpleondemand \u0026gt;\u0026gt; /etc/initramfs-tools/modules update-initramfs -u -k $(uname -r) PCIe probe failures on Linux kernel boot While booting the Linux kernel, you might experience PCIe probe failures, which render the attached PCIe device inaccessible. The \u0026ldquo;drivers: pci: introduce configurable delay for Rockchip PCIe bus scan\u0026rdquo; thread on the Linux kernel mailing list (LKML) discusses this issue and proposes a fix.\nManjaro ARM applies the following patches to the kernel package, which fix the issue:\n1005-rk3399-rp64-pcie-Reimplement-rockchip-PCIe-bus-scan-delay.patch 1007-arm64-dts-rockchip-Add-PCIe-bus-scan-delay-to-RockPr.patch ","permalink":"/documentation/ROCKPro64/Troubleshooting/","tags":null,"title":"Troubleshooting"},{"categories":null,"contents":"There is a number of things that can prevent the board from booting up properly. The most common culprits of a failed boot are:\nSubpar or counterfeit microSD card Subpar Power Supply High resistance (thin) or a very long microUSB cable Failed imaging of the microSD card Note Make sure to have the newest version of the operating system and the bootloader installed. To find out more, visit the PINE64 forum thread.\nSupported screen resolutions The board supports a number of video resolutions under Linux, however RemixOS and Android images currently only support 720p and 1080p. Linux supports a wider range of resolutions (see all resolutions supported on Linux here). If the native resolution of your monitor or TV is not compatible with the board you will be unable to get video output working with your screen.\nSteps Follow these steps to determine the cause of your problem:\nCheck your PSU and barrel cable ratings Download and install a base image of Linux Plug in power and ethernet into your Board Confirm activity on the ethernet port LED Find out the IP of the SOPINE on the router interface Try to connect to the running SOPINE from your computer using SSH Notes If neither of the above mentioned scenarios fits the problem you are facing, please consult the PINE64 forum thread from user Ghost.\n","permalink":"/documentation/SOPINE/Troubleshooting/","tags":null,"title":"Troubleshooting"},{"categories":null,"contents":"Details on how to get the most out of a Pinebook Pro.\nCustomizing the Pinebook Pro\u0026rsquo;s default Manjaro KDE system Watching DRM content (Netflix, etc.) Most paid online streaming services use Widevine DRM to make their content more difficult to pirate. Widevine is not directly supported on Manjaro KDE, however it is still possible to watch DRM content via the \u0026ldquo;chromium-docker\u0026rdquo; package which downloads a 32-bit ARM container and installs Chromium with Widevine inside of that. While not space-efficient, or efficient in general, it’s the recommended solution for watching this content on your Pinebook Pro. You can install this package with:\nsudo pacman -Sy chromium-docker Checking GPU capabilities To see what versions of OpenGL and OpenGL ES are supported by the Pinebook Pro, what driver is in use, and what version of the driver is loaded, install the \u0026ldquo;mesa-demos\u0026rdquo; package with:\nsudo pacman -Sy mesa-demos And then run:\nglxinfo | grep OpenGL This will give detailed information about your graphics card and driver, useful for debugging.\nBetter GPU compatibility and performance For better graphics performance, you may install the \u0026ldquo;mesa-git\u0026rdquo; package, built and supplied in the Manjaro ARM repos. This lets you bring in the latest features, optimizations, and bugfixes for the graphics driver used by the Pinebook Pro. Installation is as simple as:\npacman -Sy mesa-git Then you may reboot to load the newer driver.\nWith Mesa 20.2 there is no longer much reason to use this over the standard mesa package, and applications may occasionally break with mesa-git.\nReporting bugs to the Mesa project will help make sure any problems are quickly fixed.\nOpenGL 3.3 support By default, with the current state of the Panfrost GPU driver, the Pinebook Pro supports OpenGL 2.1 and OpenGL ES 3.0. If you want to use OpenGL 3.3, you need to set the system-wide environment variable, open the /etc/environment file with:\nkate /etc/environment And then at the bottom of the file, on a new line, add:\nPAN_MESA_DEBUG=\u0026#34;gl3\u0026#34; Then save the file, entering your password when prompted, and reboot the system. When you check your GPU capabilities, it should report OpenGL 3.3 and applications that rely on it should function properly. Note that GL 3.3 support is incomplete and some rendering features do not work yet, notably geometry shaders.\nInstall Anbox on Pinebook Pro Manjaro 20.10 Youtube video on installing Anbox on Pienbook Pro Manjaro Build 20.10 by LivingLinux\nCustomizing the Pinebook Pro\u0026rsquo;s previously-default Debian system Here are some hints on what you can do to customize the Pinebook Pro’s previous factory image (aka mrfixit2001 debian build)\nInitial user changes, password, name, etc When you first get your Pinebook Pro, you should consider setting strong passwords and making the default account your own.\nReboot (this is just to ensure all background processes belong to the user are not running. There are other ways to achieve this but this way is easy)\nOnce the machine reboots press Alt-Ctrl-F1 to bring up a text terminal\nLogin as root (login: root, password: root)\nSet a strong password for the root user using the following command and it’s prompts:\n# passwd (and follow prompts) Rename the rock user to your prefered username (replace username with whatever you like):\n# usermod -l _username_ -d /home/_username_ -m rock Rename the rock group to match your preferred username:\n# groupmod -n _username_ rock Put your name in the account, (replace \u0026ldquo;John A Doe\u0026rdquo; with your name):\n# chfn -f \u0026quot;John A Doe\u0026quot; _username_ Set a strong password for the normal user:\n# passwd _username_ Log out of the text terminal:\n# logout Press Alt-Ctrl-F7 to go back to the login screen and then login as the normal user\nOpen text terminal to fix login error: \u0026ldquo;Configured directory for incoming files does not exist\u0026rdquo;:\n$ blueman-services Select \u0026ldquo;Transfer\u0026rdquo; tab and set \u0026ldquo;Incoming Folder\u0026rdquo; to yourself or if adduser is in the distributions, create an user with sudo adduser $USER (fill out variables as required), then add the user to the groups using sudo adduser $USER $GROUP by adding one group at a time.\nChanging the default hostname Debian 9 has a command to allow you to change the hostname. You can see the current settings using:\n$ sudo hostnamectl Static hostname: Debian-Desktop Icon name: computer Machine ID: dccbddccbdccbdccbdccbdccbdccbccb Boot ID: ea99ea99ea99ea99ea99ea99ea99ea99 Operating System: Debian GNU/Linux 9 (stretch) Kernel: Linux 4.4.210 Architecture: arm64 To change, use this, (with hostname used as the example):\n$ sudo hostnamectl set-hostname _hostname_ Whence done, you can re-verify using the first example.\nThen you should backup and edit your /etc/hosts entry’s name:\n$ sudo cp -p /etc/hosts /etc/hosts.`date +%Y%m%d` $ sudo vi /etc/hosts 127.0.0.1\tlocalhost 127.0.0.1\t_hostname_ ::1\tlocalhost ip6-localhost ip6-loopback fe00::0\tip6-localnet ff00::0\tip6-mcastprefix ff02::1\tip6-allnodes ff02::2\tip6-allrouters 127.0.1.1 linaro-alip Disable Chromium browser\u0026rsquo;s prompt for passphrase \u0026amp; password storage Perform the following steps:\nOn the tool bar, hover over the Chromium icon Using the right mouse button, select Properties In the Command: line section, add --password-store=basic before the %U Use the x Close button to save the change This will of course, use basic password storage, meaning any saved passwords are not encrypted. Perfectly fine if you never use password storage. Changing the boot splash picture The default boot splash picture can be replaced using the following instructions:\nInstall ImageMagick which will do the conversion $ sudo apt-get install imagemagick Create a 1920 x 1080 picture. For the best results, use a PNG image (It supports lossless compression). From the directory in which your new image is stored run the following commands Convert your image to the bootsplash raw format using imagemagick convert. $ convert yoursplashimage.png -separate +channel -swap 0,2 -combine -colorspace sRGB RGBO:splash.fb Create a backup copy of your current splash screen $ sudo cp /usr/share/backgrounds/splash.fb /usr/share/backgrounds/splash_original.fb Copy your new splash screen into place $ sudo cp splash.fb /usr/share/backgrounds/splash.fb Set the correct permissions on the splash.fb file $ sudo chmod 644 /usr/share/backgrounds/splash.fb If you do not want to see kernel console text messages, make sure you don’t have Plymouth installed Watching Amazon Prime videos with Chromium When you create a new user, it will be necessary to launch the Chromium browser with a specific user agent like below:\nchromium-browser --user-agent=\u0026#34;Mozilla/5.0 (X11; CrOS armv7l 6946.63.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36\u0026#34; There may be more tweaks needed.\nEnabling text boot time messages By default, most Linux distributions have a boot screen with a picture. To see all the boot time messages, use one of the following:\nDebian Backup and edit the U-Boot configuration file: cp -p /etc/default/u-boot /etc/default/u-boot.`date +%Y%m%d` chmod a-w /etc/default/u-boot.`date +%Y%m%d` vi /etc/default/u-boot Remove the quiet and splash parameters. Leave everything else alone.\nUpdate the U-Boot configuration: u-boot-update Test and verify you get what you think you should be seeing. Manjaro Backup and edit the U-Boot configuration file: cp -p /boot/extlinux/extlinux.conf /boot/extlinux/extlinux.conf.`date +%Y%m%d` chmod a-w /boot/extlinux/extlinux.conf.`date +%Y%m%d` vi /boot/extlinux/extlinux.conf Change console=ttyS2,1500000 to console=tty1 Remove the bootsplash.bootfile option and it’s parameter. You can add verbose logging by appending ignore_loglevel to the line where boot splash was. Leave everything else alone. Test and verify you get what you think you should be seeing. Retro Gaming on the Pinebook Pro A retro-gaming OS named R-Cade has been made available for the Pinebook Pro, provided by The Retro Center.\nR-Cade includes over 100 retro-gaming systems, a lightweight web browser, and includes the latest release of KODI to provide full 4K UHD media playback and streaming. Streaming options in KODI are provided by various addons, such as Netflix, Disney+, and Amazon Prime. More information can be found here.\nReleases can be downloaded from their GitHub.\nImproving readability Some people find that a 14\u0026quot; LCD screen with 1080p, (1920 x 1080), has text and icons a bit too small. There are things you can do to make the screen easier to use and read.\nIncrease the font size Use a font with more pronounced features Increase the various window manager sizes (e.g. increase the height of the tool bar) Change the color scheme to be easier on the eyes. Higher contrast can help usability. Change the window manager’s decorations (e.g. use larger icons) Use a workspace manager, with one application per workspace When at home or office, use an external monitor Change the X-Windows DPI. One such method that someone used successfully, is: echo \u0026quot;Xft.dpi: 150\u0026quot; \u0026gt;\u0026gt; ~/.Xresources Change the 150 as desired to get the size adjustment you want. However, do not change the resolution of the LCD screen, otherwise you may end up with a blank / black screen. If that happens, see this troubleshooting section for the fix: Blank screen after changing builtin LCD resolution\nChromium tweaks Flags From the official Debian image:\n--disable-low-res-tiling \\ --num-raster-threads=6 \\ --profiler-timing=0 \\ --disable-composited-antialiasing \\ --test-type \\ --show-component-extension-options \\ --ignore-gpu-blacklist \\ --use-gl=egl \\ --ppapi-flash-path=/usr/lib/chromium-browser/pepper/libpepflashplayer.so \\ --ppapi-flash-version=32.0.0.255 \\ --enable-pinch \\ --flag-switches-begin \\ --enable-gpu-rasterization \\ --enable-oop-rasterization \\ --flag-switches-end Note that in some cases, this may also decrease performance substantially, as observed when using these flags on the Manjaro KDE desktop. Feel free to experiment to find what is smoothest for you personally.\ngVim has performance issue It appears that using GTK3 can cause very slow scrolling, while Vim in a terminal window works fine. Simply revert back to using GTK2 (how to do so is somewhat Linux distriobution-specific).\nAnother solution may be to run gVim with\nGDK_RENDERING=image environment variable set. It seems that this improves the performance by reverting back to software-only rendering.\nKernel options Here are some Pinebook Pro \u0026amp; its RK3399 SoC Linux specific options. If kernel version, (or version range specific), it should list that information in the description.\nTo see if a specific feature is enabled in the current kernel, you can use something like this:\n$ zgrep -i rockchip_pcie /proc/config.gz # CONFIG_ROCKCHIP_PCIE_DMA_OBJ is not set CONFIG_PHY_ROCKCHIP_PCIE=m If it’s listed as =m, then it’s a module. You can see if the module is loaded with:\n$ lsmod | grep -i rockchip_pcie phy_rockchip_pcie 16384 0 Note modules are not loaded until needed. Thus, we sometimes check the kernel configuration instead to see if a feature is configured first, then see if it’s a module.\nHardware video decoding Here is a method to check for hardware video decoding by the VPU. There are special Linux kernel modules that perform this function.\nOlder systems, such as the previously-default Debian desktop, use the Rockchip-supplied kernel module rk-vcodec. To check, something like this can be used:\n$ lsmod | grep rk-vcodec or\n$ zgrep RK_VCODEC /proc/config.gz CONFIG_RK_VCODEC=y Note that in the above example, the Rockchip video CODEC is not built as a module, but included into the kernel. Thus, it does not show up in the list modules check.\nNewer systems may use a different option as in the configuration below:\n$ zgrep HANTRO /proc/config.gz CONFIG_VIDEO_HANTRO=m CONFIG_VIDEO_HANTRO_ROCKCHIP=y ","permalink":"/documentation/Pinebook_Pro/Software/Tuning/","tags":null,"title":"Tuning"},{"categories":null,"contents":"This is a collection of tutorials and frequently asked questions for the PineTab2.\nTutorials Putting the Device into Maskrom Mode To recover from a bad eMMC/SPI flash, plug the included debug adapter into the charging USB-C port and switch the white switch to its \u0026ldquo;ON\u0026rdquo; position to bypass eMMC/SPI boot. This tries to boot from SD, and if no SD is inserted, enters Maskrom mode.\nRecovery from non-booting device Warning You cannot use a virtual machine for this tutorial as rkdeveloptool does not function as intended. Note Before trying this, try the Maskrom instructions above by changing the debug adapter switch to \u0026ldquo;ON\u0026rdquo; to bypass the internal storage to boot the factory image off an SD Card. If this doesn\u0026rsquo;t work you may proceed with this tutorial. There may be situations where the device refuses to turn on and you cannot see anything coming up through UART. This may indicate that your device is bricked. The PineTab2 includes a debug adapter which allows the user to access Maskrom mode. On it\u0026rsquo;s own this mode is useless as the user requires a miniloader from Rockchip to access any rkdeveloptool commands.\nInstall rkdeveloptool\nFirst you must install rkdeveloptool if you haven\u0026rsquo;t already. You can find instructions on the Rockchip wiki.\nClone\ngit clone https://github.com/rockchip-linux/rkdeveloptool.git\nInstall dependencies\nsudo apt-get install libudev-dev libusb-1.0-0-dev dh-autoreconf pkg-config libusb-1.0\nCompile\nautoreconf -i ./configure make make install Put device into Maskrom mode\nThe debug adapter, bottom port is for UART and the top one is for maskrom\nTurn off your PineTab2 by holding the power button for around five seconds. Then grab your debug adapter, make sure the Maskrom switch is in the \u0026ldquo;ON\u0026rdquo; position, plug it into your PineTab2 and plug a USB-C cable into the top port and into your computer.\nCheck that your device is in Maskrom mode by typing lsusb into a terminal. If it displays Fuzhou Rockchip Electronics Company Device then it has successfully entered Maskrom mode.\nTroubleshooting\nIf you only see QinHeng Electronics USB Serial (UART) either try switching USB-C ports on the adapter or plugging in both adapter ports into your computer. Boot miniloader using Maskrom\nTo issue any commands using rkdeveloptool you must first load a Rockchip miniloader through Maskrom.\nNote The zip is hosted directly on this website. Download MiniLoaderAll.bin.zip\nOnce you download and unzip the miniloader, issue this command using rkdeveloptool.\nrkdeveloptool db MiniLoaderAll.bin\nNote This command downloads the loader to the device temporarily. If you powered off the device and wish to enter Maskrom and issue rkdeveloptool commands you must follow the above instructions again. Once the command completes, wait for the device to reappear in lsusb. Make sure it has a different name than before. Be patient as it can take ~20 seconds.\nFuzhou Rockchip Electronics Company Device USB-MSC\nRecovery to factory firmware\nTo make sure the only boot option for the device is via SD Card, erase the internal storage.\nrkdeveloptool ef\nYou will have to wait for a while until it has finished. Once the command has completed, force power off the device and place an SD Card with the DanctNix factory firmware into the card slot.\nDownload factory image\nhttps://echo.danctnix.org:7269/factory_images/pinetab2/\nNote The factory image is flashed to a microSD card and it will overwrite the eMMC installation after booting. Info Newer images use the volume and power button for selection at boot instead of the keyboard. Screen Rotation Auto-rotating the Screen Auto-rotation is handled by your operating system. However, the following general steps should work on distributions that support iio-sensor-proxy:\nTo enable auto-rotation, install the iio-sensor-proxy package: sudo pacman -S iio-sensor-proxy and reboot. Some desktop environments, such as KDE, default to only allowing screen rotation while in tablet mode (detached from the case.) To enable it with the keyboard attached, go to System Settings\u0026ndash;\u0026gt;Display and Monitor -\u0026gt; Display Configuration -\u0026gt; Uncheck \u0026ldquo;Only when in tablet mode\u0026rdquo; and click \u0026ldquo;Apply.\u0026rdquo; Rotating the Login Screen Login screen orientation is handled by your operating system. Below are the instructions for the SDDM login screen that ships with the factory image:\nBy default, the login screen is set to display in portrait mode. If you wish to change it to landscape mode to match the keyboard while in the case, use the following steps (Credit to chzbacon) :\nInstall necessary software: sudo pacman -S xorg-xrandr xorg-xinput Edit /usr/share/sddm/scripts/Xsetup. For example, using nano: sudo nano /usr/share/sddm/scripts/Xsetup and add the following two lines to the end of file: xrandr --output DSI-1 --mode 800x1280 --rate 60.00 --rotate right xinput set-prop \u0026quot;pointer:Goodix Capacitive TouchScreen\u0026quot; --type=float \u0026quot;Coordinate Transformation Matrix\u0026quot; 0 1 0 -1 0 1 0 0 1 Now edit /etc/sddm.conf.d/sddm.conf, for example: sudo nano /etc/sddm.conf.d/sddm.conf and add the following two lines (case sensitive): [X11] DisplayCommand=/usr/share/sddm/scripts/Xsetup Reboot, and your login screen should now display in landscape mode. Frequently Asked Questions General How does the PineTab2 compare to the Pinebook Pro? It’s slower, as it is intended to be a successor to the PineTab1, not the Pinebook Pro. It’ll still handle web browsing, video playback and documents fine though.\nWhat is the Performance of the PineTab2 compared to the PineTab-V? The PineTab2 is notably faster than the PineTab-V. You can see this by comparing the Quartz64 sbc-bench results to the Star64 ones. Performance should not be a factor of consideration when purchasing a PineTab-V.\nI am a casual user with minimal Linux experience. Is this device for me? The PineTab 2 is considered early release at this point, and the community is expected to develop support for it over time. For example, the Known issues page details several features that are not yet fully working. You may at times need to troubleshoot this device and some development experience is ideal if you want to realize the tablet’s full potential at this stage.\nFor these reasons, the PineTab2 may not be the ideal device for casual users. However, if you feel up to the challenge and want to learn while joining a great community, you are more than welcome! Please join one of our chat platforms: the community is always happy to help!\nWhat works, what doesn\u0026rsquo;t? Please see Known issues.\nI only know Python, can I help with drivers? Drivers are (at least typically) written in the C programming language. Unfortunately, there is no way to \u0026ldquo;code drivers in Python\u0026rdquo; because usually drivers need to access and process memory allocation directly. If you feel like this is interesting to you, we suggest you to spend some time learning the C programming language, maybe with an emphasis in device driver development. The good news is that, since you already know a programming language, you already know part of the skill.\nIn short, you can only help with drivers development if you learn the C programming language first.\nHardware Does the Tablet support a Pen? No, adding a digitiser for pen inputs would make the price too high.\nIs there SPI Flash? Yes! A 128 Mbit flash chip (sk25lp128) is reportedly present on production devices.\nSoftware What operating systems are currently available? The PineTab2 uses ARM operating systems. Please see Software for a current list of software releases.\nHow can I install an operating system on the SD card / eMMC? See the article Software.\nCan I run Android on it? Theoretically yes, practically there’s little chance anyone wants to make a well-supported Android build for this device. If you’re looking for an Android tablet, buy any mainstream tablet, and you’ll get better value for your money.\nHowever, if you just need to run a few simple android apps, you might want to have a look at Waydroid which can be installed on Arch Linux ARM using the following command: sudo pacman -S waydroid\nBooting What\u0026rsquo;s the boot order for SD cards and eMMC? The SPI and the internal memory (eMMC) have a higher boot priority than the microSD card. Please see the Software for more detailed information.\nCan I install a different OS on my PineTab2? Yes! While all PineTab2 come with an OS preinstalled, you are free to use any OS on the integrated storage (the eMMC) or an SD card. See Software for how to install them.\nBluetooth The Bluetooth isn\u0026rsquo;t working The BES2600 Bluetooth driver still needs to be implemented. Please see the Networking Using USB section above for a workaround.\nWi-Fi The Wi-Fi isn\u0026rsquo;t working The BES2600 Wi-Fi driver needs major cleanup and bugfixing: at the moment it causes system crashes. Please see the Networking Using USB section for a workaround.\nVideo Can PineTab2 play back DRM content such as Netflix? Yes, though the specific implementation depends on your installed operating system.\nOn the default Arch Linux Arm: Widevine, using the widevine-aarch64 package in the AUR is working, and was demonstrated on the PineTab2 using Paramount+ and Disney+. Install it (yay -S widevine-aarch64), run the included register script to get Firefox to recognize it, and it should start working.\n","permalink":"/documentation/PineTab2/Software/Tutorials_and_FAQ/","tags":null,"title":"Tutorials and FAQ"},{"categories":null,"contents":" Tip It is helpful to have a debugging serial cable for this. Building U-Boot manually Prerequisites These instructions are written with a host Arch Linux desktop system in mind.\nThis guide will be especially useful if you are looking to overclock the ram on your PinePhone following the information found here.\nYou must have these packages installed: dtc swig bc aarch64-linux-gnu-gcc\nIf you are using a different system such as Ubuntu, there are plenty of cross compilation instructions available online with which you can grab the needed package names from, however you should be able to follow these instructions with these packages installed: build-essential bison flex swig gcc-aarch64-linux-gnu\nCompilation Tip This guide is written with the PinePhone in mind. On other devices you will need to set a different platform variable and likely use a different U-Boot source with patches oriented towards your device. Note by default these instructions utilize all of your computers cores to compile thanks to the -j and $(nproc) parameters. If you wish to only use one core to compile, or change the number of cores used for example to only two cores, then you can either completely remove the -j$(nproc) parameter from the make commands, or just take off $(nproc) and add the number of threads you want used in it’s place: -j4\nFirst, You need to compile the ATF (Arm Trusted Firmware):\ngit clone https://github.com/crust-firmware/arm-trusted-firmware/ cd arm-trusted-firmware export CROSS_COMPILE=aarch64-linux-gnu- export ARCH=arm64 make PLAT=sun50i_a64 -j$(nproc) bl31 cd .. After the ATF is compiled clone u-boot and copy the bl31.bin file into the u-boot directory.\ngit clone https://gitlab.com/pine64-org/u-boot.git cd arm-trusted-firmware cp build/sun50i_a64/release/bl31.bin ../u-boot/ cd .. Tip You cannot build Crust if you do not have the or1k musl toolchain installed. This toolchain is not usually available in distribution repositories and will have to be manually installed to the system. The following text will show a simple way to install the toolchain. Download the toolchain’s archive: https://musl.cc/or1k-linux-musl-cross.tgz\nExtract the compressed archive: tar zxvf or1k-linux-musl-cross.tgz\nMove the extracted archive to wherever you would like to install the toolchain to. In these instructions it will simply be installed to the users documents folder.\nThe final step is to edit your .bashrc and add the following to the end:\n# Path for or1k toolchain export PATH=\u0026#34;$PATH:/home/USER/Documents/or1k-linux-musl-cross/bin/\u0026#34; After you’ve completed that you can close out the terminal and reopen it and proceed to the following instructions.\ngit clone https://github.com/crust-firmware/crust cd crust export CROSS_COMPILE=or1k-linux-musl- make pinephone_defconfig make -j$(nproc) scp cp build/scp/scp.bin ../u-boot/ cd .. Tip If you do not wish to have Crust in your U-Boot build, then you can skip exporting SCP cd u-boot/ git checkout crust export CROSS_COMPILE=aarch64-linux-gnu- export BL3bl31.bin export ARCH=arm64 export SCP=scp.bin make distclean make pinephone_defconfig make all -j$(nproc) U-Boot installation Once successfully compiled you can proceed to flash the device\nWarning Replace [CHANGE THIS] with the location of your SD card and make sure you are using the proper location. Failure to do so can result in data loss. sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/[CHANGE THIS] bs=1024 seek=8 Tip If you are compiling U-Boot in order to overclock your DRAM you can check if it was successful by reading the values of /sys/kernel/debug/clk/clk_summary p-boot multi-bootloader One of the smallest and fastest PinePhone bootloaders, it was developed by Ondrej Jirman with the ability of booting multiple distributions on the PinePhone in mind.\nMore information can be found here\nExternal Links Sunxi U-Boot Wiki\nU-Boot build instructions\nor1k toolchain download\n","permalink":"/documentation/General/U-Boot/","tags":null,"title":"U-Boot"},{"categories":null,"contents":" This shows signals from the Pinebook Pro’s point of view, so connect the adapter’s RX to ring 1, and TX to the tip. See also the Pine64 official document describing this.\nSerial console UART is enabled by flipping the UART switch to the ON position (item 9). To do so, you need to remove the Pinebook Pro’s bottom cover by following the disassembly and reassembly guidelines. The OFF position is towards the touchpad, while the ON position is towards the display hinges.\nWith the UART switch in the ON position, the console is relayed via the headset jack, on which the audio output is no longer available. Please ensure that you are using a 3.3 V UART interface (such as the CH340, FTDI-232R, or PL2303, which are available in both 3.3 V and 5 V variants) to avoid damage to the RK3399 SoC. Older version of the serial console cable sold by the Pine Store used wrong voltage level and should not be used, see this forum thread for further information. Recent version of the same cable uses the right voltage level, which can also be checked by measuring the voltage on the TX ring.\nInsert the USB plug of the cable into a USB port on the machine that you will use to monitor the Pinebook Pro’s serial console, ensuring that the audio jack of the serial cable is be fully inserted into the Pinebook Pro’s headphone port. Run lsusb in a terminal and you should see a line similar to this:\nBus 001 Device 058: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Serial console output should now be accessible on the respective machine using a terminal emulator, such as screen, picocom or minicom. Here are a few examples of how to invoke a terminal emuator:\nscreen /dev/ttyUSB0 1500000 picocom /dev/ttyUSB0 -b 1500000 minicom -D /dev/ttyUSB0 -b 1500000 ","permalink":"/documentation/Pinebook_Pro/UART/","tags":null,"title":"UART"},{"categories":null,"contents":" Basic non-stock PineNote UART dongle\nThe USB UART dongle delivered with the PineNote allows you to have access to its serial console via USB-C Debug Accessory Mode (DAM) without having to disassemble the device. The factory-installed operating system runs the serial console at the 1,500,000 bps speed, 8 data bits and 1 stop bit, no parity, and no flow control. The USB-C male end should go into the PineNote and the female end can be connected with a standard USB-C cable to your computer.\nIt is relatively easy to build your own UART interface with a USB-C breakout board (for example https://www.ebay.com/itm/275407037613), two resistors and a 3.3V USB serial adapter. It is basically just two 1K pull up resistors (R3, R4), the data sheet values of 10K isn’t whats on the real hardware, see the schematic. The pull ups enable the serial output on SBU1 and SBU2 you can use with any 3.3V USB serial adapter.\nThe UART dongle is not necessary to flash the PineNote, but is essential if something goes wrong to fix it without having to open the case.\nThis page contains information on creating and using a UART dongle for the PineNote. The PineNote was shipped with a compatible UART dongle, but replacements are not available to order in case of loss or hardware fault. Thankfully it is not difficult to make your own from easily-acquired components and a small bit of soldering.\nFear not if you’ve never soldered anything before! This serves as an excellent first soldering project. Borrow the tools from a friend, local hackerspace, or tool library. Pine64 also makes a nice soldering iron themselves, the Pinecil.\nA PineNote UART dongle enables you to:\nInteract with the system boot menu Read system events in real time as the PineNote is used Fix the PineNote without opening the case if something goes wrong while flashing it Since the PineNote is an embedded system, interfacing with it during boot is more complicated than with an ordinary computer. The UART dongle enables you to do this.\nThe PineNote factory firmware runs UART at a baud rate of 1500000 bps, 8 data bits, 1 stop bit, no parity and no flow control. The process by which the PineNote design was modified to include closed-case UART is documented here.\nStock dongle The stock UART dongle included with the PineNote was a simple device plugging directly into the PineNote’s USB-C port. The dongle exposed a female USB-C port, which the user plugged into to get UART access. This design unfortunately ruled out passthrough USB connections, where the user connects to the PineNote via UART and USB simultaneously. The dongle is not currently available for purchase.\nFront\nBack\nCreating a dongle A typical self-built PineNote UART dongle design has the following components:\nA USB-C breakout board with a male connector exposing the 24 pins of the PineNote’s USB-C port A USB-UART adapter, to plug into a USB port of the computer you’ll use to interface with the PineNote Jump wires to connect specific breakout board pins to pins on the USB-UART adapter Two 1,000 Ohm through-hole resistors to splice into the jump wires Electrical tape or heat shrink to wrap connectors and prevent shorts You will also need the following tools:\nSoldering iron with solder Wire cutters \u0026amp; strippers The PineNote’s internal UART system is documented in this schematic. The purpose of all 24 USB-C pins is documented on the USB-C Wikipedia page.\nWe are interested in three sets of pins:\nThe SBU1 (A8) and SBU2 (B8) side band use pins The CC1 (A5) and CC2 (B5) configuration channel pins The GND ground return pins (A1, A12, B1, and B12) In the PineNote UART schematic you can see (on the bottom right diagram labeled USB_TYPEC_Male) the side band pins are given the labels UART2_TX_SUB1 for A8 and UART2_RX_SUB2 for B8. The first (TX) is used for transmitting data and the second (RX) is used for receiving data, from the perspective of the PineNote. Also note the configuration channel pins labeled TYPEC_CC1 for A5 and TYPEC_CC2 for B5. The diagram shows they must be connected to a 3.3V source in parallel, mediated by resistors. Per the USB-C standard, when these pins are pulled high this indicates the device should enter Debug Accessory Mode; connecting them to a voltage source \u0026amp; limiting the current with pull-up resistors accomplishes this. The schematic indicates 10,000 Ohm resistors, but community member Visti Andresen (talpadk) experimented and found 1,000 Ohm resistors work better. Our mission is to wire up pins from a USB-UART adapter to a USB-C breakout board following these requirements.\nBuying components There are many possible USB-C breakout board designs available for purchase online. One particularly useful design is a \u0026ldquo;passthrough\u0026rdquo; or \u0026ldquo;intercept\u0026rdquo; style, with both male and female USB-C ports. This design is more versatile in case you want to reuse it in other projects, and also enables you to connect to the PineNote via UART and USB at the same time. An example of this product can be found here, although you are encouraged to shop around for cheaper options. If you’re fine with a bit more soldering, there is a very cheap one here.\nSimilarly, there are many USB-UART adapter designs available. These devices plug into your computer and expose a number of pins themselves, connecting to specific pins on the breakout board with jump wires. It is important to get a 3.3V model, or at least a model with the option of 3.3V, as a 5V source might fry the PineNote. Here is one example with jump wires included, although you are again encouraged to shop around for alternatives.\nAll other necessary components of our UART dongle are readily \u0026amp; cheaply available in many locations.\nSplicing resistors The desired end result; wrap removed from resistors for illustration purposes.\nThis is the only difficult part of the whole process. Your goal is to create a Y-shaped jump wire with 1,000 Ohm through-hole resistors spliced into each of the twin arms. The solitary leg will connect to a 3.3V source on your USB-UART adapter. The twin arms will connect to the configuration channel pins on your USB-C breakout board. Per the USB-C standard, when these pins are pulled high this indicates the device should enter Debug Accessory Mode; connecting them to a voltage source \u0026amp; limiting the current with pull-up resistors accomplishes this.\nFor this project you’ll need:\nA soldering iron with solder Wire cutters \u0026amp; strippers 2x jumper wires, male/female as compatible with your board designs 2x 1,000 Ohm through-hole resistors Electrical tape or heat shrink wrap Consider buying extra jumper wires and resistors in case you mess up. Also double-check that you have 1K resistors with this color code calculator. Although the PineNote UART schematic says to use 10K Ohm resistors, community member Visti Andresen (talpadk) experimented and found 1K is more appropriate.\nAssemble your Y-cable as follows:\nGraft one jump wire onto the other to form a Y shape using this technique, ensuring solitary leg end is compatible with your USB-UART adapter Splice resistors into the twin arms using this technique Splice remaining jump wire onto the ends of the resistors, ensuring ends are compatible with your USB-C breakout board Cover all exposed wire \u0026amp; resistors with electrical tape or heat shrink wrap Assembly Once you have acquired all necessary components, assemble the UART dongle as follows:\nConnect a jump wire from the GND pin on the USB-UART adapter to any one of the four GND pins on the USB-C breakout board (A1, A12, B1, or B12) Connect a jump wire from the RXD pin on the USB-UART adapter to the UART2_TX_SUB1 SBU1 pin on the USB-C breakout board (A8) Connect a jump wire from the TXD pin on the USB-UART adapter to the UART2_RX_SUB2 SBU2 pin on the USB-C breakout board (B8) Connect your Y-shaped jump wire from the 3.3V source pin on the USB-UART adapter to the CC1 and CC2 pins on the USB-C breakout board (A5 and B5) Wrap all metal connectors in electrical tape or heat shrink to prevent accidental shorts Be very certain of your connections for the 3.3V source and its cable, as there is a real risk of irreparably frying your PineNote if they’re wrong! Especially be sure you are connecting to a 3.3V source and not a 5V source.\nNote that if you mix up the TX/RX pins, it will still work but the USB-C breakout board will just plug into the PineNote upside down. You can therefore choose which orientation you want by swapping the TX/RX pin connections. Experience shows that RX/TX-TX/RX connections will have the PineNote face down while connected, while RX/RX-TX/TX connections will put the PineNote face up.\nUsing the dongle First, use your UART dongle to physically connect your PineNote to your computer:\nPlug the USB-UART adapter into one of your computer’s USB ports Plug the USB-C breakout board into the USB-C port on the bottom of your PineNote; the orientation matters, so try both and remember which one works Once the hardware is connected, we need some program on your computer to communicate over that connection with 1500000 (1.5 million) bps, 8 data bits, 1 stop bit, no parity and no flow control.\nHere’s how you do that:\nIdentify the USB-UART adapter in your /dev directory by running ls /dev with it plugged in, unplugging it, then again running ls /dev and seeing what changed; it is likely to be called /dev/ttyUSB0 Check your permissions; run ls -l /dev/ttyUSB0 to see which groups have access to the dongle (probably dialout or uucp), and add your user to that group; remember you need to log out before group changes take effect Install minicom (or some other option, but the instructions below are written for minicom) In a terminal window, run minicom -D /dev/ttyUSB0 -b 1500000 or run minicom --setup to specify these settings by default Once the software is set up, power-cycle your PineNote; as the system boots you should see text appearing in your terminal window. You can exit the session with ctrl+a x then pressing Enter to confirm. Run man minicom for more details.\nSending commands Pressing ctrl+a in minicom enables you to send keystrokes to your PineNote. The most important of these is ctrl+c, which if sent during boot will put you in the U-Boot command prompt. You can then type help to list possible commands.\nTroubleshooting If you don’t see any text in your terminal as the PineNote boots, or the text is garbled, try the following:\nEnsure your GND, RX/TX, and CC jump wires are connected to the correct pins on both the USB-UART adapter and the USB-C breakout board Connect your USB-C breakout board to your PineNote in the opposite orientation Run minicom as sudo in case your user doesn’t have appropriate permissions Ensure you are setting the baud rate to 1500000 (1.5 million), and (less importantly because these are probably used by default) 8 data bits, 1 stop bit, no parity and no flow control If you can see text but are having trouble sending ctrl+c to the PineNote during boot:\nBe sure you’re typing ctrl+a first, or whatever escape sequence your terminal emulator uses Send it right as the PineNote is booting, before the loading bar appears on screen Double-check your Y-shaped pull-up resistor cable; if this isn’t working properly you’ll probably be able to read text but not send text USB passthrough If your USB-C breakout board has a passthrough/intercept design, you can connect to your PineNote over USB and UART at the same time. This can be useful when you’re doing development work on the PineNote boot process so you don’t have to continually reconnect cables. You’ll need a USB-A to USB-C cable, connecting directly from your computer’s USB-A hub to your USB-C breakout board’s female USB-C port. It’s important to connect directly from USB-A, without any intermediate USB-C components. Note that connecting a live USB cable to your USB-C breakout board in this way dramatically increases the danger of frying your PineNote with a short, so you should only do this if all connectors are safely wrapped in electrical tape.\n","permalink":"/documentation/PineNote/Development/UART/","tags":null,"title":"UART"},{"categories":null,"contents":" Internals of the RockBox with the UART contacts visible on the bottom right\nA serial console can be connected to the RockBox to retrieve the UART boot logs. A device such as a USB to TTL converter can be used to connect the RockBox. Simply set the USB device to 3.3 volts and connect GND to the GND connector on the mainboard, RTX to TX and TXD to RX. The fourth unlabelled contact on the mainboard should not be connected.\nNote Unlike the ROCKPro64, connecting TXD does not prevent the device from booting up. Connect the USB device to the PC and use a tool such as screen to display the serial output:\nscreen /dev/ttyUSB0 1500000 Then power up the RockBox and enjoy the serial output on the PC.\nTo enable UART output in the OS as well (otherwise the output would stop at \u0026ldquo;Starting kernel \u0026hellip;\u0026rdquo;), console=ttyS2,1500000n8 can be added to the append line in the /boot/extlinux.conf file when using EXTLINUX.\n","permalink":"/documentation/RockBox/Development/UART/","tags":null,"title":"UART"},{"categories":null,"contents":"The UART serves as a console for early boot and kernel messages, and also offers access to a root shell in the factory test image.\nConnecting the UART adapter UART Adapter\nThe UART adapter allows access to the UART through the USB 2.0 Type-C port:\nInsert the UART adapter face-up in the USB 2.0 Type-C port (the USB port furthest from the power button). Connect a USB cable from another computer to the port on the adapter marked \u0026ldquo;DEBUG\u0026rdquo;. The green LED on the adapter should light up. The other adapter port can be connected to USB power if you don’t want to run the tablet on its battery. In a terminal window on the other computer, use tio, screen, minicom, or another application that supports serial port communication to connect via USB serial at 115200 bit/s 8N1 (8 data bits, no parity, 1 stop bit):\ntio /dev/ttyUSB0\nscreen /dev/ttyUSB0 115200\nminicom -D /dev/ttyUSB0 -b 115200 Install one of the above from your distribution’s package manager if none are already installed. The device may have a different name, particularly if multiple USB serial devices are connected. On macOS it will have a name like /dev/tty.usbserial-_nnnn_. If Permission denied is reported, you may need to be added to the group that can access the port with a command like sudo usermod -a -G dialout $USER. Then log out and log back in or use a command like newgrp dialout to create a new shell in that group. Ubuntu-based distro users may encounter the error, \u0026ldquo;cannot open /dev/ttyUSB0: No such file or directory\u0026rdquo;. If this occurs, check the output of sudo dmesg --follow and unplug/replug the USB to look for any errors. If you see an error like, \u0026ldquo;usb 1-1: usbfs: interface 0 claimed by ch341 while \u0026lsquo;brltty\u0026rsquo; sets config #1\u0026rdquo;, then the brltty service is likely conflicting with this device. Brltty provides access to blind users who use a braille display; if you do not need this service, try disabling it using these commands:\nsudo systemctl stop brltty-udev.service\nsudo systemctl mask brltty-udev.service\nsudo systemctl stop brltty.service\nsudo systemctl mask brltty.service The switch on the UART adapter has no function on the PineTab-V; the boot order is controlled by the Vol-/Vol+ switches.\n","permalink":"/documentation/PineTab-V/UART_adapter/","tags":null,"title":"UART adapter"},{"categories":null,"contents":" The UART adapter\nThe USB-C UART adapter can be connected to the PineTab2 to debug boot issues at the early boot:\nPlug the adapter face-up in the USB-C port furthest away from the power button. If all the lights are lit, you have the wrong port: only the green light should be lit when you first plug it in. Plug USB-C cable into the port on the adapter marked \u0026ldquo;DEBUG\u0026rdquo; (the other port can be used as a power delivery passthrough so you can charge and debug at the same time) Set the \u0026lsquo;SD BOOT MASKROM\u0026rsquo; switch to OFF if no SD card is inserted and you do not plan to boot from an SD card. If the switch is set to ON without an SD card present, the tablet may fail to boot. Open a terminal window Install minicom or screen via your distribution’s package manager, if you don’t have it installed already Connect via minicom using sudo minicom -D /dev/ttyUSB0 -b 1500000 or via screen using sudo screen /dev/ttyUSB0 1500000 Ubuntu-based distro users may encounter the error, \u0026ldquo;cannot open /dev/ttyUSB0: No such file or directory\u0026rdquo;. If this occurs, check the output of sudo dmesg --follow and unplug/replug the USB to look for any errors. If you see an error like, \u0026ldquo;usb 1-1: usbfs: interface 0 claimed by ch341 while \u0026lsquo;brltty\u0026rsquo; sets config #1\u0026rdquo;, then the brltty service is likely conflicting with this device. Brltty provides access to blind users who use a braille display: if you do not need this service, try disabling it using these commands: sudo systemctl stop brltty-udev.service sudo systemctl mask brltty-udev.service sudo systemctl stop brltty.service sudo systemctl mask brltty.service ","permalink":"/documentation/PineTab2/Development/UART_adapter/","tags":null,"title":"UART adapter"},{"categories":null,"contents":" PhoenixCard\nSupported Displays\nUnsorted (Single Page)\nPhoenixCard How to Create MicroSD Card Android Image for Pine A64 What do I need? The PhoenixCard software from Allwinner. You can download it here A firmware image (.img files) A SD-Card (best Class 10 with 8GB or more SD-Card) - backup everything first, the Card will be formatted! An external SD-Card Reader A Windows PC Step to create the SD-Card Extract the PhonixCard-xx.rar file into an empty directory. Navigate into the directory where you installed PhoenixCard and start PhoenixCard.exe. Click DiskCheck and choose the drive with your SD-Card Click Img File and choose the file you want Write Mode must be set to Startup Press Burn Wait until the burning process is finished (you will see the progress in the progress bar and the notification window) Booting Up the SD-Card Insert the SD-Card into the Pine64 and Power-up On the first time boot-up, it might take up to 5 minute for the system to get ready On the sub-sequence boot-up, it will only take about 40 to 60 second for the system to get ready Related Reference Easily Create an Android Bootable SD Card for Allwinner A80 Devices with PhoenixCard Tool PhoenixCard Tutorial YouTube Video Supported Displays Important Contribute to it by looking for MIPI-DSI panels in drivers/gpu/drm/panel/ and filling out the table from their data sheets MIPI-DSI Displays MIPI-DSI Displays are displays that follow the MIPI-DSI standard. Such displays can be connected to various PINE64 Single Board Computers.\nMIPI Channels and Lanes The MIPI Lanes number is given in a format of channels×lanes. Before buying one, make sure that your SBC has enough channels and lanes to drive the display!\nROCKPro64: 2×4 Quartz64 Model A: 1×4 Quartz64 Model B: 1×2 SOQuartz: 1×4 + 1×2 Displays With Mainline Drivers These displays have free and open-source drivers in the main Linux kernel tree.\nManufacturer Part Number Size Resolution Panel Technology MIPI Lanes Feiyang FY07024DI26A30-D 7.0\u0026quot; data-sort-value=\u0026ldquo;614400\u0026rdquo; 1024×600 TN? data-sort-value=\u0026ldquo;4\u0026rdquo; 1×4 Sharp LQ101R1SX01 10.1\u0026quot; data-sort-value=\u0026ldquo;4096000\u0026rdquo; 2560×1600 TN? data-sort-value=\u0026ldquo;8\u0026rdquo; 2×4 Sharp LS060T1SX01 6.0\u0026quot; data-sort-value=\u0026ldquo;2073600\u0026rdquo; 1080×1920 ? data-sort-value=\u0026ldquo;4\u0026rdquo; 1×4 LVDS Displays LVDS Displays are displays that follow the LVDS standard.\nLVDS Hardware Support Only Quartz64 Model A seems to support LVDS panels.\nDisplays and Timings TBD\n","permalink":"/documentation/Unsorted/_full/","tags":null,"title":"Unsorted (Single Page)"},{"categories":null,"contents":" Note Devices shipped before July 2021 were pre-installed with InfiniTime 0.7.1 and an older bootloader. This features green text PINE TIME on boot, and should be updated to the new bootloader as described below.\nNewer devices already have a \u0026gt;=1.0.0 bootloader and do not need updating. You can identify these with a green Pinecone image on boot.\nWarning Do not follow these steps on devices which shipped with the 1.0.1 bootloader or later. You will downgrade the bootloader and (soft-)brick your watch! Congratulations on receiving your new PineTime!\nSo now you’re probably wondering exactly how on earth do you go about upgrading your watch to the latest and greatest version of InfiniTime - you know, that version you’ve seen all those great pictures, videos and reviews of. To those of us that are developing stuff for it, it’s pretty easy and straightforward, but like with all technology, it is a bit tricky.\nWarning Some people ran into issues during the update process that would temporarily make their watch unusable (display frozen or blank). The only know workaround consists of waiting for the battery to drain completely and try again. With the display off, and battery fully charged, you can expect a wait of 5-7 days so it is best to not fully charge it. If it freezes with the display on, it will likely be flat by the end of the day. We’ve never heard of any PineTimes that were permanently bricked (were not recoverable), though. In a nutshell, you need to:\nCharge your watch, but not to 100% - keep it at approximately 50% - for the reason described above. Update InfiniTime Update the bootloader Install the recovery firmware Update Process So how do you do this? Where do you start? Well, with a sealed PineTime, your only easy option is via Over The Air (OTA) Device Firmware Update (DFU), which is done via Bluetooth. There are a couple of different ways and apps you can use to do this. If you have an Android device, you can use Gadgetbridge or NRFConnect (NRFConnect is available on iOS devices as well). Otherwise, if your laptop or desktop computer has Bluetooth and runs Linux, you can use Siglo or Amazfish. You can also use these applications on your Pinebook Pro or Pinephone if you happen to have those devices.\nThe reason for installing the updates in the specified order is because newer versions of InfiniTime have a more robust Bluetooth update process, and since we’re updating everything over Bluetooth, the fewer retries and failures from that you have the better. It will still sometimes disconnect mid update, meaning you’ll need to try again, and possibly restart the watch a few times as well. And since the recovery firmware is new to the 1.0.0 version of the bootloader, it’s best to update that last.\nThis video shows the bootloader and recovery firmware installation procedure.\nThis video shows the bootloader installation and firmware update using Amazfish.\nYou can also read a detailed installation procedure in the documentation of the bootloader.\nUpdate InfiniTime To update the main InfiniTime app, you want to flash pinetime-mcuboot-app-dfu-1.0.0.zip.\nAfter updating InfiniTime, ensure that you validate the firmware to prevent it from being automatically reverted/rolled back if your watch is reset/restarted. To do this, swipe right to access the quick actions panel, press the gear/settings icon, swipe up once to show the second page, press on the \u0026lsquo;Firmware\u0026rsquo; option and then on \u0026lsquo;Validate\u0026rsquo;.\nVideo showing validation process\nGadgetbridge Connect your PineTime to GB Download the aforementioned file to your phone Find the file in your file manager \u0026lsquo;Open With\u0026rsquo; Gadgetbridge F/W Installer (method varies by device) - on my phone, it is press and hold, select the file, and then choose \u0026lsquo;open with app\u0026rsquo; from the more options menu Confirm that you wish to apply the update Wait for the update to complete Video showing how to start the update\nNRFConnect (not recommended) The app is closed source and versions after 4.24.3 don’t work with the PineTime. We recommend you use GadgetBridge instead.\nDownload the aforementioned file to your phone. Open NRFConnect Scan for your device Connect to it Choose the DFU option at the top right of the screen Ensure the \u0026lsquo;Distribution packet (ZIP)\u0026rsquo; option is selected, and press OK Select your previously downloaded file Wait for the update to complete Video showing how to start the update\nSiglo If your device was not detected upon start, press \u0026ldquo;Rescan\u0026rdquo; to find it. Select the \u0026ldquo;1.0.0\u0026rdquo; tag Select the aforementioned file/asset. Select \u0026ldquo;Flash It!\u0026rdquo; Amazfish Run Amazfish (service + UI) Pair with you device: Unzip the DFU file to extract the .bin file. Click on \u0026ldquo;pair with watch\u0026rdquo; on the top Select \u0026ldquo;PineTime\u0026rdquo; (if your device is running InfiniTime 0.7.1 or lower) or \u0026ldquo;InfiniTime (if it’s running InfiniTime 0.8+) and choose your device in the list Click on \u0026ldquo;Download file\u0026rdquo; on the top Click on \u0026ldquo;Choose file\u0026rdquo; and select the .bin file you extracted from the DFU file Click on \u0026ldquo;Send file\u0026rdquo; Wait for the update to complete. See it in action!\nUpdate the bootloader To update the bootloader, you want to flash reloader-mcuboot.zip. Once the bootloader is updated, you should notice that the boot logo has changed. Previously, it was a green \u0026ldquo;PineTime\u0026rdquo; logo, and now it is a large pinecone that is progressively drawn in green.\nVideo showing what the InfiniTime 1.0.0 bootloader looks like\nUsing Gadgetbridge Same process as before, but with the file for this step.\nUsing NRFConnect Same process as before, but with the file for this step.\nUsing Siglo Same process as before, but select the \u0026ldquo;0.14.1\u0026rdquo; tag, and the file/asset for this step.\nUsing Amazfish You may need to re-pair with your device by selecting \u0026ldquo;InfiniTime\u0026rdquo; (since you’ve already upgraded to InfiniTime 1.0) in the device type list. Then follow the same process as before, but with the file for this step.\nInstall the recovery firmware Warning Don’t do this before updating the bootloader, otherwise your PineTime will freeze at the end of the process, and you will need to wait for the battery to go flat To install the recovery firmware, you want to flash pinetime-mcuboot-recovery-loader-dfu-0.14.1.zip. You will know when this is running when it shows an InfiniTime logo with a progress bar running across the bottom whilst it is installing the recovery firmware.\nUsing Gadgetbridge Same process as before, but with the file for this step.\nUsing NRFConnect Same process as before, but with the file for this step.\nUsing Siglo Same process as before, but with the file/asset for this step.\nUsing Amazfish Same process as before, but with the file for this step.\nTroubleshooting Sometimes during the update process, the connection will drop, and the update will fail. Your PineTime isn’t broken, most likely the Bluetooth link dropped for a moment, so just try again. Try rebooting your phone, if it keeps failing, try restarting the watch by holding the power button down for approximately 8 seconds. Try to avoid holding down the button with the screen off. Or try with another device, just in case there are compatibility issues.\nVersion 1.0.0 of InfiniTime is merely the first version that was considered sufficiently feature-complete and stable enough for daily use. This isn’t to say there aren’t still bugs present (\u0026lsquo;cause there are!). So there are a few bugs still present in the update process and the bootloader. One unfortunate bug appears to be that sometimes when the watch tries to restart after an update, the bootloader locks up, and the watch won’t turn on. In this case, you will need to wait until the watch battery goes flat, to force the watch to reset. This will most likely involve waiting for a week, and then when you put the watch on the charging cradle, it will power up and you should be right to try again.\nIf you get stuck or have any questions, join us on your preferred chat platform or the product forum. There’s usually someone available who can help, or will get back to you in a few hours.\n","permalink":"/documentation/PineTime/Software/Upgrade_to_InfiniTime_1_0_0/","tags":null,"title":"Upgrade PineTime to InfiniTime 1.0.0"},{"categories":null,"contents":" Upstream Linux kernel DT: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3588-quartzpro64.dts Upstream U-Boot DT: https://github.com/u-boot/u-boot/blob/master/arch/arm/dts/rk3588-quartzpro64-u-boot.dtsi Function Status Component Notes Video Output Needs porting VOP2 Collabora said they’ll work on this. The video output IP on the RK3588 should mostly be the same as the one on the RK356x, but the chip specific stuff will need to be integrated into the vop2 driver. Video Input Needs porting rk_hdmirx Huge 3600 line driver, but generally seems to be in good condition 3D Acceleration Needs writing Needs writing panfrost Collabora said they’ll work on this. New architecture, reportedly needs many changes to the kernel component of Panfrost. Video Decode Needs writing GStreamer only, no ffmpegSource hantro using v4l2-requests VDPU121 handling 1080p60 H.263/MPEG-4, MPEG-1 and MPEG-2 Needs writing rkvdec2 using v4l2-requests Nobody is known to be working on this for now. VDPU346 handling 8K60 H.265, H.264, VP9 and AVS Needs writing rkdjpeg using v4l2-requests User:CounterPillow is doing a little work on this. VDPU720 handling JPEG In reviewSource hantro using v4l2-requests Collabora is working on this. VDPU981 handling 4K60 AV1 Video Encode Needs writing GStreamer only JPEG on VEPU121 Driver already exists, only minor changes needed. Needs writing ? H.264 on VEPU580 Needs writing ? H.265 on VEPU580 Audio Linux Mainline rockchip-i2s-tdm As of 6.2Source CRU Linux Mainline clk-rk3588 As of 6.2Source MMC Linux Mainline sdhci-of-dwcmshc As of 5.19Source pinctrl Linux Mainline pinctrl-rockchip As of 5.19Source GPIO Linux Mainline rockchip-gpio As of 6.1Source I2C Linux Mainline rk3x-i2c Should be the same as RK3399, just needs devicetree work SPI Linux Mainline rockchip-spi Should be the same as previous SoCs, just needs devicetree work PMU In reviewSource rk806 Talks over SPI Regulators Needs porting rk860 Talks over I2C GMAC Linux Mainline dwmac-rk As of 6.1Source Power Domains Linux Mainline rockchip-pm-domain As of 6.1Source CAN Needs porting rockchip_canfd Not broken out on the QuartzPro64, so we probably won’t be the ones porting it SPDIF TX May need porting rockchip-spdif Genuinely just needs the compatible string added, I think, otherwise we’re all good. Not broken out on QuartzPro64 dev board SPDIF RX Needs porting rockchip-spdifrx Not broken out on QuartzPro64 dev board PCIe May need porting rockchip-dw-pcie Downstream driver and upstream are quite different, look into how much work actually needs doing. Seems to be the same controller as rk3568 so maybe none? NPU Needs porting/writing ? rockchip-rknpu USB 2.0 In reviewSource phy-rockchip-inno-usb2 Might have more factors than just the PHY USB 3.0 ? ? SATA Linux Mainline ahci-dwc Just needs the compatible added to the bindings, done here Thermal In reviewSource rockchip-thermal Wifi \u0026amp; Bluetooth ? ? HWRNG Needs porting rockchip-rng The code \u0026amp; DT work is easy to port \u0026amp; working RTC Linux Mainline hym8563 Should only need DT work (see here for an example) OTP In reviewSource rockchip-otp SARADC In reviewSource rockchip_saradc ","permalink":"/documentation/QuartzPro64/Upstreaming_status/","tags":null,"title":"Upstreaming status"},{"categories":null,"contents":" Warning The data presented in this section requires updating. Function Status Component Notes Video Output Linux Mainline rockchipdrm With mpv, you\u0026rsquo;ll need to specify something like mpv --gpu-context=drm --drm-connector=1.HDMI-A-1 to get it to play back on a VT 3D Acceleration Linux Mainline Upstream Mesa lima Very recent version recommended for the best experience. Has weird glitches on HDMI output in weston. Video Decode Linux Staging Broken/Not in ffmpeg hantro_vpu and rockchip_vdec, using v4l2-requests Soon to be moved out of staging, ffmpeg patch set seemingly abandoned, does not work on newer kernels. Git branch with commits Audio Linux Mainline snd_soc_rockchip_* Power Button Linux Mainline rk805_pwrkey If your PWR switch does nothing unless held, this may need to be loaded manually with modprobe or by putting it in /etc/modules-load.d/ Analog Video Output Needs porting rockchip_drm_tve Definitely needs some cleanup before it\u0026rsquo;d be ready for mainline, and needs some dt bindings written. ","permalink":"/documentation/ROCK64/Software/Upstreaming_status/","tags":null,"title":"Upstreaming status"},{"categories":null,"contents":" Quick links Pinecil V1 Quick Start Guide Navigate the Pinecil menus: Guide here. Overview Prep Tasks\nTip Clean new cartridges/tips with isopropyl alcohol (IPA) to remove factory residue before installing (even if it looks clean). If you have no IPA, at least try a paper towel, especially clean the white end with the two silver electric contacts (do not use water; it could get into the seam line on the white end). This resolves issues with jumping temperatures or random no-tip symbol from poor electric contact. Do not try to bend the two internal contacts, they are made of a thin stiff spring metal and could break (not soft copper), but you could wipe them with IPA (including the small PCB pad below the contacts).\n1. Install the tip: The Pinecil comes with a separate heating element, the tip.\nRemove the screw from the front top-side of handle. Then, gently push the tip all the way back until the wide collar/guard is touching the front of the plastic (see \u0026ldquo;File:Pinecilv2-1.jpg\u0026rdquo; (photo). Gently tighten or loosen this screw to install or swap the tip. (careful, tiny screws break easy, if tip does not fall out, it’s tight enough) The bottom front screw should not touch the tip, it only holds the handle together (see Fasteners). Always unplug before swapping tips if you have multiple tips. 2. Supply power: the USB-C port, connected to any supply, is enough power to show the display screen, but not necessarily enough to heat the tip.\nUSB port at 5 volts (i.e., laptop) shows DC Low, this is enough for firmware updates and to view the menu, but not to run the soldering iron. See Power section for details on power options. QC 12V phone chargers will not work, as they are too weak. 3. Heat the tip: plug Pinecil into an appropriate power supply.\nClicking [+] starts the tip heating. The detailed display option shows power draw, current temperature, supply voltage, and time until sleep mode starts. Adjust the target temperature with further clicks of [+] and [-] buttons. Wait a few seconds for the regular display to return, then hold down [-] for a moment to turn the heat off. You can observe the temperature measurement go up and down. Certain settings involve holding down both buttons (see GitHub IronOS for details on firmware settings). 4. Using the Settings Menu:\nTo check the firmware version, hold down the [-] button. It will display something like \u0026ldquo;v2.19.A3BBABC 13-07-22\u0026rdquo;. This is the firmware number and release date, the date is July 13, 2022 in the example. Clicking [-] when heat is off steps through main categories menus to control a variety of settings, see Getting started with menus section. Clicking [-] also returns to the regular display of temperature and supply voltage (this view varies if you activate detailed idle). At other times it may show power draw. Click [-] to scroll to the the main menu section desired (i.e., User Interface). Then click [+] button to change various internal settings. Then click [-] again to go to the next item in the sub-menu. 5. Important notes:\nThe iron will \u0026ldquo;sleep\u0026rdquo;, switching to a lower temperature, after it has been put down for a short time, and heat up again when it is picked up. Calibration of the Tip temperature is usually not necessary and should only be done if the tip is off by +/- 5 °C or temperature is behaving oddly. See instructions to calibrate the tip in the firmware on GitHub IronOS. For Safety, unplug the soldering Iron when not in use or left unattended. To heat up the tip, we need a power supply that can provide at least 12V 3A to run. This is the bare minimum. Pinecil will heat slowly at only 12V/3A. To maximize performance, higher Volts/Amps/Watts is recommended (see Power supplies). Option 1: a USB-C supply that can negotiate up to such a voltage. For good performance and soldering experience, a USB-C PD65W, 20V, 3+ A charger is recommended (suitable for most users). Option 2: a supply with a DC 5525 barrel connector (+ pos center, - neg outside) that supplies anywhere from 12V-21V, 3+ amps (V1 Pinecil) or 12V-24V, 3+ amps (V2 Pinecil). Option 3: use a battery, i.e., an 18V-21V tool Battery with a Power Wheels adapter, and a cable to plug into the Pinecil DC5525 barrel jack. You may have a suitable supply already that could be used, (see Power supplies). While 12V-3A will work, it will not heat the tip as quickly and efficiently as a PD65W-20V USB-C charger or a higher rated DC barrel charger. See warnings about using random DC barrel chargers, not all of them have the correct polarity or DC 5525 style plug and some may be too high of voltage which could damage the Pinecil. Getting Started with the Menu Getting Started Guide in GitHub/IronOS Main Settings Menu: updated list is found in the firmware repository Settings Menu Power settings: settings related to power, battery cells, input voltage. Soldering settings: settings for soldering such as, boost temps, increments for temperature change Sleep mode: power \u0026amp; tip saving, such as sleep mode, sleep temperature, and shutdown modes, motion sensitivity User interface: settings such as, units C/F, display orientation, button reversal, animation speed, brightness, boot logo duration Advanced settings: assorted catchall for settings that don’t fit elsewhere or settings that require some thought before use. Restore default/factory settings is here. It will not change the firmware version, but rather resets the menu back to IronOS defaults. This is good to do after a major firmware update as settings may have been altered and need to be re-selected/customized again to work as expected. Hidden Debug Menus: also available, see GitHub/IronOS ","permalink":"/documentation/Pinecil/Usage/","tags":null,"title":"Usage"},{"categories":null,"contents":" The PINE64 USB LoRa adapter\nThe PINE64 USB LoRa adapter is based on the Semtech SX1262 LoRa module and the CH341 USB bus converter chip. The CH341 chip can be configured in multiple mode to convert USB to various serial and parallel ports. In this case, it’s configured in synchronous serial mode, which allows this chip to convert from USB to the SPI bus needed to talk to the SX1262 LoRa module:\n-------- -------------------------- | | | USB LoRa Adapter | | PC | \u0026lt;--USB--\u0026gt; | CH341 \u0026lt;--SPI--\u0026gt; SX1262 | | | | \u0026lt;--I/O--\u0026gt; | -------- -------------------------- Pins Pinout\nSX1262 Pin Name Description 1 ANT Antenna 2 GND2 3 VREG 4 DCC 5 VCC 6 DIO1 Connected on CH341 Pin 7 7 DIO2 Connected on CH341 Pin6 8 DIO3 Connected on CH341 Pin 5 9 GND 10 MISO SPI MISO (CH341 Pin 20) 11 MOSI SPI MOSI (CH341 Pin 22) 12 SCK SPI clock (CH341 Pin 24) 13 NSS SPI Chip select 14 POR Reset pin 15 Busy Busy pin 16 GND Kernel module for CH341 We need a driver for the CH341 USB bus converter chip. This driver will allow us to send command to the CH341 (SPI messages and access to the GPIOs). I’ve successfully build and run this driver from rogerjames99 on my desktop computer (running Manjaro Linux) and on my Pinebook Pro (ARM64, running Manjaro ARM Linux). For any kernel newer than 3.10 but mandatory for kernels newer than 5.15 you need to use the dimich-dmb fork of the the spi-ch341-usb driver. This fork has updated documentation for the newer kernel interfaces. If this driver gives you problems please drop by any of the social platforms in the Pine64 LoRa chat and give a holler, and if you are using a 5.15 or older kernel you can use the rogerjames99 fork.\n$ git clone https://github.com/rogerjames99/spi-ch341-usb.git or $ git clone https://github.com/dimich-dmb/spi-ch341-usb.git then $ cd spi-ch341-usb $ make $ sudo make install\nOnce the driver is installed, unload the module ch341 if it has been automatically loaded:\n$ lsmod |grep ch341 $ sudo rmmod ch341 On my setup, ch341 would be automatically loaded once I connected my USB adapter. This module drives the CH341 is asynchronous serial mode, which will not work for a SPI bus.\nThen load the new module:\n$ sudo modprobe spi-ch341-usb Plug your USB adapter and check that the module is correctly loaded :\n$ dmesg [20141.872107] usb 1-1.1: USB disconnect, device number 4 [20143.820756] usb 1-1.1: new full-speed USB device number 5 using ehci-platform [20143.973366] usb 1-1.1: New USB device found, idVendor=1a86, idProduct=5512, bcdDevice= 3.04 [20143.973413] usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [20143.973434] usb 1-1.1: Product: USB UART-LPT [20143.975137] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: connect device [20143.975164] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: bNumEndpoints=3 [20143.975183] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: endpoint=0 type=2 dir=1 addr=2 [20143.975206] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: endpoint=1 type=2 dir=0 addr=2 [20143.975229] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: endpoint=2 type=3 dir=1 addr=1 [20143.975254] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs0 SPI slave with cs=0 [20143.975273] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs0 gpio=0 irq=0 [20143.975295] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs1 SPI slave with cs=1 [20143.975313] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs1 gpio=1 irq=1 [20143.975334] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs2 SPI slave with cs=2 [20143.975352] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output cs2 gpio=2 irq=2 [20143.975373] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input gpio4 gpio=3 irq=3 [20143.975394] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input gpio6 gpio=4 irq=4 [20143.975415] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input err gpio=5 irq=5 [20143.975435] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input pemp gpio=6 irq=6 [20143.975456] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input int gpio=7 irq=7 (hwirq) [20143.975478] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input slct gpio=8 irq=8 [20143.975499] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input wait gpio=9 irq=9 [20143.975520] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input autofd gpio=10 irq=10 [20143.975542] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: input addr gpio=11 irq=11 [20143.975564] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output ini gpio=12 irq=12 [20143.975585] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output write gpio=13 irq=13 [20143.975607] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output scl gpio=14 irq=14 [20143.975628] spi-ch341-usb 1-1.1:1.0: ch341_cfg_probe: output sda gpio=15 irq=15 [20143.975650] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: start [20143.975677] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: SPI master connected to SPI bus 1 [20143.977831] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: SPI device /dev/spidev1.0 created [20143.978183] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: SPI device /dev/spidev1.1 created [20143.978552] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: SPI device /dev/spidev1.2 created [20143.978726] spi-ch341-usb 1-1.1:1.0: ch341_spi_probe: done [20143.978735] spi-ch341-usb 1-1.1:1.0: ch341_irq_probe: start [20143.979133] spi-ch341-usb 1-1.1:1.0: ch341_irq_probe: irq_base=103 [20143.979154] spi-ch341-usb 1-1.1:1.0: ch341_irq_probe: done [20143.979162] spi-ch341-usb 1-1.1:1.0: ch341_gpio_probe: start [20143.979220] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=cs0 dir=0 [20143.979229] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=cs1 dir=0 [20143.979237] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=cs2 dir=0 [20143.979245] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=gpio4 dir=1 [20143.979253] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=gpio6 dir=1 [20143.979260] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=err dir=1 [20143.979268] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=pemp dir=1 [20143.979275] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=int dir=1 [20143.979283] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=slct dir=1 [20143.979290] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=wait dir=1 [20143.979298] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=autofd dir=1 [20143.979306] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=addr dir=1 [20143.979314] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=ini dir=0 [20143.979321] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=write dir=0 [20143.979329] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=scl dir=0 [20143.979337] spi-ch341-usb 1-1.1:1.0: ch341_gpio_get_direction: gpio=sda dir=0 [20143.979831] spi-ch341-usb 1-1.1:1.0: ch341_gpio_probe: registered GPIOs from 496 to 511 [20143.981152] spi-ch341-usb 1-1.1:1.0: ch341_gpio_probe: done [20143.981212] spi-ch341-usb 1-1.1:1.0: ch341_gpio_poll_function: start [20143.981291] spi-ch341-usb 1-1.1:1.0: ch341_usb_probe: connected [20144.756250] usbcore: registered new interface driver ch341 [20144.756334] usbserial: USB Serial support registered for ch341-uart With kernel 5.16 and newer the output is shorter:\n$ dmesg [ 6744.813564] usb 1-2.1.1: new full-speed USB device number 21 using xhci_hcd [ 6744.904377] usb 1-2.1.1: New USB device found, idVendor=1a86, idProduct=5512, bcdDevice= 3.04 [ 6744.904383] usb 1-2.1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 6744.904385] usb 1-2.1.1: Product: USB UART-LPT [ 6744.960243] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: output cs0 SPI slave with cs=0 [ 6744.960246] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: output cs1 SPI slave with cs=1 [ 6744.960247] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: output cs2 SPI slave with cs=2 [ 6744.960249] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: input gpio4 gpio=0 irq=0 (hwirq) [ 6744.960251] spi-ch341-usb 1-2.1.1:1.0: ch341_cfg_probe: input gpio5 gpio=1 irq=1 [ 6744.960302] spi-ch341-usb 1-2.1.1:1.0: ch341_spi_probe: SPI master connected to SPI bus 0 [ 6744.960350] spi-ch341-usb 1-2.1.1:1.0: ch341_spi_probe: SPI device /dev/spidev0.0 created [ 6744.960398] spi-ch341-usb 1-2.1.1:1.0: ch341_spi_probe: SPI device /dev/spidev0.1 created [ 6744.960445] spi-ch341-usb 1-2.1.1:1.0: ch341_spi_probe: SPI device /dev/spidev0.2 created [ 6744.960583] spi-ch341-usb 1-2.1.1:1.0: ch341_usb_probe: connected Driver development Kernels 5.14 and older Once the module spi-ch341-usb is correctly loaded, here’s how you can transfer data on the SPI bus (in C):\n/* Open the SPI bus */ int spi = open(\u0026quot;/dev/spidev1.0\u0026quot;, O_RDWR); uint8_t mmode = SPI_MODE_0; uint8_t lsb = 0; ioctl(spi, SPI_IOC_WR_MODE, \u0026amp;mmode); ioctl(spi, SPI_IOC_WR_LSB_FIRST, \u0026amp;lsb); /* Transfer data */ /* TODO: Init buffer_out, buffer_in and size */ const uint8_t *mosi = buffer_out; // output data uint8_t *miso = buffer_in; // input data struct spi_ioc_transfer spi_trans; memset(\u0026amp;spi_trans, 0, sizeof(spi_trans)); spi_trans.tx_buf = (unsigned long) mosi; spi_trans.rx_buf = (unsigned long) miso; spi_trans.cs_change = true; spi_trans.len = size; int status = ioctl (spi, SPI_IOC_MESSAGE(1), \u0026amp;spi_trans); To access GPIOs, you first need to export them (to make them accessible via /sys/class/gpio. As you can see in the dmesg output, GPIOs from 496 to 511 were registered, which means we can export 16 GPIOs. The mapping of these I/O is available in the source code of the driver. For example, pin slct is the 12th, meaning we need to export GPIO 496+12 = 508.\nint fd; if ((fd = open(\u0026quot;/sys/class/gpio/export\u0026quot;, O_WRONLY)) == -1) { perror(\u0026quot;open ini\u0026quot;); exit(-1); } if (write(fd, \u0026quot;508\u0026quot;, 3) == -1){ perror (\u0026quot;write export 508\u0026quot;); } Once exported, the GPIO is available in /sys/class/gpio/sclt (the naming is specified by the driver). You can read the pin in C:\nint fd; if ((fd = open(\u0026quot;/sys/class/gpio/slct/value\u0026quot;, O_RDWR)) == -1) { perror(\u0026quot;open\u0026quot;); } char buf; if (read(fd, \u0026amp;buf, 1) == -1) { perror(\u0026quot;read\u0026quot;); } int value = (buf == '0') ? 0 : 1; You can also write it:\nint fd; if ((fd = open(\u0026quot;/sys/class/gpio/ini/value\u0026quot;, O_RDWR)) == -1) { perror(\u0026quot;open ini\u0026quot;); } if (write(fd, value ? \u0026quot;1\u0026quot; : \u0026quot;0\u0026quot;, 1) == -1) { perror (\u0026quot;write\u0026quot;); } Kernel 5.15 and newer We need some help documenting how these interfaces work|\nThe driver creates these interfaces:\nPin SPI Function GPIO function GPIO name IRQ 15 CS0 - - - 16 CS1 - - - 17 CS2 - - - 19 - Input gpio4 hardware 21 - Input gpio5 software The dimich-dmb fork of spi-ch341-usb works with 5.15+ kernels, but as you can see above it is not configured for the needs of the Pinedio-USB by default. I have started a branch in my fork to work on getting the driver pre-configured for our needs. The branch can be found here. Please feel free to help|And open issues or discussions in the repo if you have problems or ideas how to help. Any improvements to the actual code beyond configuration should be pushed to the temporary upstream.\nSince linux-5.15 binding to spidev driver is required to make slave devices available via /dev/, e.g. for slave 1 on bus 0 as real root (not with sudo):\n# echo spidev \u0026gt; /sys/class/spi_master/spi0/spi0.1/driver_override # echo spi0.1 \u0026gt; /sys/bus/spi/drivers/spidev/bind For all devices handled by spi_ch341_usb driver (again, only as real root):\n# for i in /sys/bus/usb/drivers/spi-ch341-usb/*/spi_master/spi*/spi*.*; do echo spidev \u0026gt; $i/driver_override; echo $(basename $i) \u0026gt; /sys/bus/spi/drivers/spidev/bind; done The documentation found at https://github.com/dimich-dmb/spi-ch341-usb/blob/master/README.md has more information.\nThe 5.15+ driver is not ready yet. But if you are interested in testing, helping to get the configuration right, or working on application development you can build and test the current driver:\n$ git clone -b pinedio https://github.com/UncleGrumpy/spi-ch341-usb.git $ cd spi-ch341-usb $ make $ sudo make install So far this will automatically set up the SPI slave device /dev/spi0.0. It names the ch341-usb device as \u0026ldquo;pinedio\u0026rdquo; this will allow application developers to find the correct gpiochip by name. I need help confirming the correct gpio pins but as of now the driver will setup the following configuration:\nThe driver uses following CH341A pins for the SPI interface.\nPin Name Direction Function SPI (CH341A) 18 D3 output SCK (DCK) 20 D5 output MOSI (DOUT) 22 D7 input MISO (DIN) 15 D0 output CS0 The driver uses the following GPIO configuration.\nWarning It is not sure if these are the correct pins to use| CH341 Pin CH341A Name Function GPIO Name GPIO Configuration SX1262 connection 7 INT# IRQ dio_irq Input DIO1 (IRQ) 8 SLCT BUSY dio_busy Input BUSY 26 RST# Hard Reset dio_reset Output NRESET The function of these pins can be changed from user space by using libgpiod. The command line tools installed with the library (gpioset, gpioget, gpiodetect, gpioinfo and others can be used for bash scripts, etc. and applications should all use the libgpiod interfaces. The /sys/class/gpio interface has been removed from the kernel in 5.15, so any apps using /sys/class/gpio to access gpio pins are broken, or will be as distos update their kernels to 5.15 and beyond.\nGPIO pins can be listed with gpioinfo:\n$ gpioinfo pinedio The output should look similar to:\ngpiochip1 - 3 lines: line 0: \u0026quot;dio_irq\u0026quot; unused input active-high line 1: \u0026quot;dio_busy\u0026quot; unused input active-high line 2: \u0026quot;dio_reset\u0026quot; unused output active-high The gpiochip# might be different. The driver exposes the Pinedio with the gpio name \u0026ldquo;pinedio\u0026rdquo;, developers should use this name to interact with the gpiochip because the gpiochip# of the device is likely to be different from one system to the next, or depending on the order devices are initialized.\nDriver for the SX1262 LoRa module Now that we can talk to the SX1262 via the CH341 USB converter chip, we need to send actual commands to make it emit or receive LoRa messages. To do this, you can implement the driver yourself using info from the datasheet, or use an existing driver (you can easily find drivers for the Arduino framework, for example. I found this C++ driver. It’s well written, lightweight and easily portable across many platforms. All you have to do is implement 3 HAL function : read GPIO, write GPIO and transfer data on SPI. I wrote a quick’n’dirty app that emits a LoRa frame. It’s available here.\nAs I don’t have any \u0026lsquo;raw\u0026rsquo; LoRa device on hands, I check that it was actually transmitting something using my SDR setup (simple TNT usb key and Gqrx software):\n","permalink":"/documentation/Pinedio/USB_adapter/","tags":null,"title":"USB adapter"},{"categories":null,"contents":"The optional NVMe adapter allows the use of M.2 SSDs that support the NVMe standard (SATA is not supported). The adapter supports M and M+B keyed devices, in both 2242 and 2280 physical sizes, which are the most commonly available. In addition, 2230 and 2260 sizes are also supported, though NVMe devices that use those sizes are rare.\nMake sure to read the notes in Accessory compatibility before selecting an M.2 SSD for your Pinebook Pro, because there are certain limitations. Once you have fitted and tested your NVMe drive, please consider adding a note to that page\nPlease see a separate section that describes reported issues with the NVMe drives in Pinebook Pro.\nInstalling the adapter The V2.1-2019-0809 SSD adapter that shipped with the initial Pinebook Pro batches had significant issues. A repair kit will be shipped to address those issues. (If necessary, it can be modified to work. There is an unofficial tutorial on the forums describing these modifications.)\nThe updated SSD adapter, labeled V2-2019-1107, takes into account the prior problems with touchpad interference. New orders as of Feb. 22nd, 2020 will be the updated adapter.\nThis is the link to the Pinebook Pro accessories in the store: https://pine64.com/?v=0446c16e2e66\nActual installation instructions are a work in progress. Unofficial instructions for installing V2-2019-1107 can be found here.\nPost NVMe install power limiting Some NVMe SSDs allow reducing the maximum amount of power. Doing so may reduce the speed, but it may be needed in the Pinebook Pro to both improve reliability on battery: Some NVME may be stable with default settings when running on AC power but cause frequent kernel panics (system freeze with power LED blinking red/green) when running on battery. Reducing NVME power drain solves this in some cases. And reducing power used gives better battery life. Here are the commands to obtain and change the power settings. The package \u0026rsquo;nvme-cli\u0026rsquo; is required to run these commands. The example shows how to find the available power states, and then sets it to the lowest, non-standby setting, (which is 3.8 watts for the device shown):\n$ sudo nvme id-ctrl /dev/nvme0 NVME Identify Controller: ... ps 0 : mp:9.00W operational enlat:0 exlat:0 rrt:0 rrl:0 rwt:0 rwl:0 idle_power:- active_power:- ps 1 : mp:4.60W operational enlat:0 exlat:0 rrt:1 rrl:1 rwt:1 rwl:1 idle_power:- active_power:- ps 2 : mp:3.80W operational enlat:0 exlat:0 rrt:2 rrl:2 rwt:2 rwl:2 idle_power:- active_power:- ps 3 : mp:0.0450W non-operational enlat:2000 exlat:2000 rrt:3 rrl:3 rwt:3 rwl:3 idle_power:- active_power:- ps 4 : mp:0.0040W non-operational enlat:6000 exlat:8000 rrt:4 rrl:4 rwt:4 rwl:4 idle_power:- active_power:- $ sudo nvme get-feature /dev/nvme0 -f 2 get-feature:0x2 (Power Management), Current value:00000000 $ sudo nvme set-feature /dev/nvme0 -f 2 -v 2 -s set-feature:02 (Power Management), value:0x000002 Some NVMe SSDs don’t appear to allow saving the setting with \u0026ldquo;-s\u0026rdquo; option. In those cases, leave off the \u0026ldquo;-s\u0026rdquo; and use a startup script to set the non-default power state at boot. If you want to test performance without saving the new power setting semi-permanently, then leave off the \u0026ldquo;-s\u0026rdquo; option.\nOn systemd based distributions like Manjaro, a non-default power state for an NVME can be set using a systemd service. This is useful in cases where the NVME drive does not save the power state and/or uses APST. An example systemd service, nvme-throttle.service, is shown below:\n[Unit] Description=Throttles NVME to lesss power hungry mode After=suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target [Service] Type=oneshot ExecStart=/usr/bin/nvme set-feature /dev/nvme0 -f 2 -v 1 [Install] WantedBy=multi-user.target suspend.target hibernate.target hybrid-sleep.target suspend-then-hibernate.target Here the value after \u0026ldquo;-v\u0026rdquo; is the maximum power state that you want your SSD to use. This will be executed at system startup, and every time your system exits any suspend mode that might reset the SSD to default values.\nThis file needs to be placed in the /etc/systemd/system directory. Afterwards, to activate the service, run:\nsystemctl daemon-reload systemctl enable --now nvme-throttle.service There is another power saving feature for NVMes, APST, (Autonomous Power State Transitions). This performs the power saving \u0026amp; transitions based on usage. To check if you have a NVMe SSD with this feature:\n$ sudo nvme get-feature -f 0x0c -H /dev/nvme0 Information for this feature, (on a Pinebook Pro), is a work in progress. It is enabled by default in latest Manjaro kernels and reported to work. On some NVME SSDs (WD), APST is compatible with limiting NVMe maximum power: APST will work and not exceed maximum power state defined using previous method.\nUsing as data drive As long as the kernel in use has both the PCIe and NVMe drivers, you should be able to use a NVMe drive as a data drive. It can automatically mount when booting from either the eMMC or an SD card. This applies to Linux, FreeBSD, and Chromium, using the normal partitioning and file system creation tools. Android requires testing.\nUsing as OS root drive The SoC does not include the NVMe boot code, so the NVMe is not in the SoC’s boot order. However, using the U-Boot update script from the mrfixit2001 Debian or Arglebargle’s modified script, and the modified u-boot images provided by forum user pcm720, you can now add support to boot from an NVMe drive. Binary images are useable with SD, eMMC, and SPI flash. For OS images using the mainline kernel, there are a few variants of U-Boot available that also support NVMe as the OS drive. Though these may require writing the U-Boot to the SPI flash for proper use of the NVMe as the OS drive.\nThe current boot order, per last testing, for this modified U-Boot is:\nMicroSD eMMC NVMe For more information, please refer to the forum post.\nIt is also possible to initially boot off an eMMC or SD card, then transfer to a root file system on the NVMe. Currently, it is necessary to have the U-Boot code on an eMMC or SD card. (A forum member posted here about using a modified version of U-Boot with NVMe drivers, that uses /boot and / off the NVMe drive. So this may change in the future.)\nPlease see Bootable Storage.\n","permalink":"/documentation/Pinebook_Pro/Guides/Using-the-optional-NVMe-adapter/","tags":null,"title":"Using the optional NVMe adapter"},{"categories":null,"contents":" Warning When removing the large RF shield found on the mainboard, to be able to short the pins on the SPI chip, make absolutely sure to align it correctly while putting it back. Failing to do so can result in shorting the battery to the ground, due to the close proximity of the solder pads for the bypass cables, which would prevent the normal operation and effectively cause a fire hazard. It is highly recommended to disconnect the battery before removing the RF shield, and before putting it back. See SPI for details.\nThe Pinebook Pro comes with a 128 Mbit, (16MByte), flash device suitable for initial boot target, to store the bootloader. The SoC used on the Pinebook Pro boots from this SPI flash device first, before eMMC or SD card. At present, April 19, 2020, the Pinebook Pros ship without anything programmed in the SPI flash device. So the SoC moves on to the next potential boot device, the eMMC. ARM/ARM64 computers do not have a standardized BIOS, yet.\nHere is some information on using the SPI flash device:\nYou need the kernel built with SPI flash device support, which will supply a device similar to: /dev/mtd0 The Linux package below, will need to be available: mtd-utils You can then use this program from the package to write the SPI device: flashcp \u0026lt;filename\u0026gt; /dev/mtd0 Even if you need to recover from a defective bootloader written to the SPI flash, you can simply short pin 6 of the SPI flash to GND and boot. This will render the SoC bootrom unable to read from the SPI flash and have it fall back to reading the bootloader from other boot media like the eMMC or Micro SD card.\nThe procedures described above are a lot less risky than attaching an external SPI flasher and do not require any additional hardware. At present, April 19th, 2020, there is no good bootloader image to flash into the SPI flash device. This is expected to change, as there are people working on issue.\n","permalink":"/documentation/Pinebook_Pro/Guides/Using_the_SPI_flash_device/","tags":null,"title":"Using the SPI flash device"},{"categories":null,"contents":"The following variants exist of the Pinebook:\nPinebook 11.6″ Pinebook 11.6″ 1080p Pinebook 14″ More information can be found on the sunxi wiki.\n","permalink":"/documentation/Pinebook/Variants/","tags":null,"title":"Variants"},{"categories":null,"contents":"There are currently two variants of the PineTab-V:\nPineTab-V – 4GB RAM and 64GB eMMC storage PineTab-V – 8GB RAM and 128GB eMMC storage ","permalink":"/documentation/PineTab-V/Variants/","tags":null,"title":"Variants"},{"categories":null,"contents":" For CM4 carrier board comprehensive list, please visit Jeff Geerling collection SOQuartz with DF Robot CM4 Carrier Board\nSOQuartz with Waveshare CM4 Carrier Board\nSOQuartz with Waveshare CM4 PoE Board\n","permalink":"/documentation/SOQuartz/Baseboards/Various_CM4_carrier_boards/","tags":null,"title":"Various CM4 carrier boards"},{"categories":null,"contents":"Pinebook Pro v1 and v2 were prototype models that did not make it to the public. The \u0026ldquo;first batch\u0026rdquo; (first 100 forum pre-orders) onward are v2.1. [https://forum.pine64.org/showthread.php?tid=8111]\n","permalink":"/documentation/Pinebook_Pro/Versions/","tags":null,"title":"Versions"},{"categories":null,"contents":"The PineTime uses a standard 20mm watch band / strap. There is a thread in the forum discussing this.\nDue to the watches design. Retention for the spring bars are recessed into the watch. Not all 20mm bands / straps work. This is especially the case for Nato style bands / straps being too thick.\nKnown working bands:\nBISONSTRAP 20mm Quick Release Silicone Watch Band / Amazon US DMVEIMAL 20mm Quick Release Watch Band Metal Strap / Amazon US Morsey 20mm Quick Release Watch Band / Amazon US BINLUN 20mm Canvas Quick Release Watch Strap / Amazon US ","permalink":"/documentation/PineTime/Accessory/Watch_band/","tags":null,"title":"Watch band"},{"categories":null,"contents":"Generally, a higher power charger is better; a 20V power supply will give better performance than a 15V charger. The Pinecil needs a minimum of 3 amps and will work with higher amps charger. However, do not exceed the volts rating for V1 and V2 models or damage to components could occur (see the side of the Pinecil handle for the maximum volts).\nPower Chart Type Volts / Tip Ω = Amps * Volts = Watts USB-C PD3.0 20V / 8.0 Ω = 2.5A * 20V = 50W USB-C PD3.0 20V / 6.2 Ω = 3.2A * 20V = 64W DC Barrel 24V / 8.0 Ω = 3.0A * 24V = 72W DC Barrel 24V / 6.2 Ω = 3.8A * 24V = 92W **EPR PD3.1 28V / 8.0 Ω = 3.5A * 28V = 98W* **EPR PD3.1 28V / 6.2 Ω = 4.5A * 28V = 126W* Power Notes PINE64 officially states the Pinecil V2 will support up to 24V-88W. Tentatively, the V2 also unofficially supports 28V-140W EPR/PD3.1 USB-C chargers with certified EPR 240W USB-C cables. DC barrel power is 24V-5A maximum on V2. This allows headroom for higher spikes that happen in DC bricks or off-brand bench supplies. It is not a smart charger like a USB-C charger which uses chips to negotiate with devices like the Pinecil. Ralim’s IronOS firmware works with the PD3.1 protocol (EPR 28V-140W chargers) on Pinecil V2. EPR USB-C is new to the market in 2022. The first wave of these smart chargers are 28V/140W, are more expensive, and require a PD 3.1/240W cable to fully allow the 28V power to V2. EPR is backwards compatible for all USB-C devices. EPR chargers/cables can be used for everything else USB-C as well. Pinecil is not a USB-C tester: when the detailed screen is enabled on Pinecil, note it shows estimates and are at best +-10%. The watts shown on detailed mode are a big picture number for convenience and debugging various chargers used. It is not going to be as accurate as an external tester. Use external metering for comparisons or testing (external testers also cause a small reduction in Watts). QC Chargers Many Quick Charge or QC3 phone chargers are not recommended as Pinecil V2 is rated for a minimum of 3 Amps or more to work properly (see Pine Store Official rating on power ports). Most QC 12V phone chargers are only 1.5 Amps, this will lead to Thermal Runaway or Undervoltage messages because of weak power (older QC2 type is not supported in the IronOS firmware at all).\n","permalink":"/documentation/Pinecil/Power_supplies/Watts/","tags":null,"title":"Watts"},{"categories":null,"contents":" Using rkdeveloptool Use the PINE64 fork of rkdeveloptool.\nConnect a USB-C cable to the \u0026ldquo;DEBUG PORT\u0026rdquo; USB-C port, and a second to the \u0026ldquo;DOWNLOAD\u0026rdquo; USB-C port. Cable direction for the latter matters, so if it doesn’t show up after entering download mode, try rotating the USB-C connector to the other side.\nTo enter rockusb mode, interrupt the boot by holding the \u0026ldquo;V+/REC\u0026rdquo; on-board button or mashing Ctrl+C very quickly on the serial comms, then type download.\n$ rkdeveloptool list should now show you the device somewhat like this:\n$ rkdeveloptool list DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=204 Loader Important Note: If you receive an error about being unable to create the comms object in the following steps, make sure you have the udev rules installed with CounterPillow’s RK3588 device id patch, install them to /etc/udev/rules.d/ and udevadm control --reload Now, we can e.g. show the partitions on the eMMC:\n$ rkdeveloptool list-partitions # LBA start (sectors) LBA end (sectors) Size (bytes) Name 00 8192 16383 4194304 security 01 16384 24575 4194304 uboot 02 24576 32767 4194304 trust 03 32768 40959 4194304 misc 04 40960 49151 4194304 dtbo 05 49152 51199 1048576 vbmeta 06 51200 133119 41943040 boot 07 133120 329727 100663296 recovery 08 329728 1116159 402653184 backup 09 1116160 1902591 402653184 cache 10 1902592 1935359 16777216 metadata 11 1935360 1937407 1048576 baseparameter 12 1937408 8310783 3263168512 super 13 8310784 120831935 57610829824 userdata You can now use rkdeveloptool write-partition partitionname yourfile to overwrite one of the eMMC partitions.\nU-Boot and kernel on SD, RootFS on eMMC This is the setup User:CounterPillow currently uses. In short, you’ll need a vendor U-Boot on your SD card, with a boot partition on it that contains your extlinux.conf, device tree and kernel.\nSetting up the SD card Assuming your SD card is /dev/sdX, partition as e.g. follows:\n# parted -s /dev/sdX mklabel gpt # parted -s /dev/sdX mkpart loader 64s 8MiB # parted -s /dev/sdX mkpart uboot 8MiB 16MiB # parted -s /dev/sdX mkpart env 16MiB 32MiB # parted -s /dev/sdX mkpart efi fat32 32MiB 544MiB # increase size as you wish # parted -s /dev/sdX set 4 boot on Flash SPL and u-boot:\n# dd if=rk3588_spl_loader_v1.06.109.bin of=/dev/sdX1 # dd if=uboot.img of=/dev/sdX2 Then make the filesystem:\n# mkfs.vfat -n \u0026#34;efi\u0026#34; /dev/sdX4 Mount it to e.g. /mnt/sdcardboot:\n# mount /dev/sda4 /mnt/sdcardboot Put the following in /mnt/sdcardboot/extlinux/extlinux.conf:\ndefault l0 menu title QuartzPro64 Boot Menu prompt 0 timeout 50 label l0 menu label Boot Jank Kernel SDMMC linux /jank fdt /dtbs/rockchip/rk3588-evb1-v10.dtb append earlycon=uart8250,mmio32,0xfeb50000 console=ttyS2,1500000n8 root=/dev/mmcblk0p14 rw rootwait Copy your kernel to /mnt/sdcardboot/jank and your DTB to /mnt/sdcardboot/dtbs/rockchip/rk3588-evb1-v10.dtb.\nUnmount it, we’re done with the SD card.\nCreating the root file system First, allocate a file the size of your desired root partition (larger sizes will take longer to transfer, don’t make the same mistakes as CounterPillow did), here we choose 16G:\n$ fallocate -l 16G rootpart.bin then, make the filesystem on it. CounterPillow went for ext4 because nobody has ever been fired for using ext4:\n$ mkfs.ext4 rootpart.bin Now mount it:\n# mount rootpart.bin /mnt/emmc-root Now we’ll download the Arch Linux ARM generic rootfs tarball and go to town:\n$ wget -N http://os.archlinuxarm.org/os/ArchLinuxARM-aarch64-latest.tar.gz{,.sig} $ curl \u0026#39;https://keyserver.ubuntu.com/pks/lookup?op=get\u0026amp;search=0x68b3537f39a313b3e574d06777193f152bdbe6a6\u0026#39; | gpg --import=- # in case you\u0026#39;re lacking the key $ gpg --verify ArchLinuxARM-aarch64-latest.tar.gz.sig # don\u0026#39;t you dare skip this # bsdtar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C /mnt/emmc-root # notice that this is run as root Then we just need to edit fstab. Get the UUID (not PARTUUID) from lsblk:\n$ lsblk -o NAME,SIZE,MOUNTPOINTS,UUID and put it in /mnt/emmc-root/etc/fstab as follows:\nUUID=_root-uuid-here_ / ext4 defaults 0 1 Unmount /mnt/emmc-root, we’re done with it.\nFlashing the root file system with RockUSB Warning This will destroy whatever data is on that userdata partition. But you’re here to run Linux, not Android, right? Plug one USB-C cable into the debug UART port, the other into the download port. Yes you will need two USB-C cables (or A-to-C cables) for this, get over it.\nPlug in your board, reset it while hammering Ctrl+c on the debug UART until you get into a u-boot command line. Now enter the download command.\nIf your device doesn’t show up in lsusb or rkdeveloptool list command, pull out the download USB-C plug, rotate it axially by 180 Euler degrees, and plug it back in.\nNext, flash the partition. Depending on the size of it, this can take over an hour: $ rkdeveloptool write-partition userdata rootpart.bin\nBooting Unplug the download USB-C cable once done.\nPut the SD card in the board. Reset it. You can now boot and your rootfs on eMMC will be mounted and contains an ALARM userland.\nTo update kernels or the device tree, just shut down the board, take out the SD card, write a new kernel or dtb to it, and plug it back in. No more need for rkdeveloptool, yay.\n","permalink":"/documentation/QuartzPro64/Ways_to_do_things/","tags":null,"title":"Ways to do things"},{"categories":null,"contents":" Tip You can use Cheese to test the Camera functionality Streaming video resolutions supported, (uncompressed):\n320 x 240 640 x 480 800 x 600 1280 x 720 1600 x 1200 Still frame resolutions supported:\n160 x 120 176 x 144 320 x 240 352 x 288 640 x 480 800 x 600 1280 x 720 1600 x 1200 ","permalink":"/documentation/Pinebook_Pro/Features/Webcam/","tags":null,"title":"Webcam"},{"categories":null,"contents":"The PineCube can be powered by the host and communicate as a peripheral. First, you’ll need to a dual USB-A (male) cable to plug it into your computer. Note that the Micro-USB port can be used only for power because the data lines are not connected.\nUSB as an Ethernet gadget Goal: To achieve fast (low latency) wired network connection via USB-A port of PineCube. PineCube will be shown as a network device when connected to a computer via USB-A port. You can set up the computer to be in the same network as PineCube and connect to PineCube via SSH and/or Stream Videos from it.\nAdditional patch to PineCube device tree disable ehci0 and ohci0, enabling usb_otg device instead and setting dr_mode to otg. If otg is not working for you, try setting dr_mode to peripheral. On Armbian there is no need for disabling ehci0 and ohci0. Device tree can be edited via armbian-config tool on Armbian OS (armbian-config -\u0026gt; System -\u0026gt; DTC). Example DTC on Armbian: usb@1c19000 { compatible = \u0026#34;allwinner,sun8i-h3-musb\u0026#34;; reg = \u0026lt;0x1c19000 0x400\u0026gt;; clocks = \u0026lt;0x03 0x1d\u0026gt;; resets = \u0026lt;0x03 0x11\u0026gt;; interrupts = \u0026lt;0x00 0x47 0x04\u0026gt;; interrupt-names = \u0026#34;mc\u0026#34;; phys = \u0026lt;0x0e 0x00\u0026gt;; phy-names = \u0026#34;usb\u0026#34;; extcon = \u0026lt;0x0e 0x00\u0026gt;; status = \u0026#34;okay\u0026#34;; dr_mode = \u0026#34;otg\u0026#34;; phandle = \u0026lt;0x2c\u0026gt;; }; Load necessary kernel modules. You can skip this step if you use Armbian OS because necessary modules are already loaded by default (Detailed instructions for sunxi and Ethernet gadget: https://linux-sunxi.org/USB_Gadget/Ethernet)\nmodprobe sunxi modprobe configfs modprobe libcomposite modprobe u_ether modprobe usb_f_rndis Add sunxi and g_ether to /etc/modules to get them to load on startup. /etc/modules:\nsunxi g_ether Configure the g_ether device to start with a stable MAC address. /etc/modprobe.d/g_ether.conf:\noptions g_ether host_addr=f6:11:fd:ed:ec:6e Set a static IP address for usb0 on startup with network manager\n/etc/network/interfaces: auto usb0 iface usb0 inet static address 192.168.10.2 netmask 255.255.255.0 Boot the PineCube plugging it into a computer\nConfigure the USB Ethernet device on the computer to be in the same subnet as the PineCube. Example setting:\nnetwork setting: Manual address: 192.168.10.5 netmask: 255.255.255.0 gateway: 192.168.10.2 Done. You can use above methods to stream video through this USB Ethernet connection. Bandwidth and response time is much faster compared to usual network methods.\nUSB as a Webcam (UVC) gadget Note This is work in progress. Goal: Make PineCube behave almost as same as like normal Webcam. When you connect PineCube to a computer it will be shown as a webcam device. No need for an additional set up you can use it straight after plugging the PineCube to a computer. USB-A port is for data transfer between PineCube and computer/phone. Micro-USB port is for power.\nAction Plan (by Newton688):\nAttempt to load the uvc_gadget (usb_f_uvc) or g_webcam Look at this project to see if it can bridge UVC gadget output with the v4l from the OV5650 camera sensor: https://github.com/wlhe/uvc-gadget Progress report so far (by Disctanger):\nConfigfs method is going to be used to control OTG port.\nAdditional patch to PineCube device tree disable ehci0 and ohci0, enabling usb_otg device instead and setting dr_mode to otg. If otg is not working for you, try setting dr_mode to peripheral. On Armbian there is no need for disabling ehci0 and ohci0. Device tree can be edited via armbian-config tool on Armbian OS. (armbian-config -\u0026gt; System -\u0026gt; DTC). Example DTC on Armbian:\nusb@1c19000 { compatible = \u0026#34;allwinner,sun8i-h3-musb\u0026#34;; reg = \u0026lt;0x1c19000 0x400\u0026gt;; clocks = \u0026lt;0x03 0x1d\u0026gt;; resets = \u0026lt;0x03 0x11\u0026gt;; interrupts = \u0026lt;0x00 0x47 0x04\u0026gt;; interrupt-names = \u0026#34;mc\u0026#34;; phys = \u0026lt;0x0e 0x00\u0026gt;; phy-names = \u0026#34;usb\u0026#34;; extcon = \u0026lt;0x0e 0x00\u0026gt;; status = \u0026#34;okay\u0026#34;; dr_mode = \u0026#34;otg\u0026#34;; phandle = \u0026lt;0x2c\u0026gt;; }; Load necessary kernel modules:\nmodprobe sunxi modprobe configfs modprobe libcomposite Set up camera so that it would capture images in YUYV format (Currently only supported format in UVC gadget). You can adjust resolutions but have to adjust Configfs set up step as well.\nmedia-ctl --set-v4l2 \u0026#39;\u0026#34;ov5640 1-003c\u0026#34;:0[fmt:YUYV8_2X8/640x480@1/30]\u0026#39; Clone UVC gadget repo for raspberry pi to your PineCube\ngit clone https://github.com/peterbay/uvc-gadget.git cd uvc_gadget Comment out 1182~1185 lines of uvc-gadget.c file:\n// if (! uvc_shutdown_requested \u0026amp;\u0026amp; ((uvc_dev.dqbuf_count + 1) \u0026gt;= uvc_dev.qbuf_count)) { // return; // } Build the source code inside PineCube using make command. It takes only few seconds to build the code.\nmake gcc -W -Wall -g -c -o uvc-gadget.o uvc-gadget.c gcc -g -o uvc-gadget uvc-gadget.o Set up configfs (multi-gadget). You can have the following script as a bash script as well.\nGADGET_PATH=/sys/kernel/config/usb_gadget/pinecube mkdir $GADGET_PATH echo 0x1d6b \u0026gt; $GADGET_PATH/idVendor echo 0x0104 \u0026gt; $GADGET_PATH/idProduct echo 0x0100 \u0026gt; $GADGET_PATH/bcdDevice echo 0x0200 \u0026gt; $GADGET_PATH/bcdUSB echo 0xEF \u0026gt; $GADGET_PATH/bDeviceClass echo 0x02 \u0026gt; $GADGET_PATH/bDeviceSubClass echo 0x01 \u0026gt; $GADGET_PATH/bDeviceProtocol mkdir $GADGET_PATH/strings/0x409 echo 100000000d2386db \u0026gt; $GADGET_PATH/strings/0x409/serialnumber echo \u0026#34;Pine64\u0026#34; \u0026gt; $GADGET_PATH/strings/0x409/manufacturer echo \u0026#34;PineCube Webcam\u0026#34; \u0026gt; $GADGET_PATH/strings/0x409/product mkdir $GADGET_PATH/configs/c.1 mkdir $GADGET_PATH/configs/c.1/strings/0x409 echo 500 \u0026gt; $GADGET_PATH/configs/c.1/MaxPower echo \u0026#34;UVC\u0026#34; \u0026gt; $GADGET_PATH/configs/c.1/strings/0x409/configuration mkdir $GADGET_PATH/functions/uvc.usb0 mkdir $GADGET_PATH/functions/acm.usb0 echo 512 \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming_maxpacket # cat \u0026lt;\u0026lt;EOF $GADGET_PATH/functions/uvc.usb0/control/processing/default/bmControls # 0 # 0 # EOF mkdir -p $GADGET_PATH/functions/uvc.usb0/control/header/h ln -s $GADGET_PATH/functions/uvc.usb0/control/header/h $GADGET_PATH/functions/uvc.usb0/control/class/fs/h # ln -s $GADGET_PATH/functions/uvc.usb0/control/header/h $GADGET_PATH/functions/uvc.usb0/control/class/hs/h # ln -s $GADGET_PATH/functions/uvc.usb0/control/header/h $GADGET_PATH/functions/uvc.usb0/control/class/ss/h config_frame () { FORMAT=$1 NAME=$2 WIDTH=$3 HEIGHT=$4 framedir=$GADGET_PATH/functions/uvc.usb0/streaming/$FORMAT/$NAME/${HEIGHT}p mkdir -p $framedir echo $WIDTH \u0026gt; $framedir/wWidth echo $HEIGHT \u0026gt; $framedir/wHeight echo 333333 \u0026gt; $framedir/dwDefaultFrameInterval echo $(($WIDTH * $HEIGHT * 80)) \u0026gt; $framedir/dwMinBitRate echo $(($WIDTH * $HEIGHT * 160)) \u0026gt; $framedir/dwMaxBitRate echo $(($WIDTH * $HEIGHT * 2)) \u0026gt; $framedir/dwMaxVideoFrameBufferSize cat \u0026lt;\u0026lt;EOF \u0026gt; $framedir/dwFrameInterval 333333 400000 666666 EOF } config_frame mjpeg m 640 360 config_frame mjpeg m 640 480 config_frame mjpeg m 800 600 config_frame mjpeg m 1024 768 config_frame mjpeg m 1280 720 config_frame mjpeg m 1280 960 config_frame mjpeg m 1440 1080 config_frame mjpeg m 1536 864 config_frame mjpeg m 1600 900 config_frame mjpeg m 1600 1200 config_frame mjpeg m 1920 1080 SMALL_WIDTH=480p mkdir -p $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH echo 640 \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/wWidth echo 480 \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/wHeight echo 333333 \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwDefaultFrameInterval echo $((640 * 480 * 80)) \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMinBitRate echo $((640 * 480 * 160)) \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMaxBitRate echo $((640 * 480 * 2)) \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwMaxVideoFrameBufferSize cat \u0026lt;\u0026lt;EOF \u0026gt; $GADGET_PATH/functions/uvc.usb0/streaming/uncompressed/u/$SMALL_WIDTH/dwFrameInterval 333333 400000 666666 EOF mkdir $GADGET_PATH/functions/uvc.usb0/streaming/header/h cd $GADGET_PATH/functions/uvc.usb0/streaming/header/h # ln -s ../../mjpeg/m ln -s ../../uncompressed/u cd ../../class/fs ln -s ../../header/h cd ../../class/hs ln -s ../../header/h cd ../../../../.. ln -s $GADGET_PATH/functions/uvc.usb0 $GADGET_PATH/configs/c.1/uvc.usb0 ln -s $GADGET_PATH/functions/acm.usb0 $GADGET_PATH/configs/c.1/acm.usb0 udevadm settle -t 5 ! : ls /sys/class/udc \u0026gt; $GADGET_PATH/UDC If above script goes without issues you should be able to see one more additional /dev/video* device.\nrun uvc-gadget. UVC Gadget software links camera of PineCube and UVC gadget (OTG port). \u0026ldquo;-v\u0026rdquo; is for video input device - PineCube Camera, \u0026ldquo;-u\u0026rdquo; is for output video device UVC device or OTG port, -x shows FPS.\n./uvc-gadget -u /dev/video1 -v /dev/video0 -x Plug the PineCube to your laptop or pc and check if you can see PineCube Webcam.\nKnown issues Low Frame rate(3FPS~5FPS). That is because:\nAt the time of writing this section, streaming_maxpacket value cannot be set to max value (2048 bytes.) It can be set only to 512 bytes. If streaming_maxpacket is set to max (2048) value, UDC cannot be turned on with Invalid Value error. YUYV (uncompressed) file format is being used to stream the images. Uncompressed images take a lot of USB bandwidth compared to compressed. We can stream more frames, if MJPEG or even H254 (compressed images) would be used. I will be investigating further on how to stream more frames through USB port. ","permalink":"/documentation/PineCube/Projects/Webcam/","tags":null,"title":"Webcam"},{"categories":null,"contents":"PINE64 Official Stores\nMain global PINE64 store (ships from China, exports only, Global, VAT not included). Amazon-USA official pine64 store (ships from USA, has Pinecil V2 - no tips/accessories) Affiliates\nAmeriDroid (offers pre-order, ships to USA/Global/Brazil) blinkyparts GmbH (ships from Germany, shipping worldwide, full sortiment 2-years warranty included, offers full range of Pinecil accessories) Eleshop.eu (ships from EU, offers pre-order, 2-year warranty included per EU laws). In Netherlands, use this NL link. Droneit (ships from Sweden, sells all Pine tips/accessories). Handheld Legend (ships from USA to worldwide). Keycapsss (ships from Germany to EU/AUS/Global) Testclips (ships from GB) Typeractive (ships from USA to 55 countries). URS Electronics (local in-store only sales in Portland, Oregon, USA) bitcompact (ships from Canada) Reference: https://pine64.com/affiliates/ Why buy from a legitimate seller?\nThe PINE64 Mission is to get hardware into the hands of open source developers and tinkerers. Buying authentic Pinecils supports that mission (see this article).\nIn July 2022, all final stock sold out of Pinecil V1 (GD32VF103 mcu) at the Pine Store \u0026amp; all legit resellers. There are zero new authentic Pinecil V1 sold in the world after July 2022. Pinecil V1 was made in a black color with a light blue finger grip. PINE64 never made an all-blue Pinecil, and never used blue or red color boxes (those are fake copies with fake PINE64 logos and Pinecone).\nStarting Aug. 2, 2022, only the new Pinecil V2 model with the new BL706 Bluetooth Low Energy (BLE) MCU are made by PINE64 and sold at all authentic resellers. They are black with a green finger grip (see photos in the Picture section). The new model has anti-counterfeiting features. Authentic Pinecil using the newest official GitHub IronOS firmware, will successfully pass the Authenticiy Checker website. If a new Pinecil (post Aug. 1, 2022) does not have a BL706 chip, then it is a fake copy. If the AliExpress seller tries to show \u0026ldquo;CE certification\u0026rdquo; documents as some type of proof, those are all copied public info from the documentation page in the certifications section. PINE64 publishes those as they are the CE/FCC certifications for the stamps on the Pinecil. They are not proof of purchase from the Pine Store Ltd.\n","permalink":"/documentation/Pinecil/Purchase/Where_to_buy/","tags":null,"title":"Where to buy"},{"categories":null,"contents":"Reporting bugs is a great way to contribute and to help bringing order at managing and solving issues.\nOverview Issues should only be reported in the correct bug trackers, not in the community chats. The following list is a selection of common bug trackers.\nPinePhone and PinePhone Pro Issues with the PinePhone and the PinePhone Pro can be reported on the following bug trackers (selection).\nOperating Systems and Distributions Arch Linux ARM (DanctNIX): https://github.com/dreemurrs-embedded/Pine64-Arch/issues?q=is%3Aissue Fedora: https://github.com/nikhiljha/pp-fedora-sdsetup/issues?q=is%3Aissue Gentoo: On the bug tracker of the corresponding unofficial overlay GloDroid: https://github.com/GloDroid/glodroid_manifest/issues?q=is%3Aissue Kali Linux: https://github.com/Shubhamvis98/kali-pinephone/issues?q=is%3Aissue LuneOS: https://github.com/webOS-ports/meta-pine64-luneos/issues?q=is%3Aissue Maemo Leste: https://github.com/maemo-leste/bugtracker/issues?q=is%3Aissue Manjaro ARM: https://gitlab.manjaro.org/manjaro-arm/issues/pinephone Mobian: https://gitlab.com/mobian1/issues Multi-distro demo image: - Nemo Mobile: https://github.com/nemomobile-ux/main/issues?q=is%3Aissue NixOS: https://github.com/NixOS/mobile-nixos/issues?q=is%3Aissue OpenMandriva Lx: - openSUSE: https://gitlab.com/slem.os/slem.os/-/issues?sort=created_date\u0026state=all postmarketOS: PinePhone: https://gitlab.com/postmarketOS/pmaports/-/issues?sort=created_date\u0026state=opened\u0026label_name%5B%5D=device-pine64-pinephone PinePhone Pro: https://gitlab.com/postmarketOS/pmaports/-/issues?sort=created_date\u0026state=opened\u0026label_name%5B%5D=device-pine64-pinephonepro PureOS: unmaintained Sailfish OS: https://github.com/sailfish-on-dontbeevil SkiffOS: https://github.com/skiffos/SkiffOS/issues?q=is%3Aissue Slackware: - Swmo: https://todo.sr.ht/~mil/sxmo-tickets Ubuntu Touch: https://gitlab.com/ubports/community-ports/pinephone/-/issues?sort=created_date\u0026state=all User Interfaces Plasma Mobile: https://invent.kde.org/plasma/plasma-mobile/-/issues Plasma Mobile applications: https://invent.kde.org/groups/plasma-mobile/-/issues Phosh: https://gitlab.gnome.org/World/Phosh/phosh/-/issues?scope=all\u0026state=all Phosh projects: https://gitlab.gnome.org/World/Phosh Bootloaders and Firmwares U-Boot: TBD Tow-Boot: https://github.com/Tow-Boot/Tow-Boot/issues?q Levinboot: https://gitlab.com/DeltaGem/levinboot/-/issues?sort=created_date\u0026state=all Crust: https://github.com/crust-firmware/crust/issues?q=is%3Aissue Pinephone Modem SDK: https://github.com/Biktorgj/pinephone_modem_sdk/issues?q=is%3Aissue Hardware Issues The page Hardware issues can be used to track known problems with the hardware (and how to fix them). If you’re not exactly sure how to describe the issue, try the discussion tab for that page, or other community resources.\nAccessories TBD\nPineTime InfiniTime: https://github.com/InfiniTimeOrg/InfiniTime/issues?q=is%3Aissue PineTab Arch Linux ARM: https://github.com/dreemurrs-embedded/Pine64-Arch/issues?q=is%3Aissue+label%3A%22device%3A+pinetab%22 Manjaro ARM: https://gitlab.manjaro.org/manjaro-arm/issues Mobian: https://gitlab.com/mobian1/issues postmarketOS: https://gitlab.com/postmarketOS/pmaports/-/issues?sort=created_date\u0026state=opened\u0026label_name%5B%5D=device-pine64-pinetab Ubuntu Touch: https://gitlab.com/ubports/community-ports/pinephone/-/issues?sort=created_date\u0026state=all ","permalink":"/documentation/Introduction/Where_to_report_bugs/","tags":null,"title":"Where to Report Bugs"},{"categories":null,"contents":"If the PineCube will have a wired Ethernet connection to the main network it is possible to use it as a WiFi access point, possibly extending your existing network to further outside. Here are some steps you can take to do this starting from an Armbian system as a starting point. Note that you may need to upgrade your kernel to 5.13.x for this to work well.\nInstall bridge-utils package using apt-get\nAdd the following to your /etc/network/interfaces to set up both the eth0 Ethernet interface and the br0 bridge interface (change br0 to manual if static IP is preferred)\n/etc/network/interfaces: auto eth0 iface eth0 inet manual pre-up /sbin/ifconfig $IFACE up pre-down /sbin/ifconfig $IFACE down auto br0 iface br0 inet dhcp bridge_ports eth0 bridge_stp on Edit the /etc/default/hostapd uncommenting the line with \u0026lsquo;DAEMON_CONF=\u0026quot;/etc/hostapd.conf\u0026quot;\u0026rsquo;\nEdit the /etc/hostapd.conf to set the SSID, password and channel for your AP.\nRun sudo systemctl enable hostapd.service to enable the hostapd service on startup\nReboot your cube with the ethernet cable connected\n","permalink":"/documentation/PineCube/Projects/WiFi_AP/","tags":null,"title":"WiFi AP"},{"categories":null,"contents":" PMWF01A: Wifi Remote I2c Module\nQuick Start Guide Hardware Setup Hardware Setup\nMake sure that the driver for USB/UART Programming/Console Adapter (PMPROG01) is properly install and the PC is detected it as Comm Port. The USB/UART Bridge is base on Silicon Lab CP2012 chipset. USB/UART Programming/Console Adapter (PMPROG01) driver can be Download here Connect the USB/UART Programming/Console Adapter (PMPROG01) to the Wifi Remote I2c Device. You can power-up the WiFI Remote I2c module through the USB Bus for configuration and programming. Place the jumper J2 on USB/UART Programming/Console Adapter (PMPROG01) to 5V output selection.\nSetting Configuration Termite Setup Screen\nHelp Command\nFor windows system, you can use terminal emulator program Termite to configure the device. Make sure the \u0026lsquo;Port\u0026rsquo; setting is refer to the USB/UART Programming/Console Adapter (PMPROG01)\u0026rsquo;s Virtual Comm Port. Follow the setting according to the setup screen capture. (57600Baud 8-N-1) Once Termite configuration is done, press \u0026lsquo;OK\u0026rsquo; to save the setting. On the Wifi Remote I2c Device, Press the configuration button to allow the device to go into configuration mode. Press Config Mode button to go into configuration mode Type \u0026lsquo;help\u0026rsquo; to show the command available for configuration. Type \u0026lsquo;show\u0026rsquo; to list out current configuration. We will use PineA64 as our Wifi Remote I2c module’s server. To Set the PineA64’s IP address in to the device, enter (we will be using IP address 192.168.0.230 as example) server 192.168.0.230 To configure the Wifi AP SSID and Password, (eg SSID=TestingWifi and Password=12345 ) wifi TestingWifi 12345 The SSID and password are case sensitive. Please make sure it is input correctly. Once configuration is done, type \u0026rsquo;exit\u0026rsquo; to exit configuration mode and allow the device to reboot. Please make sure your network is has DHCP server. The WiFi Remote i2c module will be running on DHCP mode and will requesting a IP address from your network’s DHCP server. After reboot, the Red LED indicator will start to blink in fast blinking mode. Once the WiFi Remote I2c module connected to the WiFi Access Point, the LED indicator will go into slow blinking mode. The hardware configuration is done. The next step will be configure the PineWifiServer into your PineA64 board. Setup the PineWifiServer Download the PineWifiServer from the Download Section Copy PineWifiServer xxxxxxxx.gz into your PineA64 with linux on it. (where xxxxxxxx is the version number) Unzip the file using gunzip. Add Execution flag on both of the file by chmod +x PineWifiServer Start the PineWifiServer by ./PineWifiServer Once the server is started, you will notice that the LED indicator on the Wifi Remote I2c Hardware will change from slow blinking to always on. To login into the server, telnet into localhost port 10000 telnet localhost 10000 PineWifiServer Login Screen\nTo show current connect Wifi Remote I2c type \u0026rsquo;list\u0026rsquo; in small capital letter. To see all available command, type \u0026lsquo;help\u0026rsquo;. To exit the console, type \u0026rsquo;exit\u0026rsquo;. Please take note that you are only allow one login simultaneously. The second telnet login will be rejected. Running the WifiAppDemo Download the PineWifiServer from the Download Section Copy WifiAppDemo xxxxxxxx.gz into your same PineA64 board that currently running with PineWifiServer. (where xxxxxxxx is the version number) Unzip both of the file using gunzip. Add Execution flag on both of the file by chmod +x WifiAppDemo before start running the demo application, please logout any telnet session to the PineWifiServer. The demo application will telnet into the PineWifiServer and start polling all the available Wifi Remote I2c device currently connected to the server. The demo application will also poll the I2c port of the hardware for the Ambient Light Sensor and the Temperature/Humidity Sensor if the sensor is connected to the Wifi Remote I2c module. To start the WifiAppDemo, type ./WifiAppDemo The Application will connect the PineWifiServer currently running in the localhost. Example of screen shot with WifiAppDemo polling multiple Wifi Remote I2c with Ambient Light Sensor and Humidity/Temperature Sensor connected on it. The speed for each round of polling is 1 second per poll.\nFirmware Upgrade Hardware Setup Short Jumper S2 on the WiFI Remote I2c module (before power up the board) to allow the board to go in to firmware programming mode.\nHardware Setup\nMake sure that the driver for USB/UART Programming/Console Adapter (PMPROG01) is properly install and the PC is detected it as Comm Port. The USB/UART Bridge is base on Silicon Lab CP2012 chipset. USB/UART Programming/Console Adapter (PMPROG01) driver can be Download here Connect the USB/UART Programming/Console Adapter (PMPROG01) to the Wifi Remote I2c Device. You can power-up the WiFI Remote I2c module through the USB Bus for configuration and programming. Place the jumper J2 on USB/UART Programming/Console Adapter (PMPROG01) to 5V output selection.\nSoftware Setup Download the firmware from the download section and unzip the file. Download the windows Python base Flash Download Tools by Espressif from Espressif website. Setup the ESP Flash Download tools according to the screen short. Make sure that the firmware address is set correctly. Baud rate is set to 115200baud and Com Port is set according to the Virtual Com Port of your PC. Once the ESP Flash Download tool and hardware is setup properly, press the \u0026lsquo;Start\u0026rsquo; button to start the firmware uploading process. After uploading is done, power off and on again the WiFi Remote I2c module to restart the system. Technical Specification Dimension: 47.00mm x 34.00mm Input Voltage: 5V Max. Input Current: 200mA Operating Frequency: 2412MHz-2484MHz Output power of PA for 802.11b: 19.5dBm-21.5dBm Receiver Sensitivity at DSSS, 1Mbps: -98dBm I/O Pin Out Download Program/Driver Termite a simple RS232 terminal Flash Download Tools v2.4 Under Tools Section Silicon Lab CP2102 Virtual COM Port Driver WifiAppDemo.gz PineWifiServer.gz PMWF01A Firmware PMWF01A Firmware Source PineWifiRemoteI2c Server Source.tar.gz Datasheet/Related Information TE PCJ-105D3M Relay Datasheet ESP8266 Datasheet ESP8266 forum ESP8266 Flash Download Tools, Please refer to the Tools section ESP8266 Resources CP2102 Datasheet ","permalink":"/documentation/Accessories/Wifi_remote_i2c/","tags":null,"title":"Wifi Remote I2c"},{"categories":null,"contents":"PineVoice implements open-source WiFi Provisioning protocol Improv. Any application supporting this protocol is capable of setting up WiFi on the PineVoice.\nEntering Provisioning Mode On first boot, the speaker automatically enters Wi-Fi provisioning mode. While in this mode, the ring LED blinks yellow.\nIf the ring LED is not blinking yellow, the speaker is not in provisioning mode. Perform a factory reset to return it to provisioning mode, by holding • dot button for 15 seconds. After releasing the button, PineVoice should restart and launch Provisioning Mode.\nProvisioning Once the speaker is in provisioning mode (ring LED blinking yellow), use one of the following methods to send the Wi-Fi credentials:\nThrough Web Info Web Provisioning requires browser with Web Bluetooth API support. Please refer this table if your browser is supported. Open this website on your PC or phone, which have Bluetooth 4.0 (Low Energy) connectivity and then press following button:\nAlternative web provisioning If button on this website does not work, try it on Improv website.\nThrough Home Assistant Home Assistants supports Improv via BLE. This feature must be set up properly to be functional. Please, follow this instructions on Home Assistant website.\nThis card should pop up automatically in your Home Assistant on Devices page:\nImprov Card in Home Assistant\nAfter successful provisioning, please continue to Assistance Setup.\n","permalink":"/documentation/PineVoice/WiFi_Setup/","tags":null,"title":"WiFi Setup"},{"categories":null,"contents":"This page is about the community project to bring wireless charging to the PineBuds Pro.\nWireless charging The PineBuds Pro don’t have wireless charging by default, but you can add it. However, you need to know how to disassemble the charging case and solder bunch of SMT components to the PCB.\nPine originally planned to have wireless charging for the PineBuds Pro, but apparently for cost reasons they decided to cancel it. However, they left footprints on the PCB for wireless charging component. They also designed COPO CP2021 component to be used. You also need a bunch of other components, such as resistors and of course electromagnetic coil. The places intended for the components, the footprints, are made for SMT (also called SMD) components. That means you need a hot air soldering station and experience.\nRequired tools Picks/thin cards Screwdriver Hot air soldering station Tweezers Solder Flux Glue Required components COPO CP2021 WIP Steps First open the lid and then try to press the case from the front edge with a plectrum or a thin card. There are two clips on each side. Soon the case will snap open. Carefully unscrew and remove the PCB from the case. Solder the necessary components to their respective footprints, use the PineBuds Pro Charging Case Schematic/COPO CP2021 2.5W Qi Wire Power Receiver Datasheet (below). Screw the PCB back into the place. There is plenty of space, glue the coil to the bottom of the case. Close the charging case. ","permalink":"/documentation/PineBuds_Pro/Community_projects/Wireless_charging/","tags":null,"title":"Wireless charging"},{"categories":null,"contents":"The key to save battery is to enable only what you need when you need it. nRF52832 has a lot of functionalities allowing you to draw as little current as possible. Here are some tips and tricks:\nDisable / shutdown / put in sleep mode all devices around the MCU (display controller, touch controller, external memory). Disable all peripheral inside the MCU when you don’t need them (SPI, TWI(I²C)). The power management of the NRF52832 is very smart and will completely shut down (power off and disable the clock) the peripheral when the software disables it. Put the MCU to sleep as soon and as often as possible. If you are not using a RTOS, this is done by calling WFE (wait for event) instruction. Most of the time, RTOS implement this functionality. For example, FreeRTOS calls it the tickless mode: it puts the CPU in sleep mode when no task is planned for execution for more than a specified time, and wakes up as soon as an event is detected or when a task is ready to run. Do not use logging (JLink RTT, SWO, semihosting), it uses a lot of power. Ensure that the debug circuitry of the MCU is not enabled when you measuring the battery life. The debug peripheral is enabled as soon as you connect a debugger to the device, and is not automatically disabled, even if you disconnect the debugger you will have to wait for the battery to go flat to disable to port. The software running in the NRF52832 cannot disable the debug peripheral. To disable the debug circuitry: using nrfjprog --reset using JLinkExe: issue the command writeDP 1 0 or with OpenOCD: issue the command halt issue the command flash fillw 0x10001208 0xFFFFFF00 0x01 issue the command reset You can check if the debug port is enabled using the following code: DWT-\u0026gt;CYCCNT ? \u0026#34;NO\u0026#34;:\u0026#34;YES\u0026#34; Read the errata sheet of the MCU and apply workarounds if they apply to your software. ","permalink":"/documentation/PineTime/Development/Write_battery-friendly_software/","tags":null,"title":"Write battery-friendly software"},{"categories":null,"contents":"This guide is for community members wanting to announce project updates on the Pine64 community blog.\nSetup You should first prepare a fork of the pine64 website repository on GitHub, then clone it.\ngit clone https://github.com/USERNAME/website.git\nOnce the repository is cloned, you can open up the template folder at /content/blog/template and copy template_update.txt to /content/blog as a .md file.\nImportant Heads up, try to keep the naming of blog post files consistent. Put the month and year and a brief description of the contents. For example: august_2025_pt2_factory_image.md and december_2020_pinephone_release.md. Blog post details Once the template is copied, you can start editing the blog post details. Below is an example of a blog posts basic layout with some explanations of each option does (with explanation after \u0026ldquo;//\u0026rdquo;):\n1title: \u0026#34;PROJECT update: TAGLINE\u0026#34; // The title for the blog post. 2date: \u0026#34;yyyy-mm-dd\u0026#34; // Date of publishing. 3authors: [\u0026#34;Name of author\u0026#34;] // Author(s) of the blog post. 4categories: 5 - \u0026#34;community\u0026#34; 6 - \u0026#34;news\u0026#34; 7 - \u0026#34;pine64-community\u0026#34; 8tags: 9 - \u0026#34;tag_1\u0026#34; // E. g. \u0026#34;pinetab2\u0026#34;, \u0026#34;pinenote\u0026#34; 10 - \u0026#34;tag_2\u0026#34; 11images: // Cover art (preview and embedded) 12 - \u0026#34;/blog/images/pine64_banners/pine64_blue.png\u0026#34; 13summary: \u0026#34;Summary about the contents\u0026#34; 14 // Blog post summary, used in RSS and blog post list 15 16--- 17 18![Blog post banner artwork](/blog/images/pine64_banners/pine64_blue.png) 19 // Cover art found in the blog post itself. 20 21{{\u0026lt; toc \u0026gt;}} 22 // Creates the table of contents 23 24## HEADING TITLE 25 // First headline, put what your blog post is about here. The title should be formatted like \u0026ldquo;Project Update: New PineTab2 Factory Image\u0026rdquo; or \u0026ldquo;Project Update: PinePhone Pro FreeBSD port\u0026rdquo; The date entry follows the yyyy-mm-dd format. Make sure to test that the blog post appears in the hugo preview, depending on your timezone you may have to set it a day back. Categories are already correct in the template, so leave these alone. Tags are used to recommend similar blog posts with the same tags. For example: pinetab2, pinetab-v and pinenote. Important A useful tip, if you find yourself stuck with what what to put in the details at the top of the file, there is a completed example in the templates folder. Cover image details There are a number of different cover images to choose from that are included in the /content/blog/images/pine64_banners folder. The default image is called pine64_blue.png and has green, yellow and red color variations in pine64_banners/pine64_colors.\nBlog post list cover image The first option cover: image: is used for the cover image found on the blog post list. The image path for this option starts with the pine64_banners folder.\npine64_banners/festival_lights.png pine64_banners/pine64_colors/pine64_yellow.png Embed cover image The second option images: is used for the embed cover image. This image will appear when you post a link to the post on platforms like Mastodon and Matrix. The image path for this option starts with the /blog folder.\n/blog/images/pine64_banners/festival_lights.png /blog/images/pine64_banners/pine64_colors/pine64_yellow.png Blog post cover image The cover image found in the blog post itself can be set just after the option section ends. The image path for this option starts with the /blog folder.\n![Blog post banner artwork](/blog/images/pine64_banners/festival_lights.png) ![Blog post banner artwork](/blog/images/pine64_banners/pine64_colors/pine64_yellow.png) Write After the setup is done you are ready to start writing. Blog posts are written in Markdown so it is expected that you take a look at the Markdown syntax guide if you haven\u0026rsquo;t already. If you are unsure on how to lay out your blog post, take a look at the completed template for inspiration.\nInstall hugo You can preview what the final post will look like by installing the hugo site generator. On Linux it\u0026rsquo;s straight forward, use your package manager to install hugo.\nFedora: sudo dnf install hugo Debian/Ubuntu: sudo apt install hugo Arch Linux: sudo pacman -S hugo On Windows you must download the hugo binary and add it to your environment variables, you can find prebuilt binaries here. For any other operating systems and installation information you can find the documentation here.\nTest your blog post Start the hugo site generator by running hugo server in the root of the website repository, then check for anything that may look off in your blog post.\nMerge that thing! Once you\u0026rsquo;re happy with what you\u0026rsquo;ve written, you can submit a pull request on the website repository and we will review and merge it.\nAvailable cover image The source files for the following cover images have been placed in the /content/blog/images/pine64_banners/source_files folder. Make sure to not overwrite the originals.\npine64_blue.png (default) festival_lights.png the_sign.png forest.png fountain.png Bring your own cover image If you\u0026rsquo;d like to bring your own cover image for your blog post, you can drop it in the /content/blog/images/pine64_banners/community folder. Make sure to edit the path for the cover image at the top of the blog post document to reflect this.\nTry to keep cover image at a 16:9 aspect ratio, 1920x1080 is a good resolution to aim for. The font size used for the tagline in GIMP is 150px. ","permalink":"/documentation/Introduction/Writing_a_blog_post/","tags":null,"title":"Writing a blog post"},{"categories":["SBCs"],"contents":" A versatile single board computer for makers The Yuzuki Avaota-A1 is powered by an Allwinner A527 Octa-Core ARM Cortex-A55 64-Bit CPU @2.0GHz, ARM Mali G56 GPU and RISC-V XuanTie E906 CPU@200MHz. It provides an onboard eMMC, MicroSD Card slot, PCI-e, Pi-2 Bus, USB 3.0, and many other peripheral interfaces for makers to integrate with sensors and other devices.\nFeatures and Specifications SoC 4 x ARM Cortex-A55 at 2.0 GHz Memory LPDDR4 RAM (2/4GB) GPU Mali-G57 Valhall GPU @ 850MHz Features Digital Video output up to 4K@60Hz H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4K×2K @ 30fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4K×2K @ 60fps 3.5mm audio Jack Dual 10/100/1000Mbps Ethernet 2.4GHz/5Ghz MIMO WiFi 802.11 b/g/n/ac with Bluetooth 5.2 on-board 128Mbit (16MByte) XSPI NOR flash memory - bootable microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable on-board 16GB or 32GB 2×20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header 4 lane MiPi DSI port for LCD panel 4 lane MiPi CSI port for camera module 1 x USB3.0 OTG port 1 x USB2.0 Host port 1 x USB2.0 OTG port 1 x CAN port Stores Global Global: Accessories Affiliates Documentation Yuzuki Avaota A1 Schematics and certifications ","permalink":"/devices/yuzuki_avaota-a1/","tags":null,"title":"Yuzuki Avaota A1"},{"categories":null,"contents":" The PineVoice\nThe Yuzuki Avaota-A1 is an ARM64 based Single Board Computer powered by an Allwinner A527 Octa-Core ARM Cortex-A55 64-Bit CPU @2.0GHz, ARM Mali G56 GPU and RISC-V XuanTie E906 CPU@200MHz. It provides an onboard eMMC, MicroSD Card slot, PCI-e, Pi-2 Bus, USB 3.0, and many other peripheral interfaces for makers to integrate with sensors and other devices.\nFurther information Datasheets\nSchematics and certifications\nSpecifications\nDatasheets Allwinner A527 SoC information:\nAllwinner A527 SoC Product Brief Allwinner A527 SoC Datasheet Allwinner SoC User Reference Manual X-Power PMU information:\nAllwinner AXP717 PMU Product Brief Allwinner AXP717 PMU Datasheet LPDDR4 (200 Balls) SDRAM:\nRaysonLPDDR4 Datasheet eMMC information:\nKingston eMMC Datasheet Ethernet related info:\nRealtek RTL8211F 10/100/1000M Ethernet Transceiver Datasheet WiFi/BT module info:\nAICSemi 8800D40 module 11AC Dual Band 2T2R WiFi + Bluetooth5.2 Datasheet AICSemi AIC8800DC 11AX Wi-Fi + Bluetooth5.2 Datasheet Schematics and certifications Avaota A1 SBC dimensions\nInput Power: DC 12V @ 3A 5.5mmOD/2.1mmID center-positive Barrel DC Jack connector\nSchematic:\nYuzuki Avaota-A1 Schematic v1.7 Board map of connectors with schematic v1.1 identifiers:\nAvaota A1 SBC layout\nCertifications:\nDisclaimer: Please note that PINE64 SBC is not a \u0026ldquo;final\u0026rdquo; product and in general certification is not necessary. However, PINE64 still submits the SBC for FCC, CE, and ROHS certifications and obtain the certificates to prove that the SBC board can pass the testing. Please note, a final commercial product needs to perform its own testing and obtain its own certificate. Not yet available Specifications SoC and Memory Specification Based on Allwinner A527 Allwinner T527 A527 block diagram\nCPU Architecture Quad-core ARM Cortex-A55 at 2.0 GHz AArch32 for full backwards compatibility with ARMv7 ARM Neon Advanced SIMD (single instruction, multiple data) support for accelerated media and signal processing computation Includes VFP hardware to support single and double-precision operations ARMv8 Cryptography Extensions Integrated 32KB L1 instruction cache and 32KB L1 data cache per core Integrated 64KB L2 instruction cache and 128KB L2 data cache per cluster 1MB unified system L3 cache GPU Architecture Mali-G57 Valhall GPU@850MHz 4x Multi-Sampling Anti-Aliasing (MSAA) with minimal performance drop 128KB L2 Cache configurations Supports OpenGL ES 1.1, 2.0, and 3.2 Supports Vulkan 1.1 Supports OpenCL 1.1, 1.2, 2.0 Full Profile Supports Renderscript L2 Cache Configurable 64KB – 512KB ** 64KB-128KB for 1-Core ** 128KB-256KB for 2-Core ** 256KB for 3-Core ** 1x256KB-2x256KB for 4-Core ** 2x256KB-2x512KB for 5-Core and 6-Core configurations Supports 3400 Mpix/s fill rate when at 850MHz clock frequency Supports 243.2 GLOP/s when at 850MHz clock frequency for peak single precision (FP32) performance System Memory LPDDR4 RAM Memory Variants: 2GB and 4GB. Board Features Video Digital Video output up to 4K@60Hz H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4K×2K @ 30fps H.265/HEVC Main/Main10 profile @ level 5.1 High-tier; up to 4K×2K @ 60fps Audio 3.5mm audio Jack Network Dual 10/100/1000Mbps Ethernet 2.4GHz/5Ghz MIMO WiFi 802.11 b/g/n/ac with Bluetooth 5.2 Storage on-board 128Mbit (16MByte) XSPI NOR flash memory - bootable microSD - bootable, supports SDHC and SDXC and storage up to 256GB eMMC - bootable on-board 16GB or 32GB Expansion Ports 2×20 pins \u0026ldquo;Pi2\u0026rdquo; GPIO Header Avaota-A1 40 pin connector diagram\n4 lane MiPi DSI port for LCD panel 4 lane MiPi CSI port for camera module 1× USB3.0 OTG port 1× USB2.0 Host port 1× USB2.0 OTG port 1× CAN port Software Software releases\nSoftware releases These releases are still in beta state and are only fit for development purposes.\nOpenWrt Image Build OpenWrt Github Release Armbian Mainline Linux OS Image Build Source code available at https://github.com/pine64/build/releases, others are welcome to fork and enhance. Attach USB keyboard, then follow onboard small LCD screen message to complete first setup After the initial setup, please allow some time for the download of the HA (Home Assistant) image PineDio Zigbee dongle driver already included For the board with 2GB of memory, please only use OS build with Picoclaw version. The following are 2026.06.05 builds\nDirect Download Ubuntu 26.05 Noble with Home Assistance and Picoclaw build from pine64.org (987MB, MD5 777f08ad5d42f3e8c56aa242eff8f855) Direct Download Ubuntu 26.05 Noble with Home Assistance and openclaw build from pine64.org (988MB, MD5 e40065560256718af2590f85137a55cc) The following are 2026.05.21 builds\nDirect Download Ubuntu 26.05 Noble with Home Assistance and Picoclaw build from pine64.org (987MB, MD5 4f60fdd168817b70f5b782f412009210) Direct Download Ubuntu 26.05 Noble with Home Assistance and openclaw build from pine64.org (982MB, MD5 bd6f6edb2a5733d79b0ea4bf3d867403) Avaota OS Legacy Linux Image Build The following OS build is derived from the Allwinner BSP\nDirect Download Ubuntu 22.04.5 Jimmy CLI build from pine64.org (480MB, MD5 958dce883859ea7dae29ccd460a5996d) Direct Download Ubuntu 22.04.5 Jimmy Gnome build from pine64.org (1.09GB, MD5 916a974dbdbcdc21f13860e597a44df2) Direct Download Ubuntu 22.04.5 Jimmy XFCE build from pine64.org (1.26GB, MD5 7eac664789ad44b4db1241f6d7d15ffe) Direct Download Ubuntu 24.04 Noble CLI build from pine64.org (1.26GB, MD5 8976d153484c6dfb14434f26c1a15e14) Android 13 Image Build Note: \u0026ldquo;eng\u0026rdquo; build enable root and log for development or hacking purpose, \u0026ldquo;user\u0026rdquo; build disable root and log as release version\nDirect Download Eng build from pine64.org (1.25GB, MD5 6692b8cd14aeccfed4bbdc148f607135) Direct Download User build from pine64.org (1.22GB, MD5 cc0227464c7a451b582aba1f3b1944ae) Android 13 SDK Direct Download from pine64.org (62.28GB, MD5 f565ff9d0f712ca9c8131c69011379cf) Resources and Articles Yuzuki github for more information Yuzuki\u0026rsquo;s Avaota fun site dedicated to Avaota OS in Chinese ","permalink":"/documentation/Yuzuki_Avaota-A1/_full/","tags":null,"title":"Yuzuki Avaota A1 (Single Page)"}]