|
Got my wifi router's power monitor chip up and running on i2c-gpio! Once I get native i2c working, I'll crank up the sample rate to 1 kHz. I should be able to see the power signatures of short duration events like web page loads and client associations. It can also do long-term monitoring for making cool-looking (tho marginally useful) graphs. I wonder if any of the RGB casemod nerds have gotten i2c dma working on qualcomm?
|
# ? Apr 29, 2024 21:32 |
|
|
# ? May 22, 2024 06:29 |
|
vulkan 1.0 was also released in february ... february 2016 looks like vulkan is up to version, uh, 1.3.283? what exactly are they doing over there
|
# ? Apr 29, 2024 22:15 |
|
I2C fixed
|
# ? Apr 30, 2024 02:57 |
|
great job!!!
|
# ? Apr 30, 2024 03:40 |
|
The next big question is do I take this ISL28022 driver in progress and finish it off, and try to get it merged into hwmon? This would go into the mainline Linux kernel, not just OpenWrt. What's the open source etiquette re. taking someone's 98% finished work, and doing the final polishing to get it merged? ryanrs fucked around with this message at 16:32 on Apr 30, 2024 |
# ? Apr 30, 2024 16:29 |
|
Generally you reach out to the person and ask if you can take over the work. When you submit it upstream mention them in the commit message as well.
|
# ? Apr 30, 2024 17:46 |
|
Dear Sir, I am writing to you from the non-shitposting(?) linux thread in the OS poo poo-posting subforum of the dead comedy website SomethingAwful.com. I would like to touch your source code.
|
# ? Apr 30, 2024 22:05 |
|
ryanrs posted:Dear Sir, I am writing to you from the non-shitposting(?) linux thread in the OS poo poo-posting subforum of the dead comedy website SomethingAwful.com. I would like to touch your source code. your source repository is a piece of poo poo
|
# ? Apr 30, 2024 22:05 |
|
spankmeister posted:every source repository is a piece of poo poo
|
# ? Apr 30, 2024 22:10 |
|
plz don’t touch my source, it’ll trigger a full rebuild
|
# ? Apr 30, 2024 22:50 |
|
ryanrs posted:Dear Sir, I am writing to you from the non-shitposting(?) linux thread in the OS poo poo-posting subforum of the dead comedy website SomethingAwful.com. I would like to touch your source code. To Whom It May Concern, Greetings from the Linux non-shitposting thread in the OS shitposting forum of the dead and buried comedy site Something Awful. I see you have almost finished your ISL28022 driver, [borat voice] very nice! However, it is not finished, which is not so nice. I will finish it for you [broat voice] i like! P.S. I will credit you Sincerely, ryanrs
|
# ? May 1, 2024 00:16 |
|
ryanrs posted:The next big question is do I take this ISL28022 driver in progress and finish it off, and try to get it merged into hwmon? This would go into the mainline Linux kernel, not just OpenWrt. actually looks like a few people worked on it (unless those are reviewers?). i wouldn't worry about it, just credit where due e: ah yeah they are reviews. idk. just email the guy and ask, i mean, it is a mailing list lol e2: lol it looks like he made his personal site in openoffice or something Beeftweeter fucked around with this message at 00:22 on May 1, 2024 |
# ? May 1, 2024 00:18 |
|
Beeftweeter posted:To Whom It May Concern, To Whom it May Concern, All your source code are belong to us. You have no chance of mainline merging make your time. For great compiling. P.S: YOSPOS BITCH!!! Sincerely: Ryanrs FlapYoJacks fucked around with this message at 00:42 on May 1, 2024 |
# ? May 1, 2024 00:39 |
|
Beeftweeter posted:Greetings from the Linux non-shitposting thread this part is getting increasingly implausible
|
# ? May 1, 2024 01:20 |
|
What is a good online tool for charting a long time series, like 100k+ points? I want to be able to pan/scroll around the zoomed out view, then zoom in tight to see the power spikes from individual wifi packet transmissions.
|
# ? May 1, 2024 01:32 |
|
Power signature of an ssh login (over wired ethernet, radios disabled). This is from CPU use during crypto authentication.
|
# ? May 1, 2024 06:26 |
|
I wonder if the resolution is good enough to do side channel analysis
|
# ? May 1, 2024 06:42 |
|
1 mA resolution at 2 kHz.
|
# ? May 1, 2024 07:27 |
|
ryanrs posted:1 mA resolution at 2 kHz. probably not then, but interesting nonetheless
|
# ? May 1, 2024 07:29 |
|
fresh_cheese posted:bummer. guess its bugzilla/launchpad/jira time i fixed it, turns out LUKS was working fine, but boot was failing somewhere because i didn’t have linux-modules-extra installed for the latest kernel annoyingly without it I couldn’t get networking so i installed an old kernel from liveusb, then used that to install all the missing packages
|
# ? May 1, 2024 15:08 |
|
oh no blimp issue posted:i fixed it, turns out LUKS was working fine, but boot was failing somewhere because i didn’t have linux-modules-extra installed for the latest kernel rescue media FTW good save! YOSPOS BTICH
|
# ? May 2, 2024 00:15 |
|
My OpenWrt router has a lot of gpio lines that are not being used properly, or even initialized. What is the proper, correct, current Linux way of handling gpios that do things. Not uncommitted user gpios, but real concrete stuff like resetting the bluetooth radio, or enabling downstream PoE, or knowing whether you're connected to AC power or not. For example, I want to implement this logic at boot time: enable_pse = (is_ac_power || is_8023at); i.e. don't turn on downstream PoE if you're on a low-power 802.3af upstream port. I can do this by poking sysfs gpio with a shell script, but (1) that's really late in the boot process, (2) sysfs gpio is deprecated. And of course the user is allowed to turn downstream PoE on and off, so maybe there are persistent settings in uci or something. Am I really supposed to write a little kernel driver to turn downstream PoE on and off? Is this supposed to be a "platform driver" or what? I am not looking for a hack solution. What is Best Practice for this kind of GPIO usage in 2024, for something I might want to get merged upstream? e: this would be for kernel 6.6 ryanrs fucked around with this message at 06:57 on May 2, 2024 |
# ? May 2, 2024 06:55 |
|
spankmeister posted:I wonder if the resolution is good enough to do side channel analysis wasn't that how they found the hack in xz utils
|
# ? May 2, 2024 07:25 |
|
Tunicate posted:wasn't that how they found the hack in xz utils I think they were just measuring how much time certain operations took, and the xz stuff took a lot more time than it usually does. Measuring power is a different beast but I bet it could achieve similar results especially if people use aggressive cpu frequency changes.
|
# ? May 2, 2024 07:36 |
|
ryanrs posted:
pretty sure I saw a lot of commercial code just run cron jobs that check gpio pins over bash and take appropriate action so anything else would be better
|
# ? May 2, 2024 07:38 |
|
Ugh, searching for this stuff is super annoying because you get five paragraphs in before you realize you're reading obsolete poo poo from 1999. I don't want to write a driver for this, but gpio-hog in the device tree is not enough.
|
# ? May 2, 2024 07:45 |
|
Anyways, taking all of this seriously... I don't have a lot of GPIO experience beyond just raspberry pi. But I'm looking at the stuff in the kernel documentation: https://www.kernel.org/doc/Documentation/gpio/gpio.txt Assuming that the gpio hardware:
You can just use select() or poll() on the gpio as it is exposed on the filesystem in a userspace application. This leads to the simplest code that uses blocking so 0% CPU is used while waiting. And since the code is all in userspace, it's easier to debug and manage. You don't really want to put "business logic" in a kernel driver that turns downstream PoE on and off unless it's the only way to address your use case because it can lead to dependency issues and the kernel doesn't really expose the right interfaces within the kernel itself to address that use case. Personally, I would be constantly worried about whether I hold the correct mutexes or if other context information is relevant.
|
# ? May 2, 2024 07:58 |
|
Are you describing the deprecated sysfs gpio api? I think the current design uses a shitload of character device ioctls and a userspace library to hide the gross inner workings. e: yes this a serious question, here is the motivation for it: OpenWrt instructions to enable downstream PoE code:
1) Uses numbers not names, and the numbers aren't even fixed gpio line numbers. The number is unstable between kernel versions (changed when OpenWrt migrated from 6.1 to 6.6). The new number is 546 and the above wiki instructions no longer work. 2) The gpios need to be configured at startup (setting direction, drive strength, polarity, etc). This is not being done on the AP-303H and some outputs aren't configured as outputs until first use. 3) I want to let users turn PoE on and off, but not change basic pin configuration like turning it into an input. Also this is standard gpio stuff that literally every single computer needs to do. Every computer ever made has some random pins that need to be configured at system startup. How can it be so hard? Shell script + sysfs is looking pretty good, tbh. e2: This works and should be stable: code:
ryanrs fucked around with this message at 16:22 on May 2, 2024 |
# ? May 2, 2024 15:35 |
|
ryanrs posted:Are you describing the deprecated sysfs gpio api? I think the current design uses a shitload of character device ioctls and a userspace library to hide the gross inner workings. does the default busybox support e.g. quote:GPIO_POE=$((GPIO_BASE+34)) ? if yes then i probably won't need to do a compile, thats the kind of thing i was talking about in the other thread
|
# ? May 2, 2024 16:23 |
|
Yes, busybox supports $(()) arithmetic. At this point, I can do everything I want in user mode with a dozen lines of code. It'd be crazy to write a kernel driver when the script is working. Anyway, I just edited the OpenWrt wiki page and updated 446 -> 546. Good enough.
|
# ? May 2, 2024 16:42 |
|
ryanrs posted:Yes, busybox supports $(()) arithmetic. what about double-bracketed tests with variable replacement? iirc that was the primary reason i wanted a custom busybox, and while it does support that kind of thing it at least used to require editing the config header/a custom build i'd suppose if it supports double parenthetical arithmetic then it probably does
|
# ? May 2, 2024 17:28 |
|
Tunicate posted:wasn't that how they found the hack in xz utils the guy was microbenching postgres with debian unstable , and he noticed ssh logins took longer and investigated now imagine if the exploit code was better written or was just time bombed to not run until 2025
|
# ? May 2, 2024 17:40 |
|
ryanrs posted:Are you describing the deprecated sysfs gpio api? I think the current design uses a shitload of character device ioctls and a userspace library to hide the gross inner workings. Yeah, a much more resilient and mature solution would be to actually create a file on sysfs or something which only loads when the relevant device is detected and does the GPIO work. And also to expose a different file which you can read in order to find out the kind of port that PoE is connected to in order to see if it’s safe to be enabled. But it’s a lot of work to write the driver, and even more work to keep it maintained by forward porting it to new kernel releases
|
# ? May 2, 2024 17:52 |
|
Beeftweeter posted:what about double-bracketed tests with variable replacement? iirc that was the primary reason i wanted a custom busybox, and while it does support that kind of thing it at least used to require editing the config header/a custom build Like this? code:
|
# ? May 2, 2024 17:55 |
|
Tunicate posted:wasn't that how they found the hack in xz utils not really no, but timing side channel attacks exist yes
|
# ? May 2, 2024 18:19 |
|
ryanrs posted:Are you describing the deprecated sysfs gpio api? I think the current design uses a shitload of character device ioctls and a userspace library to hide the gross inner workings. sometimes updating the wiki to call something deprecated drags all the dweebs out of the dark to yell at either you or each other about what the correct way is now, if you want an answer faster
|
# ? May 2, 2024 18:21 |
|
No, I'm just going to write patches against the system config scripts, using the deprecated sysfs api. I don't even need to submit the patches. I can use image builder with official builds and patch the scripts through uci-defaults or during the deployment process. If I end up with something reasonably clean, I'll submit the patches, but I don't actually need them to be merged.
|
# ? May 2, 2024 18:41 |
|
ryanrs posted:Like this? it seems like that'd be fine, but ehh now that i'm not in a moving car i can elaborate better lol at the time (~10 years ago lol) i was using those kinds of constructs for ffmpeg workflows, i doubt i'll be doing that much now but i might, idk. so this is just an off the top of my head example of something i might try: code:
but i literally just banged this out here, so there might be a missing fi statement or something, idk, i didn't check it obviously. it's just an example. i intentionally mixed "-eq" and "=" operators, mixed "[[" and "[" constructs — usually when i'm doing something like this i just go for functionality over form — but that does trip up some interpreters sometimes (especially dash, which simply doesn't have double bracket constructs anyway) sometimes i need to do arithmetic within them, sometimes i don't, etc., so when i was compiling openwrt and busybox i just threw in the kitchen sink. back then it supported all of that, it just needed to be enabled at compile time (which it didn't do by default) also somewhat relatedly, i usually try to avoid "[" constructs on a real machine since that usually calls the "[" binary, whereas "[[" constructs use a builtin but since we're talking about busybox here, it's all the same binary — other than the extended functionality afforded by double bracket constructs i suppose there's no benefit to using one over the other anyway. right? e: readability Beeftweeter fucked around with this message at 19:35 on May 2, 2024 |
# ? May 2, 2024 19:26 |
|
root@OpenWrt:~# opkg install bash Package bash (5.2.21-r1) installed in root is up to date. takes about 500k of space
|
# ? May 2, 2024 19:34 |
|
|
# ? May 22, 2024 06:29 |
|
ryanrs posted:root@OpenWrt:~# opkg install bash lmao good point
|
# ? May 2, 2024 19:35 |