<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.
<set_> Anyway, blah. Back to my ramblings.
<zmatt> I mean, someone deadbugged an osd335x-csip out of pure silliness => https://twitter.com/pdp7/status/1100349116515827712
<set_> Hmm.
<set_> That is awesome.
<set_> But how?
<set_> Blog it!
<set_> Do you think he did it w/ a kernel or barebones?
<zmatt> probably a linux system, pretty much nobody programs the am335x baremetal, but dunno
<set_> So, he through a USB boot to chip and then programmed it w/ the USB?
<set_> Anyway, I do not know. That is awesome.
<zmatt> I guess?
<set_> He had like six wires and the usb-c.
<set_> I read an article a while back about how to program the smallest chip.
<set_> This fellow had more hardware to program the chip than anything else.
<set_> Power adapter, LED for confirmation, and on and on and on. I wonder if I could find it.
<set_> MCU. Sorry. not just a chip.
<set_> But, not as nice as your twitter video.
<set_> ...
<set_> Is it okay if I C & P from the beagleboard.org site W/OUT showing the published icon of the .org?
<set_> Oh! I will go and read the disclaimer again.
<rcn-ee> For side reference, the chip Octavo used in that demo has an built-in eMMC as on option.. ;) https://octavosystems.com/octavo_products/osd335x-c-sip/
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
<set_> oh!
<set_> Fooled me.
thinkfat_ has quit [Ping timeout: 240 seconds]
thinkfat has joined #beagle
<set_> rcn-ee: I just looke at their HVAC system deployment using an OSD335x type of chip. Very interesting, i.e. esp. the part w/ networking.
<set_> side note...I got like 45 paragraphs in w/ photos, code, and descriptions. Google Blogger died on me.
<set_> Ha.
<set_> Are you asking me if I yelled at google from my living room? I am shy but not too shy. Sure I did. Yes sir!
hnv has quit [Ping timeout: 272 seconds]
hnv has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
fakuivan has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
fakuivan has joined #beagle
CygniX_ has joined #beagle
CygniX has quit [Read error: Connection reset by peer]
KartikANK has joined #beagle
KartikANK has quit [Quit: Leaving]
rob_w has joined #beagle
Rohan has joined #beagle
<Rohan> Hello Together
<Rohan> I am new to beaglebone.
<Rohan> I bought beaglebone black. I am unbale to SSH to board however I am able to connect board via serial connection.
<Rohan> I am using Macbook Pro M1.
<Rohan> Can anyone please help?
<Rohan> I used "ssh debian@"
<Rohan> I get "ssh: connect to host port 22: Operation timed out"
<Rohan> denix Can you please help
<Rohan> jkridner Can you please help
<Rohan> agraf can you please help?
<Rohan> djinni Can you please help?
Rohan has quit [Quit: Client closed]
javaJake_ has joined #beagle
javaJake has quit [Ping timeout: 240 seconds]
javaJake_ is now known as javaJake
indigaz0 has joined #beagle
indigaz has quit [Ping timeout: 240 seconds]
indigaz0 is now known as indigaz
otisolsen70 has joined #beagle
florian has joined #beagle
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #beagle
Raajeshwar has joined #beagle
<Raajeshwar> Hi, I was using Beaglebone Black. Ethernet IP address was not correct sometimes after boot. Tried a software solution provided in link https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/ which didn't work in many cases. Anyone faced the same? Is there a solution to this?
kveremitz has quit [Quit: ZNC - http://znc.in]
ikarso has joined #beagle
kveremitz has joined #beagle
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
kveremitz has quit [Quit: ZNC - http://znc.in]
<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.
<Raajeshwar> Thank you.
kveremitz has quit [Quit: ZNC - http://znc.in]
kveremitz has joined #beagle
kveremitz has quit [Client Quit]
kveremitz has joined #beagle
set_ has quit [Ping timeout: 256 seconds]
otisolsen70 has quit [Quit: Leaving]
<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.
<rcn-ee> Raajeshwar: please share: journalctl | grep 'cpsw\|eth\|connman'
<rcn-ee> and systemctl status connman
<rcn-ee> expecting something like: https://paste.debian.net/1232527/
<Raajeshwar> Sure, but I don't have the device with issue right now. I will post it as soon as possible.
lucascastro has quit [Read error: Connection reset by peer]
lucascastro has joined #beagle
Raajeshwar has quit [Quit: Client closed]
florian has quit [Quit: Ex-Chat]
fakuivan has quit [Ping timeout: 240 seconds]
fakuivan has joined #beagle
fakuivan has quit [Ping timeout: 272 seconds]
buzzmarshall has joined #beagle
vagrantc has joined #beagle
nmingotti has quit [Ping timeout: 256 seconds]
vagrantc has quit [Quit: leaving]
<zmatt> rcn-ee: also, you've seen hotplug problems with systemd-networkd? any details?
<zmatt> it's worked very reliably for me in the many years I've used it now
<rcn-ee> yeah... un-plug ethernet, bootup.... plug in ethernet cable... (5.10.x) ethernet doesn't seem to auto come up..
<zmatt> and it's systemd-networkd specific? or did they just break the driver in 5.10 ? e.g. the phy power management bug workaround thingy
<rcn-ee> i don't think it's phy... flashing board right now to help..
<zmatt> have a kernel log and/or "ip addr" output?
<rcn-ee> zmatt: fresh bootup... Ethernet NOT plugged in.. https://paste.debian.net/1232545/
<zmatt> oh and networkctl ?
<rcn-ee> zmatt: and today... it works... https://paste.debian.net/1232546/
<rcn-ee> works as i want... https://paste.debian.net/1232547/
<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..
<rcn-ee> zmatt: there is a phy scan here, but we drop out before with skip_scan, wonder if we can force the driver to "auto"probe say with device tree variable for probe bus... (pre dt)... https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/ethernet/ti/davinci_mdio.c?h=v5.17-rc6#n408
<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
<rcn-ee> that's cool.. and if we fix 'reset' in u-boot, it gives linux a chance to not f**k it up..
<zmatt> well, soft-reset via mdio can't fuck up the phy
<zmatt> it just wastes time
vagrantc has joined #beagle
vigneshr has quit [Quit: Connection closed for inactivity]
russ has quit [Ping timeout: 240 seconds]
russ has joined #beagle
CygniX_ has left #beagle [Konversation terminated!]
CygniX has joined #beagle
otisolsen70 has joined #beagle
russ has quit [Ping timeout: 260 seconds]
fakuivan has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
russ has joined #beagle
otisolsen70 has quit [Quit: Leaving]
set_ has joined #beagle
zjason has quit [Quit: ERC (IRC client for Emacs 28.0.50)]