nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
Shadyman has joined #beagle
thinkfat has quit [Ping timeout: 245 seconds]
thinkfat has joined #beagle
russ has quit [*.net *.split]
noahm has quit [*.net *.split]
denix has quit [*.net *.split]
Epakai has quit [*.net *.split]
kona has quit [*.net *.split]
noahm has joined #beagle
Epakai has joined #beagle
russ has joined #beagle
denix has joined #beagle
kona has joined #beagle
rob_w has joined #beagle
ikarso has joined #beagle
shoragan[m] has quit [Quit: Bridge terminating on SIGTERM]
NishanthMenon[m] has quit [Quit: Bridge terminating on SIGTERM]
mvaittin has quit [Quit: Bridge terminating on SIGTERM]
suy|m has quit [Quit: Bridge terminating on SIGTERM]
shoragan[m] has joined #beagle
mvaittin has joined #beagle
suy|m has joined #beagle
NishanthMenon[m] has joined #beagle
otisolsen70 has joined #beagle
javaJake_ has joined #beagle
javaJake has quit [Ping timeout: 252 seconds]
javaJake_ is now known as javaJake
florian has joined #beagle
Shadyman has quit [Remote host closed the connection]
starblue has quit [Ping timeout: 272 seconds]
starblue has joined #beagle
* bradfa looks at USB 4 spec... yeah, no way in hell anyone produces an IP block that can do USB 4 correctly and without a 1000 page errata list in the next 5 years.
* bradfa will be seriously impressed if Intel's 3rd generation of USB 4 host controllers actually do things correctly (ie: I'm saying their first 2 tries will fail miserably), nevermind the USB 4 device side IP blocks or dual role or any of the tunneling junk
<zmatt> I think the Apple M4 has usb4 ? the alternative is hooking up some pcie to usb4 bridge
<zmatt> I mean, usb4 is largely based on thunderbolt, so it's not like it's all done from scratch
<zmatt> but still
<zmatt> apple M1 I mean
<bradfa> zmatt: does it? I can't keep up with tech news anymore...
<bradfa> oh, it does!
<bradfa> at least with Apple no one will ever see the errata list, they can keep it secret and make it look like they did it right, owning the silicon and the OS all in-house
<zmatt> hehe
<zmatt> you mean chips HAVE BUGS? *shocked pikachu face*
<bradfa> I look forward to the great jobs program which will be synopsis' USB 4 dual role controller IP block
<bradfa> many software engineers will send their children to college on that one
<zmatt> "roles" are fuzzy with usb4, it even supports host-to-host networking
<bradfa> yeah, and the whole time sync and routing and spanning tree and...
<zmatt> "USB4 by itself does not provide any generic data transfer mechanism or device classes like USB 3.x, but serves mostly as a way to tunnel other protocols like USB 3.2, DisplayPort, and optionally PCIe. While it does provide a native Host-to-Host protocol, as the name implies it is only available between two connected hosts; it is used to implement Host IP Networking."
<bradfa> it's like someone said, "You know what's great and super complicated?! USB! What can we combine it with to make it even more confusing? Networking! Video displays! Other versions of USB! PCIe! And if anyone else has any good ideas on how we can ensure our own jobs for the next decade please write them and place them in this box here outside my office."
* bradfa writes down, "Make the cabling even more complicated and confusing for normal people. HDMI cannot be best at this!"
<zmatt> I mean, like, given the prior existence of Thunderbolt 3, it kinda sorta makes sense for usb to usurp it
<zmatt> and actually reduce the number of incompatible things
<bradfa> zmatt: it just would've made sense for that to happen when USB went to 3.0
<bradfa> I don't recall why that didn't happen, seems like Intel was leading both
<zmatt> I guess, if usb3 had simply used pcie as the new transport
<bradfa> Also, seems like a big missed opportunity to have gone optical early and solved many other problems back then, too
<zmatt> instead of making a new one
<zmatt> optical is a no-go, they wanted passive adapters
<zmatt> to usb2
<bradfa> I knew I read this long ago!
<zmatt> yeah, Thunderbolt originally had nothing to do with usb
<zmatt> Thunderbolt 3 is where the real mess started
<zmatt> because using the same connector for different incompatible things is obviously a good idea and surely won't create confusion for normal users
<zmatt> heh, interesting
<zmatt> well, that didn't happen
<bradfa> everything old is new again!
<bradfa> but yeah, if you want a SoC with real USB 4 support, and not just the USB 3.x rebranded kind, you're probably going to have to sign up for a millions/year contract with a big boy silicon vendor and sign some crazy looking NDAs
<bradfa> or just wait for Intel to come out with something and beg them to sell it to you
shoragan[m] has quit [Quit: User was banned]
mvaittin has quit [Quit: User was banned]
NishanthMenon[m] has quit [Quit: User was banned]
suy|m has quit [Quit: User was banned]
lucascastro has joined #beagle
zjason` is now known as zjason
shoragan[m] has joined #beagle
mvaittin has joined #beagle
NishanthMenon[m] has joined #beagle
suy|m has joined #beagle
set_ has quit [Remote host closed the connection]
set_ has joined #beagle
Guest5 has joined #beagle
rob_w has quit [Remote host closed the connection]
<Guest5> hai i wanted to do tunneling in beaglebone black to remote server. but am beginner in the configuration side of it. so can any one please guide me to get to know the things.
<zmatt> wireguard may be of interest (and its kernel module is already included in the beaglebone's standard kernel I think)
<zmatt> (see for documentation)
<Guest5> how to use that by doing the service manner while booting up the board. please share me the reference.
<zmatt> ehh, there's a bunch of ways you could do that, though I don't really have time to go into details right now (I'm at work)
<Guest5> in here it not detailing the tunnel method. and the configurations.
<Guest5> let me know if any one knows please
Guest5 has quit [Quit: Client closed]
<vvn> With the stock bbb, you need to hold a button down to boot from the SD card instead of the eMMC, correct?
lucascastro has quit [Remote host closed the connection]
lucascastro has joined #beagle
<set_> No. I am pretty sure you need to the hold down the Boot Button/S2 on the board to boot to eMMC.
<set_> That is only if the board has a SD Card in it too.
<set_> Unless something has changed recently or in the last year, that is how I managed to use the eMMC image over SD image w/ a SD Card in the slot while having two images, i.e. one on the eMMC and one on the SD Card in its slot on the BBB.
florian has quit [Quit: Ex-Chat]
AKN has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
AKN has quit [Read error: Connection reset by peer]
lucascastro has joined #beagle
<starblue> vvn: that's how my bbb behaves, after a power cycle, after a reset it will use the same boot medium again
<starblue> but then I started with bbb only last may, so maybe it changed last april? 😎
ikarso has quit [Quit: Connection closed for inactivity]
vagrantc has joined #beagle
<set_> Hmm. That is neat. I never noticed that fact. Thank you for sharing this info.
buckket has quit [Quit: buckket]
buckket has joined #beagle
<starblue> You can also put a boot configuration on eMMC that will try to boot from SD card first, that's IMHO the most convenient setup.
ikarso has joined #beagle
<set_> in uboot?
<set_> like if one was to use a build env. for booting the board, e.g. ____-ng or Buildroot?
zjason has quit [Read error: Connection reset by peer]
lucascastro has quit [Ping timeout: 272 seconds]
zjason has joined #beagle
<starblue> Yes, buildroot. I think it is the default, last time I was lazy and just copied U-Boot over from the SD card to the eMMC, and it worked.
<starblue> That was in January, I set up a bbb to water some plants.
<set_> Ha. nice.
<set_> There was an older script floating around the planet handling such a task.
<set_> So, just using Linux to transfer the uboot commands can work too ( I guess ).
xet7 has joined #beagle
buzzmarshall has joined #beagle
otisolsen70 has quit [Quit: Leaving]
Shadyman has joined #beagle
<zmatt> vvn: powering on with the S2 button held down will cause the bbb to ignore the bootloader on eMMC (if any) and always use the one from sd card
<zmatt> (and it will keep doing that until next power-cycle, the button isn't checked at reboot)
<zmatt> vvn: however, the bootloader on eMMC will normally still prefer booting the system on sd card, if any, over booting from eMMC
<zmatt> so usually it'll just boot from SD card when one is inserted, the button is not needed
<zmatt> however, if the system on sd card is too different from the one on eMMC, the bootloader on eMMC may not be compatible with the sd card and fail to boot it (or worse, boot it but ignore some settings in /boot/uEnv.txt, causing weird problems) ... that's when the S2 button comes in use
<vvn> yes I was about to say that it depends on the bootloader
<vvn> but thank you, it answers my question!
<zmatt> also useful if you somehow bork the bootloader on eMMC
<zmatt> or if you want to be really sure it either boots from SD card or not at all
<zmatt> starblue: that's actually the default yes
<zmatt> starblue: for the normal images anyway, dunno buildroot
<zmatt> set_: ehh, you're very confused. if you power on with the S2 button held down it will _never_ boot from eMMC
<zmatt> (ignoring some really weird scenarios, like having an sd card inserted with just a bootloader on it but no linux system)
nparafe has quit [Quit: - Chat comfortably. Anywhere.]
nparafe has joined #beagle
ikarso has quit [Quit: Connection closed for inactivity]
<set_> Oh.
<set_> Okay.
<set_> Sorry vvn.
<set_> I made an error in understanding the spewed it out.