**** BEGIN LOGGING AT Thu May 15 02:59:59 2014
May 15 04:24:55 <mranostay> hmmm i don't get how sid got this codez to work
May 15 05:03:05 <mranostay> gah warning: relocation to symbol "C0" overflowed; the 18-bit relocated address
May 15 06:05:16 <av500> that would never happen on x86
May 15 08:20:30 <mranostay> x86 all things!
May 15 08:20:38 <mranostay> as long as i'm employed here
May 15 08:20:59 * mranostay looks for other ships 3 years out
May 15 09:16:13 <Abhishek_> mranostay: sid defines C4 like this: int C4 __attribute__((cregister("MEM",near),peripheral));
May 15 09:17:19 <mranostay> yeah need far pointers
May 15 09:17:26 <mranostay> need to sleep for dayjob
May 15 09:17:37 * mranostay converts to x86 protected mode
May 15 09:17:43 <Abhishek_> k
May 15 09:17:59 <Abhishek_> day starts at?
May 15 09:18:05 <mranostay> 5 hours from now
May 15 09:18:15 * mranostay rarely sleeps
May 15 09:37:34 <Abhishek_> mranostay: would a 16-byte SBBO instruction to DDR complete in a single cycle?
May 15 13:05:41 * karki_ is happy that is theory exams are over! 
May 15 13:05:50 * karki_ *his
May 15 13:07:04 <karki_> Abhishek_ : any access to the DDR would take multiple cycles!
May 15 13:21:44 <Abhishek_> that I understand, but I have to quantify it for my application
May 15 13:25:33 <karki_> as in?
May 15 13:26:30 <karki_> Abhishek_ : are the access cycles constant when accessing the DDR? (I doubt it....)
May 15 13:27:11 <Abhishek_> not expected, depends on the L3Fast interconnect that connects them
May 15 13:27:35 <karki_> panto : Hi!
May 15 14:53:23 <vvu|Log> karki_: so u are done now...i'm just starting :(
May 15 14:56:10 <karki_> vvu|Log : It's okay.... I still have a week left :(
May 15 14:56:44 <vvu|Log> oh well
May 15 14:57:15 <karki_> panto : wanted to discuss some device driver stuff with you!
May 15 15:04:30 <karki_> vvu|Log : have you worked with kobjects?
May 15 15:08:36 <karki_> mranostay : what is the significance of __attribute__ in your code?
May 15 15:09:37 <Abhishek_> that's the new TI Compiler magic
May 15 15:10:50 <karki_> is it in the doc?
May 15 15:11:08 <karki_> Abhishek_ : what does it do?
May 15 15:11:12 <Abhishek_> Check README.txt, I posted a link on Sunday, IIRC
May 15 15:15:19 * karki_ should RTM more :p
May 15 16:07:35 <mranostay> Abhishek_: README.txt is barely helpful :)
May 15 16:08:11 <Abhishek_> we need READMORE.txt :P
May 15 16:10:20 <karki_> Abhishek_ : +1 ;)
May 15 16:10:41 <karki_> I want an opensource C compiler!
May 15 16:11:27 <Abhishek_> Well there's a GCC port to PRU ds2 linked to once
May 15 16:11:39 <Abhishek_> I wonder if it's usable
May 15 16:28:53 <karki_> I remember that, checked it out. but don't know how well it works.
May 15 16:37:38 <vvu|Log> karki_: nop, never did kernel driver dev
May 15 16:43:46 <Abhishek_> I'm betting on UIO for the first bits, will get onto remoteproc later
May 15 16:49:29 <karki_> You would have to change quite a bit of code, right? if you plan to move from UIO to remote proc?
May 15 16:53:37 <Abhishek_> mranostay: examining the ws28xx lighting code disassembly for PRU0, the compiler is doing something weird for the CTRs , I see no SBCO instruction
May 15 16:53:49 <Abhishek_> there's one LBCO, that's all
May 15 16:55:42 <mranostay> yeah it is all broken
May 15 16:55:47 <mranostay> pru1 code works :)
May 15 16:56:09 <Abhishek_> well, that's just pure assembly, so expected ;)
May 15 16:56:32 <mranostay> would nodejs help here?
May 15 16:56:34 <mranostay> :)
May 15 16:57:30 <Abhishek_> Dunno, I was reading and came across "the Jeft Atwood's law"
May 15 16:57:56 <Abhishek_> any application that can be written in JavaScript will eventually be written in JavaScript
May 15 17:01:54 * karki_ is not really found of JS
May 15 17:02:46 <karki_> */me *fond
May 15 17:02:52 * karki_ * fond
May 15 17:03:01 <karki_> damn this keyboard :/
May 15 17:10:41 <karki_> panto : Hi!
May 15 17:17:44 <Abhishek_> mranostay: I just sent you a patch to the Makefile to generate detailed ASM listings (C interleaved) instead of the objdump listings which had little meaning.
May 15 17:43:33 <karki_> panto mranostay : for my project, would I be developing my own driver or modifying the rproc_pru driver that is currently available?
May 15 17:47:19 <mranostay> karki_: modify the rproc_pru one
May 15 17:47:24 <mranostay> add your syscalls
May 15 17:48:37 <karki_> and how would I be getting a userspace interface to talk to the driver?
May 15 17:48:50 <panto> well, that's something to develope
May 15 17:48:53 <panto> *develop
May 15 17:50:37 <karki_> alexanderhiam was discussing about a sysfs interface.....
May 15 17:52:06 <karki_> panto : what other alternatives do I have?
May 15 17:54:05 <panto> a sysfs interface is know to work
May 15 17:54:19 <panto> but, it's not very high performance
May 15 17:54:51 <panto> ideally you want a shared memory interface exposing downcalls
May 15 17:55:27 <Abhishek_> mranostay: How would you suggest defining a LA interface over remoteproc?
May 15 17:57:20 <karki_> panto : shared memory interface as in? Isn't sysfs just to give a user space exposure to the driver? shared memory is the driver <--> PRU implementation, right?
May 15 17:58:03 <panto> well, you can map a chunk of memory to user-space
May 15 17:58:46 <panto> and then use a mechanism to trigger a downcall to the PRU
May 15 17:58:55 <panto> that's for ARM -> PRU comms
May 15 17:59:33 <Abhishek_> so an upcall is when the PRU signals the ARM, correct?
May 15 17:59:35 <karki_> hhmm.... so implement mmap for the driver?
May 15 17:59:48 <karki_> I'm confused!
May 15 17:59:52 <panto> for PRU to ARM, you can try to map some PRU event bits to a user-space signal
May 15 18:00:22 <panto> from the PRU side it looks like an up-call
May 15 18:00:56 <karki_> and on the user side use a signal handler?
May 15 18:01:13 <panto> you need to have a well defined interface, in order to handle the copying of arguments to/from the shared memory and handle cache management
May 15 18:01:25 <panto> karki_, yes
May 15 18:01:38 <Abhishek_> how does the current UIO implementation wait for interrupts?
May 15 18:01:53 <panto> you don't have to do the work in the signal handler, the signal handler can notify the main loop of your application to handle it
May 15 18:02:42 <panto> https://www.kernel.org/doc/htmldocs/uio-howto/wait_for_interrupts.html
May 15 18:03:05 <panto> don't worry about it yet
May 15 18:03:25 <panto> just keep on hacking, get the pru code ported to the new TI compiler stuff
May 15 18:03:36 <panto> and when this is done, I'll give you guys a hand
May 15 18:07:20 <karki_> panto :  the main application (on linux) does not run in a loop (or so I thought). I will have to have a wait_for_event() function, this has to return only when the signal arrives, right? (thinking along the lines of the UIO interface)
May 15 18:07:57 <Abhishek_> panto: I'm thinking, with a remoteproc implementation, I'll have to map a chunk of memory to userspace, then use a mechanism for downcalls, upcalls, isn't this exactly what's there in the UIO driver and libprussdrv?
May 15 18:08:58 <panto> karki_, sigwait
May 15 18:09:16 <panto> Abhishek_, almost
May 15 18:09:28 <panto> UIO doesn't know how to deal with cache
May 15 18:10:02 <panto> and you can't use it if you want to do a standard kernel driver interface in the same time
May 15 18:10:39 <Abhishek_> I'm looking at this: https://github.com/beagleboard/linux/blob/beaglebone-3.2/drivers/uio/uio_pruss.c and I see the SRAM something. Is this the cache?
May 15 18:11:07 <Abhishek_> oops, wrong branch
May 15 18:11:16 <panto> no, this is the static ram
May 15 18:11:18 <Abhishek_> this: https://github.com/beagleboard/linux/blob/3.8/drivers/uio/uio_pruss.c
May 15 18:11:50 <panto> static ram is mapped uncached
May 15 18:12:17 <panto> but you have to copy data in/out of it
May 15 18:12:58 <panto> you can't do something like pru_tx(void *data, int size) with the pointer in user-space data
May 15 18:13:15 <panto> in DRAM
May 15 18:13:31 <panto> so the data address space you can address is very small
May 15 18:13:36 <panto> IIRC the SRAM is a few K
May 15 18:13:43 <karki_> 64K
May 15 18:13:48 <karki_> I think
May 15 18:14:46 <karki_> how exactly do you "handle" the cache? Is it not supposed to be transparent to the programmer?
May 15 18:18:23 <Abhishek_> panto: It isn't clear to me when you said " you can't do something like pru_tx(void *data, int size) with the pointer in user-space data in DRAM"
May 15 18:18:55 <panto> karki_, it is transparent to the ARM programmer
May 15 18:19:03 <panto> PRU & ARM are not coherent
May 15 18:19:40 <panto> Abhishek_, passing a pointer to DRAM requires manual cache management
May 15 18:20:11 <Abhishek_> the DRAM being the 512MB RAM, correct?
May 15 18:20:16 <karki_> yes
May 15 18:21:03 <karki_> panto : how do you go about manual cache management?
May 15 18:21:39 <panto> you need to call the cache management functions manually
May 15 18:22:13 <panto> http://minghuasweblog.wordpress.com/2013/03/29/arm-cache-flush-on-mmapd-buffers-with-clear-cache/
May 15 18:22:48 <panto> it needs to use a syscall
May 15 18:23:01 <panto> but, there are complications
May 15 18:23:34 <panto> so that's why I want to use some kind of user-space to downcall bridge
May 15 18:23:51 <panto> which will perform the required management transparently
May 15 18:25:16 <Abhishek_> panto: What you said is that this pru_tx is a function that's running on ARM, and it's passing some data to the PRU. So it means that I cannot just pass a pointer to my data in RAM to the PRU directly, it needs to be in a specific region of the DDR RAM so that the PRU can access it?
May 15 18:25:43 <panto> not exactly
May 15 18:25:56 <panto> the user-space pointer is a virtual address
May 15 18:27:02 <karki_> and VM to PM translation is process specific.....
May 15 18:27:03 <panto> the PRU has full access to the DRAM address space
May 15 18:27:21 <karki_> PRU bypasses MMU, right?
May 15 18:27:23 <Abhishek_> yep, that I know
May 15 18:27:23 <panto> so let's take a transmit call for example
May 15 18:27:24 <panto> yes
May 15 18:27:32 <panto> you need to do the following
May 15 18:28:00 <panto> 1. flush the contents of the cache lines in the given virtual address space (data, data + size - 1)
May 15 18:28:27 <panto> 2. lock the memory pages contains the buffer in physical memory
May 15 18:29:05 <panto> 3. convert the virtual address span to a list of (physical, count) scatter gather array elements
May 15 18:29:42 <panto> 4. get the physical address of the scatter gather array
May 15 18:30:21 <panto> 5. perform a down call as pru_tx_pru(struct scatter_gather *sga, int nelems)
May 15 18:31:00 <panto> 6. return from the downcall (collecting the return value)
May 15 18:31:06 <panto> 7. unlock the memory pages
May 15 18:31:14 <panto> 8. return to user-space
May 15 18:31:32 <karki_> thats a big list.....
May 15 18:31:43 <panto> things are simpler if you use a mmemaped memory space
May 15 18:31:56 <panto> since you can skip the scatter gather part
May 15 18:32:08 <panto> and pass a pointer directly there
May 15 18:32:14 <karki_> for that the driver has to give an implementation of mmap, right?
May 15 18:32:28 <panto> hey, life's hard, get over it :)
May 15 18:32:41 <karki_> or is it something else? :p
May 15 18:33:09 <panto> the driver will have some device file you can map just like uio
May 15 18:33:20 <panto> but I expect all of that to be handled by a user-space library
May 15 18:33:28 <panto> I don't want applications to deal with it
May 15 18:34:11 <panto> we have a hacky way to do it with UIO
May 15 18:34:19 * karki_ wonders how cool this would be if they thought this is class!
May 15 18:34:21 <panto> I want something elegant and easy to use
May 15 18:34:22 <Abhishek_> OK so as I understood, the problem with UIO occurs when you have to pass big chunks of data to the PRU, they may be existing as scattered chunks in the physical memory and UIO doesn't know how to deal with it?
May 15 18:34:36 <panto> UIO can't deal with cached memory areas
May 15 18:34:52 <panto> which is all your DRAM basically
May 15 18:35:16 <karki_> So UIO is fine only with sram stuff?
May 15 18:35:30 <panto> is fine with non-cached memory areas
May 15 18:36:00 <panto> UIO's existence is solely due to reason of circumventing the GPL
May 15 18:36:09 <panto> but don't pass that info around :)
May 15 18:36:54 <Abhishek_> why?
May 15 18:37:13 <panto> cause device drivers must have their source released under the GPL
May 15 18:37:22 <panto> user-space application do not have to
May 15 18:38:28 <Abhishek_> oh, so implement the driver as a user space application and use the "GPLed" UIO to talk to their device?
May 15 18:40:36 <karki_> panto : one more concern, if people keep patching the rproc_pru for every firmware they develop, won't it mess up that driver? (eg. I'm going to modify the driver for my firmware, you added support for your firmware, etc)
May 15 18:41:38 <panto> karki_, we'll figure things out
May 15 18:41:55 <panto> we'll refactor the driver
May 15 18:42:10 <panto> into common use parts and implementation specific parts
May 15 18:42:28 <panto> this was not a problem when it was first created
May 15 18:42:33 <karki_> exactly what I was typing ;)
May 15 18:43:10 <Abhishek_> okay, so would it be possible to have a libprussdrv-like API for the remoteproc implementation
May 15 18:43:24 <Abhishek_> something like libprussdrvrproc?
May 15 18:43:37 <panto> yeah
May 15 18:43:49 <panto> but probably much more advanced
May 15 18:43:55 <karki_> :'D  libprussdrvrproc
May 15 18:44:01 <panto> I have a few ideas about how to go
May 15 18:44:05 <Abhishek_> is this to be done this SoC?
May 15 18:44:11 <panto> but you need to fix the basic stuff first
May 15 18:44:21 <panto> Abhishek_, not really
May 15 18:44:40 <panto> you're only doing the first parts of something that might end up much bigger
May 15 18:44:50 <panto> at the moment you have your goals
May 15 18:45:07 <karki_> exactly my thought, things are getting too stretched for this SoC :( have to split work smartly!
May 15 18:45:43 * karki_ has ended up using "exactly" one too many times today ;)
May 15 18:46:34 <Abhishek_> So what I'm taking off this discussion is that I'm continuing with UIO drivers for the Logic Analyzer code for the SoC, and taking a remoteproc implementation as it becomes available as a stretch goal. (So switching from libprussdrv to libprussdrv-rproc as it develops)
May 15 18:46:57 <Abhishek_> *core/code
May 15 18:49:28 <panto> yeah
May 15 18:49:37 <panto> the core PRU code is irrelevant
May 15 18:49:59 <Abhishek_> panto: What's your opinion?
May 15 18:50:13 <karki_> panto : interface like libprussdrv-rproc is something I'll HAVE to develop, right? or there is no way I'll get any client interaction in the first place!
May 15 18:50:49 <panto> Abhishek_, we have different goals - yours is to get the logic analyzer
May 15 18:51:11 <panto> I'm more interested in getting the PRU stuff easily usable by users
May 15 18:51:22 <panto> karki_, you have to do it
May 15 18:51:40 <panto> so if you're ready by the time Abhishek_ is done, he might have time to use your stuff
May 15 18:51:50 <panto> ok, enough for now, got to work too
May 15 18:52:00 <karki_> hhmm..... I'll have to modify my SoC goals
May 15 18:52:05 <karki_> Thanks panto :)
May 15 18:52:12 <Abhishek_> thank you for your time panto :)
May 15 18:52:16 <panto> np
May 15 18:52:37 * karki_ realizes he has to sleep!
May 15 18:52:49 <karki_> Abhishek_ : when do you sleep?
May 15 18:53:36 <Abhishek_> it's about to be 2am here, I have to rerecord the audio track for my slides
May 15 18:54:08 <Abhishek_> usually by 3am
May 15 18:54:13 <karki_> where are you?
May 15 18:54:20 <Abhishek_> Jakarta, ID
May 15 18:54:23 <karki_> when do you wake up?
May 15 18:54:44 <Abhishek_> normally in 8hrs after I sleep
May 15 18:55:11 <karki_> I didn't know you stayed in indonesia!
May 15 18:55:41 <Abhishek_> here since my vacations in May
May 15 18:57:16 <karki_> I sleep at 1, get up at 7. So G'nite, I have half an hour to finish my recording, of which I'm almost done..
May 15 18:58:22 <Abhishek_> g'nite
May 15 19:20:14 <Abhishek_> panto: (cc mranostay) bothering you again with one more question: What issues can I have with UIO implementations for a LA situation (PRU is sampling from the GPIs and transferring data in bulk to the userspace application: maybe writing directly to DRAM in the extram_pool area (given by UIO), or in small chunks of PRU shared RAM being used as a ring
May 15 19:20:14 <Abhishek_> buffer)?
May 15 19:20:44 <panto> cache coherency management
May 15 19:20:52 <panto> and working with UIO which is kinda of a hack
May 15 19:21:40 <Abhishek_> could you suggest a resource for knowing more cache coherency?
May 15 19:30:22 <Abhishek_> panto: ^ & the link which you gave above for "__clear_cache" could help in this case? Also, could you point me to the UIO hack regarding memory management?
May 15 20:40:00 <Abhishek1> IRCCloud seems to have crashed
May 15 20:43:39 <vvu|Log_> Abhishek_: use IRSSI
May 15 20:43:51 <vvu|Log_> and leave it open in a screen session
May 15 21:22:27 <mranostay> the hell is irccloud?
May 15 21:26:30 * Abhishek_ is downloading koen's evil kernel sources
May 15 21:28:06 <Abhishek_> mranostay: IRCCloud is a fancy new IRC web client (and subscription based bouncer)
May 15 21:29:40 * Abhishek_ wonders how much he will use out of the 2 GB bundle he's downloading
May 15 21:31:26 <mranostay> downloading?
May 15 21:31:32 <mranostay> what warez?
May 15 21:31:50 <Abhishek_> Koen's kernel
May 15 21:33:00 <Abhishek_> *sources
May 15 21:33:53 <mranostay> what horrible ISPs do you have?
May 15 21:34:48 <Abhishek_> Currently clocking 5mbps, "4G TD-LTE"
May 15 21:36:09 <Abhishek_> ah done, only 750MB
May 15 21:42:50 <Abhishek_> so many x lines add whitespace errors warnings in patches
May 15 22:11:45 <Abhishek_> make -j on the kernel can crash my system?
May 16 00:01:36 <vvu|Log> Abhishek_: why crash ?
May 16 00:01:49 <vvu|Log> it should now if u have enough ram
May 16 00:02:46 <vvu|Log> j
May 16 00:04:30 <ds2> crash?
May 16 00:06:22 <vvu|Log> the build will stop, but no crashing
May 16 00:26:33 <Abhishek_> I don't know what happened, I did make -j and my system froze (only hdd activity, no kbd or mouse inputs), screen went blank after some time and no response to CtrlC. I hard rebooted and completed the kernel build with make -j8
May 16 00:28:08 <Abhishek_> Strange because there's 8GB RAM and an i7-3
May 16 00:29:37 <vvu|Log> what i learned after GSOC was that a VPS somewhere sames a lot of time than working on ur local machine
May 16 00:32:13 <Abhishek_> VPS for building the project?
May 16 00:32:48 <vvu|Log> yeah, i had to recompile kernels all over the place at some point
May 16 00:33:00 <vvu|Log> and was sick of keeping my laptop on all times
**** ENDING LOGGING AT Fri May 16 02:59:58 2014