**** BEGIN LOGGING AT Fri Jul 20 03:00:01 2018
Jul 20 03:48:29 <kremlin> e
Jul 20 06:18:52 <vikash_> Hi, everyone, I am trying to load two character sets in ubuntu virtual terminal, but only one is getting loaded, whichever is first in the list. Any idea why this is happenning?
Jul 20 07:25:43 <vikash_> Hi, everyone, I am trying to load two character sets in ubuntu virtual terminal, but only one is getting loaded, whichever is first in the list. Any idea why this is happenning?
Jul 20 07:30:23 * tbr fails to understand the problem
Jul 20 07:30:32 <tbr> what are you doing?
Jul 20 09:50:40 <bart57> Is there any hardware changes between the older version of bbg(2016 downwards) and the newer versions. I cannot get my IMST lora concentrator to light up on the newer versions of bbg running the same code
Jul 20 10:03:27 <tbr> bart57: hmm, not sure. You might need to ask the manufacturer or check their website.
Jul 20 10:04:56 <tbr> bart57: http://wiki.seeedstudio.com/BeagleBone_Green/#faq - could it be this? they changed the eMMC
Jul 20 10:05:32 <tbr> you'd be running a *really* old firmware if that is the case
Jul 20 10:07:48 <dcmertens> Hello everyone. I am unable to use config-pins to add p9.31 in spi mode
Jul 20 10:08:04 <dcmertens> the error is this:
Jul 20 10:08:05 <dcmertens> Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P9_31_pinmux/state
Jul 20 10:08:59 <dcmertens> fyi, uname -r gives 4.4.30-ti-r64
Jul 20 10:09:27 <tbr> dcmertens: do you have any overlays loaded?
Jul 20 10:10:05 <dcmertens> my uEnv.txt has this line:
Jul 20 10:10:06 <dcmertens> cape_enable=bone_capemgr.enable_partno=BB-ADC,cape-universalh
Jul 20 10:10:40 <tbr> so you are loading an ADC?
Jul 20 10:10:47 <dcmertens> yep
Jul 20 10:11:03 <dcmertens> and i wanted to use the univeral to configure everything else
Jul 20 10:11:05 <tbr> well, then you can't use the pinmux tool as cape-universal will be unavailable
Jul 20 10:11:15 <tbr> it's either or
Jul 20 10:11:30 <dcmertens> are you sure? I can use config-pin to configure almost all other pins
Jul 20 10:11:59 <dcmertens> For example, I can set p9.29 and p9.30 to spi mode without issue
Jul 20 10:12:00 <tbr> mh, I'll have to defer to zmatt then. He's more up to date on this.
Jul 20 10:13:03 * dcmertens wonders if zmatt is busy, or perhaps asleep
Jul 20 10:20:12 <tbr> dcmertens: https://groups.google.com/d/msg/beagleboard/X_xYW_0BUSA/f1fvE2GICgAJ - check this maybe?
Jul 20 10:24:08 <dcmertens> tbr, thanks!
Jul 20 10:24:57 <dcmertens> I found that a bit earlier
Jul 20 10:25:23 <dcmertens> RCN recently changed some of the mode names
Jul 20 10:26:02 <dcmertens> in my case, I have an older version of config-pin, which expects an output name of spi, not spi_sclk
Jul 20 10:26:55 <tbr> mn, no clue then
Jul 20 10:27:04 <dcmertens> so, to be clear, when I ask "config-pin -l p9.31", I get
Jul 20 10:27:10 <dcmertens> default gpio gpio_pu gpio_pd pwm spi pruout pruin
Jul 20 10:27:14 <dcmertens> tbr++
Jul 20 10:27:33 <dcmertens> haven't struck a solution yet, but I appreciate the help
Jul 20 10:27:47 <tbr> might make sense to verify on an up to date image? is the kernel latest in that 4.4.30-ti line?
Jul 20 10:28:22 <dcmertens> that is a great question
Jul 20 10:28:37 <tbr> let's check git, sec
Jul 20 10:28:48 <dcmertens> at some point recently I ran apt-get update and upgrade
Jul 20 10:28:59 <dcmertens> so if something is available, it should be up-to-date
Jul 20 10:29:07 <dcmertens> (recently=yesterday)
Jul 20 10:30:59 <dcmertens> I am on a somewhat older version of Debian
Jul 20 10:31:24 <tbr> https://github.com/RobertCNelson/ti-linux-kernel-dev/commits/ti-linux-4.4.y looks like a newer one should be possible
Jul 20 10:32:18 * dcmertens checks
Jul 20 10:32:48 <tbr> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Kernel_Options this might help too
Jul 20 10:34:37 <dcmertens> Hmm, I will have to investigate a little later since that'll require switching my setup
Jul 20 10:36:10 <tbr> yes, it might be somewhat invasive
Jul 20 10:36:30 <tbr> might make sense to pop that in on a SD-card
Jul 20 10:41:11 <dcmertens> tbr, I hope to avoid that if it's just a little uEnv.txt issue
Jul 20 10:41:20 <dcmertens> at any rate, I gotta go for a few ours
Jul 20 10:41:21 <dcmertens> o/
Jul 20 10:41:29 <tbr> sure
Jul 20 12:26:51 <dcmertens> zmatt, any thoughts on the question above?
Jul 20 12:28:45 <dcmertens> Alternatively, I wonder if I should just modify a local copy of cape-universalh to strip out the SPI pins, so that I can load spidev1
Jul 20 12:30:00 <dcmertens> This seems most closely related to my problem: https://forums.adafruit.com/viewtopic.php?f=49&t=101951&p=510493#p510493
Jul 20 12:33:12 <dcmertens> drewfustini suggests changing uEnv.txt to include this:
Jul 20 12:33:12 <dcmertens> dtb=am335x-bonegreen-overlay.dtb
Jul 20 12:33:28 <dcmertens> I've tried it before...
Jul 20 12:33:29 * dcmertens gives it another try
Jul 20 12:44:00 <dcmertens> oh joy, and now I have discovered that P9.19 "is not modifyable". What?
Jul 20 12:49:25 <dcmertens> Why isn't it possible to map it to gpio13, like in here?
Jul 20 12:49:26 <dcmertens> https://github.com/nomel/beaglebone/blob/master/gpio-header/generated/gpio-P9.19-00A0.dts
Jul 20 12:52:43 <dcmertens> ah... so cape-universalh explicitly does not provide for p9.19 or p9.20:
Jul 20 12:52:44 <dcmertens> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universalh-00A0.dts#L105
Jul 20 12:55:00 * dcmertens is considering a personal fork of cape-universalh
Jul 20 12:58:02 <dcmertens> alright, here we go.....
Jul 20 13:03:34 <dcmertens> Presumably universal doesn't touch this so that BB can use the i2c to query cape eeprom
Jul 20 13:03:34 <dcmertens> https://github.com/cdsteinkuehler/beaglebone-universal-io/blob/master/cape-universalh-00A0.dts#L774
Jul 20 13:03:41 * dcmertens isn't using that
Jul 20 13:38:56 <stash> I have a gpio that acts as a reset line for an FPGA connected to my device.
Jul 20 13:39:24 <stash> What is the "right" way to represent it in the device tree?
Jul 20 13:39:59 <stash> It should be pulled low at boot (in reset) and driven high by a user space app.
Jul 20 13:43:54 <stash> I've considered: regulator, reset, gpio-hog, led?
Jul 20 13:50:36 <dcmertens> stash, have you considered taking a working dto and modifying it so that the default is pulldown?
Jul 20 14:01:20 <stash> dcmertens: by overriding the pinctrl-{names,<N>} entries in the gpio controller?
Jul 20 15:10:13 <dcmertens> stash, that's what I would try (am presently trying) to do
Jul 20 16:32:31 <kim_> what output pins on the BB-Blue are used for a stepper motor? There doesn't seem to be a lot of documentation on this type of motor.
Jul 20 16:32:40 <kim_> Also, I am assuming an H-bridge is needed.
Jul 20 19:49:43 <dcmertens> does anybody know how to set up P9_19 and P9_20 for GPIO use?
Jul 20 19:50:02 <zmatt> that seems plausible
Jul 20 19:50:36 <dcmertens> yes, but for example the universal cape does not make them modifiable
Jul 20 19:50:49 <dcmertens> zmatt, they are reserved for i2c
Jul 20 19:51:00 <zmatt> if your dtbs are uptodate they should actually reconfigurable
Jul 20 19:51:09 <dcmertens> hmmm
Jul 20 19:51:15 <zmatt> they will however still be configured to i2c by default
Jul 20 19:51:17 <dcmertens> they almost certainly are not...
Jul 20 19:51:24 <dcmertens> (up to date)
Jul 20 19:52:21 * dcmertens checks 
Jul 20 19:52:47 <zmatt> if you want to entirely avoid those pins from being used for i2c during boot, you need to change the main dt to disable capemgr and set the default pinmux to gpio, and modify and recompile the bootloader to disable boot-time probing for CAPEs
Jul 20 19:54:45 <dcmertens> I am going to have circuit boards mounted on top of my BBs. These pins are connect to SPI channel select pins. I don't imagine it will be a problem for boot time i2c to hammer on them
Jul 20 19:55:10 <dcmertens> in other words, I will definitely not use them for i2c, but I want the path of least resistance to get them working as GPIOs
Jul 20 19:55:13 <dcmertens> :-)
Jul 20 19:55:49 <dcmertens> looks like cape-universalh does not make them changeable
Jul 20 19:55:49 <dcmertens> so... cape-universalh does not expose these
Jul 20 19:55:52 <dcmertens> ooops
Jul 20 19:55:54 <zmatt> in that case, update your kernel to get a more recent dtb
Jul 20 19:55:58 <dcmertens> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/cape-universalh-00A0.dts#L106
Jul 20 19:56:19 <zmatt> they're not made reconfigurable by the universal overlay, rcn made them reconfigurable in the base dtb
Jul 20 19:56:37 <zmatt> so it's the kernel you need to update, not the bb.org-overlays
Jul 20 19:57:39 <dcmertens> ah, so my kernel has them as non-reconfigurable?
Jul 20 19:59:08 <zmatt> they used to be, but at some point rcn made them configurable: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bone-common.dtsi#L506-L538
Jul 20 19:59:55 <dcmertens> did he do this foor 4.4?
Jul 20 20:00:42 <dcmertens> ah, he did!
Jul 20 20:00:42 <dcmertens> https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bone-common.dtsi#L487
Jul 20 20:00:44 <zmatt> yup
Jul 20 20:00:59 <dcmertens> (just replaced 4.9 with 4.4 in the url. :-)
Jul 20 20:01:24 <zmatt> he backported those changes in 4.4.91-ti-r135 according to the commit history
Jul 20 20:06:03 <dcmertens> do you know much about dtb-rebuilder?
Jul 20 20:06:22 <dcmertens> because when I "make arm", it doesn't make anything related to the bb green
Jul 20 20:06:38 <dcmertens> wait...
Jul 20 20:06:45 <dcmertens> nm
Jul 20 20:06:46 <zmatt> any reason to not simply update to the latest 4.4-ti kernel?
Jul 20 20:07:08 <dcmertens> yes, because getting a system that lets me write pru assembly has been very, very difficult
Jul 20 20:07:09 <zmatt> to get kernel bugfixes in addition to these dtb changes
Jul 20 20:07:19 <zmatt> ehh
Jul 20 20:07:22 <dcmertens> and I do not know the magic well enough to know what to mix
Jul 20 20:07:48 <zmatt> it works perfectly on the latest kernels, both 4.9 and 4.14 -ti and -bone
Jul 20 20:07:51 <dcmertens> sorry, I bet you're cringing at that
Jul 20 20:08:05 <zmatt> both rproc (-ti kernels) and uio (-ti and -bone kernels)
Jul 20 20:09:12 <dcmertens> yes, I now that uio is supposed to work with new kernels, but my experience was rather different
Jul 20 20:09:21 <zmatt> it used to be a bit of a hassle, and uio-pruss was broken for a while in 4.9-ti kernels, but nowadays with u-boot overlays you just configure  uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo  in /boot/uEnv.txt and you're good to go
Jul 20 20:09:34 <dcmertens> sounds really simple
Jul 20 20:09:38 <dcmertens> but I couldn't get it to work
Jul 20 20:09:58 <dcmertens> and I *could* get it to work with a 2016-based debian jessie distribution
Jul 20 20:10:00 <zmatt> that may have been during the period when it was broken in 4.9-ti maybe?
Jul 20 20:10:08 <dcmertens> almost certainly
Jul 20 20:10:09 <zmatt> (for very silly reasons)
Jul 20 20:11:15 <dcmertens> This is the only thing that worked "out of the box":
Jul 20 20:11:16 <dcmertens> http://catch22.eu/beaglebone/beaglebone-pru-uio/
Jul 20 20:11:44 <zmatt> if that was the reason you may want to consider giving the latest stretch image a try again
Jul 20 20:11:55 <dcmertens> Since getting that working, I have spent the better part of a week customzing the image
Jul 20 20:12:04 <zmatt> hmm
Jul 20 20:12:06 <dcmertens> so I can flash 40-someodd boards with the same image
Jul 20 20:12:35 <n8vi> dcmertens: I had a lot of trouble too after not touching the PRU for several years as everything changed from under me.  I've pasted my notes at you in a query.
Jul 20 20:13:25 <dcmertens> n8vi++
Jul 20 20:13:26 <dcmertens> thanks!
Jul 20 20:13:35 <n8vi> Let me know if you have any issues
Jul 20 20:13:36 <zmatt> dcmertens: well it's your call of course.  since I know at some point you probably want to "freeze" at the version you're using to keep things stable (at which point things will start aging), I personally wouldn't want to already start out with an ancient system during development
Jul 20 20:14:17 <dcmertens> zmatt, the freeze is going to be rather significant; these BBs serve as the basis for a data acquisition system; once they're working, I'm not likely to touch them
Jul 20 20:14:25 <zmatt> hence
Jul 20 20:14:26 <dcmertens> for multiple years
Jul 20 20:14:39 <dcmertens> at which point, everything will need a huge overhaul anyway
Jul 20 20:14:47 <zmatt> which is exactly why I wouldn't want to start out with an old system
Jul 20 20:15:01 <zmatt> but, that might just be me
Jul 20 20:15:23 <zmatt> just saying, this particular problem has been solved
Jul 20 20:15:34 <dcmertens> I don't follow. The next time I update these boards, I'll start from scratch, not by updating
Jul 20 20:15:35 <zmatt> getting uio-pruss working is a piece of cake nowadays
Jul 20 20:15:41 <dcmertens> hmm
Jul 20 20:15:42 <dcmertens> ok
Jul 20 20:16:05 <dcmertens> and presumably it has the advantage that p9.19 and p9.20 are modifyable
Jul 20 20:16:12 <zmatt> well these boards can't be frozen yet since you're still developing?
Jul 20 20:16:13 <dcmertens> which is my *only* pinch point now
Jul 20 20:16:14 <zmatt> yes
Jul 20 20:16:36 <dcmertens> zmatt, I'll write new acquisition code, but all of that is shared over nfs
Jul 20 20:16:41 <dcmertens> that'll change all over the place
Jul 20 20:16:46 <dcmertens> but the base OS will be fixed
Jul 20 20:16:52 <zmatt> "will be" or "is" ?
Jul 20 20:17:07 <dcmertens> I haven't flashed any boards yet
Jul 20 20:17:25 <dcmertens> but re-installing and testing everything will probably take a couple of days
Jul 20 20:17:43 <dcmertens> and my summer time for research is rapidly evaporating...
Jul 20 20:17:47 <zmatt> okay
Jul 20 20:17:57 <zmatt> fair enough
Jul 20 20:18:09 <dcmertens> so if I can spend 10 minutes compiling a new dtb and be done...
Jul 20 20:18:16 <dcmertens> you see where I'm coming from
Jul 20 20:18:34 <zmatt> I do
Jul 20 20:19:48 <zmatt> but the latest 4.4-ti bonegreen dtb in dtb-rebuilder has rproc enabled only, so at the very least you'll need to modify it
Jul 20 20:20:41 <zmatt> that should be as simple as commenting out line 22 and uncommenting line 32 in https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bonegreen.dts
Jul 20 20:20:59 <zmatt> presumably
Jul 20 20:22:13 * dcmertens checks
Jul 20 20:23:21 <dcmertens> wait, I remember trying to do this...
Jul 20 20:23:41 <zmatt> that "easy" switch was broken in 4.9-ti I think
Jul 20 20:23:46 <zmatt> but it looks like it should work in 4.4-ti
Jul 20 20:24:02 <zmatt> haven't tried it of course
Jul 20 20:24:14 <zmatt> (4.4 is archeology to me)
Jul 20 20:25:32 <dcmertens> I have tried something like this before, but let's try again
Jul 20 20:26:24 <zmatt> don't forget to make a backup of your current dtbs
Jul 20 20:26:48 * dcmertens nods
Jul 20 20:26:54 <dcmertens> thanks for that
Jul 20 20:27:44 <dcmertens> 'cause I would have just rolled right over it
Jul 20 20:28:39 <MichaelLong> dcmertens, why not putting that stuff under version control, thats at least what I was using with everthing I changed on the BBBs
Jul 20 20:29:03 <zmatt> yes, etckeeper has also proved very useful to me
Jul 20 20:29:25 <zmatt> (and I keep my own dt sources in a git repo)
Jul 20 20:29:53 <dcmertens> MichaelLong, I have the discipline/habit with programming
Jul 20 20:29:57 <dcmertens> but now with sysconfig stuff
Jul 20 20:30:28 <dcmertens> does the current am335x-bonegreen.dtbo work with config-pin?
Jul 20 20:30:58 <dcmertens> sorry, ....dtb
Jul 20 20:31:13 <zmatt> "current" as in latest 4.4-ti or *current* ?
Jul 20 20:31:28 <dcmertens> I mean the dtb-rebuilder
Jul 20 20:31:45 <dcmertens> I will install it on 4.4.30-ti-r64
Jul 20 20:31:45 <zmatt> that doesn't change the question
Jul 20 20:31:55 <zmatt> okay you mean 4.4-ti
Jul 20 20:32:00 <dcmertens> sure. :-)
Jul 20 20:32:19 <zmatt> presumably?
Jul 20 20:32:23 <zmatt> 22:24 < zmatt> haven't tried it of course
Jul 20 20:32:23 <zmatt> 22:24 < zmatt> (4.4 is archeology to me)
Jul 20 20:33:35 <dcmertens> ok, we'll find out
Jul 20 20:35:42 <dcmertens> so, a question then about uEnv.txt
Jul 20 20:35:55 <dcmertens> it'll say "dtb=am335x-bonegreen.dtb"
Jul 20 20:36:07 <dcmertens> which means that freshly built dtb needs to be in the initramfs
Jul 20 20:36:16 <zmatt> normally it doesn't have to say that since it's auto-determined
Jul 20 20:36:17 <zmatt> no
Jul 20 20:36:22 <zmatt> dtbs are not in initramfs
Jul 20 20:36:26 <dcmertens> oh!
Jul 20 20:36:29 <dcmertens> that's helpful
Jul 20 20:36:30 <zmatt> dtbs are loaded by u-boot
Jul 20 20:36:43 <dcmertens> then, "cmdline=coherent_pool=1M quiet cape_universal=enable"
Jul 20 20:36:52 <dcmertens> is the cape_universal part necessary?
Jul 20 20:37:42 <dcmertens> ok, we're trying it with that bit...
Jul 20 20:37:54 <zmatt> that's how cape-universal was being enabled in the pre-uboot-overlays days (that parameter is of course ignored by the kernel, but early userspace detects it and loads the universal overlay)
Jul 20 20:43:17 <dcmertens> It sounds like that's not needed anymore? At any rate, I need to load a universal cape in the cape_enable portion of uEnv.txt
Jul 20 20:43:29 <dcmertens> then most things work as expected
Jul 20 20:43:33 <dcmertens> as for P9.19...
Jul 20 20:43:34 <zmatt> in a recent image it isn't, but you're not using one
Jul 20 20:43:42 <zmatt> oh
Jul 20 20:43:47 <zmatt> then dunno
Jul 20 20:44:10 <zmatt> I never used cape-universal to begin with, so I never really dug into this stuff
Jul 20 20:44:28 <zmatt> and now it's all in the past anyway
Jul 20 20:45:25 <dcmertens> so it's not working as I would like
Jul 20 20:45:39 <dcmertens> do you happen to know where RCN keeps the overlays repo?
Jul 20 20:45:52 <zmatt> https://github.com/RobertCNelson/bb.org-overlays
Jul 20 20:46:02 <dcmertens> yup
Jul 20 20:46:04 <dcmertens> just found that
Jul 20 20:46:05 <dcmertens> thanks
Jul 20 20:50:12 * dcmertens is generating a new initramfs with latest overlays
Jul 20 20:51:34 <zmatt> are those used in the initramfs?
Jul 20 20:52:07 <dcmertens> to my knowledge, if you load them in the uEnv.txt, they need to be in the initramfs
Jul 20 20:52:26 <dcmertens> but, you know, there's stuff out there that's five years old
Jul 20 20:52:31 <zmatt> okay
Jul 20 20:52:55 <dcmertens> at any rate, it seemed to be necessary when I got things working earlier this week,
Jul 20 20:52:59 <zmatt> I use neither overlays nor initramfs (the beaglebone boots just fine without one, and noticably faster too), so I wouldn't know
Jul 20 20:53:58 <dcmertens> well, all of that did not work
Jul 20 20:54:34 <dcmertens> so you'll see more of me next week. :-)
Jul 20 20:54:40 <zmatt> lol
Jul 20 20:55:14 <dcmertens> o/
Jul 20 20:55:15 <zmatt> it sounds like it might actually be less hassle to use a recent image
Jul 20 20:55:22 <zmatt> if the old one is this fragile
Jul 20 20:55:30 <dcmertens> yes
Jul 20 20:55:38 <dcmertens> it was fragile, but oh so close
Jul 20 20:55:45 <zmatt> doing your customizations a second time is probably a lot faster than the first time
Jul 20 20:55:58 <zmatt> especially if you keep that system around for reference
Jul 20 20:56:04 <dcmertens> probably
Jul 20 22:12:19 <veremitz> jkridner: did you make any progress on the buildbot issue?
**** ENDING LOGGING AT Sat Jul 21 03:00:02 2018