buzzmarshall has quit [Quit: Konversation terminated!]
vagrantc has quit [Quit: leaving]
renrelkha has quit [Quit: bye]
renrelkha has joined #beagle
<mewt>
hm ok, so I've got a serial console and am looking at this suspect beaglebone
<mewt>
I'm running the latest default image, off an SD card
<mewt>
eth0 comes up, but if I send DHCPDISCOVER with dhclient, I cannot see the DHCPOFFER from my router
<mewt>
I know it's being made, because I see it in LuCi's logs...
<mewt>
Does this point to hardware failure, misconfigured uboot, ... ?
<mewt>
In uboot the phy does come up on mdio address too, but I mean I can see the interface from debian, etc. etc. and one direction clearly works
<mewt>
It just...cannot see the dhcpoffer for some reason (tm)
<mewt>
ah nvm
<mewt>
ah no no, that is right -- i thought i was looking at another client but I see the mac addr there
<mewt>
It does come up on mdio addr 2 but the image seems to be able to deal with that just fine
<mewt>
Ok, the LAN8710 register contents tells me: BCR = 0x1000 (auto-negotiate mode, not in reset), BSR = 0x7809 (100basetx and some-other-stuff-capable, can autonegotiate, supports extended capabilities)
<mewt>
No fault is shown in the auto negotiation advertisement register, expansion register says no faults & auto-negotiation is possible. Not sure what else to check in there
<mewt>
guess it's getting about time to check physical continuity and then blame software again...
<mewt>
"cpsw Waiting for PHY auto negotiation to complete......... TIMEOUT !" but the symbol error register...reads as 0
thinkfat_ has joined #beagle
<zmatt>
mewt: maybe phy got damaged?
<mewt>
yep, seems like that's about all I can think now, or something else in the path...
<zmatt>
we had a case where a customer connected the ethernet port to a phone line... it kinda survived, except after that phy could no longer detect link changes without manually resetting the phy
<mewt>
I didn't read closely enough in the LAN8710 datasheet to see how that register stuff works
<mewt>
hmmm
<mewt>
It just seems odd it'd read fine over MDIO and have only one way broken, but I guess it could also be stuff later in the chain
<mewt>
I guess I could try to probe pins
<mewt>
It does have near and far-end loopback to play with too right?
<mewt>
near-end would rule out any digital issue
<mewt>
There's also some kind of link integrity test. But there's no way I could look at that til tomorrow, much too tired
thinkfat_ has quit [Ping timeout: 268 seconds]
<mewt>
Seems quite hard to get another one right now, as well -- backordered everywhere I looked... so it's probably worth trying a bit more
<markand>
if I have /dev/ttyO4 that means it's already enabled right? we have a peripheral connected to it but I'm unable to talk with it at the moment
<mewt>
>I cannot see the DHCPOFFER from my router
<mewt>
sorry, that should read "I cannot see the DHCPOFFER from the beaglebone". It is logged by LuCi
<zmatt>
markand: you mean ttyS4 ?
<zmatt>
markand: unfortunately the 8250 driver that creates the ttyS devices is a bit weird... they're created unconditionally, regardless of whether they're enabled in DT
<markand>
hmmm, I've seen that it's ttyO4 somewhere over the internet, let me try with ttyS4
<markand>
oh well, it's a symbolic link to ttyO4
<markand>
I mean the opposite, ttyS4 -> ttyO4
<zmatt>
(the number of ttyS devices created can be set in the kernel config or overridden at boot time using the 8250.nr_uarts kernel parameter)
<zmatt>
yeah ttyO* are symlinks to ttyS* for backwards compatibility
<markand>
I've read that I should use uboot_overlay_addr2=/lib/firmware/BB-UART4-00A0.dtbo
<zmatt>
markand: sounds like you're reading a lot of old info
<markand>
heh
<zmatt>
if you're on a modern image in its default configuration, "cape-universal" is enabled which enables most peripherals and creates "pinmux helper" devices that allow the pins to be muxed to peripherals at runtime (using the "config-pin" utility or by directly writing a sysfs attribute, e.g. https://pastebin.com/MKtWJ8G8 )
<zmatt>
so to use an uart all you then need to do is configure the pins using config-pin
<markand>
so it's P9.11 and P9.13 for uart 4 ?
<set_>
Yes!
<set_>
11 and 13!
<set_>
config-pin p9.11 uart && config-pin p9.13 uart <<< This does it!
<markand>
okay it goes better, thanks
<set_>
Nice!
<markand>
so I'll need to wrap my application into a sheel script to enable this before
<markand>
shell *
<markand>
oh and by the way, never buy any feig product
<set_>
Yes...
<set_>
Feig?
<set_>
Okay.
<set_>
Sounds like a Italian car.
<set_>
In your shell script, you do not need sudo for config-pin.
<set_>
markand: What file do you use to start your shell scripts on boot?
<markand>
it's the worse company for RFID identification products
<set_>
Oh.
<set_>
.bashrc?
<markand>
needs a large proprietary C++/Java SDK, are pretty unhelpful, anaemic documentation, needs proprietary software to read documentation (yes, a .exe file that shows up docs, really!)
<set_>
Ha.
<markand>
SDK throws undocumented errors
<set_>
Hahhaha. That does sound terrible.
<markand>
:(
<set_>
Sorry.
<set_>
Frowns all around!
<set_>
I see .service files pop up on the google searches but I thought there was another way to boot files when the board starts, i.e. shell scripts in particular.
<set_>
In this dir. /etc/init.d/?
<set_>
or symlink the file in /etc/init.d/ to /etc/rc.d/?