shepper Posted Monday at 03:11 AM Posted Monday at 03:11 AM The Rock-s0 has the same rk3308b processor and the build uses a BL31binary, with u-boot. The SV06Ace has the same cpu and BL31/u-boot. I reviewed this thread and was trying to follow the example commit provided. It is a little difficult to work through a commit as not all of the paths to the files are present in my depth=1 git clone. Is it possible to download the commit for the Rock-s0 and use it to patch the build directory? If I could run the patch, then I would have some actual files to copy and edit. The maintainer of the Rock-s0, linked on the Armbian Info page for the s0 has not made any recent commits. The last Rock-s0 commit was where it was moved back to an older bootloader scheme. # Rockchip RK3308 quad core 512MB SoC WiFi BOARD_NAME="SV06 Ace" BOARD_VENDOR="sovol" BOARDFAMILY="rockchip64" BOARD_MAINTAINER="shep" BOOTCONFIG="sv06ace-rk3308_defconfig" BOOT_FDT_FILE="rockchip/sv06ace.dtb" KERNEL_TARGET="current" KERNEL_TEST_TARGET="current" DEFAULT_CONSOLE="serial" SERIALCON="ttyS0" MODULES_BLACKLIST="rockchipdrm analogix_dp dw_mipi_dsi dw_hdmi gpu_sched lima hantro_vpu panfrost" HAS_VIDEO_OUTPUT="no" BOOTBRANCH_BOARD="tag:v2024.10" BOOTPATCHDIR="v2024.10" BOOT_SCENARIO="binman" DDR_BLOB="rk33/rk3308_ddr_589MHz_uart0_m0_v2.07.bin" BL31_BLOB="rk33/rk3308_bl31_v2.26.elf" FORCE_UBOOT_UPDATE="yes" OVERLAY_PREFIX="rk3308" function post_family_config__rocks0() { declare -g BOOTDIR="u-boot-${BOARD}" declare -g BOOTSCRIPT="boot-rockchip64-ttyS0.cmd:boot.cmd" family_tweaks_bsp() { #overrides rockchip64_common.inc #Install udev script that derives fixed, unique MAC addresses for net interfaces #that are assigned random ones bsp=$SRC/packages/bsp/rockpis rules=etc/udev/rules.d Specifically, where are following files, referenced in /build/boards/*.csc located? BOOTCONFIG=*.defconfig" BOOT_FDT_FILE="*.dtb" The declared boot scripts Thanks 0 Quote
shepper Posted 1 hour ago Author Posted 1 hour ago (edited) I started down this path and realized that the patches are applied to downloaded linux kernel source. Normally, the kernel source is "cleaned" even if the build fails. I then found the sakura pi github page and the page has more recent commit than the Rock-s0, incorporates the kernel.dtsi while adhering the the u-boot requirements for rockpi's. U-boot for Rockpi. I'd like to base my build on the more up-to-date code. The easist way to do this is set CLEAN_LEVEL="" but I'm running into issues with the patches in GitHub: Sakura-Pi failing to apply. Essentially, I would iike to have the patches apply, not necessarily build and have the files generated by the patches remain. I have a large dtb file, extracted from Sovol's OEM firmware, that I would like to copy/paste into the generated *.dtb file, rename the *csc file and the defconfig file, and then generate a patch against clean source. Conceptually, this should work and I'm suprised it is this difficult to generate a new board for an existing family. Alternatively, a script could generate a file from a highlited portion of a patch and generate a file. Or is is possbile to run ./compile.sh a step at a time? It would be helpful in this setting, very instructive about the process and would narrow down build failures. Am I on the right path? Any step-by-step examples and or links to helpful scripts? Edited 1 hour ago by shepper added step by step builds 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.