Fedora 35 on rock64

[dafsjr]

Hello,

It is my first post here.

I've just managed to run Fedora 35 in rock64 without external kernels, u-boot or tools.
I searched in the forum and I did not find a post about this, so I am sharing the image in my google drive, fell free to download and test, I hope you enjoy.

https://drive.google.com/drive/folders/1...sSeHehKkOC

In the drive there are some images of the system working.

You will need at least a 4GB sdcard and the system take about 40 seconds to finish the boot.
The image is using grub2 with uEFI emulated by u-boot, the USB3 port seems to work correctly, SELinux and Audit are enabled and the root filesystem is ext4.

The username and the password is rock64 and there is a sudo rule for this user.

[Rocklobster]

Hello,

It is my first post here.

I've just managed to run Fedora 35 in rock64 without external kernels, u-boot or tools.
I searched in the forum and I did not find a post about this, so I am sharing the image in my google drive, fell free to download and test, I hope you enjoy.

https://drive.google.com/drive/folders/1...sSeHehKkOC

In the drive there are some images of the system working.

You will need at least a 4GB sdcard and the system take about 40 seconds to finish the boot.
The image is using grub2 with uEFI emulated by u-boot, the USB3 port seems to work correctly, SELinux and Audit are enabled and the root filesystem is ext4.

The username and the password is rock64 and there is a sudo rule for this user.

Great work. That gives us all another OS option on the Rock64.

[dafsjr]

Hi guys,

As we know, the classic block filesystems, like ext4, xfs and even the little more modern, btrfs, don't work in the best way possible with SD cards, because of that, I created a new image using f2fs, this image is in the same link of the first post and the rules are the same of the other image.

I hope you enjoy it.

[dafsjr]

I discovered something interesting, the dtb of the Fedora's kernel has a mac address defined, so if you have more than one SBC as I do, all of them will be with the same mac address. During the boot, the dtb is loaded after the kernel, so I think there are no parameters to put in the kernel's command that solve this, I tried several and none of them worked. The only way I found to solve that until now is using the parameter 802-3-ethernet.cloned-mac-address inside the nic configuration on NetworkManager. I still working on that although.

[t4_4t]

> ... If you have more than one SBC as I do, all of them will be with the same mac address.

I think there are two main points to this issue.

Item-1)  Can "u-boot" generate board-specific "Mac Addrss" ?
Item-2)  Can "u-boot" pass "Mac Addrss" to "Linux-kernel" ?

Unfortunately, both of the above do not seem to be well implemented in the image you presented.

As for Item-2.
It is relatively easy to deal with this problem by either changing the configuration parameters of "grub" or changing to a startup method other than "grub".

However, Item-1 requires rebuilding the "u-boot" correctly.
The "Image" you provided does not correctly read the value of "eFuse", which is the source of the board-specific "Mac Addrss" generation.


> ... the dtb of the Fedora's kernel has a mac address defined, ...
I have checked and the "dtb (rk3328-rock64.dtb)" in the image you provided does not have the properties, that you claim.

Code:

// at u-boot of your original image
your original image
=> printenv cpuid# serial# ethaddr eth1addr
cpuid#=f0fefcfe000000000000000000000000
serial#=5a04dec3dea047fc
ethaddr=36:a2:19:1e:57:36
## Error: "eth1addr" not defined

---

// your original image
# ip addr (on Fedora-Linux)
    ...
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
        link/ether 4a:61:29:f2:46:e2 brd ff:ff:ff:ff:ff:ff      // at "rock64_fc35_aarch64_ext4_20220130.img.xz"
        link/ether aa:99:b7:f3:fb:b4 brd ff:ff:ff:ff:ff:ff      // at "rock64_fc35_aarch64_f2fs_20220311.img.xz"

// "grub" configuration parameters changed
# ip addr (on Fedora-Linux)
    ...
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
        link/ether 36:a2:19:1e:57:36 brd ff:ff:ff:ff:ff:ff      // at both-images

The "Mac Address" generated by "u-boot" is correctly passed to "linux-Kernel".
* However, as mentioned earlier, the "Mac Address" generated by "u-boot" itself is incorrect.

My custom u-boot

Code:

// The correct "eFuse" value of my this board and the generated "Mac Address"
=> printenv cpuid# serial# ethaddr eth1addr
cpuid#=55524b503039303038000000000xxxx
serial#=20b06b8f26ddxxxx
ethaddr=1e:81:62:6b:xx:xx
eth1addr=1e:81:62:6b:xx:XX

---

# ip addr (on Fedora-Linux)
    ...
    2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
        link/ether 1e:81:62:6b:xx:xx brd ff:ff:ff:ff:ff:ff      // at both-images

I have several "Rock64-boads" (4 of them) and the "eFuse" values are all different.
I would like to clarify this fact here.