10:51 <CounterPillow> qschulz: lol @ your "the cover letter" response to krzk. I feel like he never reads them, as this has happened to me before as well.

11:04 <qschulz> CounterPillow: /me shrugs

11:05 <qschulz> I feel like I'm slowly entering the dead end they are putting me towards to

11:07 <qschulz> I don't understand what they are objecting to

11:19 <CounterPillow> My guess is that they don't like that the property is formulated as register contents, as opposed to a declarative way to describe what the hardware expects, they just don't know it yet ;)

11:22 <qschulz> CounterPillow: thanks for chiming in the thread, will wait tomorrow to answer so that I'm a bit less frustrated :)

11:22 <CounterPillow> okay just saw krzk's response from 12:57, looks like I am correct in my assessment

11:23 <qschulz> somewhat, they don't say if they are totally against the property or the name/description of it

11:23 <qschulz> (or I didn't understand it that way ;) )

11:23 <CounterPillow> "Don't focus on registers" :)

11:24 <qschulz> but at the same time asking me if maybe our products aren't routed properly :)

11:24 <CounterPillow> Yes ignore any of his complaints that the hardware must be wrong, that's just him being him

11:26 <qschulz> we shouldn't need to know that

11:27 <qschulz> because if I let my frustrated self answer there I would tell them "are you asking me to adapt the HW so it fits the DT binding" :D ?

13:24 <robmur01> qschulz: FWIW I'd suggest focusing the description more on the fact that the different behaviours have different effects on the supply rails and other board-level signals

13:25 <robmur01> TBH the quote from the datasheet doesn't really provide any obvious useful information for the context, so it kinda is just "there's this thing, it has these settings, let's make it a property", without any obvious "why"

13:31 <robmur01> Also, the wording of said cover letter *could* be interpreted as using a kernel DT to work around a bootloader bug ;)

13:33 <qschulz> robmur01: that's sadly the extent of the information I have :/

13:33 <robmur01> (as opposed to "this should be in DT so everyone sets it correctly and consistently" which seems like a reasonable argument to make)

13:34 <qschulz> but fair enough for the other points, will try to pay better attention into writing meaningful commit logs/cover letters

13:34 <qschulz> to be fair, I'm planning on implementing the same thing from U-Boot too

13:35 <qschulz> waiting on the binding to be accepted first, no need to do backward compatibility with unmerged DT bindings (or if it ends up not being merged, having dead code :) )

13:43 <robmur01> yeah, in that case I'd lean well into the other direction - "RST_FUN is poorly documented, but different boards depend on these observable effects of different settings, so we want it in DT so U-Boot, Linux and everyone else can do the right thing"

13:45 <robmur01> if you squint it's perhaps a little like how the system-power-controller property selects between register-based shutdown vs. TF-A wiggling a GPIO

16:17 <Dex2x> Ah man, I finally got a male fan connector, for my heatsink of my opi 5 ultra, but it doesn't have the needed female connector for the fan on the heatsink :/

17:15 <Dex2x> I am not getting my board to boot from the "linux-image-6.15-rc7-arm64" kernel, it keeps booting from the linux-image-current-rockchip-rk3588

17:30 <diederik> do you have u-boot-menu installed?

17:31 <diederik> when that runs, that updates ``/boot/extlinux/extlinux.conf`` and there you can set the default boot option ... and it should make an entry for every kernel installed

17:42 <Dex2x> okay didn't know about that package, added it

17:43 <Dex2x> is the u-boot just a bootload like grud?

17:48 <Dex2x> that borked it, need UART

18:02 <CounterPillow> you're likely using some vendor u-boot that may not play well with that

18:02 <CounterPillow> u-boot is a bit more than what grub would do, since on x86 you have the whole platform initialisation before the bootloader is run

18:07 <Dex2x> ah yeah Exception from a Data abort, from current exception level

18:08 <Dex2x> oh I can't boot to the old vendor kernel either

18:09 <Dex2x> I take it I need to reflash this now

18:10 <CounterPillow> or you can build and flash a mainline u-boot that will actually work

18:12 <Dex2x> I can just flash a u-boot while I can't boot? IS this to the spiflash?

18:13 <CounterPillow> where it is depends on your setup, but yes it can be flashed over the USB protocol in any case if you know how to get your board into maskrom mode. Don't really have time to walk you through that right now though

18:13 <Dex2x> Oh I know how to get it in maskrom mode

18:13 <Dex2x> I just didn't know the u-boot goes to that

19:17 <Dex2x> okay just need to find a working uboot :/

19:26 <CounterPillow> git clone https://source.denx.de/u-boot/u-boot.git && git clone https://github.com/rockchip-linux/rkbin/ && cd u-boot && export BL31=../rkbin/bin/rk35/rk3588_bl31_v1.48.elf && export ROCKCHIP_TPL=../rkbin/bin/rk35/rk3588_ddr_lp4_2112MHz_lp5_2400MHz_v1.18.bin && make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- orangepi-5-max-rk3588_defconfig && make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j"$(nproc)"

19:26 <CounterPillow> results in a u-boot-rockchip.bin you can flash to sector 64 on eMMC with rkdeveloptool, sector 64 on SD with dd. That is assuming orangepi made no u-boot relevant changes from max to ultra

19:29 <Dex2x> Let me try, I managed to boot off a SDCARd, so I can just compile this from the opi5

19:40 <Dex2x> can I write it to the emmc from the device, using dd ?

19:47 <CounterPillow> yes

19:48 <Dex2x> the last make step is failing though

19:49 <CounterPillow> dd if=u-boot-rockchip.bin of=/dev/mmcblkwhatever seek=32768B bs=4K oflag=dsync status=progress # to write u-boot to the emmc

19:49 <Dex2x> <3 you rock

19:50 <CounterPillow> to find out which of your mmcblks is the emmc, `lsblk` is handy

19:51 <CounterPillow> if you're compiling on 64-bit arm natively rather than cross-compiling, you probably want to leave out the CROSS_COMPILE=... makeflag

19:53 <Dex2x> even so,m ln: failed to create symbolic link 'arch/arm64/include/asm/arch': No such file or directory . I might be missing the needed tools

19:53 <CounterPillow> yes, look higher up in the build log, there's probably something you're missing

19:55 <Dex2x> well I see just config written with ` make ARCH=arm64 orangepi-5-max-rk3588_defconfig` where the cross compile had additional outpout

19:56 <CounterPillow> `make mrproper` to remove the config

19:56 <CounterPillow> then try generating it again without the CROSS_COMPILE

19:56 <Dex2x> aaah ! okay that looks better m but still symlink :/

19:57 <Dex2x> https://paste.debian.net/1376954/

20:01 <CounterPillow> never seen this one, weird

20:31 <Dex2x> I am to amaze :p , well I am trying the armbian opi 5 max build

20:54 <Dex2x> hmmm okay the rc kernel is not booting for me

20:55 <Dex2x> at least not the one with the armbian for the op5 max , but not sure if that makes that much of a difference