<sorear> rqou: does retaliation refer to the siliconpr0n thing?
<rqou> yes
<rqou> and apparently now d!gshadow is spreading lies about it
<sorear> What is his version of the story
<rqou> that my release of no-symbiflow tools violated a verbal NDA
<rqou> which is extremely false
<rqou> it was specifically constructed not to
<gruetzkopf> hm, a XC7A15T may be an option if i can get at the TLPs there
<rqou> lol trying to tunnel pcie over something?
<gruetzkopf> yes
<gruetzkopf> this time, proper, switchable, ethernet
<gruetzkopf> ethertype 0x22E4 :P
<rqou> not f0f-style ethernet?
<gruetzkopf> f0f mode would be easy to add :P
<etrig> huh, I ordered a funny 3-in-1 programming adapter that I thought was broken but it looks like xilinx has just been shipping the wrong xusb_emb.hex ever since they released vivado I guess
<gruetzkopf> if i do this "easy mode" i might generate ethernet frames of ~4200B though
<gruetzkopf> if i implement a fake pcie switch i can clamp that to "normal" sizes
<rqou> meh, within normal jumbo frame sizes
<gruetzkopf> i should implement a fake switch anyways
<gruetzkopf> so i can get at the SFP+ modules EEPROM and DOM
<rqou> then it can look even more like the clusterfuck that is thunderbolt :P
<gruetzkopf> that's the only sane part of it, really
* whitequark stares at rqou
<whitequark> don't even mention thunderbolt
<rqou> we can call it etherbolt :P
<whitequark> lol
<gruetzkopf> i mean, i should likely expose a third device, you know, a 'normal' nic?
<rqou> we should RE thunderbolt while we're at it :P
<gruetzkopf> the more i read and hear about it the more i want to throttle someone at santa clara
<rqou> not cupertino?
<gruetzkopf> i already have enough reasons to do that
<whitequark> lol
<azonenberg_work> rqou, awygle: afaik RXAUI is only supported by like one broadcom chipset
<azonenberg_work> its impossible to use for mere mortals
<rqou> lol
<rqou> "is a proprietary modification created by Marvell[2] and Dune Networks"
<azonenberg_work> gruetzkopf: the xc7k160t has 8 10g gtx's
<azonenberg_work> But fbg484 only bonds out four
<rqou> ooh that's why i remember it was 4
<azonenberg_work> So you need the ffg676 or larger package
<azonenberg_work> Also prjxray is targeting kintex. So it should work
<rqou> how big is that package, physically?
<azonenberg_work> 26 balls square 1mm pitch plus margin
<azonenberg_work> So 27-28?
<rqou> wait
<rqou> so ~ 3cm x 3cm
<azonenberg_work> Yeah
<rqou> that seems smaller than i expected
<azonenberg_work> And ffg. The heat spreader version
<azonenberg_work> flip chip
<azonenberg_work> The cheap 676 cant do 10g due to package si concerns
<rqou> i thought they were recently requalified?
<azonenberg_work> Only the 484 ball variant
<azonenberg_work> FBG484 is flip chip but no heatsink and was originally specced at 6G max
<sorear> gruetzkopf: is there something wrong with stapling together a few ecp5s?
<azonenberg_work> They upgraded it to 10G recently
<azonenberg_work> But apparently 676 has too long wires or something?
<rqou> huh
<azonenberg_work> Until then i was gonna do 1156 ball artix for the switch
<azonenberg_work> and xaui
<awygle> azonenberg_work: there's an NDAd Microsemi chip that does RXAUI
<awygle> at least one
<azonenberg_work> Now 484 kintex can do it
<azonenberg_work> awygle: My point stands. Not accesible to mere mortals
<rqou> can you actually get usable yield on a 1156-ball part?
<awygle> I know
<azonenberg_work> rqou: Never tried
<awygle> That's exactly what I said earlier
<azonenberg_work> It would also need an 8+ layer board. Prob 12
<azonenberg_work> The 484 kintex is 6, maybe 8
<gruetzkopf> i think at least for "demo" it's gonna be ECP5
<azonenberg_work> rqou: i've toaster ovened a fbg484 kintex7 though
<gruetzkopf> join the deep-fry club.
<gruetzkopf> don't even really need 5G for demo purposes
<gruetzkopf> xilinx' pcie stuff uses the normal transceivers too
<rqou> i thought it had a hard macro?
<rqou> idk how that is connected to things
<azonenberg_work> its a hard mac or something
<azonenberg_work> for pcie 2
<gruetzkopf> it's basically impossible to find the documentation at all
<azonenberg_work> pcie 3 wasnt final at tapeout so they use a soft core
<rqou> lol yeah
<azonenberg_work> You can of course softcore pcie 2 too
<rqou> we should start by poking the phasers tbh
<azonenberg_work> Agreed
<whitequark> litepcie
<awygle> litepcie uses the hard IP right?
<awygle> and is Xilinx only?
<gruetzkopf> "here's a list of all 7-series" "great, but i want to know exactly what i can use of this exact device at the same time"
<whitequark> oh hm
<rqou> need to write a "heavypcie" :P
<rqou> or use f0f-pcie?
<whitequark> right, it uses xilinx phys
<whitequark> what's f0f?
<rqou> no wait, iirc f0f-pcie was a hacked up blob
<rqou> fail0verflow
<gruetzkopf> it's getting worse with every single xilinx generation
<azonenberg_work> gruetzkopf: gimme a sec
<awygle> I'd love a "just a serdes" PCIe core, ideally in verilog but I'm not picky
<rqou> gruetzkopf: hey, altera has a hard nios in their serdes
<rqou> not sure if better or worse
<gruetzkopf> wat
<awygle> Isn't that RIFFA thing supposed to do that? Or part of it?
<azonenberg_work> This may be useful
<azonenberg_work> this is a pretty large list of fpgas from various vendors focused on serdes
<azonenberg_work> how many of what speed, how much the chip costs
gnufan has quit [Ping timeout: 264 seconds]
<rqou> oh nice
<azonenberg_work> if webpack or the equivalent free-as-in-beer vendor toolchain works with it
<azonenberg_work> etc
<azonenberg_work> And digikey pricing as of a couple months ago
<gruetzkopf> that's pretty helpful
<gruetzkopf> the thing i wanted to know from xilinx was "does the pcie hard ip consume transceivers, and if so, which"
<azonenberg_work> Along with calculated cost per RGMII, 10G, etc interface (this was targeting ethernet swtich desing)
<rqou> gruetzkopf: also iirc xilinx has a microblaze embedded in their serdes
<azonenberg_work> gruetzkopf: Yes it does, and i think it may be flexible
<rqou> not sure if hard or soft though
<rqou> rumors are that these control (among other things) NBTI mitigations
<awygle> doesn't include SGMII/1000-X compat tho azonenberg_work :-P
<azonenberg_work> awygle: well any transceiver can do SGMII
<awygle> yeah but often gpio can too
<azonenberg_work> I could add options for max LVDS io, whether LVDS can do SGMII, etc
<awygle> After a certain point on that list
<awygle> (I don't actually care, I know what I like and want to use)
<azonenberg_work> But for the sake of the initial "how many GTPs can i get"
<azonenberg_work> that spreadsheet was awesome
<awygle> yup, that's why I added the ecp5 and altera stuff to it
<awygle> Very useful reference
<gruetzkopf> might just have to to a ghetto poc first
gnufan has joined ##openfpga
<gruetzkopf> single ECP5, single pcie1 lane, one round-trip via a 1G optics
Miyu has quit [Ping timeout: 245 seconds]
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
Ultrasauce has quit [Remote host closed the connection]
Ultrasauce has joined ##openfpga
unixb0y has quit [Ping timeout: 240 seconds]
GenTooMan has quit [Quit: Leaving]
unixb0y has joined ##openfpga
futarisIRCcloud has joined ##openfpga
kristianpaul has quit [Quit: Lost terminal]
kristianpaul has joined ##openfpga
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/a994314d8d7edd6cdea9f39adfa955873c45a442
<openfpga-github> Glasgow/master a994314 whitequark: applet.spi.flash_avr: new applet.
<gruetzkopf> neat
<travis-ci> whitequark/Glasgow#31 (master - a994314 : whitequark): The build passed.
<gruetzkopf> it's not too long since i last bootstrapped a usb avr programmer using the "stick wires into printer port" method
<whitequark> where do you expect me to find a printer port lol
<gruetzkopf> on the laptop dock :P
<sorear> didn't you used to have one living in your apartment
<whitequark> lol
<gruetzkopf> i have used worse methods
emeb has quit [Quit: Leaving.]
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/ae7baf0a0b243c9d3d7de8c881bc46ef023e2d7d
<openfpga-github> Glasgow/master ae7baf0 whitequark: applet.spi.flash_avr: take DUT out of reset before exit.
<travis-ci> whitequark/Glasgow#32 (master - ae7baf0 : whitequark): The build passed.
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/62cc57f79627ed4181c861acce402c52589e3c88
<openfpga-github> Glasgow/master 62cc57f whitequark: applet.spi.flash_avr: add attiny24/45/85 support....
<travis-ci> whitequark/Glasgow#33 (master - 62cc57f : whitequark): The build passed.
soylentyellow_ has joined ##openfpga
soylentyellow has quit [Ping timeout: 252 seconds]
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/23e3369c2a9cc4f4cd126257060fe364b13bd667
<openfpga-github> Glasgow/master 23e3369 whitequark: applet.spi.flash_avr: fix applet description.
<travis-ci> whitequark/Glasgow#34 (master - 23e3369 : whitequark): The build passed.
soylentyellow has joined ##openfpga
rohitksingh_work has joined ##openfpga
soylentyellow_ has quit [Ping timeout: 252 seconds]
rohitksingh_wor1 has joined ##openfpga
rohitksingh_work has quit [Ping timeout: 252 seconds]
kuldeep has quit [Ping timeout: 252 seconds]
kuldeep has joined ##openfpga
rohitksingh_wor1 has quit [Quit: Leaving.]
rohitksingh_work has joined ##openfpga
sunxi_fan has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
<rqou> whitequark: https://twitter.com/whitequark/status/1036495358707286017 <-- the worst thing i've ever heard of (for real, not as a troll) was an svn "branch" called FinalMergeReal2
<whitequark> hahahaha
<rqou> and by "branch" i mean "directory, under the branches/ hierarchy"
<whitequark> On entry to the PE_DFP_VDM_Mode_Entry_NAKed state the Policy Engine Shall inform the Device Policy Manager of
<whitequark> the reason for failure (NAK, BUSY, timeout or Protocol Error).
<whitequark> god this is like walking through molasses
<whitequark> something like 400 pages out of the 600 page specification looks autogenerated and is completely useless
<rqou> you haven't seen anything yet
<rqou> try a missile-chip-company datasheet
<rqou> try 10k pages
<whitequark> SoC datasheets being 10-20k pages is OK
<rqou> no it isn't
<whitequark> well other than my PC running out of memory with the pdf bitmap cache
<rqou> one of them broke the document management/watermarking server
<whitequark> but that's just okular being shit
<whitequark> lol what
<rqou> yeah
<rqou> it was also completely useless
<rqou> pages and pages of stuff like "mac table foobar-feature entry 0"
<rqou> "mac table foobar-feature entry 1"
<rqou> repeat 2^n times
<whitequark> LOL
Bike has quit [Quit: Lost terminal]
<rqou> i wonder how common autogenerated "documentation" is?
<rqou> oh yeah whitequark how do you feel about hardware designed in excel? :P
<rqou> iirc you tweeted about this before
<whitequark> sigh
<whitequark> not again
<whitequark> broadcom would be the 4th major company that does this
<rqou> amazingly, afaik they didn't
<rqou> or at least the switches didn't
<rqou> they had a much more... unusual workflow instead
<rqou> but excel was only used to estimate things which seems pretty normal
<rqou> oh yeah, they also did have the classic spreadsheet to explain to customers why the bandwidth displayed on a test set does not match expectations
<rqou> e.g. if one clock was maximally fast and one was maximally slow then packets would be dropped
<rqou> whitequark: this foss project is designed in libreoffice instead http://j-core.org/
<cr1901_modern> Well, the microcode anyway
sunxi_fan has joined ##openfpga
<cr1901_modern> "microcode editor" seems like quite a domain-specific GUI application
<rqou> hence the use of excel :P
<rqou> you can even use macros to generate interlocking or whatever :P
<cr1901_modern> I feel like there should be a "microcode assembler" that's smart and autogenerates offsets for various fields in a microcode word
<rqou> whitequark: https://twitter.com/whitequark/status/1036504737347198976 <-- did you know that fruit company has an undocumented guid in _DSM for force-injecting data into iokit/devicetree?
<rqou> yes, i think you needed to know that :P
Miyu has joined ##openfpga
<rqou> whitequark: dumb question: do you know if alpine ridge actually contains an xhci controller?
<rqou> or is it tb-only?
<whitequark> rqou: it has an xhci controller
Miyu has quit [Ping timeout: 245 seconds]
<rqou> so now i'm confused
<rqou> how is the usb-c side channel actually managed?
<rqou> 7WZWP85V84W8Q&th=1 there's no funny extra cable or anything
<rqou> so how does the cpu actually control the usb alternate modes?
<rqou> or is it entirely autonomous on this type of card?
<rqou> also, what prevents this device from working in just any old motherboard?
<whitequark> rqou: hahahahaha of course there is a funny extra cable
<whitequark> look at the comments
<whitequark> Short answer: no.
<whitequark> It needs direct connection to the PCI express slot + has an additional cable that plugs into the motherboard.
<rqou> oh huh it does
<whitequark> and the motherboard has a GPIO cable that lets you set modes.
<rqou> they just hid it in the photos
<whitequark> yes. horrible piece of shit.
<rqou> wait that header only has 5 wires
<rqou> wtf is it for?
<rqou> wtf why does foxconn have a patent on this
<whitequark> it reads the alternate mode list through SMBus and then sets the altmode via this stupid GPIO header
<whitequark> why the fuck they couldn't just have used SMBus for everything is beyond me
<rqou> that's stupid
<rqou> wait a sec
<rqou> why does it need to loop through the cpu in the first place?
<rqou> why can't the card itself select the mode it should use?
<whitequark> no fucking idea
<rqou> so um... with everything just barely hidden, why hasn't anybody just fully reverse engineered thunderbolt yet?
<whitequark> because it's a goddamn piece of shit
<whitequark> AAAAAAAA
<whitequark> I figured out why it doesn't work
<rqou> why?
<whitequark> ACPI doesn't deliver a "USB C device is plugged in" notification
<rqou> wait why is acpi involved?
<rqou> i thought xhci could do that by itself?
<whitequark> no
<whitequark> it's for altmodes
<whitequark> altmodes don't involve XHCI at all
<rqou> wtf
<rqou> why are altmodes even considered usb?
<whitequark> they're USB because they use the USB connector
<whitequark> you don't actually need to do anything with the USB data pairs
<rqou> this is retarded
<rqou> so if i just built a mechanical adapter between an sfp cage and usb-c, do i now have my own new altmode?
<whitequark> no
<whitequark> you need to do something with the USB PD control channel
<whitequark> to declare an altmode
<rqou> this hairball is ridiculous
<rqou> why does everything depend on everything?
<whitequark> you have to list your VID in the response to the Discover SVIDs command
<whitequark> and then you need to list your altmodes in response to the Discover Modes command
<whitequark> and then you need to handle the Enter Mode command
<whitequark> and a bunch of other shit too
<rqou> so what was your original problem?
<rqou> why doesn't acpi send a notification correctly?
<whitequark> who the fuck knows
<rqou> so what's supposed to happen if it does?
<whitequark> linux discovers the cable plug and lists it in sysfs under the usb port
<whitequark> then it discovers the device on the other end of the cable and lists it in sysfs under the cable plug
<whitequark> then it discovers the altmodes and lists them in sysfs under the device
<whitequark> then you can probably poke it
<rqou> so it sounds like you somehow forced it?
<whitequark> except half of this is unimplemented and the other half doesn't work
<whitequark> forced what?
<whitequark> it doesn't work yet
<rqou> oh nvm
<whitequark> hm
<whitequark> why does it say "USB power delivery version 2"
<whitequark> in sysfs
<rqou> isn't the "signals superimposed on vbus" the old version?
<rqou> pre type-c?
<whitequark> oh
<whitequark> PD 3.0 has Revision: 3.0 and Version: 1.2
<whitequark> there's no version 2
<whitequark> hang on
<whitequark> usb_power_delivery_revision
<whitequark> 2
<whitequark> ok hm
<rqou> if you see any mention of "shorted the data lines for 500mA" afaik that's the super duper ancient PD spec
<whitequark> >USB Power Delivery Rev. 2.0, v1.3 and USB Power Delivery Rev 3.0, v1.1 are functionally the same except with regard to new features incorporated into USB PD Rev. 3.0 in support of USB Authentication and other forthcoming specifications.
<whitequark> christ
<whitequark> I hate all of this
<rqou> oh sorry i was wrong
<rqou> the thing i was describing is not "power delivery"
<rqou> it's the "usb battery charging" spec :P
<whitequark> yeah
<rqou> oh wait
<whitequark> ok PD 2.0 is pretty much the same wrt modes
<rqou> you can totally signal both
<rqou> what happens if you signal PD _and_ battery charging?
<whitequark> dunno
<whitequark> don't care
<rqou> how does anybody actually test this?
<gruetzkopf> they don't seem to do that at all
<gruetzkopf> they don't seem to do that
<rqou> i bet a full test of everything USB would require quite a few time capsules too :P
<rqou> TI calculators and early PDAs did a lot of weird shit
Hamilton has joined ##openfpga
<whitequark> lol I crashed the USB PD chip in my laptop
<rqou> wtf
<rqou> why can this crash?
<whitequark> [845718.513440] ucsi_acpi USBC000:00: PPM NOT RESPONDING
* whitequark shrugs
<whitequark> or maybe the EC
<whitequark> ok so if I reload the module, it correctly discovers the uh
<whitequark> the fact that there's a partner plugged into the port
<gruetzkopf> why is there no proper notification for that
<whitequark> there is
<whitequark> it's done via ACPI
<whitequark> and it's kinda broken
<whitequark> it does work but only sometimes
<gruetzkopf> all this half-implemented-in-acpi stuff is terrifying
<rqou> how possible is it to write a TB driver stack that just tears down all ACPI handlers and takes over the chip directly?
azonenberg_work has quit [Ping timeout: 272 seconds]
<whitequark> impossible
<whitequark> you have to talk to the USB PD chip via EC
<whitequark> and the only interface description of EC is in ACPI
<rqou> can't you do that via in and out opcodes?
<whitequark> no
<rqou> not standardized?
<whitequark> talking to EC involves an SMM trap
<whitequark> at least on this laptop
<rqou> wtf
<gruetzkopf> that's likely 100% machine specific
<whitequark> that too
<whitequark> every interface that's actually standardized relies on ACPI
<whitequark> and ACPI converts the standard interface into awful shitty gunk that goes into the EC mailbox
azonenberg_work has joined ##openfpga
<rqou> hmm what are the chances that this "upgrade card" "just works" as a tb->pcie adapter? https://www.amazon.com/dp/B01NBULFMD
<rqou> gruetzkopf: you like crazy hacks, want to try it?
<gruetzkopf> don't have any TB hosts :P
<whitequark> rqou: uh
<whitequark> this is literally what it is
<rqou> does the backplane have anything special?
<whitequark> no
<whitequark> it just routes one PCIe connector to the other
<rqou> how do you know?
<whitequark> and has a bunch of misc junk like a switcher and a thermal sensor and a fan
<rqou> that's what i would assume
<whitequark> because I have that backplane.
<rqou> ah ok
<rqou> can you post a photo?
<rqou> i can't seem to find any on the intertubes
<whitequark> it's really not interesting
<rqou> wait, so what incompatibility are you experiencing right now?
<whitequark> and I'm lazy and don't wanna unscrew it
<whitequark> uh
<whitequark> the Apple Thunderbolt 3 to 2 adapter doesn't work
<whitequark> I have the Thunderbolt 2 version of the Sonnet bo
<whitequark> box
<rqou> ah ok
<whitequark> the card isn't available locally
<rqou> want me to just mail you one? :P
<rqou> i can get it with prime shipping here
<whitequark> if you buy it for me, sure :p
<rqou> pay me back in unusual russian electronics or something? :P
<whitequark> uh sure, which do you want
<rqou> idk, i can wait until later for that :P
<rqou> so i definitely don't need the chassis, right?
<whitequark> i'm pretty sure you don't need the chassis
<rqou> i can just splice some of the cursed cables together? :P
<whitequark> sigh ok let me take another look at the backplane
<whitequark> i should wake up my roommate and tell him to take a photo of it
<whitequark> he has one of those cameras that weigh like 2x more than my laptop and can use it really well
<whitequark> see the thunderbolt adapter PCB photo
<gruetzkopf> $mysterious_roommate strikes again
<whitequark> different roommate
<whitequark> this apartment kind of has a lot of randos in it
<whitequark> including me lol
<rqou> is this the apartment that got nitrated?
<rqou> actually whitequark want to just trade for the tb2 card?
<whitequark> yes
<whitequark> hm
<rqou> since that doesn't seem to be available standalone
<whitequark> sure, if you're fine with only sending it when the tb3 one arrives
<whitequark> on the off chance i get the adapter to work
<rqou> sure
<whitequark> i'm not actually sure that the tb3 card will fare any better, too
<whitequark> i *think* it *might* work better
<whitequark> but after looking at this horrorfest i am not sure in *anything* when it is involved
<gruetzkopf> i believe "all" that's required to get the apple tb3->tb2 adapter to work for DP displays is to implement DP alt mode and a mechanical switch..
<whitequark> i think so
<whitequark> you have the firmware
<gruetzkopf> and no reason to do it ;)
<whitequark> i... suppose you could tactically drill the case to get at the testpoints to reflash it
<whitequark> with a CNC mill
<whitequark> and some pogo pins
<gruetzkopf> did you see anything scary-usb-cc-fw-update-related in it?
<whitequark> i haven't tried to RE the firmware yet
<whitequark> i only confirmed that it has thumb code
<whitequark> not compressed or encrypted
<whitequark> no idea why the string table is mangled, it's weird
<whitequark> it could be that my setup for reading the firmware is shit, i'll capture a trace with my LA later
<whitequark> oh for fuck's sake
<whitequark> the altmode support in linux is just not implemented for ucsi
<whitequark> on top of the firmware bug that prevents hotplug notifications from appearing
<whitequark> sigh, let's add it
* azonenberg_work continues to suggest that whitequark simply drop the cursed protocol that is USB
<azonenberg_work> and move to something sane like ethernet
<rqou> huh startech now has an x520 clone
<whitequark> azonenberg_work: you can't run an eGPU over ethernet
<rqou> azonenberg_work: how are you planning to get the ethernet into a fruit computer?
<azonenberg_work> rqou: i also wouldn't buy a fruit computer :p
<whitequark> rqou: i don't use fruit computers
<rqou> also the startech x520 clone is way more expensive than a NOS x520
<rqou> that's pretty unusual for them; usually their pricing is pretty decent
<rqou> oh wow the 82599ES chip is _old_
<rqou> launched in 2009, 65nm
<gruetzkopf> Expected Discontinuance Q1'23
<rqou> still a super reliable chip unlike the mellanox piece of shit
<azonenberg_work> whitequark: you can't?
<azonenberg_work> What about...
<azonenberg_work> (17:08:03) gruetzkopf: ethertype 0x22E4 :P
<azonenberg_work> (sure, you need an fpga or something on the far side to bridge back but...)
<rqou> azonenberg_work: build it first
<rqou> then talk
<rqou> :P
<azonenberg_work> rqou: if you gave me a pcie master
<azonenberg_work> i could make you eGPU over RS232 if i wanted to :p
<rqou> no
<rqou> bad
<rqou> should not copy f0f
<azonenberg_work> 22e4 framing over PPP over RS232
<azonenberg_work> :p
<whitequark> azonenberg_work: well i don't understand pcie
<whitequark> or high speed serdes
<whitequark> so it's easier to fix this usb-c shit
<whitequark> the linux source defines the macro ARRAY_SIZE 47 (forty seven) times
Hamilton2 has joined ##openfpga
Hamilton2 has quit [Read error: Connection reset by peer]
Hamilton2 has joined ##openfpga
<whitequark> ugh I hate C
Hamilton has quit [Ping timeout: 246 seconds]
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
Hamilton2 has quit [Quit: Leaving]
<whitequark> ugh do I have to download a linux source tree
<whitequark> i ain't got disk space for that
<gruetzkopf> wow, you're even more disk-constrained than i am
<gruetzkopf> (looks at 4 linux trees in ~)
<whitequark> gruetzkopf: it's mostly taken by gigantic LLVM debug builds
<whitequark> and Windows VMs
[X-Scale] has joined ##openfpga
X-Scale has quit [Ping timeout: 245 seconds]
[X-Scale] is now known as X-Scale
q3k1 is now known as q3k
<whitequark> rqou: ugh
<whitequark> so the adapter advertises some mode with SVID 8087 (Intel I guess. why not 8086?) and some mode with SVID 05ac (Apple)
<whitequark> and it looks like the 8087 mode is just "USB"
<whitequark> what's the fucking point but whatever
<whitequark> so the adapter *is* apple-locked
<gruetzkopf> idiots
<gruetzkopf> so a capture of a "normal" tb3 alt-mode exchange would help now?
<whitequark> yes
<whitequark> would help a lot
<gruetzkopf> (i'd be far to easy if there was a way to query the host-supported alt modes, you know, for actually helping the user if stuff doesn't work)
<gruetzkopf> ("you've plugged in x into y1, but that only works in ports z1 to z4")
<whitequark> gruetzkopf: uh there is such a way
<whitequark> i just wrote a patch for linux that makes it possible
<whitequark> it was exposed via ACPI but not actually used in linux before
<whitequark> [856816.978580] ucsi_acpi USBC000:00: con1: found port altmode 8087:00000001
<whitequark> [856816.978606] ucsi_acpi USBC000:00: con1: found port altmode ff01:00001c46
<whitequark> [856817.282308] ucsi_acpi USBC000:00: con1: in altmode index 0
<whitequark> [856817.128092] ucsi_acpi USBC000:00: con1: found port altmode 413c:00000001
<whitequark> [856818.277557] ucsi_acpi USBC000:00: con1: found partner altmode 8087:00000001
<gruetzkopf> a TI document i found suggests 8087:0001 is thunderbolt
Bike has joined ##openfpga
<gruetzkopf> and ff01 is plain DP mode
<whitequark> hmmmm
<whitequark> gruetzkopf: any idea what 8087:00000003 is?
<gruetzkopf> so it looks like the 16bit part is the actual link mode
<gruetzkopf> and the vendor can decide what the other 32 bit do
<whitequark> also, whoa
<gruetzkopf> in displayport, it indicates possible muxer configs
<whitequark> slva931 gives me a LOT to work with
<gruetzkopf> it leaks quite a lot of the tps6598x stuff
<whitequark> though, hm
<whitequark> this is the *host* interface
<whitequark> might not work the same on the device
<whitequark> >A tool specifically made for TPS65983 exists. It contains projects explicitly for Intel
<whitequark> Thunderbolt reference designs.
<whitequark> oh.
<gruetzkopf> page 3 "adapter mode response" is mentioned
<whitequark> THAT is why TPS65983 exists.
<gruetzkopf> *grabs generic tool*
<gruetzkopf> i couldn't find out what the third alt mode is
<gruetzkopf> (41c3)
<whitequark> 413c?
<whitequark> oh
<whitequark> this is Dell
<whitequark> it's for the Dell dock
<whitequark> the Dell dock passes PCIe lanes directly into the dock I think
<whitequark> so it doesn't require Thunderbolt support from the OS
<gruetzkopf> is this dell specific or the proper alt mode?
<whitequark> pretty sure this is dell specific
<whitequark> the 413c is Dell's USB VID
<gruetzkopf> ah
<gruetzkopf> (why can't they simply publish a list..)
<whitequark> it's the USB VID list
<whitequark> the ff* are defined in the USB standard
<whitequark> and everything else is in usb.ids
<gruetzkopf> where in the usb standard is it?
<gruetzkopf> didn't see it in typec or pd
<whitequark> I think it's defined like that by reference
<gruetzkopf> i've seen it pointing to partner specs
<gruetzkopf> (which i sadly don't have)
<gruetzkopf> so i found another screenshot of the tool which also shows a MIPI VID and DP config
<gruetzkopf> (also, wow, this stupid spec supports _6_ batteries per usb-pd device
<whitequark> yep
rohitksingh_work has quit [Read error: Connection reset by peer]
<gruetzkopf> grab the ti tool (linked in the document), it talks about very interesting things like TB4
<whitequark> yeah I have it
<gruetzkopf> also: several fw images
<whitequark> yep
<whitequark> I already decompiled the entire thing and ported it to Linux
<whitequark> that's how I know that I can read and write registers by querying the billboard device
<whitequark> lemme do that
zino has quit [Quit: Leaving]
<gruetzkopf> i have a non-tb usb-c hosting laptop that i should try
zino has joined ##openfpga
<whitequark> do you have this adapter?
<gruetzkopf> not personally, i know a few fruit computer users who have it
<whitequark> sigh
<whitequark> the device doesn't respond to register reads/writes
<whitequark> i *guess* i can just poke its i2c
<whitequark> very obnoxious
<whitequark> ok lemme rework it to get access to testpoints
<whitequark> should probably read the firmware properly first
<whitequark> ugh goddamn tiny testpoints
<whitequark> gonna end up tearing off one of them am i not
<whitequark> put a disgusting blob of hot glue on it
<gruetzkopf> OSINT on DP alt mode: pinout "C" is all-four-diffpairs-as-dp
<whitequark> ok but I'm not actually interested in DP altmode
<whitequark> this laptop doesn't even support it
<gruetzkopf> yes it does
<whitequark> (officially known)
<whitequark> what
<whitequark> hang on
<whitequark> *what*
<whitequark> dell says it doesn't
<gruetzkopf> ff01:randomgarbage is DP alt
<whitequark> LOL
<whitequark> what hte fuck
<gruetzkopf> the random garbage is the exact config details (haven't decoded your specific laptop yet)
<gruetzkopf> it's a TB host, it should support DPALT
<gruetzkopf> so 1c64 is DFP-D only, DP-Phy only, this is a receptacle, concurrent usb2 enabled, pinouts C, D, E, F
<gruetzkopf> now, that MAY be a bogus claim by your alt mode controller, but this is what it says
<gruetzkopf> oh, not F, sorry
<gruetzkopf> i should automate decoding that
<pie__> what're you working on?
<gruetzkopf> i'm somehow doing OSINT for whitequarks "fun with thunderbolt" quest
<whitequark> gruetzkopf: ok, i got the SPI trace
<pie__> ah
<pie__> good luck \o/
Bike has quit [Ping timeout: 252 seconds]
<pie__> jesus christ https://twitter.com/whitequark/status/1035910333490241538 you two were made for eachother lmao
<pie__> jk jk
rohitksingh has joined ##openfpga
rohitksingh1 has joined ##openfpga
rohitksingh has quit [Ping timeout: 244 seconds]
<whitequark> rqou: WTF
<whitequark> I compared what I read from the flash to what the controller read from the flash
<whitequark> sha1 matches
<whitequark> the strings in the string table really are that weirdly mangled
<gruetzkopf> endian-swapped UCS-2 or what monstrosity have they built?
<whitequark> no
<whitequark> worse
<whitequark> they look... compressed
<whitequark> but they aren't
<whitequark> afaict
<whitequark> ok, I have a first problem trying to replace the firmware
<whitequark> I found where it stashes the firmware size and CRC
<whitequark> but it uses some weird CRc.
<sorear> so in my experience with baby's first software obfuscation, "mangle the strings" is the first thing they do
<sorear> maybe they stopped there
<whitequark> lol
<whitequark> spiflash-1: Read data (addr 0x000000, 4 bytes): 00 40 00 00
<whitequark> spiflash-1: Read data (addr 0x000ffc, 4 bytes): 00 60 06 00
<whitequark> spiflash-1: Read data (addr 0x06a00c, 4 bytes): 04 ff 00 00
<whitequark> spiflash-1: Read data (addr 0x06a008, 4 bytes): 00 10 00 00
<whitequark> spiflash-1: Read data (addr 0x06a000, 4 bytes): 01 00 e0 ac
<whitequark> spiflash-1: Read data (addr 0x06a010, 4 bytes): eb bf 8d 57
<whitequark> then a read of 0xff04 bytes
<whitequark> I know what the 1st, 2nd, 5th and 6th words mean
<whitequark> 3rd is probably a header/command and 4th is probably a memory destination
<whitequark> SWD would help, assuming it's not fused off
<gruetzkopf> the more i read about this, the more confused i am about this not working
<gruetzkopf> can you i2c-poke the DUT with your current arrangement?
<gruetzkopf> i'm interested in the TB-autoentry bit being set (register 0x52 bit 49)
Bike has joined ##openfpga
<whitequark> uh yeah I can try
* whitequark heats up the soldering iron
* whitequark sighs
rohitksingh1 has quit [Ping timeout: 252 seconds]
Miyu has joined ##openfpga
rohitksingh has joined ##openfpga
<whitequark> hm
<whitequark> SCL is high, SDA is lwo
<whitequark> at idle
<whitequark> thats kinda weird, it should have pullups...
<whitequark> oh lol
<whitequark> I misconnected something
<whitequark> ok, there is zilch on I2C on bootup
<whitequark> gruetzkopf: any chance you can tell me the correct I2C sequence?
<whitequark> I'm testing a few things meanwhile
<gruetzkopf> i'll find out
rohitksingh1 has joined ##openfpga
rohitksingh has quit [Ping timeout: 245 seconds]
m4ssi has joined ##openfpga
<gruetzkopf> so.. address is 0b0100xxxw with 000 being default for x
<whitequark> gruetzkopf:
<whitequark> [ INFO] glasgow.applet.i2c.master: scan found read address 0b111000
<whitequark> [ INFO] glasgow.applet.i2c.master: scan found read address 0b1101011
<whitequark> weird.
<whitequark> [ INFO] glasgow.applet.i2c.master: scan found write address 0b111000
<whitequark> [ INFO] glasgow.applet.i2c.master: scan found write address 0b1101011
<gruetzkopf> the former is a valid address for the second i2c bus
<gruetzkopf> equivalent in function
<gruetzkopf> sequence would be addr_w , reg_nr (0x52), restart, addr_w, read * 8
<whitequark> okay sec
<openfpga-github> [Glasgow] whitequark pushed 1 new commit to master: https://github.com/whitequark/Glasgow/commit/25ab549687f30bf9583f330374858f67ffd2330a
<openfpga-github> Glasgow/master 25ab549 whitequark: applet.i2c.master: add an option to drop into Python shell.
<gruetzkopf> sorry, addr-r after the restart, of course
<gruetzkopf> (but this is all volatile afaict)
<travis-ci> whitequark/Glasgow#35 (master - 25ab549 : whitequark): The build passed.
<gruetzkopf> oh, it's worse (bad docs). the first byte you read back is bytes_to_read. variable length "registers"
<gruetzkopf> but this should work in this case
<whitequark> wtf ok
<gruetzkopf> if that works, you should be able to grab the full device state by enumeration all 0xFF possible registers
<gruetzkopf> the longest field i've seen so far is 64 bytes
<whitequark> alright, sec
<gruetzkopf> 0x7f is the last register i see in the tooling
<whitequark> gruetzkopf: i2c_iface.write(0b111000, [0x00]);i2c_iface.read(0b111000, 8, stop=True) => bytearray(b'\xf0\x9f\xff\xff\xff\xff\xff\xff')
<whitequark> seems sensible?
<gruetzkopf> sensible reply, yeah
<whitequark> >>> read_reg(0x52)
<whitequark> <coroutine object read_reg at 0x7f6df4b685c8>
<whitequark> bytearray(b'\xff\xe0\xff\xff\xff\xff\xff\xff')
<whitequark> actually, hang on
<whitequark> that's not at all what happens on the bus, wtf
GenTooMan has joined ##openfpga
<whitequark> gruetzkopf: oh god
<whitequark> I think it wants clock stretching
<gruetzkopf> ctrl-f says yes
<whitequark> bleh
<whitequark> ok
<whitequark> let's just run it at 10 kbps
<gruetzkopf> this documentation is absolutely terrible
<whitequark> no shit
<whitequark> aha
<whitequark> yeah, that's more like it
<gruetzkopf> can we get (someone else) to filter through the last few weeks of this channel and your twitter and write it down?
<whitequark> >>> read_reg(0)
<whitequark> <coroutine object read_reg at 0x7f10930f6e08>
<whitequark> bytearray(b'\x04(\x00\x00\x00\x00\x00\x00')
<whitequark> gruetzkopf: I write it down in the kernel.org bugzilla bug for this adapter
<whitequark> blog style
<whitequark> I bet I annoy all the twenty people who are CC'd on it but idgaf
<gruetzkopf> try 0x52 , that should have at least 4 bits set
<whitequark> >>> read_reg(1)
<whitequark> <coroutine object read_reg at 0x7f10930f65c8>
<whitequark> bytearray(b'\x04ACE1\x00\x00\x00')
<whitequark> yeah this is definitely valid
<whitequark> ACE1 is present in firmware
<whitequark> application customization entry or something
<whitequark> gruetzkopf: bytearray(b'\x83\xff\xff\xff\xff\xff\xff\xff')
<gruetzkopf> okay, so of course the register layout is different..
<whitequark> hang on
<whitequark> more clock stretching
<whitequark> i think
<whitequark> sec
<whitequark> yeah let me hack this more properly
<gruetzkopf> so if you're doing thos more properly, read one byte after restart, then [byte] more
<gruetzkopf> (yes, this is terrible)
<whitequark> i... hm
<whitequark> not sure if i'm wrong or sigrok is wrong
<whitequark> oh WTF
<whitequark> how did my code *ever* work
<whitequark> gruetzkopf: ok, I figured it all out
<whitequark> framing error Glasgow-side
<whitequark> I *really* need to do something about desync of FIFOs Glasgow-side with software-side
<whitequark> anyway
<whitequark> gruetzkopf: 06 fe fe fe fe fe fe ff
<whitequark> does this look sensible
<gruetzkopf> for 0x52?
<whitequark> yes
<whitequark> either this or \x83\xff\xff\xff\xff\xff\xff\xff
<whitequark> one is what Glasgow says, the other is what my LA says
<whitequark> and I can't tell which one of them lies
<whitequark> the former looks less insane
<whitequark> ugh neither of them is correct
<whitequark> sec
<gruetzkopf> for all of the TPS6598x i can find 0x52 is 8 bytes long
<Ultrasauce> the only thing worse than being gaslit by the tooling is when you built it yourself
<whitequark> gruetzkopf: \x07\x03\x00\x01\x00\x03\x00\x05
<whitequark> clock stretching *again*
<whitequark> i now run i2c at 1 kbps
<gruetzkopf> of 0x51 7 is a seen-before length
<whitequark> 0x51 is \x07\x00\x00\x00\x1c\x00\x00\x00
<whitequark> lemme just dump all of them
<Ultrasauce> is this the TB thing you're working on?
<whitequark> yes
<whitequark> gruetzkopf: https://hastebin.com/tivariyoyo.http
<gruetzkopf> ok.. would it be to horrible to implement first-reply-byte-is-data-length (exclusive of itself)?
<whitequark> not really, sec
<gruetzkopf> this looks good so far though
<whitequark> let me make it into a proper applet first
<whitequark> the REPL became a mess
<whitequark> gruetzkopf: I can just read it twice right?
<whitequark> or are there any registers where reads are side effectful?
sunxi_fan has quit [Quit: Leaving.]
<whitequark> it'd be a royal pain to redo the gateware to support this properly...
<gruetzkopf> none where that's documented
<whitequark> ok
<shapr> https://twitter.com/shapr/status/1036645335580459008 "If Brexit goes through, I'm going to start calling the Disjunction Jack instead of the Union Jack."
<shapr> I crack me up.
<gruetzkopf> (not that any of them are properly documented, but i haven't seen any read sideffects, certainly not in the config)
* shapr goes back to fixing verilog
<pie__> shapr, symmetric difference
<shapr> yeah, not as quotable though
<pie__> :p
<whitequark> gruetzkopf: https://hastebin.com/ofoqatakuc.http
<whitequark> registers 47 and 4f are interesting
kuldeep has quit [Ping timeout: 272 seconds]
<gruetzkopf> 47 "transmit identity data object"
kuldeep has joined ##openfpga
<gruetzkopf> i still don't see why this -3 ic variant exists
<whitequark> gruetzkopf: docs heavily imply it exists *only* to support Intel reference designs
<whitequark> which is insane
<gruetzkopf> yes
<gruetzkopf> especially as its (known) features are all included in the other
<whitequark> yep
<whitequark> and there's even a -3B variant
<gruetzkopf> apple has at least two different 3letter
<whitequark> I think Apple -B is -3A and Apple -C is -3B
<whitequark> but I'm not sure
<whitequark> gruetzkopf: any interesting write ideas?
<gruetzkopf> i'm still staring at bitfields
<whitequark> ahh k
<whitequark> thanks!
<gruetzkopf> they seem to have messed with things just for the sake of it
rohitksingh1 has quit [Quit: Leaving.]
rohitksingh has joined ##openfpga
rohitksingh has quit [Quit: Leaving.]
<gruetzkopf> do you know which pd controller/firmware your laptop uses?
<whitequark> gruetzkopf: not sure; it's in the BIOS
<whitequark> let me see
<gruetzkopf> i'm currently chasing a lead on the config template for the ti tool
<whitequark> gruetzkopf: LOL
<gruetzkopf> i found a config a person leaked onto ti e2e
<whitequark> there's a TPS65982 firmware in the BIOS
<gruetzkopf> that matches 7 bytes for 0x52 and stuff like that
<whitequark> aha
rohitksingh has joined ##openfpga
<gruetzkopf> from googling around there's deliberate incompatibility between the -2 and the -3
<whitequark> wtf
<whitequark> gruetzkopf: but how does it *happen*
<gruetzkopf> i've not seen a 2-2, neither a 3-3 handshake
<whitequark> hm
<gruetzkopf> i'll go hunting for the -3 tooling some more
rohitksingh has quit [Quit: Leaving.]
m4ssi has quit [Remote host closed the connection]
<cr1901_modern> whitequark: At this point in the Thunderbolt saga, I've forgotten what you were originally trying to do :P. Is the idea your adapter doesn't work, and it's b/c Apple is deliberately locking out non-Apple products?
rohitksingh has joined ##openfpga
<gruetzkopf> the apple adapter does not work on a dell xps 13
<gruetzkopf> and apparently there's no good reason for it
<gruetzkopf> terrible question: have you tried this with up-to-date NT?
rohitksingh has quit [Quit: Leaving.]
kuldeep has quit [Ping timeout: 272 seconds]
azonenberg_work has quit [Ping timeout: 272 seconds]
kuldeep has joined ##openfpga
azonenberg_work has joined ##openfpga
rohitksingh has joined ##openfpga
<whitequark> gruetzkopf: what do you think about setting "TBT emarker override"?
<whitequark> NT, no
<whitequark> I should
<whitequark> actually, scratch that
<whitequark> there's no way to control the PD controller via software on Dell platforms
<whitequark> I've seen Dell people say that on LKML
<gruetzkopf> that's terrible
<whitequark> yeah
<whitequark> the USB C ACPI interface is shitty even by already low USB C standards
<gruetzkopf> (even this ooold dell laptop has fun ec bugs
<gruetzkopf> sometimes keys get soft-stuck
<gruetzkopf> also hard lockout between keyboard and trackpad
<whitequark> gruetzkopf: wait
<whitequark> TBTModeDataTXSOP Upper 16 bits of data to be sent on Intel VID SVDM Discover Modes (SOP) response (UFP) or
<whitequark> used to drive TBT AM policy (DFP).
mumptai has joined ##openfpga
<whitequark> this makes it send SVDM response 8087:00010001
<whitequark> instead of the proper 8087:00000001
<whitequark> the host PD still reports 8087:00000001, probably because it's buggy or something
<gruetzkopf> can you verify that on the wire?
<whitequark> yes, I did
<whitequark> 8087:00010001 is what it sends on the wire
<whitequark> that surprised me
<gruetzkopf> iinteresting
rohitksingh has quit [Quit: Leaving.]
<whitequark> lemme add a write-reg function
<gruetzkopf> which bit do you suspect to mean that
<whitequark> what do you mean "suspect"
<whitequark> TBTModeDataTXSOP
<gruetzkopf> oh, so the 8 is a bug in the tool
<gruetzkopf> (Iength)
<whitequark> you mean the fact that everything cuts off at 8 bytes?
<whitequark> yeah
<whitequark> it's something about the way it does I2C
<gruetzkopf> no
<whitequark> oh?
<gruetzkopf> the tool says 8 byte length for 0x52 on all chips i have templates sor
<gruetzkopf> *for
<whitequark> hm
<whitequark> lol
kuldeep has quit [Ping timeout: 250 seconds]
kuldeep has joined ##openfpga
<whitequark> gruetzkopf: ok, I have successfully sent it a reset command
<whitequark> and it reset itself
<whitequark> "GAID" to 0x08
<gruetzkopf> ok
<gruetzkopf> oh, the "public" tool contains a TPS65983b_register_definitions_reduced.py which seems unused
<gruetzkopf> but contains most of the register descriptions anyways
<whitequark> yeah
<whitequark> ok the register contents are reloaded after a reset.
<whitequark> annoying.
<whitequark> the DISC command is not recognized.
<gruetzkopf> even the "reduced" tpl/py file should be enough to make the ti tool do this job
<gruetzkopf> (generate a new firmware image, diff, write)
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
<whitequark> I couldn't do it yesterday, actually
<whitequark> it just kept crashing in weird ways
<whitequark> gruetzkopf: also, I can't figure out what CRC-32 polynomial and residual it wants
<whitequark> I've ran quickbms on the data read via SPI but no luck...
kmehall has quit [*.net *.split]
eddyb has quit [*.net *.split]
whitequark has quit [*.net *.split]
elms has quit [*.net *.split]
ovf has quit [*.net *.split]
comietek has quit [*.net *.split]
mithro has quit [*.net *.split]
pointfree has quit [*.net *.split]
bubble_buster has quit [*.net *.split]
eightdot has quit [*.net *.split]
reportingsjr has quit [*.net *.split]
tnt has quit [*.net *.split]
florolf has quit [*.net *.split]
eightdot has joined ##openfpga
reportingsjr has joined ##openfpga
florolf_ has joined ##openfpga
whitequark has joined ##openfpga
elms has joined ##openfpga
eddyb has joined ##openfpga
bubble_buster has joined ##openfpga
comietek has joined ##openfpga
ovf has joined ##openfpga
pointfree has joined ##openfpga
Guest1973 is now known as oni
mithro has joined ##openfpga
comietek has quit [Changing host]
comietek has joined ##openfpga
comietek has joined ##openfpga
kmehall has joined ##openfpga
tnt has joined ##openfpga
<whitequark> gruetzkopf: weird.
<whitequark> I can't modify anything via registers. any behavior.
<whitequark> I disable Intel VID and it still advertises Intel VID.
<gruetzkopf> interesting
<whitequark> I can read it back too
<gruetzkopf> maybe their firmware only looks at flash for actual actions?
<gruetzkopf> i don't want to have to read TI code, though
<whitequark> looks like it
<whitequark> but why?..
<whitequark> that kind of defeats the whole point of the host interface
<gruetzkopf> if in doubt, guess intel made them do it
<whitequark> gruetzkopf: also, 0x5f is *not* "Data Status Register"
<whitequark> it doesn't change if I flip the plug
<gruetzkopf> the host does that in attached-cable applications
<whitequark> oh
mithro has quit []
mithro has joined ##openfpga
ayjay_t has joined ##openfpga
emeb has joined ##openfpga
azonenberg_work has quit [Ping timeout: 245 seconds]
azonenberg_work has joined ##openfpga
kuldeep has quit [Ping timeout: 244 seconds]
kuldeep has joined ##openfpga
kuldeep has quit [Ping timeout: 240 seconds]
kuldeep has joined ##openfpga
<jn__> pie__: fun!
emeb has quit [Quit: Leaving.]
<esden> tnt: ok it turns out my memory failed me once again. It turns out I have never ordered the V0.2 of the icebreaker-tiny hardware. I am working on some changes to the icebreaker to get it to V1.0, I will place an order for the icebreaker-tiny as soon as that is done so that it gains the improvements from my full size icebreaker work if there are any.
<esden> but the version here: https://github.com/esden/icebreaker/tree/master/hardware/bitsy-v0.2a should be usable from the hardware standpoint. I just would like to carry forward the changes I might make in the full size version to it.
futarisIRCcloud has joined ##openfpga
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##openfpga
mumptai has quit [Ping timeout: 244 seconds]
cr1901_modern has quit [Read error: Connection reset by peer]
cr1901_modern has joined ##openfpga
mumptai has joined ##openfpga