**** BEGIN LOGGING AT Fri Jun 19 02:59:57 2020 Jun 19 03:29:51 making tunes? Jun 19 03:33:15 Yep! Jun 19 03:33:52 what kind Jun 19 03:33:58 w/ BELA and Course 4, I got me a little mixer for oscillators! Jun 19 03:34:10 They call it detune. Jun 19 03:34:33 I am basically warping sounds for now. Jun 19 03:35:12 I am waiting to learn more before I plug in the guitar to the old BELA and BBB. Jun 19 03:37:09 MattB0ne: I tried to figure out what i am doing incorrectly. I am basically altering decibels to linear amplitude. Jun 19 03:37:16 But... Jun 19 03:37:41 The source I have is busted. So, I contacted their forum for fun. Oops. Jun 19 03:38:23 The BELA people made this easy to use sampler/mixer out of a GUI. It is neat for now. Jun 19 03:39:29 For future use, and w/ their future Courses, I plan on attempting sensor related NOISE making. Jun 19 03:41:52 Like pots and pans but w/ current and circuitry! Jun 19 03:43:12 Anyway, the cpp program will not allow me to call a float in the BELA render function. Jun 19 03:44:10 way over my head but good luck Jun 19 03:44:37 zmatt: to start the ecap I just need "pruss.ecap.config |= 1 << 20 " Jun 19 03:45:08 Thank you. I need to figure it out to move on to pitch. Jun 19 03:45:41 set_ good luck Jun 19 03:46:02 Yea! Jun 19 03:49:16 Godspeed! Jun 19 03:52:29 Good luck w/ the pru stuff. I revieved it before and tried. I could not find time for me and pru. Jun 19 03:52:53 It seems very complicated and drawn out. I hope you figure out your query. Jun 19 08:27:27 hello Jun 19 08:28:08 were the logs of this chat are saved? can't find anything >2018 with google (obsolete beagleboard page) Jun 19 08:28:49 see topic Jun 19 09:14:00 @zmatt, are you here? Jun 19 12:04:59 cannot git update tools scripts: unable to access github server certificate verification failed. Jun 19 12:05:10 any clues? Jun 19 13:23:57 Parduz: is the system date/time on your beaglebone correct? it should be if it has internet access (since it'll use NTP, but just to confirm) Jun 19 13:27:19 HI zmatt: yup, that was the problem Jun 19 13:27:33 i'm still struggling with boot time Jun 19 13:28:33 by reading here and there, i've decided to upgrade the kernel s now i have the 4.4.145 r23 Jun 19 13:29:34 4.4 ? that's really ancient Jun 19 13:30:37 that's what the script bringed down Jun 19 13:30:51 ? Jun 19 13:31:10 the kernel upgrade script only upgrades _within_ the major kernel series you're using Jun 19 13:31:22 so if you were using 4.4-ti, it'll give you the latest 4.4-ti kernel Jun 19 13:31:37 it won't upgrade you to a later major kernel series unless you explicitly request it Jun 19 13:32:08 ok. should i? or should start with a fresh whole image Jun 19 13:32:10 ? Jun 19 13:32:34 I'm puzzled by the 4.4... I'm pretty sure the default kernel for the image date you mentioned was 4.14 Jun 19 13:33:00 or wait, was your image 2019 or 2018 ? Jun 19 13:33:14 my last one was initrd.img-4.14.108-ti-r122 Jun 19 13:33:31 what i have no is initrd.img-4.4.145-bone-rt-r23 Jun 19 13:33:32 with "image" I mean filesystem image Jun 19 13:33:38 wait what Jun 19 13:33:48 why did you switch to an ancient bone-rt kernel? what did you do? Jun 19 13:34:22 what command did you enter? Jun 19 13:35:39 git pull then sudo ./update_kernel.sh --bone-rt-kernel --lts Jun 19 13:36:02 oh other words you _asked_ it to upgrade your fairly recent 4.14-ti kernel to an ancient bone-rt kernel Jun 19 13:36:11 doh Jun 19 13:37:01 ok, i reflash then come back here. Jun 19 13:37:27 I mean, you can just switch back Jun 19 13:37:45 reflashing seems unnecessary Jun 19 13:38:01 you've clearly already done significant boot time optimization Jun 19 13:38:19 how i switch back? Jun 19 13:39:46 /opt/scripts/tools/upgrade_kernel.sh --ti --lts-4_14 will bring you back to 4.14, or you can use --ti --lts-4_19 to upgrade to 4.19-ti Jun 19 13:41:44 (you can also switch between installed kernels by changing uname_r in /boot/uEnv.txt to any kernel version that's already installed) Jun 19 13:42:55 once you're back running on a sane kernel version you'll want to remove the weird old bone-rt kernel, sudo apt-get purge linux-image-4.4.145-bone-rt-r23 Jun 19 13:43:09 ok Jun 19 13:43:25 updating it right now Jun 19 13:43:40 i guess i've killed the network clock sync also :| Jun 19 13:43:58 i need to set the date each reboot Jun 19 13:44:16 on reboot even? that's definitely super weird Jun 19 13:44:23 system clock is normally preserved across reboot Jun 19 13:44:53 dunno what i've done :| Jun 19 13:47:11 connmand is usually the ntp client (weirdly)... last time I saw a boot graph you were still using that, so it's weird that system time is not getting set right for you (unless you don't have normal working internet access nor a local ntp server) Jun 19 13:47:39 but even without ntp, it should still get preserved across reboot... lemme check which service manages that Jun 19 13:47:51 thnx Jun 19 13:55:48 it seems there's no service that manages it, I think setting the system clock from the rtc is done by the kernel and setting the rtc from the system clock is presumably likewise handled either the kernel or perhaps by systemd itself Jun 19 13:56:07 I've never seen it not be preserved across reboot Jun 19 13:56:29 (though obviously it won't get preserved across power-cycle) Jun 19 13:57:19 i always use "sudo reboot" Jun 19 13:57:51 what does sudo timedatectl show show? Jun 19 13:58:50 Local time: Thu 2016-11-03 17:17:56 UTC Jun 19 13:58:59 RTC time: Sat 2000-01-01 05:41:24 Jun 19 13:59:02 stop Jun 19 13:59:07 don't paste multiline output into chat Jun 19 13:59:10 you should know better Jun 19 13:59:15 use a paste service like pastebin.com Jun 19 13:59:40 there was all what i thought to paste Jun 19 13:59:57 hello i am trying implement a communication between Main ARM processor and PRU. There is a shared RAM location of 64kb which i want to use. I am struggling with what path to take there are some implementations with RPmsg some other says UiO is a option. can you please guide me Jun 19 13:59:59 everything else is set to "no" Jun 19 14:00:37 deepankarmaithan: what "shared RAM location of 64kb" ? Jun 19 14:01:30 https://www.ti.com/product/AM3358 here you can see there is a shared ram of 64KB Jun 19 14:01:50 deepankarmaithan: if you use the uio-pruss driven then it'll allocate a shared memory region for pru's use in ddr memory of configurable size (default 256 KB), and of course you can use the pruss local memories (which are 8K+8K+12K) Jun 19 14:01:52 see the block diagram image Jun 19 14:01:57 you mean the OCMC ram ? Jun 19 14:02:19 yes Jun 19 14:02:26 some if it is used by the linux kernel, but it is possible to allocate some of it for your own use Jun 19 14:02:31 *some of it Jun 19 14:03:49 can this be done using UiO Jun 19 14:04:45 *this also makes me think how will i know which part of it is being used by the linux Jun 19 14:07:17 I am new to this communication stuff so it might be a silly question but if i am writing my PRU codes in c and using remoteproc to load and start stop. can i also use UiO simultaneously Jun 19 14:08:35 https://pastebin.com/MaMH844M Jun 19 14:09:14 this particular way of allocating shared memory can be used regardless of what driver you use for pruss itself yeah Jun 19 14:09:56 okay. Thanks a good starting point. Jun 19 14:10:39 so this example allocates 16KB at offset 0x4000 ... I think the max you'll be able to allocate is 56KB (0xe000) at offset 0x2000 Jun 19 14:13:05 I think that is enough for my requirement. Can you please also share a good link for uio-pruss example implementation. I found several but are very old and things have changed now Jun 19 14:13:14 the "export;" actually already makes it accessible from userspace via sysfs (/sys/bus/platform/devices/40300000.sram/40304000.sram) but you can't mmap that so it's kind of useless Jun 19 14:13:58 deepankarmaithan: yeah the libprussdrv library is old and kinda sucks... I've made a python library to replace it: https://github.com/mvduin/py-uio Jun 19 14:14:10 I've also been wanting to make a newer C/C++ library but haven't gotten around to it Jun 19 14:14:54 last boot chart http://svgur.com/s/MAd - related log via serial: https://pastebin.com/r7h7jLw4 Jun 19 14:15:11 unfortunately py-uio doesn't have much documentation, but I'm often here if you have questions :) Jun 19 14:15:29 I basically want to write a gpio chip driver that will get data from userspace and then will write it to a memory location from where the PRU will read it and then will send it to the shift register connected to the peripheral Jun 19 14:16:16 so basically send a raw stream of serial output Jun 19 14:16:24 yes Jun 19 14:16:24 with the data transferred from userspace to pru via a ringbfufer Jun 19 14:16:30 *ringbuffer Jun 19 14:16:48 keep in min that reading ocmc is still much slower for pru than reading prus local memory Jun 19 14:17:10 though it should at least be fairly deterministic Jun 19 14:17:36 using pruss memory for the ringbuffer would yield the highest performance Jun 19 14:18:21 also, to avoid synchronization bugs, make sure the write-pointer/write-index that's updated by userspace is located in the same memory as the buffer... either both in ocmc or both in pruss ram Jun 19 14:18:47 i am contemplating on ringbuffers. Yes using a pruss memory will yield more performence but will it not be slower for the ARM to write there. I mean near to PRUSS is faster for pru and slower for arm Jun 19 14:19:06 no, ocmc is about as far away for ARM as PRUSS Jun 19 14:19:33 okay. Jun 19 14:19:58 either way, what will help is using "big" writes, e.g. a single neon store instruction can write 64 bytes at once Jun 19 14:20:51 or, what I did, is patch the kernel to make memory mapped using /dev/mem or uio be mapped as "device memory" rather than the painfully slow "strongly ordered memory" Jun 19 14:21:18 "device memory" is the same type that's used in kernel space, so I'm not sure why it's not using it for userspace Jun 19 14:21:43 that change causes writes to be "fire and forget", so the cpu won't wait for confirmation that the write has landed on the target Jun 19 14:22:20 which also means that write performance won't really depend on how far away the target memory is Jun 19 14:22:51 Okay some clarity and alot of information to process for me. :) . I have to take baby steps. *Figuring out the first thing to do now Jun 19 14:23:24 the patched I did are the first two patches in this directory: https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.14/patches/local Jun 19 14:24:12 hmm I thought I had a nicer version of this patch, maybe I never pushed it to github... I'll have to check that Jun 19 14:26:04 thanks going through them Jun 19 14:26:18 it's a tiny patch Jun 19 14:26:24 really tiny Jun 19 14:27:08 but it does mean userspace needs to be aware of the change in semantics when using uio or /dev/mem (you could also just patch uio and leave /dev/mem alone) Jun 19 14:28:06 ok Jun 19 14:31:39 usually it doesn't matter that writes are performed asynchronously without the cpu waiting for them, but sometimes you just really want to know a write has landed at the target. the solution for that is performing a dummy read from the same target, which is also known as an "ocp barrier". example: https://elixir.bootlin.com/linux/v4.19.128/source/arch/arm/mach-omap2/pdata-quirks.c#L203 Jun 19 14:32:58 Hi, all. quick question: BBB wireless: in u-boot, usb start reports "USB0: port not available" ( I have USB stick inserted in the USB0). What is missing? Jun 19 14:33:23 david87: usb 0 is the mini-B device port. the usb host port is usb 1 Jun 19 14:33:50 or micro-B for the BBB wireless I think, it's mini-B on the original BBB Jun 19 14:35:15 clock set with sudo timedatectl set-ntp on and reboot, seems working now Jun 19 14:35:34 Parduz: "set-ntp on" is a bad idea as long as you're using connman Jun 19 14:35:42 since it is already an ntp client Jun 19 14:36:02 so you'll have two ntp implementations fighting each other Jun 19 14:36:07 uh Jun 19 14:36:20 micro-B is USB client port. I was referring to USB Host controller (device) port. I have USB drive inserted into USB0. Is USB driver software included in the UBOOT? Jun 19 14:36:46 david87: I understand you're referring to the usb host port, but what I'm saying is that that's usb1 Jun 19 14:36:49 not usb0 Jun 19 14:37:08 how to start USB1, then Jun 19 14:37:15 if u-boot doesn't include a usb host stack then I assume "usb start" would just say unknown command Jun 19 14:37:54 thank Jun 19 14:38:06 I've never tried to use the usb host port in u-boot, does something like "fatls usb 1:1" not work? Jun 19 14:38:16 after usb start Jun 19 14:39:21 no usb port is started. Jun 19 14:39:54 usb start: USB0: Port not available. No USB1 reported Jun 19 14:41:27 ok, maybe the command just exists because usb gadget support is included but no usb host support is... that's possible I guess, I don't know how u-boot has been configured exactly Jun 19 14:42:03 a usb host stack is a fairly complicated and bulky thing Jun 19 14:42:44 Thank you. I will find a version to add USB stack into u-boot. Jun 19 14:43:42 The NXP (FreeScale) iMX6 includes USB stact in the UBoot Jun 19 14:43:56 note that the linux driver for usb on the am335x is pretty crappy, so I expect poor performance if you're using a usb drive as rootfs Jun 19 14:44:03 oh I know u-boot can support it Jun 19 14:44:44 but maybe it wasn't working properly, or maybe it just made u-boot excessively large... I dunno, I didn't chose the u-boot configuration for the bbb Jun 19 14:45:08 Do you have any suggestions or point me some resources for BBB wireless to be flashed through USB Client port for bare-metal Jun 19 14:45:52 flashing or just booting? booting a baremetal application via the usb device port is quite easy Jun 19 14:46:06 flashing would mean booting some sort of flasher I guess Jun 19 14:46:13 TI might have tools for that, not sure Jun 19 14:46:41 Well, it has to be booted from USB client, then Flash eMMC from USB Client Port (mini-B) Jun 19 14:47:19 Will TI Tools work for BeagleBone Black? Jun 19 14:47:32 what "TI Tools" ? Jun 19 14:47:57 Well, You are referring TI tools Jun 19 14:48:38 I think I've seen some tools for flashing an AM335x-based device, but I don't remember specifics, you'd need to search Jun 19 14:48:52 but I don't see any reason why they would not work on the BBB Jun 19 14:48:58 OK, Thank you Jun 19 14:50:21 zmatt, can you look at the boot graph and log? Jun 19 14:51:14 while it boot the terminal do a big pause after "Started Raise network interfaces" Jun 19 14:51:20 Parduz: the serial console output isn't very useful, please give the full log from journalctl Jun 19 14:51:35 ok Jun 19 14:52:54 or analyze it youreslf first, see if udev.log_priority=6 was enough to make udev log what it's doing in sufficient detail, otherwise bump it to udev.log_priority=7 (which I'd imagine will create a ton of spam in your log) Jun 19 14:53:22 also you're still using a weird kernel Jun 19 14:53:41 you forgot the --ti option to upgrade_kernel I imagine Jun 19 14:53:49 since you're on a 4.19-bone-rt kernel Jun 19 14:54:23 sudo update_kernel.sh --ti --lts-4_19 Jun 19 14:54:59 ehh, okay then I don't understand how the upgrade_kernel.sh script works (I never use it) Jun 19 14:56:35 oh, --ti-kernel Jun 19 14:56:37 not --ti Jun 19 14:57:04 was about to say it Jun 19 14:57:11 ok, back to updating it Jun 19 14:57:35 it would have been nice if it gave an error on unknown arguments :/ Jun 19 14:58:57 4.19.94-ti-r45 is this one? Jun 19 14:59:42 also keep in mind that omitting "quiet" from cmdline and increasing udev's log_priority will both slow down boot, so you should just use them to debug issues and then add remove the udev.log_priority argument and add "quiet" back... in fact you can add "quiet" back already since the serial console output isn't very useful anyway Jun 19 15:00:00 that's at least the right series yeah Jun 19 15:00:35 why is0'nt useful? Jun 19 15:00:55 what do you see there that's useful? Jun 19 15:01:14 removing "quiet" is mostly for debugging kernel issues Jun 19 15:03:41 wpa supplicant is rather useless on a beaglebone without wifi (unless you're using 802.1X authentication I guess) Jun 19 15:04:20 yup, we already tried to remove it without success, at the beginning of this year Jun 19 15:04:34 something will keep it on Jun 19 15:04:51 connman probably starts it? Jun 19 15:05:00 it obviously can't if you just remove it Jun 19 15:05:07 what i don't get why there 20sec after "Found device /dev/ttyS0" Jun 19 15:05:55 https://pastebin.com/jehgyX1i Jun 19 15:05:55 yes that's the thing we're trying to debug using udev.log_priority, but you haven't yet shared (or possibly even looked at?) its log output yet Jun 19 15:06:03 until now Jun 19 15:06:07 :) Jun 19 15:06:44 nothing useful here, try log priority 7 Jun 19 15:07:07 also journalctl -o short-monotonic may be more useful, it gives high-precision monotonic timestamps since boot Jun 19 15:07:31 k, 5 minuts and i'll do Jun 19 15:07:34 huh Jun 19 15:07:37 systemd-udevd[181]: Unknown udev kernel command line option "udev.log_priority" Jun 19 15:11:07 oh, systemd 232 ... that's like, really old Jun 19 15:11:57 right, you're still using debian stretch, so everything is really old Jun 19 15:20:39 while i'm purging then rebooting: SHOULD i change image? will it gives me better chanches for boot time? Jun 19 15:21:09 you mean purge silly kernels? that's something you do _after_ rebooting to the new kernel Jun 19 15:21:17 and it's just to clean up disk space Jun 19 15:21:17 yup Jun 19 15:21:44 what do you mean by "change image" ? Jun 19 15:22:16 you sayd "you're still using stretch, so everything is really old" Jun 19 15:23:17 should i restart with the newest debian and image available? Jun 19 15:23:39 restart = redo mu own changes on a BBB image Jun 19 15:23:45 *my Jun 19 15:24:17 right... I mean, you can either upgrade your system to buster or start with a fresh image and redo your customizations... at some point the former will be less hassle, but it requires a bit of care during the upgrade procedure. i.e. it requires you can cope with debian asking you "this config file has changed upstream but you also have local modifications, what do you want to do?" Jun 19 15:25:45 I'm fairly comfortable with dealing with such things, but probably not everyone is. then again, it's something I've become comfortable with by doing it obviously Jun 19 15:26:00 (I also run debian on my laptop so that helps of course) Jun 19 15:26:48 no, ill just start with a fresh image. My question is if i should do 'cause my current image is too old .... or bugged, or haunted, or whatever. What advantages i'll get that justify to start again from a fresh image? Jun 19 15:27:05 regardless, I do recommend installing etckeeper. it'll turn your /etc/ into a git repository to track changes to config files over time (both manual ones and changes due to package installs/updates/removals) Jun 19 15:27:32 well the thing is, debian stretch is kinda obsolete Jun 19 15:27:50 etckeeper: this is a very good suggestion Jun 19 15:28:26 should i change udev.log_priority to 7? or it is really an unknown command? Jun 19 15:28:28 like, if you have a production system shipped that's still using it I can imagine wanting to stick with it, but if you're still building a new system then I wouldn't want to _start_ with something that's already ancient Jun 19 15:28:43 it says it doesn't understand it, which probably means your systemd-udevd is too old to understand it Jun 19 15:28:56 systemd-232 dates from 2016 Jun 19 15:32:56 rebooting, meanwhile. Jun 19 15:40:00 geez Jun 19 15:40:26 too much long, pastebin don't take it Jun 19 15:41:55 what did you do to get more log output? Jun 19 15:42:11 there's a lot of error Jun 19 15:42:48 need to go back to a stable situation Jun 19 15:43:13 i think 'll be here monday :( Jun 19 15:43:20 thanks for your help Jun 19 15:44:42 OH , i was wrong Jun 19 15:45:19 seems that the log parameter for the old version is udev.log-priority Jun 19 15:45:49 i put it also, and unless the kernel stops at the first unknown command, it worked. Jun 19 15:46:39 they're not interpreted by the kernel anyway (the kernel just silently ignored anything unknown, so kernel parameters are here just used to pass config options to early userspace) Jun 19 15:47:01 if log priority 7 creates too much spam, try 6 first Jun 19 15:47:38 yup, trying now Jun 19 15:50:27 https://pastebin.com/1W5UuStV (journal, priority 6) Jun 19 15:51:11 http://svgur.com/s/MB9 graph Jun 19 15:51:36 have you tried to look at the log? because the problem is immediately obvious Jun 19 15:51:51 and it's self-inflicted Jun 19 15:53:40 i see this: pvrsrvkm: loading out-of-tree module taints kernel Jun 19 15:53:48 googled about it Jun 19 15:53:57 not sure if it is the problem Jun 19 15:54:21 so here's another reason to start with a clean image: if you have etckeeper installed from the start, and begin by optimizing boot time before you add "features" or other customizations, then you'll notice when a change you make is causing slow boot Jun 19 15:54:30 no that's a completely irrelevant remark Jun 19 15:54:39 "tainted" is just the kernel equivalent of "warranty void if seal is broken" Jun 19 15:54:41 look at timestamps to see where it's spending time Jun 19 15:54:48 wait Jun 19 15:54:54 the 3 rules Jun 19 15:55:04 pmount Jun 19 15:55:12 yup Jun 19 15:55:23 trying to mount anything from an udev rule is already broken Jun 19 15:55:35 inherently Jun 19 15:56:14 and the invocations also look like nonsense to me Jun 19 15:56:14 ok Jun 19 15:56:45 as for the taint: you can definitely just remove all sgx modules packages, you're not using them anyway and it'll avoid the kernel taint Jun 19 15:57:16 lol i don't even know what they are :D Jun 19 15:57:27 kernel driver for the sgx530 3d gpu Jun 19 15:57:38 (which is not supported when using X11) Jun 19 15:57:55 (and requires userspace libraries which are not installed) Jun 19 15:58:31 ok, so i'll start again monday with a fresh and updated image and see where i'll go Jun 19 15:58:59 that rules were the only working solution i've been able to do to aoutmount USB sticks Jun 19 15:59:35 I think that's a topic I've commented on previously Jun 19 15:59:42 i still have the logs when you explained me what to do instead, so i'll ook at it Jun 19 16:00:38 thnx again, time to close the office Jun 19 16:00:45 have anice w.e. Jun 19 16:00:53 since the stick will always be in the same usb port, I think it's possible to match on that... though the better solution would be to have your application receive the notifications from udisks and use it to mount/umount the stick Jun 19 16:01:35 or I guess you can do without udisks... but it might make things simpler Jun 19 16:01:46 dunno Jun 19 16:01:48 i'll look at that Jun 19 16:01:54 I probably said more insightful things back then Jun 19 16:02:16 my boss is kicking me out of the building Jun 19 16:02:19 lol Jun 19 16:02:22 ciao :) Jun 19 17:47:17 the splitz Jun 19 20:53:48 I'm trying to apply our device tree mods from 4.1.19-bone20 to 4.19.50-bone35. Declarations have changed a lot ... and pinmux uses "AM33XX_IOPAD" for everything now. I can't find where that's defined to understand how to map from old to new. Anyone point me at that? Jun 19 20:54:47 Ragnorok: pinmux hasn't changed, the macros are just for readability Jun 19 20:55:06 include/include/dt-bindings/pinctrl/am33xx.h Jun 19 20:55:08 but old pinmux blocks using magic hex values should work unmodified Jun 19 20:55:12 -include Jun 19 20:55:38 I figured, but the numbers in the macros don't line up. I'd like to use the new way if possible. Thanks! Jun 19 20:56:08 there's a cascade of magic offsets added and subtracted via various nested macros Jun 19 20:56:24 in fact I have trouble thinking of any customizations you might do in an on top of the base dts that would require modification for 4.19 compared to 4.1 Jun 19 20:56:35 the last major incompatible changes were 3.8 -> 4.x I think Jun 19 20:57:06 Ragnorok: are you using an overlay or a custom dts ? Jun 19 20:58:12 Dunno. Tried just tossing the dtb and it crashed. Tried just compiling the old dts and it crashed. Now I'm trying to update the new ones. It is a custom dts made by modding some existing ones. Jun 19 20:58:34 oof, that's always a bad idea Jun 19 20:59:05 I didn't do this work originally. I'm simply attempting recreate it, now the guy who did it is no longer here. Jun 19 20:59:08 like, for a beaglebone you'd typically want to #include an existing beaglebone dts and then build on top of that Jun 19 20:59:54 then to move to a new kernel, you can probably use the same custom .dts since any kernel-dependent differences would be handled in the dts or dtsi you #include Jun 19 21:00:19 anyway, your crash is probably not related to pinmux since that simply hasn't changed Jun 19 21:00:39 "devicetree is independent of the kernel" Jun 19 21:00:39 I have "instructions", which at least point me in a a direction for what to change where. There's a lot more changes than pinmux. Jun 19 21:00:42 yeah, right Jun 19 21:00:59 mru: it's absolutely not, nor did I claim that Jun 19 21:01:11 but usually the changes are dealt with in what you #include Jun 19 21:01:16 not you, but kernel maintainers try to maintain that illusion Jun 19 21:02:09 I know next to nothing about device trees, sadly. I also haven't researched how to try to debug a crash. Should prolly do that. Jun 19 21:04:02 Ragnorok: https://pastebin.com/raw/z18z86Fn #includes needed to get all macros and example use of them Jun 19 21:04:59 For some reason the dtsi I'm currently looking at uses hex for the first parm, not a symbol. Jun 19 21:05:34 there's PIN_INPUT and PIN_OUTPUT (which are badly named since they mean "input buffer enabled" and "input buffer disabled", no effect on output buffer) and both have _PULLUP and _PULLDOWN versions Jun 19 21:05:44 sure, like I said the macros are just to make things more readable Jun 19 21:05:54 you can use magic hex values all the way Jun 19 21:06:43 however BONE_P9_11 is a lot easier to understand than 0x070 Jun 19 21:06:59 Yup. I'm just trying to work it all out. Jun 19 21:07:21 I also have this summary of dts syntax: https://pastebin.com/XC8vB33d Jun 19 21:08:12 I've found some good refs on DTs and been reading them. Jun 19 21:08:34 there exist good non-outdated refs on DT ? :D Jun 19 21:09:15 Well I don't know how outdated they are, but given my rank n00bness, any information is potentially useful, like what all that stuff is even telling the system. Jun 19 21:09:50 when in doubt, I refer to the DT spec Jun 19 21:10:00 lol Jun 19 21:10:07 "The Datasheet Always Wins" Jun 19 21:10:11 and the binding docs, obviously Jun 19 21:10:22 Ragnorok: DT is a really simple and dumb datastructure. its interpretation is quite context-dependent, although there are some common idioms Jun 19 21:11:00 e.g. despite the varied and structured-looking syntax for property values, in the compiled DT a property is just a structureless byte-array Jun 19 21:11:14 It looks like a simple and dumb datastructure where the editor should know what complexity that dumb data structure is creating or it'll end in tears. Jun 19 21:11:36 yep, there's quite limited error-checking dtc can do Jun 19 21:12:03 since the structure and semantics of many properties are driver-dependent Jun 19 21:12:16 hasn't there been some work towards validating a dt against the binding docs? Jun 19 21:12:44 possibly yeah, I've seen work on making formal binding specs Jun 19 21:12:45 of course, you still can only pray that the driver agrees Jun 19 21:14:19 Krikey. Another day another dollar. I'll prolly poke at this more Sunday. Thanks for the info! Jun 19 21:14:25 Ragnorok: anyway, if you can share the dts then perhaps I can give feedback Jun 19 21:15:04 Will considert that next week after I've failed some more. lol Jun 19 21:15:05 or some other time I guess :) Jun 19 21:16:12 is this for a product that embeds a BBB or for a custom AM335x-based board? Jun 19 22:19:22 MattB0ne: I finished the Course 4 from BELA on Youtube. Neat, heh? Jun 19 22:24:08 Onto Course 5! MIDI stuff and harmonics! Jun 19 22:32:17 Are people making synths out of the BBB and BELA from what you hear? Jun 19 22:32:51 I have this older model Yamaha, i.e. '79. It is busted a bit but works still. Do you think I could alter it to make it work w/ BELA and the BBB? Jun 19 22:45:57 zmatt: for the ecap to turn it "on" nothing is needed after "pruss.ecap.config |= 1 << 20 " Jun 19 22:48:53 also anyone work with load cells before Jun 20 00:10:33 Hmmm Jun 20 00:10:36 MattB0ne: nope, ecap will be running after that Jun 20 00:10:36 quiet time of the day Jun 20 00:11:16 MattB0ne: you can confirm that by doing print(pruss.ecap.counter) a few times in a row, you'll see the counter running Jun 20 00:32:10 did they ever release the regular eCAP support in capture mode? Jun 20 00:42:37 I just watched a video of a rally in our nice, quiet town. Neat! The videographer had the jitters, though. Shakin' and bouncin'. Jun 20 00:43:48 Tripod time! Jun 20 00:44:09 I should have stuck to BELA. Jun 20 00:45:55 Course 5! Jun 20 00:46:19 zmatt: thanks Jun 20 00:46:19 set_ you may have a good vendor in mind Jun 20 00:46:19 Nope. Why would you ask? Jun 20 00:46:30 i need a motor driver to take my pwm signal and attenuate a load Jun 20 00:46:32 Oh. For BELA and not the tripod? Jun 20 00:46:37 for motor Jun 20 00:46:38 Oh! Jun 20 00:46:46 MotorCape or LoadCape. Jun 20 00:46:58 GHI. Jun 20 00:47:06 preferrably not a cape Jun 20 00:47:13 most of my pins are spoken for Jun 20 00:47:14 Oh. Um. L298d. Jun 20 00:47:29 Let me check again. Jun 20 00:48:05 any other options Jun 20 00:48:12 i only need to control 1 motor Jun 20 00:48:17 https://www.digikey.com/short/zhfv3f Jun 20 00:48:26 Oh. Jun 20 00:48:49 Okay. I do not know of one to control one motor. What type of motor? Jun 20 00:48:57 DC? Jun 20 00:49:05 or servo? Jun 20 00:49:32 simple planetary gear motor DC Jun 20 00:50:01 https://www.digikey.com/short/zhfvq9 Jun 20 00:50:02 may role with the L298 Jun 20 00:50:09 Look at the drv. Jun 20 00:51:01 I think GenTooMan is a kind of wiz w/ chips and source, i.e. esp. w/ motors in mind. Jun 20 00:52:16 yeah Jun 20 00:52:31 I am really disappointed the jrk cannot just function as an h bridge Jun 20 00:52:39 i am going to triple check Jun 20 00:53:21 maybe even a dsp? Jun 20 00:53:31 Oh. Jun 20 00:53:33 Yea. Jun 20 00:53:39 I remember now. The damn jrk. Jun 20 00:53:58 pwm is different from analog voltage control right Jun 20 00:54:03 ? Jun 20 00:54:13 It is analog. Jun 20 00:54:24 pwm is analog? Jun 20 00:54:25 it is not analog Jun 20 00:54:28 What? Jun 20 00:54:28 pwm is pwm Jun 20 00:54:30 Oh. Jun 20 00:54:41 It acts like analog. Jun 20 00:54:44 it doesn't Jun 20 00:54:49 What? Seriously? Jun 20 00:55:01 Well, as usual, I am confused. Jun 20 00:55:05 dang it. Jun 20 00:55:11 lol Jun 20 00:55:37 I was reading an article a while back. PWM is like ________? Anyway, let me go off to look for this article. Jun 20 00:55:51 https://www.abelectronics.co.uk/docs/kb/servopi/pwm/servopi-pwmduty.svg Jun 20 00:56:03 that's what a pwm output signal looks like Jun 20 00:56:11 periodic pulses Jun 20 00:56:22 I thought it was square waves? Jun 20 00:56:51 whatever you want to call it... a "square wave" normally means the high-time and low-time are the same Jun 20 00:57:00 like a pwm signal with 50% duty cycle Jun 20 00:57:13 Oh. It is a digital signal. Yikes. I was way off base. Jun 20 00:57:46 In the first line of the article, too. Jun 20 00:57:58 of course you can low-pass filter a pwm output to get sort of an analog output Jun 20 00:58:00 sort of Jun 20 00:59:26 @zmatt: My BELA is up and running. I made a midi, sort of. I am waiting to learn more about the Midi idea so I can attempt buttons and circuitry. Jun 20 00:59:43 I only have the GUI so far. Jun 20 01:00:16 @zmatt: MattB0ne is looking for a specific chip for a geared motor. Jun 20 01:00:30 What is a good chip for that business? Jun 20 01:02:37 MattB0ne: "I am really disappointed the jrk cannot just function as an h bridge" ... uhh, what makes you think that? Jun 20 01:02:55 Alright. Party time! Jun 20 01:02:57 it bidirectionally controls DC motors... that implies it's an H-bridge Jun 20 01:03:40 ohh, because it's a position-controller you mean Jun 20 01:03:58 I think the issue is lack of pin space on his end. Jun 20 01:05:08 set_: I think you're having no idea what you're talking about Jun 20 01:05:45 MattB0ne: you're right, it does seem like it's only a position-controller with no way to just set the motor output to a fixed value... at least no documented way Jun 20 01:06:03 never mind! Jun 20 01:06:12 you can set feedback mode to "none" to get speed control Jun 20 01:09:31 Speed! Jun 20 01:09:40 Vroom! Jun 20 01:10:09 So, are we plannin' on using the jrk or not? Jun 20 01:10:19 And what build is going on? Jun 20 01:10:55 B/c...I can build it too! Is this not what you all desire, i.e. me building a replica? Jun 20 01:11:51 I still have those mini Pololu drivers if that is what is going on... Jun 20 01:12:32 Just for the record, I do not have that exact driver. So, it may be different on my end. Jun 20 01:14:40 @zmatt: MattB0ne said and I quote, "Most of my pins are spoken for." Jun 20 01:14:52 I figured that meant, he was out of pin space. Jun 20 01:15:00 ! Jun 20 01:15:59 Anyway, I am chatting w/ myself again. Blah. Jun 20 01:28:59 set_: he said that to clarify he was not looking for a cape Jun 20 01:29:06 That too! Jun 20 01:29:14 no not "that too", that was a single statement Jun 20 01:29:25 Oh. Fine. Jun 20 01:29:26 he's not looking for a cape, since most of his pins are already in use Jun 20 01:29:35 hence a cape has basically 0% of being compatible Jun 20 01:29:39 Can I win at something for once. Sheesh. Jun 20 01:29:52 ? Jun 20 01:30:07 I got it now. Okay. Jun 20 01:31:07 I got my BBGW plugged in and this is it. I am dealing w/ nothingness now. I need direction. @zmatt: What direction do you have to give? Jun 20 01:35:45 I have no idea what you're talking about? Jun 20 01:35:57 direction with what? Jun 20 01:36:24 That makes two of us. Oh, direction on what to do next w/ the BBGW! Jun 20 01:38:09 bury it in the garden? Jun 20 01:38:18 No. Jun 20 01:38:24 I don't know, I'd not be inclined to get a BBGW in the first place Jun 20 01:38:28 I need to do something more inventive than that... Jun 20 01:38:31 given its pin-stupidity Jun 20 01:38:37 Ha. Jun 20 01:39:31 (a whole bunch of I/O is in use by the wifi/bt chip, hence it'll also be incompatible with many capes) Jun 20 01:41:03 Right. I remember. Jun 20 01:47:06 https://docs.python.org/2/library/itertools.html#itertools.cycle Jun 20 01:47:34 from itertools import cycle gives me a method to use for looping functions. I found this out in a book! Now, I can use it for a bot! Jun 20 01:48:34 If my board would stop "crashing." I guess some of my, like you say, pins are already taken up by WiFi/BT. Jun 20 01:49:09 back Jun 20 01:49:22 Ha! Jun 20 01:49:41 zmatt: if I set PID to none I still need to set the speed level through its logic system Jun 20 01:50:00 i think it is better for me to get a simple board that takes the PWM as a signal Jun 20 01:50:11 I will find something else to use the jrk for Jun 20 01:50:33 You can do it w/ your BBB! Jun 20 01:50:47 yeah but I dont want to do that Jun 20 01:50:50 Oh. Jun 20 01:50:52 Okay. Jun 20 01:50:57 I am going through all this trouble to learn PRUs Jun 20 01:51:06 Aw. I remember. Jun 20 01:51:08 and get this RT boost Jun 20 01:51:18 RT = real time? Jun 20 01:51:18 sort of gets washed away by the jrk Jun 20 01:51:22 Right. Jun 20 01:51:32 it is doing its own thing and calcs the PID stuff even if you do not use it Jun 20 01:51:55 i probably could work something else out but I think the simpler approach that I can just connect to pin 42a Jun 20 01:52:02 and wash my hands of it Jun 20 01:52:15 P9_42a to be specifc Jun 20 01:52:21 Aw. Jun 20 01:52:30 Are you using the AI? Jun 20 01:52:51 I am tempted to jump on that Jun 20 01:53:05 because it has more horsepower and I have a vision piece to my project Jun 20 01:53:08 buuuuttt Jun 20 01:53:12 it seems to new Jun 20 01:53:22 to risk it Jun 20 01:53:31 does it have the same chip as a BBB Jun 20 01:53:37 or it is completely different setup Jun 20 01:54:20 there isnt a nifty kino pin sheet I can look at Jun 20 01:54:27 next project I may pick up one though Jun 20 01:54:29 My once working, literally two seconds ago, source now tells me via my BBGW that I have no such file or directory. Jun 20 01:54:30 Boo! Jun 20 01:54:35 No. Jun 20 01:54:43 The AI has another, separate chip. Jun 20 01:54:57 how is the documentation Jun 20 01:55:00 Yes. @zmatt made one. Jun 20 01:55:04 Okay. Jun 20 01:55:19 I can get some resources if you are still interested or you can wait for @zmatt. Jun 20 01:55:39 for right now I will stick with what I got Jun 20 01:55:51 though I may look to port over to the AI Jun 20 01:55:54 if it makes sense Jun 20 01:56:05 MattB0ne: oh you mean you wanted to stick a pwm signal into it instead of commanding it? yeah that's not what it's made for Jun 20 01:56:17 zmatt: yeah Jun 20 01:56:25 this was before I knew about PRUs Jun 20 01:56:25 for that you need a H-bridge driver, not a motor controller Jun 20 01:57:26 ok Jun 20 01:57:35 another question I had regarding power Jun 20 01:57:47 I will need power going to the motor via this H bridge driver Jun 20 01:57:59 and I also need to power my load cell digitizer Jun 20 01:58:35 I only have 1 DC power supply. What I am worried about is that the motor pulls current in an unsteady manner Jun 20 01:59:03 I was just going to split the power to the two devices but I am worried about the constantly changing current draw messing up the load cell stuff Jun 20 02:01:37 I mean, that's a matter of using a power supply that's adequate for the task Jun 20 02:01:54 but yeah, a switching motor will be a pretty icky load Jun 20 02:02:21 is there a way to isolate it Jun 20 02:02:27 the power supply can do 10amps Jun 20 02:02:40 I wont be pulling that much through it so it can handle everything tasked Jun 20 02:03:05 And greasy if it overheats! Jun 20 02:03:16 if it can supply 10 amps while maintaining good regulation then you shouldn't have anything to worry about Jun 20 02:03:26 ok Jun 20 02:03:47 obviously it's a good idea to confirm the output stability using a scope once you have a motor attached Jun 20 02:03:56 I dont have to worry about the current changing for everything else connected to it Jun 20 02:04:28 that depends on how well the power supply does its job Jun 20 02:04:39 I se Jun 20 02:04:52 I see so it is more on the power supply than the components Jun 20 02:05:40 I was worried about it frying everything since if one component needs 4amps all the sudden everybody wired in parallel needs to take 4amps Jun 20 02:05:43 it's about the suitability of the power supply for the way you intend to use it Jun 20 02:05:51 well we shall see Jun 20 02:05:51 that's not how current works Jun 20 02:05:55 lol Jun 20 02:06:18 I did take one circuits class Jun 20 02:06:26 but that was my throwaway class for the semester Jun 20 02:06:35 and it was when I was a freshman Jun 20 02:07:03 think of it like a water supply: if the water supply infrastructure is good, then how much you open your faucet (i.e. how much water current you're drawing) won't affect your water pressure or that of your neighbour Jun 20 02:07:16 thing that sucks with the H Bridget is that I would need another wire to do bi direction Jun 20 02:07:21 not a biggie Jun 20 02:07:27 but a slight bummer Jun 20 02:07:32 a direction-gpio yes Jun 20 02:09:14 or two control lines if you also want to be able to freewheel Jun 20 02:15:03 did someone say bi-directional? Jun 20 02:15:17 My entire philosophy is crashing. Never mind me. Jun 20 02:21:02 I got me a video reference on files in C. Yea! NOw, it is time to learn it for good. Any pointers? No pun intended. Jun 20 02:21:23 Sorry for my lame humor. Food time! **** ENDING LOGGING AT Sat Jun 20 03:00:22 2020