FriendlyELEC-Forum

Power & Source of Big Ideas
https://www.friendlyelec.com/Forum/

Fedora on NanoPC-T4

https://www.friendlyelec.com/Forum/viewtopic.php?f=61&t=3571

Page 1 of 1

Fedora on NanoPC-T4

Posted: Wed May 05, 2021 8:37 pm
by usual user
My micro SD card went full, hence I migrated my OS configuration to a new card. Thereby I wondered how my setup would work for someone else. So I also created a trial image and uploaded Fedora-trial-01-aarch64-34-1.2.img. If you like and have a spare micro SD card, put the image on it and report your observations with my deployment.

Re: Fedora on NanoPC-T4

Posted: Thu May 27, 2021 5:36 pm
by supergordon
Hey, good job on this :D . It runs absolutely smooth. Also youtube playback with the web browser Falcon is very smooth. Browsing through the web feels more like it should be - less laggy experience.

Glmark run very well without stuttering - looks like it is hardware accelerated.

Kodi also runs very good. With hardware acceleration of course. But did'nt test 4K yet but I will asap.

I would love to see more releases from your customized fedora linux. :)

Re: Fedora on NanoPC-T4

Posted: Thu May 27, 2021 8:23 pm
by usual user
supergordon wrote:
Kodi also runs very good. With hardware acceleration of course. But did'nt test 4K yet but I will asap.
I doubt that it will be hardware accelerated as I know ffmpeg mainline is missing some support for it. LibreELEC is carrying some patches for it, but they are on some older version. I. e. I am not aware of suitable patches to rebuild the package. I'm not sure if Kodi also requires some love or if kodi-19.1 is sufficient. It is just pushed to stable (update report) and "dnf upgrade" will probably pull it in.
supergordon wrote:
I would love to see more releases from your customized fedora linux.
User space is pure fedora, i. e. "dnf upgrade" will keep it up to date. What you see is only my personal configuration how I set up fedora for me. The only exception you cannot get from fedora is uboot and the kernel in the provided form. I rebuild the packages with some early adoption patches and modified some configurations to my personal taste.

Re: Fedora on NanoPC-T4

Posted: Fri May 28, 2021 12:44 pm
by supergordon
Hey there,

currently writing this post with your customized fedora - I use it all day long and I really like it. I have like 20 browser tabs open, pdfreader and the terminal and nothing lags. everything is promptly loaded. thats a real desktop pc feeling

The images from friendlyarm (friendlydesktop, lubuntu) feel like they not good ports (except android, thats a good port) and are also lagging. You cant do heavy browsing activities in the internet without anything to lag or for something wait to load. even with armbian it sucks browsing the internet with chrome or firefox (but as a server without gui its the best you can have.

thank you for letting me see what the nanopct4 is really capable of

Re: Fedora on NanoPC-T4

Posted: Fri May 28, 2021 3:18 pm
by usual user
supergordon wrote:
I have like 20 browser tabs open, pdfreader and the terminal and nothing lags. everything is promptly loaded.
The same goes for me, but I'm also building the kernel package on the second desktop at the same time.
screenshot.jpeg
screenshot.jpeg (124.1 KiB) Viewed 56939 times

Re: Fedora on NanoPC-T4

Posted: Fri May 28, 2021 11:51 pm
by supergordon
what kernel source did you take? http://opensource.rock-chips.com/wiki_Upstream_Kernel
the one with rockchip specific fixes/additions or the unmodified kernel source?

this page might be helpful http://opensource.rock-chips.com/wiki_Main_Page

and also their github https://github.com/rockchip-linux

Re: Fedora on NanoPC-T4

Posted: Sat May 29, 2021 8:29 am
by usual user
supergordon wrote:
what kernel source did you take?
I only care for mainline. Fedora follows mainline very close, so I'll grab the kernel source package from here, add my modifications, and rebuild. Currently I only carry this two relevant patch sets: add_select_SND_SOC_RT5651 and add-dp-alt-mode-to-PBP. And of course my personal kernel configuration settings, but these are mainly fliping modules to build-in as I prefer to run without initramfs.
So what you see with my image is, with the exception of the typec hack, pure mainline.

Re: Fedora on NanoPC-T4

Posted: Mon May 31, 2021 12:08 am
by usual user
Running on Wayland gives a nice performance boost.

Code: Select all

[lxqt@trial-01 ~]$ glmark2

=======================================================
    glmark2 2021.02
=======================================================
    OpenGL Information
    GL_VENDOR:     Panfrost
    GL_RENDERER:   Mali T860 (Panfrost)
    GL_VERSION:    3.1 Mesa 21.1.1
=======================================================
.
.
.
=======================================================
                                  glmark2 Score: 107
=======================================================

Code: Select all

[lxqt@trial-01 ~]$ glmark2-es2

=======================================================
    glmark2 2021.02
=======================================================
    OpenGL Information
    GL_VENDOR:     Panfrost
    GL_RENDERER:   Mali T860 (Panfrost)
    GL_VERSION:    OpenGL ES 3.0 Mesa 21.1.1
=======================================================
.
.
.
=======================================================
                                  glmark2 Score: 182
=======================================================

Code: Select all

[plasma@trial-01 ~]$ glmark2

=======================================================
    glmark2 2021.02
=======================================================
    OpenGL Information
    GL_VENDOR:     Panfrost
    GL_RENDERER:   Mali T860 (Panfrost)
    GL_VERSION:    3.1 Mesa 21.1.1
=======================================================
.
.
.
=======================================================
                                  glmark2 Score: 594
=======================================================

Code: Select all

[plasma@trial-01 ~]$ glmark2-es2

=======================================================
    glmark2 2021.02
=======================================================
    OpenGL Information
    GL_VENDOR:     Panfrost
    GL_RENDERER:   Mali T860 (Panfrost)
    GL_VERSION:    OpenGL ES 3.0 Mesa 21.1.1
=======================================================
.
.
.
=======================================================
                                  glmark2 Score: 615
=======================================================

Re: Fedora on NanoPC-T4

Posted: Wed Jun 02, 2021 8:03 pm
by usual user
I have now ffmpeg with these patches applied in place.

Code: Select all

External libraries providing hardware acceleration:
cuda                    nvdec                   v4l2_request
cuda_llvm               nvenc                   vaapi
cuvid                   opencl                  vdpau
ffnvcodec               v4l2_m2m                vulkan
But as I don't know how to verify the hardware acceleration, I'm not sure if something else is also required.
screenshot.jpeg
screenshot.jpeg (109.1 KiB) Viewed 56681 times

Re: Fedora on NanoPC-T4

Posted: Mon Jun 07, 2021 2:33 pm
by tony013
@usual user - thank you for the pointer to this lovely place :)
Didn't know that before.

Don't know, whether it is ok, posting in this forum without having a nano...

I never got in touch with fedora, but seeing your amazing work makes me want to try it. Could you please shine me a light, on how to start?
I only have debian systems - is it possible to build fedora on a debian?

Re: Fedora on NanoPC-T4

Posted: Tue Jun 08, 2021 8:37 pm
by usual user
Fedora is not device-specific, only architecture-specific. The only device specific for Arm is the bootloader in the firmware area. For Rockchip the firmware area looks like this. To boot my aarch64 image you only need a distro-boot capable u-boot for your device in there. Fedora comes with mainline u-boot for several devices. See /usr/share/uboot in my image for reference. To get one from there on the spot, something like this should be enough:

Code: Select all

dd bs=512 seek=64 conv=notrunc if=/usr/share/uboot/rock-pi-4-rk3399/u-boot-rockchip.bin of=/dev/${DEVICE}" ; sync
Since the quality is quite different, the suitability can be quite worthy. At least for my NanoPC-T4 it was not to my liking.
But you can borrow a working firmware area from another image.
First check if the u-boot is distro-boot capable. Therefor put a /extlinux/extlinux.conf in the boot partition and see if u-boot picks it up while booting:

Code: Select all

Retrieving file: /extlinux/extlinux.conf
The contend does not realy matter for this test. Mainline u-boot builds from Armban have mostly distroboot enabled ;-)
Then copy out the firmware area like this:

Code: Select all

dd bs=512 seek=64 count=32704 conv=notrunc if=/dev/${DEVICE} of=firmware.img
And then re-enter in my image.

Code: Select all

dd bs=512 seek=64 conv=notrunc if=firmware.img of=/dev/${DEVICE}" ; sync
A suitable dtb should be available. See /usr/lib/modules/5.12.0-198.fc34.aarch64/dtb/rockchip in my image for reference. If not automatically selected correctly, it can be set fixed by e.g.:

Code: Select all

fdt    /usr/lib/modules/linux-default/dtb/rockchip/rk3399-nanopc-t4.dtb
in /extlinux/extlinux.conf

tony013 wrote:
I only have debian systems - is it possible to build fedora on a debian?
You know fedora is a distribution?

Re: Fedora on NanoPC-T4

Posted: Wed Jun 09, 2021 2:53 am
by tony013
Thank you very much for your reply!

You know fedora is a distribution?

Sure! I build tweaked libreElec, and compiled (partly) armbian, so I thought, have to do similar to get your image into play

To boot my aarch64 image you only need a distro-boot capable u-boot for your device in there.

I don't know enuf of boot process yet, to understand, how things could be tweaked. I have a "rockchip-bsp" repo cloned from radxa and LE as well as armbian should have similar too.

I'm a bit confused about the dd-commands which write to device. dd is a stupid tool, that copies just blocks, so to me it looks like first and last dd write to the same location, so they overwrite each other.

First check if the u-boot is distro-boot capable. Therefor put a /extlinux/extlinux.conf in the boot partition and see if u-boot picks it up while booting

Where can I find that output?
Actually I have the problem, that all my rockpis don't write anything to computer monitor. I only have output using AVR and beamer - which is not the right equipment to test SOCs

Re: Fedora on NanoPC-T4

Posted: Wed Jun 09, 2021 6:42 am
by usual user
tony013 wrote:
I build tweaked libreElec, and compiled (partly) armbian, so I thought, have to do similar to get your image into play
At this stage, no tweaks or compilations are required, only existing code must be copied to its place.
tony013 wrote:
dd is a stupid tool, that copies just blocks, so to me it looks like first and last dd write to the same location, so they overwrite each other.
Rockchip's maskrom code starts executing its firmware at sector 64, hence bootloader code has to start there. My commands describe two times the same operation, execept the location where the bootloader is obtained is different. In my image fedora comes with these bootloaders built from mainline:

Code: Select all

a64-olinuxino          amarula_a64_relic          bananapi_m2_plus_h5                        
bananapi_m64           beelink_gs1                dragonboard410c                                         
dragonboard820c        evb-rk3328                 evb-rk3399                                              
ficus-rk3399           firefly-rk3399             geekbox                                                 
hikey                  khadas-edge-captain-rk3399 khadas-edge-rk3399                                      
khadas-edge-v-rk3399   khadas-vim                 khadas-vim2                                             
khadas-vim3            khadas-vim3l               libretech-ac                                            
libretech_all_h3_cc_h5 libretech_all_h3_it_h5     libretech_all_h5_cc_h5                                  
libretech-cc           mvebu_espressobin-88f3720  mvebu_mcbin-88f8040                                     
nanopc-t4-rk3399       nanopi_a64                 nanopi-k2                                               
nanopi-m4-2gb-rk3399   nanopi-m4-rk3399           nanopi_neo2                                             
nanopi-neo4-rk3399     nanopi_neo_plus2           nanopi-r2s-rk3328                                       
odroid-c2              orangepi_3                 orangepi_lite2                                          
orangepi_one_plus      orangepi_pc2               orangepi_prime                                          
orangepi-rk3399        orangepi_win               orangepi_zero2                                          
orangepi_zero_plus     orangepi_zero_plus2        p212                                                    
p2371-2180             p2771-0000-500             p3450-0000                                              
pine64-lts             pine64_plus                pinebook                                                
pinebook-pro-rk3399    pine_h64                   pinephone                                               
pinetab                poplar                     puma-rk3399                                             
roc-cc-rk3328          rock64-rk3328              rock960-rk3399                                          
rock-pi-4c-rk3399      rock-pi-4-rk3399           rock-pi-e-rk3328                                        
rock-pi-n10-rk3399pro  rockpro64-rk3399           roc-pc-mezzanine-rk3399                                 
roc-pc-rk3399          rpi_3                      rpi_4                                                   
rpi_arm64              sopine_baseboard           tanix_tx6                                               
teres_i                turris_mox                 vexpress_aemv8a_juno                                    
xilinx_zynqmp_virt
If the one provided there is not sufficient, I described how to extract one from a known good image. Since the real size is not known, the entire firmware area is extracted.
tony013 wrote:
Where can I find that output?
At the serial console for sure. Access to the serial console is recommended because video displays usually initialized too late, if at all.

Re: Fedora on NanoPC-T4

Posted: Wed Jun 09, 2021 2:31 pm
by tony013
Thanks a lot for your patience and support!

At this stage, no tweaks or compilations are required, only existing code must be copied to its place.

That sounds almost too good to be true.
So you say, that i.e. taking kodi from LE and copy it to whatever linux image should work?
Beautiful - I'll try that

At the serial console for sure. Access to the serial console is recommended because video displays usually initialized too late, if at all.

Ok, just ordered a serial cable - will take some days to arrive.

I'm very curious, what will be possible with serial console enabled :)
(stil dreaming of multiboot on rockpi ... )

Re: Fedora on NanoPC-T4

Posted: Wed Jun 09, 2021 4:37 pm
by usual user
tony013 wrote:
So you say, that i.e. taking kodi from LE and copy it to whatever linux image should work?
No, we are not talking about user space. We are talking about to make my image bootable for your device.
Anyway, I rebuild the uboot-tools for another reason and since your device seems quit identical to mine bootloaderwise, I also build the rock-pi-4 version with my tweaks in place also.
You should now be ready to go. I uploaded two versions because I don't know which exact device you have.
So, put my image on a sdcard, chose the right bootloader and put it with

Code: Select all

dd bs=512 seek=64 if=u-boot-rockchip.bin of=/dev/${DEVICE}
in place. Boot the device with this prepared sdcard and see how far you get.

Re: Fedora on NanoPC-T4

Posted: Thu Jun 10, 2021 2:25 am
by tony013
No, we are not talking about user space. We are talking about to make my image bootable for your device.

Ah ok. I understand.

I don't know which exact device you have.

I have rockpi-4a with 2Gb and 4Gb Memory

Boot the device with this prepared sdcard and see how far you get.

Thank you very much for your work and all the valuable pointers.
When I receive my USB-serial cable, I hope to find out more about u-boot.

Re: Fedora on NanoPC-T4

Posted: Thu Jun 10, 2021 12:24 pm
by supergordon
Hello,

I've tried to resize the main partition that is only around 4GB big with gparted, but it refuses to boot then.
It just gives some unspecific errors at the very beginning of the boot process.

Could you help me on that? I need much more space than 4GB, I can't even finish doing updates because no space is left.

Re: Fedora on NanoPC-T4

Posted: Thu Jun 10, 2021 2:12 pm
by tony013
Boot the device with this prepared sdcard and see how far you get.

Tried it, just without serial console (have to wait for cable).
I wrote your image to sdcard using balena ...
... and as I did not know, whether your "of=/dev/$(DEVICE)" is the disk device or the partition device (i.e. sdf or sdf1) I tried both.
None of them works.
I checked my network monitor - where no additional client appeared.
(Booting other images I have no output on monitor too, but they appear in network monitor as new dhcp-client and I can login via ssh).

Access to the serial console is recommended because video displays usually initialized too late, if at all.

Do you know, who is resposible to initialize graphic output?

At the beginning every image had early screen output (systemd logs), but since my failure of putting an emmc card with valid installation to another rockpi, none of them has any output to computer monitor. But they do have output, if I connect the soc to my beamer :(

Re: Fedora on NanoPC-T4

Posted: Thu Jun 10, 2021 7:33 pm
by usual user
supergordon wrote:
Could you help me on that?
Gparted probably garbled the partuuid. Check with:

Code: Select all

lsblk -o +PARTUUID
If the partuuid has been changed, restore the original, or more simply, replace all partuuid values in /extlinux/extlinunx.conf with the one displayed by lsblk.

Re: Fedora on NanoPC-T4

Posted: Thu Jun 10, 2021 7:43 pm
by usual user
tony013 wrote:
I did not know, whether your "of=/dev/$(DEVICE)" is the disk device or the partition device
An image is an image is an image, hence the entire device.
tony013 wrote:
Do you know, who is resposible to initialize graphic output?
For u-boot output u-boot. The provided one should have everything necessary activated. But I'm really not sure what you're doing, I'm not even sure if you put u-boot in. At least you didn't mention it.
As long as you don't have serial console access, let us start entirely basic. Start with a entire empty SD card. Therfore run:

Code: Select all

dd if=/dev/zero of=/dev/sdf
Let it run till it stops with "no space left on device". Then dd the u-boot-rockchip.bin in place. Put the SD card in your device and remove any emmc modules. Now start your device. If still no output, retry with your beamer connected.

Re: Fedora on NanoPC-T4

Posted: Thu Jun 10, 2021 8:25 pm
by supergordon
usual user wrote:
supergordon wrote:
Could you help me on that?
Gparted probably garbled the partuuid. Check with:

Code: Select all

lsblk -o +PARTUUID
If the partuuid has been changed, restore the original, or more simply, replace all partuuid values in /extlinux/extlinunx.conf with the one displayed by lsblk.


Thank you, that is wotking very well. I edited extlinux.conf to match the new partuuid after the partition has been resized. :)

Re: Fedora on NanoPC-T4

Posted: Sat Jun 12, 2021 2:59 am
by tony013
But I'm really not sure what you're doing, I'm not even sure if you put u-boot in. At least you didn't mention it.

I wrote:
I wrote your image to sdcard using balena ...
... and as I did not know, whether your "of=/dev/$(DEVICE)" is the disk device or the partition device (i.e. sdf or sdf1) I tried both.
None of them works.

So having written the image to sdcard with balena, the only command where I could confuse "of=/dev/$(DEVICE)" is the u-boot transfer.

  • So first try (before my quoted post):
    sd-card initialized with balena writing your image on it
    Then writing u-boot to /dev/sdf1
    Insert the sd-card into rockpi and power it on. Nothing happens
  • second try (before my quoted post):
    sd-card initialized with balena writing your image on it
    Then writing u-boot to /dev/sdf
    Insert the sd-card into rockpi and power it on. Nothing happens
  • Third try (yesterday):
    wipeout of sdcard with dd
    Writing your image to sdcard with balena
    Writing u-boot to /dev/sdf
    Connect rockpi to beamer and power it on.
    I saw some boot messages where I thought, I had read the word "Fedora" - but it was to fast. Then the obvious systemd messages and after appearance of gui I had to realize, that the rockpi did boot another system from emmc.

On other rockpi with emmc - when I insert a sd-card, rockpi boots from sdcard and not from emmc.

Anyway - I removed the emmc and powered the rockpi on again - having the sdcard with your image inserted. Some boot messages appeared, but after reset of graphic system, nothing more. No systemd messages, no gui, nothing.

Sadly the boot messages disappeared to fast, so I can't say, what really happened. Hope that will be better with serial console ...

And I don't understand the fact, that this rockpi has no output connected to computer monitor (whatever linux I insert to boot from), but does have correct output connected to a beamer. Other rockpi has correct output connected to computer monitor.
The only difference is, that the computer monitor has no hdmi-input, so I use a hdmi to dvi converter.
I checked edid-data from both situations - they appear correct to my limited knowledge.

Re: Fedora on NanoPC-T4

Posted: Sat Jun 12, 2021 2:52 pm
by usual user
When I said I don't know what you're doing, it was because of the use of balena. As you can see from the previous conversation with @supergordon, software sometimes does things that the user does not intend. Because you do not have serial console access and thus log messages can not simply roll back, I have suggested removing all software from the system. With only the firmware in place, and not even my image involved, the following should have happened: U-boot initializes the video display and begins to output messages from its search for a suitable configuration. Since no configuration should be found now, the process should end with access to the u-boot console. There should now be u-boot commands enterable. The experiment with the beamer should serve to check the basic function with a known functioning display. If the video display initialization fails at this stage, any further attempts can be set because the firmware is not suitable in this state. Otherwise, the investigation into the causes could have continued. Mainline primarily supports only original HDMI modes, even for the kernel there are different patches to partially solve this. So it remains only the method to find a working image and to export the firmware with the given requirements (distroboot support) to boot my image.
tony013 wrote:
And I don't understand the fact, that this rockpi has no output connected to computer monitor (whatever linux I insert to boot from), but does have correct output connected to a beamer
Perhaps these were all attempts based on unmodifiered mainline code.
tony013 wrote:
Other rockpi has correct output connected to computer monitor. The only difference is, that the computer monitor has no hdmi-input, so I use a hdmi to dvi converter.
This probably forces an original HDMI mode and therefore works.

Re: Fedora on NanoPC-T4

Posted: Sun Jun 13, 2021 8:18 am
by usual user
I have now a kernel with pcie nvme enabled in place.
Now my Samsung SSD 970 EVO Plus is the fastes disk in town.

Code: Select all

/dev/disk/by-path/platform-f8000000.pcie-pci-0000:01:00.0-nvme-1:
 Timing buffered disk reads: 2188 MB in  3.00 seconds = 728.87 MB/sec

 /dev/disk/by-path/platform-fe320000.mmc:
 Timing buffered disk reads: 158 MB in  3.04 seconds =  52.06 MB/sec

 /dev/disk/by-path/platform-fe330000.mmc:
 Timing buffered disk reads: 778 MB in  3.00 seconds = 258.98 MB/sec

 /dev/disk/by-path/platform-xhci-hcd.0.auto-usb-0:1:1.0-scsi-0:0:0:0:
 Timing buffered disk reads: 984 MB in  3.00 seconds = 327.93 MB/sec

 /dev/disk/by-path/platform-xhci-hcd.5.auto-usb-0:1.1:1.0-scsi-0:0:0:0:
 Timing buffered disk reads: 196 MB in  3.02 seconds =  64.81 MB/sec
 
 /dev/disk/by-path/platform-xhci-hcd.5.auto-usb-0:1.4:1.0-scsi-0:0:0:0:
 Timing buffered disk reads: 118 MB in  3.02 seconds =  39.11 MB/sec

Re: Fedora on NanoPC-T4

Posted: Sun Jun 13, 2021 1:09 pm
by tony013
Very impressive!
Well done :)

I've checked the installation images (I tested so far) for firmware section and I guess, LibreElec is the best suitable template for new images.
It uses "unscrambled" syslinux with well separated spaces.

file output of an LE-image (formatted for better readability):

Code: Select all

LibreELEC-RK3399.arm:

DOS/MBR boot sector;

partition 1 : ID=0xc, active,
              start-CHS (0x10,0,1),
              end-CHS (0x3ff,3,32),
              startsector 32768,
              1048576 sectors;

partition 2 : ID=0x83,
              start-CHS (0x3ff,3,32),
              end-CHS (0x3ff,3,32),
              startsector 1081344,
              65536 sectors


Partition 1 contains kernel, ramdisk, dtb and extlinux.conf, whereas partition 2 is the root-fs, that get mounted at ramdisk. If its true, that userspace area does not depend on firmware, than you could provide fedora for lot of devices this way.

May be I found a source, why your image does not work on rockpi. Address locations are quite different from LE and your image:

Code: Select all

Fedora-trial-01:

DOS/MBR boot sector;

partition 1 : ID=0x83,
              active,
              start-CHS (0x40,0,1),
              end-CHS (0x1e6,63,32),
              startsector 131072,
              9254912 sectors

Re: Fedora on NanoPC-T4

Posted: Sun Jun 13, 2021 3:36 pm
by usual user
tony013 wrote:
Partition 1 contains ... extlinux.conf
If u-boot also emits messages on screen from its actions, everything that is needed is already available. Transfer the firmware area to my image as described above and it would have to work. If this is not the case, it is impossible to continue the analysis meaningfully without a serial console log.
tony013 wrote:
Address locations are quite different from LE and your image
From a firmware point of view, the partition layout is insignificant. Since the firmware area for Rockchip ranges from sector 64 to sector 32767, the only requirement for partition layout is not to overlap this area with other use.

Re: Fedora on NanoPC-T4

Posted: Mon Jun 14, 2021 8:22 am
by usual user
gstreamer1-1.19.1-1 makes use of hardware-accelerated video components for sure.
gstreamer1.png
gstreamer1.png (195.05 KiB) Viewed 55446 times

Re: Fedora on NanoPC-T4

Posted: Tue Jun 15, 2021 5:00 pm
by tony013
Hi,

just got my serial cable, so I tested it with start of LE:

Code: Select all

Boot1: 2018-06-26, version: 1.14
CPUId = 0x0
ChipType = 0x10, 221
Spi_ChipId = b4016
SpiBootInit:0
mmc0:cmd5,32
SdmmcInit=0 0
BootCapSize=0
UserCapSize=7616MB
FwPartOffset=2000 , 0
StorageInit ok = 148592
SecureMode = 0
SecureInit ret = 0, SecureMode = 0
GPT  signature is wrong
LoadTrust Addr:0x1800
LoadTrust Addr:0x1c00
LoadTrust Addr:0x2000
No find bl30.bin
No find bl32.bin
Load uboot, ReadLba = 1000
hdr 00000000031912c0 + 0x0:0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x0                                                                                                           0,0x00,0x00,0x00,0x00,0x00,

Load OK, addr=0x200000, size=0xa44f8
RunBL31 0x40000
NOTICE:  BL31: v1.3(debug):734d84297
NOTICE:  BL31: Built : 15:30:40, Dec 12 2019
NOTICE:  BL31: Rockchip release version: v1.1
INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
INFO:    Using opteed sec cpu_context!
INFO:    boot cpu mask: 0
INFO:    If lpddr4 need support multi frequency,
INFO:    please update loader!
INFO:    Current ctl index[0] freq=400MHz
INFO:    Current ctl index[1] freq=800MHz
INFO:    plat_rockchip_pmu_init(1190): pd status 3e
INFO:    BL31: Initializing runtime services
WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE init                                                                                                           ialization. SMC`s destined for OPTEE will return SMC_UNK
ERROR:   Error initializing runtime service opteed_fast
INFO:    BL31: Preparing for EL3 exit to normal world
INFO:    Entry point address = 0x200000
INFO:    SPSR = 0x3c9


U-Boot 2017.09 (Jun 04 2021 - 12:56:38 +0200), Build: jenkins-RK3399-664

Model: Rockchip RK3399 Evaluation Board
DRAM:  2 GiB
Relocation Offset is: 7fd1a000
PMIC:  RK808
pwm-regulator(vdd-center): init 950000 uV
vdd_center 950000 uV
regulator(vdd-center) init 950000 uV
MMC:   dwmmc@fe320000: 1, sdhci@fe330000: 0
Using default environment

In:    serial@ff1a0000
Out:   serial@ff1a0000
Err:   serial@ff1a0000
Model: Rockchip RK3399 Evaluation Board
Net:   eth0: ethernet@fe300000
Hit any key to stop autoboot:  0
switch to partitions #0, OK
mmc1 is current device
Scanning mmc 1:1...
Found /extlinux/extlinux.conf
Retrieving file: /extlinux/extlinux.conf
reading /extlinux/extlinux.conf
229 bytes read in 6 ms (37.1 KiB/s)
1:      LibreELEC
Retrieving file: /KERNEL
reading /KERNEL
23738376 bytes read in 1004 ms (22.5 MiB/s)
append: boot=UUID=0406-4807 disk=UUID=f14037c4-47c3-40ce-9923-a41a8c6d470f quiet                                                                                                            console=uart8250,mmio32,0xff1a0000 console=tty0 coherent_pool=2M cec.debounce_m                                                                                                           s=5000
Retrieving file: /rk3399-rock-pi-4b.dtb
reading /rk3399-rock-pi-4b.dtb
73408 bytes read in 9 ms (7.8 MiB/s)
## Flattened Device Tree blob at 01f00000
   Booting using the fdt blob at 0x1f00000
   Loading Device Tree to 000000007deec000, end 000000007df00ebf ... OK
Adding bank: start=0x00200000, size=0x7fe00000

Starting kernel ...


[    0.744338] panfrost ff9a0000.gpu: [drm:panfrost_devfreq_init] *ERROR* Couldn                                                                                                           't set OPP regulators
[    0.766951] rk_gmac-dwmac fe300000.ethernet: cannot get clock clk_mac_speed

Re: Fedora on NanoPC-T4

Posted: Tue Jun 15, 2021 5:59 pm
by usual user
Could you also provide the log with my image and my provided u-boot-rockchip.bin in place?

Re: Fedora on NanoPC-T4

Posted: Wed Jun 16, 2021 2:22 pm
by tony013
Extracted your image to sdcard with balena and then patched u-boot with dd as recommended here (above).

Here it is:

Code: Select all

Boot1: 2018-06-26, version: 1.14
CPUId = 0x0
ChipType = 0x10, 221
Spi_ChipId = b4016
SpiBootInit:0
mmc0:cmd5,32
SdmmcInit=0 0
BootCapSize=0
UserCapSize=30436MB
FwPartOffset=2000 , 0
StorageInit ok = 236356
SecureMode = 0
SecureInit ret = 0, SecureMode = 0

GPT 0 signature is wrong

LoadTrust Addr:0x1800
LoadTrust Addr:0x1c00
LoadTrust Addr:0x2000
LoadTrust Addr:0x2400
LoadTrust Addr:0x2800
LoadTrust Addr:0x2c00
LoadTrust Addr:0x3000
LoadTrust Addr:0x3400
Addr:0x1800 No find trust.img!
LoadTrustBL error:-3
SecureMode = 0
SecureInit ret = 0, SecureMode = 0

Re: Fedora on NanoPC-T4

Posted: Wed Jun 16, 2021 5:27 pm
by usual user
tony013 wrote:
Here it is:
This is not the expected log output of my provided u-boot. It starts the same way as the LE. Looks like you have firmware in SPI that takes precedence over emmc and SD card. Disable it as described here. I.e. connect PIN23 and PIN25. Now power cycle with my image on SD card in place and no emmc module plugged in. Because emmc firmware would take precedence over SD card.

Re: Fedora on NanoPC-T4

Posted: Sat Jul 03, 2021 7:46 am
by usual user
Sorry, I can no longer claim I have never tested my image with another device. My HoneyComb is now running with the image I composed for the NanoPC-T4. The only precautions for this were a firmware, borrowed from an image provided by the manufacturer, and some small configuration adjustments. And this despite the fact that fedora does not offer any special measures for Layerscape support. The only special measure for HoneyComp support is that fsl-lx2160a-honeycomb.dtb comes with the mainline kernel.

Re: Fedora on NanoPC-T4

Posted: Sat Jul 03, 2021 12:15 pm
by usual user
I have built a current kernel with sdhci-of-esdhc as build-in instead of as module to run the HoneyComb without initramfs as well.
If there is an interest in using this kernel for my image, I have uploaded it here.
Fedora Kernel Team has picked up an in flight fix for proper pcie support already. So nvme support for NanoPC-T4 is working properly and a bug has to be no longer be papered over by disabling a debug config.
To put the kernel in place, extract the provided archive like e.g.:

Code: Select all

[root@trial-01 workbench]# tar -C /usr/lib/modules/ -xzf 5.13.0-58.fc34.aarch64.tgz
And put this stanza as first stanza in /extlinux/extlinux.conf:

Code: Select all

label 5.13.0-58.fc34.aarch64 trial-01
        fdtdir /usr/lib/modules/5.13.0-58.fc34.aarch64/dtb/
        kernel /usr/lib/modules/5.13.0-58.fc34.aarch64/vmlinuz
        append loglevel=4 root=PARTUUID=696d6701-01 cma=768M coherent_pool=2M selinux=0 audit=0 console=uart8250,mmio32,0xff1a0000 console=tty0 fbcon=nodefer rootwait rootfstype=ext4 raid=noautodetect

If you are running with a different PARTUUID, do not forget to adjust the PARTUUID value accordingly.

Re: Fedora on NanoPC-T4

Posted: Sat Aug 14, 2021 7:08 am
by usual user
Kernel 5.14.0-0.rc5 with drm panfrost in-flight patches for 5.15.x shows remarkable graphics improvements.
Meanwhile switched to 5.14.0-1, but this commit must be reverted for rk3399 Ethernet to continue to work.
Now also applied LibreELEC kernel patches and rebuild ffmpeg with v4l2-request-hwaccel support. gst-play-1.0, ffplay and mpv now play bbb_sunflower_1080p_30fps_normal.mp4 with similar achievement.
VP9 support has just landed in media staging, i.e. is in flight for 5.17.0. I moved to 5.16.0-rc2 with media staging patches applied.
"mpv --hwdec=auto --hwdec-codecs=all ${MOVIE}" successfully supports various hardware accelerated codecs (hwdec: drm-copy):
h264.jpg
h264.jpg (137.26 KiB) Viewed 46667 times
vp8.jpg
vp8.jpg (183.3 KiB) Viewed 46667 times
vp9.jpg
vp9.jpg (178.6 KiB) Viewed 46667 times
Gstreamer main branch has just landed VP9 support, i.e. 1.20 should have it out of the box.
Kernel 5.16.0-rc5 still requires this regression fix for RGA support.

The eagle has landed. \o/

Re: Fedora on NanoPC-T4

Posted: Sat Feb 04, 2023 9:42 am
by deafcrump
Hey, good job on this :D . It runs absolutely smooth. Also youtube playback with the web browser Falcon is very smooth. Browsing through the web feels more like it should be - less laggy experience.
teatv
hellodear.in
All times are UTC
Page 1 of 1
Powered by phpBB® Forum Software © phpBB Limited
https://www.phpbb.com/