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
Debian Stretch image that boots :
U-boot used in the above build :
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:
BSD: not present
APM: not 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
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.