04:19 <user21> I got it running again based on the armbian build and put the patch files into the `userpatches` folder

04:20 <user21> compiled mesa with flags, running the test now and still getting the `Couldn't open kernel device`

04:20 <user21> is the .ko file I need to load manually ? and what is the file it tries to look for ?

04:21 <user21> did you succeed in getting this tested on 5b ?

04:36 <user21> I think mu patches are not applied, see last comment in this post https://forum.armbian.com/topic/28677-how-to-apply-my-own-kernel-patch/

05:52 <a3f> qschulz, If /soc/aliases were to be like /aliases, it wouldn't help, yes. But the idea is that /soc/aliases would have the same numbering as used in the SoC reference manual instead. Board-level aliases would go into /aliases then

05:56 <a3f> barebox uses /chosen/barebox,bootsource-mmcX and so on properties for that. I would try to upstream this as /chosen/aliases/ when your /chosen/bootsource goes in

07:47 <CounterPillow> <user21> did you succeed in getting this tested on 5b ? <-- yes

07:47 <CounterPillow> user21: you should be seeing a device node in /dev/accel/

07:48 <CounterPillow> You do not need to manually load the driver

07:49 <CounterPillow> what you do need to do however is build with it, so make sure CONFIG_DRM_ACCEL=y and CONFIG_DRM_ACCEL_ROCKET=y are set

07:49 <CounterPillow> (or =m for the latter)

07:53 <qschulz> a3f: I assume s;/chosen/aliases;/soc/aliases; is what you meant?

07:55 <qschulz> but thanks, makes sense. We should be using that for the gpio controller for example, which slightly depends on boot order if no alias is provided

07:56 <qschulz> and one can imagine the GPIO numbering scheme is different on pin headers used by a board compared to the one in the SoC datasheet

12:15 <user21> @CounterPillow: what was the kernel version the patches were applied to ?

12:15 <CounterPillow> our rockchip-devel branch, but any recent kernel version will work.

12:16 <user21> ok

12:18 <Ermine> Does mainline kernel have any limitations on number of partitions on MMC storage on RK3588s ?

12:19 <user21> I got a conflict on last two commits on 6.14.5 nothing major, fixable

12:19 <user21> https://snipboard.io/d1osE5.jpg

12:38 <CounterPillow> Ermine: I doubt the mmc controller is even aware of partitions aside from the two hardware boot partitions. If you're having issues, it's probably because you formatted your flash storage as MBR, and not GPT.

12:38 <CounterPillow> Unless you're trying to keep compatibility with MS-DOS, MBR should probably not be used.

12:39 <Ermine> Well, we see only 6 partitions here, though u-boot lists all 7

16:05 <user21> @CounterPillow I've applied the patches, created a new image, booted but I don't see the /dev/accel

16:06 <CounterPillow> user21: yes but did you enable both the driver and the DRM_ACCEL framework in your kernel config

16:12 <user21> normally this is part of the patches

16:12 <user21> https://snipboard.io/WJ1oy5.jpg

16:12 <user21> but I see it is as module not built-in

16:13 <user21> let me find what to load manually

16:13 <CounterPillow> that's fine, but that patch is just the defconfig

16:13 <CounterPillow> you don't need to load manually

16:13 <user21> ah

16:13 <CounterPillow> the config you build the kernel with needs to have it

16:13 <user21> I see

16:13 <CounterPillow> defconfig is just applied if you `make defconfig` and may differ from what you actually do

16:15 <user21> I see, looking where to trigger this for the armbian based builds

18:14 <a3f> qschulz, yes, /chosen/aliases -> /soc/aliases.

19:14 <user21> ok so now that I have activated the right kernel config with the "CONFIG_DRM_ACCEL=y and CONFIG_DRM_ACCEL_ROCKET=y" turns out the kernel patches are not working for 6.14.5 because "drm_sched_init_args" is defined in "/drm/gpu_scheduler.h" from 6.15 and up

19:15 <user21> this breaks the compilation

19:35 <CounterPillow> user21: sounds like you're missing https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/commit/73aba31a00b34c254be575b524da568e115d985d

19:35 <CounterPillow> Oh, or rather

19:35 <CounterPillow> you should drop it

19:35 <CounterPillow> 6.14 looks to still be using the old API then

19:36 <user21> oh I see, good catch thank you

19:36 <user21> trying

21:26 <user21> dropped that patch, recompiled everything, booted the image but I still don't see the /dev/accel

21:26 <user21> the kernel .config was having the CONFIG_DRM_ACCEL=y and CONFIG_DRM_ACCEL_ROCKET=y and CONFIG_DRM=y

21:49 <CounterPillow> anything in /sys/kernel/debug/devices_deferred?

22:10 <user21> the file is there but it is empty

22:12 <CounterPillow> okay, so no deferred devices, that's good

22:12 <CounterPillow> sudo dmesg | grep -i rocket

22:12 <user21> empty

22:14 <CounterPillow> You do not need to manually load any kernel module

22:14 <CounterPillow> so

22:14 <CounterPillow> if it's not loading, it means you're not using the right DT

22:16 <user21> crap

22:16 <user21> need to review

22:16 <CounterPillow> you can try installing device-tree-compiler and then running `dtc -I fs /sys/firmware/devicetree/base` to see the currently loaded device tree, look for any nodes with rknn in the compatible. If they're missing, that means you're not using the right DT

22:21 <user21> thank you! trying now

22:33 <user21> there are some lines but not alot, worried this is just armbuild stuff

22:33 <user21> and the actual chages to dts seems are applied but get overlayed by something else from armbian build

22:45 <user21> compatible = "rockchip,rk3588-rknn-core\0rockchip,rknn-core";

22:46 <CounterPillow> is status = "okay" in that node?

22:46 <user21> status = "disabled";

22:47 <user21> compatible = "rockchip,rk3588-rknn-core-top\0rockchip,rknn-core-top";

22:47 <user21> status = "disabled";

22:47 <user21> compatible = "rockchip,rk3588-rknn-core\0rockchip,rknn-core";

22:47 <user21> status = "disabled";

22:47 <user21> rknn_core_2 = "/npu-core@fdad0000";

22:47 <user21> rknn_mmu_1 = "/iommu@fdac9000";

22:47 <user21> rknn_core_top = "/npu-core@fdab0000";

22:47 <user21> rknn_core_1 = "/npu-core@fdac0000";

22:47 <CounterPillow> Okay, so the changes of the base DT are in there but the device specific ones that enable those aren't.

22:47 <user21> rknn_mmu_2 = "/iommu@fdad9000";

22:48 <user21> ok so suspicion is that my patches are getting overriden by some build step

22:48 <CounterPillow> The problem likely is that you're not using the rock-5b device tree. The changes should translate to the 5b plus one quite similarly as that 5b enablement commit already does though

22:50 <CounterPillow> (though if it is a 5bp device tree then whatever random patch for it armbian ships is likely completely detached from mainline since sre only recently submitted one to mainline that he wrote himself)

22:51 <user21> https://snipboard.io/npBKJo.jpg

22:51 <user21> and the build command is like this "./compile.sh BOARD=orangepi5-plus BRANCH=edge BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bookworm KERNELBRANCH='branch:v6.14.5'"

22:52 <user21> all the patches go into "userpatches/kernel/archive/rockchip64-6.14"

22:52 <CounterPillow> that doesn't tell me much since I don't use armbian and have no interest in ever touching it ;)

22:54 <user21> ah, ok, no problem, what do you use ? I don't care to be honest, armbian was a way to abstract out a build framework and generate an .img file that get flushed to a SSD

22:55 <user21> if there is a better system I'm in

22:55 <user21> I need kernel 16.4.5+ with patches and the right device tree, then boot it

22:55 <CounterPillow> at work we generate our images using debos

22:55 <CounterPillow> see https://gitlab.collabora.com/hardware-enablement/rockchip-3588/debian-image-recipes for our pipeline

23:02 <CounterPillow> debos just handles the image generation, to make a kernel package with the right patches applied you can just fork debian's kernel package (or make your own) and add the patches there. Or you can forego all of that and just `make bindeb-pkg` in the kernel tree and throw the resulting debs (confusingly in ..) into it, if it has to be a quick and dirty job

23:15 <user21> is there a guide that I can try this quickly

23:15 <user21> something like

23:15 <user21> git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git ~/linux-stable

23:15 <user21> cd ~/linux-stable

23:15 <user21> git switch v6.14.5

23:15 <user21> git am *.patch

23:15 <user21> cd ~/debos

23:15 <user21> ./debos build --linux-src=~/linux-stable

23:16 <user21> then get an image I can dd to ssd or sdcard

23:16 <jmabsd> user21: no idea sorry, best of luck.

23:18 <CounterPillow> no, debos is a bit more up-front setup to make a description of the steps you want to build your image

23:36 <jmabsd> By the way, regarding the Radxa Rock5B - RK3588  "SPL" vs "SPI" terminology, as discussed in this forum thread https://forum.radxa.com/t/flash-spi-and-spl-on-rock5b-questions-caveat-spl-is-never-flashed/26800/

23:36 <jmabsd> I still feel Radxa's installation docs page, and this forum thread, are a bit unclear.

23:37 <jmabsd> Actually did Yuntian write a post to get some other guy Peter Wang and some "Nasca" to have a look?

23:43 <jmabsd> I think the answer is: "SPI is an u-boot image, and it also contains SPL which is RockChip's early boot code.

23:45 <jmabsd> The SPI file is flashed to the SPI flash chip on the Rock5B PCB, which is used as boot medium by the Rock5B.

23:45 <jmabsd> Meanwhile, the SPL file is only used in advanced debugging, to make the Rock5B actually boot when in MaskROM mode and connected to a host computer via USB. Here, the host computer will send the SPL file via USB to the Rock5B, to cause it to enter a normal boot procedure."

23:49 <jmabsd> Well maybe it's clear enough now.

23:56 <user21> nice

23:56 <user21> quick update on my effort: indeed I got the wrong device tree, retrying a new compile and tracing it down