Bugzilla – Bug 1221169
Request to allow Rockchip non-free ATF firmware into Tumbleweed
Last modified: 2024-03-12 16:45:33 UTC
Created attachment 873342 [details] Copy of the Rockchip license for the ATF files I am currently in the process of porting openSUSE Tumbleweed to the Firefly ITX-3588J ARM64 development board [1] which uses a Rockchip RK3588 [2], an ARM-A v8 architecture ship, as its CPU. Due to the nature of the ARM-A v8 CPUs requiring an ARM Trusted FIrmware (ATF) to boot, I became aware that the following firmware components are not available as Open Source packages from Rockchip / Firefly. I have also checked and confirmed that the required files are neither in the package arm-trusted-firmware [5] nor in any kernel-firmware-* package. I cannot proceed without using these files, since they are critical for the booting process. - ARM Trusted-Firmware for ARM-A profile (TF-A), a.k.a. EL3 Runtime Software a.k.a BL 31: rk3588_bl31_v1.42.elf - Trusted Linux/Secure Linux/OPTEE a.k.a. Secure-EL1 Payload (optional) a.k.a. BL 32: rk3588_bl32_v1.14.bin - Rockchip TPL (tertiary program loader) for initialising the DRAM: rk3588_ddr_lp4_2112MHz_lp5_2736MHz_v1.13.bin These components are hosted in a Gitlabs repo [3] of the board's manufacturer Firefly. The license, which obviously is not an OSI approved OS license, is [4]. I'm also attaching it to this ticket in case the URL might move in the future. The license part relevant for distribution of the files is: "Rockchip hereby grants to you a non-exclusive license (a) to use, copy, distribute the Software; (b) to modify any source code as part of Software(if any) and sublicense, distribute such modifications. Except as expressively authorized by Rockchip in writing, you may NOT: (a) decompile, reverse-engineer, dissemble, or attempt to derive any source code from the Software; (b) remove or obscure any copyright, patent, or trademark statement or notices contained in the Software." To my understanding, while not being an OSS license, it would satisfy the requirements to allow distribution in openSUSE and openSUSE Build Service (OBS) according to the description at [6]: "Exceptions to this policy will be done for the openSUSE distribution and those packages are in the Non-Free projects of openSUSE, e.g. openSUSE:Factory:NonFree. If you like to see a package included in NonFree, please open a bugreport against the distribution and supply information about the license. We especially need the right to redistribute software if we include it in the build service." Consequently, I would like to apply for such an exception. -- [1] https://wiki.t-firefly.com/en/Core-3588J/index.html [2] https://www.rock-chips.com/uploads/pdf/2022.8.26/192/RK3588%20Brief%20Datasheet.pdf [3] https://gitlab.com/firefly-linux/rkbin/-/tree/firefly/bin/rk35?ref_type=heads [4] https://gitlab.com/firefly-linux/rkbin/-/blob/rk3588/linux_release_v1.3.0d/LICENSE?ref_type=tags [5] https://build.opensuse.org/package/show/hardware:boot/arm-trusted-firmware [6] https://en.opensuse.org/openSUSE:Build_Service_application_blacklist
Hi, Could you create "pull request" against[1], so we can easily evaluate required changes? Thanks! [1] https://build.opensuse.org/package/show/hardware:boot/arm-trusted-firmware
Thank you for the quick response. I have created the PR: https://build.opensuse.org/request/show/1156958
Well, done! Could you enable build of the all packages, just to be sure that nothing is broken, please?
Hi Ivan, the maintainer of arm-trusted-firmware notified me that he wants me to create a separate package. The new submit request is: https://build.opensuse.org/request/show/1157014
Okay. Looks fine. Once installed how BootRom will locate these artefacts, should they be put in EFI partition or something? Looking at Rockchip Wiki these chips required wired storage map[1]. I am wondaring how do you see installation process on thse boards. Somehow I doubt that they could boot current TW iso. Perhaps custom Kiwi image (raw)? [1] http://opensource.rock-chips.com/wiki_Partitions
At the moment, I am using the board manufacturer's BSP's loader (U-Boot 2017.09), which is not configured with EFI boot support at all. However, I see a chance to disect it and develop an up-todate U-Boot using Tumbleweed's U-Boot SRPM with proper EFI boot support. Until then, I have a manual workaround that works by packaging the openSUSE kernel and root FS as a bootable SD card. After the system has started up for the first time, the /boot and / partitions (/dev/mmcblk0p3 and /dev/mmcblk0p6) can be changed using standard tooling. The generel boot flow on Firefly ITX-3588J right now is as following: ARM core reset vector --> Rockchip boot0, boot1 (most likely on-chip ROM, since the BSP documentation states the board is "unbrickable") --> U-Boot (on /dev/mmcblk0p1 and /dev/mmcblk0p2 (?), can be overwritten with a self-compiled version) --> U-Boot searches for a GPT partition (on /dev/mmcblk0) with the label "boot". In standard Rockchip partitioning, this will always be /dev/mmcblk0p3, but I think it can be changed. --> On the GPT "boot" label partition (expected with an ext2/3/4 FS), search for /extlinux/extlinux.conf --> Using extlinux.conf, we know the file names for kernel Image (maybe zImage is possible, too?), initrd and dtb --> U-Boot loads kernel, initrd and dtb into memory --> U-Boot jumps to the kernel entry point and hands off control So, my long-term plan is: 1. Create an updated U-Boot with proper EFI boot support (TODO) 2. Create an RAW image the openSUSE end-user can flash on an SD-Card in Rockchip's sdcard paritioning format (might need proprietary Rockchip tools subject to the same of similar license as the ARM Trusted Firmware blobs) 3. The end-user boots up with the SD card 4. A script (I believe the "oem" KIWI images already have code templates for that) flashes the new U-Boot, deletes /dev/mmcblk0p7 ("userdata", not required by openSUSE) and /dev/mmcblk0p6 ("root") recreates /dev/mmc0blkp6 ("root") with a FS of the end-users choice (btrfs default?) 5. Extract the openSUSE rootfs to "root" 6. adjust /boot/extlinux/extlinux.conf (on /dev/mmcblk0p3) to boot the openSUSE-fied kernel 7. Final reboot into the finished system I plan to combine steps 4,5 and 6 in a script so the end-user does not have to deal with the details. The proprietary Rockchip tools mentioned in step 2 are only needed for the build of the setup SD card. They are not required on the rootfs and on the final system.
Looks like you have a plan. Complicated, but a plan. :-) Looking at various boot binaries placement requirements, I doubt that the whole thing will be able to be integraded in a generic ISO or RAW image. So I would suggest you go to directly to custom Kiwi image, which will have to be just DD to SD card and will boot without further modifications. Something like Firefly-RK3288 JeOS image [1]. I don't think you need to have script which is run on first boot. You could setup things during Kiwi image creation. For example see [2], especially editbootinstall*.sh and config.sh scripts. [1] https://en.opensuse.org/HCL:Firefly-RK3288 [2] https://build.opensuse.org/package/show/home:iivanov:alinx-zynqmp-micro/SLE-Micro
I have just seen that my PR (is that the correct term for requests in OSB?) got accepted. Many thanks for it! So, given that it is now a package in Tumbleweed, I think this ticket is resolved, and I can continue on my project. I will have a look at the resources (RK3288 JeOS) and try to find out if I can expand on it.