**** BEGIN LOGGING AT Thu Jul 05 03:00:02 2018
Jul 05 06:14:53 <loki42a> Does anyone have a blog post / forum etc about using an screen with the pocket beagle? Basically I'd like to connect it to a parallel RGB display around 4 inch.
Jul 05 06:23:23 <tbr> loki42a: have you consulted its SRM yet? https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual
Jul 05 17:50:40 <zmatt> lcdc pins are not available on the pocketbeagle
Jul 05 17:52:18 <zmatt> unless you solder wires onto the 16 pull-up/down resistors used to configure sysboot :P
Jul 05 20:28:09 <CareBear\> hi all. can I get a mapping to the PRU data memory through rproc, the way I used to with prussdrv_map_prumem() ?
Jul 05 20:45:38 <CareBear\> would that be an intmem resource?
Jul 05 21:14:11 <zmatt> you know you can still use uio-pruss right?
Jul 05 21:14:25 <zmatt> :)
Jul 05 21:21:21 <CareBear\> zmatt : I saw it listed as one of four possibilities
Jul 05 21:21:38 <zmatt> one of four?
Jul 05 21:21:42 <CareBear\> zmatt : that means I can just ignore all rproc stuff?
Jul 05 21:21:47 <zmatt> yep
Jul 05 21:21:49 <CareBear\> yes, hm, let's see if I can find it again
Jul 05 21:21:53 <CareBear\> cool
Jul 05 21:22:11 <CareBear\> and my dtbo continues to work? pinmux etc?
Jul 05 21:22:49 <zmatt> depends on what's in your dtbo
Jul 05 21:23:04 <zmatt> when using a recent image in its default state, you don't need a dtbo at all
Jul 05 21:23:26 <CareBear\> zmatt : http://dpaste.com/3DG4XDQ
Jul 05 21:23:40 <zmatt> you select uio-pruss or remoteproc-pru by uncommenting the appropriate line in /boot/uEnv.txt and setup pins using config-pin
Jul 05 21:24:14 <zmatt> (but doing pinmux using an overlay is supported too)
Jul 05 21:24:23 <CareBear\> ok, so I will completely replace my dtbo with config-pin calls?
Jul 05 21:24:49 <CareBear\> I tried enabling my dtbo but then the system didn't boot anymore
Jul 05 21:25:04 <CareBear\> but then I still had rproc enabled, I'll try with ui instead
Jul 05 21:26:29 <zmatt> I don't see anything obviously wrong with it
Jul 05 21:26:49 <CareBear\> thanks
Jul 05 21:27:53 <zmatt> oh wait, pocketbeagle or beaglebone?
Jul 05 21:28:15 <CareBear\> I'm testing on pocketbeagle but final target is beaglebone black where this is working with (very) old OS
Jul 05 21:28:39 <CareBear\> some IO conflicts perhaps..
Jul 05 21:30:09 <zmatt> yeah for pocketbeagle you'd need to disable the pinmux helper node (which allows runtime pinmux selection using config-pin) for each pin you use in an overlay
Jul 05 21:30:23 <zmatt> so overlays are a bit more complicated there than on beaglebone
Jul 05 21:30:50 <CareBear\> how come there's a difference?
Jul 05 21:32:25 <zmatt> on beaglebone, "cape-universal" (which contains all these pinmux helper nodes) is an overlay that's optionally enabled, and automatically disabled if you enable any overlay.    on pocketbeagle it is part of the base dt
Jul 05 21:32:37 <CareBear\> ah I see!
Jul 05 21:33:30 <zmatt> I mean, it is possible to apply overlays without disabling cape-universal obviously, since it is an overlay itself :P   and there are more special-purpose overlays (like that pru overlay) that do not cause cape-universal to be disabled
Jul 05 21:34:22 <zmatt> but uboot_overlay_addr0-7 (whether set manually or auto-detected) and dtb_overlay cause cape-universal to be disabled
Jul 05 21:34:55 <zmatt> so what did you mean by "four possibilities" ?
Jul 05 21:38:28 <CareBear\> .searching
Jul 05 21:40:49 <CareBear\> oh, just found an example which simply mmaps the shared memory on /dev/mem - duh
Jul 05 21:40:58 <zmatt> ewwwwwww
Jul 05 21:41:23 <CareBear\> found it: https://hackaday.io/project/5837-pruss-support-for-newer-kernels
Jul 05 21:41:31 <CareBear\> "Such data transfer is possible through"
Jul 05 21:41:44 <zmatt> also known as "the easy way to make piece of shit software that throws a bus error in the user's face if the pru firmware didn't load"
Jul 05 21:42:00 <CareBear\> yes? also for the data memory?
Jul 05 21:42:39 <zmatt> just use uio-pruss, it's supported in basically every kernel for beaglebone
Jul 05 21:42:42 <zmatt> both -bone and -ti
Jul 05 21:42:46 <CareBear\> cool
Jul 05 21:43:06 <david__> Question for others:  Is there a 3d CAD model of the beaglebone blue available somewhere?
Jul 05 21:43:41 <zmatt> CareBear\: btw in case it's of any use: I made a python lib for using uio-pruss, https://github.com/mvduin/py-uio/#uio_pruss
Jul 05 21:43:53 <CareBear\> oh nice one!
Jul 05 21:44:02 <zmatt> (also capable of loading ELF executables produced by clpru.  no support for the resource table yet)
Jul 05 21:44:03 <CareBear\> I already have my C things, but I'll note it for future projects
Jul 05 21:52:43 <CareBear\> can I actually test my thing on the pocket? maybe not eh..
Jul 05 21:53:01 <zmatt> depends on whether the pins you need are available I guess
Jul 05 21:53:42 <CareBear\> right - they aren't externally available, but maybe there are conflicts on the OSD? I am happy if I get to the point where PRUs run my firmware and my userspace code can talk with the firmware
Jul 05 21:53:43 <zmatt> that's the only relevant difference between beaglebone and pocketbeagle for pru applications
Jul 05 21:54:09 <zmatt> no the osd is just an am335x + ddr3 + pmic
Jul 05 21:54:12 <CareBear\> ack
Jul 05 21:55:00 <zmatt> for uio-pruss, make sure you're using a sufficiently recent 4.9-ti kernel, or a 4.14-ti kernel or any -bone kernel
Jul 05 21:55:19 <CareBear\> 4.14.49-ti-r54
Jul 05 21:55:32 <zmatt> (but -bone kernels might have wonky pocketbeagle dtb iirc)
Jul 05 21:56:07 <zmatt> should be fine.  you could try running some py-uio examples to double-check whether pruss is working okay
Jul 05 21:57:50 <CareBear\> File flipdot_pru0.bin open passed
Jul 05 21:57:50 <CareBear\> File flipdot_pru1.bin open passed
Jul 05 21:57:52 <CareBear\> looks good
Jul 05 21:58:09 <CareBear\> I didn't run config-pin at all now
Jul 05 21:58:21 <CareBear\> so I guess there are no twiddling pins, but that's OK
Jul 05 21:58:49 <zmatt> sure, pru has no idea its pins aren't doing anything
Jul 05 21:58:59 <zmatt> its inputs will read as 0
Jul 05 21:59:10 <zmatt> outputs are ignored
Jul 05 21:59:35 <CareBear\> nod. I don't think this cape has any inputs
Jul 05 21:59:40 <CareBear\> all right - it looks fine
Jul 05 21:59:42 <CareBear\> thanks a lot!
Jul 05 22:00:25 <CareBear\> is there a recommended way to do the config-pin setup? if not I'd make a service for it, type=oneshot
Jul 05 22:00:55 <zmatt> that should work.  or just right before your program is launched
Jul 05 22:01:01 <CareBear\> aye
Jul 05 22:01:21 <zmatt> or you could do it in your program (each pin setup is just writing the pin mode to a sysfs attribute for each pin)
Jul 05 22:01:52 <CareBear\> then I lose backward compatibility
Jul 05 22:02:37 <zmatt> just mentioning options :)
Jul 05 22:02:54 <CareBear\> good to know - that's a lot more convenient than the dtbo
Jul 05 22:03:25 <zmatt> I use neither myself, I'm a custom-dtb sort of person ;)
Jul 05 22:04:12 <CareBear\> yes, I too like custom builds, but then I have to do the updates too.. ;)
Jul 05 22:04:25 <CareBear\> fine for an actual product, less so for side projects
Jul 05 22:04:57 <zmatt> it's pretty rare to have to update the dtb for a new kernel though, usually just happens for new major-version (e.g. 4.9 -> 4.14)
Jul 05 22:05:27 <CareBear\> ack. I don't even know what version the old system is running. it's several years old
Jul 05 22:06:00 <zmatt> and it's just the base definitions in that case, so I just fix that and recompile all dtbs for various products/projects
Jul 05 22:07:25 <zmatt> I understand the convenience of config-pin for typical users, but once you're used to making a dts and have decent macros it's not much slower.  plus I hate that cape-universal slow down boot a lot and creates a ton of silly devices
Jul 05 22:09:42 <CareBear\> I hear you, I am a big fan of minimalism
Jul 05 22:10:15 <zmatt> I don't recall exactly, but I seem to remember the default images boot a bit slower than https://liktaanjeneus.nl/boot.svg
Jul 05 22:10:19 <zmatt> ;)
Jul 05 22:11:49 <CareBear\> very nice!
Jul 05 22:11:58 <CareBear\> it seems I can't set slew rate with config-pin
Jul 05 22:12:18 <zmatt> fast/slow slew officially shouldn't be touched anyhow
Jul 05 22:12:27 <CareBear\> oh? I like slow
Jul 05 22:13:15 <zmatt> my guess would be that timing specs in the datasheet might not be accurate anymore if slow slew is used, hence TI says that
Jul 05 22:13:21 <zmatt> that's just my guess though
Jul 05 22:13:39 <CareBear\> ha ok
Jul 05 22:13:43 <zmatt> how slow is slow slew anyway? I've never tried it with a scope attached
Jul 05 22:13:58 <zmatt> and no longer have access to a good scope :-/
Jul 05 22:15:24 * zmatt liked the Agilent MSO7054B at his previous work
Jul 05 22:28:34 <CareBear\> I don't know anymore
Jul 05 22:28:52 <CareBear\> I think I've solved all my problems with your kind help. thanks a lot!
Jul 05 22:28:55 <CareBear\> time to go home
**** ENDING LOGGING AT Fri Jul 06 03:00:01 2018