| minute | stephano: this is the patch that lets me use dp-connector on the edp port https://source.mnt.re/reform/reform-debian-packages/-/blob/main/linux/patches7.1/rk3588-mnt-reform2/7001-mnt-rockchip-dp-changes-for-usb-c-alt-mode.patch?ref_type=heads | 00:00 |
|---|---|---|
| minute | stephano: this is the pretty horrendous patch to get 3 displays to work. there must be some underlying serious bug in the rockchip vop2 driver that makes the "cluster" type layers/planes only work with 3 displays when certain side effects happen | 00:03 |
| minute | stephano: the symptom was: when i have both an eDP and a HDMI output in devicetree, _and_ a DSI output, eDP would only work if i plug in HDMI at least once, otherwise it would output a signal but just all black screen. when plugging in HDMI the eDP pixel stream was "unlocked", it immediately appeared. this took me forever to understand, i thought it was the monitors at first etc | 00:04 |
| minute | stephano: later i realized it's not HDMI that activates eDP. it's vp1 that activates vp0. so if i swapped eDP to vp1 and HDMI to vp0, it was the other way around: i needed to plug in USB-C/DP to make the HDMI display pixelstream also appear | 00:06 |
| minute | stephano: finally i realized it's not the vps! there's an algorithm (a loop) in the vop2 driver that assigns each active (in devicetree) vp a "window" (layer/plane) initially. these never change. and it uses that list that i'm patching for this assignment | 00:07 |
| minute | stephano: so whoever has the lowest vp number gets the first window, cluster0. the second one gets cluster1 and so on. | 00:07 |
| minute | stephano: the "esmarts" are only assigned to drm overlay planes by default. but i figured they can actually also be primary planes. we lose AFBC compression capability on these outputs then, unfortunately. | 00:08 |
| minute | stephano: but at least the code for the "esmart" windows seems to work correctly, they can be used in parallel without affecting each other in nasty ways. so the real holy grail question is: what is wrong/messed up in the rockchip vop2 code that handles the "cluster" type windows | 00:09 |
| minute | if we figure that out, then that patch can be dropped :D | 00:10 |
| minute | what's also interesting there is that you can basically freely select between two AXI buses (0 and 1, where 0 has higher performance) and each "window" gets assigned an AXI client id, which is semi arbitrarily chosen in the driver's list, which i have a hunch could be related to this issue | 00:11 |
| stephano | minute: I see, so we're giving up hardware compression on 2 of 3 outputs to avoid a driver bug. The vop2_get_cluster_lb_mode() comment certainly looks suspicous. I'm sure once I have the MB2.0 we can work out a fix in no time and upstream it. ;) | 00:16 |
| minute | stephano: neat :D yeah that's the stuff i can really need some help with... it's been too many nights were i went home at 4am after endless debugging sessions of this stuff | 00:22 |
| stephano | minute: I'll read up on the differences between Cluster and Esmart windows. I also have some contacts at both Rockchip and Collabora. | 00:24 |
| minute | stephano: hmm the rotation thing there is actually interesting, you might be onto something. i haven't checked if the pocket's display rotation upsets things in the driver. OTOH when you do `cat /sys/kernel/debug/dri/display-subsystem/vop2/summary` strangely you'll see that there is no HW rotation in place | 00:24 |
| minute | so i guess the rotation at least once we're in gnome is done by the compositor/the gpu | 00:25 |
| minute | (but i'm not sure: the debug output might also be unreliable) | 00:25 |
| minute | but for me it says, for the internal display, > rotate: xmirror: 0 ymirror: 0 rotate_90: 0 rotate_270: 0 | 00:25 |
| minute | in any case the vop2 driver is chock full of exciting things and comments... like "we must wait standby complete when we want to disable aclk, if not, memory bus maybe dead" | 00:29 |
| minute | or "This is a workaround for crazy IC design" | 00:30 |
| stephano | minute: lol. crazy IC designers. designing crazy ICs. | 00:31 |
| + spew (~spew@user/spew) | 00:32 | |
| stephano | And it's Andy of all people... he should go ask those crazy IC designers what they were thinking. | 00:33 |
| minute | yeah :D | 00:33 |
| stephano | So Cluster and Esmart windows are genuinely non-trivially different paths inside VOP2, with enough quirks that even Rockchip's own engineers call the design out as nutty. That's classic hardware fun. | 00:34 |
| minute | yes, exactly | 00:38 |
| minute | it's kind of hard to convey why this is/was so hard for me, because noone would believe how bizarre the setup is in there that i have to work with | 00:39 |
| minute | ah btw it's possible that i don't see hw rotation here because esmarts can't do rotation :D | 00:40 |
| + simba (~simba@91.126.182.14) | 00:41 | |
| josch | stephano: in the debian machinery with your patches, amlogic/meson-g12b-bananapi-cm4-mnt-pocket-reform.dtb isn't getting built anymore. Are you missing the device tree patches? I see that your branch doesn't have ./arch/arm64/boot/dts/amlogic/meson-g12b-bananapi-cm4-mnt-pocket-reform.dts | 00:43 |
| - simba (QUIT: Ping timeout: 246 seconds) (~simba@91.126.182.14) | 00:45 | |
| stephano | josch: hmmm, let me check. IIRC all the dts files got copied in manually by my build scripts, but maybe there were patches in there somewhere I was missing. | 00:52 |
| stephano | josch: okay, now I remember. build.sh uses the dts files in reform-debian-packages, so in my build setup I mimic it (copy in, edit makefiles, etc). I *think* build.sh starts from a clean kernel source, copies MNT's .dts files into it, edits the vendor Makefiles to build them, then uses quilt to package that whole diff into one generated patch (dts.patch) that ships with the Debian source. If | 01:00 |
| stephano | quilt fails to capture one file during that step, it just won't be in the final patch. | 01:00 |
| stephano | josch: so the patches I generated will not include the dts files or the Makefile edits. they will just be the patches that were in reform-debian-packages. | 01:02 |
| stephano | josch: i can update my build system so that it applies those changes as commits if we want to do it that way. or we can mull over the best route here. | 01:03 |
| digitalrane | josch: got via email your message about NixOS maintenance + the direction to move away from tracking patches in the repo, to maintaining branches pre-patched (if I understood the workflow). that's much more aligned with how NixOS tracks and trusts inputs (source code sources) so I think will actually make NixOS on Reform easier to maintain, not harder. | 01:04 |
| josch | stephano: why do you use the patches from reform-debian-packages as your source? This will be the last time that doing that will be useful. I also attached the script I used to go from patch files to git commits in that MR and in the commit message. | 01:05 |
| josch | digitalrane: wonderful, i already recorded that in the aforementioned commit message | 01:05 |
| josch | stephano: going forward, the ./linux/patchesX.YY directories are going the way of git rm -rf | 01:06 |
| stephano | josch: right, I assumed that was all going away, I just missed the part of the script where the dts/makefile changes happened. | 01:10 |
| minute | josch: btw thanks for completing my sentence in the firmware update instructions post :D I fixed that now | 01:10 |
| josch | minute: ah good to know that i didn't mess up that completion, nice :D | 01:10 |
| stephano | josch: so I basically use that script to add in the dts files and Makefile updates, but as commits, they'll need authors, dates, etc. I just wasn't sure you wanted me to be the author and wall clock time to be the date of all those commits. :) | 01:15 |
| josch | stephano: since this is just a patch stack, history of the files (including all its contributors) will somehow get lost over time. I have to write this down as one of the downsides of this mechanism. I'd just put minute as author and call it a day. | 01:17 |
| stephano | josch: okay, that works for me. ^^ | 01:18 |
| minute | nice. | 01:29 |
| stephano | josch: okay, that's 8 more commits, 16 dts files, 1 dtsi file, and 4 Makefile edits (freescale, amlogic, rockchip, qcom). | 01:41 |
| + simba (~simba@91.126.182.14) | 01:42 | |
| stephano | josch: sorry about the confusion there. for whatever reason I assumed you just wanted patches that were straight out of reform-debian-packages, not the dts/makefile ones. easy fix though, I just had to uncomment that code. :) | 01:43 |
| josch | stephano: i think an advantage of the new system is that we can *also* change the device tree files right in the kernel which avoids the super ugly makefile patching among other things | 01:44 |
| stephano | josch: agreed, 100% | 01:45 |
| Esi | oh my, just tested Xonotic on the pocket reform. I did not expect to reach 50-90 fps on this device. <3 (also, the trackball was way more usable than I expected O_o). amazing | 01:45 |
| josch | i've retried the pipeline, it's building now: https://source.mnt.re/josch/reform-debian-packages/-/jobs/24125 | 01:45 |
| stephano | \o/ | 01:45 |
| josch | stephano: speaking of upstreaming, did you try out this? https://source.mnt.re/josch/linux/-/merge_requests/1 | 01:46 |
| josch | i also saw that other device trees have a lot of overlap and could maybe benefit from moving common parts into a common dtsi | 01:46 |
| - simba (QUIT: Ping timeout: 241 seconds) (~simba@91.126.182.14) | 01:47 | |
| josch | anyway, off to bed now _o/ | 01:48 |
| - aperezdc (QUIT: Ping timeout: 253 seconds) (~aperezdc@2a03:6000:6e61:633::43) | 01:54 | |
| minute | n8n8! | 01:55 |
| - xktr (QUIT: Ping timeout: 248 seconds) (~xktr@user/xktr) | 01:56 | |
| + xktr (~xktr@user/xktr) | 01:58 | |
| + aperezdc (~aperezdc@2a03:6000:6e61:633::43) | 02:11 | |
| - mjw (QUIT: Ping timeout: 248 seconds) (~mjw@gnu.wildebeest.org) | 02:21 | |
| - aperezdc (QUIT: Ping timeout: 247 seconds) (~aperezdc@2a03:6000:6e61:633::43) | 02:28 | |
| - colinsane (QUIT: Remote host closed the connection) (~colinunin@97-113-90-70.tukw.qwest.net) | 02:45 | |
| + aperezdc (~aperezdc@2a03:6000:6e61:633::43) | 02:48 | |
| + colinsane (~colinunin@97-113-90-70.tukw.qwest.net) | 02:49 | |
| - Gooberpatrol66 (QUIT: Quit: Konversation terminated!) (~Gooberpat@user/gooberpatrol66) | 02:59 | |
| stephano | Pipeline passed: https://source.mnt.re/josch/reform-debian-packages/-/jobs/24125 (´◡`) | 03:06 |
| stephano | Nice way to end the weekend. | 03:07 |
| - paperManu (QUIT: Ping timeout: 250 seconds) (~paperManu@173.206.254.242) | 03:25 | |
| + simba (~simba@91.126.182.14) | 03:29 | |
| - chrcav (QUIT: Quit: leaving) (~chrcav@user/chrcav) | 03:33 | |
| - simba (QUIT: Ping timeout: 245 seconds) (~simba@91.126.182.14) | 03:34 | |
| + paperManu (~paperManu@79.127.134.47) | 03:35 | |
| - paperManu (QUIT: Read error: Connection reset by peer) (~paperManu@79.127.134.47) | 04:05 | |
| + simba (~simba@91.126.182.14) | 04:19 | |
| - AnimaInvicta (PART: !!unknown attribute: msg!!) (~AnimaInvi@88-169-191-86.subs.proxad.net) | 04:22 | |
| - simba (QUIT: Ping timeout: 249 seconds) (~simba@91.126.182.14) | 04:23 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 05:04 | |
| + simba (~simba@91.126.182.14) | 05:24 | |
| + mrdaught (~mrdaught@bras-base-maplon2310w-grc-11-174-89-155-2.dsl.bell.ca) | 05:26 | |
| - mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@bras-base-maplon2310w-grc-11-174-89-155-2.dsl.bell.ca) | 05:27 | |
| - simba (QUIT: Ping timeout: 251 seconds) (~simba@91.126.182.14) | 05:29 | |
| - spew (QUIT: Quit: nyaa~) (~spew@user/spew) | 05:42 | |
| + spew (~spew@user/spew) | 05:43 | |
| + tookmund (~tookmund@pool-72-84-249-135.rcmdva.fios.verizon.net) | 05:55 | |
| + simba (~simba@91.126.182.14) | 06:22 | |
| - simba (QUIT: Ping timeout: 258 seconds) (~simba@91.126.182.14) | 06:27 | |
| - spew (QUIT: Quit: bye) (~spew@user/spew) | 07:01 | |
| - tookmund (QUIT: Ping timeout: 252 seconds) (~tookmund@pool-72-84-249-135.rcmdva.fios.verizon.net) | 07:06 | |
| + simba (~simba@91.126.182.14) | 07:26 | |
| - simba (QUIT: Ping timeout: 245 seconds) (~simba@91.126.182.14) | 07:31 | |
| josch | stephano: pipeline passed -- do you have time to fix imx8m+ qcacld2 out-of-tree-driver as well? ;) | 07:47 |
| - arminweigl (QUIT: Remote host closed the connection) (~arminweig@sourcehut/user/arminweigl) | 07:55 | |
| + arminweigl (~arminweig@sourcehut/user/arminweigl) | 07:56 | |
| josch | too late, done :) | 08:27 |
| josch | testing noow... | 08:27 |
| + simba (~simba@91.126.182.14) | 08:30 | |
| - simba (QUIT: Ping timeout: 258 seconds) (~simba@91.126.182.14) | 08:35 | |
| - lidstah (QUIT: Ping timeout: 245 seconds) (~lidstah@gateway/tor-sasl/lidstah) | 08:48 | |
| + lidstah (~lidstah@gateway/tor-sasl/lidstah) | 08:50 | |
| - marty (QUIT: Ping timeout: 276 seconds) (~marty@static-23-234-102-213.cust.tzulo.com) | 09:07 | |
| + marty (~marty@static-23-234-103-203.cust.tzulo.com) | 09:09 | |
| - aperezdc (QUIT: *.net *.split) (~aperezdc@2a03:6000:6e61:633::43) | 09:46 | |
| - cli (QUIT: *.net *.split) (~m-vsauiy@user/cli) | 09:46 | |
| - dodo (QUIT: *.net *.split) (~dodo@user/dodo) | 09:46 | |
| - Kooda (QUIT: *.net *.split) (~kooda@natsu.upyum.com) | 09:46 | |
| - frickler (QUIT: *.net *.split) (~jens@user/frickler) | 09:46 | |
| - AshCurry (QUIT: *.net *.split) (~AshCurry@user/AshCurry) | 09:46 | |
| - a3f (QUIT: *.net *.split) (~a.fatoum@flummi.grey.stw.pengutronix.de) | 09:46 | |
| - glu (QUIT: *.net *.split) (~glu@user/glu) | 09:46 | |
| - buckket (QUIT: *.net *.split) (~buckket@vps.buckket.org) | 09:46 | |
| - jbmorley (QUIT: *.net *.split) (~jbmorley@dhcp-72-253-8-30.hawaiiantel.net) | 09:46 | |
| - BAndiT1983 (QUIT: *.net *.split) (~quassel@2a03:b0c0:3:f0:0:1:9e0a:7000) | 09:46 | |
| + glu (~glu@user/glu) | 09:46 | |
| + frickler (~jens@user/frickler) | 09:46 | |
| + BAndiT1983 (~quassel@2a03:b0c0:3:f0:0:1:9e0a:7000) | 09:46 | |
| + AshCurry (~AshCurry@user/AshCurry) | 09:46 | |
| + a3f (~a.fatoum@flummi.grey.stw.pengutronix.de) | 09:46 | |
| + aperezdc (~aperezdc@2a03:6000:6e61:633::43) | 09:46 | |
| + jbmorley (~jbmorley@dhcp-72-253-8-30.hawaiiantel.net) | 09:46 | |
| + cli (~m-vsauiy@user/cli) | 09:46 | |
| + dodo (~dodo@user/dodo) | 09:46 | |
| + buckket (~buckket@vps.buckket.org) | 09:46 | |
| + Kooda (~kooda@natsu.upyum.com) | 09:46 | |
| + simba (~simba@91.126.182.14) | 10:12 | |
| - simba (QUIT: Ping timeout: 249 seconds) (~simba@91.126.182.14) | 10:17 | |
| josch | stephano: "make CHECK_DTBS=y" errors out for amlogic/meson-g12b-bananapi-cm4-mnt-pocket-reform.dtb: https://source.mnt.re/josch/reform-debian-packages/-/jobs/24161 | 10:40 |
| josch | (with kernel 7.2) | 10:41 |
| + simba (~simba@91.126.182.14) | 10:43 | |
| - simba (QUIT: Ping timeout: 251 seconds) (~simba@91.126.182.14) | 10:49 | |
| josch | qcacl2 now successfully builds with 7.2.2: https://source.mnt.re/josch/reform-debian-packages/-/jobs/24166 | 11:00 |
| josch | minute: can you merge this? https://source.mnt.re/reform/qcacld2/-/merge_requests/19 | 11:00 |
| + simba (~simba@91.126.182.14) | 11:12 | |
| + mjw (~mjw@gnu.wildebeest.org) | 11:17 | |
| - simba (QUIT: Ping timeout: 256 seconds) (~simba@91.126.182.14) | 11:17 | |
| + mrdaught (~mrdaught@174.89.155.2) | 11:27 | |
| - mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@174.89.155.2) | 11:31 | |
| - Guest29952 (QUIT: Quit: The Lounge - https://thelounge.chat) (~ndufresne@transit.collaboradmins.com) | 11:34 | |
| + Guest29952 (~ndufresne@transit.collaboradmins.com) | 11:37 | |
| josch | minute: in mnt-sc, would it be a problem if mntsc_probe() would call sc_cmdresp_retry(..., "(0q)") early and return -ENODEV if it fails? Doing that would avoid creating a "dead" battery entry. | 12:44 |
| + simba (~simba@91.126.182.14) | 12:45 | |
| - mjw (QUIT: Ping timeout: 271 seconds) (~mjw@gnu.wildebeest.org) | 12:45 | |
| - simba (QUIT: Ping timeout: 264 seconds) (~simba@91.126.182.14) | 12:49 | |
| + paperManu (~paperManu@173.206.254.242) | 12:51 | |
| * Guest6168 -> mjw | 13:05 | |
| - lidstah (QUIT: Remote host closed the connection) (~lidstah@gateway/tor-sasl/lidstah) | 13:08 | |
| + lidstah (~lidstah@gateway/tor-sasl/lidstah) | 13:08 | |
| - lidstah (QUIT: Remote host closed the connection) (~lidstah@gateway/tor-sasl/lidstah) | 13:19 | |
| + lidstah (~lidstah@gateway/tor-sasl/lidstah) | 13:23 | |
| minute | josch: lets try it! this could possibly also fix the journald loop issue? | 13:45 |
| josch | minute: i'm trying it right now but wanted to know if there was a reason why it should not be done | 13:46 |
| josch | and thank you for merging! _o/ | 13:54 |
| - tomenzgg (QUIT: Ping timeout: 253 seconds) (~tomenzgg@user/tomenzgg) | 14:48 | |
| + simba (~simba@91.126.182.14) | 15:07 | |
| - simba (QUIT: Ping timeout: 265 seconds) (~simba@91.126.182.14) | 15:11 | |
| stephano | josch: that failure looks like something to do with ti,pruss-intc.yaml, TI's interrupt controller binding. So I think dtschema is flagging some type conflict. Possible something new in 7.2. I'd try the dtb check agains a clean 7.2.2 tree and see if it fails. | 15:25 |
| + wakest__ (~wakest__@88.130.184.197) | 15:46 | |
| + simba (~simba@91.126.182.14) | 16:12 | |
| - simba (QUIT: Ping timeout: 242 seconds) (~simba@91.126.182.14) | 16:16 | |
| - sterni (QUIT: ) (~quassel@user/sterni) | 16:50 | |
| + sterni (~quassel@user/sterni) | 16:50 | |
| - kfx (QUIT: Remote host closed the connection) (~kfx@grendel.sciops.net) | 16:57 | |
| - schalken (QUIT: Ping timeout: 242 seconds) (~schalken@117-118-178-69.gci.net) | 16:59 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 17:00 | |
| josch | minute: confirmed -- if the mnt-sc driver fails early, boot proceeds normally | 17:02 |
| minute | josch: awesome, many thanks for testing this | 17:03 |
| josch | there is no display backlight though, i guess i have to re-order some things | 17:03 |
| minute | josch: hmm, can you show me your patch so far? | 17:03 |
| josch | minute: something (i don't know which component) keeps querying the battery status and i guess that's where it gets stuck. An alternative would be to report dummy values. | 17:03 |
| josch | i inserted this: | 17:04 |
| josch | uint8_t buffer[MNTSC_RES_SZ]; if (sc_cmdresp_retry(data, "(0q)", buffer)) {dev_err(&spi->dev, "sc_ | 17:04 |
| josch | cmdresp_retry(0q) failed.\n");return -ENODEV;} | 17:04 |
| * rick____ -> rick_ | 17:04 | |
| josch | after spi_set_drvdata(spi, data); | 17:04 |
| josch | editing patches sucks, so it's all in a single line | 17:04 |
| minute | aw. why do you need to edit the patch? | 17:04 |
| josch | minute: was quicker than finding where the original lives that i should diff it against | 17:05 |
| minute | when i work on mntsc i just build the .ko in the reform-debian-packages/linux/linux checkout and ssh it over | 17:05 |
| minute | josch: hmm the original is just /dev/zero normally | 17:06 |
| minute | the patch creates the file, no? | 17:06 |
| minute | so you can recreate the patch by just doing git diff /dev/zero drivers/firmware/mnt-sc.c | 17:07 |
| josch | yes and i'd still have to get the number of lines in the @@ line right and after it broke twice i just did it in a single line :) | 17:07 |
| minute | why not just edi mnt-sc.c? | 17:07 |
| minute | s/edi/edit | 17:07 |
| josch | that file is not in git, right? | 17:07 |
| minute | not sure, but it doesn't have to be, because you have a patch file that can create it (the patch file is a repository, kind of) | 17:08 |
| minute | my workflow is: 1. let the patch create mnt-sc.c 2. edit mnt-sc 3. recreate patch by doing git diff /dev/zero mnt-sc.c | 17:08 |
| josch | well, the discussion is moot because MR 195 exists and i rather want to use that going forward :) | 17:08 |
| minute | yes, you can also just use that :D | 17:08 |
| minute | josch: ok, back to the problem at hand. you say that there is "no backlight" | 17:09 |
| josch | yes | 17:10 |
| minute | josch: ok what is the state of the system controller currently, in your device? does it run old firmware, or no firmware? | 17:11 |
| josch | i already re-ordered things because right now i abort before mntsc_create_backlight() is getting called | 17:11 |
| josch | i have it with an old firmware | 17:11 |
| minute | josch: hm but create_backlight won't help i think, because if you return enodev it will be destroyed again | 17:12 |
| josch | i also return 0 now :) | 17:12 |
| josch | wait did i copy pastewrong? | 17:12 |
| josch | yes i did | 17:12 |
| josch | one sec here is what i'm currently building: | 17:12 |
| josch | https://paste.debian.net/hidden/3b1bb2fe | 17:12 |
| josch | line 328 is the interesting one and i moved the stuff that used to be at the end before it | 17:13 |
| + spew (~spew@user/spew) | 17:14 | |
| minute | josch: ok, in any case, mnt-sc can't talk to the old firmware _at all_ so the driver has no function at all | 17:15 |
| josch | whoops | 17:15 |
| minute | josch: i'm more worried about having no backlight without mnt-sc, as opposed to having 100% backlight, but unchangeable | 17:15 |
| josch | well, feel free to take over at any time -- i'm just poking in the dark | 17:15 |
| minute | josch: my understanding is that by no backlight you mean that the backlight is visibly at 0%, i.e. nothing visible on screen? | 17:16 |
| minute | and i wonder why that should happen... | 17:16 |
| josch | the screen is black -- hard to see whether something would show on it... | 17:16 |
| minute | josch: ok so with the old firmware, normally the backlight goes on immediately on powerup. is that no longer the case? | 17:17 |
| josch | it does not go on. this is with u-boot | 17:17 |
| minute | uff ok that is extremely strange. or... do you have display v1 mabye? | 17:18 |
| josch | nope, v2 | 17:18 |
| josch | is panel-mnt-pocket-reform required to be loaded for the backlight to come up? | 17:19 |
| josch | because that one depends on mnt-sc, no? and in my last iteration, mnt-sc still exited with ENODEV | 17:19 |
| josch | i'm only trying the patch i sent you last now (it's building) | 17:19 |
| - wakest__ (QUIT: Ping timeout: 257 seconds) (~wakest__@88.130.184.197) | 17:20 | |
| minute | josch: well lets go one step back. we first need to figure out why the display doesn't activate directly after powerup, with no OS involved | 17:21 |
| minute | josch: normally there is some light that should come out of the display after you press hyper+enter, 1 | 17:22 |
| josch | maybe i have to go to a darker spot | 17:22 |
| josch | i'll come back to you in ~1 hour i need to do household stuff now | 17:22 |
| minute | right, i was thinking maybe it's just too bright there to see | 17:22 |
| minute | (the new firmware also still has this behavior, for backwards compat) | 17:23 |
| josch | yes, i rather use a command on the shell than trust my eyes about the backlight XD | 17:23 |
| minute | the brightness is normally by default at 100% for exactly this reason | 17:23 |
| minute | that the OS or bootloader can't set the brightness | 17:23 |
| minute | the OS can't tell you what the real brightness is, because it can't ask about that. it only can tell you what it thinks it should be | 17:24 |
| minute | in any case, it is normal that there won't be a backlight node if mnt-sc doesn't probe correctly. that's fine | 17:24 |
| josch | yup, i just wish it were possible because that'd give me a binary answer instead of "maybe your room is too bright, who knows" | 17:25 |
| minute | because this backlight node would be nonfunctional anyway | 17:25 |
| josch | right | 17:25 |
| minute | josch: only the firmware knows about the backlight, but as you have the old fw, you don't have a CLI to ask it | 17:25 |
| josch | yup | 17:26 |
| josch | thank you for the feedback -- i'll get back to you once i can test the new version which doesn't exit with ENODEV | 17:26 |
| minute | it rather sounds like the panel is not being initialized by panel-mnt-pocket-reform. but there should be copious output in dmesg about htis | 17:26 |
| minute | josch: your code is basically correct so the problem is elsewhere now | 17:26 |
| minute | josch: all of this must work with mnt-sc failing | 17:27 |
| josch | oh.. hrm... i remember that last time i forced unload of mnt-sc my display went off -- that expected? | 17:28 |
| minute | josch: not expected | 17:30 |
| josch | fun :D | 17:30 |
| minute | josch: i mean, it depends. was this with old or new fw | 17:30 |
| minute | josch: if with new fw, expected, because then the gpios that mntsc offers were created and the panel opened them | 17:31 |
| josch | yes, new fw. okay | 17:31 |
| minute | josch: so it was creating a dependency. it is optional though | 17:31 |
| + mrdaught (~mrdaught@bras-base-maplon2310w-grc-11-174-89-155-2.dsl.bell.ca) | 17:31 | |
| minute | josch: so if mntsc doesn't offer these gpios, the panel driver should just continue with a warning | 17:31 |
| minute | josch: most helpful would be the dmesg logs after your current mntsc patch. but no rush, send me later :D i'm also working on next handbook now | 17:32 |
| josch | perfect, you get a ping once i have it for you. i have uart connected, so you get the full boot log :) | 17:33 |
| - mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@bras-base-maplon2310w-grc-11-174-89-155-2.dsl.bell.ca) | 17:35 | |
| + wakest__ (~wakest__@88.130.184.197) | 17:46 | |
| + tomenzgg (~tomenzgg@24.148.84.215) | 17:48 | |
| - tomenzgg (QUIT: Changing host) (~tomenzgg@24.148.84.215) | 17:48 | |
| + tomenzgg (~tomenzgg@user/tomenzgg) | 17:48 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 18:05 | |
| + AnimaInvicta (~AnimaInvi@88-169-191-86.subs.proxad.net) | 18:19 | |
| - schalken (QUIT: Ping timeout: 255 seconds) (~schalken@117-118-178-69.gci.net) | 18:23 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 18:25 | |
| josch | backlight is on :) | 18:44 |
| josch | and there we have an image | 18:44 |
| josch | minute: the latest patch i linked above makes it work without journalctl problems. It boots fine now. Tested with a fresh MNT Debian unstable system image. | 18:46 |
| josch | minute: should i now upgrade the firmware to the latest to see whether things keep working or is there value in me keeping the old firmware for now to test other things? | 18:47 |
| minute | josch: awesome!! yes, please test with the new firmware directly :3 | 18:47 |
| sigrid | is there any documentation on how to write u-boot to emmc on rk3588? | 19:05 |
| sigrid | and perhaps how to build it as well | 19:06 |
| + Ar|stote|is (~linx@149.210.8.177) | 19:20 | |
| - schalken (QUIT: Ping timeout: 265 seconds) (~schalken@117-118-178-69.gci.net) | 19:25 | |
| + chrcav (~chrcav@user/chrcav) | 19:25 | |
| + wielaard (~mjw@gnu.wildebeest.org) | 19:26 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 19:27 | |
| + paperManu_ (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 19:44 | |
| ch | https://source.mnt.re/reform/reform-rk3588-uboot has a build.sh | 19:52 |
| ch | i imagine https://source.mnt.re/reform/reform-rk3588-uboot/-/tags/2026-01-11 might have docs on flashing, but i cant see the page atm | 19:53 |
| minute | sigrid: dd if=uboot of=disk seek=64 | 19:56 |
| minute | ch: what's the first number of your ipv4? | 19:57 |
| stephano | sigrid: you can also find the offsets and locations here: https://source.mnt.re/stephano/reform-tools/-/tree/main/machines | 19:58 |
| sigrid | nice, thanks | 19:59 |
| ch | minute: (no secret) 89.144.220.207 | 20:00 |
| ch | pretty sure this is a dynamic pool tho | 20:00 |
| minute | ok, checking | 20:00 |
| minute | ch: ok it's not in the blocked /8 or /16 networks, so checking invidiuals... | 20:01 |
| minute | ch: funny, that IP doesn't appear to be blocked. but a bunch of others in 89.144.220.x | 20:03 |
| - schalken (QUIT: Ping timeout: 260 seconds) (~schalken@117-118-178-69.gci.net) | 20:06 | |
| + schalken (~schalken@69.178.118.117) | 20:07 | |
| - schalken (QUIT: Ping timeout: 271 seconds) (~schalken@69.178.118.117) | 20:12 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 20:13 | |
| josch | sigrid, minute: if somebody needs the raw dd command to flash a bootloader, then anybody with access to reform-flash-uboot can just run it like this: | 20:18 |
| josch | reform-flash-bootloader --dry-run --verbose /dev/mmcblk1 | 20:18 |
| josch | and that will *not* do the flashing but instead print the command that would've been run, in my case: | 20:18 |
| josch | dd if=/boot/flash.bin of=/dev/mmcblk1boot0 bs=512 seek=1 skip=1 conv=fdatasync | 20:18 |
| josch | this also takes care of "magic" like deciding whether to write to a boot0 partition and not only gives the "seek" but also the right "skip" value | 20:19 |
| josch | (and will remind you to write 0 and 1 to /sys/class/block/${DEV_MMC}boot0/force_ro) | 20:21 |
| minute | josch: ah neat @ --dry-run | 20:23 |
| josch | minute: and because you can give an arbitrary machine with the --machine option you can provide the right dd command for anybody, even those who don't have the same machine you are running the command on :) | 20:25 |
| josch | minute: the latest MNT Debian unstable system image was usable with the old firmware, given mnt-sc is changed using my patch above. Of course no battery and no display brightness but the system worked and i was able to connect to the wifi and upgrade my sysctl to the latest version. Now I have battery information and can set the screen brightness just fine. Anything else i should test? | 20:37 |
| josch | Curiously, I get: "reform-hw-setup: Invalid card number 'rk3588tlv320aic'" and the issue seems to persist across reboots. aplay -l only lists hdmi | 20:38 |
| minute | josch: sounds great @ your mntsc hotfix! | 20:41 |
| minute | josch: ok, so your rk3588 (?) is seeing no audio chip now? | 20:41 |
| josch | let me paste you a dmesg... sec... | 20:45 |
| josch | yes, rk3588 pocket reform | 20:45 |
| josch | latest mnt debian unstable system image -- no debian stable sheningans | 20:46 |
| josch | oh great, now it's back -- so it *is* flaky... | 20:46 |
| josch | rebooting again... | 20:46 |
| - wakest__ (QUIT: Ping timeout: 266 seconds) (~wakest__@88.130.184.197) | 20:59 | |
| - schalken (QUIT: Ping timeout: 261 seconds) (~schalken@117-118-178-69.gci.net) | 21:09 | |
| josch | i'm unable to reproduce it after it failed three times in a row it worked fine six times in a row... sigh... | 21:10 |
| + schalken (~schalken@117-118-178-69.gci.net) | 21:11 | |
| - schalken (QUIT: Ping timeout: 254 seconds) (~schalken@117-118-178-69.gci.net) | 21:35 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 21:36 | |
| - tomenzgg (QUIT: Ping timeout: 267 seconds) (~tomenzgg@user/tomenzgg) | 21:47 | |
| - Gooberpatrol66 (QUIT: Quit: Konversation terminated!) (~Gooberpat@user/gooberpatrol66) | 21:56 | |
| + wakest__ (~wakest__@2a02:2455:8220:4700:6554:374a:157d:9c35) | 21:57 | |
| - wakest__ (QUIT: Ping timeout: 259 seconds) (~wakest__@2a02:2455:8220:4700:6554:374a:157d:9c35) | 22:01 | |
| minute | fun twist https://lore.kernel.org/all/2026080354-skater-urgent-31b2@gregkh/T/#u | 22:02 |
| frickler | nice | 22:09 |
| * mjw -> Guest7036 | 22:09 | |
| - Guest7036 (QUIT: Killed (molybdenum.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:4600:5952:3a9:6e0e:555a) | 22:09 | |
| * wielaard -> mjw | 22:09 | |
| + Guest7036 (~mjw@2001:1c06:2486:4600:5952:3a9:6e0e:555a) | 22:10 | |
| josch | i would like to click that link but after staring at my browser trying to solve the anubis riddle for more than 120 seconds (yes i looked at my clock) i just gave up... what irony would it be if that was an llm related post... | 22:12 |
| - schalken (QUIT: Ping timeout: 257 seconds) (~schalken@117-118-178-69.gci.net) | 22:12 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 22:13 | |
| frickler | it is, yes, and yes, sadly scrapers have learned to solve anubis, but using it at high enough levels seem to still slow them down enough to keep services running semi-reasonably. | 22:14 |
| frickler | but 5 seconds on a fast CPU may become an eternity on slower hardware indeed | 22:18 |
| + wakest__ (~wakest__@2a02:2455:8220:4700:6554:374a:157d:9c35) | 22:21 | |
| - gianmarcogg03 (QUIT: Ping timeout: 270 seconds) (~quassel@user/gianmarcogg03) | 22:22 | |
| + gianmarcogg03_ (~quassel@user/gianmarcogg03) | 22:22 | |
| josch | too bad prices for a much faster cpu like rk3588 increased by 100 USD *again* recently... i wonder why that is... | 22:24 |
| rick_ | can we please create an alternative to corporate web? sites which can be accessed which don't need massive cpus and are by desing not scrape relevant... | 22:34 |
| rick_ | tbh i think my fedi instance still runs so well is, that i basically blocked any unauthanticated access | 22:35 |
| - schalken (QUIT: Ping timeout: 264 seconds) (~schalken@117-118-178-69.gci.net) | 22:47 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 22:48 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 22:56 | |
| - lidstah (QUIT: Ping timeout: 248 seconds) (~lidstah@gateway/tor-sasl/lidstah) | 22:59 | |
| + lidstah (~lidstah@gateway/tor-sasl/lidstah) | 23:01 | |
| + simba (~simba@91.126.182.14) | 23:03 | |
| - simba (QUIT: Ping timeout: 240 seconds) (~simba@91.126.182.14) | 23:07 | |
| - schalken (QUIT: Ping timeout: 263 seconds) (~schalken@117-118-178-69.gci.net) | 23:09 | |
| loon | rick_: folks are working on that, and such things do exist, but adoption is basically zero | 23:12 |
| - vagrantc (QUIT: Ping timeout: 250 seconds) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 23:12 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 23:13 | |
| - schalken (QUIT: Ping timeout: 263 seconds) (~schalken@117-118-178-69.gci.net) | 23:20 | |
| + schalken (~schalken@117-118-178-69.gci.net) | 23:23 | |
| - paperManu_ (QUIT: Ping timeout: 258 seconds) (~paperManu@modemcable141.205-200-24.mc.videotron.ca) | 23:24 | |
| - lidstah (QUIT: Remote host closed the connection) (~lidstah@gateway/tor-sasl/lidstah) | 23:28 | |
| + lidstah (~lidstah@gateway/tor-sasl/lidstah) | 23:28 | |
| + mrdaught (~mrdaught@174.89.155.2) | 23:34 | |
| + siviq (~siviq@user/siviq) | 23:35 | |
| - mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@174.89.155.2) | 23:37 | |
| + paperManu_ (~paperManu@173.206.254.242) | 23:39 | |
| siviq | Esi I've been catching up on the irc logs and saw you asked for fun open hardware projects. I've been using Tanmatsu, which is open hardware/software device for some time now (https://nicolaielectronics.nl/tanmatsu/). I created simple online radio player for it https://mastodon.social/@siviq/117084218352932504. And used it during my vacation :) | 23:49 |
| Esi | oh that looks lovely <3 | 23:54 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!