vd has quit [Quit: Client closed]
vd has joined #beagle
<vd> damn web client
<set_> Okay, okay...is there anyone, anyone at all, who can tell me what to get for a BBAI in the form of an image, i.e. beagleboard.org, something else, maybe other things?
<set_> I am interrupting and I know it. Please excuse me.
<set_> The reason I ask is this...
<set_> I have flashed five images during a course of a few hours. Is that normal?
<set_> I cannot get the 5_10 kernel to boot yet.
<set_> Forget it. I will keep trying.
<set_> sorry for interjecting on my own behalf. Carry on young lads!
* GenTooMan tosses more carrion out to add to the fodder?
<mattb0ne> linux does not need to be defraggebut I feel my prgorgam performance is limited by the io of saving stuff to a disk
<mattb0ne> whcih gets worse as I fill up
<set_> TOddy for thebody?
<set_> GenTooMan: I celebrated you leaving the other day...you never did reply until now.
<set_> Spankx.
<set_> It seems 5_10 is up and runnin' now.
<set_> Odd.
<set_> But...I am going for 5.4.x
<set_> Fish snips should be a cracker of a good time?
<GenTooMan> well hopefully not twice as crumby though.
<set_> GenTooMan: What are you doing?
<set_> are you ing'ing?
<set_> Oh.
<set_> On the TISDK, I cannot for the life of me figure out why halt does not turn the board off w/ Arago.
<set_> I read some docs. on it. BBAI is compatible but when I read other docs, unpopulated in the present, there is no mention of CCS 10 and BBAI.
<set_> fodder!
<set_> Sir, what is fodder?
<set_> Just for giggles, this is not a smear campaign.
Guest9145 has joined #beagle
<GenTooMan> actually working on a complimentary symmetry audio amplifier using a pair of FETs to feed high power BJTs. Kind of tricky to bias unfortunately.
<set_> Nice!
<GenTooMan> at least it isn't oscillating at 1MHz anymore.
<set_> See, I celebrate in your doing awesome along w/ leaving (knowing you will be back).
<set_> Hmm.
<Guest9145> My BBBlack cant connect by usb on my laptop with ubuntu 20.4 .What can i verify to resolve
<set_> GenTooMan: My guess was that 1MHz is too slow for your entire endgame on the contraption.
<GenTooMan> Guest9145, are you powering it separately or from the USB port?
<set_> <<< Knows little on speed vs. sizing.
<Guest9145> no i use only usb port
<set_> I mean...I read about heap, static memory, and data a little.
<set_> There is like 20 + different kinds of heap.
<set_> excuse me guys/gals. My ongoing effort is getting me to interrupt.
<GenTooMan> can you tell of the BBB is starting up?
<GenTooMan> Guest9145, can you tell of the BBB is starting up?
<Guest9145> yes, explain better my BBB not take the ip
<set_> LEDs! near the Ethernet Port!
<Guest9145> they are working
<set_> try beaglebone.local or if on WIN, a COM port?
<Guest9145> The problem is with ubuntu , on win7 the BBB work fine
<set_> I think it is, right, w/ port 22?
<set_> Let me check.
<GenTooMan> it's so much easier with a ethernet switch. Hmm you don't have console access obviously. I suggest you use zenmap with the intense scan setting.
<GenTooMan> just to see if it's showing up as something different than anticipated (or at all).
<Guest9145> the so inform that cant conect with the port 22 by ssh
<set_> ssh debian@ <<<
<set_> For linux!
<set_> simple yet effective!
<set_> Right...zenmap?
<set_> Sorry GenTooMan...I keep interrupting.
<GenTooMan> zenmap scans all possible IP's on your network you may wish to use 192.168.*.* for the target also
ikarso has quit [Quit: Connection closed for inactivity]
<set_> oh.
<Guest9145> many thks I try with debian@ tomorrow and consult again.Regards!
<GenTooMan> gnight!
Guest9145 has quit [Quit: Client closed]
<set_> ApeSt yle Numeri c Jokes!
<set_> GenTooMan: Can we still chat?
<GenTooMan> I allow you to talk for the moment ;)
<set_> Fine.
<set_> I always like to kid and joke. But...people are having real concerns and my issues are minimal.
<set_> For instance, I kept chatting w/ this fellow b/c I forgot how to do things.
<set_> now, when I learn how to do stuff, then take notice. No fair!
<set_> Oh, oh, oh.
<set_> GenTooMan: Can you get tensorflow on you BBAI or BBB?
<GenTooMan> only if I install AI simulation and development software on them.
<set_> Now, what does that mean? Oh. It is your choice?
<GenTooMan> right :D
<set_> Not just any AI...oh.
<GenTooMan> I'm not doing much with AI based things, at this time so not at this time. :D
<set_> There, deep in the source, is a heap section in Tensorflow Lite and I cannot find it.
<set_> I found a way to get only so far. 8%.
<set_> Maybe searching the source w/ another file could prove useful?
<set_> I think there are many libs. in my kernel that cmake does not show available...
<set_> I need to run ./configure into a file. Sheesh. WHen will I learn?
<set_> 2>?1
<set_> Off to read.
CrazyEddy has quit [Ping timeout: 240 seconds]
<set_> bash time!
<set_> yes...I typed that out.
CrazyEddy has joined #beagle
<set_> double chevron!
<set_> nOpe.
mastermind__ has joined #beagle
mattb0ne has quit [Ping timeout: 252 seconds]
mastermind__ has quit [Remote host closed the connection]
mastermind__ has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
mastermind__ has quit [Remote host closed the connection]
SymbioticFemale has joined #beagle
<SymbioticFemale> wc
SymbioticFemale has left #beagle [#beagle]
ikarso has joined #beagle
mapache has joined #beagle
mapache has quit [Quit: Client closed]
ikarso has quit [Quit: Connection closed for inactivity]
Guest2930 has joined #beagle
Guest2930 has quit [Client Quit]
florian has joined #beagle
<zmatt> ssh'ing to "beaglebone.local" should definitely work on an ubuntu system, regardless of how the BBB is connected
<zmatt> but maybe they were using an ancient ubuntu whose ancient network manager didn't support using multiple interfaces at the same time, and therefore it doesn't bring up the usb networking interfaces (since doing so would disconnect you from your current network connection)
Shadyman has quit [Remote host closed the connection]
starblue has quit [Quit: WeeChat 3.0]
vitorio has quit []
vitorio has joined #beagle
otisolsen70 has joined #beagle
lucascastro has quit [Ping timeout: 245 seconds]
lucascastro has joined #beagle
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #beagle
charlie5 has quit [Ping timeout: 244 seconds]
lucascastro has quit [Ping timeout: 252 seconds]
buzzmarshall has joined #beagle
charlie5 has joined #beagle
lucascastro has joined #beagle
lucas_ has joined #beagle
lucas_ has quit [Read error: Connection reset by peer]
lucascastro has quit [Ping timeout: 244 seconds]
lucas_ has joined #beagle
lucas__ has joined #beagle
lucas__ has quit [Remote host closed the connection]
lucas_ has quit [Ping timeout: 244 seconds]
lucascastro has joined #beagle
lucas_ has joined #beagle
lucascastro has quit [Ping timeout: 256 seconds]
lucascastro has joined #beagle
lucas_ has quit [Ping timeout: 256 seconds]
lucas_ has joined #beagle
lucascastro has quit [Ping timeout: 245 seconds]
giort has joined #beagle
lucas_ has quit [Remote host closed the connection]
lucas_ has joined #beagle
lucas_ has quit [Ping timeout: 252 seconds]
charlie5 has quit [Ping timeout: 244 seconds]
giort has quit [Quit: giort]
the_person48 has joined #beagle
<the_person48> hi everyone, I am using a beaglebone black, rev C, that I am trying to put debian 11 (bullseye) on. I was using 10 (buster) before, and that worked. but I want to use gcc/g++ 11, which apparently is only compatible with bullseye
<the_person48> I installed this image onto a microSD card: https://rcn-ee.net/rootfs/debian-armhf/2021-09-01/ (first one)
charlie5 has joined #beagle
<the_person48> then booted from it by holding the user boot button. However, the only way I am able to access the BB is via a keyboard and monitor
<the_person48> I tried sshing but that doesn't work
<rcn-ee> did fix your network? not sure why it's not working for you..
<the_person48> on the keyboard and monitor setup, it tells me that the ethernet connection is unavailable
<the_person48> no, this is the same issue as yesterday
<rcn-ee> okay.
<the_person48> but the same ethernet cable/connection works for other devices, and it also worked for this beaglebone with image 10
vd has quit [Quit: Client closed]
vd has joined #beagle
<the_person48> ok, so I installed the new release from today, now I have internet
<the_person48> I'm trying to flash the eMMC, which rcn-ee suggested I do with dd yesterday
<the_person48> but having trouble unzipping the image file first, the image doesn't have xz-utils and tells me "no installation candidate" when I try to install it
<the_person48> any idea what that's about? maybe it depends on something I don't have?
<zmatt> have you done apt-get update ?
<the_person48> no, good idea
<zmatt> (to download the package lists)
<the_person48> good call, doing that now
<rcn-ee> the_person48, why are you installing to eMMC? aren't you going to install gcc-11 and then build something big?
<rcn-ee> just leave it on the microSd..
<the_person48> ok, yeah that worked
<the_person48> I am told that the eMMC is more reliable
<the_person48> I don't know if there will be enough room but that's part of what I'm trying to figure out
<rcn-ee> and slow as shit..
<rcn-ee> it's 99.9999 vs 99.999 doesn't matter..
<zmatt> I'd install to eMMC and only use sd card for extra space if really needed... eMMC has twice the read performance of SD on the BBB
<zmatt> the old micron eMMCs were slow
<rcn-ee> i'm just thinking the_person48 going to run out of space on 4Gb when building his project..
<the_person48> if that happens it's ok, we'll use the SD card if we have to
<the_person48> but the goal is to see if everything can fit on the eMMC to start
<rcn-ee> df -h would tell you the install size..
<zmatt> I simply used apt to upgrade to bullseye fairly recently, iirc without significant problems. this is on a custom image once upon a time based on one of the standard console images (probably stretch?)
<the_person48> I didn't realize I could upgrade to bullseye just with apt
<the_person48> if this doesn't work I'll try that
<zmatt> the end result is probably not quite the same though...
<the_person48> how so?
<zmatt> e.g. it won't update u-boot, on bbb images it also doesn't update the kernel (though you can install a newer version with apt, and there's a script to do that for you), and things like config defaults may have changed
<zmatt> things that aren't part of the debian distro, just part of the newer image
<zmatt> e.g. /boot/uEnv.txt
<zmatt> in my case that didn't matter since I'm running a custom u-boot and kernel anyway
<the_person48> gotcha
<the_person48> would it allow ssh'ing through the micro-USB to USB cable?
<the_person48> the main complication I've run into with this image so far is not being able to do that (assuming that regular ssh'ing through ethernet works now, which it should but haven't confirmed yet)
charlie5 has quit [Ping timeout: 244 seconds]
the_person48 has quit [Quit: Client closed]
<zmatt> dunno, I'd assume so? upgrading via apt should leave the system as similar as possible
<zmatt> but you'd need to ask rcn or just Try It And See
the_person48 has joined #beagle
<zmatt> or just fix usb networking
<rcn-ee> and most of the "beagleboard.org" packages don't exist in bullseye, so an upgrade will just leave the old version present..
<the_person48> sorry I lost connection for a minute
<the_person48> last message I see is "or just fix usb networking"
<zmatt> the_person48: https://pastebin.com/VLfM7fQQ
<the_person48> thanks
<zmatt> like, bbb images normally use a complicated startup script to create a composite usb device, but you can also just disable that entirely and add g_ether to your /etc/modules :P as long as your host pc isn't a mac it'll get the job done
<zmatt> well, and arrange for suitable configuration for the interface of course
<the_person48> it is not a mac, I'm running ubuntu
<rcn-ee> zmatt, thanks to support of udc in systemd, that script is nuked in bullseye. ;)
<zmatt> sweet
<rcn-ee> part of the reason the_person48 is having problems... he's expecting usb0 etc to be setup, i'm still working on that..
<the_person48> yeah I was asking if the apt version of debian 11 would have that, but I think I lost the answer when I lost connection
<rcn-ee> have what? the complex boot script.. it's gone..
<zmatt> if replace whatever network manager is installed by systemd-networkd it's pretty trivial to configure the interface to make it work (see https://pastebin.com/3tjj3v3R )
<zmatt> *if you replace
<the_person48> would have usb0 ssh capabilities
<zmatt> there's no such thing as "ssh capabilities", if you have a working network connection to the bbb you can ssh to it
<the_person48> ok, so then set up the USB0 then, which I think you just answered
<rcn-ee> the_person48, usb0 is setup in bullseye... look at zmatt 's pastbin.. the "/etc/systemd/network/usb0.network" change should activate it after a reboot..
<rcn-ee> ignore the "//etc/modules-load.d/gadget.conf" change, that's taken careof..
<rcn-ee> gadget-acm-ecm -> two serial gadets and usb0.. from: https://github.com/linux-usb-gadgets/libusbgx
<zmatt> (I definitely wouldn't suggest trying the procedure in my pastebin on any image other than the current debian buster images unless you know exactly what you're doing)
<zmatt> rcn-ee: I feel like there must be a better way of doing this
<rcn-ee> usb serial console in 5 seconds from power up. ;)
<zmatt> lol why are you running depmod -a right before printing an error and exiting
charlie5 has joined #beagle
<rcn-ee> i do like your systemd-network usb0, i've been stuck on network-manager to auto do that..
<zmatt> systemd-networkd is really nice
<rcn-ee> it 'should' never hit that.. the module is built-in as of last week, and it's been built as module for many years.. the depmod -s is more i just give up..
<rcn-ee> network-manger want's usb0 + uuid in it's config.. where as sytemd-network just wants usb0
<zmatt> systemd-networkd allows pretty flexible matching rules
<zmatt> e.g. I have a server setup to automatically bring up *every* usb networking interface and plug them into a bridge
<the_person48> ok, I tried following the pastebin, but I'm running into issues on the first set of commands, 16-25
<the_person48> tells me permission denied even though I added sudo
<zmatt> the_person48: please don't try to follow the pastebin on bullseye
<the_person48> oh ok
<zmatt> rcn-ee: and the setup for that is: https://pastebin.com/raw/bb6ergVk
<rcn-ee> With Bullseye, we make this very clean... usb-gadget.target -> fires bb-start-usb-gadgets script (loads usb0/usb1) -> fires systemd-networkd for usb0/usb1 dhcp ;)
<zmatt> what's /usr/bin/gadget-acm-ecm ? is that another script?
<zmatt> ah bullseye already uses systemd-networkd?
<rcn-ee> i've nuked connman for network-manger... (for the wifi config)... but if systemd-networkd simplfies usb0/usb1.. (this is all because systemd got usb-gadget.target)
<rcn-ee> yeah, bullseye is becoming a blank slate to reboot the image..
<zmatt> just configure wpa_supplicant directly, it's really easy
<rcn-ee> do we think users will understand that? connman/nm have a console gui..
<rcn-ee> (for wifi)
<rcn-ee> or since everyone has a pi, and they use wpa_supplicant, we can assume they will figure it out now?
<zmatt> manual wpa_supplicant.conf: https://pastebin.com/raw/mYfMxXMQ
<zmatt> (the key_mgmt-line is to avoid fallback to insecure WEP)
<zmatt> (iirc)
<zmatt> it also wouldn't be hard to make a simple cli to scan for networks and select one
<rcn-ee> i'm wondering if there isn't a terminal front end... searching github..
<zmatt> you can configure wpa_supplicant to get its settings from the config file, but allow it to be updated via dbus commands
<zmatt> (as opposed to the usual arrangements: 1. static manually-written wpa_supplicant.conf, no dbus 2. no conf file, puppeteered via dbus by a network management daemon )
<zmatt> wpa_supplicant has wpa_cli yes
<zmatt> it's... not very user-friendly
<rcn-ee> it......does everything...wow...
<zmatt> eeeeeverything
<zmatt> and once wpa_supplicant has connected to your configured wifi network, it brings the interface link up and then systemd-networkd will take it from there just like any other interface
<zmatt> I guess the only problem would be if you want to configure multiple wifi networks, each with different network settings
<zmatt> maybe there's a way to deal with that, I've never looked... generally you'd just use dhcp for all wifi networks anyway
vagrantc has joined #beagle
<zmatt> rcn-ee: oh yeah, what I meant earlier was that it would be nicer if the service can have ExecStart=/usr/bin/gadget-acm-ecm and use some sort of dependency to load the kernel module if needed
<rcn-ee> yeah, i couldn't find a good example on that.. the service waited on libcomposite it would be perfect..
<zmatt> honestly, just ExecStartPre=/sbin/modprobe libcomposite
<rcn-ee> what about built-in case?
<zmatt> you can modprobe built-in modules, it's a noopo
<zmatt> *noop
<zmatt> $ sudo modprobe ext4 && echo ok
<zmatt> ok
<rcn-ee> i was looking for a specific systemd setting, looks everyone followed you! ;)
<zmatt> I wouldn't use -
<zmatt> the module is not optional
<zmatt> like, let's break out the cases: if the module is built-in or already loaded modprobe is a noop, if a failure happens while loading the module it's appropriate for the service to fail right away
the_person48 has quit [Quit: Client closed]
<zmatt> if modprobe can't load the module because your system or module index is broken.. then whatever, it's really not the job of this startup service to try to fix that, many more things will break too anyway :P
<zmatt> why keep the bb-start-usb-gadgets script instead of just ExecStart=/usr/bin/gadget-acm-ecm ?
<zmatt> that log line seems pointless but if you really want it you can just use ExecStartPre=/bin/echo ... :P
<rcn-ee> the "gadget-acm-ecm" is just a testing standin, we are going to load this *.scheme instead.. https://github.com/rcn-ee/repos/blob/master/bb-usb-gadgets/suite/bullseye/debian/bbb-acm-mass_storage-ncm-rndis.scheme
<rcn-ee> it's also just going to reference /etc/default/<something> so users can use what every prebuild gadget setup they want..
<zmatt> I've seen a thing that allows composite usb devices to be defined using config files rather than having to use scripts
<rcn-ee> it also needs to set the usb0/usb1 mac address's... so it's unique per system, but the same between reboots..
<rcn-ee> zmatt, that's libusbgx and gt (gt uses *.scheme) files!
<zmatt> the mac address thing is annoying indeed... I don't have a clean solution for that either
<rcn-ee> crap lost my old notes... but with "gt" you can first load a *.scheme, then using gt update the mac address values, and then finally gt run.. (so 3 steps..)
florian has quit [Quit: Ex-Chat]
<zmatt> it's a shame the usb_f_{ecm,ncm,rndis} drivers don't support the {dev,host}_addr module parameters like g_ether does, otherwise it would be possible for u-boot to set those mac addresses by passing appropriate kernel parameters... I understand that using module parameters for that can only be used if you never make two instances of the driver, but I'm pretty sure that's 99.99% of the use-cases
<zmatt> (it could do it for g_ether though, then people who use g_ether instead of a composite device can get appropriate stable mac addresses for free)
<rcn-ee> zmatt, can you set both sides of the mac address with: https://pastebin.com/3tjj3v3R ?
<rcn-ee> we could "setup" /etc/systemd/network/usb0.network during "ssh" key generation, and place the initial mac addres's..
<zmatt> it would be ideal if systemd-networkd could configure the host MAC address, but I don't think it can. also, I have no idea why I'm going through all this trouble to derive a MAC address instead of just relying on the default (which is to use a random _persistent_ mac address, i.e. that's stable across reboots)
<rcn-ee> i'm okay with a random "_persistent_"... some devices the mac address is broken or weird, and the i2c wait to get it..
<zmatt> I should note though that systemd relies on /etc/machine-id being a unique identifier for the system
<zmatt> which it's definitely _supposed_ to be... but if there are people who use a flashing procedure that just copies it from the image, that would be bad
<rcn-ee> is there a systemd command to regenerate machine-id... we tried just deleting it in buster, but there has to be a sytemd way by now..
<zmatt> hmm
<zmatt> it definitely has a bunch of stuff related to machine-id generation, I'm still investigating
<zmatt> it looks like it will generate it if missing?
<rcn-ee> so in our ssh regeneration script: https://github.com/rcn-ee/repos/blob/master/generic-sys-mods/suite/bullseye/debian/generic-sys-mods.regenerate_ssh_host_keys.service#L6 we could add a few more *Pre, that delete /etc/machine-id and run dbus-uuidgen --ensure=/etc/machine-id before ssh..
<zmatt> uhh, just omit /etc/machine-id from images and don't copy it onto the target system when flashing, and afaict systemd will automatically generate a random machine-id
<zmatt> (and save it to /etc/machine-id)
<rcn-ee> okay
<zmatt> copying hwrng to urandom is not needed if you have rng_core.default_quality=100 in the kernel parameters
<zmatt> why exactly do you delete and *regenerate* them, instead of omitting keys from the image and while flashing and just generating missing keys (i.e. only ssh-keygen -A -v) ?
<zmatt> like, if I flashed an image to sd card and then mounted it and generated host keys, I'd be very puzzled to discover they're gone and replaced by different ones when I boot that image
<rcn-ee> Good point, historically they were always there.. i can nuke them up front. .;)
<zmatt> ah, if /etc/machine-id is missing, systemd will be in "first boot" mode... I wonder what that implies
<rcn-ee> you could have a lot of fun with that: https://www.freedesktop.org/software/systemd/man/systemd-firstboot.html
<zmatt> I'm wondering if that applies, since that manpage doesn't exist on debian
<rcn-ee> lol: "It is not recommended to use systemd-firstboot on the running system while it is up." it can do a lot of fun things..
<zmatt> and "dpkg -L systemd | grep firstboot" yields nothing
<rcn-ee> it might be related to systemd images/container support..
<zmatt> (also, if systemd --system is invoked with a --machine-id=... option, or systemd.machine_id=... is in the kernel parameters, then that machine id will be used and will be written to /etc/machine-id (unless /etc/machine-id exists but is not writable, then it'll be written to /run/machine-id .. e.g. for network-booting systems with readonly /etc)
<zmatt> )
<zmatt> ohh and that /run/machine-id is then mounted at /etc/machine-id
<zmatt> clever
<zmatt> rcn-ee: OH, beware of /var/lib/dbus/machine-id
<zmatt> make sure on fresh images/installs that it's either missing or a symlink to /etc/machine-id
<zmatt> why the hell is it not a symlink anyway
<rcn-ee> i'll just nuke both..
<zmatt> then /var/lib/dbus/machine-id will become a copy of /etc/machine-id ... I feel like making it a symlink is less error-prone
<zmatt> or not hmm
<zmatt> no actually it'll be created as a symlink
<rcn-ee> i think we just remove both, and systemd will re-create what ever it wants.
<zmatt> so why the bleep is it not a symlink on a fresh debian install o.O
<zmatt> (also not on m laptop)
<zmatt> /lib/tmpfiles.d/dbus.conf has a line that will create /var/lib/dbus/machine-id (as symlink to /etc/machine-id) if missing
<zmatt> but I guess the debian installer explicitly creates /var/lib/dbus/machine-id using dbus-uuidgen
<zmatt> which doesn't make it a symlink "for historical reasons" according to https://wiki.debian.org/MachineId :P
<zmatt> rcn-ee: ohh, "first boot" mode (/etc/machine-id missing) has all sorts of impact
<rcn-ee> yeah, that's kind of why i'm looking for a better way..
<rcn-ee> or something clean..
<zmatt> normally it's created during installation
<zmatt> before boot
<zmatt> thing is, systemd expects to know its machine id really early, before any other process runs
<zmatt> oh, if /etc/machine-id is blank it will still regenerate it but not enter "first boot" mode
<zmatt> I'm making some notes: https://pastebin.com/7jqE0zwn
the_person48 has joined #beagle
<the_person48> hi guys, in light of my continuing OS difficulties, I have been asked to compare the different OS options available to us for the beaglebone black. I am aware that debian is the only supported OS, and that debian 10 is the latest stable version, while 11 is a new release and not yet stable. I also have been able to get ubuntu 18.04 to work, despite
<the_person48> it being unsupported. I am under the impression that ubuntu 20.04 doesn't work at all on the beaglebone; is this accurate?
<the_person48> I looked around for images to try it to confirm this but couldn't find any for the beaglebone that I could figure out the installation steps for
<vd> what's the difference between pmic and pwm ?
<the_person48> I did find images here but couldn't find the actual image file or a setup_sdcard.sh script, so couldn't figure out how to install them: https://rcn-ee.com/rootfs/eewiki/minfs/
<rcn-ee> the_person48, ubuntu rules keep pissing me off... they started trying to charge me for a server running ubuntu...
<the_person48> that's annoying
<vd> zmatt all dts is good (usb hub, gpio-hog, keys, eeprom, etc.). Now doing the last part, the touchscreen LCD!
<the_person48> I did hear that microsoft bought canonical
<rcn-ee> yeah. i'm about one more issue before i just rip out ubuntu from my image building script..
<the_person48> gotcha
<vd> rcn-ee you're not using a buildsystem such as buildroot or yocto?
<the_person48> for the purposes of reporting back to my coworkers though, is ubuntu 20.04 possible to install, and just unsupported? or is it both unsupported and not possible to install due to lack of images?
<rcn-ee> the_person48, that "minfs" image is used in these guides.. https://forum.digikey.com/t/debian-getting-started-with-the-beaglebone-black/12967
<rcn-ee> the_person48, BUT you get to build kernel/u-boto your self..
<rcn-ee> vd, debian's debootstrap... with a large bash wrapper around it..
<the_person48> ok, so possibly, but a big pain in the butt is what I'm getting. accurate?
<rcn-ee> the_person48, ubuntu on the BBB is supported by you the user.. Debian is support by us.. In either case Debian nor Ubuntu provide direct support..
<rcn-ee> (for the bbb)
<vd> rcn-ee actually using build systems to bootstrap common distribution is something missing. But a friend of mine is working on that (adding debootstrap, pacstrap and such support to buildroot).
<rcn-ee> vd, we are just u-boot/kernel on top of stable version of debian with some ti packages and needed backports.. the goal, is just to be 99% still debian..
the_person48 has quit [Quit: Client closed]
<vd> is the LCD and touchscreen built together or can you use the LCD without the touchscreen?
<rcn-ee> vd, the bindings are separate and independent..
<vd> the touchscreen seems to be an SPI device
<rcn-ee> spi/i2c/adc... most have specific bindings.
<vd> rcn-ee so a touchscreen is an (spi/i2c/adc/...) device with a filter stick on the screen?
<vd> I've never seen how it was built
<rcn-ee> it's a layer between your finger and the screen..
<rcn-ee> resistive, fine wires, capactive, glass layer with lots of math..
<vd> I see
<zmatt> rcn-ee: I've updated https://pastebin.com/7jqE0zwn
<zmatt> first boot mode mostly means ConditionFirstBoot in unit files will be true, but systemd will also perform a 'systemctl --preset-mode=enable-only preset-all'
<vagrantc> /14/14
<zmatt> cat?
<vd> zmatt it's need a way to pull-in service units for the first boot only, similar to the system-update mode
<zmatt> mostly yes... that was the expected part, I didn't know about the preset-all
<vd> why is the LCD_DATA* pinmux declared in the i2c0 node in boneblack-common?
<zmatt> it's not, you probably meant to ask why the LCD_DATA* pinmux is declared in a node that's referenced by an i2c device?
<zmatt> and the answer is because that node is the hdmi transmitter
<zmatt> though, I disagree with this choice and would have attached the pinmux for lcdc to &lcdc
<zmatt> but either choice works
<vd> ha, understood
<vd> lcdc for "LCD controller" I presume? i.e. the SoC side of the LCD controller
<vd> zmatt do you have an example of dts 16-bit lcdc? I lost the link
<zmatt> this doesn't include the pinmux node (&lcd_pins) but it should be obvious
<vd> yes, all the LCD_DATAx with mode 0
<zmatt> mode 0, PIN_OUTPUT (no pullup/pulldown)
<zmatt> for the remaining four LCD pins (or whichever of those pins you need for your lcd) it's also mode 0 but I'd recommend PIN_OUTPUT_PULLDOWN
<vd> zmatt btw I had a talk with an electronics guy, I understand a bit better external pullup/down. I also ended up removing the _PULL* suffix which works fine.
<zmatt> so, the reason why it doesn't really matter that the base dts did the pinmux for &lcdc in the pinmux node for the hdmi transmitter is because it's not a problem if the pins aren't muxed yet when &lcdc is initialized because lcdc only has outputs and doesn't know or care where anyone is listening (and noone is listening until the hdmi transmitter is initialized)
<zmatt> I'd recommend keeping either _PULLUP or _PULLDOWN on all pins except the LCD_DATA pins
<zmatt> to keep lines from floating e.g. if you boot the beaglebone without your custom hardware attached
<zmatt> though avoid configuring internal pull that contradicts external pull
<vd> ok
mattb0ne has joined #beagle
<zmatt> basically: you want digital signals to be either low or high most of the time, not somewhere halfway in between (except briefly during transitions) or undefined. devices connected to a net may just observe the net without touching it or they may be trying to make the net either low or high... and they can do so with different amounts of strength, e.g. they may be output that are strongly driven ...
<zmatt> ...low/high or they may be weak pull-up/downs. strong wins from weak (this is an approximation). you don't want a fight between pull-up and pull-down, you _definitely_ don't want a fight between drive-low and drive-high (that's called a "short circuit" and leads to unhappiness), but you always want _someone_ to be making that net either low or high
<zmatt> all this isn't super critical btw (except the part about avoiding short-circuits), as evidenced by the fact that the beaglebone in reset default state has a pull-up/down conflict on P9.15 and it doesn't seem to be killing them
<zmatt> but intermediate levels (nor really "low", not really "high") may cause excessive current in the input receiver and could possibly affect device reliability
<vd> ok
<vd> how do you link backlight and pwm to the lcd?
otisolsen70 has quit [Quit: Leaving]
the_person48 has joined #beagle
<the_person48> due to my ongoing operating system and library compatibility difficulties, I am now looking into cross compiling code for the beaglebone black rev C (running debian 10), from a host PC, running ubuntu 20.04. Has anyone here tried cross compiling on the beaglebone before?
<the_person48> Any tips/potential pitfalls?
<rcn-ee> the_person48, it works best if both are running Debian 10..
<rcn-ee> or 11..
<vd> rcn-ee how does backlight pwm work? I don't understand how a single line (gpmc_a2.ehrpwm1a) allows 100 different levels of brightness (I was assuming a single line meant on/off only)
<rcn-ee> if you want to play games with Ubuntu builds with Debian rootfs, go right ahead..
<the_person48> your response makes me think you don't reccomend cross-compiling, but can you please elaborate?
<vd> rcn-ee I see the node, but I'm wondering how this works. A single line can generate 100 brightness levels?
<rcn-ee> vd, yeah it looks weird.. that's the way it is..
<rcn-ee> We could probally do it in 16 steps, but for somereason we did a ton years ago..
<vd> my question was more about the protocol used with the pwm and this single output line
<rcn-ee> which line?
<vd> this gpmc_a2.ehrpwm1a
<rcn-ee> it's a pwm... so the pin goes up an down with a period and delay..
the_person48 has quit [Quit: Client closed]
<vd> like morse or 1-wire
<rcn-ee> PWM: Pulse Width Modulation https://en.wikipedia.org/wiki/Pulse-width_modulation
ikarso has joined #beagle
<vd> rcn-ee I'm stupid... the gpmc_a2.ehrpwm1a line is the power output, not the data line to control the pwm chip...
<rcn-ee> it's the pwm signal...
* vd facepalms
<rcn-ee> stick a scope on it ;)
<rcn-ee> SHould look like a nice square wave..
<vd> so setting the backlight pwm to 0 isn't the same as disabling the panel with the dedicated GPIO
<vd> it saves power I presume
<rcn-ee> maybe... depends on the downstream circuit.. but assuming gnd = off the panel...
<vd> there's no link in the dts between lcdc and the panel?
<rcn-ee> but the bugger doesn't work... anywho are lcd and panel driver is from back in the 3.8.x era days, so early device-tree.. it still works..
<rcn-ee> at one time our "lcdc" driver had it's own "lcdc-panel" driver, so i'm pretty sure that old connection still works for compab sake..
<vd> my LCD uses LCD_DATA0 to15 and 3 others: LCD_AC_BIAS_EN, LCD_PCLK and GPMC_WEN for "LCD_BUFFER_OE#". Does lcdc needs a special configuration for that?
lucascastro has joined #beagle
lucas_ has joined #beagle
<vd> rcn-ee I already have another GPIO defined for the "LCD_POWER_EN" (declared with enable-gpios, so I'm wondering what that LCD_BUFFER_OE# is
lucascastro has quit [Ping timeout: 252 seconds]
<rcn-ee> sounds like a voltage buffer enable... probally either use a hog, or as the gpio enable..
<vd> well it goes into the OE# pin 22 of two SN74LVC8T245DGVR
<rcn-ee> yeah, i'd do a hog...
<vd> so there's this line in addition to an LCD_POWER_EN pin?
<rcn-ee> if you want to save power and just turn it off. use gpio-led..
calculus has quit [Ping timeout: 240 seconds]
calculus has joined #beagle
<rcn-ee> vd, does lcd_power_en drive the buffer vcc on LCD_BUFFER_OE ?
<vd> hum I cannot tell
<vd> I'll use an active low hog for LCD_BUFFER_OE and see
<rcn-ee> i was just thinking, if LCD_POWER_EN also enables SN74LVC8T245DGVR, then having if off might bad when LCD_BUFFER_OE goes high.. unless the SN74LVC8T245DGVR is just driven by normal vcc then it would be fine..
<vd> rcn-ee I will confirm that soon (copy/pasting this question!)
<vd> (so far it doesn't seem to have a link between LCD_BUFFER_OE and LCD_POWER_EN)
<rcn-ee> OKay, good then we are fine... lcd_buffer_oe -> gpio-hog, adn lcd_power_en as the enable-gpio in the panel driver..
<vd> All done, with spi1 register but no touchscreen thing yes, I might try this now and see
<vd> is it safe to copy/paste all this panel node configuration or I should look for something? like the red-blue wiring, timings, panel-info etc.
<rcn-ee> panel-info and display-timings you get to come up with. ;)
<rcn-ee> bpp is either 16 bit or 24bit.
<rcn-ee> do you know what lcd panel is used adn do you have a datasheet?
<rcn-ee> there should be a number on the back somewhere..
<vd> looking for it
<vd> rcn-ee AD7843ARUZ-REEL7?
<vd> nah seems like the touchscreen thingy connected on SPI1
<rcn-ee> yeap, that's the touchscreen.
kveremitz has quit [Quit: ZNC - http://znc.in]
kveremitz has joined #beagle
<vd> rcn-ee I think it's a RS800480T-7X0WQ-A
<rcn-ee> so 800x600 ;) there's one number..
<vd> I don't understand how device tree works for this. There seems to have a driver for it (okaya,rs800480t-7x0gp) via the panel-simple driver but we must use the ti,tilcdc,panel compatible?
<rcn-ee> vd, awesome, you can use the okaya one thru the panel driver.. (compabible)
<vd> that's for the "gp" though, not my "wq-a" panel
ikarso has quit [Quit: Connection closed for inactivity]
<vd> rcn-ee why would you use the ti,tilcdc,panel compatible? Is it like a generic driver (panel-simple?)? I mean it's not an actual hardware device, is it?
<zmatt> your lcd panel is not a hardware device? what is it then exactly, a piece of software? a concept? :P
<vd> what?
<zmatt> ah, I misunderstood your question
<zmatt> it's a generic panel driver yeah, there's no reason for a different driver per panel
<vd> zmatt so an existing compatible for your actual hardware (e.g. okaya,rs800480t-7x0gp) is just a way to preconfigure the timings and panel info?
<vd> I still have trouble to understand what ti,tilcdc,panel does exactly
<rcn-ee> vd, it let's a us define every parameter of the panel..
<zmatt> vd: for some reason the simple-panel driver felt the need to embed a giant list of timings for different panels into the driver instead of just putting those timings in DT: https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/panel/panel-simple.c#L3454-L3482
vagrantc has quit [Quit: leaving]
<vd> rcn-ee it seems weird, I would've expected panel,simple everywhere instead of tilcdc,panel... I mean, there's no TI stuff in there I think
<rcn-ee> it's an old driver..
<vd> zmatt which is correct, it's way more robust to factorize a model settings into its driver instead of repeating its settings in every devicetrees using it
<vd> rcn-ee Ha I see! So we can expect this tilcdc,panel driver to go away in future mainline releases I suppose
<rcn-ee> it did go away...
<vd> rcn-ee drivers/gpu/drm/tilcdc/tilcdc_panel.c
<vd> still there as of 1a6d80f