In https://www.pine64.org/rockpro64/ it is indicated that ROCKPro64 has Lithium Battery Port in the manner of Pine64+ and Pine64-LTS, and the photo seems to show a battery connector. But in https://wiki.pine64.org/index.php?title=ROCK64 there is no mention of a lithium battery port and that clearly looked like the battery connector, it is labeled "SPDIF header" and the other possible port candidates are labeled as "PWM controlled fan header", "RTC battery backup header" and "DC out for SATA disk cable".
edit the Makefile update cross compiler folders update board to say pine phone
make (makes images)
grabbed the following afterwards:
u-boot-sunxi-with-spl.bin
copied this file to Mac book host file
booted up with jump drive on my sdcard
now I can see all drives
unmount all drives
bash-3.2# gpt -r show disk3
start size index contents
0 1 MBR
1 1952
1953 248048 1 MBR part 131
250001 7171874 2 MBR part 131 MBR part 131 7421875 23363661
See (1 1952) is not assigned, but 1
and 2 are so I zeroed out 1 - 1952 just in case left overs (This is where uboot resides be careful your deleting boot now)
bash-3.2# dd if=/dev/zero of=/dev/disk3 bs=512 seek=1 cou sync && sync && syncnt=1952
then I did the following:
bash-3.2# dd if=u-boot-sunxi-with-spl.bin of=/dev/disk3 bs=1024 seek=8 the above can be found at SUNXI sites= sync && sync && sync 1024 seek=8
Try at your own risk but it worked for me
Output on UART:
DRAM: 2048 MiB
Trying to boot from MMC2
NOTICE: BL31: v2.3(release):v1.4-5069-ga4b8b9dba
NOTICE: BL31: Built : 1592882082
NOTICE: BL31: Detected Allwinner A64/H64/R18 SoC (1689)
NOTICE: BL31: Found U-Boot DTB at 0x40647b8, model: Pine64 PinePhone (1.2)
NOTICE: PSCI: System suspend is available via SCPI
CPU: Allwinner A64 (SUN50I)
Model: Pine64 PinePhone (1.2)
DRAM: 2 GiB
MMC: Device 'mmc@1c11000': seq 1 is in use by 'mmc@1c10000'
mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1
Loading Environment from FAT... Unable to use mmc 1:2... In: serial@1c28000
Out: serial@1c28000
Err: serial@1c28000
starting USB...
No working controllers found
Hit any key to stop autoboot: 0
I've found that the information needed to replace the default OS on Pinebook Pro is scattered all over the place, and in some places, contradictory. To help newbs like me avoid the trial-by-error that I went through, I've made the following guide based on a successful replacement of Mate/Debian with XFCE/Manjaro.
Update: extended introduction to clarify the structure of the guide
First, an overview of the guide. First, to replace the eMMC distro, we need to make an ARM-compatible OS on a microSD. For the purposes of this guide, we will be using the same OS on the microSD as we are on the eMMC, but theoretically any ARM-compatible OS could be used on the microSD.
Once we have the working OS on the microSD booting on the PBP, we will use that system to use 'dd' to transfer an image of manjaro directly onto the eMMC, bit by bit.
0. Get the proper images and signatures.
First, download the images and checksums you need.
It's very important to verify that the compressed image you downloaded isn't corrupted or anything. To do that, we will be running sha256sum on our image and checking it against the checksum we downloaded.
Make sure you are in the directory containing the images, usually `~/Downloads`
Code:
$ sha256sum <target image>.img.xz
For mac, use:
Code:
$ shasum -a 256 <target image>.img.xz
This will print a string of characters followed by the name of the file. Check that checksum against the .img.xz.sha256 file. There are many ways to do this, but the simplest way is to print the file:
Code:
$ cat <target image>.img.xz.sha256
Ideally, the output will look exactly the same as the sha256sum function. If it isn't, then your image is corrupted and you need to redownload the image.
2. Decompress the image
Get xz-utils if you don't already have it installed.
Code:
$ # On Arch:
$ sudo pacman -Syu xz-utils
$ # On Debian/Ubuntu:
$ sudo apt-get install xz-utils
Then, extract the image.
Code:
$ # I like to use the -v flag so I can watch the progress of the extraction
$ unxz -k -v <target image>.img.xz
The mac equivalent is a bit different:
Code:
$ # Get xz package if you don't already have it
$ brew install xz
I recommend using balena Etcher to flash the image to microSD. Simply select the image, then the drive to flash to, and then wait for etcher to finish. It will likely take good while, so make some tea or something.
4. Boot from microSD.
Once the microSD has been flashed, pop it into the microSD drive on your Pinebook Pro and turn it on. If all has gone well, it will boot to Manjaro's desktop.
NOTE: this system is not our final OS, this is simply the environment in which we will install Manjaro the internal eMMC memory.
You will get a few setup questions:
- keyboard layout
- username
- additional groups (there's a bug here: leaving this field empty will not add the default groups, so you will have to type them in manually separated by commas)
- full name
- password
- root password
- timezone
- locale (en_US.UTF-8 if you are located in the United States)
- hostname
At this point, we still need to put Manjaro on the internal eMMC memory, so we have a few more steps to run.
5. Repeat steps 0-2
As much as I wish to tell you that the Manjaro ARM installer works, it is incredibly buggy at the moment, so this is where we will have to get technical and dangerous. Download a new image of Manjaro, verify its checksum, and decompress it, just like we did in Steps 0-2.
EDIT: To clarify, this image should be on the freshly booted microSD portion of the PBP. This cannot be done on the eMMC portion of the PBP, because we are using this image to to replace the operating system on the eMMC. It has to be done from the microSD.
6. Using dd
EDIT: First, make sure that you are booted on the microSD card. This will not work if you are working on the eMMC portion of the PBP.
At this point, I'm afraid we have to resort to the tool of last resort: dd. Jokingly, it is short for "disk destroyer", because it is incredibly literal and the slightest misspelling could destroy all data on the target.
What dd does is it does a direct bit-by-bit transfer from a target to a destination in the form of:
EDIT 2020-11-03: I have added a few arguments that make dd a little faster. `bs=4M` makes the byte copy go way faster, and is just as reliable as the default (512 bytes). I also added in the `status=progress` argument, which will show the byte copy progress in real time.
So, for our pinebook pro, we are targeting our freshly downloaded image, likely at '/home/<user>/Downloads'. The destination will be '/dev/mmcblk2', but you should use `fdisk -l` to verify that your eMMC internal storage is located there.
For my own pinebook pro, I ran:
Shutdown your system, remove the microSD card, and if all went well, you should be prompted for the same information as you were prompted for in Step 4.
8. Rejoice!
Congratulations, you have now successfully replaced the default OS on the Pinebook Pro!
I turned my Pinephone on today to find that my SIM card wasn't detected, and I found that my Pinephone is not detecting US SIM cards but after putting in a European SIM card I had it detected it just fine. The 2 distros I was running were UBPorts and Mobian, could one of them have updated the modem firmware causing this issue? I had a US SIM card working just fine 3 days ago but I updated both Mobian and UBPorts also 3 days ago and I wasn't paying attention to the SIM card status.
Edit: It actually appears to work in the factory test but wasn't working in UBPorts or Mobian.
I have a PBP and is currently running Manjaro KDE from factory on it. I have the adapter and a NVME. I was wondering if I could have just the necessary files on the eMMC to boot and then have everything else on the NVME like home directory and programs and such. I have not found an updated way to do this. Also I am open to suggestions for alternatives. I would just like to have everything touching NVME after booting while still running Manjaro KDE.
I've seen pictures on Twitter and whatnot where people have really good looking wallpapers for their PinePhone that are Pine64 related. Does anyone know where I could find something like this?
In: serial
Out: serial
Err: serial
Model: Pine64 RK3399 Pinebook Pro
Bootdev(atags): mmc 0
PartType: EFI
rockchip_get_boot_mode: Could not found misc partition
boot mode: None
init_resource_list: failed to get resource part, ret=-1
Can't find file:logo.bmp
failed to display uboot logo
CLK: (uboot. arml: enter 816000 KHz, init 816000 KHz, kernel 0N/A)
CLK: (uboot. armb: enter 24000 KHz, init 24000 KHz, kernel 0N/A)
aplll 816000 KHz
apllb 24000 KHz
dpll 800000 KHz
cpll 24000 KHz
gpll 800000 KHz
npll 600000 KHz
vpll 24000 KHz
aclk_perihp 133333 KHz
hclk_perihp 66666 KHz
pclk_perihp 33333 KHz
aclk_perilp0 266666 KHz
hclk_perilp0 88888 KHz
pclk_perilp0 44444 KHz
hclk_perilp1 100000 KHz
pclk_perilp1 50000 KHz
Net: No ethernet found.
Hit key to stop autoboot('CTRL+C'): 0
do_boot_rockchip: Could not find boot part
Checking for mmc dev 1...
Card did not respond to voltage select!
mmc_init: -95, time 9
starting USB...
USB0: USB EHCI 1.00
USB1: USB OHCI 1.0
USB2: USB EHCI 1.00
USB3: USB OHCI 1.0
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 2 USB Device(s) found
scanning bus 2 for devices... 1 USB Device(s) found
scanning bus 3 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Checking for usb dev 0...
Device 0: unknown device
Checking for mmc dev 0...
switch to partitions #0, OK
mmc0(part 0) is current device
Scanning mmc 0 for bootable partitions...
Scanning mmc 0:3 for extlinux or boot scripts...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
1992 bytes read in 67 ms (28.3 KiB/s)
select kernel
What I'm interested in, though, is the memory training speed.
Code:
channel 0 training pass!
channel 1 training pass!
change freq to 800MHz 1,0
Channel 0: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
Channel 1: LPDDR4,800MHz
Bus Width=32 Col=10 Bank=8 Row=15/15 CS=2 Die Bus-Width=16 Size=2048MB
256B stride
This is the final training pass I see in the uboot output.
Looking at the datsheet, the memory modules are either rated for 1600MHz or 1866MHz.
I've found that the RK3399 supports dynamic DRAM frequency scaling, but I haven't verified if this is working - I don't see anything about it in dmesg.
I see a peak of about 5.5GB/s running the "mbw" benchmark. At 800MHz on a 64 bit bus, I'd expect (800 * 2 * 64 / 8) = 12.8GB/s, which is consistent with a streaming copy bandwidth of around 5.5GB/s.
At 1600MHz, I'd expect to see 25.6GB/s - and I know there's display overhead, but for an optimized copy, it seems like we're not seeing the full performance of this system.
So, my questions:
0. Am I misreading the output/screwing up my math?
1. How can I verify the memory frequency in Linux?
2. Should uboot be setting the frequency to the maximum before handing off to a kernel that might not be adjusting it?
3. Should we have dynamic memory frequency stuff enabled in the kernel?
Thanks!
Well, darn. I was looking at the LPDDR4 datasheet, should have been looking at the RK3399 datasheet.
Per IRC, it just doesn't support running the memory bus up that high. Seems to be limited at 933 for DDR3, 800 for DDR4.
