Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

This time the kernel 7.0 boots and I have an initramfs prompt (stopped b/c not finding it's root file sys). Tested on SD card and NVME. I have to rename the *.dtb or change extlinux.conf in order to match DTB names:

sed -i 's,x1_orangepi-rv2,k1-orangepi-rv2,' /mnt/boot/extlinux/extlinux.conf

The legacy and current Armbian images matches a DTB name to the Spacemit-K1 chip that is visible in u-boot via TLV_CODE_PRODUCT_NAME in the product_name env var. This is how the Bianbu u-boot is able to boot on different boards while Armbian uses the extlinux.conf file. Please either change the BOOT_FDT_FILE (for edge) in board config or rename *.dts in kernel tree.

I attach a dmesg for futher analysis (SD-Card not inserted, u-boot started via MTD and NVME).
dmesg-opirv2-7.0.txt

✅ This PR has been reviewed and approved — all set for merge!

This time the kernel 7.0 boots and I have an initramfs prompt (stopped b/c not finding it's root file sys). Tested on SD card and NVME. I have to rename the *.dtb or change extlinux.conf in order to match DTB names:

sed -i 's,x1_orangepi-rv2,k1-orangepi-rv2,' /mnt/boot/extlinux/extlinux.conf

The legacy and current Armbian images matches a DTB name to the Spacemit-K1 chip that is visible in u-boot via TLV_CODE_PRODUCT_NAME in the product_name env var. This is how the Bianbu u-boot is able to boot on different boards while Armbian uses the extlinux.conf file. Please either change the BOOT_FDT_FILE (for edge) in board config or rename *.dts in kernel tree.

I attach a dmesg for futher analysis (SD-Card not inserted, u-boot started via MTD and NVME). dmesg-opirv2-7.0.txt

Do a PR and create a symlink in both legacy and current and update your $board.conf to point to the mainline tree k1-orangepi-rv2.dtb instead of the vendor one. Or rename them completely? Should work either way I gather.

marvin: dt git:( SPACEMIT-005 ✓ ) $ ln -s x1_orangepi-r2s.dts k1-orangepi-rv2.dts
marvin: dt git:( SPACEMIT-005 ?:1 ✗ ) $ ls -l
total 116
-rw-rw-r-- 1 patrick patrick  1003 Mar 12 06:32 Makefile
-rw-rw-r-- 1 patrick patrick 26585 Mar 12 06:32 k1-bananapi-f3.dts
-rw-rw-r-- 1 patrick patrick 26766 Mar 12 06:32 k1-musepi-pro.dts
lrwxrwxrwx 1 patrick patrick    19 Mar 13 15:40 k1-orangepi-rv2.dts -> x1_orangepi-r2s.dts
-rw-rw-r-- 1 patrick patrick  1174 Mar 12 06:32 lcd_tc358762xbg_dpi_800x480.dtsi
-rw-rw-r-- 1 patrick patrick 20815 Mar 12 06:32 x1_orangepi-r2s.dts
-rw-rw-r-- 1 patrick patrick 28283 Mar 12 06:32 x1_orangepi-rv2.dts

If I would have stuck with the bianbu source names it would be k1-x_deb1.dts and k1-x_MUSE-Pi.dts.

The k1-orangepirv2 name is from upstream (Linux7)? The x1-orangepi name is stored in the chip and thus it is from the chip vendor, e.g. where you probably find MUSE in your board (stop u-boot, then printenv product_name should show "MUSE"). The kernel folks are rather stubborn, so if thats from there namespace I would adapt legacy and current...

The k1-orangepirv2 name is from upstream (Linux7)? The x1-orangepi name is stored in the chip and thus it is from the chip vendor, e.g. where you probably find MUSE in your board (stop u-boot, then printenv product_name should show "MUSE"). The kernel folks are rather stubborn, so if thats from there namespace I would adapt legacy and current...

This makes sense as we are currently using vendor u-boot, but once we move to mainline u-boot this will no longer be the case. I would think staying ahead of the curb would be a better choice?

Are you afraid that by renaming the DTS files in the kernel, this is some how going to break something?

Are you afraid that by renaming the DTS files in the kernel, this is some how going to break something?

No, it's only a file name. Using the name stored in the chip has the (future) option to have a single "firmware for all". using the name from upstream promises less fiddling. Thus it's the latter...

Are you afraid that by renaming the DTS files in the kernel, this is some how going to break something?

No, it's only a file name. Using the name stored in the chip has the (future) option to have a single "firmware for all". using the name from upstream promises less fiddling. Thus it's the latter...

I suspect we could do this now by editing u-boot. Going that route would open up the door for UEFI one image fits them all type deal. Would lose easy overlay support though? Other option would be start using a boot.scr that takes this into account.

I'm fine with either, its just not on my list of things to mess around with at the moment. You are more than welcome to have at it though :)

Are you afraid that by renaming the DTS files in the kernel, this is some how going to break something?

No, it's only a file name. Using the name stored in the chip has the (future) option to have a single "firmware for all". using the name from upstream promises less fiddling. Thus it's the latter...

This was tested on the BPI-F3 using the last musepipro test img I made.

Loading K1-X Environment ...
[   2.718] 
[   2.719] Running NVMe Scan ...
[   2.730] pcie_dw_k1x pcie@ca400000: has no power on gpio.
[   2.732] pcie_dw_k1x pcie@ca400000: has no power-on-status flag, use default.
[   2.740] Now init Rterm...
[   2.742] pcie prot id = 1, porta_init_done = 0
[   2.746] Now waiting portA resister tuning done...
[   2.751] porta redonly_reg2: 00005d47
[   2.754] pcie_rcal = 0x00005d47
[   2.758] pcie port id = 1, lane num = 2
[   2.761] Now int init_puphy...
[   2.764] waiting pll lock...
[   2.767] Now finish init_puphy....
[   2.770] pcie_dw_k1x pcie@ca400000: Unable to get phy0
[   2.775] pcie_dw_k1x pcie@ca400000: Unable to get phy1
[   2.911] PCIE-0: Link up (Gen2-x2, Bus0)
[   3.112] 1792 bytes read in 14 ms (125 KiB/s)
[   3.114] ## Executing script at 02000000
[   3.417] 22821024 bytes read in 249 ms (87.4 MiB/s)
[   3.641] 18872215 bytes read in 212 ms (84.9 MiB/s)
[   3.643] Loading boot/dtb/spacemit/k1-bananapi-f3.dtb ...
[   3.683] 33722 bytes read in 25 ms (1.3 MiB/s)
[   3.685] Booting BananaPi BPI-F3 from mmc 0:1 ...
[   3.689]    Uncompressing Kernel Image
[   4.169] Moving Image from 0x10000000 to 0x200000, end=362e000
[   4.197] ## Loading init Ramdisk from Legacy Image at 21000000 ...
[   4.200]    Image Name:   uInitrd
[   4.203]    Image Type:   RISC-V Linux RAMDisk Image (gzip compressed)
[   4.210]    Data Size:    22820960 Bytes = 21.8 MiB
[   4.215]    Load Address: 00000000
[   4.218]    Entry Point:  00000000
   Verifying Checksum ... OK
[   4.325] ## Flattened Device Tree blob at 31000000
[   4.327]    Booting using the fdt blob at 0x31000000
[   4.332]    Loading Ramdisk to 7c7a3000, end 7dd66860 ... OK
[   4.347]    Loading Device Tree to 000000007c797000, end 000000007c7a23b9 ... OK

Starting kernel ...

root@musepipro:~# dmesg | grep "command"
[    0.000000] Kernel command line: earlycon=sbi console=tty1 console=ttyS0,115200 rw root=PARTUUID=0e676e08-01 rootfstype=ext4 loglevel=1 fsck.repair=yes net.ifnames=0 rootwait init=/sbin/init
root@musepipro:~# ls /boot
boot.bmp                        Image
boot.cmd                        initrd.img-7.0.0-rc3-edge-spacemit
boot.scr                        System.map-7.0.0-rc3-edge-spacemit
config-7.0.0-rc3-edge-spacemit  uInitrd
dtb                             uInitrd-7.0.0-rc3-edge-spacemit
dtb-7.0.0-rc3-edge-spacemit     vmlinuz-7.0.0-rc3-edge-spacemit

If we setup a boot script, we could "I suppose" get rid of individual board.conf(s) and just use one spacemit.conf. Allowing us to have one img to rule them all.

If you are interested in working on it?
boot.cmd.txt

If you are interested in working on it?
boot.cmd.txt

Not sure if I want to do that now. Lets postpone and focus on unfinished tasks instead: I'll send a PR x1opirv.dtb->k1opirv2 first, then overthink / integrate that GPU package grab from Bianbu (see forum post on RV2), then massage Linux7, then maybe play a bit with the NPU/Ollama thingy, then unified images. LG // Sven-Ola