**** BEGIN LOGGING AT Thu Jan 31 02:59:57 2019 Jan 31 03:34:53 Beagleboard.org is going to Germany! That is some far away lands. Good luck everyone. Jan 31 03:40:19 Hello there. Any folks with PRU experience? Jan 31 03:41:49 the easiest way to find out is by asking your question Jan 31 03:42:27 (as a general rule, there are plenty of knowledgeable people here, it may just sometimes take time to get a response) Jan 31 03:44:50 I'm using " prussdrv_pru_clear_event(PRU_EVTOUT_1, PRU0_ARM_INTERRUPT);" and it doesn't seem to be working. Jan 31 03:45:42 I set EVTOUT_1 on the PRU and this is correctly picked up by prussdrv_pru_wait_event(PRU_EVTOUT_1); Jan 31 03:46:14 lemme check quickly what it does (I use my own code for uio-pruss instead of libprussdrv, so I'm not very familiar with its functions) Jan 31 03:48:24 Thanks. More info: I'm using prussdrv_pru_wait_event(PRU_EVTOUT_1); at the top of a while loop. I attempt to clear the interrupt as soon as the while loop is entered but it's not clearing. This results in the loop being executed repeatedly. Jan 31 03:49:16 are you sure you're not clearing the wrong event? that would be the simplest explanation Jan 31 03:50:07 Setting with: MOV R31.b0, PRU0_R31_VEC_VALID | PRU_EVTOUT_1 // signal BB once per second Jan 31 03:50:21 uhh that's definitely wrong Jan 31 03:50:23 Clearing with: prussdrv_pru_clear_event(PRU_EVTOUT_1, PRU0_ARM_INTERRUPT); Jan 31 03:51:45 pru writes 32-47 (i.e. PRU0_R31_VEC_VALID + (0..15)) to R31.b0 to set event 16..31 in the pru intc Jan 31 03:52:38 #define PRU0_R31_VEC_VALID 32; Jan 31 03:52:42 this should then be mapped via a channel to one of the "host interrupt" outputs of the pru intc Jan 31 03:52:44 #define PRU_EVTOUT_1 4 Jan 31 03:53:21 host interrupts 2..9 are routed to the arm core, and that's what apparently (and confusingly) libprussdrv seems to be calling PRU_EVTOUT_0..7 Jan 31 03:54:12 the second argument to prussdrv_pru_clear_event is the event number, i.e. PRU0_ARM_INTERRUPT in this case Jan 31 03:55:04 Yes, that is what I currently have Jan 31 03:55:58 if PRU0_ARM_INTERRUPT is 16+n then pru needs to write 32+n to R31.b0 (for some n in range 0..15) Jan 31 03:56:43 libpruss definitely made this pretty confusing with their api design and naming of constants Jan 31 03:57:20 Good to know I'm not the only one who finds this confusing.. Jan 31 03:58:52 maybe my py-uio intc would make things clearer... https://github.com/mvduin/py-uio/blob/master/pru-examples/intc-test.py Jan 31 03:58:58 corresponding pru firmware https://github.com/mvduin/py-uio/blob/master/pru-examples/fw/intc-test.pasm Jan 31 03:59:32 So The #defines for R31_VEC_VALID 32 Ored with 4 should give the desired 32 +n result then? Jan 31 03:59:46 I'll look at your code now Jan 31 03:59:52 I actually explicitly check which event was flagged and clear that one... oddly libprussdrv doesn't seem to have a function for it Jan 31 04:02:09 Hmmm Python... Jan 31 04:02:41 libprussdrv's prussdrv_pru_clear_event(irq, event) would be equivalent to intc.ev_clear_one(event); intc.out_enable_one(2+irq) in py-uio Jan 31 04:04:16 yeah I still want to make a C/C++ library for uio-pruss to replace libprussdrv Jan 31 04:04:24 haven't gotten around to it Jan 31 04:06:53 I wonder if libprussdrv is broken.... I've seen a couple of other posts with the same problem and no answer. Jan 31 04:09:12 it still doesn't work after using the correct event number on both sides? Jan 31 04:09:59 i.e. if pru is writing R31_VEC_VALID | 4 to R31 then PRU0_ARM_INTERRUPT needs to be 20 Jan 31 04:10:11 Oh so what one is wrong? Jan 31 04:10:19 also that constant is really badly named, since it's an event number Jan 31 04:11:09 PRU0_ARM_INTERRUPT is however 19 Jan 31 04:11:26 which means pru needs to write R31_VEC_VALID | 3 Jan 31 04:11:49 in general to trigger event 16..31 pru needs to write 32..47 to R31 Jan 31 04:12:23 (this is an unfortunate situation created in prussv2... in prussv1 you'd write 32..63 to R31 to trigger event 32..63) Jan 31 04:16:15 Ok I'll try that know quickly Jan 31 04:23:21 oh nice, prussdrv.h defines PRU_EVTOUT_0 = 0 through PRU_EVTOUT_7 = 7 Jan 31 04:23:26 Ok so that did not work. Currently I have 2 events been generated. PRU_EVTOUT_0 and PRU_EVTOUT_1. 0 is used to signal the termination of the PRU code. This is correctly picked up by the host and the program exits cleanly however the host does not attempt to clear. Event 1 is also picked up by the host but it only works once as the host doesn't clear the event. This suggests to me that the numbering of the events is correct and the pro Jan 31 04:23:36 pruss_intc_mapping.h defines PRU_EVTOUT0 = 2 .. PRU_EVTOUT7 = 9 Jan 31 04:23:51 that's certainly not confusing at all Jan 31 04:23:52 -.- Jan 31 04:24:25 Yes I noticed that in the header files.. Confusing alright! Jan 31 04:26:40 hi Jan 31 04:26:48 Hello Jan 31 04:27:25 I am using beagle bone black wireless from last two days it is not getting detected in PC? Jan 31 04:27:43 What should be route cause of the problem? Jan 31 04:30:36 Still here Jan 31 04:31:20 Thanks for your help zmatt. I've got to head off but will check in later Jan 31 04:33:37 Hi Jan 31 04:34:03 Help Jan 31 04:36:01 hello Jan 31 04:36:07 can anyone help me? Jan 31 04:38:49 Hello there Jan 31 05:01:09 HELP Jan 31 05:37:57 Anyone else had problems with prussdrv_pru_clear_event (PRU_EVTOUT_1, PRU0_ARM_INTERRUPT); not working? Jan 31 05:38:25 have you fixed the pru code yet? Jan 31 05:40:04 Hi zmatt. No.. sadly I have not worked out the problem yet. Jan 31 05:40:32 can you check the following value after clearing: printf( "0x%x\n", *(unsigned volatile *)prussdrv_get_virt_addr(0x4a320300)); Jan 31 05:41:00 it should show a mask of all events pending in the pru intc Jan 31 05:41:24 sorry, wrong address Jan 31 05:41:33 0x4a320280 Jan 31 05:42:57 Oh that sounds very useful. I'm away from my desk now but I'll try that tomorrow morning when I'm back in the office. Jan 31 05:43:41 asking for help here when you can't actually test or debug anything is not particularly productive Jan 31 05:44:32 Yeah good point. I'll check back in tomorrow. Jan 31 08:59:38 zmatt: just for information, gnuplot has a "system" command, so I can recall our reading/writing script before poltting , into a gnuplot loop. ;-) Jan 31 09:04:24 Newbie question : how can I install a software from github ? Jan 31 11:49:26 hi. i am new Jan 31 11:49:35 can anyone help me get started Jan 31 12:16:13 pluto__: what would you like to get help with? Jan 31 12:17:25 tbr: i would like to contribute. what must i know as a beginner **** BEGIN LOGGING AT Thu Jan 31 12:34:12 2019 Jan 31 13:02:42 pluto__: ah, is it that you'd like to potentially take part in GSoC? Jan 31 13:56:30 in rcn-ee.com/rootfs/bb.org/testing/2019-01-27/stretch-console/ what's the difference between debian-9.7-console and bone-debian-9.7-console ? Jan 31 14:09:26 fred__tv_: AFAIU the former is a raw rootfs with no hw specific bits Jan 31 14:09:43 the latter and the x15 are hw specific images Jan 31 14:10:57 is bone-debian suggested to start with using a beaglebone white ? Jan 31 14:11:39 I guess it should work on a white too Jan 31 14:14:00 ok Jan 31 14:17:06 tbr: i don't know if that'd be feasible yet. i am only a beginner. i'd like to learn about developing on this platform first. Jan 31 14:33:56 *sigh* Jan 31 15:00:56 how do I disable ipv6 on beagle ? Jan 31 15:19:33 fred__tv_: unless you want to go back by about 30 years in time, you better don't Jan 31 15:20:10 Just for debug purpose Jan 31 15:21:16 not sure if you still can just disable it on kernel level completely Jan 31 15:21:31 you should be able to disable it per network interface though Jan 31 15:22:47 by the looks of it: /proc/sys/net/ipv6/conf/all/disable_ipv6 Jan 31 15:50:13 ok disabled but no luck, I'm trying to solve a 80 seconds boot time caused by networking Jan 31 16:03:53 m Jan 31 16:55:24 I googled and found some half-finished options. So -- do you recommend any "breadboard simulator"? Jan 31 16:56:41 I want in particular to use parallel circuits to minimize the use of analog inputs. But even trying to work the math out hurts my brain. Jan 31 16:57:44 (basically putting variable resistor "sensors" in parallel should have a harmonic mean-type effect. Jan 31 18:31:28 I submitted the 6LoWPAN project zmatt , we have 14.5/20 for the grade Jan 31 18:32:08 but after that one jury member emailed me saying that it deserved better but he had to take points because we didn't communicate much, and that he wants to write an article about the project in some french linux embedded magazine Jan 31 18:32:59 we finished a half-working demo 30 minutes before the presentation after staying up whole night, the demo randomly deadlocked after a few packets so I had to discreetly reset it Jan 31 18:33:02 they didn't see anything Jan 31 18:33:24 but yeah I'd like to solve that deadlock thing before submitting the code to RTEMS Jan 31 18:53:43 I'm looking for a way to get clean audio out of a beaglebone, preferably without using anything expensive and definitely without using anything large. Jan 31 18:55:06 I've got it working using a transformer to break a ground loop but my preferred USB audio adapter seems to pick up a lot of power line noise (it clicks every time one of the blue lights flashes). Jan 31 18:55:43 though it's possible that's a driver problem with too little buffering Jan 31 18:56:25 ideally I'd take the i2s output, convert to optical, and then have an optical to audio adapter on the amp Jan 31 18:57:04 but the bits to do that seem to be quite large or expensive, even though the components are cheap Jan 31 20:33:32 https://filebin.ca/4VRYz9rs55Wl Jan 31 20:34:43 why this looooong boot (other that networking.service I'm trying to solve) ?? Jan 31 20:36:20 seems odd, like it's waiting for something to time out Jan 31 20:36:25 have you checked journal? Jan 31 20:37:37 hmmm not yet wait.. Jan 31 20:38:09 you could also check systemctl status and systemctl list-jobs during this time where it seems to be doing nothing Jan 31 20:38:43 not yet reachable (working remotely , waiting vor a vpn fix I'm working to) Jan 31 20:42:03 hmm? the boot log says that sshd is running at that time Jan 31 20:42:19 it completes startup at 46s Jan 31 20:46:20 this is the latest bone-debian9.7-console Jan 31 20:46:49 the 9.6 gave the one we have seen together https://filebin.net/b4w2fsazl462hgpz Jan 31 20:47:54 the console image uses ifupdown by default, not connman? Jan 31 20:49:54 (I'd personally just remove both and enable systemd-networkd instead) Jan 31 20:50:26 https://pastebin.com/7j1NPvJh Jan 31 20:50:54 just purged connman , I'm so lazy with ifupdown Jan 31 20:50:56 Hi zmatt, I'm going to try the code you suggested now Jan 31 20:51:33 fred__tv_: systemctl disable serial-getty@ttyGS0.service Jan 31 20:53:20 fred__tv_: (side note: you probably also want to disable hostapd.service and bb-wl18xx-bluetooth.service since you don't have a wifi/bluetooth chipset) Jan 31 20:54:02 I also can't imagine a good reason for udhcpd.service .. it's probably for usb networking and/or AP mode, neither or which you use Jan 31 20:54:55 fred__tv_: also, I'm not sure using ifupdown counts as "laziness", considering how much time you've already had to put into debugging boot issues as a result Jan 31 20:55:43 Benjah: ok Jan 31 20:57:01 you're right , but I'm masochist finding to fix things that should work....... Jan 31 20:58:22 but why those services that start at 93 seconds ?? Jan 31 20:59:09 Hi zmatt, the output was: 0x100000 Jan 31 20:59:37 fred__tv_: because they're conditional on getty.target which is waiting for serial-getty@ttyGS0.service which is waiting for /dev/ttyGS0 to appear, which never happens. that's why I just told you to disable serial-getty@ttyGS0.service Jan 31 20:59:55 Benjah: i.e. you're still having pru send a different event than you're clearing Jan 31 21:00:06 already done ! Jan 31 21:00:16 fred__tv_: and it still hangs? Jan 31 21:00:56 I wonder if it's getting a list of getty services to spawn from some config file Jan 31 21:01:02 eth0 still up @43 seconds and those services at 93 sec Jan 31 21:01:16 same error in journal? about serial-getty@ttyGS0.service Jan 31 21:02:02 Benjah: your C code is clearing event 19, while PRU is sending event 20 Jan 31 21:02:08 no Jan 31 21:02:11 no more Jan 31 21:02:26 fred__tv_: can you pastebin the journal output now? Jan 31 21:02:44 and maybe boot.svg Jan 31 21:03:09 although probably the boot.svg still doesn't show anything interesting in this case Jan 31 21:03:38 I'll try clearing event 20 Jan 31 21:03:43 https://filebin.ca/4VRiSRMQb3WU/boot.svg Jan 31 21:05:20 it still looks like getty.target is the one that's waiting for some timeout, and the rest follows as a result. Jan 31 21:05:36 journal output? Jan 31 21:07:43 https://ghostbin.com/paste/kasuf Jan 31 21:08:36 uhh this doesn't match your latest boot.svg Jan 31 21:08:53 [ 46.736695] beaglebone systemd[1]: Startup finished in 1.895s (kernel) + 44.837s (userspace) = 46.732s. Jan 31 21:09:28 same running machine.... Jan 31 21:10:01 in fact your latest boot.svg is exactly the same file as the previous one Jan 31 21:10:07 so I think you just messed that up Jan 31 21:10:28 your journal log shows the problem of the long delay is fixed Jan 31 21:11:14 what a Idiot... Jan 31 21:12:21 zmatt looks promising so far. More soon Jan 31 21:12:32 https://filebin.ca/4VRl6ylzsTe0/boot.svg Jan 31 21:14:26 like I said, problem solved, other than networking.service Jan 31 21:15:10 no it isn't fixed , systemctl disable serial-getty@ttyGS0.service has fixed 40 seconds more Jan 31 21:15:17 ah yes Jan 31 21:16:00 the problem is on-screen login prompt (or ssh access) appears after eth0 came up !! Jan 31 21:18:34 why net eth0: initializing cpsw version 1.12 (0) at 46sec ? Jan 31 21:19:05 has it something to do with PRU ? Jan 31 21:19:22 nothing whatsoever Jan 31 21:20:30 it seems that networking.service first does 39 seconds of nothing, and then finally brings up ethernet (which triggers that log message at 46s) Jan 31 21:21:33 at 45.26 seconds actually Jan 31 21:21:38 any ifupdown config file to check ? Jan 31 21:21:59 I haven't used ifupdown in many, many, many years Jan 31 21:22:38 I use systemd-networkd on every system I work with (embedded, desktop, and server) Jan 31 21:26:05 I can switch to if simple enough.... Jan 31 21:26:39 just wondering if connman purge has messed up something... Jan 31 21:26:43 create https://pastebin.com/eybmPMh1 Jan 31 21:27:29 systemctl disable networking ; systemctl enable systemd-networkd systemd-resolved Jan 31 21:27:50 reboot and pray I didn't forget a step? ;) Jan 31 21:27:54 I'm working with static IP Jan 31 21:28:59 on sec Jan 31 21:29:00 *one Jan 31 21:31:05 found Jan 31 21:31:09 https://pastebin.com/FuiQMvYQ Jan 31 21:31:44 more details in man systemd.network Jan 31 21:35:12 after reboot, assuming eth0 comes up properly, you should probably replace /etc/resolv.conf with a symlink to /run/systemd/resolve/stub-resolv.conf Jan 31 21:35:49 this will make it managed by systemd-resolved Jan 31 21:36:05 yes Jan 31 21:43:09 https://ghostbin.com/paste/smwf9 Jan 31 21:44:15 wat Jan 31 21:45:01 it is actually taking 44 seconds for the eth0 device itself to show up? Jan 31 21:45:08 still.... Jan 31 21:45:26 login prompt after 10 seconds now but no eth Jan 31 21:45:49 yeah, so networking is now non-blocking, and you also see for example that systemd-timesyncd responds dynamically to eth0 coming up Jan 31 21:45:50 networking disabled , systemd-networkd enabled Jan 31 21:45:55 so there are already benefits Jan 31 21:46:09 :-( Jan 31 21:46:10 but the core issue actually seems to be in the kernel somehow Jan 31 21:46:33 what the hell is going on here Jan 31 21:46:38 can I see a boot.svg ? Jan 31 21:47:39 https://filebin.ca/4VRvkNqwDD7F/boot.svg Jan 31 21:48:30 wtf ? Jan 31 21:48:33 oh right, startup is "done" at that point, since the eth0 interface seems to show up dynamically Jan 31 21:50:27 out of curiosity: can you try commenting out enable_uboot_cape_universal=1 in /boot/uEnv.txt ? Jan 31 21:54:13 another thing that could be useful for debugging is adding udev.log_priority=8 to the "cmdline" variable in /boot/uEnv.txt Jan 31 21:54:18 this enables udev debugging Jan 31 21:54:31 zmatt: SUCCESS! I now clear PRU1_ARM_INTERRUPT instead of PRU0_ARM_INTERRUPT, even though I'm using PRU0. Seems like header file bug to me. Many thanks for your help with this problem. You're an asset to the community. Jan 31 21:54:48 Benjah: it's not a header file bug Jan 31 21:55:08 Oh so user error? (it normally is for me) Jan 31 21:55:12 the bug is that you're having pru0 set the event meant for pru1->arm signalling Jan 31 21:55:21 instead of the one meant for pru0->arm signalling Jan 31 21:55:37 https://ghostbin.com/paste/yshqr Jan 31 21:55:40 Oh I see. Jan 31 21:55:44 those names are just suggestions of course, you can use events 16..31 for any purpose you want Jan 31 21:56:01 but it may require customizing the intc mapping Jan 31 21:56:26 fred__tv_: LOL, cape-universal was the problem as I imagined? Jan 31 21:56:38 it seems.... Jan 31 21:56:51 in other words it was simply the enormous horde of devices and the massive volume of udev rules triggered Jan 31 21:56:58 caused by cape universal Jan 31 21:57:19 what does it do ? Jan 31 21:57:27 apparently the adafruit bbio library doesn't support i2c on python 3 at all? Jan 31 21:57:27 enable everything, basically Jan 31 21:57:45 *bbio python library Jan 31 21:57:49 syntaxfree: just use a python i2c library of your choice Jan 31 21:58:05 I can't imagine an adafruit wrapper having added value Jan 31 21:58:34 fred__tv_: it also creates a pinmux switching device for each expansion header pin Jan 31 21:58:49 fred__tv_: I also wouldn't be surprised if there are some horribly inefficient udev rules attached to them Jan 31 21:59:04 example ? Jan 31 21:59:06 * syntaxfree gears spinning Jan 31 21:59:16 fred__tv_: oh and it exports each gpio Jan 31 21:59:21 so wait, is serial communication on the beaglebone handled like an unix stream? Jan 31 21:59:37 syntaxfree: serial or i2c? Jan 31 21:59:45 regardless, they're handled the same as on every other linux system Jan 31 21:59:54 Right, so if I wanted to clear the interrupt using prussdrv_pru_clear_event(PRU_EVTOUT_1, PRU0_ARM_INTERRUPT); then I'd need to set what bit on the PRU? Jan 31 22:01:00 Benjah: PRU0_ARM_INTERRUPT is 16+3, so you'd write 32+3 to R31 Jan 31 22:01:15 isn't I2C a serial protocol with a clock signal? Jan 31 22:01:24 syntaxfree: i2c is i2c Jan 31 22:01:26 zmatt: should I expect something not working ? Jan 31 22:02:08 zmatt: Letme try that.. Jan 31 22:02:53 fred__tv_: it just means you'll need to explicitly enable/configure on-chip peripherals you want to use via overlays or a custom dt Jan 31 22:03:17 as opposed to everything being enabled by default and being able to select pin function at runtime using the config-pin utility Jan 31 22:03:50 UART i.e. ? Jan 31 22:04:07 default GPIO use ? Jan 31 22:04:21 fred__tv_: but you already used overlays iirc? unless I'm confusing you with someone lese Jan 31 22:04:24 *else Jan 31 22:05:05 no, not me Jan 31 22:05:09 ok Jan 31 22:06:12 what overlays iirc ? Jan 31 22:06:19 you weren't the one with the custom lcd cape? Jan 31 22:06:26 I'm so bad with names Jan 31 22:06:38 ah that way overlay Jan 31 22:06:50 yes it's me Jan 31 22:06:54 phew Jan 31 22:07:24 so, you're already used to declaring your hardware via overlays rather than using cape-universal Jan 31 22:07:36 exactly Jan 31 22:07:48 this also means that on the current image, cape-universal is no longer automatically disabled when custom overlays are used (like it used to be), good to know Jan 31 22:07:59 that one plus UART1 overlay Jan 31 22:08:21 exactly. so, with cape-universal you wouldn't have needed an overlay for that, you could have used config-pin instead Jan 31 22:08:56 if I need to play with GPIOs instead ? Jan 31 22:09:24 you can still export those manually from sysfs, or you can use an overlay to declare and initialize them Jan 31 22:10:14 (see https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi ) Jan 31 22:10:44 so, without cape-universal all gpio are dead ? Jan 31 22:11:01 they're just not exported via sysfs *by default* Jan 31 22:11:46 is there a "generic" gpio overlay in /lib/firmware ? Jan 31 22:12:00 you can still export them using an overlay, export them manually using /sys/class/gpio/export, or use the gpio chardev interface Jan 31 22:12:12 I think most gpio libraries will automatically export them if needed Jan 31 22:12:24 the "generic overlay" would be cape-universal Jan 31 22:13:05 :-) Jan 31 22:13:39 note it's possible the slow boot with cape-universal enabled is mostly caused by badly written udev rules... like doing stupid shit such as a chmod -R on all of /sys/class/gpio triggered by every gpio pin exported Jan 31 22:13:59 might want to check /etc/udev/rules.d/ for things like that Jan 31 22:14:24 also make sure you have the latest version of the bb-customizations package, or whatever it's called Jan 31 22:15:18 instead of inspecting the rules statically you could also use the udev.log_priority=8 kernel parameter to debug what udev is doing perhaps Jan 31 22:16:22 things like SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chmod -R ug+rw /sys/devices/platform/ocp/*.gpio'" Jan 31 22:16:36 lol Jan 31 22:17:19 there's so much wrong with that line Jan 31 22:17:53 I'm used to export gpio by hand when needed.... Jan 31 22:17:54 the use of /bin/sh, using ug=rw instead of g=u, and applying it to all devices instead of just the one this event is for Jan 31 22:18:34 that one is 80-gpio-noroot.rules Jan 31 22:19:31 well so I can switch back to ifupdown...... Jan 31 22:19:37 ;-) Jan 31 22:20:14 you probably could, but systemd-networkd still improves boot time and also enhances services like systemd-timesyncd Jan 31 22:20:38 plus you'll agree the config is pretty straightforward Jan 31 22:21:06 as simple as /etc/network/interface Jan 31 22:21:21 try replacing the two lines in 80-gpio-noroot.rules by: Jan 31 22:21:37 SUBSYSTEM=="gpio", ACTION=="add", TEST=="value", RUN+="/bin/chgrp -R gpio '/sys%p'", RUN+="/bin/chmod -R g=u '/sys%p'" Jan 31 22:22:13 see if that saves time (when cape-universal is enabled) Jan 31 22:26:49 oh actually that's not quite equivalent though Jan 31 22:26:56 there is also : Jan 31 22:26:57 maybe remove the TEST=="value" Jan 31 22:27:40 group change Jan 31 22:27:43 SUBSYSTEM=="gpio", PROGRAM="/bin/sh -c '/bin/chown -R root:gpio /sys/devices/platform/ocp/*.gpio'" Jan 31 22:27:53 my line includes that Jan 31 22:28:05 ah ...seen... Jan 31 22:28:06 that's why I said "two lines" in "try replacing the two lines in 80-gpio-noroot.rules by:" Jan 31 22:28:15 sry Jan 31 22:28:17 wait Jan 31 22:29:00 82-gpio-config-pin.rules looks equally awful Jan 31 22:29:16 and doesn't even make sense Jan 31 22:29:28 I don't think those belong to the gpio subsystem Jan 31 22:31:12 I don't have a standard bb.org image on any beaglebone so I can't easily check what sort of device the pinmux helpers are Jan 31 22:32:08 eth0 up in 32 seconds (instead of 45) Jan 31 22:32:22 ok wow Jan 31 22:35:25 since I don't usually work with overlays etc. etc. , I could leave cape-universal disabled.. Jan 31 22:35:40 or enable just what I need... Jan 31 22:37:02 can you try udevadm info -a $path on one of the /sys/devices/platform/ocp/ocp:*pinmux devices? Jan 31 22:37:08 why all these hoops to jump throo? Is this an old cape or a non supported cape? Jan 31 22:37:27 Snert_: we're just trying to fix slow boot caused by cape-universal Jan 31 22:37:53 or apparently caused by horrible udev rules Jan 31 22:39:20 which one ? Jan 31 22:39:29 any will do Jan 31 22:40:24 syntax ? Jan 31 22:40:40 udevadm info -a followed by the path :P Jan 31 22:42:26 https://ghostbin.com/paste/ugqzx Jan 31 22:43:07 ok, then 82-gpio-config-pin.rules can be replaced by: Jan 31 22:43:37 SUBSYSTEM=="platform", DRIVER=="bone-pinmux-helper", RUN+="/bin/chgrp -R gpio '/sys%p'", RUN+="/bin/chmod -R g=u '/sys%p'" Jan 31 22:44:02 done Jan 31 22:44:17 let's see how much that saves :) Jan 31 22:45:37 eth0 up in 21 sec Jan 31 22:46:52 nice Jan 31 22:47:26 yes Jan 31 22:47:44 it could be enough....rather than 46 sec Jan 31 22:48:06 console starts in 10 sec anyway... Jan 31 22:48:46 I go taking a shower.... Jan 31 22:48:47 similiar thing can be done in 83-eqep-noroot.rules, but with DRIVER=="eqep" and the group changed to eqep instead of gpio Jan 31 22:49:23 81-pwm-noroot.rules should already be fixed if you have the latest version of the customizations package Jan 31 22:49:59 go , spit out strings , I'll check on after-bath Jan 31 23:04:54 back Jan 31 23:16:04 83-eqep-noroot.rules has already DRIVER=="eqep" and group eqep Jan 31 23:16:38 I meant you can use the same rule I gave for 82-gpio-config-pin.rules, except with DRIVER=="eqep" and group eqep Jan 31 23:17:49 sigh.... Jan 31 23:20:16 20 seconds Jan 31 23:20:40 yeah didn't expect it would make much difference since there are only three eqep devices Jan 31 23:20:49 the gpios and pinmux helpers are the big ones Jan 31 23:22:26 you mean changing permission and group to each single gpio and pinmux takes all that time to system ? Jan 31 23:23:58 well it used to be spawning a shell (twice) and change the permission and group of *all* gpios and pinmux helpers, each time a gpio was detected Jan 31 23:24:28 so the time this takes is quadratic in the number of gpios Jan 31 23:25:02 ok Jan 31 23:30:15 I have a problem with erased eeprom of LCD7 clone, when I install a new microsd , lcd isn't recognized as a cape, so no video... I should add ovverrided overlay to uEnv.txt before to boot Jan 31 23:31:03 a custom cape is obviously not recognized on a fresh image. that's a feature, not a bug Jan 31 23:31:42 your cape isn't an "LCD7 clone", it's a custom lcd cape that doesn't really resemble the lcd7 Jan 31 23:32:01 it requires different display timings and lacks much of the random other hardware on the lcd7 cape Jan 31 23:32:31 why is this a problem? Jan 31 23:33:01 let's say is a "LCD7 fake" Jan 31 23:33:09 install and enable your custom overlay on it and voila Jan 31 23:33:24 it's just part of the many customizations you're already doing to the system Jan 31 23:34:32 no, the only way in which it resembles the lcd7 is in that it's an lcd cape Jan 31 23:34:44 it is, therefore, simply "a custom lcd cape" Jan 31 23:35:05 yes , it's just I have no immediate access to video and have to access via SSH (searching for dhcp leased ip) Jan 31 23:35:38 you can find its ip via avahi (beaglebone.local) Jan 31 23:35:50 or simpler add dtb and modified uEnv.txt loading sdcard in another machine Jan 31 23:36:08 yep Jan 31 23:36:16 plenty of options Jan 31 23:36:18 not that problem... Jan 31 23:36:38 or plug the fresh system into usb and ssh into it via usb networking or the usb serial console Jan 31 23:36:54 since that still works on a fresh image Jan 31 23:37:02 lot of ways Jan 31 23:37:56 I meant my LCD cape claims to be a LCD7 (that is not) Jan 31 23:38:12 well it no longer does Jan 31 23:38:19 RIP Jan 31 23:38:27 which is overall a good thing Jan 31 23:38:37 even if you previously abused it Jan 31 23:39:20 I haven't yet solved STM power-up timing... Jan 31 23:39:45 that board works badly with 3.3V Jan 31 23:39:46 I thought you were going to power it from the 3.3v of the beaglebone Jan 31 23:40:13 this is just from off-the-shelf board? Jan 31 23:40:19 *just some Jan 31 23:40:41 (rather than being designed for this project) Jan 31 23:40:48 and sys_5V powers too early Jan 31 23:41:54 what do you mean , sry Jan 31 23:42:27 is the stm-board custom designed for this project? Jan 31 23:43:38 if it was designed to be attached to the beaglebone, then you should just toss it back to the designers since they failed to make it interoperable with the beaglebone Jan 31 23:43:40 no, it is a commercial impedance analyzer https://rigexpert.com/products/kits-analyzers/aa-30-zero/getting-started-with-the-zero/ Jan 31 23:43:46 hm Jan 31 23:44:48 then my recommendation would be to use some sort of power switching ic, controlled for example by the reset output of the beaglebone (P9.10) Jan 31 23:45:33 to ensure the stm board is powered up when the beaglebone's powerup is complete, and the stm is powered off when the beaglebone begins powering down Jan 31 23:45:46 (preferably use sys_5v as input to the power switch) Jan 31 23:50:02 I was thinking to a simple low power SMT solid state relay driven by beagle 3.3V Jan 31 23:50:36 sharing the common 5V power supply Jan 31 23:51:12 Time to go bed Jan 31 23:51:15 using a logic output such as reset out is preferred over using a poewr supply to switch a power supply Jan 31 23:51:59 yes it should be done.... Jan 31 23:52:28 and since your board was pretty low power (if I remember correctly), I recommend using sys_5v just as an extra precaution Jan 31 23:53:05 I mean to share the main power supply Jan 31 23:53:11 using a common 5V supply and using the 3.3v to switch would lead to problems with power-down timing Jan 31 23:54:07 to beagle or to stm ? (or both) Jan 31 23:54:39 it would most likely leave the stm powered for too long when doing a shutdown on the beaglebone Jan 31 23:54:58 ok Jan 31 23:55:20 unless you use something like a voltage supervisor to verify that the 3.3v is at least 3V or so, and use that to control the power switch Jan 31 23:55:35 though even that would be iffy Jan 31 23:56:20 dealing with multiple power domains is a headache :) Jan 31 23:57:06 well , thank you again for support Jan 31 23:57:27 (and to have discovered something wrong..) Jan 31 23:58:07 good night Feb 01 00:07:43 zmatt: I get it now, the names of the host interrupts are just hash defines. Can call them what ever I want. Feb 01 00:08:06 the names of the events you mean Feb 01 00:08:26 the host interrupt line used is something pru doesn't have to deal with Feb 01 00:09:02 again, prussdrv uses awful naming, since "EVTOUT" is referring to host interrupts and "PRU0_ARM_INTERRUPT" is an event Feb 01 00:20:35 Okay right.. still a little refinement needed in my understanding then but I can make things work now. Feb 01 00:33:17 I've been looking for case for the BBBW, so far with no luck. Either commercial, or a 3D Print design. ANyone have any pointers? Feb 01 00:46:08 meyal or plastic is what I look for. I prefer metal. Feb 01 00:46:23 I have not found either Feb 01 00:46:25 Snert_: BBBW... wireless... Feb 01 00:46:47 Yes Feb 01 00:47:07 a metal case with external wireless connections would be my choice Feb 01 00:47:21 as opposed to plasteek. Feb 01 00:47:36 Mine as well, but I have not found any Feb 01 00:51:01 it's those antenna connections that make it hard to find. Feb 01 00:51:04 i just made a little platform for my bbblue, pretty cool but not a case Feb 01 00:51:27 let's see it. Feb 01 00:51:35 I've on rare occasion added legs to a beaglebone, but that's about it Feb 01 00:52:43 I've actually had good luck with wireless in a metal case provided the range isn't that far Feb 01 00:54:47 ok uno momento Feb 01 00:56:10 it's worse if the bbw is in a metal case and the then the bb lives inside a metal cabinet. Feb 01 00:58:11 Many options for non-wireless, but none for this variant Feb 01 00:58:54 What are we waiting on seeing? Feb 01 00:59:02 A case? Feb 01 00:59:47 I 3D printed a case for the BBG once. Feb 01 01:00:08 Oh. Platform. Feb 01 01:00:45 I'm failing to find a metal case with provisions for external antennas. Feb 01 01:01:06 Oh. You can always drill the antenna holes out, right? Feb 01 01:01:07 plastik is ok but is a good heat trapper. Feb 01 01:01:13 Oh. Feb 01 01:01:19 no it's just a little platform, and I'm having technical difficulties as usual Feb 01 01:01:33 vdr no big was curious is all. Feb 01 01:02:03 At the moment anything would be fine - just need some basic protection Feb 01 01:02:09 Yea. Aluminum should be a good heat sink but how can you find a way to strategically drill those holes w/ the antenna coming through. Feb 01 01:02:20 Dozens of options for the basic BBB, but none for the BBBW Feb 01 01:02:34 Oh. b/c of WIFI! Feb 01 01:03:01 The old conumdrum. Feb 01 01:03:16 and yes. That is how I spelled it. Feb 01 01:03:47 https://www.tindie.com/products/TEMProducts/beaglebone-black-shell/#shipping Feb 01 01:03:58 I found this a while back. Feb 01 01:05:05 That one is for the BBB Feb 01 01:05:20 Slightly different layout for the BBBW Feb 01 01:05:28 I know. It should work for the BBBW too. Feb 01 01:05:51 You will just have a hole where the Ethernet connection is located. Feb 01 01:06:11 https://www.aliexpress.com/af/beaglebone-black-metal-case.html?SearchText=beaglebone+black+metal+case&d=y&initiative_id=SB_20190131170521&origin=n&catId=0&isViewCP=y&jump=afs Feb 01 01:06:39 And $60 is a bit steep! Feb 01 01:07:04 Yep. Feb 01 01:07:09 sounds cheep for 5 of them actually. Feb 01 01:07:13 https://imgur.com/wmXs5FS Feb 01 01:07:20 Metal is not cheap, esp. when it needs to be altered. Feb 01 01:07:44 vdr: nice! perfect sized too Feb 01 01:07:59 Hey. I want to share too! Feb 01 01:08:21 Hello? Feb 01 01:08:31 Unless I am miising somethng the $60 is for 1 Feb 01 01:08:36 that link had a metal case for 18bux Feb 01 01:08:39 https://imgur.com/YNrLpCv Feb 01 01:09:08 vdr that's a metal platform? or plasteek? Feb 01 01:09:20 That is nice. Feb 01 01:09:28 grooves are for zip ties, or it could be drilled or... it's plastic, a material called delrin Feb 01 01:09:34 made from scrap at work Feb 01 01:09:46 delrin is Good. Feb 01 01:10:29 Yeah - the AliExpress one would work I suspect Feb 01 01:10:44 the stand-offs are 1/4" base is also, enough to clear the components plus zip ties Feb 01 01:10:49 Guest60757: 60bux for 1 lot. 1 lot is 5 pieces Feb 01 01:11:08 Guest: That one is $60.00 plus S & H. Feb 01 01:11:08 or 18bux each in the middle of the page Feb 01 01:11:20 delrin machine's nice too, it pays to have a 60K cnc at your disposal Feb 01 01:11:31 gotta go Feb 01 01:11:46 Later. Feb 01 01:12:02 downloaded the cad data for the board from grabcad.com Feb 01 01:12:18 Not ideal, but.... Feb 01 01:12:43 the other metal cases I see are din rail mount. Feb 01 01:13:04 SOmewhat surprised none have been uploaded to Thingiverse Feb 01 01:13:26 In any case, thanks for the pointers Feb 01 01:14:06 They have many. Feb 01 01:14:08 I found a bunch. Feb 01 01:14:20 None for the W Feb 01 01:14:25 Oh. Feb 01 01:14:36 thems will be plasteek. Feb 01 01:14:37 UNless you have some variant of search I am missing Feb 01 01:14:48 Let me see. Hold please. Feb 01 01:14:49 which may be fine, but trap heat. Feb 01 01:15:16 you could always swiss cheese the plastic case Feb 01 01:16:09 Nope. You were right. Feb 01 01:16:21 There is always Freecad. Feb 01 01:16:38 yea thingiverse centers around 3d printed so by nature it's plastic Feb 01 01:16:58 Or like vdr typed, that one site could help. Feb 01 01:17:20 grabcad Feb 01 01:17:43 Hey Guest: Do you want to work on making a BBBW case? Feb 01 01:18:21 I'm in the same boat with bbx15 - no metal cases available at all for that one. Feb 01 01:19:34 brb Feb 01 01:19:52 Not at the moment Feb 01 01:19:57 Okay. Feb 01 01:20:21 I used grabcad to get the data for the bb board, used that data to draw what I wanted for the base Feb 01 01:20:37 At some point will get set up to create the 3D files, but no bandwidth now. Feb 01 01:20:56 what to do with the antenna? coming out of a case? Feb 01 01:21:58 Generally you would run a iFl to bulkhead SMA connector, then attach antenna(s) there Feb 01 01:22:38 yes those are available. Just drilla hole. Feb 01 01:23:02 you have no actual hardwire enet all, right? Feb 01 01:23:28 the bbbw has no ethernet Feb 01 01:24:27 so putting the hardwire enet in the wireless vlan isn't an option and doesn't fit the use case. Feb 01 01:25:51 https://www.mouser.com/ProductDetail/Taoglas/CABR01?qs=%2Fv8iy7V9uiw5JJSqA3Aebw%3D%3D&gclid=Cj0KCQiA1sriBRD-ARIsABYdwwE1Tt4QJ98NRCR0cuq1sMyDVirhyxCkX0NUnxty0__3rfCvKuPkFKgaAg6JEALw_wcB Feb 01 01:25:57 is that what you are talking about? Feb 01 01:26:18 that's big Feb 01 01:26:34 well, 1/4" round hole in the case. Feb 01 01:27:58 Looks right, but not familiar with 'HSC' type connector Feb 01 01:28:04 Will be similar. Feb 01 01:28:10 Gotta run. Thanks Feb 01 01:28:45 those ittybitty u.fl flavored connectors - I always get the manuf's datasheet and make sure it's the right sex. Feb 01 01:29:11 as opposed to just seeing the online pic Feb 01 01:29:43 Good idea. Some have 5Ghz too. Feb 01 01:30:02 Some are both 2.4 and 5Ghz. Feb 01 01:30:16 hirose is a manuf name listed on mouser Feb 01 01:30:34 so a good google on hirose u.fl should do it Feb 01 01:30:34 Aw. Feb 01 01:32:40 https://www.amazon.com/Flex-Case-BeagleBone-Black-Wood/dp/B00JRKCO7G <-- these crack me up. No way. Feb 01 01:32:58 let's encase our bbb in kindling! Feb 01 01:33:54 Wood? Feb 01 01:35:31 ya! amazing lol. Feb 01 01:35:37 https://www.amazon.com/GeauxRobot-BeagleBone-Black-Compact-Case/ Feb 01 01:35:40 I saw it. Feb 01 01:35:42 It is cool. Feb 01 01:36:10 I think they are fun to make w/ laser engravers. Feb 01 01:36:27 At least, I think that is how they made that one. Feb 01 01:36:56 You could put a heatsink piece of aluminum in that slim case. Feb 01 01:37:11 Love the style and look. Hate the Flame On factor though. Feb 01 01:37:37 Oh. What is Flame On? Feb 01 01:37:44 The beagle print? Feb 01 01:37:46 but how often does a bb actually flame on. Feb 01 01:37:51 Oh. Feb 01 01:37:52 I got you. Feb 01 01:39:47 I guess it depends on how much processing is done while it runs for a bit. Feb 01 01:40:34 I went to grabcad to look at the 3D models of the BBB. Feb 01 01:40:41 They have three or four. Feb 01 01:41:27 No BBBWs though. Feb 01 01:42:14 Snert: Do you use a BBBW or want to make a enclosed item for that board? Feb 01 01:44:23 I don't use the wireless version. Not yet. Feb 01 01:44:45 I was just tryimg to find something for someone else who asked. Feb 01 01:45:34 Oh. Feb 01 01:45:47 I had to switch to raspi cause the bbb lost it's hardwire enet port :( Feb 01 01:46:17 Wireless is great as far as it goes but in terms of reliability I need hardwire. Feb 01 01:46:34 Okay. No issue. I figured it would be fun to make a 3D enclosure for the good of the community. Feb 01 01:46:43 Snert_: "lost it's hardwire enet port" ? Feb 01 01:46:55 Make everything Open Source, easy to understand, and done. Feb 01 01:46:56 you damaged your ethernet somehow? Feb 01 01:47:11 no...they just stopped putting a hardwire port on a bbb. Feb 01 01:47:16 ehm, what? no Feb 01 01:47:21 the bbb and bbbw are two variants Feb 01 01:47:46 BBB = Ethernet Feb 01 01:47:49 the bbbw did not replace the bbb Feb 01 01:47:53 BBBW = WIFI Feb 01 01:47:56 that Feb 01 01:48:11 you can simply choose whether you want ethernet or wifi/bt Feb 01 01:48:47 https://beagleboard.org/black-wireless <-- I see no hard enet port in addition to wireless. Feb 01 01:49:00 that's because that's the black-wireless Feb 01 01:49:01 not the black Feb 01 01:49:20 you have *either* wifi/bt (bbbw) *or* ethernet (bbb) Feb 01 01:50:07 https://beagleboard.org/black is the ethernet version Feb 01 01:50:20 yea, that's the one I use for DNS. Feb 01 01:50:42 but I'd do more with the wireless if it existed. Feb 01 01:51:14 like make my leviton in wall light switches connect to it. Feb 01 01:51:49 but anyways beer:30 so gottarun Feb 01 01:52:21 if you want ethernet + wifi, you can always just stick a wifi usb stick into the BBB Feb 01 01:53:31 or a BBE WIFI ... https://www.sancloud.co.uk/?page_id=1028 Feb 01 01:54:14 (those also have gigabit ethernet and the option of 1G of ram) Feb 01 02:31:06 we had to write a SPI driver, but I'm not sure it's correct Feb 01 02:31:15 it may be the root cause of the issues we had Feb 01 02:31:26 maybe there's a blatant mistake in it Feb 01 02:32:06 we used McSPI0 in master mode with only one channel, with D0 as input and D1 as output Feb 01 02:32:13 we tried with and without FIFOs Feb 01 02:38:50 the sequence we do to send/receive in full-duplex is bsp_spi_send_start_dummy(), bsp_spi_sel_addr(), beagle_spi_ioctl(), bsp_spi_send_stop(); we use interrupts Feb 01 02:38:54 here's the code: https://paste.serveur.io/O4428atl.c Feb 01 02:40:21 the AM335x datasheet isn't the most clear of all datasheets I've read Feb 01 02:40:45 lines 42-46 is useless, MODULEMODE is not a status register Feb 01 02:41:16 status field I mean Feb 01 02:41:21 it doesn't change unless you write to it Feb 01 02:44:33 right Feb 01 02:44:56 that driver seems to work, when I write then read from the module connected to SPI we have the correct values Feb 01 02:45:00 you probably mean TRM, not datasheet :) and it's pretty decent.. definitely could be better sometimes, but overall TI's documentation is quite good in comparison to what I've seen of other SoC manufacturers Feb 01 02:45:22 but there's maybe some kind of race condition related to interrupts, in the heat of the things it begins to give nonsensical values Feb 01 02:45:40 yeah the datasheet in itself is good, but it seems like it's been translated from another language Feb 01 02:45:51 so some sentences aren't very intelligible Feb 01 02:46:06 hmm, can't say I've ever gotten that impression Feb 01 02:47:52 I feel like rewriting the driver from scratch Feb 01 02:48:01 but it's my comrade that wrote it, he won't be happy that I trash his code Feb 01 02:48:08 and I'm not even sure the problem is in it Feb 01 02:48:57 hmm, why is it meddling with the test register? (SYST) Feb 01 02:49:32 that's a good question Feb 01 02:49:36 you're speaking of line 61 ? Feb 01 02:49:45 that's precisely the line that solved all our problems Feb 01 02:49:48 that made the code work Feb 01 02:50:01 we found that in LK code, the little kernel thing from google Feb 01 02:50:17 and apparently they take their code from some TI reference implementation if I understood correctly Feb 01 02:50:42 but SYST is system register, not test register Feb 01 02:51:16 no something just went wrong in the docs there, it is definitely just for test Feb 01 02:51:53 the doc said "This bit must be cleared prior attempting to clear a status bit of the MCSPI_ IRQSTATUS register." Feb 01 02:51:54 are you saying the SSB bit somehow gets set? that seems so incredibly implausible Feb 01 02:51:55 about SSB Feb 01 02:52:06 yes, of course, it can't be set Feb 01 02:52:09 but it isn't set by default Feb 01 02:52:28 as long as the SSB bit is set, all irq status bits get set every clock cycle Feb 01 02:52:33 so you wouldn't be able to clear any Feb 01 02:52:41 they say must be cleared, I understand that as must be cleared every single time before clearing IRQSTATUS Feb 01 02:52:55 therefore the bit must be cleared before clearing any irqstatus Feb 01 02:52:59 that's what they mean Feb 01 02:53:04 yes Feb 01 02:53:10 but that's only relevant if you set the bit in the first place Feb 01 02:53:13 so just clear it once for all in the initialization ? Feb 01 02:53:14 which is just used as integration test Feb 01 02:53:17 ah Feb 01 02:53:26 well without that line the code didn't work Feb 01 02:53:33 I didn't write the code, but that's what my comrade said Feb 01 02:53:34 are you sure it's not just acting as a delay? Feb 01 02:54:29 I have trouble believing it could be doing anything more than that Feb 01 02:54:39 not entirely, but it's a fast operation so I don't think that'd delay by much Feb 01 02:54:49 maybe it got set by something else then ? Feb 01 02:54:50 it does a read Feb 01 02:54:55 yes Feb 01 02:54:56 therefore takes at least 100 cycles Feb 01 02:55:00 ah ? Feb 01 02:55:12 reading from MMIO takes that much time ? Feb 01 02:55:22 "ping time" to peripherals is quite significant Feb 01 02:55:35 ah Feb 01 02:55:44 I see Feb 01 02:56:02 what ARM memory attributes does RTEMS use for MMIO? "Device" or "Strongly Ordered" ? Feb 01 02:57:00 how can I check that ? Feb 01 02:57:23 uhh? documentation? source code? Feb 01 02:58:00 yeah I meant like if there's a register I can probe or something Feb 01 02:58:07 but I'm searching the docs meanwhile too Feb 01 02:58:11 it also affects performance: writes to Device memory are fast ("fire and forget") while writes to Strongly Ordered memory are as slow as reads **** ENDING LOGGING AT Fri Feb 01 02:59:56 2019