[fedora-arm] Rock64 support for F28?

Post by Jonathan Vaughn
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.

Yes, I did intend on doing that, I ran into a number of problems and
also purely just ran out of time.

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

That is correct and the Rock64 particularly is different to the
Rockchips support above. The Rock64 device is not supported in
upstream u-boot which is what we ship and for a device to be
classified as fully supported by Fedora so even when the improvement
in Rockchips support lands (which I'm hoping I will finish off in
F-29, assistance would help) it's currently unlikely the Rock64 will
be in that list.

Post by Jonathan Vaughn
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.

That's two different problems and there's a bunch of other stuff that
is actually in there.

Post by Jonathan Vaughn
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 ...

Most of what you have below is interesting but most probably won't
going into a-i-i, we don't currently and personally I really not sure
i want to go the route of moving around partitions and changing
partitioning schemes on the fly there.

Post by Jonathan Vaughn
https://github.com/ayufan-rock64/linux-build/releases/download/0.7.8/stretch-minimal-rock64-0.7.8-1061-arm64.img.xz
https://github.com/ayufan-rock64/linux-u-boot
OpenSUSE info : https://en.opensuse.org/HCL:Rock64
# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.4
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.

ATF is Arm Trusted Firmware, it's a requirement of ARMv8 / aarch64.
It's a core part of the ARM architecture and handles a number of
things including the PSCI which is what handles things such as
secondary CPU startup etc.

Post by Jonathan Vaughn
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.

Being Debian I very much doubt that TBH

Post by Jonathan Vaughn
I'm not sure how fedora-arm-installer decides to partition things, it wasn't

It doesn't, only thing it does related to partitions is to optionally
grow the root partitions out to the full size of the destination
storage.

Post by Jonathan Vaughn
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.

So all the of the above is interesting but I'm not sure we actually
need to put all the bits into a series of partitions. Generally a lot
of the above appears to be based upon the way Android does this stuff.

Rockchips actually some really good docs on their boot process, a few
bits are a little out of date based on improvements in upstream U-Boot
but it's a very useful starting point:

http://opensource.rock-chips.com/wiki_Boot_option

From there we should be able to dd out the U-Boot/ATF stack to an
offset and it should just work. The bit that I've had issues with is
around the upstream ATF working on the SoCs

Peter
_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproject.org
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/***@lists.fedoraproject.org/message/WUS2SCZGD3JOHLQNZOYH45KFOJBLJEL6

Jonathan Vaughn

2018-08-10 01:23:18 UTC

So it seems one of the major hurdles to official Fedora support is getting
support in upstream U-Boot for the RK3328, and after that baking the right
kind of ARM Trusted Firmware image (though perhaps it's possible to do this
once and just handle it as a blob versus rebuilding it) ?

All the weird partitioning as you pointed out is likely due to
Android-ness, I'm sure whatever original materials Rockchip has for Linux
is built around Android assumptions, and it's likely that the community
built Debian Stretch image just followed that example.

It sounds from what you're saying as far as partitions and SPL/U-Boot/Trust
image, that we could in theory just write those to the correct locations
regardless of whether they're all in separate partitions (a la Android) or
one big partition (such as Fedora assumes), so long as there's space in the
partition layout for them all to fit in the first partition?

It looks like the default image has a FAT16 first partition, but the pine64
target then writes various things at fixed positions (and it sounds like
this would be similar for Rock64, just different things perhaps different
places) - seems like this would corrupt the FAT16 partition, but leave the
necessary boot code in the right places?

Also, reviewing the link you gave for the RK wiki, it looks like perhaps it
will want GPT partitioning :
"Write GPT partition table to SD card in U-Boot, and then U-Boot can find
the boot partition and run into kernel."

Though it's hard to know if that's a suggestion (being Android centric) or
requirement, without some experimentation.

I'm going to try just copying the boot related partitions from the working
Stretch image on top of a normal Fedora ARM image and see what happens
(other than probably "corrupting" the FAT16 partition). First to see if it
starts booting at all, secondly if it actually boots completely or goes
splat somewhere along the way.

As for the bit about 'System Volume Information' I now realize from looking
at the time stamp that it was because I had written the image with Etcher
on my Windows desktop and before I then attached the device to a Linux VM
Windows auto mounted it and had it's way with it...

Post by Jonathan Vaughn
I see a few months ago in the mailing list that support was brought up

(in

Post by Jonathan Vaughn
the context of F27) and it was mentioned that improving support for
Rockchips devices in general was intended for F28.

Yes, I did intend on doing that, I ran into a number of problems and
also purely just ran out of time.

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

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
lack of appropriate uboot in /usr/share/uboot for Rock64.

That's two different problems and there's a bunch of other stuff that
is actually in there.

Post by Jonathan Vaughn
I flashed (and tested successfully) a community built Debian Stretch

image

Post by Jonathan Vaughn
and by comparing it's partition layout and some information from

OpenSUSE I

Post by Jonathan Vaughn
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 ...

Post by Jonathan Vaughn
https://github.com/ayufan-rock64/linux-build/releases/

download/0.7.8/stretch-minimal-rock64-0.7.8-1061-arm64.img.xz

Post by Jonathan Vaughn
https://github.com/ayufan-rock64/linux-u-boot
OpenSUSE info : https://en.opensuse.org/HCL:Rock64
# gdisk -l /dev/sdc
GPT fdisk (gdisk) version 1.0.4
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

Post by Jonathan Vaughn
(partition 5) per OpenSUSE is apparently some kind of "trust" image.

Being Debian I very much doubt that TBH

Post by Jonathan Vaughn
I'm not sure how fedora-arm-installer decides to partition things, it

wasn't
It doesn't, only thing it does related to partitions is to optionally
grow the root partitions out to the full size of the destination
storage.

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
glancing at the source code for fedora-arm-installer it seems like it

just

Post by Jonathan Vaughn
extracts the image onto the media and assumes the layout based on what

was

Post by Jonathan Vaughn
in the image, which might present a problem if the unified AArch64 image

has

Post by Jonathan Vaughn
only 3 partitions? Unless it would be expected that Fedora would have

it's

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
in the right direction or if you already have some WIP that needs a
volunteer to test it, to do be your guinea pig.

Jonathan Vaughn

2018-08-10 01:52:41 UTC

Well trying to boot the Fedora image after dd'ing the Rock64 bits in place
was interesting. Didn't work, but at least the boot loader still tried got
to U-Boot, which failed to find ext2 wherever it expected it to be and then
tried to TFTP boot (which didn't work, since I don't have a TFTP boot
server set up for it, of course).

So perhaps U-Boot itself needs to be Fedora-fied in some fashion to boot a
Fedora image (versus the goofy Android-ness of the Stretch image I took the
boot loader binaries from).

Post by Jonathan Vaughn
So it seems one of the major hurdles to official Fedora support is getting
support in upstream U-Boot for the RK3328, and after that baking the right
kind of ARM Trusted Firmware image (though perhaps it's possible to do this
once and just handle it as a blob versus rebuilding it) ?
All the weird partitioning as you pointed out is likely due to
Android-ness, I'm sure whatever original materials Rockchip has for Linux
is built around Android assumptions, and it's likely that the community
built Debian Stretch image just followed that example.
It sounds from what you're saying as far as partitions and
SPL/U-Boot/Trust image, that we could in theory just write those to the
correct locations regardless of whether they're all in separate partitions
(a la Android) or one big partition (such as Fedora assumes), so long as
there's space in the partition layout for them all to fit in the first
partition?
It looks like the default image has a FAT16 first partition, but the
pine64 target then writes various things at fixed positions (and it sounds
like this would be similar for Rock64, just different things perhaps
different places) - seems like this would corrupt the FAT16 partition, but
leave the necessary boot code in the right places?
Also, reviewing the link you gave for the RK wiki, it looks like perhaps
"Write GPT partition table to SD card in U-Boot, and then U-Boot can find
the boot partition and run into kernel."
Though it's hard to know if that's a suggestion (being Android centric) or
requirement, without some experimentation.
I'm going to try just copying the boot related partitions from the working
Stretch image on top of a normal Fedora ARM image and see what happens
(other than probably "corrupting" the FAT16 partition). First to see if it
starts booting at all, secondly if it actually boots completely or goes
splat somewhere along the way.
As for the bit about 'System Volume Information' I now realize from
looking at the time stamp that it was because I had written the image with
Etcher on my Windows desktop and before I then attached the device to a
Linux VM Windows auto mounted it and had it's way with it...

Post by Jonathan Vaughn
I see a few months ago in the mailing list that support was brought up

(in

Post by Jonathan Vaughn
the context of F27) and it was mentioned that improving support for
Rockchips devices in general was intended for F28.

Yes, I did intend on doing that, I ran into a number of problems and
also purely just ran out of time.

Post by Jonathan Vaughn
It doesn't appear that fedora-arm-installer currently supports the

Rock64

Post by Jonathan Vaughn
board as far as I can tell.

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
lack of appropriate uboot in /usr/share/uboot for Rock64.

That's two different problems and there's a bunch of other stuff that
is actually in there.

Post by Jonathan Vaughn
I flashed (and tested successfully) a community built Debian Stretch

image

Post by Jonathan Vaughn
and by comparing it's partition layout and some information from

OpenSUSE I

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
uboot ...

Post by Jonathan Vaughn
https://github.com/ayufan-rock64/linux-build/releases/downlo

ad/0.7.8/stretch-minimal-rock64-0.7.8-1061-arm64.img.xz

atf

Post by Jonathan Vaughn
(partition 5) per OpenSUSE is apparently some kind of "trust" image.

Post by Jonathan Vaughn
The reserved partitions (partitions 2 and 3) seem to just be all nulls.
The boot partition (partition 6) has extlinux/extlinux.conf apparently

Post by Jonathan Vaughn
well as 'System Volume Information' (guessing that the origin of that
partition was built on Windows), and partition 7 is of course regular

old

Post by Jonathan Vaughn
Linux filesystem.

Being Debian I very much doubt that TBH

Post by Jonathan Vaughn
I'm not sure how fedora-arm-installer decides to partition things, it

wasn't
It doesn't, only thing it does related to partitions is to optionally
grow the root partitions out to the full size of the destination
storage.

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
glancing at the source code for fedora-arm-installer it seems like it

just

Post by Jonathan Vaughn
extracts the image onto the media and assumes the layout based on what

was

Post by Jonathan Vaughn
in the image, which might present a problem if the unified AArch64

image has

Post by Jonathan Vaughn
only 3 partitions? Unless it would be expected that Fedora would have

it's

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
in the right direction or if you already have some WIP that needs a
volunteer to test it, to do be your guinea pig.

Peter Robinson

2018-08-14 13:58:50 UTC

If it's a self built ATF you can do as you like as long as it's got
the bits of u-boot needed to boot UEFI. For us to ship it in Fedora we
need to build it due to policies.

Post by Jonathan Vaughn
All the weird partitioning as you pointed out is likely due to Android-ness,
I'm sure whatever original materials Rockchip has for Linux is built around
Android assumptions, and it's likely that the community built Debian Stretch
image just followed that example.
It sounds from what you're saying as far as partitions and SPL/U-Boot/Trust
image, that we could in theory just write those to the correct locations
regardless of whether they're all in separate partitions (a la Android) or
one big partition (such as Fedora assumes), so long as there's space in the
partition layout for them all to fit in the first partition?

That's my understanding, we can tweak the locations too, it's just the
SPL that needs to be in a specific spot.

Post by Jonathan Vaughn
It looks like the default image has a FAT16 first partition, but the pine64
target then writes various things at fixed positions (and it sounds like
this would be similar for Rock64, just different things perhaps different
places) - seems like this would corrupt the FAT16 partition, but leave the
necessary boot code in the right places?

The Pine64 works fine if it's a MBR partition, we've supported that
device for a couple of releases.

Post by Jonathan Vaughn
Also, reviewing the link you gave for the RK wiki, it looks like perhaps it
"Write GPT partition table to SD card in U-Boot, and then U-Boot can find
the boot partition and run into kernel."

Shouldn't make any difference what so ever, upstream u-boot will boot
either as per the UEFI standard.

Post by Jonathan Vaughn
Though it's hard to know if that's a suggestion (being Android centric) or
requirement, without some experimentation.
I'm going to try just copying the boot related partitions from the working
Stretch image on top of a normal Fedora ARM image and see what happens
(other than probably "corrupting" the FAT16 partition). First to see if it
starts booting at all, secondly if it actually boots completely or goes
splat somewhere along the way.

The FAT16 partition is where all the EFI bits reside, they are core
for booting an aarch64 Fedora system.

Post by Jonathan Vaughn
As for the bit about 'System Volume Information' I now realize from looking
at the time stamp that it was because I had written the image with Etcher on
my Windows desktop and before I then attached the device to a Linux VM
Windows auto mounted it and had it's way with it...

Yes, I did intend on doing that, I ran into a number of problems and
also purely just ran out of time.

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

That's two different problems and there's a bunch of other stuff that
is actually in there.

Being Debian I very much doubt that TBH

Post by Jonathan Vaughn
I'm not sure how fedora-arm-installer decides to partition things, it wasn't

It doesn't, only thing it does related to partitions is to optionally
grow the root partitions out to the full size of the destination
storage.

_______________________________________________
arm mailing list -- ***@lists.fedoraproject.org
To unsubscribe send an email to arm-***@lists.fedoraproject.org
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/***@lists.fedoraproject.org/message/4ZK5HZEVIZS3NPQ

Jonathan Vaughn

2018-09-26 23:50:15 UTC

I've gotten U-boot installed into the SPI by using the
u-boot-flash-spi-rock64.img.xz from
https://github.com/ayufan-rock64/linux-u-boot/releases

So in theory I can boot from not just eMMC or SD but also USB, TFTP, etc.
Also, in theory, can boot things that don't have to proper U-boot bits for
the Rock64

This works for things like Armbian and such that have Rock64 compatible
images that already booted without u-boot in SPI, but does not appear to
work for Fedora.

Booting AArch64 image I get :
Found EFI removable media binary efi/boot/bootaa64.efi
reading efi/boot/bootaa64.efi
868376 bytes read in 71 ms (11.7 MiB/s)
libfdt fdt_check_header(): FDT_ERR_BADMAGIC
## Starting EFI application at 02000000 ...
Card did not respond to voltage select!
mmc_init: -95, time 9
Scanning disk ***@ff520000.blk...
Card did not respond to voltage select!
mmc_init: -95, time 9
Scanning disk ***@ff500000.blk...
Scanning disk usb_mass_storage.lun0...
Found 3 disks
Something has gone seriously wrong: Device Error
Shim was unable to measure state into the TPM

When booting armhfp image I get :
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
510 bytes read in 106 ms (3.9 KiB/s)
Ignoring unknown command: ui
Ignoring malformed menu command: autoboot
Ignoring malformed menu command: hidden
Ignoring unknown command: totaltimeout
Fedora-Server-armhfp-28-1.1 Boot Options.
1: Fedora-Server-armhfp-28-1.1 (4.16.3-301.fc28.armv7hl)
Enter choice: 1: Fedora-Server-armhfp-28-1.1
(4.16.3-301.fc28.armv7hl)
Retrieving file: /initramfs-4.16.3-301.fc28.armv7hl.img
56591459 bytes read in 2684 ms (20.1 MiB/s)
Retrieving file: /vmlinuz-4.16.3-301.fc28.armv7hl
6672896 bytes read in 396 ms (16.1 MiB/s)
append: ro root=UUID=7ea4a72f-1f7f-42c0-a0d6-f75138f2419b
Retrieving file: /dtb-4.16.3-301.fc28.armv7hl/rockchip/rk3328-rock64.dtb
** File not found /dtb-4.16.3-301.fc28.armv7hl/rockchip/rk3328-rock64.dtb **
Skipping Fedora-Server-armhfp-28-1.1 (4.16.3-301.fc28.armv7hl) for failure
retrieving fdt

Any ideas what I can try? The armhfp I'm guessing fails because of a lack
of support for the device, the dtb file doesn't exist. But the AArch64
image has a more vague "FDT_ERR_BADMAGIC" ...

Post by Jonathan Vaughn
So it seems one of the major hurdles to official Fedora support is

getting

Post by Jonathan Vaughn
support in upstream U-Boot for the RK3328, and after that baking the

right

Post by Jonathan Vaughn
kind of ARM Trusted Firmware image (though perhaps it's possible to do

this

Post by Jonathan Vaughn
once and just handle it as a blob versus rebuilding it) ?

If it's a self built ATF you can do as you like as long as it's got
the bits of u-boot needed to boot UEFI. For us to ship it in Fedora we
need to build it due to policies.

Post by Jonathan Vaughn
All the weird partitioning as you pointed out is likely due to

Android-ness,

Post by Jonathan Vaughn
I'm sure whatever original materials Rockchip has for Linux is built

around

Post by Jonathan Vaughn
Android assumptions, and it's likely that the community built Debian

Stretch

Post by Jonathan Vaughn
image just followed that example.
It sounds from what you're saying as far as partitions and

SPL/U-Boot/Trust

Post by Jonathan Vaughn
image, that we could in theory just write those to the correct locations
regardless of whether they're all in separate partitions (a la Android)

Post by Jonathan Vaughn
one big partition (such as Fedora assumes), so long as there's space in

the

Post by Jonathan Vaughn
partition layout for them all to fit in the first partition?

That's my understanding, we can tweak the locations too, it's just the
SPL that needs to be in a specific spot.

Post by Jonathan Vaughn
It looks like the default image has a FAT16 first partition, but the

pine64

Post by Jonathan Vaughn
target then writes various things at fixed positions (and it sounds like
this would be similar for Rock64, just different things perhaps different
places) - seems like this would corrupt the FAT16 partition, but leave

the

Post by Jonathan Vaughn
necessary boot code in the right places?

The Pine64 works fine if it's a MBR partition, we've supported that
device for a couple of releases.

Post by Jonathan Vaughn
Also, reviewing the link you gave for the RK wiki, it looks like perhaps

Post by Jonathan Vaughn
"Write GPT partition table to SD card in U-Boot, and then U-Boot can find
the boot partition and run into kernel."

Shouldn't make any difference what so ever, upstream u-boot will boot
either as per the UEFI standard.

Post by Jonathan Vaughn
Though it's hard to know if that's a suggestion (being Android centric)

Post by Jonathan Vaughn
requirement, without some experimentation.
I'm going to try just copying the boot related partitions from the

working

Post by Jonathan Vaughn
Stretch image on top of a normal Fedora ARM image and see what happens
(other than probably "corrupting" the FAT16 partition). First to see if

Post by Jonathan Vaughn
starts booting at all, secondly if it actually boots completely or goes
splat somewhere along the way.

The FAT16 partition is where all the EFI bits reside, they are core
for booting an aarch64 Fedora system.

Post by Jonathan Vaughn
As for the bit about 'System Volume Information' I now realize from

looking

Post by Jonathan Vaughn
at the time stamp that it was because I had written the image with

Etcher on

Post by Jonathan Vaughn
my Windows desktop and before I then attached the device to a Linux VM
Windows auto mounted it and had it's way with it...

Yes, I did intend on doing that, I ran into a number of problems and
also purely just ran out of time.

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

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
the
lack of appropriate uboot in /usr/share/uboot for Rock64.

That's two different problems and there's a bunch of other stuff that
is actually in there.

Post by Jonathan Vaughn
make the appropriate files in socs.d, boards.d, and what all is needed in
uboot ...

Post by Jonathan Vaughn
https://github.com/ayufan-rock64/linux-build/releases/

download/0.7.8/stretch-minimal-rock64-0.7.8-1061-arm64.img.xz

Post by Jonathan Vaughn
The reserved partitions (partitions 2 and 3) seem to just be all

nulls.

Post by Jonathan Vaughn
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.

Being Debian I very much doubt that TBH

Post by Jonathan Vaughn
I'm not sure how fedora-arm-installer decides to partition things, it wasn't

It doesn't, only thing it does related to partitions is to optionally
grow the root partitions out to the full size of the destination
storage.

image

Post by Jonathan Vaughn
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

Post by Jonathan Vaughn
partitions ?
Anyways, I'm happy to either figure this out on my own if you can

point