**** BEGIN LOGGING AT Thu Jul 25 02:59:58 2013
Jul 25 14:15:45 <mluckham> panto, ping
Jul 25 14:16:24 <panto> mluckham, pong
Jul 25 14:16:41 <mluckham> good morning/day to you :)
Jul 25 14:16:45 <panto> :)
Jul 25 14:16:51 <panto> good morning too
Jul 25 14:17:06 <mluckham> the compile worked, now I'm trying to get the testpru[01] to load
Jul 25 14:17:17 <panto> it should be too hard
Jul 25 14:17:22 <panto> *shoudn't
Jul 25 14:17:28 <panto> what doesn't work?
Jul 25 14:17:57 <mluckham> i can't figure out how to tell it to load them
Jul 25 14:18:07 <mluckham> i tried modprobe remoteproc, modprobe pru_rproc
Jul 25 14:18:20 <mluckham> and echo BB-BONE-PRU-01 > capemgr.8/slots
Jul 25 14:18:32 <panto> ok, there are a number of PRU capes
Jul 25 14:18:37 <mluckham> there is also a BB-BONE-PRU-02
Jul 25 14:18:41 <panto> going from simpler to more complex
Jul 25 14:18:53 <panto> the last one that works with the pru example is BB-BONE-PRU-04
Jul 25 14:19:00 <panto> use that one
Jul 25 14:19:14 <mluckham> that's what you said, I couldn't find it / didn't look in the right place
Jul 25 14:19:29 <panto> firmware/capes in the kernel sources
Jul 25 14:19:35 <mluckham> ok!
Jul 25 14:19:58 <mluckham> brb
Jul 25 14:35:47 <mluckham> panto, conflict P8.20 (#4: BB-BONE-EMMC-2G)
Jul 25 14:35:55 <panto> yes
Jul 25 14:36:10 <panto> that cape uses every output pin that the prus have
Jul 25 14:36:25 <panto> you'll have to boot with the HDMI/emmc capes disabled
Jul 25 14:36:36 <mluckham> so I need to adjust uEnv.txt
Jul 25 14:37:02 <panto> yes
Jul 25 14:37:12 <mluckham> k
Jul 25 14:53:53 <mluckham> ok, testpru loaded and running now
Jul 25 14:54:32 <mluckham> I notice testpru1 seems to do PWM output - I should see on my logic analyzer?
Jul 25 14:55:39 <mluckham> btw, dmesg | tail shows testpru output - any other way to see pru printf output?
Jul 25 14:59:05 <panto> yes
Jul 25 14:59:14 <panto> yes, on both
Jul 25 14:59:19 <panto> just a sec
Jul 25 14:59:53 <panto> https://plus.google.com/100242854243155306943/posts/UbxDZahNoKv
Jul 25 15:00:21 <panto> and there's a character device with a serial prompt interface on /dev/vport0p0
Jul 25 15:01:51 <mluckham> i noticed /dev/vport0p0 was created
Jul 25 15:02:11 <mluckham> and in dmesg:  remoteproc1: registered virtio0 (type 11) but I didn't find a device with that name
Jul 25 15:02:17 <panto> that's your serial like interface
Jul 25 15:02:22 <mluckham> great :)
Jul 25 15:03:06 <panto> remoteproc1 is for the PRU1 (which doesn't have a virtio interface)
Jul 25 15:03:21 <panto> the concept is that you have one PRU for your comm with linux as a frontend
Jul 25 15:03:29 <panto> and a PRU for doing the hard realtime stuff
Jul 25 15:05:52 <mluckham> in the link you gave me, /sys/class/pwm were created by testpru's ?
Jul 25 15:07:33 <panto> they were created by the proc driver, which communicates with the prus
Jul 25 15:07:39 <panto> use the source
Jul 25 15:08:28 <mluckham> ok
Jul 25 15:09:25 <mluckham> now, how can linux-side interact with the vrings?
Jul 25 16:31:53 <mluckham> jj2baile, ping
Jul 25 16:34:09 <panto> mluckham, via a virt device
Jul 25 17:15:33 <mluckham> this is relevant?  http://omappedia.org/wiki/Design_Overview_-_RPMsg#Firmware_Loading
Jul 25 17:34:23 <panto> mluckham, it is but I don't use it
Jul 25 17:34:41 <panto> the resource table is created via the DT data, and is not part of the firmware image
Jul 25 17:35:43 <mluckham> can I use some the vring code in testpru0.c as a model?
Jul 25 17:35:51 <wmat> did I miss a ping? I see the alert, but don't see the message.
Jul 25 17:38:02 <panto> obviously
Jul 25 17:38:30 <panto> I wouldn't recommend trying to do vring code from scratch
Jul 25 17:38:38 <panto> took me some time until I got it working
Jul 25 17:38:46 <mluckham> thought so - times two!  I bet it did!
Jul 25 17:38:55 <panto> :)
Jul 25 17:40:17 <mluckham> so what would be equivalent to '	rsc_vdev = resource_get_rsc_vdev(res, VIRTIO_ID_RPROC_SERIAL, 0);' in order to get the virt device connection?
Jul 25 17:40:35 <mluckham> on the linux side
Jul 25 17:41:17 <panto> mluckham, you don't need that in the linux side
Jul 25 17:41:30 <panto> cause in linux you build the resource table yourself
Jul 25 17:41:37 <panto> check the code for the sordid details
Jul 25 17:41:50 <mluckham> sordid, check!
Jul 25 17:42:27 <mluckham> so no /dev/???? for the virt device, everything is in the resource table (the one specified in the .dts?)
Jul 25 17:42:49 <panto> yes
Jul 25 17:42:53 <panto> of sorts
Jul 25 17:43:55 <mluckham> would the kernel code for /dev/vport0p0 be a model?
Jul 25 17:45:11 <panto> yes
Jul 25 17:45:12 <panto> but
Jul 25 17:45:20 <panto> it is very very complicated
Jul 25 17:46:04 <panto> I would say just use this fake serial device as your bulk-data transfer
Jul 25 17:46:18 <panto> and use the up/down call methods for your control plane
Jul 25 17:46:41 <mluckham> agreed, that seems like the simplest approach
Jul 25 17:47:05 <panto> if you're familiar with networking it's pretty similar to that kind of architecture
Jul 25 17:47:17 <panto> separate things into control plane/data plane
Jul 25 17:47:26 <mluckham> layering
Jul 25 17:47:30 <panto> optimize each plane for different characteristics
Jul 25 17:48:49 <mluckham> that would handle bulk-in, what about bulk-out?
Jul 25 17:49:02 <mluckham> same vport0p0 device?
Jul 25 17:50:22 <panto> vport0p0 is bi-directional
Jul 25 17:51:23 <mluckham> is it buffered?
Jul 25 17:51:33 <panto> yes
Jul 25 17:51:41 <mluckham> using the vrings ..
Jul 25 17:51:54 <panto> controlled by the DT provided count of descriptors
Jul 25 17:52:06 <mluckham> yep
Jul 25 17:55:20 <mluckham> maybe i'll try to write or add a loopback to testpru0
Jul 25 17:57:04 <mluckham> back soon
Jul 25 17:57:08 <panto> k
Jul 25 18:43:09 <mluckham> back (from the vet)
Jul 25 19:40:38 <mluckham> panto, do/can you use any tools to help debug PRU code?
Jul 25 19:48:14 <panto> no
Jul 25 19:48:24 <panto> there's a working printf (sc_printf)
Jul 25 19:48:29 <panto> that's all you need
Jul 25 19:48:42 <panto> free yourself from reliance on tools
Jul 25 19:48:49 <panto> the only one you need is in your head
Jul 25 19:50:23 <mluckham> printf : standard if there is nothing else
Jul 25 19:51:10 <panto> you don't need anything else
Jul 25 19:51:18 <panto> I mean really
Jul 25 19:51:25 <panto> that's what most people debugging the kernel use
Jul 25 19:53:24 <mluckham> back to the days of think+code+think again - before hitting 'run' :)
Jul 25 19:53:29 <ds2> printf don't work too well inthe kernel ;)
Jul 25 19:53:38 <ds2> so if you are using it, you will have problems.
Jul 25 19:54:52 <mluckham> typical for kernel debugging
Jul 25 19:56:01 <panto> ds2, pedantic :)
Jul 25 19:56:22 <mluckham> drop what would have printed into a buffer instead, look at the buffer after a crash
Jul 25 19:56:24 <mluckham> old school
Jul 25 19:56:37 <panto> the problem you get to fix are rarely something you can fix via stepping via a debugger
Jul 25 19:56:55 <panto> PRUs are flinging bits out at 100MHz
Jul 25 19:57:03 <panto> use a scope if you have to
Jul 25 19:57:20 <ds2> Mmmm scopes
Jul 25 19:57:22 <mluckham> right, too complex - would need a full-blown emulator
Jul 25 19:57:29 <mluckham> i have scope + logic analyzer, fortunately
Jul 25 19:57:35 <mluckham> use pins for debugging :)
Jul 25 19:57:51 <ds2> you can do an amazing amount of debugging with a VOM
Jul 25 19:58:01 <mluckham> ... if you must!
Jul 25 19:58:15 <panto> mark 1 eyeball + mark 1 brain is all you need
Jul 25 19:58:19 <mluckham> and a LED!
Jul 25 19:58:40 <ds2> I'd avoid LEDs if possible
Jul 25 19:58:47 <mluckham> groan
Jul 25 19:58:49 <ds2> those things can leave you astray
Jul 25 19:59:00 <ds2> not joking
Jul 25 19:59:04 <mluckham> i know
Jul 25 19:59:06 * panto hugs his scope 
Jul 25 19:59:10 <mluckham> awww
Jul 25 19:59:12 <panto> ok, time to go now
Jul 25 19:59:17 <mluckham> tx again panto
Jul 25 19:59:19 <ds2> problem is you cannot see low duty cycles
Jul 25 19:59:24 <mluckham> you got us off the ground now
Jul 25 19:59:24 <panto> don't mention it
Jul 25 19:59:36 <panto> that's the point
Jul 25 19:59:42 <panto> open sauce and all that
Jul 25 19:59:42 <mluckham> :)
Jul 25 19:59:47 <panto> g'night
Jul 25 19:59:49 <mluckham> night
Jul 25 19:59:54 <mluckham> jj2baile, ping
Jul 25 20:57:41 <mluckham> jj2baile, ping
Jul 25 21:26:49 <mluckham> jj2baile, please look at https://www.dropbox.com/s/rx24a1khb823lj2/panto_build.sh and try to replicate the steps to get panto's testpru0 and testpru1 running - I think you should use the information to update your blog
Jul 25 22:31:45 <jj2baile> mluckham: Alright, Thanks, Ill take a look
Jul 25 22:33:14 <mluckham> jj2baile, let me know your questions and I'll try to help
Jul 25 22:34:13 <mluckham> I understand now how his scheme works, it's pretty impressive
Jul 25 22:34:30 <mluckham> but i think we need to define a jtag debugger interface
Jul 25 22:35:23 <mluckham> if you look at the bottom of the panto_build.sh file (the link I gave you) it shows how to operate the pwm driver (testpru1), and talks about the bidirectional vring connection /dev/vport0p0
Jul 25 22:36:41 <mluckham> panto suggests the downcall-type interface be used for control, and the bi-directional serial driver be used for bulk transfers
Jul 25 22:37:08 <mluckham> testpru0 (pru0) handles the linux-pru communication - what I was just talking about
Jul 25 22:37:26 <mluckham> and alerts testpru1 (pru1) for the actual pin bashing
Jul 25 22:38:16 <jj2baile> mluckham: is this the same as the pastebin you did the other day?
Jul 25 22:38:22 <mluckham> for an interface, at least there would need to be primitive commands - that map to jtag functionality
Jul 25 22:38:45 <mluckham> the link is https://www.dropbox.com/s/rx24a1khb823lj2/panto_build.sh
Jul 25 22:38:58 <jj2baile> Yeah, I've opened it
Jul 25 22:39:28 <jj2baile> hmmm Ok. I see.
Jul 25 22:40:02 <mluckham> we could keep it really simple, even use the 'pwm' driver but replace or add some code in testpru0 for the functionality we need
Jul 25 22:40:23 <mluckham> at first, change it later
Jul 25 22:41:48 <mluckham> do you see how the pwm driver is configured (duty_ns, period_ns) and then executed (run)?
Jul 25 22:44:40 <jj2baile> wow, quite detailed documentation you have here.
Jul 25 22:44:45 <jj2baile> quite helpful, thanks.
Jul 25 22:44:50 <mluckham> bread crumbs
Jul 25 22:45:25 <mluckham> you should be able to follow along, and duplicate what I did here
Jul 25 22:46:07 <mluckham> and write it up properly, for your blog
Jul 25 22:46:17 <mluckham> and reports, etc
Jul 25 22:46:19 <jj2baile> Yeah.
Jul 25 22:46:51 <mluckham> meanwhile I want to start making progress with an openocd interface
Jul 25 22:47:15 <mluckham> you know about jtag protocols, i don't
Jul 25 22:48:13 <mluckham> there must be parameters (bus speed, data element size, buffer lengths, etc, etc) that have to be configured - do you know what I mean?
Jul 25 22:48:53 <jj2baile> well the speed of communication is moot, based on how the protocol works, but yeah.
Jul 25 22:49:15 <jj2baile> The things that have to be configured most of all is information specific to the target being debugged.
Jul 25 22:49:30 <mluckham> such as?
Jul 25 22:49:52 <jj2baile> the actual instructions the target supports (and the requisite opcode)
Jul 25 22:50:11 <jj2baile> the Instruction register length
Jul 25 22:50:34 <jj2baile> Which I think might be able to be detected dynamically, however strictly by the spec they way im thinking of may not be defined.
Jul 25 22:50:44 <jj2baile> may not have well-defined results*
Jul 25 22:50:58 <jj2baile> etc.
Jul 25 22:51:19 <jj2baile> But that information will come from the interface with openocd
Jul 25 22:51:49 <jj2baile> since there are the standard ways of telling openocd about its target,
Jul 25 22:52:03 <jj2baile> I also need to look more into the openocd side of things
Jul 25 22:52:07 <mluckham> openocd only operates the jtag with the bare minimum to supply sane gdb support
Jul 25 22:52:17 <jj2baile> But yeah Ill try to get pantos kernel up first
Jul 25 22:52:23 <mluckham> absolutely
Jul 25 22:52:50 <mluckham> right now we have two ends of the protocol:  gdb-side of openocd, and signalling side of jtag target
Jul 25 22:52:57 <mluckham> we need to define what is in the middle
Jul 25 22:53:29 <mluckham> and whether to implement a one-off special
Jul 25 22:53:48 <mluckham> or a general-purpose jtag linux driver (which sounds like a big job)
Jul 25 22:54:19 <mluckham> it is also easy to see the jtag-side of openocd - we can just use the openjtag project as a basis, I think
Jul 25 22:55:01 <mluckham> you should take a look at openjtag too
Jul 25 22:55:25 <mluckham> they have an interesting intermediate 'language', not just pin signal bashing
Jul 25 22:56:37 <mluckham> http://www.openjtag.org/download/v1.0/OPENJTAG%20Communication%20Protocol%20Manual.pdf
Jul 25 22:57:19 <mluckham> I'm thinking, openocd sends one of the command bytes to the PRU, which triggers the CPLD on the BONETAG to do the actual signalling
Jul 25 22:57:31 <mluckham> what do you think?
Jul 25 22:59:30 <mluckham> what are your alternative ideas?
Jul 25 23:02:28 <jj2baile> my original ideas were far simpler. but I had thought it would end up being something like sending a command to instruct the PRU to do a specific function. then relaying the result back
Jul 25 23:02:31 <vvu> anyone here have any idea if i can build a smaller angstrom build? like < 500 megs or such?
Jul 25 23:02:35 <jj2baile> so similar to the last thing you said it seems
Jul 25 23:03:26 <mluckham> I suspect it could save a lot of time, piggybacking on the ideas in openjtag
Jul 25 23:03:40 <jj2baile> I shall take a look at that project as well
Jul 25 23:03:47 <ds2> yes
Jul 25 23:03:57 <ds2> take out unneeded packages
Jul 25 23:04:36 * vvu needs to get familiar with how angstrom is built
Jul 25 23:04:50 <vvu> ds2: i think i'm on the end with writing eMMC via android
Jul 25 23:04:50 <ds2> vvu: what command do you use to start a build?
Jul 25 23:05:03 <mluckham> jj2baile, what is your schedule on this?
Jul 25 23:05:23 <vvu> ds2: don't have things in front of me right now, i was just curious to prep my work for 2morrow
Jul 25 23:05:35 <ds2> vvu: oh..
Jul 25 23:05:38 <ds2> rough overview
Jul 25 23:05:49 <ds2> you ultimately will run bitbake foo-image
Jul 25 23:06:02 <ds2> somewehre in recipes is a file with soemthing like foo-image.bb
Jul 25 23:06:13 <ds2> inside there is a list packages for the image
Jul 25 23:06:22 <jj2baile> mluckham: this being? And I had wanted to first get the video out of the way by the end of the week.
Jul 25 23:06:24 <vvu> i want to build a simple angstrom like with some text editor, terminal, internet browser and kinds that is all
Jul 25 23:06:29 <ds2> remove ones that you don't need (watch dependencies)
Jul 25 23:06:30 <vvu> just for a rough eMMC flash
Jul 25 23:06:44 <vvu> to get some things working
Jul 25 23:06:47 <ds2> you can also in the same place copy foo-image.bb to foo2-image.bb
Jul 25 23:06:54 <ds2> edit foo2-image.bb to be ur liking
Jul 25 23:07:00 <vvu> yep
Jul 25 23:07:06 <ds2> then change it to run bitbake foo2-image
Jul 25 23:07:07 <mluckham> jj2baile: I just want to know what I should do, by when, to coordinate with you
Jul 25 23:07:26 <ds2> this is somewhat vague as it has changed a little since I last used it and I don't have it in front of me
Jul 25 23:07:32 <vvu> ds2: if i put android on a BBB are there good chances that i can run my project on that one ?
Jul 25 23:07:40 * vvu thinks it will run :)
Jul 25 23:07:51 <ds2> probally if you can get that android working reliably ;)
Jul 25 23:08:01 <vvu> OH :))
Jul 25 23:08:05 <ds2> I had some performance issues with the BBW
Jul 25 23:08:11 <vvu> so not so stable ?
Jul 25 23:08:16 <ds2> I have a little plastic box with LCD and BBW
Jul 25 23:08:29 <ds2> no... but I was testing it over 3-4 hours
Jul 25 23:08:40 <vvu> saw the post on your website about the android tablet thingie with BBW
Jul 25 23:08:48 <ds2> yes that's the thing
Jul 25 23:09:01 <ds2> GB was a little better performance wise
Jul 25 23:09:07 <ds2> I had ICS and GB going
Jul 25 23:09:33 <jj2baile> mluckham: Im not sure of exactly the timing, but for at least today, and maybe tomorrow, Im going to try to get the video, at least recorded.
Jul 25 23:09:40 <vvu> i was just curious about it, BBBception
Jul 25 23:10:25 <mluckham> jj2baile: ok, I'll continue to play around here.  Did you know about the Detroit Maker Faire this weekend / are you going?
Jul 25 23:10:27 <ds2> I been thinking of a way to un F the BBB to try that
Jul 25 23:10:35 <ds2> but the BBB is so F'ed :(
Jul 25 23:10:46 <jj2baile> mluckham: I vaguely knew about it, not going though.
Jul 25 23:10:51 <vvu> saw some posts on G+ about android on BBB
Jul 25 23:10:54 <mluckham> i'm thinking about it
Jul 25 23:11:03 <vvu> with video and all but on HDMI not lcd cape
Jul 25 23:11:12 <jj2baile> hmm I guess detroit /is/ pretty close to southern ontario
Jul 25 23:11:20 <ds2> some guy on the ML got it going with a later kernel
Jul 25 23:11:22 <mluckham> probably 1-1/2 hours from here
Jul 25 23:11:26 <ds2> but the whole cape system is seriously F'ed
Jul 25 23:11:32 <ds2> I would not try it with a cape
Jul 25 23:11:34 <jj2baile> i forgot it was so close
Jul 25 23:11:44 <vvu> ds2: so glad my project does not involve a cape
Jul 25 23:11:45 <mluckham> 3 hours for you
Jul 25 23:11:50 <mluckham> 3.5
Jul 25 23:12:13 <ds2> heheeh :)
Jul 25 23:12:54 <mluckham> jj2baile, if you need help just ask
Jul 25 23:13:05 <jj2baile> Yeah, definitely shall.
Jul 25 23:13:13 <mluckham> good luck with the panto stuff then
Jul 25 23:13:33 <vvu> mluckham: sorry to bug into the discussion, you are a student ?
Jul 25 23:13:39 <mluckham> no
Jul 25 23:13:49 <vvu> uoke :)
Jul 25 23:14:09 <mluckham> well, always a student ... ;)
Jul 25 23:14:17 <mluckham> never ends
Jul 25 23:14:51 <ds2> mluckham: you're the openocd guru, right? :D
Jul 25 23:15:18 <mluckham> wouldn't use those words, but I've been looking at how to integrate openocd with the prujtag project
Jul 25 23:16:28 <mluckham> how about you?
Jul 25 23:16:31 <ds2> but you're with the openocd side, right?
Jul 25 23:16:36 <mluckham> yes, openocd side
Jul 25 23:16:44 <ds2> I'm just an random trouble maker :D
Jul 25 23:16:47 <mluckham> lol
Jul 25 23:17:01 <ds2> couldn't this be handled like how the stlink2 stuff is handled?
Jul 25 23:17:11 <mluckham> tell me more
Jul 25 23:17:21 <ds2> the swd thing forced a resturce of the code, IIRC
Jul 25 23:17:53 <ds2> I donno that much details. All I recall was some highlights on how stlink2 works with openocd in the current code
Jul 25 23:18:21 <mluckham> looks like st-link is an in-circuit debugger
Jul 25 23:18:52 <mluckham> prujtag project wants to implement an external jtag debugger, with CPLD boost for speed
Jul 25 23:19:16 <mluckham> .. and PRU boost ..
Jul 25 23:19:55 <mluckham> but I suppose the SWD protocol should be investigated
Jul 25 23:20:20 <mluckham> openocd supports swd
Jul 25 23:22:23 <ds2> st-link is a SWD debugger
Jul 25 23:22:29 <ds2> not really incircuit
Jul 25 23:22:43 <mluckham> i see it can use fewer pins than jtag
Jul 25 23:22:55 <ds2> it is a dongle but ST almost gives it away with the Discovery board (you can move jumpers and connect it to your own board)
Jul 25 23:23:11 <ds2> yes, SWD is 2 wire. it is for the low pin count deivces...mostly Cortex-M stuff
Jul 25 23:23:29 <mluckham> we have Stellaris Launchpad, with ICD (USB) and also 6-pin JTAG capability
Jul 25 23:23:47 <ds2> the concepts for SWD should be applicable to JTAG too
Jul 25 23:24:40 <mluckham> probably swd is jtag-minus?  jtag also good for component scanning and board testing?
Jul 25 23:25:53 <mluckham> anyway, I'm here to help with jtag <g>
Jul 25 23:29:41 <ds2> swd is suppose to be jtag with pins serialized
Jul 25 23:29:58 <ds2> something like serializing a serial protocol
Jul 25 23:47:31 <ka6sox> mluckham, focus is key...
Jul 25 23:47:58 <mluckham> yep
Jul 25 23:49:42 <ka6sox> jj2baile, can we have the video by sunday?
Jul 25 23:50:06 <jj2baile> K.
Jul 25 23:50:11 <jj2baile> I was going to try to do it today
Jul 25 23:50:48 <jj2baile> I have access to a video camera now, but not sure if there is a tripod or something of that sort
Jul 25 23:51:05 <jj2baile> oh actually, I think there is. Ok that should be fine, just need figure out how to use it.
Jul 25 23:53:18 <ka6sox> okay great!
**** ENDING LOGGING AT Fri Jul 26 02:59:57 2013