| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 00:26 | |
| ^alex | sdk 2 wants picotool 2, but picotool 2 refuses to find libusb D: | 00:28 |
|---|---|---|
| - jacobk (QUIT: Ping timeout: 276 seconds) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 00:40 | |
| + jacobk (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 00:41 | |
| - vagrantc (QUIT: Ping timeout: 276 seconds) (~vagrant@2600:3c01:e000:21:7:77:0:50) | 00:43 | |
| - jacobk (QUIT: Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 01:54 | |
| josch | slightly related, packaging picotool and picosdk in Debian is currently blocked by picolibc failing to build in unstable for over a week already: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077452 | 01:56 |
| + bkeys1 (~Thunderbi@45.134.140.153) | 02:51 | |
| - bkeys (QUIT: Ping timeout: 260 seconds) (~Thunderbi@45.134.140.153) | 02:52 | |
| * bkeys1 -> bkeys | 02:52 | |
| + chrcav (~chrcav@user/chrcav) | 03:30 | |
| - nsc (QUIT: Ping timeout: 244 seconds) (~nicolas@i5C74DD26.versanet.de) | 03:34 | |
| + nsc (~nicolas@i5C74DE92.versanet.de) | 03:36 | |
| - xktr (QUIT: Quit: leaving) (~xktr@user/xktr) | 03:56 | |
| + xktr (~xktr@user/xktr) | 04:19 | |
| - bkeys (QUIT: Ping timeout: 265 seconds) (~Thunderbi@45.134.140.153) | 04:39 | |
| ^alex | ohhhh the picotool that the sdk offers to build _specifically_ doesn't build with libusb. i guess because the sdk is using it for the elf2uf2 capacity in picotool2 | 05:20 |
| ^alex | (upside down face emoji) | 05:20 |
| - Gooberpatrol66 (QUIT: Ping timeout: 264 seconds) (~Gooberpat@user/gooberpatrol66) | 06:03 | |
| - colinsane (QUIT: Ping timeout: 255 seconds) (~colinunin@97-113-150-69.tukw.qwest.net) | 06:24 | |
| + _justin_kelly7 (~justinkel@user/justin-kelly/x-6011154) | 07:00 | |
| - _justin_kelly (QUIT: Quit: The Lounge - https://thelounge.chat) (~justinkel@user/justin-kelly/x-6011154) | 07:18 | |
| * _justin_kelly7 -> _justin_kelly | 07:18 | |
| + Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 07:29 | |
| + colinsane (~colinunin@97-113-70-61.tukw.qwest.net) | 08:17 | |
| josch | minute: re "sorting is hard": maybe the patches should all be prefixed with a running counter of the form %04d as it is used by git-format-patch and in case of linux/patches6.10/rk3588-mnt-reform2/, have the first 99 reserved for collabora patches and have your patches start at 100 which makes them easily distinguishable | 10:14 |
| josch | or even have a linux/patches6.10/rk3588-0001-collabora directory and another linux/patches6.10/rk3588-0002-mnt directory | 10:15 |
| josch | because naming the directory "reform2" is not quite fitting as those patches apply to pocket and next as well and because it avoids having a magic "offset" to distinguish your patches from those by collabora | 10:15 |
| minute | josch: yeah... | 10:17 |
| minute | upgrading my rk3588 reform to 6.10.3 | 11:04 |
| josch | minute: you switched the reform-handbook default branch from master to main (thank you!) but all the merge requests are still against master | 11:05 |
| josch | this means that the MR of mine to reduce the size which you set to auto-merge (thanks!) got merged into master and not the new default branch main | 11:05 |
| minute | argh | 11:05 |
| minute | yeah there were some issues preventing me from removing master in gitlab | 11:05 |
| josch | sorry | 11:06 |
| josch | i forgot that changing default branches does not automatically change the target branch of the open MRs | 11:06 |
| minute | hmm, 6.10.3 kills display on my rk3588 reform, will debug a bit later | 11:14 |
| josch | it's always something... | 11:14 |
| minute | yeah :D | 11:15 |
| josch | minute: note, that i dropped two of your hdmi rk3588 patches because as far as i could tell they were upstreamed | 11:15 |
| josch | minute: in case you feel comfortable with that you can also (temporarily) give my account sufficient privileges for the reform-handbook repo and i can clean up the mess that my recent request of changing the default branch caused | 11:20 |
| amospalla | minute: what do you mean with "6.10 kills display" ? | 11:25 |
| amospalla | With 6.10 Pocket (with stock motherboard) has display problems too (altough I recently changed the display so I was unsure what the cause was). | 11:26 |
| amospalla | (mine either boots, or Kernel prints only 3 lines and then goes blank, altough ocassionaly has done other things like kernel complaining and finally hang) | 11:29 |
| minute | josch: ok, i will do that! | 11:34 |
| minute | amospalla: that's an unrelated issue then as rk3588 has a different patch stack/drivers | 11:35 |
| amospalla | yeah, that must be, if it was related I would not be alone with this. | 11:35 |
| minute | i need to do some more 6.10 testing today on imx8mp pocket | 11:36 |
| amospalla | It must be me not connecting the ribbon correctly, I suspect. | 11:36 |
| minute | the cable is fiddly yeah | 11:38 |
| Zaba | yeah at least with some of those FFC connectors it can be pretty hard to tell if the cable is fully inserted | 11:40 |
| josch | minute: thank you, i lack privileges to change/delete branch properties but i was able to change the target branch of all MRs to "main" and put the size reduction commits into "main" as well | 11:43 |
| josch | now re-running reform-debian-packages... | 11:43 |
| - buckket (QUIT: Quit: buckket) (~buckket@vps.buckket.org) | 12:12 | |
| + buckket (~buckket@vps.buckket.org) | 12:13 | |
| minute | josch: i made you "owner" now, does that help? | 12:57 |
| josch | yes! :D | 12:59 |
| minute | ok phew :3 | 13:00 |
| minute | now testing 6.10.3+dsi build on rk3588 pocket | 13:02 |
| minute | ah :D W: unsupported machine: MNT Reform Next with RCORE RK3588 Module | 13:02 |
| josch | reform-handbook is all set up now :) | 13:03 |
| josch | hah! | 13:03 |
| josch | okay, sec... | 13:03 |
| josch | shall i add the pocket there as well now that i'm at it? | 13:04 |
| josch | wait, that's just a warning | 13:04 |
| josch | it used to be fatal but no longer | 13:04 |
| josch | but lets add it nevertheless | 13:05 |
| minute | yeah, it installed the wrong dtb now (the next one) | 13:05 |
| minute | (manually corrected that in /boot) | 13:05 |
| josch | then it is missing in flash-kernel if the dtb is wrong? | 13:06 |
| minute | ah sorry, probably an error in my dts | 13:07 |
| minute | ohh, it freezes... maybe i forgot to disable vop_mmu | 13:07 |
| josch | it's missing in flash-kernel | 13:07 |
| josch | only reform 2 and next are in the flask-kernel patch so far, not the pocket | 13:07 |
| minute | josch: yes, but also in the pocket dts i wrote Next by accident | 13:07 |
| minute | (i mean, forgot to change to pocket) | 13:07 |
| josch | right | 13:08 |
| josch | i put rockchip/rk3588-mnt-pocket-reform.dtb into the flash-kernel patch now | 13:08 |
| minute | thanks | 13:08 |
| josch | minute: anything else you want to see in reform-tools? otherwise i do a new release right now | 13:09 |
| minute | josch: not right now, release sounds good | 13:09 |
| minute | hmmmm, unfortunate that 6.10 doesn't work on the pocket rk3588 | 13:10 |
| minute | hmm > dw_hdmi_qp | 13:10 |
| minute | i think that's new, maybe that's what replaced partly the hdmi patches? | 13:11 |
| minute | back to the drawing board | 13:12 |
| josch | patch 0101-drm-panthor-Fix-IO-page-mmap-for-32-bit-userspace-on-64-bit-kernel.patch is the one i dropped | 13:12 |
| minute | ohh panthor, that's unrelated to hdmi | 13:13 |
| minute | ok, my old monolithic kernel works with the dtb from reform-debian-packages, so the lockup is driver related | 13:13 |
| minute | lets see if i have a similar lockup or what's up on my reform with rk3588 with the 6.10.3 kernel | 13:14 |
| minute | (i say old but that mono kernel is actually 6.11) | 13:14 |
| minute | hmm strange, no further output after [ 1.615424] Run /init as init process | 13:21 |
| minute | ah, still console=tty1 in extlinux.conf | 13:22 |
| ch | i was -just- gonna write "console=" correct? :) | 13:22 |
| pandora | i just noticed that my battery status in the swaybar doesn't update anymore after the last few updates (apt update/upgrade). Is that something known? | 13:22 |
| minute | pandora: on reform or pocket?' | 13:24 |
| pandora | 13:24 | |
| josch | pandora: yes, there is a forum thread about it. Summary: waybar changed something which reveals a "bug" in the lpc firmware | 13:24 |
| minute | yeah, we need to soon release pocket lpc firmware update | 13:24 |
| minute | which is in beta now | 13:24 |
| minute | > Timed out for waiting the udev queue being empty. | 13:25 |
| minute | something is very broken now @ rk3588 .__. | 13:25 |
| josch | ch: yes, last october is when i learned that the last console= is the one that matters :) https://source.mnt.re/reform/reform-tools/-/commit/d9ee804f63720c550238c6790f80f0a0019c5cca | 13:25 |
| minute | > Begin: Loading essential drivers ... | 13:25 |
| minute | but no further output. i still can press return | 13:25 |
| pandora | ah thx ... gonna check the forum | 13:25 |
| josch | minute: being stuck at that point reminds me of this: file:///home/josch/tmp/mntre.com/reform-irc-logs/2024-07-11.log.html#t01:46:45 | 13:26 |
| josch | pandora: https://community.mnt.re/t/after-apt-upgrade-today-battery-in-waybar-stuck-at-100/2299/20 | 13:27 |
| minute | josch: huh, weird | 13:28 |
| minute | maybe some new essential driver is missing in initrd | 13:28 |
| minute | i will try to break into initramfs shell | 13:28 |
| minute | aha | 13:30 |
| minute | > [ 3.285210] Kernel panic - not syncing: Asynchronous SError Interrupt | 13:30 |
| minute | in > [ 3.285291] dw_hdmi_qp_update_power+0x424/0x698 [dw_hdmi_qp] | 13:30 |
| minute | so it is related to hdmi driver changes | 13:32 |
| minute | josch: maybe i was dreaming but didn't you say you dropped 2 hdmi related patches? | 13:38 |
| josch | yes, i did say it was 2 | 13:38 |
| josch | but i checked and it seems to have been just one | 13:38 |
| minute | josch: ah, and it was the 32 bit panthor fix? | 13:39 |
| josch | yes | 13:39 |
| minute | ok, then i need to look what changed in general about the hdmi driver, and where this qp driver comes from | 13:39 |
| josch | as usual the collabora | 13:39 |
| josch | patch stack changed everything | 13:39 |
| josch | lots of stuff got removed as well as added | 13:40 |
| minute | aha, so i need to dig in their kernel | 13:40 |
| minute | do you know which linux version they based it on? | 13:40 |
| josch | i didn't rebase their things, i took what they publish for 6.10 | 13:40 |
| josch | they have one branch per kernel release and every time there is a new release, i throw away their old patch stack and replace it by the new one | 13:41 |
| minute | aha hmhm https://lore.kernel.org/all/20240807-b4-rk3588-bridge-upstream-v3-0-60d6bab0dc7c@collabora.com/ | 13:41 |
| minute | josch: ahhh i see | 13:41 |
| minute | the new driver has > compatible = "rockchip,rk3588-dw-hdmi-qp", | 13:44 |
| minute | but if i'm not mistaken our rk3588s.dtsi has compatible = "rockchip,rk3588-dw-hdmi"; | 13:45 |
| minute | yeah i think i see what the problem could be | 13:47 |
| minute | in the current 6.11 branch, rk3588s.dtsi is just 2 lines and includes a new rk3588-base.dtsi | 13:48 |
| minute | and in that base dtsi you can see that the hdmi driver has changed to the -qp variant https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/blob/rk3588/arch/arm64/boot/dts/rockchip/rk3588-base.dtsi?ref_type=heads#L1405 | 13:48 |
| minute | but they forgot to update this in the 6.10 branch's rk3588s.dtsi | 13:48 |
| minute | huh, but wait, the qp driver isn't in here https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/tree/rk3588-v6.10/drivers/gpu/drm/rockchip?ref_type=heads | 13:50 |
| minute | ah, it is in the synopsys folder | 13:51 |
| minute | hmm ok the rockchip hdmi driver in the 6.10 stack still has a big if/else and uses compatible = "rockchip,rk3588-dw-hdmi", | 13:53 |
| minute | aha! disabling hdmi1 makes it spring to life, so i probably have to adjust something about hdmi1 | 13:57 |
| minute | ok, my reform boots now with 6.10.3, that's a relief | 13:58 |
| minute | ok, fixing up hdmi1 node | 14:00 |
| Twodisbetter | minute: excellent glad things are working out | 14:00 |
| minute | i wonder why they didn't also just make hdmi1 compatible... | 14:10 |
| minute | argh, they removed all functionality for hdmi1 from dw_hdmi-rockchip.c | 14:19 |
| minute | so this is a regression | 14:19 |
| minute | josch: i'm not yet sure how but we have a big issue now with the collabora patchstack starting with 6.10, they just removed all support for the second hdmi | 14:24 |
| josch | probably time to contact them? | 14:24 |
| josch | maybe there is some deeper context | 14:24 |
| minute | yeah. i guess they just didn't think that someone needed it | 14:25 |
| minute | i will write to Cristian Ciocaltea and i need to revert my laptop to 6.9 | 14:25 |
| minute | mail sent | 14:38 |
| josch | will u-boot be the same? | 14:47 |
| josch | if yes: https://source.mnt.re/reform/reform-rk3588-uboot/-/merge_requests/3 | 14:47 |
| minute | josch: yeah | 14:48 |
| josch | minute: i pushed a new commit because i forgot to list the flash.bin as an artifact, you might need to re-enable the automatic-merging for that commit | 14:50 |
| - bleb (QUIT: Ping timeout: 264 seconds) (~cm@user/bleb) | 14:53 | |
| minute | josch: there was a short discussion about rockchip hdmi1 stuff in #linux-rockchip | 15:06 |
| minute | it looks like they don't wanna help with that now (different goals, wanting to make the driver smaller first to be upstreamable). we need to forward port the old version i guess | 15:06 |
| josch | bummer :/ | 15:08 |
| josch | i pushed the changes needed to build pocket-reform-system-rk3588.img.gz to https://source.mnt.re/reform/reform-system-image/-/merge_requests/105 | 15:09 |
| minute | josch: thank you! | 15:10 |
| minute | so with hdmi disabled, the pocket rk3588 stuff boots, but dsi display doesn't work yet. it's a bit complicated because i have 2 (3) different displays here that need different timings, and the success i had yesterday was with one that needs different timings than what we have in our modified jdi driver | 15:12 |
| minute | sre in #linux-rockchip encourages porting the hdmi bits from the 6.9 stack | 15:15 |
| + bkeys (~Thunderbi@45.134.140.153) | 15:15 | |
| minute | ok, i'm kind of fed up with rk stuff atm, will do the 6.10. suspend testing on imx8mp now | 15:17 |
| minute | resume does not work, same hang | 15:31 |
| josch | and rk3588-mnt-pocket-reform system image support needs a new tag in reform-rk3588-uboot and a new reform-tools release -- i'll do that later, afk now | 15:33 |
| minute | hmm also i had it hang twice at boot | 15:35 |
| minute | didn't someone else report that 6.10.3 randomly hangs at boot on imx8mp pocket? | 15:36 |
| minute | amospalla: with 6.10.3 it looks like i can successfully boot only sometimes, you have the same behavior? | 15:39 |
| minute | amospalla: on imx8mp pocket | 15:39 |
| amospalla | minute: yes | 15:42 |
| amospalla | I could have downgraded kernel on my Pocket, didn't think about that. | 15:43 |
| amospalla | Just to test if it worked well again. | 15:44 |
| minute | i think 6.10.3 is definitely broken for imx8mp. i think we need to pull it and investigate @ josch before more people break their pocket reforms | 15:47 |
| minute | it's weird because it seems random | 15:48 |
| amospalla | It is. | 15:48 |
| minute | i'll delete the kernel package from the repo for now and stop repo sync process | 15:49 |
| amospalla | I barely use my pocket because lack of free time, feel free to ask for testing on mine if needed. | 15:49 |
| amospalla | having linux-headers-6.9.12-mnt-reform-arm64 and linux-image-6.9.12-mnt-reform-arm64 installed, can I just remove the 6.10 packages and expect it to boot? | 15:49 |
| minute | amospalla: i think so | 15:50 |
| minute | in worst case you can recover via microSD card | 15:50 |
| amospalla | me too, yeah, let's try. | 15:50 |
| minute | ok, 6.10.3 packages disabled in repo | 15:51 |
| minute | now having some food | 15:51 |
| amospalla | good profit | 15:51 |
| amospalla | minute: may be of your interest, on 6.10 /sys/class/power_supply/8xlifepo4/ moved to /sys/class/power_supply/BAT0/ | 16:16 |
| - aloo_shu (QUIT: Ping timeout: 252 seconds) (~aloo_shu@85.51.17.53) | 16:21 | |
| minute | amospalla: yep, that's correct and good | 16:24 |
| amospalla | better :) | 16:24 |
| + aloo_shu (~aloo_shu@85.51.17.53) | 16:32 | |
| minute | aha, when you wait for 0.5-1 minute: | 16:45 |
| minute | [ 24.017317] watchdog: Watchdog detected hard LOCKUP on cpu 1 | 16:45 |
| minute | [ 48.021309] watchdog: Watchdog detected hard LOCKUP on cpu 0 | 16:45 |
| - hairu (QUIT: Remote host closed the connection) (m-uotkmd@user/hairu) | 16:51 | |
| + hairu (m-uotkmd@user/hairu) | 16:53 | |
| minute | i now have an extlinux.conf with loglevel=7 and break=modules | 16:55 |
| minute | it can still hang then | 16:55 |
| minute | also, i guess something is again amiss in terms of modules in the initrd. > platform 32f10000.blk-ctrl: deferred probe pending: imx8mp-blk-ctrl: failed to get noc entries | 16:59 |
| minute | > platform 32e60000.dsi: deferred probe pending: platform: supplier 32ec0000.blk-ctrl not ready | 16:59 |
| - mjw (QUIT: Killed (erbium.libera.chat (Nickname regained by services))) (~mjw@gnu.wildebeest.org) | 16:59 | |
| * Guest2979 -> mjw | 16:59 | |
| minute | also, not sure if that's good > imx-pgc imx-pgc-domain.14: failed to power down ADB400 | 16:59 |
| + Guest1027 (~mjw@gnu.wildebeest.org) | 17:00 | |
| minute | that's pgc_hdmimix | 17:01 |
| minute | last time the fix for the noc entries stuff was this https://source.mnt.re/reform/reform-tools/-/merge_requests/71/diffs | 17:23 |
| + jacobk (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 17:24 | |
| minute | also, i'm rebooting source.mnt.re now | 17:24 |
| minute | ah, i probably had a very old reform-tools on that imx8mp machine | 17:31 |
| minute | that's why some important modules did not get loaded in initramfs | 17:31 |
| + bkeys1 (~Thunderbi@45.134.140.153) | 17:42 | |
| - bkeys (QUIT: Ping timeout: 255 seconds) (~Thunderbi@45.134.140.153) | 17:43 | |
| * bkeys1 -> bkeys | 17:43 | |
| minute | aha, once i got a panic and the bt has [ 4.287211] imx8mp_blk_ctrl_power_on+0x3c/0x260 | 17:50 |
| minute | > [ 4.287098] imx8mp_hdmi_power_notifier+0x3c/0xc0 | 17:50 |
| minute | > [ 4.287090] regmap_write+0x68/0x88 | 17:50 |
| + andypiper (~andypiper@45.148.12.75) | 17:55 | |
| minute | hmm something is odd, i get crash with imx8mp_hdmi_power_notifier in the trace, even if i removed hdmi_blk_ctrl: blk-ctrl@32fc0000 from dtsi | 18:03 |
| + vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:50) | 18:09 | |
| minute | aha, wrong dtb filename m) | 18:21 |
| josch | minute: just read the backlog. Depending on how long you estimate you need with a fix, you might want to press the "keep" button on the last reprepro job from reform-debian-packages which produced the 6.9 kernel: https://source.mnt.re/reform/reform-debian-packages/-/jobs/5257 | 18:21 |
| josch | otherwise, the 6.9 kernel will vanish and it will be difficult to rebuild it because Debian unstable doesn't ship it anymore | 18:21 |
| minute | josch: thanks, good call.. just pressed that button | 18:22 |
| minute | nuked all hdmi stuff from the pocket reform dts now here | 18:25 |
| minute | aha, now it seems to not lock up during boot any longr | 18:28 |
| minute | booted at least 5,6 times now and so far no hangs | 18:30 |
| minute | yeah. it's definitely the new hdmi drivers | 18:32 |
| ^alex | just flashed sdk-2.0 versions of the pocket kbd and syscon firmware | 18:36 |
| minute | neat | 18:36 |
| ^alex | MR !6 in the pipe | 18:37 |
| josch | oh elf2uf2 is now in "picotool uf2 convert" | 18:42 |
| josch | ^alex: thank you for testing version 2.0 of picosdk -- once picolibc builds again, i can upload it to debian as well | 18:44 |
| ^alex | no worries | 18:45 |
| josch | ^alex: but i don't understand why the | 18:47 |
| josch | install-fw-dependencies.sh script is supposed to remove picotool | 18:47 |
| josch | i do not think that this is a good style as those who run this script might have picotool installed for other purposes | 18:47 |
| ^alex | because it goes and installs picotool 2.0 into /usr/local | 18:47 |
| ^alex | and we would rather not have two incompatible versions, one in /usr and the other in /usr/local | 18:48 |
| josch | i do not think that install-fw-dependencies.sh should have a "sudo make install" at all | 18:49 |
| josch | the script should not have side-effects outside of the directory that it is run in other than those changes that are guarded by the package manager | 18:49 |
| ^alex | minute, there was a set_sys_clock_48mhz() commented at the top of sysctl.c - we uncommented it and the syscon seems to run normally, was there any reason it was commented out? | 18:49 |
| josch | why not replace the "sudo apt install picotool" with "sudo apt satisfy picotool (>= 2.0)" | 18:49 |
| josch | that way, it will make sure that a high-enough version of picotool is installed before proceeding | 18:50 |
| ^alex | josch, good question! we just reverted minute's commit to undo the picotool install, and the `sudo make install` was part of that. also we didn't know about `apt satisfy`, that's new to us :) | 18:50 |
| minute | ^alex: at some point i had some instability that i thought was related, but it turned out not to be | 18:52 |
| ^alex | ah ok | 18:53 |
| ^alex | i _think_ the easiest path to downclocking these 2040s is set_sys_clock_48mhz() and then using the 2.0 sdk `clock_configure_undivided` to reclock the system | 18:53 |
| ^alex | then we can consider powering down the system PLL and so forth | 18:54 |
| ^alex | and that's where we're heading today | 18:54 |
| ^alex | if our orange fluffer will step off of our keyboard :) | 18:55 |
| minute | nice | 18:56 |
| ^alex | another thing we were planning on making is a stdio driver that logs to a ring buffer, but on the keyboard that presents the problem of "how do we present it" - squeezing it onto the OLED screen a page at a time? the syscon can at least dump it via a command... | 18:58 |
| ^alex | tunnel it over the UART to the syscon? | 18:58 |
| minute | ^alex: yeah maybe the keyboard could query log lines/pages with some offset parameter? | 19:00 |
| minute | or just "give me another page" | 19:00 |
| * mjw -> Guest6824 | 19:16 | |
| - Guest6824 (QUIT: Killed (copper.libera.chat (Nickname regained by services))) (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 19:16 | |
| * Guest1027 -> mjw | 19:16 | |
| + Guest6824 (~mjw@2001:1c06:2488:1400:4fd:39a7:74ac:7bae) | 19:16 | |
| - andypiper (QUIT: Quit: My device has gone to sleep. Zzzz…) (~andypiper@45.148.12.75) | 19:20 | |
| + andypiper (~andypiper@45.148.12.75) | 19:21 | |
| * andypiper -> andypiper[afk] | 19:21 | |
| * andypiper[afk] -> andypiper | 19:21 | |
| ^alex | josch, updated the install-fw-dependencies script per comment | 19:55 |
| josch | ^alex: thank you! Unrelated to your MR I'm also wondering about those pico_sdk_import.cmake files. As I understand it, those should be copied verbatim from upstream pico-sdk. Is my understanding correct? If yes, those could become a symlink to /usr/src/pico-sdk/external/pico_sdk_import.cmake | 20:09 |
| ^alex | ooh, we're getting pico-sdk as a package? :) | 20:10 |
| josch | it already exists | 20:10 |
| ^alex | ah | 20:10 |
| josch | but it's not version 2.0 | 20:10 |
| josch | all blocked by https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1077452 | 20:10 |
| ^alex | gotcha | 20:10 |
| minute | i finally have working dsi display again with 6.10.3 on imx8mp, the issue was a bad mezzanine adapter here ;0 | 20:11 |
| - andypiper (QUIT: Ping timeout: 252 seconds) (~andypiper@45.148.12.75) | 20:11 | |
| ^alex | every time we hear that word, a clip from the film 'The Hudsucker Proxy' plays in our head: "forty-four!"/"not counting the mezzanine" | 20:12 |
| minute | haha | 20:16 |
| minute | ok, i'm now turning hdmi things back on to narrow down what's causing freezes | 20:21 |
| ^alex | josch, personally we don't like squashing changes on merge, b/c we find the history of exploration to be important | 20:25 |
| josch | ^alex: okay! i leave the decision up to you :) | 20:25 |
| josch | (unless minute has a strong opinion in either direction of course) | 20:25 |
| minute | nope | 20:30 |
| minute | all good | 20:30 |
| minute | ok so hdmi is definitely the culprit @ freezing @ 6.10.3 imx8mp. | 20:30 |
| minute | i wonder if and why that is happening only to us | 20:30 |
| minute | or is it caused by the supposed suspend fix patch? | 20:31 |
| ^alex | josch, we'll probably wait to merge it until picotool 2 comes into apt | 20:32 |
| minute | i compared the following files in our stack to the current linux git version, and they're identical: imx8mp-hdmi-tx.c imx8mp-hdmi-pvi.c phy-fsl-samsung-hdmi.c | 20:42 |
| minute | building a linux head kernel now with our remaining patches applied | 20:53 |
| minute | to see if that also hangs | 20:54 |
| - mesaoptimizer (QUIT: Ping timeout: 244 seconds) (~mesaoptim@user/PapuaHardyNet) | 21:00 | |
| + mesaoptimizer (~mesaoptim@user/PapuaHardyNet) | 21:12 | |
| minute | so far it doesn't hang | 21:17 |
| minute | and hdmi works | 21:17 |
| minute | so... now the big question, what are the differences | 21:18 |
| minute | monolithic vs modular kernel or actual code differences? | 21:18 |
| minute | hmm, imx8mp-hdmi.c is not a thing anymore | 21:23 |
| minute | the 4 patches in our "hdmi" folder are now unnecessary https://source.mnt.re/reform/reform-debian-packages/-/merge_requests/53 | 21:35 |
| - colinsane (QUIT: Quit: bye) (~colinunin@97-113-70-61.tukw.qwest.net) | 21:52 | |
| minute | aha, our debian kernel, but built monolithic, also doesn't freeze | 21:54 |
| + colinsane (~colinunin@97-113-70-61.tukw.qwest.net) | 21:55 | |
| ^alex | oh no | 21:57 |
| minute | so there's probably some race condition that happens due to module load order / synchronicity | 21:59 |
| minute | that would explain the randomness | 21:59 |
| minute | to combat this i will bake in more imx related modules into the kernel, especially those power domain related ones | 21:59 |
| - jacobk (QUIT: Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 22:58 | |
| + jacobk (~quassel@47-186-105-237.dlls.tx.frontiernet.net) | 23:16 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!