**** BEGIN LOGGING AT Mon Aug 12 02:59:58 2013
Aug 12 08:15:44 <keesj> Hi!
Aug 12 09:46:13 <keesj> How are our students doing?
Aug 12 09:47:48 <keesj> sleepy?
Aug 12 10:58:27 <tcort> keesj: hello and welcome back.
Aug 12 10:59:02 <keesj> thanks
Aug 12 10:59:24 <keesj> tcort has been doing great work!
Aug 12 11:00:07 <tcort> thanks :)
Aug 12 11:00:49 <tcort> not sure if you had time to read my blog since you got back, but I've posted a couple of youtube videos.
Aug 12 11:01:52 <keesj> watched a few indeed (powerdown and rtc related) also looked at the patches and submitted work
Aug 12 11:03:30 <tcort> I'll go through some of the code comments when I've had a bit more coffee :)
Aug 12 11:03:37 <keesj> I plan on doing some profiling in the next 2 weeks or so.
Aug 12 11:04:20 <keesj> do you have the weather cape?
Aug 12 11:04:23 <tcort> some minix/arm stuff is pretty slow.
Aug 12 11:05:00 <tcort> not yet
Aug 12 11:05:35 <keesj> yes it's dead slow hence the profiling :P
Aug 12 11:05:57 <keesj> lets hope it is not a architectural problem
Aug 12 11:06:01 <tcort> maybe the clock interrupt? on i386 it's 60Hz and on arm it's 1kHz
Aug 12 11:06:19 <panto> isn't minix just inherently slower due to the micro-kernel arch?
Aug 12 11:06:25 <keesj> yes that's quite high indeed but there is more
Aug 12 11:06:52 <keesj> panto: yes certainly and currently but not that slow
Aug 12 11:07:10 <panto> keeps us posted :)
Aug 12 11:07:15 <keesj> I hope it's the curerent context switching code and flushes that cause the problem
Aug 12 11:07:48 <panto> define dead slow
Aug 12 11:08:05 <keesj> I also plan to give CCS and the profiling tools there a second chance
Aug 12 11:08:19 <tcort> panto: time gcc hello.c => 36 seconds
Aug 12 11:09:18 <keesj> panto: some problems are indeed related to the micro architecture e.g. we do way more context swiching for trivial stuff
Aug 12 11:09:46 <panto> tcort, wtf
Aug 12 11:09:52 <panto> you got issues
Aug 12 11:10:06 <keesj> panto: but I want to "define" dead slow in numbers
Aug 12 11:10:49 <panto> run this on both minix & linux
Aug 12 11:10:57 <panto> time ./hello
Aug 12 11:11:17 <keesj> mmc == slow , exec == slow
Aug 12 11:11:22 <panto> that will tell us if the problem is I/O or not
Aug 12 11:11:33 <panto> can you root nf?
Aug 12 11:11:34 <panto> *nfs
Aug 12 11:12:13 <keesj> any help is welcome but it is not trivial figuring out where it is slow
Aug 12 11:12:47 <keesj> we can boot using tftp and a ramdisk or create a ramdisk and copy the content but can not nfs mount root
Aug 12 11:13:14 <panto> ok, try ramdisk booting
Aug 12 11:13:27 <panto> sounds like you got serious I/O problems
Aug 12 11:16:57 <keesj> also dd of /dev/null to /dev/null is not that fast either (I need to boot up my board) / setup my stuff again
Aug 12 11:17:09 <keesj> but it is fun work!
Aug 12 11:48:27 <keesj> it is not so much I/O related but something else. I mean it's not the amount of I/O that matters but the amount of call/context switches. I did a simple test using dd and different block sizes and counts. http://pastebin.com/Th4T07PS and a second (transfering 10 MB using different block size)
Aug 12 11:53:05 <keesj> needless to say it takes zero time on linux http://pastebin.com/urMSFKV3
Aug 12 11:56:38 <panto> you need to profile
Aug 12 11:56:51 <panto> does minix has anything like oprofile or perf?
Aug 12 12:12:23 <keesj> I did some hacking around using the arm performance counters a few month ago
Aug 12 12:12:47 <keesj> I wonder it using the embedded trace (en openocd or ccs) is a fast solution
Aug 12 12:13:33 <keesj> Also I wonder how to train qemu to do this
Aug 12 12:13:56 <keesj> documentation around profiling and qemu is .. not that great
Aug 12 12:18:48 <keesj> (and perormance counters are not implemented in the armv7 emulator in qemu)
Aug 12 12:19:21 <panto> nah
Aug 12 12:19:26 <panto> use a real arm
Aug 12 14:15:32 <hatguy> panto: what's the best way to find dynamically assigned "adapter number" for an i2c bus, given the address; from C code preferably
Aug 12 14:34:22 <keesj> system tracing using CCS is no longer completely borken (for me)
Aug 12 14:45:33 <keesj> upon inspection reading the timers is expensive(in terms of cycles)
Aug 12 14:45:58 <keesj> about 116
Aug 12 15:45:29 <panto> back
Aug 12 15:45:51 <panto> hatguy, err, what do you mean?
Aug 12 15:47:04 <hatguy> panto: I had a discussion about this with bradfa... https://www.kernel.org/doc/Documentation/i2c/dev-interface says that the adapter number is assigned dynamically.... so what's the best way to determine it at runtime?
Aug 12 15:48:25 <hatguy> panto: I was thinking along the lines of checking if /sys/devices/ocp.2/4819c000.i2c/i2c-* was a valid path or not
Aug 12 15:50:22 <panto> do you mean making sure that each adapter number is matching the hardware TRM number?
Aug 12 15:50:35 <panto> so that I2C0 -> i2c-0 etc?
Aug 12 15:50:50 <panto> or that the clients are assigned numbers that you control?
Aug 12 15:52:17 <hatguy> panto: I don't think that if they match or not matters at all... I just want to be sure that I'm controlling the right device.. so I guess the latter
Aug 12 15:55:34 <panto> the i2c-* directory is always valid in /sys/devices/ocp.2/*.i2c/
Aug 12 15:56:26 <panto> it is dynamically assigned but you know the hardware i2c # by that name
Aug 12 15:56:41 <panto> you also have /sys/class/i2c-adapter & /sys/class/i2c-dev
Aug 12 15:58:06 <hatguy> panto: does your second message mean that the hardware i2c# match the linux ones?
Aug 12 16:05:28 <panto> no
Aug 12 16:05:50 <panto> but that #.i2c is the address of the I2C IP block in the global memory space
Aug 12 16:06:01 <panto> so you can very easily infer
Aug 12 16:07:13 <hatguy> panto: ok, so the #.i2c directory is the most reliable way to find out the i2c # number, is that correct?
Aug 12 16:07:34 <panto> as things stand yes
Aug 12 16:07:47 <panto> there is another way but needs driver hacking
Aug 12 16:08:16 <panto> go with mapping the #.i2c names to hardware I2C blocks
Aug 12 16:08:43 <hatguy> panto: ok great
Aug 12 16:09:05 * hatguy just needs to figure out the C code to do this
Aug 12 16:10:52 <ka6sox> panto, is there anything preventing us (other than having to do the sysfs incantation dance) from implementing status/control sysfs entries for the JTAG vring/remoteproc driver?
Aug 12 16:18:40 <panto> ka6sox, no
Aug 12 16:19:32 <panto> but by it's nature sysfs is not a very high speed interface
Aug 12 16:19:58 <panto> it's perfectly acceptable for starting up, but we will need a device I/O interface
Aug 12 16:19:58 <ka6sox> this is just for things like start/stop running/not
Aug 12 16:20:04 <panto> that's fine
Aug 12 16:20:25 <panto> but if you have a device I/O interface it costs nothing to add some ioctls
Aug 12 16:20:42 <ka6sox> polling sucks
Aug 12 16:20:54 <panto> who said anything about polling?
Aug 12 16:21:04 <panto> it's a filedescriptor
Aug 12 16:21:07 <ka6sox> nobody...I just had to throw that in.
Aug 12 16:21:18 <panto> you can make sure select, poll works sanely
Aug 12 16:21:20 <panto> hehe :)
Aug 12 16:21:27 <ka6sox> true
Aug 12 16:21:46 <ka6sox> remember I'm old school...we have status bits mostly
Aug 12 16:21:56 <ka6sox> not 32bit registers.
Aug 12 16:22:06 <ka6sox> and file descriptors.
Aug 12 16:23:06 <panto> heh
Aug 12 18:42:15 <koen> panto: can we add some kind of aliases in the DT to for i2c3 to be called i2c3 in linux?
Aug 12 18:42:37 <panto> koen, it's complicated :(
Aug 12 18:42:53 <panto> I have a patch that puts the devices in order
Aug 12 18:43:03 <panto> but it's in of/device core
Aug 12 18:43:12 <panto> and you know how well things go there
Aug 12 18:43:22 <panto> even bug fixes get everyone's panties in a bunch
Aug 12 18:44:11 <koen> as long as pantos don't get in a bunch :)
Aug 12 18:45:02 <gregkh> panto: hey, I take device core patches all the time, and my panties are just fine :)
Aug 12 18:45:08 <panto> I only use beagleborad approved panties
Aug 12 18:45:21 <panto> gregkh, ah, it lives! :)
Aug 12 18:45:45 <panto> let's just say that pointing faults in other people's code never goes down easily
Aug 12 18:46:06 <gregkh> panto: that's what kernel development is all about, that's why we do it, so that others can fix the bugs we add :)
Aug 12 18:46:15 <panto> hehe
Aug 12 18:46:23 <panto> are you making elce13?
Aug 12 18:47:35 <gregkh> panto: elce13?
Aug 12 18:48:37 <panto> embedded linux conference europe 2013
Aug 12 18:49:55 <Russ> I'm pretty sure its elce7 (7th elce conference)
Aug 12 18:50:31 <gregkh> panto: ah, yeah, I'll be there, it's part of linuxcon 2013, right?  and the kernel summit, and probably 5 other conferences at the same time/place...
Aug 12 18:50:37 <panto> yes
Aug 12 18:50:51 <panto> kernel summit is at the same time (about)?
Aug 12 18:50:58 <Russ> 23rd-25th
Aug 12 18:51:03 <gregkh> panto: yes, the days before/after, can't remember which.
Aug 12 18:51:14 * gregkh travel schedule is crazy for the next few months
Aug 12 18:51:25 <panto> invite only
Aug 12 18:51:49 <panto> can't seem to be with the cool folks then
Aug 12 18:51:58 <gregkh> panto: yes, invite only, but you have to nominate yourself to go (you invite yourself) and then the people are picked from there.
Aug 12 18:52:33 <gregkh> panto: there are still some open slots for "hobbyists" that don't get paid to do kernel development.
Aug 12 18:52:39 <Russ> I think the other conference is cloud something
Aug 12 18:52:48 <gregkh> panto: the call for those applications hasn't gone out yet, but will in a few days
Aug 12 18:53:22 <panto> I'm not sure I fit the hobbyists monicker
Aug 12 18:55:14 <panto> elce is oct 24-25
Aug 12 18:55:48 <panto> I guess we can hang out someplace
Aug 12 19:07:11 <mdp> panto, you should swing over to connect .us when you're done there
Aug 12 19:13:05 <mluckham> ka6sox, ping
Aug 12 19:16:10 <mluckham> panto, ping
Aug 12 19:18:27 <panto> mluckham, pong
Aug 12 19:18:49 <mluckham> hi panto
Aug 12 19:18:55 <panto> hi
Aug 12 19:19:09 <mluckham> I've been looking at OpenOCD drivers - looking for a simple one, to start with
Aug 12 19:19:13 <panto> mdp, err, since I'm paying out of pocket it's not going to happen
Aug 12 19:19:57 <panto> contrary to what the rumors say I'm not an independently wealthy playboy/kernel-developer/philanthropist
Aug 12 19:20:17 <koen> no, you club baby seals
Aug 12 19:20:23 <mluckham> looking at http://openocd.sourceforge.net/doc/doxygen/html/interface_8h.html
Aug 12 19:20:50 <mdp> panto, could have fooled me
Aug 12 19:20:52 <panto> koen, it's a weakness of mine
Aug 12 19:21:12 <panto> who can resist bashing their cute faces in?
Aug 12 19:21:27 <mluckham> the most trivial is bitbang.c
Aug 12 19:21:43 <koen> but with the shiny pate and the audi, mistaking you for a playboy is easy
Aug 12 19:21:52 <koen> not to mention that foreign accent chicks dig
Aug 12 19:22:09 <panto> da
Aug 12 19:22:26 <panto> lets ask ze wife
Aug 12 19:22:57 * mdp tries to decode the "foreign accent" comment from koen's perspective
Aug 12 19:22:58 <mdp> ;)
Aug 12 19:24:02 <koen> californian and hawaiian people say I have a texas accent
Aug 12 19:24:15 <koen> texas people don't really speak to me after I mention my fondness for umbrella drinks
Aug 12 19:24:40 <panto> the weirdest case of wtf english accent was that .de eurovision song a couple years back
Aug 12 19:25:07 <panto> http://www.youtube.com/watch?v=8QSgNM9yNjo
Aug 12 19:25:51 <koen> that's indeed weird
Aug 12 19:26:11 <koen> that reminds me, need to further my research on mlocke's accent
Aug 12 19:27:12 <mdp> koen, unpossible to trace...military kid that moved about
Aug 12 19:27:53 <koen> not unpossible
Aug 12 19:27:56 <koen> we have prism
Aug 12 19:28:21 <mdp> mlocke has "nothing to hide" :P
Aug 12 19:28:28 <panto> prism, where locate mlocke's accent on the map...
Aug 12 19:28:42 <panto> s/where/
Aug 12 19:28:44 <panto> s/where//
Aug 12 19:28:45 <panto> bah
Aug 12 19:28:47 <panto> can't type
Aug 12 19:29:28 <panto> mluckham, http://sourceforge.net/p/openocd/code/ci/master/tree/src/jtag/drivers/amt_jtagaccel.c
Aug 12 19:30:12 <mluckham> that looks interesting
Aug 12 19:30:35 <mluckham> although the bitbang approach could be useful at first
Aug 12 19:30:41 <panto> yes
Aug 12 19:30:52 <panto> you can try a two pronged approach
Aug 12 19:31:08 <panto> first, get open ocd running with a simple bitbanged (or sysfs gpio)
Aug 12 19:31:38 <panto> http://sourceforge.net/p/openocd/code/ci/master/tree/src/jtag/drivers/OpenULINK/README
Aug 12 19:31:51 <panto> the above is something like our stuff
Aug 12 19:31:54 <mluckham> i guess gpio would get me familiar with how to use openocd targeting the launchpad
Aug 12 19:32:03 <panto> right
Aug 12 19:32:14 <panto> I don't even care about launchpad atm
Aug 12 19:32:21 <panto> just get it running
Aug 12 19:32:30 <mluckham> no, but I need something to see results
Aug 12 19:32:41 <panto> gdb not good enough?
Aug 12 19:32:57 <mluckham> no prob, I can use gpio to see pin states changing on the logic analyzer
Aug 12 19:33:17 <mluckham> then shift same functionality to pru
Aug 12 19:33:20 <panto> I don't want you to get bogged down in fixing problems that are not part of the project
Aug 12 19:33:51 <mluckham> the thing is, lacking an interface definition for the code I need to learn enough about how to use OpenOCD to create something sane
Aug 12 19:33:57 <panto> btw, it looks like that even the hardware accelerated jtag interfaces ain't too fast
Aug 12 19:34:08 <panto> go with the bitbang/sysfs stuff first
Aug 12 19:34:21 <panto> "Maximum achievable TCK frequency is 182 kHz for ULINK clocked at 24 MHz."
Aug 12 19:34:38 <mluckham> for speed we'll need to come up with an efficient arm-pru protocol
Aug 12 19:34:49 <panto> http://sourceforge.net/p/openocd/code/ci/master/tree/src/jtag/drivers/OpenULINK/src/jtag.c
Aug 12 19:35:39 <mluckham> yeah, like that
Aug 12 19:36:34 <mluckham> i had been looking at openjtag http://openocd.sourceforge.net/doc/doxygen/html/openjtag_8c.html
Aug 12 19:38:22 <mluckham> so:  gpio bitbang -> pru bitbang -> pru+cpld bitbang -> then revisit?
Aug 12 19:38:41 <mluckham> or leave out pru+cpld, if there's no board available yet
Aug 12 19:41:04 <panto> pru bitbang is not going to be 'call pru to toggle pin'
Aug 12 19:41:38 <mluckham> until I know more about jtag, that's all it could be
Aug 12 19:41:48 <panto> start learning :)
Aug 12 19:42:03 <mluckham> somewhere in the middle (?) now :)
Aug 12 19:42:46 <mluckham> well, middle for the project (I think I can code gpio + pru bitbang solutions)
Aug 12 19:42:56 <mluckham> but daa-daa goo-goo for jtag
Aug 12 19:43:38 <mluckham> the actual jtag wire protcol looks simple enough (TMS, TCK, TDI, TDO, TRST, SRST)
Aug 12 19:44:01 <mluckham> OpenOCD does the heavy lifting for knowing WHEN to operate those signals
Aug 12 19:44:02 <panto> yes
Aug 12 19:44:07 <mluckham> and how
Aug 12 19:44:22 <panto> I guess you'll need to understand how the bulk transfer stuff happens
Aug 12 19:44:32 <panto> if you got to accelerate something it's that
Aug 12 19:44:51 <mluckham> right - then the vrings come into play
Aug 12 19:45:09 <panto> right
Aug 12 19:45:18 <panto> get cracking
Aug 12 19:45:21 * panto cracks the whip 
Aug 12 19:45:24 <mluckham> ow!
Aug 12 19:46:37 <mluckham> do you have some idea of the performance for writing 1 byte with downcall/interrupt vs 1 byte to vring - how fast the PRU can react?
Aug 12 19:47:05 <panto> the downcall is probably going to be as fast as the vring
Aug 12 19:47:26 <mluckham> that's what I thought, for that case
Aug 12 19:47:52 <panto> you can even do bulk transfers
Aug 12 19:47:53 <panto> dunno
Aug 12 19:47:59 <panto> it all depends
Aug 12 19:48:08 <panto> this is all brand new stuff
Aug 12 19:48:23 <mluckham> do you mean, downcall bulk transfers?
Aug 12 19:48:39 <panto> the downcall is just an rpc mechanism
Aug 12 19:48:52 <panto> you can just as easily pass the buffer
Aug 12 19:48:56 <mluckham> k
Aug 12 19:49:02 <panto> the PRU code is going to be just as fast
Aug 12 19:49:13 <panto> the only diff is that the linux side will block waiting for the transfer to end
Aug 12 19:49:25 <panto> which could be not what you want
Aug 12 19:49:39 <panto> but again, it depends
Aug 12 19:49:58 <panto> it's much easier to do than vrings
Aug 12 19:50:38 <mluckham> well, i can get started now - will share this with Tom when he appears
Aug 12 19:51:36 <mluckham> and for PRU bitbang, i'll create the signal-level sysfs attribute names, we discussed the other day, and use downcalls
Aug 12 19:51:41 <mluckham> gpio firt though
Aug 12 19:51:45 <mluckham> first
Aug 12 19:52:15 <mluckham> is jj2baile still around?
Aug 12 19:52:28 <mluckham> jj2baile, ping
Aug 12 19:54:56 <mluckham> tx panto
Aug 12 20:00:37 <panto> np
Aug 12 20:33:50 <ds2> oh where oh where has the GSoC students gone
Aug 12 20:37:31 <bradfa> ds2, hopefully they're all busy working :)
Aug 12 20:41:33 <ds2> they are students
Aug 12 20:42:01 <ds2> it seems both students I been helping have not been seen in the last few days
Aug 12 20:42:33 <panto> ds2, the sirens of booze + young summer sex beckon them
Aug 12 20:50:28 <ds2> ah I see
Aug 12 20:51:58 <panto> can you blame them?
**** BEGIN LOGGING AT Mon Aug 12 22:07:56 2013
Aug 13 01:42:21 <mluckham> ka6sox, ping
**** ENDING LOGGING AT Tue Aug 13 02:59:59 2013