**** BEGIN LOGGING AT Mon Jun 20 02:59:59 2016 Jun 20 03:40:50 yeah i preregistered on your suggestion Jun 20 03:41:13 but i'm literally looking at a "buy the BBX15 for 300 dollars and have it shipped to you by next week" link Jun 20 03:45:02 ayjay: if you want verification if the link is something worth looking into, you might want to share it with others Jun 20 03:45:16 the internet, while finite, is a pretty big place Jun 20 03:57:00 i mean, i figured someone would know if the product was being distributed to retailers yet, but ill get the link tomorrow... goodnight Jun 20 03:58:26 actually here http://www.neutronusa.com/Manufacturer/index.cfm/ID/6691/Page/1 Jun 20 03:58:29 it's at the bottom Jun 20 04:05:36 is a little suspicious Jun 20 04:13:39 mouser did have it listed .. but I think even they back-tracked Jun 20 04:17:11 Factory Lead Time: 26 Weeks - well, that's possibly a bit harsh .. Jun 20 04:18:39 But the first production batch weren't even supposed to be completed untl the end of the month .. and I don't think they've done the 2nd round of FCC yet Jun 20 04:19:18 I'm predicting September .. :) **** BEGIN LOGGING AT Tue Oct 25 19:29:13 2016 **** ENDING LOGGING AT Tue Oct 25 19:38:38 2016 **** BEGIN LOGGING AT Tue Oct 25 19:42:10 2016 Oct 25 19:52:57 Ragnorok: Stuff I've found was either old and missing initrd support or used the Sitara SDK or wanted some old hand built RCN kernel. Oct 25 19:53:35 Ewww. Okey then. After I'd typed that it seemed that may be what you were trying, but so far I haven't found the "un-ENTER" key. (grin) Oct 25 19:53:38 I'll probably have to just do a lot of RTFM on u-boot. Oct 25 19:54:23 I should do the same The Mythical Some Day. Oct 25 19:59:44 I have a paycheck motivating this endeavor. ;) Oct 25 20:03:30 Hi folks, static ip assigned to the BeagleBone Black (with Debian) through /etc/network/interfaces file isn't persistent Oct 25 20:04:03 It changes every evening if I assign in the morning Oct 25 20:04:15 Remove connman. Oct 25 20:04:32 Or learn to set static IP using it. We removed it because it's simpler. Oct 25 20:05:02 Dhcp takes over to give nearest ip possible Oct 25 20:05:28 Where is connman located, do I need to purge it? Oct 25 20:05:44 It's a package like anything else, iirc. Oct 25 20:06:30 Is it by default available in the Debian image that surfaces on the link on beagleboard.org Oct 25 20:06:33 ? Oct 25 20:06:42 I believe so, yes. Oct 25 20:08:27 OK. I should remove. Can you please help understand the reason, how removing connman would exactly the problem, I mean what it does that won't happen after removing it, which will solve the problem. Oct 25 20:09:06 #exactly solve Oct 25 20:10:16 From my limited understanding, connman is simply a different way to managed network resources, which ignores /etc/network/interfaces. I never figured out how to get it to do static IP, but if it's removed, the system goes back to paying attentin to /etc/network/interfaces. Or that's how it was for me. Oct 25 20:11:19 Great. Thanks @Ragnorok Oct 25 20:11:30 One is happy to be of service. Good luck! Oct 25 20:12:09 Kudos. Thanks Oct 25 20:12:33 Hey folks, anyone would like to share some more wisdom on this topic? Oct 25 20:24:59 @Rognorok if I remove connman, I might not be able to configure the Bluetooth (I have to port my project from BBB to BeagleBone Green wireless) using connmanctl commands Oct 25 20:25:25 Is there any better way rather than removing connman? Oct 25 20:26:19 Learn how connman works to configure static IP would be my guess. I doubt it's hard, but 8 months ago data was sparse at best. Oct 25 20:27:13 Sure Oct 25 20:41:57 laurittr, yes I'm able to get a can0, only 1 of the 2 can ports show up tho... and when I try to use it, it acts normal.. I even get the debug prints from the kernel module in dmesg. I need to add more messages to see what is going. Something must still be off in the DT/overlay, but I don't see how. Maybe something has changed in the kernel that has broken the spi mcp251x module Oct 25 20:42:32 but when I rx/tx data on the canbus, nothing shows up Oct 25 22:17:47 Hello Oct 25 22:18:26 I am in dire need of Beaglebone Black PRU help. Oct 25 22:19:44 I have followed along this http://www.righto.com/2016/09/how-to-run-c-programs-on-beaglebones.html#ref1 tutorial however I am stuck in the point of trying to read data inside the pru, specifically reading tons of data (array of bytes) Oct 25 22:39:19 tlab: Does nothing show up on the can bus or over spi? Oct 25 22:39:53 nothing on canbus Oct 25 22:39:57 I have not checked spi Oct 25 22:40:38 Ok, I can hook it up on thursday to check, dont have my beagle here. Oct 25 22:40:57 Do you mind sending back the overlay you have now, after the line you edited so I can check that Oct 25 22:41:00 ? Oct 25 22:41:41 sure Oct 25 22:41:54 What kerenel are you using now btw? Oct 25 22:42:34 4.4.24-ti-r55 Oct 25 22:43:52 Can you read data in the PRU? Oct 25 22:44:23 Or create and read binary files in the PRU? Oct 25 22:44:33 I have never touched the pru, so can't help. Just wait for a couple of hours and somebody will probably answer you Oct 25 22:45:28 Oh alright XD thank you. Oct 25 23:07:44 BeagleNoob: I expect there is a shared memory region of some sort that you'll need to send the data through (will need a program on the linux side to service it) Oct 25 23:08:03 BeagleNoob: documentation seems to indicate either Oct 25 23:08:27 http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide#prussdrv_init PRUSSDRV or remoteproc might provide an API to handle this Oct 25 23:08:37 * fishey1 has not personally used the PRU at all Oct 25 23:09:14 * fishey1 wishes it was an armv7m variant so I could avoid the lack of good development tools. Oct 25 23:17:30 Oh I have heard of that but Oct 25 23:17:59 I dont understand how you can use the limited shared memory for such large data sizes Oct 25 23:18:42 Yes, I have seen that api guide but it seems gibbersh to me XD Oct 25 23:22:03 According to a wiki you can use this int prussdrv_pru_write_memory to send the array Oct 25 23:22:12 but how would you even access it on the pru side? Oct 25 23:23:33 laurittr, well I moved the clk from yours into mine, and I have one of the spi can's working! yay Oct 25 23:25:46 what, is it working Oct 25 23:25:48 ? Oct 25 23:26:17 yeah I have 2 of the 3 can's working Oct 25 23:26:32 one is dcan, the other two are mcp2515 Oct 25 23:32:49 oh, nice Oct 25 23:32:59 Can you send it to me pls? Oct 25 23:33:13 Want to try it out for myself Oct 25 23:39:05 I sent it to your email Oct 26 01:21:28 BeagleNoob: without actually bothering to look, my guess would be it uses the shared ram as a ring buffer or a similar kind of fifo to stream data from one to the other Oct 26 01:22:06 and a cortex-M core would not be a good substitute for PRU Oct 26 01:25:22 of course writing a pru application in C instead of its very fancy assembler also seems silly to me Oct 26 01:26:47 fishey1: you could load your own firmware onto the cortex-m3 in the wakeup domain if you want an armv7m :P Oct 26 01:41:25 BeagleNoob: keep in mind that pruss doesn't have much local ram, and if you care about performance you really want to avoid making PRU cores perform reads outside pruss Oct 26 01:43:19 reading n words from local ram is 2+n cycles, reading n words from the main ddr3 ram has been reported at 42+n cycles Oct 26 01:45:43 im sorry zmatt but your knowledge is far above me Oct 26 01:46:34 the reason why I am choosing c is simply because its simpler and much more capable on my part. Oct 26 01:46:51 ok, but what are you using the pru for? Oct 26 01:47:21 in simpliest of terms to toggle an led Oct 26 01:47:38 >,< Oct 26 01:47:46 why use pru for that? and how does it involve "lots of data" ? Oct 26 01:48:00 Because I need the PRU's speed Oct 26 01:48:19 you won't see the LED toggle .. it'll be too fast for the eye to see! Oct 26 01:48:35 the normal GPIO speeds are not capable of speeds at or above Hz Oct 26 01:48:35 can you be less vague and just explain what you're trying to do rather than how you're trying to get there? Oct 26 01:49:53 I want to read a binary file (any size) and use its content to toggle the led Oct 26 01:50:48 thus my main issue is being able to read the bytes of data in the PRU program. Oct 26 01:51:07 you mean just send out the bits? at what speed? Oct 26 01:51:48 yes, well speeds is easily changable because I have set timers up in the PRU Oct 26 01:51:54 speed isnt my problem Oct 26 01:52:02 at what speed, max? Oct 26 01:52:12 1 MHz Oct 26 01:53:15 oh lol, you can bitbang that out in so many ways. I'd probably consider McASP as my first choice Oct 26 01:53:35 Whats McASP? Oct 26 01:54:06 audio serial port Oct 26 01:54:19 Instead of PRU's? Oct 26 01:55:01 it's basically a synchronous serial port Oct 26 01:55:23 so sending out a long stream of bits of data is its purpose in life Oct 26 01:55:45 in any case, you could of course use PRU as serializer Oct 26 01:56:29 Whats the max speed? And why would I use it over the PRU? Oct 26 01:56:31 hell 1 MHz is so slow you could probably make an elaborate EDMA construction bitbanging some gpio Oct 26 01:56:57 Actually I honestly want the fastest speed I can get Oct 26 01:57:13 The PRU's testing capabalities allows that Oct 26 01:57:15 really, what are you *doing* ? Oct 26 01:58:06 "toggling a led" at 1 MHz or above is something that could use a bit more clarification Oct 26 01:58:12 top secret spy stuff Oct 26 01:58:15 since that's not exactly how one normally uses a led Oct 26 01:58:41 I am creating a LiFi system. Oct 26 01:59:22 I don't suppose the various IrDA protocols implemented by the uarts are of any help? Oct 26 02:00:59 hmm Oct 26 02:01:08 btw to answer your original question more directly: you evidently want to stream data to PRU, so the obvious approach would be a ring buffer Oct 26 02:02:04 I dont think you can use the uart to toggle the led Oct 26 02:02:30 they generate pulses (in accordance to the relevant IrDA protocols) Oct 26 02:02:44 Yes I know you need "something" but I dont know "how" to implement it Oct 26 02:03:15 For example: prussdrv_map_prumem and int prussdrv_pru_write_memory Oct 26 02:03:20 http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide#prussdrv_map_prumem Oct 26 02:04:59 But would I continuously overwrite the PRU0 DATARAM? Oct 26 02:05:07 Also what register would I read in the PRU? Oct 26 02:05:18 google "ring buffer" Oct 26 02:05:20 study it Oct 26 02:05:58 experiment with it just using two threads in a program, or two linux programs with a shared memory buffer Oct 26 02:06:20 The issue isnt that, its the fact that the PRU only allows 8kb of instruction memory Oct 26 02:07:06 and because I am working in c, and the PRU code is compiled differently (using CCS) to get the binary out file Oct 26 02:07:24 There is no way to share a memory buffer Oct 26 02:07:26 why is the iram size a problem? it sounded like you're using pru basically as little more than a shift register Oct 26 02:07:34 I tried using extern Oct 26 02:07:40 but I came across many errors Oct 26 02:07:55 uhhhh, you're very very confused Oct 26 02:08:43 anyway I appreciate the help, Ill cotinue trying some stuff Oct 26 02:08:59 all of pruss ram is shared with the rest of the system (e.g. the cortex-a8), the rest of the system is just polite enough not to touch it usually Oct 26 02:10:18 prussdrv_map_prumem() is like mmap(), it is used to make one of the pruss rams visible in your linux program Oct 26 02:10:21 laurittr, zmatt: well I have it partially working https://github.com/travlytle/bbb_dtb Oct 26 02:10:48 Right, I understand that a little bit Oct 26 02:10:48 I think the chip select isn't working, because only one of the two spi can's work Oct 26 02:11:06 So, how would I access the specifc ram in my PRU Oct 26 02:11:06 tlab: try using gpio chip selects, or at least for the second one Oct 26 02:11:13 do you know the register? Oct 26 02:11:33 That holds the Ram address Oct 26 02:11:42 I am using the cs-gpios Oct 26 02:11:58 tlab: which kernel? Oct 26 02:12:09 4.4.24-ti-r55 Oct 26 02:13:10 BeagleNoob: from a PRU core's point of view its local data RAM always starts at address 0 Oct 26 02:15:23 what I don't understand, on the 3.8 kernel there is no dtb, no overlay... yet it loads just fine Oct 26 02:16:01 I see! Oct 26 02:16:02 tlab: I have no idea what you mean by that. of course there's a dtb, and also a dtbo that got automatically loaded from /lib/firmware/ Oct 26 02:18:01 So which method would be best to use? Oct 26 02:18:13 prussdrv_pru_write_memory ? or mmap Oct 26 02:18:47 Since I have to continuously send data Oct 26 02:19:30 prussdrv_map_prumem Maps the PRU DRAM memory to input pointer. Memory is then accessed by an array. Oct 26 02:19:36 zmatt, nope there is nothing.. it seems to work with just the eeprom stuff Oct 26 02:20:31 tlab: eeprom just contains some metadata which informs linux (cape-manager to be precise) which overlay it should load Oct 26 02:22:29 ehh well it's loading a dtb, the default config must be good Oct 26 02:22:38 not loading ! Oct 26 02:23:19 BeagleNoob: so, after doing void *pruram0; prussdrv_map_prumem( PRUSS0_PRU0_DATARAM, &pruram0 ); in linux (I'm hoping this is right, the docs are crappy and clearly outdated), that pointer should now point to the local data ram of pru core 0 Oct 26 02:25:07 so mind that the meaning of addresses/pointers depends on where core is running Oct 26 02:25:39 so how would I access this data in the pru? Oct 26 02:25:57 just set a register to 0x00000000 Oct 26 02:26:25 that same little chunk of memory is located at 0x00000000 for core running on pru core 0, at 0x00020000 for pru core 1, and at whatever prussdrv_map_prumem conjured up in your linux process Oct 26 02:26:29 uhh Oct 26 02:27:06 you can just directly access memory at some particular address Oct 26 02:27:35 i.e. *(int*)0x1234 = 42; Oct 26 02:28:04 of course if the compiler put some important stuff at 0x1234 then this would be a bad idea Oct 26 02:28:11 in some examples they have set up the registers used to control the gpio and end the pru olatile register unsigned int __R31, __R30; Oct 26 02:28:28 is it possible to add a register that point to the member? Oct 26 02:28:28 those are magic registers for doing gpio yes Oct 26 02:28:42 like how would I do it C wise Oct 26 02:30:19 * zmatt sighs Oct 26 02:30:22 OH WAIT Oct 26 02:31:13 brb im gonna try something Oct 26 02:31:19 BeagleNoob: one last tip Oct 26 02:33:41 ugh I found an old mcp251x driver where alex modified it in kernel 3.2 Oct 26 02:37:41 https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/recipes-kernel/linux/linux-mainline-3.8/net/0006-mcp251x-add-device-tree-support.patch Oct 26 02:37:57 got a segfault Oct 26 02:37:58 ;-; Oct 26 02:38:09 so he's modified the module to specifically work with this board Oct 26 02:38:16 or so it seems Oct 26 02:38:27 You get a seg fault if you're trying to read something for which you aren't mapped a page. Someone suggested Oct 26 02:38:36 tlab: uhh, this is angstrom? Oct 26 02:38:49 I assumed you meant the debian 3.8 kernel Oct 26 02:39:07 I'm using debian Oct 26 02:39:49 that link shows meta-beagleboard linux-mainline-3.8 Oct 26 02:39:55 BeagleNoob: hang on a bit Oct 26 02:40:32 tlab: yes which is why I'm a bit puzzled what I'm looking at, since I've only seen paths like that with Yocto and such Oct 26 02:40:47 that patch evidently adds Device Tree support to the driver Oct 26 02:40:57 so it can be used, say, from an overlay :P Oct 26 02:41:30 oh, you think that is what is edited? Oct 26 02:42:09 it's pretty clear from the patch Oct 26 02:42:18 even just by looking at which #includes it added Oct 26 02:43:17 mcp251x_platform_data_dt_get Oct 26 02:43:27 get dt :\ Oct 26 02:43:51 well seems my issue is still cs, I'll work more on it later Oct 26 02:44:02 tlab: try different kernels Oct 26 02:44:12 I've seen lots of changes in the mcspi driver over time Oct 26 02:44:17 especially w.r.t. chip selects Oct 26 02:44:32 really, I thought they looked mainly the same Oct 26 02:47:38 well I'll try later, night Oct 26 02:47:40 BeagleNoob: http://pastebin.com/NMXqTt31 Oct 26 02:47:48 BeagleNoob: this is absolutely untested Oct 26 02:49:41 oh much appreciated Oct 26 02:49:54 BeagleNoob: and consider trying assembly, then at least you hopefully understand what the PRU core does exactly Oct 26 02:50:07 C's abstraction seems to be causing confusion Oct 26 02:51:08 yea... the problem is I dont know how to put the c algorthim in assembly XD Oct 26 02:53:05 This is what im trying right now Oct 26 02:53:08 very simple test Oct 26 02:53:10 unsigned int pru0 = 0xAA; prussdrv_pru_write_memory(PRUSS0_PRU0_DATARAM, 0, &pru0, 2); Oct 26 02:54:11 then on the PRU side I did: unsigned int *byte = 0x00000000; then do something with byte[0]; which holds AA Oct 26 02:55:54 note that prussdrv_pru_write_memory basically just does prussdrv_map_prumem + memcpy() (except instead of calling memcpy it has its own custom copy loop) Oct 26 02:58:12 zmatt: why do you think an armv7m wouldn't be a good replacement for the PRUs? Oct 26 02:58:54 fishey1: the PRU cores are designed to have cycle-predictable timing so you can make custom bus protocols, that's also why it is unpipelined Oct 26 02:59:26 zmatt: so https://en.wikipedia.org/wiki/ARM_Cortex-R , then? Oct 26 02:59:26 [WIKIPEDIA] ARM Cortex-R | "The ARM Cortex-R is a family of 32-bit RISC ARM processor cores licensed by ARM Holdings. The Cortex-R is optimized for hard real-time and safety critical applications. It is one of the three different Arm Cortex profiles, the other two being the Cortex-A for applications processors, and Cortex-M for..." Oct 26 02:59:41 lol no Oct 26 02:59:45 That's an armv7m Oct 26 02:59:53 no it's v7-r **** ENDING LOGGING AT Wed Oct 26 02:59:58 2016