00:55 <vd> set_ don't worry that's a public channel ;-)

01:08 <set_> The public!

01:25 <vd> zmatt given the datasheet, it looks like serveral usb hubs are plugged into the expansion headers and their "5V_EN#" lines are wired to non-usb pins of the expansion headers, like P8 7, 9, 16, 18... How would you describe that in the device tree?

01:27 <zmatt> that's a bit too vague to give a meaningful answer... is there anything the kernel is expected to do with those lines at all? why do they exist? normally usb hubs are auto-discovered and fully controlled via usb, so they do not have a presence in DT

03:02 <vd> zmatt sorry for the delay. I really thing these are only unused expansion pins used as power inputs for the usb hub. They do are discovered actually I think. But I was wondering if I should use GPIO mode or maybe an unused mode to "reserve" these lines somehow

03:09 <zmatt> mainline kernels are rather deficient in good ways for working with random gpios... bb.org kernels have gpio-of-helper for that purpose which names and initializes gpios per DT configuration and exports them to userspace. mainline does have the clumsy "gpio hog" mechanism to force gpios to a particular level, but they're not devices so you can't associate pinmux with them directly, the best you can ...

03:09 <zmatt> ...do is just attach pinmux to the gpio controller itself (even though this is kind of clumsy and seems self-referential, although it does work in practice)

03:09 <zmatt> you can also leave them unused and undeclared entirely, if they do not have to be driven (i.e. have external pull-downs)

03:15 <vd> ok so you won't touch them if "things work"

03:15 <vd> otherwise, gpio mode

03:28 <zmatt> I mean, I'm mostly just guessing based on your limited description

03:29 <zmatt> however I wouldn't use "things work" as an indication they're configured correctly

03:30 <zmatt> also, I'd use a gpio-of-helper since I do use a bb.org kernel (with custom config and patches)

03:36 <vd> I'll jump right away to the buttons ("gpio-keys" I presume) which must be way simpler

03:37 <zmatt> I mean the problem is that I don't know if what you need to do with those enable-lines is simple since you haven't stated what they're for or how they're to be used

03:38 <vd> I can look up what pins they connect to on the usb device side

03:38 <zmatt> and I can't remotely read the mind of your hardware designer

03:39 <zmatt> I'm also going to sleep anyway

03:40 <vd> zmatt thanks a lot again for your help!

14:29 <BorikGor> Hi everyone. I've got a BBB with an Angstron installed on it. I'm trying to install the latest Debian onto it, but for some reason it doesn't work.. :(

14:30 <zmatt> if it's refusing to boot from sd card, power on while holding down the S2 button (the one closest to the sd card slot), you can let go once the power led turns on

14:31 <BorikGor> I think it finally worked.. :) I got the Debian login screen iover a new COM port..

14:31 <BorikGor> Thanks, mate! :)

14:31 <zmatt> also, if you've previously tried to edit /boot/uEnv.txt to convert a standalone sd card image into a flasher... it happens every now and then that people accidently edit the one on eMMC rather than the one on sd card, possibly resulting in the system flashing eMMC onto SD card.

14:32 <BorikGor> Never got the chance to access uEnv.txt.. This is the first time it asked me for Debian access credentials.. :)

14:32 <zmatt> if you managed to boot from sd card, use "sudo blkdiscard /dev/mmcblk1" to wipe eMMC so the ancient system there can't cause any more trouble

14:33 <BorikGor> I've been at it for the last couple of hours.. As soon as I ask for help everything start to work.. XD

14:33 <zmatt> for future reference, instead of download a standalone sd card image and editing /boot/uEnv.txt to turn it into a flasher, there are also ready-to-go flasher images available for download

14:33 <BorikGor> zmatt, thanks for the tips and for you attention!

14:33 <BorikGor> I hope I won't have to bother you again.. :)

14:34 <BorikGor> I've downloaded the image linked here:

14:34 <BorikGor> https://beagleboard.org/latest-images

14:34 <zmatt> that page has both standalone and flasher images

14:34 <BorikGor> I got the "AM3358 Debian 10.3 2020-04-06 4GB SD IoT"..

14:34 <zmatt> yep that would be the standalone image

14:35 <BorikGor> That's standalone, I think... right?

14:35 <zmatt> the flasher is a bit further down, "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher"

14:35 <zmatt> the only difference is that one line in /boot/uEnv.txt

14:36 <BorikGor> Cool, I need it with GUI right now.. Maybe later, when I'm more confident about the whole stuff.. :)

14:36 <zmatt> so there's no reason to download the flasher now, but it's useful to know in case you need one in the future

14:36 <zmatt> none of the images include a GUI

14:36 <BorikGor> The flasher is smaller and boots faster, is it not?

14:36 <zmatt> no

14:36 <BorikGor> Oh.. Then I'm in for a surprise.. :)

14:36 <zmatt> flasher just means it'll automatically reflash eMMC

14:36 <zmatt> instead of booting normally from sd card

14:37 <BorikGor> Oh, that's Special images, I was referring to.. :)

14:37 <zmatt> the special images are.. special. don't get those unless you have a specific reason to get one of those and know what it is

14:38 <zmatt> maybe you're thinking of console images? those are minimal images for people who prefer to just manually install whatever packages they need

14:39 <BorikGor> Though as much.. :)

14:39 <BorikGor> The console image is a tempting offer.. :)

14:40 <BorikGor> But I think I'll spend a few weeks on it installing the stuff I need, instead of doing what I need to do right now.. :)

14:40 <BorikGor> So, I'll stay with the recommended one for now..

14:40 <zmatt> GUI is not included anymore as it takes up a ton of space and is not particularly useful, people generally don't connect keyboard/monitor to the BBB, they just connect to it via ssh (or, in case of the IoT image, the web-based IDE)

14:40 <BorikGor> But it's good to know there are such "naked" images available for BBB... Thanks for the info!

14:41 <zmatt> yeah they're meant for people who are already comfortable with debian... for whom installing a few packages isn't going to take weeks, nor days, nor hours probably

14:41 <BorikGor> That's a bummer, regarding the GUI.. I was just meaning to connect it to my not smart TV and try stuff with it, using a wireless keyboard/mouse..

14:42 <zmatt> sounds like a very uncomfortable way to use it

14:42 <zmatt> the SoC on the BBB was designed for industrial applications, its video capabilities are... rather minimal

14:43 <BorikGor> apk-install is in my muscle memory, but I have no idea what is it exactly that I need to install, so googling and understanding the search results, that's what's going to take me a ton of time.. :)

14:43 <zmatt> basically just meant for simple touchscreen interfaces... it doesn't even have hardware mouse cursor support

14:43 <BorikGor> Oh, that's good to know.. Thanks..

14:44 <zmatt> it's definitely not designed to be used as a desktop computer

14:44 <zmatt> that doesn't mean you can't of course

14:44 <zmatt> but I don't see why I'd use the BBB as a terrible desktop pc instead of using... an actual desktop pc, or my laptop

14:45 <BorikGor> No, not a PC, of course, but I thought to run the programming environment using the HDMI and do stuff there, instead of connecting to it via SSH..

14:45 <zmatt> I mean, that *is* typical work for a desktop pc

14:46 <zmatt> though like I said, there is a web-based IDE you can access via a web browser instead of ssh'ing in

14:46 <zmatt> (I don't have any experience with it so dunno how well it works)

14:47 <zmatt> I'm pretty sure there are also IDEs which allow you to work locally and automatically sync files to the remote system

14:47 <zmatt> or even compile locally and run the executable on the remote system (though that's generally more work to setup)

14:47 <BorikGor> Never knew those existed, to be frank.. :)

14:48 <zmatt> I'm personally fine with vim and makefiles so I don't have any advice to offer for such IDEs, but I know it's a thing

14:51 <BorikGor> But isn't VIM is like direct connection, only a tad slower, because of connecting over the network?

14:51 <zmatt> vim is a text editor

14:51 <BorikGor> Oh, I thought you were referring to VNC, sorry.. %)

14:53 <BorikGor> Is there any indication of the flashing process? When it's done, for example?

14:54 <BorikGor> I've just changed the uEnv.txt file and rebooted the BBB...

14:54 <zmatt> while it's flashing the leds show a distinctive back-and-forth pattern across all four leds (sometimes referred to as "cylon" or "knight rider" if either of those references is familiar to you), when complete it will automatically power off

14:54 <zmatt> (all four leds flashing at the same time indicates a failure)

14:56 <BorikGor> Knight Rider... :) Once done a simple project for a friend with a Microchip and a spare brake light to turn his VW jetta into a knight vehicle.. :D That was fun..

14:57 <BorikGor> What if I see only the User2 LED ON and the rest are off?

14:57 <BorikGor> Does that mean anything?

14:57 <zmatt> sounds like it crashed during very early boot

14:58 <zmatt> possibly you messed up the line you edited

14:58 <BorikGor> That's a bummer..

14:58 <zmatt> maybe just download a pre-made flasher image instead ;)

14:59 <BorikGor> The uEnv should be accessable from other system, right?

14:59 <zmatt> sure, you can try to fix it

14:59 <BorikGor> If I have to reburn that SD card, I'll download the prebuilt.. :)

15:00 <BorikGor> Yeah.. Win10 can't handle partitions not meant for MS.. XD

15:00 <zmatt> correct

15:01 <BorikGor> I can boot the BBB and then mount the SD card, can't I?

15:03 <zmatt> if you ignored my advice of wiping eMMC then yes

15:04 <BorikGor> Oh, I forgot about it.. Turned out for the best.. :)

20:43 <vd> should you ideally disable the pinmux you're not using? i.e. the ones that are not connected to anything on the daughter board?

20:45 <zmatt> I have no idea what you mean by "disable the pinmux"

21:02 <vd> zmatt like when there's a red cross on an expansion header pin on the datasheet, meaning it's unused/not connected

21:02 <vd> Is there like a "disabled" mux mode you should use for that ?

21:02 <zmatt> no

21:03 <zmatt> I'd just leave them at default (gpio with default pull)

21:04 <vd> ok

21:12 <vd> if it's physically not connected there's no risk anyway