**** BEGIN LOGGING AT Sat Dec 17 03:00:00 2016
Dec 17 03:07:19 <jaydoobie> Is there a guide to understand how to enable the PRU and configure a DTO for the 4.4.30-ti-r64 kernel?  I had a program working on 3.8, but am working to upgrade to a BBB wireless, and was wanting to use a more recent kernel.
Dec 17 03:40:24 <zmatt> jaydoobie: I think uio_pruss can be enabled by an overlay, lemme quickly see if I spot something
Dec 17 03:41:14 <zmatt> or just install a bone kernel (e.g. 4.4.39-bone15 )
Dec 17 03:46:37 <zmatt> or 4.9-bone3
Dec 17 03:46:42 <zmatt> if you like shiny new
Dec 17 03:54:55 <jaydoobie> Will those kernel's perform better?  :)  I don't mind upgrading, but I'd like something that works well.  I'm almost tempted to move back to the 3.8.* kernel I was using before
Dec 17 03:55:50 <zmatt> 3.8 is really ancient and a dead end
Dec 17 03:56:43 <zmatt> as for performance, that's a rather broad and vague subject :)  but fortunately you can just apt-get install a kernel and see if it lives up to your expectations
Dec 17 04:06:51 <jaydoobie> yeah, I know 3.8 is ancient, but it at least worked, minus a few workarounds I needed in my code
Dec 17 04:09:26 <zmatt> I use 4.8 (probably 4.9 soon)
Dec 17 04:10:23 <jaydoobie> Is there a way to turn on debug for the bone_capemgr in any of the kernels?
Dec 17 04:12:00 <zmatt> I don't use capemgr myself, but overlays in general have pretty awful diagnostics (which is one reason I avoid them)
Dec 17 04:12:29 <zmatt> maybe there's dyndbg messages that can be enabled, I could check
Dec 17 04:14:21 <zmatt> I'm assuming you're asking this to debug an overlay right?
Dec 17 04:20:40 <jaydoobie> I have two issues, 1 is that I cannot seem to enable the PRUs, and second I cannot configure the pinmux so that my PRU could could access the correct pins
Dec 17 04:21:09 <zmatt> have you switched to a -bone kernel yet?
Dec 17 04:21:35 <jaydoobie> I'm on a ti kernel
Dec 17 04:21:52 <jaydoobie> 4.4.30-ti-r64, from the latest image (12-6)
Dec 17 04:23:29 <zmatt> I *think* an overlay might be able to get uio_pruss to work on those kernels but it would definitely be more involved
Dec 17 04:23:40 <zmatt> hence my suggestion to install a -bone kernel instead
Dec 17 04:25:39 <zmatt> it's a bit of a long story... basically TI decided to ditch uio_pruss in favor of a new way to work with PRUSS (using remoteproc).  it was not well received, and somehow this ended up with the current 4.4-ti kernels having neither of them enabled out of the box
Dec 17 04:25:50 <zmatt> I don't really understand it myself either :P
Dec 17 04:26:05 <zmatt> but the -bone kernels have remained loyal to uio_pruss
Dec 17 04:26:26 <jaydoobie> ok, what is the best way for me to get back to a -bone kernel?
Dec 17 04:27:02 <zmatt> if I saw correctly it looked like the latest -ti kernel also uses it again, so this issue may be in progress of being resolved.  but I'm not sure why a -ti kernel is default anyway
Dec 17 04:27:19 <zmatt> sudo apt-get update    (you only need to do this once every now and then to get new package lists)
Dec 17 04:27:42 <zmatt> sudo apt-get install linux-image-4.4.39-bone15
Dec 17 04:27:48 <jaydoobie> yup, did that just the other day
Dec 17 04:28:29 <zmatt> substitute whatever version you want... e.g. linux-image-4.9-bone3 if you're feeling adventurous :)
Dec 17 04:28:58 <jaydoobie> I think I'll stick to 4.4.39 for now :)
Dec 17 04:29:24 <jaydoobie> I must be missing a source, cannot find the images in apt-get
Dec 17 04:29:51 <zmatt> uhh, the source should definitely be there of course
Dec 17 04:30:14 <zmatt> ah, you might need to do apt-get update again
Dec 17 04:30:21 <jaydoobie> I think apt has been fubared.
Dec 17 04:30:30 <jaydoobie> I just did it again after it failed the first time
Dec 17 04:30:47 <zmatt> it was released only 7 hours ago
Dec 17 04:31:01 <zmatt> so a package listing from "the other day" wouldn't have it yet
Dec 17 04:31:06 <jaydoobie> I don't even see a 4.4.30*bone*
Dec 17 04:31:21 <zmatt> uhh huh what
Dec 17 04:31:28 <jaydoobie> yeah tell me
Dec 17 04:31:33 <zmatt> how are you checking?
Dec 17 04:32:08 <jaydoobie> apt-cache search bone
Dec 17 04:32:12 <jaydoobie> apt-cache search linux-image
Dec 17 04:33:08 <zmatt> uhhh
Dec 17 04:33:28 <zmatt> any errors from apt-get update ?
Dec 17 04:33:32 <jaydoobie> ahhh it's bone14 not 15
Dec 17 04:33:55 <jaydoobie> found it.  Been dealing with this thing for way too long :)
Dec 17 04:33:59 <zmatt> like I just said bone15 was released 7 hours ago
Dec 17 04:34:09 <jaydoobie> ah
Dec 17 04:34:16 <zmatt> that ought to be enough time to hit the repositories I'd think
Dec 17 04:34:17 <jaydoobie> apt-update just now didn't have any failures
Dec 17 04:34:27 <jaydoobie> still I'll go to 14 and see how it goes
Dec 17 04:34:32 <jaydoobie> and update to 15 tomorrow if need be
Dec 17 04:35:29 <zmatt> you can track which kernels have been recently released by rcn-ee here for example -> https://github.com/RobertCNelson/linux-stable-rcn-ee/releases
Dec 17 04:36:51 <jaydoobie> very cool.  Will bookmark that.  rt=real time?
Dec 17 04:37:05 <zmatt> yeah those are kernels with the rt patches
Dec 17 04:38:21 <jaydoobie> My call to prussdrv_open(PRU_EVTOUT_0)  still fails after the upgrade
Dec 17 04:38:57 <jaydoobie> but I do see something I screwed up to see if it would ignore the error or not, so one more fix
Dec 17 04:39:04 <zmatt> does it normally automatically load the overlay for pruss?
Dec 17 04:39:13 <zmatt> also make sure cape-universal is disabled (see http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration )
Dec 17 04:41:20 <jaydoobie> I guess I'm not 100% sure how it was loaded in my 3.8 kernel...it just all happened to work with the DTS I created
Dec 17 04:41:54 <jaydoobie> I hope this isn't because I'm using a BBB-wireless.
Dec 17 04:42:19 <zmatt> dts you created?
Dec 17 04:42:34 <jaydoobie> Yes
Dec 17 04:42:46 <jaydoobie> for my "cape"
Dec 17 04:43:02 <zmatt> can you pastebin it?
Dec 17 04:43:15 <zmatt> and I'm assuming you checked kernel log for errors?
Dec 17 04:43:24 <jaydoobie> I'm using RCN's dtb-rebuilder for the main dtb (with the uio_pruss enabled)
Dec 17 04:43:41 <zmatt> ohhh that's a detail you could have mentioned earlier :P
Dec 17 04:43:56 <zmatt> since then it shouldn't matter which kernel you use
Dec 17 04:43:57 <jaydoobie> let me confirm my git hub version is in sync
Dec 17 04:44:01 <jaydoobie> ooh
Dec 17 04:44:04 <jaydoobie> :( sorry
Dec 17 04:44:22 <jaydoobie> https://github.com/doobie42/OpenPegasus/blob/master/dto/openpegasus-00A0.dtsi
Dec 17 04:44:45 <zmatt> -ti kernels support both uio-pruss and the remoteproc thing, it's just the DT that current fails to enable either
Dec 17 04:45:33 <jaydoobie> would be nice if all of this were documented somewhere :)
Dec 17 04:46:35 <zmatt> it would be nice if there were some very basic examples of how to get common things to work, and preferably automated unit-tests to ensure that those instructions don't silently break without being noticed
Dec 17 04:47:09 <zmatt> so what happens, does your overlay get loaded? are there errors? does the uio device show up?
Dec 17 04:47:49 <jaydoobie> it appears to get loaded happily.
Dec 17 04:47:51 <jaydoobie> no errors
Dec 17 04:47:53 <jaydoobie> doesn't show up
Dec 17 04:48:05 <jaydoobie> 99c pinmux are not what I want
Dec 17 04:48:07 <zmatt> overlay shows in slots?
Dec 17 04:48:24 <jaydoobie> Yes
Dec 17 04:48:46 <jaydoobie> 4: P-O-L   0  Override Board Name,00A0,Override Manuf,openpegasus
Dec 17 04:49:20 <jaydoobie> 990, 994, 99c are 0x27
Dec 17 04:49:22 <zmatt> I mentioned how wonderful the diagnostics of overlays are right?
Dec 17 04:49:51 <zmatt> you might want to check out my 'show-pins' utility -> https://github.com/mvduin/bbb-pin-utils
Dec 17 04:50:17 <zmatt> I personally prefer it to manually parsing hex values ;)
Dec 17 04:50:18 <jaydoobie> Yeah, it shows them, but it isn't correct.
Dec 17 04:50:35 <jaydoobie> 0x27 isn't my 0x15 ;)
Dec 17 04:51:06 <jaydoobie> The only think I can think of is I'm using am335x-boneblack-wireless-emmc-overlay.dt*
Dec 17 04:51:35 <jaydoobie> I used that because I thought I read somewhere I needed it ecause the am335x-boneblack-wireless.dt* has HDMI enabled and would break me
Dec 17 04:51:36 <zmatt> wait, that's right you're using a custom main dt, why are you then *also* using an overlay?
Dec 17 04:51:47 <jaydoobie> but I have tired both
Dec 17 04:52:05 <jaydoobie> well my overlay is mainly because I used it before... I tried putting into the custom main one...without success
Dec 17 04:52:12 <zmatt> also you said you enabled pruss in your main dt
Dec 17 04:52:37 <jaydoobie> I uncommented the am33xx-pruss-uio.dtsi
Dec 17 04:55:07 <zmatt> ah, and that sets status="okay"
Dec 17 04:55:31 <zmatt> which means that setting status="okay" again in an overlay has no effect
Dec 17 04:55:49 <zmatt> and you're too late to attach pinmux to it, it already scanned for that
Dec 17 04:55:56 <jaydoobie> ah
Dec 17 04:56:08 <jaydoobie> I'm moving my overlay back to the main one
Dec 17 04:56:09 <zmatt> probably they're assuming you'll just config the pins with cape-universal instead
Dec 17 04:56:39 <zmatt> yeah I do everything in the main dt
Dec 17 04:56:41 <jaydoobie> I don't care how I enable things so long as I can get the PRU's up and setup the pins the way I want them ;)
Dec 17 04:57:03 <zmatt> attaching pinmux to the pruss node in the main DT should work fine
Dec 17 04:57:36 <zmatt> but, the uio device didn't show up?
Dec 17 04:57:50 <zmatt> because it obviously should have
Dec 17 04:58:06 <jaydoobie> Nope it doesn't.
Dec 17 04:58:13 <jaydoobie> well uio does
Dec 17 04:58:16 <jaydoobie> uio_pruss does not
Dec 17 04:58:44 <zmatt> what do you mean?
Dec 17 04:58:55 <zmatt> what other uio devices do you have?
Dec 17 05:00:17 <jaydoobie> uio_pdrv_genirq
Dec 17 05:00:25 <jaydoobie> and uio show up in lsomod
Dec 17 05:00:29 <jaydoobie> *lsmod
Dec 17 05:00:50 <zmatt> driver != device
Dec 17 05:01:02 <jaydoobie> ah, where should I look then?
Dec 17 05:01:13 <zmatt> ls /dev/uio*
Dec 17 05:01:32 <jaydoobie> Nothing found
Dec 17 05:01:44 <zmatt> ok, this is odd
Dec 17 05:02:40 <zmatt> you sure you got no errors in kernel log?
Dec 17 05:02:57 <zmatt> you can show just messages of priority "notice" and above with:
Dec 17 05:03:01 <zmatt> journalctl -k -b-0 -p notice
Dec 17 05:03:08 <zmatt> (-b-0 means since last boot)
Dec 17 05:03:43 <jaydoobie> omap_voltage_late_init: Voltage driver support not added
Dec 17 05:03:51 <jaydoobie> no cape found for slot0-3
Dec 17 05:04:11 <jaydoobie> omap-sham 531000000000.sham: initialization failed
Dec 17 05:04:40 <zmatt> so far nothing exciting, though if there's more maybe use pastebin or such
Dec 17 05:04:55 <jaydoobie> that is all that looked like an error (and was in red)
Dec 17 05:06:31 <zmatt> btw the pin numbers listed in your overlay don't conflict with eMMC or HDMI
Dec 17 05:06:47 <zmatt> only HDMI-audio I guess
Dec 17 05:10:44 <jaydoobie> ok, that was what  it was...the HDMI audio,I don't care about audio anyway
Dec 17 05:11:26 <jaydoobie> if I update he uEnv.txt file do I need to rebuild the initramfs?
Dec 17 05:11:48 <jaydoobie> er initrd
Dec 17 05:12:09 <zmatt> no
Dec 17 05:12:35 <zmatt> uEnv.txt is actually needed to locate initramfs in the first place
Dec 17 05:13:04 <zmatt> ok I'll just quickly see what happens if I install kernel 4.4.39-bone15 and load your overlay
Dec 17 05:17:51 <jaydoobie> I wonder if I have something in the main DT that isn't in the overlay, but I know on my old BBB with kernel3.8 if I didn't echo my overlay my device wouldn't work
Dec 17 05:18:32 <zmatt> try normal dt + overlay?
Dec 17 05:19:26 <jaydoobie> that didn't work out of the box when I started with the 4.4.30 kernel
Dec 17 05:19:44 <zmatt> but that with a ti kernel
Dec 17 05:19:47 <zmatt> *that was
Dec 17 05:19:59 <zmatt> it should work on the -bone kernel
Dec 17 05:21:39 <jaydoobie> ok, will try...slow process to update the initrd image
Dec 17 05:23:03 <zmatt> uh, you don't need to update the initramfs image (you named it correctly earlier) for a DT change
Dec 17 05:23:23 <jaydoobie> Yes, but you said the normal DT, I had a hacked up version, so I reverted it
Dec 17 05:23:47 <zmatt> tip: give hacked up versions a different name and keep the originals :P
Dec 17 05:24:01 <jaydoobie> that works...in the future :)
Dec 17 05:24:42 <jaydoobie> something in the new kernel also has a delay efore it boots.  I'll need to find my dongle so I can see the console
Dec 17 05:25:05 <zmatt> btw your overlay's hex values don't seem to match the comments
Dec 17 05:25:19 <zmatt> 0x030 is the offset for P8_12, not P8_17
Dec 17 05:26:05 <zmatt> P8_17 isn't even a pru pin
Dec 17 05:26:30 <jaydoobie> I think it is a typo
Dec 17 05:26:35 <jaydoobie> should be 8_12
Dec 17 05:26:49 <jaydoobie> I believe; I would need to find my reverse engineering document
Dec 17 05:27:24 <jaydoobie> yeah 8_12, 8_17 is something else not needed in the PRU
Dec 17 05:27:47 <jaydoobie> didn't work with th stock DT
Dec 17 05:28:56 <jaydoobie> one thing I am seeing is the normal DT I moved to uses some of my pins
Dec 17 05:29:22 <zmatt> yeah you do need the "emmc overlay" variant
Dec 17 05:30:43 <zmatt> interesting, I also hit an error the first time I did apt-get update on this bbb (haven't used this one in a while)
Dec 17 05:30:48 <zmatt> E: Could not open file /var/lib/apt/lists/httpredir.debian.org_debian_dists_stretch_main_binary-armhf_Packages.diff_Index - open (2: No such file or directory)
Dec 17 05:31:27 <zmatt> oh well, it seems to work fine
Dec 17 05:33:54 <jaydoobie> lucky ;)
Dec 17 05:35:29 <jaydoobie> I wonder if my issue is that the wireless has a conflict too
Dec 17 05:36:19 <zmatt> wait, is it a bbb wireless or a bbg wireless?
Dec 17 05:36:54 <jaydoobie> bbb wireless
Dec 17 05:37:37 <jaydoobie> I thought I started that in my first message
Dec 17 05:37:48 <zmatt> I didn't think it claimed any extra expansion header pins?
Dec 17 05:40:04 <jaydoobie> I don't know, but I'm about to say I'll stick with my old BBB and throw a usb wireless stick in it and use these somewhere else.
Dec 17 05:41:30 <diycookies> hi
Dec 17 05:44:38 <zmatt> jaydoobie: ok, let's see what I get on this kernel...
Dec 17 05:44:47 <jaydoobie> How do you compile the DTS into the DTO?  Could I be doing something wrong?
Dec 17 05:45:40 <jaydoobie> dtc -O dtb -I dts -o /lib/firmware/openpegasus-00A0.dtbo -b 0 -@ openpegasus-00A0.dtsi
Dec 17 05:45:54 <jaydoobie> does that seem valid?
Dec 17 05:45:58 <zmatt> yeah
Dec 17 05:46:28 <zmatt> ok interesting, this kernel doesn't even boot for me
Dec 17 05:47:03 <jaydoobie> uh oh, glad I didn't go to bone15 then...
Dec 17 05:47:10 <zmatt> bone14
Dec 17 05:47:15 <jaydoobie> oh
Dec 17 05:47:19 <jaydoobie> bone14 worked for me
Dec 17 05:47:50 <jaydoobie> I think I'm out of energy to deal with this for tonight.  Thank you so much for you help zmatt, I understand this a bit more even if it doesn't work
Dec 17 05:48:07 <zmatt> maybe my overall setup is somehow no longer compatible with this relatively old kernel
Dec 17 05:48:16 <zmatt> though not sure why then
Dec 17 05:48:57 <zmatt> ah
Dec 17 05:49:21 <zmatt> rcn hasn't backported my patch for stable mmc numbering to these kernels
Dec 17 05:49:50 <zmatt> so this still requires an initramfs, which I don't have
Dec 17 05:49:57 <jaydoobie> ahh
Dec 17 05:50:48 <jaydoobie> Tomorrow I power up my old BBB (nonwireless) I was using and grab the main DT I was using off it and see if I can find something missing.
Dec 17 05:51:24 <jaydoobie> I set this up a year ago and probably spent just as much time trying to get it work with a 4.1 kernel until everyone told me to move back to a 3.8 kernel
Dec 17 05:51:41 <zmatt> btw do keep in mind DTs are somewhat different between kernel versions
Dec 17 05:51:52 <zmatt> they're usually reasonably compatible though
Dec 17 05:52:09 <zmatt> I'd actually suggest moving forward
Dec 17 05:52:11 <jaydoobie> yup, ut I should be able to decode it on that one, copy the source over and recompile it
Dec 17 05:53:54 <zmatt> I'll just give it one more try
Dec 17 05:54:05 <zmatt> but with a bit more recent -bone kernel
Dec 17 05:54:26 <zmatt> (I normally run custom-built kernels with custom DT)
Dec 17 05:54:29 <jaydoobie> maybe I'll also update my old BBB to a new kernel and see if it works
Dec 17 05:54:49 <jaydoobie> I just don't want to "ruin" it
Dec 17 05:55:00 <zmatt> make a backup first?
Dec 17 05:55:38 <jaydoobie> Yeah, I could do that.
Dec 17 05:56:47 <zmatt> I have a setup for doing so via USB, quite convenient (boots the bbb into a mass storage gadget mode so it shows up like a usb drive)
Dec 17 05:59:16 <jaydoobie> ahh is that a "linux" feature or a BBB feature/
Dec 17 05:59:58 <jaydoobie> I'll probably look to see about making an image and putting it onto an sd card
Dec 17 06:00:33 <zmatt> I based on the "BBBlfs" utility which someone wrote
Dec 17 06:00:36 <jaydoobie> My last experiment didn't work so I think I'm going to head off to bed and start up on this tomorrow or whenever
Dec 17 06:00:44 <zmatt> that particular implementation is quite crappy, but the concept is nice
Dec 17 06:00:52 <zmatt> http://pastebin.com/x5QzB18E   some notes I wrote on it
Dec 17 06:01:45 <jaydoobie> Thanks.  have a good one
Dec 17 06:01:48 <zmatt> new kernel package finally installed
Dec 17 06:02:16 <zmatt> let's hope this one does boot
Dec 17 06:02:23 <zmatt> oh he left
Dec 17 06:05:33 <zmatt> hmm, the overlay works, but no driver gets loaded
Dec 17 06:12:18 <zmatt> kernel module failed to load due to relocation out of range... it's getting more fun by the minute
Dec 17 10:58:25 <maddy> hi friends
Dec 17 10:58:58 <maddy> have a doubt regarding kernel load address for bbb
Dec 17 10:59:17 <maddy> can anybody help me out
Dec 17 11:03:57 <maddy> anybody is online
Dec 17 11:07:12 <maddy> hello
Dec 17 11:17:22 <zmatt> maddy: kernel load address?
Dec 17 11:17:43 <zmatt> that's a rather obscure detail to be concerned about
Dec 17 15:51:36 <maddy> Hi Friends
Dec 17 15:58:37 <maddy> anybody online
Dec 17 16:03:29 <vagrantc> yup
Dec 17 16:04:44 <madhu> hi
Dec 17 16:05:14 * vagrantc waves
Dec 17 16:05:35 <vagrantc> if you've got a question, go ahead and ask and wait patiently for a response
Dec 17 16:06:33 <madhu> what is the kernel loadaddress for the bbb
Dec 17 16:08:21 <vagrantc> if you're at the u-boot prompt, it should be populated in the $kernel_addr_r variable
Dec 17 16:14:14 <madhu> I have the uboot log, I can rdload=0x81000000 and kloadaddr=0x800080000
Dec 17 16:14:22 <madhu> which is the kernel address
Dec 17 16:15:06 <vagrantc> that might be an old u-boot version
Dec 17 16:15:36 <madhu> so how to find now
Dec 17 16:16:26 <madhu> is it not possible to find out the kernel load address now?
**** BEGIN LOGGING AT Sat Dec 17 19:15:04 2016
Dec 18 00:57:25 <ayjay_t> anyone wanna share their gcc flags for their linaro compiler?
**** ENDING LOGGING AT Sun Dec 18 02:59:59 2016