OK, bought a new RockPro64, downloaded some linux images, burned some of them to eMMC, didn't boot.
The green light comes on (power) and the white light comes on and stays on. Then for about half a second the white light goes off, then goes on again for a couple of seconds. Repeat.
No HDMI output whatsoever.
Did some more reading, some searching the forums, nothing turns up but for an almost random mention somewhere that a uboot might be old.
Turns out, on new RockPro64 boards you have to install the u-boot / uboot, if you actually want to run some linux images.
Uboot is the ARM bootloader. There is a storage chip (SPI) on the RockPro64 board that holds the bootloader software.
The bootloader software is ran during boot, and if it finds a correct image, it boots that image.
Also: no information anywhere on how to actually install a new uboot.
New RockPro64 boards, it turns out, they come without a working uboot loader, or with a seriously old version that just doesn't load Linux images.
Now the information says you download an image, flash the image to an SD-card or eMMC and then boot it. When it boots, it flashes the SPI with the new uboot, and we should see a blinking white light. Which would be nice, if it actually loaded that image to start the flashing. Which it didn't. Because: no working uboot.
OK, so, the solution: download the ayufan linux image, flash that to a eMMC or SD.
E.g.: bionic-mate-rockpro64-0.9.14-1159-armhf.img.xz
Boot from that, and yes: this takes ages. But it's all good stuff.
Then open a terminal to install the .deb with:
sudo dpkg -i u-boot-rockchip-rockpro64-2017.09-rockchip-ayufan-1065-g95f6152134.deb
(make sure you are in the download folder)
Then you can install the uboot to the SPI:
sudo rock64_write_spi_flash.sh
You have to type YES with capitals to agree that this is a risky move. Then: be patient
There is a lot of scrolling... and then it's done.
Reboot, and you should be able to load images other than ayufan's.
Oh, yeah, this software works wonders for burning images: https://www.balena.io/etcher/
You don't have to 'unxz' the images, you can burn the .xz images right to an SD card or an eMMC.
This took me the better part of a day, so let's hope this post saves someone a day or an unnecessary RMA.
Also: please correct / reply if any of the above is wrong. I've only been at it for a day now.
I have two 2,5" external hard drives, which I use for backups. So far I have used them with different machines mostly on USB2 ports, never had an issue. So I thought surely the PBP USB3-port must be able to power them, but that does not seem to work. One won't spin up and sits there clicking, the other one does spin up but starts clicking once I try to mount it. So now I bought a USB-C to USB-A converter and hooked the drives up to the USB-C port, and now the one that wouldn't spin up mounts (the other one does still does not mount). I couldn't find any power specification for the USB-ports in the Rockchip datasheet, but I am a bit puzzled because so far even the cheapest netbooks would power these drives even on USB2...
Is this the expected behaviour?
With some issues of suspend, I noticed that hibernate is not an option on the default Debian OS.
Using flash drives, either eMMC or NVMe, returning from hibernate is pretty fast.
On implementation, I've always used hibernate with dedicated swap partition. That's not in the default Debian OS. Easy enough to fix.
Anyone interested in hibernate?
Or hybrid-sleep?
How does hibernate work with swap file?
Note: hybrid-sleep is a combination of suspend for a set time, and if not restored to full power on, automatically hibernate. The hibernate image is written at the beginning of hybrid-sleep. If battery power dies suddenly during the suspend phase, you still have your hibernate image to resume to.
I used an external USB 3.0 hard drive to both apply an additional power load on the system and to offload compilation writes (decrease writes to eMMC).
In summary:
The PBP performed well, no lockups or freezes experienced.
The max SoC temp measured during make -j6 was 74 degrees Celsius, within recommended operating range.
The SoC/GPU temperatures do differ throughout operation (to my surprise).
Data indicates that under kernel compilation with external hard drive attached, the battery does not discharge while attached to the DC power supply.
Subjectively, although the bottom of the laptop did get very warm it was not uncomfortably so. I did not think to measure the case temperature with anything other than my fingers.
UPDATE 02 DEC 2019:
The tools used to run the compile test can be found here:
Really enjoying my PineBook Pro, I don't mind working around a few niggles here and there and I appreciate the hard work that has gone into this (and is still going into this!). It's genuinely a lovely device.
I have just one issue that's a show-stopper: A key cap (or is it 'keycap'?) has fallen off, for no obvious reason, and I can't work out how to refit it. It's not had much use and I'm not a keyboard thumper, so it's a bit disappointing, but enough moaning - how do I get it back in place?
The scissor-type mechanism is still attached to the underside of the key cap (see attached image), and I can see that a part of it must slide under a metal hook-type piece on the keyboard... but I can't figure out how to manage that.
Has anyone else had to do this? Please help!
I know some people were planning to move their key caps around, instead of waiting for the ANSI keyboard I assume - anyone done that yet? If so, shout up.
If it's not possible to refit it (& I really hope it is!), is this a warranty-type situation?
Thanks, all, for your help.
Bicko.
Just wanted to give the Pine64 team a big thank you for making a computer that is fun for me again, in the sense of the hardware and OS (ARM is pretty new to me...not counting that one I ignore in my phone). There have been a few in my life...my first Amiga 1000, the first time I built a MP computer for Linux (Mandrake) and this little Pinebook Pro. Part of the fun is figuring out for yourself what you can get to work and navigating its quirks and attributes, but a big part of the fun is the anticipation of seeing what the community can do with it.
I know at $200.00 this is not a profit making enterprise, so thank you for producing a a device for and about the community.
I lose audio output whenever I reboot my PBP. I've gone through sound preferences, hardware, speaker options, tried different profiles and tested them. Currently "stereo output and stereo input" puts sound out. If I reboot, I no longer have sound even with the same profile I selected earlier. I have to go back to sound preferences and try other profiles. How can I get sound on the PBP consistently without changing the profile?
