**** BEGIN LOGGING AT Thu Sep 29 02:59:58 2016 Sep 29 03:27:14 Ugh... any reason bone debian doesn't have midori? Sep 29 03:57:07 o poop, device tree modification = kernel panic Sep 29 03:58:04 back to the sd cards... Sep 29 06:06:06 Good morning guys, any suggestions for an IDE for the BBB? Sep 29 06:06:25 If possible an IDE for windows Sep 29 06:09:44 gorba_scp: what do you mean by IDE ? were you able to login to BBB ? from windows ? Sep 29 06:13:23 I was able to do file transfers via SCP and connect to the BBB via Cloud9 Sep 29 06:14:31 IDE like CCStudio Sep 29 06:19:47 I am searching for a suggestions from a experienced user if anyone faced problems using, ie Visual Studio, just under Linux OS(Ubuntu), Cloud9.. Sep 29 06:31:55 zmatt: hi there! Sep 29 06:32:49 I still have some issues configuring the mclk clock for wm8974... Sep 29 06:33:43 don't know what I am doing wrong but I can't see any output from mcasp1_ahclkx Sep 29 06:34:08 the pin mux is correct Sep 29 06:34:48 but now I am diving into davinci-mcasp.c module and it does not feel right ;-( Sep 29 06:37:34 is it really possible to output a clock divided from the main oscillator when the beagleBone is in salve mode for both bit clock and frame sync? Sep 29 07:07:18 zmatt: where is the audio guru? Sep 29 07:14:25 moerning Sep 29 07:21:27 Velsiol: good morning, mr magnetic needle :-) Sep 29 07:24:33 :^( Sep 29 08:21:08 Anyone know how I can make the SPI transfer 1024 byte in one go? Now it transfers 32 bit (the bits/word), pauses for 200ns and then continues Sep 29 08:40:35 tommer: which spi mode are you using? Sep 29 08:50:07 SPI_MODE_0 Sep 29 08:51:38 ok Sep 29 08:51:53 no idea, sounds strange... 200ns is a lot of time Sep 29 08:52:11 it's actually 208.3 ns I assume? Sep 29 08:53:12 which is 10 cycles at 48 MHz Sep 29 08:54:11 it varies a bit Sep 29 08:54:33 hmmm that's an important bit of info too Sep 29 08:54:52 since it basically excludes any delays introduced by the spi peripheral itself Sep 29 08:55:16 seems like its not using DMA for the transfers, I send it an array of bytes[1024], why would it pause between each 32 bit? Sep 29 08:55:38 you're at 48 MHz right now? Sep 29 08:56:30 if it weren't using dma then you'd see much much more slowdown and timing variation Sep 29 08:59:17 umm, is the spi interface using a fifo? is it 32bit wide? Sep 29 08:59:23 I know mcspi doesn't use edma in an efficient way, I'm wondering if this might cause effective rate-limiting Sep 29 08:59:53 a fifo of 1 word is not a fifo :P it does actually have a fifo of some non-negligible size Sep 29 09:00:13 iirc 64 somethings (bytes or words, dunno) Sep 29 09:05:42 zmatt: I just removed all overhead and just using the ioctl call now, and the delay between 32bits is stable at approx. 378ns Sep 29 09:06:47 running at 48 MHz Sep 29 09:08:10 that's a lot of time... the 32-bit transfer itself is only 667 ns Sep 29 09:09:29 what happens if you use 24 MHz ? do the delays exist then? Sep 29 09:11:41 yes, its the same delay Sep 29 09:14:55 I currently use the standard BB-SPIDEV0/1 DTO's Sep 29 09:18:12 oh that's lovely it uses a dma burst size of... 1 word Sep 29 09:18:18 (it = the driver) Sep 29 09:18:44 haha, such efficient.. many wow.. Sep 29 09:19:09 at 8 bits/word the delay is 396 ns.. Sep 29 09:22:03 between individual bytes? I'm pretty sure it... oh, no, the driver fails to enable word-packed fifo access so it actually needs a fifo write per byte rather than per 4 bytes Sep 29 09:22:19 how... efficient Sep 29 09:23:44 do you think its anyway around it? Sep 29 09:24:21 ive heard someone talking about using iio library, tried it? Sep 29 09:24:58 that makes no sense Sep 29 09:27:26 wait I misread, it does use a proper dma burst size Sep 29 09:27:35 huh, ok, what's weird then Sep 29 09:28:54 could it be something with the device tree overlay? Sep 29 09:30:55 no I don't think so Sep 29 09:30:55 There seems to be a dts which enables dma on the rpi: https://github.com/raspberrypi/linux/pull/1085/files#diff-de96fc47e4a4479419deb284086c246e Sep 29 09:31:09 what does the rpi have to do with anything? Sep 29 09:31:11 spi-dma-overlay.dts Sep 29 09:31:48 dma is configured in the main dts, it makes absolutely no sense to me to do so in overlays Sep 29 09:32:49 ok, just an idea.. 400 ns between each word does not make sense Sep 29 09:33:46 If i try to send 512kB the ioctl simply fails.. Sep 29 09:33:59 can you dump the peripheral register at offset 0x128 ? Sep 29 09:35:46 hmm, ( 0x48030128 for spi0, 0x481a0128 for spi1) Sep 29 09:36:36 if you get a bus error that's linux power management getting in the way, doing it while transfers are happening should work Sep 29 09:41:56 any other way than using devmem2? Sep 29 09:42:22 Hi, just saw the BBB wireless news, when is it expected to be available for purchase ? Sep 29 09:42:33 Does anyone know ? Sep 29 09:44:21 tommer: no, devmem2 is fine Sep 29 09:45:32 tejas: seeed shows it as in stock Sep 29 09:45:45 BBG wireless you mean then Sep 29 09:47:06 tejas: also you could just use the drop down box on this page: https://beagleboard.org/green-wireless Sep 29 09:47:36 devmem2 0x481a0128 returns: Value at address 0x1209663784 (0xb6fd0128): 0x1 Sep 29 09:48:00 uhhh what the hell Sep 29 09:48:45 the value looks okay though, so presumably the address is just shown in a bogus way Sep 29 09:49:35 I think its the right one, I get bus error when its not transmitting. Sep 29 09:51:03 and register at offset 12c ? Sep 29 09:51:20 assuming you use chip select 0 Sep 29 09:51:54 (0x12c + 0x14 * chipselect in general) Sep 29 09:53:35 at 0x12c: 0x1167296 Sep 29 09:57:30 uhh Sep 29 09:58:18 no Sep 29 09:59:18 what do you mean "chip select in general" there is only one cs per SPI Sep 29 09:59:41 no there isn't Sep 29 10:00:59 although the latest driver seems to believe so... curious, I'm pretty sure an older edition even used channels other than zero when using gpio chip selects Sep 29 10:02:53 that value you showed is utter garbage though Sep 29 10:07:08 value at (0x4810a012c+0x14): 0x66504 Sep 29 10:09:04 ehm, that's one digit too many in the address Sep 29 10:09:09 you mean 0x481a012c Sep 29 10:10:16 (and still makes no sense) Sep 29 10:11:31 its a new board guys Sep 29 10:11:31 root@beaglebone:~/devmem2# devmem2 0x481a012c /dev/mem opened. Memory mapped at address 0xb6f2e000. Value at address 0x1209663788 (0xb6f2e12c): 0x1167296 Sep 29 10:11:36 https://beagleboard.org/blog/2016-09-26-meet-beaglebone-black-wireless/?source=techstories.org Sep 29 10:12:23 ok what the hell is that utility doing Sep 29 10:13:04 what dev2mem are you using? Sep 29 10:13:13 I never use it really Sep 29 10:13:18 I don't even think I have it installed Sep 29 10:20:18 tommer: ok, I'm done with spi for now, good luck with it :P you can try different kernel versions (a lot seems to have happened in that driver) or perster TI about the delays on E2E since it looks to me like the mcspi peripheral inserts them itself Sep 29 10:22:28 and 0x1167296 simply isn't a valid channel configuration, the peripheral would not function with it. I have no idea however where the problem is Sep 29 10:29:32 zmatt: ok thanks :) Sep 29 11:18:09 zmatt: I was using an older BBB Debian image, Im going to try the newest now. But last time I tried that one I didnt get SPI to work. At startup the DTO loaded was the cape-universal and both spi's were available in /dev/, but when I tried the SPI test (MISO to MOSI on one of the SPIs) it didnt work. Sep 29 11:18:33 oh wow you're still using the prehistoric 3.8 ? Sep 29 11:18:57 yeah just disable cape-universal and load an overlay Sep 29 11:20:35 alright, I will try it out! Sep 29 11:20:43 or use cape-universal but you need to setup pinmux using eh, pin-ctrl or something like that the util is called Sep 29 11:22:14 if you want to build an overlay for it though you may find my https://github.com/mvduin/overlay-utils useful, it makes writing overlays less painful and includes an example for spi0 (and partial example for spi1) Sep 29 11:22:29 great thanks! Sep 29 11:22:48 it also includes utils (in bin/) to add/remove overlays using the new configfs mechanism instead of cape-manager Sep 29 12:54:40 zmatt: tried using the overlay-utils, SPI0 is mapped and IOCTL can use it, but there is nothing on the clock output anymore Sep 29 12:55:51 that sounds odd, maybe check if I somehow mucked up the pinmux in the overlay? Sep 29 12:57:53 used the spi0 example directly Sep 29 12:58:17 and I disabled the cape-universal Sep 29 12:58:48 that doesn't exclude the possibility of mistakes by me, but I'm a bit busy so please check it yourself Sep 29 12:58:55 you can also use show-pins from https://github.com/mvduin/bbb-pin-utils Sep 29 13:01:40 wow, so p9.22 shows as fast rx pullup and mode 7.. Sep 29 13:02:45 ill try to enable capeuniversal again since the mode was wrong Sep 29 13:16:56 no good, the pinmux is still wrong Sep 29 13:17:08 even after using capemgr and BB-SPIDEV0 Sep 29 13:22:54 nah, I cant get the SPI to work with the new BBB image Sep 29 13:23:23 that makes no sense, we use SPI all the time Sep 29 13:23:56 there are no errors in kernel log when loading the overlay (either one) Sep 29 13:23:59 ? Sep 29 13:28:43 loading BB-SPIDEV0: [ 126.171273] bone_capemgr bone_capemgr: part_number 'BB-SPIDEV0', version 'N/A' [ 126.171308] bone_capemgr bone_capemgr: slot #4: override [ 126.171323] bone_capemgr bone_capemgr: Using override eeprom data at slot 4 [ 126.171340] bone_capemgr bone_capemgr: slot #4: 'Override Board Name,00A0,Override Manuf,BB-SPIDEV0' [ 126.182048] bone_capemgr bone_capemgr: slot #4: dtbo 'BB-SPIDEV0-00A0.dtbo' loaded; overl Sep 29 13:29:20 please use pastebin for pasting such things Sep 29 13:29:44 or any similar paste service Sep 29 13:43:13 zmatt: is the overlay-util broken? Sep 29 13:43:38 I get parse error on all the provided .dtsi files Sep 29 13:44:19 laurittr: did you use make ? Sep 29 13:44:39 (there's a Makefile there for good reason) Sep 29 13:44:43 haha Sep 29 13:44:59 that makes sense :p Sep 29 13:45:11 Anyways, you got the tt3201 overlay to work? Sep 29 13:45:20 apparently it doesn't Sep 29 13:45:20 Hi People Sep 29 13:45:26 what? Sep 29 13:45:27 why not Sep 29 13:45:29 ? Sep 29 13:45:49 I don't have that board, I just tried to help someone here with that thing Sep 29 13:46:23 That might have been me? I got some help from you earlier trying to get mcp2515 to work Sep 29 13:57:35 zmatt: On my old BBB image I edited the /boot/uEnv.txt file to disable HDMI and EMMC, is this still working? Sep 29 14:03:30 http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration Sep 29 14:06:04 transitioning from 3.8 will probably take some effort, but that effort is no doubt only going to get worse with time... you don't want to be stuck on a prehistoric kernel forever, unable to take advantage of improvements that have been or will be made Sep 29 14:33:43 zmatt: got it working again. Its better, now its approx 208 ns between each 32 bit word Sep 29 14:34:11 that's the same value you reported earlier Sep 29 14:36:06 No, that was 378 ns Sep 29 14:36:09 between each 32 bit word Sep 29 14:36:48 hmm, before that you mentioned 200ns, where did that number come from? Sep 29 14:38:52 just approx. from looking at the scope Sep 29 14:39:02 now its fixed at 208 ns Sep 29 14:39:27 weird, I have no idea how the change in kernel could have affected that timing Sep 29 14:40:02 its the exact same code Sep 29 14:40:36 well no the driver has changed, but such short timings can really only originate within the peripheral Sep 29 14:41:05 or dma, but then it wouldn't have been the same for every word since dma is done in bursts Sep 29 14:43:00 http://pastebin.com/d7Kr8My1 here's my code Sep 29 14:46:35 ah this is rx+tx ... can you compare with tx-only ? Sep 29 14:46:47 ( .rx_buf = 0 ) Sep 29 14:48:40 same result Sep 29 14:51:26 it still seems to point to the delay being generated in the peripheral itself, but then why did it change from the previous kernel... very very curious Sep 29 14:54:36 yeah, well Im off.. later Sep 29 14:57:35 Hi, Has anyone ever run Uniflash from TI on the BBB or BBG? Sep 29 15:04:19 Hello everyone. I am trying to install mysql-server and client on my BBB running Debian Jessie. I am having problems in installing it. When I set the root password for MYsql, it gives me a error message that it is unable to change the root password. Sep 29 15:04:47 Also at the end it gives the following error: Sep 29 15:04:49 dpkg: error processing package mysql-server (--configure): Sep 29 15:04:49 dependency problems - leaving unconfigured Sep 29 15:04:49 Processing triggers for libc-bin (2.19-18+deb8u6) ... Sep 29 15:04:49 Errors were encountered while processing: Sep 29 15:04:49 mysql-server-5.5 Sep 29 15:04:50 mysql-server Sep 29 15:04:52 E: Sub-process /usr/bin/dpkg returned an error code (1) Sep 29 15:05:04 Can anyone help in figuring out the problem? Sep 29 17:57:19 zmatt: I just saw an spi implementation using IOCTL which splits the N long byte array into N spi_transfer structs. Maybe this is the way to make the userspace driver utilize dma transfers? Sep 29 19:11:03 this is wrong, i think: http://remcoder.github.io/2016/09/29/google-launches-iot-developer-kit.html Sep 29 19:12:04 Isn't this just seeed using google's api? is it actually endorsed by google? Sep 29 19:22:56 zmatt: That tt3201 driver, do you remember who needed help with it. If it wasn't me I would really like to get in contact with them as I need to get it to work. Sep 29 20:01:41 laurittr: tlab Sep 29 20:10:12 tommer: you *are* using dma: it is used for length >= 600 bytes Sep 29 20:12:37 the decision to use dma is mainly one of cpu efficiency anyhow: it's a heuristic that weighs the cost of occupying the cpu for the duration of the transfer versus the cost of setting up dma, cache flushes etc Sep 29 20:13:34 zmatt: ok, I just cannot figure out why there is a 208ns delay. Too much to be a FIFO handling, but yes the cpu utilization is low when transmitting constantly at the SPI, so DMA is being used.. Sep 29 20:14:05 it should reach full speed either way, and since you're apparently seeing stable timing even between txrx and txonly (this would never happen if cpu/dma were the bottleneck) it is being caused by the spi peripheral itself Sep 29 20:14:37 which is why I'm so puzzled that upgrading the system had any impact Sep 29 20:16:17 yeah, I thought that was weird as well.. Well, tomorrow I'll try with pthread and high priority on SCHED_FIFO.. Sep 29 20:16:29 cpu priority is absolutely irrelevant Sep 29 20:16:35 since you're using dma Sep 29 20:16:43 for the 208 ns yes, but not for multiple transmits/reads Sep 29 20:16:50 ah yes Sep 29 20:17:36 I will just leave the 208 ns for now, might be some weird settings on the SPI peripheral as you mentioned Sep 29 20:17:54 you can try pestering TI about it on E2E Sep 29 20:18:07 (e2e.ti.com) Sep 29 20:18:38 hah, last time I did that I got an answer that didnt really answer anything.. Sep 29 20:20:20 also, wasn't the conclusion already drawn that managing the transfers from linux userspace was no way going to be fast enough for you, with the suggestion of either using PRU or use externally triggered dma ? Sep 29 20:24:22 and yeah e2e is not always useful, but sometimes it is Sep 29 22:16:46 Hi, I was just wondering if someone can help me get numpy on my BBB. I can't seem to be able to install it. Sep 29 22:21:35 how did you try installing it? Sep 29 22:21:50 Lidia: apt-get install python-numpy Sep 29 22:21:54 or python3-numpy Sep 29 22:22:55 debian really ought to rename python2 packages to python2-* Sep 29 22:31:39 debian are stuck in the Age of python2 surely .. python3 is alien .. its NEW! Sep 29 22:32:26 yes I know debian is a pile of ancient crap, but given how long the transition is undoubtedly going to take you'd expect at least sid to take that step sooner rather than later Sep 29 22:33:09 :) Sep 29 22:33:21 a step in the direction would be an improvement lol Sep 29 22:33:48 it would also reduce the bias against python introduced by the default Sep 29 22:33:52 *against python 3 Sep 29 22:42:05 considering what levels of incompatibility python reaches with each new version, it's no wonder it takes them a damn long time for each version jump Sep 29 22:45:50 that's what major versions are for, and although I'm not a heavily invested python programmer my impression is that where big changes were made they were needed Sep 29 22:46:07 __future__ helps to bridge the gap Sep 29 22:47:08 The only thing I thought was really bone headed was making '/' a floating point division operator. That violates principle of least surprise, in the context of coming from other languages Sep 29 22:47:16 It was a brave move, I'll give them that Sep 29 22:47:56 dunno about principle of least surprise Sep 29 22:48:02 depends on what languages you come from Sep 29 22:48:23 is fp division in most scripting languages I can think of Sep 29 22:48:26 / is fp division in most scripting languages I can think of Sep 29 22:48:57 Okay, fair point Sep 29 22:49:20 But it has the potential to introduce hard to spot bugs in existing code Sep 29 22:49:48 I guess I've always thought of Python as a nice wrapper around systems programming more than a scripting language Sep 29 22:49:59 * MathOnNapkins has biases, to be sure Sep 29 22:50:00 lol **** ENDING LOGGING AT Fri Sep 30 02:59:58 2016