**** BEGIN LOGGING AT Thu Jul 18 02:59:58 2013 Jul 18 05:25:44 is there any reason it isn't just based on the mfd-next tree? Jul 18 07:15:19 ZubairLK, in patch 5, tiadc_step_config Jul 18 07:15:26 when comparing against bool, use false, not 0 Jul 18 07:16:42 you might rename the variable to cont_mode or some such to make it more readable Jul 18 07:21:10 also, "TI-am335x-adc" in the topic is a bit weird, I'd go with ti_am335x_adc or ti-am335x-adc Jul 18 07:21:26 those are both really small things though Jul 18 07:22:04 see http://lkml.indiana.edu/hypermail/linux/kernel/1306.1/01106.html for example Jul 18 07:22:31 not that that one is perfect either, the / is uncommon Jul 18 07:23:58 if you look at the actual commit, you can see it got fixed up in mfd-next https://kernel.googlesource.com/pub/scm/linux/kernel/git/sameo/mfd-next/+/9f99928fe Jul 18 07:24:23 be sure to state in your header email (00/21) or whatever, what the patches are based on Jul 18 07:24:48 if it's mfd-next at such and such a commit merged with something, state that, etc Jul 18 07:25:38 and of course remove the "*** BLURB HERE ***" from your cover letter/header email :) Jul 18 07:39:40 moarning Jul 18 07:39:44 hi mluckham Jul 18 07:39:59 (you've pinged me at 4am btw, so no I was not around :) ) Jul 18 09:54:05 Thank-you Russ. I'll look into it. Jul 18 09:54:24 gn Jul 18 11:03:41 can someone help me with some linking errors http://pastebin.com/V4qYVfef Jul 18 11:12:53 -all-static ? Jul 18 11:13:08 and you you have a libc.a or only the .so? Jul 18 11:23:14 mhmh dunno at all Jul 18 11:23:24 i just sources the envoirment for angstrom2012 Jul 18 11:25:02 koen: angstrom-eglibc-x86_64-armv7a-vfp-neon-v2012.12-toolchain.gz this one i'm using. Jul 18 11:25:33 I never use static linking, so I don't know if there's a libc.a Jul 18 11:25:52 mhmh i need to deploy stuff to my custom ramdisk and that is why i need it Jul 18 14:28:30 koen: ping Jul 18 15:10:00 vvu: pong Jul 18 16:30:15 gm Jul 18 16:30:25 anybody here familiar with mainline patches? Jul 18 16:30:37 is there a hard limitation on the length of the subject line.. Jul 18 16:30:38 don't ask to ask :) Jul 18 16:30:58 afaik, you want it to be 76 characters or less, but I'm just guessing Jul 18 16:31:14 hmm. squeezing a title in that is tricky.. Jul 18 16:31:37 especially with iio: ti_am335x_adc: taking up so much space.. Jul 18 16:31:50 Some merge messages can be really long Jul 18 16:32:01 "Merge tag 'driver-core-3.10-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core" Jul 18 16:32:18 "parisc: Use unshadowed index register for flush instructions in flush_dcache_page_asm and flush_icache_page_asm" Jul 18 16:32:33 so its acceptable. *i hope* Jul 18 16:32:44 as long as they mean something.. Jul 18 16:32:44 what is the header anyway? Jul 18 16:33:07 iio: ti_am335x_adc: Fix wrong samples received on 1st read Jul 18 16:33:15 the read goes into the next line in the *.patch file.. Jul 18 16:33:24 manually put it back on the same line. Jul 18 16:33:31 similar stuff with other words too.. Jul 18 16:33:42 that should be fine Jul 18 16:33:47 other patches* Jul 18 16:33:49 don't bother with patch files though, use git send-email Jul 18 16:33:59 70-75 characters for the summary phrase...straight out of SubmittingPatches Jul 18 16:34:04 be sure to do a --dry-run Jul 18 16:34:06 * mdp reads from the good book Jul 18 16:34:08 hmm. I make patch files then use git send-mail Jul 18 16:34:12 mdp, or you know, you could actually read the instructions :p Jul 18 16:34:29 you can do that all in one step Jul 18 16:34:34 i make patch files using format-patch and then send-mail.. Jul 18 16:34:40 i see. Jul 18 16:34:43 i'll look into it. Jul 18 16:34:46 send-email takes format-patch options Jul 18 16:35:00 i send myself a ton of emails n then send it to actual ppl. thats my 'real' dry-run Jul 18 16:38:21 LKML is one of the most Brutal Darwinian places on the planet. Jul 18 16:42:32 survival of the meanest Jul 18 16:44:11 indeed. but you cant be a kernel devel if you cant face this :p Jul 18 18:18:55 jj2baile, ping? Jul 18 19:23:43 ka6sox: pong Jul 18 19:25:21 hiya Jul 18 19:25:26 got time to meet today? Jul 18 19:25:29 :) Jul 18 19:25:40 or are you hard at it and just need to be left alone to work :) Jul 18 19:26:44 I can meet. Jul 18 19:27:32 okay good. Jul 18 19:27:44 let me see if mluckham has time and when. Jul 18 19:27:56 as we need to start interfacing with the app. Jul 18 19:28:03 (and passing data back and forth) Jul 18 19:29:10 mhm Jul 18 19:29:51 simple data passing...not full on stuff. Jul 18 22:28:32 Round 2 of upstreaming the ADC stuff has begun. Jul 18 22:28:46 i hope i wake up to good natured emails :p Jul 18 22:29:22 laptop lying open. irc some comments unsuitable for lists here. i'll check in the morning. :) Jul 18 22:29:35 http://thread.gmane.org/gmane.linux.kernel.iio Jul 18 22:35:01 ZubairLK, fingers crossed...it helps that Russ commented :) Jul 18 23:26:20 ka6sox, I'm here (8pm EDT) Jul 18 23:29:20 okay Jul 18 23:29:32 lets see if jj2baile is around? Jul 18 23:29:36 ok Jul 18 23:29:37 jj2baile, Ping? Jul 18 23:30:10 panto, Ping? Jul 18 23:30:35 i really must ping panto in the AM! Jul 18 23:31:51 mornin Jul 18 23:34:25 jj2baile, if you have a kernel, with vring, and pru stuff already built - any part of those - it would save me some time Jul 18 23:34:40 i have built a stock kernel and u-booted it to the BBB, it runs okay Jul 18 23:34:55 but I haven't been able to add the dtbs to panto's kernel yet Jul 18 23:36:09 Nope, just have the stock kernel at this point Jul 18 23:36:29 Only thing extra I have is a simple dts Jul 18 23:36:42 (that just enabled the required pins for testing purposes) Jul 18 23:37:39 okay so vrings are an issue still? Jul 18 23:38:16 ok - afaik I need to get panto's build, for the vring stuff (not the stock kernel) and he told me to read the drivers to figure out - how to write a test app in C Jul 18 23:39:00 and his pru stuff, I need to get the PRU toolchain to build, and learn how that all works Jul 18 23:39:56 at the rate I can work on this, I'm still a few days away from getting all this working Jul 18 23:40:18 jj2baile, you have working PRU code? Jul 18 23:41:40 ka6sox, I 'assume' there is something wrong with vring in stock kernel, from what panto has said in days past - maybe that's a wrong assumption Jul 18 23:52:05 let me see if I can clarify with him when he is up Jul 18 23:52:29 that would be good Jul 18 23:53:06 I have his kernel built, it's just the dts need to be appended to the uImage Jul 18 23:53:34 but the instructions elinux.org/Building_BBB_Kernel don't work for me, with his kernel Jul 18 23:53:58 I think there is something missing in a Makefile somewhere, but haven't tracked it down Jul 18 23:55:21 jj2baile, how do you add the dts to the stock kernel uImage? Jul 18 23:55:42 mluckham: You load it at runtime with the capemgr interface Jul 18 23:55:56 and yes, I have working Pru code Jul 18 23:56:14 the current test code just does simple jtag stuff like an IDCODE query and the SAMPLE instruction Jul 18 23:56:43 can I get it? Jul 18 23:57:24 mluckham: https://github.com/zecozephyr/PRUJTAG Jul 18 23:57:30 tx Jul 18 23:57:45 the dts is included, but not the invokation required to build it believe Jul 18 23:57:54 Oh thats not true. I put it into the makefile Jul 18 23:58:57 mluckham: So once you build it, and put it into /lib/firmware, just do ` Jul 18 23:59:07 echo cape-jtag-pru > /sys/devices/bone_capemgr.9/slots Jul 18 23:59:49 If you have issues getting the kernel module to load properly (an issue i faced) I also found a fix for that. Jul 19 00:00:40 oh, and one last important thing, you need to add `optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN` to the uEnv.txt of the beagle before using my dts Jul 19 00:01:05 (since the HDMI framer interferes with a lot of stuff, and removing it at run time causes bad things to happen) Jul 19 00:01:05 that's the conflict with pins you had, a few days ago? Jul 19 00:01:10 yes. Jul 19 00:01:50 hm, This is all stuff I should put into a Readme Jul 19 00:02:00 :) Jul 19 00:02:34 after i've been doing a 'writeme' in my notebook ... Jul 19 00:05:06 what about use a non DT kernel? Jul 19 00:10:41 DT? Jul 19 00:12:00 Well, it seems DT is the future, so one will have to get it working with it eventually? Jul 19 00:12:20 mluckham: Device tree, as in the device tree sources and binaries, etc. Jul 19 00:12:32 yah, just figured that out ... Jul 19 00:12:49 depends on who's vision of the future Jul 19 00:12:56 so that's instead of .dts files? Jul 19 00:13:10 dts files are device treees Jul 19 00:13:37 Since what kernel version did beaglebone start using device trees? Jul 19 00:16:18 3.7.X Jul 19 00:16:27 but it wasn't a production kernel Jul 19 00:16:34 production was 3.8 Jul 19 00:16:47 and *only* for the BBB Jul 19 00:27:13 DT is the present Jul 19 00:27:46 DT is a failure. Jul 19 00:29:09 a skeptic Jul 19 00:29:40 when it works well on a small ARM, we shall see Jul 19 00:30:48 ARM is not PPC Jul 19 00:33:31 PPC is not ARM Jul 19 00:36:03 Is it MIPS? Jul 19 00:42:44 jj2baile, can you blog about all this? Jul 19 00:43:01 and the readme is a good idea too...but adding to the blog is very good. Jul 19 00:43:12 jj2baile, I downloaded your stuff and pru_package and built BB-JTAG-PRU-00A0 on the BBB Jul 19 00:43:41 Tartarus: it could be...I seen it on the internet Jul 19 00:45:19 ls Jul 19 00:45:38 ka6sox: Alright. Only thing I havent mentioned is the dts parts of what I did. but ill do a general post about how to navigate what i've done so far. Jul 19 00:46:06 jj2baile, thanks Jul 19 00:46:26 mluckham, are you doing the assembly on the bone or on your dev machine? Jul 19 00:47:57 mluckham: Alright, tell me if you have any issues, or If I forgot anything. Jul 19 00:48:34 no, I was mistaken .. the .dts was already built (do I need to copy that to /lib/firmware?) Jul 19 00:48:50 you said something about cape-jtag-pru ... Jul 19 00:49:02 ka6soc, on the BBB Jul 19 00:50:07 mluckham: move the resulting dtbo to /lib/firmware, which is the default search path for the capemgr Jul 19 00:50:40 then you can just load it as such: echo cape-jtag-pru > /sys/devices/bone_capemgr.9/slots Jul 19 00:53:13 it built Boundary.bin and test.bin, I don't see a .dtb file ... Jul 19 00:55:18 oh sorry, you do 'make dts' in the Boundary directory to get the .dtbo file Jul 19 00:56:39 tx Jul 19 00:57:36 Boundary is the linux executeable and Boundary.bin is the PRU binary Jul 19 00:57:56 you need to execute Boundary while in the bin directory for it to find the pru file. Jul 19 01:00:53 jj2baile, this is all good stuff to go in teh blog/readme Jul 19 01:01:34 ok, .dtbo built - but no /sys/devices/bone-capemgr :( Jul 19 01:01:36 I actually already wrote the README Jul 19 01:01:49 and yes, the blog post will go over the stuff in the README in a less terse manner Jul 19 01:02:07 :) Jul 19 01:02:36 ka6sox, userspace arduino > pru ... fight! Jul 19 01:02:49 mluckham: Well... That's not an error i've come across yet. Jul 19 01:03:03 unsure if typo in IRC or terminal, but it is bone_capemgr ? (i assume irc) Jul 19 01:03:12 * ds2 hands mdp a strike any where match to go with the gasoline Jul 19 01:03:23 +1 Jul 19 01:03:23 don't worry about it - i'll make sure it's the kernel, which I built, that is running on the BBB Jul 19 01:03:44 mdp, no contest Jul 19 01:03:55 US Arduino...DOG SLOW Jul 19 01:04:14 come to think of it, I never really found out why uio_pruss would not work for me. Jul 19 01:04:23 RU Arduino rabbit fast? Jul 19 01:04:24 cat slow Jul 19 01:04:40 and all the script im using seems to be doing is loading and unloading the module quickly until it works. Jul 19 01:04:56 oh and loading a cape Jul 19 01:04:58 ka6sox: next say the realtime means fast ... please :) Jul 19 01:05:34 real time means BLAZING FAST Jul 19 01:06:01 the blaze is fast? Jul 19 01:06:23 however...arduino is a ROCKET compared to JavaScript Jul 19 01:06:25 blazing saddles fast Jul 19 01:06:58 :) Jul 19 01:15:50 tx jj2baile, i'll play with the PRU stuff tomorrow Jul 19 01:24:02 the BBB has bone_capemgr.8, when I do the echo it complains about the BONELT-HDMI conflict, so I am making progress of a sort Jul 19 01:24:38 jj2baile, do you still have the uEnv.txt mod in? Jul 19 01:27:23 ka6sox: yes. I guess i could have chosen different pins for the program, but it seems in the end it will need to be gone anyway Jul 19 01:29:58 right, I think thats why mluckham is having this issue Jul 19 01:30:08 unless I'm missing something Jul 19 01:31:53 booting from the eMMC kernel, bone_capemgr.9 is there Jul 19 01:32:10 is it /boot/uEnv.txt to be edited? It doesn't seem to be removing the conflict Jul 19 01:32:55 if its HDMI then disabling the HDMI should allow you to boot this up Jul 19 01:33:04 going too fast - I left off part of the optargs :( Jul 19 01:40:41 I am adding to /boot/uEnv.txt a new line `optargs=quiet capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN` then shutdown -r now Jul 19 01:41:04 on restart, dmesg still complains about some conflict with BONELT-HDMI Jul 19 01:43:42 maybe it has always done that, I seem to recall ... nothing to do with this PRUJTAG stuff? Jul 19 01:44:42 yah, it's a red herring (at least in part) https://groups.google.com/forum/#!msg/beagleboard/Fx2NRvqUpl8/mbzx-tZyz2sJ Jul 19 01:45:06 enuf for today - tomorrow I will explore whether I'm updating the correct uEnv.txt file Jul 19 01:46:02 zz Jul 19 01:56:25 nite mluckham-zz **** ENDING LOGGING AT Fri Jul 19 02:59:58 2013