vagrantc has quit [Remote host closed the connection]
troth has joined #beagle
<set_>
is beaglecfg done already? I am askin' b/c I see it is a bit buggy. I was scrolling in the GPIO pins section and received some errors.
<set_>
The errors were just random alpha-numeric characters showing on different parts of the screen.
<set_>
i.e. in the terminal.
<set_>
GenTooMan: Where are you? Get to the ole 'puter. I am senseless and learnin' while takin' notes.
<set_>
Anyway, when you get the message, look at this figure...$600.00. Does that seem reasonable for three to five boards? I know the answer is no but other, cheaper outlet places are asking about holes.
buzzmarshall has quit [Quit: Konversation terminated!]
<GenTooMan>
set_, hmm you may want to look at automated calculators for assembly for ideas on costs for assembly. It mostly depends on what they are doing. pick and place versus hand assembly.
<set_>
Oh.
<set_>
Okay.
<set_>
I looked online at automation.
<set_>
I keep getting these questions, "How many holes do you have?" Then, there are other normal questions but...
<set_>
How should I derive the amount of holes w/out knowing?
<set_>
I mean...I can count the holes on the PCBs made by OSH Park but some of them are very tiny. myeyes.
<set_>
Ha.
<set_>
I found some actual nice automated customer survey data on the automation assembly quoters.
<set_>
But! Holes still...I really feel like counting holes is far beyond what needs to happen.
<set_>
i was going to deal w/ SmallBatchAssembly but I think they went under.
<set_>
Like that...
<set_>
Poof.
troth has quit [Ping timeout: 246 seconds]
vd has joined #beagle
<GenTooMan>
hmm you mean through holes or vias? is that for the board or for through hole parts?
<set_>
Right.
<set_>
The automation sites just kept asking about and I quote, "holes."
<set_>
Literally, "How many holes are on the board?"
<set_>
I got tired of searching Chinese and Japanese and Taiwanese suppliers. At first, I figured, "This is a good idea and cheap!"
<set_>
I soon learned.
<set_>
That they are asking too much for something that may not be as is stated when purchasing.
<set_>
Who can I get to when things go awkward? You know? I am not traveling to Japan over some $350.00 in boards.
<set_>
I know these are not issues to you. So, I am just chatting about it b/c it has to do w/ making Capes for my BBB type boards.
troth has joined #beagle
Raajeshwar has joined #beagle
djinni has quit [*.net *.split]
blathijs has quit [*.net *.split]
blathijs has joined #beagle
djinni has joined #beagle
russell-- has quit [*.net *.split]
marcheu has quit [*.net *.split]
frostsnow has quit [*.net *.split]
noahm has quit [*.net *.split]
danny has quit [*.net *.split]
noahm has joined #beagle
frostsnow has joined #beagle
russell-- has joined #beagle
marcheu has joined #beagle
<Raajeshwar>
Hi guys, We are using the Avahi service for resolving domain names in Beaglebone devices in the local network. A set of 7 devices connected and running successfully for 3 days with the domain name. After that, we could not access the device using the domain name. Avahi logs were not found in the message log or Syslog. What might cause the domain
<Raajeshwar>
name resolving to fail? The local network was created using Ethernet beagle bone black boards.
<Raajeshwar>
Note: Similar set of another 7 devices in other network was working good. Avahi service documentation link - http://avahi.org/
troth has quit [Ping timeout: 260 seconds]
troth has joined #beagle
rob_w has joined #beagle
Shadyman has quit [Ping timeout: 250 seconds]
NishanthMenon has quit [Ping timeout: 246 seconds]
NishanthMenon has joined #beagle
Shadyman has joined #beagle
vd has quit [Ping timeout: 256 seconds]
giort has joined #beagle
Raajeshwar has quit [Ping timeout: 256 seconds]
otisolsen70 has joined #beagle
notserpe has quit [Ping timeout: 264 seconds]
moto-timo has quit [Ping timeout: 268 seconds]
bradfa has quit [Ping timeout: 268 seconds]
pbrobinson has quit [Ping timeout: 250 seconds]
vitorio has quit [Ping timeout: 265 seconds]
mgsb has quit [Ping timeout: 264 seconds]
mturquette has quit [Ping timeout: 246 seconds]
vigneshr has quit [Ping timeout: 265 seconds]
NishanthMenon has quit [Ping timeout: 250 seconds]
drewfustini_ has joined #beagle
paulbarker has quit [Ping timeout: 268 seconds]
mgsb has joined #beagle
paulbarker_ has joined #beagle
vigneshr has joined #beagle
drewfustini has quit [Ping timeout: 260 seconds]
drewfustini_ is now known as drewfustini
jkridner has quit [Ping timeout: 264 seconds]
NishanthMenon has joined #beagle
mturquette has joined #beagle
jkridner has joined #beagle
Raajeshwar has joined #beagle
notserpe has joined #beagle
moto-timo has joined #beagle
bradfa has joined #beagle
vitorio has joined #beagle
pbrobinson has joined #beagle
Shadyman has quit [Remote host closed the connection]
florian has joined #beagle
Guest78 has joined #beagle
Guest78 has quit [Client Quit]
Guest82 has joined #beagle
ikarso has joined #beagle
Guest82 has quit [Client Quit]
<zmatt>
Raajeshwar: an annoying thing that can happen with avahi when certain network changes occur is that it manages to conflict with its own registration, causing the avahi hostname to get renamed... that would result in logs though, check with "journalctl -u avahi-daemon"
<zmatt>
one way to check the current avahi hostname is with: busctl call org.freedesktop.Avahi / org.freedesktop.Avahi.Server GetHostName
<zmatt>
that's the only thing I can think of that may cause hostname resolution to suddenly start failing
<Raajeshwar>
We didn't check journalctl -u avahi-daemon when this happened. But checked /var/log/syslog and /var/log/messages and found nothing from avahi. The problem is we then restarted avahi in all devices and then we didn't see this issue.
<zmatt>
I have no idea what is or isn't logged by rsyslogd, I haven't used it in many many years
<zmatt>
I think it's *supposed* to log these things too, but dunno
<zmatt>
(if you have rsyslog installed that is, which I don't but afaik it is still installed by default0
<zmatt>
)
<Raajeshwar>
Thank you, let us see if we can replicate again and run "journalctl -u avahi-daemon".
<zmatt>
you can add the -f option to journalctl to continuously monitor the log output (exit with control-C)
rob_w has quit [Remote host closed the connection]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
johanhenselmans has joined #beagle
<johanhenselmans>
Hello, I have a 4D LCD cape which is identified by BB-BONE-LCD4-01-00A1.kernel. I want to use the buttons on the cape programmatically. I saw in https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD4-01-00A1.dts that the buttons are disabled to be used by other programs, and then are defined to do some keymapping( up down, left right. How do I get this stuff removed? Do I have to rebuild the kernel? Does the extension i
<johanhenselmans>
.kernel, imply that this thing is resident in the kernel?
<rcn-ee_>
johanhenselmans, .kernel means it was a *.dtbo in the kernel build, vs the exernally built version..
<rcn-ee_>
aka, bb.org-overlays will eventually go away, do to kenrel abi changes breaking the generic *.dtbo's..
<johanhenselmans>
So that means that changing the behaviour of a cape means recompiling a complete kernel, or are these dynamically loaded from /lib/firmware or some such?
<rcn-ee_>
johanhenselmans, no changing in building, other then the repo:
<rcn-ee_>
kernel specific overlays are located under: ls /boot/dtbs/`uname -r`/overlays
<johanhenselmans>
OK, so BB-BONE-LCD4-01-00A1.dtbo is found in /boot/dtbs/`uname -r`/overlays, so that means recompiling the kernel, correct?
<rcn-ee_>
johanhenselmans, 'no'... that doesn't mean recomping the kernel.. if you want to modify that specific overlay, clone the branch specific to the kernel version from: https://github.com/beagleboard/BeagleBoard-DeviceTrees then modify hte *.dts, and run make ; make install..
<rcn-ee_>
which kernel are you using today?
<johanhenselmans>
5.10.78-bone57 as per instruction...
<johanhenselmans>
Already checked out the repo. Now to get a compile running via NFS, with Mac OS as a server… (I’ll just clone it to another BBB).
<rcn-ee_>
only gcc, device-tree-compiler is required..
<rcn-ee_>
should build in less then a minute on a bbb..
<johanhenselmans>
And…. dtc is missing (starting from a the 1GB console image)
<johanhenselmans>
Hmm, make src/arm/overlays/BB-BONE-LCD4-01-00A1.dtb does indeed compile only that specific dts, but make install src/arm/overlays/BB-BONE-LCD4-01-00A1.dtb starts compiling all the stuff. Anyway, I’ll just copy the dtb file to /boot/dtbs/`uname -r`/overlays.
<johanhenselmans>
Should I rename it ot dtbo? Any difference?
<johanhenselmans>
And reboot…
<rcn-ee_>
just do a 'make ; sudo make install', other things aren't really tested..
<johanhenselmans>
Ah, OK. Just rebooted, button pins are not seen as part of the cape, and display stilll works. Only problem is that ‘config-pin p9.15’ now says ‘ open() for /sys/devices/platform/ocp/ocp:P9_15_pinmux/state’ failed, No such file or directory. Should it not be a default pin config?
<johanhenselmans>
Ah, missed the ‘disabled part in the beginning. Recompile in a minute.
<johanhenselmans>
Nearly there. It seems that P9.16 is now part of something called ocp/P9_16_pinmux (pinmux_P9_16_gpio_input_pin), which prevents it from setting via ‘config-pin p9.16 gpio_input’. Where did that one come from?
florian has quit [Quit: Ex-Chat]
philenotfound has quit [Remote host closed the connection]
ikarso has quit [Quit: Connection closed for inactivity]
troth has quit [Ping timeout: 268 seconds]
vd18 has joined #beagle
vd has quit [Ping timeout: 256 seconds]
troth has joined #beagle
troth has quit [Ping timeout: 260 seconds]
<zmatt>
what's "gpio_input" ?
<zmatt>
that mode makes no sense
troth has joined #beagle
<zmatt>
johanhenselmans: and "ocp/P9_16_pinmux" is actually thing that allows config-pin to work
<zmatt>
note that all configurable pins except P9.19/20 default to gpio anyway
<zmatt>
there are three relevant gpio modes: "gpio_pd" (internal pull-down enabled), "gpio_pu" (internal pull-up enabled), "gpio" (internal pull-up/down disabled" ... the "default" mode is a synonym for "gpio_pu" or "gpio_pd" (which of the two varies per pin), except for P9.19/20 for which default is i2c
<zmatt>
it seems inconsistent whether "gpio_input" mode exists or not, but whenever it does it appears to be a synonym for "gpio"