<cyrozap>
It'd bring us closer to the ideal of "everything is Ethernet" :)
<cyrozap>
azonenberg: ^
pie_ has joined ##openfpga
bibor has quit [Ping timeout: 252 seconds]
pie_ has quit [Ping timeout: 240 seconds]
balrog has quit [Quit: Bye]
balrog has joined ##openfpga
ZipCPU|Laptop has quit [Ping timeout: 248 seconds]
digshadow has quit [Ping timeout: 250 seconds]
<pointfree>
cyrozap: Would this require implementing a full USB-C driver?
<pointfree>
I don't like that USB-C cables require firmware inside the cable.
digshadow has joined ##openfpga
<cyrozap>
pointfree: Most USB-C cables don't have or need firmware, unless they're for power delivery.
<cyrozap>
And Ethernet alternate mode doesn't exist (yet).
<pointfree>
cyrozap: I thought USB-C alternate modes are only available through the Power Delivery Protocol.
<pointfree>
Also, you can have your own custom alternate modes.
azonenberg_work has joined ##openfpga
azonenberg has quit [Ping timeout: 265 seconds]
openfpga-bb has quit [Ping timeout: 260 seconds]
openfpga-bb has joined ##openfpga
azonenberg has joined ##openfpga
nrossi has joined ##openfpga
Bike has quit [Quit: Lost terminal]
user10032 has joined ##openfpga
oeuf has quit [Ping timeout: 272 seconds]
<felix_>
for the alternate modes a device needs to support the power delivery protocol (it does not need to support the various pd modes though). pd and alternate modes use the same mechanism to communicate that
oeuf has joined ##openfpga
<lain>
yeah, and in USB-C that goes over CC (Control Channel)
<lain>
another neat trick I've been meaning to do with usb-c is add a sata alt mode. infinitely more useful than esata, since usb-c can supply power to the drives, and you can put two sata drives per usb-c connector.
<felix_>
yeah, that sounds like a good idea
<rqou>
yeah, why doesn't it already have sata/raw-non-tb-pcie/1000base-x/10gbase-x alternate modes?
<felix_>
iirc there is some pcie alternate mode
<rqou>
there's a _thunderbolt_ alternate mode
<felix_>
that too
<rqou>
wait, both?
<felix_>
if i remember that corrently, yes
<rqou>
wtf
<rqou>
wait that proposed idea is to hook an ethernet mac to a usb 3.1 phy wtf
<sorear>
how bad is nvme for spinning disks? could use that maybe
<rqou>
just use a normal 10g fiber phy
<rqou>
i thought nvme ran over pcie?
<sorear>
yeah, and you could use it with the pcie alternate mode felix_ just described
<rqou>
too many stupid permutations possible :P
<sorear>
amazon is doing a NAS over NVMe now
<rqou>
10g nic over pcie over usbc alternate function? :P
<rqou>
lain: usb-c to sfp+ DAC cable :P
<sorear>
maybe
<sorear>
or xhci to mess with people :P
<rqou>
there's also yet another idea to run the ethernet base-t phy over the usb3.1 wires
<rqou>
iirc?
<rqou>
for maximum incompatibility, have some vendors running a base-x phy, some running a base-t phy, some running sgmii, and some running ethernet glued to a usb 3.1 phy :P
inode has joined ##openfpga
user10032 has quit [Quit: Leaving]
<felix_>
there are even two ways to transfer an hdmi signal over usb type c...
<felix_>
and even more ways to connect a hdmi display to a type c connector ;P
eduardo__ has joined ##openfpga
eduardo_ has quit [Ping timeout: 276 seconds]
<eduardo__>
whitequark: Did you do a UDP or TCP/IP implementation ?
<eduardo__>
whitequark: I was asked by a guy from CERN . They are looking for a UDP or better TCP/IP implementation which they could use for their mixed signal particle sensor ASIC in the ATLAS sensor. Should be 1 GBit. They do 65nm and 130nm. Radiation hardened.
<sorear>
er, that's a software impl and you're clearly asking for some kind of hardware impl, ignore me
<sorear>
[what is a hardware impl of tcp/ip?]
<cr1901_modern>
sorear: Ask @fieldhamster/michael field, azonenberg, or _florent_. They've all done one.
ym has quit [Quit: Leaving]
m_t has joined ##openfpga
m_t has quit [Remote host closed the connection]
m_t has joined ##openfpga
pie_ has joined ##openfpga
moho1 has quit [Ping timeout: 260 seconds]
Bike has joined ##openfpga
moho1 has joined ##openfpga
eduardo__ has quit [Ping timeout: 248 seconds]
eduardo__ has joined ##openfpga
<azonenberg>
cr1901_modern: My implementation wasn't finished enouhg to use - it worked but had performance issues
<azonenberg>
i have ideas on how to make it better but never finished
<azonenberg>
worse yet, it was for FPGA and not ASIC and would take a while to convert
<azonenberg>
it relied on block ram / ff init at POR
azonenberg_work has quit [Ping timeout: 265 seconds]
RaivisR has quit [Read error: Connection reset by peer]
<balrog>
azonenberg: does ULA ASIC to netlist decoding fall somewhere on your silicon RE tools plan? :)
<balrog>
s/ULA/gate array
<azonenberg>
balrog: That would be a special case of ASIC RE in that it would still need die photos, but only of a few layers and the rest could be inferred from positions on the die
<azonenberg>
Given the photo-to-polygon vision code it would be easy
<balrog>
azonenberg: there's TONS of legacy stuff that uses these things
<azonenberg>
In general i am focusing mostly on fpga short term simply b/c it doesnt depend on a bunch of lab upgrades we have to do at work
<balrog>
with a comparatively small set of standard cells
<azonenberg>
also, gotta run out to the office
<balrog>
alright
<qu1j0t3>
pointfree: fwiw I bought an Anadigm 5V board.
azonenberg_work has joined ##openfpga
m_w has joined ##openfpga
azonenberg_work has quit [Ping timeout: 265 seconds]
mumptai has joined ##openfpga
azonenberg_work has joined ##openfpga
nrossi has quit [Quit: Connection closed for inactivity]
oeuf has quit [Ping timeout: 265 seconds]
c60k28 has joined ##openfpga
pie__ has joined ##openfpga
pie_ has quit [Remote host closed the connection]
oeuf has joined ##openfpga
digshadow has quit [Ping timeout: 240 seconds]
<_florent_>
eduardo__: here is a the core i wrote: https://github.com/enjoy-digital/liteeth, it can be configured to do MAC/IP/UDP in hardware with various PHYs (there is also Etherbone support on top of UDP) . Hardware implementation has been validated on FPGA, it should not require too much work to port it to ASIC but would need more testing of corner cases.
<eduardo__>
_florent_: great. Thanx. Will forward this. Lets see if they are interested.
<_florent_>
eduardo__: this is using migen (python that generates verilog), but can be re-written in VHDL/Verilog without too much efforts i think if configuration is known.
felix_ has quit [Ping timeout: 255 seconds]
digshadow has joined ##openfpga
felix_ has joined ##openfpga
pie___ has joined ##openfpga
pie__ has quit [Read error: Connection reset by peer]
theMagnumOrange has quit [Read error: Connection reset by peer]
<digshadow>
balrog: IMHO current roadmap is django monkeys for ROM, then lambda based IC, then ULA crowdsourcing
<lain>
now that I have an AMD box I want to start poking PSP
<lain>
but from a cursory glance, it looks like it doesn't have all the fancy enterprise BS that makes Intel ME so scary, like lights-out access :P
pie_ has joined ##openfpga
pie___ has quit [Ping timeout: 240 seconds]
RaivisR has joined ##openfpga
pie_ has quit [Remote host closed the connection]
pie_ has joined ##openfpga
<felix_>
from what i read, the psp could also do some really nasty things
mumptai has quit [Quit: Verlassend]
<felix_>
intel amt and amd dash aren't that different and uhm amd sucks at securing their stuff much more than intel
<lain>
well that's unfortunate
<lain>
hmm I have a bios image, I wonder if the PSP signing key is in it
<lain>
I wonder if it was generated on a ROCA-vuln smartcard :P
<awygle>
lol @ 802.3bs
<awygle>
On several levels
<felix_>
$person did some work on the psp fimrware image unpacking. not sure though if that was published
<lain>
oh interesting, PSP has something like BootGuard. I'm glad it isn't enabled on this machine (confirmed by flashing unsigned firmware to the spi flash)
<rqou>
oooh I didn't even think about checking burned-into-rom rsa keys for ROCA
<rqou>
somebody please do that
<lain>
I already checked the Intel ME signing key
<rqou>
it's not presumably?
<lain>
it's not vuln, yeah
<rqou>
somebody check nprotect's new key lolol :P
<rqou>
the >512 bit one :P :P
<lain>
I love when the "we want open bios" people argue that the signing keys should be released so everyone can sign anything they want, while simultaneously arguing that the whole thing is a security disaster
<lain>
I'm all for open firmware, but uhm
<lain>
releasing the signing keys /is a vulnerability/
<lain>
I've even seen people say "if someone had access to the private signing keys they could sign malware!" and in the same paragraph call for releasing the private signing keys so they could sign their own open-source firmware
<lain>
</rant>
<rqou>
I'd be ok with "invasive physical jumper allows replacing signing keys"
<felix_>
small but rather loud fraction. and they usually don't know or care about the implications
<rqou>
like how chumby and chromebooks have the flash ~WP signal on a testpoint
<felix_>
yep, allowing the users to provision their own keys is more like the way to go
<felix_>
some ideas of teh chromebook security model are really good
cr1901_modern has quit [Read error: Connection reset by peer]
<lain>
yeah, I agree
<azonenberg_work>
yeah thats a good compromise
<azonenberg_work>
Allow overwriting the keys, but doing so wipes a "not tampered" key of some sort
<azonenberg_work>
So you can detect the device is no longer in OEM configuration
<azonenberg_work>
at any time allow uploading a new "not tampered" key so i can verify that my own signing key hasnt been altered etc
<felix_>
or like unlocking the bootloader from an android phone. you get to run your own code, but the user data gets lost during the unlock, since the aes key gets wiped
<lain>
felix_: any idea how to extract the psp firmware image from a uefi capsule or spi flash dump?
<lain>
I ran uefi dump but there's a lot of things with psp in the name :s
<felix_>
uh, have a look what the build system does in coreboot
<felix_>
i don't remember the details
<rqou>
unfortunately android isn't _quite_ the same
<rqou>
iiui the bootloader will always drop you in EL1 or EL2 at best and you can't run EL3 code
<felix_>
oh, well, i didn't mean the real implementation there, but the user experience
m_t has quit [Quit: Leaving]
cr1901_modern has joined ##openfpga
<lain>
hm
<rqou>
apparently even getting android bootloaders to drop you in EL2 is hard
<lain>
yeah I have no idea how to find anything in coreboot source tree :P
<lain>
ah well
<lain>
the coreboot Build_HOWTO wiki page just says that users need to extract the PSP firmware for building into coreboot, but it doesn't say /how/