I see a few months ago in the mailing list that support was brought up (in the context of F27) and it was mentioned that improving support for Rockchips devices in general was intended for F28.

It doesn't appear that fedora-arm-installer currently supports the Rock64 board as far as I can tell. 

I'm trying to figure out how to add support by adding to /usr/share/arm-image-installer/boards.d and socs.d, as well as solving the lack of appropriate uboot in /usr/share/uboot for Rock64.

I flashed (and tested successfully) a community built Debian Stretch image and by comparing it's partition layout and some information from OpenSUSE I can guess at what some of it should be, but I'm not entirely sure how to make the appropriate files in socs.d, boards.d, and what all is needed in uboot ... 

Debian Stretch image that boots : https://github.com/ayufan-rock64/linux-build/releases/download/0.7.8/stretch-minimal-rock64-0.7.8-1061-arm64.img.xz
U-boot used in the above build : https://github.com/ayufan-rock64/linux-u-boot
OpenSUSE info : https://en.opensuse.org/HCL:Rock64

working stretch partition layout : 
# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.4

Partition table scan:
  MBR: protective
  BSD: not present
  APM: not present
  GPT: present

Found valid GPT with protective MBR; using GPT.
Disk /dev/sdc: 62333952 sectors, 29.7 GiB
Model: Storage Device
Sector size (logical/physical): 512/512 bytes
Disk identifier (GUID): 9CFDF7D8-766C-43DE-9354-57097D428E8F
Partition table holds up to 128 entries
Main partition table begins at sector 2 and ends at sector 33
First usable sector is 34, last usable sector is 62333918
Partitions will be aligned on 64-sector boundaries
Total free space is 30 sectors (15.0 KiB)

Number  Start (sector)    End (sector)  Size       Code  Name
   1              64            8063   3.9 MiB     8300  loader1
   2            8064            8191   64.0 KiB    8300  reserved1
   3            8192           16383   4.0 MiB     8300  reserved2
   4           16384           24575   4.0 MiB     8300  loader2
   5           24576           32767   4.0 MiB     8300  atf
   6           32768          262143   112.0 MiB   0700  boot
   7          262144        62333918   29.6 GiB    8300  root

loader1 (partition 1) is the SPL, loader2 (partition 4) is the U-Boot. atf (partition 5) per OpenSUSE is apparently some kind of "trust" image. 

The reserved partitions (partitions 2 and 3) seem to just be all nulls. 

The boot partition (partition 6) has extlinux/extlinux.conf apparently as well as 'System Volume Information' (guessing that the origin of that partition was built on Windows), and partition 7 is of course regular old Linux filesystem.

I'm not sure how fedora-arm-installer decides to partition things, it wasn't obvious from socs.d/boards.d, so I'm not sure how to ensure that when creating the soc/board scripts that the correct layout is maintained. From glancing at the source code for fedora-arm-installer it seems like it just extracts the image onto the media and assumes the layout based on what was in the image, which might present a problem if the unified AArch64 image has only 3 partitions? Unless it would be expected that Fedora would have it's own build of uboot that would ensure things didn't need all those other partitions ?

Anyways, I'm happy to either figure this out on my own if you can point me in the right direction or if you already have some WIP that needs a volunteer to test it, to do be your guinea pig.