- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 00:00 | |
- kklimonda_ (QUIT: Read error: Connection reset by peer) (~kklimonda@user/kklimonda) | 00:43 | |
- Ar|stote|is (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~linx@149.210.4.126) | 01:00 | |
+ Ar|stote|is (~linx@149.210.4.126) | 01:00 | |
+ vagrantc (~vagrant@2600:3c01:e000:21:7:77:0:20) | 01:07 | |
- Nixkernal (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@2a02:1210:1613:e600:a4d7:a280:f8c8:f15e) | 01:14 | |
- erle (QUIT: Read error: Connection reset by peer) (~erle@ip5f5bd03c.dynamic.kabel-deutschland.de) | 01:14 | |
+ mrdaught (~mrdaught@50.237.127.178) | 01:30 | |
+ jacobk (~quassel@utdpat241106.utdallas.edu) | 01:31 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 01:33 | |
+ mrdaught (~mrdaught@50.237.127.178) | 01:38 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 01:38 | |
- mjw (QUIT: Ping timeout: 272 seconds) (~mjw@gnu.wildebeest.org) | 01:45 | |
- cobra (QUIT: Ping timeout: 264 seconds) (~cobra@user/Cobra) | 01:46 | |
+ mjw (~mjw@gnu.wildebeest.org) | 01:50 | |
- S0rin (QUIT: Ping timeout: 256 seconds) (~S0rin@user/s0rin) | 01:57 | |
- vagrantc (QUIT: Quit: leaving) (~vagrant@2600:3c01:e000:21:7:77:0:20) | 01:59 | |
+ S0rin (~S0rin@user/s0rin) | 02:00 | |
+ mrdaught (~mrdaught@50.237.127.178) | 02:05 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 02:06 | |
+ cobra (~cobra@user/Cobra) | 02:17 | |
- S0rin (QUIT: Ping timeout: 264 seconds) (~S0rin@user/s0rin) | 02:20 | |
+ S0rin (~S0rin@user/s0rin) | 02:26 | |
+ mrdaught (~mrdaught@50.237.127.178) | 02:28 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 02:29 | |
+ mrdaught (~mrdaught@2607:fb90:9fab:52b9:c9a0:b876:2cbf:181c) | 02:44 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@2607:fb90:9fab:52b9:c9a0:b876:2cbf:181c) | 02:45 | |
- colinsane (QUIT: Quit: bye) (~colinunin@97-113-159-4.tukw.qwest.net) | 02:45 | |
+ colinsane (~colinunin@97-113-159-4.tukw.qwest.net) | 02:48 | |
- mjw (QUIT: Ping timeout: 272 seconds) (~mjw@gnu.wildebeest.org) | 02:49 | |
- S0rin (QUIT: Ping timeout: 264 seconds) (~S0rin@user/s0rin) | 03:06 | |
+ S0rin (~S0rin@user/s0rin) | 03:09 | |
- S0rin (QUIT: Ping timeout: 264 seconds) (~S0rin@user/s0rin) | 03:32 | |
+ S0rin (~S0rin@user/s0rin) | 03:34 | |
+ erle (~erle@2a02:8109:da40:c4::221d) | 03:47 | |
- nsc (QUIT: Ping timeout: 264 seconds) (~nicolas@80-99-142-46.pool.kielnet.net) | 03:49 | |
+ nsc (~nicolas@103-99-142-46.pool.kielnet.net) | 03:50 | |
- bkeys (QUIT: Ping timeout: 255 seconds) (~Thunderbi@45.134.140.153) | 03:51 | |
- erle (QUIT: Quit: Democracy must always be better armed than tyranny.) (~erle@2a02:8109:da40:c4::221d) | 03:57 | |
+ erle (~erle@2a02:8109:da40:c4::221d) | 04:05 | |
+ mrdaught (~mrdaught@2607:fb90:9fab:52b9:c9a0:b876:2cbf:181c) | 04:16 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@2607:fb90:9fab:52b9:c9a0:b876:2cbf:181c) | 04:20 | |
- jacobk (QUIT: Ping timeout: 268 seconds) (~quassel@utdpat241106.utdallas.edu) | 04:39 | |
+ jacobk (~quassel@utdpat241106.utdallas.edu) | 05:02 | |
+ mrdaught (~mrdaught@2607:fb90:9fab:52b9:c9a0:b876:2cbf:181c) | 05:23 | |
- mrdaught (QUIT: Ping timeout: 256 seconds) (~mrdaught@2607:fb90:9fab:52b9:c9a0:b876:2cbf:181c) | 05:27 | |
+ mrdaught (~mrdaught@50.237.127.178) | 05:31 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 05:32 | |
- jacobk (QUIT: Ping timeout: 268 seconds) (~quassel@utdpat241106.utdallas.edu) | 05:58 | |
+ jacobk (~quassel@64.189.201.150) | 06:16 | |
+ mrdaught (~mrdaught@50.237.127.178) | 06:18 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 06:20 | |
+ mrdaught (~mrdaught@50.237.127.178) | 06:53 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 06:55 | |
+ mrdaught (~mrdaught@50.237.127.178) | 07:37 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 07:40 | |
+ mrdaught (~mrdaught@50.237.127.178) | 08:36 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 08:36 | |
- Asmadeus (QUIT: Ping timeout: 256 seconds) (~asmadeus@240b:13:8c80:d300::42:13) | 08:40 | |
+ Asmadeus (~asmadeus@240b:13:8c80:d300::42:13) | 09:21 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:55cc:437f:6aa3:25d7) | 09:50 | |
+ mrdaught (~mrdaught@50.237.127.178) | 10:36 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 10:37 | |
- Nixkernal (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@2a02:1210:1613:e600:55cc:437f:6aa3:25d7) | 10:59 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:8d1:c876:3456:5957) | 11:01 | |
- Nixkernal (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@2a02:1210:1613:e600:8d1:c876:3456:5957) | 11:28 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:9861:865:81dc:ab53) | 11:30 | |
- Nixkernal (QUIT: Client Quit) (~quassel@2a02:1210:1613:e600:9861:865:81dc:ab53) | 11:31 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:2537:ceac:9704:f2f3) | 11:33 | |
+ wakest (m-a7d6fe@45.77.48.108) | 12:15 | |
- wakest (PART: !!unknown attribute: msg!!) (m-a7d6fe@45.77.48.108) | 12:19 | |
+ wakest (m-a7d6fe@45.77.48.108) | 12:19 | |
- Nixkernal (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@2a02:1210:1613:e600:2537:ceac:9704:f2f3) | 12:23 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:797e:293:93a8:1c6d) | 12:25 | |
- Nixkernal (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@2a02:1210:1613:e600:797e:293:93a8:1c6d) | 12:33 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:c8a0:5849:750e:6085) | 12:34 | |
- Nixkernal (QUIT: Client Quit) (~quassel@2a02:1210:1613:e600:c8a0:5849:750e:6085) | 12:39 | |
+ Nixkernal (~quassel@2a02:1210:1613:e600:fdd7:bb07:fde0:c3d0) | 12:43 | |
+ mjw (~mjw@gnu.wildebeest.org) | 12:58 | |
- buckket (QUIT: Remote host closed the connection) (~buckket@vps.buckket.org) | 13:57 | |
+ buckket (~buckket@vps.buckket.org) | 13:58 | |
- qbit (QUIT: Remote host closed the connection) (~qbit@mail.suah.dev) | 14:11 | |
+ qbit (~qbit@mail.suah.dev) | 14:14 | |
+ mrdaught (~mrdaught@50.237.127.178) | 14:37 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 14:50 | |
josch | minute: about your recent suggestion about setting wifi mtu to 1000: are you still seeing connection drops with a311d wifi and wifi.powersave = 2? | 16:39 |
---|---|---|
+ robin (~robin@user/terpri) | 16:54 | |
+ mrdaught (~mrdaught@50.237.127.178) | 17:25 | |
- mrdaught (QUIT: Remote host closed the connection) (~mrdaught@50.237.127.178) | 17:41 | |
+ mrdaught (~mrdaught@50.237.127.178) | 17:41 | |
f_ | ah yeah progman :) | 18:05 |
minute | josch: actually i didn't see drops in the last few days, which is confusing | 19:15 |
minute | root@reform:/etc# iw wlan0 get power_save | 19:16 |
minute | Power save: off | 19:16 |
minute | someone has a debian package issue https://community.mnt.re/t/build-essential-conflicts/1889 | 19:18 |
josch | hrm... funny, my wifi still drops sometimes. Not often, maybe twice a day but still noticable. | 19:20 |
josch | thanks for making me aware of the build-essential forum question -- i replied | 19:24 |
minute | josch: ok, so i am pretty sure i had dropouts last weekend, but not this weekend | 19:24 |
minute | i still need to figure out some correlations or better causations :D | 19:25 |
minute | ha, just had a dropout! | 19:26 |
minute | so they take around 25 seconds | 19:26 |
minute | nothing in dmesg | 19:27 |
minute | i get around 27mbit symmetrical in speedtest | 19:28 |
minute | setting mtu to 1000 now | 19:28 |
minute | ok, doesn't matter, just had a 10 second dropout during speedtest | 19:29 |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 19:31 | |
+ mrdaught (~mrdaught@50.237.127.178) | 19:35 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 19:35 | |
vkoskiv | Experimenting with improvements to A311D wifi? I don't recall having had any dropouts after setting that powersave flag N months ago. | 19:35 |
minute | interesting. i think with powersave off i have a lot less issues but they still appear from time to time (like just now 2 times) | 19:39 |
- TadeusTaD (QUIT: Quit: Stay Cheeki Breeki) (tadeustad@psifactor.pl) | 19:42 | |
+ TadeusTaD (tadeustad@psifactor.pl) | 19:47 | |
+ mrdaught (~mrdaught@50.237.127.178) | 19:47 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 19:48 | |
+ mrdaught (~mrdaught@50.237.127.178) | 20:03 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 20:04 | |
+ mrdaught (~mrdaught@50.237.127.178) | 20:26 | |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 20:29 | |
- kensanata (QUIT: Quit: OK) (~alex@user/kensanata) | 20:48 | |
+ kensanata (~alex@user/kensanata) | 20:49 | |
hramrach | https://www.benkuhn.net/wireless/ That said, wires are a trap also, you can get entangled in the wires if too many go to your machine :) | 20:56 |
hramrach | ACTION eyes the wire nest to the left | 20:58 |
josch | minute: wait, your connection comes back on after half a minute? By itself? | 21:03 |
josch | i'm also currently using the flat molex antenna that came with my a311d and not the better laird antenna | 21:05 |
+ mrdaught (~mrdaught@50.237.127.178) | 21:29 | |
minute | josch: yes, connection always recovers after 10-30 seconds | 21:32 |
minute | i'm also using molex | 21:33 |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 21:33 | |
josch | this is very interesting -- i'll wait a bit longer next time this happens for me then | 21:34 |
josch | maybe i was too quick to hit the re-connect button | 21:34 |
josch | i'm on kernel 6.5 from backports -- maybe you upgraded to 6.6 already? | 21:37 |
jackhill | hey, I feel like I should be able to find this on my own, however, where is the source for the uboot boot.scr (for iMX.8)? | 21:44 |
josch | jackhill: in Debian, we generate boot.scr using flash-kernel and that one uses this template: | 21:46 |
josch | https://sources.debian.org/src/flash-kernel/3.107/bootscript/all/bootscr.uboot-generic/ | 21:46 |
jackhill | josch: oh, so not at all reform specific then? | 21:46 |
josch | what is reform-specific are the values that are put into the template :) | 21:47 |
josch | jackhill: and i think it is understandable that you didn't find this by yourself. You are not the first one to ask. I filed this merge request to make the information you were looking for easier to find in the future: https://salsa.debian.org/installer-team/flash-kernel/-/merge_requests/53 | 21:48 |
jackhill | right, make sense. Very cool, thank you. Reform/iMX.8 is the first arm device I've really dug into, and I'm slowly forming a mental picture :) | 21:49 |
josch | yeah, the very first bits of the boot process are not quite intuitive if you come from x86 | 21:50 |
jackhill | haha, indeed. The temptation of getting uboot to boot grub and go from that familiar environment is strong when I think about doing any customization. | 22:05 |
josch | there are people who have been experimenting with going from u-boot to efi | 22:08 |
josch | minute: do you personally use a dark-mode extension as you suggested on the forum? I just tried out Dark Reader as you suggested and suddenly my websites render much slower than before :( | 22:13 |
Zaba | you can also use bootstd and let u-boot read an extlinux.conf instead of boot.scr and all that nonsense | 22:14 |
josch | yes, on Debian you'd install the u-boot-menu package to have a fitting extlinux.conf generated | 22:15 |
jackhill | Zaba: bootstd? Yeah, where I eventually want to get to is to create a Guix image for reform. Maybe translating everything to Guix tooling or maybe reusing some of the reform debian stuff to eventually boot the Guix image. | 22:16 |
jackhill | but reguardless of that juts understanding the process is its own rewared :) | 22:17 |
josch | it is much easier to write a custom extlinux.conf than writing a custom boot.scr, I think | 22:18 |
josch | mine looks like this: https://paste.debian.net/hidden/d8714609/ | 22:18 |
Zaba | bootstd is the u-boot term for… oh, well, it's complicated and poorly documented, unfortunately | 22:18 |
jackhill | lol | 22:19 |
jackhill | josch, Zaba thanks! | 22:19 |
josch | Zaba: we recently discussed where the documentation for u-boot's extlinux.conf is :) | 22:19 |
josch | there are some text files in the u-boot source | 22:19 |
Zaba | but basically, there's code in u-boot for booting fully under the control of those horrendous boot scripts, and then there's an alternative way of booting through other means, including a parser for extlinux.conf | 22:19 |
Zaba | josch: the only reliable documentation i found was in the text files ending in .c | 22:20 |
josch | haha fair :) | 22:20 |
Zaba | it's really a shame because it simplifies things so much and you never have to touch a u-boot script again if all you're doing is booting linux normally (which, let's face it, is what most people want) | 22:20 |
Zaba | but because of poor messaging/documentation most people remain painfully unaware of the possibility | 22:21 |
josch | indeed | 22:21 |
josch | for example, I only found out by trying it (i don't see it documented) that you can use u-boot environment variables in "append" in extlinux.conf | 22:21 |
jackhill | how does one tell uboot to use extlinux v. the horrendous boot scripts? :) | 22:21 |
Zaba | doesn't help that some popular SBCs have popularized some extremely questionable u-boot-related workflows, too | 22:21 |
josch | jackhill: u-boot will first check if extlinux.conf exists and use that and only fall back to boot.scr if it doesn't exist | 22:22 |
jackhill | josch: oh, super! | 22:22 |
Zaba | yeah, you don't tell u-boot things. u-boot just does things. and if it doesn't, it was probably configured wrong at its build time | 22:23 |
Zaba | (except if you get to its command prompt and start telling it things) | 22:23 |
hramrach | u-boat goes underwater, you don't see what it's dpoing andw why | 22:25 |
Zaba | (sometimes though it will inexplicably do *different* things when commanded to manually, compared to when left its own devices) | 22:25 |
Zaba | hramrach: yeah last time i had problems i had to printf debug it | 22:26 |
jackhill | lol | 22:26 |
jackhill | I guess the other thing I need to learn is about device trees and their source and binary forms | 22:26 |
Zaba | yeah that's pretty easy, there's a tool called dtc that can convert between the different forms | 22:28 |
hramrach | if you know what you are doing you can get some value out of that | 22:29 |
hramrach | the problem is that a dts is composed of multiple files, and that infromation is lost when converted to dtb | 22:30 |
jackhill | fair enough. And these device trees are something MNT maintains? | 22:31 |
Zaba | well yeah, if you want the original source it's best to go to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts and find it there | 22:31 |
hramrach | but you can convert the current stuff to dtb, or a specific vintage of the kernel sources to dtb, and compare with the actual dtb you are seeing | 22:31 |
josch | jackhill: the reform-specific device trees and patches are all collected here: https://source.mnt.re/reform/reform-debian-packages/-/tree/main/linux?ref_type=heads | 22:33 |
jackhill | cool, thanks | 22:34 |
Zaba | for example here is the device tree for the imx8mq SoM for reform 2 in mainline linux: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/freescale/imx8mq-mnt-reform2.dts | 22:34 |
Zaba | it mostly relies on a chain of #includes and only specifies things that are different about this particular device | 22:35 |
Zaba | if you convert the binary device tree into source, all the includes will be flattened etc | 22:35 |
josch | somebody [tm] should look into upstreaming the dts files from reform-debian-packages... :/ | 22:36 |
hramrach | that requires connector support that is pending for at lest a decade | 22:37 |
hramrach | because reform has connectors [tm] | 22:39 |
digitalrayne | the dts in mainline u-boot is also another place reform device trees live, when i get time i'm going to see if there is much delta between the boundary u-boot fork and what's in mainline u-boot today | 22:49 |
digitalrayne | i'm sure there is a whole discussion about whether dts should live in u-boot or the linux kernel also | 22:49 |
hramrach | u-boot is synced from the kernel .. unless a separate dts repository got realized, another thjing pending for years | 22:52 |
bluerise | the u-boot version is 1:1 copied from kernel, with minor changes in the u-boot.dts for u-boot specific fixes | 22:52 |
josch | digitalrayne: i think bluerise has been rebasing the necessary stuff on upstream u-boot -- but no display support yet as far as i know | 22:55 |
- jacobk (QUIT: Ping timeout: 268 seconds) (~quassel@64.189.201.150) | 22:56 | |
digitalrayne | yep! it's what is used to bring up OpenBSD on the reform, display is there, as well as nvme + second pcie | 22:56 |
digitalrayne | that's interesting re: the syncing from linux | 22:57 |
bluerise | that's standard procedure ;) | 23:00 |
bluerise | the unfortunate reality is that a) vendors don't care much about pushing their device trees into linux and b) doing that upstreaming ... sometimes takes some endurance | 23:01 |
bluerise | therefore you end up living with either old/incompatible versions, or mainline with not all hw support | 23:01 |
bluerise | and before you finish one machine, the next soc/product comes around and the game starts again | 23:02 |
jackhill | bluerise: is it just device tree that's missing? I thought driver code was missing from linux too. Otherwise, why couldn't we have latest linux and point at an out of tree device tree? | 23:02 |
bluerise | but maybe I'm just burned out :) | 23:02 |
bluerise | depends on the soc I guess? don't know what the status for imx8mq is. it's fairly old, so it should have OK support | 23:03 |
bluerise | apart from it not supporting the external refclk/ext_osc bindings | 23:04 |
bluerise | (for pcie0 | 23:04 |
+ jacobk (~quassel@utdpat241106.utdallas.edu) | 23:08 | |
Zaba | upstreaming things into linux still seems to happen far more consistently than upstreaming things into u-boot | 23:15 |
minute | josch: i do not use a dark mode extension. | 23:19 |
hramrach | not a sith, eh? | 23:28 |
+ mrdaught (~mrdaught@50.237.127.178) | 23:30 | |
minute | i would consider myself "goth" or goth-adjacent. | 23:30 |
- mrdaught (QUIT: Read error: Connection reset by peer) (~mrdaught@50.237.127.178) | 23:31 | |
minute | i just googled for css overrides in firefox, per-domain, it is possible but strangely involved | 23:31 |
+ bkeys (~Thunderbi@45.134.140.153) | 23:32 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!