**** BEGIN LOGGING AT Sun May 19 02:59:57 2019
May 19 03:03:24 <zmatt> and again, unless you're already certain about this part, inquire whether the obsoleteness of the system is actually part of the assignment, since it doesn't seem very reasonable to me
May 19 03:05:13 <zmatt> since the combination of not updating the kernel yet making a new kernel driver for a hardware component (which suggests a system in development phase rather than maintenance phase) makes absolutely no sense
May 19 03:13:46 <zmatt> (and if you _are_ certain that this bullshit is really what they expect of you... yikes, I hope you get a better job offer eventually)
May 19 03:54:57 <zero_note> zmatt: it was definitely a problem of permissions on the echo command
May 19 03:55:27 <zmatt> that's what Permission Denied usually is :P
May 19 03:56:00 <zero_note> (unfortunately I moved abroad 2 month ago and this is the only company that would hire me with my current visa...life is really hard when you try to improve it=
May 19 03:56:45 <zero_note> but now I can see clearly that there is something else that is using one of the pin I need
May 19 03:56:57 <zero_note> [  172.050786] bone_capemgr bone_capemgr: slot #5: BB-LX-ACCEL conflict P9.15 (#4:cape-universaln)
May 19 03:57:22 <zmatt> okay so this isn't even a customized system or anything
May 19 03:57:35 <zmatt> it's literally an old beaglebone they found in a drawer and handed to you with whatever old system was on it
May 19 03:57:52 <zero_note> the truth has been spoken.
May 19 03:57:55 <zmatt> they probably won't even notice if you reflash it to the latest image
May 19 03:58:01 <zmatt> :P
May 19 03:58:46 <zero_note> haha ok, but I'll try to avoid the reflash way for another
May 19 03:58:55 <zero_note> lets say 2/3 hours
May 19 03:59:26 <zmatt> no, seriously, either get confimation on this or just do it, what you're doing right now is nonsensical
May 19 03:59:27 <zero_note> I know you can't see my point, hope you don't get upset because of this :P
May 19 04:00:08 <zero_note> uhmm today is Sunday, I don't think anyone would answer my questions
May 19 04:01:57 <zero_note> I notice that the problem is P9.15(GPIO_48), I'll use a different one for the interrupts
May 19 04:02:10 <zmatt> cape-universal occupies _all_ gpios
May 19 04:02:20 <zero_note> ahh cool
May 19 04:02:20 <zmatt> it's a replacement for using overlays
May 19 04:03:06 <zmatt> on current systems, overlays can disable cape-universal for individual pins, but that's not an option for pre-u-boot-overlays
May 19 04:03:40 <zero_note> ok
May 19 04:04:28 <zero_note> but there should be another way to do it
May 19 04:04:56 <zmatt> but seriously, I'd be kind of upset if a developer would waste his time on this.  is there anything in your assignment that's explicit about having to do it on the currently-installed system, or is it just about getting this sensor working on this hardware?
May 19 04:04:57 <zero_note> I mean, if we were in 2016 instead of today, with the same board and the same system
May 19 04:05:07 <zmatt> we're not
May 19 04:05:36 <zero_note> it's just about getting the sensor working on that hw
May 19 04:06:15 <zmatt> then what you're doing is a collossal waste of time.  instead of solving the problem, you're fighting with obsolescence
May 19 04:06:40 <zmatt> that's not smart use of an engineer's time
May 19 04:08:08 <zero_note> I see, in you opinion the only way to do this is updating the system and then proceed with dtbo and kernel module
May 19 04:09:07 <zmatt> "only way"? no.  but that's the obvious thing to do when developing a new driver
May 19 04:09:50 <zmatt> otherwise your exercise becomes archeology of how old beaglebones work and how to deal with ancient kernels and build scripts, instead of doing the *actual* assignment of getting the sensor to work
May 19 04:10:44 <zmatt> if there is already a driver, then I'd confirm whether it actually works properly, and report that
May 19 04:23:36 <zero_note> OK
May 19 04:24:06 <zero_note> the dtbo is fixed and the driver is working.
May 19 04:24:34 <chris__> I am using debian stretch on the beagleboard x15.  I would like to use general purpose timers 2 and 3, however I can see that the CM_L4PER_TIMERx_CLKCTRL:MODULEMODE field is 0x0 (disabled).  I have tried setting 'status = "okay"' in the dts, but it has no effect.  Does anyone know how to enable the timers via dts?
May 19 04:24:51 <zero_note> I had to remove P9.15 from exclusive-use in my dts
May 19 04:25:22 <zmatt> zero_note: disabling cape-universal would be a more-correct solution
May 19 04:26:17 <zmatt> right now you have a gpio conflict, and it's probably arbitrary whether you or cape-universal "wins"
May 19 04:26:33 <zero_note> ok, I'll disable it
May 19 04:26:41 <zmatt> (or maybe that kernel was already patched to ignore gpio conflicts, which itself is pretty gross)
May 19 04:27:38 <zmatt> chris__: looking at prcm registers is rarely useful, the kernel will automatically enable peripherals when needed and disable them again when not
May 19 04:28:12 <zmatt> so the question is more what you mean by "use them"
May 19 04:31:24 <zmatt> for example if you'd want to use one of the timers for pwm, you'd need to add a pwm-omap-dmtimer device
May 19 04:31:36 <chris__> zmatt: I'd ultimately like to use them as event counters.  If I try accessing the timer registers via mmap/devmem2, an exception is thrown (I think because the hardware is switched off, since the module is not turned on in the PRCM).  If I use devmem2 to enable the right bit in PRCM, then I can access the memory registers.  My hope is that I can 'enable' the timers via dts, so that they are available to use
May 19 04:31:38 <zmatt> (see Documentation/devicetree/bindings/pwm/pwm-omap-dmtimer.txt )
May 19 04:32:00 <zmatt> ah, use uio-pdrv-genirq for that
May 19 04:32:55 <zmatt> that creates a device that's basically like /dev/mem, but 1. limited to one device (i.e. the ranges specified in DT)  2. ensures power management work (the peripheral is enabled as long as you have the device open or mmapped) 3. it allows delivery of an irq to userspace
May 19 04:33:02 <chris__> zmatt: ah, so I can specify uio-pdrv-genirq and assign one of timer2, 3, etc., and then it will be enabled? (i'm googling it now)
May 19 04:35:16 <zmatt> basically you just set the compatible-string of the device to make it use uio_pdrv_genirq instead of its normal driver.  annoyingly it has no fixed compatible-string, instead you specify it was a module parameter: https://github.com/mvduin/py-uio/blob/master/etc/modprobe.d/uio.conf
May 19 04:36:16 <zmatt> then in DT you specify that compatible-identifier, and I personally also add a property that makes it easy to create a convenience symlink for the device: https://github.com/mvduin/py-uio/blob/master/dts/adc.dtsi
May 19 04:37:02 <zmatt> (this is an example for the tscadc device of the beaglebone but it should work similarly for other devices)
May 19 04:37:34 <zmatt> udev rule to create the symlink (i.e. /dev/uio/adc in this example): https://github.com/mvduin/py-uio/blob/master/etc/udev/rules.d/10-of-symlink.rules
May 19 04:39:29 <zmatt> hmm, I thought I had actually created a dmtimer example for py-uio... guess I never finished it
May 19 04:40:39 <chris__> zmatt: so in the timer entry, i would replace 'compatible = "ti,omap5430-timer";' with 'compatible = "generic-uio"'?
May 19 04:41:27 <zmatt> effectively yes, by adding a snippet to your main dts that overrides that property
May 19 04:43:05 <chris__> ok, thank you muchly.  And if I wanted to use the timer for PWM, not event capture, I should setup a pwm-omap-dmtimer entry that references timer2/3/4?
May 19 04:43:37 <zmatt> yes, if you want to use the kernel pwm driver
May 19 04:43:58 <zmatt> (obviously you could also use it for pwm by configuring it manually via uio)
May 19 04:44:38 <zero_note> zmatt: ok, disabling the universal_cape lets me leave my dts untouched.
May 19 04:44:58 <chris__> got it - i shall try the uio approach now
May 19 04:45:42 <zmatt> chris__: don't forget to add a pinmux node to your device, unless you're setting the pinmux correctly in u-boot (as TI recommends for the dra7xx/am57xx)
May 19 04:45:58 <zmatt> *pinmux node for your device
May 19 04:46:24 <zmatt> also, if you want to receive the timer's irq in userspace, here's how: https://pastebin.com/tarLaht8
May 19 04:47:03 <chris__> zmatt: thank you - that's really helpful!
May 19 04:47:45 <zmatt> all SoC-level interrupts are level-triggered, so you'd follow the second example in that
May 19 04:48:51 <zmatt> (using the code intended for edge-triggered interrupts would not be harmful, but it would cause a lot of spurious interrupts)
May 19 04:49:04 <chris__> zmatt: i just tried &timer2 { 	status = "okay";   compatible = "uio"; }; in my dts, but timer2 is still disabled in the PRCM
May 19 04:49:14 <zmatt> after opening the uio device?
May 19 04:49:19 <chris__> or do i need to open the uio first for PRCM to enable it?
May 19 04:49:30 <chris__> i will try that now... :)
May 19 04:49:31 <zmatt> yes, you open and mmap the uio device
May 19 04:49:43 <zmatt> prcm is handled completely transparently
May 19 04:50:50 <zmatt> caution: the offset parameter for mmap() is interpreted weirdly by uio, and should almost always be set to 0
May 19 04:52:13 <chris__> hmm, there doesn't appear to be any entries under /dev/uio or /sys/class/uio
May 19 04:52:23 <zmatt> is the driver loaded?
May 19 04:52:59 <chris__> forgive me - which driver?
May 19 04:53:04 <zmatt> since the compatible-string is a module parameter, which the kernel won't know about until the module is loaded, it cannot possibly auto-load the module based on compatible-string
May 19 04:53:07 <zmatt> uio_pdrv_genirq
May 19 04:53:44 <zmatt> try adding it to /etc/modules
May 19 04:54:31 <chris__> add "uio_pdrv_genirq" to /etc/modules.d/modules.conf?
May 19 04:54:53 <zmatt> yes
May 19 04:55:02 <zmatt> (which is a symlink to /etc/modules)
May 19 04:55:57 <zmatt> hmm that's weird
May 19 04:56:09 <zmatt> it does seem to load automatically on my beaglebone
May 19 04:56:47 <chris__> actually, i can already see it when i try lsmod
May 19 04:59:25 <zmatt> after creating the /etc/modprobe.d/uio.conf file that sets the of_id parameter, did you reboot? (unloading the module and loading it again should also suffice)
May 19 05:00:37 <chris__> zmatt: ah, i missed that step - i will try now
May 19 05:07:17 <zmatt> I should ask rcn-ee[m] to set that parameter by default on his images, to give a canonical compatible-string to use for overlays that want to use uio_pdrv_genirq
May 19 05:08:07 <zmatt> especially since you can only specify *one* compatible-string, so some sort of consensus on what string to use is required
May 19 05:08:25 <zmatt> (e.g. plain "uio" as my py-uio examples all use)
May 19 05:09:19 <zmatt> maybe "linux,uio" would be nicer
May 19 05:09:24 <zmatt> but *shrug*
May 19 05:21:44 <chris__> zmatt: you are a wizard - using devmem2, I can see the PRCM register change from disabled/enabled/disabled before/during/after I have /dev/uio0 open
May 19 05:22:13 <zmatt> ain't it magic
May 19 05:23:08 <chris__> well, I really appreciate your help.  I know volunteering can be a thankless task sometimes, but I really appreciate you taking the time to help me!
May 19 05:23:13 <zmatt> basically: using /dev/mem means you're bypassing the kernel and doing stuff without its knowledge or consent, which is often something you'd rather avoid
May 19 05:24:04 <chris__> haha, i've spent the past *many years* doing bare metal stuff, so still getting used to this pesky kernel that keeps getting in my way :)
May 19 05:24:47 <zmatt> lol
May 19 05:25:20 <zmatt> I mean, you *can* do that, but then it's your responsibility to ensure the kernel doesn't need to know or care about what you're doing
May 19 05:25:54 <zmatt> generally speaking however you'll want to leave power management to the kernel
May 19 05:27:24 <zmatt> uio is a nice compromise, you get full control over the peripheral and access to its interrupt, but the details related to the peripheral's integration into the SoC (i.e. power management and how that irq is delivered to you exactly) is left to the kernel
May 19 05:33:27 <zmatt> I've done some full baremetal programming on the beaglebone too... it's definitely nice having all of those resources freely available for you to use without a kernel getting in the way, and bootrom can tftpboot my application in the blink of an eye.  it's just a lot of effort if you want to do more complicated stuff
May 19 05:35:15 <chris__> i see some useful functions in drivers/clocksource/timer-ti-dm.c (like omap_dm_timer_read_counter) - one thing i haven't been able to figure out is if there is a userspace api to these functions?
May 19 05:35:32 <zmatt> no
May 19 05:37:03 <zmatt> btw, you said event counter.. you mean like pulse-counting? because I don't see how the timers would be of any use for that
May 19 05:37:09 <zmatt> the eQEP modules can do that
May 19 05:37:29 <chris__> ok, so i would need to write a kernel module to act as an intermediary between that code and any userspace app?  or is that totally a dumb idea (as in, would i be potentially attempting to access resources that other parts of the kernel were using)
May 19 05:38:46 <zmatt> I mean, that sounds like just making a kernel driver for whatever your (unclear) use-case is for these timers, just like there's one for using them as pwm outputs
May 19 05:48:12 <chris__> I didn't explain very well - the intent is to use the "capture mode" functionality of the general purpose timers.  I was hoping that a driver/library might already exist that allows me to do this from user space, but if not, I can use the uio method to access the timer registers directly
May 19 05:48:52 <zmatt> yeah not sure either (ditto for the capture mode of the eCAP devices)
May 19 05:49:52 <chris__> no worries - looks like I might be the first... which generally means everybody else does it some other way I don't know about :-)
May 19 05:52:01 <zmatt> I know ardupilot has something like that (timestamping signal transitions) used for custom protocol decoding, for which they use the eCAP in pruss and some PRU firmware that looks after it and streams the timestamps to memory
May 19 05:52:55 <zmatt> (using PRU for that isn't really necessary, e.g. DMA would work fine too, or just interrupts if the rate is low enough, but this was probably the easiest solution for them)
May 19 05:55:04 <chris__> i've been working on a driver that captures gpio interrupts and allows a user space app to get properties like "interrupt count", "time of last interrupt", etc, through the standard linux file descriptor technique http://tiny.cc/w3bx6y
May 19 05:55:50 <zmatt> I think linux already timestamps interrupts, the question is how to get access to them
May 19 05:56:06 <chris__> however, i wanted to experiment with the hardware timer counter to see what accuracy it offered
May 19 05:56:33 <zmatt> getting gpio interrupts to userspace is itself of course already possible, both via sysfs and using uio (the latter also provides a counter)
May 19 05:57:01 <zmatt> eh I guess the uio counter might not be that useful since you're required to reenable the interrupt manually
May 19 05:57:28 <zmatt> though again, the kernel already keeps a counter, exposed via /proc/interrupts
May 19 05:58:24 <zero_note> zmatt: newbie question: even using a static address I can't ssh through the USB connection
May 19 05:58:31 <zero_note> common pitfalls?
May 19 05:59:17 <zero_note> (abouth ETH: I have neither a cable or a router, so for now only microSD)
May 19 05:59:51 <zmatt> zero_note: newbie answer: be sure to use the latest stretch-iot image from the site :P
May 19 06:00:05 <zmatt> usb networking should simply work
May 19 06:00:10 <zero_note> ahaha
May 19 06:01:12 <zero_note> from the BBB side everything seems ok, all the usb_gadget modules are loaded and the interface has the correct IP, netmask and gateway
May 19 06:02:19 <zmatt> chris__: if you want accurate timestamps you probably want to use the kernel API for getting the current monotonic time
May 19 06:03:26 <zmatt> chris__: using a gptimer will have worse accuracy, and it'll give you timestamps in a timebase that can't be meaningfully related to timestamps available in userspace