lanefu changed the topic of #armbian-rockchip to: Armbian - Linux for ARM development boards | Rockchip SoC | www.armbian.com | This channel is relayed to the equivalent Discord channel | this channel is logged
<Armbian-Discord> <r​pardini> rk3399-kobol-helios64.dts was added to Torvald's in 5.11-rc1, so yeah, a long time ago.
<Armbian-Discord> <r​pardini> I'm not picking on the helios64 here -- I'm pointing to a grotesque behaviour by the Armbian patching system: https://github.com/armbian/build/blob/master/lib/functions/compilation/patch/patching.sh#L88 "detect and remove files that patch will create". why do we do this?
<Armbian-Discord> <I​gorPec> good question. i can't reason it out of my head. would need to go back into history
<Armbian-Discord> <I​gorPec> at least we should rework this to warn if we are overwriting a file
<Armbian-Discord> <r​pardini> The way I see it: we do that so we can build "twice"
<Armbian-Discord> <I​gorPec> ahaa
<Armbian-Discord> <r​pardini> if we build, the file is put there, then we build again, it fails, since file already exists
<Armbian-Discord> <I​gorPec> yes, this is needed in some case
<Armbian-Discord> <I​gorPec> so we only need a warning system
<Armbian-Discord> <I​gorPec> to detect if file exists prior to patching
<Armbian-Discord> <r​pardini> in my delusional Python patching rewrite in a-n I'm removing this.
<Armbian-Discord> <r​pardini> I do a "remove all untracked, but not ignored, files from git" before starting patching....
<Armbian-Discord> <r​pardini> and if a patch tries to create something that already exists it will just fail...
<Armbian-Discord> <r​pardini> that's how I found that pesky helios64 thing.
<Armbian-Discord> <I​gorPec> aha,that will probably do
<Armbian-Discord> <r​pardini> I also found a few more patches that actually apply, but then don't make any sense.
<Armbian-Discord> <r​pardini> Case in question: board-pbp-add-dp-alt-mode.patch, also in rockchip64
<Armbian-Discord> <I​gorPec> btw. i am thinking to enable weekly zoom meetings to have 1h per week for live discussuin
<Armbian-Discord> <r​pardini> applying that patch results in extcon = <&fusb0>; being added to an emmc node!
<Armbian-Discord> <I​gorPec> oh. could be wrong 🙂
<Armbian-Discord> <I​gorPec> rockchip is generally a big mess
<Armbian-Discord> <I​gorPec> well, patches in general ...
<Armbian-Discord> <r​pardini> there is also a 11mb+ patch to add rl8723cs wifi driver that is everywhere
<Armbian-Discord> <r​pardini> it's just a mess, and the combination of "remove files patch would create" plus patch's default fuzz, simply hides the problems
<Armbian-Discord> <I​gorPec> yes, it hides it ... i am aware
<Armbian-Discord> <I​gorPec> 😦
<Armbian-Discord> <I​gorPec> 8723cs is needed i guess
<Armbian-Discord> <r​pardini> patching.py is to the rescue, but I will bug you all about crazy patches, please bear with me 😉
<Armbian-Discord> <I​gorPec> perhaps not anymore?
<Armbian-Discord> <r​pardini> I think 8723cs is needed, but shouldn't be a patch in each of the families, instead in the extrawifi I think.
<Armbian-Discord> <I​gorPec> brb lunch time
<Armbian-Discord> <I​gorPec> is this something that would help us?
<Armbian-Discord> <T​onymac32> The helios64 in theory runs a screen via the type C. The PBP patch was a Manjaro hack fest that seemed to work at the time, don't know if it's still needed
<Armbian-Discord> <T​onymac32> Ah yes, "all node endings look the same" issue
<Armbian-Discord> <T​onymac32> };
<Armbian-Discord> <T​onymac32> };
<Armbian-Discord> <M​anoftheSea> that takes a type-c to hdmi, right?
<Armbian-Discord> <T​onymac32> Display port
<Armbian-Discord> <M​anoftheSea> oh, alt-mode
<Armbian-Discord> <T​onymac32> Ja
<Armbian-Discord> <M​anoftheSea> Yeah, I don't have the cable or a monitor that can do it, to tell you
<Armbian-Discord> <M​anoftheSea> unless linux can do an alt-mode in, somehow?
<Armbian-Discord> <T​onymac32> Yeah, I do, but not in my basement at the ceiling where it lives 😆
<Armbian-Discord> <T​onymac32> No, it's all outs
<Armbian-Discord> <T​onymac32> In any case this is a typical issue with patching when we lead mainline with features, when they get added it isn't always in the same place, then the patch algo just goes "this looks good enough" since the DTS is full of repeating patterns
<Armbian-Discord> <T​onymac32> The larger the family the more problematic this is since any individual contributor can miss details of what's being applied where, shared responsibility yields less comprehensive checking more often than not
<Armbian-Discord> <M​anoftheSea> sure, makes sense.
<Armbian-Discord> <r​pardini> I will soon-ish publish the applied patches back to git, where we can clearly see those problems.
<Armbian-Discord> <r​pardini> For .dts/.dtsi changes, we could export the patches with something like --unified=10 (default is 3), so context is more complete and avoids those "} }" problems.
<Armbian-Discord> <r​pardini> Exactly. Manjaro 5.7.y stuff from years ago.
<Armbian-Discord> <T​onymac32> Yeah, but as far as I can tell it never really got sorted out properly in mainline either
<Armbian-Discord> <T​onymac32> I've walked through that particular quagmire a few times, I can sort it out for the boards I can test. I need to go ahead and shine up the ROC-PC since we don't care about non-functioning default power solutions (hello Rock 5B)
<Armbian-Discord> <F​reAk> Greetings, I'm a veteran Linux user (RHEL is the daily driver) but novice SBC tinkerer. I have a nanopc-t4 I've been running for a few years running various services for my home network.
<Armbian-Discord> <F​reAk> I recently upgraded in-place from Armbian Buster to Bullseye (apt upgrade). Talk about nerve wracking!
<Armbian-Discord> <F​reAk> I ended up on Kernel 5.15 instead of 5.19 which confused me slightly since the images show kernel 5.19.
<Armbian-Discord> <F​reAk> I also can't seem to figure out the new PWM fan controls, installing the fancontrol package doesn't seem to help, pwmconfig doesn't seem to think there is a fan-capable sensor module installed. Do I need to update my kernel to fix it?
<Armbian-Discord> <M​anoftheSea> SBC doesn't always follow the parent distro kernel.
<Armbian-Discord> <M​anoftheSea> Beyond that, I'm not knowledgeable about your hardware.
<Armbian-Discord> <r​pardini> He might be hit by the change of family for the nanopct4, from rockchip64 to media...
<Armbian-Discord> <F​reAk> I've been reading about people having issues booting from nvme, so I'm slightly hesitant to update to fix the pwm fan, since that is how I boot now (uboot on emmc and os on nvme)
<Armbian-Discord> <F​reAk> Yeah, I might be using the wrong acronym? SBC = single board computer?
<Armbian-Discord> <t​mm1> yes
<Armbian-Discord> <t​mm1> typically they use older kernels from the board provider, since the latest upstream kernel doesn't have the drivers or support
<Armbian-Discord> <T​enkawa> Which board are you specificly interested in?
<Armbian-Discord> <M​anoftheSea> Yeah, you're right there. I support a different family though
<Armbian-Discord> <T​enkawa> ah the T4
<Armbian-Discord> <T​enkawa> My FriendlyElec board is also a different family
<Armbian-Discord> <c​0rnelius> i have a t4 but I don't have the fancy fan so can't test that
<Armbian-Discord> <c​0rnelius> got this in my dmesg; ```
<Armbian-Discord> <c​0rnelius> nanopc: ~ $ dmesg | grep fan
<Armbian-Discord> <c​0rnelius> [ 0.000000] rcu: Adjusting geometry for rcu_fanout_leaf=16, nr_cpu_ids=6
<Armbian-Discord> <c​0rnelius> [ 3.596544] fan53555-regulator 0-0040: FAN53555 Option[8] Rev[1] Detected!
<Armbian-Discord> <c​0rnelius> [ 3.599744] fan53555-regulator 0-0041: FAN53555 Option[8] Rev[1] Detected!
<Armbian-Discord> <c​0rnelius> ```