**** BEGIN LOGGING AT Sun Jun 01 02:59:58 2014 Jun 01 04:40:21 * Abhishek_ yawns Jun 01 05:01:51 * karki_ finds this hilarious : http://pastebin.com/PnYQ3kqn some guy who thought people on IRC were customer care guys :'D Jun 01 09:16:07 * karki_ jumps off a roof. Jun 01 09:16:52 Don't worry, someone might be holding the trampoline below ;) Jun 01 09:44:45 karki_: why so ? Jun 01 09:50:32 vvu : my BBB died :'( Jun 01 09:58:13 how come ? Jun 01 10:01:31 I was playing with a few overlays and cape manager, on some particular command I got a huge syslog msg and my ssh got cut off, I re logged in tried to shut down the BBB, but BBB did not shutdown (though my connection was cut and was no longer able to reconnect). So I switched off the power and switched it back on, and other than the power led, nothing switches on! Jun 01 10:05:54 see maybe ur eMMC got corrupted Jun 01 10:06:05 i assume you have serial cable Jun 01 10:06:23 if it stalls like that maybe the MLO on the eMMC or uSD screwed up Jun 01 10:13:44 The uSD card seems fine when I connect it to my PC. Jun 01 10:14:22 This is the second time this happened today. Jun 01 10:15:16 try and do a reflash Jun 01 10:15:31 never happened to me but never worked with overlays and stuff Jun 01 10:15:41 The first time when it didn't boot, I removed the sd card, connected to my comp (didn't do anything other than navigate through it). then connected it back into my BBB, it worked perfectly! Jun 01 10:15:53 * vvu hates so much airport internet Jun 01 10:22:27 vvu : this is so random, it works now. Jun 01 10:22:38 I didn't do ANYTHING Jun 01 10:27:43 karki_: 42 Jun 01 10:27:52 ;) Jun 01 10:47:55 Abhishek_ : ping Jun 01 10:57:22 guys! where can I find the DTO source files for corresponding the .dtbo files in /lib/firmware ? Jun 01 10:57:53 previously in angstrom dts was present in the same folder Jun 01 11:01:42 nvm, found it :) Jun 01 14:03:03 karki: did you get the remoteproc stuff working? Jun 01 14:03:15 yes Jun 01 14:03:44 made modifications to the driver, seems to be working the way I want it to. Jun 01 14:03:47 as of now. Jun 01 15:05:14 Good to know. It's been a long weekend so far #XMenDoFP. Jun 01 15:12:27 panto: It seems the sysfs reload assumes ELF firmware only. I'm adding stuff there to support bin files too Jun 01 15:34:09 Abhishek_ : the funny thing is as per the official kernel docs for rproc, there is supposed to be support only for ELF. did you come across the doc? I kinda got confused when I saw a bin implementation in panto's code Jun 01 15:34:43 panto : ping Jun 01 15:35:09 that must be an off-spec hack to get to get PASM stuff running I think Jun 01 15:35:28 panto might not be available today anyway Jun 01 15:36:05 yeah. Jun 01 15:36:09 until the new C Compiler generated stuff be cleared for takeoff, I don't think so Jun 01 15:36:58 what kind of exe does the pru assembler output? Jun 01 15:37:27 That's a raw bin file ready to be written into the PRU RAM from offset 0 Jun 01 15:37:37 *IRAM Jun 01 15:49:07 Abhishek_ : have you traced down the IRQ's and upcalls and downcalls? Jun 01 15:52:32 currently going through that part to add stuff Jun 01 16:03:31 Abhishek_ : If you are using rproc, how are you planning to implement the shared memory b/w kernel and PRU? Jun 01 16:04:29 I actually wanted to ask panto that, but given the nature of your project I thought you must have already discussed about this with him before! Jun 01 16:19:49 never mind, figured it out, though I just can't get over the weird fn names :p Jun 01 16:30:43 * vvu just moved in a place where just ports 80 and 443 are opened on the router...i cannot even ssh :( Jun 01 16:32:51 I know that feeling, vvu . Tor might be your best bet there :) Jun 01 16:34:22 karki: I'll just create shared memory pools within the rproc interface, add a custom char device (like the implementation of LED strip drivers by mranostay) for BeagleLogic Jun 01 16:34:58 but how will you pass on the physical addr to the PRU? Jun 01 16:35:45 The allocator gives both physical and virtual addresses, so that should not be a point of concern. Jun 01 16:36:01 which allocator? Jun 01 16:37:34 dma_alloc_coherent, so instead of creating a single large pool (which was the point of contention and the roadblock), I create multiple small pools Jun 01 16:38:07 Abhishek_: it sucks big time Jun 01 16:39:19 :/ Jun 01 16:40:42 maybe i will get a VPN and get it done with Jun 01 16:44:32 * karki just finished implementing some nice image processing algorithms :) Jun 01 16:44:47 feels goood, back to the bone now....... Jun 01 16:44:49 in OpenCV? Jun 01 16:44:54 nah Jun 01 16:45:01 plain code ;) Jun 01 16:45:09 thats why it feels good Jun 01 16:46:15 * karki considers taking up a masters in machine learning and image processing. Jun 01 16:46:32 happens to be my strongest subjects (for now ;) ) Jun 01 16:49:07 Abhishek_ : "dma_alloc_coherent" is in which header file again? Jun 01 16:49:38 it resolves down to architecture specific implentations. Jun 01 16:50:17 the ones used in rproc driver Jun 01 16:50:23 where is it defined Jun 01 16:50:32 which header Jun 01 16:50:45 just want to look at src code :) Jun 01 16:51:52 nvm Jun 01 16:52:10 I was searching for #inc Jun 01 16:52:25 forgot the "linux/" ;) Jun 01 16:52:27 my bad Jun 01 17:05:35 Abhishek_ : So the mmap of your fops will return the virt addr given by "dma_alloc_coherent", and the PRU will get the phy addr? Jun 01 17:05:58 yep Jun 01 17:07:34 but there wouldn't be just one virtual address, so I'll have to figure out something else. Jun 01 17:08:54 why do you have a problem with a single chunk of memory? Jun 01 17:09:01 I don't get it Jun 01 17:09:40 I cannot get more than 8 MB of memory with dma_alloc_coherent, it crashes my current UIO implementation. Jun 01 17:10:11 you are sticking with UIO? Jun 01 17:10:25 I thought you ditched it for rproc Jun 01 17:10:31 the UIO impl internally uses that to alloc mem Jun 01 17:11:33 * Abhishek_ has ditched the UIO bandwagon and is running to climb onto the remoteproc bandwagon Jun 01 17:11:48 I am currently in-between Jun 01 17:12:02 you can't for long ;) Jun 01 17:12:17 yep, that's a dangerous place to be. Jun 01 17:12:59 I'll be borrowing some of your rproc code if you do end up taking the rproc route Jun 01 17:13:22 * karki will save time implementing PRU->ARM side stuff Jun 01 17:13:54 sure, but remember, there's nothing like saving time in programming. Jun 01 17:16:04 I sure "saved" some time with UIO. Jun 01 17:24:14 but it was useful to prototype though. Jun 01 17:30:05 Abhishek_ : Does the clpru have GPIO libraries ready to use? Jun 01 17:30:56 IIRC it doesn't Jun 01 17:32:11 how do you write to registers in clpru? Jun 01 17:32:56 have you compiled a simple "gpio toggle program" with the clpru? Jun 01 17:33:16 no, not really Jun 01 17:34:36 this entire C compiler stuff was the only reason I didn't want to get my hands dirty with remoteproc in first instance, I preferred to start with UIO which was minimal, so I could rapidly build my PRU firmware Jun 01 17:36:52 I wanted to start with UIO too, too bad my project was "A remote proc cased botspeak interpreter for the PRU" ;) Jun 01 17:37:08 "remote proc" being the highlight there :p Jun 01 18:02:55 There's a need to reduce to reduce entry barrier in remoteproc, so that people may avoid wasted hours with the UIO "hacks". I could work on that post-GSoC. Jun 01 18:03:41 I call dibs on refactoring the rproc driver Jun 01 18:03:45 ;) Jun 01 18:04:10 or if you have decided to do that..... I have something else in mind Jun 01 18:04:12 :p Jun 01 18:05:29 everyone does have "something else", that is not an excuse though Jun 01 18:06:04 ? Jun 01 18:06:23 I meant remote proc stuff itself, but not the refactoring part. Jun 01 18:06:48 that way I have 3 other heavy stuff up my hand right now :( **** ENDING LOGGING AT Mon Jun 02 02:59:59 2014