+- PINE64 (https://forum.pine64.org)
+-- Forum: ROCK64 (https://forum.pine64.org/forumdisplay.php?fid=85)
+--- Forum: Linux on Rock64 (https://forum.pine64.org/forumdisplay.php?fid=88)
+--- Thread: Fedora 35 on rock64 (/showthread.php?tid=15916)
Fedora 35 on rock64 - dafsjr - 01-30-2022
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/1zgedunTCFiRMZktpR-d4GOsSeHehKkOC
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.
RE: Fedora 35 on rock64 - Rocklobster - 01-31-2022
(01-30-2022, 10:33 AM)dafsjr Wrote: 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/1zgedunTCFiRMZktpR-d4GOsSeHehKkOC
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.
RE: Fedora 35 on rock64 - dafsjr - 03-11-2022
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.
RE: Fedora 35 on rock64 - dafsjr - 03-16-2022
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.
RE: Fedora 35 on rock64 - t4_4t - 03-19-2022
> ... 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-imagesI have several "Rock64-boads" (4 of them) and the "eFuse" values are all different.
I would like to clarify this fact here.