Hello,

I received my Pinebook Pro in Spring 2021.  I last used it about one month ago, and left it disconnected.  So, the battery has completely drained.

I've been charging it using the barrel charger for more than twelve hours.  When I turn it on, the green power light comes on, and the screen comes up bright white.  After ten seconds or so, the backlight dims a bit so it's a softer white.  At that point, I can do things like toggle num lock on my external keyboard.

I don't think it is an OS issue, because it booted completely fine a month ago and I haven't touched it.  But just in case, I am using hand-debootstrapped Debian "bullseye" with a custom kernel build using Manjaro's patches as of a year ago, and stock Debian u-boot.

Any ideas about what these symptoms could indicate?  Really hope it is not bricked!  I don't have UART, but I could get one if it's not just that the screen is completely dead.

Thanks.

Currently, I'm on the Speakout phone plan. I'm using my 10-12 year old Samsung phone, and it works fine, but I've wanted a tinker phone with pure Linux for several years.

I'm interested in going down the rabbit hole to try my SIM card on a Pine Phone Beta Edition. I'd like to know if anyone has used the Speakout carrier on the Pine Phone and what experience they've had with it.

Are all carriers generally the same in terms of call reliability?

Has anyone managed to get ov5647 to work on Quartz64 or Soquartz? I've spent last few days on it and despite the configuration being correct I can't get the mipi csi to see the data.

So if you do have ov5647 working on Quartz64 /Soquartz or a similar mcy please post the DTS that works for you.

Hi all,

I am managing a cluster of Rock64/RockPro64 and I need access to the GPU cycle counters (I already got access to CPU cycle counter) of the Mali T860 included in the board. I am trying to use the HWCPipe (https://github.com/ARM-software/HWCPipe) interface to get the CPU counters. However, this library tries to use /dev/mali0 to interact with the GPU, which is not exposed to the user in armbian using the Panfrost driver.

I have tried several ways of installing the mali midgard driver without success so far. Besides, I have tried to use /dev/dri/card1 (and 0) as resource for HWCPipe, but it doesn't work either.

Does someone know how I could expose the /dev/mali0 interface to userspace using panfrost driver or how to install mali-midgard driver in the last armbian version (kernel 5.15.48)?

The same posted here applies for Rock64 with lima driver for Mali-400 GPU, just in case...

I have a Pinebook Pro from the original first batch. I've noticed that the WiFi signal strength is much lower on the PBP than with my other devices. This happens in both 2.4 and 5 GHZ. I re-seated the antenna connector and that didn't change anything. I'm running Manjaro with all the latest updates. I have disabled Bluetooth (through the GUI) and that didn't seem to help. Is there anything else that I should be trying?


Yes, I'm just noticing the signal weakness now because I've only recently started taking the PBP with me to places where I need to use public WiFi.

Thank you,
B34N

Listening to podcasts using gnome-podcasts (flatpak) was working fine until last weekend. It no longer prevents the system from suspend.
The log shows

Hi,
I haven't found any information about it anywhere else, so I'm asking here.
What should I do, if I use the Caprine app and the keyboard to type things doesn't come up? I have been copy-pasting the text which you probably can understand is horribly inconvenient. Is there any way to solve this?
Besides, I want to use the Tutanota app, but it doesn't seem to work (it's an outdated version in Discover and it cannot update itself automatically (the keyboard also does not pop up).
What should you do?
Thanks, guys, for any input

Hi there,is there a good tutorial about the u-boot with example?
I've installed Freebsd on microSD card,and on a hd as well but i'd
Like to boot it from the HD as the main way.
I

I've been thinking of buying a Pinephone for quite a while now, but I don't really know if it's really the perfect phone for me, or if there's better.
I just want a phone for basic calling and messaging and also to goof around with a pocket terminal while staying open, and for relatively cheap.
For now I'm thinking of a Pinephone(Pro) with the keyboard shell.

Thanks.

Hi there,

TL;DR: S/PDIF output is choppy, unclear whether hardware or software issue, any insights appreciated.

I got a ROCKPro64 running Debian stable (with the kernel pulled in from backports). I modified the devicetree to enable SPDIF, by disabling the other two i2s blocks and enabling the SPDIF blocks. I also re-routed the SPDIF signal to the Pi2 GPIO header (using the alternate pin which was already provisioned in the devicetree), because I didn't have a compatible 2mm pin socket available, and delivery times were in the order of months for those. I am connecting via a hand-soldered coax cable to the amp. I tried different cables and adapters to rule out the cabling as a source of problem.

S/PDIF output works in principle, but there are issues. In particular, the amplifier will irregularly fail to recognize the signal for a short moment (it has indicator lights for S/PDIF PCM which turn off briefly), like some kind of synchronization loss. This causes a gap in the audio.

After looking at the amplifier schematics (it is a Denon AVR-1910 and the service manual can be found on the internet), I realized that the signal is tied to GND using a 75 ohm resistor, which would result in significant peak current being sourced from the RK3399 GPIO. To mitigate that, I added a 2N7000 N-FET as driver, powered from the 5V rail with a 75 ohm resistor. This results in 33mA of peak current, I suppose, which should be fine for the 5V rail (any USB device may need more than that).

That way, I hope to have ruled out any cabling/power issues on the transmission line.

I am currently running nothing except mpd on the box. I tried with pulseaudio inbetween mpd and ALSA, but that did not fix the issues (although I *think* it reduced the issues somewhat, not 100% sure).

The rate of issues seems to correlate with the kind of content played back. 44.1 kHz 16 bit content seems to work better than 48 kHz 24 bit content. 96 kHz 24 bit content is completely unplayable (all you can hear are irregular pops on the output, somewhat like light drizzle rain on a metal roof). mpd is not saturating the CPU; it is between 5% and 30%, depending on the ALSA buffer and period time configuration. (With a buffer_time of 0.5s and a period_time of 1ms, I can get 96 kHz content to play somewhat, but with many, many gaps). There's also no significant iowait going on. Swap is turned off.

I took out my oscilloscope and looked at the signal on the wire and I noticed that most of the time (not always, but that may be my scope failing to trigger properly) when a gap occurs, the S/PDIF signal is interrupted. The smallest gap I saw was 22 microseconds. However, ALSA does *not* report a buffer underrun (via the EPIPE error code) to the application. (I also saw some significant ringing at the rising edges of my simplistic driver, which I removed with a 100pF capacitor in parallel to GND, but that did not change the issue.)

I am a bit at a loss at where to look at next. With ALSA not reporting an underrun, I'm not sure if this is a hardware or a software issue.

I saw someone else report a similar problem, but I can't find it anymore in the forums (the search is broken for me).

I'm not sure what to look at next. I'm not 100% sure this is a hardware problem, it may also be in the Linux kernel or whatnot. Feel free to move this thread if appropriate. I am trying to reproduce the issue with speaker-test currently, but so far I wasn't able to (unless when tweaking the buffer sizes well below any sensible threshold, at which point -EPIPE *is* returned from ALSA, suggesting that that then is another issue). Because of this, I decided to post this in the Linux subforum instead of the hardware one.

I appreciate any kind of input and I'm more than happy to provide scope traces, config files, schematics or anything else which may be useful in debugging this. Because I'm at this point rather clueless where to even start, I decided against uploading a swath of data, but don't hesitate to ask.

kind regards & thank you for reading,
jssfr