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

 

 

 

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 March 5Mar 5 by shepper
added step by step builds