- GNUmoon2 (QUIT: Ping timeout: 258 seconds) (~GNUmoon@gateway/tor-sasl/gnumoon) | 00:12 | |
sigrid | I am extremely confused with how lpc commands are handled over spi | 00:29 |
---|---|---|
sigrid | it expects three bytes - magic 0xb5, a command, and an argument | 00:29 |
sigrid | it does not respond to any of the bytes (I guess the host will read that as 0) | 00:29 |
sigrid | then it responds with SSP0_FIFOSIZE bytes, also dummy-reading from the host after each write | 00:30 |
sigrid | SSP0_FIFOSIZE = 8 | 00:31 |
sigrid | if I look at the linux driver counterpart of it absolutely nothing makes any sense | 00:31 |
sigrid | 4 bytes are written, 8 bytes are read back | 00:32 |
sigrid | how exactly does this work? | 00:32 |
minute | hm! | 00:44 |
minute | unfortunately NanoCodeBug is not here to tell us | 00:45 |
minute | sigrid: as far as i understand, in spi reads and writes are always coupled? | 00:49 |
sigrid | yeah, they are supposed to be | 00:49 |
+ GNUmoon2 (~GNUmoon@gateway/tor-sasl/gnumoon) | 00:49 | |
minute | i will need to look into the code tomorrow or in 2 days | 00:50 |
sigrid | it seems the logic sometimes gets itself cornered if some wrong data is sent by the host | 00:57 |
sigrid | rn, for example, all I get is 0xa9 no matter what I send :) | 00:57 |
sigrid | I got it to work (somewhat) but with stale data readout, precisely because of the confusion surrounding how many bytes does it expect at first | 00:58 |
sigrid | looks like I have to send 3 bytes, put chip select into inactive state for some time - until LPC tries to respond, blocking (I sure hope it does) until chip select is active | 00:59 |
sigrid | then reading 8 bytes, which also requires me to send 8 bytes | 01:00 |
minute | oof | 01:02 |
sigrid | yep, that worked right away :D | 01:10 |
sigrid | multiple burst mode with negative chip select toggle to the rescue | 01:11 |
+ monkeybusiness (~monkbusy@user/monkeybusiness) | 01:11 | |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 01:35 | |
- GNUmoon2 (QUIT: Remote host closed the connection) (~GNUmoon@gateway/tor-sasl/gnumoon) | 01:42 | |
- mtm (QUIT: Ping timeout: 252 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 02:04 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 02:31 | |
- chomwitt (QUIT: Ping timeout: 244 seconds) (~chomwitt@2a02:587:dc16:fe00:36b8:e455:625c:e00b) | 02:31 | |
- cwebber (QUIT: Remote host closed the connection) (~user@user/cwebber) | 03:07 | |
+ monkey_business (~monkbusy@103.87.94.35) | 03:15 | |
- monkeybusiness (QUIT: Ping timeout: 252 seconds) (~monkbusy@user/monkeybusiness) | 03:17 | |
- monkey_business (QUIT: Changing host) (~monkbusy@103.87.94.35) | 03:38 | |
+ monkey_business (~monkbusy@user/monkeybusiness) | 03:38 | |
- monkey_business (QUIT: Quit: Leaving) (~monkbusy@user/monkeybusiness) | 03:41 | |
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 03:58 | |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 04:10 | |
- buckket (QUIT: Read error: Connection reset by peer) (~buckket@pdp8.buckket.org) | 04:58 | |
- Boostisbetter (QUIT: Ping timeout: 248 seconds) (4a410829d7@irc.cheogram.com) | 06:13 | |
- klardotsh (QUIT: Ping timeout: 244 seconds) (~klardotsh@98.97.35.142) | 06:24 | |
- Gooberpatrol66 (QUIT: *.net *.split) (~Gooberpat@user/gooberpatrol66) | 08:47 | |
- chartreuse (QUIT: *.net *.split) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 08:47 | |
- ggoes (QUIT: *.net *.split) (~gregf@fsf/staff/ggoes) | 08:47 | |
- pinoaffe (QUIT: *.net *.split) (~pinoaffep@2a01:4f9:c010:a00b:1337:1337:11be:10) | 08:47 | |
- rafostar[m] (QUIT: *.net *.split) (~rafostarm@2001:470:69fc:105::2:52da) | 08:47 | |
- ehmry (QUIT: *.net *.split) (~quassel@WLWB-VID145-122-227.lcom.net) | 08:47 | |
- kitty4 (QUIT: *.net *.split) (~kitty@096-039-147-043.res.spectrum.com) | 08:47 | |
- frank2- (QUIT: *.net *.split) (~frank2@juicy.frank2.net) | 08:47 | |
- svp (QUIT: *.net *.split) (sid537750@id-537750.uxbridge.irccloud.com) | 08:47 | |
- patrick (QUIT: *.net *.split) (224fa09e8b@fsf/member/patrick) | 08:47 | |
- conky (QUIT: *.net *.split) (5fb0fe5593@2604:bf00:561:2000::10b) | 08:47 | |
- bkeys (QUIT: *.net *.split) (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 08:47 | |
- robin (QUIT: *.net *.split) (~robin@user/terpri) | 08:47 | |
- ex-parrot (QUIT: *.net *.split) (~fincham@user/ex-parrot) | 08:47 | |
- joeyh (QUIT: *.net *.split) (joeyh@2600:3c03::f03c:91ff:fe73:b0d2) | 08:47 | |
- bgs (QUIT: *.net *.split) (~bgs@212-85-160-171.dynamic.telemach.net) | 08:47 | |
- flowy (QUIT: *.net *.split) (~flowy@2a01:4f8:c0c:1a8f::1) | 08:47 | |
- sbp (QUIT: *.net *.split) (~sbp@apache/doge/sbp) | 08:47 | |
- sinedeo_ (QUIT: *.net *.split) (~sinedeo@2a01:4f9:c010:2837::1) | 08:47 | |
- _E (QUIT: *.net *.split) (~e@bsd.moe) | 08:47 | |
+ Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 08:50 | |
+ chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 08:50 | |
+ pinoaffe (~pinoaffep@2a01:4f9:c010:a00b:1337:1337:11be:10) | 08:50 | |
+ ggoes (~gregf@fsf/staff/ggoes) | 08:50 | |
+ rafostar[m] (~rafostarm@2001:470:69fc:105::2:52da) | 08:50 | |
- indefini[m] (QUIT: Ping timeout: 248 seconds) (~indefinim@2001:470:69fc:105::1e2a) | 08:51 | |
- jryans (QUIT: Ping timeout: 240 seconds) (~jryans@2001:470:69fc:105::1d) | 08:51 | |
- tinybronca[m] (QUIT: Ping timeout: 268 seconds) (~tinybronc@2001:470:69fc:105::2:1af6) | 08:52 | |
- scops (QUIT: Ping timeout: 264 seconds) (~scopstchn@2001:470:69fc:105::8da) | 08:54 | |
- rafostar[m] (QUIT: Ping timeout: 268 seconds) (~rafostarm@2001:470:69fc:105::2:52da) | 08:55 | |
- Gooberpatrol66 (QUIT: *.net *.split) (~Gooberpat@user/gooberpatrol66) | 08:56 | |
- chartreuse (QUIT: *.net *.split) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 08:56 | |
- ggoes (QUIT: *.net *.split) (~gregf@fsf/staff/ggoes) | 08:56 | |
- pinoaffe (QUIT: *.net *.split) (~pinoaffep@2a01:4f9:c010:a00b:1337:1337:11be:10) | 08:56 | |
+ _E (~e@bsd.moe) | 08:58 | |
+ sinedeo_ (~sinedeo@2a01:4f9:c010:2837::1) | 08:58 | |
+ sbp (~sbp@apache/doge/sbp) | 08:58 | |
+ flowy (~flowy@2a01:4f8:c0c:1a8f::1) | 08:58 | |
+ bgs (~bgs@212-85-160-171.dynamic.telemach.net) | 08:58 | |
+ joeyh (joeyh@2600:3c03::f03c:91ff:fe73:b0d2) | 08:58 | |
+ ex-parrot (~fincham@user/ex-parrot) | 08:58 | |
+ robin (~robin@user/terpri) | 08:58 | |
+ bkeys (~Thunderbi@static-198-54-135-69.cust.tzulo.com) | 08:58 | |
+ conky (5fb0fe5593@2604:bf00:561:2000::10b) | 08:58 | |
+ svp (sid537750@id-537750.uxbridge.irccloud.com) | 08:58 | |
+ frank2- (~frank2@juicy.frank2.net) | 08:58 | |
+ kitty4 (~kitty@096-039-147-043.res.spectrum.com) | 08:58 | |
+ patrick (224fa09e8b@fsf/member/patrick) | 08:58 | |
+ ehmry (~quassel@WLWB-VID145-122-227.lcom.net) | 08:58 | |
+ Gooberpatrol66 (~Gooberpat@user/gooberpatrol66) | 08:58 | |
+ chartreuse (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 08:58 | |
+ pinoaffe (~pinoaffep@2a01:4f9:c010:a00b:1337:1337:11be:10) | 08:58 | |
+ ggoes (~gregf@fsf/staff/ggoes) | 08:58 | |
- mjw (QUIT: Killed (NickServ (GHOST command used by wielaard!~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440))) (~mark@gnu.wildebeest.org) | 09:03 | |
+ mjw (~mark@gnu.wildebeest.org) | 09:04 | |
- mjw (QUIT: Killed (NickServ (GHOST command used by wielaard!~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440))) (~mark@gnu.wildebeest.org) | 09:04 | |
* wielaard -> mjw | 09:04 | |
+ mark__ (~mark@gnu.wildebeest.org) | 09:04 | |
+ rafostar[m] (~rafostarm@2001:470:69fc:105::2:52da) | 09:52 | |
+ jryans (~jryans@2001:470:69fc:105::1d) | 09:55 | |
+ Smith42 (~Smith42__@147.197.221.58) | 10:32 | |
+ scops (~scopstchn@2001:470:69fc:105::8da) | 10:37 | |
josch | minute: the content of linux/patches is now a patch-stack created by git-format patch. Just dropping an appropriately named file into that directory will now do what you expect. | 10:42 |
josch | I already tested the kernel built with the rearranged patches and things still seem to work. :) | 10:42 |
+ tinybronca[m] (~tinybronc@2001:470:69fc:105::2:1af6) | 10:56 | |
josch | So, after upgrading to 5.19 and with the most recent sysimage-v3 from CI without any changes and without starting sway but just with the terminal I still have suspend/wakeup problems... | 11:10 |
josch | At random points, when attempting to wake up with circle+space, I would only see "waking up lpc... 0%" and then it would go black again and nothing happens... | 11:11 |
minute | josch: from 10 sleep+wake attempts, how many fail? | 11:19 |
minute | approx | 11:19 |
josch | tried 10 times, didn't come back 3 of those | 11:29 |
josch | if it works for everybody else these days then maybe there is just some random thing in my specific unit | 11:30 |
josch | or it's about the wifi card I have or some such (i'm using my own card and not the default compex) | 11:31 |
minute | ah, that could be it... we could send you a compex to compare. but i also should do a new test with many sleep+wake cycles, maybe i was lucky | 11:38 |
josch | minute: thanks for the offer but since there is not much powersaving during suspend anyways, i'm not going to use it often | 11:40 |
minute | alright! | 11:40 |
josch | that's why i usually do not have my reform with me in the evenings because it's plugged in in my office | 11:40 |
josch | minute: is the fact that there is still considerable power consumption during suspend a property of the SoM or a property of the mainboard? Since I ordered an LS1028A, maybe suspend ends up working a bit better with it? | 11:42 |
minute | i'm not sure on either. | 11:42 |
josch | well, we shall see :) | 11:44 |
sknebel | I guess the LS1028A is even less designed for applications where suspend matters. but that doesnt necessarily mean its bad at it | 11:47 |
minute | i just tried 10 sleep+resume cycles in sway and it always came back | 11:59 |
josch | I'm happy to hear that it works in principle and that it's just me. :) | 11:59 |
minute | my test was running on battery (no power brick), compex wifi, 256gb transcend ssd (i should really get a bigger one!) | 12:00 |
+ buckket (~buckket@pdp8.buckket.org) | 12:09 | |
+ indefini[m] (~indefinim@2001:470:69fc:105::1e2a) | 13:43 | |
+ chomwitt (~chomwitt@2a02:587:dc16:fe00:7a9a:c189:544:1fa5) | 13:45 | |
- mtm (QUIT: Ping timeout: 260 seconds) (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 14:02 | |
+ cwebber (~user@user/cwebber) | 15:42 | |
minute | funfact: Xorg works | 16:08 |
josch | no way -- what changed?? | 16:08 |
+ mtm (~mtm@c-73-27-62-116.hsd1.fl.comcast.net) | 16:08 | |
minute | i'm using it without hw accel though | 16:08 |
minute | maybe i just found a config that works | 16:08 |
minute | most apps are pretty snappy with software rendering / llvmpipe though | 16:09 |
minute | GPUs are overrated ;) | 16:09 |
minute | i'll check if hw accel works too (i don't think so) | 16:10 |
minute | http://dump.mntmn.com/etnaviv-x11.conf.txt | 16:27 |
minute | here's a screenshot of xfce4 on reform http://dump.mntmn.com/Screenshot_2022-09-07_16-43-14.png | 16:44 |
josch | wow, that's awesome! | 16:48 |
josch | i guess we put that xorg.conf into reform-tools? | 16:48 |
minute | josch: yeah, we can remove the commented section, it doesn't appear to have an effect | 16:50 |
minute | there are some limits, i.e. fullscreen video playback has a low framerate | 16:52 |
minute | i guess because it has to be cpu scaled | 16:52 |
josch | minute: I assume you put your config into /etc/X11/xorg.conf.d/? Could you quickly verify that the config also takes effect if you place it into /usr/share/X11/xorg.conf.d/ | 16:55 |
josch | Because reform-tools should install into /usr and not into /etc | 16:55 |
minute | sure, can check | 16:55 |
minute | it might also be possible to run xorg on dsi and wayland on HDMI or the other way around | 16:56 |
minute | josch: yes, i've moved it to /usr/share/X11/xorg.conf.d/10-reform.conf and it works | 16:59 |
josch | minute: perfect! This should work: https://source.mnt.re/reform/reform-tools/-/merge_requests/24 | 17:03 |
minute | thanks, merged | 17:04 |
- Smith42 (QUIT: Ping timeout: 264 seconds) (~Smith42__@147.197.221.58) | 17:22 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 17:24 | |
eery | wait, was Xorg not working before now? I've used a similar config and it's worked "fine" for me, performance was very bizarre but it did function | 17:39 |
flowy | eery: (was just reading chat log) one of the reasons you don't really need to worry about encrytion performance is because almost everything you do including web browsing is not going to utlise multiple cores very well | 17:42 |
flowy | so for all single core bound tasks you won't notice a difference | 17:43 |
josch | vagrantc: you recently(-ish... back in April...) noticed a checksum mismatch of packages offered by our repo. This is now fixed thanks to SOURCE_DATE_EPOCH and thanks to src:linux being bit-by-bit reproducible. :) | 17:45 |
josch | I just re-triggered the reform-debian-packages pipeline and the linux-image-arm64 package built by the current run is exactly the same as the one built in the last. | 17:46 |
flowy | josch: impressive! | 17:46 |
minute | cool | 17:46 |
josch | minute: could you re-trigger the reform-system-image pipeline? Then we get an image with 5.19 kernel plus the xorg fixes. :) | 17:46 |
minute | yup | 17:46 |
minute | running | 17:48 |
josch | sweet, thanks! | 17:49 |
eery | looking forward to it so I can be lazy and grab the regenerated initramfs ;) | 17:53 |
josch | eery: that initramfs will have been built with an /etc/fstab which will likely not do what you want | 17:54 |
eery | well I'm currently using an initramfs/kernel yoinked from a sysimage v3 build, and it coincedentally works | 17:56 |
eery | was this something recently changed? | 17:56 |
vagrantc | josch: yeah, src:linux was generally reproducible except for the documentation packages | 17:57 |
josch | which we are not building :) | 17:57 |
vagrantc | josch: did you figure out how to rename the metapackage? | 17:58 |
josch | vagrantc: i haven't investigated that yet | 17:58 |
josch | it's on my todo list | 17:58 |
vagrantc | look forward to trying 5.19! | 17:58 |
vagrantc | josch: so some packages were built without SOURCE_DATE_EPOCH and that is why the checksums mismatched? | 17:59 |
vagrantc | josch: i would have thought packages built these days have SOURCE_DATE_EPOCH set ... or are some packages built manually by constructing DEBIAN/ and whatnot? | 18:00 |
josch | vagrantc: yes | 18:00 |
josch | we construct src:linux ourselves | 18:00 |
vagrantc | oh wow. :) | 18:00 |
josch | because we need custom patches and we don't want to build a full package | 18:00 |
josch | we don't need the cloud stuff or the rt stuff | 18:01 |
vagrantc | that should be easy enough to disable with some more patches... | 18:01 |
josch | now I set SOURCE_DATE_EPOCH to the value of the last git commit to make this reproducible | 18:01 |
josch | and I use faketime when running dch to make the d/changelog entry have a reproducible timestamp as well | 18:02 |
vagrantc | so is debian/changelog changed? | 18:02 |
vagrantc | oh fun. :) | 18:02 |
vagrantc | some distros just hard-code SOURCE_DATE_EPOCH=0 ... though that sometimes has some strange effects | 18:02 |
josch | d/changelog has to be changed or otherwise we cannot have our own version | 18:02 |
josch | i'm now also putting the timestamp in the package version so that changes in the git repo result in a new version of the binaries produced by src:linux | 18:03 |
vagrantc | so from the sounds of things it's not quite ready for me to boot my reform and update to the newest shiniest kernel? | 18:03 |
minute | why not? | 18:03 |
vagrantc | i misunderstood some comments earlier, sounds like it was about regenerating the reform-system-image, not hte kernel | 18:04 |
minute | yeah. the kernel is good now | 18:04 |
kfx | is there a kernel tree that can just build, or is the debian packaging the canonical kernel source? | 18:06 |
minute | kfx: you can clone from kernel git, plop in the patches from reform-debian-packages/linux and also add the config snippet | 18:09 |
minute | could be automated with a script perhaps | 18:10 |
minute | containing the right defconfig (?), CROSS_COMPILE and ARCH | 18:11 |
+ Boostisbetter (4a410829d7@irc.cheogram.com) | 18:13 | |
- mjw (QUIT: Killed (NickServ (GHOST command used by mark__!~mark@gnu.wildebeest.org))) (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 18:41 | |
* mark__ -> mjw | 18:41 | |
+ wielaard (~mjw_@2001:1c06:2488:1400:9e5c:8eff:fe8f:a440) | 18:41 | |
Boostisbetter | You know, one other advantage of using Sway is that notifications are greatly simplified. Everytime I resume the Reform there are ton of things getting updated and yet I don't have a ton of notifications flying all over the screen like I would on Gnome. It is the little things. | 20:51 |
+ ajr (~ajr@user/ajr) | 21:32 | |
josch | Boostisbetter: what is gnome notifying about? (i'm not a gnome user so i have no clue) | 21:33 |
Boostisbetter | josch: basically when using Gnome, when you get notifications from various programs, they will flash in the center top of the screen. Sometimes they can linger and it is annoying | 22:08 |
vkoskiv | It seems like flowy and I will have a small Reform meetup in Helsinki tomorrow :D | 22:09 |
Boostisbetter | lucky you guys! | 22:09 |
josch | yes, you can both be in Helsinki! ;) | 22:09 |
josch | oh and the reform meetup of course :) | 22:10 |
vkoskiv | I'll be sure to capture an image of two Reforms side by side in the wild | 22:10 |
Boostisbetter | with the food you guys are eating would also be cool | 22:10 |
josch | make sure they mate so that you get a pocket reform for free! | 22:10 |
Boostisbetter | hahahahaha! | 22:10 |
vkoskiv | Inital plan is coffee, but we'll see if food happens as well. | 22:10 |
vkoskiv | There is a time restriction, a ferry leaves at a set time. | 22:11 |
vkoskiv | But should be fun. Reforms & Coffee | 22:13 |
eery | Boostisbetter: notifications aren't specific to gnome FWIW, there are various implementations of the xdg notification api for wayland, like mako (and you can disable notifications in gnome) | 22:17 |
- chomwitt (QUIT: Ping timeout: 255 seconds) (~chomwitt@2a02:587:dc16:fe00:7a9a:c189:544:1fa5) | 22:19 | |
minute | vkoskiv: cool, enjoy | 23:16 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!