**** BEGIN LOGGING AT Fri Dec 20 03:00:11 2019 Dec 20 03:04:36 https://pastebin.com/KgNeWDLh is the source that went w/ the MotorBridge.py file but I am receiving errors. Something about OSError: [Errno 16] Device or resource busy. Dec 20 03:05:41 I also read that smbus2 will not work on specific boards like the RPi but it can be used to write 32 bytes of data at a time. Dec 20 03:23:31 Is something wrong w/ the i2c-1 bus for Capes, i.e. specifically the MotorBridge Cape? I can use other i2c busses if necessary, i.e. 0 or 2. Dec 20 03:27:31 Okay. I am using 2 now. Dec 20 03:28:01 Here is the error: OSError: [Errno 121] Remote I/O error. I am looking up info. if anyone wants to jump in. Dec 20 13:35:22 Hello, i have a question... i am getting errors while running rc_test_drivers Dec 20 13:35:44 Kernel: 4.4.49-ti-r89 Dec 20 13:35:50 uart2 Dec 20 13:36:01 i need help Dec 20 13:39:42 Priyanka: exactly what error are you getting ? Dec 20 13:42:31 ERROR: gpio 0 driver not loaded Dec 20 13:42:39 ERROR: pru-rproc driver not loaded Dec 20 13:42:50 and ERROR: ADC iio driver not loaded Dec 20 13:46:53 ai1 Dec 20 13:53:42 Hi, I'm using the BBB with a USB webcam that requires a minimum of 150Mbits/sec transfer speed due to their API and sensor clock. Currently I can only reach around 80Mbits/sec on average. Does anyone know of a way to increase the bandwidth on the BBB? Dec 20 14:00:14 Priyanka: it sounds like it's expecting some particular DT configuration that's missing, but I'm not that familiar with librobotcontrol. first of all though, the kernel version indicates you're using a very old system, I'd suggest starting with using the latest iot image Dec 20 14:02:05 ECSteve: dma still seems to be disabled for musb in the latest 4.14-ti and 4.19-ti drivers, that probably doesn't help Dec 20 14:03:09 ECSteve: although, I don't actually know the reason musb dma is disabled... and I vaguely recall someone mentioning he'd tested musb with dma and it somehow turned out to be even slower, but that was a long time ago and I don't know the workload circumstances Dec 20 14:07:48 ECSteve: 150Mbit/s theoretically shouldn't be a problem in terms of bandwidth, so the low performance is no doubt due to a high amount of driver overhead Dec 20 14:08:22 which also means performance can presumably be improved by improving the driver Dec 20 14:08:27 which kernel version are you using? Dec 20 14:14:54 4.14 is the kernel version. I'm looking into adjusting the transfer size as per what has been indicated here: https://elinux.org/images/6/66/Elc_2014_usb.pdf But thought it seems somewhat dated and thought I would check to see if anyone has tried anything else that worked well. Dec 20 14:17:07 dunno, I mostly just try to avoid usb :) Dec 20 14:17:32 zmatt is there any way to flash the beagle bone without an SD card?? Dec 20 14:18:31 ECSteve: you can try recompiling the kernel with musb dma enabled... I'm sure there's a good reason it's disabled by default, but maybe it works out for your use case Dec 20 14:21:42 Priyanka: you can try https://github.com/ravikp7/node-beagle-boot (last update: 1 year ago) or its gui wrapper https://github.com/ravikp7/BeagleBoot (last update: 2 years ago) Dec 20 14:22:06 Thank you @zmatt I will try that next as it seems worth a shot definitely. Dec 20 14:25:47 ECSteve: https://pastebin.com/imwCJ1UE Dec 20 14:26:17 ECSteve: and if you haven't built a kernel with custom config yet: https://pastebin.com/eLhrp1Hg Dec 20 14:27:03 you'll want the ti-linux-4.14.y branch (which is the current default branch) of https://github.com/RobertCNelson/ti-linux-kernel-dev **** BEGIN LOGGING AT Fri Dec 20 17:24:36 2019 Dec 20 18:17:26 Siegurd: it should already be using dma (for transfers above a certain threshold size) Dec 20 18:20:27 dma is used for transfer sizes >= 160 bytes Dec 20 18:23:49 I'm pretty sure I've investigated this phenomenon a long while ago, I just can't remember what my conclusions were Dec 20 18:26:19 I think it might be neglecting to use turbo mode Dec 20 18:32:00 I'm pretty sure that's exactly what's going on... whether or not to use turbo mode seems to be coming from platform data (struct omap2_mcspi_device_config) and was never ported to DT Dec 20 18:32:51 even then the inter-byte gap seems excessively large, I wonder if it's somehow also failing to properly configure the fifo or something Dec 20 18:39:21 I transfer 4096 bytes (its a max that i could via SPI at once) Dec 20 18:40:47 yeah like I said last time you can raise that limit with a kernel parameter (spidev.bufsiz), but it won't have any significant effect Dec 20 18:41:31 I'm pretty sure the kernel driver is just configuring the spi peripheral in a really suboptimal way Dec 20 18:48:50 yeah, no mater how big the limit is, the delays occurs every 8 impulses of CLK signal. Dec 20 18:50:40 obviously since that's the configured word-length Dec 20 18:51:35 (a 16-bit or 32-bit word length would no doubt increase performance, but is probably useless to you since it would result in byte-swapping due to SPI being big-endian) Dec 20 18:53:30 yep, changing word length doesn't solve the delay problem Dec 20 18:53:54 well it will increase the number of bits in between delays Dec 20 18:54:58 it definitely does Dec 20 18:55:30 anyway, this looks like something that just needs to be fixed in the kernel driver Dec 20 18:56:07 I expect that some inter-byte gap will remain, but I'm pretty sure it doesn't need to be this large Dec 20 18:57:16 any ideas how to fix the kernel driver? Dec 20 19:03:17 just tested out of curiosity: using 32-bit wordsize and 2048-word (8192-byte) transfer size I got 4.452 MB/s .. so that's indeed a lot better, albeit only useful in limited circumstances Dec 20 19:03:49 found this link but don't now if it can help in my case https://github.com/RobertCNelson/ti-linux-kernel-dev/commit/92b9a647aaecbc6b18fba289d8a010852bf96a81 Dec 20 19:04:51 that's not even remotely relevant Dec 20 19:05:14 also, that's an ancient commit Dec 20 19:05:17 can you describe in details how to change wordsize? Will test it now Dec 20 19:06:56 it's one of the parameters of your spi transfer Dec 20 19:07:02 like clock frequency etc Dec 20 19:07:34 so, my suspicion is that this line is the cause, or at least part of it: https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.14.108-ti-r120/drivers/spi/spi-omap2-mcspi.c#L1179 Dec 20 19:08:29 I'm pretty sure "cd" is NULL nowadays, hence turbo mode effectively won't be used Dec 20 19:09:04 I'm also a bit puzzled why it only uses it for receive-only transfers, I'm pretty sure it should also apply to rx+tx transfers Dec 20 19:10:08 I'd be tempted to remove "cd && cd->turbo_mode &&" from the condition and see what that does Dec 20 19:20:12 where can i find this file? Dec 20 19:29:30 there is no spi-omap2-mcspi.c in /lib/modules/4.14.108-ti-r113/kernel/drivers/spi/ Dec 20 19:30:03 ehm, of course there isn't Dec 20 19:31:02 sorry, Im newbie in Linux Dec 20 19:31:27 /lib/modules contains compiled kernel modules, not source code Dec 20 19:33:23 oh.. so it needs to be compiled. Can it be made with some onboard tool? Dec 20 19:33:26 if you scroll up, I mentioned how to build a customized kernel earlier today (about 5 hours ago)... the pastebin I linked also mentions how to build a patched kernel Dec 20 19:33:46 compiling a kernel on the beaglebone itself sounds like something I would not want to even attempt Dec 20 19:34:04 got it Dec 20 19:35:48 it would take absolutely forever, assuming you wouldn't run out of memory (you probably will) or run out of eMMC space (you almost certainly will) Dec 20 19:37:41 I guess I could build a kernel for you with that change... Dec 20 19:40:18 Yes it would be great, thank you! Dec 20 19:40:28 The linux rabbit hole is much deeper than i thought.... Dec 20 19:40:54 well generally when using linux you don't have to end up patching drivers and recompiling a kernel ;) Dec 20 19:41:47 although you could look at it differently... if it were Windows then the conclusion "yep, the performance of this driver kinda sucks" would probably be the end of the road with no way to improve it Dec 20 19:42:16 definitely Dec 20 20:01:48 it's compiling Dec 20 20:03:18 of course, since turbo mode has apparently been (unintentionally) disabled for a long time, and therefore hasn't been tested in a long time, there's a risk that it's now broken... but I guess we'll find out Dec 20 20:04:10 Cool! Thanks! We'll find it out. Dec 20 20:05:10 Do I need to write image to SDcard with new kernel? Dec 20 20:05:16 nope Dec 20 20:08:07 installing via dpkg? Dec 20 20:08:08 when it's done compiling I'll upload the .deb file somewhere, you can install it with "sudo dpkg -i FILE" Dec 20 20:08:12 yep Dec 20 20:15:11 in case of failure where can I get the unedited kernel? Dec 20 20:40:16 I just built the latest kernel of the 4.14-ti series (ti-linux-4.14.y branch) as described in the notes I linked earlier (https://pastebin.com/eLhrp1Hg) Dec 20 20:40:26 with a one-line change and custom version suffix Dec 20 20:41:03 it's done: https://liktaanjeneus.nl/mcspi-patch/ ... you probably don't need the headers package but I included it just in case Dec 20 20:44:56 got it. Installing Dec 20 20:48:43 done. rebooting Dec 20 20:54:28 running test Dec 20 20:58:04 Interesting result. The speed increase from 2 Mbyte/s to 2.8 Mbyte/s. The delay duration became shorter. Making a screenshot of oscill Dec 20 21:02:21 http://www.fotolink.su/v.php?id=5d802a5d8465d214493b7a56f6a9315b Dec 20 21:09:32 uhh but that scope pic suggests a much higher data rate Dec 20 21:09:47 it's showing 230ns per byte, which is 4.3 MB/s Dec 20 21:10:29 230ns = 11 cycles @ 48 MHz, i.e. 8 data cycle + 3 idle cycles Dec 20 21:19:46 yes, but there is another issues. The CS pin does not return to HIGH state mediately after reading 4096 bytes. It waits 265 us and then goes HIGH. And for next reading seqence it also wait that long, so the pause between 2 readings is 244*2=488us= ~0.5 ms that's a lot. Dec 20 21:20:24 screening Dec 20 21:21:37 http://www.fotolink.su/v.php?id=80d5260d4fa2120b84e424280a0ddb81 Dec 20 21:22:03 Dang wifi on the 'ol puter died. Sorry about yesterday. Dec 20 21:22:26 the blue one (4 channel) is CS. Dec 20 21:24:30 Was anyone following along in my plea to get ideas for the MotorBridge Cape and smbus2 for python3 for the BBGW? Dec 20 21:29:32 Siegurd: why are you toggling CS every 4096 bytes? in case of spi flash that would also mean you'd need to send a new read-command each time Dec 20 21:29:56 with the patch I'm now getting 4.4 MB/s Dec 20 21:30:17 with a 4096-byte transfer size Dec 20 21:32:45 that delay is still odd though Dec 20 21:32:59 lemme see what I get if I make each transfer a separate command Dec 20 21:33:26 zmatt: Yes Im sending read-command each time. Dec 20 21:38:00 if CS pin would not stay high after the end of transmission - the memory wont work for write commands.. Dec 20 21:39:06 so it must bee triggered Dec 20 21:39:21 https://www.winbond.com/resource-files/w25q128fv_revhh1_100913_website1.pdf Dec 20 21:40:25 using separate commands seems to have little effect on performance for me.... it went from 4.396 MB/s to 4.364 MB/s (4096-byte blocksize) ... are you sure you're not spending that time in your own code? Dec 20 21:40:43 and that sounds very weird and unlike any spi flash I'm familiar with.. lemme read that datasheet Dec 20 21:40:56 oh wait Dec 20 21:41:10 no for write that might make sense, it probably wraps per page Dec 20 21:41:23 but you were benchmarking read, not write Dec 20 21:50:10 Im not sure its really proper way to trigger CS pin each time to read a lot of data (increasing limit value of SPI transfer at time may absolutely solve the problem), but isn't that time to triger CS pin of 244 us too long? Changing state of GPIO must be around 2 MHz. Dec 20 21:55:11 why on earth are you using a gpio? Dec 20 21:55:36 instead of letting the kernel driver manage chip select like normal Dec 20 21:56:06 and dunno how fast you can toggle a gpio... I'd imagine in less time than that yes, but that depends on how (in)efficient your gpio code is Dec 20 21:56:42 No, im using SPI CS, not GPIO emulated CS. Dec 20 22:00:59 but manual of the PocketBeadle bord says that usual GPIO can be triggered with ~2MHz, and 40MHz with PRU. So even if i do use GPIO pin as a CS the frequency 2MHz is much higher than 4 kHz for that CS pin now. Dec 20 22:02:20 if I did the math right I'm seeing somewhere in the order of 50us of per-transfer overhead, including the read command (though most of it will be simply the overhead of doing a system call from userspace) Dec 20 22:03:51 so if you're seeing higher values I'm inclined to pin that on inefficiency in userspace Dec 20 22:04:10 and/or more system calls than necessary Dec 20 22:06:13 OK, I will check the SPI library for that, and will try to use GPIO as a CS for an experiment. Dec 20 22:07:14 that can only be more inefficient Dec 20 22:10:41 the chip select from the spi peripheral is "free" .. it gets controlled regardless of whether a gpio chip select is configured in DT. using a gpio chip select just means additional work has to be done Dec 20 22:12:04 I understand that, but in this case in may be not brilliant, but still a solution. Dec 20 22:13:49 ?? Dec 20 22:14:09 how is making things even slower a "solution" for disappointing performance? Dec 20 22:20:45 CS pin trigger frequency for now is = 244 us = 4 kHz. I can literally trigger it faster by hand. Or just use some GPIO. Of course this solution can be made only when there is no other option. Dec 20 22:30:29 I'm confused what you're trying to say Dec 20 22:32:26 let me reiterate: my benchmark shows 4.3-4.4 MB/s regardless of whether I use a separate command for each 4096-byte block or use a continuous read stream, the difference is insignificant Dec 20 22:32:48 so if your code is much slower, that's most likely just the fault of your code Dec 20 22:33:03 agree Dec 20 22:33:38 (or whatever library you're using) Dec 20 23:10:12 but the question is, why the same code with the same SPI library (SPI f=50MHz) and the same memory module running on OrangePi zero gives 5.5 MBytes/s read speed? Dec 20 23:12:31 I didn't change benchmark code at all. So there is no user code in-between readings. Dec 20 23:12:53 presumably a combination of a slightly faster SPI peripheral and a faster cpu that runs the inefficient userspace code more quickly, but that's really just a guess Dec 20 23:13:22 there might also be a difference in overhead in the kernel driver Dec 20 23:14:38 since I know neither the orangepi nor what your code does, it's rather difficult for me to speculate on this Dec 20 23:15:52 OK, will check library code again. Dec 20 23:17:23 Thanks for help! Dec 20 23:18:56 I will summarize results in topic on a forum if getting any improvements. Dec 20 23:21:01 yes, someone will have to look into fixing the turbo mode thing properly Dec 20 23:21:38 for me that fixed the performance issues Dec 20 23:38:28 zmatt: maybe you could create request in github? Dec 20 23:41:05 the linux kernel isn't developed on github Dec 20 23:41:39 and I'm uncertain what the best way is to fix this (in a way that is appropriate for all platforms that use this driver, not just the one I happen to care about) Dec 20 23:42:46 I'm sure that check isn't there for no reason, presumably there are older SoCs where turbo mode doesn't work Dec 20 23:43:03 (or shouldn't be used for another reason) Dec 20 23:47:13 right Dec 21 01:25:51 @zmatt: Hey man...you are not going to believe this factoid. The dang board works again w/ the MotorBridge Cape. Dec 21 01:25:52 Boy! Dec 21 01:26:19 I think I was having issues b/c of the router/wifi/blah breakage. Dec 21 01:26:28 Anyway. Thank you for looking out the other day. Dec 21 01:27:11 I was about to make a very long post in google.groups.beagle or whatever and now, I need not get harassed. Yea boy! Dec 21 02:24:32 Do I need to type up a .dts file or use a udev rule instead of config-pin for the AI? Dec 21 02:29:46 I am asking b/c I saw in the google.groups, people were stating that the AI machine needs to be set up before userspace for pinmuxing. **** ENDING LOGGING AT Sat Dec 21 02:59:58 2019