**** BEGIN LOGGING AT Fri Jul 05 02:59:58 2013
Jul 05 08:59:13 <vvu> av500: ping
Jul 05 14:03:09 <beng-nl> tcort: i am out of town sat+sun, so if anything comes up i won't be able to respond until monday
Jul 05 14:03:21 <beng-nl> tcort: i trust this won't block you, if you even want to do anything in the weekend :)
Jul 05 14:06:09 <tcort> beng-nl: I have no blocking problems on the horizon. Have a good weekend!
Jul 05 14:10:19 <beng-nl> great! thank you!
Jul 05 15:27:49 <ka6sox> jj2baile, I'm here
Jul 05 16:10:16 <mluckham> ka6soc, I'm here - setting up Eclipse/openocd targeting the Launchpad
Jul 05 16:10:37 <mluckham> following the tutorials here http://kernelhacks.blogspot.ca/2012/11/the-complete-tutorial-for-stellaris_25.html
Jul 05 16:16:57 <ka6sox> kewl
Jul 05 16:17:35 <mluckham> gdb+openocd on the command line is madness
Jul 05 16:17:53 <panto> I beg to differ
Jul 05 16:18:02 <mluckham> lol - I'm used to IDE
Jul 05 16:18:04 <panto> that's what eclipse uses under the hood
Jul 05 16:18:11 <mluckham> yes of course!
Jul 05 16:18:23 <panto> so you have one more layer (eclipse)
Jul 05 16:18:30 <panto> that won't help you debug it
Jul 05 16:18:46 <mluckham> true that on a past project, I grew to hate Eclipse ...
Jul 05 16:19:59 <mluckham> that was on a Google-GWT project
Jul 05 16:20:26 <mluckham> blaming Eclipse probably misplaced ...
Jul 05 16:22:30 <panto> hating eclipse is never misplaced
Jul 05 16:22:41 <panto> learn to love the command line and it will love you back
Jul 05 16:23:13 <mluckham> true it can be much faster ... once you learn what to do
Jul 05 16:23:23 <mluckham> + no carpal tunnel
Jul 05 16:23:28 <mluckham> (mouse)
Jul 05 16:24:37 <mluckham> I was reading some of your stuff on installable Capes
Jul 05 16:25:40 <mluckham> that plus CPLD = Software Defined Peripheral ?
Jul 05 16:26:29 <panto> you might do without the CPLD on some cases
Jul 05 16:26:53 <mluckham> sure
Jul 05 16:28:05 <mluckham> your installable Capes means - a driver (or something, I didn't read it all yet) - automagically appears when the Cape is detected?
Jul 05 16:30:50 <panto> any driver that is needed with the proper configuration
Jul 05 16:31:18 <mluckham> as described by the EEPROM contents ... ?
Jul 05 16:32:08 <panto> yes
Jul 05 16:33:06 <mluckham> what would happen next?  Example if a driver that claims there is a CPLD appears, another app would connect using the driver to use the CPLD (whether to USE it, or to program it) ??
Jul 05 16:35:43 <ka6sox> mluckham, I'm hoping we can get the kernel to use the firmware() method to load those
Jul 05 16:36:02 <panto> the whole point is to use the cpld to build another peripheral
Jul 05 16:36:19 <mluckham> yes, I get that - great idea
Jul 05 16:36:26 <panto> for example you could (by loading firmware) make the cpld to be an i2c controller/spi/whatever
Jul 05 16:36:56 <mluckham> ok - dynamically determining what you want the Cape to be ...
Jul 05 16:38:21 <mluckham> how general purpose can you make the additional driver circuitry, beyond the CPLD?
Jul 05 16:38:48 <mluckham> such as the drivers in the project Cape schematic ...
Jul 05 16:40:06 <ka6sox> mluckham, the purpose of the CPLD on BoneTag is mostly Glue....but we could definately use it to reprogramme the functionality if necessary
Jul 05 16:40:42 <ka6sox> mluckham, the drivers were chosen to accomodate 1.8v to 5v inputs and outputs for various targets
Jul 05 16:41:33 <mluckham> so ... a bunch of drivers on the board, just choose which ones you want to use
Jul 05 16:42:15 <ka6sox> in this case, I have wired them to the various standard connectors found on target boards for JTAG/SWD/SBW/AVRisp
Jul 05 16:42:34 <ka6sox> however....
Jul 05 16:42:50 <ka6sox> since they are open collector you *could* repurpose them
Jul 05 16:43:32 <mluckham> PRU not being stricly necessary ... just for speed ?
Jul 05 16:44:18 <ka6sox> the PRU is to handle the Hard RT aspects of various debugging stuff
Jul 05 16:45:30 <mluckham> so the PRU is an optional part of the Cape driver [firmware]
Jul 05 16:46:15 <mluckham> or vice versa <g>
Jul 05 16:47:38 <ka6sox> the purpose of all this is to USE the PRU, and as such it is not optional
Jul 05 16:48:04 <ka6sox> (otherwise I could make the CPU BitBang the JTAG but that sucks pretty bad)
Jul 05 16:48:18 <panto> the cpld is not capable of doing anything too complicated
Jul 05 16:48:56 <panto> so you have a cascade of elements, from the most general (and non deterministic), to the most specialized and deterministic
Jul 05 16:49:08 <panto> ARM -> PRU -> CPLD -> wires
Jul 05 16:49:23 <ka6sox> the CPLD, in this case, was put there so we could investigate whether serial or parallel out of the PRU is best, and whether we needed any FIFO buffering
Jul 05 16:49:53 <mluckham> ok - the PRU is what attracted me about the project
Jul 05 16:50:15 <ka6sox> the CPLD, in this cape, is Glue
Jul 05 16:53:04 <mluckham> I've not used JTAG at the signalling level before
Jul 05 16:53:28 <mluckham> the FIFO buffering would use the PRU memory?
Jul 05 16:53:59 <ka6sox> I was thinking about adding a little bit (maybe 1 byte) to the CPLD if we determine its necessary
Jul 05 16:54:06 <mluckham> ahh
Jul 05 16:54:20 <ka6sox> again, once its there, its fixed
Jul 05 16:55:16 <ka6sox> I only intend to change the programming in the CPLD to accomplish the goals of the project
Jul 05 16:55:24 <ka6sox> then leave it alone
Jul 05 16:55:26 <mluckham> for jitter removal?  Or would that make jitter worse?
Jul 05 16:55:43 <ka6sox> the CPLD will handle all Jitter issues
Jul 05 16:57:29 <mluckham> about JTAG, is high-speed (50+ MHz) for faster download, or - what else?
Jul 05 16:57:36 <mluckham> you can't program flash that fast - can you?
Jul 05 16:58:55 <panto> mluckham, I have worked on projects where there was no flash
Jul 05 16:59:18 <panto> but there were a few hundreds of MB of DRAM, where the roofs and the kernel was transferred via jtag
Jul 05 16:59:34 <panto> there was no high-speed interface and no flash working
Jul 05 17:00:20 <ka6sox> 50+mhz is the goal of this project (for the summer)
Jul 05 17:00:29 <ka6sox> most wigglers go about 5mhz...at most
Jul 05 17:00:42 <mluckham> i see - what about JTAG trace execution buffer - can that be done using this Cape / project output?
Jul 05 17:01:13 <ka6sox> if we can get this going and transfer the data to openOCD then sure...why not
Jul 05 17:01:35 <ka6sox> purpose is not just programmer, but also Debugger as well.
Jul 05 17:01:41 <panto> yes
Jul 05 17:02:29 <mluckham> it has a lot of potential
Jul 05 17:02:57 <ka6sox> I'm hoping to get to the $300 class of debugger for $120
Jul 05 17:03:23 <ka6sox> if we can get it to go to 100mhz...thats the $2000 class performance
Jul 05 17:03:34 <mluckham> :)
Jul 05 17:04:24 <ka6sox> right now I'd settle for working at all.
Jul 05 17:04:38 <mluckham> ha!  have you designed 100 MHz hardware?
Jul 05 17:04:43 <ka6sox> yes
Jul 05 17:04:57 <ka6sox> I work @ 100mhz daily
Jul 05 17:06:18 <mluckham> RF/analog factors creep in ... so you know
Jul 05 17:07:14 <ka6sox> FT Job is 50% Analogue, 50% Digital
Jul 05 17:07:49 <panto> ka6sox, I've managed to use both PRUs now
Jul 05 17:08:08 <ka6sox> panto, including shared memory?
Jul 05 17:08:13 <panto> yeah
Jul 05 17:08:18 <panto> the works
Jul 05 17:08:33 <ka6sox> iirc the shared memory also shows up on L4 right?
Jul 05 17:08:40 <panto> going to do an N channel pwm controller
Jul 05 17:08:47 <panto> yes, but you can't use it
Jul 05 17:09:01 <panto> I tried but there are problems with the arbitration when the PRUs run
Jul 05 17:09:19 <ka6sox> so you could set initial conditions but when running you can't
Jul 05 17:10:56 <panto> there is a way
Jul 05 17:11:02 <panto> the other PRU
Jul 05 17:11:16 <panto> so, I think I have it under control
Jul 05 17:13:46 <panto> for small amounts of data there's an even faster memory
Jul 05 17:13:51 <panto> shadow register banks
Jul 05 17:16:39 <ka6sox> are those between PRU<>CPU or PRU<>IO?
Jul 05 17:17:43 <panto> they are shared in the PRU
Jul 05 17:17:57 <panto> single cycle access in the non-contented access case
Jul 05 17:18:15 <panto> 30x4 bytes in a single cycle
Jul 05 17:18:18 <ka6sox> oh right, I saw those
Jul 05 17:18:25 <panto> if I read the manual correctly
Jul 05 17:18:54 <ka6sox> b00m
Jul 05 17:19:48 <panto> btw, apparently accessing the DRAM is dog slow
Jul 05 17:20:01 <panto> which is expected really, no cache
Jul 05 17:20:07 <ka6sox> right
Jul 05 17:20:20 <panto> could be close to half a usec per access
Jul 05 17:20:36 <ka6sox> without a coherent cache how are we going to make virtio happy?
Jul 05 17:20:42 <panto> already done
Jul 05 17:20:52 <ka6sox> vrings?
Jul 05 17:20:58 <panto> yes
Jul 05 17:21:59 <panto> https://github.com/pantoniou/linux-bbxm/commit/f01b49efc60b70e968ff58109bb0284adc6f76c8
Jul 05 17:22:16 <panto> it's just a device
Jul 05 17:24:17 <ka6sox> so we need to let openOCD use this device for its I/O
Jul 05 17:26:47 <panto> it's a serial port
Jul 05 17:27:01 <panto> well, not a tty, but it's a byte stream
Jul 05 17:27:19 <panto> which is easier to handle than coming up with a linux jtag subsystem
Jul 05 17:30:53 <ka6sox> yes, what I was hoping was to let the protocols be handled by the OCD app and only deal with timing issues in the PRU
Jul 05 17:32:56 <ka6sox> the initial thing will be the Boundry Scan (BS) and then the OCD app knows what to send next
Jul 05 17:33:12 <ka6sox> as long as it has a BSL for the devices probed.
Jul 05 17:40:33 <ka6sox> panto, I know that direct access is kind of slow...but it maybe that we need to do BS first and then do further configuration of the PRU to know the length of the frame
Jul 05 17:41:09 <ka6sox> also things like openOCD can collapse the length by putting devices into "bypass" so that means after we do that the length changes too.
Jul 05 17:41:14 <ka6sox> and the PRU needs to know that
Jul 05 17:55:34 <panto> k
Jul 05 17:56:31 <ka6sox> panto, how easy will it be to flush a vring?
Jul 05 17:57:29 <panto> err, easy
Jul 05 17:58:11 <ka6sox> everytime we change lengths we will need to flush things
Jul 05 17:58:47 <ka6sox> I really don't want to do any FIFOs if we can keep up with just the PRUs
Jul 05 18:40:19 <_av500_> vring my beeeeeeeell
Jul 05 18:46:27 <ka6sox> _av500_, are you into Disco?
Jul 05 21:40:02 <vvu> av500: watched the elc presentation of the FIT stuff, really nice. u-boot already has support for it. 2morrow i will test if things work :)
Jul 06 01:15:56 <jj2baile> `/win 13
Jul 06 01:18:07 <ka6sox> hiya jj2baile
Jul 06 01:27:13 <jj2baile> oh, hey.
Jul 06 01:27:46 <ka6sox> long week?
Jul 06 01:28:01 <jj2baile> ka6sox: so you mentioned we would need to plan with panto in the coming week about the interface between the C code and PRU i think?
Jul 06 01:28:06 <jj2baile> oR was it a different layer
Jul 06 01:28:19 <jj2baile> ka6sox: Yeah kind of. accidentally skipped a sleep cycle.
Jul 06 01:28:24 <ka6sox> panto has worked thru those details and now has example code
Jul 06 01:28:35 <jj2baile> ka6sox: excellent, where is it hosted?
Jul 06 01:28:58 <ka6sox> https://github.com/pantoniou/testpru/blob/master/testpru.c
Jul 06 01:29:13 <jj2baile> i like men
Jul 06 01:29:25 <jj2baile> anyone want sex?
Jul 06 01:29:28 <jj2baile> right now>
Jul 06 01:29:36 <jj2baile> ... sorry. About that.
Jul 06 01:29:44 <jj2baile> My friend took my laptop when i got up
Jul 06 01:30:04 <jj2baile> ka6sox: Thanks for the url
Jul 06 01:30:24 <jj2baile> I should go back to locking my computer whenever i leave my laptop
Jul 06 01:31:30 <ka6sox> for the serial testing panto has a DTC for this
Jul 06 01:31:46 <ka6sox> also did you see the new PASM and "supported" instructions?
Jul 06 01:32:07 <ka6sox> especially look at loop
Jul 06 01:32:10 <jj2baile> i saw new instructions but was not entirely sure if they those instructions were supported by the beagle
Jul 06 01:32:17 <jj2baile> good to know that they are
Jul 06 01:32:40 <jj2baile> How new are device trees as an interface? I had never seen them prior to doing research on the beagle.
Jul 06 01:33:28 <ka6sox> the beagle is one of the first ARM devices to support this paradigm
Jul 06 01:33:41 <ka6sox> but its been around in PPC and other ARCH's for a long time
Jul 06 01:33:48 <ka6sox> origins are OpenFirmware.
Jul 06 01:33:52 <jj2baile> Aha, that explains a lot actually. I had asked various people familiar with such technologies about it and many of them knew not of it
Jul 06 01:36:17 <ka6sox> for upstreaming to mainline linus has said "no more boardfiles"
Jul 06 01:36:22 <ka6sox> so that means DT
Jul 06 01:37:34 <ka6sox> jj2baile, I think we have someone who will be working on the openOCD to virtio driver code
Jul 06 01:37:49 <ka6sox> and the virtio driver code is done by panto
Jul 06 01:37:54 <ka6sox> so now you need to "catch" it
Jul 06 01:38:28 <jj2baile> Alright. So I need to go read that documentation with regards to the signals openocd emits
Jul 06 01:38:58 <ka6sox> this will be important to determine what you need to do with the code and how to talk back to it
Jul 06 01:39:10 <ka6sox> but the actual code is being handled by someone else.
Jul 06 01:39:18 <ka6sox> mluckham, ping?
Jul 06 01:39:31 <jj2baile> Yeah, communicating back to openocd is an interesting aspect i didn't think about yet.
Jul 06 01:39:54 <ka6sox> we will let mluckham talk to us about this.
Jul 06 01:44:54 <ka6sox> jj2baile, we need to do "discovery" of whats on the JTAG bus (aka Boundary Scan)
Jul 06 01:45:32 <jj2baile> Yeah, That would be a good first thing to implement
Jul 06 01:51:32 <ka6sox> okay yes, that would be our first task
Jul 06 01:53:32 <ka6sox> from your reading of IEEE1149 that discovery protocol is defined
Jul 06 01:58:32 <jj2baile> Yeah, i recall it being fairly straight forward.
Jul 06 02:03:21 <ka6sox> is that what you are planning on doing next?
Jul 06 02:05:30 <jj2baile> yeah, well my general plan was just to try to do the signaling accurately with the PRU alone, but i didn't decide specifically which to do first. Boundary test is a great starting place
Jul 06 02:06:23 <ka6sox> that will completely test the protocol
Jul 06 02:09:33 <ka6sox> I need to go to another city in the morning but when I arrive on site I'll check in
Jul 06 02:10:36 <jj2baile> i really do like men
Jul 06 02:11:01 <jj2baile> anyone want to bang RIGHT NOW?!
Jul 06 02:11:14 <jj2baile> wtf?
Jul 06 02:11:26 <jj2baile> serioously dudes.
Jul 06 02:11:33 <jj2baile> im willing rigt now\
Jul 06 02:11:57 <jj2baile> im pullijg kmy
Jul 06 02:12:17 <jj2baile> sigh... I never learn do I. I think ill just shut my computer off for the night.
Jul 06 02:12:26 <jj2baile> ka6sox: Thanks for the discussion!
Jul 06 02:12:30 <jj2baile> i really apologize...
Jul 06 02:13:00 <jj2baile> But yeah, assuming good documentation of the stellaris, based on the boundary test i should be able to detect any possible issues with my implementation
Jul 06 02:13:43 <jj2baile> I guess gnu screen has a locking feature for a reason.
Jul 06 02:43:26 <ka6sox> jj2baile, yup...
Jul 06 02:43:31 <ka6sox> protect the computer!
Jul 06 02:43:32 <ka6sox> laters
**** ENDING LOGGING AT Sat Jul 06 02:59:58 2013