m-atoms has quit [Read error: Connection reset by peer]
m-atoms has joined #beagle
flatwhatson has joined #beagle
vagrantc has quit [Quit: leaving]
thinkfat_ has joined #beagle
thinkfat has quit [Ping timeout: 264 seconds]
<kveremitz>
zmatt: quick query if you're around .. /sys/class/leds .. I'm guessing needs to be defined in DT, and not also defined in /sys/class/gpio [or such] ? ie. if there is data present in the GPIO section, and you want it as a led 'item' you need to Move It :D
<kveremitz>
(or anyone similarly versed in DT/sys/class-fu)
<zmatt>
correct
<kveremitz>
damn, when the brain works .. XD
<kveremitz>
thanks
<kveremitz>
sanity-check: PASS - you /are/ insane :d
<zmatt>
of course not all led drivers are gpio, there's also pwm-led and such
<kveremitz>
oooh, can I have a fading 'heartbeat' led?! :p
<zmatt>
but yeah, gpio-leds or whatever it's called will claim those gpios, which is mutually exclusive with exporting to sysfs... or at least it should be, iirc rcn's kernel has some check patched out
<kveremitz>
I can usefully port the beagle* over to my pine64 :D
<kveremitz>
DT*
m-atoms has quit [Ping timeout: 264 seconds]
blech has quit [Ping timeout: 252 seconds]
waldo323_ has joined #beagle
waldo323__ has quit [Ping timeout: 264 seconds]
buzzmarshall has quit [Quit: Konversation terminated!]
giort has joined #beagle
waldo323_ has quit [Remote host closed the connection]
waldo323_ has joined #beagle
flatwhatson has quit [Read error: Connection reset by peer]
flatwhatson has joined #beagle
calculus has quit [Ping timeout: 252 seconds]
calculus has joined #beagle
giort has quit [Quit: giort]
florian has joined #beagle
BeagleKho has joined #beagle
<BeagleKho>
Hi
<BeagleKho>
Anyone know how to boot OS image into beaglebone black emmc?
Shadyman has quit [Remote host closed the connection]
<BeagleKho>
@all
BeagleKho has quit [Client Quit]
Guest30 has joined #beagle
Guest30 has quit [Quit: Client closed]
set_ has quit [Ping timeout: 268 seconds]
otisolsen70 has joined #beagle
otisolsen70_ has joined #beagle
blech has joined #beagle
otisolsen70_ has quit [Quit: Leaving]
otisolsen70_ has joined #beagle
otisolsen70_ has quit [Remote host closed the connection]
buzzmarshall has joined #beagle
trinath has joined #beagle
trinath has quit [Remote host closed the connection]
trinath has joined #beagle
<trinath>
hi
<trinath>
I have a query on beaglebone x15
<trinath>
Can i configure PCIe of beagle bone x15 in endpoint mode
<trinath>
?
trinath has quit [Remote host closed the connection]
trinath has joined #beagle
trinath has quit [Remote host closed the connection]
trinath has joined #beagle
<trinath>
hi
<trinath>
Can i configure PCIe of beagle bone x15 in endpoint mode ?
<trinath>
Can anyone answer my quey please ?
Guest81 has joined #beagle
Guest81 has quit [Quit: Client closed]
<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
<trinath>
That's fine..
<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
<zmatt>
it might be more fruitful to ask on the TI E2E forum
<trinath>
I also thought the same..
<trinath>
But i need a confirmation on tha
<trinath>
taht
<zmatt>
I'm not sure you'll get any, as far as I know this is basically unexplored territory
<trinath>
Ok..
<zmatt>
but PCIe is available on the expansion headers, and the AM572x apparently supports endpoint mode
<trinath>
Anyways thank you zmatt for answering my query..
<trinath>
Ok... i will find out...thanks again
trinath has quit [Remote host closed the connection]
<zmatt>
good luck!
thinkfat has joined #beagle
thinkfat_ has quit [Ping timeout: 246 seconds]
otisolsen70_ has joined #beagle
otisolsen70_ has quit [Remote host closed the connection]
<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"..
<zmatt>
not sure what you mean by "whole stack", but just restart systemd-networkd... it doesn't cause any network interruption as such
<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..
thinkfat has quit [Remote host closed the connection]
m-atoms has joined #beagle
thinkfat has joined #beagle
giort has joined #beagle
giort has quit [Ping timeout: 252 seconds]
lucascastro has joined #beagle
giort has joined #beagle
Shadyman has joined #beagle
lucas_ has joined #beagle
lucascastro has quit [Ping timeout: 265 seconds]
zjason` has joined #beagle
zjason has quit [Ping timeout: 265 seconds]
giort has quit [Remote host closed the connection]
giort has joined #beagle
giort has quit [Remote host closed the connection]
Posterdati has joined #beagle
agentnocent has joined #beagle
<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
<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.
<agentnocent>
The idea is to use downloaded Google Maps or Bing Maps (I am not sure which is best suited yet).
<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
agentnocent has quit [Ping timeout: 246 seconds]
the_person48 has joined #beagle
<the_person48>
hey guys, I'm running debian 9.5 on a beaglebone black rev C
<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].
agentnocent has quit [Quit: Leaving]
<zmatt>
the_person48: please don't configure internal pulldown on P8.03-06 or P8.20-25, they have external pull-ups
<zmatt>
the_person48: what do you mean by "not coming up" ?
<the_person48>
as in, the synlink isn't there in /dev/gpio
<rcn-ee>
zmatt, seeing something odd with systemd-networkd and eth0 (hot plug) is there a *.network option we need to enable that?
<the_person48>
here's the ls -la output on /dev/gpio
<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..
<the_person48>
and zmatt you're saying to change to PIN_NOPULL for P8.3-6 and P8.20-25?
<zmatt>
rcn-ee: uhh strange, I've never had a problem with it
<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
<the_person48>
sounds good
<the_person48>
and do you think that might be causing the issue with P8.03?
<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
<zmatt>
the_person48: I have no idea what's going on with P8.03 for you
<rcn-ee>
it detects link down... but never gets a link is up..
<rcn-ee>
(rebooting with v5.4.x, might be a kernel bug..)
<zmatt>
if the kernel doesn't report link up there's nothing systemd-networkd can do
<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
<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. ;)
<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
<zmatt>
okay so the gpio didn't get exported for some reason
<the_person48>
P8.03 shows up with the name "gpio-demo" while P8.04 is named "P8.04"
<the_person48>
sorry that's from before
<zmatt>
check kernel log?
<the_person48>
I used to think they were not, haven't removed the comment
<the_person48>
ok, how do I do that again?
<zmatt>
also you still have pulldown configured
<the_person48>
oh oops
<the_person48>
sorry I rewrote the file but forgot to recompile
<the_person48>
this is what I have for my boot/uEnv.txt
vd has joined #beagle
set_ has joined #beagle
<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)
<the_person48>
yeah good to eliminate at least first
<the_person48>
but it's weird that it's enabled even though I have that line commented?
<zmatt>
indeed
<the_person48>
could it be an issue with the onboard eMMC?
<rcn-ee>
P8.03 would be the eMMC... you have ti disabled?
<zmatt>
no
<zmatt>
rcn-ee: he does
<rcn-ee>
one of his pastebin shows: #disable_uboot_overlay_emmc=1
<the_person48>
let me double check
<zmatt>
huh, but show-pins is showing the pins not being in use by eMMC
<the_person48>
yeah you're right it is commented
<the_person48>
that's weird, I swear I uncommented that
<the_person48>
changing now
<zmatt>
but then how... why... is the pinmux not configured to eMMC ? o.O
<the_person48>
haha I have no idea
<the_person48>
much weirdness
<the_person48>
but we
<the_person48>
'll see if this fixes it
<zmatt>
the_person48: oh and the P8.03 issue is indeed caused by cape-universal
<rcn-ee>
it's really best to "not" use any eMMC pins, depending on model/etc they can't be disabled..
<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
<the_person48>
ok, I wonder how to disable it though cause I already have that line commented about enabling uboot cape universal
<the_person48>
yeah we didn't understand that when developing hardware that meshes with the BB
<the_person48>
and now trying to avoid changing the hardware
<rcn-ee>
#disable_uboot_overlay_emmc=1 -> enable
<the_person48>
ok, I'll do that first one
<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 ...
<zmatt>
...are not affected
<the_person48>
or wait sorry I'm trying to figure out how to disable the uboot_cape_universal
<zmatt>
the_person48: why exactly are you using an obsolete version of debian again?
<the_person48>
don't have access to ethernet right now for beaglebone but I can do that later
<the_person48>
because my coworkers have used it succesfully before and already vetted it through all our bureacracy
<the_person48>
it's not really up to me unless I show that it can't be done
<rcn-ee>
the_person48, ah right! Ethernet.. why are you doing this project again? talk about so many handycaps, no serial, no etherenet...
<the_person48>
well I do usually have ethernet just not where I am literally right now
<rcn-ee>
your on irc, bridge your device?
<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
<the_person48>
I'm not opposed to that but have never figured out how to do it succesfully
<the_person48>
believe me, I agree, it's just not up to me
<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
<the_person48>
I understand it must be frustrating to work with for you guys
<the_person48>
yeah
<rcn-ee>
it's always upto the developer... Customer wants something, it's up to you to deliver and charge them for it. ;)
<the_person48>
haha
<the_person48>
true
<zmatt>
yes it is, please be sure to make it clear that it is in fact frequently causing unnecessary problems
<zmatt>
(frustrating to work with, that is)
<the_person48>
I am and will continue to communicate that
<the_person48>
yeah I feel you and appreciate the continued support
<rcn-ee>
and don't forget to invoice them "for their insane handicaps"...
<the_person48>
will do ;)
<the_person48>
ok, so when I do get back where I have ethernet
<rcn-ee>
you might have a problem with apt, i forget when "apt" offically supported that.. so you might have to use apt-get ...
<the_person48>
then the uboot loader should be newer and hopefully not have this weirdness?
<the_person48>
gotcha, I think apt is working on this one but will use apt-get if necessary
<rcn-ee>
but ever since i don't waste time with the extra 4 characters..
<zmatt>
I think apt was in stretch already? I'm not sure, it's been so long ago
<the_person48>
yeah I think it's here
<zmatt>
I generally don't linger on the past that long
<zmatt>
:P
<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?
<the_person48>
for sure
<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..
<rcn-ee>
that's where a serial cables helps debug.. ;)
<the_person48>
ok
<the_person48>
well I'll update and then let you guys know how it goes
<the_person48>
and when I have a serial cable as well but that'll be a lot longer
<rcn-ee>
even a rpi's serial usb adapter would work, some stores have them in stock..
<the_person48>
got it, ok maybe there's an easier way to find one
<set_>
Hey wait...
<set_>
Should I know about the evm too w/ uboot?
<set_>
Hello? Echo, test, one two. Is this thing on?
<zmatt>
set_: the u-boot am335x-evm board target is also used for all beaglebone variants, that's how it's always been
<zmatt>
(it auto-detects which board it's actually running on)
<zmatt>
so no, you don't need to know anything about the evm
<zmatt>
it's just a poorly named u-boot target, it ought to be am335x-generic or something like that :P
<set_>
Oh.
<set_>
Got it.
<set_>
Good, phew. I thought I had to learn more at your expense.
<set_>
Ooh.
<set_>
Just kiddin'.
<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).
<set_>
Seems plausible and undeniably justified. Anyway, off to test things to make sure I have something say.