**** BEGIN LOGGING AT Tue Sep 21 02:59:57 2021
Sep 21 10:35:18 <BeagleKho> Hi
Sep 21 10:35:40 <BeagleKho> Anyone know how to boot OS image into beaglebone black emmc?
Sep 21 10:36:40 <BeagleKho> @all
Sep 21 13:47:09 <trinath> hi
Sep 21 13:47:45 <trinath> I have a query on beaglebone x15
Sep 21 13:48:14 <trinath> Can i configure PCIe of beagle bone x15 in endpoint mode
Sep 21 13:48:19 <trinath> ?
Sep 21 13:49:43 <trinath> hi
Sep 21 13:50:10 <trinath> Can i configure PCIe of beagle bone x15 in endpoint mode ?
Sep 21 13:50:57 <trinath> Can anyone answer my quey please ?
Sep 21 13:56:06 <zmatt> trinath: like the channel topic says, "PLEASE BE PATIENT", this is a community chat and yo're asking a question about a very obscure topic that very few people will have any useful feedback to give on
Sep 21 13:56:59 <trinath> That's fine..
Sep 21 13:58:31 <zmatt> in fact I don't think I've ever seen or heard anyone doing anything with PCIe on the bbx15, however it's close to identical to the baseboard of the AM572x EVM so presumably it's theoretically possible
Sep 21 13:59:16 <zmatt> it might be more fruitful to ask on the TI E2E forum
Sep 21 13:59:30 <trinath> I also thought the same..
Sep 21 13:59:51 <trinath> But i need a confirmation on tha
Sep 21 13:59:55 <trinath> taht
Sep 21 14:00:39 <zmatt> I'm not sure you'll get any, as far as I know this is basically unexplored territory
Sep 21 14:01:21 <trinath> Ok..
Sep 21 14:01:34 <zmatt> but PCIe is available on the expansion headers, and the AM572x apparently supports endpoint mode
Sep 21 14:01:40 <trinath> Anyways thank you zmatt for answering my query..
Sep 21 14:03:01 <trinath> Ok... i will find out...thanks again
Sep 21 14:05:28 <zmatt> good luck!
Sep 21 15:27:37 <rcn-ee> zmatt, i've switched the bullseye daily to systemd-networkd, usb0 and usb1 are starting up nicely.. do we have to reload the whole stack if we change usb0 from "DHCPServer" -> "DHCP" for windows ics, or can we just reload "usb0"..
Sep 21 15:29:03 <zmatt> not sure what you mean by "whole stack", but just restart systemd-networkd... it doesn't cause any network interruption as such
Sep 21 15:30:18 <rcn-ee> okay, perfect, let's assume your connected thru eth0, and you change usb0 from default to dhcp, just restarting systemd-networkd shouldn't kill the eth0 connection..
Sep 21 15:30:30 <zmatt> it won't
Sep 21 15:30:48 <rcn-ee> perfect, thanks!
Sep 21 15:38:54 <rcn-ee> i've added the defaults here for bullseye, https://github.com/rcn-ee/repos/tree/master/bb-usb-gadgets/suite/bullseye/debian
Sep 21 21:41:01 <agentnocent> So I am looking into using a beagle board combined with a case and a screen to make a very basic offline map-reader. I want to use ubuntu + firefox and don't know what case or screen would be needed for this project. I am needing it to fit in a hand and have a battery that can last at least two hours of continuous usage. I state this as I'd like any general advice, pointers, specific models of pieces to
Sep 21 21:41:01 <agentnocent> get, etc. if anyone knows of any. I will continue researching this on my own but in the meantime thought to leave this here.
Sep 21 21:41:33 <agentnocent> The idea is to use downloaded Google Maps or Bing Maps (I am not sure which is best suited yet).
Sep 21 21:42:35 <agentnocent> also this is just as a project and not for serious usage; mostly to show myself that I can and poke around with improving it as time goes on
Sep 21 21:50:50 <the_person48> hey guys, I'm running debian 9.5 on a beaglebone black rev C
Sep 21 21:51:16 <the_person48> I have set up a boot overlay: https://pastebin.com/GCRw9E0m
Sep 21 21:51:19 <the_person48> which seems to be working
Sep 21 21:51:32 <the_person48> as well as udev rules. in /etc/udev/rules.d:
Sep 21 21:51:33 <the_person48> gpio-symlinks.rules: https://pastebin.com/RHpxYLuq
Sep 21 21:51:45 <the_person48> but P8.03 is not coming up for some reason
Sep 21 21:52:10 <the_person48> even though the overlay has totally analogous code for P8.03 and P8.04 and the other gpios I'm using
Sep 21 21:52:15 <the_person48> any idea why that might be?
Sep 21 21:53:15 <the_person48> sorry, correction, my overlay is as follows:
Sep 21 21:53:16 <the_person48> https://pastebin.com/xpu1t889
Sep 21 21:53:19 <the_person48> I updated it a bit
Sep 21 23:19:20 <agentnocent> [Having read now the guidelines for questions as I noticed the link after coming back to this: I do apologize for the framing of the questions; in any case, my hope is to develop this over the course of the month - I will document my thoughts, information gathered, etc. into a document of some sort before coming back].
Sep 21 23:22:06 <zmatt> the_person48: please don't configure internal pulldown on P8.03-06 or P8.20-25, they have external pull-ups
Sep 21 23:25:18 <zmatt> the_person48: what do you mean by "not coming up" ?
Sep 21 23:31:43 <the_person48> as in, the synlink isn't there in /dev/gpio
Sep 21 23:32:43 <rcn-ee> zmatt, seeing something odd with systemd-networkd and eth0 (hot plug) is there a *.network option we need to enable that?
Sep 21 23:32:45 <the_person48> here's the ls -la output on /dev/gpio
Sep 21 23:32:45 <the_person48> https://pastebin.com/mW5rpfAc
Sep 21 23:33:08 <zmatt> rcn-ee: to enable what?
Sep 21 23:33:35 <rcn-ee> zmatt, boot up, we have dhcp on eth0, disconnect cable, it drops the ip.. plug back cable... doesn't fire up and get an ip..
Sep 21 23:33:45 <the_person48> and zmatt you're saying to change to PIN_NOPULL for P8.3-6 and P8.20-25?
Sep 21 23:34:13 <zmatt> rcn-ee: uhh strange, I've never had a problem with it
Sep 21 23:35:05 <zmatt> the_person48: yes, or PULLUP would be safe too (but pointless since the external pull-ups are stronger than the internal ones), just not PULLDN
Sep 21 23:38:09 <the_person48> sounds good
Sep 21 23:38:18 <the_person48> and do you think that might be causing the issue with P8.03?
Sep 21 23:38:23 <the_person48> or is that separate?
Sep 21 23:38:26 <rcn-ee> zmatt, i wonder if it's my eth0.network config?  https://github.com/rcn-ee/repos/blob/master/bb-usb-gadgets/suite/bullseye/debian/eth0-DHCP.network 5.10.59-ti-r18 and here's systemd https://paste.debian.net/1212774/
Sep 21 23:38:37 <zmatt> the_person48: it shouldn't matter in practice since you're configuring the gpio as output-only which means internal pull configuration will be ignored (once the gpio is configured), but it's better to configure internal pulls sensibly regardless of how the pin is used
Sep 21 23:38:45 <zmatt> the_person48: I have no idea what's going on with P8.03 for you
Sep 21 23:38:47 <rcn-ee> it detects link down... but never gets a link is up..
Sep 21 23:39:10 <rcn-ee> (rebooting with v5.4.x, might be a kernel bug..)
Sep 21 23:39:54 <zmatt> if the kernel doesn't report link up there's nothing systemd-networkd can do
Sep 21 23:42:34 <zmatt> the_person48: check what show-pins says about P8.03 versus e.g. P8.04, check if gpio38 has shown up in /sys/class/gpio/, if it has then use udevadm test --action=add on it
Sep 21 23:45:00 <rcn-ee> zmatt, yeap works in 5.4.x, okay atleast i got most of the systemd-networkd (from connman) configuration converted before i founda  kernel bug to deal with. ;)
Sep 21 23:45:19 <the_person48> that might be something. https://pastebin.com/iBaSvmux
Sep 21 23:45:32 <zmatt> the_person48: also why is there an "AIN not configurable?" comment in your gpio-helper's pinmux block?  even if they were (they're not), the pinmux block for your gpio-helper would be the wrong place for it :P
Sep 21 23:45:57 <zmatt> okay so the gpio didn't get exported for some reason
Sep 21 23:45:58 <the_person48> P8.03 shows up with the name "gpio-demo" while P8.04 is named "P8.04"
Sep 21 23:46:01 <the_person48> sorry that's from before
Sep 21 23:46:15 <zmatt> check kernel log?
Sep 21 23:46:15 <the_person48> I used to think they were not, haven't removed the comment
Sep 21 23:46:21 <the_person48> ok, how do I do that again?
Sep 21 23:46:27 <zmatt> also you still have pulldown configured
Sep 21 23:46:32 <the_person48> oh oops
Sep 21 23:46:40 <the_person48> sorry I rewrote the file but forgot to recompile
Sep 21 23:46:42 <the_person48> one sec
Sep 21 23:46:51 <zmatt> dmesg or journalctl -k
Sep 21 23:48:14 <the_person48> https://pastebin.com/YT2yMVq2
Sep 21 23:48:32 <the_person48> here's the kernel log, I just recompiled to adjust the pulldowns to nopulls and am rebooting
Sep 21 23:49:17 <zmatt> you've got cape-universal enabled again
Sep 21 23:49:32 <zmatt> it's conflicting with everything
Sep 21 23:49:52 <the_person48> ahh
Sep 21 23:50:55 <the_person48> I've got the enable_uboot_cape_universal=1 commented
Sep 21 23:51:00 <the_person48> isn't that correct?
Sep 21 23:51:23 <zmatt> weird, the pinmux helpers are still there
Sep 21 23:51:47 <zmatt> rcn-ee: any ideas?
Sep 21 23:51:55 <the_person48> https://pastebin.com/MDwKqrTZ
Sep 21 23:52:03 <the_person48> this is what I have for my boot/uEnv.txt
Sep 21 23:54:33 <zmatt> (I don't know why having cape-universal enabled would interfere with exporting the gpio for P8.03 but not the other gpios, but it's the most obvious suspect)
Sep 21 23:54:47 <the_person48> yeah good to eliminate at least first
Sep 21 23:54:58 <the_person48> but it's weird that it's enabled even though I have that line commented?
Sep 21 23:55:03 <zmatt> indeed
Sep 21 23:55:17 <the_person48> could it be an issue with the onboard eMMC?
Sep 21 23:55:20 <rcn-ee> P8.03 would be the eMMC... you have ti disabled?
Sep 21 23:55:21 <zmatt> no
Sep 21 23:55:28 <zmatt> rcn-ee: he does
Sep 21 23:55:55 <rcn-ee> one of his pastebin shows: #disable_uboot_overlay_emmc=1
Sep 21 23:56:14 <the_person48> let me double check
Sep 21 23:56:23 <zmatt> huh, but show-pins is showing the pins not being in use by eMMC
Sep 21 23:56:45 <the_person48> yeah you're right it is commented
Sep 21 23:56:52 <the_person48> that's weird, I swear I uncommented that
Sep 21 23:56:53 <the_person48> changing now
Sep 21 23:57:11 <zmatt> but then how... why... is the pinmux not configured to eMMC ? o.O
Sep 21 23:57:26 <the_person48> haha I have no idea
Sep 21 23:57:30 <the_person48> much weirdness
Sep 21 23:57:32 <the_person48> but we
Sep 21 23:57:36 <the_person48> 'll see if this fixes it
Sep 21 23:58:03 <zmatt> the_person48: oh and the P8.03 issue is indeed caused by cape-universal
Sep 21 23:58:03 <rcn-ee> it's really best to "not" use any eMMC pins, depending on model/etc they can't be disabled..
Sep 21 23:58:41 <zmatt> you can reuse the data pins as long as you don't reuse both clk and cmd... but yeah I'd see reusing eMMC pins as a last resort if you really have no other pins left
Sep 21 23:59:01 <the_person48> ok, I wonder how to disable it though cause I already have that line commented about enabling uboot cape universal
Sep 21 23:59:21 <the_person48> yeah we didn't understand that when developing hardware that meshes with the BB
Sep 21 23:59:22 <rcn-ee> disable_uboot_overlay_emmc=1 -> disable..
Sep 21 23:59:31 <the_person48> and now trying to avoid changing the hardware
Sep 21 23:59:33 <rcn-ee> #disable_uboot_overlay_emmc=1 -> enable
Sep 21 23:59:57 <the_person48> ok, I'll do that first one
Sep 22 00:00:59 <zmatt> the_person48: cape-universal tries to claim the gpio for P8.03 (since it's the first gpio it tries to claim), this fails because you already have it claimed, and this conflict somehow manages to unexport your gpio (I've noticed that kernel bug too, it also happens when manually trying to export a gpio that's already exported), at which poins the gpio-of-helper probe bails out so the remaining gpios ...
Sep 22 00:01:05 <zmatt> ...are not affected
Sep 22 00:01:15 <the_person48> or wait sorry I'm trying to figure out how to disable the uboot_cape_universal
Sep 22 00:01:27 <rcn-ee> #enable_uboot_cape_universal=1 > disabled...
Sep 22 00:01:37 <the_person48> yeah I have that
Sep 22 00:01:45 <the_person48> but zmatt is saying it's enabled anyways
Sep 22 00:01:59 <rcn-ee> the_person48, what did "version.sh" output?
Sep 22 00:02:30 <the_person48> this is my new /boot/uEnv.txt: https://pastebin.com/ry7EWN7U
Sep 22 00:02:31 <rcn-ee> did you order that serial port adapter last week?
Sep 22 00:03:28 <zmatt> serial output would indeed be useful
Sep 22 00:03:42 <the_person48> I did order it but it takes literally months to get things here unfortunately
Sep 22 00:03:48 <the_person48> where's the version.sh located again?
Sep 22 00:04:25 <rcn-ee> the_person48, sudo /opt/scripts/tools/version.sh
Sep 22 00:04:34 <rcn-ee> (it's beagle-version in bullseye)
Sep 22 00:05:13 <the_person48> https://pastebin.com/ziWi3Jqi
Sep 22 00:05:17 <the_person48> gotcha
Sep 22 00:05:21 <the_person48> here's the output
Sep 22 00:05:26 <rcn-ee> [U-Boot 2018.03-00002-gac9cce7c6a]
Sep 22 00:05:31 <rcn-ee> yeah.. i'm not touching it..
Sep 22 00:05:38 <zmatt> lol
Sep 22 00:05:59 <rcn-ee> apt update ; apt install bb-u-boot-am335x-evm
Sep 22 00:06:24 <rcn-ee> Then: sudo /opt/u-boot/bb-u-boot-am335x-evm/install.sh followed by a reboot..
Sep 22 00:06:27 <the_person48> what is that?
Sep 22 00:07:10 <zmatt> updater for your prehistoric bootloader
Sep 22 00:07:16 <rcn-ee> the_person48, that will install the current "shipping" version of u-boot for our BeagleBone BLacks': https://github.com/beagleboard/u-boot/commits/v2019.04-bbb.io-am335x
Sep 22 00:07:34 <the_person48> ok, got it
Sep 22 00:07:46 <zmatt> the_person48: why exactly are you using an obsolete version of debian again?
Sep 22 00:07:47 <the_person48> don't have access to ethernet right now for beaglebone but I can do that later
Sep 22 00:08:10 <the_person48> because my coworkers have used it succesfully before and already vetted it through all our bureacracy
Sep 22 00:08:18 <the_person48> it's not really up to me unless I show that it can't be done
Sep 22 00:08:29 <rcn-ee> the_person48, ah right! Ethernet.. why are you doing this project again?  talk about so many handycaps, no serial, no etherenet...
Sep 22 00:08:49 <the_person48> well I do usually have ethernet just not where I am literally right now
Sep 22 00:09:21 <rcn-ee> your on irc, bridge your device?
Sep 22 00:09:49 <zmatt> the_person48: anything "can be done", it's just that starting a new project with something that's already obsolete and largely unmaintained right from the start is lunacy
Sep 22 00:09:56 <the_person48> I'm not opposed to that but have never figured out how to do it succesfully
Sep 22 00:10:03 <the_person48> believe me, I agree, it's just not up to me
Sep 22 00:10:26 <zmatt> like, I can understand people don't want to update if they're using debian stretch and already have large numbers of devices deployed into the field
Sep 22 00:10:27 <the_person48> I understand it must be frustrating to work with for you guys
Sep 22 00:10:46 <the_person48> yeah
Sep 22 00:10:48 <rcn-ee> it's always upto the developer... Customer wants something, it's up to you to deliver and charge them for it. ;)
Sep 22 00:10:56 <the_person48> haha
Sep 22 00:10:57 <the_person48> true
Sep 22 00:11:21 <zmatt> yes it is, please be sure to make it clear that it is in fact frequently causing unnecessary problems
Sep 22 00:11:41 <zmatt> (frustrating to work with, that is)
Sep 22 00:11:42 <the_person48> I am and will continue to communicate that
Sep 22 00:11:50 <the_person48> yeah I feel you and appreciate the continued support
Sep 22 00:11:55 <rcn-ee> and don't forget to invoice them "for their insane handicaps"...
Sep 22 00:12:06 <the_person48> will do ;)
Sep 22 00:12:27 <the_person48> ok, so when I do get back where I have ethernet
Sep 22 00:12:31 <the_person48> I will:
Sep 22 00:12:35 <the_person48> sudo apt update
Sep 22 00:12:40 <the_person48> sudo apt install bb-u-boot-am335x-evm
Sep 22 00:12:52 <the_person48> sudo /opt/u-boot/bb-u-boot-am335x-evm/install.sh
Sep 22 00:12:55 <the_person48> then reboot
Sep 22 00:13:07 <rcn-ee> you might have a problem with apt, i forget when "apt" offically supported that.. so you might have to use apt-get ...
Sep 22 00:13:12 <the_person48> then the uboot loader should be newer and hopefully not have this weirdness?
Sep 22 00:13:27 <the_person48> gotcha, I think apt is working on this one but will use apt-get if necessary
Sep 22 00:13:27 <rcn-ee> but ever since i don't waste time with the extra 4 characters..
Sep 22 00:13:30 <zmatt> I think apt was in stretch already?  I'm not sure, it's been so long ago
Sep 22 00:13:48 <the_person48> yeah I think it's here
Sep 22 00:14:10 <zmatt> I generally don't linger on the past that long
Sep 22 00:14:19 <zmatt> :P
Sep 22 00:14:20 <the_person48> but yeah, so you guys think that the reason cape_universal is enabled despite the /boot/uEnv.txt is probably cause of the version of the uboot loader?
Sep 22 00:14:23 <the_person48> for sure
Sep 22 00:14:34 <rcn-ee> the_person48, a newer version of u-boot should have most of the "things" stabliized, when i first wrote those patches in 2018.03 they were "very" beta... and we hadn't worked out every combination..
Sep 22 00:14:41 <rcn-ee> that's where a serial cables helps debug.. ;)
Sep 22 00:14:45 <the_person48> ok
Sep 22 00:14:52 <the_person48> well I'll update and then let you guys know how it goes
Sep 22 00:15:01 <the_person48> and when I have a serial cable as well but that'll be a lot longer
Sep 22 00:15:34 <rcn-ee> even a rpi's serial usb adapter would work, some stores have them in stock..
Sep 22 00:16:08 <the_person48> got it, ok maybe there's an easier way to find one
Sep 22 00:21:06 <set_> Hey wait...
Sep 22 00:21:17 <set_> Should I know about the evm too w/ uboot?
Sep 22 00:22:47 <set_> Hello? Echo, test, one two. Is this thing on?
Sep 22 00:26:31 <zmatt> set_: the u-boot am335x-evm board target is also used for all beaglebone variants, that's how it's always been
Sep 22 00:26:56 <zmatt> (it auto-detects which board it's actually running on)
Sep 22 00:27:09 <zmatt> so no, you don't need to know anything about the evm
Sep 22 00:27:41 <zmatt> it's just a poorly named u-boot target, it ought to be am335x-generic or something like that :P
Sep 22 00:27:42 <set_> Oh.
Sep 22 00:27:50 <set_> Got it.
Sep 22 00:28:00 <set_> Good, phew. I thought I had to learn more at your expense.
Sep 22 00:28:01 <set_> Ooh.
Sep 22 00:28:09 <set_> Just kiddin'.
Sep 22 00:29:10 <set_> Speakin' of just kiddin', I cannot get this darn flying Blue to take place. Luckily for me, a more experienced person is going to be helping (hopefully).
Sep 22 00:30:04 <set_> Seems plausible and undeniably justified. Anyway, off to test things to make sure I have something say.
**** ENDING LOGGING AT Wed Sep 22 02:59:57 2021