Hello,

is anybody using the C4Labs clusterboard case and the fans?

what is the best way to power them up?

i have connected them as described in the docu, but they are not spinning up.

kind regards,
langerma

Would the ROCKPro64 5volt, 5amp power supply be uable with the Pinebook Pro?

Mostly seeing if I mis-place my PBP power supply, would I have a backup power supply using one from my ROCKPro64...

Though, now that I think about it, I have a 5v, 3a USB power brick on my desk to charge various portable devices. That might work using a USC-C cable.

Hello all,

Has anyone reused their pinebook battery for other than powering a pinebook?  Mine is in pieces right now, so I'm looking to reuse the parts I can.  

Is the connector that the pinebook battery uses easy to acquire on Amazon or other sites online?  Would I have to de-solder the connector from the main board?  I tried to plugin a male end of GPIO jumper cable into one female outputs, but the pin is too thick.

The battery meters at around 4 ish volts, so I will need to boost it to 5 volts to run a raspberry pi.

Any thoughts or suggestions?

Bonjour ...

J'ai constaté un dysfonctionnement avec un des Pine Rock Pro et le module WiFi / BT.
Sur le premier Pine le module WiFi / BT fonctionne convenablement et lorsque j'installe le même module WiFi / BT (et la même eMMC) sur le second, le module WiFi / BT est bien détecté mais ne fonctionne pas ?

Cordialement.

Guess this begs my (ignorant) question: Is there anyone talking about this? For PBP or does someone know if there's a compiled version that would work?
I like Puppy and, while my programming skills are limited, would like to help make this happen...Thanks!

Hi

I reported a bug with mono on my rock/pine devices here: https://github.com/mono/mono/issues/16770

Seems like the devs can't reproduce it on their ARM devices. I'm hoping someone here who's also using mono on 64-bit debian or ubuntu could take the effort to try and reproduce it, or maybe give me some things-to-try to solve it. It could be pine/rock/ayufan specific. 

My kernel version on the rock is 4.4.103-rockchip-ayufan-175.

Thanks.

I've gotten the stock rootfs running on the Rockpro64 SBC, using steps from a variety of sources. If desired, I'll try to hunt down the locations. Steps below:

Section 1 - Making a Good SPL

0. Perform these steps from a functional image, on the board, such as Armbian
    -note: may need to "apt-get install gcc-arm-none-eabi binutils-arm-none-eabi"

1. Get u-boot, cd into the folder
    #git clone https://gitlab.denx.de/u-boot/u-boot.git
    #cd u-boot
    #make clean

2. Get, make the Trusted code, copy it into the u-boot folder
    #git clone https://github.com/ARM-software/arm-trus...rmware.git atf
    #make -C atf PLAT=rk3399 bl31
    #cp bl31.elf ../

3. Make u-boot
    #make rockpro64-rk3399_defconfig
    #make ARCH=arm -j7


4. Write loaders to disk, or copy them to storage for Section 2
    #tools/mkimage -n rk3399 -T rksd -d tpl/u-boot-tpl-dtb.bin tpl-spl.img
    #cat spl/u-boot-spl-dtb.bin >> tpl-spl.img
    #dd if=tpl-spl.img of=/dev/mmcblkN seek=64 conv=fsync
    #dd if=u-boot.itb of=/dev/mmcblkN seek=16384 conv=fsync

Section 2 - Install Arch

0. This must be performed from a different computer, make sure uboot-tools is installed

1. Zero the beginning of the SD card:

    #dd if=/dev/zero of=/dev/sdX bs=1M count=32

2. Start fdisk to partition the SD card:

    #fdisk /dev/sdX

3. At the fdisk prompt, create the new partition:

    Type o. This will clear out any partitions on the drive.
    Type n, then p for primary, 1 for the first partition on the drive, 32768 for the first sector, and then +4G
    -this creates a 4G partition
    Write the partition table and exit by typing w.

4 . Create the ext4 filesystem:

    #mkfs.ext4 /dev/sdX1

5. Mount the filesystem:

    #mkdir something
    #mount /dev/sdX1 something

5. Download and extract the root filesystem (as root, not via sudo):

    #wget http://os.archlinuxarm.org/os/ArchLinuxA...est.tar.gz
    #tar -xpf ArchLinuxARM-aarch64-latest.tar.gz -C something

6. Use this as boot.txt, place in something/boot/
    
 

Looking forward to a Debian Buster OS release for the Pinebook Pro.  This won't work in Debian Stretch, but improvements were made that are in Buster.  Believe it or not, a Raspberry Pi 3 Model B can boot and run GNOME3 now.

What issues with conflicting custom packages, kernel modules, firmware drivers, etc. might arise when one changes the released OS image and installs:

• gdm3 in place of lightdm (assuming this is the default display manager used)
  
• gnome-core in place of MATE
  
• network-manager-gnome
  

Hi all,

I mounted an ASUS 22" touchscreen monitor to the wall of our kitchen for my wife. I hooked up an RPi4 with Raspbian and managed to get a decent enough setup with an onscreen keyboard. It's still not as nice a UX as Android though, partly because there are apps she uses that aren't available on Linux. I just found out about the Pine boxes. Would I be able to get one that will let me use Android with my touchscreen?

Thanks!

Hi Everyone,

I know that you're all eagerly awaiting your Pinebook Pros. Now that I have a little bit of free time I figured that I should update you all on what's been going on behind the scenes.

TL : DR : we hit two roadblocks that delayed the shipping process by a few weeks (2-3) - but it should be all sorted now. The first batch ought to go out (hopefully early) next week. October batches may or may not be affected; we'll likely make up some of the lost time

Here are the details:

The first problem was related to the Pinebook Pro not powering on in the event that the battery was disconnected from the main board. While this will likely not affect the grand majority of users, a suitable work-around had to be put in place in the event Pinebook Pro has to be ran without a battery. There are now two jumper cables on the PCB that can be bridged to power up the Pinebook Pro without the battery plugged in. Here is the engineering notice.

The second problem we ran into is an incompatibility between factory workflow and the RK3399 SOC boot-sequence. Prior to flashing the Debian MATE image, the factory preloads a testing build on the eMMC to determine if a Pinebook Pro unit is functional. This is after the unit is screwed together and 'completed'. Unfortunately, the inherent RK3399 boot sequence priorities eMMC over SD card, so flashing from SD / USB 2.0 is literally impossible using the build that the factory uses (NB. the custom Debian build permits SD booting prior to eMMC; this described scenario relates only the the factory OS build). In result, all units had to be unscrewed and re-flashed with the shipping build by hand and put back together. As you can surely appreciate, this takes time.

This isn't the factory's fault per se, they are just accustomed to working with SOCs which have a boot sequence hierarchy akin to the original Pinebook, which uses the Allwinner A64; this SOC priorities SD over eMMC in the boot hierarchy. In the future, the default Debian MATE build will be flashed onto the eMMC while all testing will be done from SD.

We expect that we'll make up much of the lost time in future batches, but the deadlines may shift a week or two forward in time.

So, the first batch should now be going out in just a few days, while the October pre-orders (forum member + public) may be suffer a slight delay. I'll keep you posted.

Sorry for the delay!