**** BEGIN LOGGING AT Tue Jan 07 02:59:58 2020 Jan 07 09:35:42 Hello everyone. Is there any way to increase the usb bandwidth on the BBB besides enabling DMA (which I have already done)? Jan 07 09:38:06 Currently have a Ximea USB camera that will only transfer images from the camera's buffer if it can achieve a minimum bandwidth of 150Mb/sec. When it checks the bandwidth on opening the camera it can only achieve 60 to 80 Mb/sec and so won't transfer any images. Jan 07 09:38:47 just curious, what was the bandwidth before enabling DMA Jan 07 09:38:48 ? Jan 07 09:39:09 The same Jan 07 09:39:26 also, Mb (bit) or MB (byte) ? Jan 07 09:40:55 the short answer is probably "figure out why the driver is so slow and fix it"... but that's easier said than done Jan 07 09:41:55 Mb (bit) and do you mean libusb? Jan 07 09:42:27 And thanks for the help zmatt, you helped me before christmas and the help is appreciated Jan 07 09:43:16 oh you're using libusb instead of using it as a video device? Jan 07 09:43:56 but no I meant the musb kernel driver (including platform glue) Jan 07 09:44:20 although inefficient userspace code could also muck up performance obviously Jan 07 09:47:58 It's unfortunately a requirement of the ximea api to use libusb at the moment. Jan 07 09:50:34 And yeah, it's not being used as a video device. We have the camera take a single picture and then trying to take that frame and save it as an image. It works on PC and on raspberry pi in testing, where the bandwidth can be achieved, but not with the BBB Jan 07 09:50:55 so it uses a bulk endpoint rather than an isochronous one? Jan 07 09:51:45 yes, the ximea api uses a bulk endpoint Jan 07 10:10:00 also what you're describing is really weird... if it's using a bulk endpoint to transfer single images then it shouldn't be expecting a specific bandwidth, bulk endpoints do not come with any bandwidth or latency guarantee, that's what isochronous endpoints are for Jan 07 10:38:35 oh no, it looks like the driver unconditionally applies a workaround for a hardware bug in the AM335x 1.0, even though this bug has been fixed in AM335x 2.x (the BBB uses the most recent silicon revision, 2.1) Jan 07 10:41:59 ECSteve: in drivers/usb/musb/musb_cppi41.c in the function cppi41_configure_channel (about halfway down the file), there's a variable use_gen_rndis which is false (0) by default and set to true (1) if cppi41_channel->is_tx is true Jan 07 10:42:40 try making use_gen_rndis unconditionally true, e.g. by commenting out the if-statement or by changing the declaration from "unsigned use_gen_rndis = 0;" to "unsigned use_gen_rndis = 1;" Jan 07 10:44:44 (a proper fix would be to use a quirk-bit to determine if this workaround is needed) Jan 07 10:49:10 oh, hm Jan 07 10:49:27 actually it may be necessary to also disable the rx_toggle code then Jan 07 10:49:31 it probably is Jan 07 10:50:45 just put a return statement at the top of the save_rx_toggle and update_rx_toggle functions or something (defined near the top of the file) Jan 07 10:52:19 so right now, due to the workaround, for in-transfers the dma transfer size is limited to the usb packet size (max 512 bytes for high-speed bulk) and after each packet will get an interrupt to set up the next packet transfer Jan 07 10:52:34 so yeah, that will tank performance Jan 07 10:53:36 it should also be completely unnecessary on the BBB (and any other AM335x 2.x device) Jan 07 11:52:43 Ah, sorry zmatt, I was out to lunch. I agree, it is weird, but it's again a problem I think with the ximea api at that point as they require the bandwidth in order to transfer the entire image before the sensor clears the data. They are considering opening up the possibility of being able to change the sensor clock frequency so I can lower the Jan 07 11:52:44 required bandwidth, but they can't guarantee that possibility at this time. Jan 07 12:17:05 right but that very much sounds like they should be using isochronous endpoints, not bulk endpoints Jan 07 12:17:28 So I'm trying the changes you suggested to the musb driver and compiling the kernel now to see if that will make a difference. Hopefully it does. Jan 07 12:18:27 yeah I think that should make a significant impact (assuming it doesn't break stuff because I overlooked something) Jan 07 12:45:23 m Jan 07 12:55:12 Well, it definitely made an impact, It only has a bandwidth of 34 Mb/s now Jan 07 12:56:22 lol Jan 07 12:56:23 wtf Jan 07 12:56:29 how Jan 07 12:57:44 I guess if it's just measuring bandwidth and not checking the data, then if the toggle is messed up the resulting packet loss would be perceived as reduced bandwidth Jan 07 12:58:47 you set use_gen_rndis to 1 and disabled the save_rx_toggle/update_rx_toggle functions? Jan 07 12:59:38 yes Jan 07 12:59:44 I guess you could try *not* disabling those two functions, I didn't look particularly carefully at what's going on Jan 07 12:59:50 but they are part of the erratum patch Jan 07 13:00:18 I'm guessing that until it measures sufficient bandwidth there's no way to verify it's receiving correct data? Jan 07 13:00:59 exactly. It measures first and if it's below the bandwidth it won't even attempt to transfer the data. Jan 07 13:01:30 I'll try not disabling those functions and see what that does. Thankfully it doesn't take too long to compile the kernel Jan 07 13:01:49 yeah recompiling after minor changes is pretty fast Jan 07 13:03:09 maybe disabling the errata workaround isn't as simple as this for whatever reason, I don't really have time or motivation to dig a lot more deeply into this driver Jan 07 13:08:37 it would probably also be useful to have a better test for usb performance, e.g. make some other embedded system into a simple usb gadget with a bulk endpoint that continuously produces packets (with a sequence number in them to be able to detect if any are dropped due to driver issues) Jan 07 13:09:21 then you could also test the impact of the size of reads performed by the client program Jan 07 13:33:59 discovered what the issue may be actually. When I compile with build_deb.sh it switches to master branch and all the changes to the driver go poof. Jan 07 13:35:30 oh! tools/rebuild_deb.sh Jan 07 13:35:49 build_deb.sh indeed generates a clean source tree Jan 07 13:36:06 tools/rebuild_deb.sh leaves it alone Jan 07 13:36:33 Ok! awesome, thanks again. Jan 07 13:51:47 ECSteve: some notes regarding building beaglebone kernels: https://pastebin.com/eLhrp1Hg Jan 07 14:30:07 Greetings! Jan 07 15:14:56 i have issues trying to read analog signals from my BBB. i have a voltage sensor plugged to AIN0 but am unable to read analog signals from the sensor. my trials has been with IOBB C library which i got from here https://github.com/VegetableAvenger/BBBIOlib/tree/master/Demo trying out the Demo code for ADC, my thoughts are that its not efficient enough or am doing something wrong.Although i haven't Jan 07 15:14:58 been able to get an alternative. Any sample or example code on how to efficiently read analog signals using C programming or any better implementation would be well appreciated.Thank you. Jan 07 15:15:56 last updated 5 years ago, rarely a good sign ;) Jan 07 15:16:48 also this uses /dev/mem, which means it will conflict with the kernel driver Jan 07 15:18:09 (and it has no way to get irqs so it has to poll for completion, which is terrible) Jan 07 15:19:54 m-blasie: you haven't really specified your needs though... are you just trying to read it occasionally? periodically? if the latter, how often and does regular spacing of samples matter? what sort of bandwidth are you hoping to get? Jan 07 15:20:05 what do you mean exactly by "not efficient enough" Jan 07 15:20:41 The values i get varries with a constant rate, i.e the demo code collects 10 samples which are always thesame at any number of times it runs on a loop Jan 07 15:21:07 yeah that sounds like the code is broken Jan 07 15:21:17 since in reality there's significant noise present Jan 07 15:22:36 @zmatt: i want to be able to read it as a stream, periodically (1.e in a loop with 5s interval) Jan 07 15:22:59 the official mechanism is iio.. e.g. by using libiio or for occasional measurements you can use the sysfs interface Jan 07 15:23:20 5s interval is not a stream, it's a single measurement every now and then Jan 07 15:24:42 yea more like it Jan 07 15:28:51 so simplest is just reading the value from sysfs, that's something you can do in any programming language: Jan 07 15:28:54 cat /sys/bus/platform/devices/44e0d000.*/iio:device*/in_voltage7_raw Jan 07 15:29:53 though it can be tricky to reliably locate the path in a way that works across different kernel versions Jan 07 15:30:35 (I'd generally use an udev rule to make a symlink in a convenient place instead of hardcoding sysfs paths) Jan 07 15:33:23 example using python3-libiio: https://pastebin.com/M35Eq9TD Jan 07 15:46:25 wow thanks looks really simple and straight forward but i have got a question, "adc = iio_ctx.find_device('44e0d000.tscadc:adc') # FIXME this name is kernel version dependent" is this suppose to be replace by the pin number "44e0d000.tscadc:adc'"? Jan 07 15:47:06 @zmatt: When doing a rebuild, I run into the following errors and feeling a bit out of my depth on how to solve them: https://pastebin.com/3F5AFHpr Jan 07 15:47:25 ECSteve: ehhhhhh Jan 07 15:47:34 something broke terribly somehow Jan 07 15:48:52 this is simply after running tools/rebuild_deb.sh, after the last ./build_deb.sh was successful ? Jan 07 15:49:51 yes. after modifying the driver file in the KERNEL subdirectory and then running tools/rebuild_deb.sh Jan 07 15:50:07 this definitely has nothing to do with a change to the driver Jan 07 15:50:48 what does 'git status' say inside the KERNEL directory? Jan 07 15:53:25 git status reads: https://pastebin.com/0N5uSKm5 Jan 07 15:53:42 wrong directory Jan 07 15:54:03 Ah, right, sorry Jan 07 15:54:57 This is the only change: modified: drivers/usb/musb/musb_cppi41.c Jan 07 15:55:40 The change hasn't been commited yet though, could that be an issue? Jan 07 15:55:53 can you show the first few lines of output of 'git log' ? Jan 07 15:55:56 no that doesn't matter Jan 07 15:56:07 same directory? Jan 07 15:56:10 yes Jan 07 15:58:17 https://pastebin.com/Ttga9e6x Jan 07 15:58:42 ehhh Jan 07 15:59:07 did you abort the last ./build_deb.sh before it was done preparing the source tree maybe? Jan 07 16:00:01 quite probably, yes after discovering that it switched to the master branch and rebuild a clean source. Jan 07 16:00:28 Guess I'll start from scratch and try again Jan 07 16:01:17 yes tools/rebuild_deb.sh doesn't touch the source tree.. which does mean it needs to be in a proper state to begin with Jan 07 16:02:02 once ./build_deb.sh enters menuconfig (or, if AUTO_BUILD=1, starts actually compiling the kernel) you can abort it and apply your changes Jan 07 16:02:10 and then tools/rebuild_deb.sh Jan 07 16:24:06 m-blasie: https://pastebin.com/PQFSKYNn Jan 07 16:33:48 Ok, the rebuild has worked now zmatt, going to check to see if it fixes things now. Jan 07 16:54:34 @zmatt It has worked! 192Mb/s registered by the camera! Thank you so much for all your help with this. Jan 07 16:55:21 this should probably be reported upstream so it can be fixed properly... Jan 07 16:59:26 Still haven't fully tested to make sure it's receiving correct data yet, but it's been a long day and I'll check tomorrow. If it works correctly tomorrow I'll let you know. For now, have a pleasant rest of your day. **** ENDING LOGGING AT Wed Jan 08 02:59:58 2020