**** BEGIN LOGGING AT Thu Jun 11 02:59:59 2020 Jun 11 17:25:31 if I compile my own dbto file to open up my PRU pins I can just add it to uEnv.txt so it gets pulled in at boot ? Jun 11 17:25:51 i am using Kilobaser to make one Jun 11 17:36:07 using what? Jun 11 17:36:27 I googled that and the only thing I found is some DNA synthesis machine Jun 11 17:38:46 maybe he's trying to configure a beagle dog Jun 11 17:38:49 and if you want to configure PRU pins by default you can indeed just use an overlay that just adds a pinmux node to pruss (and disables conflicting cape-universal nodes) Jun 11 17:47:48 https://www.kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator Jun 11 17:48:03 was what I was using to make a dbto with 4 pins open Jun 11 17:55:16 MattB0ne: that seems completely broken for me Jun 11 17:55:31 and overall looks awful Jun 11 17:56:49 my suggestion would be to grab my https://github.com/mvduin/overlay-utils Jun 11 17:57:03 put something like https://pastebin.com/raw/jEWrW9vX into a file named pru-pins.dtsi Jun 11 17:57:27 (adjust for the pru pins you want to use and their direction) Jun 11 17:57:38 then "make pru-pins.dtbo" to produce an overlay Jun 11 17:57:51 ok Jun 11 17:57:58 lol Jun 11 17:58:35 if using uio-pruss, also "make uio-pruss.dtbo" as replacement for the default AM335X-PRU-UIO-00A0.dtbo which is badly written in a way that makes it impossible to add pinmux to it using another overlay Jun 11 18:01:57 btw, one caveat about pru output pins: they have random values until software initializes r30 Jun 11 18:02:16 (but there are ways to avoid that, if needed) Jun 11 18:02:55 (simplest being using config-pin to configure pru output pins _after_ initializing pruss instead of configuring the pins early using config-pin or an overlay) Jun 11 18:07:32 yeah I dont want to do it every time and this application is the only thing I will do with this board Jun 11 18:08:09 you don't need to explain the motivation for using an overlay, I'm just pointing out a caveat Jun 11 18:08:24 what is the least painful way of getting info out of PRU Jun 11 18:08:32 (which is also solvable while still using an overlay, but slightly trickier) Jun 11 18:08:41 that's too vague to be answerable Jun 11 18:09:06 so as I am creating this encoder I would like to get a printout of the reading Jun 11 18:09:32 but once I have this running in the PRU I would need some mechanism to see what is going on Jun 11 18:09:44 have the encoder write the current position to pru memory (which it needs to do anyway), read it from there Jun 11 18:14:27 e.g. using py-uio: https://pastebin.com/ccCEtFwF Jun 11 18:21:49 decoder I mean, the encoder is the piece of hardware stuck to your motor :P Jun 11 19:07:44 zmatt: On a whim I dump mounted in the script run by the systemd-poweroff drop-in you did yesterday. Even though it has umount.target in After, all are still mounted. Is this normal? Jun 11 19:08:40 Maybe the deafult systemd-poweroff doesn't have that and I think it does for some reason, for instance. Jun 11 19:09:09 that -> umount.target in After. Guess I could stick it in the drop-in to be sure? Jun 11 19:11:59 Ragnorok: what filesystems were you expecting to be unmounted at that point? Jun 11 19:16:10 All I guess, given "umount.target". Other than saying it's to umount all file systems there's not much in that file, and umountfs.service points to /dev/null. I haven't determined what that means. Jun 11 19:18:26 umount.target works by mount units have an automatic Conflicts=umount.target Jun 11 19:18:38 Ah. Jun 11 19:19:11 but not / obviously, nor certain special filesystems Jun 11 19:20:04 Why would it be in After then? I feel like I'm missing something. I've been reading so much about systemd it's all blurring together. lol Jun 11 19:22:40 also, what has After=umount.target ? Jun 11 19:23:09 ah Jun 11 19:23:21 /lib/systemd/system/systemd-poweroff.service. I'm under the impression the drop-in is modded that. Jun 11 19:23:33 what do you mean "Why would it be in After then?" ? where else would it be? Jun 11 19:24:08 systemd-poweroff.service obviously needs to be ordered After anything that needs to happen before poweroff Jun 11 19:24:51 (more specifically it has Requires= and After= on it) Jun 11 19:25:30 I thought conficts was like a mutex on a target. I wouild not expect a mutex-like object to make sense in After. That implies I don't understand conflicts, but that's fine. I'm sure I'll read more about it. Jun 11 19:27:03 umount.target is ConflictedBy e.g. run-user-1000.mount Jun 11 19:27:23 so when systemd-poweroff.service Requires umount.target, this will stop run-user-1000.mount Jun 11 19:27:54 So I didn't understand Conflicts. Cool. Jun 11 19:28:29 Conflicts just does what it says: it indicates the unit conflicts with another, hence they become mutually exclusive Jun 11 19:29:28 Right. Where is where I got mutex-like behaviour from. But I didn't recall it would stop things. I thought it only prevented simo execution. Jun 11 19:30:39 no, it'll stop Jun 11 19:31:10 that's also how shutdown works in general: systemctl show -p ConflictedBy shutdown.target Jun 11 19:32:33 Neat. I stumbled across more systemctl stuff all the time. Jun 11 21:42:25 zmatt: I am looking at your google sheet Jun 11 21:42:41 and I wanna use P8.20 and P8.21 for PRU1 Jun 11 21:42:45 its in purple Jun 11 21:42:50 and you have eMMCclk Jun 11 21:43:04 and eMMC cmd in purple Jun 11 21:43:11 does that mean I would break something ? Jun 11 22:05:54 MattB0ne: P8.03-06 and P8.20-25 are in use by eMMC and cannot be used for other purposes Jun 11 22:09:34 (unless you boot from SD card instead of eMMC, enable the eMMC's reset pin in its OTP configuration, and disable eMMC via /boot/uEnv.txt. you'd also want to make sure P8.43 is pulled low with a resistor to ensure bootrom doesn't try to load u-boot from eMMC) Jun 11 22:46:23 damn Jun 11 22:46:59 always something Jun 11 22:47:18 is there a simple way of porting my filesystem from my eMMC to an SD card Jun 11 22:47:21 without starting over Jun 11 23:14:43 MattB0ne: why not just use the pru pins on P9 ? https://pastebin.com/raw/XPaY9xF8 Jun 11 23:16:00 if pru1 is only going to control the pru ecap (assuming pru0 is the decoder) then you don't really need any direct pru1 in/out pins Jun 11 23:17:39 I rebuilt openssl and then realized that the plugin for AF_ALG was a separate thing Jun 11 23:17:48 oops Jun 11 23:19:16 MattB0ne: in necessary addition I/O options are available too: edio on P9.17/18 can be used by either pru, and if necessary the pru cores can also access the main gpio controllers and thus access all of the BBB's GPIO (albeit at a performance cost) Jun 11 23:19:23 *if necessary, additional Jun 11 23:27:01 MattB0ne: and yeah it is possible to copy the contents of eMMC to SD card, but I'd regard that as last resort Jun 11 23:29:58 I will end up needing both PRUs Jun 11 23:30:26 after I use the cape PRU1 only has P8_20 and P8_21 open Jun 11 23:30:36 trying to work around this damn lcd panel Jun 11 23:30:44 painted myself into a corner Jun 11 23:30:58 and P9.26 Jun 11 23:31:09 and the other I/O options I mentioned Jun 11 23:31:20 what's pru1 going to do that requires fast direct I/O ? Jun 11 23:38:12 PRU0 is the decoding but that one is ok Jun 11 23:38:22 PRU1 will have to drive the eCAP Jun 11 23:38:44 and interface with the OS Jun 11 23:39:01 also the UART Jun 11 23:39:08 my control loop will be on PRU1 Jun 11 23:39:53 okay, in other words you don't need any direct I/O pins on pru1, as I assumed Jun 11 23:40:23 ecap and uart are both on P9, interfacing with the OS doesn't involve pins at all Jun 11 23:42:38 the UART for the PRU is accessed via memory? Jun 11 23:42:52 i guess the only other thing I would want fast access to is my load cell Jun 11 23:43:44 note about "fast" vs "slow" in this context.. "slow" would still be only a fraction of a microsecond Jun 11 23:44:59 pru direct I/O pins are just for tying pins directly to PRU registers (r31 for input, r30 for output) Jun 11 23:45:16 allowing super fast access Jun 11 23:46:02 this has nothing to do with peripherals like eCAP or UART, which have their own pinmux options and are controlled by software via memory-mapped registers (like all peripherals) Jun 11 23:46:32 similar to the example I gave for eCAP Jun 11 23:50:16 ok **** ENDING LOGGING AT Fri Jun 12 02:59:58 2020