Hello everyone

I received the Pinephone last week and I am happy with it. There is however one thing that I would like to share with the community: When the Pinephone is off and I plugin the powersupply the phone boots immediately. It does so from eMMC and/or SD Card and with Ubuntu Touch as well as Mobian installed.
This is occasionally inconvenient, which is why I would like to know whether this is also the case with you and whether something can be done about it.

Thank you so much and best regards!

Hi there,

I’d like to install OpenWRT in the PINE RockPro64 (followed the installation instructions here: https://openwrt.org/inbox/toh/pine64/pin...pro64_v2.1) but I have a problem now. 

I’ve downloaded the OpenWRT image from here: https://downloads.openwrt.org/snapshots/...hip/armv8/ and flashed it into a 64GB microSD card. 
When I insert the microSD card to RockPro64 and plugged in the power, there is no response. The display was black and showed nothing. 
 
Does anyone install OpenWRT in RockPro64 before? Can someone point me in the right direction? Thanks in advance!

I've had fun tinkering around with the Pro, but I think it's time I let someone with more experience contribute to the Pro community.  Really, the nail in the coffin is lack of reliable sleep mode.  This can't be my daily driver without it.  

1) Is $160 + shipping a fair price for a used systme?
2) What's the safest way to remove my personal data while keeping the system usable? I don't to want to mess anything up on the boot side.

Thanks.

I have been working on a QML program and have been obviously doing it on my computer but my PinePhone won't let me log into GitLab and will let me log into GitHub but won't let me download my code. Any idea on how to transfer my code over to my PinePhone? I was thinking of doing a libertine container for git but that isn't working right now unfortunately.

It's now 2'nd or 3rd time my PP CE boots up woth a date in year 2115 (why 2115)

The cure is to do a : hwclock -s
So the hwclock is correct , but the sysclock is waaaayy off.
If this wasn't a battery device NTP would be the solution , but here a hwclock -s seems to be the fix

I'm on "latest" apt-get update/upgrade as of today 2020-07-15




Fresh ssh after reboot

mobian@mobian:~$ date
Fri Sep  6 23:43:51 CEST 2115


mobian@mobian:~$ sudo -i
[sudo] password for mobian:
root@mobian:~#
root@mobian:~# hwclock -s
root@mobian:~# date
Wed Jul 15 17:43:51 CEST 2020
root@mobian:~#

root@mobian:~# uname -a
Linux mobian 5.7-pinephone #5.7.0+pinephone8 SMP PREEMPT Sun Jul 12 18:21:59 CEST 2020 aarch64 GNU/Linux
root@mobian:~#


/Bingo

July Community Update discussion goes here

Well, I took my Intel 660p to my brother's house and put it in his windows box and it was working, firmware updated, and showing nothing wrong.  When I dropped it back in my Pinebook Pro...nothing.  So I decided to investigate some and completely took out the main board of the PBP.  After reassembling I booted and the NMVe was there!  Drove back home and the NVMe is no longer listed as a drive.  Any idea what's going on?  So, I now know, it's not the NVME's fault.  I guess next I buy a new adapter or cable?  If that doesn't work, then what?  Main board?  

I've got an UART adapter on the way, so maybe I can tell what's up in the boot sequence.  I get the impression that something is not initializing correctly.  The last major change I made was to go to PCM720's spiflash.bin on the spi to try to get boot happening directly from the NVMe.  After all this I'm considering going to U-Boot on EMMC and system on NVME. 


Any thoughts or suggestions welcome.  Thanks!

-Josh

The video scaled output has changed in the last update on my phone.
Changed the output scale from 2 to 1.8 in /etc/phosh/phoc.ini and it has returned to the previous normal.

Just a post in case this was either not intended or, if it was intended, as a reminder on how to change it back for those wishing to.

I've been using my PinePhone Ubports edition with much success for the last few weeks, but last night I think it was exposed to too much liquid. I laid out a bunch of things from my backpack and sprayed bleach cleaner over them (because the plague). After I dried things off, I tried to charge and boot my PinePhone (stupid, I know) and all I got to was a backlit black screen. The backlight turned on and off a few times pretty systematically. I typically use Mobian, but I tried booting into Ubports as well. Nothing...not even the Pine64 logo showed up. When I insert or remove the USB cable, however, the phone plays a clicking sound effect, which makes me think the thing might not be completely dead. Not sure if this matters, but the phone was in a pretty hot environment for the preceding hour and AFAIK had exhausted its battery when I cleaned it.

If anyone has troubleshooting ideas, shoot.

If anyone knows what part I might have shorted/destroyed, let me know.

Thank you in advance for your wisdom!

Hello,

the rock64 i2c-0 when trying to quick check discover connected devices (quick read, byte read, both), does send on occasions following the NACKed address byte a 2nd start condition and stop immediately, then another 3rd start before next transfer [see the attachment], that starts with the next device address. the additional 2nd start before the stop is bothering a STM32 slave sitting on this bus (additional data point a LPC controller does not get affected). While he STM32 seems sensitive to such errors (BERR) and causes lock-up, I am interested in knowing why does the rock64 do this.

the code looks like this:

for(i=0; i<128; i++)
{
ioctl(I2cSlave, I2C_SLAVE, i);


// i2c_smbus_write_quick(I2cSlave, I2C_SMBUS_WRITE);
rc = i2c_smbus_read_byte_data(I2cSlave, commad_word);

the bus is run at 100KHz, i even tried adding a delay in the loops for 100ms, still does not help. is there a setting in device tree or in rockchip's i2c registers to prevent this from happening? If this is not normal could some other hardware/software muxed on the port pins be causing this?

[attachment: 1 NACKd-address in the capture is a normal one, that ends with a stop and the next start condition starts the next transfer. the 2nd NACKd-address ends with a added 2nd start, then stop, followed by a start for the next transfer]

Thanks,
-Michael.

Attached Files

  i2c-inserted 2nd start.png (Size: 116.65 KB / Downloads: 588)