03:40 <SolidHal> urjaman Thanks, I'll try that out. In case you didn't see, I solved the dwc2/ath9k issue. I have a patch here https://github.com/SolidHal/PrawnOS/blob/master/resources/BuildResources/patches-tested/kernel/0001-Fix-ath9k-dwc2-init-frame-overruns.patch

05:40 <SolidHal> urjaman Your config worked, which means now I get to find the needle in the config haystack! But at least it's not a kernel bug, thanks again!

07:22 <urjaman> SolidHal: nice to hear (and i'd be curious to know what config it was when you figure it out), and yeah i've bookmarked (and looked at) that dwc2/atkh9k workaround, hopefully i'll remember to put it in the next time i work on the kernel

07:23 <urjaman> (I dont have an ath9k to test so not super high priority for me...)

19:29 <sphalerite> I'm booting a standard linux from u-boot 2019.07 on my nanopi m4. It works wonderfully on a cold boot, but when I try to reboot, the SPL fails to load u-boot itself: mmc_load_image_raw_sector: mmc block read error // SPL: failed to boot from all boot devices // ### ERROR ### Please RESET the board ###

19:29 <sphalerite> Any ideas what might be going on here and how to fix it?

19:45 <mmind00> sphalerite: maybe the emmc is in a bad state?

19:46 <urjaman> i'd guess there is some sort of trouble in moving the eMMC (or SD? idk) from the high-speed mode linux uses back to the mode u-boot uses...

19:46 <mmind00> sphalerite: one idea would be to add an emmc-pwrseq to the dts, which might set things back?

19:47 <mmind00> or possibly check the clock-rates? ... but then how does it manage to load bootrom->tpl->spl from emmc I wonder

19:47 <sphalerite> how would I do that?

19:48 <sphalerite> (sorry, not much of an expert on this…)

19:50 <sphalerite> that is, the emmc-pwrseq

19:50 <sphalerite> if that's indeed relevant to SD cards

19:51 <sphalerite> in arch/arm/dts/rk3399-nanopi4-u-boot.dtsi I'm guessing?

19:51 <sphalerite> within the &sdmmc node

19:56 <sphalerite> according to a grep, no :)

19:59 <inode> more info in Documentation/devicetree/bindings/mmc/mmc-pwrseq-emmc.txt

20:03 <mmind00> sphalerite: there should be more examples in other rockchip boards as well ... the "important" thing is to hook up the emmc reset line ... for example rk3368-orion-r68-meta.dts ... you just need to get the rk3399 emmc reset gpio

20:09 <sphalerite> mmind00: huh, I don't see rk3368-orion-r68-meta.dts

20:09 <mmind00> sphalerite: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3368-orion-r68-meta.dts#n23

20:10 <sphalerite> oooooh, in the _kernel_ dts??

20:10 <sphalerite> I was looking in u-boot >.<

20:11 <mmind00> sphalerite: that's the second part ... aka uboot also handles power-sequences ... I was primarily looking for an actual example :-)

20:11 <sphalerite> right

20:12 <sphalerite> but I need to put it in the u-boot device tree so that u-boot will reset the SD card [controller?], right?

20:20 <sphalerite> I think I'm beyond my depth here :(

20:21 <stikonas> oh, this emmc-pwrseq might be something that I need too on rockpro64...

20:22 <stikonas> at the moment reboots don't work here

20:22 <stikonas> although, I don't get any error message at all

20:35 <mmind00> sphalerite: correct that then needs to go into the uboot dts as well

20:35 <mmind00> sphalerite: but of course that's "just a simple" copy'n'paste :-D

20:35 <sphalerite> but how do I find the right GPIO?

20:37 <vicencb> Hi, since a recent update of archlinuxarm on the kevin platform the X session is updating frames only when switching VTs.

20:37 <vicencb> for testing i have tried sway and it works fine with a decent frame-rate.

20:37 <vicencb> Has anybody experienced a similar issue before?

20:37 <vicencb> Does somebody know where could be the root cause?

20:37 <vicencb> (Note: X is using the fbdev driver)

20:45 <mmind00> sphalerite: I think there should be schematics for the nanopi devices?

20:47 <mmind00> vicencb: why would you want fbdev? The edp on Kevin uses PSR for power savings, which is hooked into the rockchip drm-driver and works nicely with both regular kms stuff, modesetting xserver and wayland ... but I guess it might be possible that fbdev could affect it

20:48 <mmind00> vicencb: and I had seen something similar in the past with the xserver cursor only blinking while moving the mouse ... but that got fixed meanwhile

20:49 <vicencb> mmind00: i am using fbdev because /usr/lib/dri/rockchip_dri.so segfaults while fbdev has been working fine since last week

21:12 <vicencb> mmind00: also fbdev is working fine on the sapphire board through hdmi (using archlinuxarm too)

21:15 <mmind00> vicencb: as I said, the edp PSR might be the culprit

21:16 <vicencb> mmind00: does PSR stand for power saving registers?

21:26 <vicencb> oh, i see, panel self-refresh