| - erlehmann (QUIT: Read error: Connection reset by peer) (~erle@dynamic-046-114-035-056.46.114.pool.telefonica.de) | 00:00 | |
| + erlehmann (~erle@dynamic-046-114-033-133.46.114.pool.telefonica.de) | 00:02 | |
| - freakazoid333 (QUIT: Read error: Connection reset by peer) (~freakazoi@107.87.136.83) | 00:10 | |
| - artfwo (QUIT: Ping timeout: 252 seconds) (~artfwo@2a02:8109:8500:26d0:1398:e619:a0e4:9b0e) | 01:00 | |
| - ephase (QUIT: Quit: WeeChat 3.1) (~ephase@2a01:e0a:168:1211:be4c:890f:dab8:5b49) | 01:08 | |
| - Neelfyn (QUIT: Quit: Connection closed for inactivity) (uid180106@id-180106.stonehaven.irccloud.com) | 02:31 | |
| - adjtm_ (QUIT: Quit: Leaving) (~adjtm@188.26.199.222) | 02:52 | |
| + adjtm (~adjtm@2a0c:5a80:1f13:a400:f557:172f:dd90:5513) | 02:54 | |
| - mtm (QUIT: Quit: ERC (IRC client for Emacs 27.1.91)) (~user@c-174-58-99-93.hsd1.fl.comcast.net) | 04:17 | |
| + mtm (~mtm@c-174-58-99-93.hsd1.fl.comcast.net) | 04:29 | |
| - mtm (QUIT: Client Quit) (~mtm@c-174-58-99-93.hsd1.fl.comcast.net) | 04:31 | |
| + mtm (~mtm@c-174-58-99-93.hsd1.fl.comcast.net) | 04:40 | |
| + specing_ (~specing@APN-123-244-46-gprs.simobil.net) | 06:12 | |
| - specing (QUIT: Ping timeout: 264 seconds) (~specing@user/specing) | 06:15 | |
| + artfwo (~artfwo@2a02:8109:8500:26d0:98dc:edef:3632:22d7) | 07:17 | |
| + ysftaha (~ysftaha@d24-57-234-201.home.cgocable.net) | 07:18 | |
| ysftaha | does the reform run voidlinux? | 07:18 |
|---|---|---|
| ysftaha | s/run/support | 07:19 |
| - ysftaha (PART: !!unknown attribute: msg!!) (~ysftaha@d24-57-234-201.home.cgocable.net) | 07:22 | |
| + adjtm_ (~adjtm@188.26.199.222) | 07:31 | |
| - adjtm (QUIT: Ping timeout: 264 seconds) (~adjtm@2a0c:5a80:1f13:a400:f557:172f:dd90:5513) | 07:34 | |
| - chartreuse (QUIT: Remote host closed the connection) (~chartreus@S0106f0f249dfd9c3.cg.shawcable.net) | 07:36 | |
| - Kooda (QUIT: Ping timeout: 272 seconds) (~kooda@natsu.upyum.com) | 09:54 | |
| + Kooda (~kooda@natsu.upyum.com) | 09:54 | |
| - jryans (QUIT: Quit: node-irc says goodbye) (~jryansmat@2001:470:69fc:105::1d) | 11:48 | |
| + jryans (~jryansmat@2001:470:69fc:105::1d) | 11:48 | |
| - emery (QUIT: Quit: https://quassel-irc.org - Chat comfortably. Anywhere.) (~quassel@37.205.14.171) | 12:00 | |
| + emery (~quassel@2a03:3b40:fe:ab::1) | 12:00 | |
| * sknebel -> sebsel | 12:36 | |
| * sebsel -> sknebel | 12:36 | |
| + odnes (~odnes@109-178-166-252.pat.ren.cosmote.net) | 14:08 | |
| - artfwo (QUIT: Ping timeout: 264 seconds) (~artfwo@2a02:8109:8500:26d0:98dc:edef:3632:22d7) | 14:10 | |
| + artfwo (~artfwo@2a02:8109:8500:26d0:ba2:ae05:73b3:a2a4) | 14:28 | |
| - artfwo (QUIT: Ping timeout: 248 seconds) (~artfwo@2a02:8109:8500:26d0:ba2:ae05:73b3:a2a4) | 15:21 | |
| + mjw (~mjw_@2001:1c06:2488:200:9e5c:8eff:fe8f:a440) | 15:29 | |
| + artfwo (~artfwo@172.98.75.220) | 15:34 | |
| - odnes (QUIT: Read error: Connection reset by peer) (~odnes@109-178-166-252.pat.ren.cosmote.net) | 16:05 | |
| + odnes_ (~odnes@109-178-166-252.pat.ren.cosmote.net) | 16:05 | |
| - erlehmann (QUIT: Ping timeout: 265 seconds) (~erle@dynamic-046-114-033-133.46.114.pool.telefonica.de) | 16:15 | |
| + erlehmann (~erle@dynamic-046-114-033-133.46.114.pool.telefonica.de) | 16:19 | |
| - artfwo (QUIT: Ping timeout: 248 seconds) (~artfwo@172.98.75.220) | 16:54 | |
| + artfwo (~artfwo@172.98.75.220) | 17:07 | |
| - odnes_ (QUIT: Ping timeout: 264 seconds) (~odnes@109-178-166-252.pat.ren.cosmote.net) | 17:11 | |
| + specing (~specing@user/specing) | 18:12 | |
| - specing_ (QUIT: Ping timeout: 248 seconds) (~specing@APN-123-244-46-gprs.simobil.net) | 18:14 | |
| bluerise | mntmn: Personally I think an SDIO based ath10k would also be nice, we just don't yet have a driver for that in OpenBSD. I'm using bwfm(4) most of the time, since it's quite a bit faster as all the wifi stuff is happening on the chip itself, instead of in software. | 18:20 |
| mntmn | bluerise: interesting | 18:22 |
| bluerise | But, I know that when you ship a product with a wireless chip on board, that's more effort for CE... | 18:22 |
| mntmn | bluerise: yep, that's one of 2 reasons why there are no radios included ;) | 18:22 |
| bluerise | On the other hand, wireless chip vendors hand you their 'we did CE for the chip', so that helps | 18:22 |
| bluerise | yup | 18:22 |
| - mjw (QUIT: Quit: Leaving) (~mjw_@2001:1c06:2488:200:9e5c:8eff:fe8f:a440) | 18:26 | |
| bluerise | If I were capable of building such stuff, I'd probably: switch to i.MX8MP (better silicon, less heat), use the additional third SD controller for Murata 1MW, route USB to the miniPCIe and add a SIM card slot | 18:26 |
| bluerise | ah damn, MP only has 1 PCIe | 18:26 |
| mntmn | and worse GPU | 18:27 |
| bluerise | but for LTE that'd be fine. if you wanted to improve the WiFi by adding a PCIe card, you'd lose out | 18:27 |
| mntmn | and also some difference regarding displays which i forgot | 18:27 |
| bluerise | though the SDIO one is quite fast tbh | 18:27 |
| bluerise | PCIe bwfm(4) is faster though | 18:28 |
| mntmn | it would be possible to make a mPCIe card that has a usb controller + m.2 slot on it though | 18:28 |
| mntmn | to regain usb cap | 18:28 |
| swivel | didn't they reel in the heat issues of the librem5 eventually through kernel fixes | 18:28 |
| mntmn | mostly yes swivel | 18:28 |
| mntmn | reform doesn't really have heat issues | 18:28 |
| bluerise | if you ever see those fixes, let me know | 18:28 |
| mntmn | i'm pretty sure it was the cpuidle stuff | 18:28 |
| bluerise | might check if I can use those for $work product as well | 18:28 |
| bluerise | though that one isn't running Linux | 18:29 |
| mntmn | but at some point (a longer time ago), the temperature was much better | 18:29 |
| mntmn | like, there was a change that made it better | 18:29 |
| mntmn | but i don't remember exactly which patches | 18:29 |
| mntmn | but more than a year ago | 18:30 |
| bluerise | actually, if space permitted, you could also just add another mPCIe slot and *only* route USB + SIM card slot to it | 18:35 |
| bluerise | like, get a USB hub with 2 more USB ports. one to the existing mPCIe slot for BT, another one to a new slot which only has USB+SIM for LTE | 18:36 |
| bluerise | but, to be fair, I'm fine with it as it is, I don't need BT/LTE | 18:37 |
| bluerise | having trouble getting the sd2 card detect pin to work, hmhm | 18:49 |
| mntmn | but i'm talking about not redesigning the motherboard ;) | 18:51 |
| bluerise | imxesdhc_card_detect:644: 0 | 18:52 |
| bluerise | I must be doing something wrong | 18:52 |
| mntmn | i can say that card detection does work in linux | 18:53 |
| bluerise | hm, so on the hummingboard pulse, SD2_CD is connected directly to the SoC, which is why it adds a pullup. on the Reform it looks like the motherboard does the pullup to 3.3V | 19:02 |
| bluerise | my mistake, there it is | 19:28 |
| bluerise | imxesdhc_card_detect:644: 1 | 19:28 |
| bluerise | scsibus2 at sdmmc1: 2 targets, initiator 0 | 19:28 |
| bluerise | sd2 at scsibus2 targ 1 lun 0: <SD/MMC, USD00, 0010> removable | 19:28 |
| bluerise | sd2: 30250MB, 512 bytes/sector, 61952000 sectors | 19:28 |
| mntmn | awesome! | 19:31 |
| bluerise | mntmn: any specific requirement for pull request branch names? | 19:40 |
| mntmn | bluerise: nope, whatever you like! | 19:48 |
| mntmn | bluerise: haha, 25$ coupon for you ;) https://twitter.com/crowd_supply/status/1398337735841050624?s=20 | 20:02 |
| mntmn | btw anyone who writes a field report for CS gets $25 credit from them | 20:03 |
| bluerise | Heh. :D | 20:04 |
| bluerise | my 'mod' really isn't worth it a lot, I mean, I only added WiFi, NVMe, and a few uart wires to the outside... but I guess what people can see/touch can be more relatable | 20:05 |
| bluerise | should do a field report once OpenBSD works fine ;) | 20:05 |
| bluerise | mailed Lucas in regards to PCIe | 20:06 |
| bluerise | We really need those int/ext refclk bindings upstreamead | 20:07 |
| mntmn | indeed, thanks for poking | 20:09 |
| mntmn | i posted a patch for it on the list in november (??) or so but it was just poking anatop directly to enable the refclk output, i guess lucas wanted some cleaner way | 20:10 |
| mntmn | but idk how to integrate that into linux clk framework | 20:10 |
| mntmn | that's above my paygrade as dave haynie would say | 20:11 |
| bluerise | https://github.com/openbsd/src/blob/master/sys/dev/fdt/dwpcie.c#L900 | 20:11 |
| bluerise | We also poke anatop directly... | 20:11 |
| mntmn | oh, openbsd has this already! :3 | 20:12 |
| mntmn | so the obvious solution is just to migrate to openbsd ;) | 20:12 |
| bluerise | mntmn: added by yours truly: https://github.com/openbsd/src/commit/6a2b914cbe70933ece2b56f73f6faa3973741400 | 20:12 |
| bluerise | Nah, OpenBSD has other missing stuff. No MIPI-DSI, no etnaviv accel, no suspend/resume (on arm64)... | 20:13 |
| bluerise | but not because of bikeshedding, but because of not enough developers ;) | 20:14 |
| mntmn | hehe | 20:14 |
| bluerise | I told you, I built two products based on i.MX8M (MQ, and MP). :) OpenBSD based, both. | 20:14 |
| mntmn | very nice | 20:15 |
| mntmn | did you ever play with the "big" i.MX8? | 20:15 |
| mntmn | (asking because i never saw one) | 20:15 |
| bluerise | Nope, never got those | 20:15 |
| bluerise | I have an LX2K here | 20:15 |
| mntmn | ah yeah me too | 20:15 |
| mntmn | and the LS1028A of course... | 20:15 |
| bluerise | Looking forward to SolidRun's CN9K, especially the upgraded ClearFog line | 20:16 |
| bluerise | Less powerful than a LX2K, but nice little network appliances indeed | 20:16 |
| bluerise | pcie refclk for pcie2 is always powered on? | 20:21 |
| bluerise | refclk generator seems to have wifi kill switch as output, the the lpc seems to always turn that on? | 20:21 |
| mntmn | as output? | 20:25 |
| bluerise | input to refclk generator is wifi kill switch out, and the switch has PCIE1_PWR_EN which comes from the LPC? | 20:26 |
| mntmn | bluerise: you probably mean PCIE1_PWR_EN | 20:26 |
| mntmn | that is always on | 20:26 |
| bluerise | ok | 20:26 |
| mntmn | it doesn't actually work to turn that off | 20:27 |
| mntmn | it crashes the imx | 20:27 |
| bluerise | heh | 20:27 |
| mntmn | doesn't like pcie cards going away | 20:27 |
| mntmn | maybe a pcie driver thing | 20:27 |
| bluerise | I have an issue when I configure the pcie1... | 20:28 |
| mntmn | what's the issue? | 20:28 |
| bluerise | well, we have different bindings, so without changing the device tree it'll try and use internal refclk for both pcie0 and pcie1 | 20:28 |
| bluerise | in that case pcie1 somehow works, but I have some 'trouble' with NVMe coherency on pcie1, might be something else though | 20:29 |
| bluerise | now I changed the device tree to make sure that for pcie1 external refclk is configured | 20:29 |
| mntmn | pcie1 needs to be internal refclk and pcie2 external | 20:29 |
| bluerise | the NVMe still shows up, but once I hit userland, where some more accesses happen, the machine just hangs | 20:30 |
| - artfwo (QUIT: Ping timeout: 264 seconds) (~artfwo@172.98.75.220) | 20:30 | |
| mntmn | bluerise: do you have it the right way around? | 20:30 |
| bluerise | aah, nah, found it, it's something else binding related | 20:31 |
| bluerise | old bindings had ctrl-id = <0> and ctrl-id = <1> | 20:31 |
| bluerise | linux code does.. | 20:31 |
| bluerise | .#define IMX8MQ_PCIE2_BASE_ADDR 0x33c00000 | 20:31 |
| bluerise | if (dbi_base->start == IMX8MQ_PCIE2_BASE_ADDR) | 20:32 |
| bluerise | imx6_pcie->controller_id = 1; | 20:32 |
| mntmn | ah, i see | 20:33 |
| bluerise | so without ctrl-id set, the second pcie controller driver instance changed the settings of the first | 20:33 |
| + artfwo (~artfwo@2a02:8109:8500:26d0:1559:c14:3676:cb54) | 20:44 | |
| + Neelfyn (uid180106@id-180106.stonehaven.irccloud.com) | 20:58 | |
| bluerise | Funny how when you think it's gonna be easy, it's getting harder instead. Both NVMe and SD card sometimes (too often) return zeroes on read. | 21:01 |
| bluerise | and, is it normal that one battery 'dies' first? battery status showed one at 0.9, rest at 3.* | 21:02 |
| bluerise | at 37% charge total | 21:02 |
| mntmn | kind of, but that sounds extreme | 21:10 |
| mntmn | 0.9 is near death | 21:10 |
| mntmn | when did you last charge? | 21:10 |
| mntmn | also, better charge soon! | 21:11 |
| + scops (~scops@p200300da3721c9000219b8fffe08ddc1.dip0.t-ipconnect.de) | 21:15 | |
| Kooda | The blinking low-battery icon is kind of confusing when you’re looking at the battery status, it shows the top right one as point-something because of the icon redraw ^^' | 21:15 |
| Kooda | It might have been 3.9 here | 21:15 |
| Kooda | But yeah I had some odd behaviour with the battery as well. Status showed me 20% battery remaining, but one battery was at 2.5V, I hastily plugged the charger in. | 21:17 |
| bluerise | Kooda: Ah, that explains it then | 21:19 |
| mntmn | normally it learns where "0%" is after one automatic shutdown when a cell is below <2.5V | 21:21 |
| mntmn | bluerise: ah yeah sorry. i really need to work on the UX on this. | 21:21 |
| mntmn | unfortunately too many other mega important things to do ATM | 21:21 |
| bluerise | yeah, no worries | 21:22 |
| Kooda | Someone else™ could patch it :) | 21:22 |
| mntmn | bluerise: lpc actually switches off when a cell goes below 2.5v | 21:22 |
| mntmn | Kooda: haha yeah | 21:22 |
| Kooda | Ok goo, next time I’ll let it run to auto shutdown then | 21:23 |
| Kooda | good* | 21:23 |
| Kooda | I was afraid it would not stop near 2.5 | 21:23 |
| Kooda | Also, is it normal that I notice a little voltage drop at the end of a charge? I read a bit about that for some chemistry but I don’t know if it also applies to LiFePO | 21:24 |
| mntmn | Kooda: see also https://source.mnt.re/reform/reform/-/blob/master/reform2-lpc-fw/src/boards/reform2/board_reform2.c#L883 | 21:25 |
| mntmn | Kooda: hmm not sure what you mean. maybe it's just the balancing in effect? | 21:25 |
| Kooda | Ah, might be | 21:25 |
| mntmn | i.e. LPC will drain off cell voltage above a certain limit | 21:26 |
| Kooda | I should try to worry a bit less about all that, since these cells are easy to replace. I had so many bad experiences with regular Li-ion that I’m over cautious ^^' | 21:28 |
| bluerise | Yeah, it's really nice that those can just be replaced | 21:34 |
| + odnes (~odnes@109-178-166-252.pat.ren.cosmote.net) | 21:43 | |
| mntmn | Kooda: it's good to be cautious! | 21:44 |
| mntmn | btw if your cells ever really go below 1V and reform doesn't want to charge them, you can probably revive them with a lab power supply (current limited) | 21:45 |
| - artfwo (QUIT: Ping timeout: 264 seconds) (~artfwo@2a02:8109:8500:26d0:1559:c14:3676:cb54) | 21:48 | |
| * sknebel -> can | 21:50 | |
| * can -> sknebel | 21:50 | |
| Kooda | mntmn: just tried charging again: all cells climb to about 3.7V, then the charging stops and the screen shows all cells at 3.3V | 21:50 |
| mntmn | Kooda: ah yeah that's fine | 21:50 |
| Kooda | Are they all getting discharged? | 21:50 |
| mntmn | Kooda: no | 21:51 |
| mntmn | Kooda: they can't actually hold this much charge | 21:51 |
| Kooda | I see | 21:51 |
| mntmn | Kooda: so as soon as the charge voltage is released, they go to "normal" | 21:51 |
| bluerise | Yeah, ack. | 21:51 |
| Kooda | Ah so the supply’s voltage is taken into account when seeing 3.7V? | 21:51 |
| mntmn | Kooda: the charge voltage yes, because when charging, that is the voltage that is measured on the cells... | 21:52 |
| Kooda | Heh indeed ^^ | 21:52 |
| Kooda | Thanks for all the infos :) | 21:52 |
| mntmn | well, that's what this is all about! | 21:54 |
| + artfwo (~artfwo@2a02:8109:8500:26d0:cadc:4e6f:939a:4b59) | 22:00 | |
| - odnes (QUIT: Ping timeout: 264 seconds) (~odnes@109-178-166-252.pat.ren.cosmote.net) | 22:27 | |
| - Neelfyn (QUIT: Quit: Connection closed for inactivity) (uid180106@id-180106.stonehaven.irccloud.com) | 23:11 | |
| - jryans (QUIT: Quit: node-irc says goodbye) (~jryansmat@2001:470:69fc:105::1d) | 23:56 | |
| + jryans (~jryansmat@2001:470:69fc:105::1d) | 23:56 | |
| * natalie- -> natalie | 23:58 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!