**** BEGIN LOGGING AT Tue Jul 09 02:59:57 2019 Jul 09 03:00:15 But...off to try zmatt's ideas. Jul 09 03:01:30 hmm, would have to defer to rcn-ee[m] :) Jul 09 03:01:39 Otay. Jul 09 03:02:01 rcn-ee[m]: Aw! Jul 09 03:03:04 jkridner: jkridner[m]: bbb.io/start still returns an empty page FYI Jul 09 03:04:28 veremitz: did you clear you cache? Jul 09 03:04:39 uhoh Jul 09 03:04:45 I just checked. It worked for me or maybe I need to clear mine. Jul 09 03:04:47 Who knows? Jul 09 03:05:24 hmm no it seems I still get the base layout, but no page content Jul 09 03:05:56 I think zmatt pointed it out a week ago? Jul 09 03:07:20 veremitz: The stuff @zmatt has in his show-pins util. is not what I need. I am using the character device idea w/ this 4.14.x image. I am using and I quote: "ls -la /dev/gpiochip1" and I think this should write back some valuable info. Jul 09 03:07:28 Do you know what I am doing incorrectly? Jul 09 03:07:29 oh. Jul 09 03:07:35 hmm nope. Jul 09 03:07:39 Okay. Jul 09 03:07:58 I have been using this idea w/ serial ports. It works. I have not figured out gpio just yet. Jul 09 03:08:09 Just an led, too! Jul 09 03:09:28 yeah I'm confused as to what you are trying to do, and how. Jul 09 03:09:42 Oh. First, I call the info. on the terminal. Jul 09 03:09:58 Then, I get the info. and create and module. Jul 09 03:10:20 Then, I use the info. in userspace. Jul 09 03:10:36 that sounds .. complicated. Jul 09 03:10:42 I only got a motor to run so far w/out gpio. Jul 09 03:10:49 I used serial. Jul 09 03:11:12 I am pretty sure, b/c of the info. in the 4.19.x kernel online, this is what I did a while back. Jul 09 03:11:25 Please hold. I will get the info. Jul 09 03:11:59 https://linux-kernel-labs.github.io/master/labs/device_drivers.html#character-device-drivers is the starting place. Jul 09 03:12:29 At the end of the tutorial, there is an "exam" on these ideas. Jul 09 03:12:41 It is better w/ kernel 4.19.x, though. Jul 09 03:13:19 I think I was using 5.1.x though. I cannot remember. I was having too much fun and my notes are gone or never were. Jul 09 03:16:43 https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/ Jul 09 03:16:45 I see Jul 09 03:16:49 successor to sysfs Jul 09 03:17:50 seems reasonable enough Jul 09 03:19:59 I saw that already. it used to work for me. Jul 09 03:20:15 I gave up on it b/c of using newer kernels. Jul 09 03:20:32 and facebook...long story. Jul 09 03:40:33 veremitz: I tried that libgpiod.git/ example again. It done work-a-did again. Thank you. Jul 09 03:41:11 \o/ Jul 09 03:41:53 Yea boy! Jul 09 03:42:04 LED! Jul 09 03:44:39 awesome! Jul 09 03:48:08 Yep... Jul 09 04:13:25 why would you use that instead of the sysfs interface? Jul 09 04:17:52 Not sure. Just trying out things and enjoying life. Jul 09 04:21:23 @zmatt: I was reviewing the docs. on the google groups for erasing the eMMC on the BBB. I have come up empty but I was enlightened. Jul 09 04:21:47 ? Jul 09 04:21:56 erase the eMMC? why? Jul 09 04:21:58 Do you know how to erase the eMMC. I wrote it down six months back. My notes are missing again. Jul 09 04:22:08 I was going to help this fellow. Jul 09 04:22:18 He is having issues w/ the librobotcontrol stuff. Jul 09 04:22:41 He is on google groups looking for support. Jul 09 04:23:03 I researched the erase emmc idea on google groups to look up how to do it again. Jul 09 04:23:12 I came up w/ 1000s of ways. Jul 09 04:24:07 so, why erase eMMC? he wants to boot from sd card? Jul 09 04:24:18 Right. Jul 09 04:24:27 sudo blkdiscard /dev/mmcblk1 Jul 09 04:24:42 I figured he could have trouble w/ the library b/c of his bootloader on his emmc. Jul 09 04:24:57 if he's booting from sd card then yes that's possible Jul 09 04:25:07 Remember that old issue w/ the bootloader and the emmc taking precedence? Jul 09 04:25:08 a better solution usually is to reflash eMMC and boot from that instead of from sd card Jul 09 04:25:19 Right. I figured he could back up instead. Jul 09 04:25:35 And still boot from the SD Card after erasing the eMMC. Jul 09 04:25:46 ehm, he's getting compile errors Jul 09 04:25:58 also, he's not booting from sd card Jul 09 04:26:09 Oh. Jul 09 04:26:12 you're giving him useless advice Jul 09 04:26:17 I know now. Jul 09 04:26:25 I thought he said he was booting from SD Card. Jul 09 04:26:50 I am about to try to use this: sudo dpkg-reconfigure librobotcontrol Jul 09 04:27:14 I will set it up for starting on boot and the existing option. Jul 09 04:27:32 Then, I will run the software he has had issues w/. Jul 09 04:27:59 It is just a separate device tree. Jul 09 04:32:02 I just got what he was doing. it just take rc_blink w/out compiling the .c source. Jul 09 04:34:29 I've answered him Jul 09 04:34:39 it was a pretty trivial issue Jul 09 04:35:37 Me too! Jul 09 04:36:13 except yours are nonsense Jul 09 04:36:20 @zmatt: I told him to just type rc_blink instead of trying to compile. Jul 09 04:36:27 So, so. Jul 09 04:36:30 but he's trying to compile it Jul 09 04:36:32 and failing Jul 09 04:36:34 I know. Jul 09 04:36:41 Why is he doing that? Jul 09 04:37:04 because he wants to be able to compile the examples, since these are... examples? Jul 09 04:37:16 But... Jul 09 04:37:20 You can just run them as is. Jul 09 04:37:25 rc_blink Jul 09 04:37:27 you're missing the point Jul 09 04:37:29 rc_version Jul 09 04:37:31 and so on... Jul 09 04:37:37 What point? Jul 09 04:38:07 I have missed the point. Jul 09 04:38:10 running a trivial example like rc_blink is pointless, but the example exists as example on how to use librobotcontrol. being able to compile it is a bare minimum first step towards making your own stuff Jul 09 04:38:22 Oh. Jul 09 04:38:24 I got it now. Jul 09 04:38:38 He did not say those ideas, though. Jul 09 04:38:48 I do not read minds. Jul 09 04:39:40 not is any mind-reading required, he states quite clearly what he was trying to do and what problem he encountered Jul 09 04:39:43 *nor is Jul 09 04:39:52 Fine. Jul 09 04:39:58 No biggie. Jul 09 04:40:03 You win as usual. Jul 09 04:40:30 @zmatt: Up, up, and Otay! Jul 09 04:40:39 Later for now, how-now-brown-cow. Jul 09 05:20:17 people has a strange idea of 'boot' Jul 09 05:20:40 isn't the purpose of the user button to force booting from the SD card? Jul 09 05:24:53 ds2: hmm, context? Jul 09 05:25:15 zmatt: the whole erase the emmc thing Jul 09 05:25:59 yeah it's unfortunate that eMMC bootloader also tries to load linux from sd card Jul 09 05:26:24 if it didn't do that, the confusion wouldn't exist Jul 09 05:26:49 are you agreeing that having U-boot/MLO do a media search a bad idea? Jul 09 05:27:22 uh, yes? ROM already does a media search, and the media contains u-boot + linux Jul 09 05:27:31 IMO - we need to drive home boot == what the chip ROM does. period. anything else is a bug Jul 09 05:27:40 zmatt: thought I was along in that opinion Jul 09 05:28:03 nope, our beaglebones have an u-boot on eMMC that only loads linux from eMMC Jul 09 05:29:05 having u-boot do media search ultimately caused so much trouble Jul 09 05:30:04 does the AM33xx series properly report where it was booted from (per the ROM)? Jul 09 05:30:10 (e.g. I've run into an E2E post of someone who'd been trying everything to get stuff to work for two weeks or something like that, and the complete solution was "wipe eMMC") Jul 09 05:30:23 yeah ROM passes that info to MLO Jul 09 05:30:30 think the AM35x doesn't always reflect that right info Jul 09 05:31:01 heh... I almost blew a day on that same problem. what saved me was version strings were different Jul 09 05:31:10 AM35xx ? that's an unusual chip Jul 09 05:31:28 yes Jul 09 05:31:52 someone wanted a Beagle Classic based design but didn't want SGX or DSP Jul 09 05:32:51 I mean, noone forces you to use it :P Jul 09 05:33:32 cost was a factor Jul 09 05:33:41 am35xx has sgx btw Jul 09 05:33:48 ah, am3517 only Jul 09 05:33:52 am3505 I think doesn't Jul 09 05:34:22 oamp3530 vs am35xx vs DM3730 has subtle but annoying differences esp wrt to the bootloader Jul 09 05:34:36 yeah am35xx is unusual w.r.t. memory controller Jul 09 05:34:53 iirc Jul 09 05:35:02 it has the O4 EMIF IIRC Jul 09 05:35:13 not the SDRC like the O3 Jul 09 05:37:41 it's kind of a hybrid Jul 09 05:38:26 it does use EMIF, but glues to the interconnect via SMS/VRFB like SDRC, not via DMM/TILER like omap4 Jul 09 05:38:30 *glued Jul 09 05:39:47 probally to work around the O3 frame buffer Jul 09 05:42:39 it's basically just an omap3, but with the memory controller swapped out to support ddr2 and lpddr (instead of m-sdr and lpddr) Jul 09 05:43:48 (amoung other changes, I can't remember what else they did in the am35xx) Jul 09 05:45:11 given how tightly coupled the O3 FB is to the memory, I wonder if there are some memory movement stunts that can be done via the fb Jul 09 05:45:26 i.e. for systems that don't use the fb for a display Jul 09 05:45:44 what framebuffer? afaik the framebuffer is simply in ram Jul 09 05:48:54 the omap frame buffer can do a lot of tricks with the planes Jul 09 05:49:06 the am33xx is dumber then a doorstop Jul 09 05:49:13 am33xx's fb I mean Jul 09 05:50:52 oh the am35xx actually has quite a few changes besides memory controller... added ethernet, CAN, an UART, removed IVA, trimmed camera ISP down to just VPFE Jul 09 05:51:41 am335x's lcdc is extremely dumb yes, it's a small extension of the one on the omap-L13xx Jul 09 05:52:29 omap3 still has a fancy memory scheduler with rotation engine (VRFB), similar in purpose to TILER in omap4/5 Jul 09 05:56:56 oh yeah am35xx also added usb otg phy (other omap3 chips use ULPI) Jul 09 12:03:56 zmatt: sysfs is bein deprecated by the looks of things Jul 09 12:04:05 its not the best interface tbf Jul 09 13:05:24 veremitz: with the sysfs interface and gpio-of-helper I can declare named gpios in DT and configure them (including constraining whether the gpio is input or output), an udev rule creates symlinks based on those declarations (so applications don't have to know which gpio is used for "dsp-reset" on this hardware revision), and I can easily control privileges per gpio. can I do any of this with the ... Jul 09 13:05:30 ...new interface yet? Jul 09 13:07:34 constraining gpio direction in DT is particularly important since without that, any application with access to some input effectively has the CAP_DESTROY_HARDWARE capability by reconfiguring it as output, which is not acceptable Jul 09 13:10:07 (if safety is not regarded as important then you may as well just mmap the gpio controller, then at least you get good performance) Jul 09 13:18:17 m Jul 09 20:53:21 zmatt: I'm not sure tbh, esp. how the DT stuff is handled, but that's custom anyway. afaict its just a set of bindings and tools at this stage Jul 09 23:05:35 veremitz: "that's custom anyway" ? are you referring to gpio-of-helper? although it is non-mainline, I think it (after some cleanup) very much belongs in mainline Jul 09 23:06:05 not heard of that before Jul 09 23:06:07 linky? Jul 09 23:07:46 link to? it's how gpios are exported to sysfs by DT, as done e.g. by cape-universal. there's also an example of it in my overlay-utils: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi Jul 09 23:07:54 oh ok Jul 09 23:08:10 if not to that, what were you referring to with "but that's custom anyway" ? Jul 09 23:10:39 well you hve to set up gpio's in DT .. or they don't exist, right? Jul 09 23:11:01 and you have to do that before boot .. unless you use overlays (dtbo) Jul 09 23:16:05 without gpio-of-helper you can still manually export them (by writing the gpio number to /sys/class/gpio/export) or you can use the new chardev Jul 09 23:38:44 veremitz: maybe you're confusing setting up gpios with declaring gpio controllers... the latter is indeed a mandatory part of DT to have any gpios at all. the former is not required, nor even possible in mainline, but I personally consider it absolutely essential **** ENDING LOGGING AT Wed Jul 10 03:01:22 2019