**** BEGIN LOGGING AT Sat Oct 03 02:59:57 2020 Oct 03 03:05:47 inserting __delay_cycles(1); into the top-level loop reduces the interval of the spurious interrupt to once every 25 cycles Oct 03 03:08:35 wtf, putting the delay before clearing the interrupt (https://pastebin.com/N9h3CaE6) causes a spurious interrupt every other interrupt (https://pastebin.com/N18smBWi) Oct 03 03:08:45 in timestamp you only are incrementing the second whenever the rollover happens (i remember reading that earlier) Oct 03 03:08:47 what the f is going on here... that's the exact opposite of what I had expected Oct 03 03:10:01 renrelkha: .... yes, and? Oct 03 03:10:19 (note again that timestamp() works correctly, seconds() is buggy) Oct 03 03:16:06 there's something really broken going on with eCAP's interrupt status flags Oct 03 03:17:29 i apologize i do not completely understand everything that is happening, i am studying. i do not see anything that tells me for sure that the timestamp() is fine (other than you saying so.lol) it appears to me that seconds is getting saved by the pru into a memory space that the python can read? and the same the timestamp struct. then they python is reading those and outputting what they contain. from the output it could be that seconds is Oct 03 03:17:29 incremented too many times or that timestamp.s is not incremented enough Oct 03 03:17:59 timestamp.s is incremented correctly, if you run the script you can easily see that Oct 03 03:18:36 and it shows that seconds jumps by 2 even though python polls it at a very high rate Oct 03 03:21:24 yeah, I've just added an explicit test in the pru code to check whether the interrupt flag is still set right after clearing it, and that's indeed what's happening Oct 03 03:22:08 it's like it sometimes ignores the write the ECCLR Oct 03 03:23:04 *to ECCLR Oct 03 03:26:07 I'm actually seeing a whole bunch more deviations between the ecap's interrupts and how they are documented to work in the TRM Oct 03 03:27:39 yay, hardware bugs \o/ *sigh* Oct 03 03:31:49 bugs. Nice. Oct 03 03:33:25 outside of knowingly understanding the bug(s), what errors are reported? Oct 03 03:33:42 ? Oct 03 03:34:04 I thought the errors/bugs you were receiving were noticeable. Oct 03 03:34:18 its like a clock that is supposed to go tick tock Oct 03 03:34:26 but sometimes misses a tick or tock Oct 03 03:34:31 I get it. Okay. Oct 03 03:35:00 or rather, it's telling me 1 second has passed and sometimes _immediately_ tells me again that one second has passed Oct 03 03:35:22 yes sorry Oct 03 03:35:37 but yeah, sometimes missing a tick would be equally annoying Oct 03 03:36:20 oh well, easy workaround: don't use the interrupt, use code like timestamp() instead (even if you don't care about the nanoseconds and only want a seconds counter, though the function can be simplified in that case) Oct 03 03:37:21 so, when you call the irq, you are still receiving a counter that states one second has passed. Oct 03 03:37:22 Okay. Oct 03 03:37:37 https://pastebin.com/9Q5rvZ9W am i correct in my understand that the pru interrupt is being initiated by like 9 Oct 03 03:37:38 ... no. Oct 03 03:37:41 @set_ Oct 03 03:37:47 Oh. Oct 03 03:37:54 line Oct 03 03:38:31 renrelkha: that line configures ecap to pwm mode with a period of 200000000 cycles (which is 1 second) Oct 03 03:39:16 but from that point on it is triggering once per second Oct 03 03:39:22 that point Oct 03 03:39:51 since the interrupt indicates the pwm counter has wrapped Oct 03 03:40:28 i initially meant 'that point' as line 9 but after reading more does the pwm actually start at line 24 Oct 03 03:40:39 no Oct 03 03:41:16 line 24 starts the pru core Oct 03 03:41:51 (core 0 specifically) Oct 03 03:42:14 What board am335x or am5729? Oct 03 03:42:17 well at what point is it staring to put out the pwm pulses Oct 03 03:42:27 line 9 Oct 03 03:43:50 I mean, ignoring that the no pin is muxed to pru ecap mode and the duty cycle is 0 so you wouldn't see any actual pwm pulses regardless Oct 03 03:43:51 so there will be some amount of time before the pru sees the first pulse which will not be the first pulse output by the pwm Oct 03 03:44:14 note that the pwm output is irrelevant, it is not being used Oct 03 03:44:49 is that not what is triggering the irq which in seconds() is whats making it increment ? Oct 03 03:44:54 no Oct 03 03:45:02 what the fuck Oct 03 03:45:02 05:39 <@zmatt> since the interrupt indicates the pwm counter has wrapped Oct 03 03:45:39 i.e. when the counter rolls over from 199999999 to 0 Oct 03 03:46:16 that should happen for the first time 1 second after executing line 9 Oct 03 03:47:14 so the spurious initial irq is also a bug (perhaps related, hard to say), but that is separate from periodically getting a duplicate irq Oct 03 03:47:51 i guess i do not understand what is causing the CT_ECAP.ECFLG to be set Oct 03 03:47:58 05:45 <@zmatt> i.e. when the counter rolls over from 199999999 to 0 Oct 03 03:48:18 that is what sets bit 6 of ECFLG Oct 03 03:48:34 like that just happens Oct 03 03:48:46 ... that's the purpose of the interrupt Oct 03 03:48:51 or there is some piece of code here Oct 03 03:49:38 the purpose of interrupts is for hardware signalling to software that certain events have happened Oct 03 03:49:59 line 9 of the python is what is causing the interrupt to be triggered ( 1 second later then every 1 second thereafter) Oct 03 03:50:01 ? Oct 03 03:50:17 line 9 is configuring and enabling the hardware (ecap) Oct 03 03:51:02 after which it performs its task, which is mostly just incrementing a counter until it hits a configured maximum and then resetting it to zero Oct 03 03:51:47 and outputting a signal whenever that counter is >= some other value you configure, thus yielding a PWM output, but I'm not using that functionality here Oct 03 03:53:42 so as a side effect of the pwm output you are getting a interrupt Oct 03 03:54:09 or a side effect of initializing the pwm Oct 03 03:54:17 * zmatt sighs Oct 03 03:54:24 Mailbox! Oct 03 03:54:25 man i am sorry Oct 03 03:54:27 Use a mailbox! Oct 03 03:54:33 set_: shut the fuck up. Oct 03 03:54:37 ha. Okay. Oct 03 03:55:26 like, I have this || much patience left, this is a really bad time to be interjecting your random nonsense Oct 03 03:55:38 Fine. Okay, I will chill out. Oct 03 03:55:57 You are right. I do not have a clue as to what you guys are doing now. Oct 03 04:01:51 renrelkha: oversimplification of what the eCAP hardware does (or is supposed to do anyway) in PWM mode: https://pastebin.com/E0wMDHJF Oct 03 04:02:30 the whole block of code should be understood as happening instantaneously, so if ACMP == 0 the pwm output pin never becomes high Oct 03 04:03:24 (also "every 5 ns" is for PRU ecap, the other three eCAPs run at 100 MHz hence for those it's every 10 ns) Oct 03 04:14:03 i find this online to explain to me better The basic idea is the timer counts up by 1 every cycle (PWM mode is enabled in ECCTL2). When the counter reaches the value in the APRD (period) register, it resets and triggers a "compare equal" interrupt (as controlled by ECEINT). Thus, interrupts will be generated with the period specified Oct 03 04:14:30 yep Oct 03 04:15:42 that is because of using the pwm Oct 03 04:15:47 according to the TRM, enabling the interrupt in ECEINT should not be necessary for getting the bits set in ECFLG (just for generating a pulse on eCAP's interrupt output), though I've discovered that that's not how it actually behaves Oct 03 04:16:22 I don't know what you mean by that Oct 03 04:16:42 but the pwm output pin itself is controlled separately, albeit by the same events Oct 03 04:17:18 the timer is running and triggering the interrupt only because the pwm is being utilized Oct 03 04:17:21 ? Oct 03 04:17:29 however, if ACMP == 0 (zero duty cycle) the pwm output pin has no pulses (remains constant low), while both interrupts do get signalled Oct 03 04:18:06 and the value 200000000 is the APRD ? Oct 03 04:18:09 the timer is running whenever it is enabled Oct 03 04:18:19 (regardless of whether it's in capture mode or in pwm mode) Oct 03 04:18:50 these interrupts are associated with pwm mode only, capture mode has a different set of interrupts (bits 1-5 of ECFLG/ECCLR/ECEINT) Oct 03 04:19:10 yes Oct 03 04:19:34 and ACMP == 0 in my case since I don't use the pwm output Oct 03 04:20:54 is the pwm.initialize() enabling the timer Oct 03 04:21:34 https://github.com/mvduin/py-uio/blob/master/src/uio/ti/ecap.py#L59-L75 Oct 03 04:22:42 ah right, my description was off by one Oct 03 04:23:30 https://pastebin.com/dUbHHJNm this is more correct Oct 03 04:23:58 so APRD isn't actually the period, it's the maximum value (199999999 in this case) Oct 03 04:32:07 line 75 contains 1<<20 which enables the counter which triggers the irq Oct 03 04:32:17 when it hits zeroo Oct 03 04:32:22 ? Oct 03 04:32:35 please dont be mad if im wrong Oct 03 04:33:52 https://github.com/mvduin/py-uio/blob/master/src/uio/ti/ecap.py#L59-L75 Oct 03 04:35:10 im really trying to understand Oct 03 04:46:44 Okay. So, you guys are working on the ecap.py file for pwm usage under the uio PRU source? Oct 03 04:47:17 If you guys are not too stressed already, I would like to try soon. But not now, you guys are stressed. Oct 03 04:49:36 we are not working on anything Oct 03 04:49:52 i am trying to understand the code he pasted earlier Oct 03 04:50:24 Oh. Oct 03 04:50:25 Okay. Oct 03 04:50:44 PRU code: https://pastebin.com/h59kPiXG Oct 03 04:50:44 python code: https://pastebin.com/nKaB2n9D Oct 03 04:50:44 output: https://pastebin.com/ixyrWu4g Oct 03 04:50:48 I do not understand why I am so wrong so often. Someone tell me something. Sheesh. Oct 03 04:50:52 Okay. Oct 03 04:51:53 renrelkha: oversimplification of what the eCAP hardware does (or is supposed to do anyway) in PWM mode: https://pastebin.com/E0wMDHJF Oct 03 04:52:17 I will read that too. Oct 03 04:52:57 https://pastebin.com/dUbHHJNm this is more correct Oct 03 04:53:29 well dont bug him about it Oct 03 04:53:37 just read it Oct 03 04:53:38 renrelkha: Do not worry. I will not. Oct 03 04:53:40 Okay. Oct 03 04:53:46 we wont even discuss either Oct 03 04:54:01 I want to read more on the subject to learn more about what bbb.io offers on their distros. Oct 03 04:54:06 Done. Oct 03 04:54:15 No more. Oct 03 05:26:06 line 7: I got /dev/uio[0 - 7]/ && not /dev/uio/pruss/module. Oct 03 05:28:04 Sorry. I forgot. I am excited. Oct 03 05:28:05 then you didn't follow py-uio's installation instructions Oct 03 05:28:11 I am following them now. Oct 03 05:28:13 My bad. Oct 03 05:28:14 (missing udev rule) Oct 03 05:28:30 I thought it was already put on the board. Oct 03 05:28:52 i am going to do it now. Oct 03 05:40:26 Okay. I ran the basic-test.py file. It works. Oct 03 05:40:37 Now, onto the other one. Oct 03 05:58:57 Are we compiling s on the else statement? Oct 03 05:59:48 The only error I receive is the a '^' on a single quotation mark. Oct 03 06:01:02 Sorry. The if statement is where I receive the error on the '^' mark of the single quotation mark. Oct 03 06:01:16 I am reviewing errors now. Oct 03 06:03:54 the '/r' means that...well hell: https://docs.python.org/3/reference/lexical_analysis.html#string-and-bytes-literals Oct 03 06:06:04 https://pastebin.com/prvquxsB <<< does this apply? Oct 03 06:08:32 It seems that it is an ASCII carriage return that is being placed before {s}. Oct 03 06:12:48 What is that module file at /dev/uio/pruss/module? Oct 03 06:12:55 elf? Oct 03 06:24:12 Are you looking for bugs or searching for malware? Oct 03 06:26:58 Alright, so, if you are looking for a literal character in ASCII, use anything but this idea >>> "{", "}" or NULL. Oct 03 06:27:24 outside of the chevron. Do not worry about the chevron. Oct 03 06:34:48 Do you need to use ascii() or repr()? Oct 03 06:39:51 Okay. I got it. I am out for now. Oct 03 06:41:10 set_: I have not even the slightest idea what on earth you're rambling about Oct 03 06:41:51 any compile errors you get are, without a doubt, entirely your fault Oct 03 08:00:35 :q Oct 03 12:06:12 Hi all. Ive been trying for about a year to get a BB booting so that I can expose the three hardware serial ports, to access via Node-RED, but its prooving more difficult than expected. Has anyone done this before? Oct 03 22:16:33 zmatt: it seems like what one might want to go for is basic networking and ssh on a micro recovery image Oct 03 22:16:57 s_: for what context/purpose ? Oct 03 22:16:59 but i think that would mean something heftier than busybox Oct 03 22:17:18 zmatt: creting a nice solid OTA recovery image Oct 03 22:17:32 what is an "OTA recovery image" and how would you use it? Oct 03 22:18:22 my use for busybox was to execute a shell script that mainly consisted of moving a new directories Oct 03 22:18:35 what i am thinking is that it would be a small partition of space that is an isolated tiny OS that can be used to clear off the current image and download a new one for unpacking Oct 03 22:19:10 i think this might greatly increase the number of dependencies involved Oct 03 22:20:04 if you don't have space to download and unpack without removing the old system then you might need a 2-stage process like that yeah, though that greatly increases complexity and risks and you should definitely test it well. I would not bother with busybos in that case, a stripped-down debian system is small enough Oct 03 22:21:33 e.g. you'd do an upgrade to a new minimal system which then (after making space by removing the old system) auto-installs whatever is needed on top of it (which can probably be as simple as downloading and unpacking a tarball onto the existing system) Oct 03 22:25:19 yeah.. that's a good idea. maybe use debootstrap Oct 03 22:25:25 so, I assume the fact that you're thinking about this implies that you do not have enough space for the old and new systems to (briefly) exist simultaneously? (or at minimum, old system + tarball of new system) Oct 03 22:25:56 zmatt: its funny, i think its very possible they won't be able to, yes Oct 03 22:26:17 but ive also been poking around and saw ALOT we could take out Oct 03 22:26:26 to make the new system you mean? I'd just start with a console image ( https://elinux.org/Beagleboard:Latest-images-testing#Debian_10_.28Buster.29_Console ) and futher remove unnecessary stuff Oct 03 22:27:08 well given how much more complicated and riskier it would make the upgrade process, leaning down your system should definitely be explored first Oct 03 22:27:41 *how much more complicated and riskier it would make the upgrade process if you can't do it in 1 step Oct 03 22:27:46 zmatt: seems like one approach would be to do both. like have a contingency where the thing can reach out to the internet to recover itself Oct 03 22:28:05 right now jut seeing what is possible Oct 03 22:28:29 you were talking about 1000 devices. that should be plenty of motivation to ensure the upgrade process, once started, _will_ _not_ _fail_ Oct 03 22:29:03 best way to do that is to have the image on there before any rebooting Oct 03 22:29:08 i agree with that Oct 03 22:29:18 having the final new system unpacked and ready to go before the old system is touched in any way at all, yeah Oct 03 22:29:49 or at least having a tarball of the new system downloaded, along with the installer Oct 03 22:30:33 and then change /boot/uEnv.txt to boot into the installer and reboot Oct 03 22:30:38 built busybox last night. pretty neat Oct 03 22:31:15 yeah like I said I didn't bother with that, I just used one in the busybox-static debian package Oct 03 22:32:03 did you just make the pile of symlinks you needed? Oct 03 22:32:24 I needed none, I just renamed it to "sh" Oct 03 22:32:53 i thought how it worked was it would execute itself and look at the 0th arg Oct 03 22:33:59 no, it recognizes its own commands as shell builtins Oct 03 22:35:18 I mean, it will also look at the 0th arg when invoked, but I'm not sure it even bothers spawning a process at all for things like "mv" or "rm" Oct 03 22:35:35 yeah, interesting Oct 03 22:35:43 that does make its use pretty simple Oct 03 22:38:47 wow deb10 console is pretty light Oct 03 22:39:36 i guess one could take out wifi firmware Oct 03 22:39:40 if not using it Oct 03 22:40:09 there's a fair bit that can be taken out iirc Oct 03 22:40:53 https://bpa.st/52JQ Oct 03 22:41:30 that's the complete list of packages installed? I remember there being more Oct 03 22:41:57 dpkg-query -Wf '${Installed-Size}\t${Package}\n' | sort -n Oct 03 22:42:16 i missed the smallest one sudo Oct 03 22:42:43 wait... whoa whats up with this terminal Oct 03 22:42:54 this isn't right, I know for a fact that a ton of packages are missing from this list Oct 03 22:45:15 yes, i think my terminal is doing something weird Oct 03 22:46:06 https://pastebin.com/raw/G3DzvQQu Oct 03 22:47:45 but yeah, if you're not using wifi then all of the wifi stuff can go (*rtl8*, *firmware*, wpasupplicant), bluetooth (bluez) Oct 03 22:48:38 btrfs-progs can go Oct 03 22:50:00 there's no need for initramfs (though I think the kernel package may have an inappropriate dependency on it, which can be solved by installing a dummy initramfs-tools package (initramfs-tools_1.0_all.deb) Oct 03 22:50:04 ) Oct 03 22:50:27 more wifi stuff: crda, wireless-tools Oct 03 22:53:01 I personally use systemd-networkd + systemd-resolved (included with systemd) instead of the default networking stuff (ifupdown, connman, isc-dhcp-*, dnsmasq, bb-usb-gadgets) Oct 03 22:53:11 more wifi stuff (wireless-regdb, iw) Oct 03 22:54:31 haveged is pointless if you enable use of the hwrng by having something like "rng_core.default_quality=100" in your kernel parameters, which is there by default Oct 03 22:56:17 i wonder if the nonfree misc firmware is needed for anything Oct 03 22:56:47 pretty sure all the firmware is for various wifi stuff Oct 03 23:03:18 i wonder if apt will remove itself hehe Oct 03 23:03:40 or how bad removing perl would be Oct 03 23:04:24 apt-get will ask you to tyoe "Yes, do as I say!" if you ask it to remove apt Oct 03 23:05:00 there's probably some critical stuff depending on perl Oct 03 23:05:12 yeah. Oct 03 23:05:43 besides, perl is a beautiful language, why would you want to remove it? ;) Oct 03 23:05:51 down to 363M which is not bad Oct 03 23:07:52 it seems like one could strp down your image this way to free up space too Oct 03 23:08:18 or just start with this stripped-down image and only install what you need Oct 03 23:09:10 zmatt: i mean if you have something built up with more in it, before you update you could strip it down to this, bring over your tarball or whatever you have for the new image, then reboot into the minimal (new) environment Oct 03 23:10:33 but yes, I think this is telling me there may be a fair bit of cruft in the image im working with Oct 03 23:10:34 our production beaglebones have 452M used according to df -h, of which 145M is our custom stuff Oct 03 23:11:17 so you found another 60M Oct 03 23:11:42 minutes 69M of crap people seem to have littered in /home and /root on this particular beaglebone (which is not quite a clean production system but also used for testing) Oct 03 23:11:45 *minus Oct 03 23:12:10 lemme grab the package list Oct 03 23:12:41 when you get this tiny, apt dist-upgrade is startig to look reasonable Oct 03 23:13:16 locally sure, not on remote systems, not automated Oct 03 23:13:33 power interruption during apt dist-upgrade = system hosed Oct 03 23:16:45 https://pastebin.com/vFT2SRMt Oct 04 00:10:08 i noticed no python3 Oct 04 00:10:09 :) Oct 04 00:10:56 yeah debian is a bit behind on changing whatever is pulling in python2 to use python3 instead Oct 04 00:11:54 despite python2 being deprecated for a decade Oct 04 00:13:54 hmm what's pulling in python even Oct 04 00:14:39 wait, python isn't installed either, what am I saying Oct 04 00:15:12 I just assumed you meant to imply that by saying "no python3" instead of "no python" Oct 04 00:15:57 there's intentionally very little in the host system, like I mentioned most of our services run inside containers Oct 04 00:18:18 (the ones that don't are root-privileged and written in C++ with no library dependencies other than libc/libstdc++/libsystemd ) Oct 04 00:18:23 yeah python3 i think is pulled for unattended-upgrades Oct 04 00:18:46 which is not something I'd want to have installed Oct 04 00:19:23 vim is worth 32MB wow Oct 04 00:19:59 unattended-upgrades is appropriate for personal systems, *maybe* servers, definitely not embedded systems in inaccessible locations Oct 04 00:20:37 yep Oct 04 00:20:53 I think vim is one of the real big oness Oct 04 00:21:26 yeah, I should probably have a smaller vim variant installed... but on the rare occasion I need to log into one of these systems for a support call, I kinda want a comfortable vim :P Oct 04 00:22:14 maybe I should custom-build one, since I know this vim has a lot of features enabled that I don't care about Oct 04 00:23:26 how is vim-tiny Oct 04 00:27:07 MattB0000ne: ecap irqs are buggy, so avoid the irq-using variants. the non-irq version works fine though Oct 04 00:27:32 ok I am using the non irq with nano seconds Oct 04 00:27:39 i am doing something wrong converting though Oct 04 00:27:57 test PRU program: https://pastebin.com/h59kPiXG test python script: https://pastebin.com/9Q5rvZ9W Oct 04 00:28:01 when i init the ecap that makes it wrap after 1 second ? Oct 04 00:28:31 if you init it with a period of 200000000 clock cycles (i.e. 1 second) then yes? Oct 04 00:28:32 cool let me try Oct 04 00:29:10 hmm resize32fs converted the file system to 32 bit Oct 04 00:29:12 this test tests both methods, and shows the irq timestamp sometimes incrementing by 2 Oct 04 00:29:39 s_: no it didn't, also it's called resize2fs Oct 04 00:29:56 well it said it did Oct 04 00:30:30 pastebin showing how you invoked it and what it printed Oct 04 00:31:26 https://bpa.st/5LSA Oct 04 00:31:51 -s Turns off the 64bit feature Oct 04 00:32:02 you asked it to Oct 04 00:32:11 so yeah, then it will Oct 04 00:38:49 ah so i did. Oct 04 00:41:51 how do I stop it Oct 04 00:41:53 lol Oct 04 00:42:01 ctrl-C Oct 04 00:42:11 does that halt the core too? Oct 04 00:42:18 read the python code Oct 04 00:42:35 i c ic Oct 04 00:42:37 cool Oct 04 00:42:41 this is what I needed Oct 04 00:43:18 kinda funny that python has a finally as a reserved word Oct 04 00:45:40 zmatt: so bzipped its around 140M Oct 04 00:46:04 MattB0000ne: what's funny about that? Oct 04 00:46:29 so I guess that's around 400*2+150 a little over a gig Oct 04 00:46:39 if one was going to have both unpacked at once Oct 04 00:47:45 doesnt seem to fit other words try, close if, while etc... seems less computer-like **** ENDING LOGGING AT Sun Oct 04 02:59:57 2020