[ ARM64 ] build, for Pine64 RockPro64

tuxd3v · 2020-05-05 17:27:08

Hello All,
This is a preliminary build, for RockPro64
v0.2beta Server build.

Features & Versions:

1) - Arm Trusted Firmware - v2.3 ( built for arm64 )
U-boot boot-loader - v2020.04 ( built for arm64 )
2) - Linux Kernel - Stable 5.6.10 ( built for arm64 )
3) - UserSpace - Devuan Beowulf ( for arm64 )
4) - ChangeLog - update kernel,correct ethernet, hdmi, initial bringup of sound via hdmi
5) - Problems & to be done - After coming to Beowulf, its impossible to auto-mount zramfs as swap, automatically, sound via 3.5mm Jack still not possible usig codec HIFI ES8316...

1) BootLoader( ATF + u-boot )

Disk Partitioning scheme:

# parted /dev/mmcblk1
(...)                                                         
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags: 

Number  Start   End     Size    Type     File system  Flags
 1      64s      8063s     8000s                  idbloader
 2      16384s   24575s    8192s                  uboot
 3      24576s   32767s    8192s                  none
 4      32768s   262143s   229376s   ext2         boot       boot, esp
 5      262144s  3743744s  3481601s  ext4         rootfs

a) - Bootloader( Arm Trusted Firmware + U-Boot ), starting at sector 64( 1st partition.. ), and ending at sector 32767( 3rd partition.. )
a1) - The Bootloader will search for a file called 'boot.scr'( in 4th partition ), and after initialize the u-boot environment, will execute that script..
a2) - In 'boot.scr', for this image, it will point to 'RockPro64 v2.1' Device Tree Binary File by default( was tested there.. )..
a3) - If you have "RockPro64 v2", please Read Bellow in the 'Notes Section'..
b) - 4th Partition( after BootLoader ) is mounted as '/boot'
c) - 5ft Partition is mounted as rootfs '/'

NOTA!
The Bootloader in a) usually takes ~1MiB..
Each time a bootloader is built, all area [ 64s - 32767s ], needs to be clean first( so that you can flash the new bootloader.. because could still be there any bits of the previous one.. which could lead to unpredictable consequences.. ).

If you have Other Board than "RockPro64 v2.1'''( RockPro64 v2' ), situation described in a3):
The 'boot.cmd' script( format, Human Readable ):

setenv macaddr da 19 c8 7a 6d f4

#setenv devtype mmc
#setenv devnum 1

#part uuid ${devtype} ${devnum}:1 idbloaderuuid
#part uuid ${devtype} ${devnum}:2 ubootuuid
#part uuid ${devtype} ${devnum}:3 noneuuid
#part uuid ${devtype} ${devnum}:4 bootuuid
#part uuid ${devtype} ${devnum}:5 rootfsuuid

setenv bootargs "earlyprintk debug=on earlycon=uart8250,mmio32,0xff1a0000  console=tty1 console=ttyS2,1500000n8 root=/dev/mmcblk1p5 rw rootfstype=ext4 fsck.repair=yes net.ifnames=0 video=eDP-1:1680x1050@60 video=HDMI-1:1680x1050@60 bootsplash.bootfile=dev1-arm16.png"
# ubootpart=${bootuuid}
setenv fdtfile rockchip/rk3399-rockpro64.dtb

if load ${devtype} ${devnum}:4 ${kernel_addr_r} vmlinuz; then
  if load ${devtype} ${devnum}:5 ${fdt_addr_r} usr/lib/linux-image-5.6.10/${fdtfile}; then
    fdt addr ${fdt_addr_r}
    fdt resize 65536
    fdt set /ethernet@fe300000 local-mac-address "[${macaddr}]"
    booti ${kernel_addr_r} - ${fdt_addr_r};
  fi;
fi

Write this Image, to a sd-card, then mount it, and change the 'boot.cmd' script to point to your board..
# You can find a list of supported boards in: '/usr/lib/linux-image-5.6.10/rockchip'
# Edit the file 'boot.cmd', with 'vi' for example.
# change the line:
'setenv fdtfile rockchip/rk3399-rockpro64.dtb'
to
'setenv fdtfile rockchip/rk3399-rockpro64-v2.dtb'

Save the file,
# Generate the real script file( binary ), 'boot.scr'

mkimage -C none -A arm64 -T script -d boot.cmd boot.scr

2) - Linux Kernel

Packages:

There are 3 packages installed( in the future will be at least Userspace Panfrost mesa-3d graphics drivers more.. for a desktop version..):

~# dpkg -l |grep -E "(linux-.*(headers|image|libc-dev))"
ii  linux-headers-5.6.10       5.6.10-7                           arm64        Linux kernel headers for 5.6.10 on arm64
ii  linux-image-5.6.10         5.6.10-7                           arm64        Linux kernel, version 5.6.10
ii  linux-libc-dev:arm64       5.6.10-7                           arm64        Linux support headers for userspace development

The target will be to reach, ideally, full usability of all characteristics..

3) - UserSpace -Users & Passwords:

1) root - password 'toor'
2) devuan - password 'devuan'

NOTA!
SSH is enabled, so that you can login, but root login, is disabled, you should login as 'devuan', only then switch to 'root', if you want to.. for that,
After Login as 'devuan', issue:

sudo su -

And type your 'devuan' password, that's it..

4) - Changelog

a) - Kernel update to 5.6.10,
b) - Ethernet working ok
c) - HDMI is working ok, but still needs to be enabled sooner in the boot process..
d) - Panfrost kernel Driver
e) - DVFS - Dynamic Voltage Frequency Scalling working ok
f) - { IR, RTC, SPDIF } Kernel Driver test Handlers, including decoders for RAW IR( NEC, RC5(x/sz), RC6, JVC, Sony. SANYO, Sharp, MCE Keyboard/mouse, XMP )
g) - Its now possible to boot, without assigning '/dev/urandom' to crng( but there are still a warning message in the boot process... ).
h) - reboot now works OK.
i) - Fan PWM works, but always at 255( max power.. )
j) - Sound via HIFI ES8316, to 3.5mm Jack still not possible( Codec added )..
k) - Sound via HDMI, works OK!!
l) - USB Ports work, but still a warning message about usb-otg..

5) - Problems and testings to be done..

a) - After migration to beowulf, its impossible, for now, to automount zramfs as swap, automatically.. you need to issue

swapon -a

it could be related with several packages, including those( most probably): init init-system-helpers initscripts insserv eudev mawk sed( this problem doesn't occurr in the RPi1 Image..armel )

b) - Testing is needed, on camera interfaces
c) - testing is needed in LVDS panels
d) - Test IR driver shipped, tests needed
e) - Compile UserSpace Mesa Panfrost Driver stack( userspace counterpart for kernel space one.. )
f) - ~~Try to tune Fan PWM~~( if possible will be added ATS to control fan ), Right npw,
the most pratical solution would be to add;
echo 251 > /sys/class/hwmon/hwmon2/pwm1 to /etc/rc.local
g) - solve Sound via HIFI ES8316..
h) - ~~improve Sound Quality via HDMI..~~ Solved!!
i) - investigate usb-otg warning
j) - other minor warnings..

For this image, to reach more Supported Hardware and Users, your help is also needed
Testing devuan-beowulf-rockpro64-arm64-0.2.img, and posting your feedback.

SHA256sum:

4$ sha256sum devuan-beowulf-rockpro64-arm64-0.2.img.tar.xz 
ab0f9547de0d92f1516a2bbde944606043ce88a30aa098a72734782b12dbd9a3  devuan-beowulf-rockpro64-arm64-0.2.img.tar.xz

Best Regards,
tux

Last edited by tuxd3v (2020-05-12 19:17:14)

tuxd3v · 2020-05-12 19:26:58

PWM is configurable with values [ 250 - 255 ].
250 - Fan Off.
255 - Fan at maximum power..

The Fan behaviour, suggests( after several tests...), that we have 5 levels of power.. 25{1,2,3,4,5}.

'echo 251 > /sys/class/hwmon/hwmon2/pwm1' - activates Fan in the lower power applied, if you have a not so efficient Cooling system,
The value 251, maybe not sufficient, and so maybe you need to try levels above( 252-255 ).

If you have a emmc flash module in place,
And you have flashed this image to a sdcard, then if you want to boot from sdcard, you need to close Switch4( SW4 jumper close to emmc module, during at least some ~5 seconds, while applying power to the board ), if not, it will boot from the emmc module..

Of course you can also flash it to a emmc module, and then boot normally( because emmc has priority over sdcard on this board.. ).

Last edited by tuxd3v (2020-07-12 23:23:11)

cafinux · 2020-12-05 13:39:12

Looks interesting but the link goes to a 404 page. Is there someway of acquiring the image? The pine64 Rockpro is a very versatile board and I have used a few but have wanted a simple cut down img with out all the bloat. BTW I'm lazy I should set to and study the SDK.

tuxd3v · 2020-12-05 20:18:05

hello cafinux,
you can grab the image here

EDIT: there are several partitions because it is using a shceme of GPT partitions and so to make a small image was impossible, since the backup partition table is mirrored at the end of the sdcard, obligating you to do a large image..

So we make several images that you can dd to the correct places to form the final image..in that way we make a "small image"
The next image for that board, will have a traditional msdos partition scheme ignoring the 3 bootloader partitions and so will be all info in same image

If you have any doubts, just ask

Last edited by tuxd3v (2020-12-07 22:00:31)

The officially official Devuan Forum!

#1 2020-05-05 17:27:08

[ ARM64 ] build, for Pine64 RockPro64

#2 2020-05-12 19:26:58

Re: [ ARM64 ] build, for Pine64 RockPro64

#3 2020-12-05 13:39:12

Re: [ ARM64 ] build, for Pine64 RockPro64

#4 2020-12-05 20:18:05

Re: [ ARM64 ] build, for Pine64 RockPro64

Board footer