Fedora 35 on rock64
#1
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.
  Reply
#2
(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/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.
  Reply
#3
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.
  Reply
#4
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.
  Reply
#5
> ... 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.
  Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  DietPi OS for ROCK64 MichaIng 40 16,792 11-15-2022, 05:28 PM
Last Post: Chubber
  slarm64 (unofficial slackware) Rock64 RK3328 (aarch64) mara 126 130,859 11-13-2022, 01:04 PM
Last Post: mara
  Using multiple UART's on Rock64. ramprasad 0 248 08-29-2022, 01:22 PM
Last Post: ramprasad
  Using multiple UART's on Rock64. sachineswar 0 210 08-29-2022, 12:31 PM
Last Post: sachineswar
  Rock64 v2 - did not work song / audio sqw200zu 1 371 07-29-2022, 12:08 PM
Last Post: sqw200zu
  Rock64 Rev3 doesn't boot and leds blinking fast dishins 6 5,096 06-30-2022, 06:28 PM
Last Post: rookie_267
  my rock64 can't boot rookie_267 0 396 06-27-2022, 06:52 PM
Last Post: rookie_267
  Armbian for Rock64 pineadmin 57 51,182 04-01-2022, 03:16 PM
Last Post: TRS-80
  openwrt for the rock64 wilsonYan 29 17,612 03-13-2022, 10:25 PM
Last Post: CanadianBacon
  Home Assistant Supervisor for rock64 karbon17 4 2,303 02-23-2022, 10:12 AM
Last Post: karbon17

Forum Jump:


Users browsing this thread: 1 Guest(s)