Hi Everyone,

Just wonder if there's any guide on how to read the console via UART?

I've done everything written in the wiki:

1. Bought the USB to DB9 cable.
2. Soldered a 3.5mm audio jack to it (pin 2 - to the tip, pin 3 - to the ring, pin 5 - to the sleeve).
3. Switched the UART toogle on.
4. Plugged everything in.
5. Ran screen /dev/ttyUSB0 1500000.
6. Powered on the PBP.
7. Saw nothing.

Am I missing anything here?

Found this installation guide on the Ub-ports forum for anyone interested in installing ubuntu touch.

1. Download the rootfs image from https://ci.ubports.com/job/rootfs/job/rootfs-pinephone/
   
2. Extract and write the image to an SD card
   
3. Plug SD card into phone
   
4. Boot phone
   

I'd like to know if I can boot up system on nvme SSD.
I may a little faster.

Hi

I don't have yet my dev kit, but I have just started to check for the current status.
Am I wrong if I say that there is no official project for now and people are testing things/setting up their dev setup on their side ?

Look like the most advanced project is Lup Yuen Lee's rust project (https://twitter.com/MisterTechBlog), but he seems to not use this forum.
So maybe this project is kind of official ?
I was first very surprised to see he is working in rust language. 
I always thought that rust is a very good language but not for IOT because of the code size and lack of full control. (just compare a hello world in rust and C (in release mode) and check the code size). After few research I saw that this big size come from libraries that are statically linked. In barre metal we dont use external library like libstd, so we are fine.
But I then dont have an answer to my question: is rust code bigger than C ? If yes is it acceptable ?
I have nothing against rust, it can be an opportunity to learn (I like the philosophy behind rust, and I have planed to learn it in the future), but when doing IOT stuff it's better to have full control on what we are doing. And in C you can understand what is happening in low level (assembly code). I suppose I wont be able to do that in rust.
Also in C you have full control of the FW size and of your structure. Is it also the case in rust ? I read in the net that Rust references can be fat ... 

One argument of  Lup Yuen Lee to use rust is that, rust protect us on memory corruption. But on very small system it's better to avoid use of heap (malloc/free). You dont need that. And you may even end up by fragmenting your few RAM because of different size object allocation.
And in rust if you use things like map or vector, are you then indireclty use the heap ? If yes, is there any issue on RAM fragmentation ?

One more thing: There is 512KB of ROM. In case of FW update which I suppose has to be done via bluetooth., where can we save the blob we receive ? We may have to split in 2 the ROM, right ? If it's the case then the FW code has to fit in 256 KB (less if we count the bootstrap). Is the rust code able to fit ?
Or maybe you prefer to have a smart bootloader with DFU and bluetooth inside the bootloader ?

Again I have nothing against rust, and will be happy to learn it sooner that I was expecting, but then I would like to know if someone is comfortable enough to handle this kind of issue ?

http://files.pine64.org/doc/rockpro64/ro...21-SCH.pdf
"PCIe x4"-page 27

Please refer to the above page
What we want to pay attention to is the series of parts attached to the signal "PCIE_RX3P / PCIE_RX3P".
(These parts are not a typographical mistake in the circuit diagram. These parts are actually mounted.)

----

I would like to ask someone with hardware experience.
Is it allowed to add such parts to high-speed signal lines that require strict impedance matching?
In the first place, what is the significance of adding these parts?

If such a component is added to a high-speed signal line such as "PCIEx"
The signal amplitude that passes is greatly reduced, and it can be presumed that the eye pattern at the receiving end will be severe.
And all cards of type "x4" are actually affected.
For example, "nvme", but it goes without saying that the impact is not limited to this.

I own 3 "rockpro64" units. (2 units are unstable or limited)
And I actually removed the parts described above for these.
The result is as expected,
It was confirmed that all three units were operating stably, including two units that were originally unstable (crash or limited-Link).
---

Another product, for example:
"pinebookpro_v2.1_mainboard_schematic.pdf"
Does not include the parts described above.
And it is the same for other manufacturers.
From this, it is clear that these additional parts are not due to restrictions in "RK3399".

I think it is a complete mistake in circuit design.
Perhaps they forgot to remove the parts that were added for operation verification at the prototype stage.

For some aggrevating reason something keeps changing my resolv.conf, even though I've specified dhcp address only in network manager and set dns servers.

Resolv always gets set to:

I was so happy that I got the Rockpro64 working including Wifi. But I soon found it's not stable at all. I was listening to some internet radio with SMplayer and suddenly I heard the Rockpro crashed and couple seconds later screen went total black. Only thing I could do is remove the power supply and put it back to reboot.

First I thought maybe SMplayer was fooling around but even on a new fresh reboot I left the rockpro days on to see what will happen. And sometimes after couple days it crashed again. And onetime I had it for 11 days up no problem until it went black again. 

This is my Rockpro version:
Linux rockpro64 4.4.167-1213-rockchip-ayufan-g34ae07687fce #1 SMP Tue Jun 18 20:44:49 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux

Anyone also had these kind of problems? 

In the future I would like to run small things 24/7 on the Rockpro and need a stable one for that.

Thanks

Hello to the few of you in the same situation as me. As Luke suggested last week, I emailed the pine team to get an update on my order. I placed my order back in September and received an email in late October saying that my order would be shipping soon. Since then I haven't received any information from DHL. This is the response from the pine team in case some of you didn't get one: 


Hello there,

Thanks for your message.
We apologize as our China dispatch team was delayed the estimate shipping date on last week due to the civil unrest in Hong Kong.
They will try to travel to Hong Kong on this week to dispatch the Pinebook Pro if the civil unrest nearby our warehouse is calm down.

Appreciated for your patient and sorry for any inconvenience caused.

If you need further help, please do not hesitate to let us know.

We will be more than happy to assist you.


Have a great day.

Thanks. 
 
Sincerely,
[b]PINEBOOK Team[/b]
[u]http://www.pine64.org[/u]

I ordered my pinephone, and I am now thinking how to connect extra hardware to this pocket PC.
What I found so far is this (the 6in1 version):

https://nl.aliexpress.com/item/4000183847600.html


The big question, is this going to work with the pinephone?

In the sellers text there are 3 chips mentioned:

RTL5411 (3x USB3-hub)
VL102 (PD-port)
IT6563 (HDMI port)

What to do, ordering it now so I got it hopefully at the same time as the pinephone arrives, or better buy something else?

I am trying to get the [unsupported] armbian image to load from eMMC on my pine h64 model b.  The armbian image 

https://dl.armbian.com/pineh64/archive/A..._5.1.15.7z

seems to work like a charm on SD, but I'd like to get the os onto eMMC for faster io.  I have been able to get the Android eMMC and AOSC builds to boot from eMMC on this board, but I'd really prefer Armbian, just because it is a known and will be similar to the rock64 boards I have running Armbian.

However, flashing the image directly onto eMMC doesn't seem to work.  Trying to boot just gives me a black cursor on the serial console.  No activity at all, no u-boot or anything.  As far as I can tell, this should work.  The image seems to have the correct `eGON.BT0` header at the right offset in the image, so I presumed it would have/should have booted.  But no dice

I am new to u-boot, but took a stab at building and installing it onto the eMMC for the h6 anyway, using as a guide: 

http://linux-sunxi.org/Mainline_U-Boot

After following the instructions, building u-boot on a rock64 (targeting the h6), and writing it to the eMMC at the 8kb offset, I pop the card onto the h6.  

However on boot I end up with :

Quote:U-Boot SPL 2020.01-rc2-00035-g3ff1ff3ff7 (Nov 17 2019 - 10:16:56 +0000)
DRAM: 4096 MiB
Trying to boot from MMC2