<set_>
Does the newer BBB have a SiP or is it still SoC styled?
<zmatt>
there's been no major redesign of the BBB, just some small tweaks
<set_>
Okay. So, unlike the BBBW, the BBB is a SBC w/ SoC tech. Okay. Got it.
<zmatt>
why would they redesign it? it would just make it more expensive for no benefit
<set_>
I am trying to keep up w/ the times. I am starting a dang-gone blogger account w/ blogging as evidence of me on this Earth w/ the BBB.
<set_>
I thought people would like major updates.
<set_>
Not me per se but others may want other things available.
<zmatt>
it wouldn't be an update
<set_>
Oh.
<set_>
Upgrade?
<zmatt>
no?
<set_>
Downgrade?
<set_>
I do not know.
<zmatt>
not either really, except for probably being more expensive
<set_>
no grade?
<set_>
Oh.
<zmatt>
the main benefit of the osd335x is that it makes it easier to design a board... but that's not a benefit if the board has already been designed
<set_>
got it. I purchased a OSD335x SiP b/c I thought I could afford the BGA socket.
<set_>
The BGA socket is like 750% of the cost of the chip.
<set_>
ha.
<zmatt>
nobody uses these things with sockets
<set_>
I know but for my learning, as usual, things should start slow.
<set_>
Not to the moon w/ set_ is the idea. Grounded and slow mo'.
<set_>
It would have been cool to use a single pin to my liking. Anyway, you are right. I am making things up. I should not use the BGA socket or OSD335x for anything yet. I am not that dude, sir.
<set_>
Maybe a blog?
<set_>
Is that slow enough?
<set_>
There are no updates to peoples blogs. It is like the world changes and the blogs are left in the dust w/out updates.
kveremitz has quit [Read error: Connection reset by peer]
kveremitz has joined #beagle
kveremitz has quit [Ping timeout: 240 seconds]
kveremitz has joined #beagle
Konsgnx1 has joined #beagle
Konsgnx1 has quit [Read error: Connection reset by peer]
<Raajeshwar>
Kernel 4.14.71-ti-r80
Steve_ has joined #beagle
SJFriedl has quit [Ping timeout: 240 seconds]
rob_w has quit [Remote host closed the connection]
<zmatt>
Raajeshwar: what do you mean by "wrong ip address" ? if you're suffering from the ethernet issue the result would be that ethernet doesn't work whatsoever
<zmatt>
the IP address configured for Ethernet is the one offered by your network's DHCP server, the BBB has no influence over that
<Raajeshwar>
Wrong IP address means a random IP assigned to eth0. When that happens board couldn't access the internet. When rebooted again, it just fixes it. Also this doesn't happen in all boards. Only few boards behave this way. Changing LAN switch or connecting to a different network didn't work in that device. Just rebooting few times will make it occur.
kveremitz has joined #beagle
<zmatt>
odd
<zmatt>
if it's fixed by rebooting then it's definitely not an ethernet phy issue
<zmatt>
those issues require a hard reset (using the button) or power cycle to resolve
<zmatt>
so it still sounds like a software issue or networking issue to me
<zmatt>
although I have no explanation of why it would only affect certain boards
<Raajeshwar>
Oh ok. But only on 2/10 boards we had.
<zmatt>
they're all running the same debian image?
<Raajeshwar>
Yes
<Raajeshwar>
One image flashed in all boards
<zmatt>
by "random ip address" you mean a link-local 169.254.xxx.xxx address?
<Raajeshwar>
Yes
Shadyman has joined #beagle
<zmatt>
I guess I'd try monitoring with a packet sniffer to see what's going on?
<zmatt>
also try to see if the board is reachable via its link-local IPv6 address (fe80::xxxx:xxxx:xxxx) in that state, e.g. using ping6 from another board
<Raajeshwar>
Ok. We will try it out.
<zmatt>
just to clarify, when you said "rebooting" you mean using "sudo reboot" ?
<Raajeshwar>
Yes
<Raajeshwar>
From terminal we did "sudo reboot"
<zmatt>
okay yeah, then this definitely isn't related to the ethernet phy issues described by that article you linked
<zmatt>
those can neither be triggered by reboot nor resolved by it
<Raajeshwar>
Ok. For sure we didn't do reset or power down the board by unplugging from the supply. We will further test it and post the updates.
<rcn-ee>
Raajeshwar: have you posted a pastebin of a full dmesg of those boards yet? i didn't seen anything in the scroll back..
<Raajeshwar>
No I haven't posted it. Currently I don't have that board. Will post it once I get to the board. I have a working board now which is perfectly fine. After number of reboots it looks good, getting expected IP.
<rcn-ee>
can you get in over usb or serial (j1)?
<Raajeshwar>
Yes, I was able to connect with USB when I see the issue. I was able to see wrong IP in ifconfig.
<rcn-ee>
was the Ethernet plugged in before power up? I've seen some weird hotplug problems with systemd-networkd... Are you using connman, network-manager, systemd-networkd or some other networking backend?
<Raajeshwar>
Yes, board was connected to ethernet before power up. We are using connman.
<zmatt>
that first paste looks like what I'd expect for "ethernet not plugged in" though
<zmatt>
it's administratively up, but has no carrier
<rcn-ee>
checks that off my list... random bugs i've been seeing.; )
<zmatt>
that sounds unsatisfying if you think there was a bug but it just randomly vanished
<rcn-ee>
about as satifying as my "bad" phy board, showed the issue for 2 days last week, but then started working...
<zmatt>
we have a board here that statistically showed the phy issue fairly regularly, though I haven't verified it still does it
<zmatt>
(we used it to test hardware workarounds)
<rcn-ee>
Well right now, if your booting v5.10.x+ (with TI's new cpsw driver) there is no kernel workaround.. And on that board, the "u-boot" workaround also wasn't working... then magically started working... hard to test patch options when the boards are so random..
<zmatt>
we're still on 4.14, so the current software workaround works for the cases where the phy works but has the wrong address, but that still leaves the cases where the phy doesn't work at all which is the part we were trying to find a workaround for
<zmatt>
the mainline u-boot board code looked like it's supposed to work for both new and old cpsw driver? but obviously still only for the cases where the phy merely has the wrong address (but otherwise still works)
<rcn-ee>
i'm also not even sure if the u-boot section is actually being run.. that was the last thing i playing with, dumping printf's around that..
<zmatt>
rcn-ee: well, you kinda want this resolved in u-boot anyway (also for things like netboot), so I do think that that having u-boot patch the DT is ultimately the best solution
<zmatt>
of course on the latest BBB revision you can (and should) just reset the phy until it works properly, but that doesn't help for previous BBB revisions
<rcn-ee>
for the newer design, doing the gpio reset in u-boot is also easier.. for some reason phy-reset is a mess on mainline..
<rcn-ee>
it's best we do all fixes in u-boot
<zmatt>
yeah the phy reset gpio line should only be used for the workaround, not for normal phy resets u-boot or the kernel may want to do afterwards (for some reason... it doesn't seem to have any point other than delaying link up)
<zmatt>
since using the phy reset gpio on a properly working phy can (afaik) also result in a faulty phy state
<rcn-ee>
the older cpsw driver was already slow enough, doing a reset in linux just slows it down more..
<zmatt>
I think I actually patched our kernel to eliminate one of the pointless resets