Hi folks,

I lurk on here more or less. I bought the original pinebook. It worked for about two weeks and then I couldn't ever get it to boot up again after the battery died while running. But that's a different story for a different day.

I am a rare type of consumer who was an early and eager adopter of smartphones and pda's and now see them with disgust. For PDAs, I am still a loyal palm pilot user. On the phone end I used a variety of palm treos. Jumped over to the palm pre (what a disaster that was). Followed that horse for a few years and jumped to android at the galaxy s2 > s4 > s7 > grand prime > blackberry keyone (best smartphone i ever had) > j2

A year ago, my growing disdain for where the industry has gone (along with the internet) has driven me to abandon smartphones for a flip phone. It runs a locked down android that has a hotspot feature. Thing even comes with a media player and a radio tuner (internal fm hardware). While I find myself not missing the smartphone one iota, one thing I dislike on the flip phone is the old style texting. Most people I know prefer to text over talk and I often find myself going days without actually talking on the phone but will send/receive hundreds of sms/mms messages. Sometimes, if the conversation is complicated, I'll email my phone the message and forward it to the person I'm talking to because it's easier to use a keyboard.

Which brings me to this post. I'm brainstorming methods in which I can create a mms/sms-only device complete with a qwerty hardware keyboard, a small non-touch screen with a high enough resolution to display images, software for decoding video and software for playing them (received via text), usb-c for file transfer/storage/charging. Virtual keyboards suck hard. I don't really care how cheaply it's built either. The case can be 3d printed for all I care.

It should be easy enough to start with stock android and trim it down to only the basic sms/mms, carrier (3g/4g/etc), power management components (like my flip phone). 

I am considering the pinephone and adapting the hardware to make it appear somewhat like my old peek. I could tear apart my old peek and jam in pinephone guts. Problem is, last I checked the pinephone won't work with my one major constraint which is the carrier (Sprint). I'm on a family plan so, that's the one static requirement. I considered doing a pairing situation but that would require a phone everywhere I go to make that possible.

Ultimately, this project would simply be a fun endeavor and, if successful, would yield a device that fits my lifestyle.

I thought I understood Docker, but maybe not. I'm running ayufan's Ubuntu on my ROCK64; uname identifies it as aarch64. When I run Docker (via Kubernetes) and ask for a multi-architecture image, I get this error:

    no matching manifest for linux/arm/v8 in the manifest list entries

But Docker Hub lists the image (rook/ceph:v1.1.2) as built for both amd64 and arm64 architectures. I thought aarch64 and arm64 meant the same thing, with userland calling the architecture aarch64 and kernel calling it arm64. Is that not true? How are these names related to linux/arm/v8?

If this machine pulled an arm64 image, would it be able to run it? Maybe my Docker is just misconfigured so it doesn't recognize what it can run.

SBC:    Rockpro64 v2.1 4Gb
OS:     ubuntu 18.04 minimal w / Mate' DE     
        Linux rockpro64 4.4.190-1233-rockchip-ayufan-gd3f1be0ed310 #1 SMP Wed Aug 28 08:59:34 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

While performing an apt update && apt upgrade, the following messages occur:

W: http://ppa.launchpad.net/ayufan/rock64-0.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://ports.ubuntu.com/ubuntu-ports/dis.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://ppa.launchpad.net/ayufan/rock64-0.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://ports.ubuntu.com/ubuntu-ports/dis.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://ports.ubuntu.com/ubuntu-ports/dis.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.
W: http://deb.ayufan.eu/orgs/ayufan-rock64/.../InRelease: The key(s) in the keyring /etc/apt/trusted.gpg.d/ayufan.key.chroot.gpg are ignored as the file has an unsupported filetype.

Any explainations? Concerns?

TIA,
/Faradn
~ Rockpro64 ~ Odroid N2 ~ Odroid XU4 ~ Pi 3B ~

Yesterday I tried to install the Spotify plugin in Kodi but somehow it is not installing? Anyone got it working on their RockPro?

I am wondering if a year or two years in the future the Pine book Pro will have a replacement motherboard that will run the solid-state NVMe drive as easily as the current one runs the EMMc drive.?

  I will definitely purchase that motherboard  !

 Meanwhile I will be happy with the one I purchased.

Hi, a short question. Will the PineTime have a switch to kill the bluetooth? I imagine the use case when it can be used as Morning alarm and it would be kept in the bedroom close to the body. Thanks

We having been discussing uboot on SPI as a way to get bootable PCIe NVMe drives. Yet the consensus is that the SPI is for a version of uboot, (or other firmware), that is quite stable.

But, we can also do some interesting things for recovery. If uboot is not that big, perhaps we can have 2 versions, with a tiny bit of code to select the most current, unless a special key is held down. Then it uses the prior release. That may help prevent some of the bricking of the PBP that has been disscused for new, but faulty firmware.

This could apply to both eMMC and SPI., though eMMC is an easier un-brick than SPI.

Just an idea.

Some users and me have experienced time drift in some sopine modules. This manifests as a date jumping randomly in the future, for example around the year 2114.

Some system output:

I have grouped header mapping between SOPine Clusterboard prototype and Baseboard, focusing on GPIO. I hope it also helps you guys.


ATTENTION: Please verify this BEFORE use, and help to improve this mapping's reliability for all the community.

Attached Files

  SOPine_Clusterboard_Pin_Mapping_v0.4.pdf (Size: 180.96 KB / Downloads: 2150)

My RockPro64 arrived at last, and I've been testing it for the last 2 days. I installed LibreElec and I must say that so far it's working pretty well, but I have a couple of issues that I'd like a little help, if possible.

Firstly the fan. I connected mine on the connector 4 of the diagram on the Pine64 site (the one equivalent to "PWM controlled fan header "), but it just doesn't work at all. Not that bad for now, since I still don't have a case and I also got a 20mm heatsink (the maximum temperature I got was 50°C), but I really would like it to work properly, because as soon as I get a case I'm sure it will heat a lot. I've seen a couple of other threads in which people say that it's necessary to recompile the image and apply a couple of patches in order to make it work properly. Is that still the case or there are any other way?

The other thing that has got me worried is the behavior of the leds. Once the board is up and running the red led keeps blinking all the time (2 short blinks) and the white led is off. As I've read on the Pine64 site the expected behaviour would be the white led to stay on and the red one being a sort of "DIY" whose behaviour would depend on what each developer programmed to his image. Is that constant blinking of the red led the expected behaviour on LibreElec running on RP64?

I'm using my TV remote (through its HDMI-CEC feature) in order to control Kodi. It's working and all, but what I want is to turn it on as I turn the TV on, and off as I turn the TV off. The TV is correctly configured and I revised all related configurations on Kodi, and it still doesn't work. If I use the remote to turn on the TV the RP64 doesn't turn on, and if it's already on and I use the remote to turn off the tv nothing happens on the RP64 (no matter which option I configure on Kodi). Am I missing something?

Any help would be much appreciated.