| minute | ok, i'm back! | 00:00 |
|---|---|---|
| minute | > Linux pocki3000 6.14.5-mnt-reform-arm64 #1 SMP Debian 6.14.5-1~exp1+reform20250506T193533Z (2025-05-06) aarch64 GNU/Linux | 00:00 |
| vagrantc | promising :) | 00:05 |
| minute | works fine :3 tomorrow i'll also update u-boot :D i wonder if my usb hub reset thing will fix the usb-not-working-on-10%-of-boots or nah | 00:07 |
| minute | later it'll turn out that it's wonky dwc3 again that relies on a certain loglevel for timing :D | 00:07 |
| josch | ls1028a traumatization is no joke | 00:08 |
| vagrantc | apparently running 8 builds in parallel letting each build use 8 cores cranks the load up to ~60 ... but it was still pretty responsive. :) | 00:10 |
| minute | josch: yeah | 00:16 |
| josch | reform-system-rk3588-dsi.img.gz: found 1 matching artifact files and directories | 00:19 |
| josch | job succeeded | 00:19 |
| josch | (will just spend the next 15 minutes uploading the artifacts) | 00:20 |
| minute | niice | 00:20 |
| josch | minute: do you want to test the images first? | 00:20 |
| minute | josch: yeah, but can only do it tomorrow | 00:20 |
| josch | okay! | 00:21 |
| josch | then i'll leave it up to you to press the merge button :) | 00:21 |
| svp | my memory must be getting foggier than i thought, i didnt remember the good ol' i.mx8mw getting as spicy as ive been feeling it lately | 00:28 |
| svp | er, mq* | 00:28 |
| josch | svp: spicy? | 00:29 |
| svp | josch: hot | 00:29 |
| svp | i do have an idea besides repasting but it depends on whether or not i can find that side-blowing fan i have... | 00:30 |
| vagrantc | josch: the patched rk3588-mnt-reform2.dts ... did not go as smoothly as i would liked. might give it another try another time. :) | 00:38 |
| zeha | minute: could you try this on your pocket? https://source.mnt.re/reform/pocket-reform/-/merge_requests/36 | 00:39 |
| josch | vagrantc: what happened? | 00:40 |
| - robin (QUIT: Ping timeout: 276 seconds) (~robin@user/terpri) | 00:46 | |
| + bkeys (~Thunderbi@h211.16.186.173.dynamic.ip.windstream.net) | 00:49 | |
| minute | zeha: awesome, thank you very much for working on this! will install | 00:57 |
| + reform24713 (~mmmm@37.4.229.40) | 00:58 | |
| reform24713 | hello from imx8mq :) | 00:58 |
| reform24713 | Linux mmmm 6.14.5-mnt-reform-arm64 #1 SMP Debian 6.14.5-1~exp1+reform20250506T203207Z (2025-05-06) aarch64 GNU/Linux | 00:58 |
| - reform24713 (QUIT: Client Quit) (~mmmm@37.4.229.40) | 00:58 | |
| josch | seems to work :) | 00:58 |
| josch | that was with the new system image from the pipeline | 00:59 |
| - Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149.210.0.224) | 01:00 | |
| minute | josch: nice! | 01:00 |
| + Ar|stote|is (~linx@149.210.0.121) | 01:00 | |
| + robin (~robin@user/terpri) | 01:01 | |
| minute | zeha: lost usb hub of monitor for a few seconds after updating but then it came back :D | 01:04 |
| minute | zeha: and is still charging | 01:04 |
| zeha | uh ok | 01:08 |
| zeha | upgrading resets the pd state | 01:09 |
| zeha | so not totally unexpected that the usb hub also resets or so | 01:09 |
| minute | zeha: yeah totally | 01:09 |
| minute | zeha: it's kind of luxurious that this works at all | 01:09 |
| minute | "part of my computer rebooted" | 01:10 |
| zeha | hah yeah | 01:12 |
| zeha | the MR works for me with my usual charger, and with the aukey charger selfawaresoup mentioned | 01:13 |
| zeha | can try tomorrow with more chargers | 01:13 |
| zeha | but i think it should be fine for selfawaresoup to try | 01:13 |
| minute | zeha: yes, very nice | 01:14 |
| minute | i'll also test a bunch | 01:14 |
| minute | one bugfix we could do is: after sysctl update, some state in sysctl forgets that power is on, so if you accidentally hit oled->1, it'll hard reset the system | 01:16 |
| ^alex | "part of my computer rebooted", specifically the part that controls the power! | 01:16 |
| minute | haha yes | 01:16 |
| ^alex | also yeah, i think we observed the same issue on the pocket | 01:16 |
| ^alex | w/r/t forgetting exactly what was on, so saying "turn on" from the menu is a hard reset | 01:17 |
| minute | yeah | 01:17 |
| ^alex | but at least doing the upgrade itself isn't a hard reset anymore | 01:17 |
| minute | totally... i'm sure it's just some flag not being set in the function that recovers from the reset | 01:18 |
| minute | heh, with 6.14 i now have /dev/video0-4 | 01:18 |
| zeha | i think hitting 1 while on is always a hard reset | 01:19 |
| zeha | theres just no check | 01:19 |
| zeha | let me try this | 01:19 |
| zeha | hmm | 01:20 |
| minute | zeha: there's just a logic error in turn_som_power_on() | 01:23 |
| minute | zeha: the latch is enabled before setting the values | 01:23 |
| minute | i mean, "error"... i just did it that way and also with the 10ms stair for the enables... not even sure if that's great or necessary | 01:24 |
| zeha | i wonder if turn_som_power_on shouldnt just return if som_is_powered is already true | 01:25 |
| zeha | but if you know how to make turn_som_power_on safe, please do :) | 01:26 |
| minute | zeha: that would be a quick fix yeah. | 01:26 |
| zeha | i dont really understand why it only happens after a sysctl upgrade | 01:26 |
| ^alex | we might not have restored all of the state across resets | 01:27 |
| ^alex | we meant to revisit that code a while ago but the world kinda exploded :) | 01:27 |
| minute | zeha: ok, it's like this: the external latch holds the gpio values for the enables. after reset, the gpios are off, but the latch still keeps the old values going... until someone sets the latch to 1, which happens in the first step in turn_som_power_on | 01:27 |
| zeha | ahh | 01:28 |
| zeha | m( | 01:28 |
| minute | yeah. | 01:28 |
| ^alex | yeah i think we don't store all of the GPIO states, just kinda hack it when coming back up post-reset | 01:28 |
| minute | correct | 01:28 |
| ^alex | we would probably do something like store the GPIO states in the low bits of those (iirc) watchdog registers | 01:29 |
| ^alex | so that a reset can restore them correctly | 01:30 |
| minute | interesting. but we should also know the gpio states, if i'm not mistaken | 01:30 |
| minute | they're simply those that result at the end of turn_som_power_on | 01:30 |
| ^alex | oh! well then | 01:30 |
| minute | another fix would be to not latch in the beginning of the function if som_is_powered | 01:31 |
| minute | (but latch at the end, for a moment) | 01:31 |
| minute | anyway, i should be sleeping :D can look into this later | 01:31 |
| ^alex | go sleep! | 01:31 |
| zeha | with the stair in, i think it doesn't really make sense to do the turn-on dance when its already supposed to be turned on | 01:31 |
| zeha | but yeah, tomorrow | 01:32 |
| minute | (also, i wonder how to actually use all those video decoders we have now? mpv doesn't seem to like them out of the box) | 01:32 |
| minute | n8n8 | 01:32 |
| - mjw (QUIT: Ping timeout: 248 seconds) (~mjw@gnu.wildebeest.org) | 01:46 | |
| - vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 01:54 | |
| - robin (QUIT: Ping timeout: 272 seconds) (~robin@user/terpri) | 02:03 | |
| + robin (~robin@user/terpri) | 02:08 | |
| - aloo_shu (QUIT: Ping timeout: 244 seconds) (~aloo_shu@90.166.99.224) | 02:13 | |
| - paperManu (QUIT: Ping timeout: 252 seconds) (~paperManu@172.93.30.55) | 03:47 | |
| + aloo_shu (~aloo_shu@90.166.99.224) | 04:57 | |
| + chomwitt (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 06:12 | |
| - chomwitt (QUIT: Ping timeout: 268 seconds) (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 07:00 | |
| - jacobk (QUIT: Ping timeout: 276 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 07:11 | |
| + jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 07:12 | |
| - jnerula (QUIT: Ping timeout: 248 seconds) (~jnerula@li1009-93.members.linode.com) | 07:21 | |
| - elektron (QUIT: Ping timeout: 272 seconds) (~elektron@apoc.halo.nu) | 07:21 | |
| + elektron (~elektron@apoc.halo.nu) | 07:22 | |
| + jnerula (~jnerula@li1009-93.members.linode.com) | 07:22 | |
| - shdw (QUIT: Ping timeout: 248 seconds) (~shdw@static.218.156.216.95.clients.your-server.de) | 07:25 | |
| + shdw (~shdw@static.218.156.216.95.clients.your-server.de) | 07:25 | |
| - mhoye (QUIT: Ping timeout: 272 seconds) (~mhoye@li319-32.members.linode.com) | 07:27 | |
| + mhoye (~mhoye@li319-32.members.linode.com) | 07:27 | |
| - Ar|stote|is (QUIT: Ping timeout: 272 seconds) (~linx@149.210.0.121) | 07:30 | |
| + Ar|stote|is (~linx@149.210.0.121) | 07:31 | |
| + chomwitt (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 08:23 | |
| zeha | tried a few more chargers and it seems solid | 11:03 |
| - jacobk (QUIT: Ping timeout: 248 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 11:04 | |
| + jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 11:04 | |
| zeha | i think i'm for the first time conciously seeing what minute meant with 'the charger chip seems to hang sometimes' | 11:06 |
| minute | zeha: how did you trigger it? the cases i know of happen if the rp2040 is reset/flashed at the wrong moment, presumably during some comms with the charger or monitor | 11:07 |
| zeha | unplugged a usb-c charger | 11:08 |
| - manis (QUIT: Ping timeout: 272 seconds) (01a66df340@185.72.67.185) | 11:14 | |
| minute | zeha: oh weird | 11:21 |
| minute | zeha: with your new fw it does charge here at home on all 3 chargers i have (ravpower, dell monitor, apple phone charger) | 11:24 |
| zeha | can you try a bit of unplugging/replugging, to see if its now more likely to hang? | 11:24 |
| zeha | :\ | 11:24 |
| zeha | super weird | 11:38 |
| - chomwitt (QUIT: Ping timeout: 252 seconds) (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 11:54 | |
| + andreas-e (~Andreas@2001:861:c4:f2f0::c64) | 11:56 | |
| + mjw (~mjw@gnu.wildebeest.org) | 12:34 | |
| + paperManu (~paperManu@172.93.30.55) | 12:44 | |
| + chomwitt (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 12:44 | |
| + gustav28 (~gustav@c-78-82-38-134.bbcust.telenor.se) | 13:02 | |
| - Ar|stote|is (QUIT: Ping timeout: 272 seconds) (~linx@149.210.0.121) | 13:09 | |
| + Ar|stote|is (~linx@149.210.3.247) | 13:13 | |
| - mjw (QUIT: Ping timeout: 244 seconds) (~mjw@gnu.wildebeest.org) | 14:21 | |
| - sterni (QUIT: ) (~quassel@user/sterni) | 14:27 | |
| + sterni (~quassel@user/sterni) | 14:28 | |
| * Guest8720 -> mjw | 14:35 | |
| wickedshell | zeha, minute is this the PR for the respect charger power limit? I can flash it here and test my various chargers if you need wider testing | 17:17 |
| zeha | https://source.mnt.re/reform/pocket-reform/-/merge_requests/36 | 17:18 |
| zeha | ^ this | 17:18 |
| wickedshell | zeha: yup that's the one I was thinking of. Are you looking for more testing of it/is it ready for that? | 17:20 |
| zeha | yeah, please test | 17:21 |
| wickedshell | wilco | 17:24 |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-137-170.tukw.qwest.net) | 17:30 | |
| wickedshell | Okay, I've done this before, but I've apparently forgotten things in the last 3 months, or not awake enough yet. update-sysctl-firmware.sh can't find the rp2040, or thinks more then one is found. Any pointers? | 17:33 |
| wickedshell | huh, looks like it's a usb devid mysmatch. I have 1209:6d07 which says it's the generic pocket reform system controller, but the script is looking for a different idea. Might just change the script to look for the devid it currently is? | 17:36 |
| + colinsane (~colinunin@97-113-137-170.tukw.qwest.net) | 17:37 | |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 17:45 | |
| wickedshell | Okay, I'm a bit stuck, can't seem to get the system controller into bootloader mode currently it's running PREF1SYSR12020250118 | 17:46 |
| zeha | i guess your sysctl is new enough for fwupd | 17:56 |
| zeha | in that case you can try: sudo fwupdtool install --allow-reinstall --allow-older ./sysctl.cab | 17:56 |
| zeha | if that doesnt work, probably this should work: sudo reform-mcu-tool bootsel pocket-sysctl-1.0 ; sudo picotool load -f sysctl.uf2 ; sudo picotool reboot | 17:57 |
| wickedshell | Huh, never used fwupd before. Annoyingly apparently last round of updates broke apt. I'll go with the mcu tool for now and figure out apt later | 18:01 |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-137-170.tukw.qwest.net) | 18:03 | |
| josch | wickedshell: do you have some output that apt give you? Maybe it's easy to fix | 18:06 |
| wickedshell | josch: it was complaining about a read only filesystem inside of the apt stuff (something with a path of partial) I went for easy mode, rebooted (not expecting it to work) and if uh isn't a problem anymore | 18:08 |
| + arminweigl_ (~arminweig@sourcehut/user/arminweigl) | 18:09 | |
| - arminweigl (QUIT: Ping timeout: 265 seconds) (~arminweig@sourcehut/user/arminweigl) | 18:09 | |
| * arminweigl_ -> arminweigl | 18:09 | |
| zeha | readonly fs might have been triggered by the fw update attempt | 18:10 |
| wickedshell | zeha, interesting. I didn't have fwupdtoool available, so not sure what flagged it into that. | 18:11 |
| zeha | some of the update shell scripts do it, iirc | 18:11 |
| wickedshell | After apt worked fwupdtool was used and worked to load it. After using fwupdtool though I will note I was getting weird key repeats off the keyboard/input lag. Not a problem after a subsequent reboot | 18:12 |
| josch | zeha: if the firmware update script can leave the filesystem read-only then an exit trap is missing which reverts the system state in case of an error? | 18:15 |
| zeha | josch: iirc you're supposed to reboot afterwards | 18:15 |
| zeha | https://source.mnt.re/reform/reform-factory/-/blob/main/pocket-reform/update-sysctl-firmware.sh?ref_type=heads#L131 | 18:16 |
| zeha | dunno how one should recover from this | 18:16 |
| josch | i see | 18:17 |
| wickedshell | zeha: steam deck, pine power, dell laptop charger, anker 6 in 1 all work | 18:18 |
| josch | at least that should not be a problem anymore after the firmware is on that revision as afterwards fwupd can be used without this drawback, right? | 18:18 |
| zeha | josch: yes | 18:18 |
| zeha | wickedshell: great! | 18:18 |
| wickedshell | A USB-C battery pack that can only do 5V3A, 9V2A, 12V1.5A does not work | 18:18 |
| zeha | hmm. 12V1.5A should work in theory | 18:19 |
| zeha | can you capture the debug output on /dev/ttyACM0? | 18:19 |
| wickedshell | It worked with the firmware that it shipped from the factory to me with way back when, but didn't after any of the USB-C rework stuff. (Although that making steam deck chargers work was much more valuable then the battery bank) | 18:19 |
| zeha | i guess a battery pack might do some "interesting" stuff and i don't have one for testing. so if you could get the debug output that might be helpful | 18:20 |
| wickedshell | zeha what's an easy way to capture stuff from a serial port for sharing? My normal version of just connect screen isn't exactly friendly for sharing | 18:21 |
| josch | minute: uuuh you merged https://source.mnt.re/reform/reform-system-image/-/merge_requests/124 *partyemoji* | 18:22 |
| josch | wait, i got this: 🎉 | 18:22 |
| wickedshell | oh god. It worked after replugging it enough times :P | 18:22 |
| zeha | wickedshell: could you try minicom -C capture.log -D /dev/ttyACM0 | 18:22 |
| zeha | ugh | 18:23 |
| wickedshell | First 4 times didn't work, the fifth magically did | 18:23 |
| zeha | then i'm even more interested in debug output :D | 18:23 |
| potatoespotatoes | heyo! I'm setting up the rk3588+guix image and I'm having a bit of trouble detecting the wifi card (the AsiaRF Wi-Fi card with MT7612U chipset). Is that supposed to work out-of-the-box on 6.12 or do I need mediatek drivers? | 18:25 |
| potatoespotatoes | The other person who was loud about getting this working seemed to indicate that the former was possible, but no dice for me : ( | 18:26 |
| potatoespotatoes | *getting guix+mntreform working | 18:26 |
| josch | potatoespotatoes: in debian at least you need the non-free firmware-mediatek package | 18:26 |
| zeha | driver should be in the stock kernel though | 18:27 |
| zeha | mt76x2u / mt76x02_usb | 18:27 |
| potatoespotatoes | if it's in stock kernel, do I just need to add this to the list of modules loaded at boot? Where can I even find that list (I've tried looking) | 18:28 |
| wickedshell | zeha I blame this battery pack as being weird. I now can't get the exact message I saw with screen before. But it also appears to releate to how I interact with the battery pack. (IE don't touch anything with the display off, plug it in and it charges me, if I press the button on it first it tells me to get lost) | 18:29 |
| zeha | potatoespotatoes: i took it from my working pocket | 18:32 |
| zeha | wickedshell: :/ | 18:32 |
| wickedshell | zeha: https://pub.microbin.eu/upload/snail-dog-goat | 18:32 |
| potatoespotatoes | oh! are you running guix? that would be very cool | 18:32 |
| wickedshell | I wouldn't obsess about the battery pack too much, it was a free unexpected item in a box from scamazon, if it works it's kinda cool, if not I'm not upset :) | 18:33 |
| zeha | potatoespotatoes: no, that was from a debian host | 18:34 |
| potatoespotatoes | zeha: ah, okay. I'm always curious (many hands make light work : )) | 18:35 |
| zeha | wickedshell: looks like there's some baudrate issue with this log | 18:36 |
| zeha | wickedshell: can you try again and add -b 115200? | 18:36 |
| wickedshell | zeha I'll admit to having never used minicom and didn't spec the baudrate, I did when I used screen | 18:36 |
| wickedshell | Will do | 18:36 |
| zeha | sorry | 18:36 |
| potatoespotatoes | I think it should be in this mediatek-firmware package from the nonguix repo, so I'm crossing my fingers and I'll probably add a few more wifi drivers in case other users are using different chipsets | 18:37 |
| wickedshell | zeha: nah, that's on me | 18:37 |
| wickedshell | zeha: https://pub.microbin.eu/upload/snail-duck-whale | 18:39 |
| zeha | still looks kinda borked, but ok | 18:40 |
| wickedshell | zeha honestly looks like that in screen locally as well | 18:41 |
| zeha | # [pd] PD_STATE_ATTACHED_SNK timeout while handshaking, sending soft reset | 18:42 |
| zeha | # [pd] PD_STATE_ATTACHED_SNK timeout while handshaking, reset | 18:42 |
| minute | josch: i just flashed the rk3588-reform2-dsi image from here to sd card and booted it in the device, which works fine, and then i did reform-migrate to try to install to emmc. i still got a "W:" about the machine not being supported. is that still expected? https://source.mnt.re/reform/reform-system-image/-/jobs/9789/artifacts/browse | 18:42 |
| zeha | not that great behaviour | 18:42 |
| zeha | wickedshell: so the # should always be at the start of a line. dunno why that doesnt work on your machine | 18:42 |
| wickedshell | The one that works at the end is what happens when I plug it in without having turned the device screen on with the button (who knows what modes that toggles through) | 18:43 |
| josch | minute: what was the warning message? | 18:43 |
| josch | minute: the machine.conf for rk3588 has EMMC_BOOT=warn | 18:43 |
| josch | minute: should this not be the case anymore? | 18:44 |
| wickedshell | zeha that's a USB CDC device right? So we really shouldn't lose anything... | 18:44 |
| minute | josch: i have to do it again to see. ah, the warning was "unsupported machine" or "machine not supported" | 18:44 |
| josch | was it: E: writing to eMMC not supported on | 18:44 |
| zeha | wickedshell: yeah | 18:45 |
| josch | ah no wait, it was: | 18:45 |
| josch | W: Using eMMC on $(cat /proc/device-tree/model) is not without risk. | 18:45 |
| zeha | maybe the minicom defaults are wrong or something | 18:45 |
| josch | there is a bit more text informing about the risk and then you can press "y", yes? | 18:45 |
| wickedshell | zeha: yeah, except that screen shows me the same thing, which is surprising, unless minicom has confused the rp2040? | 18:46 |
| zeha | ah hm | 18:46 |
| wickedshell | Any important changes to the pico SDK since january? I didn't pull any updates there first | 18:46 |
| minute | josch: "W: unsupported machine: MNT Reform 2 with RCORE-DSI RK3588 Module" | 18:47 |
| josch | ooooh shoot | 18:47 |
| josch | that's the initramfs | 18:47 |
| minute | i just reran: sudo reform-boot-config --emmc /dev/mmcblk0p2 | 18:47 |
| josch | okay, at least it doesn't exit 1 or anything | 18:47 |
| minute | so it outputs that after > update-initramfs: Generating /boot/initrd.img-6.14.5-mnt-reform-arm64 | 18:47 |
| josch | good, then i know where to fix this | 18:47 |
| josch | one sec... | 18:47 |
| minute | and some a bit weird sounding messages of "WARNING: Unknown X keysym "dead_greek"" | 18:47 |
| minute | fwiw, the system doesn't manage to boot from emmc after this. only from sd | 18:48 |
| zeha | dont hate the dead greeks! | 18:48 |
| josch | minute: bin/reform-hw-setup also does not do the right thing so init_rk3588 and init_wm8960 are never run -- can you confirm? | 18:49 |
| minute | josch: i think i saw a systemd error about this yeah | 18:49 |
| wickedshell | zeha: what version of pico-sdk is expected? | 18:49 |
| zeha | i'm compiling with pico-sdk-source 2.1.1-1 | 18:50 |
| minute | i'm testing the a311d reform2 image and the display is coming up fine, but it's rotated :D my guess is that this bananapi cm4 has the pocket uboot on emmc | 18:51 |
| zeha | :D | 18:51 |
| minute | yeah, sway isn't rotated | 18:52 |
| josch | rotated? i thought we are talking about classic reform with rk3588 | 18:53 |
| josch | next round of fixes: https://source.mnt.re/reform/reform-tools/-/merge_requests/119 | 18:53 |
| minute | josch: yeah i'm doing multiple tests on multiple machines in parallel to not have waiting times | 18:53 |
| josch | minute: but the pocket reform has nothing to do with dsi, right? | 18:53 |
| minute | ah yes, did reform-flash-uboot emmc on the a311d test reform and now the console is rotated correctly again. | 18:53 |
| minute | josch: i don't recall mentioning pocket! | 18:54 |
| minute | josch: ah i did | 18:54 |
| josch | i also thought only pocket had the rotated display | 18:54 |
| minute | josch: it's just that i have random test modules flying around. i took one that must have been used in a pocket before | 18:54 |
| josch | ah okay! :D | 18:54 |
| minute | so it's emmc uboot was used and made the console rotated. | 18:54 |
| minute | josch: looks good, should i merge or will you? | 18:55 |
| josch | if this is the last fix, i'll cut a new reform-tools release | 18:55 |
| josch | or should we go via another reform-debian-packages patch first? | 18:55 |
| josch | (the latter will be faster as it does not have to wait for Debian) | 18:56 |
| minute | josch: ah, yeah i need this working tonight, or i'll have to do local patching on the machines | 18:56 |
| josch | good, then lets patch reform-debian-packages now | 18:56 |
| josch | one sec... | 18:56 |
| minute | (because tomorrow is feiertag i only have today to finish prep for the classic reform2 rk3588 installations that will happen on friday) | 18:56 |
| minute | josch: i can also pretest it by applying your diff on the test machine | 18:57 |
| josch | feel free to do that | 18:57 |
| minute | (btw a311d classic is fine with latest system) | 18:57 |
| wickedshell | zeha: okay I'm on a much older one, I just have the 1.5.1 since that's what install-fw-dependencies.sh gave me | 18:58 |
| wickedshell | So that could easily be related | 18:58 |
| zeha | you could try the built fw from https://source.mnt.re/zeha/pocket-reform/-/jobs/9790/artifacts/download?file_type=archive | 18:59 |
| zeha | i think that should also use a current pico sdk | 18:59 |
| zeha | actually i'm somewhat surprised it compiles with 1.5 | 18:59 |
| minute | ah i guess i need to patch the files on the emmc rootfs... | 19:00 |
| wickedshell | zeha: to be fair I had to make build.sh look at where install-fw-dependencies dropped the sdk. But yeah, looks like the fw dep script needs an update | 19:00 |
| wickedshell | I'm going to just update the SDK here | 19:01 |
| zeha | you can install pico-sdk-source from debian testing | 19:01 |
| minute | josch: ah, this fix doesn't look like its critical for the function maybe? because that case doesn't do anything? | 19:01 |
| zeha | then build.sh should work as is | 19:01 |
| minute | josch: but i can confirm the warning is gone | 19:01 |
| josch | minute: the initramfs-tools change indeed is harmless | 19:02 |
| josch | minute: but the reform-hw-setup problem should not be harmless as no hardware setup is happening | 19:02 |
| minute | josch: got it | 19:03 |
| minute | then i need to debug in depth why this system isn't booting from emmc | 19:04 |
| josch | i pushed the fix directly to main of reform-debian-packages | 19:04 |
| josch | build_patched_arm64 job succeeded | 19:05 |
| minute | nice | 19:08 |
| wickedshell | zeha: okay fixed it by going to newer SDK version | 19:09 |
| josch | minute: re booting emmc: consider that i might've screwed up my changes to the linux device tree to make it compatible with u-boot. Maybe I have removed too much. | 19:11 |
| josch | (if you are talking about the dsi dtb that is) | 19:11 |
| minute | josch: ah hmm yeah | 19:11 |
| minute | josch: it works on sd card though | 19:13 |
| josch | i'm not going to pretend that i know what i'm doing :D | 19:13 |
| zeha | wickedshell: oh wow, good to know | 19:13 |
| minute | josch: debugging has commenced | 19:16 |
| josch | i hope it's not too crazy! | 19:34 |
| minute | weird, now that i connected a serial debugger, it boots from emmc ;S | 19:37 |
| josch | ls1028a déjà vu intensifies | 19:41 |
| minute | ah. different module, different story | 19:41 |
| minute | mmc_load_image_raw_sector: mmc block read error | 19:42 |
| minute | SPL: failed to boot from all boot devices | 19:42 |
| minute | ### ERROR ### Please RESET the board ### | 19:42 |
| minute | power cycled, now it works | 19:42 |
| josch | \o/ | 19:42 |
| minute | so it seems emmc support in uboot for rk3588 is wonky | 19:42 |
| minute | ;/ | 19:42 |
| minute | not the first time that uboot emmc support is wonky... | 19:43 |
| minute | maybe we need to lower the clock in the uboot dts... | 19:43 |
| minute | at least i can say that the whole reform-migrate to emmc process works now | 19:44 |
| josch | alternatively, you could try reform-flash-rescue which downloads and flashes the latest image to emmc | 19:45 |
| minute | ah yeah, i always mega forget about this... maybe because there is no more "rescue" per se | 19:45 |
| minute | does that use bmaptool btw? | 19:46 |
| josch | if it's available then yes | 19:47 |
| josch | it falls back to dd if it's not installed | 19:47 |
| josch | (checks via command -v) | 19:47 |
| minute | neat | 19:47 |
| josch | and with Debian Bookworm images from reform.debian.net it also checks the GPG signature of the image :) | 19:47 |
| minute | interesting, the dts files for reform2 and reform2-dsi have different mmc freqs | 19:48 |
| minute | (in uboot) | 19:48 |
| minute | so i already lowered the freq for linux once but not for uboot... but the lowering is already in the reform2-dsi dts i'm testing with... meh | 19:49 |
| minute | maybe uboot works better @ 200mhz mmc? :D | 19:50 |
| josch | (reform-debian-packages pipeline succeded) | 19:50 |
| + manis (01a66df340@185.72.67.185) | 19:55 | |
| minute | nice | 19:59 |
| minute | looks like it was already deployed? | 20:01 |
| minute | ok, will now try to install gnome on this desktop reform system (which now miraculously boots from emmc) | 20:10 |
| minute | sudo systemctl disable greetd; sudo apt install gnome | 20:10 |
| minute | that's all that's needed to get it running | 20:24 |
| minute | interesting, gnome-shell-extension-dashtodock (debian package) is not recognized by gnome as an extension... or possibly i have to relogin | 20:33 |
| minute | ok, i need to remove this "DEBUG: ti_sn65dsi86_suspend skipped." spam from our driver | 20:36 |
| minute | pushed | 20:45 |
| josch | i can confirm that disabling greetd and installing gnome is all that's needed -- that's also how i installed it here on a minimal system image on imx8mq | 21:14 |
| - sigrid (QUIT: Quit: Lost terminal) (~sigrid@ftrv.se) | 21:49 | |
| + sigrid (~sigrid@ftrv.se) | 21:50 | |
| - jacobk (QUIT: Ping timeout: 276 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 21:58 | |
| + jacobk (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 21:58 | |
| - gustav28 (QUIT: Quit: Quit) (~gustav@c-78-82-38-134.bbcust.telenor.se) | 22:15 | |
| - jacobk (QUIT: Ping timeout: 248 seconds) (~quassel@47-186-65-73.dlls.tx.frontiernet.net) | 22:22 | |
| josch | minute: is everything ready? should i upload a new reform-tools version? | 22:25 |
| minute | josch: the new ping doesn't work :D operation not permitted | 22:29 |
| - chomwitt (QUIT: Ping timeout: 260 seconds) (~chomwitt@2a02:85f:9ac9:6600:1ac0:4dff:fedb:a3f1) | 22:33 | |
| minute | josch: with reform-tools everything seems to be fine yeah | 22:33 |
| - andreas-e (QUIT: Quit: Leaving) (~Andreas@2001:861:c4:f2f0::c64) | 22:35 | |
| josch | minute: what do you get when you run this: getcap /usr/bin/ping | 22:36 |
| josch | and do you have linux-sysctl-defaults installed? | 22:41 |
| minute | josch: sorry, can't do it atm, need to drive home | 22:43 |
| josch | okay! | 22:45 |
| josch | minute: I was able to reproduce the problem on the 6.14 system image on imx8mq and installing linux-sysctl-defaults is indeed the fix | 22:48 |
| josch | i'll just add it as a depends to reform-desktop-minimal | 22:49 |
| minute | josch: nice, thanks | 22:57 |
| josch | minute: each pipeline run of reform-system-image now creates nearly 14 GB of artifacts. Maybe you want to re-evaluate the concept of a unified system image? It would only exclude those platforms with ancient u-boot (never updated imx8mq) and platforms where you didn't flash u-boot with dtbpath set (original imx8mplus pocket) | 23:17 |
| minute | josch: sounds good! | 23:35 |
| + mark_ (~mjw@gnu.wildebeest.org) | 23:36 | |
| * mjw -> Guest5299 | 23:36 | |
| - Guest5299 (QUIT: Killed (tantalum.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 23:36 | |
| * mark_ -> mjw | 23:36 | |
| + Guest5299 (~mjw@2001:1c06:2486:a800:7602:5eff:dc71:a72c) | 23:37 | |
| josch | minute: maybe the pipeline can have a setting which allows to build all images every once in a while but have the unified non-device-specific image the default? | 23:37 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!