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.
_______________________________________________ arm mailing list -- arm@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to arm-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/arm@xxxxxxxxxxxxxxxxxxxxxxx/message/UPJRV67MJQ44O34R2TFTGT6ZLTECEJQ3/
