brook has quit [Remote host closed the connection]
brook has joined #beagle
brook_ has joined #beagle
vagrantc has quit [Quit: leaving]
brook has quit [Read error: Connection reset by peer]
brook_ has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Read error: Connection reset by peer]
brook has joined #beagle
brook has quit [Remote host closed the connection]
brook has joined #beagle
brook has quit [Ping timeout: 244 seconds]
demirok has quit [Read error: Connection reset by peer]
demirok has joined #beagle
otisolsen70 has joined #beagle
otisolsen70 has quit [Remote host closed the connection]
otisolsen70 has joined #beagle
Guest46 has joined #beagle
<Guest46>
Hi good morning
<Guest46>
I want to interface 5 inch touch screen with BB Black board, we got the HDMI working but the touch is not working
<Guest46>
its for a Industrial automation work our company is working ON
Guest19 has quit [Quit: Client closed]
Guest46 has quit [Quit: Client closed]
<zmatt>
thanks for sharing? I guess he didn't have any actual question to ask
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #beagle
vigneshr has joined #beagle
demirok has quit [Quit: Leaving.]
ft has quit [Quit: Lost terminal]
demirok has joined #beagle
Shadyman has quit [Quit: Leaving.]
Guest16 has joined #beagle
florian has joined #beagle
<Guest16>
Hello, I was wondering what are the main differences between the beaglebone black wireless and the beaglebone green wireless? I am aware they are different in how you can connect to them but are there any chip differences? I could not find any apparent differences from my searches
<zmatt>
Guest16: the green wireless has some serious compatibility issues with capes, many of its pins are not usable
<zmatt>
the black wireless reused the SoC pins that were previously used for ethernet, while the green wireless inexplicitly left most of those unused and instead sacrificed a bunch of expansion header pins for use by the wifi/bluetooth chip instead
<zmatt>
*inexplicably
<Guest16>
I see, does it have a different pinout?
<zmatt>
I mean it's technically the same pinsout, but a bunch of pins cannot be used for your own purposes because they're already in use by the wifi
<zmatt>
it's kinda like a beaglebone with a wifi cape stacked on top
<zmatt>
and the green-wireless (just like the green) lacks hdmi output
<Guest16>
So would you say its better to use a standard black with a cape rather than the green if I've already got a system set up that used the black wireless
<Guest16>
Cant find any black wirelesses
<zmatt>
I don't really understand that question
<zmatt>
if you don't care about hdmi and don't (ever) need the expansion header pins occupied for wifi/bt on the green-wireless, then the green-wireless is fine
<Guest16>
Sorry, I had a system set up that used the beaglebone black wireless but it blew. I'm looking to replace it and was thinking if the green wireless was good enough or to use a black wired with a cape
<Guest16>
Thank you
<zmatt>
well a wireless cape (if you can actually fine one) will surely use at least as many expansion header pins as the green-wireless does
<zmatt>
so the only reason to use a black + wifi cape instead of a green-wireless would be if you need both ethernet *and* wifi, or you need hdmi
<Guest16>
I see
<Guest16>
thank you!
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
Guest16 has quit [Quit: Client closed]
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
jfsimon1981 has quit [Read error: Connection reset by peer]
jfsimon1981 has joined #beagle
starblue has quit [Ping timeout: 264 seconds]
starblue has joined #beagle
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
Guest19 has joined #beagle
<Guest19>
hello all again. I was wondering if there's a way to use pins on the compatibility header of the BBAI to access serial port (instead of the fine pitch three pin connector next to the USB-C for which I have no connectors handy).
<outrageous>
I think the 3 pin connector is debug serial console and I don't think that can be re-routed to GPIO pins
<zmatt>
depends on what you mean by that exactly... like, are you trying to just move the linux console to another serial port, or do you want to capture early messages from u-boot?
<zmatt>
to use a different serial port for the earliest u-boot messages would require building a custom u-boot
<zmatt>
setting the console parameter in /boot/uEnv.txt, along with a DT overlay to setup the necessary pinmux, would allow that serial console to be used as console for linux (and for late u-boot messages I think, not 100% sure)
<zmatt>
if you just want to spawn *a* login shell on another serial port, without necessarily making it the console, then that would be even easier
<zmatt>
so it all depends on what you actually want
jfsimon1981 has quit [Remote host closed the connection]
jfsimon1981 has joined #beagle
<Guest19>
early messages from boot (given my boot woes from yesterday). I think given that I don't have access to the system when it doesn't boot, there is no hope of altering uboot
jfsimon1981 has quit [Remote host closed the connection]
<zmatt>
if it's not booting at all (no USR leds) then I would also not expect anything on the serial console
jfsimon1981 has joined #beagle
<Guest19>
I have a single known good SD card that boots. It's an older image, so I don't want it. I've tried flashing multiple other SD cards, and none boot.
<Guest19>
I'm very reluctant to flash that SD card at all
<zmatt>
and if you want people to associate your name with previous conversations, you might want to pick something better than "Guest19" ;)
<Guest19>
heh. yes this is true.
<zmatt>
I wonder if maybe there's just something wrong with those images which didn't get noticed because u-boot from eMMC got used instead
<zmatt>
with u-boot on those images I mean
<zmatt>
but I can't investigate that right now, I'm off to work, o/
set_ has quit [Remote host closed the connection]
<Guest19>
can you confirm uboot outputs to serial? I think the ultimate answer will come from the early boot complaints.
<zmatt>
though as a last remark before I go, if you have *some* image you can boot, you could use that to install a working u-boot on eMMC
<Guest19>
yeah, that's a good idea. I've wasted a lot of time on this so far and I just need a build box in a cluster to get back up
<Guest19>
is there a preferred uboot to flash?
<Guest19>
or do I just flash the SD image itself onto mmc?
<zmatt>
1. yes 2. I guess you could try that, or at least copy u-boot (located between the partition table and the root partition), though having a more recent u-boot from rcn-ee may be preferred
<zmatt>
maybe rcn-ee can help with this, I really gotta go now
<zmatt>
(if he's around)
<zmatt>
anyway, afk!
<Guest19>
thanks zmatt
zmatt has quit [Ping timeout: 268 seconds]
set_ has joined #beagle
zmatt has joined #beagle
demirok has quit [Ping timeout: 240 seconds]
<rcn-ee>
Guest19: i noticed last night, on the bbai, the usr led's are used in the newer branch of u-boot... give it a good 10 seconds before linux boot and takes over usr led blinking..
<Guest19>
rcn-ee where can I find a latest emmc image (including uboot) for BBAI?
<zmatt>
I don't use the USR leds in my u-boot build for our beaglebones either, but it only takes a second or two before the kernel takes over.... 10 seconds is certainly a long time to see no activity at all
<rcn-ee>
Guest19: well i'm uploading one right now, as the ksmbd-tool spammed systemd in 09-01...
<Guest19>
(and rcn-ee: I have that debug cable on order)
<Guest19>
Ah, great. Can you ping this channel when you are done uploading?
<rcn-ee>
use etcher.io on that am57xx*.img.xz it'll take a good 10 seconds before kernel loads and takes control over usr* leds'..
buckket has quit [Remote host closed the connection]
<Guest19>
is there a reason you guys recommend etcher.io other than lower support calls from users?
<rcn-ee>
it's gotten to the point, i don't trust users to understand dd. ;)
<zmatt>
plus the post-flash verification is very useful to catch flaky cards
<rcn-ee>
i forget when we started working with belana, but once they added xz uncompression years ago for our images, they became our default 'go to'..
<Guest19>
understood.
buckket has joined #beagle
<rcn-ee>
On the am335x/am57xx everything is 'ext4' files except the first 1-4MB of space on the image which is the bootloader at specific memory positions on the image/drive...
<Guest19>
ok. And I'm in the process of searching for this, but maybe you can answer directly: does that go straight onto /dev/mmcblk1 or is there some special handling required for emmc flash?
demirok has joined #beagle
<rcn-ee>
With Bullseye, i tried to make it simpler for me and users.. One image.. boot into image.. run: ` sudo enable-beagle-flasher ; sudo reboot` to convert a normal to 'flasher'...
<rcn-ee>
editing /boot/uEnv.txt was tricky... users got confused when there was two images.. idk.. this will probally also fail.. but at the moment, Bullseye.. only one image to start with..
<Guest19>
ok, fyi - from my earlier chat: I have a BBAI which boots from a known good SD card, but refuses to boot from anywhere else. It's vexxing, and because I don't have a serial connection, I can't tell what it's blocking on. The LEDs never come up, which indicates to me (from your above comment) that the uboot complains about something and never drops
<Guest19>
into linux boot loader.
<Guest19>
My current strategy is to boot using the known good image, and try to reflash the emmc directly. So I do not have the option to do the SD flasher path, unless I misunderstood your point.
otisolsen70 has quit [Quit: Leaving]
<Guest19>
I will figure out what is going on in the enable-beagle-flasher
<rcn-ee>
zmatt: just thought of something stupid.. what's your thoughts.. on bootup for new users... we have these random usb `enx3403de8d01a5` nodes show up.. could convert the first part to "Beagle"... `enxbealee8d01a5` 'beagle' or 'bone'... ;)
<rcn-ee>
which follows the old 2 images, use /boot/uEnv.txt to convert between the two.. It's just Bullseye, i'm trying to start clean..
demirok has quit [Quit: Leaving.]
demirok has joined #beagle
<rcn-ee>
idk, it would only help users who actually look under `ip address`... see it's up, just enable dhcp.. but users who look would already see 2 new interfaces and understand, that's my network connection..
<zmatt>
rcn-ee: I wouldn't mess with the randomly generated mac addresses like that, it would just increase the risk of collision. besides, the naming of those interfaces is distro-dependent
brook has joined #beagle
<zmatt>
rcn-ee: also, you can't make an "l" nor a "g"
<Guest19>
I do have a wish list for the uboot loader, not sure if you guys are using the generic one or a custom one for bb, but turning on at least one USR LED and leaving it solid on when uboot starts would help people not be concerned that the device is bricked.
<rcn-ee>
ugh.. forgot about the 'l'... had the 'g' ... yeah too riskly..
<zmatt>
I'm assuming the leds not being turned on is a bug/oversight, not a deliberate decision
<rcn-ee>
Guest19: yeap, noticed that last night.. don't remember if on the bbai we had the 4 usr led's working in u-boot.. but yeah, i'm going to add that shortly..
<Guest19>
I appreciate it.
<rcn-ee>
Guest19: on the am335x, the 4 led's load on sequence of certain aspects of loading u-boot..
brook has quit [Ping timeout: 244 seconds]
Guest5051 has joined #beagle
Guest5051 has quit [Client Quit]
johanhenselmans has quit [Ping timeout: 248 seconds]
johanhenselmans has joined #beagle
brook has joined #beagle
johanhenselmans has quit [Quit: johanhenselmans]
<zmatt>
rcn-ee: fyi, I just made a git repo for (a new version of) the tiny utility I made for messing with the cortex-a15 cpu power management registers on the am572x: https://github.com/mvduin/omap5-cpu-pm
<Guest19>
ok, so that last flasher image you posted (rcn-ee), has worked. I'm not sure how or what my previous images were not doing right, but as I said LED's will enormously help. (as well as my receiving the serial debug console).
<Guest19>
very likely the reason they didn't work was PEBKAC
<set_>
I know it all to well!
<zmatt>
can confirm, set_ is very experienced with PEBKAC :)
<set_>
I like, in fact, so much that I make time for it now.
<set_>
"Not to self..."
<set_>
Make PEBKAC reality for everyone around me!
<set_>
Outside of jokes and funnies, has anyone mastered this edge-ai-apps?
<set_>
edge-ai-apps is for the BBAI-64. It seems the docker container for it does not allow for ROS commands.
<zmatt>
if current kernels still default to "requested power state: ON", maybe I should poke tmlind and ask if he knows if there's a good reason for that
<rcn-ee>
@NishanthMenon ... ^ ;) or do you want to stay hands off on am57xx . ;)
<rcn-ee>
zmatt: i'll package it add it to all buster/bullseye/etc. ;)
<zmatt>
I mean, you can always wash your hands afterwards ;)
<zmatt>
heh, is that wise?
<rcn-ee>
he spends most of his day working on j7+ stuff.. so the am57xx is only like 4-5 years off his radar..
<zmatt>
I still have to believe there must be a good reason the kernel is disallowing cpu power management
<zmatt>
even though I've not observed any negative effects myself
<rcn-ee>
i think part of the problem, i've been terrible at validating mainline on bbai, i've now got 4 nodes setup to do more mainline testing.. first goal is to get the 5.10.x-ti in a much much better shape, then v4.19.x-ti..
brook has quit [Ping timeout: 268 seconds]
<NishanthMenon>
Zmatt rcn-ee tmlind will know best on j6/am57x should be on #linux-ti
<zmatt>
rcn-ee: can you easily check if the default is still ON on 5.10 at least?
<zmatt>
I kinda don't want to bug tmlind with an issue I've not validated on kernels newer than 4.19 ;-)
<rcn-ee>
zmatt: Bus error
<zmatt>
on a bbai?
jfsimon1981 has quit [Remote host closed the connection]
<zmatt>
or bbx15
<rcn-ee>
bbai...
<zmatt>
ehh
jfsimon1981 has joined #beagle
<rcn-ee>
ugh... wrong code-server window...
<zmatt>
lol
<zmatt>
maybe I should put in a check that it's the right SoC
<rcn-ee>
(just flashed a bunch of boards, so i have dozen browser tabs open that look exactly teh same..)
<set_>
I bought littelfuse brand stuff before. I got a thermistor/temp. sensor.
<set_>
I handles my funny 3D life.
zjason` has joined #beagle
<set_>
Print!
zjason has quit [Ping timeout: 260 seconds]
demirok has quit [Ping timeout: 268 seconds]
<set_>
I am affraid to update.
<set_>
double f.
* set_
gets left in the past like atari...
nparafe has quit [Ping timeout: 240 seconds]
<set_>
rcn-ee: Hey "bro," um. Ugh. Should I use the udev rules that are on the board currently w/ updated images?
nparafe has joined #beagle
<set_>
I mean...will that even work?
<set_>
I have the 2020 image w/ all the fixings so far, i.e. TTY, PWM, SPI, and it is all in /dev/ currently.
<set_>
WHelp, there is one way to find out!
<set_>
Just foreseeing the future here. Labor day, set_, weekend? You know!
<set_>
Anyway...
<set_>
Outside of udev, what may I might need outside of udev when updating images?
<set_>
So, things are similar at the least?
<set_>
Anyway. Forget it. Time to party! labor day weekend has begun (sort of).
<rcn-ee>
set_: udev for what exactly?
<set_>
gpio, pwm, spi, uart
<set_>
i2c
<set_>
for the BBB.
<set_>
I was trying to build something a while back, got poop shot, and rerouted my endeavors to something else. Poop shot = nonsensical. But...I was rerouted to other things.
<set_>
So, I figured if I could use those tech. peripherals and "mean" it, I think I could finally finish up on this project.
<set_>
It is for some drivers in the auto. field.
<set_>
I have them still. I am missing one component so far to this day. I think things may be weather ready soon.
<set_>
So, I wanted to make sure my breadboard ideas work and are just not creating amplifiers.
<set_>
"Like last time!"
<set_>
Man, that pissed me off so badly.
<set_>
I need three to one. I got a 18 pin chip instead. I only needed a four pin chip.
<set_>
I could not get it.
<set_>
Still!
<rcn-ee>
if you find an actual issue, please let us know..