**** BEGIN LOGGING AT Thu Oct 26 03:00:02 2017 Oct 26 04:34:14 I've got an older Beaglebone Black that I'm using to control some LEDs over the PRU. I just got a Beaglebone Black Wireless that I'm trying to do the same thing with. I'm using the most recent debian image, and am using a C program using libprussdrv to talk to the PRU. Oct 26 04:35:00 If i enable the /boot/uDev.txt overlay: Oct 26 04:35:01 uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo Oct 26 04:35:01 The the PRU is now responding. Oct 26 04:36:14 However, the pins don't seem to be activated, and the device tree that I was using before is way different with this version, and the slots file doesn't seem to exist in /sys/devices/bone_capemgr.X (this doesn't exist at all) and sometimes it exists in /sys/devices/platform/bone_capemgr/slots, but it doesn't always exist in that folder and I"m not sure why Oct 26 04:36:34 Do I have to use a device tree overlay to enable GPIO pins for the PRU still? Oct 26 04:52:09 Is there a way to temporarily turn off the PWR LED of the BBB via software? I've figured it out for the other four LEDs, but would like to disable the PWR LED so that my room doesn't look like an alien invasion is about to happen when I turn the lights off ;) Oct 26 06:08:46 frostsnow: yes Oct 26 06:09:32 frostsnow: the power led is connected to LDO2 of the power-management IC, and that LDO is (since BBB rev A6 iirc) not used for anything else Oct 26 06:09:40 so it can actually be turned off Oct 26 06:22:58 zmatt: So if I'm understanding this correctly I'm seeing the power-management IC at '/sys/devices/platform/ocp/44e0b000.i2c/i2c-0/0-0024/tps65217-{charger,pmic,bl}/', which means that it's interacted with via i2c, though I'm not yet sure if I can turn it off via 'sysfs' or I need to grok i2c first. Oct 26 06:23:49 '/sys/firmware/devicetree/base/ocp/i2c@44e0b000/tps@24/regulators/regulator@0' is also promising, but looks dangerous to mess around in without a clue. Oct 26 06:26:18 I was gonna offer a simple example using i2c-tools, but for some reason it is being stubborn... even though I know I've done this in the past without any issue Oct 26 06:27:06 * frostsnow begins emerging i2c-tools. Oct 26 06:30:30 oh lol, never mind I was an idiot Oct 26 06:35:35 Bah, i2cdetect tells me to specify a bus found listed by the -l option but then tells me that no such bus exists :( Oct 26 06:36:28 don't use i2cdetect Oct 26 06:36:34 basically... ever Oct 26 06:36:47 i2c is not a discoverable bus Oct 26 06:37:18 sudo i2cget -f -y 0 0x24 0x16 Oct 26 06:37:34 that will return which power outputs are enabled, should be 0x7f Oct 26 06:37:41 bit 0 is the power led Oct 26 06:37:56 writing that register however requires a slightly special procedure Oct 26 06:37:57 Yup, got 0x7f Oct 26 06:38:35 (I'd also like to be able to toggle it back on, FWIW, making 'dimon' and 'dimoff' scripts) Oct 26 06:39:22 why not dim {on,off} ? :P Oct 26 06:40:13 Clearly, most of my brain power was spent with the revelation that I needed a 'dimoff' script after I'd turned everything off ;) Oct 26 06:41:38 Funny thing, when trying to name the script I considered how I can tell people to be quiet if they're making noise, but I don't really have a word for telling people not to emit light, as they usually don't, unless they are on fire. Oct 26 06:42:26 https://pastebin.com/nJ1Y3MqF Oct 26 06:44:06 Well I didn't mean that you had to write the script for me, but thank you! Oct 26 06:44:21 oh, and needless to say, try to avoid making typos when dealing with the pmic ;) Oct 26 06:45:31 Otherwise it will be emitting an "on-fire" kind of light? :P Oct 26 06:45:45 hehe Oct 26 06:47:06 and don't do this on a beaglebone white or very old beaglebone black (older than rev A6) Oct 26 06:48:19 Notes Oct 26 06:48:20 Noted* Oct 26 06:54:20 \o/ it works, thanks again zmatt Oct 26 06:57:26 :D Oct 26 06:57:52 of course it would also be possible to do this more elegantly via the kernel Oct 26 06:58:40 iirc you can declare a regulator-controlled LED in Device Tree, so then the power led would appear in /sys/class/leds like the others Oct 26 07:01:16 The kernel would then send the commands via i2c? Also, the main thing is to make sure that the PMIC is the TPS-65217 and not some other, chip, right? ...or are there other factors? Oct 26 07:02:02 !s/,// Oct 26 07:02:17 my commands specifically assume a tps65217 where LDO2 connects to the power led and nothing but the power led, and the remaining outputs are always enabled Oct 26 07:03:16 and yeah, if it's done the nice way then the tps65217 kernel driver will take care of all the i2c Oct 26 07:03:37 Would it be useful if I did a small blog on this, or do you think they're too many assumptions built into the i2c command and it might cause more headaches down the road? Oct 26 07:05:02 well the assumptions built into the i2c command are based on the hardware design of the beaglebone, so those are not suddenly going to be invalid Oct 26 07:06:02 and one icky thing is that I use two separate invocations of i2cset, which means there's a race condition possible if the kernel decides to communicate with the pmic right inbetween those two Oct 26 07:06:26 that can be fixed by making a tiny program that uses the i2c api directly Oct 26 07:07:47 doing it the nice way via DT is probably not very hard either, but still more hassle Oct 26 07:07:54 script < tiny program < kernel driver Oct 26 07:08:50 the kernel driver already exists (kernel module "leds-regulator") Oct 26 07:09:03 kernel driver enhancement* :P Oct 26 07:09:18 Though I assumed the driver would involve the tps65217 Oct 26 07:09:19 no, no programming is required, just a DT declaration Oct 26 07:09:30 the tps65217 already has a driver too of coruse Oct 26 07:11:07 I guess I don't understand the interaction between the LED-driver and the TPS-driver, since the LED is somehow related to the TPS. Oct 26 07:12:03 AIUI, device trees are a way for ARM devices to declare hardware to the Linux kernel Oct 26 07:12:18 describe it yes Oct 26 07:12:35 e.g. you can describe that there's a led connected to one of the regulators of the tps65217 Oct 26 07:14:42 oh, wow never mind Oct 26 07:14:43 Ah, then the kernel would know (hopefully) how to handle that LED based on its knowledge of the tps65217 and leds-regulator Oct 26 07:14:55 it looks like the leds-regulator driver has never been DTified Oct 26 07:15:07 lame Oct 26 07:16:26 Womp. So it'd need a full-on tps65217 patch? Oct 26 07:16:39 no, the leds-regulator driver just needs a tiny bit of revision Oct 26 07:17:01 at least, i think Oct 26 07:17:05 I'm still looking at it Oct 26 07:17:22 yeah, no, right now it requires platform data Oct 26 07:17:31 it can't get its config from DT Oct 26 07:18:42 Hmm Oct 26 07:18:45 looks to me like it should actually be pretty easy to fix Oct 26 07:19:20 here's how much config the driver has -> http://elixir.free-electrons.com/linux/v4.11/source/include/linux/leds-regulator.h#L41 Oct 26 07:20:29 oh wait a minute Oct 26 07:21:07 ...do I want to know what an a780_vibrator is? o.o Oct 26 07:21:33 I didn't even look at the example, I was just pointing at the struct Oct 26 07:22:23 Yeah, I was searching for more context and found the example amusing Oct 26 07:35:40 yeah, if I remove the "always-on" flag on ldo2 then the kernel automatically shuts it off since it's unused as far as it knows... if there were a sysfs attribute to force a regulator on then that would also have provided a nice way to toggle it, but alas there doesn't seem to be one Oct 26 07:36:18 there's a reg-userspace-consumer driver but it has the same problem as leds-regulator: platform data required, no DT config supported Oct 26 07:42:10 It might make a good feet-wetting project, though now I'm fully confused as to which part of the kernel ought to be handling it :P Oct 26 07:43:28 the leds-regulator driver represents the led, as device, and holds a reference to a regulator. it implements requests to toggle the led by toggling the regulator Oct 26 07:44:18 the regulator in this case would be &ldo2_reg -> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/tps65217.dtsi#L41-L44 Oct 26 07:47:36 So those were the 8 things under '/sys/firmware/devicetree/base/ocp/i2c@44e0b000/tps@24/regulators/' Oct 26 07:48:02 6* Oct 26 08:02:35 Going to bed now. Project is probably too deep for me yet, but I'll take a stab at it next Wednesday. Night! Oct 26 08:44:38 * karanlearns[m]1 sent a long message: karanlearns[m]1_2017-10-26_08:44:37.txt Oct 26 08:44:58 how do i enable the ttyUSB0 port Oct 26 17:01:45 karanlearns[m]1, check for /dev/ttyACM0, first. it's another possible name. Oct 26 17:01:58 otherwise, is this on the beaglebone side or on your computer? Oct 26 21:26:42 Hi, can you please me how to change beaglebone black wallpaper? Oct 26 21:27:48 Please? Oct 26 21:28:47 does anyone known how to change BBB wallpaper? Oct 26 23:05:25 what do you mean "wallpaper" Oct 27 00:15:45 BeagleBone and Radio/Modems! Oct 27 02:32:28 rar_rar: desktop background image Oct 27 02:39:00 Hey...the damn XBee radios have a 2mm pin spacing. The damn breadboard is 2.5 mm in spacing. Now, I must reconvene at a later date on my radio control of the Motor Bridge Cape and the BBB. Boo! Oct 27 02:39:52 ... Oct 27 02:40:27 I thought I could just use a f to m jumper wire. No go. The damn pins are too tiny. Oct 27 02:40:40 <<<< has issues Oct 27 02:48:22 $2.95 solution! Geaux BBB! **** ENDING LOGGING AT Fri Oct 27 03:00:01 2017