01:54 <TheConceptBoy> Good evening, everyone.

01:55 <TheConceptBoy> I've gotten a fresh installation of beaglebone black debian

01:55 <TheConceptBoy> I went with the website advertised version instead of the nightly builds this time due to a library dependency being made for that version

01:56 <TheConceptBoy> I need to grant debian user permissions to gpio

01:56 <TheConceptBoy> I'm not sure why it's not already there by default

02:00 <TheConceptBoy> The reason I suspect it's the permissions is because of a python error

02:00 <TheConceptBoy> ValueError: Set gpio mode failed, missing file or invalid permissions.

02:00 <TheConceptBoy> it mentions permissions so that's what I'm on to checking first

02:04 <TheConceptBoy> Also, on an unrelated question

02:04 <TheConceptBoy> what's the point of root if everything can be sudo overwritten

02:09 <TheConceptBoy> hmm... I'm honestly this close to just abandoning linux altogether, going back to esp32, slapping a big ass spi ram chip so I can work with json data and stick wit the land where everything... just... works...

03:01 <set_> Hello!

03:01 <set_> Do not give up on Linux.

03:01 <set_> Use udev rules instead.

03:03 <set_> TheConceptBoy: I think the missing permissions are due to an error in udev or the older firmware that one may be using.

03:04 <set_> Anyway, w/ power comes responsibility. Right!

03:05 <zmatt> sounds like it failed changing the pin mode, which suggests to me maybe he was trying to use a pin that was already in use e.g. for hdmi

03:09 <set_> oh!

03:09 <set_> That makes sense.

03:10 <set_> he seems agitated. Linux can get the best of 'em!

03:10 <set_> Maybe some cool soothing music?

03:10 <set_> hummmmm. Clank but w/out the bang, bang?

03:14 <set_> Soothing music calms the calamity of Linux when things get adjusted in a manner in which needs special attention.

03:14 <set_> @zmatt: I thought you already told him about the uEnv.txt file that is available on the beagleboard.org images?

03:26 <set_> is pathlib broken w/ the newer images?

03:30 <set_> never mind me.

03:31 <set_> It seems w/ the newer images, blah.

04:47 <zmatt> no?

05:01 <set_> no?

05:02 <set_> @zmatt: Today was Thanksgiving. I am thankful for you and our kind words.

05:02 <set_> Yes. our.

05:02 <set_> Ha.

05:03 <set_> Anyway, I was using libgpiod again on the newer images w/ a .dts file but the .dts file was a sysfs file.

05:03 <set_> So, things broked.

05:03 <set_> Blah.

05:12 <set_> I was using the RelayCape and found that the CIS (Cape Interface Spec) is using sysfs instead of libgpiod for writing a .dts file.

05:12 <set_> Anyway, this is common still! Phew.

05:12 <set_> At least the libgpiod file I wrote does not keep the gpio high now when the file exits/ends.

05:13 <set_> It used to keep the pin high. Now, it just breaks the gpio pin, still, but not as a floating high pin.

05:13 <set_> It returns low.

05:22 <ds2> happy thanksgiving!

05:27 <zmatt> set_: it sounds like all of your problems are caused by using libgpiod... have you considered the simple fix of not using libgpiod ?

05:37 <set_> Yes

05:37 <set_> I have considered it.

05:37 <set_> Hey ds2.

05:37 <set_> Happy thanksgiving.

08:44 <Guest9165> i want to start internet on BBB connected to ubuntu 18.04

08:45 <Guest9165> what steps i have to perfrom

12:54 <Guest9196> hi

12:54 <Guest9196>  i want to connect to internet from BBB

12:55 <Guest9196> internet running on ubuntu Linux 18.08

12:55 <Guest9196> 18.04

12:55 <Guest9196> please reply , what the steps i have to perfrom

12:55 <set_> Hello.

12:57 <set_> Guest9196: I think the beagleboard.org people have shied away from Ubuntu to dive deeper in Debian for their images.

12:57 <set_> Let me see if I can find something.

12:58 <set_> Here is a wishbone: https://repos.rcn-ee.com/ubuntu/

12:59 <set_> Now, I cannot tell you that will work b/c I have not tested it recently.

13:11 <zmatt> he meant ubuntu on his host pc I'm pretty sure, not on the bbb

13:11 <zmatt> Guest9196: if the bbb is connected via ethernet to your pc, and your pc has internet via wifi, then you need to enable internet sharing to share your pc's internet to the bbb

13:14 <zmatt> I'm off to work, afk

15:00 <Parduz> Hello, i'm struggling with a BBB which does not reads some USB drives (or better, reads only the one i've shipped with it, and not any of the drives the Korean customer tried)

15:00 <Parduz> I've found this very old thread:

15:00 <Parduz> https://beagleboard.narkive.com/lT3z4Vmy/caution-musb-babble-interrupt-occurred

15:00 <zmatt> are you actually seeing babble errors in the kernel log?

15:00 <Parduz> i would like to know if the USB problem discussed there is still an issue or was solved.

15:01 <zmatt> babble is generally a hardware issue

15:01 <zmatt> but I haven't really heard people talking about it in many years, I'm pretty sure the current kernel driver recovers from them

15:02 <zmatt> what are you actually seeing in the kernel log?

15:02 <Parduz> zmatt: i dont have ANY access to the BBB there. All i know is that my kiosk app does not automatically shows the drive content, which to me means that the sda1 was not mounted by the system

15:02 <zmatt> is the usb stick FAT-formatted?

15:02 <zmatt> (and not exFAT or NTFS)

15:02 <Parduz> yes, FAT32

15:02 <Parduz> but mine here works also with NTFS.

15:03 <zmatt> k

15:03 <Parduz> anyway, we told the customer to format with Fat32

15:04 <Parduz> there's this line in FSTAB: /dev/sda1 /media/usb auto user,uid=1000,gid=1000,fmask=0137,dmask=0027,noauto 0 0

15:05 <Parduz> and my app check for the media folder every second and shows the content when the folder exists.

15:08 <Parduz> "but I haven't really heard people talking about it in many years, I'm pretty sure the current kernel driver recovers from them"

15:08 <Parduz> I found that thread 'cause i've see the word "babble" in dmesg on my BBB here. It happened when i removed the USB drive, so i'd say that it should not be related to the old babble issue. Am i right?

15:08 <zmatt> that just sounds like an electrical glitch as you removed the usb drive

15:08 <Parduz> yup.

15:09 <Parduz> but i'm still unable to think at any cause of my problem there in Korea.

15:10 <Parduz> the kernel for Debian 10 was already patched for the "babble" problem?

15:10 <zmatt> that's going to be very hard to debug without having one of 1. access to the bbb, 2. access to logs, or 3. access to an usb stick that exhibits the problem

15:11 <zmatt> I have no idea, but the babble issue was afaik limited to fairly specific hardware scenarios, I don't think it ever happened simply with a usb stick

15:12 <Parduz> ues, i see. what i meant is if you never heard of the problem from before Debian 10 or after

15:12 <zmatt> I don't remember

15:12 <Parduz> kk

15:12 <Parduz> thanks

15:58 <Guest20> Hi everyone! I'm new to Beagle and am now working with a BeagleBoneBlack. My beagle was shipped with Debian 10 on the eMMC and what it seems like there is no FAT partition so the SPL and U-Boot would be written in RAW somewhere on the eMMC. Does anyone have a memory layout for the eMMC, i.e. where are SPL, U-Boot and (especially) U-Boot enviroments

15:58 <Guest20> written on the eMMC? I cannot find this information anywhere online. Must urgently I now need to configure /etc/fw_env.config so I can use fw_setenv. Later on I will also need to overwrite SPL as well as U-Boot (using dd). Any help would be greatly appreciated!

16:03 <zmatt> Guest20: why not just completely reflash eMMC with a new image?

16:03 <zmatt> and the default u-boot on beagleboard.org images do not support persistent environment

16:04 <Guest20> Aaah ok well that explains a lot already

16:04 <zmatt> oh wait you have the latest image, I keep thinking debian 10 is older than buster

16:04 <zmatt> SPL with configuration header is at sector offset 256, u-boot.img is at sector offset 768

16:06 <Guest20> I cannot do a complete eMMC reflash as I will use my own custom Linux rootfs that I have cross-compiled and my eMMC will be divided into two partitions and to support system update. Then after every update I will use fw_setenv to set a persistens variable that U-Boot will use to know which partition to boot.

16:07 <zmatt> I see, then you may need to build u-boot yourself

16:08 <Guest20> zmatt thanks! So in the latest Debian image (U-boot is at U-Boot 2019.04-00002-g31a8ae0206 (May 13 2020 - 09:26:17 -0500), Build: jenkins-github_Bootloader-Builder-139) there is no support to for persisting U-boot enviroment?

16:09 <zmatt> correct, it only supports the built-in environment

16:11 <Guest20> Ok thanks once again! Saved me a lot of trouble trying to find what cannot be found :) I will tweak my own SPL and U-Boot binaries a bit still to make sure the will support persistent variables and then dd them into the memory sectors and hope for the best that it will boot