**** BEGIN LOGGING AT Thu Jun 05 02:59:58 2014
Jun 05 07:04:32 <Abhishek_>  panto: Currently using your rproc impl as a module, I see with lsmod that it is being used by 2 processes and that is perhaps causing the driver not to cleanly unloaded. Are these two processes IRQs?
Jun 05 07:13:30 <vmayoral|pc> good morning
Jun 05 07:13:57 <Abhishek_> hi
Jun 05 07:28:16 <panto> hi Abhishek_
Jun 05 07:28:32 <panto> not processes, other modules
Jun 05 07:29:27 <Abhishek1> panto: so how to cleanly unload the module then?
Jun 05 07:42:49 <panto> paste the lsmod output
Jun 05 07:46:11 <Abhishek_> panto, here
Jun 05 07:46:17 <Abhishek_> root@beaglebone:/mnt/BeagleLogic/kernel# modprobe remoteproc
Jun 05 07:46:17 <Abhishek_> root@beaglebone:/mnt/BeagleLogic/kernel# insmod pru_rproc_bl.ko
Jun 05 07:46:17 <Abhishek_> root@beaglebone:/mnt/BeagleLogic/kernel# lsmod
Jun 05 07:46:17 <Abhishek_> Module                  Size  Used by
Jun 05 07:46:17 <Abhishek_> pru_rproc_bl           19784  2
Jun 05 07:46:18 <Abhishek_> remoteproc             14620  1 pru_rproc_bl
Jun 05 07:46:18 <Abhishek_> virtio_ring             7203  1 remoteproc
Jun 05 07:46:19 <Abhishek_> virtio                  4618  1 remoteproc
Jun 05 07:46:19 <Abhishek_> g_multi                47152  2
Jun 05 07:46:20 <Abhishek_> libcomposite           13883  1 g_multi
Jun 05 07:46:20 <Abhishek_> autofs4                17241  2
Jun 05 07:46:21 <av500> pastebin
Jun 05 07:46:30 <av500> next time
Jun 05 07:46:34 <Abhishek_> ok
Jun 05 07:48:07 <panto> hmm, something is incrementing the module use count
Jun 05 07:48:23 <panto> tbh, we never tested using it as modules
Jun 05 08:01:44 <Abhishek1> And attempting to reload a bin firmware caused a kernel oops. That can be fixed, however I'm moving to C anyway
Jun 05 08:02:06 <Abhishek1> I mean, generating elfs with the PRU C Compiler
Jun 05 08:06:24 <panto> Abhishek1, I want you guys to get to a point where your stuff mostly works
Jun 05 08:06:30 <panto> then I'll make a pass and fix things
Jun 05 08:06:56 <panto> it is not a good use of time to start fiddling with things while you're in the middle of your work
Jun 05 08:07:06 <panto> I know there are lots of warts
Jun 05 08:07:15 <panto> the biggest is that we need to move to a mainline kernel
Jun 05 08:07:42 <panto> so, although you are in pain, it's not a debilitating kind of pain
Jun 05 08:07:47 <panto> hang in there :)
Jun 05 08:08:04 <Abhishek1> yup, hanging tight :)
Jun 05 09:24:09 <karki> vvu : I've been trying since today morning, but my board refuses to boot :(
Jun 05 09:24:25 <karki> only pwr led for the board switches on
Jun 05 09:24:29 <Abhishek1> is there stuff in the eMMC?
Jun 05 09:24:34 <karki> ya
Jun 05 09:24:45 <karki> angstrom
Jun 05 09:25:44 <karki> I did serial debug, nothing. I believe the ARM chip is not getting started at all
Jun 05 09:26:36 <karki> no primary or secondary bootloader in action I guess, (since serial read no info at all, + not any sort of blinking)
Jun 05 09:26:41 <karki> my sd card is fine
Jun 05 09:27:14 <karki> Abhishek1 : have you got your rev C ?
Jun 05 09:28:14 <Abhishek1> nope, haven't heard anything about shipping
Jun 05 09:28:36 <Abhishek1> except that it is delayed, of course.
Jun 05 09:47:26 * karki suicides :(
Jun 05 10:43:44 * karki 's BBB randomly decided to boot!
Jun 05 11:49:20 <karki> panto : Is it wise to create the shared memory during probe itself? (thats what I'll be doing now)
Jun 05 11:49:50 <panto> karki, seems fine
Jun 05 11:56:26 * Abhishek1 is porting his PRU firmware to CLPRU assembly
Jun 05 12:57:15 <vvu> karki: you did have something there if it booted
Jun 05 12:58:30 * vvu blames this on magic
Jun 05 12:59:14 <Abhishek1> I don't know why but my BBB also likes to magically boot from eMMC if the SD filesystem is not sync'd properly it seems
Jun 05 12:59:53 <Abhishek1> it's just a minor annoyance sometimes
Jun 05 14:38:33 <Abhishek1> It looks like the CLPRU assembler is very sensitive to syntax, LBBO &R0,.. is valid and LBBO R0,... is invalid
Jun 05 15:58:09 <karki> panto : what type should my variable pointing to the starting of the shared memory be? I'm confused b/w  int* , u32* , void *__iomem. I'm not aware of kernel conventions yet!
Jun 05 15:58:24 <karki> (variable on the kernel side)
Jun 05 16:04:24 <panto> void
Jun 05 16:04:29 <karki> ok
Jun 05 16:04:38 <panto> you can convert to whatever without a cast
Jun 05 16:05:42 <karki> thanks :)
Jun 05 16:06:25 <karki> I should have shared mem done in a few hours. I'll start with user space interaction tomorrow
Jun 05 16:14:52 <Abhishek1> karki: What's the size of the shared mem pool in your case?
Jun 05 16:15:09 <karki> probably 8K
Jun 05 16:15:33 <Abhishek1> k
Jun 05 16:18:48 <Abhishek1> mranostay jkridner panto: Does the PRU C Compiler have "preprocessed macros", e.g. I write NOP 7 and it inserts 7 NOPs into the assembly code.
Jun 05 16:19:11 <Abhishek1> NOP 10 and 10 NOPs in my code, and so on
Jun 05 16:19:28 <mranostay> yeah you can do macros
Jun 05 16:19:44 <mranostay> ah you mean inline assembly?
Jun 05 16:20:39 <Abhishek1> no, not exactly, I mean if I write something like NOP 'n', then the macro would evaluate to n NOPs when preprocessed
Jun 05 16:21:32 <mranostay> i highly doubt that
Jun 05 16:21:41 <Abhishek1> I have ported some of the macros I had been using with the PASM syntax however
Jun 05 16:22:01 <Abhishek1> the CLPRU assembler is stricter than PASM
Jun 05 16:22:03 <mranostay> panto: does TI do anything that insane? :)
Jun 05 16:23:48 <Abhishek1> mranostay: Can I assign a data array to a series of registers, or I am at the mercy of the compiler in the case (tempted to do the PRU0 code in C & inline assembly)
Jun 05 16:24:25 <Abhishek1> something like char d[32] assigned to R20-R27?
Jun 05 16:31:12 <Abhishek1> mranostay: just found out that __delay_cycles(x) does exactly what I am looking for
Jun 05 16:35:12 <Abhishek1> it accepts a constant (no variables) and generates NOPs and loops to spin around for "x" cycles
Jun 05 16:54:35 * Abhishek1 thinks that RTFM (readme.txt) does turn out to be a little helpful sometimes :)
Jun 05 16:56:57 <mranostay> Abhishek1: hmmm i don't think you do that
Jun 05 16:57:02 <mranostay> *can
Jun 05 16:57:23 <mranostay> at least directly
Jun 05 16:57:37 <mranostay> i'm sure the compiler does use the register page feature
Jun 05 16:59:04 <Abhishek1> readme.txt has a mention that it can let structs go to registers ( < 44 bytes)
Jun 05 17:04:19 * karki RTM is always helpful ;)
Jun 05 17:04:53 <Abhishek1> released to market
Jun 05 17:05:15 <Abhishek1> s/market/manufacturing
Jun 05 17:45:16 <Abhishek1> made a struct, but the compiler doesn't seem to be happy enough to give it a register bank
Jun 05 18:27:55 <karki> panto : I'm able to create the shared memory and give the physical addr to the pru, but now how is the PRU supposed to access that memory location? (The code is in C)
Jun 05 19:01:50 <karki> Abhishek1 : were you able to access memory external to the PRU ?
Jun 05 19:02:23 <Abhishek1> last week? ;)
Jun 05 19:02:58 <karki> so how do you go about accessing the memory external to the local address space?
Jun 05 19:03:42 <Abhishek1> with a SBBO assembly instruction
Jun 05 19:05:24 <karki> hhmm
Jun 05 19:05:36 <Abhishek1> you doing it in C?
Jun 05 19:05:46 <karki> yes
Jun 05 19:06:26 <karki> :/
Jun 05 19:34:12 <panto> I'm not really here, but there is a PRU memory map in the manual
Jun 05 19:34:23 <panto> you just *(u32 *)0x100000 = 10
Jun 05 19:34:29 <panto> ok, away now
Jun 05 19:34:38 <Abhishek1> g'night panto
Jun 05 21:21:02 * vvu likes the peace and quiet around here
Jun 05 21:21:10 <Abhishek1> REALLY????
Jun 05 21:22:00 * Abhishek1 is cleaning up commits
Jun 05 21:22:26 <_av500_> vvu: pong
Jun 05 21:25:16 <_av500_> ok, need to zzz
Jun 05 21:26:18 <vvu> no worries _av500_
Jun 05 21:26:28 <vvu> we can catch up 2morrow, same here sleep :)
Jun 05 21:26:43 <Abhishek1> same here, once I push stuff up
Jun 05 21:27:49 <vvu> Abhishek1: you are done with all university stuff right ?
Jun 05 21:28:48 <Abhishek1> for this semester yes but still 6sems to go for me to post-graduate :P
Jun 05 21:29:10 <vvu> eh but now you can spend all the night coding and not caring when you wake up 2morrow morning !
Jun 05 21:29:57 <Abhishek1> yep, it is even probably time for everyone to wake up now in some while
Jun 05 21:30:17 <Abhishek1> over here
Jun 05 21:30:29 <vvu> what GMT are you ?
Jun 05 21:30:32 <Abhishek1> +7
Jun 05 21:30:58 <vvu> ohoo so 6AM going now right ?
Jun 05 21:31:22 <Abhishek1> just 4:30 AM
Jun 05 21:31:30 <vvu> ah, calculations going wrong again
Jun 05 21:32:13 <Abhishek1> yep, things like further suggest sleep time :P
Jun 05 21:32:27 <Abhishek1> *like these
Jun 05 21:32:37 <vvu> or like ^^
Jun 05 21:34:48 <Abhishek1> indeed
Jun 05 21:39:55 <vvu> Abhishek1: link to git repo ?
Jun 05 21:40:37 <Abhishek1> currently pushing to local branch though, https://github.com/abhishek-kakkar/BeagleLogic
Jun 05 22:47:55 <Abhishek_> commits pushed on the work so far, more blanks to fill in before kernel driver and PRU firmware freeze
Jun 05 22:51:39 <Abhishek1> g'night channel
**** ENDING LOGGING AT Fri Jun 06 03:00:00 2014